[MPlayer-users] mencoder: effective use of qp, crf params for x264?

[Guillaume POIRIER]

Hi,

On 1/30/07, matthew.garman at gmail.com <matthew.garman at gmail.com> wrote:

> On Tue, Jan 30, 2007 at 04:27:35PM +0100, Guillaume POIRIER wrote:
> > the bitrate that will end up being used by qp will depend on the
> > complexity of the scene (more or less equivalent to "how well it
> > compresses"), and the "amount of efforts" that the codec put towards
> > trying to make good use of the bits.
> > Likewise, if you give bitrate as a target, the average quant of the
> > frame/the movie will depend on how well the movie compresses with the
> > given encoding parameters
>
> Hmmm... that's causing me to re-think my scheme.
>
> Seems like crf might be more flexible for inputs that are greatly
> different.

Yes, it's somewhat closer to a "no brainer" option useful when you
can't/don't want to bother with bitrate computation. :-)


>  For example, I've been encoding TV episodes with
> bitrate=1400 (and other params similar to what I've posted
> previously).  But with *animation* (cartoons), I could drop that
> down to bitrate=900 and still have acceptable quality.
>
> Now I wonder if I had found some "optimal" crf value (optimal for
> *me* of course), that I could have saved myself some
> trial-and-error, i.e. using crf, mencoder would have known that it
> could use fewer bits with animation.
>
> Conversely, I'm concerned with hitting the "ceiling" when using
> bitrate=x: I'll get an encoding that's not to my liking if x aren't
> enough bits for some random movie with many extremely complex motion
> scenes.  Of course I could go with x+1, but now I'm wasting a bunch
> of bits for the majority of movies that aren't so complex.
> (Compared to a sufficiently low crf, which would use plenty of bits
> on the complex movie, but know to use fewer on everything else. (?))
>
> So is it fair to say that specifying bitrate=x is generally
> preferred when you have the time to fine tune x---for every
> individual job?  Otherwise, do some initial experimentation with
> crf, find your optimal value and run with it?
>
> Is there a way for mplayer to combine the best of both worlds?
> E.g., something along the lines of using crf on the first pass,
> having mencoder tell you what the optimal bitrate would be, then
> using that bitrate on pass=2?

Well, mencoder can't do that for you, but you can script mencoder to
do "exactly" that.

Here's what tuxrip script, listed on our "related projects":
http://tuxrip.free.fr/index_en.html do to pick well-fitted bitrate:
It does a fast encode of a certain percentage of the movie, at a low
constant quant, looks at the size of the resulting file, and scale the
size according to the percentage encoded, and the desired quality.

If you wanna re-implement this (BTW, this is called a compression
test), say you encode 5% of the movie, with fast options, with 20
chunks of video taken at evenly separated parts of the movie. You
encode at qp=18, which corresponds to a "perfect" encode (i.e. there
won't be any encoding artifacts due to too high quants), yet not
lossless encode.
Your sample ends up weighting 150MB, so 150*20=3000 the full encode
would be 3000MB.
You can bet that with two pass, better encoding options, longueur
encoded sequences, and the fact that quant 18 is probably overkill, so
it's safe to say that you can compute your bitrate between 40 and 60%
of the 3000MB found by the compression test.
So far, this technique proved very effective to compute a sensible
bitratre in my experience.

Guillaume