[FFmpeg-devel] [RFC] H.264/SQV3 separation: h264data.h
Tue Dec 16 02:36:53 CET 2008
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
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel