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

[Jeff Clagg]

I was going to send some wording suggestions about the last x264 guide
commit. But I have too many objections to bring up first.

In a nutshell, my problem is that I went out of my way to avoid getting
caught up in digressions, complications, and asides. Simplicity was a
key goal. Another goal was to not simply duplicate info that is quite
adequately provided elsewhere (e.g., the man page has better technical
explanations of what the options do). If users want to read overly
convoluted stuff about H.264, they're free to browse the ITU draft,
particularly the parts dealing with interlacing.

Anyway:

> The following settings are examples of different encoding options
> combinations that affect the speed VS quality tradeoff given the same
> target bitrate. If you are aiming at perfect quality without too much
> thinking and no size limitation, a low constant quantizer encode (like
> with qp_constant=18) with no B-frames (bframes=0) will probably look
> very good, but will needlessly spend lots of bits to encode details that
> could be coded more wisely using some advanced settings.

1. Why is this an appropriate place to bring up constant qp encoding?
And how does the number of bframes relate to this?

I don't object to adding a set of tips about constant qp encoding. Indeed
I have often thought it would be nice to provide a rough sketch of what
kind of quality levels are achieved by what qp ranges. Few people would
guess that qp=18 is actually quite high quality, for instance. It is
also useful to have good working knowledge of the quantizer scale in
order to pick a suitable qp_min and qp_max. But this should be treated
BEFORE the examples section, it doesn't necessarily have anything to do
with bframes, and ideally it should be introduced in such a way that the
user can quickly and easily decide whether or not this is an encoding
style that he should try out.

Most importantly, it is probably not helpful in this guide to provide
benchmarks at constant quant. This opens several cans of worms. First,
the guide already claims that all PSNR benchmarks are 2-pass, fixed
bitrate. Secondly, the reason for doing this in the first place was that
it's much more straightforward - for example, some options lower both
PSNR and bitrate. The sure way to make an easy, valid comparison is to
hold bitrate constant. Finally, um, ip_factor and pb_factor.

I'm not saying constant qp encodes are useless for benchmarking. Indeed
anyone who benchmarks against JM should use constant qp. And it's a
good way to eliminate the influence of ratecontrol when making codec
comparisons. But none of these concerns belong in this guide.

> All the encoding settings were tested on a 720x448 @30000/1001 fps
> video sample, the target bitrate was 900kbps, and the machine was an
> AMD-64 3400+ at 2400 Mhz in 64 bits mode.

I deliberately glossed over any considerations of absolute benchmarks
because I think this, too, opens up too many cans of worms. All the
benchmarks prior to this one have been *relative* ("option x has a y%
speed penalty") for brevity's sake,...

> Each encoding setting is followed by the encoding speed (in frames per
> seconds), the compression efficiency loss (in percent of bitrate)
> compared to the "very high quality" setting, and the PSNR loss (in dB).

... I don't get it - above you said the target bitrate was 900kbps, so
what's the deal with these bitrate variations?

> * Very high quality:
>  subq=6:4x4mv:8x8dct:me=3:frameref=5:bframes=3:b_pyramid:weight_b 
>  6fps, 0%, 0dB.                                                  
> *  High quality:
>  subq=5:4x4mv:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b:psnr
>  13fps, -13%, -0.89dB.
> * Fast: subq=4:bframes=2:b_pyramid:weight_b:psnr 17fps, -20%,
>  -1.48dB.

Again, I don't get it - are these constant bitrate or not?

Every other speed benchmark on the page is relative, but these are all
absolute, in fps - why is that not a bad idea?