[x264-devel] Re: Bandwidth measurements - influence of different parameters

[Jeff Clagg]

On Fri, Jan 20, 2006 at 12:27:08PM +0100, Davy De Winter wrote:

> - b-frames (varying from 1 to 10): generally can be concluded that 
> b-frames give the most advantage up until 3 b-frames according to 
> bandwidth. Delay is now also correctly ((num_of_bframes+1)*frame_read_time)

This might not be doing exactly what you think it's doing since b-frames
are placed adaptively by default.

> - cbr (varying from 20% af the amount of actually required bandwidth to 
> 100% of the required bandwidth in steps of 10%): as expected, nice 
> results and almost no influence on bandwidth. One question here: is the 
> bandwidth reached by varying the quantisation parameter, because I did 
> not find any answer in previous posts how it is implemented (I'd like to 
> read something 'bout it).

Yes, the requested bitrate is achieved by varying the quantizer. All
encoders work this way.

> Are there also some other parameters according to the community which 
> are very interesting to test, because we expect the other parameters 
> only will have a minor influence (e.g. varying the macro-block size in 
> I-, P-and B-frames). One important note: we only wanted to vary 
> parameters which still give an acceptable (subjective!) quality. Of 
> course, with only 20% of the required bitrate, quality is not 
> acceptable, but in general, this is not our main concern, we focus here 
> on bandwidth and delay.
> 
> Any comments and/or advice very appreciated!

A general comment: I don't think you are familiar with general principles
of video encoding (not complaining or anything, just saying this is my
impression). I'm also not completely sure what you mean by bandwidth or
delay. Related to the bandwidth issue: useful test of encoding parameters
usually has to take account of both bitrate and distortion in order to
tell you anything meaningful. Simple example that should help make this
apparent: suppose option1 decreases bitrate (at fixed quantizer) by 5%,
and option2 also decreases bitrate by 5%. Option1 gives slightly
worse-looking output while option2 gives slightly better looking output.
See why you can't look at bitrate only? Most tests either use fixed
quantizers, and report BOTH rate and distortion (usually PSNR), or they
use 2-pass on all encodes at the same bitrates, and report only PSNR.

A few other comments, you might want to try the different ME algorithms
(dia, hex, umh, esa). Hex is the default and iirc isn't affected by
me_range. UMH is possibly a more useful compromise between speed and
quality, and it can be tuned with me_range. ESA is too slow for
practical use.

You might also consider trying different numbers of reference frames;
this can have a large effect. Also, try the different "levels" of
trellis. Also try different partition analysis flags, though I think
intra partition analysis flags usually have very little effect on speed.

keyint isn't really for improving quality; it's used to trade off
seekability against quality. E.g. using keyint=12 in a 24fps video makes
it possible to seek with 0.5 second precision, but it doesn't achieve
very efficient coding. So I don't think there's very much point in
testing different values of it. At larger values, the rate-distortion
effects of keyint are overwhelmed by the characteristics of the source
video (how often scene changes occur).

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html