[x264-devel] Re: [Mp4-tech] CALL FOR MPEG4-AVC/H.264 CODECS (fwd)

[Loren Merritt]

On Mon, 29 Aug 2005, Tuukka Toivonen wrote:

> I thought it might be nice to forward this message here too.
>
> I believe these people are aware of x264, but might not know
> the best encoding options.
>
> According to my experiments, the best safe encoding options are
>
> --bframes 3
> --no-b-adapt
> --b-pyramid

Even with pyramid, there are high-motion cases where forcing B-frames is a 
big penalty. And in my experience those cases are more common and more 
severe than ones where b-adapt uses too few B-frames. (Also, too many 
B-frames in high motion increases the required motion estimation settings 
=> slower.)

> --ref 14
> --pbratio 1.5
> --analyse all
> --direct temporal
> --me 3

--me umh

> --merange 24
> --subme 6
> --8x8dct
>
> - "--direct spatial" would give higher performance in PSNR,
>  but I'm not sure if it is usable, so I wouldn't recommend
>  using it yet. There have been some fixes in x264, but
>  I wasn't able to verify if they fixed the problem as
>  I haven't been able to decode .264 into raw yuv with
>  recent Mencoder cvs versions :(

The bug was never detectable that way: you want to check x264's 
DEBUG_DUMP_FRAME vs JM. I did so when I applied the fix, and it 
seemed ok. (Well, DEBUG_DUMP_FRAME outputs in coded order, so I actually 
did "mplayer -vo md5sum fdec.yuv" and compared to JM without regard to 
order.)

> - Larger "--ref" might be slightly better but possibly with
>  lesser compatibility

14 is already overkill, though it's safe.

> - I don't have yet recommendations for "balanced" (ie. faster)
>  coding options.
> - I haven't mailed the people below (maybe some developer
>  would like to do it--it would be great to have an independent
>  comparison of x264 to other encoders)

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html