[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