X264 Options for Fast Decode

[j7n]

Hi, I'm looking for the best X264 options that would ensure fast decoding while keeping transparent quality. Bitrate should be whatever is required. Encoding complexity does not matter. So far I've come up with this command line:

--keyint 120 --min-keyint 1 --bframes 2 --b-pyramid --no-cabac --no-deblock --ref 2 --crf 18 --pbratio 1.20 --scenecut 50 --direct "auto" -A "p8x8,b8x8,i4x4" --weightb --me "umh" --subme 6 --b-rdo --mixed-refs --no-fast-pskip --no-dct-decimate

I am not sure about the meaning of "-A" parameter and how weighted biprediction influences decompression speed.

My material originates from downscaled bluray and 50fps deinterlaced video.

[Dark Shikari]

--no-cabac and --nf are the only biggies, really. Bitrate is obviously very important too; lower is faster to decode.

--bframes may or may not have much effect; they may speed up decoding but might also increase the bitrate required to get the same quality, slowing decoding down.

[Lele-brz]

--bframes may or may not have much effect; they may speed up decoding but might also increase the bitrate required to get the same quality, slowing decoding down.

This is interesting, does it really mean that using bframes requires increasing the bitrate? I thought the opposite since bframes are smaller and could help redistributing the bitrate where needed.
Is also the resolution to take into consideration about decoding speed? I would say that a larger buffer at the same bitrate could take more CPU to decode.

[audyovydeo]

Hi, I'm looking for the best X264 options that would ensure fast decoding while keeping transparent quality. Bitrate should be whatever is required. Encoding complexity does not matter. So far I've come up with this command line:


Seems like you're looking for the real minimum, in which case you might as well put all options to their minima (me dia, -r 1, -A none, -m 1, etcetera).

Another approach is to target Baseline and/or Main profiles, which are conceived for near-ubiquitous playback.
I use the following :

set base=-r 1 --me hex -m 5 -t 0 -A i4x4,p4x4,p8x8 --direct auto --no-fast-pskip --no-cabac

set main=-r 1 -b 16 --me hex -m 5 -t 0 -A p8x8,p4x4,b8x8,i4x4 --direct auto --b-pyramid -w --bime --no-fast-pskip --no-cabac


cheers
audyovydeo

[nm]

Seems like you're looking for the real minimum, in which case you might as well put all options to their minima (me dia, -r 1, -A none, -m 1, etcetera).
He said that encoding complexity doesn't matter, so it would be better to (nearly) maximize all the options that don't have much of an effect on decoding speed.

[j7n]

Thank you for your replies. Encoding is done just once. If playback is required (i.e. not strictly archival), also low powered silent computers should be capable of doing it.

audyovydeo, why did you set these partitions: p8x8,p4x4,b8x8,i4x4?

[audyovydeo]

audyovydeo, why did you set these partitions: p8x8,p4x4,b8x8,i4x4?

Hi there. I based myself on information from the wiki :

http://en.wikipedia.org/wiki/X264

plus endless info-sieving on doom9.

cheers
audyovydeo

[akupenguin]

Another approach is to target Baseline and/or Main profiles, which are conceived for near-ubiquitous playback.
I use the following :
That would be counterproductive. 8x8dct isn't any slower to decode than 4x4dct, and anything that increases compression also lowers the cpu time spend in bitstream parsing.
p4x4 is slower to decode than p8x8.
Thus, partitions=i4x4,i8x8,p8x8,b8x8 (i.e. the default) is optimal for decode speed.

[SuNova]

--no-cabac and --nf are the only biggies, really. Bitrate is obviously very important too; lower is faster to decode.

--bframes may or may not have much effect; they may speed up decoding but might also increase the bitrate required to get the same quality, slowing decoding down.
Can you explain more? Whenever I raise b-frames from 0 to even 1, I suffer from playback lags in my mobile device (It's not an old one 4xcores). I was thinking using b-frames is really dangerous for decoding speed so I set it to 0.

[sneaker_ger]

bframes shouldn't affect decoding speed much. Mostly resolution, fps, bitrate, bitdepth and --no-cabac --no-deblock --no-weightb --weightp 0 (--tune fastdecode)
It could be a bug in your playback software or authoring software if bframes produce problems. Or your device is limited to the baseline profile (which I doubt if it's a quad-core).

[SuNova]

bframes shouldn't affect decoding speed much. Mostly resolution, fps, bitrate, bitdepth and --no-cabac --no-deblock --no-weightb --weightp 0 (--tune fastdecode)
It could be a bug in your playback software or authoring software if bframes produce problems. Or your device is limited to the baseline profile (which I doubt if it's a quad-core).

Thank you good explanation. I was thinking it is related to hardware but maybe I should contact Telegram team as it is decoder related because the playback is normal about video files but not GIFs (simply h.264 videos without audio channels). Much appreciated.

[SuNova]

Excuse me, I'm sorry for being dummy. I use this settings in my encoding (I don't care about encoding speed as I said):
--preset placebo --crf 21.5 --qpstep 30 --rc-lookahead 80 --aq-mode 2 --psy-rd 1:0.15 --keyint infinite --bframes 1 --partitions p8x8,b8x8,i8x8,i4x4 --merange 36 --ref 5 --threads 1
Do you have any advice for me in order to improve decoding speed with almost no quality loss? Because I think I'm doing it in a really aggressive way.
In order to explain, I was using p4x4 with -bframes 0 because I was thinking decoding bframes requires more processing power, but I read somewhere else in doom9 that they may even improve decoding speed with lowering bitrate in crf mode. Also p4x4 can be more harmful in decoding speed with very little gain in quality so turned it off and set -bframes to 1. Now for example if I set -bframes 2 or even -bframes 16 with -b-adapt 2 what is the effect on decoding speed? Better or worse?
Sorry guys I'm really confused. Just give me tips because I'm encoding for mobile processors.

[kuchikirukia]

Never do infinite keint. It's just annoying when you run into a 30 or 45 second part that isn't seekable. The compression gained going above the default 10 seconds is negligible. You can bump it up 25 or 50% without affecting seekability too much, but I wouldn't go higher than that.

You want less processing power? First step would be to downscale anything higher than 720p to 720p. A spline16 resized 720p CRF 18 or 19 is going to be pretty comparable to a CRF 21.5 1080.

[benwaggoner]

It's been a while since a mobile device shipped without a HW High Profile decoder, and I don't think any quad-core SoC ever lacked a High Profile decoder. And a HW decoder shouldn't care about any of this fast decode stuff. Are you forcing a software decoder for some reason?

For a SW decoder, peak bitrate is a big factor, so stuff that reduces compression efficiency like reduced b-frames generally will make your perf worst at a given quality level. If it's a custom SW decoder, B-frames introduces more out-of-order frames and thus a bigger decoded frame buffer, but that's a RAM and pipeline management issue, not a CPU thing. Strictly Hierarchical B-frames sometimes can help with this kind of stuff.

B-frames were more computationally expensive in MPEG-2 and VC-1, but I don't think they should be significantly different in H.264, since both P and B can reference multiple reference frames. --vbv-maxrate and --vbv-bufsize can certainly be helpful, particularly as stock x264 doesn't automatically constrain those to the specified Profile @ Level. For compatibility, I always suggest using the lowest level compatible with your content's frame size and fps, and set maxrate, bufsize, and at or below the Profile @ Level maximum.

Other than making sure my streams are complaint with target hardware, it's been years since I had to sweat further tuning for modern-ish devices*.

* Except max ref-frames for HW DRM'ed content running in memory carve out Trust Zone on Qualcomm SoCs. You need to carve out memory for the max frame size * max number of reference frames. So even if 1080p uses only 4, if your lowest bitrate uses 8, you need to carve out 1920x1080x8 in memory that is otherwise not available to the system.