[FFmpeg-devel] [RFC] H.264/SQV3 separation: h264data.h
Tue Dec 16 09:43:35 CET 2008
On Tue, Dec 16, 2008 at 02:36:53AM +0100, Michael Niedermayer wrote:
> On Tue, Dec 16, 2008 at 02:26:07AM +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:
> > > > > > no, the apparent slowdown of cathedral-beta2-400extra-crop-avc.mp4 is not ok
> > > > 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 ...
> i just realized you didnt post the patch, please do i cant look into it
> without having it :)
> also a link to the slower becomig file would be usefull
I did post a link to the patch. I did not attach it because it is 118kB:
Here is the sample that "slows down":
This one gets faster:
Probably it would be interesting to test some other samples...
More information about the ffmpeg-devel