[Ffmpeg-devel] Differences between mencoder and ffmpegwhenencoding using x264 (original) (raw)

Robert Swain robert.swain
Tue Feb 21 04:45:05 CET 2006

Hello,

On Monday 20 February 2006 08:53, Luca Abeni wrote:

On Sun, 2006-02-19 at 17:33 +0000, Robert Swain wrote: [...]

> Yet again someone has noted that the x264 defaults in FFmpeg are lacking. > This is giving a bad impression of x264. :/ Do not worry... At least to me, it is pretty clear that the problem is not in the x264 library, but is in the glue code contained in libavcodec/x264.c. I apologize if I gave the impression that I was complaining about x264. But maybe the real problem (for me, at least) is that I am expecting something wrong from libavcodec/x264.c. In my opinion, such code should aim to "integrate" x264 with ffmpeg in a "nice" way (meaning that it should try to "translate" the libavcodec parameters I am used to into x264 parameters).

I see that Loren has already responded and it would appear that this e-mail passed me by somehow, but I will add my own comments. :)

Parameters were reused where possible/sensible in my/other's opinion. Maybe you're right about the translation. I came from an xvid/x264 background rather than an FFmpeg background (encoding-wise at least) and as such I tended to side with my heritage with regard to any decisions I made. ^-^ This is not a common trait for me.

> Just setting the output codec to x264 and setting a bit rate or other > mechanism is insufficient

I think this is the real problem. In my opinion (but remember: I do not know x264 internals at all, so I might be completely wrong) the same AVCodecContext settings that give decent results with MPEG4 should give equally decent results with H.264... So, I think this is the thing that should be improved.

I agree with Loren's comments.

> People expect the > defaults to yield good quality such that they can specify a bit rate to > evaluate the capability of a codec and it's just not the case.

Maybe I am being naive, but... Why? The same defaults that give decent quality with a codec should give decent quality with all the other codecs, no? At least, this is how it works for most of the ffmpeg codecs I tried.

As Loren pointed out, the very small GOP size and lack of b-frames. among other things, really do not help x264. It is my opinion that, to be fair to each codec, default parameters should be tuned for each codec. Unless this is done via internal variables that have been specifically tuned such that the same defaults yield a good output for all FFmpeg codecs, the same settings are unlikely to be close to optimal and even moreso for an outside codec.

Again, it seems that libavcodec/x264.c is doing things "his own way", and is not well integrated with the rest of libavcodec. AVCodecContext contains a lot of fields that are only used by x264, and x264.c does not use many fields of AVCodecContext.

As Loren said, if such parameters do not exist in FFmpeg, do you want x264 to just not be able to use them? It uses a more recent standard from MPEG and has different features to the others, as implemented in x264. The new parameters had to be added.

For example, look at AVCodecContext.cqp (I already wrote an email about it some time ago, but as far as I can see noone replied). It took some time to me to understand how to encode h264 video at a constant quality... Why isn't x264.c using AVCodecContext.globalquality and CODECFLAGQSCALE (with some eventual translation, if needed) like the other codecs?

I did this because qscale means nothing to me while I (and other x264 users to my knowledge) are much more familiar with 'qp's. 'qscale' was originally used but as most x264 users (due to use of the cli or mencoder) I changed it to cqp. I will take all the flak for this decision.

I should document its use, especially as the poor defaults require some RTFMing, and without an M to RTF, I can see that it would be difficult. :)

Another thing: with MPEG* and H263 (I think) I can get a good quality improvement by setting "mbdecision = FFMBDECISIONRD". This has no effect on x264. Doesn't x264 implement something similar to "mbdecision = FFMBDECISIONRD"? If it does, maybe x264.c could "translate" this setting in the equivalent x264 one?

As Loren said, x264 uses the subme option to control such techniques and as such I tried to avoid use of *cmp.

Thanks (and sorry if what I wrote does not make sense),

It made perfect sense. I apologise for missing your e-mail and hence giving a delayed response.

Rob

More information about the ffmpeg-devel mailing list