[HD-DVD Challenge] MPEG2, VC-1 and H264 with real uncompressed source movie

[Sagittaire]

At this time I make VC-1 encoding ... and it's very very very slow ... lol

cscript.exe wmcmd.vbs -input azerty.avs -output VC1-6Mbps.wmv -v_codec WVC1 -v_profile AP -v_mode 4 -v_bitrate 6000000 -v_peakbitrate 29400000 -v_peakbuffer 320 -v_performance 100 -videoonly -pixelformat YV12 -v_keydist 600 -v_bframedist 2 -v_dquantoption 2 -v_loopfilter 1 -v_mbmodecost 1 -v_mmatch 0 -v_mslevel 3 -v_msrange 4 -v_mvcoding 3 -v_mvcost 1 -v_percopt 0 -v_denoise 0 -v_edgeremoval 0

cscript.exe wmcmd.vbs -input azerty.avs -output VC1-12Mbps.wmv -v_codec WVC1 -v_profile AP -v_mode 4 -v_bitrate 12000000 -v_peakbitrate 29400000 -v_peakbuffer 320 -v_performance 100 -videoonly -pixelformat YV12 -v_keydist 600 -v_bframedist 2 -v_dquantoption 2 -v_loopfilter 1 -v_mbmodecost 1 -v_mmatch 0 -v_mslevel 3 -v_msrange 4 -v_mvcoding 3 -v_mvcost 1 -v_percopt 0 -v_denoise 0 -v_edgeremoval 0

cscript.exe wmcmd.vbs -input azerty.avs -output VC1-24Mbps.wmv -v_codec WVC1 -v_profile AP -v_mode 4 -v_bitrate 24000000 -v_peakbitrate 29400000 -v_peakbuffer 320 -v_performance 100 -videoonly -pixelformat YV12 -v_keydist 600 -v_bframedist 2 -v_dquantoption 2 -v_loopfilter 1 -v_mbmodecost 1 -v_mmatch 0 -v_mslevel 3 -v_msrange 4 -v_mvcoding 3 -v_mvcost 1 -v_percopt 0 -v_denoise 0 -v_edgeremoval 0

[crypto]

I think at these bitrates the modern compressions can't play their advantages against old mpeg-2. Anyway let's wait for the results.

[Sagittaire]

I think at these bitrates the modern compressions can't play their advantages against old mpeg-2. Anyway let's wait for the results.

1) Well be carefull this source is really complex: I have vbv saturation for MPEG2 in really complexe scene and for that even bitrate at 24 mbps can't help ...

2) 6 Mbps is really low bitrate for this source. MPEG2 will use really high average quantizer for 6 Mbps. For 6 Mbps I think that VC-1 and H264 will done really better quality than MPEG2.

[Golgot13]

1) Well be carefull this source is really complex: I have vbv saturation for MPEG2 in really complexe scene and for that even bitrate at 24 mbps can't help ...

2) 6 Mbps is really low bitrate for this source.


What software do you use for MPEG2 encoding ?



MPEG2 will use really high average quantizer for 6 Mbps. For 6 Mbps I think that VC-1 and H264 will done really better quality than MPEG2.


Yes, FREE (ISP in France) have H264 VoD at 4Mbps to 4.5Mbps (1440x1080 resolution)
encoded with the last version of Ateme software encoder (I listen, I am not sure).

I think 6Mbps will be nice for 1920x1080 (HD VoD from FREE is good)



Sagittaire your "lnbox" for privet message is full.

Golgot13

[Sagittaire]

What software do you use for MPEG2 encoding ?

Sagittaire your "lnbox" for privet message is full.

Golgot13

Libavcodec and TMPGenc ... Libavcodec produce the best result for very high quantizer.

[zambelli]

Some comments on the WMV encoder line...

You can exclude the following parameters:
-v_profile AP -pixelformat YV12 -v_percopt 0 -v_denoise 0 -v_edgeremoval 0
They are redundant because that's what the codec uses by default anyway.

I'm not sure you're setting some of the parameters according to the constraints you posted earlier. For example, you say:

-v_bitrate 6000000 -v_peakbitrate 29400000 -v_peakbuffer 320 -v_keydist 600
You're forgetting to set -v_buffer. If buffer size is set to 9781 kbits, then at 6000kbps/29400kbps the buffer sizes will be 1630 and 333 msec respectively.

You also specify that max GOP length is 15 frames. At 25 fps, the key distance should be 0.6 seconds, which you appear to be trying to set, but you're forgetting that the v_keydist parameters is expressed in seconds, not milliseconds. :)

Finally, I would recommend you change the following parameters to this:
-v_performance 80 -v_mslevel 4 -v_msrange 0 -v_mvcoding 0 -v_mvcost 1
For slightly faster encoding, you can set v_mslevel to 1. Either way, you should use true chroma for best results.

Even though the vector range is defined as 1024/256, I don't think you should be fixing the encoder to that dimension. It might result in a lot of unnecessary motion search if the content doesn't require it. Just set it to Adaptive for starters and you can fine tune it later.
Finally, perf mode 100 is a lot slower than 80, but isn't usually worth the wait. Just my personal opinion.

[zambelli]

One question about the avisynth script:
Source=ConvertToYV12(source, matrix="PC.601")
Shouldn't the RGB -> YV12 conversion be using Rec709? I was under the impression that 0-255 RGB should be getting mapped to 16-235 YUV because HD-DVD uses TV range, not PC range. Furthermore, HD doesn't use Rec601 color coefficients because those were designed for SDTV.

Or do HDTV standards somehow not apply to HD-DVD?

[Sagittaire]

-v_bitrate 6000000 -v_peakbitrate 29400000 -v_peakbuffer 320 -v_keydist 600
You're forgetting to set -v_buffer. If buffer size is set to 9781 kbits, then at 6000kbps/29400kbps the buffer sizes will be 1630 and 333 msec respectively.

Well I read WMEncUtil.chm and I read that v_mode 4 don't work with -v_buffer but only with -v_peakbitrate and v_peakbuffer. For this test I set vbv like that: max bitrate at 29400 KBps and max buffer at 9 781 000 bits. That's mean 29400 Kbps for peakbitrate and 324 ms for peakbuffer (round at 320 ms for 8 frames at 25 fps). Here I think that v_buffer is useless: first v_buffer don't work with v_mode 4 and secondly v_buffer t make CBR for each t ms interval. I wan't real VBR encoding (with vbv limitation) and not CBR enconding for broadcast scenario ... ???


You also specify that max GOP length is 15 frames. At 25 fps, the key distance should be 0.6 seconds, which you appear to be trying to set, but you're forgetting that the v_keydist parameters is expressed in seconds, not milliseconds. :)

Well -v_keydist 0.6 dont work. Minimal interval for -v_keydist is 1 sec. It's really curious because variable must be float in WMCmd.vbs.

case "-v_keydist"
'Get video keyframe distance
g_intVideoKeydist = ReadFloat( args, i, i+1 )
if g_intVideoKeydist = -1 then
ParseParameters = false
exit function
end if

g_intVideoKeydist = 1000 * g_intVideoKeydist

i = i + 1

I make little modification to choose ms in input for v_keydist like that:

case "-v_keydist"
'Get video keyframe distance
g_intVideoKeydist = ReadFloat( args, i, i+1 )
if g_intVideoKeydist = -1 then
ParseParameters = false
exit function
end if

g_intVideoKeydist = 1 * g_intVideoKeydist

i = i + 1


Finally, I would recommend you change the following parameters to this:
-v_performance 80 -v_mslevel 4 -v_msrange 0 -v_mvcoding 0 -v_mvcost 1
For slightly faster encoding, you can set v_mslevel to 1. Either way, you should use true chroma for best results.

I will try that ... thx
RDO for macroblock mode (-v_mbmodecost 1) is usefull ... ???


Even though the vector range is defined as 1024/256, I don't think you should be fixing the encoder to that dimension. It might result in a lot of unnecessary motion search if the content doesn't require it. Just set it to Adaptive for starters and you can fine tune it later.

Well I don't know. HD-DVD VC-1 stream must have lenght motion vector limitation for hardware decoding. I choose MP@HL for MPEG2 and that's mean +/- 1024 pixels for Horizontal Vector Range and +/- 128 pixels for Vertical Vector Range, HP@L4.1 for H264 and that's mean +/- 1024 pixels for Horizontal Vector Range and +/- 512 pixels for Vertical Vector Range and AP@L3 for VC-1 and I think that it's not possible to have unlimited vector so I chose +/- 1024 pixels for Horizontal Vector Range and +/- 256 pixels. "Macroblock adaptative range" sound like unlimited range for me ... ???


Shouldn't the RGB -> YV12 conversion be using Rec709? I was under the impression that 0-255 RGB should be getting mapped to 16-235 YUV because HD-DVD uses TV range, not PC range. Furthermore, HD doesn't use Rec601 color coefficients because those were designed for SDTV

Well I dont know ... default matrix is Rec.601 for ConvertToYV12 in avisynth. I choose Full Range PC.601 Matrix and best possible YV12 quality for the source.

unspecified : Use Rec.601 coefficients, scaled to TV range [16,235].
"PC.601" : Use Rec.601 coefficients, keep full range [0,255].
"Rec709" : Use Rec.709 coefficients, scaled to TV range.
"PC.709" : Use Rec.709 coefficients, keep full range.

Rec709 is perhaps better way but it's just different pre-process for the source and matrix scaling don't change really the encoding result because the source is always the same for all codec.

[*.mp4 guy]

you should use 24 fps, most dvd's are authored at 23.976 fps telecined to 29.97, its a fair bet that the same procedure will be used on hd dvd and blu-ray, not to mention that 24 fps is the source frame rate and there is no point in needlessly complicating things. Also the vbv buffer should be 29.4 megabits, or 30105.6 kilobits.

[Sagittaire]

you should use 24 fps, most dvd's are authored at 23.976 fps telecined to 29.97, its a fair bet that the same procedure will be used on hd dvd and blu-ray, not to mention that 24 fps is the source frame rate and there is no point in needlessly complicating things. Also the vbv buffer should be 29.4 megabits, or 30105.6 kilobits.

1) 1080p25 and 1080i29.970 are fully compliant with HD-DVD and I dont know very well for 1080p24. With same bitrate progressive encoding will be always better than interlacing encoding with 3:2 pulldown pre-process. My country is PAL region and will use certainely 50 hz for HD-DVD then 1080p25 is the best choice for me in this test. Anyway 1080p24 or 1080p25 don't change anything in a video quality benchmark ... ;-)

2) there are 3 parameters for vbv:
- max bitrate
- max buffer size
- max initial buffer occupency

I have information for max bitrate and and you can choose initial buffer occupency like you want. But for max buffer I have no informations. I choose 9 781 Kbit because it's the official value for MPEG2 MP@HL profil. 30 105 kilobits outperform the MPEG2 MP@HL profil and by far but if you have official link for these setting then I can change the spec for this test. IMO you make a confusion between max bitrate at 29.4 Mbps and max buffer size at 29.4 Mbits. Anyway If 30 105 Kbits (seem very high for me) is HD-DVD compliant max vbv buffer size then 9 781 Kbits will be compliant too ... ;-)

[zambelli]

Well I read WMEncUtil.chm and I read that v_mode 4 don't work with -v_buffer but only with -v_peakbitrate and v_peakbuffer.
You're right - Sorry, my bad, I forgot that you were using v_mode 4 for encoding. You don't need v_buffer in that case.

Well -v_keydist 0.6 dont work. Minimal interval for -v_keydist is 1 sec. It's really curious because variable must be float in WMCmd.vbs.
Are you sure? I just tested setting v_keydist to 0.5 on a 24fps video source and it correctly inserted an I frame every 12 frames.

Your code modification works too, but it shouldn't be necessary - I don't see a problem with the original code.

RDO for macroblock mode (-v_mbmodecost 1) is usefull ... ???
In my experience, it doesn't affect the quality - so I typically just leave it out.
"Macroblock adaptative range" sound like unlimited range for me ... ???
I see your point. I always assumed that it dynamically picked between the other 3 ranges but never exceeded them. I should probably check with our devs though. Setting it to fixed 1024/256 forces the codec to always search that range on every frame, which might not be optimal.
Anyway, I don't see why motion search range is in the HD-DVD specs anyway. It's an encoder setting, not a decoder setting. Can somebody clarify?

Rec709 is perhaps better way but it's just different pre-process for the source and matrix scaling don't change really the encoding result because the source is always the same for all codec.
I disagree. If you're trying to adhere to HD-DVD specs, then I think the source should be processed correctly. I recommend that the ConvertToYV12 be changed to Rec709, or at least left at default Rec601.

[drmpeg]

The maximum VBV size for VC-1 AP@L3 in HD-DVD is 14,811,136 bits (or 1,851,392 bytes).

HD-DVD does not restrict MPEG-2. The maximum for MPEG-2 MP@HL is 9781248 bits (1,222,656 bytes). You have this correct already.

H.264 is also not restricted.

Ron

[zambelli]

1) 1080p25 and 1080i29.970 are fully compliant with HD-DVD and I dont know very well for 1080p24. With same bitrate progressive encoding will be always better than interlacing encoding with 3:2 pulldown pre-process. My country is PAL region and will use certainely 50 hz for HD-DVD then 1080p25 is the best choice for me in this test. Anyway 1080p24 or 1080p25 don't change anything in a video quality benchmark ... ;-)
I agree with drmpeg that it would be best to encode at 23.976fps. It does make a difference because bitrate is expressed in bits per seconds, which means that increasing the framerate spreads the bits thinner over each frame in that one second.

People shouldn't confuse encoding at 23.976p with decoding at 29.97i. Of course it's most optimal for any codec to encode only 24 progressive frames per second if that's what the source is. Telecine, if 29.97i is required by spec, can be done post-encoding by inserting the appropriate repeat flags into the bitstream. With all 3 codecs you can encode a 23.976fps source at 23.976fps and then run the elementary stream through a tool that will "convert" it to a 29.97i steam by adding the correct frame level metadata. DGPullDown is an example of a tool that can do this for MPEG-2.

I vote for 23.976fps encoding.

[drmpeg]

Note that 23.976 fps also limits the GOP to 14 frames. Since most folks will be using 2 B-frames, then this further limits the GOP to 12 frames.

Ron

[Sagittaire]

I disagree. If you're trying to adhere to HD-DVD specs, then I think the source should be processed correctly. I recommend that the ConvertToYV12 be changed to Rec709, or at least left at default Rec601.

Well it's not a real problem but I change that.
Damned ... all my encoding are bad now ... :devil:


I agree with drmpeg that it would be best to encode at 23.976fps. It does make a difference because bitrate is expressed in bits per seconds, which means that increasing the framerate spreads the bits thinner over each frame in that one second.

Well If you are sure that 23.976 fps progressive for video elementary stream is fully compliant it's not really a problem to change that to. Anyway 6000 Kbps at 24 fps done 5760 Kbps at 25 fps and it's the same problem for all the codec.


The maximum VBV size for VC-1 AP@L3 in HD-DVD is 14,811,136 bits (or 1,851,392 bytes).

HD-DVD does not restrict MPEG-2. The maximum for MPEG-2 MP@HL is 9781248 bits (1,222,656 bytes). You have this correct already.

H.264 is also not restricted.

No buffer restrictions for H264 and MPEG2 .... ???!!!!!????

Well you must use the 3 parameters for vbv. Max Bitrate with unlimited max buffer size is completely useless. You must have limitation for max bitrate (fixed by the optical support speed HD-DVD 1X or DVD 3X here) and buffer to outperform localy this physical fixed max bitrate.

Buffer is fixed by the chip for hardware decoding and if there are 14,811,136 bits for max buffer size for VC-1 with HD-DVD then obligatory max buffer size will be the same for the other codec ... ???


Note that 23.976 fps also limits the GOP to 14 frames. Since most folks will be using 2 B-frames, then this further limits the GOP to 12 frames.

You are sure? 12 frame for GOP is really ridiculous low value? And How must be the GOP with adaptative bframe number? The GOP spec are the same for 1080p25? 25 fps with GOP 15 will done certainely better result than 1080p24 with GOP 12 for the same bitrate (little more bits for 1080p24 but really less Iframe for 1080p25)


I see your point. I always assumed that it dynamically picked between the other 3 ranges but never exceeded them. I should probably check with our devs though. Setting it to fixed 1024/256 forces the codec to always search that range on every frame, which might not be optimal.
Anyway, I don't see why motion search range is in the HD-DVD specs anyway. It's an encoder setting, not a decoder setting. Can somebody clarify?

It's simply chip limitation for hardware decoding. For exemple DVD standard fixe max vector lenght at +/-512 H and +/- 128 V. If you don't respect these limitations the video elementary stream will be not compliant and will not play on DVD SAP.

[drmpeg]

No buffer restrictions for H264 and MPEG2 .... ???!!!!!????

Just to clarify, I meant HD-DVD applies no additional restrictions other than the maximum for MPEG-2 MP@HL and H.264 Level 4.1 in their respective specification. So MPEG-2 MP@HL on HD-DVD is still 9,781,248 bits maximum.

I believe the maximum for H.264 Level 4.1 is 62,500,000 bits (which would set the hardware decoder requirements)?

Ron

[drmpeg]

You are sure? 12 frame for GOP is really ridiculous low value? And How must be the GOP with adaptative bframe number? The GOP spec are the same for 1080p25? 25 fps with GOP 15 will done certainely better result than 1080p24 with GOP 12 for the same bitrate.
The display time of the GOP cannot exceed .6006 seconds. Same as regular DVD.

Blu-ray GOP size is more relaxed at 1 second.

Ron

[Sagittaire]

The display time of the GOP cannot exceed .6006 seconds. Same as regular DVD.

Blu-ray GOP size is more relaxed at 1 second.

Ron

oh yes but it's not obligatory fixed bframe at 2. All the good encoder can use adapative bframe and in this case the max GOP will be always at 14. Anyway quality for 1080p25 GOP 15 will be the same that 1080p24 GOP 14 with same bitrate:
- More Iframe for 1080p24: +7%
- Less bits for each frame for 1080p25: -4%

[Sagittaire]

Well I make modification for the test after reflexion:

Color convertion PC.601 to Rec.709
Don't change anything for encoding because the hierarchy will be the same for the codec quality. But [16-235] TV scaling done more compressible source and quality compression (aka average quantizer) will be higher for all the encoding at the same bitrate.

max Buffer Size at 9 781 Kbits for MPEG2, VC-1 and H264
All the codec seem not use the same vbv buffer for HD-DVD. Anyway for make real comparison between codec use the same vbv buffer is better way. 9 781 Kbits is a good value for MPEG2 and will done good result too with VC-1 and H264.

Framerate at 25 fps
1080p25 GOP 15 or 1080p23.976 GOP 14 don't change anything for quality (aka average quantizer) at the same bitrate. 1080p25 is fully compliant with the HD-DVD and will be always progressive (for encoding process and for decoding process).

[Sagittaire]

Here very partial result for H264:

3D:\Mes dossiers\Codec\x264>x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 294
00 --vbv-bufsize 9500 --level 4.1 --bframe 2 --b-rdo --bime --weightb --ref 2 --
mixed-refs --direct auto --filter -1:-1 --bitrate 6000 --pass 3 --stats "H264_6M
bps.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.33 --analyse "all" --8x8dct --m
e "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --progress -o H2
64_6Mbps.mp4 azerty.avs
avis [info]: 1920x1080 @ 25.00 fps (15691 frames)
x264 [warning]: width or height not divisible by 16 (1920x1080), compression wil
l suffer.
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: slice I:1137 Avg QP:20.94 size:105408 PSNR Mean Y:48.75 U:58.69
V:57.31 Avg:49.67 Global:46.96
x264 [info]: slice P:6863 Avg QP:21.65 size: 38238 PSNR Mean Y:47.95 U:57.57
V:56.31 Avg:48.91 Global:46.18
x264 [info]: slice B:7691 Avg QP:23.35 size: 11607 PSNR Mean Y:47.40 U:60.11
V:58.33 Avg:48.48 Global:45.36
x264 [info]: mb I I16..4: 41.5% 40.3% 18.1%
x264 [info]: mb P I16..4: 11.7% 11.4% 2.4% P16..4: 31.1% 7.6% 3.1% 0.4% 0
.2% skip:32.1%
x264 [info]: mb B I16..4: 0.9% 1.5% 0.4% B16..8: 10.4% 1.2% 2.3% direct:
1.8% skip:81.6%
x264 [info]: 8x8 transform intra:43.8% inter:52.6%
x264 [info]: direct mvs spatial:87.2% temporal:12.8%
x264 [info]: ref P 79.8% 20.2%
x264 [info]: ref B 82.9% 17.1%
x264 [info]: SSIM Mean Y:0.9878017
x264 [info]: PSNR Mean Y:47.739 U:58.894 V:57.374 Avg:48.753 Global:45.806 kb/s:
6010.40

encoded 15691 frames, 0.98 fps, 6011.45 kb/s

Quality for only 6000 Mbps is really impressive and better by far than MPEG2 encoding. And this source is really really complex and uncompressible source ... ;-)

[Golgot13]

Quality for only 6000 Mbps is really impressive and better by far than MPEG2 encoding. And this source is really really complex and uncompressible source ... ;-)

And you don't use the MBAFF option... (because it's 25p)
May be Mr Zambelli can do better with VC1 stream compliant HD DVD.:sly:
I'm very happy to have a test like this... :D


Golgot13

[Manao]

And this source is really really complex and uncompressibleIf you got 47dB with 6000 Mbps, then it's not complex nor uncompressible. I'm more used to 33-35 dB for complex & uncompressible 1080p.

[zambelli]

Framerate at 25 fps
1080p25 GOP 15 or 1080p23.976 GOP 14 don't change anything for quality (aka average quantizer) at the same bitrate. 1080p25 is fully compliant with the HD-DVD and will be always progressive (for encoding process and for decoding process).
Why do you keep insisting that different framerates at the same bitrate yield the same quality? It's just not true. A 720p29.97 video will not have the same quality as a 720p59.94 video if you use 6Mbps for both. The difference between 25 and 23.976 fps might not be drastic, but if you have the option of using 4.3% more bits per frame - why not?

It's your test so I'll let you make the final call, but I just don't see a point in insisting on 25fps when we're never going to actually author HD-DVDs out of these videos.

[foxyshadis]

I believe the assumption is that the extra P or B frame per gop will save enough to ameliorate that extra 4% cost. That would very much depend on how large on average P and B frames are in this movie.

[Sagittaire]

If you got 47dB with 6000 Mbps, then it's not complex nor uncompressible. I'm more used to 33-35 dB for complex & uncompressible 1080p.

"this source is really complex and uncompressible source ... [if I compare with overall real world movie source]."

Like you say very well (certainly really better than me) PSNR is not absolute quality measure but only relative quality measure. You can't say "you got 47 dB with 6000 Mbps at 1080p then source is really compressible".

1) I make resize at 576*320 and q2 encoding with XviD 1.2.0 and default setting (ME6, VHQ1, Trellis, Bframe at 2/1.50/1.00, H263 ... ect). And average bitrate for this little movie is 1866 Kbps. You are an old DVDRipper like me and you know what that means certainery really better than me ... ;-)

2) I made this little example with q4 and noisy source. With original source will done 1116 Kbps and 43.36 dB. I make little denoising and q4 done this time 1053 Kbps and 43.59 dB. Lower bitrate and better PSNR. PSNR is not an absolute quality measure. I made test too with very noisy source at --crf 20 with x264 and with FFT3dFilter: something like 42 dB at 1200 Kbps for noisy source and 44 dB at 1000 Kbps for encoding after FFT3dFilter filtering.

Elephant Dream is a perfect digital master source without noise and will done always high PSNR even with extreme compression level and poor visual quality. It's a relative uncompressible source if I compare with an usual movie source.


Why do you keep insisting that different framerates at the same bitrate yield the same quality? It's just not true. A 720p29.97 video will not have the same quality as a 720p59.94 video if you use 6Mbps for both. The difference between 25 and 23.976 fps might not be drastic, but if you have the option of using 4.3% more bits per frame - why not?

1) First all the codec will use 25 fps. 24 fps or 25 fps don't change anything for video benchmark hierarchy. Relative result between codec will be the same for 1080p25 at 6 000, 12 000 and 24 000 Mbps or for 1080p24 at 5 760, 11 520 and 23 040 Kbps.

2) Secondly simply because bit/frame will be better (-1/25 = -4%) for 1080p24 but not for IFrame frequency (+1/15 = +7%). High IFrame frequency with short GOP is not a very efficient GOP structure simply because Iframe use really more average size than PFrame or BFrame. Now little example with MPEG2 encoding at constant quantizer 4:

framerate at 23.976. Adaptative bframe. Max Gop at 0.6006 sec -> 14 frame max
1672 Kbps and 44.86 dB -> reference

framerate at 23.976. No Adaptative bframe. Max Gop at 0.6006 sec -> 12 frame max
1760 Kbps and 44.89 dB -> +5%

framerate at 25.000. Adaptative bframe. Max Gop at 0.6006 sec -> 15 frames max
1719 Kbps and 44.86 dB -> +3%

framerate at 25.000. No Adaptative bframe. Max Gop at 0.6006 sec -> 15 frames max
1767 Kbps and 44.87 dB -> +5%

I use adaptative bframe for H264 and MPEG2 but I don't know if VC-1 use adaptative bframe. In all case GOP 15 is better way IMO for make good comparison.


Frame Quant Size YPSNR UPSNR VPSNR APSNR Type
493, 3.00, 23640, 46.92, 51.72, 51.76, 48.02 I
494, 3.00, 3582, 46.23, 51.34, 51.35, 47.37 B
495, 3.00, 3564, 46.53, 51.51, 51.51, 47.65 B
496, 3.00, 5046, 46.00, 51.10, 51.11, 47.13 P
497, 3.00, 3449, 46.35, 51.27, 51.38, 47.47 B
498, 3.00, 3838, 46.00, 51.23, 51.21, 47.15 B
499, 3.00, 4700, 45.73, 50.96, 50.97, 46.88 P
500, 3.00, 3625, 45.97, 51.08, 51.04, 47.11 B
501, 3.00, 3462, 46.11, 51.11, 51.07, 47.23 B
502, 3.00, 4460, 46.03, 51.07, 51.05, 47.16 P
503, 3.00, 3954, 46.08, 51.00, 51.03, 47.19 B
504, 3.00, 4006, 45.84, 50.98, 51.01, 46.99 B
505, 3.00, 23273, 47.23, 51.69, 51.74, 48.28 I
506, 3.00, 3982, 46.00, 51.10, 51.28, 47.15 B
507, 3.00, 3481, 46.58, 51.37, 51.50, 47.69 B
508, 3.00, 7347, 46.72, 51.13, 51.02, 47.75 P
509, 3.00, 4108, 46.98, 51.46, 51.47, 48.03 B
510, 3.00, 4421, 46.62, 51.36, 51.27, 47.70 B
511, 3.00, 7580, 46.39, 50.87, 50.75, 47.43 P
512, 3.00, 4403, 46.65, 51.21, 51.11, 47.70 B
513, 3.00, 4260, 46.82, 51.16, 51.07, 47.84 B
514, 3.00, 7248, 45.98, 50.76, 50.70, 47.07 P
515, 3.00, 3764, 46.74, 51.08, 51.02, 47.76 B
516, 3.00, 4028, 46.35, 50.83, 50.77, 47.40 B


x264 [info]: slice I:1137 Avg QP:20.94 size:105408 PSNR Mean Y:48.75 U:58.69 V:57.31 Avg:49.67 Global:46.96
x264 [info]: slice P:6863 Avg QP:21.65 size: 38238 PSNR Mean Y:47.95 U:57.57 V:56.31 Avg:48.91 Global:46.18
x264 [info]: slice B:7691 Avg QP:23.35 size: 11607 PSNR Mean Y:47.40 U:60.11 V:58.33 Avg:48.48 Global:45.36

[Manao]

"you got 47 dB with 6000 Mbps at 1080p then source is really compressible"I didn't say that either.Like you say very well (certainly really better than me) PSNR is not absolute quality measure but only relative quality measureBut you do know, as I do, that 47 dB is a high PSNR, not for from the visually lossless ones. The SSIM is 90, which is insanely high too. And when I say I get 33 dB on some of my videos, you do know too that it's low. 1) I make resize at 576*320 and q2 encoding with XviD 1.2.0 and default setting (ME6, VHQ1, Trellis, Bframe at 2/1.50/1.00, H263 ... ect). And average bitrate for this little movie is 1866 KbpsSo what ? It's hard to encode when you downsize it ? What does it prove ?

You thing is, you got 47 dB @ 6 Mbs. You're close to saturating your eyes. How will you judge the quality of 12 & 24 Mbps then, when you can't even see the difference between them ?

[Sagittaire]

I didn't say that either

Yes it's true but sound little like that ... ;-)

"If you got 47dB with 6000 Mbps, then it's not complex nor uncompressible."


But you do know, as I do, that 47 dB is a high PSNR, not for from the visually lossless ones. The SSIM is 90, which is insanely high too.

It's 45.8 dB for OPSNR at 6000 Kbps. If I make crf 21 encoding on other very clean 1080p source (http://images.apple.com/movies/wb/the_departed/the_departed-tlr1b_h1080p.mov) the result can be very better: 47.8 dB and 5787 Kbps. And these trailers are always less compressible than original movie like you say very well.



And when I say I get 33 dB on some of my videos, you do know too that it's low. So what ? It's hard to encode when you downsize it ? What does it prove ?

Well 33 dB for 1080p at 6 Mbps ... ? Certainely with personnal DV source with an "Alzeimer" cameraman. But certainely not with usual movie source ... ???


So what ? It's hard to encode when you downsize it ? What does it prove ?

Simply that this source is not really compressible. 1080p XviD at q2 will done certainely something like 12.0 Mbps.


You thing is, you got 47 dB @ 6 Mbs. You're close to saturating your eyes. How will you judge the quality of 12 & 24 Mbps then, when you can't even see the difference between them ?

Yes it's perhaps true. I thing that 24 Mbps encoding will saturing eyes for this source like generaly for all the other movie source. Like 12 Mbps or 24 Mbps will certainely saturing eyes for this source (http://trailers.nerodigital.com/Disney/TheGreatestGame_HD_AVC.mp4).

[Sagittaire]

End of encoding for H264 ...

D:\Mes dossiers\Codec\x264>x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 294
00 --vbv-bufsize 9500 --qpmin 5 --level 4.1 --bframe 2 --b-rdo --bime --weightb
--ref 2 --mixed-refs --direct auto --filter -1:-1 --bitrate 24000 --pass 3 --sta
ts "H264_24Mbps.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.33 --analyse "all"
--8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --pr
ogress -o H264_24Mbps.mp4 azerty.avs
avis [info]: 1920x1080 @ 25.00 fps (15691 frames)
x264 [warning]: width or height not divisible by 16 (1920x1080), compression wil
l suffer.
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: slice I:1135 Avg QP: 9.80 size:295463 PSNR Mean Y:56.12 U:62.03
V:60.80 Avg:56.68 Global:54.36
x264 [info]: slice P:6865 Avg QP:10.35 size:150371 PSNR Mean Y:54.89 U:60.63
V:59.51 Avg:55.49 Global:53.35
x264 [info]: slice B:7691 Avg QP:11.77 size: 64931 PSNR Mean Y:54.74 U:62.84
V:61.19 Avg:55.48 Global:52.72
x264 [info]: mb I I16..4: 25.3% 37.3% 37.4%
x264 [info]: mb P I16..4: 5.3% 12.7% 8.5% P16..4: 27.3% 15.0% 8.5% 1.3% 1
.5% skip:19.9%
x264 [info]: mb B I16..4: 0.6% 1.8% 1.5% B16..8: 16.7% 3.6% 7.5% direct:
5.6% skip:62.7%
x264 [info]: 8x8 transform intra:44.1% inter:32.5%
x264 [info]: direct mvs spatial:88.0% temporal:12.0%
x264 [info]: ref P 80.7% 19.3%
x264 [info]: ref B 80.4% 19.6%
x264 [info]: SSIM Mean Y:0.9966756
x264 [info]: PSNR Mean Y:54.904 U:61.814 V:60.425 Avg:55.571 Global:53.092 kb/s:
23797.49

encoded 15691 frames, 0.65 fps, 23798.50 kb/s

... average quantizer at 10 with OPSNR at 53 dB. And like I say this source is not really compressible. A large majority of movie will use better average quantizer for 24 Mbps with H264 ... :confused:

[zambelli]

Sagittaire, the SSIM download link in your post is broken. The usual SSIM download doesn't support Lumimask=2.

[Sagittaire]

Sagittaire, the SSIM download link in your post is broken. The usual SSIM download doesn't support Lumimask=2.

1) New link in the first post:
http://multimediacom.free.fr/Download/SSIM.rar
This SSIM plugin use little One2Tech patch for lumimask. lumimask=1 is the original lumimask.

2) I make little test for VC-1 at 24 fps and 25 fps with GOP 0.6 sec and 2 Bframes. For the same bitrate bitrate 25 fps will done better result for metric than 24 fps. Parhaps because VC-1 don't use adaptative GOP and must use GOP12 à 24 fps(IBBPBBPBBPBB) and GOP15 at 25 fps (IBBPBBPBBPBBPBB)?

3) I make actually the VC-1 encoding with same setting than "best quality" profil (except for bframe at 2). I choose adaptative macroblock range because +/- 1024 H and +/- 256 V is really too slow and I think that this setting use always lower maximum values for pixel range search like you say (if VC-1 dev can confirm that?)

[zambelli]

1) New link in the first post:
http://multimediacom.free.fr/Download/SSIM.rar
This SSIM plugin use little One2Tech patch for lumimask. lumimask=1 is the original lumimask.
Thank you.

2) I make little test for VC-1 at 24 fps and 25 fps with GOP 0.6 sec and 2 Bframes. For the same bitrate bitrate 25 fps will done better result for metric than 24 fps. Parhaps because VC-1 don't use adaptative GOP and must use GOP12 à 24 fps(IBBPBBPBBPBB) and GOP15 at 25 fps (IBBPBBPBBPBBPBB)?
Yes, WMV9 AP doesn't support adaptive GOP lengths, so GOP15 is going to work better because of less bits being spent on the more frequent I-frames.

3) I make actually the VC-1 encoding with same setting than "best quality" profil (except for bframe at 2). I choose adaptative macroblock range because +/- 1024 H and +/- 256 V is really too slow and I think that this setting use always lower maximum values for pixel range search like you say (if VC-1 dev can confirm that?)
I'm currently encoding with these settings:
-v_codec WVC1 -v_mode 4 -v_bitrate 6000000 -v_peakbitrate 29400000 -v_peakbuffer 320 -v_keydist 0.6 -v_framerate 25 -v_performance 80 -v_bframedist 2 -v_loopfilter 1 -v_mmatch 2 -v_mslevel 4 -v_msrange 0
I left out the dquant settings this time, but I'll probably add them in the next round of encoding.

[zambelli]

OK, I finished encoding the movie with WMV9 AP with the following wmcmd.vbs settings:

-v_codec WVC1 -v_mode 4 -v_bitrate 6000000 -v_peakbitrate 29400000 -v_peakbuffer 320 -v_keydist 0.6 -v_framerate 25 -v_performance 80 -v_bframedist 2 -v_loopfilter 1 -v_mmatch 2 -v_mslevel 4 -v_msrange 0

After running PSNR and SSIM via Avisynth, I got:

Total frames processed: 15691
Minimum Average Maximum

Y: Mean Absolute Deviation: 0.0000 12.8633 111.9753
U: Mean Absolute Deviation: 0.0000 0.8216 1.9066
V: Mean Absolute Deviation: 0.0000 0.8870 1.7420
Sum: Mean Absolute Deviation: 0.0000 24.5789 74.6502

Y: Mean Deviation: -1.3326 0.3728 111.9753
U: Mean Deviation: -0.3660 0.0727 0.9462
V: Mean Deviation: -0.8141 0.0471 0.5873
Sum: Mean Deviation: -0.8143 0.8852 74.6502

Y: Mean Square Error: 0.0000 3.3119 110.9444
U: Mean Square Error: 0.0000 0.6574 7.6650
V: Mean Square Error: 0.0000 0.7330 5.5465
Sum: Mean Square Error: 0.0000 2.4397 73.9629

Y: Root Mean Square Error: 0.0000 1.5753 10.5330
U: Root Mean Square Error: 0.0000 0.6798 2.7686
V: Root Mean Square Error: 0.0000 0.7283 2.3551
Sum: Root Mean Square Error: 0.0000 1.3705 8.6002

Y: PSNR: 27.6798 42.9300 1.#INF
U: PSNR: 39.2857 49.9522 1.#INF
V: PSNR: 40.6906 49.4799 1.#INF
Sum: PSNR: 29.4407 44.2575 1.#INF
Minimum Average Maximum

Mean Absolute Deviation: 0.0000 24.5789 74.6502
Mean Deviation: -0.8143 0.8852 74.6502
PSNR: 29.4407 44.2575 1.#INF

SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 85.28804341

Sagittaire, can you run the 6Mbps x264 encode through Avisynth PSNR & SSIM too and post results?

Those short GOPs really seem to be giving the codec a hard time. I'll also try disabling Loopfilter - if there aren't macroblocking problems, Loopfilter probably softens the picture unnecessarily.
Maybe some DQuant tweaking is in order too.

[Sagittaire]

At this time very partial result from the encoder itself:

MPEG2 6000 Kbps, Overall PSNR = ~42.00 dB
MPEG2 12000 Kbps, Overall PSNR = ~46.00 dB

H264 6000 Kbps, Overall PSNR = 45.80 dB

3D:\Mes dossiers\Codec\x264>x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 294
00 --vbv-bufsize 9500 --level 4.1 --bframe 2 --b-rdo --bime --weightb --ref 2 --
mixed-refs --direct auto --filter -1:-1 --bitrate 6000 --pass 3 --stats "H264_6M
bps.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.33 --analyse "all" --8x8dct --m
e "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --progress -o H2
64_6Mbps.mp4 azerty.avs
avis [info]: 1920x1080 @ 25.00 fps (15691 frames)
x264 [warning]: width or height not divisible by 16 (1920x1080), compression wil
l suffer.
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: slice I:1137 Avg QP:20.94 size:105408 PSNR Mean Y:48.75 U:58.69
V:57.31 Avg:49.67 Global:46.96
x264 [info]: slice P:6863 Avg QP:21.65 size: 38238 PSNR Mean Y:47.95 U:57.57
V:56.31 Avg:48.91 Global:46.18
x264 [info]: slice B:7691 Avg QP:23.35 size: 11607 PSNR Mean Y:47.40 U:60.11
V:58.33 Avg:48.48 Global:45.36
x264 [info]: mb I I16..4: 41.5% 40.3% 18.1%
x264 [info]: mb P I16..4: 11.7% 11.4% 2.4% P16..4: 31.1% 7.6% 3.1% 0.4% 0
.2% skip:32.1%
x264 [info]: mb B I16..4: 0.9% 1.5% 0.4% B16..8: 10.4% 1.2% 2.3% direct:
1.8% skip:81.6%
x264 [info]: 8x8 transform intra:43.8% inter:52.6%
x264 [info]: direct mvs spatial:87.2% temporal:12.8%
x264 [info]: ref P 79.8% 20.2%
x264 [info]: ref B 82.9% 17.1%
x264 [info]: SSIM Mean Y:0.9878017
x264 [info]: PSNR Mean Y:47.739 U:58.894 V:57.374 Avg:48.753 Global:45.806 kb/s:
6010.40

encoded 15691 frames, 0.98 fps, 6011.45 kb/s


Your setting are really too slow for my little sempron 2.1 Ghz. In my case it's verry better for speed to use that I think (with certainely very good and close result at this high quality level):

cscript.exe wmcmd.vbs -input azerty.avs -output VC1-6Mbps.wmv -v_codec WVC1 -v_profile AP -v_mode 4
-v_bitrate 6000000 -v_peakbitrate 29400000 -v_peakbuffer 320 -v_performance 60 -videoonly -pixelformat YV12
-v_keydist 600 -v_bframedist 2 -v_dquantoption 2 -v_loopfilter 1 -v_mmatch 0 -v_mslevel 3 -v_msrange 0 -v_mvcost 1
-v_percopt 0 -v_denoise 0 -v_edgeremoval 0



Now verry little and partial analyse for your VC-1 codec:

Mean Absolute Deviation: 0.0000 24.5789 74.6502
Mean Deviation: -0.8143 0.8852 74.6502
PSNR: 29.4407 44.2575 1.#INF


1) Your VC-1 codec done very good and very better result than the best MPEG2 encoder for metric (libavcodec IMO) and it's close to H264 (44.22 dB is a very good quality for this source at 1080p).

2) Like MPEG2 and certainely H264, Min PSNR is very low. VBV constraint imply high quantisation level in complex part (high motion, complex texture). Inloop is always necessary if you use vbv constraint (HD-DVD scenario encoding) even if you use 12 or 24 Mbps I think because quant variation will be always very high ...

I will make very better analyse with graph PSNR to compare how work Rate Control for each codec.


If possible you can done a link for your VC-1 encoding at 6, 12 and 24 Mbps ... ???

[Manao]

Whatever the bitrate, vbv constraints remain the same. So the min PSNR shouldn't change. Anyhow, 30 dB seems really low since the max bitrate is 30 mbps.

@zambelli : v_peakbuffer = 320 ? In what unit is expressed the v_peakbuffer ? milliseconds ?

[zambelli]

At this time very partial result from the encoder itself:
Any chance you could run the SSIM through Avisynth? I don't expect the PSNR to be significantly different, but in the case of SSIM we're using the Avisynth plugin specifically for the Lumimask=2 option, so we might as well compare apples to apples.

1) Your VC-1 codec done very good and very better result than the best MPEG2 encoder for metric (libavcodec IMO) and it's close to H264 (44.22 dB is a very good quality for this source at 1080p).
I have to say this is a very strange source. For example, frame-by-frame PSNR shows very high dB in the first 100 frames, yet when I view the video I can see some heavy macroblocking in that intro fade-in from black. I wonder why it's not being reflected in the PSNR numbers.

I will make very better analyse with graph PSNR to compare how work Rate Control for each codec.
Let me know if you'd like me to send you the PSNR log.

If possible you can done a link for your VC-1 encoding at 6, 12 and 24 Mbps ... ???
Well, the file is 400+ MB in size. I have nowhere to upload something that big. The best I could do is share it out over Bittorrent.

[zambelli]

@zambelli : v_peakbuffer = 320 ? In what unit is expressed the v_peakbuffer ? milliseconds ?
Yes, that was discussed earlier. 320ms at 29.4Mbps equals 9500 kbit buffer, which is one of the requirements that Sagittaire defined.

[Sagittaire]

Any chance you could run the SSIM through Avisynth? I don't expect the PSNR to be significantly different, but in the case of SSIM we're using the Avisynth plugin specifically for the Lumimask=2 option, so we might as well compare apples to apples.

I will make that for VC-1, MPEG2 and H264 ... but my little sempron is really slow and particulary for VC-1 "best quality" encoding ... ;-)


I have to say this is a very strange source. For example, frame-by-frame PSNR shows very high dB in the first 100 frames, yet when I view the video I can see some heavy macroblocking in that intro fade-in from black. I wonder why it's not being reflected in the PSNR numbers.

Like I say to Manao in previous thread PSNR is not absolute quality measure but only relative quality measure. Frame "A" at 40 dB could be visualy really better than Frame "B" at 43 dB but Frame "C" at 40 dB will be always really better than the same frame "C" at 43 dB. Moreover PSNR is not perfect quality measure.


Let me know if you'd like me to send you the PSNR log.

Yes I will compare with my VC-1 encoding ...


Whatever the bitrate, vbv constraints remain the same. So the min PSNR shouldn't change. Anyhow, 30 dB seems really low since the max bitrate is 30 mbps.

Yes and min PSNR will be ~28 dB for MPEG2. Like I say this source is really complex. But for me 30 Mbps for max bitrate and 9500 Kbits for buffer could be really a big problem for HD-DVD like 10 Mbps and 1835 Kbits could be a big problem for DVD with really complex source ...

[Gabriel_Bouvigne]

... average quantizer at 10 with OPSNR at 53 dB. And like I say this source is not really compressible.
An average Qp of 10?? Then it's an EASY source, certainly not an hard to encode one.

[drmpeg]

I've finished the clip in MPEG-2. It is available for download here:

http://www.w6rz.net/ed.zip

Warning: It is a large file, 1,394,612,788 bytes.

It is 18 Mbps average, 29 Mbps peak with 12 frame fixed GOP, 1080i@29.97 with telecine flags, REC. 709 matrix. Single-pass VBR from a real-time hardware encoder.

http://www.lsilogic.com/products/video_production__professional_/hdtvxpress.html

Here's a graph of the bitrate:

http://img434.imageshack.us/img434/6241/edbitskm0.th.jpg (http://img434.imageshack.us/my.php?image=edbitskm0.jpg)

And the average quantization per frame:

http://img326.imageshack.us/img326/4237/edqmx3.th.jpg (http://img326.imageshack.us/my.php?image=edqmx3.jpg)

I'll have a PSNR graph of the first 3500 frames soon.

Ron

[Sagittaire]

An average Qp of 10?? Then it's an EASY source, certainly not an hard to encode one.

Well I think that the large majority of 1080p movie will certainely use even lower average quantizer at 24 Mbps for H264. 24 Mbps for 1080p will use the same average quant that 7 Mbps for 720*576. Try to make encoding with large DVD source with x264 and see the average quant at 720*576 and 7 Mbps ... ;-)

@ drmpeg

Not possible for you to make encoding at 25 fps with good challenge bitrate?
It's actually very difficult for me to make MPEG2 encoding without overflow problem with mencoder (libavcodec).
Anyway your bitrate and quantizer graph show really good that vbv constraint are a problem for this source.

[Sagittaire]

@ Zambelli

Post Process is compliant with VC-1 standard?
If yes what's PP setting will use HD-DVD SAP?

[Manao]

drmpeg : were you using the linear scale or the exponential one ? The exponantial should be better suited for that kind of content, I think. Also, why does the quantizer seems capped to 2, while it can go down to 1 in the standard ? Finally, could you link to a txt file containing the bitrates / quantizer ( and possibly psnr ) per frame ? Because your graphs seem nice, but not precise enough.

[drmpeg]

@ drmpeg
Not possible for you to make encoding at 25 fps with good challenge bitrate?

Yes, no problem. This first version is for folks to actually burn on DVD-R with MF5. I chose 18 Mbps average as a compromise between quality and download time.

In fact, I have to code a new clip for the PSNR graph. The hardware encoder that I'm using doesn't always stay in film mode. It drops to video during black frames, which causes problems when I run my PSNR program (the coded and reference frames slide out of sync). So I need to do a progressive encode, and 25 fps would be fine.

Ron

[drmpeg]

drmpeg : were you using the linear scale or the exponential one ? The exponantial should be better suited for that kind of content, I think. Also, why does the quantizer seems capped to 2, while it can go down to 1 in the standard ? Finally, could you link to a txt file containing the bitrates / quantizer ( and possibly psnr ) per frame ? Because your graphs seem nice, but not precise enough.
Yes, the clip uses non-linear quant scale. So the maximum value is 112 and the minimum is 1. The encoder itself is capping the minimum quant to 2.

I do have the raw data files. I'll post them when I have a chance. I agree that much detail is lost in a 16000 frame graph.

EDIT: here is a zip of the raw data files (edbits.txt is bits per frame, edq.txt is quant_scale / 2 and edbs.txt is the complete stats file):

http://www.w6rz.net/edstats.zip

And a graph of VBV usage:

http://img169.imageshack.us/img169/866/edvbvzx9.th.jpg (http://img169.imageshack.us/my.php?image=edvbvzx9.jpg)

A single-pass VBR algorithm can't really take advantage of the VBV.

Ron

[zambelli]

@ Zambelli
Post Process is compliant with VC-1 standard?
If yes what's PP setting will use HD-DVD SAP?
I don't think post processing is in the standard, though I could be wrong - I really ought to read that spec in its entirety. I doubt HD-DVD uses PP on any codec. It's high definition after all - it's not very desirable to filter it.

I personally think that any PSNR/SSIM measurements should be done without PP. I know Doom9 disagrees with that - he always leaves PP at its default setting in his codec shootout. I just don't think postprocessing an image has any relevance to encoder quality.

You can control post processing in WMV decoder by setting these 2 registry values (both DWORD):

"HKCU\Software\Microsoft\Scrunch\Post Process Mode"
"HKCU\Software\Microsoft\Scrunch\Force Post Process Mode"

to 0 (none), 1 (weak deblocking), 2 (strong deblocking), 3 (weak deblocking + deringing) or 4 (strong deblocking + deringing).

[drmpeg]

I don't think post processing is in the standard, though I could be wrong - I really ought to read that spec in its
Post processing is part of the VC-1 standard. The bitstream syntax is:

FRMRTQ_POSTPROC - 3 bits of quantized frame rate. Frame rate = (2 + FRMRTQ_POSTPROC * 4) frames/second

BITRTQ_POSTPROC - 5 bits of quantized bitrate. Bitrate = (32 + BITRTQ_POSTPROC * 64) kbps.

POSTPROCFLAG - 1 bit at the sequence layer that indicates if POSTPROC will be present at the picture layer.

POSTPROC - 2 bits at the picture layer that indicate:
00 = No post processing
01 = De-blocking
10 = De-ringing
11 = De-blocking and De-ringing

The de-blocking and de-ringing filters are described in Annex H.

Ron

[Sagittaire]

Post processing is part of the VC-1 standard. The bitstream syntax is:

FRMRTQ_POSTPROC - 3 bits of quantized frame rate. Frame rate = (2 + FRMRTQ_POSTPROC * 4) frames/second

BITRTQ_POSTPROC - 5 bits of quantized bitrate. Bitrate = (32 + BITRTQ_POSTPROC * 64) kbps.

POSTPROCFLAG - 1 bit at the sequence layer that indicates if POSTPROC will be present at the picture layer.

POSTPROC - 2 bits at the picture layer that indicate:
00 = No post processing
01 = De-blocking
10 = De-ringing
11 = De-blocking and De-ringing

The de-blocking and de-ringing filters are described in Annex H.

Ron


Well it's really interessing and curious. VC-1 can use different PP for each image and PP level is indicate in the bitstream. Post Process for VC-1 on windows seem doesn't work like that.

Anyway with inloop and with this bitrate (even 6 Mbps use low quantizer in most case) I think that PP0 or PP1 can be good choice here. PP1 could done very better result but only for high quantizer.


You can control post processing in WMV decoder by setting these 2 registry values (both DWORD):

"HKCU\Software\Microsoft\Scrunch\Post Process Mode"
"HKCU\Software\Microsoft\Scrunch\Force Post Process Mode"

to 0 (none), 1 (weak deblocking), 2 (strong deblocking), 3 (weak deblocking + deringing) or 4 (strong deblocking + deringing).

Yes I know very well that. I use little .exe for make that directly:
http://multimediacom.free.fr/Video/WMVPostpross.exe

Perhaps good idea for DMO filter or WMP11 because default PP4 is simply always too high for my eye. PP1 is very better for quality and PP0 very better for my CPU ... ;-)

[Manao]

drmpeg : thanks a lot.A single-pass VBR algorithm can't really take advantage of the VBV.In that case, it doesn't matter. The VBV is full just before the scene that empties it, so a two passes algorithm wouldn't have done better.

[Soulhunter]

@ Sagittaire

Why the ConvertToYV12(Source, Matrix="PC.601") line?

- Original frame (http://img106.imageshack.us/img106/3623/00501xh3.png)

- ConvertToYV12(Source, Matrix="PC.601") (http://img301.imageshack.us/img301/9206/sourceconverttoyv12sourcematrixpc601yo6.png)

As you see you get wrong levels and banding!


- ConvertToYV12(Source, Matrix="PC.709") (http://img106.imageshack.us/img106/596/sourceconverttoyv12sourcematrixpc709bk0.png)

- Direkt feed [ImageSource -> VDubMod] (http://img301.imageshack.us/img301/7879/directnh4.png)

Correct levels and no banding... ^^


Bye

[Sagittaire]

Zambelli use good argument for choose rec709 (simply because it's the official matrix for TV). There are simply little error in metric script (I made correction).