[MPlayer-dev-eng] [PATCH]Add support for CoreAVC h264 codec

[Michael Niedermayer]

Hi

On Wed, Oct 04, 2006 at 08:00:15PM -0700, Alan Nisota wrote:
> On 10/4/06, Corey Hickey wrote:
> >Alan Nisota wrote:
> >> On 10/3/06, Michael Niedermayer wrote:
> >>> things to test
> >>> * low resolution where all reference frames+1 _easily_ fit in the L2 
> >cache
> >>> * CABAC / CAVLC
> >>> * high bitrate / low bitrate
> >>> * intra only
> >>> * B frames vs. no B frames
> >>> * loop filter / disabled loop filter
> >>>
> >>> and also check if the output of coreavc is binary identical to ffh264
> >>> if not that would explain why they are faster
> >>>
> >>> also try to compile (i386)/dsputil* with -O2 that will make lavc
> >>> faster depending on the gcc version
> I used the same input file for all runs (1280x720, 55secs, 3242 video 
> frames)
> I resized the stream to 320x180, 640x360, 960x540, and 1280x720

could you test 160x96 too?


[...]
> frame comparison was done using:
> mplayer -vc coreavc/ffh264 -vo md5sum -nosound
> every frame was different.  I guess the next step would be to do a

could you provide mplayer -v output of one coreavc -vo md5sum run and one
ffh264 -vo md5sum run?


> frame diff but let's do this one step at a time.  The one thing I can
> say is that the output from CoreAVC looks very good.

h264 requires bit identical output, so either ffh264 or coreavc or
our comparission method is flawed

also maybe you want to try -lavdopts fast it will cheat with decoding
b frames with a faster but not compliant MC function

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is