Few Questions about CRF mode, 8 vs. 10 bit encoding, and predictive lossless mode

[jasonwc]

I recently started to play with some of the more advanced features of x264 - particularly 10 bit encoding and the predictive lossless encoding mode and I have a few questions.

I should start by saying that I've read this (http://mewiki.project357.com/wiki/X264_Settings) and this (http://www.avidemux.org/admWiki/doku.php?id=tutorial:h.264) to familiarize myself with x264's options as well as several guides directed at MEGUI users, which is the GUI I'm using to make the process easier.

1) Is a 10 bit encode with a given CRF value and settings equivalent in quality to the same encode done at 8 bits?

The quantizer range for 8 bit encodes is 0-51 whereas the range is expanded to 0-69 in 10 bit mode. As expected, I noticed that CRF16 encodes with the 10 bit encoder display higher quants for I/P/B frames than a CRF16 encode done with identical settings in 8 bit mode.

I've read that 10 bit encoding offers a 10-20 efficiency gain over 8 bit encoding due to enhanced internal precision and will reduce banding at a given bitrate. However, it's unclear to me if the CRF levels are equivalent between 8 bit and 10 bit encoding modes. In other words, should I expect a CRF16 encode @ 10 bits to be equivalent to an encode done at 8 bit color depth with identical x264 settings?

Also, how much of a speed hit should I expect from for 10 bit encoding. I'm using a Core i7 with hyper-threading enabled (12 threads in x264). I'm doing a test encode of my Toy Story 3 BD as it has a lot of scenes where banding could be an issue, so I thought it would be a good 8 bit vs. 10 bit test encode. I'm basically using stock --very-slow --tune film settings. Encoding at original 1920x1080 size. Not resizing or using any filters that could slow down encoding and my CPU is pegged at 100%. It's encoding at about 2 FPS with the following settings (see below).

cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

2) Do the speed presets trade both quality AND efficiency in CRF mode, or just efficiency?

I've read inconsistent explanations of the impact of x264's quality presets on the quality of output in CRF mode. Obviously in 2-pass mode, lowering the preset to a faster setting will reduce quality as the bitrate is staying the same.

However, in CRF mode, x264 is not limited to a given output size, and may therefore increase bitrate to account for the faster encoding settings. MeGUI's guide, for example, states that the speed presets for 2-pass mode trade off speed for quality, whereas in CRF mode, they trade off speed for compression.

However, I've read elsewhere that the speed presets impact BOTH efficiency and quality in CRF mode.

This is important to me because when I'm encoding for Blu-Ray, size is generally not a constraint (my video content is short). I've been using CRF16 @ --veryslow but if the quality is the same/very similar at lower settings, it may make sense to encode faster since compression efficiency isn't very important.

3) What do I have to do to ensure I use the appropriate color space for lossless encoding?

I decided to play around with x264's predictive lossless encoding mode by using the PNG sequence from "Elephant's Dream" which can be found here (http://orange.blender.org/blog/original-lossless-source-available/).

I've tried reading about color spaces but I'm still pretty clueless and not sure what settings I'm supposed to use to ensure no loss in quality.

I tried setting --output-csp RGB since the PNG sequence is in 24 bit RGB - The output had more banding than the source PNGs. I then added ConvertToRGB() in my Avisynth script but that didn't help. The output looked the same and the banding was much more noticeable than in the PNGs.

I also tried using --output-csp i444 in x264 and ConverToyv24() in my Avisynth script but MeGUI complained that ConvertToyv24() wasn't recognized although it appears to be supported by Avisynth. See here (http://avisynth.org/mediawiki/ConvertToYV24). Perhaps support is only in the development versions as MeGUI uses the stable 2.5.8 version.

I read that Avisynth doesn't support 10 bit output natively but support can be achieved by using various plugins. One of the listed plugins is avs4x264mod.exe and that is used by MeGUI.

I'm pretty clueless here. Any help would be greatly appreciated. Thanks!

[nm]

2) Do the speed presets trade both quality AND efficiency in CRF mode, or just efficiency?

In CRF mode, faster presets generally give higher bitrates but quality may also turn out slightly different. Especially the fastest presets (superfast and ultrafast) tend to give noticeably lower quality at the same CRF value.


This is important to me because when I'm encoding for Blu-Ray, size is generally not a constraint (my video content is short). I've been using CRF16 @ --veryslow but if the quality is the same/very similar at lower settings, it may make sense to encode faster since compression efficiency isn't very important.

This is a different question. If you have no file size constraints, it's always possible to use fast presets and let the encoder use enough bits to reach the quality you want. Encoding mode can be CRF or 2-pass but CRF is easier since you don't need to guess a suitable bitrate.

Try CRF 16 with default settings (medium preset) or maybe slightly lower CRF with one of the faster presets. Medium is probably fast enough and it's pretty balanced.

[sneaker_ger]

1.
Quantizer range is 0 - 63 for 10 bit. --qp values above 63 (or 51 for 8 bit) are only for the VBV emergency mode AFAIK.
You may increase CRF a bit for 8 bit -> 10 bit, but there is no constant value, i.e. source dependent/subjective. I think I read "1 to 3" somewhere. If you're fighting banding it may be even more.

3.
Are you actually using lossless mode? ("--qp 0")

[jasonwc]

1.
Quantizer range is 0 - 63 for 10 bit. --qp values above 63 (or 51 for 8 bit) are only for the VBV emergency mode AFAIK.
You may increase CRF a bit for 8 bit -> 10 bit, but there is no constant value, i.e. source dependent/subjective. I think I read "1 to 3" somewhere. If you're fighting banding it may be even more.

3.
Are you actually using lossless mode? ("--qp 0")

1) Ah, that's good. I just wanted to make sure that CRF 16 at 10 bit was at least as good as CRF 16 at 8 bit. If it's better AND smaller (which it appears to be), that works.

3)

Yes, here's the command line for the encode and mediainfo for the sample:

Job commandline: "C:\Program Files\MeGUI\tools\x264\avs4x264mod.exe" --preset veryslow --qp 0 --deblock -1:-1 --keyint 240 --qpmin 10 --qpmax 51 --no-dct-decimate --output-csp i444 --sar 1:1 --output "D:\Lossless test videos\Elephants Dream Lossless 10bit 444.mkv" "D:\Lossless test videos\Elephants Dream CRF16 10bit.mkv.avs"

The AVS script:

CoronaSequence("D:\Lossless test videos\ED-1080-png\*.png", sort=1)
Assumefps (24.0)
#deinterlace
#crop
#denoise
trim(6500,7200)
ConverttoRGB32()

Mediainfo:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:4:4 Predictive@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 29s 208ms
Bit rate : 76.3 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 1.534
Stream size : 266 MiB (98%)
Writing library : x264 core 122 r2184 5c85e0a
Encoding settings : cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=9 / psy=0 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=12 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0
Language : English
Default : Yes
Forced : No

[jasonwc]

Kind of odd that MeGUI adds "--qpmin 10 --qpmax 51" for a -qp0 encode. They're ignored, so it doesn't matter, but still bizarre.

[sneaker_ger]

Yes. Should probably be removed from the SEI unless they serve any purpose unknown to me.

If there is banding then it must be due to one of the conversions, either in AviSynth, x264cli (swscale?) or during playback by renderer. Try updating to AviSynth 2.6, I'd be surprised if MeGUI stable had any problems with it. Then preview after a ConverToYV24() call in the same player as you use to view the encoded lossless file.

[jasonwc]

I've been using 2.5.8 because I remember reading somewhere that the 2.6 alpha builds are not compatible with MeGUI. However, I'll try anyway when my current encode is finished in a few hours. I didn't consider the possibility that my decoder was the culprit. I'm using an SVN build of ffdshow from a few weeks ago and an SVN build of MPC-HC for playback. I'll turn on ffdshow's OSD to I can see what color space it's outputting in. Thanks for the tips.

It appears I used --output-csp i444 in all the tests rather than --output-csp rgb. I'll try that after the 8 bit Toy Story 3 encode finishes. The 10 bit finished and looks excellent. I only could detect detail loss in one dark scene will comparing still frames and it would definitely not be noticeably in normal viewing conditions. I wasn't able to detect any banding that wasn't in the source - in fact one scene looked a bit better in the encode in terms of banding. Source was the US Blu-Ray of Toy Story 3 @ 24.6 Mbit AVC. Final video bitrate was 7546 Kbit which was lower than I was expecting.

Output:

"C:\Program Files\MeGUI 10 bit\tools\x264\x264_64" - --preset veryslow --tune film --crf 16.0 --keyint 240 --sar 1:1 --output "D:\In Process\Toy Story 3 2010 1080p Bluray AVC FLAC 5.1-Remux CRF16.mkv" --frames 147532 --fps 2500000/104271 --input-res 1920x1080 --input-csp i420
--[Information] [4/13/2012 8:32:40 PM] Standard error stream
---[NoImage] raw [info]: 1920x1080p 1:1 @ 2500000/104271 fps (cfr)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
---[NoImage] x264 [info]: profile High 10, level 5.1, 4:2:0 10-bit
---[NoImage]
---[NoImage] x264 [info]: frame I:1497 Avg QP:24.18 size:317239
---[NoImage] x264 [info]: frame P:46924 Avg QP:27.47 size: 74174
---[NoImage] x264 [info]: frame B:99111 Avg QP:31.15 size: 18655
....
---[NoImage] encoded 147532 frames, 1.96 fps, 7546.26 kb/s

[jasonwc]

Hmm, I'm not sure what the deal is. ffdshow says it's outputting RGB32. After upgrading to Avisynth 2.6, I was able to use ConvertToYV24 but the preview itself looked worse than the PNG - pretty much the same as the prior encode.

However, the Avisynth preview looks good when I don't do any color conversion, but the encode doesn't.

[jasonwc]

The 8 bit encode of Toy Story 3 finished, and there's a pretty significant size difference:

10 bit: 7546.26 Kb/s (5.40 GB) @ 1.96 fps (--veryslow, unrestricted Level)
8 bit: 8,571 Kb/s (6.14 GB) @ 2.79 fps (--veryslow, unrestricted Level)

So, the 8 bit encode was 13.6% larger than the 8 bit encode. I then ran a bunch of tests on a particularly high motion/detailed scene at every speed preset.

10 bit encode:

Placebo- 12,414 Kbit/sec (123 MB), 0.55 fps; QP 25.08, 28.78, 32.54
Veryslow - 12,256 Kbit/sec (121 MB); 1.59 fps; QP 24.87,28.87, 32.54
Slower - 13,139 Kbit/sec (130 MB); 3.21 fps; QP 23.81, 27.63, 30.55
Slow - 13.355 Kbit/sec (132 MB), 5.41 fps; QP 23.81, 27.64, 30.69
Medium - 14,088 Kbit/sec (140 MB), 10.58 fps; QP 24.46, 28.10, 30.64
Fast - 14,419 Kbit/sec (143 MB), 12.09 fps; QP 24.47, 28.11, 30.52
Faster- 13,619 Kbit/sec (135 MB), 17.86 fps; QP 24.54, 28.13, 30.49
Veryfast- 12,974 Kbit/sec (129 MB), 24.85 fps; QP 24.85, 28.31, 30.42
Superfast- 20,619 Kbit/sec (205 MB), 39.43 fps; QP 22.48, 25.20, 26.70
Ultrafast- 27,582 Kbit/sec (274 MB), 64.08 fps; QP 24.89, 27.93

8 bit:

Placebo: 13,062 Kbit/sec (129 MB), 0.73 fps; QP 12.47, 16.56, 20.17
Veryslow: 12,866 Kbit/sec (128 MB), 2.50 fps; QP 12.21, 16.64, 20.13
Veryslow (DXVA compatible) - 12,916 Kbit/sec (128 MB), 4.23 fps, QP 12.21, 16.64, 20.13
Slower: 13,855 Kbit/sec (137 MB), 4.71 fps; QP 12.00, 15.81, 18.61
Slow: 14,286 Kbit/sec (142 MB), 7.92 fps; QP 12.00, 15.81, 18.74
Medium: 14,553 Kbit/sec (144 MB), 12.76 fps; QP 12.38, 16.41, 18.51
Fast: 15,132 Kbit/sec (150 MB), 15.37 fps; QP 12.41, 16.43, 18.54
Faster: 14,330 Kbit/sec (142 MB), 21.97 fps; QP 12.51, 16.46, 18.50
Veryfast: 13,191 Kbit/sec (131 MB), 31.75 fps; QP 12.85, 16.66, 18.51
Superfast: 21,487 Kbit/sec (213 MB), 51.49 fps; QP 10.87, 13.44, 15.20
Ultrafast: 28,728 Kbit/sec (285 MB), 77.21 fps; QP 12.78, 15.89

10 bit --> 8 bit comparison:
Entire Movie: 13.6% larger
Placebo: 5.2% larger
Veryslow: 4.98% larger
Slower: 5.46% larger
Slow: 6.97% larger
Medium: 3.16% larger
Fast: 4.95% larger
Faster: 5.22% larger
Veryfast: 1.67% larger
Superfast: 4.21% larger
Ultrafast: 4.15% larger

Tests performed on a Core i7 860 @ stock 2.8 Ghz (2.93 Ghz Turbo), 12 GB RAM, Windows 7 x64 running 64 bit x264 (8 bit and 10 bit). Source was the US Toy Story 3 BD which had 26.4 Mbit AVC video. Encoded at 1920x1080. No resizing, cropping, or other filtering done, other than converting the colorspace to YV12.

Few thoughts:

- Placebo actually produced slightly larger files than veryslow for both the 8 bit and 10 bit encodes and did so at 1/3 the speed of veryslow. Definitely a waste of time.

- 10 bit encode was smaller in every test and took longer, as expected. Best compression resulted from using --veryslow @ 10 bit.

- It appears the use of 16 reference frames didn't do much good here - it did increase encoding time quite a bit (--veryslow --level 4.1 was almost as fast as --slower, and only marginally larger than the unrestricted --veryslow encode). I would have expected a bigger difference given the CGI source.

- CRF encodes get larger from placebo/veryslow through fast and then start getting smaller until superfast,where the bitrate balloons. Artifacts were quite obvious in veryfast, superfast and ultrafast - particularly blocking and smudging of sharp edges. Problems were less obvious on fast. Subjective differences seemed minimal for Medium or better.

So, it seems things fall apart after you go below Medium. Until Medium subjective quality is similar - at least at CRF16.

- At veryfast and below, decoding performance starts becoming a large factor. At ultrafast, only 40% of my CPU cycles were going to encoding. I figured using a DXVA decoder would speed things up but it actually made slowed encoding speed vs. using ffdshow to decode

- I was very impressed with the quality of veryfast given the bitrate. At 24.85 fps (10 bit)/ 31.75 (8 bit), it was faster than realtime. Yet, it produced results which were perfectly watchable. Artifacts were obvious in freeze frame comparisons but probably not very noticeable, if at all, while watching in normal viewing conditions.

- Seems that there's pretty much no good reason to ever use hardware encoding over x264. I have yet to obtain an encode from a hardware accelerated encoder that I didn't consider unwatchable crap. However, even at ultrafast settings, the output was perfectly watchable. Not great - but you get what you pay for. The point is that at least with x264 you can up the bitrate and get a decent output. Not so for many crappy software and hardware H.264 encoders (cough, Quicktime).

In contrast, I found a 720p hardware accelerated H.264 encode @ 30 Mbit horrible (AMD OpenCL accelerated) made within Cyberlink PowerDirector 10. There were huge macroblocks in some high complexity scenes which filled 1/4 of the screen. Utter and complete crap.

- If speed isn't a great concern, every preset through veryslow provides a noticeable improvement in compression efficiency.

- Slow and Medium presets provide a good tradeoff between speed and efficiency.

Since encoding on my Core i7 has zero impact on my system's performance (when using low priority for the process), I think --veryslow @ 10 bit is still the best for me, and --veryslow @ Level 4.1 for BD compliant encodes.

- Oh, and one amusing finding, if the ffdshow OSD is enabled, its output is burned into the final encode... :)

[sirt]

Hehe, aren't you wasting electricity too with those encodes ? :p

[CruNcher]

He tests out to decide then what he does, that is useful electricity loss ;) if it can save afterwards, jasonwc you should add a decoding complexity benchmark too for the different encodes to get a another point of view as well so you have a complete overview. Though encoding only a short sample instead of the whole runtime is not really saying much and now that you saw the results you should add SSIM and PSNR results also ;)

Though why did you converted the colorspace if the initial colorspace was already YV12 (8 bit) to begin with, i guess you did YV12->NV12->YV12 this wasn't really needed as you said you did no pre processing @ all especially not on the GPU ;)
Also the source is pretty good compressible artificial source you should try some more advanced stuff like 300 ;)

[Sagittaire]

- Placebo actually produced slightly larger files than veryslow for both the 8 bit and 10 bit encodes and did so at 1/3 the speed of veryslow. Definitely a waste of time.

Well prove nothing or simply that your test is completely useless. CRF mode at fixed value for different seeting don't produce same output quality. Then you can't compare output size file ine these conditions.

If you want make quality comparison you must fixe size file and compare quality (with metric or eyes) or fixe quality and compare size file. CRF mode is not good idea for make that.

[smok3]

CRF mode at fixed value for different seeting don't produce same output quality.

but you could match bitrate like say "crf 21 slow" and "crf 19 medium" on set of N samples and then compare quality.

[jasonwc]

He tests out to decide then what he does, that is useful electricity loss ;) if it can save afterwards, jasonwc you should add a decoding complexity benchmark too for the different encodes to get a another point of view as well so you have a complete overview. Though encoding only a short sample instead of the whole runtime is not really saying much and now that you saw the results you should add SSIM and PSNR results also ;)

Though why did you converted the colorspace if the initial colorspace was already YV12 (8 bit) to begin with, i guess you did YV12->NV12->YV12 this wasn't really needed as you said you did no pre processing @ all especially not on the GPU ;)
Also the source is pretty good compressible artificial source you should try some more advanced stuff like 300 ;)

Yeah, I only added ConvertoYV12() because if I don't MeGUI bitches about it endlessly so I figured I should.

Doesn't 300 have tons of compression artifacts since it's incredibly grainy and the geniuses at Warner Brothers encoded it at 17 Mbit with VC-1? It's annoying doing comparisons when most of the artifacts are in the source.

I think a better test would be with the Saving Private Ryan Blu-Ray. It has tons of fine grain, lots of detail, and fast movement. It also was encoded properly at 27.5 Mbit AVC and should be a better test source. I also have the 300 BD to test though.

As for the electricity cost, I was encoding a 2000 frame sample (1 minute, 23 seconds) and they were queued back to back. It got very quick after --veryslow. Probably only 2-3 hours of CPU time for all the tests.

[jasonwc]

Well prove nothing or simply that your test is completely useless. CRF mode at fixed value for different seeting don't produce same output quality. Then you can't compare output size file ine these conditions.

If you want make quality comparison you must fixe size file and compare quality (with metric or eyes) or fixe quality and compare size file. CRF mode is not good idea for make that.

I actually ran the test because I wanted to determine how much difference there is between CRF 16 encodes at different presets. If differences are small, going to a faster preset might make sense. But, if differences are noticeable, the slower presets are worth it. I wasn't really trying to test quality at a given bitrate. I was more interested in quality at a given CRF value.

And since --veryslow CRF16 has been transparent on every source I've tried at 1080p, and it appears --placebo doesn't save much, if any space, the test was somewhat useful in answering that question. Perhaps if I increased the CRF value it would be noticeable. In other words, I didn't assume that the quality would be equivalent. I knew it wouldn't be but wanted to determine which preset had the best quality/speed tradeoff for CRF16.

I'm going to test by resizing to 720p. I was able to differentiate --veryslow vs. a lossless encode with the same ayisynth script to resize (spline36). I used spline to upscale in ffdshow. The --veryslow CRF16 encode had slight haloing around objects. Lossless did not.

At 480p, this became very obvious, even from normal viewing distances. Again, the lossless encode was fine. I think Toy Story 3 is just too easy of a source. Everything above Medium looks transparent @1080p.

[jasonwc]

Well prove nothing or simply that your test is completely useless. CRF mode at fixed value for different seeting don't produce same output quality. Then you can't compare output size file ine these conditions.

If you want make quality comparison you must fixe size file and compare quality (with metric or eyes) or fixe quality and compare size file. CRF mode is not good idea for make that.

So, would a better test be running CRF16 --veryslow, taking the avg bitrate obtained and then encoding using 2 pass with all the other presets? That way, they'll all be the same size, and you can directly test quality.

[Audionut]

That's one way of doing it. Or just encode every preset at the same bitrate. I don't recall anyone actually having done it though, because, well, the results are pretty obvious.

The other option is to encode to a quality level and then compare file sizes. I don't recall anyone having done this either, because multiples encodes at the same quality is very hard.

The other option is to encode to a set metric (either psnr or ssim), but you have to make sure you use the correct command line options when doing this, and you loose the ability to test psy options.

edit: Also, if you encoded from the blu-ray source, I suspect your speed results are flawed due to the processing requirements of decoding H.264

[jasonwc]

That's one way of doing it. Or just encode every preset at the same bitrate. I don't recall anyone actually having done it though, because, well, the results are pretty obvious.

The other option is to encode to a quality level and then compare file sizes. I don't recall anyone having done this either, because multiples encodes at the same quality is very hard.

The other option is to encode to a set metric (either psnr or ssim), but you have to make sure you use the correct command line options when doing this, and you loose the ability to test psy options.

edit: Also, if you encoded from the blu-ray source, I suspect your speed results are flawed due to the processing requirements of decoding H.264

Yeah, I mentioned that last factor in one of my notes. At --ultrafast, the CPU utilization to decode was 30-40%. I tried off loading to my GPU(s) but that actually made it 10 fps slower.

[Audionut]

With only short samples, it's very easy to encode to a lossless format first that is very fast to decode. You should then also be reading the source file from one drive and encoding to another to help rule out HDD speed interference.

[nibus]

I've found that CRF placebo (--me tesa) actually increases compression on live film samples - usually around 2%.

[bcsizemo]

This thread is very similar to what I've been wondering as I've tinkered around with 10 bit....Does the QP increase when switching from the 8 bit encoder to 10 bit? Obviously given everything thing else the same, video, settings, bitrate, ect..

I have been running some tests on an SD DVD 740x480 with MeGUI and have noticed the following:

8 bit:
--[NoImage] x264 [info]: frame I:33 Avg QP:11.52 size: 48214
--[NoImage] x264 [info]: frame P:921 Avg QP:15.26 size: 20661
--[NoImage] x264 [info]: frame B:3046 Avg QP:17.80 size: 5882
--[NoImage] x264 [info]: SSIM Mean Y:0.9870626 (18.882db)
--[NoImage] x264 [info]: kb/s:1847.89

10 bit:
--[NoImage] x264 [info]: frame I:34 Avg QP:23.00 size: 48188
--[NoImage] x264 [info]: frame P:958 Avg QP:26.83 size: 21192
--[NoImage] x264 [info]: frame B:3008 Avg QP:29.62 size: 5441
--[NoImage] x264 [info]: SSIM Mean Y:0.9889075 (19.550db)
--[NoImage] x264 [info]: kb/s:1836.92

Both were done with a 2 pass encode with a bit rate of 1800 kb/s. The 10 bit looks good, just wondering if what I'm seeing about the QP going up by that much is expected. Don't mean to highjack a tread, just seemed like a waste to start a new one for such a simple question (or at least I hope so.)

[LoRd_MuldeR]

The quantizer scale for 8-Bit H.264 is 0-51, while the quantizer scale for 10-Bit H.264 is 0-63. So quantizer values cannot be compared directly between 8-Bit and 10-Bit encodes.

[bcsizemo]

The quantizer scale for 8-Bit H.264 is 0-51, while the quantizer scale for 10-Bit H.264 is 0-63. So quantizer values cannot be compared directly between 8-Bit and 10-Bit encodes.

I had come across that, and it was mentioned earlier on in the thread. I didn't know if the extension was done for a particular reason, or they were completely different. I assume the SSIM data should be the same since it is comparing the actual frame and nothing else correct? (And obviously if I like the way it looks is the biggest thing.)