x264 10bit slowness compared to 8bit (results)

[cdz]

Hey,

In doing some testing between 8/10bit, I get some rather dissatisfactory results in terms of speed/size.

The source is a high-motion clip from a game, recorded with Fraps.

source:

Video
ID : 0
Format : Fraps
Codec ID : FPS1
Duration : 33s 633ms
Bit rate : 486 Mbps
Width : 1 920 pixels
Height : 1 200 pixels
Display aspect ratio : 1.600
Frame rate : 30.000 fps
Color space : YUV
Bit depth : 8 bits
Bits/(Pixel*Frame) : 7.024
Stream size : 1.90 GiB (100%)


options:
--me umh
--merange 48
--subme 8
--ref 4
--trellis 0
--bframes 0
--qp (18 if 8bit; else 24)
--keyint 30
--ipratio 2
--deadzone-inter 6
--deadzone-intra 6
--no-psy
--no-dct-decimate


8bit results:

encoded 1011 frames, 4.07 fps, 65690.86 kb/s
278mb (13%)


10bit results:

encoded 1011 frames, 1.76 fps, 162107.85 kb/s
685mb (33%)


So, much larger/slower encode for 10bit.
The build I'm currently using is from february, but I've tested with a build from three days ago with the same results.

Are these results to be expected, or is there perhaps something wrong with my settings?
The output is to be re-encoded later, so I'm trying to keep as much detail as possible.

[SassBot]

Both of your results say: "encoded 1011 frames, 1.76 fps, 162107.85 kb/s". Did you copy something wrong?

[cdz]

@SassBot -- thanks for noticing, fixed!

[Asmodian]

Looks like they encode at exactly the same speed to me? (typo?)

You are using odd settings in my opinion, maybe try with just a preset? Why those --me-range and --subme settings for example. --me-range 24 should help speed a lot.

10-bit is known to be slower and better quality/size but also larger if you use the same settings. I guess +6 to qp isn't enough to bring the size down. Keep turning it up until the size comes out the same and then compare quality.

[Bloax]

It also puzzles me as for why you'd use a constant quantizer (*cough* --qp *cough*) instead of something like --crf 13.

[Atak_Snajpera]

your settings are bizzare indeed.

keyint ever second, psy optimalization disabled, no bframes, some dead zones added, trellis disabled as well.

take my advice and use presets created by developers

[Dark Shikari]

QP 18 in 10-bit doesn't mean the same thing as QP 18 in 8-bit -- it's a lot higher quality (and bitrate), so it's going to be way slower. The --qp option is really only for experimentation and testing, it should never be used for real encoding.

[cdz]

@Asmodian
Yes, it was a typo. Aye, the merange is too high. Actually though the 8bit max qp was 61, will keep testing different qp.

@Bloax
It's to keep more information, since It'll be re-encoded later.

@Atak
B-frames destroy too much information. I'm aware of the presets. Keyint won't make much of a difference here, and it's nice for quickly scanning through.
Also storage is relatively cheap. With raid, a terabyte is but crumbs on a fluffy cloud.

@Dark
Indeed- I'll probably end up with something ~30 ish.
But won't you agree that qp it's good for an intermediate encode?

[Dark Shikari]

B-frames don't "destroy information", they preserve it by getting better compression at the same bitrate. Constant QP mode is not any less useless for "intermediate encodes" than for any other type of encode.

Basing your encoding settings on urban legends and guessing is generally not a good idea.

[cdz]

@Dark
I've been under the impression that qp saves a lot more information, which would be useful for keeping the quality through later encodes. Also, the output looks much sharper and has more recemblance to the original; it tends to be softer/blander otherwise. But 3-400MB for a 33sec clip is rather ridiculous.
I'll try and stick with presets and bframes from now on - thanks!

[Dark Shikari]

QP 18 in 10-bit mode is going to be very roughly similar to a CRF of 0-10 or so -- so it's going to be needlessly high quality (practically lossless).

[upyzl]

Now that you used "--no-psy" , why not set a same 2pass bitrate(e.g. 2000kbps for 720p) to benchmark for Speed & SSIM comparison?

[SassBot]

@Dark
I've been under the impression that qp saves a lot more information, which would be useful for keeping the quality through later encodes.

And you came to this conclusion based on what facts?

Also, the output looks much sharper and has more recemblance to the original; it tends to be softer/blander otherwise. But 3-400MB for a 33sec clip is rather ridiculous.
I'll try and stick with presets and bframes from now on - thanks!

Yes, it looks much sharper because you've cranked the bitrate up to extreme levels. But that really has nothing to do with the fact that you used QP over CRF.

[cdz]

@dark
Yes, crf 10-15 seems to fit my storage budget

@upyzl
I never use a fixed bitrate for anything.

@Sass
Based on some general advices I got when starting with x264 around 2008. QP and no bframes. But I suppose things have changed. So no more qp, and bframes around 3. And presets.

It's also based on my general understanding of compression. If you're cheap on storage, lt will look like shit -- but that's for a different discussion.

[nm]

Based on some general advices I got when starting with x264 around 2008. QP and no bframes. But I suppose things have changed.

Nope. B-frames and CRF were generally recommended in 2008 too. Perhaps those advices were dated 2004.

[SassBot]

@Sass
Based on some general advices I got when starting with x264 around 2008. QP and no bframes. But I suppose things have changed.

Yes, the biggest thing is that advice was wrong in 2008 let alone 4 years later.

So no more qp, and bframes around 3. And presets.

Yes, constructing voodoo commandline options for x264 is generally not a good idea.


It's also based on my general understanding of compression. If you're cheap on storage, lt will look like shit -- but that's for a different discussion.

Your understanding of compression is flawed then. B-frames do not make things look bad, they improve compression so things like just as good (if not better) but use less bitrate to do so.