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

Davy De Winter davy.dewinter at intec.ugent.be
Fri Jan 20 12:27:08 CET 2006


Hi all,

as stated earlier, we've implemented a realtime-desktop streamer using 
the x264-codec. We wanted to test the influence of the different 
parameters for different scenario's and I'd like to check the results in 
this mailing-list.
We've only changed parameters which still give good quality (subjective 
measurement), except for changing the CBR parameter. //

- We've streamed the following scenario's:
    - a normal video (a football-match): high-motion
    - a 3D-game (ut2004): medium-motion
    - a sequence of webpages: low-motion
    - a sequence of movements in word-processor and excel-sheet: very 
low motion
while varying some of the (according to us) most important parameters 
that can influence the bandwidth and/or encoding/decoding-delay, without 
a noticable difference in quality.
(res: 640x480, 25 fps - standard settings of the codec except the tested 
parameter, we "feeded" always the same frames in YUV420 format)

A summerization of our results:
- GOP-size (varying from gop-size to 2 to 160 in steps of 10):
    -    Bandwidth: we almost didn't notice any influence on the 
bandwidth with the high-motion and medium-motion sequence, but on the 
low-motion sequence, the number of I-frames had a very big influence up 
until a GOP-size of 80. In the low-motion sequence, every time the 
GOP-size doubles, the amount of bandwidth used halved (until a certain 
"turnover-point"). Is this a logical result, that we almost didn't 
notice any bandwidth-influence with high-motion sequences, but a very 
big difference with low-motion sequence? (according to our opinion, it is)
    - Delay: only a minor influence, a somewhat higher delay when the 
number of I-frames is bigger.
- merange (varying from 2 to 256 in steps of 2) with diamond search:
    - Bandwidth: somewhat surprising, but we didn't see any influence in 
any of the scenarios on the bandwidth or encoding/decoding delay. Is 
this possible? Or do we not have the right scenario?
    - Delay: almost no influence
- merange (varying from 2 to 256 in steps of 2) with exhaustive search:
    - Bandwidth: the same result as merange with diamond search, almost 
any influence... Is this possible? Is it actually possible that in most 
of the scenario's, the best motion vector is found within a range of 4.
    - Delay: almost no influence (however, larger due to exhaustive search)
- cabac: a nice reduction on bandwidth (unfortunatly also a "nice 
influence on delay :-))
- subpelrefine (varying from 1 to 6): in most scenario's only an 
influence from value 5 - 6
- 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)
- 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).

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!

Best regards,
Davy.

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



More information about the x264-devel mailing list