[MEncoder-users] Tuning hqdn3d

Nicolas George nicolas.george at normalesup.org
Tue May 12 12:43:48 CEST 2009


Le primidi 21 floréal, an CCXVII, Phil Ehrens a écrit :
> 2-pass ALWAYS produces better quality.

It may be true for a particular implementation, maybe even the current
implementations, but that is by no way an absolute truth.

What do you prefer: the first half of the movie almost perfect and the
second half very poor, the first half very poor and the second half almost
perfect, or the whole movie in medium quality?

I think almost anyone will choose the latter.

My point is that, for a given total size, the best possible encode will
achieve a constant subjective quality: if the user notices a part with a
lower quality than the rest, then it would have been better to save a few
bits from the rest to enhance the quality of that part.

Of course, this subjective quality is completely impossible to quantify, let
alone compute. It depends on countless parameters, for example the native
language of the viewer (if he's reading subtitles, he takes less notice to
the image).

But codecs and rate control mechanisms need something. Therefore, we have
functions that try to evaluate that subjective quality. Some are better than
others, of course.

If rate control algorithm A uses a better evaluation function than rate
control algorithm B, then it will gives better results. But that does not
mean that it is better: if we used the evaluation function of A in algorithm
B, maybe we would get even better results.

Constant quality encoding adjusts the encoding parameters to keep a
pre-selected constant value for the evaluation function.

Average bitrate encoding adjust the encoding parameters to keep the quality
(as evaluated by the evaluation function) as constant as possible while
aiming for a target average bitrate. Multi-pass encoding does that several
times, using each time the information from the previous pass to enhance
both the stability of the quality and the accuracy of the bitrate.

Now, let us assume that we have a good evaluation function, a perfect
constant-quality rate control algorithm, and a perfect average-bitrate rate
control algorithm, both using the same evaluation function.

Now, let us do a constant quality encode, and then set our average-bitrate
algorithm to mimic the resulting file size. Then the quality of the second
file should be the same as the quality of the first.

Conversely, if we do first an average bitrate encode, and then a constant
quality encode aiming for the same quality, then the resulting files should
have the same size.

That is true if we assume that the algorithms are perfect. In practice, they
are never. But I believe (someone correct me if I am wrong) that constant
quality is easier than average bitrate, and the algorithms will more
accurately achieve their goals.

Now, note that this discussion is about constant quality versus target
average bitrate, not about single pass versus multiple pass. There are cases
where multiple pass is beneficial even for constant quality.

For example, for scene detection change. Imagine we have set a max I-frames
interval of 10s, and that we have somewhere scene changes scores that look
like that: 1000 1 1 1 1 1 2 1 1 1 1 1 1000. The best solution would be to
cut at the 2, but that relies on the information that a 1000 is coming soon.
A single pass algorithm can not do it. A multi-pass algorithm could do it
optimally, using the TeX line-splitting algorithm.

Unfortunately, as far as I know, current codecs do not implement any global
optimization. Again, if I am mistaken, a correction is welcome.

As for x264:

Is the evaluation function for crf significantly worst than the one for the
multi-pass rate control system? And if it is, why do they not replace it?

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mencoder-users/attachments/20090512/0142b1bf/attachment.pgp>


More information about the MEncoder-users mailing list