[x264-devel] Some preliminary test results

[Tuukka Toivonen]

On Mon, 20 Jun 2005, Tuukka Toivonen wrote:

> I'm preparing uber-tests that will try all x264
> parameters and also compare them to lavc's mpeg-4.

Well, test encodings are now mostly done. All 23192
of them, each 245 frames at CIF size, or 64.4 hours
of encoded video in total, using 13 different test sequences and 10 
different qp_constant values for each tested parameter combination, giving 
in total around 178 different tested combinations.

End result: best encoding is obtained (for these videos) with

/home/tuukkat/bin/mencoder -quiet -endpos 10
-rawvideo on:format=i420:fps=25:w=352:h=288 -ovc x264
-x264encopts log=3:psnr:qp_constant=20:frameref=15:nob_adapt:
b_bias=0:bframes=3:b_pyramid:ip_factor=1.4:pb_factor=1.6:
direct_pred=1:noweight_b:i4x4:i8x8:b8x8mv:8x8mv:4x4mv:8x8dct:
me=3:me_range=24:subq=6:chroma_me:chroma_qp_offset=0 -o test.10274.avi 
/video/std-video/bridge_close-352x288.yuv

> Bad thing: RDO with --subme 6 is not really better than
> --subme 5. Well, maybe 0.1%, but it varies, some sequences

Well, RDO seems after all to help quite much after enabling
many of the other options too (B-frames most likely).

I'll prepare a web page with some of the results but that will take some 
time. Now I'll just point out some interesting things:
(and I'm still running some tests with larger and noisier
self-captured videos)

- What to do if the best options are too slow? Hard to say, because
   there are no obvious candidates for speeding up.
- Decreasing frameref->10 will increase bit rate by about 0.4% but will
   decrease only by 15% of encoding time.
- Decreasing me_range->16 will increase bit rate by about 0.1-0.2% but
   only decreases by 11% of encoding time.
- Using nochroma_me increases bit rate around 0.4-0.5% but decreases quite
   little encoding time.
- Using subq=5 will decrease encoding time pretty much to half,
   but it does increase bit rate (at the same quality) by 4.2-6%.
- Using me=2 will increase bit rate by about 2.1-4% and
   decrease encoding time by 36%.
- bframes=3 was optimal, which is quite large value. Adaptive
   number of bframes was never even nearly as good (I tried
   adaptive bframes with maximum of 3, 4, and 6 B-frames
   and with different biases, of course).
- pb_factor=1.6 is larger than the default 1.3.
- ip_factor=1.4 is probably inconclusive, as it matters only
   at intra frames and with short sequences there aren't many of them.
- direct_pred=1 was clearly better in PSNR than the recommended
   direct_pred=2 but as the docs say, the latter might have better
   visual quality (I didn't look that).
- (no)weight_b didn't really affect much either encoding speed or
   quality, so I'd prefer without it.
- b_pyramid definitely helps
- me=4 was very, very slow :) and not really even better than me=3
   Might be useful to get encoding times which are comparable to JM ;)
- I didn't try ratecontrol

> 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).

Worth to see also:
http://lists.mpegif.org/pipermail/mp4-tech/2005-June/005626.html
they mention about x264 that
"Developers declare "early development stage", but encode results are one 
of the best."

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