[HD 1080p24 Challenge] MPEG2, VC-1 and H264 with real uncompressed source [Archive] - Page 3

Sagittaire

7th August 2007, 19:45

I don't understand why the VBV buffer is a problem for HD MPEG2.
This clip is 1920*1080, average bitrate: 18000, max bitrate: 28000 and a buffer of 9781 Kbits.
Let's scale it down to DVD-SD 720x576 resolution which means only 1/5 of the nr. of Macroblocks.
This yields an average bitrate: 3600, max bitrate 5600 and a buffer of 1956 Kbits.
For DVD-SD an average bitrate of 6000 and max bitrate of 9000 is quite normal with a buffer of 1835 Kbits.

So IMHO the VBV buffer isn't the problem but bitrate is...

The delta for relative complexity scene is really very high for Elephant Dream. At 18 Mbps there are very simple part (quantizer saturation at q1) and really complex part (vbv saturation at q10). It's a very hard source for Rate Control. It's really hard for HCEnc in these complex part to keep good quality: the PSNR for HCEnc is simply very low in these part and produce low OPSNR.

Now comparison between HDDVD and DVD
- average at 6Mbps and max at 8 Mbps for 720*480*24 frame
if there are vbv saturation you can't use buffer and Iframe size are directly limited by max bitrate: 8000000/(720*480*24) = 0.96 bits/pixel for IFrame
- average at 18Mbps and max at 28 Mbps for 1920*1080*24 frame
if there are vbv saturation you can't use buffer and Iframe size are directly limited by max bitrate: 28000000/(1920*1080*24) = 0.56 bits/pixel for IFrame

And in practice HDDVD don't use 28 Mbps for max bitrate (it's a possible scenario but only with 3 DD+ at 640 Kbps for example). If you make HDDVD with PIP and/or trueHD the max bitrate will be at 20 - 24 Mbps. The problem for HDDVD vs BD is not capacity (30 GB is good) but band-width (30.24 Mbps). BD can use MPEG2 with higher band-width at 45 Mbps and capacity is not really the problem.

hank315

7th August 2007, 21:51

if there are vbv saturation you can't use buffer and Iframe size are directly limited by max bitrate: 8000000/(720*480*24) = 0.96 bits/pixel for IFrame
This situation is very rare, mostly you run into VBV trouble after loading the large I-frame, not at the end of a GOP.
Also an encoder should never run into such a situation, it should know it has to handle such an I-frame at the start of a new GOP so in my eyes your example is more a RC/bitrate problem than a VBV problem.
I wanted to point out that it's more likely you will run into VBV problems at DVD-SD resolutions than at HD resolutions because the VBV/bitrate ratio is much worse for DVD-SD.
The buffer size for HD is large enough, only the relative low maximum bitrate may prevent to fill it fast enough.

Sagittaire

8th August 2007, 01:12

This situation is very rare, mostly you run into VBV trouble after loading the large I-frame, not at the end of a GOP.

Well it's the case for HCEnc and all the encoder for this source in really complex part. HCEnc must use very high quantizer to respect the vbv in these complex part.

Also an encoder should never run into such a situation, it should know it has to handle such an I-frame at the start of a new GOP so in my eyes your example is more a RC/bitrate problem than a VBV problem.

well this H264 encoder have this problem for this source (GOP at 14 frames). Libavcodec have this problem too.

H264 encoding at 12 Mbps, max at 24 Mbps
2809 1.6533 +0.0668 37 -38 38.7684 48.5288
2810 1.8734 +0.0755 36 -38 37.8276 48.5122
2811 2.1074 +0.0738 47 -43 36.9203 48.4915
2812 2.3277 +0.0617 44 -45 36.0954 48.4663
2813 2.3589 +0.0705 43 -52 36.0339 48.4409
2814 2.5663 +0.0639 53 -53 35.2827 48.4106
2815 2.6009 +0.0671 50 -50 35.1891 48.3799
2816 2.6380 +0.0578 51 -59 35.0715 48.3485
2817 2.6734 +0.0648 54 -54 34.9776 48.3167
2818 2.4900 +0.0804 49 -50 35.6235 48.2897
2819 2.4826 +0.0919 50 -50 35.6302 48.2629
2820 2.4433 +0.1026 49 -49 35.7463 48.2370
2821 2.2726 +0.1086 44 -44 36.3861 48.2151
2822 2.2432 +0.1087 46 -45 36.4622 48.1936
2823 2.2279 +0.1196 41 -46 36.5156 48.1726
2824 2.2211 +0.1186 43 -47 36.5375 48.1518
2825 2.2214 +0.1280 40 -40 36.5295 48.1310
2826 2.0731 +0.1160 38 -40 37.1995 48.1136
2827 2.1982 +0.1196 42 -41 36.6129 48.0935
2828 2.0714 +0.1200 42 -41 37.2132 48.0762
2829 2.2099 +0.1283 45 -45 36.5766 48.0561
2830 2.0709 +0.1192 38 -38 37.2061 48.0390
2831 2.9655 +0.0514 64 -64 34.0914 48.0027 <- Iframe
2832 2.4976 +0.0801 49 -49 35.6044 47.9776
2833 2.2904 +0.0944 45 -42 36.3462 47.9569
2834 2.2667 +0.0954 49 -42 36.4126 47.9366
2835 2.2310 +0.1075 43 -44 36.5147 47.9170
2836 2.2219 +0.1220 43 -43 36.5280 47.8975
2837 2.2238 +0.1325 53 -53 36.5191 47.8780
2838 2.2259 +0.1298 44 -44 36.5085 47.8586
2839 2.2068 +0.1288 52 -52 36.5622 47.8396
2840 2.2114 +0.1295 43 -45 36.5384 47.8205
2841 2.2121 +0.1353 47 -47 36.5312 47.8015
2842 2.2070 +0.1219 43 -45 36.5618 47.7828
2843 2.2054 +0.1269 41 -43 36.5629 47.7641
2844 2.2074 +0.1250 46 -46 36.5438 47.7455
2845 2.9122 +0.0635 69 -69 34.2024 47.7126 <- Iframe
2846 2.4790 +0.0932 56 -54 35.6329 47.6896
2847 2.2892 +0.1022 44 -58 36.3465 47.6704
2848 2.2697 +0.1131 44 -44 36.4097 47.6516
2849 2.2609 +0.1154 43 -43 36.4440 47.6330
2850 2.2521 +0.1191 45 -43 36.4518 47.6146
2851 2.2488 +0.1335 46 -46 36.4714 47.5963
2852 2.2642 +0.1307 47 -47 36.4313 47.5780
2853 2.2554 +0.1303 44 -44 36.4677 47.5599
2854 2.2477 +0.1266 49 -46 36.4789 47.5419
2855 2.2355 +0.1285 46 -46 36.4976 47.5241
2856 2.2429 +0.1292 51 -45 36.4888 47.5064
2857 2.2482 +0.1373 39 -49 36.4906 47.4888
2858 2.2539 +0.1304 46 -46 36.4805 47.4712
2859 2.7649 +0.0622 50 -53 34.7370 47.4443
2860 2.4919 +0.0875 48 -49 35.6332 47.4228
2861 2.3022 +0.0976 40 -42 36.3175 47.4048

Manao

8th August 2007, 11:32

Well it's the case for HCEnc and all the encoder for this source in really complex partDon't make generalisation. It's not because none of the encoders you're using handle correctly the complex parts of the video that it's impossible to do so.

Hank315 is right. An encoder should be able to make big intra frame, and the size of these frames should be restricted by the VBV size, not by the average frame size at the maximum bitrate.

Sagittaire

8th August 2007, 12:27

Don't make generalisation. It's not because none of the encoders you're using handle correctly the complex parts of the video that it's impossible to do so.

In fact I speak about vbv saturation with this source. All the encoder in VBR mode with classic curve compression setting will have difficulty to maintain quality (aka quantizer) in these really complex part.

Hank315 is right. An encoder should be able to make big intra frame, and the size of these frames should be restricted by the VBV size, not by the average frame size at the maximum bitrate.

Well I'am agree with that. But it's in practice not always the case. I think for example there are very high improvement potential for Libavcodec Rate Control.

Inventive Software

9th August 2007, 12:06

That may be the case, but remember libavcodec borrows from several other open-source projects as and when it's needed, so for rate-control, what's best in the OS world?

Sagittaire

10th August 2007, 03:03

The command-line encoder in the PEP package is really more of a test tool (I think it might even be deprecated at this point). The studios are all using the non-cmd-line encoder.

Well now test with pep.exe at 6 Mbps with PP1 forced: 43.33 dB

Minimum Average Maximum

Y: Mean Absolute Deviation: 0.0000 13.5207 5.4359
U: Mean Absolute Deviation: 0.0000 0.8102 1.8150
V: Mean Absolute Deviation: 0.0000 0.8846 1.5686
Sum: Mean Absolute Deviation: 0.0000 25.6513 3.6997

Y: Mean Deviation: -0.9311 0.6090 1.0109
U: Mean Deviation: -0.3636 0.0775 0.5885
V: Mean Deviation: -0.5276 0.0748 0.3277
Sum: Mean Deviation: -0.6207 1.3430 0.6739

Y: Mean Square Error: 0.0000 4.1491 65.0187
U: Mean Square Error: 0.0000 0.6987 6.8956
V: Mean Square Error: 0.0000 0.7902 5.9206
Sum: Mean Square Error: 0.0000 3.0142 43.4682

Y: Root Mean Square Error: 0.0000 1.8002 8.0634
U: Root Mean Square Error: 0.0000 0.7003 2.6259
V: Root Mean Square Error: 0.0000 0.7548 2.4332
Sum: Root Mean Square Error: 0.0000 1.5514 6.5930

Y: PSNR: 30.0004 41.9513 1.#INF
U: PSNR: 39.7451 49.6881 1.#INF
V: PSNR: 40.4072 49.1536 1.#INF
Sum: PSNR: 31.7491 43.3391 1.#INF
Minimum Average Maximum

Mean Absolute Deviation: 0.0000 25.6513 3.6997
Mean Deviation: -0.6207 1.3430 0.6739
PSNR: 31.7491 43.3391 1.#INF

And now result with vc1_enc.exe with PP1 in flag: 43.75 dB

Minimum Average Maximum

Y: Mean Absolute Deviation: 0.0000 12.3687 5.4406
U: Mean Absolute Deviation: 0.0000 0.7497 1.5126
V: Mean Absolute Deviation: 0.0000 0.8131 1.4572
Sum: Mean Absolute Deviation: 0.0000 23.4965 3.6962

Y: Mean Deviation: -1.0000 0.3257 0.6041
U: Mean Deviation: -0.1913 0.0610 0.6475
V: Mean Deviation: -0.4243 0.0506 0.3930
Sum: Mean Deviation: -0.6667 0.7927 0.4057

Y: Mean Square Error: 0.0000 3.8036 67.1990
U: Mean Square Error: 0.0000 0.5776 4.8270
V: Mean Square Error: 0.0000 0.6528 4.0074
Sum: Mean Square Error: 0.0000 2.7408 44.9051

Y: Root Mean Square Error: 0.0000 1.6975 8.1975
U: Root Mean Square Error: 0.0000 0.6459 2.1970
V: Root Mean Square Error: 0.0000 0.6934 2.0019
Sum: Root Mean Square Error: 0.0000 1.4620 6.7011

Y: PSNR: 29.8572 42.3289 1.#INF
U: PSNR: 41.2941 50.5149 1.#INF
V: PSNR: 42.1022 49.9830 1.#INF
Sum: PSNR: 31.6078 43.7521 1.#INF
Minimum Average Maximum

Mean Absolute Deviation: 0.0000 23.4965 3.6962
Mean Deviation: -0.6667 0.7927 0.4057
PSNR: 31.6078 43.7521 1.#INF

And here the xml project for pep.exe:
- default RC and HVS setting from 1080p_HDDVD.PEP.xml template
- Complexity at maxi, Chroma at maxi, bframe at 7

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/DigitalMedia/Codecs/2006/12/01/ParallelEncoderProject">
<ProjectName>Project1</ProjectName>
<PublishedFileURL>C:\Master\Project1.vc1</PublishedFileURL>
<PublishedLogFileURL>C:\Master\Project1.log</PublishedLogFileURL>
<OutputDirectory>C:\Master</OutputDirectory>
<SourceFiles>
<SourceFile>C:\Master\1920x1080.yuv</SourceFile>
</SourceFiles>
<AllowPtoISwitch>true</AllowPtoISwitch>
<AspectRatioIndex>1</AspectRatioIndex>
<BFrames>7</BFrames>
<Bitrate>6000</Bitrate>
<BufferSize>1843200</BufferSize>
<ChromaSearch>full</ChromaSearch>
<ClosedCaptionsPresent>false</ClosedCaptionsPresent>
<ColorFormatFlag>false</ColorFormatFlag>
<Denoise>false</Denoise>
<EncoderComplexity>4</EncoderComplexity>
<EncodingMode>VBR</EncodingMode>
<EncodingHeight>1080</EncodingHeight>
<EncodingWidth>1920</EncodingWidth>
<FrameRate>29.97</FrameRate>
<GOPLength>14</GOPLength>
<GOPType>Open</GOPType>
<Height>1080</Height>
<InterlaceMode>InterlacedTelecine</InterlaceMode>
<LoopFilter>true</LoopFilter>
<MarkIn>0</MarkIn>
<MarkOut>15689</MarkOut>
<MinEncodeQP>1.0</MinEncodeQP>
<MVRange>1</MVRange>
<PeakBitrate>20000</PeakBitrate>
<PDeltaQP>0.0</PDeltaQP>
<PerceptualOptionLevel>3</PerceptualOptionLevel>
<Segments>1</Segments>
<ThreadCount>0</ThreadCount>
<Width>1920</Width>
<BDeltaQP>
<Relative>0.0</Relative>
</BDeltaQP>
<FirstPassSettings>
<ChromaSearch>off</ChromaSearch>
<EncoderComplexity>0</EncoderComplexity>
<MVRange>0</MVRange>
</FirstPassSettings>
<CodecData>
<Property name="BFramePosOpt" type="long" value="1"/>
<Property name="DarkNoiseControl" type="long" value="0"/>
<Property name="DCBias" type="long" value="1"/>
<Property name="DQuantStrength" type="long" value="4"/>
<Property name="FavorInterLevel" type="long" value="3"/>
<Property name="MotionMatch" type="long" value="4"/>
</CodecData>
<UIData>
<RecentPublishedFileURL/>
</UIData>
</Project>

If you want really result from pep then I can use result from pep.
Anyway previous result from vc1_enc.exe with optimized setting are really better for PSNR/SSIM.
If the xml profil is not the best, it's possible to make other encoding with better xml profil.

benwaggoner

10th August 2007, 05:42

@ Sagittaire,

Running your first pass at Complexity 2 with MVRange 1 will give you better rate control that your current settings.

Threadcount 1 would also help a bit in some of the shots with a lot of vertical motion.

And 7 B-Frames? I thought we said that wasn't going to help :)! Well, if you're doing segment reencoding, that might work nicely for the credits, saving you some bits to use on the main feature. But the main sequence should use 1 or 2 B-frames.

Perceptual option in general tunes for visual quality instead of PSNR. In theory, using it could rise SSIM and lower PSNR, but I haven't tested that much with objective measures.

There's probably a few other things, but it's late and my XML translater is tired :).

zambelli

10th August 2007, 10:40

Well now test with pep.exe at 6 Mbps with PP1 forced: 43.33 dB
And now result with vc1_enc.exe with PP1 in flag: 43.75 dB

What do you mean by "in flag"? If you're talking about the bitstream PP flags, they're not useful, WMV9 Decoder DMO doesn't care about them at all. With "in flag" you're probably just using automatic PP.

Also, why PP1? There's no need for post-processing in PSNR/SSIM calculation. CoreAVC decoder isn't doing postprocessing, neither are HD-DVD players, so it's only fair that no PP gets used for VC-1 decoding too.
<BFrames>7</BFrames>
Seriously? You're not setting the maximum there - you're actually telling the encoder to insert 7 B-frames between every reference frame! I'm surprise the PSNR wasn't 20 dB. :)
<MVRange>1</MVRange>
Use adaptive MV range if possible.
<PerceptualOptionLevel>3</PerceptualOptionLevel>
Is this Dquant or Adaptive Dead Zone? I can't remember the mapping of the XML properties off top of my head.
If it's dquant, enable it only for I & P frames, and probably only use it on 12 and 18 Mbps encodes.

<BDeltaQP>
<Relative>0.0</Relative>
</BDeltaQP>

When doing the 12 and 18 Mbps encodes, you can probably set this to 1.0.
<FirstPassSettings>
<MVRange>0</MVRange>
</FirstPassSettings>
I think this should be opposite - use short range in 1st pass and use adaptive in 2nd pass.

If the xml profil is not the best, it's possible to make other encoding with better xml profil.
I'll try to get an optimized version out to you soon.

Golgot13

10th August 2007, 11:05

Hi all,

Ben and Zambelli, thank you to give nice comment about the option of VC1 encoder
(PEP or WM9). Sagitairre try to do the best VC1 encoded file with ED source.
If you not agree with some option => you can, yourself, make a best encoding of this file.

I sure Ben can make the perfect encoding from PEP :cool:

Regards,

Golgot13

Inventive Software

10th August 2007, 11:12

For shits and giggles, I have the uncompressed SD source, cause I'm nearly gone on HD space and can't have the HD source yet. Can VC-1 people (Sagittaire, benwaggoner, zambelli etc) recommend command-lines for the wmcmd.vbs, or a PRX with certain settings? And registry settings if need be. ;)

EDIT: And what in holy terminology is PEP?! :D

GmorG McRoth

10th August 2007, 11:27

EDIT: And what in holy terminology is PEP?! :D

Ether short for "Penis Enlarging Pump", or name of command line VC1 encoder.

CruNcher

10th August 2007, 12:19

So, it looks like the source I could share is right now about 45 minutes of 10-bit 4:2:2 D5 telecined from 35mm. It's stuff we shot ourselves, of a tall ship (Lady Washington) in the Puget Sound. Lots of shots of water, the ship, sailors doing stuff on the ship. So, I'm thinking about doing something like:

10 total minutes
Focusing on the more complex bits, but with a variety to stress rate control.
Matted to 1.85:1
With some fades to/from black and cross dissolves
Some kind of motion graphics opening credits and scrolling credits at the end. I'll keep those short, to have the same ballpark percent of credits as a typical film.

How does that sound? Not like there are any explosions in there, but some good frames with a nice combination of high detail (rigging) and flat gradients (the sky). Some good handheld stuff.

Camera and Lense ? Resolution ?, it sounds good especialy the water scenes a uncompresed screenshot of the scene would be nice to have an idear of how the transfer looks :)

benwaggoner

10th August 2007, 20:19

I think this should be opposite - use short range in 1st pass and use adaptive in 2nd pass.
For this clip, I think we'd actually want to use adaptive for both passes, since there's some pretty high-motion spots.

Encoding with a single thread would also get another slight boost in shots with vertical motion.

benwaggoner

10th August 2007, 21:38

Camera and Lense ? Resolution ?, it sounds good especialy the water scenes a uncompresed screenshot of the scene would be nice to have an idear of how the transfer looks :)
Not sure - I'll be picking up some of the raw source next week.

Sagittaire

11th August 2007, 00:34

What do you mean by "in flag"? If you're talking about the bitstream PP flags, they're not useful, WMV9 Decoder DMO doesn't care about them at all. With "in flag" you're probably just using automatic PP. Also, why PP1? There's no need for post-processing in PSNR/SSIM calculation. CoreAVC decoder isn't doing postprocessing, neither are HD-DVD players, so it's only fair that no PP gets used for VC-1 decoding too.

Well I don't know really the HDDVD specifications for VC1. But if you can set the PP in bitstream flag it's perhaps because hardware decoding will use post-process. Post process for VC1 is perhaps a official decoding way and part of the standard for this codec?
http://forum.doom9.org/showthread.php?p=870488#post870488

Seriously? You're not setting the maximum there - you're actually telling the encoder to insert 7 B-frames between every reference frame! I'm surprise the PSNR wasn't 20 dB. :)

Yes seriousely. Bframe are adaptative here. VC1 will use 7 bframe only if it's usefull. Anyway certainely that for 99% of time vc1 will use 0,1,2 or 3 bframe exactly like the other codec.

Use adaptive MV range if possible.

previous xml pep profil use adaptative MV range.

Is this Dquant or Adaptive Dead Zone? I can't remember the mapping of the XML properties off top of my head.
If it's dquant, enable it only for I & P frames, and probably only use it on 12 and 18 Mbps encodes.

Previous profil for vc1_enc.exe use this setting.

I think this should be opposite - use short range in 1st pass and use adaptive in 2nd pass.

Well don't change anything. First pass generate only stat and frame type for second pass and quant/size prediction. You have better prediction if you use the same setting for the first and second pass. vc1_enc.exe profil use 3 pass only for produce best possible prediction in the last pass.

I'll try to get an optimized version out to you soon.

Well it's useless. If you compare VC1 and H264 for each frame then H264 will produce better result for 99% of the time (or something like that) in this challenge. You can tweak the rate control like you want (with segment reencoding if you want) and with "better" setting (we use the best for PSNR) but it will be impossible for VC1 to obtain a better PSNR than for H264 or even close to H264.

Sagittaire

11th August 2007, 00:50

Running your first pass at Complexity 2 with MVRange 1 will give you better rate control that your current settings.

vc1_enc.exe use complexity at 3 and adaptative range for second pass.

Threadcount 1 would also help a bit in some of the shots with a lot of vertical motion.

Massive paralleling is certainely not good too for quality and Rate Control.

And 7 B-Frames? I thought we said that wasn't going to help :)! Well, if you're doing segment reencoding, that might work nicely for the credits, saving you some bits to use on the main feature. But the main sequence should use 1 or 2 B-frames.

pep can use 7 bframe if the core want use 7 frame. Doesn't change anything for quality anyway. You want 7 bframes in the challenge specification for VC1: profil use 7 bframes.

Perceptual option in general tunes for visual quality instead of PSNR. In theory, using it could rise SSIM and lower PSNR, but I haven't tested that much with objective measures.

Perceptual Option is certainely adaptative quantisation. AQ can reduce PSNR but it's generaly not a massive degradation.

zambelli

11th August 2007, 03:06

Well I don't know really the HDDVD specifications for VC1. But if you can set the PP in bitstream flag it's perhaps because hardware decoding will use post-process. Post process for VC1 is perhaps a official decoding way and part of the standard for this codec?
http://forum.doom9.org/showthread.php?p=870488#post870488
It's in the standard, but it's optional as far as I know. I'm fairly sure HD-DVD doesn't do post-processing.

Yes seriousely. Bframe are adaptative here. VC1 will use 7 bframe only if it's usefull. Anyway certainely that for 99% of time vc1 will use 0,1,2 or 3 bframe exactly like the other codec.
Shouldn't I be telling YOU how the VC-1 encoder works? ;) That sets the default B-frame count to be 7 frames. If you've got access to PEP, you also have access to VC-1 Analyzer so you should be able to see how long the B series are.

You want 7 bframes in the challenge specification for VC1: profil use 7 bframes.
Ben was asking that the B-frame restriction be removed because it's not in the HD-DVD spec. Nobody said 7 B-frames should always be used. And like I said, PEP will use the number of B-frames you specify as the default, even if adaptive B frames are enabled. Adaptive merely means that the encoder might or might not insert B-frames in certain cases despite expected pattern in a GOP. That's a very small percentage of cases though.

first and second pass. vc1_enc.exe profil use 3 pass only for produce best possible prediction in the last pass.
As I mentioned, there's little point to using the 3rd pass - it's not designed to do anything drastically differently than the 2nd pass, like automatically finetune ratecontrol or something.

Well it's useless. If you compare VC1 and H264 for each frame then H264 will produce better result for 99% of the time (or something like that) in this challenge. You can tweak the rate control like you want (with segment reencoding if you want) and with "better" setting (we use the best for PSNR) but it will be impossible for VC1 to obtain a better PSNR than for H264 or even close to H264.
One step at a time. Right now I just want to ensure that we find the settings that yield the best SSIM score we can get for VC-1 encodings. Whether the Microsoft scores are higher or lower than x264 scores is something we can worry about later.

Sagittaire

11th August 2007, 09:45

It's in the standard, but it's optional as far as I know. I'm fairly sure HD-DVD doesn't do post-processing.

Well I don't know. And for me this part is really more important than max bframe number for HDDVD standard. Anyway optional does'nt mean anything. It's yes or no.

Shouldn't I be telling YOU how the VC-1 encoder works? ;) That sets the default B-frame count to be 7 frames. If you've got access to PEP, you also have access to VC-1 Analyzer so you should be able to see how long the B series are.

Well I use simply an OSD function from another directshow filter for scan the Frametype and Framesize.

Ben was asking that the B-frame restriction be removed because it's not in the HD-DVD spec. Nobody said 7 B-frames should always be used. And like I said, PEP will use the number of B-frames you specify as the default, even if adaptive B frames are enabled. Adaptive merely means that the encoder might or might not insert B-frames in certain cases despite expected pattern in a GOP. That's a very small percentage of cases though.

If vc1 work correctly max bframe number with adaptative placement will use bframe only if it's necessary. For example in difficult part with high motion vc1 will not use bframe because use bframe for this particular scenario is less efficient than Pframe. I scan different vc1 stream from HDDVD and for example "Chronicles of Riddick" movie encoding use 7 adaptatives bframes and certainely that all the other vc1 stream from Universal use this setting for bframe.

As I mentioned, there's little point to using the 3rd pass - it's not designed to do anything drastically differently than the 2nd pass, like automatically finetune ratecontrol or something.

Well it's true but we use the best possible vc1 profil for have the best possible OPSNR/SSIM result.

One step at a time. Right now I just want to ensure that we find the settings that yield the best SSIM score we can get for VC-1 encodings. Whether the Microsoft scores are higher or lower than x264 scores is something we can worry about later.

Well VC1 and MPEG4 ASP produce most of the time similar result for metric. And MPEG4 ASP is never able to fight to H264 with metric.

Sagittaire

11th August 2007, 13:58

And other test with setting from benwaggoner. Result is only little better for OPSNR. Anyway result for SSIM is 85.72 and previous vc1_enc.exe profil produce SSIM at 86.41. Like I always say vc1_enc.exe produce exactly the same result for quality than pep.exe. Use pep.exe don't change anything and use vc1_enc.exe is really more simple for make test. The initial profil for vc1_enc.exe is IMO the best for produce the highest OPSNR/SSIM result.

Well now test with pep.exe at 6 Mbps with PP0: 44.10 dB for OPSNR and 85.72 for SSIM

Minimum Average Maximum

Y: Mean Absolute Deviation: 0.0000 13.1763 4.5640
U: Mean Absolute Deviation: 0.0000 0.7642 1.7663
V: Mean Absolute Deviation: 0.0000 0.8234 1.6109
Sum: Mean Absolute Deviation: 0.0000 24.8400 3.1151

Y: Mean Deviation: -1.0000 -0.5879 0.6439
U: Mean Deviation: -0.3941 0.0236 0.6183
V: Mean Deviation: -0.4885 0.0192 0.5467
Sum: Mean Deviation: -0.6667 -0.8277 0.3945

Y: Mean Square Error: 0.0000 3.4889 43.9233
U: Mean Square Error: 0.0000 0.5766 6.1960
V: Mean Square Error: 0.0000 0.6391 4.7024
Sum: Mean Square Error: 0.0000 2.5286 29.4009

Y: Root Mean Square Error: 0.0000 1.5742 6.6275
U: Root Mean Square Error: 0.0000 0.6369 2.4892
V: Root Mean Square Error: 0.0000 0.6793 2.1685
Sum: Root Mean Square Error: 0.0000 1.3636 5.4223

Y: PSNR: 31.7039 42.7039 1.#INF
U: PSNR: 40.2097 50.5222 1.#INF
V: PSNR: 41.4076 50.0752 1.#INF
Sum: PSNR: 33.4472 44.1020 1.#INF
Minimum Average Maximum

Mean Absolute Deviation: 0.0000 24.8400 3.1151
Mean Deviation: -0.6667 -0.8277 0.3945
PSNR: 33.4472 44.1020 1.#INF

And now result with vc1_enc.exe with PP1 in flag: 43.75 dB for OPSNR and 86.41 for SSIM

Minimum Average Maximum

Y: Mean Absolute Deviation: 0.0000 12.3687 5.4406
U: Mean Absolute Deviation: 0.0000 0.7497 1.5126
V: Mean Absolute Deviation: 0.0000 0.8131 1.4572
Sum: Mean Absolute Deviation: 0.0000 23.4965 3.6962

Y: Mean Deviation: -1.0000 0.3257 0.6041
U: Mean Deviation: -0.1913 0.0610 0.6475
V: Mean Deviation: -0.4243 0.0506 0.3930
Sum: Mean Deviation: -0.6667 0.7927 0.4057

Y: Mean Square Error: 0.0000 3.8036 67.1990
U: Mean Square Error: 0.0000 0.5776 4.8270
V: Mean Square Error: 0.0000 0.6528 4.0074
Sum: Mean Square Error: 0.0000 2.7408 44.9051

Y: Root Mean Square Error: 0.0000 1.6975 8.1975
U: Root Mean Square Error: 0.0000 0.6459 2.1970
V: Root Mean Square Error: 0.0000 0.6934 2.0019
Sum: Root Mean Square Error: 0.0000 1.4620 6.7011

Y: PSNR: 29.8572 42.3289 1.#INF
U: PSNR: 41.2941 50.5149 1.#INF
V: PSNR: 42.1022 49.9830 1.#INF
Sum: PSNR: 31.6078 43.7521 1.#INF
Minimum Average Maximum

Mean Absolute Deviation: 0.0000 23.4965 3.6962
Mean Deviation: -0.6667 0.7927 0.4057
PSNR: 31.6078 43.7521 1.#INF

And here the xml project for pep.exe:
- All HVS setting desactived for produce best PSNR.
- 1 thread for the encoding (curious way for P.E.P., isn't it?)
- Complexity at maxi, Chroma at maxi, bframe at 2.

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/DigitalMedia/Codecs/2006/12/01/ParallelEncoderProject">
<ProjectName>Project1</ProjectName>
<PublishedFileURL>C:\Master\Project1.vc1</PublishedFileURL>
<PublishedLogFileURL>C:\Master\Project1.log</PublishedLogFileURL>
<OutputDirectory>C:\Master</OutputDirectory>
<SourceFiles>
<SourceFile>C:\Master\1920x1080.yuv</SourceFile>
</SourceFiles>
<AllowPtoISwitch>true</AllowPtoISwitch>
<AspectRatioIndex>1</AspectRatioIndex>
<BFrames>2</BFrames>
<Bitrate>6000</Bitrate>
<BufferSize>1843200</BufferSize>
<ChromaSearch>full</ChromaSearch>
<ClosedCaptionsPresent>false</ClosedCaptionsPresent>
<ColorFormatFlag>false</ColorFormatFlag>
<Denoise>false</Denoise>
<EncoderComplexity>4</EncoderComplexity>
<EncodingMode>VBR</EncodingMode>
<EncodingHeight>1080</EncodingHeight>
<EncodingWidth>1920</EncodingWidth>
<FrameRate>29.97</FrameRate>
<GOPLength>14</GOPLength>
<GOPType>Open</GOPType>
<Height>1080</Height>
<InterlaceMode>InterlacedTelecine</InterlaceMode>
<LoopFilter>true</LoopFilter>
<MarkIn>0</MarkIn>
<MarkOut>15689</MarkOut>
<MinEncodeQP>1.0</MinEncodeQP>
<MVRange>1</MVRange>
<PeakBitrate>20000</PeakBitrate>
<PDeltaQP>0.0</PDeltaQP>
<PerceptualOptionLevel>0</PerceptualOptionLevel>
<Segments>1</Segments>
<ThreadCount>1</ThreadCount>
<Width>1920</Width>
<BDeltaQP>
<Relative>0.0</Relative>
</BDeltaQP>
<FirstPassSettings>
<ChromaSearch>off</ChromaSearch>
<EncoderComplexity>2</EncoderComplexity>
<MVRange>1</MVRange>
</FirstPassSettings>
<CodecData>
<Property name="BFramePosOpt" type="long" value="1"/>
<Property name="DarkNoiseControl" type="long" value="0"/>
<Property name="DCBias" type="long" value="1"/>
<Property name="DQuantStrength" type="long" value="0"/>
<Property name="FavorInterLevel" type="long" value="3"/>
<Property name="MotionMatch" type="long" value="4"/>
</CodecData>
<UIData>
<RecentPublishedFileURL/>
</UIData>
</Project>

Golgot13

11th August 2007, 14:46

Well now test with pep.exe at 6 Mbps

Hi Sagitaire,

You will do the 12Mbps encoding too ?

Sagittaire

11th August 2007, 14:55

Hi Sagitaire,

You will do the 12Mbps encoding too ?

No simply because pep.exe can't produce better result than vc1_enc.exe (in 2 pass). But really simple for me to obtain these encoding en make test. I have better human/material resource than MS ... lol

Golgot13

11th August 2007, 15:17

I have better human/material resource than MS ... lol

No, you are wrong, this challenge prouve nothing because it is not same workflow than us on HD DVD title.....
And because it can prouve that H264 have a better "Visual Quality", with or without grain (see other thread).....

But if this challenge can prouve something good about VC1, I think we could see the resource power of MS...

All companies on SMPTE or ITU or EBU use the metric to compare the quality of some codecs or standards
but I surprise that some company don't want to accept this metric when it's bad for themself...

Sagittaire

11th August 2007, 15:23

All companies on SMPTE or ITU or EBU use the metric to compare the quality of some codecs or standards
but I surprise that some company don't want to accept this metric when it's bad for themself...

http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs

"In Microsoft's own internal tests, VC-1 performs 2 to 3 times better than MPEG-2. In other words, to achieve a given PSNR, MPEG-2 requires a bit rate up to 3 times higher than VC-1. These results were measured using both low-motion and high-motion video sequences. Microsoft also compared VC-1 with H.264 and found that both codecs have comparable performance when PSNR is plotted against bit rate."

Sagittaire

11th August 2007, 21:34

Annexe - Update

11.08.2007 - All the H264 streams are availables
05.08.2007 - Max adaptative bframe at 7 for VC1, H264 and MPEG2
04.08.2007 - Unlimited range vector for VC1
03.08.2007 - Encoding with libavcodec at 18 Mbps
02.08.2007 - Max adaptative bframe at 7 for VC1
01.08.2007 - Complete Test with x264, pep and libavcodec

will coming ... if you want ... !!!
All the developpers are wellcome ... !!?

vsv

12th August 2007, 15:19

http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs

"In Microsoft's own internal tests, VC-1 performs 2 to 3 times better than MPEG-2..."

May be 20-30% better?

Sagittaire

12th August 2007, 15:27

May be 20-30% better?

Manao say that there are 25% between MPEG2 and MPEG4 ASP for efficiency. VC1 and ASP produce similar result for metric.

Dark Shikari

12th August 2007, 16:00

May be 20-30% better?
It probably depends on the bitrate.

At low bitrates, WMV destroys MPEG-4 ASP, and H.264 destroys WMV just as much.

At high bitrates they all just start to converge.

vsv

12th August 2007, 17:07

It probably depends on the bitrate.

Yes, i agree. Difference at 10Mbps possible 30% but at 20Mbps very small. At 25-30Mbps no matter what codec. Any good mpeg2 encoder with quality source able to do nice picture.
For 3xDVD (HDDVD9) i prefer h264 (free x264 or non expensive mainconcept encoder) to encode at abr 6-8Mbps.
VC1 may be good with tools for handmade polishing.
VC1 as codec without eyes and hands of Compressionists and able to do segment (within frame and between frames) reencoding can not be better than h264.

zambelli

13th August 2007, 01:24

I don't understand why you're being stubborn about the suggestions I'm giving you. I'm giving your first-hand information but for some reason you're choosing to trust other sources. :confused:

Well I don't know. And for me this part is really more important than max bframe number for HDDVD standard. Anyway optional does'nt mean anything. It's yes or no.
Fine. The answer is NO then: no post-processing is done on VC-1 video in HD-DVD decoding.
Well I use simply an OSD function from another directshow filter for scan the Frametype and Framesize.
Like I said: if you've already got access to PEP, try using VC-1 Analyzer/Viewer tool that comes with it. That's what it's for.

If vc1 work correctly max bframe number with adaptative placement will use bframe only if it's necessary.
Correctly? What's correct? The VC-1 specification doesn't define how one should implement B-frame encoding, so how can there be a correct way?
I scan different vc1 stream from HDDVD and for example "Chronicles of Riddick" movie encoding use 7 adaptatives bframes and certainely that all the other vc1 stream from Universal use this setting for bframe.
The studios are NOT encoding with PEP set to use 7 B-frames. This is just not happening.
Well it's true but we use the best possible vc1 profil for have the best possible OPSNR/SSIM result.
What does that mean? Why would you do it anyway if I said it won't make a difference?
Well VC1 and MPEG4 ASP produce most of the time similar result for metric. And MPEG4 ASP is never able to fight to H264 with metric.
In the interest of keeping this comparison authorative, I would highly recommend also doing A/B/C frame comparisons in Avisynth and posting links to PNG-compressed screen captures. As long as you're only relying on PSNR and SSIM, there will always be people (from all sides) arguing that PSNR/SSIM aren't representative enough of human perception. I say this not because I think it would favor one codec or another (I haven't even done the comparisons myself yet), but because I think it would make the comparison more valuable.

Trahald

13th August 2007, 05:57

Unfortunaly there are a bug from nah_hrd flag for trahald patch. StreamEyes show big overflow. Anyway I think that it's just HRD flags problem and stream is certainely internaly HDDVD compliant. Anyway no doubt that your build obtain better SSIM than my build.Sorry late to thread. Issue was fixed (before i knew it was broken) in patch 'g'
Yes, the reason the HRD patch isn't applied is that it doesn't attempt to generate the right numbers, it just fills in the HRD fields with something. And I don't know how to compute the right numbers either, so I can't fix it.The values in the patch are thought out values (ie based on info available in any available papers) although some are best interpretations as some settings are not 100% clear from documents. Also based on reviewing pro streams. No generic values are used.
The updated patch has generated streams that do not overflow. (for testing i even allowed for tiny buffers and x264s existing rate control kept things in check) Having said that, the patch would still have to be labeled alpha until clearer specs come out or it ages out (ie its success over time outways the fact the settings arent verified)

Now back to the challenge... :)

Trahald

13th August 2007, 06:00

Sagittaire, you may already be aware of this but streameye tools also support vc1 ie for checking gop pattern

Sagittaire

13th August 2007, 10:44

I don't understand why you're being stubborn about the suggestions I'm giving you. I'm giving your first-hand information but for some reason you're choosing to trust other sources. :confused:

Well I use all your suggested setting and profil for this test.
http://forum.doom9.org/showthread.php?p=1032840#post1032840

Anyway you don't have human/material ressource for make this little encoding (10 min). I can make that for you if you post your complete xml profil with your ideal setting. Time for make that is just 10 min ... no more.

Fine. The answer is NO then: no post-processing is done on VC-1 video in HD-DVD decoding.

Really bad for visual quality at low bitrate. Really bad for SSIM too. I will make all the encoding with your suggested setting and profil with pep.exe exactly like you want but the result will be not better ...

Correctly? What's correct? The VC-1 specification doesn't define how one should implement B-frame encoding, so how can there be a correct way?

The best way for choose frame placement is evaluate each situation. Bframe are not alway the best efficient way and by far. For example Livavcodec use RDO for the bframe placement (really really slow) and never use bframe in large zone for Elephant Dream movie. x264 use really good and faster process for frame placement (not for the fade anyway) and if you choose 3 bframes or 1000 bframes with x264 the result will be in practice the same. For example with bframe at 3 for ED x264 use the same bframe number than Pframe number. If I understand correctly VC1 use always the default max possible bframe number and bframes are just adaptative for fade and flash part. It's really curious way for adaptative bframe.

The studios are NOT encoding with PEP set to use 7 B-frames. This is just not happening.

Well perhaps only for credit with segment encoding. I scan 7 bframes for black frame in Riddick vc1 stream.

In the interest of keeping this comparison authorative, I would highly recommend also doing A/B/C frame comparisons in Avisynth and posting links to PNG-compressed screen captures. As long as you're only relying on PSNR and SSIM, there will always be people (from all sides) arguing that PSNR/SSIM aren't representative enough of human perception. I say this not because I think it would favor one codec or another (I haven't even done the comparisons myself yet), but because I think it would make the comparison more valuable.

Well this test is just metric comparison and not visual comparison. I don't say "H264 is better visually than VC1". I just say "here for this source H264 is better that VC1". It's an objective test and by definition you can't contradict that (make encoding if you want ... it's a challenge). And MS use PSNR too:
http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs

One useful objective metric is the peak signal-to-noise ratio (PSNR) plotted against bit rate. PSNR is the ratio between the maximum value of a signal (255 for 8-bit video) and the quantization noise. A higher PSNR indicates a less noisy signal. For any codec, PSNR is expected to increase at higher bit rates, because higher bit rates translate to less aggressive compression. Thus, a graph that plots PSNR against bit rate shows the performance of the codec over a range of compression settings.

In Microsoft's own internal tests, VC-1 performs 2 to 3 times better than MPEG-2. In other words, to achieve a given PSNR, MPEG-2 requires a bit rate up to 3 times higher than VC-1. These results were measured using both low-motion and high-motion video sequences. Microsoft also compared VC-1 with H.264 and found that both codecs have comparable performance when PSNR is plotted against bit rate.

And it's false for this source and certainely for many other simply because MPEG-2 never requires a bit rate up to 3 times higher than VC-1 to achieve a given PSNR.

Inventive Software

13th August 2007, 11:12

I can see this thread turning into a "Push all evidence against VC-1" thread. Makes for good reading though. ;)

@zambelli, benwaggoner: How good are the encoders that either WMcmd.vbs or WME use? Are they due for an update any time soon?

Sagittaire

13th August 2007, 11:30

I can see this thread turning into a "Push all evidence against VC-1" thread. Makes for good reading though. ;)

No ... It's really simple to contradict my result. MS can make the encoding.

1. I use encoding from vc1_enc.exe for result
2. MS say that this tool don't produce good result

3. I use encoding from pep.exe for the result (without better result)
4. MS say that there are not the "good" setting

5. I use encoding from pep.exe with "good" setting for the result (without better result)
6. MS say that it's not the "good" source for make test.

http://on10.net/Blogs/benwagg/elephants-dream-720p--2-mbps/

Inventive Software

13th August 2007, 11:32

TBF to all parties though, you have a source, you need the codec to adapt and encode the source as best as possible.

Why not just use the WMcmd.vbs?

Sagittaire

13th August 2007, 11:38

TBF to all parties though, you have a source, you need the codec to adapt and encode the source as best as possible.

Why not just use the WMcmd.vbs?

Simply because WMcmd.vbs can't produce HDDVD/BD compliant stream. Moreover WMcmd.vbs don't produce better result than pep.exe simply because the core is less advanced (big problem for fade with WMcmd.vbs stream).

CruNcher

13th August 2007, 16:26

Simply because WMcmd.vbs can't produce HDDVD/BD compliant stream. Moreover WMcmd.vbs don't produce better result than pep.exe simply because the core is less advanced (big problem for fade with WMcmd.vbs stream).

in wich terms RateControll ? or basic stuff like I,P Quality, so what i mean is if you take ratecontroll out of the equation would pep.exe and vc1_encoder.exe be more efficient also (seeing that there is a 1 year difference i doub't somehow only Ratecontroll has been improved) ?
im planing todo a noise/grain preservation test but really starting from 0 so ratecontroll wouldn't be that much important yet

benwaggoner

13th August 2007, 17:01

Anyway you don't have human/material ressource for make this little encoding (10 min). I can make that for you if you post your complete xml profil with your ideal setting. Time for make that is just 10 min ... no more.
I don't want to pull folks of finishing the next release of PEP/CineVision PSE for this, no. But I've asked our skilled PEP operators to take a look at the source and make some more definitive recommendations.

Really bad for visual quality at low bitrate. Really bad for SSIM too. I will make all the encoding with your suggested setting and profil with pep.exe exactly like you want but the result will be not better ...
No one is making HD DVD discs @ 6 Mbps, especially not full frame, sso the lack of postprocessor isn't an issue for actual titles. Unlike a loop filter, which actually helps add real image detail to a title, postprocessing just hides artifacts.

The best way for choose frame placement is evaluate each situation. Bframe are not alway the best efficient way and by far. For example Livavcodec use RDO for the bframe placement (really really slow) and never use bframe in large zone for Elephant Dream movie. x264 use really good and faster process for frame placement (not for the fade anyway) and if you choose 3 bframes or 1000 bframes with x264 the result will be in practice the same. For example with bframe at 3 for ED x264 use the same bframe number than Pframe number. If I understand correctly VC1 use always the default max possible bframe number and bframes are just adaptative for fade and flash part. It's really curious way for adaptative bframe.
In the version of PEP you have, the B-frame value is the target for content. Additional B-frames might be used for flash frames, and they can be turned off entirely for fades. But the B-frame control you're using isn't analagous to what you have in x264.

We understand the value of a more dyamic B-frame insertion process. Although for HD optical data rates and typical content, the current setup has been fine. And of course with PEP, the B-frame pattern can be manually set per segment.

Well this test is just metric comparison and not visual comparison. I don't say "H264 is better visually than VC1". I just say "here for this source H264 is better that VC1". It's an objective test and by definition you can't contradict that (make encoding if you want ... it's a challenge). And MS use PSNR too:
http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs
That's a pretty old article. Personally, I'm not that big a fan of PSNR. It's a good metric to keep an eye on (a big spike can show a problem), but as our codec has evolved, we've deployed more and more techniques that improve visual quality while reducing PSNR. SSIM is better, but assumes a perceptually uniform luma curve, and so underestimates the importance of high precision in the low luma range when seen on modern displays with elevated blacks. The latter is something the studios find really important, and our codec spends a lot of bits making sure there isn't blocking in black on consumer displays, even though that blocking wouldn't be seen on a calibrated CRT. SSIM and PSNR don't pick up on that.

buzzqw

13th August 2007, 17:23

pep or vc1_enc are freely avaiable ? where ?

thanks!

BHH

Golgot13

13th August 2007, 17:24

That's a pretty old article.

Only one year like the first version of this challenge :D

Personally, I'm not that big a fan of PSNR.

Same, but you (MS), ITU, EBU,.. use it.

It's a good metric to keep an eye on (a big spike can show a problem), but as our codec has evolved, we've deployed more and more techniques that improve visual quality while reducing PSNR. SSIM is better, but assumes a perceptually uniform luma curve, and so underestimates the importance of high precision in the low luma range when seen on modern displays with elevated blacks. The latter is something the studios find really important, and our codec spends a lot of bits making sure there isn't blocking in black on consumer displays, even though that blocking wouldn't be seen on a calibrated CRT. SSIM and PSNR don't pick up on that.

Nice, but to test some optimization, you need to have some metric result (except statistic satisfaction ;) ).
MPEG format reduce the data picture don't see by eye/brain, MPEG format
use the last research about this (from many year and use too on other codec).
H264 last version available of this research have lot of optimization and option for it.

Ben, I like your post but I prefer to see some thing:
If not agree show a other way to test the codec ?
May be ITU, EBU, DVB, MPEG (MPEG Committee) will use your tool or protocol to evaluate
the picture quality of codec.:rolleyes: :p

(MPEG Committee: http://www.chiariglione.org/mpeg/ )

Golgot13

13th August 2007, 17:30

pep or vc1_enc are freely avaiable ? where ?

Not free, only for MS partener (free) or >50.000$

buzzqw

13th August 2007, 17:34

@Golgot13
ouch... i hoped that was free... at least will help spreading of wvc1 encoding

thanks anyway!

BHH

Golgot13

13th August 2007, 17:34

Ben can you make YES or NOT the best VC1 encoding for ED ?

If NOT, I will conclude that H264 is really the best codec.

If YES, I must to see result and conclude for ED movie (CG movie) what codec is the best (may be VC1 but I doubt).

I hope that some journalist (french, I prefer) will write some thing about this (dead line for September is this week)...

Last, I listen that Toshiba will release new firmware (very soon) to correct last problem when it play H264 codec
(HD DVD player are optimized for VC1 because there is lot of VC1 HD DVD title and especially MS supervise).

zambelli

14th August 2007, 05:59

Ben can you make YES or NOT the best VC1 encoding for ED ?
One of our co-workers had some time last week to try encoding this with PEP 1.0.7. We've got a 12 Mbps VC-1 encode now that scores 47.62 dB PSNR and 92.70 SSIM, versus 46.71 dB PSNR and 92.44 SSIM of Sagittaire's VC-1 encode. The video was encoded with PEP 1.0.7 (currently in development), but with Dquant entirely off. This seems to be telling us that SSIM doesn't care about blockiness in dark and smooth areas - something that HD-DVD and BluRay studios do care about very much. So we'll continue looking into this, but it's far from being our #1 priority at this moment.

If NOT, I will conclude that H264 is really the best codec.
... the best codec for generating highest SSIM scores, perhaps. :rolleyes:

I hope that some journalist (french, I prefer) will write some thing about this (dead line for September is this week)...
I hope anyone writing an article about this challenge actually understands that it is just a metric comparison, as Sagittaire has stated in his own words.