MPEG4 AVC in FLV - Quality / Decoding speed Ratio

[Lamb]

Hi all,

I have been reading these forums for a while, and first of all I have to thank you for all those interesting information I have learnt here! I have to launch a web video hosting platform in the following months, and I would really need your help and advices.

The video sources will be amateur videos. Public aimed is very large, with all kind of computers. My problem is I don’t have a precise idea of CPU required to decode the kind of videos I plan to put online. Videos will be played using Flash. It is probably the worst AVC decoder, so I am looking for the best "quality / decoding speed" ratio, in order to be sure that most users will be able to play these videos.

I’ll keep bitrate low - around 350Kbit/sec - because it might be easier to decode, and because these videos will be streamed (php streaming or RED5, don’t know yet which one is the best option?). I will also scale the videos to a maximum resolution of 512 x 384 (Maybe I should lower it to 448 x 336 because of the low bitrate?) with 30FPS max (guess it will be 25, most of the time). Finally, I am using mencoder with x264 (don’t know if ffmpeg is better?).

1st pass:
/usr/bin/mencoder (…) -ovc x264 -x264encopts bitrate=350:subq=3:frameref=1:me=hex:partitions=all:8x8dct:bframes=3:b_adapt:b_pyramid:weight_b:brdo:bime:threads=auto:analyse=all:pass=1 (…)

2nd pass - Only changes here are “subq=6”, “frameref=5” and “me=umh” in order to optimize encoding speed on my server (this shouldn’t reduce quality at all).
/usr/bin/mencoder (…) -ovc x264 -x264encopts bitrate=350:subq=6:frameref=5:me=umh:partitions=all:8x8dct:bframes=3:b_adapt:b_pyramid:weight_b:brdo:bime:threads=auto:analyse=all:pass=2 (…)

Does the “quality / decoding speed” ratio sounds good to you? Do you think that the largest number of PC/Mac/Linux users will be able to playback that kind of videos? I don’t know if disabling CABAC and using partitions=i4x4,i8x8,p8x8,b8x8 will be necessary?

Thank you in advance for your answers!

[Dark Shikari]

The only things you can do to affect decoding speed significantly are:

1. Lower bitrate.
2. Lower framerate or resolution.
3. Disable CABAC or deblocking.

Personally though, I think 3) should be avoided; deblocking is absolutely critical at low bitrates, and CABAC gives quite a benefit bandwidth-wise.

Honestly though, I find that at "normal" bitrates and SD resolutions, decoding speed isn't a big issue. Flash is not that slow. This example H.264 video (http://mirror05.x264.nl/Dark/Flash/index_lowbitrate.html), for example, takes up about 25% CPU on my 2Ghz Core 2 Duo, and its 640x480 @ 60fps and 1.7 megabits. Most videos will be far less intensive than that.

[Lamb]

Thank you Dark Shikari.

According to your answer, I guess the parameters I am using should be ok in order to have a good quality, keeping a low CPU usage?

Do you think I could even improve quality a little bit (bitrate + resolution + maybe subq & frameref)?

Last (but not least), I know that “qcomp” parameter can help me for streaming. I need to have an (almost) constant bitrate. Default value for qcomp is 0.6 and I was thinking to lower it, but I am afraid of quality loss in expensive scenes. What would you recommand?

[Dark Shikari]

Thank you Dark Shikari.

According to your answer, I guess the parameters I am using should be ok in order to have a good quality, keeping a low CPU usage?They look fine to me.

Do you think I could even improve quality a little bit (bitrate + resolution + maybe subq & frameref)?I don't see why not. The subq+frameref won't affect decoding speed, though more refs won't help much unless its CGI/game footage/anime.
Last (but not least), I know that “qcomp” parameter can help me for streaming. I need to have an (almost) constant bitrate. Default value for qcomp is 0.6 and I was thinking to lower it, but I am afraid of quality loss in expensive scenes. What would you recommand?You're probably not streaming; you're doing progressive download (like my linked video above). In progressive download, you really don't care about bitrate variability because the player buffers it anyways. So I'd just leave all that stuff on default and not try to go for a constant bitrate.

[Lamb]

Thanks again.

But I don’t plan to serve my video files using progressive download. It will be streaming (using Red5 Streaming server or lighttpd / mp4streaming plugin + hinted mp4). That’s why I was asking for the qcomp option.

[Dark Shikari]

Thanks again.

But I don’t plan to serve my video files using progressive download. It will be streaming (using Red5 Streaming server or lighttpd / mp4streaming plugin + hinted mp4). That’s why I was asking for the qcomp option.Ah, in that case:

--aq-mode 1 --vbv-maxrate [bitrate] --bitrate [bitrate] --vbv-bufsize [buffersize]

If you can, bufsize should be at least twice bitrate or more simply because higher bufsize helps CBR encoding a lot by allowing more local bitrate variation.

[Lamb]

Ok, nice. My two parameters lines are now (in bold, differences between pass 1 and pass2):

- Pass 1:
aq-mode=1:bitrate=350:vbv-maxrate=350:vbv-bufsize=1024:subq=3:frameref=1:me=umh:trellis=0:
partitions=all:8x8dct:bframes=3:b_adapt:b_pyramid:weight_b:brdo:bime:threads=auto:analyse=all:pass=1

- Pass 2:
aq-mode=1:bitrate=350:vbv-maxrate=350:vbv-bufsize=1024:subq=6:frameref=5:me=umh:trellis=1:
partitions=all:8x8dct:bframes=3:b_adapt:b_pyramid:weight_b:brdo:bime:threads=auto:analyse=all:pass=2

I was also thinking to use trellis=2 and subq=7 if it doesn't make any difference on decoding side.

[Dark Shikari]

Ok, nice. My two parameters lines are now (in bold, differences between pass 1 and pass2):

- Pass 1:
aq-mode=1:bitrate=350:vbv-maxrate=350:vbv-bufsize=1024:subq=3:frameref=1:me=umh:trellis=0:
partitions=all:8x8dct:bframes=3:b_adapt:b_pyramid:weight_b:brdo:bime:threads=auto:analyse=all:pass=1

- Pass 2:
aq-mode=1:bitrate=350:vbv-maxrate=350:vbv-bufsize=1024:subq=6:frameref=5:me=umh:trellis=1:
partitions=all:8x8dct:bframes=3:b_adapt:b_pyramid:weight_b:brdo:bime:threads=auto:analyse=all:pass=2

I was also thinking to use trellis=2 and subq=7 if it doesn't make any difference on decoding side.Some notes:
1. UMH can be dropped to DIA on firstpass.
2. Analyse and partitions mean the same thing, so don't duplicate it. It can be dropped to "none" on the first pass.
3. B-rdo does nothing with subq < 6.
4. Trellis=2 and subq 7 will not affect decoding speed.
5. AQ-mode=1 is probably not necessary with twopass even in the case of CBR if you have the latest x264 (because 2pass VBV is now fully supported as of very very recently). If you don't have the latest x264 (r871), get it. It still might be worth experimenting though, as almost all the CBR I work with is 1pass, where aq-mode 1 is a must.

[Lamb]

Thanks again for your help !

I'll show you some examples as soon as the streaming side (Red5 or lighttpd) will be ready, if you're interested. :)

[Lamb]

I have been playing with the vbv-bufsize options on a couple of videos (bitrate is 320). With a buffer size < 2 x bitrate, I could always notice a difference with a “free” buffer size. Starting from 2 x bitrate, differences are harder to see (I can only see them on F2B and fast motion scenes).

Concerning the adaptive quantization option, I couldn’t really see a difference, but I guess it’s because of the low bitrate I’m using. Note that I'm still using the same parameters. I just added a keyint_min FPS (25), to improve seeking precision.

There is just something I wanted to be sure about: Maximum bitrate < (bitrate + buffersize), right? Moreover, would you now the Maximum bitrate calculation rule applied when no buffer size is specified ?