[Ffmpeg-devel] Differences between mencoder and ffmpegwhenencoding using x264

[Robert Swain]

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.global_quality and
> CODEC_FLAG_QSCALE (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 "mb_decision = FF_MB_DECISION_RD". This has no
> effect on x264. Doesn't x264 implement something similar to "mb_decision
> = FF_MB_DECISION_RD"? 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