What *encoding* options raises most the cpu load during playback of one video?

[darkpingu]

Hi all,

I was wondering which *encoding* options (with x264) raises most the cpu load during playback of one video.
(I guess that bitrate and resolution are some of the most)

are there more encoding parameters that can affect cpu load during video playback?

Which are the ones that make a good balance between quality and cpu load?

Thanks in advance :)

[Sharktooth]

deblocking and cabac.
both of them greatly improve the final quality at the expense of decoding complexity.
other options (compared to those 2) have negligible impact on complexity.

[Inventive Software]

CABAC reduces the file size by as much as 30% compared to the default (CAVLC), and costs about as much to decode. Turning refs down to 1 helps too in decoding.

[LoRd_MuldeR]

Turning refs down to 1 helps too in decoding.

Reducing the number of refs reduces the memory required by the decoder. But does it reduce complexity (CPU load) in a noticeable way too?

[cogman]

Doesn't bitrate play a large role in processing power required? So higher bitrates = slower decoding.

[Inventive Software]

Reducing the number of refs reduces the memory required by the decoder. But does it reduce complexity (CPU load) in a noticeable way too?

It does on my machine. If I do a 16-ref encode, and compare it to a 1-ref encode, the decoder CPU usage is noticably less, at least with ffdshow's libavcodec.

[LoRd_MuldeR]

Doesn't bitrate play a large role in processing power required? So higher bitrates = slower decoding.

That's pretty much a result of CABAC.

CABAC decoding is pretty slow/complex! And the higher the bitrate, the more bits need to be decoded.

I think when using CAVLC the effect of bitrate should be much smaller...

[darkpingu]

Thank You.

It does not matter the final file size. Anyway, If CABAC reduces file size by 30%, does It mean that the encoder "has more bits to spend" in encoding process given a target bitrate? So is that what improves the quality?

May be I could disable CABAC and raise the bitrate somewhat (30%?)

I will also try with refs and deblocking.

[LoRd_MuldeR]

Thank You.

It does not matter the final file size. Anyway, If CABAC reduces file size by 30%, does It mean that the encoder "has more bits to spend" in encoding process given a target bitrate? So is that what improves the quality?

May be I could disable CABAC and raise the bitrate somewhat (30%?)

I will also try with refs and deblocking.

Yes, when encoding to a fixed target bitrate (2-Pass mode or 1-Pass ABR mode), then CABAC improves the quality.

When using CRF mode or a fixed quantizer, then CABAC just reduced the final output size.

[darkpingu]

Finally, I made these changes:

1) I keep using CABAC but I decreased the bitrate 20%

2) I dropped the fps from 30000/1001 to 25

3) I reduced refs from 10 to 3

These settings saved about 20-30% of cpu which is enough for my needs.

Thanks

[cogman]

Finally, I made these changes:

1) I keep using CABAC but I decreased the bitrate 20%

2) I dropped the fps from 30000/1001 to 25

3) I reduced refs from 10 to 3

These settings saved about 20-30% of cpu which is enough for my needs.

Thanks

25 is quite the unstandard number for fps, you might have problems with it in the future. Considering going to 24000/1001 instead (its slightly lower, but a standard at least) Baring that, you could go for a PAL fps and get just 24.

[alfadude]

Baring that, you could go for a PAL fps and get just 24.
Pal IS 25fps not 24fps

[cogman]

Pal IS 25fps not 24fps

Whoops, :) shows how much I use pal material then.

[juGGaKNot]

deblocking and cabac.
both of them greatly improve the final quality at the expense of decoding complexity.
other options (compared to those 2) have negligible impact on complexity.

Realy ? thnx, i will turn deblocking off ( ingame captures ).

[Dark Shikari]

Realy ? thnx, i will turn deblocking off ( ingame captures ).What does "ingame captures" have to do with it?

[Sagekilla]

Deblocking has nothing to do with how good the source is. If you're thinking that because you're capturing from a clean source with no noise or artifacts of any sorts, you don't need something like deblocking, then you're in for a surprise. Deblocking will almost ALWAYS improve quality, since you won't get really bad blocking (Read: DVD version of 300).

[Comatose]

Doesn't bitrate play a large role in processing power required? So higher bitrates = slower decoding.
Yes. Quoting Dark Shikari on the animesuki forums (http://forums.animesuki.com/showpost.php?p=2021163&postcount=12):

The higher compression ratios for H.264 mean that your computer has to do more work when decoding the file for display
No, actually, the higher the bitrate (and thus the lower the compression), the higher the CPU cost of decoding. A really low bitrate H.264 file will decode much faster than a high bitrate one.

The reason MPEG-2 is faster than H.264 is simply because it is a less complex format.

[sumawo13]

I figure I might as well ask a question in here, I believe it's relevant.

What kind of affect does b frames have on decoding, more specifically, does increasing the number of b frames increase the stress on the CPU?

[Sagekilla]

No, P vs B doesn't take any significant more CPU I believe. I don't remember 100% off hand, but I think B's were actually quicker to decode because they tend to have lots of "skip" MBs.

[Dark Shikari]

Theoretically B-frames would increase CPU time because of biprediction.

In practice, they don't, because they lower the bitrate significantly at the same quality level vs no B-frames, and the difference in bitrate decoding cost is greater than the extra time spent in motion compensation. Probably. Or close to it.

[Dethis]

CABAC reduces the file size by as much as 30% compared to the default (CAVLC), and costs about as much to decode. Turning refs down to 1 helps too in decoding.

I think that using CABAC instead of CAVLC reduces the bitrate at an average 10-12%, while the decoding cost is avg 30% greater (and near 50% for the bitrate peaks).

If the bitrate is big enough (say 12Mbps with 25Mbps peaks) it should be preferable to use CAVLC. Decoding it will be easier on average and with a steadier CPU use as it will suffer less from the bitrate peaks.

All the above was the conclusion of some tests 3 years ago using ffdshow on a P4@3.6Ghz cpu. May be today's decoders-cpus behave differently

[LoRd_MuldeR]

All the above was the conclusion of some tests 3 years ago using ffdshow on a P4@3.6Ghz cpu. May be today's decoders-cpus behave differently

I recommend you repeat your test with latest ffdshow-MT and/or CoreAVC and/or DivX H.264 Decoder ;)

[akupenguin]

I think that using CABAC instead of CAVLC reduces the bitrate at an average 10-12%
That really depends on quantizer. (http://akuvian.org/src/x264/entropy.png)