[MPlayer-dev-eng] Re: Re: PATCH [0/12] CoreAVCDecoder support

[Rich Felker]

On Sat, Feb 17, 2007 at 10:56:01PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Sat, Feb 17, 2007 at 05:52:03PM +0100, elupus wrote:
> > Xbox 1 CPU
> > vendor_id : GenuineIntel
> > cpu family : 6
> > model  : 8
> > stepping : 10
> > flags  : fpu vme de pse tsc msr pae mce cx8 apic sep pge mca cmov pat pse36 
> > mmx fxsr sse
> > cpu MHz  : 733.332
> > model name : Celeron (Coppermine)
> > 
> > Harrry Potter Goblet of Fire quicktime trailer 
> > (harry_potter_goblet-tlr2_h720p.mov) 1280x544. No idea what codec options 
> > are in use thou.
> > 
> > CoreAVC
> > BENCHMARKs: VC: 130.384s VO:  16.412s A:   0.000s Sys:   1.969s =  148.765s
> > BENCHMARK%: VC: 87.6440% VO: 11.0323% A:  0.0000% Sys:  1.3237% = 100.0000%
> > 
> > FFMpeg
> > BENCHMARKs: VC: 169.442s VO:  15.894s A:   0.000s Sys:   1.914s =  187.250s
> > BENCHMARK%: VC: 90.4896% VO:  8.4880% A:  0.0000% Sys:  1.0224% = 100.0000%
> > 
> > About a 20% speed gain by using coreavc in this case, quite noticable on 
> > our limited hardware. Even skipping inloop filter for ffh264 doesn't get it 
> > up anywhere near the speed of coreavc. I wonder what industry secret they 
> > are using. 
> 
> well i guess that the choice of compiler does have some effect on the speed
> gcc is not a particulary good choice ... and theres alot more c code in h264
> decoding then in mpeg4 asp, rewriting it all in asm by hand does of course
> work but it doesnt seem like the right solution

imo relying on the compiler to optimize the performance-critical parts
of your code isn't the right solution. do we really want to tell
people "go use proprietary software if you want this to be fast"? imo
that's a very bad message to give. aside from that there's also the
issue that having performance-critical code depend on the compiler
discourages anyone from trying to replace gcc since it will take a
while to get comparable optimization..

my view is that any performance-critical code should be considered for
asm optimization. however, take that for what it's worth since i'm not
the one volunteering to write the asm.. :( perhaps you could enlighten
us on the nature of the c code that's a bottleneck..?

rereading your message, i get the idea that maybe you're just saying
the difference between coreavc and lavc decoder could be explained
away by differences in the compiler, and not that people "should" be
using intel cc. if so, sorry for getting ot.

rich