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

[Diego Biurrun]

On Mon, Dec 15, 2008 at 08:49:37PM -0500, compn wrote:
> 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.
 
No, it's simply not true that each change is benchmarked.

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

I much prefer free software and a fast ffh264.

Diego