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

[Michael Niedermayer]

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
> > > 
> > > Why is this not ok, while disabling filter_mb_fast was OK?  I measure
> > > a 25% performance increase on a sample here by re-enabling
> > > filter_mb_fast.  Why is 0.5% here intolerable, but 25% there is just
> > > fine?
> > 
> > One has to weigh the advantage against the disadvantage
> > 
> > here, advanatge, of the change is largely cosmetic
> 
> You consider code maintainability cosmetic?

no, but i consider the svq3/h264 split largely cosmetic, these 2 are in
seperate files already.
I do want the split, but iam not convinced that we have to loose 0.5% to
have it.


> 
> > disadvantage is a 0.5% speed loss, after 10 such changes our decoder is 5%
> > slower.
> 
> The separation of the two decoders can only be done once and will only
> be done once.  There is absolutely no danger for this to become a
> slippery slope.

Each individual change can be done just once.


> 
> > And thouse claiming randomness, well, if its random a different gcc version
> > shouldnt show the speed loss and in that case it could be reconsidered, though
> > again if 4 out of 5 gcc versions show the speed loss it still doesnt look too
> > good nor random. But if 2 out of 4 are slower and 2 faster it would be ok.
> 
> Do you claim that H.264 decoding performance is not sensitive to random
> changes and even to changes unrelated to H.264?

no i did not claim that


> 
> > 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 ...


> 
> There have been tons of changes to h264.c that were not subjected to the
> speed inquisition, everything PAFF-related jumps to my mind for example.

benchmarking past changes is welcome, i surely think we should do that one
day and look into speedlosses.


> The H.264/SVQ3 split is being singled out for unfathomable reasons.
> Probably because I made the error of waking sleeping dogs by running
> benchmarks in the first place.
> 
> Below is a slightly edited IRC log from yesterday night.  It should
> speak volumes about developer motivation and places where *substantial*
> speed improvements can be achieved.

I know dark shikari is not porting anything and i know he blames random
things for why he is not doing anything.
I cant help but if he is not porting code then  this is
his decission and he really should not blame anyone but himself.

Just look at the mailing list, what is it that we have
A. many patches from dark shikari that i rejected?
or.
B. few patches from dark shikari that have comments and questions in
replies to which he never even bothered to reply?

Its not that he is disagreeing about some comment from me.

If there is some rule, or otherwise he dislikes, he has not said this
on the ML yet. I cant read his mind on what the problem is if there is
any. Also i do not think that he would be ok with others commiting
poor code randomly to x264 ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081216/03ca0d1b/attachment.pgp>