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

[Sagittaire]

The overall MPEG-2 vs VC1 graph shows MPEG-2 having a better PSNR in the majority of frames except the "difficult sequence".
Also the MPEG-2 has a wild oscillations of PSNR values along the average "imaginary" line. This is maybe due to a too high B to P frame quantizer ratio.
Adjusting the bitrate distribution and the B frames ratio for a more constant quality will deliver a much better MPEG-2 performance and IMHO it wont be too far from (if not better than) the VC-1 results.
drmpeg, could you please try re-encoding adjusting the codec settings as i just suggested?
It would be also interesting to see how MPEG-4 ASP codecs (with the same limitations) perform against the others even if they were not included in the HD-DVD/BD standard.

No it's the vbv saturation. vbv constraint for MPEG2 seem to be really a problem for HD-DVD at bitrate close to max bitrate (like for DVD). With same vbv constraint VC-1 and H264 will done always very better result in difficult part simply because efficiency is better for high quantisation level and by far. MPEG2 is a very good codec for HD but max bitrate at 30 Mbps is definitively a very bad choice for this codec ...

[trbarry]

I hope that before enthusiasm peters out in this thread somebody also does the 12 mbps tests for this clip.

This shootout was supposedly targeted at the kind of transparent quality promised on hidef DVD's, not just a very good "download" quality result. So even if 12 mbps made it hard to see the differences between codecs I think it might give more credibility in other forums. But I won't have the time to do all of these myself so I'm just hoping someone else is also going in that direction.

- Tom

[diogen]

I'm really interested to see what Ben's results will be
Time permitting, I'd like to make a version of the clip using that studio encoder (not the same as Studio Edition) later so we can see how much of a difference it makes.and this better for 6Mbps (potentially bigger difference).
I agree that having 12Mbps "for the record" in all 3 formats would be really nice.

Diogen.

[zambelli]

This shootout was supposedly targeted at the kind of transparent quality promised on hidef DVD's, not just a very good "download" quality result. So even if 12 mbps made it hard to see the differences between codecs I think it might give more credibility in other forums. But I won't have the time to do all of these myself so I'm just hoping someone else is also going in that direction.
I suppose I can kick off some 12Mbps WMV encodes over the weekend, now that I'm more or less done with the 6Mbps encodes.

[drmpeg]

I'm doing a series of MPEG-2 encodes at progressively lower average bitrates (including 12
Mbps) to try and approximately match the VC-1 PSNR at 6 Mbps average. The problem is that even though the encode only takes a few minutes with the real-time encoder, my clunky PSNR processing (on a old Sun Ultra 60) takes hours.

Ron

[drmpeg]

Also the MPEG-2 has a wild oscillations of PSNR values along the average "imaginary" line. This is maybe due to a too high B to P frame quantizer ratio.
Adjusting the bitrate distribution and the B frames ratio for a more constant quality will deliver a much better MPEG-2 performance and IMHO it wont be too far from (if not better than) the VC-1 results.
drmpeg, could you please try re-encoding adjusting the codec settings as i just suggested?

I don't have control of the frame type quantizer ratio on my encoder. It is a function of the rate control adapting to scene type. For still scenes, the RC will increase the bit budget for I-frames. During motion, the RC will decrease the I-frame bit budget.

I'll post some graphs later today that zoom in to the GOP level to show the quantizer (and PSNR) ratio better.

Ron

[crypto]

@drmpeg
Thanks for the effort. The PSNR match to VC-1 @6MBit/s is exactly what I am looking for. Is it possible to add a bitrate graph?

[benwaggoner]

I'm really interested to see what Ben's results will be
and this better for 6Mbps (potentially bigger difference).

FYI, I've just finished the 2nd of 4 back-to-back weeks on road, so I doubt I'll get this done before the end of the month.

The good news is I'll get Zambelli to teach me out to get PSNR measurements out of WMV :).

[diogen]

FYI, I've just finished the 2nd of 4 back-to-back weeks on road, so I doubt I'll get this done before the end of the month.That's fine, Ben.
As long as the recent discussion on AVS with Amir posting this (http://www.avsforum.com/avs-vb/showthread.php?p=8451144&&#post8451144) doesn't mean that the real Pro encoder can't be used anywhere outside the area it was designed to be used: encoding movies.

Diogen.

[Sharktooth]

So, we have a new contender for h.264 comparison. Nero 7.5 with the new ateme encoder was just released.

[Sagittaire]

So, we have a new contender for h.264 comparison. Nero 7.5 with the new ateme encoder was just released.

I can't set vbv with Nero ... and it's a very important limitation for HD-DVD and BD


Little and partial result from MPEG2 at 6 Mbps with libavcodec (PP4) ...

Total frames processed: 15691
Minimum Average Maximum

Y: Mean Absolute Deviation: 0.0000 14.5426 5.4035
U: Mean Absolute Deviation: 0.0000 0.8500 2.0532
V: Mean Absolute Deviation: 0.0000 0.9414 1.8740
Sum: Mean Absolute Deviation: 0.0000 27.4424 3.6867

Y: Mean Deviation: -0.7741 0.7693 0.7906
U: Mean Deviation: -0.4894 0.1497 0.6595
V: Mean Deviation: -0.4976 0.1392 0.7304
Sum: Mean Deviation: -0.5120 1.9292 0.6275

Y: Mean Square Error: 0.0000 4.8923 59.4002
U: Mean Square Error: 0.0000 0.7598 8.9637
V: Mean Square Error: 0.0000 0.8663 8.1270
Sum: Mean Square Error: 0.0000 3.5326 39.7351

Y: Root Mean Square Error: 0.0000 1.8737 7.7072
U: Root Mean Square Error: 0.0000 0.7202 2.9939
V: Root Mean Square Error: 0.0000 0.7826 2.8508
Sum: Root Mean Square Error: 0.0000 1.6165 6.3036

Y: PSNR: 30.3929 41.2356 1.#INF
U: PSNR: 38.6059 49.3237 1.#INF
V: PSNR: 39.0315 48.7542 1.#INF
Sum: PSNR: 32.1391 42.6499 1.#INF
Minimum Average Maximum

Mean Absolute Deviation: 0.0000 27.4424 3.6867
Mean Deviation: -0.5120 1.9292 0.6275
PSNR: 32.1391 42.6499 1.#INF

... with really impressive result.

[Sharktooth]

Isnt the Recode HDTV AVC profile compatible with HD-DVD/BR buffer restrictions?

[Sagittaire]

update: H264 metric result

will coming:
- MPEG2 metric result
- VC-1 metric result
- Complete encoding available for 6 Mbps and 12 Mbps
- Graph PSNR comparison between codec and analyse
- Little screenshoot comparison

Problem at this time:
- I can't make 24 Mbps encoding with VC-1 (20 Mbps limitation)
- VC-1 enconding is toooooo slow (more than 30 hours for each encoding)

[Sagittaire]

Isnt the Recode HDTV AVC profile compatible with HD-DVD/BR buffer restrictions?

No, these restriction are simply specific to "Nero Profil" ...

Anyway I have always the beta Ateme encoder or the beta Elecard encoder and I can set cpb size. But why choose another H264 encoder ... x264 done excellent result.

[zambelli]

Problem at this time:
- I can't make 24 Mbps encoding with VC-1 (20 Mbps limitation)
As it turns out, that's a limitation of WME9. Have you tried using Nic's encoder? Though I'm not sure he's updated his encoder to support all the necessary encoder options, such as buffer size, key frame distance, etc.

- VC-1 enconding is toooooo slow (more than 30 hours for each encoding)
I would recommend sticking with -v_peformance 80 or 60. Don't go to 100 - in my experience, it's just not worth the extra time.

[Sagittaire]

As it turns out, that's a limitation of WME9. Have you tried using Nic's encoder? Though I'm not sure he's updated his encoder to support all the necessary encoder options, such as buffer size, key frame distance, etc.

min keyframedist is 1 sec for Nic's encoder ... :-(

I would recommend sticking with -v_peformance 80 or 60. Don't go to 100 - in my experience, it's just not worth the extra time.

Well at first time I use "best quality" option with 2 bframe but metric result are not really good.

I want reproduce your result with your setting (-v_framerate 25 -v_performance 80 -v_bframedist 2 -v_loopfilter 1 -v_mmatch 2 -v_mslevel 4 -v_msrange 0) but it's really slow. My CPU is a simple Sempron 2.1 Ghz 32 bit (MMX, MMXExt, SSE, 3DNow, 3DNowExt).

[drmpeg]

More graphs:

http://img98.imageshack.us/img98/6940/psnr0he8.th.jpg (http://img98.imageshack.us/my.php?image=psnr0he8.jpg)

http://img146.imageshack.us/img146/8800/psnr500cv9.th.jpg (http://img146.imageshack.us/my.php?image=psnr500cv9.jpg)

http://img101.imageshack.us/img101/2771/psnr1000xv0.th.jpg (http://img101.imageshack.us/my.php?image=psnr1000xv0.jpg)

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

http://img182.imageshack.us/img182/931/psnr2000ki9.th.jpg (http://img182.imageshack.us/my.php?image=psnr2000ki9.jpg)

http://img132.imageshack.us/img132/4889/psnr2500om7.th.jpg (http://img132.imageshack.us/my.php?image=psnr2500om7.jpg)

http://img245.imageshack.us/img245/6311/psnr3000eu3.th.jpg (http://img245.imageshack.us/my.php?image=psnr3000eu3.jpg)

For those wondering, this graphing tool is an old program called xvgr running on Solaris.

Ron

[Sagittaire]

1) Very intessing graph because we can see that vbv is really a problem for MPEG2 in difficult part: VC-1 at 6 Mbps is better than MPEG2 at 24 Mbps in these part ... :eek:

2) My MPEG2 encoding (libavcodec) seem really better than your MPEG2 hardware encoding. At this time MPEG2 at 12 Mbps is little better than H264 at 6 Mbps and really better than VC-1 at 6 Mbps (for overall result)

[drmpeg]

1) Very intessing graph because we can see that vbv is really a problem for MPEG2 in difficult part: VC-1 at 6 Mbps is better than MPEG2 at 24 Mbps in these part ... :eek:

2) My MPEG2 encoding (libavcodec) seem really better than your MPEG2 hardware encoding. At this time MPEG2 at 12 Mbps is little better than H264 at 6 Mbps and really better than VC-1 at 6 Mbps (for overall result)
I'll be happy to graph your MPEG-2 results (hardware vs software encoder). I'll PM you my e-mail address.

Ron

[Sulik]

drmpeg: your MPEG-2 results seem odd. It looks like the same exact encoding, except that the 24Mbps encode was capped at a lower minimum quant.

From a codec-efficiency point of view, it would be more interesting to show RD graphs at constant quantization, to eliminate differences in rate control implementations.

[Sagittaire]

drmpeg: your MPEG-2 results seem odd. It looks like the same exact encoding, except that the 24Mbps encode was capped at a lower minimum quant.

From a codec-efficiency point of view, it would be more interesting to show RD graphs at constant quantization, to eliminate differences in rate control implementations.

Completely agree ... if you want compare codec efficiency. But HD-DVD and BD can't use constant quantization with optical speed limitation (max bitrate) and chip limitation (max buffer). Constant quant encoding is not a real scenario for HD-DVD and BD particulary with MPEG2.

This test show really good that 30 Mbps for max bitrate is a very aggressive value particulary for MPEG2 MP@HL ... :eek:

Moreover if you want compare real codec efficiency use short GOP is not a good way too but HD-DVD and BD use short GOP.

[drmpeg]

drmpeg: your MPEG-2 results seem odd. It looks like the same exact encoding, except that the 24Mbps encode was capped at a lower minimum quant.

From a codec-efficiency point of view, it would be more interesting to show RD graphs at constant quantization, to eliminate differences in rate control implementations.
They are all the same peak bitrate, 29 Mbps. So for the difficult sequence starting around frame 2800, all three encodes pin the bitrate at 29 Mbps and have the same PSNR during that sequence.

I can't do constant quant with the hardware encoder (without changing the microcode).

Ron

[trbarry]

They are all the same peak bitrate, 29 Mbps. So for the difficult sequence starting around frame 2800, all three encodes pin the bitrate at 29 Mbps and have the same PSNR during that sequence.

I can't do constant quant with the hardware encoder (without changing the microcode).

Ron

So in the really difficult sections on your charts we see the R-G-black graphs converge at the max bit rate but VC1 max rate is not necessarily hit it yet. On those places VC1 multipass processing can still steal bits from other sections to keep it below the max quant (min PSNR?), at least in those places where the blue PSNR line seems to have a smooth floor of about 40.

- Tom

[Sagittaire]

So in the really difficult sections on your charts we see the R-G-black graphs converge at the max bit rate but VC1 max rate is not necessarily hit it yet. On those places VC1 multipass processing can still steal bits from other sections to keep it below the max quant (min PSNR?), at least in those places where the blue PSNR line seems to have a smooth floor of about 40.

- Tom

I fact there are simply vbv saturation for MPEG2 in these difficult part. MPEG2 at average 24 Mbps will use always 29.4 Mbps localy and VC-1/H264 at average 6 Mbps perhaps something like 15 or 20 Mbps localy without vbv saturation.

In these difficult part MPEG2 at average 24 Mbps must use perhaps something like 40 or 50 Mbps localy to obtain constant visual quality but it's impossible in this case because MPEG2 must be compliant with hardware vbv specification.

[trbarry]

I fact there are simply vbv saturation for MPEG2 in these difficult part. MPEG2 at average 24 Mbps will use always 29.4 Mbps localy and VC-1/H264 at average 6 Mbps perhaps something like 15 or 20 Mbps localy without vbv saturation.

In these difficult part MPEG2 at average 24 Mbps must use perhaps something like 40 or 50 Mbps localy to obtain constant visual quality but it's impossible in this case because MPEG2 must be compliant with hardware vbv specification.

Yep. To fairly evaluate MPEG-2 here we might need something closer to the DL50 blu-ray specifications. I think they allow a higher max bit rate, probably with MPEG-2 originally in mind. But, for HD DVD, MPEG-2 may be limited on difficult sections of the movies.

It should still be a fair test of AVC vs VC-1 though, if it weren't for the fact that AVC encoding is sorta slow. ;)

- Tom

[drmpeg]

I just realized that I've made a mistake in my MPEG-2 versus VC-1 PSNR graphs. I'm plotting just the Y channel, while the VC-1 logs are combined YUV plots.

Personally, I think combined YUV PSNR is a bad idea. A high chroma PSNR can make the overall PSNR artificially high.

To make some more meaningful graphs, I need to modify my PSNR program to include chroma (pretty easy) or I need the VC-1 logs for Y channel only.

UPDATE: I've looked at the source code for the CompareYV12 plug-in, and I believe I've figured out the combined YUV PSNR calculation. More graphs later.

Ron

[temporance]

A critique of this test: the source used is super-clean CG with less fine-grain texture than might be found in natural video. It is my believe that this source will favor codecs with in-loop filtering. H.264's deblocking should work very well, subjectively, here. What are others' opinions of any bias inherent in this source material?

Also, did anyone try encoding with a MPEG-4 pt.2 codec, for comparison's sake?

Finally, I'd be interested in measurements of CPU load for real-time playback of the competing formats.

Sorry so many questions - I am still downloading the source and intend to run some of my own tests soon.

[Sagittaire]

A critique of this test: the source used is super-clean CG with less fine-grain texture than might be found in natural video. It is my believe that this source will favor codecs with in-loop filtering. H.264's deblocking should work very well, subjectively, here. What are others' opinions of any bias inherent in this source material?

You can if you want add artificial noise for the source and make test. This source is relatively complex and will use higher quantizer than the large majority of usual movie source. VC-1 and H264 use inloop filtering.


Also, did anyone try encoding with a MPEG-4 pt.2 codec, for comparison's sake?

MPEG4 ASP is not compliant with HD-DVD or BD. XviD at q2 will done certainely something like 15 Mbps with this source.


Finally, I'd be interested in measurements of CPU load for real-time playback of the competing formats.

I will make that too.

[Sagittaire]

To fairly evaluate MPEG-2 here we might need something closer to the DL50 blu-ray specifications. I think they allow a higher max bit rate, probably with MPEG-2 originally in mind. But, for HD DVD, MPEG-2 may be limited on difficult sections of the movies.

Well if BD use higher max bitrate then result for MPEG2 will be certainely better. Anyway it's not comparison between HD-DVD and BR. It's compararison between codec and 30 Mbps for max bitrate is compliant with BD and HD-DVD profil.

[drmpeg]

This graph shows the effect of combined YUV PSNR (and why I prefer Y only).

http://img148.imageshack.us/img148/7179/psnrtestkc9.th.jpg (http://img148.imageshack.us/my.php?image=psnrtestkc9.jpg)

In all professional PSNR plots I've seen, Y, U, and V are plotted seperately.

Ron

[Manao]

That's because it's well known people have three eyes to look at three graphs simultaneously :)

No, seriously, the less graphs, the more synthetic the data, the better.

[drmpeg]

VC-1 versus H.264 at 6 Mbps average, 29.4 Mbps peak.

http://img157.imageshack.us/img157/9062/hvc0ye5.th.jpg (http://img157.imageshack.us/my.php?image=hvc0ye5.jpg)

http://img155.imageshack.us/img155/1766/hvc3100ow4.th.jpg (http://img155.imageshack.us/my.php?image=hvc3100ow4.jpg)

http://img137.imageshack.us/img137/7886/hvc6200vy9.th.jpg (http://img137.imageshack.us/my.php?image=hvc6200vy9.jpg)

http://img143.imageshack.us/img143/2342/hvc9300yd0.th.jpg (http://img143.imageshack.us/my.php?image=hvc9300yd0.jpg)

http://img242.imageshack.us/img242/5697/hvc12400ns4.th.jpg (http://img242.imageshack.us/my.php?image=hvc12400ns4.jpg)

A zoom on the difficult sequence.

http://img134.imageshack.us/img134/5439/hvczoomfa1.th.jpg (http://img134.imageshack.us/my.php?image=hvczoomfa1.jpg)

H.264 appears to be the victor.

Ron

[benwaggoner]

VC-1 versus H.264 at 6 Mbps average, 29.4 Mbps peak.


H.264 appears to be the victor.

Now them's fighting words!

I'll provide a version using the encoder the studios use as soon as I can get to it.

[trbarry]

VC-1 versus H.264 at 6 Mbps average, 29.4 Mbps peak.

Ron -

Was that for the whole movie then? And how did you encode the H.264 version? X264?

- Tom

[zambelli]

Was that for the whole movie then? And how did you encode the H.264 version?
Yeah, can we get some more info about the H.264 encodes? I didn't see anybody post their encoding parameters or PSNR/SSIM results.

[Sagittaire]

Yeah, can we get some more info about the H.264 encodes? I didn't see anybody post their encoding parameters or PSNR/SSIM results.

Encoding are here (6 Mbps and 12 Mbps) with complete PSNR test.
http://multimediacom.free.fr/HD-DVD/H264/

I will add 5.1 audio at 448 Kbps (FAAC) in next update.

and complete CLI encoding with x264:

D:\Mes dossiers\Codec\x264>x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 294
00 --vbv-bufsize 9500 --qpmin 15 --level 4.1 --bframe 2 --b-rdo --bime --weightb
--ref 2 --mixed-refs --direct auto --filter -1:-1 --bitrate 6000 --pass 3 --sta
ts "H264_6Mbps.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 --pro
gress -o H264_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:21.54 size:101388 PSNR Mean Y:48.49 U:58.52
V:57.12 Avg:49.44 Global:47.12
x264 [info]: slice P:6863 Avg QP:22.09 size: 38060 PSNR Mean Y:47.79 U:57.40
V:56.12 Avg:48.77 Global:46.46
x264 [info]: slice B:7691 Avg QP:23.74 size: 12251 PSNR Mean Y:47.28 U:59.93
V:58.14 Avg:48.38 Global:45.69
x264 [info]: mb I I16..4: 42.1% 40.5% 17.5%
x264 [info]: mb P I16..4: 11.7% 11.4% 2.4% P16..4: 30.4% 7.0% 3.0% 0.4% 0
.2% skip:33.5%
x264 [info]: mb B I16..4: 0.8% 1.4% 0.4% B16..8: 9.7% 1.2% 2.4% direct:
1.8% skip:82.2%
x264 [info]: 8x8 transform intra:43.6% inter:52.3%
x264 [info]: direct mvs spatial:74.5% temporal:25.5%
x264 [info]: ref P 80.1% 19.9%
x264 [info]: ref B 81.4% 18.6%
x264 [info]: SSIM Mean Y:0.9877791
x264 [info]: PSNR Mean Y:47.594 U:58.723 V:57.181 Avg:48.631 Global:46.110 kb/s:
5999.69

encoded 15691 frames, 1.25 fps, 6000.75 kb/s



D:\Mes dossiers\Codec\x264>x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 294
00 --vbv-bufsize 9500 --qpmin 10 --level 4.1 --bframe 2 --b-rdo --bime --weightb
--ref 2 --mixed-refs --direct auto --filter -1:-1 --bitrate 12000 --pass 3 --st
ats "H264_12Mbps.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 --p
rogress -o H264_12Mbps.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:15.82 size:174253 PSNR Mean Y:52.20 U:59.78
V:58.49 Avg:52.88 Global:50.57
x264 [info]: slice P:6861 Avg QP:16.29 size: 75734 PSNR Mean Y:51.29 U:58.75
V:57.58 Avg:52.04 Global:49.72
x264 [info]: slice B:7695 Avg QP:17.91 size: 29115 PSNR Mean Y:50.98 U:61.27
V:59.60 Avg:51.90 Global:49.13
x264 [info]: mb I I16..4: 32.9% 39.9% 27.2%
x264 [info]: mb P I16..4: 9.0% 13.3% 4.7% P16..4: 30.5% 11.2% 5.4% 0.8% 0
.6% skip:24.6%
x264 [info]: mb B I16..4: 0.8% 1.8% 0.7% B16..8: 13.3% 2.1% 4.3% direct:
4.1% skip:73.0%
x264 [info]: 8x8 transform intra:46.2% inter:35.9%
x264 [info]: direct mvs spatial:84.4% temporal:15.6%
x264 [info]: ref P 81.8% 18.2%
x264 [info]: ref B 80.8% 19.2%
x264 [info]: SSIM Mean Y:0.9935051
x264 [info]: PSNR Mean Y:51.205 U:60.059 V:58.637 Avg:52.031 Global:49.473 kb/s:
11999.59

encoded 15691 frames, 0.95 fps, 12000.61 kb/s



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:10.04 size:294208 PSNR Mean Y:55.88 U:62.04
V:60.79 Avg:56.44 Global:54.40
x264 [info]: slice P:6865 Avg QP:10.42 size:152867 PSNR Mean Y:54.77 U:60.67
V:59.54 Avg:55.36 Global:53.47
x264 [info]: slice B:7691 Avg QP:12.02 size: 65113 PSNR Mean Y:54.50 U:62.84
V:61.19 Avg:55.23 Global:52.79
x264 [info]: mb I I16..4: 24.7% 37.9% 37.5%
x264 [info]: mb P I16..4: 5.1% 12.7% 8.6% P16..4: 27.2% 15.0% 8.6% 1.3% 1
.5% skip:19.9%
x264 [info]: mb B I16..4: 0.6% 1.8% 1.5% B16..8: 16.3% 3.7% 7.8% direct:
5.8% skip:62.5%
x264 [info]: 8x8 transform intra:44.3% inter:32.2%
x264 [info]: direct mvs spatial:86.5% temporal:13.5%
x264 [info]: ref P 80.7% 19.3%
x264 [info]: ref B 80.4% 19.6%
x264 [info]: SSIM Mean Y:0.9967382
x264 [info]: PSNR Mean Y:54.716 U:61.831 V:60.440 Avg:55.379 Global:53.179 kb/s:
24015.59

encoded 15691 frames, 0.73 fps, 24016.60 kb/s

[trbarry]

Sagittaire -

Very impressive. You even did the 12 mbps test I was hoping for. I have to think about this some more. ;)

- Tom

[Sagittaire]

Sagittaire -

Very impressive. You even did the 12 mbps test I was hoping for. I have to think about this some more. ;)

- Tom

In fact the real surprise is the Libavcodec quality for MPEG2 ...

http://multimediacom.free.fr/HD-DVD/H264vsMPEG2_GraphPSNR_M.PNG (http://multimediacom.free.fr/HD-DVD/H264vsMPEG2_GraphPSNR.PNG)

http://multimediacom.free.fr/HD-DVD/H264vsMPEG2_GraphPSNR2_M.PNG (http://multimediacom.free.fr/HD-DVD/H264vsMPEG2_GraphPSNR2.PNG)

... if you observe pure coding efficiency (without vbv stauration) H264 at half bitrate is unable to beat MPEG2 and I use in practice extreme quality for H264 with perhaps the best H264 encoder (or not so far).


Anyway with vbv restriction quality for H264 at half bitrate is really more constant ...

[trbarry]

... if you observe pure coding efficiency (without vbv stauration) H264 at half bitrate is unable to beat MPEG2 and I use in practice extreme quality for H264 with perhaps the best H264 encoder (or not so far).

Anyway with vbv restriction quality for H264 at half bitrate is really more constant ...


I wonder if in those areas with PSNR < 45 or so both codecs are bumping up against the max bit rate. Is there any easy way to tell? If so then the extra constancy of X264 might really just be the better (lower) ratio of its average to max bit rate.

- Tom

[skal]

Hi Sagittaire and all,


and complete CLI encoding with x264:

D:\Mes dossiers\Codec\x264>x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 29400 --vbv-bufsize 9500 --qpmin 15 --level 4.1 --bframe 2 --b-rdo --bime --weightb
--ref 2 --mixed-refs --direct auto --filter -1:-1 --bitrate 6000 --pass 3 --sta
ts "H264_6Mbps.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 --progress -o H264_6Mbps.mp4 azerty.avs


maybe there's room for even more juice if you have some spare CPU:
--ref 3 --subme 7 --trellis 2 (--me "umh" ? "esa" even ?!?)
just some ideas...

[Sharktooth]

well, --filter 0:0 should be also better for PSNR...
however i have my doubts about --no-dct-decimate.

[drmpeg]

Just so that everyone has access to all the material, here's the VC-1 logs from Zambelli:

http://www.w6rz.net/Elephant_1080p25_6Mbps_B1_P80_Loop1_MM2_MSL4_MSR0.PSNR.log
http://www.w6rz.net/Elephant_1080p25_6Mbps_B1_P80_Loop1_MM2_MSL4_MSR0.SSIM.csv
http://www.w6rz.net/Elephant_1080p25_6Mbps_B2_P60_Loop1_MM2_MSL4_MSR0_MVC1_DQO1.PSNR.log
http://www.w6rz.net/Elephant_1080p25_6Mbps_B2_P60_Loop1_MM2_MSL4_MSR0_MVC1_DQO1.SSIM.csv
http://www.w6rz.net/Elephant_1080p25_6Mbps_B2_P60_MM2_MSL4_MSR0.PSNR.log
http://www.w6rz.net/Elephant_1080p25_6Mbps_B2_P60_MM2_MSL4_MSR0.SSIM.csv
http://www.w6rz.net/Elephant_1080p25_6Mbps_B2_P80_Loop1_MM2_MSL4_MSR0.PSNR.log
http://www.w6rz.net/Elephant_1080p25_6Mbps_B2_P80_Loop1_MM2_MSL4_MSR0.SSIM.csv

Ron

[Sharktooth]

It would be interesting to see the difference between MPEG-4 ASP encoders (xvid/divx/lavc...) and VC-1 with the same limitations. Just to see if VC-1 is a real advancement over MPEG-4 ASP. What would have happened if MPEG-4 ASP was choosen in place of VC-1?

[drmpeg]

Here's a graph comparing PSNR versus SSIM for a VC-1 clip. SSIM is scaled and offset to fit the graph.

http://img82.imageshack.us/img82/8962/pssvu3.th.jpg (http://img82.imageshack.us/my.php?image=pssvu3.jpg)

PSNR and SSIM seem pretty well correlated except for the credit roll at the end.

Ron

[GodofaGap]

however i have my doubts about --no-dct-decimate.
From my tests it is usually an improvement, certainly with trellis enabled.

Also, how are these streams going to be verified for compliancy? IMHO, only relying on a codec to respect the settings is not enough.

[zambelli]

Also, how are these streams going to be verified for compliancy? IMHO, only relying on a codec to respect the settings is not enough.
They won't be. We've pretty much concluded early in the thread that we have no way of guaranteeing any of the encoders are HD-DVD compliant, nor that we fully understand all the parameters that define HD-DVD bitstreams. So even though the encoding parameters are an attempt to make them HD-DVD/BD compliant... they're more like just guidelines at this point.

(Don't get me wrong: Microsoft has a VC-1 encoder that's fully HD-DVD compliant, but I haven't used it in this competition so far. And even if I did, we still have no proof x264 or any of the MPEG-2 encoders are fully compliant, so insisting on true compliance seems irrelevant.)

[Manao]

Imho, the only thing that matters and need checking is VBV compliancy. Allowed tools ( xf8x8, p4x4, custom matrices... ) are known and can easily be respected by the encoders.

Bitstream element order has no impact whatsoever on the quality so we don't have to care about it ( though it plays a major part in HDDVD/BD compliancy )

VBV compliancy can relatively easily be checked by external means, but alas those tools aren't necessarily easily available.

[GodofaGap]

Imho, the only thing that matters and need checking is VBV compliancy. Allowed tools ( xf8x8, p4x4, custom matrices... ) are known and can easily be respected by the encoders.
I was aiming at VBV compliancy. Especially when results are judged by per frame PSNR/SSIM, this seems essential to me.

[Dethis]

Starting from 1:47 and playing frame by frame (right arrow) with MPC 6.4.9.0 (internal MP4 splitter) at 1:52-1:53 (min:sec) MPC's stats display shows :

Buffers: 036/5271 KB (p0)
bitrate: 15670/33439 Kbps (avg/cur)

File : H264_6Mbps_final.mp4 by Sagittaire

Is this HD-DVD compliant ??

At second attempt with Haali's graphic vbv display i see max:34121. The clip plays back at about 16 fps (cpu P4 2.4/1024MB ram)

[drmpeg]

Starting from 1:47 and playing frame by frame (right arrow) with MPC 6.4.9.0 (internal MP4 splitter) at 1:52-1:53 (min:sec) MPC's stats display shows :

Buffers: 036/5271 KB (p0)
bitrate: 15670/33439 Kbps (avg/cur)

File : H264_6Mbps_final.mp4 by Sagittaire

Is this HD-DVD compliant ??
That's a very good question. It all depends on how you define "Peak Bitrate".

For example, on my MPEG-2 encodes with the real-time encoder, I purposely set the peak bitrate lower in the UI. Instead of 29.4 Mbps, I used 26 Mbps (if you look at the sequence_header on my 18 Mbps ABR 29.97 fps with telecine flags test clip http://www.w6rz.net/ed.zip, you'll see it's 26 Mbps). That's because when I graphed the bitrate, I used bits per frame with a running average over 24 frames (1 second). I also wanted folks to be able to burn the clip to DVD-R without problems (although I've never received any feedback on that).

In other words, no matter what, the bitrate of any 1 second chunk of the bitstream is less than 29 Mbps.

Did I penalize myself unnesessarily? Maybe. I just don't have a perfect concept of the blue laser drive bitstream delivery rate, demuxing buffer levels and the elementary video stream decoders VBV. So I chose the possibly too conservative bitrate over any 1 second approach.

I do know basic the numbers. For HD-DVD, the disk fills the track buffer at 36.55 Mbps, but the maximum multiplex bitrate is 30.24 Mbps (of which 29.4 Mbps can be video). For Blu-ray it's 54 Mbps into the track buffer and 48 Mbps maximum multiplex rate (of which 40 Mbps can be video).

I'll guess there's some professional bitstream verifiers available for both formats, but not to hobbyists. Maybe future hobbyist level authoring tools will verify the peak bitrate.

Another thing to consider is that real HD-DVD's contain multiple audio tracks (some of which are relatively high bitrate) and PIP secondary video. On AVSForum, one of the compressionists is claiming that full featured HD-DVD disks have the primary video peak bitrate capped at 19 Mbps. So coding with 29.4 Mbps peak bitrate may not be something that happens in the real world of HD-DVD authoring.

Ron