High 10 profile in x264: first impressions

[D3C0D3R]

used this builds
http://forum.doom9.org/showpost.php?p=1414996&postcount=3325

1. as they told us - it slooow about 3 times and it has different quatizers range for every
2. ffdshow d3c0d3 9-bit version normally - no artifacts, 10 bit - version in ffdshow b0rked - artifacts on some areas - its possible that is positive changes ))
3. logs ssim tells that at same bit rate 9bit sign. better that 8bit and 10 bit little better than 9-bit.:cool: I not sure that SSIM & PSNR calculation somehow depends from bit-depth and maybe not fair compare quality in this way, but...
EDIT as you can see PSNR & SSIM depends from depth, but i still not sure about compare
- static const int ssim_c1 = (int)(.01*.01*255*255*64 + .5);
- static const int ssim_c2 = (int)(.03*.03*255*255*64*63 + .5);
+ static const int ssim_c1 = (int)(.01*.01*PIXEL_MAX*PIXEL_MAX*64 + .5);
+ static const int ssim_c2 = (int)(.03*.03*PIXEL_MAX*PIXEL_MAX*64*63 + .5);

- double f_mse = (double)i_sqe / ((double)65025.0 * (double)i_size);
+ double f_mse = (double)i_sqe / (PIXEL_MAX*PIXEL_MAX * (double)i_size);

4. eficency of weight-p with increasing bit-depth is lowering :confused:
i plane do deeper testing on insane placebo options and divx d3c0d3 later, but it seems i was right and it helps :p
as Dark says with increasing bit depth efficency of every next bit is lower and lower

quick test logs


x264_10 --pass 1 --bitrate 1000 --ssim --psnr -o 10bit
x264_10 --pass 2 --bitrate 1000 --ssim --psnr -o 10bit.mkv 1.avs
10 bit

avs [info]: 720x304p 0:0 @ 10000000/417083 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High 10, level 3.0, bit depth 10
x264 [info]: frame I:8 Avg QP:28.67 size: 26179 PSNR Mean Y:53.32 U:56.44
V:56.88 Avg:54.13 Global:47.77
x264 [info]: frame P:481 Avg QP:32.90 size: 8088 PSNR Mean Y:42.92 U:47.40
V:48.07 Avg:44.00 Global:43.67
x264 [info]: frame B:388 Avg QP:36.60 size: 1160 PSNR Mean Y:43.01 U:48.11
V:48.74 Avg:44.16 Global:43.91
x264 [info]: consecutive B-frames: 11.6% 86.1% 1.4% 0.9%
x264 [info]: mb I I16..4: 15.2% 69.3% 15.5%
x264 [info]: mb P I16..4: 1.2% 4.4% 1.5% P16..4: 41.1% 24.9% 16.1% 0.0% 0
.0% skip:10.7%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 37.2% 4.0% 0.9% direct:
1.6% skip:56.2% L0:29.4% L1:48.4% BI:22.2%
x264 [info]: 8x8 transform intra:63.4% inter:72.5%
x264 [info]: coded y,uvDC,uvAC intra: 75.5% 76.9% 38.3% inter: 27.8% 27.1% 2.3%
x264 [info]: i16 v,h,dc,p: 69% 18% 7% 6%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 23% 19% 4% 5% 5% 7% 5% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 33% 28% 11% 3% 5% 5% 6% 4% 5%
x264 [info]: i8c dc,h,v,p: 46% 20% 27% 6%
x264 [info]: Weighted P-Frames: Y:0.2%
x264 [info]: ref P L0: 72.6% 16.0% 8.0% 3.4% 0.0%
x264 [info]: ref B L0: 95.7% 4.3% 0.0%
x264 [info]: ref B L1: 99.9% 0.1%
x264 [info]: SSIM Mean Y:0.9850951 (18.267db)
x264 [info]: PSNR Mean Y:43.056 U:47.796 V:48.447 Avg:44.164 Global:43.801 kb/s:
995.04

encoded 877 frames, 11.39 fps, 995.21 kb/s
==================================================================================
x264_9 --pass 1 --bitrate 1000 --ssim --psnr -o 9bit

9 bit

x264_9 --pass 2 --bitrate 1000 --ssim --psnr -o 9bit.mkv 1.avs
avs [info]: 720x304p 0:0 @ 10000000/417083 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High 10, level 3.0, bit depth 9
x264 [info]: frame I:8 Avg QP:23.06 size: 25945 PSNR Mean Y:53.20 U:56.29
V:56.72 Avg:54.01 Global:47.65
x264 [info]: frame P:479 Avg QP:26.95 size: 8132 PSNR Mean Y:42.89 U:47.29
V:47.93 Avg:43.95 Global:43.64
x264 [info]: frame B:390 Avg QP:30.65 size: 1143 PSNR Mean Y:42.97 U:47.98
V:48.60 Avg:44.11 Global:43.86
x264 [info]: consecutive B-frames: 12.3% 82.9% 2.1% 2.8%
x264 [info]: mb I I16..4: 16.3% 68.6% 15.2%
x264 [info]: mb P I16..4: 1.3% 4.4% 1.4% P16..4: 41.2% 25.7% 15.9% 0.0% 0
.0% skip:10.2%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 36.7% 4.0% 0.9% direct:
1.6% skip:56.6% L0:29.7% L1:48.0% BI:22.3%
x264 [info]: 8x8 transform intra:63.1% inter:72.3%
x264 [info]: coded y,uvDC,uvAC intra: 75.7% 77.2% 39.5% inter: 27.6% 27.3% 2.3%
x264 [info]: i16 v,h,dc,p: 75% 14% 5% 5%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 24% 24% 19% 4% 5% 5% 7% 5% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 34% 27% 11% 3% 5% 5% 6% 4% 5%
x264 [info]: i8c dc,h,v,p: 46% 20% 28% 6%
x264 [info]: Weighted P-Frames: Y:1.5%
x264 [info]: ref P L0: 71.0% 17.4% 8.1% 3.4% 0.0%
x264 [info]: ref B L0: 95.6% 4.4% 0.0%
x264 [info]: ref B L1: 99.8% 0.2%
x264 [info]: SSIM Mean Y:0.9847715 (18.173db)
x264 [info]: PSNR Mean Y:43.018 U:47.681 V:48.310 Avg:44.115 Global:43.763 kb/s:
994.80

encoded 877 frames, 11.07 fps, 994.97 kb/s
==================================================================================
8 bit
x264 --pass 2 --bitrate 1000 --ssim --psnr -o 8bit.mkv 1.avs
avs [info]: 720x304p 0:0 @ 10000000/417083 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.0
x264 [info]: frame I:7 Avg QP:17.39 size: 25231 PSNR Mean Y:53.92 U:56.59
V:57.10 Avg:54.66 Global:47.39
x264 [info]: frame P:384 Avg QP:21.06 size: 9459 PSNR Mean Y:42.88 U:47.16
V:47.73 Avg:43.92 Global:43.59
x264 [info]: frame B:486 Avg QP:24.05 size: 1504 PSNR Mean Y:42.37 U:47.00
V:47.61 Avg:43.46 Global:43.17
x264 [info]: consecutive B-frames: 12.2% 27.4% 37.9% 22.5%
x264 [info]: mb I I16..4: 17.9% 66.9% 15.2%
x264 [info]: mb P I16..4: 1.5% 6.1% 1.9% P16..4: 39.0% 28.4% 16.2% 0.0% 0
.0% skip: 6.8%
x264 [info]: mb B I16..4: 0.1% 0.1% 0.0% B16..8: 41.7% 6.0% 1.3% direct:
2.2% skip:48.6% L0:35.8% L1:49.2% BI:14.9%
x264 [info]: 8x8 transform intra:64.4% inter:72.1%
x264 [info]: coded y,uvDC,uvAC intra: 77.2% 77.8% 40.2% inter: 27.4% 29.1% 2.0%
x264 [info]: i16 v,h,dc,p: 71% 14% 5% 10%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 24% 24% 20% 4% 5% 5% 6% 5% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 34% 26% 11% 3% 5% 5% 6% 4% 5%
x264 [info]: i8c dc,h,v,p: 47% 20% 27% 5%
x264 [info]: Weighted P-Frames: Y:4.2%
x264 [info]: ref P L0: 60.4% 21.0% 13.6% 4.9% 0.1%
x264 [info]: ref B L0: 89.1% 9.7% 1.2%
x264 [info]: ref B L1: 92.7% 7.3%
x264 [info]: SSIM Mean Y:0.9830545 (17.709db)
x264 [info]: PSNR Mean Y:42.684 U:47.146 V:47.735 Avg:43.752 Global:43.369 kb/s:
992.89

encoded 877 frames, 36.03 fps, 993.06 kb/s

[Soichiro]

It looks like along with weight-p, b-frame efficiency also decreases greatly with 9-bit and 10-bit versions. Of course, I suppose what's important is the output, not the stats. Is there a way you could post comparison screencaps for each version? (Perhaps not for the 10-bit version if it won't decode properly, but at least for the 9 and 8 bit versions.)

inb4 the mandatory unhelpful "You're doin' it wrong" posts.

[AlekseiV]

stop it

use --tune ssim to test ssim, and --tune psnr to test psnr

[Sharktooth]

... i dont understand... if the input is still 8 bit... HOW can 10 bit encoding help? sounds like BS...

[MasterNobody]

... i dont understand... if the input is still 8 bit... HOW can 10 bit encoding help? sounds like BS...
Precision of some operation (smaller rounding errors)

[lexor]

... i dont understand... if the input is still 8 bit... HOW can 10 bit encoding help? sounds like BS...

Right now, if source has banding, fixing it with filters doesn't help, unless you throw rediculous bitrate at it, it will still band in output.

My hope is that this change will help reserve dithering/smoothing of gradients, at the low bitrates.

[mp3dom]

What rounding errors? There's no rounding errors if the source is 8 bit and your output 8 bit. Actually it doesn't make sense to encode a 8bit source to 10bit, unless you need to apply filters in the 10bit file to have more precision but Avisynth doesn't support it and I don't think that NLEs supports 10bit AVC files.

Right now, if source has banding, fixing it with filters doesn't help, unless you throw rediculous bitrate at it, it will still band in output.
My hope is that this change will help reserve dithering/smoothing of gradients, at the low bitrates.

Do you think that 10bit allow you to preserve dithering with 5000 kbps? Also, where do you think to watch a 10bit AVC file if the majority of software/hardware decoders doesn't support it? If you can fix the banding in a 8bit file (quite possible) you can preserve it with high bitrates like 30-40 Mbps or, if you need the highest quality, encode as lossless.

[Soichiro]

>Making the assumption that x264 does all its calculations in 8-bit mode.

Lol. x264 uses more precision than that, so when you output to 8-bit mode, yes, you're going to get rounding errors, unless you're encoding to lossless of course. Using 9-bit or 10-bit helps to alleviate this problem somewhat.

Although yes, this feature would be more useful if it would accept 10-bit input as well. The devs are supposedly working on that though, so we can assume that this is only a beginning.

[Audionut]

Also, where do you think to watch a 10bit AVC file if the majority of software/hardware decoders doesn't support it?

Valid for now.

I'm fairly sure ffmpeg will be updated very shortly to support 10bit.

10bit ain't going to fixed banding issues already in a source.
But it could surely help with the rounding issues if the source doesn't have issues to begin with.
I guess it will be a question of weighing up between, bitrate, hardware support, external solutions.

[Dark Shikari]

This thread is filled with stupid.

2. ffdshow d3c0d3 9-bit version normally - no artifacts, 10 bit - version in ffdshow b0rked - artifacts on some areas - its possible that is positive changes ))FFDshow only supports 8-bit. It working with over 8-bit is mere coincidence -- it only seemed to work because it just happened that all of your pixels fit in 8-bit.

4. eficency of weight-p with increasing bit-depth is lowering :confused:This is expected, if you mean that weightp helps less. The primary gain of the ref-duping weightp was because of rounding errors.

What rounding errors?Maybe, you know, the one when every single frame is decoded and all the extra bits clipped off, preventing the extra precision from being used for future references? Or in qpel, where all the extra precision is lost before doing linear interpolation? Or in bidirectional prediction, where all the extra precision is lost before doing linear interpolation?

Do you think that 10bit allow you to preserve dithering with 5000 kbps?That's the whole point.

[Sharktooth]

i still dont understand why output to 10 bits... isnt it just a waste o bits?
i mean, if rounding errors are the concern, why not just do the internal calculations in 10 bits and then "dither" down to 8 for output?

edit: well... thinkin about it probably i already know the answer..

[Dark Shikari]

i still dont understand why output to 10 bits... isnt it just a waste o bits?
i mean, if rounding errors are the concern, why not just do the internal calculations in 10 bits and then "dither" down to 8 for output?The "10" in High 10 is the internal precision, not the output precision. The output precision is the choice of your media player.

[mp3dom]

i mean, if rounding errors are the concern, why not just do the internal calculations in 10 bits and then "dither" down to 8 for output?
I was thinking the same... ok.

[Sharktooth]

The "10" in High 10 is the internal precision, not the output precision. The output precision is the choice of your media player.
yeah. i was thinking exactly that just after i wrote my post...

[moviefan]

Does 10 bit encoding result in bigger file sizes? And if it is superior to 8 bit, why hasn't it been used for e.g. Blu-ray production and why is there 8 bit precision anyway?

[Audionut]

Why is there interlaced. Why low res monitors. Why has decent 3d only just arrived etc etc.

[poisondeathray]

Does 10 bit encoding result in bigger file sizes? And if it is superior to 8 bit, why hasn't it been used for e.g. Blu-ray production and why is there 8 bit precision anyway?


Yes, slightly less than 1/3 larger file size for similar compression

No one will argue that it's superior for intermediate calculations and color correction , but is the bandwidth worth it for a distribution/end format ?

Also, most people have 6-bit or 8-bit LCD panel displays. There are a few 10-bit panels available, but they are usually for professionals and are more expensive. Ideally, you would retain 10-bit workflow (or higher) from acqusition all the way to final product and viewing.

[Stephen R. Savage]

Actually, 10-bit encoding on 8-bit YUV sources should save bits. This is because the 25% increase in pixel size is offset by more accurate prediction. Further, the output display having only 8-bits is irrelevant, as the goal of bit-depth increasing is to allow more accurate conversion back to the original 8-bit colorspace.

(Also, the random dig at TN panels is misleading. Since the pixels update faster than 60 Hz, emulation of higher bit depths is entirely possible.)

[Dark Shikari]

Does 10 bit encoding result in bigger file sizes? And if it is superior to 8 bit, why hasn't it been used for e.g. Blu-ray production and why is there 8 bit precision anyway?It's significantly slower to encode and decode, even if encoder and decoder are fully-optimized.

8-bit precision is a speed shortcut, nothing more.

[Stephen R. Savage]

It's significantly slower to encode and decode, even if encoder and decoder are fully-optimized.

8-bit precision is a speed shortcut, nothing more.

Speaking of optimization, does the fact that the pixels are no longer a power of two size present any complications when writing assembly code?

[poisondeathray]

Actually, 10-bit encoding on 8-bit YUV sources should save bits. This is because the 25% increase in pixel size is offset by more accurate prediction.

I'm seriously doubting the cost savings from more accurate prediction alone. Are you saying this is the only factor for the "offset"?

[Soichiro]

Well, you saw the OP's post, right? 9 and 10-bit had higher PSNR and SSIM at the same bitrate. I know everyone will probably tell me that doesn't mean anything and I'm stupid, but at least I have something to back this up. Saying that there's a 30% increase in bitrate and having no proof to back it up... Well, unless you have proof, that is?

I mean, you can't just look at the numbers and say 10 is greater than 8, therefore 10-bit encoding must use more bitrate (specifically, 25% more). H.264 is more complex than that.

[poisondeathray]

Maybe you're right, but I'd still like to see more proof . Does anyone know if x264's internal metrics are measuring correctly? For example , you need the Pro version of MSU's measuring utility to measure 10-bit. Maybe someone can meaure using JVT's reference software which supposedly supports 10-bit.

Also, I'm basing my previous comments on older discussions on AVC-Intra 100 (Panasonics' version of 4:2:2 10-bit used for acquisition), I'll try to find some reference links.

[Dark Shikari]

Speaking of optimization, does the fact that the pixels are no longer a power of two size present any complications when writing assembly code?Yes, in all functions that are required to clip their output pixels to valid values, such as iDCT.

Internally everything is 16-bit, but such clipping is still mandatory.

[Sulik]

Maybe you're right, but I'd still like to see more proof . Does anyone know if x264's internal metrics are measuring correctly? For example , you need the Pro version of MSU's measuring utility to measure 10-bit. Maybe someone can meaure using JVT's reference software which supposedly supports 10-bit.

This is not entirely unexpected nor specific to H.264, especially at low quantization levels, this is why MPEG-2 also had an option to use 10-bit coding of the DC component in intra blocks, even though final pixel precision was 8-bit.

[Manao]

this is why MPEG-2 also had an option to use 10-bit coding of the DC component in intra blocksNo. That option is actually badly named. In mpeg2, whatever the quantizer of the macroblock, the DC is quantized at a fixed quantizer, determined by intra DC precision. IIRC, 8 bits precision is equivalent to quantizer 8, while 10 bits is equivalent to quantizer 2. But it's not even remotely similar to what AVC does with 10 bits. In mpeg2, the output of the iDCT is 8bits (signed), whatever the intra DC precision

For the rest, 10 bits, compressed in AVC with the same quality as 8 bits, don't take more bits. It actually takes a bit less, and somewhat increases the quality. But it increases the encoder / decoder requirements, so that's why it wasn't included for bluray.

[poisondeathray]

The post I referred to earlier 8-bit vs. 10-bit and requring higher bitrate a DP who does productions for the BBC. His 30% number for the same "compression ratio" number might be incorrect, there isn't any evidence to support it , but I've seen this number quoted in several places - perhaps wrongly so. He refers in the general acquisition context (so signal processing in camera is usually from 10-14bit and RGB source , not an 8-bit YUV source).

http://www.dvinfo.net/forum/convergent-design-nanoflash/466803-8-bit-10-bit-my-thoughts.html

Broadcast Engineering is a respected publication and there does seem to be a PSNR improvement 10-bit vs. 8-bit at the same bitrate . Page 3 of their article is relevant, specific to AVC (and this thread), and seems to support what everyone is saying. Apparently PSNR gains are negligible on noisy sorces and better with clean sources. There is a link to another article below which suggest this too, and they did measure with JVT JM reference software.

http://broadcastengineering.com/hdtv/avch-encoding/index2.html

http://voyager.ericsson.net/uploads/documents/originals/10%20bit%20high%20quality%20MPEG-4%20AVC%20video%20compression.pdf

[Mug Funky]

10 bit support (especially bearing mind people are already using x264 for hi-res capture from SDI capture cards) means x264 can compete with pro formats.

obviously 10-bit input needs to be done as well, but IIRC the GsoC page mentions this.

i'd love to be able to ditch ProRes and DNxHD for something faster, better, and smaller. x264 i-frame only at 4:2:2 or 4:4:4 10 bit will be a boon to the increasing number of post people who send high quality stuff over ftp or the web. post workflow is increasingly happening in many facilities, not just the one, so low bandwidth, high (visually lossless) quality encoding with fast decode is sorely needed. if x264 can give ProRes results in less than miniDV bitrate, it'll take over pretty quickly.

[D3C0D3R]

Quote:Originally Posted by Sharktooth
... i dont understand... if the input is still 8 bit... HOW can 10 bit encoding help? sounds like BS...

Precision of some operation (smaller rounding errors)
and we have more wide range for quants - encoder is little bit flexible
look at patch below - only better rounding give us up to extra 10%
http://git.videolan.org/?p=x264.git;a=commit;h=411ee507328890fb1fde96b37b6eef854d27101a

This thread is filled with stupid.
i never pretend by naming smartest guy. that's why i'm here ))
The primary gain of the ref-duping weightp was because of rounding errors.
you mean rounding errors without weight-p accumulated and hurt quality?

For example , you need the Pro version of MSU's measuring utility to measure 10-bit.

here is some another quick rough tests on insane placebo settings with clean animated content. I know, i know i forget to change qpmin 9 --qpmax 51 --qpstep 5 - sorry, yesterday i was tired.

for this reason i didnt post 10 bit because nothing interest only different crf=34.0 for same bitrate, and it has for a 5% better ssim,psnr that a 9-bit. obviously that speed is same.
But you can see that on anime extra precision still gives us 0.35-0.4 additional db or extra 10% for 9-bit and extra 15% for 10-bit

C:\SIMPSONS\Season_34\test>x264_8 --crf 22.2 --keyint 300 --min-keyint 25 --scenecut 70 --no-fast-pskip
--bframes 6 --b-adapt 2 --b-pyramid normal --weightb --ref 16 --deblock 1:1 --rc-lookahead 100 --trellis 1
--psy-rd 0.0:0.0 --partitions p8x8,b8x8,i4x4,i8x8 --direct auto --merange 16 --qpmin 9 --qpmax 51 --qpstep 5
--me umh --subme 9 --8x8dct --ipratio 1.41 --pbratio 1.33 --chroma-qp-offset 2 --aq-mode 2 --qcomp 0.55
--aq-strength 0.7 --weightp 2 --ssim --psnr --threads 1 --output "48.mkv" "4.avs"
avs [warning]: converting input clip to YV12avs [info]: 480x360p 0:0 @ 25/1 fps(cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:13 Avg QP:21.25 size: 13414 PSNR Mean Y:49.63 U:49.31 V:50.27 Avg:49.66 Global:45.44
x264 [info]: frame P:259 Avg QP:23.76 size: 4448 PSNR Mean Y:42.66 U:43.22 V:44.55 Avg:43.00 Global:42.70
x264 [info]: frame B:629 Avg QP:29.18 size: 1195 PSNR Mean Y:41.61 U:42.78 V:44.21 Avg:42.12 Global:41.82
x264 [info]: consecutive B-frames: 4.8% 4.3% 17.2% 42.8% 19.7% 8.8% 2.4%
x264 [info]: mb I I16..4: 35.4% 23.3% 41.3%
x264 [info]: mb P I16..4: 8.5% 5.5% 5.0% P16..4: 39.0% 13.6% 7.4% 0.0% 0.0% skip:21.0%
x264 [info]: mb B I16..4: 0.8% 0.7% 0.9% B16..8: 26.3% 5.4% 1.4% direct: 1.1% skip:63.5% L0:49.6% L1:45.6% BI: 4.8%
x264 [info]: 8x8 transform intra:27.9% inter:63.4%
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: coded y,uvDC,uvAC intra: 41.8% 60.8% 34.5% inter: 10.9% 11.1% 1.2%
x264 [info]: i16 v,h,dc,p: 39% 39% 13% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 13% 44% 4% 3% 4% 3% 5% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 25% 20% 5% 5% 5% 6% 5% 7%
x264 [info]: i8c dc,h,v,p: 26% 39% 25% 9%
x264 [info]: Weighted P-Frames: Y:5.8%
x264 [info]: ref P L0: 48.4% 13.4% 14.5% 4.6% 3.3% 2.7% 2.2% 1.6% 1.2% 1.
1% 1.0% 1.9% 1.5% 1.1% 0.9% 0.8%
x264 [info]: ref B L0: 75.2% 8.8% 4.2% 2.0% 1.5% 1.2% 1.1% 0.9% 0.5% 0.5% 0.6% 1.7% 0.8% 0.6% 0.3%
x264 [info]: ref B L1: 93.1% 6.9%
x264 [info]: SSIM Mean Y:0.9885154 (19.399db)
x264 [info]: PSNR Mean Y:42.029 U:42.998 V:44.394 Avg:42.482 Global:42.090 kb/s: 461.33

encoded 901 frames, 11.20 fps, 461.49 kb/s

C:\SIMPSONS\Season_34\test>x264_9 --crf 28.2 --keyint 300 --min-keyint 25 --scenecut 70 --no-fast-pskip
--bframes 6 --b-adapt 2 --b-pyramid normal --weightb --ref 16 --deblock 1:1 --rc-lookahead 100 --trellis 1
--psy-rd 0.0:0.0 --partitions p8x8,b8x8,i4x4,i8x8 --direct auto --merange 16 --qpmin 9 --qpmax 51 --qpstep 5
--me umh --subme 9 --8x8dct --ipratio 1.41 --pbratio 1.33 --chroma-qp-offset 2 --aq-mode 2 --qcomp 0.55
--aq-strength 0.7 --weightp 2 --ssim --psnr --threads 1 --output "4_9.mkv" "4.avs"
avs [warning]: converting input clip to YV12avs [info]: 480x360p 0:0 @ 25/1 fps
(cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High 10, level 3.1, bit depth 9
x264 [info]: frame I:13 Avg QP:27.05 size: 13509 PSNR Mean Y:49.89 U:49.53
V:50.46 Avg:49.89 Global:45.66
x264 [info]: frame P:262 Avg QP:29.62 size: 4358 PSNR Mean Y:42.83 U:43.40
V:44.74 Avg:43.17 Global:42.88
x264 [info]: frame B:626 Avg QP:35.30 size: 1202 PSNR Mean Y:41.74 U:42.95
V:44.41 Avg:42.26 Global:41.95
x264 [info]: consecutive B-frames: 4.8% 5.6% 18.9% 39.2% 17.5% 10.8% 3.2%
x264 [info]: mb I I16..4: 38.0% 21.8% 40.2%
x264 [info]: mb P I16..4: 9.2% 5.0% 4.8% P16..4: 38.3% 13.2% 7.1% 0.0% 0
.0% skip:22.4%
x264 [info]: mb B I16..4: 0.8% 0.7% 1.0% B16..8: 25.3% 5.3% 1.4% direct:
1.1% skip:64.5% L0:49.0% L1:46.0% BI: 5.0%
x264 [info]: 8x8 transform intra:26.1% inter:63.7%
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: coded y,uvDC,uvAC intra: 40.4% 59.5% 34.3% inter: 11.0% 11.0% 1.2%
x264 [info]: i16 v,h,dc,p: 35% 39% 13% 13%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 12% 43% 4% 3% 4% 3% 6% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 25% 20% 5% 6% 5% 6% 5% 7%
x264 [info]: i8c dc,h,v,p: 27% 39% 25% 10%
x264 [info]: Weighted P-Frames: Y:3.4%
x264 [info]: ref P L0: 47.3% 14.2% 15.0% 4.4% 3.2% 2.7% 2.2% 1.5% 1.2% 1.
1% 0.9% 2.0% 1.2% 1.4% 0.9% 0.9%
x264 [info]: ref B L0: 75.4% 9.0% 4.0% 2.0% 1.3% 1.2% 1.0% 1.0% 0.5% 0.
5% 0.6% 1.6% 0.9% 0.8% 0.3%
x264 [info]: ref B L1: 93.2% 6.8%
x264 [info]: SSIM Mean Y:0.9894120 (19.752db)
x264 [info]: PSNR Mean Y:42.177 U:43.173 V:44.594 Avg:42.638 Global:42.242 kb/s:
459.37

encoded 901 frames, 2.15 fps, 459.53 kb/s

[madshi]

Does x264 support higher than 8bit sources yet? Or is this just for internal processing right now?

The reason I'm asking is that e.g. if you convert a 1080p24 Blu-Ray source to 720p24, the downscaling (if done properly) results in higher than 8bit bitdepth. Now if you do bad processing, you'll round the scaled down frames to 8bit. If you do good processing, you'll dither the scaled down frames to 8bit. Rounding probably results in better compression efficiency, but introduces banding. Dithering avoids banding, but reduces compression efficiency. The best solution would be for x264 to support higher bitdepth input to avoid/reduce both banding and dithering. That should improve image quality and coding efficiency at the same time.

Also, most people have 6-bit or 8-bit LCD panel displays.
A good video renderer dithers the decoder's output to the display's native bitdepth.

[Dark Shikari]

you mean rounding errors without weight-p accumulated and hurt quality?The primary purpose of the weightp refduping algorithm is to compensate for the rounding errors caused by qpel motion compensation. The less rounding error, the less useful it is.

By the way, note that this "internal bit depth increase" is a very popular feature in the H.265 proposals.

[Selur]

Little question about the High10 profile and 9-/10-bit depth, as far as I understood it atm. 9-/-10-bit support needs to be configured at compile time, so one needs a special build for each output bit depth.
Is it planned and possible to change this in the near future?
(or would gui developers who want to support High10 and the higher output bit depth need to include three x264 binaries (8/9/10 bit) with their guis?)

[Dark Shikari]

Little question about the High10 profile and 9-/10-bit depth, as far as I understood it atm. 9-/-10-bit support needs to be configured at compile time, so one needs a special build for each output bit depth.
Is it planned and possible to change this in the near future?
(or would gui developers who want to support High10 and the higher output bit depth need to include three x264 binaries (8/9/10 bit) with their guis?)We don't intend for High 10 to be widely used at the moment -- without libavcodec supporting it, it's a bit of a niche case. But we have to start somewhere, obviously.

It would be rather difficult to make it runtime settable. You'd have to effectively include 3 copies of x264 inside one build.

Also, 9 doesn't really have a reason to exist. It's only there because it's between 8 and 10 and thus trivial.

[Selur]

Thanks for the fast reply! :)

I suspected that it wasn't easy to combine the three builds but before I include three binaries and in a week the whole thing changes I thought I better ask. :)

Cu Selur

[madshi]

FWIW, both CoreAVC and DiAVC devs stated they would look into 10bit decoding later this year.

[SeeMoreDigital]

I'd love to be able to ditch ProRes and DNxHD for something faster, better, and smaller. x264 i-frame only at 4:2:2 or 4:4:4 10 bit will be a boon to the increasing number of post people who send high quality stuff over ftp or the web. post workflow is increasingly happening in many facilities, not just the one, so low bandwidth, high (visually lossless) quality encoding with fast decode is sorely needed. if x264 can give ProRes results in less than miniDV bitrate, it'll take over pretty quickly.You took the words right out of my mouth ;)

EDIT: I receive a fair amount of lossless and intermediate sources generated on Mac's... I wonder if they'll ever get around to embracing lossless AVC?

[mariush]

Why just 10 bit and not 12,14 bit too? In Wikipedia it says the Intel encoder supports up to 14 bit too...

My guess is you were thinking of using the extra bits in a 16bit pixel for masking or some processing but that's probably not it as you said in assembly you use 16 bit and then clip...

[Dark Shikari]

Why just 10 bit and not 12,14 bit too? In Wikipedia it says the Intel encoder supports up to 14 bit too...

My guess is you were thinking of using the extra bits in a 16bit pixel for masking or some processing but that's probably not it as you said in assembly you use 16 bit and then clip...11 bits began to break more things internally (various other numbers running out of precision). We might be able to go reasonably up to 12 once we convert the lookahead to 8-bit.

[Selur]

from the changelog:
Also note that the quantizer scale differs for higher bit depth. For example, for 10-bit, the quantizer (and crf) ranges from 0 to 63 instead of 0 to 51.
Will the quantizer range change for 9-bit, also? (if, yes to what values)

[LoRd_MuldeR]

from the changelog:

Will the quantizer range change for 9-bit, also? (if, yes to what values)

From the source:

#define QP_BD_OFFSET (6*(BIT_DEPTH-8))
#define QP_MAX (51+QP_BD_OFFSET)

[Selur]

Thanks :)

[Sagekilla]

Dark, theoretically if you used 16-bit precision internally, would that be twice as slow assuming you had assembly optimizations (For encoder / decoder)?

tbh, the most natural extension would be to go up to 16-bit at some point since that would be the next power of two as well as all the advantages that go with it.

[Dark Shikari]

Dark, theoretically if you used 16-bit precision internally, would that be twice as slow assuming you had assembly optimizations (For encoder / decoder)?

tbh, the most natural extension would be to go up to 16-bit at some point since that would be the next power of two as well as all the advantages that go with it.16-bit would be slower than 10-bit. 10-bit lets you actually avoid extending precision in some places -- for example, going from 8-bit to 10-bit in the hpel filter is basically free once the asm is written. But going beyond that requires 32-bit internal precision.

[D3C0D3R]

Hi everyone. so i've done testing with MSU VQMT and DivX d3c0d3r. As avs filter SSIM give me weird and very strange results i tried MSU VQMT. at first even loseless compression gived me SSIM deep below than 1. It's not simple as sounds,but after 20 minutes i able to overcome all this dificulties and get valid SSIM (SSIM precise in MSU VQMT and opening with RGB24 color)

So here results:

ffdShow d3c0d3r

8bit AVG: 0.98903
9bit AVG: 0.98704
10bit AVG: 0.98601
1649 rev AVG: 0.98903

DivX H.264 d3c0d3r 8.2.0.26

8bit AVG: 0.98870 - 88,49557
9bit AVG: 0.98858 - 87,56567
10 bit AVG: 0.98855 - 87,33624
1649 AVG: 0.98870 - 88,49557

At first ffdShow better than DivX at 8-bit this is obvious ))
But why 9 and 10 bit worse than 8 bit i cant explain...
I recheck it twice and I'm really confused....

P.S. used rack04 evil build's and 1649 rev from x264.nl
here x264 logs

C:\SIMPSONS\Season_34\test>C:\SIMPSONS\Season_34\test\8b.bat

C:\SIMPSONS\Season_34\test>x264_8 --crf 22.2 --keyint 300 --min-keyint 25 --scen
ecut 70 --no-fast-pskip --bframes 6 --b-adapt 2 --b-pyramid normal --weightb --r
ef 16 --deblock 1:1 --rc-lookahead 100 --trellis 1 --psy-rd 0.0:0.0 --partition
s p8x8,b8x8,i4x4,i8x8 --direct auto --merange 16 --qpmin 9 --qpmax 51 --qpstep 5
--me umh --subme 9 --8x8dct --ipratio 1.41 --pbratio 1.33 --chroma-qp-offset 2
--aq-mode 2 --qcomp 0.55 --aq-strength 0.7 --weightp 2 --ssim --psnr --threads
1 --output "4_8_bit.mkv" "4.avs"
avs [warning]: converting input clip to YV12avs [info]: 480x360p 0:0 @ 25/1 fps
(cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:13 Avg QP:21.33 size: 13438 PSNR Mean Y:49.54 U:49.25
V:50.10 Avg:49.56 Global:45.35
x264 [info]: frame P:257 Avg QP:23.83 size: 4432 PSNR Mean Y:42.62 U:43.12
V:44.43 Avg:42.94 Global:42.66
x264 [info]: frame B:631 Avg QP:29.17 size: 1202 PSNR Mean Y:41.56 U:42.67
V:44.07 Avg:42.05 Global:41.76
x264 [info]: consecutive B-frames: 4.2% 6.3% 15.5% 42.8% 19.1% 8.1% 3.9%
x264 [info]: mb I I16..4: 36.7% 22.5% 40.9%
x264 [info]: mb P I16..4: 8.8% 5.5% 5.0% P16..4: 38.7% 13.6% 7.2% 0.0% 0
.0% skip:21.2%
x264 [info]: mb B I16..4: 0.8% 0.7% 0.9% B16..8: 26.4% 5.4% 1.4% direct:
1.1% skip:63.3% L0:49.5% L1:45.9% BI: 4.6%
x264 [info]: 8x8 transform intra:27.5% inter:63.6%
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: coded y,uvDC,uvAC intra: 41.5% 60.4% 34.4% inter: 10.9% 11.1% 1.2%
x264 [info]: i16 v,h,dc,p: 39% 39% 13% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 13% 43% 4% 3% 4% 3% 6% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 25% 20% 5% 5% 5% 6% 5% 7%
x264 [info]: i8c dc,h,v,p: 25% 40% 25% 9%
x264 [info]: Weighted P-Frames: Y:5.1%
x264 [info]: ref P L0: 47.2% 14.3% 14.5% 4.7% 3.3% 2.7% 2.2% 1.7% 1.1% 1.
2% 1.1% 2.2% 1.3% 1.0% 0.9% 0.7%
x264 [info]: ref B L0: 75.4% 8.8% 4.2% 2.1% 1.3% 1.2% 1.0% 0.9% 0.6% 0.
5% 0.6% 1.9% 0.7% 0.4% 0.3%
x264 [info]: ref B L1: 93.4% 6.6%
x264 [info]: SSIM Mean Y:0.9879904 (19.205db)
x264 [info]: PSNR Mean Y:41.979 U:42.894 V:44.260 Avg:42.415 Global:42.034 kb/s:
459.97

encoded 901 frames, 12.76 fps, 460.13 kb/s

C:\SIMPSONS\Season_34\test>C:\SIMPSONS\Season_34\test\9b.bat

C:\SIMPSONS\Season_34\test>x264_9 --crf 28.2 --keyint 300 --min-keyint 25 --scen
ecut 70 --no-fast-pskip --bframes 6 --b-adapt 2 --b-pyramid normal --weightb --r
ef 16 --deblock 1:1 --rc-lookahead 100 --trellis 1 --psy-rd 0.0:0.0 --partition
s p8x8,b8x8,i4x4,i8x8 --direct auto --merange 16 --qpmin 10 --qpmax 57 --qpstep
5 --me umh --subme 9 --8x8dct --ipratio 1.41 --pbratio 1.33 --chroma-qp-offset
2 --aq-mode 2 --qcomp 0.55 --aq-strength 0.7 --weightp 2 --ssim --psnr --threads
1 --output "4_9bit_qpstep=5.mkv" "4.avs"
avs [warning]: converting input clip to YV12avs [info]: 480x360p 0:0 @ 25/1 fps
(cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High 10, level 3.1, bit depth 9
x264 [info]: frame I:13 Avg QP:27.16 size: 13479 PSNR Mean Y:49.74 U:49.42
V:50.29 Avg:49.75 Global:45.54
x264 [info]: frame P:263 Avg QP:29.72 size: 4341 PSNR Mean Y:42.75 U:43.26
V:44.61 Avg:43.08 Global:42.79
x264 [info]: frame B:625 Avg QP:35.27 size: 1189 PSNR Mean Y:41.70 U:42.83
V:44.29 Avg:42.20 Global:41.90
x264 [info]: consecutive B-frames: 4.8% 5.2% 19.3% 41.0% 19.1% 7.4% 3.2%
x264 [info]: mb I I16..4: 38.1% 21.2% 40.7%
x264 [info]: mb P I16..4: 9.3% 4.9% 4.7% P16..4: 38.2% 13.3% 7.1% 0.0% 0
.0% skip:22.5%
x264 [info]: mb B I16..4: 0.8% 0.7% 0.9% B16..8: 25.4% 5.3% 1.3% direct:
1.1% skip:64.5% L0:48.6% L1:46.5% BI: 4.9%
x264 [info]: 8x8 transform intra:25.4% inter:63.7%
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: coded y,uvDC,uvAC intra: 40.0% 59.4% 34.1% inter: 11.0% 10.9% 1.2%
x264 [info]: i16 v,h,dc,p: 37% 38% 14% 12%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 12% 42% 4% 3% 4% 3% 6% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 25% 20% 5% 6% 5% 6% 5% 7%
x264 [info]: i8c dc,h,v,p: 26% 39% 24% 10%
x264 [info]: Weighted P-Frames: Y:3.8%
x264 [info]: ref P L0: 46.8% 14.3% 15.1% 4.3% 3.3% 2.8% 2.3% 1.6% 1.1% 1.
1% 1.0% 1.9% 1.2% 1.3% 0.9% 0.9%
x264 [info]: ref B L0: 75.1% 9.1% 4.2% 2.0% 1.3% 1.3% 1.0% 1.0% 0.5% 0.
5% 0.5% 1.6% 0.9% 0.8% 0.3%
x264 [info]: ref B L1: 93.1% 6.9%
x264 [info]: SSIM Mean Y:0.9888604 (19.531db)
x264 [info]: PSNR Mean Y:42.121 U:43.050 V:44.473 Avg:42.566 Global:42.177 kb/s:
457.24

encoded 901 frames, 2.34 fps, 457.39 kb/s

C:\SIMPSONS\Season_34\test>C:\SIMPSONS\Season_34\test\10b.bat

C:\SIMPSONS\Season_34\test>x264_10 --crf 34.0 --keyint 300 --min-keyint 25 --sce
necut 70 --no-fast-pskip --bframes 6 --b-adapt 2 --b-pyramid normal --weightb --
ref 16 --deblock 1:1 --rc-lookahead 100 --trellis 1 --psy-rd 0.0:0.0 --partitio
ns p8x8,b8x8,i4x4,i8x8 --direct auto --merange 16 --qpmin 11 --qpmax 63 --qpstep
6 --me umh --subme 9 --8x8dct --ipratio 1.41 --pbratio 1.33 --chroma-qp-offset
2 --aq-mode 2 --qcomp 0.55 --aq-strength 0.7 --weightp 2 --ssim --psnr --thread
s 1 --output "4_10.mkv" "4.avs"
avs [warning]: converting input clip to YV12avs [info]: 480x360p 0:0 @ 25/1 fps
(cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High 10, level 3.1, bit depth 10
x264 [info]: frame I:13 Avg QP:32.91 size: 13577 PSNR Mean Y:48.60 U:49.59
V:50.42 Avg:48.74 Global:45.69
x264 [info]: frame P:254 Avg QP:35.64 size: 4412 PSNR Mean Y:42.77 U:43.30
V:44.68 Avg:43.11 Global:42.83
x264 [info]: frame B:634 Avg QP:41.06 size: 1204 PSNR Mean Y:41.76 U:42.90
V:44.36 Avg:42.26 Global:41.98
x264 [info]: consecutive B-frames: 3.8% 5.4% 18.2% 41.4% 16.3% 10.8% 3.9%
x264 [info]: mb I I16..4: 38.5% 21.2% 40.3%
x264 [info]: mb P I16..4: 9.8% 5.0% 5.1% P16..4: 37.8% 13.3% 6.9% 0.0% 0
.0% skip:22.1%
x264 [info]: mb B I16..4: 0.8% 0.6% 0.9% B16..8: 25.4% 5.4% 1.4% direct:
1.1% skip:64.4% L0:48.2% L1:46.6% BI: 5.2%
x264 [info]: 8x8 transform intra:25.0% inter:63.5%
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: coded y,uvDC,uvAC intra: 40.5% 60.2% 34.5% inter: 11.1% 10.8% 1.2%
x264 [info]: i16 v,h,dc,p: 35% 38% 13% 13%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 12% 42% 4% 3% 4% 4% 6% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 24% 21% 5% 5% 5% 6% 5% 7%
x264 [info]: i8c dc,h,v,p: 26% 39% 25% 10%
x264 [info]: Weighted P-Frames: Y:2.0%
x264 [info]: ref P L0: 46.3% 15.7% 14.0% 4.0% 3.4% 2.8% 2.2% 1.6% 1.3% 1.
1% 0.9% 2.5% 1.1% 1.6% 0.8% 0.6%
x264 [info]: ref B L0: 75.5% 9.1% 3.8% 2.1% 1.2% 1.3% 1.0% 0.9% 0.5% 0.
5% 0.5% 2.1% 0.4% 0.9% 0.2%
x264 [info]: ref B L1: 93.3% 6.7%
x264 [info]: SSIM Mean Y:0.9892742 (19.696db)
x264 [info]: PSNR Mean Y:42.142 U:43.109 V:44.535 Avg:42.594 Global:42.242 kb/s:
457.33

encoded 901 frames, 2.14 fps, 457.49 kb/s

C:\SIMPSONS\Season_34\test>C:\SIMPSONS\Season_34\test\1649.bat

C:\SIMPSONS\Season_34\test>x264_1649 --crf 22.2 --keyint 300 --min-keyint 25 --s
cenecut 70 --no-fast-pskip --bframes 6 --b-adapt 2 --b-pyramid normal --weightb
--ref 16 --deblock 1:1 --rc-lookahead 100 --trellis 1 --psy-rd 0.0:0.0 --partit
ions p8x8,b8x8,i4x4,i8x8 --direct auto --merange 16 --qpmin 9 --qpmax 51 --qpste
p 5 --me umh --subme 9 --8x8dct --ipratio 1.41 --pbratio 1.33 --chroma-qp-offse
t 2 --aq-mode 2 --qcomp 0.55 --aq-strength 0.7 --weightp 2 --ssim --psnr --threa
ds 1 --output "4_1649.mkv" "4.avs"
avs [warning]: converting input clip to YV12
avs [info]: 480x360p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:13 Avg QP:21.33 size: 13439 PSNR Mean Y:49.53 U:49.25
V:50.10 Avg:49.55 Global:45.35
x264 [info]: frame P:257 Avg QP:23.84 size: 4436 PSNR Mean Y:42.62 U:43.13
V:44.42 Avg:42.94 Global:42.66
x264 [info]: frame B:631 Avg QP:29.17 size: 1202 PSNR Mean Y:41.57 U:42.68
V:44.07 Avg:42.06 Global:41.76
x264 [info]: consecutive B-frames: 4.2% 6.3% 15.5% 42.8% 19.1% 8.1% 3.9%
x264 [info]: mb I I16..4: 36.7% 22.3% 40.9%
x264 [info]: mb P I16..4: 8.7% 5.6% 5.0% P16..4: 38.7% 13.6% 7.2% 0.0% 0
.0% skip:21.2%
x264 [info]: mb B I16..4: 0.8% 0.7% 1.0% B16..8: 26.4% 5.3% 1.4% direct:
1.1% skip:63.4% L0:49.6% L1:45.7% BI: 4.7%
x264 [info]: 8x8 transform intra:27.7% inter:63.7%
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: coded y,uvDC,uvAC intra: 41.5% 60.5% 34.4% inter: 10.9% 11.0% 1.2%
x264 [info]: i16 v,h,dc,p: 39% 39% 13% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 12% 44% 4% 3% 4% 3% 5% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 25% 20% 5% 6% 5% 6% 5% 7%
x264 [info]: i8c dc,h,v,p: 25% 40% 25% 9%
x264 [info]: Weighted P-Frames: Y:5.1%
x264 [info]: ref P L0: 47.1% 14.3% 14.5% 4.8% 3.3% 2.7% 2.1% 1.7% 1.1% 1.
1% 1.1% 2.2% 1.2% 0.9% 1.0% 0.7%
x264 [info]: ref B L0: 75.4% 8.9% 4.1% 2.1% 1.3% 1.2% 1.0% 1.0% 0.6% 0.
5% 0.6% 1.9% 0.7% 0.4% 0.2%
x264 [info]: ref B L1: 93.3% 6.7%
x264 [info]: SSIM Mean Y:0.9879807 (19.201db)
x264 [info]: PSNR Mean Y:41.981 U:42.899 V:44.259 Avg:42.417 Global:42.037 kb/s:
460.26

encoded 901 frames, 12.05 fps, 460.41 kb/s

[nm]

At first ffdShow better than DivX at 8-bit this is obvious ))

They should be the same, so you have a problem somewhere. Maybe colorspace conversions...

But why 9 and 10 bit worse than 8 bit i cant explain...

Because your decoder doesn't handle 9/10 bit video properly:

FFDshow only supports 8-bit. It working with over 8-bit is mere coincidence -- it only seemed to work because it just happened that all of your pixels fit in 8-bit.

[D3C0D3R]

Maybe colorspace conversions...
no... i used rgb24 and got SSIM=1 for x264 loseless and 1649 with 8-bit :evil: build show same results
maybe DivX does some additional post-processing (like blur) and therefore SSIM is slightly lower.
I check all settings like brightness, contrast etc and set them to 0 and off course turned off all filtering in ffdShow.

Because your decoder doesn't handle 9/10 bit video properly:
i sayed early in this thread - DivX d3c0d3r supports High 10, as you can see ffdShow has big difference between 8,9,10 and DivX - very small about 1%, but i cant understood why [8 bit] has better SSIM.

meanwhile i tested without DivX deblocking here results.

in attach - archive with cvs by MSU VQMT

DivX H264 d3c0d3r deblocking:0ff
1649 AVG: 0.98377
8bit AVG: 0.98367
9bit AVG: 0.98382
10bit AVG: 0.98398

this results is much more sane, but I'm still confused
strange difference between 1649[8bit] and 1666 [8bit] :confused:

[nm]

no... i used rgb24 and got SSIM=1 for x264 loseless and 1649 with 8-bit :evil: build show same results

So what colorspace did you use and how did you convert the output from ffdshow and DivX to that?

maybe DivX does some additional post-processing (like blur) and therefore SSIM is slightly lower.

I don't think so.

meanwhile i tested without DivX deblocking here results.

in attach - archive with cvs by MSU VQMT

this results is much more sane, but I'm still confused

Comparing with in-loop deblocking disabled in the decoder is not sane because it will corrupt the output unpredictably. You can't draw any conclusions from those results.

[D3C0D3R]

So what colorspace did you use and how did you convert the output from ffdshow and DivX to that?
i describe and upload attachment
http://forum.doom9.org/attachment.php?attachmentid=11252&d=1279004493

I don't think so.
this is usual practice smooth images to get higher PSNR, thats why i done test without deblocking - maybe this can help avoid this unwanted postprocessing


Comparing with in-loop deblocking disabled in the decoder is not sane because it will corrupt the output unpredictably.

i know, this is additional test - and it has interesting results
and bit-depth can have some influence on deblocking.

[nurbs]

What's interesting about the SSIM of the not properly decoded video being lower than the one decoded correctly?

[nm]

i describe and upload attachment
http://forum.doom9.org/attachment.php?attachmentid=11252&d=1279004493

Attachments may take a long time to get approved and we can't see them before that happens.


this is usual practice smooth images to get higher PSNR

Not in H.264 software decoders.