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

[Guillaume POIRIER]

Hi,

First of all, I'd like to repeat that I'm not satisfied with that
commit. There's a lot of room of improvement for the points that are
good, and maybe points that should be removed.

On 8/21/05, Jeff Clagg <snacky at ikaruga.co.uk> wrote:
> I was going to send some wording suggestions about the last x264 guide
> commit. But I have too many objections to bring up first.

fine with me.


> 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.

I agree that this should probably not be there. If that paragraph was
move somewhere else, and we were giving just a link to it instead
would be an improvement.


> 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.

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).

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 think that providing such a [slightly inaccurate] figure is better
than being un-understandable by Joe.


> > 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,...

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).


> > 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?

more ppl understand the idea of compression ration rather than PSNR
variation. 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.

To put it into a nutshell, the idea is more to provide informations
that Joe User can understand rather than force him to understand how a
logarithm scale works when he'd much rather spend some time on smth
else.


> > * 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?

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.

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?

Best regards,

Guillaume

-- 
Live fast, die old, and make very sure everyone knows you were there.
 -- Alan Cox