[FFmpeg-devel] [RFC] H.264/SQV3 separation: h264data.h

compn tempn
Tue Dec 16 02:49:37 CET 2008

On Tue, 16 Dec 2008 02:26:07 +0100, Michael Niedermayer wrote:
>On Tue, Dec 16, 2008 at 01:34:00AM +0100, Diego Biurrun wrote:
>> On Mon, Dec 15, 2008 at 01:33:49AM +0100, Michael Niedermayer wrote:
>> > On Sun, Dec 14, 2008 at 03:58:26PM -0800, Jason Garrett-Glaser wrote:
>> > also ive developed and optimized other codecs like the mpeg4 variants based
>> > on this concept and they are pretty much the fastest around. Had i applied
>> > random changes that made the code by 0.5% slower they would not be as
>> > fast.
>> Well, our H.264 decoder is not the fastest around and it still has areas
>> where it can be improved vastly.  So skipping refactoring for 0.3% speed
>> in one sample - don't forget that the other one improved - is premature
>> optimization.
>> But most importantly I think this obsession with speed at all costs is
>> hurting people's motivation and losing us much more than 0.3%
>> performance.  I know that I already spent far too much time on this
>> split without real progress and my motivation is going in one direction
>> only: down.
>no problem, ill spend the 30min to find out why its slower and see if it
>can be avoided.
>if we can get 0.5% speed by 30mins our decoder would be 24% faster per day
>premature or not ...

this is the reason that ffmpeg is the fastest decoder for a lot of
formats. the developers take great care to benchmark each change and
make sure they didnt lose any speed.

diego : you can speed up mplayer's h264 decoding in another way by
getting the coreavc-for-linux project merged.


More information about the ffmpeg-devel mailing list