On Sat, Aug 20, 2005 at 10:44:12PM +0200, Guillaume POIRIER wrote:

Note: I have the same "layout" for the encoding settings examples of xvid and lavc, so please tell me what you think of it in addition of the usual nits. I'm personally not satisfied with the way I put them.

My personal opinion is that the layouts are quite sensible, but maybe I'm not very skillful at design and layout tasks. I do have a broader problem with the organization of the encoding docs, which is that many people expect to be able to find practical video encoding advice in the man page. More than once I've seen the completely understandable complaint that "I RTFM'd and I still have no clue which lavcopts are best for my situation." IMO the best way to remedy this problem is to add a couple of notes to the manpage stating that the manpage is intended to provide an exhaustive list of options, and practical encoding advice is available if you build the XML docs. Adding lots of encoding tips to the manpage shouldn't be considered as a solution, because that would make it even more huge and unwieldly than it already is, plus it'd undercut the purpose of the XML docs.

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