[FFmpeg-cvslog] random thoughts about refactoring

compn tempn
Sun Jan 10 23:16:17 CET 2010


On Sun, 10 Jan 2010 22:23:34 +0100, Michael Niedermayer wrote:
>On Sun, Jan 10, 2010 at 02:48:00PM -0500, compn wrote:
>> On Sun, 10 Jan 2010 17:42:24 +0100, Michael Niedermayer wrote:
>> >On Sun, Jan 10, 2010 at 12:44:24PM +0100, Diego Biurrun wrote:
>> >> On Fri, Jan 08, 2010 at 02:28:16AM +0100, Michael Niedermayer wrote:
>> >> > On Fri, Jan 08, 2010 at 01:20:03AM +0100, Diego Biurrun wrote:
>> >> > > On Wed, Jan 06, 2010 at 06:38:14PM +0100, Michael Niedermayer wrote:
>> >> > > > On Tue, Jan 05, 2010 at 11:08:22PM +0100, Diego Biurrun wrote:
>> >> > > > > On Tue, Jan 05, 2010 at 08:43:51PM +0100, Michael Niedermayer wrote:
>> >> > > > > > On Tue, Jan 05, 2010 at 11:29:46AM +0100, Diego Biurrun wrote:
>> >> > > > > > > On Tue, Jan 05, 2010 at 03:20:47AM +0100, Michael Niedermayer wrote:
>> >> > > > > > > > On Mon, Jan 04, 2010 at 08:23:23PM +0100, Diego Biurrun wrote:
>> >> > > > > There are people here who know H.264 well enough to lend
>> >> > > > > a helping hand in theory, but in practice the implementation in lavc is
>> >> > > > > just too impenetrable.  h264.c is around 10.000 lines if you count svq3.c
>> >> > > > > which it directly includes!
>> >> > > > 
>> >> > > > > 
>> >> > > > > Also, our H.264 decoder is not a speed demon.
>> >> > > > 
>> >> > > > That seems to depend on CPU and situation, gcc making poor inlining choices
>> >> > > > and overflowing the available caches is not exactly the codes fault ...
>> >> > > 
>> >> > > Carl Eugen was the first person I have ever heard claim that our
>> >> > > H.264 decoder was faster than anything, ever...
>> >> > 
>> >> > Ive never tried CoreAVC, but i can assure you the reference implementation
>> >> > is much much slower
>> >> 
>> >> You are referring to the H.264 reference implementation?
>> >> 
>> >> Jason mentioned two new H.264 decoders on IRC that are even faster than
>> >> CoreAVC...
>> >
>> >Why is this information not posted on the mailing list ?
>> 
>> i'll paste some relevent irc chat:
>
>thank you!
>while not as usefull as i thought, it is usefull.

here is some more, probably more useful.

[16:23] <astrange> http://github.com/astrange/ffmpeg/commits/h264
[16:23] <astrange> i kept not testing those because i always have vmware open, so it adds too much benchmark noise
[16:23] <astrange> maybe i should get a shell somewhere else

[16:28] <astrange> http://github.com/astrange/ffmpeg/commit/4964d8dede05662da59becaacbb2f3f0c5462cdd oh, i submitted this one with a slight speedup but didn't get a practical reply
[16:28] <astrange> though it might be cpu dependent
[16:29] <Dark_Shikari> astrange: you should really just be able to commit that imo...
[16:29] <Dark_Shikari> doesn't that free up a register too?
[16:30] <astrange> to improve cabac c code: write branchless and branchess bypass_sign, move cabac state array into cabaccontext, pass an index to it instead of a char * (better aliasing), use AV_RB16 in refill



More information about the ffmpeg-cvslog mailing list