Should i use 10bit x264 for encoding home movies

[Terka]

Have encodings from DV, mpg2 and mpeg4 (Panasonic sd600) camera.
Should i use 10bit x264.exe for encoding 8bit x264.exe?

[Warperus]

nope, use 8-bit version

[Terka]

Thank you for answer. Why 8 bit, i read that with 10 bit i get better quality for lower size. Could you please explain simply?

[Warperus]

Your original files do not have 10 bits encoding, they are in 8-bits.
Why do you get better overall quality in 10 bits in case of 10bits source? There are more colours in picture, wich makes gradients less likely to be seen and allows encoder to store more precise estimations of pictures. Unfortunately more precise does not always mean "less size". Any noise in the process will be stored better as well, eating more space. That is, 10 bits reencoding is a waste of space and time in your particular case.
In short, you can think of 10 bits encoding if you have source of better than normal quality or at least use NLE that gives you such source.
Also you will need 10bit compatible player/codec to watch movie. It might be a problem.

[Terka]

clear. sposibo Warperus!

[JEEB]

While the compatibility can be an issue (depends on how the videos will be played back, if you are expecting to have it played back on hardware decoders then just use 8bit H.264), I have a feeling that Warperus is missing one point, 10bit encoding is beneficial to compression (Yes, even when the source is 8bit). For a layman's explanation, look at this (http://www.x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf) PDF.

[Warperus]

To be honest, I don't fully believe in this explanation. It misses something.

Take a look at quick test:

x264 0.129.2230 1cffe9f
(libswscale 2.1.1)
(libavformat 54.19.0)
(ffmpegsource 2.17.3.0)
built on Nov 9 2012, gcc: 4.7.2
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: LGPL version 2.1 or later

>x264.exe -o rose8.h264 Rose.mpg
ffms [info]: 720x576i 64:45 @ 25/1 fps (vfr)
x264 [warning]: input appears to be interlaced, enabling tff interlaced mode.
If you want otherwise, use --no-interlaced or --bff
x264 [warning]: interlace + weightp is not implemented
x264 [info]: using SAR=64/45
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 3.0
x264 [info]: frame I:3 Avg QP:23.41 size: 53288
x264 [info]: frame P:168 Avg QP:25.25 size: 12751
x264 [info]: frame B:225 Avg QP:28.14 size: 2820
x264 [info]: consecutive B-frames: 8.6% 40.9% 18.2% 32.3%
x264 [info]: mb I I16..4: 4.4% 81.2% 14.4%
x264 [info]: mb P I16..4: 0.8% 3.6% 0.5% P16..4: 49.9% 22.8% 12.6% 0.0% 0.0% skip: 9.8%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 44.7% 5.6% 1.2% direct: 1.9% skip:46.6% L0:42.5% L1:50.9% BI: 6.5%
x264 [info]: field mbs: intra: 81.3% inter:57.7% skip:43.4%
x264 [info]: 8x8 transform intra:75.3% inter:74.9%
x264 [info]: coded y,uvDC,uvAC intra: 74.2% 89.0% 53.3% inter: 21.5% 29.4% 4.8%
x264 [info]: i16 v,h,dc,p: 25% 18% 5% 52%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 14% 17% 5% 9% 8% 14% 8% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 18% 14% 6% 10% 9% 12% 7% 6%
x264 [info]: i8c dc,h,v,p: 52% 16% 22% 10%
x264 [info]: ref P L0: 62.4% 24.3% 8.7% 1.8% 1.7% 1.1%
x264 [info]: ref B L0: 71.1% 22.3% 4.9% 1.5% 0.1% 0.1%
x264 [info]: ref B L1: 78.0% 20.6% 0.9% 0.6%
x264 [info]: kb/s:1483.10

encoded 396 frames, 23.03 fps, 1483.10 kb/s


x264 0.129.2230 1cffe9f
(libswscale 2.1.1)
(libavformat 54.19.0)
(ffmpegsource 2.17.3.0)
built on Nov 9 2012, gcc: 4.7.2
configuration: --bit-depth=10 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: LGPL version 2.1 or later

>x264_10b.exe -o rose10.h264 Rose.mpg
ffms [info]: 720x576i 64:45 @ 25/1 fps (vfr)
x264 [warning]: input appears to be interlaced, enabling tff interlaced mode.
If you want otherwise, use --no-interlaced or --bff
x264 [warning]: interlace + weightp is not implemented
x264 [info]: using SAR=64/45
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High 10, level 3.0, 4:2:0 10-bit
x264 [info]: frame I:3 Avg QP:35.57 size: 51203
x264 [info]: frame P:214 Avg QP:36.88 size: 11273
x264 [info]: frame B:179 Avg QP:40.52 size: 2773
x264 [info]: consecutive B-frames: 9.6% 90.4% 0.0% 0.0%
x264 [info]: mb I I16..4: 3.8% 79.5% 16.7%
x264 [info]: mb P I16..4: 0.5% 2.8% 0.4% P16..4: 50.5% 19.7% 11.9% 0.0% 0.0% skip:14.2%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 43.6% 5.8% 1.1% direct: 2.2% skip:47.3% L0:44.0% L1:49.4% BI: 6.5%
x264 [info]: field mbs: intra: 81.2% inter:56.6% skip:45.6%
x264 [info]: 8x8 transform intra:76.7% inter:74.0%
x264 [info]: coded y,uvDC,uvAC intra: 75.1% 87.3% 53.4% inter: 22.9% 31.5% 5.0%
x264 [info]: i16 v,h,dc,p: 29% 22% 5% 44%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 13% 14% 5% 10% 9% 15% 9% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 17% 14% 6% 11% 8% 13% 7% 6%
x264 [info]: i8c dc,h,v,p: 51% 16% 22% 11%
x264 [info]: ref P L0: 66.2% 21.4% 8.6% 1.4% 1.4% 0.9%
x264 [info]: ref B L0: 69.7% 25.6% 3.1% 1.6%
x264 [info]: ref B L1: 82.0% 18.0%
x264 [info]: kb/s:1546.73

encoded 396 frames, 14.84 fps, 1546.73 kb/s

[Chikuzen]

To be honest, I don't fully believe in this explanation. It misses something.

Those who understand it compare images instead of strings or numbers at first.

[JEEB]

To be honest, I don't fully believe in this explanation. It misses something.

Take a look at quick test:
How is that a test? By default x264 sets crf to 23 and preset to medium and all psychovisual optimizations on. Results from CRF already differ between presets, and now you are even pushing in the effects of different bit depths into the porridge (каша).

Taking the aforementioned into account, the file size is not comparable. Adding to that, the fact that you are having all psychovisual optimizations on, too, makes both PSNR and SSIM useless as comparison figures as well. I can only thank the x264 development team that x264 no longer outputs those values by default so people like you can't do what many people not having a clue have done before.

Good reading on how to actually test encoders, or more like what not to do in your tests is available here (http://x264dev.multimedia.cx/archives/458) and here (http://x264dev.multimedia.cx/archives/472).

There are various things you can test with and for, but just running a command like you just did is not a test of any kind. Just like getting a higher average bit rate with the same crf and a slower preset does not mean that the slower preset is worse off compression-wise.

[Warperus]

How is that a test?Blindly :rolleyes: I pretend to be blind user of x264, download new 10-bit release and run it with typical parameters I'd use for this case in previous (8-bit) version oof x264.
I do see difference between original file and x264 encodes, but it was not my purpose to have visual transparency here. There is no noticable difference in picture between 8-bit and 10-bit. Not that I can't start pixel hunting, but why should blind user do it?
The resulting file size is unfortunately differs by about 5% not in favor of 10-bit encoding.
The speed of processing differs by about 60% not in favor of 10-bit encoding.

What does it really show? Everything is complicated enough to have a second thought about switching to 10-bit encodes.

Taking the aforementioned into account, the file size is not comparable.If you have clear guidlines for this scenario as of what are differences in settings to compensate different crf calibration settings in different builds, you are welcome to share it. :script: Without them typical user of 10-bit version should either run quality tests for himself/herself or belive in old settings and "get in trouble" (as old values prove to be questionable at best).

effects of different bit depths into the porridgeThat's the point of original question.

I'd like to express negative impact of bit depth in this particular case:
1) original camera noise is here (no processing is done yet)
2) original bit depth is ~7.8 or 8
3) there is compression noise from original encoder
4) encoder has to store 20% more bits per DCT coefficient
5) compressibility of wider alphabet is generally worse
Encoder has to compensate negative factors just to keep up.

[detmek]

Try to compare 8-bit and 10-bit encoder in 2-pass mode with --tune ssim --ssim or --tune psnr --psnr. You can start with --bitrate 1500 as that is average bitrate for your encodes with crf 23.
P.S. Also read those two pages linked in JEEB's previous post.

[Audionut]

If you have clear guidlines for this scenario as of what are differences in settings to compensate different crf calibration settings in different builds, you are welcome to share it.

I believe it would be more polite if you did some searching for yourself so that others don't have to "blindly" re-hash things which have been explained plenty of times before.

[vivan]

There is no noticable difference in picture between 8-bit and 10-bit. Not that I can't start pixel hunting, but why should blind user do it?
The resulting file size is unfortunately differs by about 5% not in favor of 10-bit encoding.So... why not increase crf of 10-bit encoding by 0.5 and compare again? I bet there would be no noticable difference too. But size would be lower. That's why it's the wrong way.

4) encoder has to store 20% more bits per DCT coefficientThat's totally wrong, look at Quantizer values.

[Asmodian]

To be honest, I don't fully believe in this explanation. It misses something.

Reread it! I don't understand how you can not "fully believe" it. It is about how x264 (H.264) really works, not a superficial understanding of it. I fully understand the confusion, I shared it at one point and the net is full of people who share it, but go over that PDF carefully. It will all make sense in the end.

That said I would advise to use 8-bit too, just for the compatibility. With home movies people usually want them for long term storage and don't know what they might want to use to play them in the future. However, if you want the highest quality possible at a specific size, or the smallest size at a specific quality, use 10-bit. 10-bit has always been better quality at the same size in any of the tests I have done.

People are always thinking crf is magical. If you want to do these kinds of tests you should always use two-pass. I use two pass when testing options but crf when encoding. :)

[bikar]

Comparison

x264 8 vs 10
bitrate 5000

http://screenshotcomparison.com/comparison/164941

[bxyhxyh]

I did ONE TEST on ONE SOURCE (anime) with x264 2216 two months ago. And Placebo was too slow for me.
http://farm9.staticflickr.com/8084/8297488696_6ece536bb7_b.jpg

This is SSIM based file size difference. Not based on the subjective quality. But there is still difference