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