[x264-devel] RDO and refframes test results

[Tuukka Toivonen]

I made some brief tests, comparing --subme 5 and 6
and number of reference frames. Below are some results.

I'm preparing uber-tests that will try all x264
parameters and also compare them to lavc's mpeg-4.
But as I can't test full product-space (all combinations
of different parameters), I will mostly test each parameter
changes independently. Let me know if there are some non-obvious
parameters that might affect each other and thus should be tested
together.

One reference frame:
http://www.ee.oulu.fi/%7Etuukkat/tmp/tst/ref1-sum-352-288-br.eps
std    = rev 239
stdnew = rev 265
all-5  = --subme 5
all-6  = --subme 6 (RDO)
Good thing: with --subme 5 the newer x264 gives about 0.3%
smaller bitrate. Not really significant improvement, but at
least it's not worse.
Bad thing: RDO with --subme 6 is not really better than
--subme 5. Well, maybe 0.1%, but it varies, some sequences
are quite much _worse_ with RDO than without it. At high bitrates,
the difference is even less.

Two reference frames:
http://www.ee.oulu.fi/%7Etuukkat/tmp/tst/ref2-sum-352-288-br.eps
Same results, really. RDO is not worth using, especially as:
http://www.ee.oulu.fi/%7Etuukkat/tmp/tst/ref2-coastguard-352-288-qt.eps
this shows that it is about twice slower than --subme 5.

Some specific test sequences:
http://www.ee.oulu.fi/%7Etuukkat/tmp/tst/ref2-paris-352-288-br.eps
http://www.ee.oulu.fi/%7Etuukkat/tmp/tst/ref2-paris-352-288-rd.eps
This gives 2% _higher_ bit rate with RDO than without it!

http://www.ee.oulu.fi/%7Etuukkat/tmp/tst/ref2-tourists_in_san_fransisco-352-288-br.eps
http://www.ee.oulu.fi/%7Etuukkat/tmp/tst/ref2-tourists_in_san_fransisco-352-288-rd.eps
Well, at least this is significantly better with RDO, giving
1.5-5% lower bit rate with RDO (these were about the two extreme cases).

Other comments: RDO seems to work best at low bit rates. Also,
the newer x264 is slightly faster than the old one (subme 5).

Multiple reference frames: average bit rate reduction:
http://www.ee.oulu.fi/%7Etuukkat/tmp/tst/refx-sum-352-288-br.eps
And time increase for one sequence:
http://www.ee.oulu.fi/%7Etuukkat/tmp/tst/refx-munchener_hall-352-288-qt.eps
Good news is that one can't choose a bad number of reference frames:
larger is always better, and little bit slower. Also, subme 6 didn't
change significantly the relative advantage between different number
of reference frames. Still, I have a feeling that x264 can't exploit
multiple reference frames quite as well as JM 9.6 (based on my earlier
tests), in cases where they would give an large advantage.

I was using these 13 CIF sequences, each 250 frames:
bridge_close coastguard flower highway news foreman mobile_and_calendar 
munchener_hall paris stefan tempete tourists_in_san_fransisco waterfall
The computer is Athlon 2 GHz, gcc version 3.3.5 (Debian 1:3.3.5-13).

Command line:
x264 -v --frames 250 --fps 30 -i 9999 -b 0 -r 1 -q 26 -A all --subme 5 -o 
test.264 /video/std-video/bridge_close-352x288.yuv 352x288

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