[MPlayer-DOCS] CVS: main/DOCS/xml/en encoding-guide.xml, 1.10, 1.11

[Jeff Clagg]

On Sun, Aug 21, 2005 at 11:00:38AM +0200, Guillaume POIRIER wrote:

> My idea was more to provide Joe User with a double set of figures: the
> relative compression efficiency (easily understandable for someone who
> has been in school) and the relative PSNR change (harder to
> understand, you need to have studied a little bit more in school).

PSNR *IS* part of the measure of compression efficiency. The issue we're
arguing stems from the fact that the other part of the measure of
compression efficiency is bitrate. I decided quite early on that the
best way to explain things concisely was to hold bitrate constant for
each discussion.

It's fair to say PSNR could be explained better. So far, the guide only
hints that +-1dB is "a very big difference," "0.2-0.5dB [...] is usually
enough to be visible". Maybe a bit more could be said about this. I
think it would be helpful to say something like, "a 1dB change in PSNR
usually corresponds to an x% change in bitrate."

Sure, the quality metric is unfamiliar to many (most?) users, but you
don't simplify the explanation by bringing in more confounding factors,
even if the confounding factors happen to involve topics that are more
familiar.

> Of course that "compression efficiency" is inaccurate since at
> constant quant, the final PSNR is never the same (but do stay close
> the one from the others) when the final bitrate varies a lot.

I'm not sure what you're getting at here, but I suspect the concern is
completely answered if "compression efficiency" is conceived correctly,
i.e., as a function of both bitrate and PSNR. This is basically the
rate-distortion approach (only, there, we may speak about the amount of
error (distortion) instead of SNR).

> I think that providing such a [slightly inaccurate] figure is better
> than being un-understandable by Joe.

For the record I never objected about any inaccurate figures. I don't
even think "inaccurate figure" is a meaningful concept in this
discussion since the performance of any kind of compression, lossy or
lossless, depends on the characteristics of the source.

> That's also the reason why I wanted to provide relative figures as
> much as possible. The only figure that I think ppl can't live without
> is: fps, just because once they have picked the codec they may want to
> choose a encoding setting depending on its speed (which only depends
> on the nb of px and on the encoding options).

OK, I guess I withdraw my objection to absolute speed figures, but they
probably belong only in the examples section. Even here, I still think
relative benchmarks are best. Of course, absolute speed figures are VERY
helpful when discussing DEcoding requirements.

> I benchmarked all the encoding settings at low constant
> quant to get an idea given a certain quality, how well a certain
> option "saves bits" (considering that at low constant quant, the PSNR
> should remain more or less constant, but not the bitrate), and with 2
> passes to get the PSNR for a given bitrate.

PSNR does not remain constant! Look at the frame-level PSNR. Even
leaving aside e.g. completely black frames, I've seen them differ by
10dB in one encode. And asking how well a certain option "saves bits"
completely in isolation of the PSNR impact is meaningless.  Plus,
you never explained that this was the testing method, so the numbers
given were undecipherable. I wasn't able to figure out what they all
were. Finally, your encode probably wasn't true constant qp to begin
with, because you didn't set ip_factor and pb_factor to 1. (not that I
think this last objection changes anything, really)

There's very little benefit to discussing the effects of the different
options at constant quant. Mostly all it does is complicate matters.

Constant qp encoding is a legitimate topic that deserves its own
treatment, maybe in the "Options pertaining to miscellaneous preferences"
section. The discussion should explain why you might want to use constant
qp, and it should give some general suggestions about what quantizers
yield what quality ranges. As a bonus, this would also be a starting
point for discussing qp_min and qp_max.

> That's because I figured that ppl might be interested in at least
> _one_ figure so that they know what speed to expect (and don't panic
> if it's awfully slow on their machine). That kind of figure is easy to
> measure, and just depends on the set of options and the number of
> pixels processed.

It also depends on bitrate.

> I agree that giving the speed penalty/gain would be better, just
> because it'll make the figures more independent from the source
> resolution.
> 
> Do you see how I could do both?

Not sure I understand the question.