[x264-devel] x264-devel Digest, Vol 76, Issue 7
Hồ Thị Bé
ctbk1989 at gmail.com
Fri Sep 13 13:12:38 CEST 2013
Thanks for your reply.
On Fri, Sep 13, 2013 at 4:43 PM, <x264-devel-request at videolan.org> wrote:
> Send x264-devel mailing list submissions to
> x264-devel at videolan.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailman.videolan.org/listinfo/x264-devel
> or, via email, send a message with subject or body 'help' to
> x264-devel-request at videolan.org
>
> You can reach the person managing the list at
> x264-devel-owner at videolan.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of x264-devel digest..."
>
>
> Today's Topics:
>
> 1. x265: Questions and comments from an outsider (Derek Buitenhuis)
> 2. Re: x265: Questions and comments from an outsider
> (Derek Buitenhuis)
> 3. Re: x265: Questions and comments from an outsider (Ivan Pozdeev)
> 4. Re: x265: Questions and comments from an outsider
> (Derek Buitenhuis)
> 5. x264 devel (H? Th? B?)
> 6. Re: x264 devel (BugMaster)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 12 Sep 2013 12:00:06 +0100
> From: Derek Buitenhuis <derek.buitenhuis at gmail.com>
> To: Mailing list for x264 developers <x264-devel at videolan.org>
> Subject: [x264-devel] x265: Questions and comments from an outsider
> Message-ID: <52319EB6.80608 at gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> So rather than break up all these (very general) comments between N
> separate emails,
> inlined in patch reviews, I figured one canonical place to air them should
> be more
> appropriate and conducive to open discussion.
>
> In no particular order, some comments:
>
>
> Code Style (or Lack Thereof)
> ----------------------------
>
> Currently, x265 is a giant mess with no consistent code style, practices,
> or guidelines.
> Certainly nothing is enforced. Below is a list of issues to discuss
> related to this.
>
> 1) Indentation: How many spaces do you indent? This is inconsistent
> throughout the codebase,
> patches regularily get pushed which randomly change it -- likely due to
> haphazardly copy
> and pasted code. This should be set and enforced, no? Perhaps a push
> hook that LINTs the
> patch? This is what Libav does.
>
> 2) Variable & Function Names: Again, inconsistent. some members have a
> MS-style 'm_' prefix,
> some have no prefix. Some have an 'n' prefix. Some have an 'x265_'
> prefix, which ideally
> should only be used for public API function namespacing.
>
> 3) References vs. Pointers: Self explanatory -- usage is inconsistent
> between const pointers,
> references, pointers, etc.
>
> 4) Function Code in Headers: Is this acceptable? Is there policy of when
> to do this? It's done
> seemingly at random currently, and is very confusing/ugly.
>
> 5) Formatting: Whitespace, code layout etc. Braces on ae line or next?
> When? How to format
> an 'if' statement? if(x)? if (x)? if( x )? if ( x )? Stuff like that.
> VERY inconsistent.
>
> 6) Header Guards: Non-generic header guards are needed so as to not
> contaminate the namespace
> or conflict with system headers. __LIST__ is a good example of a bad
> guard.
>
> Certainly these sorts of things need to be enforced to some extent within
> reason, or the codebase
> is only going to get even more bad/messy.
>
>
> Reviews (or Some Are More Equal Than Others)
> --------------------------------------------
>
> Some developers do not have their code reviewed. Some do. This sort of
> thing won't go
> down so well with community contributors, I think.
>
> Also, developers mostly seem to send their code for review, but aside from
> Steve, nobody
> seems to review others' work.
>
>
> Commit Messages
> ---------------
>
> They're quite bad.
>
> I understand that English is not the native tongue of many of the
> developers, and I
> think that they would have an easier time if there was a clear and concise
> set of
> rules for creating commit messages defined somewhere for them to follow. A
> checklist,
> perhaps. It's been my experience that this would help non-native speakers,
> but that's
> only one man's hearsay.
>
>
> Memory Allocation/Reallocation/Freeing
> --------------------------------------
>
> It's a mess. A big one. The codebase is a tangled mess of inconsistently
> used malloc(),
> free(), new, delete, X265_MALLOC(), and X265_FREE(). X265_REALLOC() does
> not exist. So,
> which is it? Make up your minds! This will affect an future C ports.
>
>
> Reimplementations of STL and Related Identity Crises
> ----------------------------------------------------
>
> Why are you reimplementing STL classes like std::list? I could understand
> if it was in C,
> so as to aid in the promised future port to C, but it's being done in C++,
> using new and
> delete, etc. This makes no sense. There's no reason to do this other than
> some misguided
> Not In House syndrome or obsession with the resulting binary size. So, uh,
> what?
>
>
> Communication
> -------------
>
> Only Steve ever seems to be available on IRC, and since he travels a lot,
> it's very cumbersome
> to interact with the developers in real time. I don't even think the IRC
> channel is listed on
> the wiki page for contributing.
>
>
> Intrinsics
> ----------
>
> When will they die? When will new ones stop getting added? This may have
> been answered already,
> but I didn't hear/see anything.
>
>
> Priorities
> ----------
>
> This is by far the most concerning aspect for me, as an outsider. The
> priorities for x265 seem
> to be geared towards demos or a 'cash out'. Rather than making the encoder
> *good*, first priorities
> have gone to making it fast. This seems very backwards. Similarly, the
> most useless ratecontrol
> method is the only method being worked on, since MCW wants to demo HLS, as
> far as I can tell.
>
> Second to this, is that I don't completely trust that MCW will not either
> stop work after
> it demos / cashes out (or x265 is 'good enough'), or won't backseat
> important things for the
> sake of demos, etc.
>
> I've seen Bad Things? happen with corporations involved in FOSS time and
> time again, so you
> could say I'm once burned, twice shy.
>
>
> </list>
>
> I am sure I am missing some things, so any community members should add
> any I forgot.
>
> - Derek
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 12 Sep 2013 12:02:50 +0100
> From: Derek Buitenhuis <derek.buitenhuis at gmail.com>
> To: Mailing list for x264 developers <x264-devel at videolan.org>
> Subject: Re: [x264-devel] x265: Questions and comments from an
> outsider
> Message-ID: <52319F5A.7000307 at gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 9/12/2013 12:00 PM, Derek Buitenhuis wrote:
> > [...]
>
> Oh, *crap*, I typo'd x265 and x264. Please disregard this on this list.
>
> - Derek
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 12 Sep 2013 17:52:54 +0400
> From: Ivan Pozdeev <vano at mail.mipt.ru>
> To: Mailing list for x264 developers <x264-devel at videolan.org>
> Subject: Re: [x264-devel] x265: Questions and comments from an
> outsider
> Message-ID: <1137609764.20130912175254 at mail.mipt.ru>
> Content-Type: text/plain; charset=windows-1252
>
> A coding style and other rules are only good as long as they
> facilitate the project's goal. Formal rules are an additional burden
> that drains time and effort and only generally become more worth that
> trouble when the activity expands beyond one man's field of vision. Current
> core team is small and apparently does good at maintaining the
> product's quality as it is. The external contributions volume is pretty
> small
> too so they seem to be able to handle them without
> special efforts to streamline the process.
>
> Regarding code style: see
> http://www.joelonsoftware.com/articles/Wrong.html
> for 3 levels of code understanding.
>
> -----Original Message-----
> From: Derek Buitenhuis <derek.buitenhuis at gmail.com>
> Sent: Thursday, September 12, 2013 15:00
> To: Mailing list for x264 developers <x264-devel at videolan.org>
> Cc:
> Subject: [x264-devel] x265: Questions and comments from an outsider
>
> So rather than break up all these (very general) comments between N
> separate emails,
> inlined in patch reviews, I figured one canonical place to air them should
> be more
> appropriate and conducive to open discussion.
>
> In no particular order, some comments:
>
>
> Code Style (or Lack Thereof)
> ----------------------------
>
> Currently, x265 is a giant mess with no consistent code style, practices,
> or guidelines.
> Certainly nothing is enforced. Below is a list of issues to discuss
> related to this.
>
> 1) Indentation: How many spaces do you indent? This is inconsistent
> throughout the codebase,
> patches regularily get pushed which randomly change it -- likely due to
> haphazardly copy
> and pasted code. This should be set and enforced, no? Perhaps a push
> hook that LINTs the
> patch? This is what Libav does.
>
> 2) Variable & Function Names: Again, inconsistent. some members have a
> MS-style 'm_' prefix,
> some have no prefix. Some have an 'n' prefix. Some have an 'x265_'
> prefix, which ideally
> should only be used for public API function namespacing.
>
> 3) References vs. Pointers: Self explanatory -- usage is inconsistent
> between const pointers,
> references, pointers, etc.
>
> 4) Function Code in Headers: Is this acceptable? Is there policy of when
> to do this? It's done
> seemingly at random currently, and is very confusing/ugly.
>
> 5) Formatting: Whitespace, code layout etc. Braces on ae line or next?
> When? How to format
> an 'if' statement? if(x)? if (x)? if( x )? if ( x )? Stuff like that.
> VERY inconsistent.
>
> 6) Header Guards: Non-generic header guards are needed so as to not
> contaminate the namespace
> or conflict with system headers. __LIST__ is a good example of a bad
> guard.
>
> Certainly these sorts of things need to be enforced to some extent within
> reason, or the codebase
> is only going to get even more bad/messy.
>
>
> Reviews (or Some Are More Equal Than Others)
> --------------------------------------------
>
> Some developers do not have their code reviewed. Some do. This sort of
> thing won't go
> down so well with community contributors, I think.
>
> Also, developers mostly seem to send their code for review, but aside from
> Steve, nobody
> seems to review others' work.
>
>
> Commit Messages
> ---------------
>
> They're quite bad.
>
> I understand that English is not the native tongue of many of the
> developers, and I
> think that they would have an easier time if there was a clear and concise
> set of
> rules for creating commit messages defined somewhere for them to follow. A
> checklist,
> perhaps. It's been my experience that this would help non-native speakers,
> but that's
> only one man's hearsay.
>
>
> Memory Allocation/Reallocation/Freeing
> --------------------------------------
>
> It's a mess. A big one. The codebase is a tangled mess of inconsistently
> used malloc(),
> free(), new, delete, X265_MALLOC(), and X265_FREE(). X265_REALLOC() does
> not exist. So,
> which is it? Make up your minds! This will affect an future C ports.
>
>
> Reimplementations of STL and Related Identity Crises
> ----------------------------------------------------
>
> Why are you reimplementing STL classes like std::list? I could understand
> if it was in C,
> so as to aid in the promised future port to C, but it's being done in C++,
> using new and
> delete, etc. This makes no sense. There's no reason to do this other than
> some misguided
> Not In House syndrome or obsession with the resulting binary size. So, uh,
> what?
>
>
> Communication
> -------------
>
> Only Steve ever seems to be available on IRC, and since he travels a lot,
> it's very cumbersome
> to interact with the developers in real time. I don't even think the IRC
> channel is listed on
> the wiki page for contributing.
>
>
> Intrinsics
> ----------
>
> When will they die? When will new ones stop getting added? This may have
> been answered already,
> but I didn't hear/see anything.
>
>
> Priorities
> ----------
>
> This is by far the most concerning aspect for me, as an outsider. The
> priorities for x265 seem
> to be geared towards demos or a 'cash out'. Rather than making the encoder
> *good*, first priorities
> have gone to making it fast. This seems very backwards. Similarly, the
> most useless ratecontrol
> method is the only method being worked on, since MCW wants to demo HLS, as
> far as I can tell.
>
> Second to this, is that I don't completely trust that MCW will not either
> stop work after
> it demos / cashes out (or x265 is 'good enough'), or won't backseat
> important things for the
> sake of demos, etc.
>
> I've seen Bad Things? happen with corporations involved in FOSS time and
> time again, so you
> could say I'm once burned, twice shy.
>
>
> </list>
>
> I am sure I am missing some things, so any community members should add
> any I forgot.
>
> - Derek
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> https://mailman.videolan.org/listinfo/x264-devel
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 12 Sep 2013 16:38:50 +0100
> From: Derek Buitenhuis <derek.buitenhuis at gmail.com>
> To: x264-devel at videolan.org
> Subject: Re: [x264-devel] x265: Questions and comments from an
> outsider
> Message-ID: <5231E00A.3040607 at gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 9/12/2013 2:52 PM, Ivan Pozdeev wrote:
> > A coding style and other rules are only good as long as they
> > facilitate the project's goal. Formal rules are an additional burden
> > that drains time and effort and only generally become more worth that
> > trouble when the activity expands beyond one man's field of vision.
> Current
> > core team is small and apparently does good at maintaining the
> > product's quality as it is. The external contributions volume is pretty
> small
> > too so they seem to be able to handle them without
> > special efforts to streamline the process.
> >
> > Regarding code style: see
> http://www.joelonsoftware.com/articles/Wrong.html
> > for 3 levels of code understanding.
>
> The email was sent to this list in error. If you wish to discuss this,
> please
> use x265-devel.
>
> - Derek
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 13 Sep 2013 10:43:06 +0700
> From: H? Th? B? <ctbk1989 at gmail.com>
> To: x264-devel at videolan.org
> Subject: [x264-devel] x264 devel
> Message-ID:
> <
> CAOKJgXyoG8wnAFxAsGa7pQqXQW2T7GAb7_HDu8X2THpjT674kw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all!
> I have a question about x264 development. x264 can support RGB(24bit)
> format?
>
> Thanks advance!
> --
> ^_^
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mailman.videolan.org/pipermail/x264-devel/attachments/20130913/76a58666/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Fri, 13 Sep 2013 13:43:34 +0400
> From: BugMaster <BugMaster at narod.ru>
> To: Mailing list for x264 developers <x264-devel at videolan.org>
> Subject: Re: [x264-devel] x264 devel
> Message-ID: <742068141.20130913134334 at narod.ru>
> Content-Type: text/plain; charset=utf-8
>
> On Fri, 13 Sep 2013 10:43:06 +0700, H? Th? B? wrote:
>
>
> > Hi ?all!
> > I have a question about x264 development. x264 can support RGB(24bit)
> format?
>
>
> > Thanks advance!--
>
> > ^_^
> >
> Hi. Yes, x264 supports both RGB input and output (more preciously it is
> GBR in H.264). For RGB output you need to specify "--output-csp rgb"
> option (without quotes).
>
> P.S. For decoding of RGB output you will need decoder with it support
> because this is High 4:4:4 Predictive profile feature.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> https://mailman.videolan.org/listinfo/x264-devel
>
>
> ------------------------------
>
> End of x264-devel Digest, Vol 76, Issue 7
> *****************************************
>
--
^_^
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20130913/6252f3ed/attachment-0001.html>
More information about the x264-devel
mailing list