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

Sagittaire

19th August 2006, 14:44

~ HD-DVD Benchmark Challenge ~

You think that your standard is the best : prove that ... !!?

A - Introduction

The purpose of this challenge is to determine which is the best codec format encoding.
HD-DVD & BD can use MPEG2, H264 and VC-1 for video codec.

B - Rules

Rule 1 : Source

Uncompressed source is available Here (http://orange.blender.org/blog/original-lossless-source-available/) for reproduce the test.
Open source Elephant Dream movie, video 1920*1080 PNG lossless, audio 5.1 Flac lossless, 15 691 frames

Rule 2 : Pre-process and encoding

You must use this avisynth script for make encoding:

Source=ImageSource("C:\LossLess\images\%05d.png", start=1, end=15691, fps=23.976)
Source=ConvertToYV12(source, matrix="Rec709")
return source

Other pre-process is not autorized. It's possible to propose example with high quality pre-process (objective like high color conversion or subjective like sharp process ... ect) but just for demonstration and not for this challenge.

Video Stream must be like HD-DVD compliant stream. You can use all the compliant audio codec and all the compliant bitrate for audio. This test is just video challenge and not audio challenge. All the video stream must be compliant with these setting:

MPEG2 Encoding
Profil & Level: MP@HL except specific restrictions
Max GOP lenght: 14 frames
Maximum bitrate: 20.0 Mbps, 24.0 Mbps and 28.0 Mbps
Buffer size: 9781 Kbits for principal HD video stream
Horizontal Vector Range: +/- 1024 pixels
Vertical Vector Range: +/- 128 pixels
Other Restrictions Setting: max adaptative GOP at 14, max adaptative bframe at 2

VC-1 Encoding
Profil & Level: AP@L3 except specific restrictions
Max GOP lenght: 14 frames
Maximum bitrate: 20.0 Mbps, 24.0 Mbps and 28.0 Mbps
Buffer size: 14745 Kbits for principal HD video stream
Horizontal Vector Range: +/- 1024 pixels
Vertical Vector Range: +/- 256 pixels
Other Restrictions Setting: max adaptative GOP at 14, max adaptative bframe at 2

H264 Encoding
Profil & Level: HP@L4.1 except specific restrictions
Max GOP lenght: 14 frames
Maximum bitrate: 20.0 Mbps, 24.0 Mbps and 28.0 Mbps
Buffer size: 14745 Kbits for principal HD video stream
Horizontal Vector Range: +/- 1024 pixels
Vertical Vector Range: +/- 512 pixels
Other Restrictions Setting: max adaptative GOP at 14, max adaptative bframe at 2,
Max reference at 4, Max breference at 3, no film grain modeling

Rule 3 : Bitrate and Max Bitrate

You must use these bitrate/size for encoding:

HD-DVD with "super bitrate" video stream and simple HDDVD authoring:
18 Mbps (Max at 28.0 Mbps) for video stream with +/- 0.5 % for bitrate tolerance
HD-DVD with "medium bitrate" video stream and standard HDDVD authoring:
12 Mbps (Max at 24.0 Mbps) for video stream with +/- 0.5 % for bitrate tolerance
HD-DVD with "low bitrate" video stream and standard HDDVD authoring:
6 Mbps (Max at 20.0 Mbps) for video stream with +/- 0.5 % for bitrate tolerance

NB: we can use HD-DVD structure too on simple DVD DL 12 cm at 8.5 GB

Rule 4 : Visual Tests

Here you can find encoding in ifo & evo structure for subjective test ... try to find yourself the best quality:

HD-DVD & BD MPEG2 at 18 Mbps :
File: not available

HD-DVD & BD MPEG2 at 12 Mbps :
File: not available

HD-DVD & BD MPEG2 at 6 Mbps :
File: not available

HD-DVD & BD VC-1 at 18 Mbps :
File: not available

HD-DVD & BD VC-1 at 12 Mbps :
File: not available

HD-DVD & BD VC-1 at 6 Mbps :
File: not available

HD-DVD & BD H264 at 18 Mbps :
File: not available

HD-DVD & BD H264 at 12 Mbps :
File: not available

HD-DVD & BD H264 at 6 Mbps :
File: not available

Rule 5 : Metrics Tests

SSIM (YV12): IMO the best metric. it uses some HVS properties but not all ...
PDF description for VSSIM (http://www.cns.nyu.edu/~zwang/files/papers/vssim.pdf)

Overall PSNR (YV12): Very good metric test, particullary for Rate Control Quality test ...
MSE = Sum t = 1 -> NFrame Sum x = 1 -> width Sum y = 1 -> height (F'(x,y,t)-F(x,y,t))² / (NFrame*width*height)
Overall PSNR = 10 * Log ( 255² / MSE)

Average PSNR (YV12):The worse metric test but Frame PSNR graph is very good to compare RC strategy ...
MSE = Sum x = 1 -> width Sum y = 1 -> height (F'(x,y,t)-F(x,y,t))² / (width*height)
Average PSNR = Sum t = 1 -> NFrame 10 * Log ( 255² / MSE) / Nframe

SSIM vs PSNR

"For a given reference video and a given compressed video, it is meant to compute a quality metric, based on perceived visual distortion. Unlike the well-known PSNR measure, it's not purely mathematical, and should correlate much better with human vision."

"A higher MSE (and so lower PSNR) should mean that the compressed clip is a worse image but MSE and PSNR are flawed in this respect as numerous tests have shown. However with SSIM, according to tests carried out on the VQEG dataset, a higher Q (SSIM value) has a much better relation to the visual quality of the compressed clip. Despite this, bear in mind the SSIM metric still isn't perfect."

Here (http://multimediacom.free.fr/Download/SSIM.rar) last AviSynth plugin for VSSIM in YV12

Average PSNR vs Overall PSNR

It's easy to increase artificially Average PSNR with Rate Control tweak. In certain case CBR (0% for variability) will be better than real VBR (100% for variability or constant quant). It's generaly not possible with Overall PSNR. Overall PSNR is very good to test Rate Control quality. If difference between Average PSNR and Overall PSNR is very high, "local quality difference" (difference between Pframe or Bframe for exemple) or "scene quality difference" (difference between low motion and high motion for exemple) will be too high and Rate Control for this codec not very good.

Here (http://multimediacom.free.fr/Download/CompareYV12.zip) last AviSynth plugin for Overall PSNR in YV12

Open your avs metric script with VirtualDub. Select file > preview input for run the test. Select file > close video file for obtain final result in log metric files. You must use these AviSynth type script for metric test:

# --> Source Opening <--
Source=ImageSource("C:\LossLess\images\%05d.png", start=1, end=15691, fps=24)
Source=ConvertToYV12(source, matrix="Rec709")

# --> Video Opening <--
video=Mpeg2Source("D:\...\MPEG2_24Mbps.d2v",idct=2)

# --> PSNR analysis <--
compareYV12(video,source,"YUV","OPSNR_MPEG2_24Mbps.log")

# --> Source Opening <--
Source=ImageSource("C:\LossLess\images\%05d.png", start=1, end=15691, fps=24)
Source=ConvertToYV12(source, matrix="Rec709")

# --> Video Opening <--
video=Mpeg2Source("D:\...\MPEG2_24Mbps.d2v",idct=2)

# --> SSIM analysis <--
return SSIM(source,video,"results.csv","SSIM_MPEG2_24Mbps.txt",lumimask=2)

C - Results

At this time here the best result ... but done better if you can ... :devil:

|--------------|---------|---------|---------|---------|---------|
| Codec | PProc | Bitrate | Size | OPSNR | SSIM 2 |
|--------------|---------|---------|---------|---------|---------|
| MPEG2 | PP4 | 0000 | 0000 | 00.00 | 00.00 |
| VC-1 | PP1 | 0000 | 0000 | 00.00 | 00.00 |
| H264 | PP0 | 0000 | 0000 | 00.00 | 00.00 |
|--------------|---------|---------|---------|---------|---------|
| MPEG2 | PP4 | 00000 | 0000 | 00.00 | 00.00 |
| VC-1 | PP1 | 00000 | 0000 | 00.00 | 00.00 |
| H264 | PP0 | 00000 | 0000 | 00.00 | 00.00 |
|--------------|---------|---------|---------|---------|---------|
| MPEG2 | PP4 | 00000 | 0000 | 00.00 | 00.00 |
| VC-1 | PP1 | 00000 | 0000 | 00.00 | 00.00 |
| H264 | PP0 | 00000 | 0000 | 00.00 | 00.00 |
|--------------|---------|---------|---------|---------|---------|
SSIM 0: Lumimask Off
SSIM 1: Lumimask On (Original Lumimask)
SSIM 2: Lumimask On (One2Tech Patch)

D - Conclusion

At this time for this movie

THE BEST IS ??????????

IF YOU DON'T AGREE WITH THAT, TRY WITH YOUR ENCODER ... !!!

Annexe - Update

01.07.2007 - NTSC setting for encoding replace PAL setting
26.10.2006 - New rules for more real HDDVD encoding (new bitrate, new vbv)
03.10.2006 - buffer for H264 is confidential but use 14400 Kbits is certainely compliant with HDDVD
02.10.2006 - official buffer for VC1 is 14400 Kbits or 480 ms for better HD-DVD compliancy
26.09.2006 - MPEG2 and H264 files with audio are available
19.09.2006 - MPEG2 metric result
18.09.2006 - H264 metric result

will coming ... if you want ... !!!

All the developpers are wellcome ... !!?

scharfis_brain

19th August 2006, 14:58

Source=ImageSource("C:\LossLess\images\%05d.png", start=1, end=15691, fps=24)
Source=ConvertToYV12(source, matrix=whatever)
return source

I think that this is only a good solution for encoders that will accept YV12 without internal conversion.

MPEG2 encoders for example commonly only accept YUY2 or RGB24 input. If YV12 is given to the encoder it either throws an error or converts it to YUY2 using DShow (or something) and then converts it to YV12 again. This results in blurring the chroma in vertical.
The only MPEG2 Encoders I know of that accept YV12 without conversion are HCEnc and QuEnc.
CCE and ProCoder will only work with YUY2. As well as TMPGenc does.

So I suggest to use
Source=ImageSource("C:\LossLess\images\%05d.png", start=1, end=15691, fps=24)
Source=ConvertToYUY2(source, matrix=whatever)
return source with CCE, ProCoder, TMPGenc and other encoders that do not accept YV12 natively.

Sagittaire

19th August 2006, 15:36

Source=ImageSource("C:\LossLess\images\%05d.png", start=1, end=15691, fps=24)
Source=ConvertToYV12(source, matrix="PC.601")
return source

I think that this is only a good solution for encoders that will accept YV12 without internal conversion.

MPEG2 encoders for example commonly only accept YUY2 or RGB24 input. If YV12 is given to the encoder it either throws an error or converts it to YUY2 using DShow (or something) and then converts it to YV12 again. This results in blurring the chroma in vertical.
The only MPEG2 Encoders I know of that accept YV12 without conversion are HCEnc and QuEnc.
CCE and ProCoder will only work with YUY2. As well as TMPGenc does.

So I suggest to use
Source=ImageSource("C:\LossLess\images\%05d.png", start=1, end=15691, fps=24)
Source=ConvertToYUY2(source, matrix="PC.601")
return source with CCE, ProCoder, TMPGenc and other encoders that do not accept YV12 natively.

Well but H264 and VC-1 encoder will use internal YV12 color convertion in this case. MPEG2 MP@HL, VC-1 and H264 use internal YV12 color space ... source must be YV12. It's not my problem if Procoder, CCE or other encoder don't use YV12 input ... ;-)

I will make HD-DVD MPEG2 encoding with Mencoder ... ;-)

Kopernikus

19th August 2006, 15:54

Its not a blind test if the testers know which encoder created the file and how much bitrate was used.

Golgot13

19th August 2006, 15:54

Well but H264 and VC-1 encoder will use internal YV12 color convertion in this case. MPEG2 MP@HL, VC-1 and H264 use internal YV12 color space ... source must be YV12. It's not my problem if Procoder, CCE or other encoder don't use YV12 input ... ;-)

Hi,

I think the size resolution is locked.
Because MPEG2 and VC1 at 6Mbps with 1920x1080 resolution, it will be very hard.
And there is not a limit for encoding pass.
(NTT Docomo have N-pass H264 encoder => 2.8Mbps for video
at 1920x1080 24fps, thirteen pass and one pass isn't in realtime...)

Golgot13

Sagittaire

19th August 2006, 16:20

Its not a blind test if the testers know which encoder created the file and how much bitrate was used.

The files will be here if you want make blind test for you.

I think the size resolution is locked.
Because MPEG2 and VC1 at 6Mbps with 1920x1080 resolution, it will be very hard.

Perhaps for MPEG2 but perhaps not for VC-1.

And there is not a limit for encoding pass.
(NTT Docomo have N-pass H264 encoder => 2.8Mbps for video
at 1920x1080 24fps, thirteen pass and one pass isn't in realtime...)

File must be compliant ... you can make 99 pass with CCE or 999 pass with x264 if you want. I can make 2.8 Mbps encoding with all encoder but IMO make 2.8 Mbps with good quality with this source will be really hard. Time encoding is not a problem in this test.

scharfis_brain

19th August 2006, 18:38

SeeMoreDigital

19th August 2006, 18:53

I must admit I would be interested to know how well MPEG-4 AVC's "lossless" encoding option would cope with these sources.... If anybody is up for it?

By-the-way, does VC-1 have a "lossless" encoding option?

Cheers

Sagittaire

19th August 2006, 20:08

@Sagittaire: I think you're aiming for high quality?
So why do you forbit YUY2 when needed for good quality?
Some encoders even won't accept YV12 and will refuse to encode the video. So you'll knock out valuable encoders in this Benchmark Challange!

I think to stick with YUY2 and correct colorimetry will be enough.
Converting from RGB->YUY2->YV12 is a transparent process.
Converting from RGB->YV12->YUY2->YV12 isn't.

Well it's really not a problem ... use YUY2 conversion or initial RGB colors for these encoders if you want if you are sure that internal YUY2, RGB -> YV12 is high quality space convertion. But reference source will be in YV12 for make comparison ...

lexor

19th August 2006, 20:43

I get a message saying that torrent is invalid, is anyone else having trouble getting it to work?

Dethis

19th August 2006, 22:25

@Sagittaire

a) What about the HD-DVD restictions like max (peak) video bitrate (29Mbps) and others (GOP size, reference B frames.. etc) we read about (I realy dont know if those "others" exist because of the HD-DVD format or the decoding chip.)

b) Isn't this test a good opportunity to to compare HD-DVD vs BD ??. Like in the following case:
Todays bests -> HD-DVD DL(30GB, 29Mbps peak video bitrate) VS BD SL (25GB 40Mbps peak video bitrate)
This will need one more category for BD (20Mbps average video bitrate with peaks up to 40Mbps).

Sagittaire

19th August 2006, 22:41

a) What about the HD-DVD restictions like max (peak) video bitrate (29Mbps) and others (GOP size, reference B frames.. etc) we read about (I realy dont know if those "others" exist because of the HD-DVD format or the decoding chip.)

Well at this time I use
adaptative GOP 15 with 2 adaptative bframe
Buffer size at 448 Ko, max bitrate at 30 000 Kbps
Max motion vector at +/- 128 pixel

b) Isn't this test a good opportunity to to compare HD-DVD vs BD ??. Like in the following case:
Todays bests -> HD-DVD DL(30GB, 29Mbps peak video bitrate) VS BD SL (25GB 40Mbps peak video bitrate)
This will need one more category for BD (20Mbps average video bitrate with peaks up to 40Mbps).

Well really good question. because for this source I have big problem for peak bitrate in high motion for MPEG2. 30 Mbps max bitrate seem not to be enough: I have buffer saturation for long high motion scene and very high average quantizer because encoder must respect vbv specification ... !!?

GodofaGap

19th August 2006, 23:19

With which tool(s) are the streams going to be verified for HD-DVD compliancy and what are the HD-DVD requirements?

IgorC

20th August 2006, 01:14

Just remebering that Blu Ray has 4 reference frames limit for H.264

CruNcher

20th August 2006, 04:26

x264 cant be used here as it isn't Broadcast stable and exactly that is needed here for STB/SAP Encoding, what this test is about :(
so we only have 2 options Ateme (wich most of the users here only have the very outdated Beta) or Elecard/Mainconcepts Encoder wich would obey to the Hardware limits needed for this test.
Im sure that Atemes outdated Beta can't cope anymore with Elecard/Mainconcepts Encoder and also it's rather useless to test such stuff as HD-DVD H.264 encoding won't be available still for some time now for most average users their only option @ the moment is Mpeg-2 HD-DVD, and no i have no idea how much longer the industry is holding H.264 HD-DVD encoding back from the average joe user, my guess is end of this year begining next year.

akupenguin

20th August 2006, 04:32

x264 cant be used here as it isn't broadcast stable and exactly that is needed here for STB Encoding what this test is about
What does "broadcast stable" mean? And exactly what restrictions do STBs impose that can't be configured in x264?

Quarkboy

20th August 2006, 06:38

Just remebering that Blu Ray has 4 reference frames limit for H.264

Wait, really? It's not fully h.264 spec compliant? Can I get a reference for this?

Sagittaire

20th August 2006, 09:51

What does "broadcast stable" mean? And exactly what restrictions do STBs impose that can't be configured in x264?

Why not to prove that and make HD-DVD authoring with x264 ... ;-)

GodofaGap

20th August 2006, 10:11

Ok I'll repeat my question.

Rule 2 : Pre-process and encoding

...

Video Stream must be HD-DVD compliant stream. You can use all the complaint audio codec and all the compliant bitrate for audio. This test is just video challenge and not audio challenge. anyway all the stream must be HD-DVD complaint.
You say it must be compliant, but you do not provide any means to check that nor do you disclose what compliant is. So which tools to check with, and what IS compliant exactly anyway?

Sagittaire

20th August 2006, 10:40

Ok I'll repeat my question.

You say it must be compliant, but you do not provide any means to check that nor do you disclose what compliant is. So which tools to check with, and what IS compliant exactly anyway?

Like for MPEG2 DVD stream ... ;-)

GodofaGap

20th August 2006, 11:04

?

It is not an answer to my question. You cannot use a DVD verifying tool to check an h264 HD-DVD stream, it's nonsense.

Manao

20th August 2006, 12:15

Sagittaire : instead of saying "the stream must be HD DVD-compliant", which nobody here knows what it implies ( not even you ), you should state clearly the restrictions on the options that can be used for each standard.

Restrictions that are really important are :
- gop structure
- average bitrate, max bitrate, cpb/vbv size
- allowed profile / level
- specific restrictions ( number of references / no breferences / custom matrices / motion range / whatever )

Those are easy to check ( except cpb/vbv compliancy ), and they are those that have an impact on the quality.

"HD DVD compliancy", however, implies a lot more than that. It requests, for example, that some SEI messages in h264 must be present in the bitstream. Moreover, those SEI must be put in the right order ( and guess what, the order and the SEIs differ from Blueray's - what a surprise... ). x264 can't - at the moment - respect that, but it's not important to the purpose of your test, since you care about quality.

QuarkBoy : it's not a question of being "h264-compliant". Bluray and HD DVD take a bunch of standards ( AVC, mpeg2 system, mpeg2 video, dolby ), and impose strictly how they must be used together. They impose for example a profile/level for AVC, but nothing prevent them for imposing some additionnal restrictions over those brought by the profile/level - for example a max number of references. The resulting video stream is still compliant with the AVC standard. The only "incompliancy" would occur if a decoder that boasted Blueray compliancy but didn't support more than 4 references would also boast AVC compliancy.

smok3

20th August 2006, 12:31

so where do we 'mail' our encodes?

Taxidermista

20th August 2006, 15:35

Talking about HD-DVD compliancy, I guess that this 'HD DVD content validator' from Microsoft is of no use, isn't it?

Start authoring in HD-DVD (http://www.microsoft.com/windows/windowsmedia/forpros/hddvd/default.aspx)

BTW, has anybody any success downloading the Elephants Dream torrent?

smok3

20th August 2006, 16:32

why not use the tools out there for cross verification?

- Final Cut Studio Pro (on mac side)
- Sonic DVD Producer HD (for wmv ...)
- Sonic Scenarist HD (for h.264)
- There is also a Sonic solution for BR

iam sure someone allready purchased some of this?

bond

20th August 2006, 16:50

moved

*.mp4 guy

20th August 2006, 17:07

BTW, has anybody any success downloading the Elephants Dream torrent?
Most torrent clients can't open the torrent because it has to many files (I ran into this problem myself) the only torrent client I could find that will work is Azureus, which is an open source java client, so it should work for any OS.

so where do we 'mail' our encodes?
at 24mbps the file should be ~2GB, at 12 it should be ~1GB, at 6mbps it should be 500MB. The best way to deliver the files would probably be to create another torrent, it shouldn't be too dificult to figure out, and torrents work great for large files like Linux iso's.

Taxidermista

20th August 2006, 19:27

akupenguin

21st August 2006, 03:52

Why not to prove that and make HD-DVD authoring with x264
I asked a question. You don't prove a question, you answer it. And if I knew the answer, I wouldn't be asking.
Anyway, I don't see what broadcast has to do with HD-DVD.

I must admit I would be interested to know how well MPEG-4 AVC's "lossless" encoding option would cope with these sources.... If anybody is up for it?
(I haven't downloaded the whole source yet, so this is based on 1000 frames from the middle...)
kbit/s codec
1194394 raw rgb
380190 png rgb
260014 ffv1 rgb
125451 ffv1 yv12
112775 x264 yv12

lexor

21st August 2006, 04:24

Most torrent clients can't open the torrent because it has to many files (I ran into this problem myself) the only torrent client I could find that will work is Azureus, which is an open source java client, so it should work for any OS.
the odd thing is that the lower res version has the same number of files, but it loads just fine, I think the size plays a role too... I so don't want to install Az :angry:

IgorC

21st August 2006, 04:32

Very little, fast and full featured Torrent client
http://www.utorrent.com/download.php 170 Kb . Without instalation :p

bkman

21st August 2006, 04:46

Very little, fast and full featured Torrent client
http://www.utorrent.com/download.php 170 Kb . Without instalation :p

Doesn't open the elephant torrent, however. Probably partly due to the stupid way it was made; a torrent that size shouldn't be using 256K blocks, but rather 4MB.

Sagittaire

21st August 2006, 12:52

You want direct link for FFV1 YV12 uncompressed source ... ???

smok3

21st August 2006, 12:59

i did a http download (firewall issues dont let me use the torrents) using wackget, just copy/paste 1000 frames at once (and no more) and you should be fine (also limit # of downloads to like 5-10 at time only).

http://millweed.com/projects/wackget/

lexor

21st August 2006, 14:04

Very little, fast and full featured Torrent client
http://www.utorrent.com/download.php 170 Kb . Without instalation :p
that's what I'm using. uTorrent and Az are the only two clients that I can use. You telling me the 1080 torrent works for you with uT?

Sharktooth

21st August 2006, 21:18

BitComet can handle it too.

bkman

22nd August 2006, 14:48

Sagittaire

22nd August 2006, 15:09

@Sagittaire:

I've downloaded some frames from the movie, and it is a bit of a contrived material to use as a source, don't you think?

I mean, there is no grain whatsoever as you would see in most movies, and even the motion blur that is present in even professional computer animation is absent.

1) Well it's the master for this movie.

2) Blender renderer use motion blur for this movie.

bkman

22nd August 2006, 15:39

1) Well it's the master for this movie.

2) Blender renderer use motion blur for this movie.

1: Only digitally filmed movies will have masters this clean

2: I didn't see much in the small sample I've downloaded, but you may be right.

lexor

22nd August 2006, 16:03

@Sagittaire:

I've downloaded some frames from the movie, and it is a bit of a contrived material to use as a source, don't you think?

I mean, there is no grain whatsoever as you would see in most movies, and even the motion blur that is present in even professional computer animation is absent.
unless you can propose a 1080p source with equal or better quality, that is available completely for free for us to do with as we please, I really don't think you should be complaining here.

bkman

22nd August 2006, 16:08

Sorry if it sounds like I am complaining, but I am just trying to point out at the onset of this test that the conclusions gained from it may not hold for many "real" movies. FWIW.

lexor

22nd August 2006, 20:36

akupenguin

23rd August 2006, 01:08

Dunno what smok3 meant, but this works for me:
wget -r -l 1 -A png http://media.xiph.org/ED/ED-1080-png/

drmpeg

23rd August 2006, 12:33

wackget is just a little Windows front-end for wget. Works good. It can parse a copy/paste of a web page for valid URL's. I used it to download the first 3000 frames, but I wrote a little script to avoid downloading the icons.

It includes wget.exe in the package.

Ron

smok3

23rd August 2006, 12:44

wackget 'workflow':
0. with firefox goto http://media.xiph.org/ED/ED-1080-png/
1. in firefox select tools/page info and clicky on links
2. select 1000 frames from here, rmb copy
3. in wackget select queue/Add from clipboard
thats it.

akupenguin's solution is better thought, since you wont have to do it multiple times, that was my 1st try, but i couldnt understand wget cli honestly...

Sagittaire

24th August 2006, 10:42

Sagittaire : instead of saying "the stream must be HD DVD-compliant", which nobody here knows what it implies ( not even you ), you should state clearly the restrictions on the options that can be used for each standard.

Restrictions that are really important are :
- gop structure
- average bitrate, max bitrate, cpb/vbv size
- allowed profile / level
- specific restrictions ( number of references / no breferences / custom matrices / motion range / whatever )

Those are easy to check ( except cpb/vbv compliancy ), and they are those that have an impact on the quality.

Well after investigation I choose that:
1920*1080, progressive frames at 25 fps for MPEG2, VC-1 and H264

MPEG2 Encoding
Profil & Level: MP@HL except specific restrictions
Max GOP lenght: 15 frames
Maximum bitrate: 29.4 Mbps
Buffer size: 9781 Kbits
Horizontal Vector Range: +/- 1024 pixels
Vertical Vector Range: +/- 128 pixels
Other Restrictions Setting: max adaptative GOP at 15, max adaptative bframe at 2

VC-1 Encoding
Profil & Level: AP@L3 except specific restrictions
Max GOP lenght: 15 frames
Maximum bitrate: 29.4 Mbps
Buffer size: 9781 Kbits
Horizontal Vector Range: +/- 1024 pixels
Vertical Vector Range: +/- 256 pixels
Other Restrictions Setting: max adaptative GOP at 15, max adaptative bframe at 2

H264 Encoding
Profil & Level: HP@L4.1 except specific restrictions
Max GOP lenght: 15 frames
Maximum bitrate: 29.4 Mbps
Buffer size: 9781 Kbits
Horizontal Vector Range: +/- 1024 pixels
Vertical Vector Range: +/- 512 pixels
Other Restrictions Setting: max adaptative GOP at 15, max adaptative bframe at 2, Max reference at 2, no bframes for reference, No custom matrix quantisation, no film grain modeling

Perhaps not exactly compliant but not far I think ... ???

*.mp4 guy

24th August 2006, 14:32

Bluray supports up to 4 reference frames, hd dvd supports more I beleive. Custome matrices, are also supported. There is no reason I can think of to disable b references.

IgorC

24th August 2006, 21:55

Nero decoder couldn't play properly x264 with bref enabled.
I didn't remeber where I heard it ;) but Brefs should be ok in theory but it's problematic for HD-DVD emulation application.

drmpeg

25th August 2006, 08:36

Are you sure that this content is 25 fps? The length of the audio is 10 minutes 58 seconds, which would suggest that the content is 23.976 fps (although there is still a ~4 second mismatch).

Ron

Sagittaire

25th August 2006, 10:57

Are you sure that this content is 25 fps? The length of the audio is 10 minutes 58 seconds, which would suggest that the content is 23.976 fps (although there is still a ~4 second mismatch).

Ron

Really not a probleme : original framerate is 24 fps but PAL convertion will done 25 fps.

Sagittaire

25th August 2006, 11:02

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

25th August 2006, 11:32

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

25th August 2006, 11:51

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

25th August 2006, 12:20

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

25th August 2006, 17:49

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

25th August 2006, 22:56

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

26th August 2006, 01:00

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

26th August 2006, 01:07

-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

26th August 2006, 01:21

Sagittaire

26th August 2006, 02:05

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

26th August 2006, 02:53

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

26th August 2006, 03:00

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

26th August 2006, 03:02

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

26th August 2006, 03:16

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

26th August 2006, 03:31

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

26th August 2006, 03:39

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

26th August 2006, 03:50

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

26th August 2006, 04:07

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

26th August 2006, 10:19

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

26th August 2006, 12:12

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

26th August 2006, 17:19

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

26th August 2006, 17:26

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

26th August 2006, 20:57

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

26th August 2006, 21:13

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

27th August 2006, 03:58

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

27th August 2006, 07:09

"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

27th August 2006, 13:59

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

28th August 2006, 14:00

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

30th August 2006, 22:41

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

Sagittaire

30th August 2006, 23:19

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

31st August 2006, 01:21

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

31st August 2006, 03:32

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

31st August 2006, 07:33

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

31st August 2006, 08:38

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

31st August 2006, 08:40

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

31st August 2006, 08:44

@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

31st August 2006, 18:49

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

31st August 2006, 23:53

... 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

1st September 2006, 04:04

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

1st September 2006, 13:29

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

1st September 2006, 23:30

@ Zambelli

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

Manao

1st September 2006, 23:58

drmpeg

2nd September 2006, 00:17

@ 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

2nd September 2006, 00:27

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

2nd September 2006, 04:39

@ 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

2nd September 2006, 05:50

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

2nd September 2006, 06:57

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

2nd September 2006, 08:23

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

3rd September 2006, 01:16

@ 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

3rd September 2006, 01:50

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).

zambelli

4th September 2006, 01:30

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 ... ;-)
I actually only just noticed you set a PP1 requirement for VC-1 at the beginning of the thread. I'll adhere to that and re-run PSNR and SSIM on my encodings. You can probably start entering the VC-1 results "officially" when I post the new numbers. :)

akupenguin

4th September 2006, 10:27

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.
If it had to work the same way everywhere, it wouldn't be called "postprocessing", it would be "decoding". The field in each frame header is just a hint.

Sagittaire

5th September 2006, 14:20

drmpeg

6th September 2006, 10:36

Here's the PSNR graph for the first 3500 frames. This is from a new encode at 24 Mbps average, 29 Mbps peak, 25 fps progressive and 15 frame GOP.

http://img208.imageshack.us/img208/3686/edpsnrpx3.th.jpg (http://img208.imageshack.us/my.php?image=edpsnrpx3.jpg)

Worst frame is 29.125 dB.

Ron

tchaikovsky

6th September 2006, 17:19

zambelli

7th September 2006, 09:14

I have problem for 24 Mbps encoding. 24 000 000 seem to be higher than the maximum bitrate for VC-1 with WMCmd.vbs ???
I don't think the bitrate is capped in the script - if any limitation exists, it's either in the WME9 SDK or in the WMV encoder DMO. I'll look into it.

zambelli

7th September 2006, 22:25

OK, so here's the best I've got so far with WMV9 AP at 6Mbps:

1 B-frame:
-input ED_1920x1080.avi -output Elephant_1080p25_6Mbps_B1_P80_Loop1_MM2_MSL4_MSR0.wmv -videoonly -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 1 -v_loopfilter 1 -v_mmatch 2 -v_mslevel 4 -v_msrange 0
SSIM: 84.75006234
Overall PSNR: 44.2776 dB

2 B-frames:
-input ED_1920x1080.avi -output Elephant_1080p25_6Mbps_B2_P80_Loop1_MM2_MSL4_MSR0.wmv -videoonly -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
SSIM: 84.98550747
Overall PSNR: 44.2432 dB

Metrics run with post-processing = 1 (weak deblocking), as requested.

Sagittaire, feel free to log the better score on the first page for VC-1. The question is: which do you value more, PSNR or SSIM?

Personally, I don't think there's much point in doing comparisons at 24Mbps. For this particular source it's obvious 24Mbps is overkill, so I don't think we'll see any difference between H.264 and VC-1.

IgorC

8th September 2006, 00:38

Personally, I don't think there's much point in doing comparisons at 24Mbps. For this particular source it's obvious 24Mbps is overkill, so I don't think we'll see any difference between H.264 and VC-1
Not only between H.264 and VC-1 but also MPEG-2.

So temporal results for 6 mbps are:
VC-1 44 dB
H.264 53 dB
+9 db is a huge difference.

Sharktooth

8th September 2006, 01:31

@zambelli: Well, it's obvious h.264 shines at mid/low bitrates, so maybe a 24mbps comparison would be more "fair" for VC-1 and MPEG-2...

zambelli

8th September 2006, 03:14

So temporal results for 6 mbps are:
VC-1 44 dB
H.264 53 dB
+9 db is a huge difference.
53 dB? You must've misread something. Nobody has actually reported complete results for x264, as run through Avisynth. The "very partial" results that Sagittaire has reported have stated the overall PSNR to be 45.806 dB. That's 1.5dB higher than VC-1 at the same bitrate, which is not all that unusual for a low bitrate such as 6Mbps.

foxyshadis

8th September 2006, 03:16

6 mbps is 11 hours on a dual-layer hd-dvd, or 10 with audio, so I'm going to go out on a limb and assume that studios are much more likely to use 12+ even for 1080 video. Frankly, we should be benchmarking scenarist hd, ms vc-1 studio, mainconcept (?), sony, and whomever else the studios use. x264 is kind of cheap, because it'll beat always any contenders (except possibly the latest ateme) by some sort of margin, but won't be used by any studio until it comes with a far more advanced gui. :p Now, if sonic or some other company were to merge its gui with x264, the game could change....

zambelli

8th September 2006, 03:18

@zambelli: Well, it's obvious h.264 shines at mid/low bitrates, so maybe a 24mbps comparison would be more "fair" for VC-1 and MPEG-2...
But we're already getting PSNR > 44 dB and SSIM > 84 at only 6Mbps. If we double that bitrate, we'll probably get SSIM into the 90s with both VC-1 and H.264, and that's already approaching transparency. What do you expect will happen at 24Mbps? SSIM=99.9%? ;) I just don't think it will be very challenging above 12Mbps, not with this source.

Sharktooth

8th September 2006, 03:35

You're right, the source is "too clean".

*.mp4 guy

8th September 2006, 04:05

I did a 12 Mbps encode a while ago with X264, it wasn't quuite withing the test restrictions, and it took forever, but I can tell you it was definately transparent to me

bkman

8th September 2006, 04:07

You're right, the source is "too clean".

Isn't that what I said several pages ago? :p

IgorC

8th September 2006, 04:13

53 dB? You must've misread something. Yes, it's my mistake. My apologies.

benwaggoner

8th September 2006, 08:24

Well I make modification for the test after reflexion:

[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).
I'm still going to argue that we should use 23.976. All the announced HD DVD titles will be using 23.976 in Europe, so if we're trying to target HD DVD performance, that's what we should be using.

Plus it is the intended frame rate, so it's just the right thing to do, and leaves open the option to adding a soundtrack later for a complete compression demo.

benwaggoner

8th September 2006, 08:29

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.

Macroblock Adaptive does exactly what you think - picks the optimal mode of or less than 1024/256. It's safe to use for this clip, and should hit optimum efficiency and performance.

benwaggoner

8th September 2006, 08:30

Thank 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.
Have you tried -v_bframedist 1? I find that generally works better for CGI content, and HD in general.

zambelli

8th September 2006, 09:35

Have you tried -v_bframedist 1? I find that generally works better for CGI content, and HD in general.
Yep! See few posts above. :)

drmpeg

9th September 2006, 00:47

Since this movie is characterized by mostly easy sequences and a few really difficult sequences (especially the one starting around frame 2800), the minimum PSNR is a more interesting number.

In your first set of results, the minimum Y PSNR was 27.6798 dB. Assuming this happened around frame 2800, then the VC-1 encoder did 1.44 dB worse than my real-time MPEG-2 encoder at 29.125 dB.

Assuming the VC-1 encoder actually reached the peak bitrate at this low PSNR, then a possible conclusion is that the VC-1 encoder doesn't do well with complex sequences.

I'll be glad to graph your frame by frame results so that a better comparision can be made. I'll PM you with my e-mail address.

Ron

But we're already getting PSNR > 44 dB and SSIM > 84 at only 6Mbps. If we double that bitrate, we'll probably get SSIM into the 90s with both VC-1 and H.264, and that's already approaching transparency. What do you expect will happen at 24Mbps? SSIM=99.9%? ;) I just don't think it will be very challenging above 12Mbps, not with this source.

tchaikovsky

9th September 2006, 02:53

@Zambelli

I have problem for 24 Mbps encoding. 24 000 000 seem to be higher than the maximum bitrate for VC-1 with WMCmd.vbs ???

This CLI done 9 999 999 bps and not 24 000 000 bps:

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 60 -videoonly -pixelformat YV12 -v_keydist 600 -v_bframedist 2 -v_dquantoption 2 -v_loopfilter 1 -v_mmatch 0 -v_mslevel 1 -v_msrange 0 -v_mvcost 1 -v_percopt 0 -v_denoise 0 -v_edgeremoval 0

Anyway, I find out a way to make WMV files that bit rate over 20Mbps by WMEA, a GUI for WME9 with AP.

I use the 10000 to 10999 frame PNG sequence make a WMV file that use compress settings is 24Mbps CBR 1pass. The file size is 115MB, 4 times size of the file 6Mbps VBR 2pass I made a while ago. Then, use 24Mbps VBR 2pass (peak bit rate) to make another one. It seems work properly.

There is another problem with WMV. When I make WMV use two pass VBR mode(CBR does not), “Total coded frames: 995”(994 in another one) be found in the encoding statistics (x264 does not drop frames). No matter wmcmd.vbs or WMEA used.

You can download WMEA on my blog if you want to make 24Mbps WMV.
http://galaxies.blogcn.com

BTW: choose "Ultra Mode" option on General page of settings.

trbarry

9th September 2006, 17:07

53 dB? You must've misread something. Nobody has actually reported complete results for x264, as run through Avisynth. The "very partial" results that Sagittaire has reported have stated the overall PSNR to be 45.806 dB. That's 1.5dB higher than VC-1 at the same bitrate, which is not all that unusual for a low bitrate such as 6Mbps.

I just now found this thread and skimmed. Did I miss it somewhere? Did we ever get x264 full ssim & psnr results posted?

- Tom

benwaggoner

9th September 2006, 20:46

Assuming the VC-1 encoder actually reached the peak bitrate at this low PSNR, then a possible conclusion is that the VC-1 encoder doesn't do well with complex sequences.

Well, I'm confident THAT'S not the problem. It's a particularly challenging and unique sequence, with all those thin moving diagonal lines. I'm not sure how well the objective measurements will correlate with subjective quality in that case.

FWIW, this test is targeting HD DVD compatibility (although I don't appear to have been persuasive in my plea to do it at 23.976 since that's what all HD DVD titles are being done at), but we're using the WMV encoder. The VC-1 encoder the studios are using supports many other modes and features, including segment reencoding.

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.

benwaggoner

9th September 2006, 20:48

I just now found this thread and skimmed. Did I miss it somewhere? Did we ever get x264 full ssim & psnr results posted?

Not yet, just VC-1 and MPEG-2.

I'd also like to see the best version of each posted, so we can compare subjectively as well as objectively. I feel that with modern codecs, objective measurements are becoming less and less correlated with subjective quality. I'd love to see us move to some kind of double-blind subjective testing like Hydrogen Audio does. Kind of painful to transport and decode lossless HD, though :).

trbarry

10th September 2006, 01:54

Not yet, just VC-1 and MPEG-2.

I'd also like to see the best version of each posted, so we can compare subjectively as well as objectively. I feel that with modern codecs, objective measurements are becoming less and less correlated with subjective quality. I'd love to see us move to some kind of double-blind subjective testing like Hydrogen Audio does. Kind of painful to transport and decode lossless HD, though :).

Ben -

Looking forward to your "professional" encodes.

I'd like to see the best entries posted for scrutiny somewhere also. But for now I'm curious and would settle just for a table of PSNR & SSIM.

While I don't consider the metrics the final word I do give them a lot more credibilty than many do. And they are certainly a good summary place to start.

- Tom

PS - If your results are improved over Zambelli's (and x264) this should give you a chance to show off the new multi-pass VC1 improvements AmirM's been recently bragging about. ;)

trbarry

10th September 2006, 02:07

I'm still going to argue that we should use 23.976. All the announced HD DVD titles will be using 23.976 in Europe, so if we're trying to target HD DVD performance, that's what we should be using.

Plus it is the intended frame rate, so it's just the right thing to do, and leaves open the option to adding a soundtrack later for a complete compression demo.

It's my understanding that in Europe BD progressive must be at 23.976 and that almost all HD DVD will also be that way. So I agree. It's the intended original rate and should be encoded that way. Let the players adjust it if needed. Many Euro players will not need it and then can output the original without messing with it.

But I'm in the USA and thus don't really consider I have a vote on this part except from an engineering perspective. ;)

- Tom

bond

10th September 2006, 12:06

It's my understanding that in Europe BD progressive must be at 23.976 and that almost all HD DVD will also be that way. So I agree. It's the intended original rate and should be encoded that way. Let the players adjust it if needed. Many Euro players will not need it and then can output the original without messing with it.that sounds very strange. american movies might be shot at 23.976, tough i doubt european ones are. seeing all the mess arising from this strange 23.976 i kinda would prefer good old straight forward 25fps be used everywhere ;)

benwaggoner

10th September 2006, 17:02

that sounds very strange. american movies might be shot at 23.976, tough i doubt european ones are. seeing all the mess arising from this strange 23.976 i kinda would prefer good old straight forward 25fps be used everywhere ;)
Movies everywhere are shot 24 fps. They're slowed down 0.1% for NTSC, and sped up 4% for PAL delivery. There is a little bit of 25p production for PAL-region only direct-to-video or direct-to-broadcast, but anything targeting global reach or a theatrical run is shot 24.

Using 23.976 in PAL regions is much closer to the original artistic intent. FWIW, this is why PAL DVD run times are typically shorter than for NTSC. Home theater advocates are pretty passionate about this.

Now that PAL HD sets are required to support NTSC rates, we're probably entering the era of slow decline of 25/50 for delivery. 24 is better for movies, and 60 is better for everything else now that we'e eliminated the PAL resolution advantage in HD.

bond

10th September 2006, 17:13

why is there still the need for the 24->23.976 slowdown btw?

*.mp4 guy

10th September 2006, 18:27

So that 3:2 Pulldown will work correctly for interlaced displays, you can't do 3:2 Pulldown on 24 fps material and get good results on a 59.94i display.

zambelli

11th September 2006, 01:45

Once again, it's important to distinguish between encoding framerate and decoding framerate. Even if PAL movies end up being encoded at 23.976, it's still possible for a PAL player to perform a 5% speedup or 24th frame repetition on-the-fly in order to meet the 25fps/50Hz output requirement.

zambelli

11th September 2006, 01:48

I'd also like to see the best version of each posted, so we can compare subjectively as well as objectively.
The only caveat to that is that a 10 minute movie at 6Mbps ends up being 430MB in size. It's not an easy filesize to host or download. At 12Mbps and 24Mbps, that number would double and quadruple respectively.

Sharktooth

11th September 2006, 02:47

i can host the files for a limited period of time.

benwaggoner

11th September 2006, 04:44

The only caveat to that is that a 10 minute movie at 6Mbps ends up being 430MB in size. It's not an easy filesize to host or download. At 12Mbps and 24Mbps, that number would double and quadruple respectively.
Yeah, this would definitely be a job for Bittorrent. Although I'm sure we could find a way to host our clips :).

Sagittaire

11th September 2006, 10:29

I'm still going to argue that we should use 23.976. All the announced HD DVD titles will be using 23.976 in Europe, so if we're trying to target HD DVD performance, that's what we should be using.

Plus it is the intended frame rate, so it's just the right thing to do, and leaves open the option to adding a soundtrack later for a complete compression demo.

Well read the previous thread. I choose 25 fps because:
- Compliant with HD-DVD
- Clearly progressive
- I use 2 bframe and no adaptative bframe is a problem for VC-1 with 0.6006 sec max keyframe interval
- Moreover Conclusion for 25 fps will be the same than for 23.976 fps

Sagittaire

11th September 2006, 10:35

I just now found this thread and skimmed. Did I miss it somewhere? Did we ever get x264 full ssim & psnr results posted?

- Tom

I make really full and complete test ... and make encoding and test at 1080p with my little sempron is really slow ... ;-)

benwaggoner

11th September 2006, 20:02

Well read the previous thread. I choose 25 fps because:
- Compliant with HD-DVD
- Clearly progressive
- I use 2 bframe and no adaptative bframe is a problem for VC-1 with 0.6006 sec max keyframe interval
- Moreover Conclusion for 25 fps will be the same than for 23.976 fps
Oh, I understand, and it's probably too late to change now. But since there aren't going to be many or any 25p HD DVD titles, it keeps it from beeing a truly relevant test. But it won't change the codec ranking.

Note most HD VC-1 is done with 1 bframe, so that winds up not being that big an issue.

crypto

11th September 2006, 20:04

Even in PAL land all movies shot on film have 24 fps. In theaters each frame is shown twice resulting in 48 fps. Video transfers (SD) are done using the PAL speedup.

Blu-Ray titles in PAL land are also all in 24p. BR PAL players have a permanent 3:2 pulldown. All PAL HD displays can handle 60Hz.

About the 23.976 fps, that's what the cameras are really set to. It avoids the hickup that would accour every 1000th frame @24 fps.

bond

11th September 2006, 20:11

why should the framerate influence the visual quality?

crypto

11th September 2006, 21:28

1000/1001

When the NTSC color television system was being developed, the designers wanted to make it compatible with all of the old black and white systems that were already in people’s homes. To do this, they had to make some compromises. The thing that has probably caused the most problems for our industry over the years is that the field rate was changed by 1/1.001 from 60 to 59.94 per second. This was a small enough change that the older TV’s would still receive the new color broadcast and allowed for the new color information to be encoded into the broadcasted signal. This offset gives rise to “niceties” such as drop-frame timecode and audio that also has to run at the right rate. Although having analog origins, it has also been extended into the digital and HD world where 24, 30, and 60 frames/fields per second becomes 23.98, 29.97, and 59.94 to be compatible with existing NTSC formats and workflows.

http://www.highdef.com/library/glossary.htm

benwaggoner

11th September 2006, 22:08

why should the framerate influence the visual quality?
More frames per sec at fixed bitrate means fewer bits per frame.

Sagittaire

11th September 2006, 22:44

More frames per sec at fixed bitrate means fewer bits per frame.

Well in fact it's more complex if you use use really short GOP (time fixed) with no adaptative bframe. In this case more bits per frame doesn't mean always higher quality by frame ...

But more generaly this test is comparison between codec and make comparison at 25 fps between codec A at 6000 kbps and codec B at 6000 Kbps will done exactly the same conclusion than comparison at 23.976 fps between codec A at 5750 kbps and codec B at 5750 Kbps. Framerate doesn't change anything if you use the same for all codec ... ;-)

benwaggoner

12th September 2006, 01:24

But more generaly this test is comparison between codec and make comparison at 25 fps between codec A at 6000 kbps and codec B at 6000 Kbps will done exactly the same conclusion than comparison at 23.976 fps between codec A at 5750 kbps and codec B at 5750 Kbps. Framerate doesn't change anything if you use the same for all codec ... ;-)
Agreed - frame rate won't change the rankings of the codecs.

drmpeg

13th September 2006, 05:01

Graphs of Zambelli's VC-1 encodes. The color key is:

Elephant_1080p25_6Mbps_B1_P80_Loop1_MM2_MSL4_MSR0.PSNR.log = black
Elephant_1080p25_6Mbps_B2_P60_Loop1_MM2_MSL4_MSR0_MVC1_DQO1.PSNR.log = red
Elephant_1080p25_6Mbps_B2_P60_MM2_MSL4_MSR0.PSNR.log = green
Elephant_1080p25_6Mbps_B2_P80_Loop1_MM2_MSL4_MSR0.PSNR.log = blue

B – v_bframedist
P – v_performance
Loop – v_loopfilter
MM – v_mmatch
MSL – v_mslevel
MSR – v_msrange
MVC – v_mvcost
DQO – v_dquantoption

http://img181.imageshack.us/img181/8051/vc13100by9.th.jpg (http://img181.imageshack.us/my.php?image=vc13100by9.jpg)

http://img147.imageshack.us/img147/4589/vc16200xj8.th.jpg (http://img147.imageshack.us/my.php?image=vc16200xj8.jpg)

http://img135.imageshack.us/img135/1359/vc19300ir1.th.jpg (http://img135.imageshack.us/my.php?image=vc19300ir1.jpg)

http://img165.imageshack.us/img165/576/vc112400ig6.th.jpg (http://img165.imageshack.us/my.php?image=vc112400ig6.jpg)

http://img158.imageshack.us/img158/7640/vc115500zn6.th.jpg (http://img158.imageshack.us/my.php?image=vc115500zn6.jpg)

And a graph of VC-1 versus MPEG-2 for the first 3500 frames. MPEG-2 = violet.

http://img243.imageshack.us/img243/7899/vc1mpeg2jj9.th.jpg (http://img243.imageshack.us/my.php?image=vc1mpeg2jj9.jpg)

On the difficult sequence starting at frame 2800, the VC-1 encodes are about 5 dB better than MPEG-2. Pretty impressive.

BTW, the minimum PSNR reported in Zambelli's summary is an error. It occurs on the last frame and would appear to be a frame mismatch. The actual minimum PSNR is around 34 dB.

Ron

zambelli

13th September 2006, 07:13

Graphs of Zambelli's VC-1 encodes. The color key is:

On the difficult sequence starting at frame 2800, the VC-1 encodes are about 5 dB better than MPEG-2. Pretty impressive.

BTW, the minimum PSNR reported in Zambelli's summary is an error. It occurs on the last frame and would appear to be a frame mismatch. The actual minimum PSNR is around 34 dB.

Thank you for doing the graphs, Ron, and for catching the PSNR error!

I'm doing one last encode (this one experimenting with range reduction) and then I think I'll take a break and watch the "competition" for a while. :)

Sharktooth

14th September 2006, 03:55

crypto

14th September 2006, 08:03

The overall MPEG-2 vs VC1 graph shows MPEG-2 having a better PSNR in the majority of frames except the "difficult sequence".

Yes, at high bitrates MPEG-2 is still a good choice. But one should keep in mind that drmpeg is comparing MPEG-2 24 MBit/s VBR vs. VC-1 6 MBit/s VBR. Too bad we have no bitrate graph. I am sure at the critical range starting at frame 2800 the MPEG-2 bitrate is capped while VC-1 has enough headroom to go up to 29.4 MBit/s.

Anyway its an impressive result for VC-1. Also these graphs can't express the advanced features like like fade out encoding. In the recent reviews HD DVD (VC-1) vs. Blu-ray (MPEG-2) testers especially mentioned the smoother fade outs and dissolves on the HD DVD side. (and a better PQ)

Sharktooth

14th September 2006, 14:48

Sure, VC1 did a really good job. I only made my comments coz i saw some inconsistancies in the MPEG-2 encode.

bond

14th September 2006, 20:17

hm the comparison at the same bitrate for both mpeg-2 and vc-1 would rock

Sagittaire

14th September 2006, 23:00

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

15th September 2006, 15:39

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

15th September 2006, 16:06

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

15th September 2006, 20:23

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

15th September 2006, 23:45

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

16th September 2006, 00:02

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

16th September 2006, 10:17

@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

18th September 2006, 07:36

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

18th September 2006, 16:50

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

18th September 2006, 17:17

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

Sagittaire

18th September 2006, 17:41

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

18th September 2006, 17:56

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

Sagittaire

18th September 2006, 17:56

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

18th September 2006, 18:22

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

18th September 2006, 20:24

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

18th September 2006, 22:52

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

19th September 2006, 09:18

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

19th September 2006, 09:31

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

19th September 2006, 10:00

Sulik

19th September 2006, 10:03

Sagittaire

19th September 2006, 10:13

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

19th September 2006, 10:16

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

19th September 2006, 15:25

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

19th September 2006, 22:47

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

20th September 2006, 03:12

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

20th September 2006, 04:47

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

20th September 2006, 11:15

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

20th September 2006, 12:16

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

20th September 2006, 14:41

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

21st September 2006, 10:09

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

21st September 2006, 10:14

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

21st September 2006, 10:16

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

21st September 2006, 16:12

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

21st September 2006, 18:00

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

21st September 2006, 21:17

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

21st September 2006, 21:48

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

21st September 2006, 22:17

Sagittaire -

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

- Tom

Sagittaire

22nd September 2006, 00:01

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

22nd September 2006, 01:25

... 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

22nd September 2006, 01:42

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

22nd September 2006, 02:14

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

drmpeg

22nd September 2006, 03:51

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

22nd September 2006, 04:22

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

22nd September 2006, 04:54

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

22nd September 2006, 08:13

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

22nd September 2006, 09:56

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

22nd September 2006, 10:15

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

22nd September 2006, 11:26

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

22nd September 2006, 11:28

drmpeg

22nd September 2006, 12:21

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

trbarry

22nd September 2006, 19:49

Besides the PSNR & SSIM metrics, one of the simple ways to compare the quality of 2 video clips is just visually compare the frame(s) that are the weakest link in the chain.

For the 6 mbps x264 clip the PSNR log shows the min PSNR occurs at frame 2821 (counting from zero). This would supposedly correspond to the 2822.png original file.

I tried to compare this X264 frame from the 12 mbps X264 clip since that's the only one I've downloaded. But when opening that clip with Vdubmod/directshow source it shows frame 2821 to be a black frame, which from the original png files should not be there. Surrounding frames seem okay.

Can anyone verify this?

If this is not a bug it would be nice if anyone could post png caps of the 6 mbps frame 2821 from the different codecs so we can compare the worst of the worst.

I'm not sure what Zambelli's VC-1 worst frame was because of the mismatch at the end. Though I wonder if that too messed up PSNR somewhat.

- Tom

edit: note any frame mismatch will totally hose PSNR results

trbarry

22nd September 2006, 20:40

Ignore my black frame issue above. It seems to be intermittant and related to Vdub searching (Edit Goto) with dshowsource.

But it still would be nice to be able to compare the various frames numbered 2821 if anybody can post them from the 6 mbps encoded tests to see if there is any visible difference.

- Tom

diogen

22nd September 2006, 21:51

The lowest PSNR frame in VC-1/6Mbps encoding is #3218 and it is 33.66.
There are 9 frames with PSNR below 36 and they are all between frames #3178 and #3218.
The frame #2821 has a PSNR of 37.17. Frames between 2810 and 2130 have PSNR between 36.55 and 38.74.
There are multiple groups of frames (e.g. 3597 to 3654) counting 104 in total that have PSNR of 1.#INF

Diogen.

Sagittaire

24th September 2006, 10:51

Hi Sagittaire and all,
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...

I my previous test gain is very little between subme 7 + trellis 2 + me "umh" and subme 6 + trellis 1 + me "hex" (for same PSNR size gain is less than 1% with dramatic speed loss). If pengvado can confirm that ?

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

for same quant and setting:
- Best PSNR for 0,0
- Best SSIM for -1,-1
- Best size for -2,-2

-1,-1 seem best choice for metric and eyes

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.

If it's true use MPEG2 for HD-DVD become in practice impossible if you want high quality because max bitrate at 19 Mbps is really to low for 1080p and MPEG2. The quality will be like HDTV MPEG2 source ... horrible.

Moreover use multiple "lossless" audio with secondary video is not an obligation for HD-DVD or BR and certainely very bad idea if you use MPEG2 for video codec.

Manao

24th September 2006, 10:58

however i have my doubts about --no-dct-decimate.Trellis allows you to know "exactly" ( PSNR-wise ) when you ought to decimate, so disabling a-priori dct-decimation can't hurt - and should actually improve PSNR.

akupenguin

25th September 2006, 03:59

I my previous test gain is very little between subme 7 + trellis 2 + me "umh" and subme 6 + trellis 1 + me "hex" (for same PSNR size gain is less than 1% with dramatic speed loss). If pengvado can confirm that ?
For "-m7 -t2 -r3 --me=umh" vs "-m6 -t1 -r2 --me=hex" (with other settings as per Sagittaire's encode (http://forum.doom9.org/showthread.php?p=878427#post878427)), I get 6% lower bitrate per psnr and 2.1x slower encoding.

If you're tweaking for speed, the first option I'd drop is -A=all. p4x4 is close enough to useless at 480p, don't even think of using it at 1080p. It improved bitrate by all of 0.18% at a cost of 7.3% time, which is a far worse tradeoff than "-m7 -t2 -r3 --me=umh".

Dethis

25th September 2006, 09:12

@ akupenguin

do you have any tweaks in mind so that the x.264 encoded file doesn't violate the 29400Kbps limit?
In Sagittaire's 6Mbps_x.264 encode the avg bitrate of the 2972 to 2881 frames is 30.8 Mbps with peaks over 34.0 Mbps

Sagittaire

25th September 2006, 13:12

For "-m7 -t2 -r3 --me=umh" vs "-m6 -t1 -r2 --me=hex" (with other settings as per Sagittaire's encode (http://forum.doom9.org/showthread.php?p=878427#post878427)), I get 6% lower bitrate per psnr and 2.1x slower encoding.

If you're tweaking for speed, the first option I'd drop is -A=all. p4x4 is close enough to useless at 480p, don't even think of using it at 1080p. It improved bitrate by all of 0.18% at a cost of 7.3% time, which is a far worse tradeoff than "-m7 -t2 -r3 --me=umh".

AAArrrrrgggggghhhhhhhh ... 6% for size gain. I will try that. I don't know very well the reference limit for HD-DVD. I will use -r2. Speed is not a problem here: more than 30 hours for each vc1 encoding (esa with h264 is certainely faster).

do you have any tweaks in mind so that the x.264 encoded file doesn't violate the 29400Kbps limit?
In Sagittaire's 6Mbps_x.264 encode the avg bitrate of the 2972 to 2881 frames is 30.8 Mbps with peaks over 34.0 Mbps

Max bitrate is not strict local max bitrate (150 Kbits max for each frame here). You use buffer too and max size can be higher than 150 Kbits for each frame.

891, 3.00, 400619, 42.55, 50.19, 45.93, 43.67 I
892, 5.00, 66317, 41.64, 50.41, 46.43, 42.92 B
893, 5.00, 68902, 41.35, 50.09, 46.08, 42.63 B
894, 2.00, 327465, 43.63, 50.33, 46.33, 44.64 P
895, 4.00, 86100, 41.84, 50.32, 46.05, 43.07 B
896, 4.00, 87712, 41.81, 50.27, 46.05, 43.04 B
897, 3.00, 259266, 43.07, 49.89, 45.88, 44.10 P
898, 4.00, 86277, 41.86, 50.00, 45.84, 43.06 B
899, 4.00, 85971, 41.56, 49.81, 45.61, 42.77 B
900, 3.00, 226414, 42.63, 49.51, 45.45, 43.67 P
901, 4.00, 80828, 41.62, 49.52, 45.31, 42.78 B
902, 4.00, 80060, 41.32, 49.37, 45.04, 42.49 B
903, 3.00, 149087, 42.44, 49.50, 45.36, 43.50 P
904, 4.00, 71735, 41.68, 49.44, 45.18, 42.82 B
905, 5.00, 340193, 39.38, 48.41, 43.41, 40.61 I

This MPEG2 stream is perfectly complaint with vbv (29.4 Mbps and 9781 Kbit for buffer) but size for Iframe can be higher than 400 Kbits or if you make local bitrate convertion higher than 80 Mbps.

akupenguin

25th September 2006, 17:19

I don't know very well the reference limit for HD-DVD. I will use -r2.
If it's level 4.1, then the limit is -r3. (Theoretically 4 refs in P-frames and 3 in B-frames, but x264 uses the same number for both, so 3 is the max.)

drmpeg

26th September 2006, 10:43

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

I've determined that the uncompressed audio files (at least the stereo ones) sync to 24 fps, not 23.976 fps.

Ron

Sagittaire

26th September 2006, 23:49

I've determined that the uncompressed audio files (at least the stereo ones) sync to 24 fps, not 23.976 fps.

Ron

I see that ... I see that ... thx

Update

26.09.2006 - MPEG2 and H264 files with audio are available
19.09.2006 - MPEG2 metric result
18.09.2006 - H264 metric result

H264 files (x264) with AAC 5.1 (FAAC) at 448 Kbps
MPEG2 files (libavocodec) with ac3 5.1 at 448 Kbps

NB : 24 Mbps MPEG2 file is not strictly vbv compliant (but not far I think) because RC for this quality level is really difficult with Mencoder.
NB : H264 files are not updated files with insame quality setting

For "-m7 -t2 -r3 --me=umh" vs "-m6 -t1 -r2 --me=hex" (with other settings as per Sagittaire's encode), I get 6% lower bitrate per psnr and 2.1x slower encoding.

Like always akupenguin (and skal) show the light. At maximum quality x264 improvement done 0.25 dB ...

D:\Mes dossiers\Codec\x264>x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 29
00 --vbv-bufsize 9500 --qpmin 15 --level 4.1 --bframe 2 --b-rdo --bime --weight
--ref 3 --mixed-refs --direct auto --filter -1:-1 --bitrate 6000 --pass 3 --st
ts "H264_6Mbps.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.33 --analyse "all"
-8x8dct --me "umh" --subme 7 --no-fast-pskip --no-dct-decimate --trellis 2 --pr
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 wi
l suffer.
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: slice I:1131 Avg QP:21.23 size:101765 PSNR Mean Y:48.68 U:58.62
V:57.22 Avg:49.62 Global:47.37
x264 [info]: slice P:6870 Avg QP:21.70 size: 37554 PSNR Mean Y:47.98 U:57.52
V:56.23 Avg:48.97 Global:46.68
x264 [info]: slice B:7690 Avg QP:23.36 size: 12691 PSNR Mean Y:47.49 U:60.02
V:58.22 Avg:48.59 Global:45.95
x264 [info]: mb I I16..4: 39.0% 42.3% 18.7%
x264 [info]: mb P I16..4: 11.0% 11.3% 2.0% P16..4: 29.6% 7.6% 3.3% 0.4%
.2% skip:34.6%
x264 [info]: mb B I16..4: 0.6% 1.2% 0.3% B16..8: 10.5% 1.3% 2.4% direct
2.2% skip:81.5%
x264 [info]: 8x8 transform intra:45.4% inter:57.7%
x264 [info]: direct mvs spatial:75.9% temporal:24.1%
x264 [info]: ref P 79.1% 14.4% 6.5%
x264 [info]: ref B 76.8% 14.8% 8.4%
x264 [info]: SSIM Mean Y:0.9881195
x264 [info]: PSNR Mean Y:47.792 U:58.826 V:57.280 Avg:48.829 Global:46.346 kb/s
5999.51

encoded 15691 frames, 0.65 fps, 6000.57 kb/s

Dethis

27th September 2006, 11:29

....

This MPEG2 stream is perfectly complaint with vbv (29.4 Mbps and 9781 Kbit for buffer) but size for Iframe can be higher than 400 Kbits or if you make local bitrate convertion higher than 80 Mbps.

Sorry, I don't get it.:(

400,619 bits / 1024 = 391 (Kbits per frame) * 25 fps = 9,781 Kbps local bitrate (9781 !!!! hmmm .. equal to the buffer's size).

I aggree it's perfectly HD-DVD compliant (<29,400Kbps)

Sagittaire

27th September 2006, 12:14

Sorry, I don't get it.:(

400,619 bits / 1024 = 391 (Kbits per frame) * 25 fps = 9,781 Kbps local bitrate (!!!! 9781 !!! equal to the buffer's size).

I aggree it's perfectly HD-DVD compliant (<29,400Kbps)

Sorry unit is bytes and not bits

400 Kbytes = 400 * 8 = 3 200 Kbits
3 200 *25 = 80 Mbps

in fact you don't understand how work vbv ... :readfaq:

Max bitrate work with buffer and if local bitrate is superior to max bitrate then the buffer is emptied. Local bitrate can be superior to the max bitrate if the buffer is not empty and can't if the buffer is empty ...

For HD-DVD max local bitrate can be 60 Mbps for 0.320 sec, For DVD max local bitrate can be 12 Mbps for 0.920 sec ... ect ect

Dethis

27th September 2006, 16:51

Sorry unit is bytes and not bits.....

400 Kbytes = 400 * 8 = 3 200 Kbits
3 200 *25 = 80 Mbps

in fact you don't understand how work vbv ... :readfaq:

Max bitrate work with buffer and if local bitrate is superior to max bitrate then the buffer is emptied. Local bitrate can be superior to the max bitrate if the buffer is not empty and can't if the buffer is empty ...

For HD-DVD max local bitrate can be 60 Mbps for 0.320 sec, For DVD max local bitrate can be 12 Mbps for 0.920 sec ... ect ect

I am really sorry . :( I should have imagined the typo (bits->bytes).

Anyway thanks for the info Sagittaire.:thanks:

And :thanks: :thanks: :thanks: for your efforts to objectively valuate all codecs.

drmpeg

28th September 2006, 11:51

NB : 24 Mbps MPEG2 file is not strictly vbv compliant (but not far I think) because RC for this quality level is really difficult with Mencoder.

The 24 Mbps MPEG-2 file is not VBV compliant by a very large amount. It looks to me like there is a bug in the rate control for 24 Mbps Average, 29.4 Mbps Peak. When it gets low in the VBV, it codes a gigantic frame and totally violates the VBV.

http://img153.imageshack.us/img153/1893/lib24vbvdk9.th.jpg (http://img153.imageshack.us/my.php?image=lib24vbvdk9.jpg)

The 12 Mbps encode is okay.

http://img153.imageshack.us/img153/5154/lib12vbvhm2.th.jpg (http://img153.imageshack.us/my.php?image=lib12vbvhm2.jpg)

Ron

zambelli

29th September 2006, 02:41

Hi Sagittaire,

I just exchanged some emails with our resident HD-DVD guru (sspears from AVSForum, in case you read that forum) and he pointed out that your VBV size is incorrect.

According to the HD-DVD specs, these are the allowed VBV buffer sizes:

1843200 bytes for Main Video HD
937984 bytes for Main Video SD
929792 bytes for Sub Video HD
242688 bytes for Sub Video SD

So it looks like the buffer size is more like 500 msec, not 320 msec.

MuTeK

29th September 2006, 12:49

Elecard H264 Encoder.
2passVBR 6mbps, HssRate = 29.4mbps, CpbSize = 9.78 Mbit

Quality: OPSNR = 46.17, SSIM = 89.44

And VBV buffer:
http://img220.imageshack.us/img220/3451/elecardavc6mbps2passot5.th.gif (http://img220.imageshack.us/my.php?image=elecardavc6mbps2passot5.gif)

bond

29th September 2006, 18:08

Manao

29th September 2006, 18:41

MuteK : how come your VBV isn't always empty, excepted on complicated scenes ?

zambelli

30th September 2006, 02:30

12Mbps VC-1 encoding done. WME9 wmcmd.vbs was used, as before, with the latest v11 WMV encoder DMO.

Command line:
-input ED_1920x1080.avi -output Elephant_1080p25_12Mbps_B2_P80_Loop1_MM2_MSL4_MSR0.wmv -videoonly -v_codec WVC1 -v_mode 4 -v_bitrate 12000000
-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

Average Bitrate: 12177994 bps
Filesize: 957,624,858 bytes
Overall PSNR: 47.6286
Minimum PSNR: 33.7551 (this time I made sure the last frame was trimmed)
Average SSIM: 92.03065060

Sagittaire

1st October 2006, 22:13

akupenguin wrote this:
http://forum.doom9.org/showthread.php?p=730001#post730001

--analyse "all" is compliant with level 4.1 ... yes or not?

I just exchanged some emails with our resident HD-DVD guru (sspears from AVSForum, in case you read that forum) and he pointed out that your VBV size is incorrect.

According to the HD-DVD specs, these are the allowed VBV buffer sizes:

1843200 bytes for Main Video HD
937984 bytes for Main Video SD
929792 bytes for Sub Video HD
242688 bytes for Sub Video SD

So it looks like the buffer size is more like 500 msec, not 320 msec.

yes drmpeg say that. Anyway I use the same vbv setting for all codec. If 14 745 Kbits is compliant then 9781 too.

The 24 Mbps MPEG-2 file is not VBV compliant by a very large amount. It looks to me like there is a bug in the rate control for 24 Mbps Average, 29.4 Mbps Peak. When it gets low in the VBV, it codes a gigantic frame and totally violates the VBV.

Argh ... I will try to obtain better result with libavcodec.

akupenguin

1st October 2006, 22:28

akupenguin write this:
http://forum.doom9.org/showthread.php?p=730001#post730001

--analyse "all" is compliant with level 4.1 ... yes or not?
Yes as of r573. Not when I wrote that.

Sergey A. Sablin

2nd October 2006, 08:07

MuteK : how come your VBV isn't always empty, excepted on complicated scenes ?

why should it be?

zambelli

2nd October 2006, 08:57

yes drmpeg say that. Anyway I use the same vbv setting for all codec. If 14 745 Kbits is compliant then 9781 too.
Well, sure, but then we're doing a disservice to all the codecs here. If the spec allows for a bigger buffer, why not use it?

As a general note, I think a lot of readers of this thread are confused about what the thread is trying to accomplish. The title makes it sound like we're trying to produce HD-DVD/BluRay compliant video bitstreams, but we've already somewhat strayed away from those guidelines. Is the point to produce the best encoding? Or find the best codec? Or find the best encoder software?

Manao

2nd October 2006, 09:04

Sergey A. Sablin

2nd October 2006, 09:20

Because you did an encoding in VBR @ 6 mbps, while the VBV buffer was configured at 29.4 mbps. Since you never saturate your VBV, you have "average bitrate = (VBV bitrate * duration + VBV end - VBV begin ) / duration". Hence, you have average bitrate = 29.4 mbps. So there's a problem, becaue obviously the average bitrate wasn't 29.4 mbps.

strange formulae to compute avc buffer level... I thought you know something about HRD - it is a bit different from mpeg-2 VBV model (and VC-1 too as it nearly same as mpeg-2).
hint: in avc buffer never saturated at the top, and because of high scale-down of a picture you just dont see how it stays without filling in the middle.

foxyshadis

2nd October 2006, 10:40

akupenguin

2nd October 2006, 11:10

strange formulae to compute avc buffer level... I thought you know something about HRD - it is a bit different from mpeg-2 VBV model (and VC-1 too as it nearly same as mpeg-2).
hint: in avc buffer never saturated at the top, and because of high scale-down of a picture you just dont see how it stays without filling in the middle.
VBV is the same, no matter what codec you're using.
That said, there are multiple ways to consider it.
The standard way is: send bits at the maximum rate allowed, except when the buffer is full. This is the most useful model for the encoder to think of, and the easiest to write. If this method were used, then Manao's comment holds.
It is also possible to think of VBV as: send bits at whatever speed you feel like, as long as they arrive some time before the decoder needs them. This method may be more useful for a real muxer, but is not appropriate for examining how much of the VBV was needed. It's also not appropriate for any sort of comparison, since there is no one unique graph that can be generated from a given bitstream.

Sagittaire

2nd October 2006, 11:18

Well, sure, but then we're doing a disservice to all the codecs here. If the spec allows for a bigger buffer, why not use it?

As a general note, I think a lot of readers of this thread are confused about what the thread is trying to accomplish. The title makes it sound like we're trying to produce HD-DVD/BluRay compliant video bitstreams, but we've already somewhat strayed away from those guidelines. Is the point to produce the best encoding? Or find the best codec? Or find the best encoder software?

1) I think that for VC-1 and H264 9781 Kbits is enought for 6 Mbps and 12 Mbps encoding (no VBV saturation or really limited vbv saturation). I think that 14400 Kbits could be usefull only for 24 Mbps encoding because the average bitrate is really close to the max bitrate. I fact I think that better buffer will be always really usefull only for MPEG2 in this challenge.

2) Well I know the buffer for VC-1 but not exactly for MPEG2 and H264. I choose these vbv values (9781 Kbits for buffer and 29.4 Mbps for max bitrate) simply because I know that these value are compliant for HD-DVD and BD and for all the codec.

Somebody know the buffer which should be used ?
- For MPEG2, VC-1 and H264
- For HD-DVD and BD

Is the point to produce the best encoding? Or find the best codec? Or find the best encoder software?

1) Try to find the best choice for low, meduim and high bitrate.
2) Try to find codec ranking with best possible encoder software for each standard.

If H264 Elecard encoder produce the best result I will choose Elecard for AVC encoder.

Sergey A. Sablin

2nd October 2006, 11:26

VBV is the same, no matter what codec you're using.
That said, there are multiple ways to consider it.
The standard way is: send bits at the maximum rate allowed, except when the buffer is full. This is the most useful model for the encoder to think of, and the easiest to write. If this method were used, then Manao's comment holds.
It is also possible to think of VBV as: send bits at whatever speed you feel like, as long as they arrive some time before the decoder needs them. This method may be more useful for a real muxer, but is not appropriate for examining how much of the VBV was needed.

there also exist an

Annex C
Hypothetical reference decoder
(This annex forms an integral part of this Recommendation | International Standard)

and I think there is no need to discuss of a most useful or more easiest way how one wants to calculate it. Elecard Buffer analyzer works in a really standard way.

drmpeg

2nd October 2006, 12:28

Somebody know the buffer which should be used ?
- For MPEG2, VC-1 and H264
- For HD-DVD and BD

BD numbers are:

MPEG-2 MP@HL = 9,781,248 bits (1,222,656 bytes) (maximum of MP@HL)
MPEG-2 MP@ML = 1,835,008 bits (229,376 bytes) (maximum of MP@ML)

H.264 MP or HP Level 4 or 4.1 = 30,000,000 bits (3,750,000 bytes)
H.264 MP or HP Level 3.2 = 24,000,000 bits (3,000,000 bytes)
H.264 MP or HP Level 3.1 = 16,800,000 bits (2,100,000 bytes)
H.264 MP or HP Level 3 = 12,000,000 bits (1,500,000 bytes)

VC-1 AP@L3 = 30,000,000 bits (3,750,000 bytes)
VC-1 AP@L2 = 30,000,000 bits (3,750,000 bytes)

Ron

Sergey A. Sablin

2nd October 2006, 12:30

BD numbers are:
H.264 MP or HP Level 4 or 4.1 = 30,000,000 bits (3,750,000 bytes)
H.264 MP or HP Level 3.2 = 24,000,000 bits (3,000,000 bytes)
H.264 MP or HP Level 3.1 = 16,800,000 bits (2,100,000 bytes)
H.264 MP or HP Level 3 = 12,000,000 bits (1,500,000 bytes)
Ron

coud you tell me pls where did you get these numbers from?

Sergey A. Sablin

2nd October 2006, 13:19

It's also not appropriate for any sort of comparison, since there is no one unique graph that can be generated from a given bitstream.

which comparison you are talking about here? the only one I can see is compliance to given restrictions (buffer state), i.e. there is no underflow for VBR case and no overflow/underflow in CBR case.
So why one need unique graph for any compression standard?

drmpeg

2nd October 2006, 13:53

which comparison you are talking about here? the only one I can see is compliance to given restrictions (buffer state), i.e. there is no underflow for VBR case and no overflow/underflow in CBR case.
So why one need unique graph for any compression standard?
The leak rate on a muxer can be higher than the bitrate indicated in the video elementary stream. However, it can be graphed. It's just done differently. You examine the level of the elementary stream buffer at every byte of the multiplex. Then at the DTS, all the picture bits are removed from the buffer (for that picture).

Ron

Sergey A. Sablin

2nd October 2006, 14:28

The leak rate on a muxer can be higher than the bitrate indicated in the video elementary stream. However, it can be graphed. It's just done differently. You examine the level of the elementary stream buffer at every byte of the multiplex. Then at the DTS, all the picture bits are removed from the buffer (for that picture).

Ron

Ron,

you are right, but I still do not see what one want to compare here. The goal is to check encoder ouput, whether it is compliant with spec or not. And the matter is to check this by standard way - ie how it is defined in spec, right? So what we are talking about then?

drmpeg

2nd October 2006, 14:46

Ron,

you are right, but I still do not see what one want to compare here. The goal is to check encoder ouput, whether it is compliant with spec or not. And the matter is to check this by standard way - ie how it is defined in spec, right? So what we are talking about then?

I believe what akupenguin was getting at is that the rules for VBV are fixed, and the results are always the same for a bitstream. But in a mux, the leak rate can be different, so the results will be different depending on that leak rate.

However, both HD-DVD and BD use a multiplex, so you have to be both VBV and T-STD compliant.

Ron

Sergey A. Sablin

3rd October 2006, 11:12

I believe what akupenguin was getting at is that the rules for VBV are fixed, and the results are always the same for a bitstream. But in a mux, the leak rate can be different, so the results will be different depending on that leak rate.

However, both HD-DVD and BD use a multiplex, so you have to be both VBV and T-STD compliant.

Ron

I hope we agreed that at least elementary stream have to be compliant with spec. (and then if it need to be muxed T-STD compliant of course)

So we've downloaded two x264 clips: 6 and 12 mbps and checked both for AVC HRD model with next parameters:
buffer size: 9.5 mbit,
hss rate: 29.4 mbps,
init delay: 0.291 sec (which is 90% of buffer size))

Here is two pictures of buffer state:

6 mbps (ok):
http://img220.imageshack.us/img220/7382/x2646mbps2passvbvdy0.th.gif (http://img220.imageshack.us/my.php?image=x2646mbps2passvbvdy0.gif)

12 mbps (failed):
http://img215.imageshack.us/img215/9292/x26412mbps2passvbvxv1.th.gif (http://img215.imageshack.us/my.php?image=x26412mbps2passvbvxv1.gif)

To be compliant 12 mbps stream must have nearly 50 mbps hss rate with given buffer size. Though it is allowed by level 4.1, but not by rules of this comparison.

I think there is no need to download 24 mbps and verify it...

I also have some doubts about VC-1 compliance too, but didn't have a chance to verify it yet.

Sergey.

Sagittaire

3rd October 2006, 11:44

I hope we agreed that at least elementary stream have to be compliant with spec. (and then if it need to be muxed T-STD compliant of course)

So we've downloaded two x264 clips: 6 and 12 mbps and checked both for AVC HRD model with next parameters:
buffer size: 9.5 mbit,
hss rate: 29.4 mbps,
init delay: 0.291 sec (which is 90% of buffer size))

Here is two pictures of buffer state:

6 mbps (ok):
http://img220.imageshack.us/img220/7382/x2646mbps2passvbvdy0.th.gif (http://img220.imageshack.us/my.php?image=x2646mbps2passvbvdy0.gif)

12 mbps (failed):
http://img215.imageshack.us/img215/9292/x26412mbps2passvbvxv1.th.gif (http://img215.imageshack.us/my.php?image=x26412mbps2passvbvxv1.gif)

To be compliant 12 mbps stream must have nearly 50 mbps hss rate with given buffer size. Though it is allowed by level 4.1, but not by rules of this comparison.

I think there is no need to download 24 mbps and verify it...

I also have some doubts about VC-1 compliance too, but didn't have a chance to verify it yet.

Sergey.

Arrrrrggggghhhhh .... but really interessing ... lol

1) What did you use for check vbv compliancy?
2) I have an "old" AVC elecard encoder (CLI, encoder.exe, 26.01.2006). I can use it for this challenge?
3) You know the official vbv/cpb buffer for H264 and HDDVD?

Sergey A. Sablin

3rd October 2006, 12:15

Arrrrrggggghhhhh .... but really interessing ... lol

1) What did you use for check vbv compliancy?
2) I have an "old" AVC elecard encoder (CLI, encoder.exe, 26.01.2006). I can use it for this challenge?
3) You know the official vbv/cpb buffer for H264 and HDDVD?

1) Elecard Buffer Analyzer - http://www.elecard.com/products/products-pc/consumer/streameye-tools/
2) We may provide you latest one, but buffer restrictions you are using are really strict - I'm afraid no one encoder will do good work here.
3) yes, but as it is still confidential information I can't publish it here.

Sagittaire

3rd October 2006, 12:57

Q. You know the official vbv/cpb buffer for H264 and HDDVD?
R. yes, but as it is still confidential information I can't publish it here.

Buffer is confidential information ... ???

buffer restrictions you are using are really strict

It's a good information. I will use the same that VC1 for H264.

Sagittaire

3rd October 2006, 13:01

Sergey A. Sablin

3rd October 2006, 13:35

Annexe - Update

03.10.2006 - buffer for H264 is confidential but use 14400 Kbits is certainely compliant with HDDVD
02.10.2006 - official buffer for VC1 is 14400 Kbits or 480 ms for better HD-DVD compliancy
26.09.2006 - MPEG2 and H264 files with audio are available
19.09.2006 - MPEG2 metric result
18.09.2006 - H264 metric result

you could try to use BluRay buffer restrictions provided by Ron instead of "unknown" HD-DVD.
the other question is - how you want to proceed with x264? even with 30 mbit buffer 12mbps stream still underflowed by 38.5 mbit...

Sergey.

Sagittaire

3rd October 2006, 13:40

you could try to use BluRay buffer restrictions provided by Ron instead of "unknown" HD-DVD.

30000 Kbits is HD-DVD compliant ... ???

the other question is - how you want to proceed with x264? even with 30 mbit buffer 12mbps stream still underflowed by 38.5 mbit...

I will use your AVC encoder ... ;-)

We may provide you latest one

zambelli

4th October 2006, 11:25

Annexe - Update
26.09.2006 - MPEG2 and H264 files with audio are available
19.09.2006 - MPEG2 metric result
18.09.2006 - H264 metric result
I think you missed my 12Mbps VC-1 result - http://forum.doom9.org/showpost.php?p=881472&postcount=220 - and I also uploaded the 6Mbps VC-1 encoding to you recently.

Sagittaire

4th October 2006, 14:59

I think you missed my 12Mbps VC-1 result - http://forum.doom9.org/showpost.php?p=881472&postcount=220 - and I also uploaded the 6Mbps VC-1 encoding to you recently.

I wait benwagonner encoding for choose the best possible way for VC1 (from MS).

Moreover the buffer for the challenge became 14400 Kbits (480 ms or 12 frames at 25 fps) for better VC1 HDDVD compliance ...

The official H264 buffer seem really higher than official VC-1 buffer but I will choose certainely the same buffer for better direct comparison between VC-1 and H264.

Anyway I can't understand why each codec have different buffer restriction.

benwaggoner

4th October 2006, 22:44

I wait benwagonner encoding for choose the best possible way for VC1 (from MS).
Best possible? You've got a long wait :). That's like waiting for the x264 guys to finish their codec and stop with all the crazy updating.

I'll get you some samples when I can, but go ahead and use Zambelli's encodes for the time being.

Dethis

11th October 2006, 15:30

@ Sagittaire, Zambelli, Dr1394, Mutec

Would you be kind enough to upload logs of your Elephand Dream's encodings (6-12-24 Mbps).
i.e. frame Number - frame type (I,P,B) - dec. time, frame size (bytes).

Not just to calm down my curiosity about their vbv behavior but also to help me model & evaluate my simplistic vbv-checking spreadsheet.

Thanks in advance.

zambelli

11th October 2006, 20:47

@ Sagittaire, Zambelli, Dr1394, Mutec
Would you be kind enough to upload logs of your Elephand Dream's encodings (6-12-24 Mbps).
i.e. frame Number - frame type (I,P,B) - dec. time, frame size (bytes).
Not just to calm down my curiosity about their vbv behavior but also to help me model & evaluate my simplistic vbv-checking spreadsheet.
I think I'll re-encode the 6 and 12 Mbps VC-1 videos, now that the buffer size has been raised for VC-1. I'll post the PSNR logs and frame logs when they're done.

Sagittaire

12th October 2006, 19:40

I think I'll re-encode the 6 and 12 Mbps VC-1 videos, now that the buffer size has been raised for VC-1. I'll post the PSNR logs and frame logs when they're done.

Wait a little time please. I will make new rules for real world HDDVD encoding certainely more like that...

MPEG2 Encoding
Profil & Level: MP@HL except specific restrictions
Max GOP lenght: 15 frames
Maximum bitrate: 20.0 Mbps or 28.0 Mbps
Buffer size: 9781 Kbits for principal HD video stream
Horizontal Vector Range: +/- 1024 pixels
Vertical Vector Range: +/- 128 pixels
Other Restrictions Setting: max adaptative GOP at 15, max adaptative bframe at 2

VC-1 Encoding
Profil & Level: AP@L3 except specific restrictions
Max GOP lenght: 15 frames
Maximum bitrate: 20.0 Mbps or 28.0 Mbps
Buffer size: 14745 Kbits for principal HD video stream
Horizontal Vector Range: +/- 1024 pixels
Vertical Vector Range: +/- 256 pixels
Other Restrictions Setting: max adaptative GOP at 15, max adaptative bframe at 2

H264 Encoding
Profil & Level: HP@L4.1 except specific restrictions
Max GOP lenght: 15 frames
Maximum bitrate: 20.0 Mbps or 28.0 Mbps
Buffer size: 30000 Kbits for principal HD video stream
Horizontal Vector Range: +/- 1024 pixels
Vertical Vector Range: +/- 512 pixels
Other Restrictions Setting: max adaptative GOP at 15, max adaptative bframe at 2,
Max reference at 4, Max breference at 3, no film grain modeling

You must use these bitrate/size for encoding:

HD-DVD with "super bitrate" video stream and simple HDDVD authoring:
18 Mbps (Max at 28.0 Mbps) for video stream with +/- 1 % for bitrate tolerance
HD-DVD with "medium bitrate" video stream and standard HDDVD authoring:
12 Mbps (Max at 20.0 Mbps) for video stream with +/- 1 % for bitrate tolerance
HD-DVD with "low bitrate" video stream and standard HDDVD authoring:
6 Mbps (Max at 20.0 Mbps) for video stream with +/- 1 % for bitrate tolerance

NB: we can use HD-DVD structure too on simple DVD DL 12 cm at 8.5 GB ... ;-)

Multiplexing for all the stream must be at 30.24 Mbps and in reality the max bitrate for video will never at 29.8 Mbps. Standard HDDVD authoring use actually secondary video stream (certainely in SD) and/or Multiple HD audio stream. For this reason all the actual HDDVD movie use max bitrate at ~ 20 Mbps for the principal video stream.