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

[Sagittaire]

~ 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]

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]

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]

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

[Golgot13]

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]

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]

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

[SeeMoreDigital]

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]

@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]

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

[Dethis]

@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]

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]

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

[IgorC]

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

[CruNcher]

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]

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]

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]

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]

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]

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]

?

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]

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]

so where do we 'mail' our encodes?

[Taxidermista]

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]

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]

moved

[*.mp4 guy]

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]

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.
Thanks. Azureus RC2.5 seems to work fine with it.

[akupenguin]

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]

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]

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

[bkman]

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]

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

[smok3]

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]

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]

BitComet can handle it too.

[bkman]

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

[Sagittaire]

@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]

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]

@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]

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]

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).
how exactly did you copy/paste 1000 at a time? it's not an ftp, I can't drag and drop, and adding 1000 links manualy is insane.

[akupenguin]

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

[drmpeg]

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]

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]

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]

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]

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]

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]

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]

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

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

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

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

[crypto]

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

[Sagittaire]

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

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

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

[Golgot13]

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

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


What software do you use for MPEG2 encoding ?



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


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

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



Sagittaire your "lnbox" for privet message is full.

Golgot13

[Sagittaire]

What software do you use for MPEG2 encoding ?

Sagittaire your "lnbox" for privet message is full.

Golgot13

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

[zambelli]

Some comments on the WMV encoder line...

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

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

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

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

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

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

[zambelli]

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

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

[Sagittaire]

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

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


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

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

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

g_intVideoKeydist = 1000 * g_intVideoKeydist

i = i + 1

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

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

g_intVideoKeydist = 1 * g_intVideoKeydist

i = i + 1


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

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


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

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


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

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

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

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

[*.mp4 guy]

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

[Sagittaire]

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

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

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

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

[zambelli]

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

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

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

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

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

[drmpeg]

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

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

H.264 is also not restricted.

Ron

[zambelli]

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

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

I vote for 23.976fps encoding.

[drmpeg]

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

Ron

[Sagittaire]

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

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


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

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


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

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

H.264 is also not restricted.

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

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

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


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

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


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

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

[drmpeg]

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

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

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

Ron

[drmpeg]

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

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

Ron

[Sagittaire]

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

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

Ron

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

[Sagittaire]

Well I make modification for the test after reflexion:

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

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

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

[Sagittaire]

Here very partial result for H264:

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

encoded 15691 frames, 0.98 fps, 6011.45 kb/s

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

[Golgot13]

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

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


Golgot13

[Manao]

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

[zambelli]

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

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

[foxyshadis]

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

[Sagittaire]

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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


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

[Manao]

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

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

[Sagittaire]

I didn't say that either

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

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


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

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



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

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


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

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


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

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

[Sagittaire]

End of encoding for H264 ...

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

encoded 15691 frames, 0.65 fps, 23798.50 kb/s

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

[zambelli]

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

[Sagittaire]

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

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

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

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

[zambelli]

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

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

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

[zambelli]

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

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

After running PSNR and SSIM via Avisynth, I got:

Total frames processed: 15691
Minimum Average Maximum

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

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

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

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

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

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

SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 85.28804341

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

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

[Sagittaire]

At this time very partial result from the encoder itself:

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

H264 6000 Kbps, Overall PSNR = 45.80 dB

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

encoded 15691 frames, 0.98 fps, 6011.45 kb/s


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

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



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

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


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

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

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


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

[Manao]

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

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

[zambelli]

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

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

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

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

[zambelli]

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

[Sagittaire]

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

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


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

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


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

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


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

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

[Gabriel_Bouvigne]

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

[drmpeg]

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

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

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

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

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

Here's a graph of the bitrate:

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

And the average quantization per frame:

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

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

Ron

[Sagittaire]

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

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

@ drmpeg

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

[Sagittaire]

@ Zambelli

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

[Manao]

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

[drmpeg]

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

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

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

Ron

[drmpeg]

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

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

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

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

And a graph of VBV usage:

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

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

Ron

[zambelli]

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

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

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

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

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

[drmpeg]

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

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

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

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

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

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

Ron

[Sagittaire]

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

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

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

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

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

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

Ron


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

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


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

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

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

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

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

[Manao]

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

[Soulhunter]

@ Sagittaire

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

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

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

As you see you get wrong levels and banding!


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

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

Correct levels and no banding... ^^


Bye

[Sagittaire]

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

[zambelli]

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]

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]

@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

[drmpeg]

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]

@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

It works properly at bitrate less than 20Mbps. i think :)

[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 ???
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]

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]

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]

@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]

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]

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]

@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]

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

[*.mp4 guy]

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]

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

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

[IgorC]

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

[benwaggoner]

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]

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]

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]

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]

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]

@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]

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]

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]

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]

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]

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]

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]

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]

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

[*.mp4 guy]

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]

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]

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]

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

[benwaggoner]

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]

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]

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]

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]

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]

why should the framerate influence the visual quality?

[crypto]

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]

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

[Sagittaire]

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]

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]

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]

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]

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.

[crypto]

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]

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

[bond]

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

[Sagittaire]

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

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

[trbarry]

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

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

- Tom

[diogen]

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

Diogen.

[zambelli]

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

[drmpeg]

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

Ron

[drmpeg]

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

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

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

Ron

[crypto]

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

[benwaggoner]

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

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

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

[diogen]

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

Diogen.

[Sharktooth]

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

[Sagittaire]

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

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


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

Total frames processed: 15691
Minimum Average Maximum

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

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

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

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

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

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

... with really impressive result.

[Sharktooth]

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

[Sagittaire]

update: H264 metric result

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

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

[Sagittaire]

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

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

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

[zambelli]

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

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

[Sagittaire]

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

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

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

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

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

[drmpeg]

More graphs:

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

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

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

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

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

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

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

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

Ron

[Sagittaire]

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

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

[drmpeg]

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

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

Ron

[Sulik]

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

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

[Sagittaire]

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

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

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

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

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

[drmpeg]

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

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

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

Ron

[trbarry]

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

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

Ron

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

- Tom

[Sagittaire]

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

- Tom

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

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

[trbarry]

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

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

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

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

- Tom

[drmpeg]

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

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

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

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

Ron

[temporance]

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

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

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

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

[Sagittaire]

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

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


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

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


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

I will make that too.

[Sagittaire]

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

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

[drmpeg]

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

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

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

Ron

[Manao]

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

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

[drmpeg]

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

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

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

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

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

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

A zoom on the difficult sequence.

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

H.264 appears to be the victor.

Ron

[benwaggoner]

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


H.264 appears to be the victor.

Now them's fighting words!

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

[trbarry]

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

Ron -

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

- Tom

[zambelli]

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

[Sagittaire]

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

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

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

and complete CLI encoding with x264:

D:\Mes dossiers\Codec\x264>x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 294
00 --vbv-bufsize 9500 --qpmin 15 --level 4.1 --bframe 2 --b-rdo --bime --weightb
--ref 2 --mixed-refs --direct auto --filter -1:-1 --bitrate 6000 --pass 3 --sta
ts "H264_6Mbps.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.33 --analyse "all" -
-8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --pro
gress -o H264_6Mbps.mp4 azerty.avs
avis [info]: 1920x1080 @ 25.00 fps (15691 frames)
x264 [warning]: width or height not divisible by 16 (1920x1080), compression wil
l suffer.
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: slice I:1137 Avg QP:21.54 size:101388 PSNR Mean Y:48.49 U:58.52
V:57.12 Avg:49.44 Global:47.12
x264 [info]: slice P:6863 Avg QP:22.09 size: 38060 PSNR Mean Y:47.79 U:57.40
V:56.12 Avg:48.77 Global:46.46
x264 [info]: slice B:7691 Avg QP:23.74 size: 12251 PSNR Mean Y:47.28 U:59.93
V:58.14 Avg:48.38 Global:45.69
x264 [info]: mb I I16..4: 42.1% 40.5% 17.5%
x264 [info]: mb P I16..4: 11.7% 11.4% 2.4% P16..4: 30.4% 7.0% 3.0% 0.4% 0
.2% skip:33.5%
x264 [info]: mb B I16..4: 0.8% 1.4% 0.4% B16..8: 9.7% 1.2% 2.4% direct:
1.8% skip:82.2%
x264 [info]: 8x8 transform intra:43.6% inter:52.3%
x264 [info]: direct mvs spatial:74.5% temporal:25.5%
x264 [info]: ref P 80.1% 19.9%
x264 [info]: ref B 81.4% 18.6%
x264 [info]: SSIM Mean Y:0.9877791
x264 [info]: PSNR Mean Y:47.594 U:58.723 V:57.181 Avg:48.631 Global:46.110 kb/s:
5999.69

encoded 15691 frames, 1.25 fps, 6000.75 kb/s



D:\Mes dossiers\Codec\x264>x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 294
00 --vbv-bufsize 9500 --qpmin 10 --level 4.1 --bframe 2 --b-rdo --bime --weightb
--ref 2 --mixed-refs --direct auto --filter -1:-1 --bitrate 12000 --pass 3 --st
ats "H264_12Mbps.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.33 --analyse "all"
--8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --p
rogress -o H264_12Mbps.mp4 azerty.avs
avis [info]: 1920x1080 @ 25.00 fps (15691 frames)
x264 [warning]: width or height not divisible by 16 (1920x1080), compression wil
l suffer.
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: slice I:1135 Avg QP:15.82 size:174253 PSNR Mean Y:52.20 U:59.78
V:58.49 Avg:52.88 Global:50.57
x264 [info]: slice P:6861 Avg QP:16.29 size: 75734 PSNR Mean Y:51.29 U:58.75
V:57.58 Avg:52.04 Global:49.72
x264 [info]: slice B:7695 Avg QP:17.91 size: 29115 PSNR Mean Y:50.98 U:61.27
V:59.60 Avg:51.90 Global:49.13
x264 [info]: mb I I16..4: 32.9% 39.9% 27.2%
x264 [info]: mb P I16..4: 9.0% 13.3% 4.7% P16..4: 30.5% 11.2% 5.4% 0.8% 0
.6% skip:24.6%
x264 [info]: mb B I16..4: 0.8% 1.8% 0.7% B16..8: 13.3% 2.1% 4.3% direct:
4.1% skip:73.0%
x264 [info]: 8x8 transform intra:46.2% inter:35.9%
x264 [info]: direct mvs spatial:84.4% temporal:15.6%
x264 [info]: ref P 81.8% 18.2%
x264 [info]: ref B 80.8% 19.2%
x264 [info]: SSIM Mean Y:0.9935051
x264 [info]: PSNR Mean Y:51.205 U:60.059 V:58.637 Avg:52.031 Global:49.473 kb/s:
11999.59

encoded 15691 frames, 0.95 fps, 12000.61 kb/s



D:\Mes dossiers\Codec\x264>x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 294
00 --vbv-bufsize 9500 --qpmin 5 --level 4.1 --bframe 2 --b-rdo --bime --weightb
--ref 2 --mixed-refs --direct auto --filter -1:-1 --bitrate 24000 --pass 3 --sta
ts "H264_24Mbps.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.33 --analyse "all"
--8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --pr
ogress -o H264_24Mbps.mp4 azerty.avs
avis [info]: 1920x1080 @ 25.00 fps (15691 frames)
x264 [warning]: width or height not divisible by 16 (1920x1080), compression wil
l suffer.
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: slice I:1135 Avg QP:10.04 size:294208 PSNR Mean Y:55.88 U:62.04
V:60.79 Avg:56.44 Global:54.40
x264 [info]: slice P:6865 Avg QP:10.42 size:152867 PSNR Mean Y:54.77 U:60.67
V:59.54 Avg:55.36 Global:53.47
x264 [info]: slice B:7691 Avg QP:12.02 size: 65113 PSNR Mean Y:54.50 U:62.84
V:61.19 Avg:55.23 Global:52.79
x264 [info]: mb I I16..4: 24.7% 37.9% 37.5%
x264 [info]: mb P I16..4: 5.1% 12.7% 8.6% P16..4: 27.2% 15.0% 8.6% 1.3% 1
.5% skip:19.9%
x264 [info]: mb B I16..4: 0.6% 1.8% 1.5% B16..8: 16.3% 3.7% 7.8% direct:
5.8% skip:62.5%
x264 [info]: 8x8 transform intra:44.3% inter:32.2%
x264 [info]: direct mvs spatial:86.5% temporal:13.5%
x264 [info]: ref P 80.7% 19.3%
x264 [info]: ref B 80.4% 19.6%
x264 [info]: SSIM Mean Y:0.9967382
x264 [info]: PSNR Mean Y:54.716 U:61.831 V:60.440 Avg:55.379 Global:53.179 kb/s:
24015.59

encoded 15691 frames, 0.73 fps, 24016.60 kb/s

[trbarry]

Sagittaire -

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

- Tom

[Sagittaire]

Sagittaire -

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

- Tom

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

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

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

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


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

[trbarry]

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

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


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

- Tom

[skal]

Hi Sagittaire and all,


and complete CLI encoding with x264:

D:\Mes dossiers\Codec\x264>x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 29400 --vbv-bufsize 9500 --qpmin 15 --level 4.1 --bframe 2 --b-rdo --bime --weightb
--ref 2 --mixed-refs --direct auto --filter -1:-1 --bitrate 6000 --pass 3 --sta
ts "H264_6Mbps.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.33 --analyse "all" --8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --progress -o H264_6Mbps.mp4 azerty.avs


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

[Sharktooth]

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

[drmpeg]

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

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

Ron

[Sharktooth]

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

[drmpeg]

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

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

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

Ron

[GodofaGap]

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

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

[zambelli]

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

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

[Manao]

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

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

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

[GodofaGap]

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

[Dethis]

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

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

File : H264_6Mbps_final.mp4 by Sagittaire

Is this HD-DVD compliant ??

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

[drmpeg]

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

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

File : H264_6Mbps_final.mp4 by Sagittaire

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

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

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

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

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

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

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

Ron

[trbarry]

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]

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]

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]

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]

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]

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]

@ 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]

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]

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]

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]

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]

....


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]

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]

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]

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]

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]

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]

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.are those values valid for mpeg-2, vc-1 and avc the same way? or does each format have different limits?

[Manao]

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

[zambelli]

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]

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]

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]

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

why should it be?

[zambelli]

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]

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.

[Sergey A. Sablin]

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]

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?
I thought the whole idea was to sort out exactly what the details of the specs are and report how well they can be followed in different encoders, along with how well each can do at the best "reasonable" settings within those limits. That's why I've been following it closely, I'm very interested in compliance (which seems to be affirmative overall), all that's left is to mux, burn, and try playing a few.

In that case artificially limiting some to match the others is odd, but I guess I might be mistaken above.

[akupenguin]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Sergey A. Sablin]

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]

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]

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]

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]

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]

@ 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]

@ 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]

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.

[Dethis]

@ Sagittaire

I am a bit confused

Dr1394 already wrote that Mpeg-2 buffer is 9,781,248 bits

Zambelli already wrote that VC-1 buffer is 14,400 Kbit = 14,745,600 bits.

Please, declare the right values.

[foxyshadis]

kilobit = 1000 bits.
kilobyte = 1024 bytes.

This is just the way it works, for better or worse, and has for decades. All video bitrates are measured that way (except a few bad codecs).

[Dethis]

Thanks Foxyshadis.

So... the first post of this thread needs a litle editing;)

[drmpeg]

@ 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.
Here's an MPEG-2 test clip for you. It is an elementary stream.

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

And the statistics (including VBV) file.

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

Ron

[rezard]

@foxyshadis

though I'm not sure,
doesn't every unit related to 'bitrate' mean powers-of-1000?

[foxyshadis]

If you were to refer to kilobytes per second, it'd be correct to use 1024, though I'm sure codecs would get it wrong enough that the distinction would be meaningless. But as long as you're talking about bits, not bytes, powers are always in 1000s.

[benwaggoner]

If you were to refer to kilobytes per second, it'd be correct to use 1024, though I'm sure codecs would get it wrong enough that the distinction would be meaningless. But as long as you're talking about bits, not bytes, powers are always in 1000s.

K==1000

All the international standard units are properly power of 10. The power of 2 numbers should use a "iB" at the end, like KiB.

http://en.wikipedia.org/wiki/KiB

It's confusing, as there are plenty of areas where people use the wrong name for their units, but we should all be moving towards being precise about this, especially as storage gets bigger. It's a significant difference between a TB and a TiB.

[Dethis]

Here's an MPEG-2 test clip for you. It is an elementary stream.

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

And the statistics (including VBV) file.

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

Ron

:thanks:

[zambelli]

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

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
Are these your final rules? Can I re-encode the WMV9 videos now? I will be using the "generic" Vista/WMP11 encoder DMO, but a few of us at MS are also working on some encodes done with our professional VC-1 encoder. You don't have to wait for the latter - let's just tally the results as they come in and keep the highest score.

Also, I vote that the current results be reset/deleted due to the change in spec rules. I also propose that from this point on any result submission must be accompanied by the PSNR log, SSIM CSV and SSIM summary generated by the respective Avisynth plugins. I've seen too many results just "show up" in the results table without anything to back them up. It's not that I don't trust you :), I just like a transparent competition. Also, if you're going to record the highest score, you should probably also note the software, revision, and encoding settings used.

[arfster]

Ditto - I've got plenty of spare computer cycles as well, and wouldn't mind a shot :-)


ps could anyone possibly seed the Elephant Dreams Torrent?

[zambelli]

ps could anyone possibly seed the Elephant Dreams Torrent?
Short of getting a torrent, your best bet is to download Wackget from http://millweed.com/projects/wackget and then run this command:
wget -r -l 1 -A png http://media.xiph.org/ED/ED-1080-png/
This will download each source PNG file from the ED website.

[bob0r]

...

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


Let me be stupid here (1024 bytes used):
DVD9
8533311488 B
8333312 KB
8138 MB
7.94 GB

[arfster]

Short of getting a torrent, your best bet is to download Wackget from.....


Thanks, worked. With Sagittaire's latest restrictions here....

http://forum.doom9.org/showthread.php?p=886879#post886879

...., my h264 12mbit encode come up with 49.675dB from the x264 prompt (see attached). Probably not comparable with the previous records, because this has 20mbit rather than 29mbit peak limit, and different b-refs. Still, it looks pretty much pristine compared to the original, so SSIM is probably 92/93 or so.

I'll run the avisynth psnr/ssim2 scripts later and edit the logs into this post, but have we settled on these new restrictions? The encodes take about 10 hours (max everything, 3-pass), or perhaps about 4 hours with 0.5 less dB, so it's no great problem to run them overnight.


Edit: end results from Avisynth are...

PSNR min: 38.8690
PSNR average: 49.6843
SSIM2: 94.22763493

[arfster]

... and 6mbit, again done with latest Sagittaire settings:


Average PSNR: 46.3835dB
Min PSNR: 34.5825db
SSIM2: 89.50666592


Hugely impressive SSIM for a 6mbit encode, although the min PSNR is low. Watching that sequence it doesn't really show though, as much of the bitrate is being consumed by background stuff that doesn't need to be terribly detailed.

[arfster]

18mbit, same conditions as before but 28mbit peak.


Average PSNR: 52.0348
Min PSNR: 37.0249
SSIM2: 95.87262239


The min PSNR is worse than 12mbit, but that's a single frame glitch. Even in the 2800-3200 hardest sequence, it's all at 45-50db. Clearly the higher 28mbit peak helps hugely here.

Thus, for the 3 encodes:

Mbit SSIM2 PSNR
6 89.5 46.4
12 94.2 49.7
18 95.9 52.0

The 18mbit looks a bit like overkill from the above, and from a quick look I can't tell the difference visually between it and 12mbit. Related to this, I found:

http://www.compression.ru/video/codec_comparison/01_subject_codec_comparison/subject_codec_comparison_part3.htm

Scroll down, they have correlations for SSIM, PSNR and VQM vs subjective rankings of 50 people. It's pretty clear that SSIM is massively superior to the other two.

[Sagittaire]

unfortunaly x264 don't respect the vbv buffer in multipass mode ...

[zambelli]

unfortunaly x264 don't respect the vbv buffer in multipass mode ...
Sagittaire, why is H.264 buffer size defined according to BluRay spec whereas the VC-1 buffer size is defined according to HD-DVD spec? It gives H.264 an unfair advantage. The buffer restriction is imposed by the HD-DVD and BD spec respectively, not by the codecs, so why set them differently?

[Sergey A. Sablin]

unfortunaly x264 don't respect the vbv buffer in multipass mode ...

even more - it doesn't follow HRD model in any RC mode, because devs use mpeg-2 vbv model instead of what is described in the spec. Plus CBR has no padding - so even for mpeg-2 vbv model overflow is it's usual state for low complexity scenes.

btw, we send you latest encoder a week ago - did you have a time to play with it? any results?

[Sagittaire]

btw, we send you latest encoder a week ago - did you have a time to play with it? any results?

oh sorry (I will make mail for thanks and questions) ... :thanks:

1) Your encoder work perfectly. Better quality than the last version with new setting.
I Try to find the best possible setting for metric and/or for my eyes.

2) I have problem with streameyes. Perhaps limitation for evaluation version. I will see that.


Sagittaire, why is H.264 buffer size defined according to BluRay spec whereas the VC-1 buffer size is defined according to HD-DVD spec? It gives H.264 an unfair advantage. The buffer restriction is imposed by the HD-DVD and BD spec respectively, not by the codecs, so why set them differently?

Well it's true. It's really strange but buffer for each codec seem different for HDDVD. For principal video stream VC1 use higher buffer than MPEG2 ( 14 745 Kbits vs 9 781 Kbits) and H264 buffer seem higher than VC1 ( 30 000 Kbits vs 14 745 Kbits). I don't know the exact value for H264 but 30 000 Kbits seem compliant with HDDVD.
http://forum.doom9.org/showthread.php?p=882932#post882932
http://forum.doom9.org/showthread.php?p=882963#post882963

And you say yourself that:
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?

[Sergey A. Sablin]

oh sorry (I will make mail for thanks and questions) ... :thanks:

1) Your encoder work perfectly. Better quality than the last version with new setting.
I Try to find the best possible setting for metric and/or for my eyes.

2) I have problem with streameyes. Perhaps limitation for evaluation version. I will see that.

feel free to email/pm me or mutek for both questions.

[zambelli]

I'll ask again: why is VC-1 buffer size 14745 kbits, while H.264 buffer size is 30000 kbits?

[guada 2]

I'll ask again: why is VC-1 buffer size 14745 kbits, while H.264 buffer size is 30000 kbits?

I don't know, but H264 size max is 32182 Kbits.

[arfster]

unfortunaly x264 don't respect the vbv buffer in multipass mode ...

Yeah - I only noticed that after doing the encodes :-) Oh well, no great hassle, it was on lowest priority so wasn't taking time from anything else, and the box is on 24/7 anyway.

Anyone got a tool to check buffer use yet? The Elecard tool doesn't work with h264 encodes (HRD parameters not present).

[MuTeK]

The Elecard tool doesn't work with h264 encodes (HRD parameters not present).

Elecard BufferAnalyzer operates with all streams (MPEG-2, MPEG-4 AVC/H264 and VC-1), but as it was mentioned correctly, the stream should have HRD parameters. If there are no such parameters, it’s impossible to analyze such streams.

Ps I think it makes sense to ask devs of x264, why they are reluctant to write these parameters into the stream first.

[arfster]

Elecard BufferAnalyzer operates with all streams (MPEG-2, MPEG-4 AVC/H264 and VC-1), but as it was mentioned correctly, the stream should have HRD parameters.

Sorry, meant to write x264 rather than h264. It's obviously not the Elecard tool's fault here.

[akupenguin]

why they are reluctant to write these parameters into the stream first.
Because it's complicated. The standard does not allow you to just write down the buffer size and maxrate used. If you include any hrd parameters, you must include an sei packet at every keyframe detailing the state of the vbv buffer. And stuff like that.

I use vbv.pl (http://akuvian.org/src/x264/vbv.pl) to verify vbv ratecontrol. It doesn't look at the stream at all, just the output of `x264 -v`.

[MuTeK]

Anyone got a tool to check buffer use yet?

Tektronix.. :) (http://www.tek.com/products/video_test/mts4ea/index.html)

[Sagittaire]

I'll ask again: why is VC-1 buffer size 14745 kbits, while H.264 buffer size is 30000 kbits?

Simply because each codec use differents values for the buffer.

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

1222000 bytes for MPEG2 Main Video HD (or 9 781 000 bits)
1843200 bytes for VC1 Main Video HD (or 14 745 000 bits)
xxxxxxxx bytes for H264 Main Video HD (or xx xxx xxx bits)

The HDDVD buffer is unknow and confidential for H264 but according Sergey A. Sablin 30 000 000 bits is compliant with HDDVD spec.
http://forum.doom9.org/showthread.ph...932#post882932
http://forum.doom9.org/showthread.ph...963#post882963


I don't know, but H264 size max is 32182 Kbits.

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

[zambelli]

The HDDVD buffer is unknow and confidential for H264 but according Sergey A. Sablin 30 000 000 bits is compliant with HDDVD spec.
Not according to my info. Our resident HD-DVD guru says: "Both codecs, within HD DVD, are 1843200 bytes for main video. There is no other option."
It would not make sense to have H.264 have a buffer nearly twice the size of VC-1's because the two codecs are expected to use very similar bitrates.

[Sagittaire]

Not according to my info. Our resident HD-DVD guru says: "Both codecs, within HD DVD, are 1843200 bytes for main video. There is no other option."
It would not make sense to have H.264 have a buffer nearly twice the size of VC-1's because the two codecs are expected to use very similar bitrates.

MPEG2, VC1 and H264 can and must use the same buffer for main HD video stream (14 475 Kbits) for HD-DVD ... ???

Your "HDDVD guru" can confirm that ... please. It's strange because Sergey A. Sablin (Elecard/MainConcept H264 dev) doesn't say that ... ???

[Sergey A. Sablin]

Not according to my info. Our resident HD-DVD guru says: "Both codecs, within HD DVD, are 1843200 bytes for main video. There is no other option."
It would not make sense to have H.264 have a buffer nearly twice the size of VC-1's because the two codecs are expected to use very similar bitrates.

right now I'm checking dvd specification for high definition video version 0.9 (probably outdated, but I haven't newer version) and see that 30 mbit buffer is allowed for H.264 for HD content. While VC-1 has restriction of 1843200 bytes as you said.

latest version I know is 1.01, but I haven't it yet, so maybe some changes were done, but I dont know any.

[arfster]

Someone requested stats from my encodes above to check for buffer compliancy, thought I'd post here in case anyone else wants to use them also......

[benwaggoner]

right now I'm checking dvd specification for high definition video version 0.9 (probably outdated, but I haven't newer version) and see that 30 mbit buffer is allowed for H.264 for HD content. While VC-1 has restriction of 1843200 bytes as you said.

latest version I know is 1.01, but I haven't it yet, so maybe some changes were done, but I dont know any.
I confirm that all HD DVD codecs use the same buffer size, and we should be using the above value for this test.

I'm also concerned by the fact that H.264 is allowed larger motion vectors in the test than VC-1. I haven't looked at that in as much detail, but I suspect that is likely in error as well.

[Sagittaire]

I confirm that all HD DVD codecs use the same buffer size, and we should be using the above value for this test.


Really good news ... I will use the same buffer for all codec. But it's strange that MPEG2 MP@HL can use 14 745 KBits for the buffer ... ???


I'm also concerned by the fact that H.264 is allowed larger motion vectors in the test than VC-1. I haven't looked at that in as much detail, but I suspect that is likely in error as well.


Well +/- 256 or +/- 512 don't change really the quality for 1080p source. Anyway I think that the compliant value is +/- 512 for HDDVD (typically level 4.1 limitation like reference frame)

I want use WME Studio Edition beta1 for make test in batch mode. I can use the same registry command than WM9E? You can done the best possible hddvd.epr profil?

Here my actual hddvd.epr

<?xml version="1.0" standalone="no"?>
<Project xmlns="http://microsoft.com/schemas/WMESE.xsd">
<Name>Untitled</Name>
<Id>{3FE09976-4820-4AA7-93A5-9ABC9D5C5E1D}</Id>
<TempOutputDirectory>C:\Documents and Settings\JFL\Local Settings\Temp</TempOutputDirectory>
<Timeline>
<Sources>
<Source id="1">
<SourceUrl>C:\Program Files\Windows Media Components\Encoder\HDDVD.avs</SourceUrl>
<VideoStreamOverride>
<StreamIndex>0</StreamIndex>
</VideoStreamOverride>
</Source>
</Sources>
<Tracks>
<VideoTrack>
<Name>Untitled</Name>
<Clips>
<Clip>
<Id>{70B844C1-CB67-484D-8EAE-833C2CC488F3}</Id>
<Name>HDDVD.avs</Name>
<SourceRef id="1" streamIndex="0"/>
<MarkIn>0</MarkIn>
<MarkOut>400400000</MarkOut>
<Preprocessing>
<Resizing>
<Cropping>
<Left>0</Left>
<Top>0</Top>
<Width>1920</Width>
<Height>1080</Height>
</Cropping>
<Dithering>true</Dithering>
</Resizing>
</Preprocessing>
</Clip>
</Clips>
<Streams>
<VideoStream>
<IsStreamSelected>true</IsStreamSelected>
<Name>Untitled</Name>
<Codec>{31435657-0000-0010-8000-00AA00389B71}</Codec>
<EncodingMode>PeakVBR</EncodingMode>
<EncoderComplexity>4</EncoderComplexity>
<DecoderComplexity>1</DecoderComplexity>
<KeyframeDistance>600</KeyframeDistance>
<ProduceAllFrames>true</ProduceAllFrames>
<Bitrate>6000000</Bitrate>
<PeakBitrate>20000000</PeakBitrate>
<BufferSize>480</BufferSize>
<GOPType>closed</GOPType>
<LoopFilter>true</LoopFilter>
<Lookahead>16</Lookahead>
<BFrames>2</BFrames>
<ChromaSearch>true</ChromaSearch>
<MVRange>-1</MVRange>
</VideoStream>
</Streams>
<Width>1920</Width>
<Height>1080</Height>
<FPS>25.000000</FPS>
<OutputInterlaceMode>Progressive</OutputInterlaceMode>
<AspectRatioIndex>0</AspectRatioIndex>
<XPixelAspectRatio>1</XPixelAspectRatio>
<YPixelAspectRatio>1</YPixelAspectRatio>
</VideoTrack>
</Tracks>
</Timeline>
<Output>
<AsfOutput>
<OutputUrl>C:\Program Files\Windows Media Components\Encoder\Untitled.wmv</OutputUrl>
<AutoAdjustRate>true</AutoAdjustRate>
<Metadata>
<String Name="Title" Value=""/>
<String Name="Author" Value=""/>
<String Name="Description" Value=""/>
<String Name="Copyright" Value=""/>
<String Name="ISAN" Value=""/>
<String Name="ADID" Value=""/>
</Metadata>
</AsfOutput>
</Output>
</Project>

[bond]

I don't know, but H264 size max is 32182 Kbits.where do you have that info from?

[Sergey A. Sablin]

I confirm that all HD DVD codecs use the same buffer size, and we should be using the above value for this test.
first of all I should say that I'm not against of fair comparison when all codecs use same settings for buffer, but I still dont understand where did you get your information from (except of some guru), so my question is:
which version are you refering to? It is clearly stated above which information and from where I have - you just told "I confirm..." Any details? Or gentlemans from MS dont need to prove their statement in this forum?
Right now I have august 2006 version and see that no changes on buffer constrains were made since 0.9. (and if you have a doc then you should see that AVC constrains are way weaker then 30 mbit, so I'm really confusing by your statement of identical parameters for all codecs)

I'm also concerned by the fact that H.264 is allowed larger motion vectors in the test than VC-1. I haven't looked at that in as much detail, but I suspect that is likely in error as well.

I'm also concerning by the fact that MPEG-2 vbv model (and VC-1, cause it is the same) is much easy/effective to use when buffer state is near floor. Seems to be a bit more advantage than a length of MVs. And it seems the should be a difference for buffer parameters if buffer models are different, dont you?

[Sagittaire]

Right now I have august 2006 version and see that no changes on buffer constrains were made since 0.9. (and if you have a doc then you should see that AVC constrains are way weaker then 30 mbit, so I'm really confusing by your statement of identical parameters for all codecs)


For principal HD video stream buffer are:
- 9781 Kbits for MPEG2 MP@HL
- 14745 Kbits for VC-1 AP@L3
- 30000 Kbits for MPEG4 AVC HP@L4.1

Yes or No for this august 2006 version ... ???



I'm also concerning by the fact that MPEG-2 vbv model (and VC-1, cause it is the same) is much easy/effective to use when buffer state is near floor. Seems to be a bit more advantage than a length of MVs. And it seems the should be a difference for buffer parameters if buffer models are different, dont you?


VBV limitation are typical hardware limitation:
- Max bitrate is fixed for the optical speed (DVD 3X or HDDVD 1X).
- Max buffer is fixed by the hardware decoder chip buffer capacity.

IMO in theory all the codec could use the same buffer. IMO chip for HDDVD and BD decoding will be the same and in theory the max buffer for principal HD stream could be 30 000 Kbits for all video codec in this case. It's strange.

[Sergey A. Sablin]

For principal HD video stream buffer are:
- 9781 Kbits for MPEG2 MP@HL
- 14745 Kbits for VC-1 AP@L3
- 30000 Kbits for MPEG4 AVC HP@L4.1

Yes or No for this august 2006 version ... ???


I already said that content of both HD-DVD and BluRay specs is confidential. So I couldn't disclosure it.
I already said that 30 mbit is allowed for AVC for HD-DVD.
If zambelli or benwaggoner have different information then at least it is interesting where it came from.

(well, maybe ron/drmpeg has hd-dvd spec, so try to ask him about this)

VBV limitation are typical hardware limitation:
- Max bitrate is fixed for the optical speed (DVD 3X or HDDVD 1X).
- Max buffer is fixed by the hardware decoder chip buffer capacity.
Thanks, I'll take a note of this


IMO in theory all the codec could use the same buffer. IMO chip for HDDVD and BD decoding will be the same and in theory the max buffer for principal HD stream could be 30 000 Kbits for all video codec in this case. It's strange.
Specs have some different specific restrictions on decoding (particularly on avc decoding), so probably there will be different chips.

[trbarry]

The buffer size thing seems to be a complex issue, with two different specs and some proprietary info. But I feel fairly strongly that for the purpose of this shootout both (all) codecs should be restricted to the same size. Since it is such a limiting factor it just wouldn't be a good comparison otherwise as it greatly affects min psnr.

- Tom

[Sergey A. Sablin]

The buffer size thing seems to be a complex issue, with two different specs and some proprietary info. But I feel fairly strongly that for the purpose of this shootout both (all) codecs should be restricted to the same size. Since it is such a limiting factor it just wouldn't be a good comparison otherwise as it greatly affects min psnr.

- Tom

I'm not against this as I already said - let's use same size for all codecs. (but mind that different buffer models lead to different quality is some situation with same buffer parameters)

[zambelli]

I already said that content of both HD-DVD and BluRay specs is confidential. So I couldn't disclosure it.
I already said that 30 mbit is allowed for AVC for HD-DVD.
We can settle the matter easily: can you specify the page and paragraph where HD-DVD spec indicates that H.264 buffer is 30 Mbits? Perhaps we're just looking in completely different places or somebody is misreading the spec. We should get on the same page - literally. :)

[Sergey A. Sablin]

We can settle the matter easily: can you specify the page and paragraph where HD-DVD spec indicates that H.264 buffer is 30 Mbits? Perhaps we're just looking in completely different places or somebody is misreading the spec. We should get on the same page - literally. :)

till now I even didn't heard that you have a spec - you always talking about some mystic guru.
And how we can see at any page if you even didn't tell yet which version of spec do you have? (or your guru)

PS: I didn't said that spec restriction is exactly 30 mbit, instead I said it is allowed ;)
PSS: check your PM box - lets discuss spec there

[guada 2]

Hello,

Sagittaire & bond:
I think it is not important to know the place.

Specs (and others) are a great factor for VLD+IQ and for "IDCT+MC".........

Other thing:
i think it is most interesting to compare Buffer size and PSNR : buffer size (macroblocks) / buffer sizes (for different values of ε) and to find the best quality (dB); but it's very complicated on Higher résolution especially in Real Time.

However i am a little confused...
when i read that:
On level number :5 (0-1)
max. Bitrate :135000 kbps
max. Decoded: 135000 kbps
picture buffer: 41310.0 kByte
max. decoder rate: 589824 macroblocks/s
max. Framesize: 1920x1088 @ 72fps


and this new level for super high-resolution video to MPEG-4 AVC/H.264 Profiles 5.2 (4096*4096):

Level number: 5.2 (expérimental)
Max macroblock processing rate MaxMBPS (MB/s): 983040
Max frame size MaxFS (MBs): 65536
Max decoded picture buffer size MaxDPB (1024 bytes): 69120,0
Max video bit rate MaxBR (1000 bits/s or 1200 bits/s): 240000
Max CPB size MaxCPB (1000 bits or 1200 bits): 240000
Vertical MV component range MaxVmvR (luma frame samples):
[-512,-511.75]
Min compression ratio MinCR: 2
Max number of motion vectors per two consecutive MBs
MaxMvsPer2Mb: 16

Bye.

[Sagittaire]

Hello,

Sagittaire & bond:
I think it is not important to know the place.

Specs (and others) are a great factor for VLD+IQ and for "IDCT+MC".........

Other thing:
i think it is most interesting to compare Buffer size and PSNR : buffer size (macroblocks) / buffer sizes (for different values of ε) and to find the best quality (dB); but it's very complicated on Higher résolution especially in Real Time.

(...)


and this new level for super high-resolution video to MPEG-4 AVC/H.264 Profiles 5.2 (4096*4096):

(...)

Bye.

........... ???

HDDVD and BD use H264 HP@L4.1. For this level "max bitrate" is 50 Mbps and "max cpb" is 62500 Kbits but HDDVD and BD don't use these max vbv specifications ...

[guada 2]

HDDVD and BD use H264 HP@L4.1. For this level "max bitrate" is 50 Mbps and "max cpb" is 62500 Kbits but HDDVD and BD don't use these max vbv specifications ...

OK. thanks

But are you sure BD use H264 L4.1.
I doubt a little, perhaps you are right then what sort of BD use 3.2?

[sillKotscha]

sorry to disturb this very informative thread based on very high technical knowledge. This is far beyond my enthusiasm for video encoding as my beloved hobby, but... :)

after reading the whole thread I came across one post by Sagittaire from 24th September 2006 (http://forum.doom9.org/showpost.php?p=879364&postcount=204)...

he states:


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.

as a remark to
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

as it seems this is really true for real life environments as well...

a german homecinema magazine was testing the very first devices available for the end user, shipped directly from the US to germany in early august. Participant were the Toshiba HD-XA1 for the HD-DVD camp (the tested discs use VC-1) and the Samsung BD-P1000 for the Blu-ray camp (the tested discs use MPEG2). They were testing in a full HD compliant way = projectors capable of native Full-HD resolution of 1920 x 1080 (VPL-VW100 and Qualia004 by sony).

I won't go into detail here but to summerize their conclusion is easy... BD (MPEG2) was clearly beaten by HD-DVD (VC-1) in terms of visual satisfaction. For them the limiting factor was clearly MPEG2 compression BUT to be fair in conjunction with lower disc space (at the moment you'll only see single layer BD = 25GB vs. HD-DVD = 30GB) + Sony for example insist on using PCM as audio source (for the time being!!) and was not using Dolby Digital + or DTS HD. That might have changed though but it was true for the tested discs.

As for the starting of a new technology this is somewhat "bad luck" for the BD camp and it seems(!!) as HD-DVD/ VC-1 will make it...

here you will find the test (http://www.cine4home.de/tests/sonstiges/BDvsHD/BRvsHDDVD.htm) and even if you can't read german, you can scroll down to see which movie/ studio titles were tested for each technology...

just my 2 cents

[drmpeg]

OK. thanks

But are you sure BD use H264 L4.1.
I doubt a little, perhaps you are right then what sort of BD use 3.2?
BD allows L3, L3.1, L3.2, L4 and L4.1 levels. I would expect the possible usage is:

SD video = L3
1280x720p24 = L3.1
1280x720p60 video = L3.2
1920x1080i30 or 1920x1080p24 = L4
1920x1080i30 or 1920x1080p24 over 20 Mbps = L4.1

Ron

[Sagittaire]

I won't go into detail here but to summerize their conclusion is easy... BD (MPEG2) was clearly beaten by HD-DVD (VC-1) in terms of visual satisfaction. For them the limiting factor was clearly MPEG2 compression BUT to be fair in conjunction with lower disc space (at the moment you'll only see single layer BD = 25GB vs. HD-DVD = 30GB) + Sony for example insist on using PCM as audio source (for the time being!!) and was not using Dolby Digital + or DTS HD. That might have changed though but it was true for the tested discs.

As for the starting of a new technology this is somewhat "bad luck" for the BD camp and it seems(!!) as HD-DVD/ VC-1 will make it...

just my 2 cents

Well be carefull ...

1) This challenge test only codec for HDDVD. BD has other vbv specification and very better max bitrate than HDDVD (in practice certainely something like 35 Mbps for video stream)

2) The MPEG2 implementation from Sony is perhaps not the best available ... see atrac codec from Sony for example. IMO MPEG2 encoding (with best possible implementation) at 24 Mbps will done always very better result than VC1 encoding at 12 Mbps.

3) The Samsung SAP is not a very good BD player.

4) IMO HD-DVD camp use certainely pre-process for the master (denoising and perhaps sharpening) for make "better visual" encoding.

[guada 2]

BD allows L3, L3.1, L3.2, L4 and L4.1 levels. I would expect the possible usage is:

SD video = L3
1280x720p24 = L3.1
1280x720p60 video = L3.2
1920x1080i30 or 1920x1080p24 = L4
1920x1080i30 or 1920x1080p24 over 20 Mbps = L4.1

Ron

:thanks:


Originally Posted by drmpeg
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

I would think that is was possible HD DVD L4.1 obtain some 34 Mbps (peak bitrate)...


1) This challenge test only codec for HDDVD. BD has other vbv specification and very better max bitrate than HDDVD (in practice certainely something like 35 Mbps for video stream)

OHOOOOOH...

[popper]

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


hi crypto, just started reading this thread and wanted to put the original UK and EU case of 25/50/P rather than the oddball US standards, remember that the UK's BBC and its other content producers has already set the standard PAL 25/50 P in much of the world.

for instance the newest BBC DVB HD trials have already set some industry standards that the much of the world will be using soon enough, heres a link to the bbc delivery outlines
http://www.bbc.co.uk/guidelines/dq/pdf/tv/hd_summary_delivery_formats_v1_3.pdf

they take their DK very seriously and protect their markets very carefully http://www.bbc.co.uk/commissioning/production/hd.shtml

in all their official documentation you will see its 25/50 and progressive and sometimes 100 for future inovation.

im pritty sure that the other vast pal/partner countrys markets are also not looking to use oddball framerates were standard 25/50 serves just fine and has done for a very long time.

why dont the US simply convert to PAL 25/50 ? as its better all round after all , and these new HD sets and related kit are already mass produced by our eastern friends in all flavours of PAL (with NTSC bolted on for convenience) so its not hard to get these new 1080P sets etc and over time the price will fall.

and thats not even mentioning all the Professional HD progressive 25/50 pal camera's and related kit that the UK film/broadcasters and content makers commission that everyone wil use one day.

[zambelli]

hi crypto, just started reading this thread and wanted to put the original UK and EU case of 25/50/P rather than the oddball US standards, remember that the UK's BBC and its other content producers has already set the standard PAL 25/50 P in much of the world.
By "oddball" I'm assuming you're referring to 29.97. The argument was never about whether this should be 25 or 29.97. The argument was whether it should be 25 or 23.976, and 23.976 (or 24 fps) is far from an "oddball" standard.

why dont the US simply convert to PAL 25/50 ?
They will, right after they switch to metric. :D

Wheh will PAL support 24 fps playback without speedup? ;)

[foxyshadis]

Now that LCD TVs can be set to any given refresh rate, and the newer HD standards all dictate supporting at least 24p in addition to region-specific ones, I think the whole debate is rapidly becoming moot. I can already buy NTSC/PAL TVs very cheaply, and likely soon all will be able to use both.

[benwaggoner]

4) IMO HD-DVD camp use certainely pre-process for the master (denoising and perhaps sharpening) for make "better visual" encoding.
Finally got around to coming here after a few weeks :).

No, the VC-1 encoding tool used for virtually all HD DVD titles doesn't do any kinds of processing like that. There is an optional denoise filter, but it isn't significantly used with HD DVD. And there's no sharpening filter at all.

I realize most folks here aren't used to looking at good D5 masters, but HD DVD titles are the closest consumers have ever gotten.

So, if it looks sharp, it's because the master was sharp :).

[IgorC]

Related topic. http://forum.doom9.org/showthread.php?p=908902#post908902

It is about new metrics. Maybe it's good as SSIM.

[trbarry]

Whatever happened to this effort? Early results seemed to suggest X264 was a tiny bit better than VC1 and both were a lot better than MPEG-2. But now all results are missing from the first page and there's been no activivity for a month or so.

Did everybody lose interest?

- Tom

[McCrash]

I think the interest is still there but it shifted towards authoring issues and HD-DVD compliance since whatever result come from x264 or wme we are unable to use it in hd-dvd assets.

From a non professional point a view, i would say avc kicks ass but vc1 requires less horsepower, isn't ?

http://forum.doom9.org/showthread.php?t=119392

[vsv]

How about to compare mpeg2/avc/vc1 encoded in same tool as CineVision vs x264 (pro tool vs free encoder) ?

[Sagittaire]

Well perhaps a new big comparison for the holiday:
- AVC from Elecard/Mainconcept, x264 and other professional encoder
- VC1 from Elecard/Mainconcept and MS PEP
- MPEG2 from Elecard/Mainconcept, Libavcodec and HCEnc

and with real 1080p23.976 HDDVD compliant stream.

[CruNcher]

There's also a new Microsoft Encoder (after their aquire of iview)
http://www.microsoft.com/expression/products/overview.aspx?key=encoder
it's part of the Expression Media, i had no time yet to look @ it but it seemes just to be another dshow gui (future interface design, skinned Vista styleish hehe) with direct api connection to the current wmv sdk so nothing new (at least nothing that would increase speed of encoding it seams for the normal prosumer/consumer q the moment) except those silverlight features, would be cool to compare silverlight streaming video vs flash streaming video in terms of cpu utilization accelerated/non acellerated in the accellerated scenario silverlight would win without any doubt, but whats about the non accellerated scenario hehe, also interesting to test vs the new Apple Google/Youtube H.264 videos and if they get accellerated,sorry for going a little oftop to much testing stuff in my head ;).

[^_^x]

how 'bout to change the restrictions
1. use the same avs source
2. max bitrate 700 (what!!!)
3. allow all optimal maximum setting of your codec have
4. no external filtering

hmm, yaps it is...

[MarcioAB]

and with real 1080p23.976 HDDVD compliant stream.

Parallel question: Will this 24p fps stream be stored in a container at the same 24p fps or will it be telecine flagged for 25 or 30 fps ?

If stored in the container as 24p fps will it be compliant with HDDVD specs ?

Thank you

[benwaggoner]

In order to stop us arguing about spec issues, does anyone have acccess to the Sonic HD DVD muxer? If so, we can agree on peak and average data rate, and just make the contest about who can make the best looking compliant stream that'll mux.

As for the container question, best we submit elementary streams using the 59.94 flagging.

Our encoder doesn't use .avs directly, but we can use GraphEdit to dump a raw .yuv from that, so we'd be getting the same pixels.

[benwaggoner]

There's also a new Microsoft Encoder (after their aquire of iview)
http://www.microsoft.com/expression/products/overview.aspx?key=encoder
it's part of the Expression Media, i had no time yet to look @ it but it seemes just to be another dshow gui (future interface design, skinned Vista styleish hehe) with direct api connection to the current wmv sdk so nothing new (at least nothing that would increase speed of encoding it seams for the normal prosumer/consumer q the moment) except those silverlight features, would be cool to compare silverlight streaming video vs flash streaming video in terms of cpu utilization accelerated/non acellerated in the accellerated scenario silverlight would win without any doubt, but whats about the non accellerated scenario hehe, also interesting to test vs the new Apple Google/Youtube H.264 videos and if they get accellerated,sorry for going a little oftop to much testing stuff in my head ;).
Wow, that was a long sentence!

Yes, Expression Media Encdoder is based on the Format SDK 11, like other commercial tools. Although it has other useful new features, like:

Support for .mov and .mpg source files
A better deinterlacer and scaler (not in the beta)
Lots of great Silverlight integration, enabling stuff like graphical thumbnail navigation to be built while compressing.


It won't do anything relevant to HD DVD, though. It's very focused on Silverlight.

[R3Z]

Wow, that was a long sentence!

Yes, Expression Media Encdoder is based on the Format SDK 11, like other commercial tools. Although it has other useful new features, like:

Support for .mov and .mpg source files
A better deinterlacer and scaler (not in the beta)
Lots of great Silverlight integration, enabling stuff like graphical thumbnail navigation to be built while compressing.


It won't do anything relevant to HD DVD, though. It's very focused on Silverlight.

Encoding features and speed improvements are made to codecs like x264 and xvid every other week. Politely i ask why is it that MS are so lazy in updating and improving their own codec ? Its bad enough the awful tools available to end users (note not multi billion dollar companies).

[vsv]

how 'bout to change the restrictions
1. use the same avs source
2. max bitrate 700 (what!!!)
3. allow all optimal maximum setting of your codec have
4. no external filtering

hmm, yaps it is...

max bitrate 700 for [HD-DVD Challenge] ? :)

[MarcioAB]

As for the container question, best we submit elementary streams using the 59.94 flagging.

Just to double check my understanding: Encode 24p source material in a 24p elementary stream and store it into an EVO container with a flag that will inform to old devices (NTSC and PAL) to playback this stream at 60i and modern devices to playback at 24p ?
Is that the correct understanding ?

Thank you

Is there still too many people out there with NTSC and PAL devices ( players and crt-TVs ) ?

[Sagittaire]

In order to stop us arguing about spec issues, does anyone have acccess to the Sonic HD DVD muxer? If so, we can agree on peak and average data rate, and just make the contest about who can make the best looking compliant stream that'll mux.


Yes, good idea. I can make the mux. Be carefull: you must use the direct avs source without pre-process (dithering or denoising for example). You can use all the advanced encoding way like segment encoding, adaptative quantisation, HVS inter/intra optimisation.


Our encoder doesn't use .avs directly, but we can use GraphEdit to dump a raw .yuv from that, so we'd be getting the same pixels.

Interessing. I can make that with all the other encoder?

[benwaggoner]

Encoding features and speed improvements are made to codecs like x264 and xvid every other week. Politely i ask why is it that MS are so lazy in updating and improving their own codec ? Its bad enough the awful tools available to end users (note not multi billion dollar companies).
We've got full-time teams working on both quality and performance optimization. But since there are so many decoders out there that we need to maintain backwards compatibility with, we do a long test cycle for each release. This is also helpful, since we can engineer big new features that touch lots of the codec pipeline, and won't produce good results in intermediate forms.

We did our most recent public codec release last fall, and we're working with a number of software vendors on integrating our new VC-1 SDK.

And of course we've done many PEP releases to the studios in that time frame. But again, those were tuned to HD optical disc needs, and we didn't test those iterations against traditional WMV Main Proifle targets.

As for awful tools, what do you mean? There are many dozens of products that incorporate .WMV encoding - there's got to be at least one that works for you.

[benwaggoner]

Just to double check my understanding: Encode 24p source material in a 24p elementary stream and store it into an EVO container with a flag that will inform to old devices (NTSC and PAL) to playback this stream at 60i and modern devices to playback at 24p ?
Is that the correct understanding ?

Actually, the 60i flagging is in the VC-1 bitstream.

Basically, we encode the 24 unique frames per second as normal, but add "judder" to the timing of the frames so that there go along a 60 Hz clock. Which is then ignored by progressive players :).

[benwaggoner]

Yes, good idea. I can make the mux. Be carefull: you must use the direct avs source without pre-process (dithering or denoising for example). You can use all the advanced encoding way like segment encoding, adaptative quantisation, HVS inter/intra optimisation.
I don't know how that can be enforced - what if the encoder has an integrated debanding/denoising filter?

FWIW, I should be getting a drive with the original high bit rate source for Elephant's Dream. Maybe I could put a .yuv.zip of it up via a .torrent

Interessing. I can make that with all the other encoder?
I think that all professional encoders in this market can read a .yuv source file. Anyone doing a test with a tool that can't?

It's also easy to pipe a .yuv into an IYUV .avi file via GraphEdit.

[MarcioAB]

I don't know how that can be enforced

What if the avs script used by each encode be jointly published with the results as a minimun ? Still dependent of trust, but ...

IMO, for the encode inside features as well as usage knowledge skills (person/team/corporation level), it should be used at it's limit - no restriction at all, unless the ones to comply with HD-DVD playback on standard stand alone players (blu-ray or hd-dvd optical media).

[Golgot13]

Hi all,

a little post since a long time:

Now I can speak about VC1 (from PEP) and H264 (from x264 or others) because the MS's NDA finished.

- First MS don't develop anymore VC1 professional encoder (PEP is remplaced by Sonic PSE or VC1 encoder from Corel, ?) .

- Second, H264 is better than VC1. H264 with CABAC option at same bitrate is better up to 35% than VC1.

At NAB, lot of people saw H264 encoder like Harmonic encoder for DTV (1920x1080 at 6-8Mbps!!!).
I hope to see soon Ambarella code integrate on H264 software or hardware encoder .
All TV broadcaster use and will use it (Canal+ HD, Sky HD, NTV HD,...), the Olympic Game 2008 in Beijing will shown it.


- Last, I don't understand HD DVD format: it don't support 25fps ( 50Hz: 50i and 25p ). It's a format for USA and Japan ???
Today lot of Live, TV show, ... are in HD 50Hz (for european TV Broadcast) and it can put only on BD but not on HD DVD.
Some video editors and studios wait the 50Hz support. HD DVD don't like european ???




You will see when the challenge will release than H264 is the best codec at low bitrate: possible to make BD or HD DVD on DVD disc
(in Japan there is some HD DVD in H264 and HD DVD on DVD disc).





Regards,


Golgot13

[drmpeg]

@Golgot13

A couple of notes.

1) The Harmonic Electra 7000 is based on the Ambarella single chip encoder. In fact, all the big hardware encoder companies are using Ambarella including Tandberg and Modulus (now Motorola).

2) 25 fps is allowed in the HD-DVD specification. There's just no players that support 25 fps.

Ron

[Sagittaire]

@Golgot13

25 fps is allowed in the HD-DVD specification. There's just no players that support 25 fps.

Ron

HDDVD PAL doesn't work on XboX 360 + addon ... ?

[benwaggoner]

Hi all,

a little post since a long time:

Now I can speak about VC1 (from PEP) and H264 (from x264 or others) because the MS's NDA finished.

- First MS don't develop anymore VC1 professional encoder (PEP is remplaced by Sonic PSE or VC1 encoder from Corel, ?).
Actually, Sonic's CineVision PSE is a rebranded and enhanced version of PEP we're doing in collaboration with Sonic. We're still doing all the codec development for it.

- Second, H264 is better than VC1. H264 with CABAC option at same bitrate is better up to 35% than VC1.
Them's fighting words, buddy! Let's agree on some source and a scenario, and let's see you match my VC-1 quality at 35% lower bitrate :).

[benwaggoner]

What if the avs script used by each encode be jointly published with the results as a minimun ? Still dependent of trust, but ...

IMO, for the encode inside features as well as usage knowledge skills (person/team/corporation level), it should be used at it's limit - no restriction at all, unless the ones to comply with HD-DVD playback on standard stand alone players (blu-ray or hd-dvd optical media).
Maybe we should just call it a "best looking video that muxes, wins" and allow whatever preprocessing people want to apply, since we all have access to the source anyway for comparison so it's not like someone can get away with using a low-pass filter. And understanding in the end it's going to be a subjective judgement, with people arguing endlessly about which tradeoffs are better.

We should define an appropriate ABR and PBR for the scenario, of course. 10 ABR, 25 PBR?

[Golgot13]

@Golgot13

A couple of notes.

1) The Harmonic Electra 7000 is based on the Ambarella single chip encoder. In fact, all the big hardware encoder companies are using Ambarella including Tandberg and Modulus (now Motorola).


Yes, I know now but Harmonic use the Ambarella since the beginning....


2) 25 fps is allowed in the HD-DVD specification. There's just no players that support 25 fps.



Yes, but after more than one year, the 25fps is not support by hardware HD DVD player (there is only Toshiba,
LG bistandard player is not HDDVD...). After 3 meeting of DVD Forum, the 25fps is not approuved !!!!!
(because they are not agree with HD DVD 25fps test disc....).
And the HD DVD format put on european market HD DVD player which don't support HD in 25fps !!!!!

To my mind today, HD DVD is not a european standard and it is not for european market
(we can not have HD DVD from HD european program like documentary or live shoot in 25fps).



About quality, we will see when this thread will release the test (why this thread si not finish, MS don't want to give tool for test ??? !!!).
And I don't see a test of VC1 codec on MSU annual test !!!!

For Sagitaire, yes X360 support 25fps like all software player.

For MS, lot of companies (like the company where I work) use VC1 because the studio think it's the best codec.
(it's like than Dolby Digital audio codec on DVD, MPEG2 Multichannel is better...).
I hope the european union investigation will show some lobby and bad thing on some format (25fps in HD DVD,...).




Golgot13

[Golgot13]

Them's fighting words, buddy!

But this thread is for a fighting challenge between the two last best codec (H264, first, and VC1).


Let's agree on some source and a scenario, and let's see you match my VC-1 quality at 35% lower bitrate :).

Today with all H264 professional encoder, encoded file in H264 is better than the same video encoded in VC1.
If Microsoft can give a source file and the VC1 encoded file of this source, we will make a little challenge between only H264 and VC1.
We will start bitrate at 6Mbps (VC1 will sleep up to 12Mbps...).

I listen there is a CinemaCraft encoder in H264 for HDDVD and BD, CC-HDe, which can make more than 2 pass....
I think it is the VC1 killer software.



Golgot13

[MarcioAB]

... in the end it's going to be a subjective judgement ...Yes. What about the use of PSNR as "the judge", like it was in the past here. Mux + PSNR

[MarcioAB]

... the 25fps is not support by hardware HD DVD player ...
What happen when you insert a 25 fps in one of those players ?
Thank you.

[Golgot13]

What happen when you insert a 25 fps in one of those players ?
Thank you.

HD DVD is ejected and we have a message that "disc don't supported".
The chipset (Broadcom, imposed after by MS) inside can support 25fps.

Last, all HD DVD hardware player must have Windows CE inside to support well iHD or HDi
(LG bi-format don't have WinCE....), it is nice for the compatibility but I'm not sure
that chinese company will make quickly cheap HD DVD player (nice the SDK and motherboard
with Broadcom chipset and WinCE).

Why the BD can support the 25fps video on all player and not the HD DVD.
The HD DVD was the first format on market, so why it was not the first format which
support 25 fps and all option of "HD DVD White Book".... :mad::mad::mad:

Today the european market is the first for new HDDVD titles release or announced,
but it will stop by the non support of 25fps framerate!!!!



Golgot13

[benwaggoner]

Yes. What about the use of PSNR as "the judge", like it was in the past here. Mux + PSNR
PSNR is certainly something well worth looking at in a test, but I'm not sold on PSNR as a definitive demonstration of video quality. I certainly would tune my VC-1 encodes differently depending on if I wanted a good PSNR or if I wanted it to perceptually look good.

[benwaggoner]

Last, all HD DVD hardware player must have Windows CE inside to support well iHD or HDi
(LG bi-format don't have WinCE....), it is nice for the compatibility but I'm not sure that chinese company will make quickly cheap HD DVD player (nice the SDK and motherboard with Broadcom chipset and WinCE).
The Toshiba A1 is Linux based and runs HDi just fine.

[benwaggoner]

But this thread is for a fighting challenge between the two last best codec (H264, first, and VC1).

[QUOTE]Today with all H264 professional encoder, encoded file in H264 is better than the same video encoded in VC1.
Which VC-1 implementation? Used how? Our current beta? We all know here that there are too many variables in compression to make such a blanket statement.

If Microsoft can give a source file and the VC1 encoded file of this source, we will make a little challenge between only H264 and VC1.
Well, how about the Elephant's Dream footage. I've been reluctant to provide content directly because if VC-1 wins people will just say we cherrypicked :).

We will start bitrate at 6Mbps (VC1 will sleep up to 12Mbps...).
I don't follow you on "sleeping." I've made 2 Mbps and 10 Mbps versions of Elephant's Dream already, and the 10 Mbps looks pretty spectacular in my opinon, and that's with our year-old codec.

I listen there is a CinemaCraft encoder in H264 for HDDVD and BD, CC-HDe, which can make more than 2 pass....
I think it is the VC1 killer software.
It isn't. VC-1 is also capable of multipass encoding with PEP.

[kolak]

Cinemacraft CC-HDe is a really powerful piece of 4.5MB (that is the size) software:)
It already (in beta version) offers comparable, if not the best PQ, from all AVC HD DVD/Blu-ray compatible encoders.
The speed is awesome in comparison to other h.264 encoders (PEP is ridiculously slow), has amazing filtering options and I can bet that in few months it will become main encoder for all big studios.
Cinemacraft is continuing to provide industry with state of the art encoders and will keep leader position also for AVC encoding (as long as other company won't make better encoder:)).

Ben- what about PEP speed?
Not many studios can afford for 16 Blade Servers to have still not real time encoding (or real time- I don't know that).
CC-DHe is 1.5 slower than realtime on one PC even with all filtering turned on:)

If you want make real comaprision you shouldn't be the person who does VC-1 encoding- it should be some compressionist, who uses PEP, but not you (you know to much):)
You don't want to do all VC-1 encoding in the World- do you?:)

ps. it does 99 passes (if it maters):)

[benwaggoner]

Ben- what about PEP speed?
Not many studios can afford for 16 Blade Servers to have still not real time encoding (or real time- I don't know that).
The blade systems are mainly there for super high quality encoding. A workstation can do HD in faster than realtime with a Tarari board and our latest optimizations.

If you want make real comaprision you shouldn't be the person who does VC-1 encoding- it should be some compressionist, who uses PEP, but not you (you know to much):)
You don't want to do all VC-1 encoding in the World- do you?:)
You have no idea how much I want to spend more time encoding :). Although I'm certainly not the best VC-1 operator here at Microsoft - there's at least 4-5 better than I am.

ps. it does 99 passes (if it maters):)
PEP doesn't have any explicit maximum number of passes either.

[kolak]

The blade systems are mainly there for super high quality encoding.

Other words- for all proper realeses, what means for all studios which don't want wait week for encoding:)


A workstation can do HD in faster than realtime with a Tarari board and our latest optimizations.

That is a different encoding and story.


At this moment good AVC implementation can at least match PEP quality, but AVC encoding takes (strangely) less time.
It's not only about how good quality is, but also about real usage of the encoder.

[benwaggoner]

Other words- for all proper realeses, what means for all studios which don't want wait week for encoding:)
VC-1 is used in the majority of HD optical discs! The studios are certainly getting something they want to use there. We've had feedback from many studios who've been given demos of the CinemaCraft encoder, and while they like many features of it, still feel they're able to get better titles done with the current version of PEP, and they're already previewing the next version...

At this moment good AVC implementation can at least match PEP quality, but AVC encoding takes (strangely) less time.
It's not only about how good quality is, but also about real usage of the encoder.
How much hands-on time with PEP have you had, and what version?

[kolak]

How much hands-on time with PEP have you had, and what version?

I know that most big studios still use PEP.

Not much at all and it was old version.
This what I judge are current releases with VC-1.
They look good, but in the same time my last tests showed that with a good master I can have the same visual quality with AVC. Latest grain optimisations in AVC solved problems with flatting the grain.
I would go for PEP, but the speed makes it unusable.
Some engineers from Japanese company (not Cinemacraft, but they work close with MS) said opposite: CC-HDe seams to be slightly better than PEP.
I'm waiting for updates for CC-HDe and I think at the end of the year CC-HDe will become the main encoder:)

I would be happy to check latest PEP version:)

[Sagittaire]

1) pep use certainely update stat like x264 for example and virtualy unlimited number of pass.

2) I think that good AVC implementation will make really better result than good VC1 implementation but only for high quantisation scenario ("low bitrate"). For low quantisation encoding like HDDVD30 scenario ("high bitrate"), it's really more complicated. Anyway HVS tuning for VC1 in "high bitrate" situation seem really advanced ...

3)I will remake this complete test soon

[skal]

If Microsoft can give a source file and the VC1 encoded file of this source, we will make a little challenge between only H264 and VC1.


Very good idea. Previous attempt got swamped miserably because of some nitpicking around obscure Top-Zeekret specs or something. So why not: MS releases a VC1 encode, point to some source, and someone does a h264 encode with same specs, whatever they are.

Skal
(and not Elephant Dream, please. Input is definitely too clean)

[zambelli]

About quality, we will see when this thread will release the test (why this thread si not finish, MS don't want to give tool for test ??? !!!).
I'm puzzled by this remark. Are you implying Microsoft somehow killed this thread's original challenge? :confused:
And I don't see a test of VC1 codec on MSU annual test !!!!

Are you referring to http://compression.ru/video/codec_comparison/call_for_codecs_07.html ? That's their decision. I've no idea why they didn't expand the codec comparison to MPEG-4 ASP, VP7 and VC-1 codecs at least, but they're the ones spending time and effort on doing the comparison - so it's entirely and rightfully their call to make.

[zambelli]

2) I think that good AVC implementation will make really better result than good VC1 implementation but only for high quantisation scenario ("low bitrate"). For low quantisation encoding like HDDVD30 scenario ("high bitrate"), it's really more complicated. Anyway HVS tuning for VC1 in "high bitrate" situation seem really advanced ...
This is something I've been saying about the codec shootouts for years: context matters and results from one scenario can't and shouldn't be extrapolated to represent results for all scenarios. In other words, it's a huge mistake to compare codecs for i.e. DVD backup, and then interpret those results as being the same for HD-DVD/BD encoding. They're vastly different scenarios with completely different goals - and thus often 2 codecs can prove to be equally valuable but in different scenarios.

Very good idea. Previous attempt got swamped miserably because of some nitpicking around obscure Top-Zeekret specs or something. So why not: MS releases a VC1 encode, point to some source, and someone does a h264 encode with same specs, whatever they are.
I see a huge potential there for Microsoft getting accused of skewing the source in favor of VC-1. As long as everyone agrees they're OK with Microsoft picking the content, I think we can start looking into the possibility of getting some content cleared for this sort of usage.

(and not Elephant Dream, please. Input is definitely too clean)
Agreed, though I've found that it can be made significantly more challenging by artificially adding grain (i.e. using AddGrain plugin for Avisynth). However, its biggest problem is not that it's clean, but that it only contains 2-3 scenes that are really challenging - the rest is piece of cake.

[MarcioAB]

... depending on if I wanted a good PSNR or if I wanted it to perceptually look good.Who will be the person to classify the "perceptually look" ?

Film is art. Codecs are just tools to make possible such art get us.
I guess the artist will consider the best codec as the one that will minimally distort his work. We are technicians. Who are we to say the result became "perceptually look good".

I guess PSNR could be used to measure how much the encoded became distant from the (art) source.

Not that I want to complicate, but a very clear criteria to compare is important ... before begin.

[Golgot13]

Are you referring to http://compression.ru/video/codec_comparison/call_for_codecs_07.html ? That's their decision. I've no idea why they didn't expand the codec comparison to MPEG-4 ASP, VP7 and VC-1 codecs at least, but they're the ones spending time and effort on doing the comparison - so it's entirely and rightfully their call to make.

Because some company don't want to lost on this comparaison (like some company with H264, first in 2005).
MSU (russian university) accept alll codec and project from all developper....

To benwaggoner, I understand that Mr Kolak have the CC-HDe turnkey, so we can do a little challenge
with a encoded file from you (choose what you want : 3min is enough) and a encoded file of same video from Kolak.
And you speak about PEP version, but I understand that lot of companies, which need your software, had not never received
(I saw some post of Kolak on MS thread, may be the same on this thread).
You (MS video staff) give lot of council at professional users but when the business start we never see you again
(if we don't have movie like "Miami Vice").
For first generation of Toshiba player with Linux inside (best player to my mind), it was not with WinCE/Broadcom SDK
because it is available since this year..... (first generation appear last year...)


And why Ben or Zambelli don't answer about 25fps (because you're in USA and you don't need it ???).
It's really a bad problem for HD DVD standard, I understand that some european companies change the framerate
of video to make HD DVD titles !!!!!!!
About other avantage of BD, the HDDVD support 23.976fps but BD support 23.976fps AND 24fps (shoot directly from movie !!!!).


Last to my mind, the best codec is H264, but VC1 is a good codec for video on old CPU:
H264 need lot of CPU resource (some video from Sagitaire need more than my little P4 3.2GHz) than VC1.
But all computer since this year (with or without last graphic card) are ready for H264.



Golgot13

[skal]

Who will be the person to classify the "perceptually look" ?

I guess PSNR could be used to measure how much the encoded became distant from the (art) source.

Not that I want to complicate, but a very clear criteria to compare is important ... before begin.

agreed, especially at high or ultra-high bitrate. It's not like comparing 56kbps pureed pixel soup, where PSNR is just telling how much post-processing you didn't use. At high bitrate, PSNR is at what you expect: fidelity. Otherwise, i'll put a Beyonce sliceshow in the middle of Elephant Dream, because you know, PSNR matters less than "perceptual look".and Beyonce has quite some of the latter.

[vsv]

Producer Richard J. Casey (www.rbfilms.com) interested in best codec and possible can provide source for test.
Ask him in this tread:
http://www.avsforum.com/avs-vb/showthread.php?t=868185

and read also another tread:
http://www.avsforum.com/avs-vb/showthread.php?p=10950912&&#post10950912

TOSHIBA and MS, STOP discrimination of EU!
Release firmware update for HDDVD players to support 25FPS!!!

[arfster]

Yes. What about the use of PSNR as "the judge", like it was in the past here. Mux + PSNR

SSIM any day, imo. MSU did a study a while back, showed it correlates best to visual quality.

[zambelli]

Because some company don't want to lost on this comparaison (like some company with H264, first in 2005).
MSU (russian university) accept alll codec and project from all developper....
All they have to do is ask. To the best of my knowledge, MSU never asked Microsoft codec team for VC-1 encoding tools or advice. How can we participate in something we are not invited to?
You (MS video staff) give lot of council at professional users but when the business start we never see you again
(if we don't have movie like "Miami Vice").
There's only 5 people on the VC-1 codec deployment team at Microsoft. Trust me when I say that our hands are full and we're doing our best to help out everybody who asks for help.
And why Ben or Zambelli don't answer about 25fps (because you're in USA and you don't need it ???).
Because Ben and I didn't write the HD-DVD spec and we don't manufacture the player units. We're here to discuss codecs. Your question is more suitable for AVS Forum's Industry Insiders (http://www.avsforum.com/avs-vb/showthread.php?t=851221) thread.
It's really a bad problem for HD DVD standard, I understand that some european companies change the framerate of video to make HD DVD titles !!!!!!!
That doesn't seem any worse than PAL DVDs speeding up 24fps film to 25 fps for PAL playback. This is the same principal in reverse. Not that I agree with it... Just saying it's nothing new.

[zambelli]

Producer Richard J. Casey (www.rbfilms.com) interested in best codec and possible can provide source for test.
Even though his company is producing the HDDVD/BD releases it doesn't mean he can freely share the sources.

If there's going to be a codec shootout using a "real" film source, that source will need to be either cleared for free distribution to everybody or the "contestents" will need to sign some sort of agreement. I can't see a middle option. Studios are highly protective of their content sources.

[kolak]

That doesn't seem any worse than PAL DVDs speeding up 24fps film to 25 fps for PAL playback. This is the same principal in reverse. Not that I agree with it... Just saying it's nothing new.

Really?
There are no good HD converters at the moment at all.
5 units in the world of new Alchemist Ph.C-HD, which is even not fully functional yet. Other solution do the job, but the quality is not really good.
Most of the masters in Europe are 50i and there is a big problem with good HD 50i to 60i conversion.

[Golgot13]

Hi Zambelli,

about help of MS, I know that you're a little team for VC1 support. But it is not true that you help everebody...
I can give the name of 5 authoring studio which ask me PEP VC1 encoder because you never answer
at email/fax/message to obtain it.
A example, Kolak ask me in February about it, the software was free but I was not able to give him.
And now Kolak and other companies prefer to make H264 HDDVD or BD...

About 25fps, HDDVD is not only for movie (24fps) in USA, there is some nice documentary, in 29.97fps,
and lot people bought and buy it. It is not posiible in europe (becuase we are in 25fps.....)!!!!!!
To Toshiba player, there is lot of firmware update to HD DVD player because you (MS) ask Toshiba to do it
for new interactivity (weblink,....). And MS can make modification in "HD DVD specification",
MS support HDDVD because HDDVD included "Advanced Content" (and VC1) on the specification
(AOD, old name of HDDVD supported in first only "Standard Content").
So you (MS) can ask Toshiba to support 25fps on their HD DVD player.
Last I don't ask you to change the HD DVD specification because 25fps is inside.....


Maybe I need to find contact with european union investigation about this, I think after you (MS and Toshiba)
will support it in one week..... :devil:


Regards,


Golgot13

[vsv]

Because Ben and I didn't write the HD-DVD spec and we don't manufacture the player units. We're here to discuss codecs. Your question is more suitable for AVS Forum's Industry Insiders (http://www.avsforum.com/avs-vb/showthread.php?t=851221) thread.

I've asked. ("http://www.avsforum.com/avs-vb/showthread.php?p=10972379&&#post10972379
)

Silence...

[vsv]

Hi Zambelli,

about help of MS, I know that you're a little team for VC1 support. But it is not true that you help everebody...
I can give the name of 5 authoring studio which ask me PEP VC1 encoder because you never answer
at email/fax/message to obtain it.
A example, Kolak ask me in February about it, the software was free but I was not able to give him.
And now Kolak and other companies prefer to make H264 HDDVD or BD...

About 25fps, HDDVD is not only for movie (24fps) in USA, there is some nice documentary, in 29.97fps,
and lot people bought and buy it. It is not posiible in europe (becuase we are in 25fps.....)!!!!!!
To Toshiba player, there is lot of firmware update to HD DVD player because you (MS) ask Toshiba to do it
for new interactivity (weblink,....). And MS can make modification in "HD DVD specification",
MS support HDDVD because HDDVD included "Advanced Content" (and VC1) on the specification
(AOD, old name of HDDVD supported in first only "Standard Content").
So you (MS) can ask Toshiba to support 25fps on their HD DVD player.
Last I don't ask you to change the HD DVD specification because 25fps is inside.....


Maybe I need to find contact with european union investigation about this, I think after you (MS and Toshiba)
will support it in one week..... :devil:


Regards,


Golgot13


GREAT POST!
Thank you, Golgot13!

[foxyshadis]

Does this thread need adult supervision? This isn't Slashdot, stop piling all the wrongs of the HD world on Microsoft's head. If you have a burning need to discuss lousy framerate conversion and support, Microsoft support, or conspiracy theories about backdoor deals at MSU, make a thread about it. (And try to get a statement from Dmitry first. I suspect they simply aren't interested in it.)

[Golgot13]

Does this thread need adult supervision?


Sorry, only answer at some bad informations.
I stop my anger about European problems.
Now, I offer my help about H264 encoding process.




Golgot13

[MarcioAB]

SSIM any day, imo. MSU did a study a while back, showed it correlates best to visual quality.

Correct. And should be the same for all: the avisynth SSIM 0.24 from Lefungus for example ?

[zambelli]

Regardless of which quality metric would be used, I think it'd be a good idea to show a graph representing the metric score per frame - and not just the overall score. Only a comparison of graphs can show how different codecs compared in particular scenes.

[MarcioAB]

Regardless of which quality metric would be used, I think it'd be a good idea to show a graph representing the metric score per frame - and not just the overall score. Only a comparison of graphs can show how different codecs compared in particular scenes.Good for a more detailed analise. The overall score should be accompanied with the diffusion of the data set. It's the average of the absolute deviations of data points from their mean.
This can be easily accomplished using, for example, the function AVEDEV() from OpenOffice.org Calc importing the csv output from ssim with all values per frame.

[Sagittaire]

Partial result:


|--------------|---------|---------|----------|---------|---------|
| Codec | PProc | Bitrate | Size | OPSNR | SSIM 2 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | PP0 | 5999 | 479233 | 43.08 | 82.55 |
| VC-1 | N/A | 5994 | 478824 | 43.75 | 86.41 |
| H264 | N/A | 6007 | 479766 | 46.35 | 89.54 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | PP0 | 12001 | 958666 | 46.38 | 91.27 |
| VC-1 | N/A | 11986 | 957521 | 46.71 | 92.44 |
| H264 | N/A | 12008 | 959329 | 49.11 | 94.18 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | PP0 | 17988 | 1434719 | 46.58 | 92.00 |
| VC-1 | N/A | 17930 | 1432338 | 48.28 | 94.60 |
| H264 | N/A | 18009 | 1438862 | 50.53 | 95.74 |
|--------------|---------|---------|----------|---------|---------|
SSIM 0: Lumimask Off
SSIM 1: Lumimask On (Original Lumimask)
SSIM 2: Lumimask On (One2Tech Patch)


1) I use Libavcodec for MPEG2: incredible result ... libavcodec outperform by far all the other mpeg2 codec.
2) "Anonymous" user make VC1 encoding with vc1_enc.exe from PEP. If I compare with Zambelli WMV9 AP encoding: little lower result for OPSNR but very better for SSIM. Anyway "Anonymous" stream are perfectly vbv compliant and perhaps not WMV9 AP stream from Zambelli and can explain the OPSNR result.
3) I use x264 for H264
4) All the stream are perfectly HDDVD compliant: scan vbv with streameyes and mux work for HDDVD. Scan vc1 stream with esa.exe from PEP by "Anonymous".
5) I can't make 18 Mbps encoding for MPEG2 with Libavcodec (quantizer saturation). I use HCEnc with best possible profil for 18 Mbps encoding.

[CruNcher]

How about Encoding Time, Decoding Complexity,Visual Compare of Key Sequences and the Settings used ?

[Sagittaire]

How about Encoding Time, Decoding Complexity,Visual Compare of Key Sequences and the Settings used ?

just partial result ... but interessing partial result.

1) Encoding Time is not a probleme here.
2) Decoding complexity is not a problem for HDDVD SAP and not really a problem with PC and low cost GPU hardware acceleration. My c2d at 2.66 Ghz is able to play all the stream without hardware acceleration.
3) Stream will be available for all the video codec
4) Setting for all the video codec too

[Golgot13]

[QUOTE=Sagittaire;1028887]Partial result:


|--------------|---------|---------|----------|---------|---------|
| Codec | PProc | Bitrate | Size | OPSNR | SSIM 2 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | PP0 | 5999 | 479233 | 43.08 | 82.55 |
| VC-1 | N/A | 5994 | 478824 | 43.75 | 86.41 |
| H264 | N/A | 6007 | 479766 | 46.35 | 89.54 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | PP0 | 12001 | 958666 | 46.38 | 91.27 |
| VC-1 | N/A | 11986 | 957521 | 46.71 | 92.44 |
| H264 | N/A | 12008 | 959329 | 49.11 | 94.18 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | PP0 | 17988 | 1434719 | 46.58 | 92.00 |
| VC-1 | N/A | 17930 | 1432338 | 48.28 | 94.60 |
| H264 | N/A | 18009 | 1438862 | 50.53 | 95.74 |
|--------------|---------|---------|----------|---------|---------|
SSIM 0: Lumimask Off
SSIM 1: Lumimask On (Original Lumimask)
SSIM 2: Lumimask On (One2Tech Patch)



Hi all,

no answer from MS team (Ben or Zambelli) ???
So with this result ( and all next test sure ), H264 can do the same quality
than VC1 but with low bitrate (up to 40% less).

I think VC1 is a codec for transition between old CPU and new CPU.
But all PC ( 80%) of this year (2007) is ready to ready H264 video
(only need a graphic card and monitor ready for HD).
And with the new graphic card (UVD or Pure HD), there will be no problem with H264.
All people will use H264 because the tool and CPU are ready.

Next year, VC1 will be dead (no people use WMV, they prefer Divx at WMV),
people will prefer H264 at VC1/WMV for HD use (and it is hard to put VC1 on TS stream,
no public muxer for VC1 on WMV).



Regards,



Golgot13

[honai]

Next year, VC1 will be dead

Perhaps you should tell that to the studios and mastering facilities that are investing millions and millions in VC-1 workflows ...

people will prefer H264 at VC1/WMV for HD use

Define "people".

Reality is that so far no company is offering professional x264 solutions, and certainly no 4:4:4 pre-mastering workflow solution that utilizes x264 anywhere in the chain. Professional h.264/AVC solutions (note that I'm talking AVC from Toshiba/Panasonic here, not x264) still perform much worse than x264.

More to the point: The actual "people" who're producing HD content now and in 2008 couldn't care less what some random guy at Doom9 opines. ;)

[Sagittaire]

Reality is that so far no company is offering professional x264 solutions, and certainly no 4:4:4 pre-mastering workflow solution that utilizes x264 anywhere in the chain. Professional h.264/AVC solutions (note that I'm talking AVC from Toshiba/Panasonic here, not x264) still perform much worse than x264.

x264 is simply H264 implementation. Ateme AVC or Mainconcept AVC for example can produce similar result. Mainconcept for example produce lower PSNR but better SSIM in this test. I don't use Mainconcept implementation in this test because I can't produce 18 Mbps encoding with this source (min quantizer limitation for my demo build I think). Sonic Cinevision encoder (really professional product I think) use for example Mainconcept SDK AVC implementation.

[honai]

Neither Ateme nor Mainconcept are being used at the major facilities.

[Golgot13]

Perhaps you should tell that to the studios and mastering facilities that are investing millions and millions in VC-1 workflows ...

I don't see any TV channel or TV broadcast company which use or will use VC1.

I 'm not sure that htere is lot of studios which are investing millions in VC1 software (because it, PEP, was free at start
and now it cost 50k$). The studio are investing in hardware encoding process (computer for network encoding).
But it is easy to use this investment to encode in H264 or others.




Define "people".

You, me, studio companies (video or authoring studio): why=
Because H264 can make a better quality at same bitrate or make the same quality with a low bitrate (to put more HD video movie or bonus).

Today, I can buy a Tvix M4100 or M5100 (or other device like AminoNET 130, NetBox 7600, PS3,..) which can play H264 HD video
from a NAS system (like linksys NSLU2 at 60$) to my HD TV set. I use H264 because I can put lot of video on my HDD and because
there is some limitation in my home bandwith (NFS better than Samba) material (my switch or router) or software (inside of HD player with network mode)



Reality is that so far no company is offering professional x264 solutions, and certainly no 4:4:4 pre-mastering workflow solution that utilizes x264 anywhere in the chain.

First VC1 don't support 4:4:4.... (no more than 4:2:0)
And it is not true for H264, there is some solution in 4:4:4 (go to NAB or IBC to see it).
HDCAM SR is a MPEG4 Part 2 Studio Profil :D (and not a wmv...) with 4:4:4 support


Professional h.264/AVC solutions (note that I'm talking AVC from Toshiba/Panasonic here, not x264) still perform much worse than x264.

Yes, but all change quickly with H264 development (see CineVision do nice H264 now not like one year before; or H264 encoder
for TV broadcasting work well now, Ambarella is a good example).
If you are 80.000$ you can buy the nice PC turnkey solution with CC-HDe (CinemaCraft HD encoder) use by Disney for BD tilte.



More to the point: The actual "people" who're producing HD content now and in 2008 couldn't care less what some random guy at Doom9 opines. ;)

You are right but I think you don't go at some professional show and you don't work on on video studio
(in europe there is lot of HD VoD encoded in H264 for IPTV broadcast, all in France except Club Internet).
I hope you will change your glace at next IBC (if you live in Europe) or NAB).


And there is lot of guy but not only in Doom9 forum who had the same opine. I hope this challenge will open
the eyes at some people and professionnal ( I listen that some authoring studio which use VC1 exclusively and
made all first HD DVD in France was interested by CC-HDe ).





Golgot13

[Golgot13]

Neither Ateme nor Mainconcept are being used at the major facilities.

All VoD HD in France ( 90% = N9uf Telecom, Wanadoo, Free and may be Alice ) use H264 software encoder from Ateme.

I don't think you live on country where there is some alternative solution than MS.
About some experience of MS I can give you a nice example of mistake from this company: WMVHD




Golgot13

[honai]

This thread is about HD-DVD, right?

Please name one (1) HD-DVD disc production facility that uses x264 or Ateme/Mainconcept for A-list titles.

(Fact is that there is not a single one.)

I hope this challenge will open
the eyes at some people and professionnal

No, it won't.

First VC1 don't support 4:4:4.... (no more than 4:2:0)
And it is not true for H264, there is some solution in 4:4:4 (go to NAB or IBC to see it).

We're talking about the pre-stage here, hence 4:4:4. The VC-1 workflow with PEP and its successor fully supports it. For x264 there is no professional 4:4:4 support (keywords: blade, SAN/NAS), period.

[Sharktooth]

I cant understand what you dont understand...
h.264 is better by specifications than VC1. PERIOD.
So, with "equivalent implementations", h.264 will be always better than VC1.

[Golgot13]

This thread is about HD-DVD, right?

Please name one (1) HD-DVD disc production facility that uses x264 or Ateme/Mainconcept for A-list titles.

x264 is a implementation of H264 (to my mind better than H264 of CineVision ).
Today professionnal companies (like your and the company where I work) are affraid by "problems" of compatibilty.
So they use commercial software (some with lot of bug, Pianiste HD DVD was made with PEP and needed a firmware update player...)
to be sure there is not any problems.

About HD DVD with H264 codec see japanese market....
There is HD DVD with H264 codec, HD DVD on DVD (3x DVD) and TwinDisc (HD DVD layer and DVD layer on same side)
and since last year (summer 2006).

You can go at Ceatec (Beginning of October) to see HD DVD with H264, all other H264 hardware (camcorder, TV,...) and more...



Today, I'm afraid by some companies partner of HD DVD format (MS with VC1 and Toshiba without support of 25fps)
and some guy (like you, see the first result of challenge).
So I think HD DVD will lost (I hope not but it take the way for).




Golgot13

[benwaggoner]

[QUOTE=Sagittaire;1028887]Partial result:


|--------------|---------|---------|----------|---------|---------|
| Codec | PProc | Bitrate | Size | OPSNR | SSIM 2 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | PP0 | 5999 | 479233 | 43.08 | 82.55 |
| VC-1 | N/A | 5994 | 478824 | 43.75 | 86.41 |
| H264 | N/A | 6007 | 479766 | 46.35 | 89.54 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | PP0 | 12001 | 958666 | 46.38 | 91.27 |
| VC-1 | N/A | 11986 | 957521 | 46.71 | 92.44 |
| H264 | N/A | 12008 | 959329 | 49.11 | 94.18 |
|--------------|---------|---------|----------|---------|---------|
| MPEG2 | PP0 | 17988 | 1434719 | 46.58 | 92.00 |
| VC-1 | N/A | 17930 | 1432338 | 48.28 | 94.60 |
| H264 | N/A | 18009 | 1438862 | 50.53 | 95.74 |
|--------------|---------|---------|----------|---------|---------|
SSIM 0: Lumimask Off
SSIM 1: Lumimask On (Original Lumimask)
SSIM 2: Lumimask On (One2Tech Patch)



Hi all,

no answer from MS team (Ben or Zambelli) ???
Just saw this now.

Interesting results, but since we don't know where the .vc1 file came from, we can't say how well done it was. This might be a good excuse for us to get around to doing our own encode with what we've got for the next version of PEP/CineVision PSE.

Also, shouldn't we really be looking at the streams? For VBR content, PSNR/SSIM isn't going to tell the whole story.

So with this result ( and all next test sure ), H264 can do the same quality than VC1 but with low bitrate (up to 40% less).
No, you've compared one metric on one source given an encode of unknown origin and optimization. And with a source without film grain, where VC-1 has the biggest advantage over H.264. It's an interesting data point, but nothing that can be generalized from!

Next year, VC1 will be dead (no people use WMV, they prefer Divx at WMV), people will prefer H264 at VC1/WMV for HD use (and it is hard to put VC1 on TS stream, no public muxer for VC1 on WMV).
People prefer Divx? Perhaps in "the scene", but any measurement of actual public streams/files out there provided commercially is going to show orders of magnitude more WMV.

[benwaggoner]

I don't see any TV channel or TV broadcast company which use or will use VC1.
Swisscom is using VC-1 for live broadcasting right now.

Lots of the MediaRoom broadcasters are using VC-1 for on-demand as well, even if they're using H.264 for live broadcasting. Now that Inlet Spinnaker is out, I'm expecting you'll here some announcements about additional broadcasters adopting VC-1.

[benwaggoner]

I cant understand what you dont understand...
h.264 is better by specifications than VC1. PERIOD. So, with "equivalent implementations", h.264 will be always better than VC1.
Untrue. VC-1 has differential quantization, non-square block sizes, and a loop filter that's better for film grain. H.264 is hardly a superset of VC-1.

[Sharktooth]

ROTFLMAO... wasnt VC-1 a superset of MPEG-4 ASP? :p
Come on, results are quite clear, VC-1 looses (by far) against h.264 using low and high bitrates, in both HD & SD, with and without stream restrictions...
Im still asking myself why VC-1 was developed when there was already MPEG-4 ASP (very popular and widely supported by hardware players...)

EDIT: I would like to see a DivX vs VC-1 comparison using the same restrictions... im sure the results would be "interesting"...

[CruNcher]

@benwaggoner
You are the one that has good connections to the R&D of Film Studios so couldn't you get the Source that was used by Universal Studios (under a Scientific License ofcourse but based on trust rather on signing a paper lol) that played a major role in the decission that the 8x8 transform (FreXt High Profile) was needed for AVC @ that time ?

Encoding that thing with X264 and compareing those results against VC-1 would be quiet interesting (but maybe some are fearing those results then ;) ), not that i say Elephants Dream is not a nice Source (Animation) but it wasn't a Source that played a role in the Development process (and decission process of Hollywood Studios) so rather useless to compare with that.

[diogen]

...Next year, VC1 will be dead
...h.264 is better by specifications than VC1.
...h.264 will be always better than VC1.
So, I guess the comparison is done...
It didn't take long this time... :)

What happened to the "quantitative nature" of doom9 roots?

Diogen.

[Sagittaire]

EDIT: I would like to see a DivX vs VC-1 comparison using the same restrictions... im sure the results would be "interesting"...

Difficult to make that because I can't scan the vbv compliancy for MPEG4 ASP and it's really important particulary for this source.

[Sagittaire]

No, you've compared one metric on one source given an encode of unknown origin and optimization. And with a source without film grain, where VC-1 has the biggest advantage over H.264. It's an interesting data point, but nothing that can be generalized from!

VC-1 Sequential Encoder


@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> HDDVD - 1080p - 29.97 fps - pulldown 3:2i - SSIM optimisation
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

@REM 6 Mbps - 3 pass - insame profil

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_1.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 6000 -maxrate 20000 -buffer 1843200 -gopperiod 14 -mvrange 1 -bframes 2 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -deblocking 1 -complexity 0 -chromasearch 4 -motionmatch 2 -perceptual 2 -dquantstrength 0 -adaptivedeadzone 1 -favorinterlevel 3 -log Temp\stat_1.txt

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_2.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 6000 -maxrate 20000 -buffer 1843200 -gopperiod 14 -mvrange 1 -bframes 2 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -deblocking 1 -complexity 4 -chromasearch 4 -motionmatch 2 -perceptual 2 -dquantstrength 0 -adaptivedeadzone 1 -favorinterlevel 3 -2pass Temp\stat_1.txt -log Temp\stat_2.txt

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_3.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 6000 -maxrate 20000 -buffer 1843200 -gopperiod 14 -mvrange 1 -bframes 2 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -deblocking 1 -complexity 4 -chromasearch 2 -motionmatch 1 -perceptual 2 -dquantstrength 0 -adaptivedeadzone 1 -favorinterlevel 3 -2pass Temp\stat_2.txt



@REM 12 Mbps - 3 pass - insame profil

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_4.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 12000 -maxrate 24000 -buffer 1843200 -gopperiod 14 -mvrange 0 -bframes 2 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -deblocking 1 -complexity 0 -chromasearch 4 -motionmatch 2 -perceptual 2 -dquantstrength 0 -adaptivedeadzone 1 -favorinterlevel 3 -log Temp\stat_3.txt

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_5.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 12000 -maxrate 24000 -buffer 1843200 -gopperiod 14 -mvrange 1 -bframes 2 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -deblocking 1 -complexity 4 -chromasearch 4 -motionmatch 2 -perceptual 2 -dquantstrength 0 -adaptivedeadzone 1 -favorinterlevel 3 -2pass Temp\stat_3.txt -log Temp\stat_4.txt

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_6.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 12000 -maxrate 24000 -buffer 1843200 -gopperiod 14 -mvrange 1 -bframes 2 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -deblocking 1 -complexity 4 -chromasearch 2 -motionmatch 1 -perceptual 2 -dquantstrength 0 -adaptivedeadzone 1 -favorinterlevel 3 -2pass Temp\stat_4.txt



@REM 18 Mbps - 3 pass - insame profil

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_7.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 18250 -maxrate 28000 -buffer 1843200 -gopperiod 14 -mvrange 0 -bframes 2 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -deblocking 1 -complexity 0 -chromasearch 4 -motionmatch 2 -perceptual 2 -dquantstrength 0 -adaptivedeadzone 1 -favorinterlevel 3 -log Temp\stat_5.txt

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_8.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 18250 -maxrate 28000 -buffer 1843200 -gopperiod 14 -mvrange 1 -bframes 2 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -deblocking 1 -complexity 4 -chromasearch 4 -motionmatch 2 -perceptual 2 -dquantstrength 0 -adaptivedeadzone 1 -favorinterlevel 3 -2pass Temp\stat_5.txt -log Temp\stat_6.txt

vc1_enc.exe -i C:\Master\1920x1080.yuv -o Temp\1080p_9.vc1 -w 1920 -h 1080 -framerate 29.97 -frametype progressive -telecine 1 -addeos -rate 18250 -maxrate 28000 -buffer 1843200 -gopperiod 14 -mvrange 1 -bframes 2 -bframeposopt 1 -bdeltaqp AdaptiveWeak -loopfilter 1 -deblocking 1 -complexity 4 -chromasearch 2 -motionmatch 1 -perceptual 2 -dquantstrength 0 -adaptivedeadzone 1 -favorinterlevel 3 -2pass Temp\stat_6.txt

[vsv]

Just speculation...
VC-1 not optimised for encoding 25fps (50Hz) content.
In this case all models of Toshiba hddvd players dont support 25fps content.
Implementation VC-1 in CineVision not good if compare to h264 in same CV.
For real test possible use source from Canon HV20 camcorder 1920x1080p24(and 25p too!) 4:2:2 10 bit Cineform stream captured from HDMI via Black Magic Intensity card.

[Sagittaire]

VC-1 not optimised for encoding 25fps (50Hz) content.

It's really not a problem for VC1. 1080p24 or 1080p25 in practice don't change anything (just GOP change and no pulldown 3:2i flags). And no judder at playback for 1080p25 stream ...


In this case all models of Toshiba hddvd players dont support 25fps content.

No it's simply that toshiba don't support HDDVD PAL. Here it's simply a firmware problem ...

[Golgot13]

@ Sagittaire

No it's simply that toshiba don't support HDDVD PAL. Here it's simply a firmware problem ...

Yes, we wait (since near of one year) the firmware update.

@Ben

People prefer Divx? Perhaps in "the scene", but any measurement of actual public streams/files out there provided commercially is going to show orders of magnitude more WMV.

There is more Divx video on the web (P2P,...) than any other format. And all (most) DVD player support Divx.

@Ben

Swisscom is using VC-1 for live broadcasting right now

Nice, but it is only one company (?). there is no US company, very strange...
H264 is used in lot of broadcast system and application (TV, IPTV, mobile broadcast, AVCHD Camcorder, LocationFree,...)

@Ben
Now that Inlet Spinnaker is out, I'm expecting you'll here some announcements about additional broadcasters adopting VC-1.

I know (from MS) that Inlet is not a good encoder solution. Fathom card can not make HD stream compliant with HD DVD
(there is no support from MS team ??). I wait a new software version with this option, VC1 compliant with HD DVD, since April 2006... :devil:

I see a demo of Inlet Spinnaker (first in NAB2006, second in NAB2007 on MS stand). I asked to see a video at 6Mbps
and it was horrible at 960x1080 (and 100meter at next stand, GrassValley, I could see a nice video at 6Mbps...).



Golgot13

[benwaggoner]

P2P (or more accurately, pirated), perhaps. But the problem with that class of P2P is that there's no money in it :).

[QUOTE]Nice, but it is only one company (?). there is no US company, very strange...
Lots of US companies are doing VC-1 for IPTV VOD, already. That should be a good indication of companies that would be interested in using VC-1 for live as well.

I know (from MS) that Inlet is not a good encoder solution. Fathom card can not make HD stream compliant with HD DVD (there is no support from MS team ??). I wait a new software version with this option, VC1 compliant with HD DVD, since April 2006...
Fathom was originally a WMVHD encoding tool - it predates the final HD DVD spec. Spinnaker is a wholly different product for live encoding, and it's excellent. And Fathom itself has had some great updates, including a software-only version. You should revisit it.

I see a demo of Inlet Spinnaker (first in NAB2006, second in NAB2007 on MS stand). I asked to see a video at 6Mbps
and it was horrible at 960x1080 (and 100meter at next stand, GrassValley, I could see a nice video at 6Mbps...).

I'm not sure what you saw, but there was no Spinnaker demo in HD at our NAB booth in 2006 or 2007.

[benwaggoner]

@benwaggoner
You are the one that has good connections to the R&D of Film Studios so couldn't you get the Source that was used by Universal Studios (under a Scientific License ofcourse but based on trust rather on signing a paper lol) that played a major role in the decission that the 8x8 transform (FreXt High Profile) was needed for AVC @ that time ?
Are you asking to see a sample of VC-1 encoded to HD DVD limits with the StEM video? That's probably something we could tackle.

Encoding that thing with X264 and compareing those results against VC-1 would be quiet interesting (but maybe some are fearing those results then ;) ), not that i say Elephants Dream is not a nice Source (Animation) but it wasn't a Source that played a role in the Development process (and decission process of Hollywood Studios) so rather useless to compare with that.
Do other folks here have access to that source who would be willing to encode the x264 version?

[Golgot13]

I'm not sure what you saw, but there was no Spinnaker demo in HD at our NAB booth in 2006 or 2007.

May be it was not "Spinnaker" but it is a VC1 streamer from Inlet (in 2006 and 2007).



Golgot13

[Golgot13]

And Fathom itself has had some great updates, including a software-only version. You should revisit it.


Fathom is a FPGA card, the software is "process code" to use this FPGA chipset.
Now it can encode in VC1, H264, MPEG2 ... now but no HD DVD or BD support.
After NAB2006 (and some info from MS and Inlet), Fathom was to receive
a update for HD DVD encoding (VC1 first and H264 with 3.0 version).
But I saw nothing at summer 2006.
At NAB2007, I saw only that it can encode in FLV and some MPEG4.

I don't understand MS politic: in 2005, MS and Inlet worked together
and Sonic sale the Fathom card with WMVHD solution.
But after 2005 nothing, Fathom support VC1 but not for HD DVD.
And no update, after lot of announce from Inlet for a release fully compliant HD DVD and BD....



Golgot13

[Sharktooth]

@diogen: http://forum.doom9.org/showthread.php?t=128498

[Sagittaire]

@diogen: http://forum.doom9.org/showthread.php?t=128498

yes it's a new thread because I use simply completely new "NTSC" setting for the challenge.

Mod can close this thread ... ?

[crypto]

I don't understand MS politic: in 2005, MS and Inlet worked together
and Sonic sale the Fathom card with WMVHD solution.
But after 2005 nothing, Fathom support VC1 but not for HD DVD.
And no update, after lot of announce from Inlet for a release fully compliant HD DVD and BD....
Golgot13

First I want to thank the participants of this challenge for the excellently documented results, which are giving a perfect insight of current encoding technology.

MS has concentrated sole on commercial HD-DVD products for the movie industry. Other ISVs and developers don't receive much support. The WM DMOs are years old and are not able to produce fully compliant streams. So no wonder Fathom cannot produce fully HD-DVD complaint output without own post processing.

There are absolutely no tools for encoding enthusiasts and hobbists like the ones here on D9. The Xbox has artificially restricted H.264 playback suport. The famous Encoder Studio Edition has been revoked, WME9 is years old, so no wonder MS is getting mostly unfriendly comments here.

H.264 is a whole different story. There are excellent free and open source tools, huge support from the community, widely playback support on consoles, streaming clients and so on. And this challenge proves superior quality for H.264. That's why people love and use it.

In Europe all HD channels are using H.264, many of them have just switched to 2nd generation encoders and are happy with the results. Three HD-DVD quality channels per transponder are absolutely doable.

[zambelli]

I must say, it's disappointing to see this thread degenerate into a VC-1 and MS bashing session. I haven't seen much discussion of Sagittaire's results - only a group of individuals immediately jumping onto the thread to declare a victory in a war that's mostly only going on in their heads. Come on. Let's be civil, have a normal discussion and focus on actual encoding results instead of drawing farfetched conclusions i.e. "VC-1 will be dead next year". The future of VC-1 and H.264 is not going to be decided by a thread on Doom9.
I don't understand MS politic: in 2005, MS and Inlet worked together
and Sonic sale the Fathom card with WMVHD solution.
But after 2005 nothing, Fathom support VC1 but not for HD DVD.
MS and Inlet are still working closely together. What products Inlet chooses to focus their product development efforts on is solely their decision. MS is only providing the encoding engine underneath. I'm not aware that Inlet ever had plans to build an HD-DVD encoding solution, though of course that's a question best answered by Inlet - I won't claim to be the best informed person on all VC-1 related products.

Golgot, on a more general but personal note... Your posts here have a history of hostile attitude, fingerpointing and speculating about MS and VC-1. You've mentioned on several occasions that you work for a professional video production company, yet I must tell you that your attitude is very far from professional. If anybody from Microsoft has ever treated you with disrespect or contempt when you sought out support from MS for your VC-1 encoding needs, please let me know, I would love to see what we can do to help or at least understand each other. If that's not the case, then I really fail to see a valid reason for your attitude other than you trying to get a cheap thrill out of publicly berating Microsoft and its employees. :confused:

[zambelli]

MS has concentrated sole on commercial HD-DVD products for the movie industry. Other ISVs and developers don't receive much support.
I don't think that's fair to say. Who are these ISVs and developers that aren't receiving supports from MS? What kind of support are they looking for?

The WM DMOs are years old and are not able to produce fully compliant streams. So no wonder Fathom cannot produce fully HD-DVD complaint output without own post processing.
A valid point and you know I won't disagree there. We are working on remedying that problem by producing a VC-1 Encoder SDK that ISVs will be able to use to build VC-1 encoding tools (HD-DVD compliant too) without dependencies on WMV encoder DMOs. As with everything, this takes time - but it's on its way.

There are absolutely no tools for encoding enthusiasts and hobbists like the ones here on D9. The Xbox has artificially restricted H.264 playback suport. The famous Encoder Studio Edition has been revoked, WME9 is years old, so no wonder MS is getting mostly unfriendly comments here.

H.264 is a whole different story. There are excellent free and open source tools, huge support from the community, widely playback support on consoles, streaming clients and so on. And this challenge proves superior quality for H.264. That's why people love and use it.
I've commented on this before. This is a bit of a "chicken or the egg" story. Nobody uses VC-1 because there aren't any tools. Nobody writes tools because nobody is using VC-1. And so it goes. I agree it's probably the latter that has to happen to facilitate the first, but at the end of the day... why does everyone keep looking at Microsoft to make this happen? Sony and Apple didn't write x264, Haali, MeGUI, and the plethora of other free H.264 tools that dominate this forum. So why does everyone keep expecting Microsoft to provide all VC-1 tools? Don't get me wrong - we'd *love* to provide Microsoft authored VC-1 tools for every nook and corner of the market, including the free stuff - but we simply don't have the resources to do so and we're doing the best we can with what we've got. The whole point of standardizing WMV9 into VC-1 was to try to get more people on board - and now that it's finally a standard (same licensing rules as with H.264), everyone is still waiting for MS to make it successful. It's like telling somebody to throw a party at their house and then not showing up because not enough "cool people" were invited.

[Beastie Boy]

Agreed with all of the above.

At least the new thread seems to have got off to a better start. Let's hope that one becomes what this one should have been.

Cheers, Beastie.

[Golgot13]

Golgot, on a more general but personal note... Your posts here have a history of hostile attitude, fingerpointing and speculating about MS and VC-1. You've mentioned on several occasions that you work for a professional video production company, yet I must tell you that your attitude is very far from professional.


It is same about MS in Europe for lot of professional studio.
MS Europe gave ( remember my private post to you of last year, in Summer)
only support at one or two authoring studio !!!!
MS Europe gave advance of 6 or 9 month at this studio and you gave for free the best VC1 encoder...
And when some other studios (the company where I work was not alone)
asked for only software (no support because it was impossible), we received some email
from you or Ben (thanks for answer) but nothing more (nothing from MS Europe)....
I can give more that 10 companies name from different european countries
(you know some one, they send you email)


If anybody from Microsoft has ever treated you with disrespect or contempt when you sought out support from MS for your VC-1 encoding needs, please let me know, I would love to see what we can do to help or at least understand each other.

But you know this names ( direspect, for me, is to wait 3 or 4 month with no answer
from MS Europe, after email, phone and fax).
Last year, you was not able to help us about this tool.
Today, it's easy because we can buy it at a extern MS company (Sonic with Cinevision PSE).


If that's not the case, then I really fail to see a valid reason for your attitude other than you trying to get a cheap thrill out of publicly berating Microsoft and its employees.


Today, I said the true (I think, but sure "my" true).
But there was lot of change at the end of 2006 from MS (Technical Training for HD DVD,
you gave the VC1 encoder,...).
I said, lot of time (see my old posts), that VC1 is a good codec transition because
it don't need a fast CPU. I was one of first supporter of HD DVD (see my old posts)
but with the politic of some companies (ex:Toshiba and 25Fps) I will, may be, change.

Sorry because I anger about some people in MS Europe (my company don't think same).
But after this post I will talk about only performance of H264 and some nice development of VC1
(but I don't think you can do more than nice PEP, except preprocessing).





Golgot13

[Golgot13]

I've commented on this before. This is a bit of a "chicken or the egg" story. Nobody uses VC-1 because there aren't any tools. Nobody writes tools because nobody is using VC-1.


You're right.


And so it goes. I agree it's probably the latter that has to happen to facilitate the first, but at the end of the day... why does everyone keep looking at Microsoft to make this happen?


You can give some nice tool or access at some VC1 tool development ( code ).
There is lot of HD player (Tvix M4100/5100, AmnoNET 130, Netbox 7600...) can read VC1
but only on WMV container. If you give this tool (like Inlet Muxer in command line).
Or you can give a demuxer to help some developper about muxing VC1 on TS stream
(Inlet have a similar software).
I think, after that, the egg (of "chicken or the egg") will be quickly a chicken and will do lot of egg.... :D




Golgot13

[skal]

everyone is still waiting for MS to make it successful. It's like telling somebody to throw a party at their house and then not showing up because not enough "cool people" were invited.
It seems to me the analogy is historically wrong. It's rather: nobody asked MS to throw a party while there was already one going on (where the chicks showed up).

[CruNcher]

It seems to me the analogy is historically wrong. It's rather: nobody asked MS to throw a party while there was already one going on (where the chicks showed up).

:goodpost: :D
and don't forget they where one of the hosts of the first party left and did a new one, and took all the things they learned from this party (and some stuff they keeped behind a curtain) to the new one (we can do a better one then the last alone with that what we've learned from the other hosts) ;)

[benwaggoner]

Fathom is a FPGA card, the software is "process code" to use this FPGA chipset.
The original version was FPGA based, but they now have a software only version. Also, there have been a lot of quality improvements.

http://forum.doom9.org/showthread.php?t=128498

They'll have HD DVD support eventually, I'm sure, but that'll be up to them to announce.

[crypto]

I don't think that's fair to say. Who are these ISVs and developers that aren't receiving supports from MS? What kind of support are they looking for?


OK, that didn't come as I ment it. I wasn't saying ISVs didn't get support. I wanted to point out the support bias towards big business. They got PEP, SDKs and ES specs for instance and all under NDA.


A valid point and you know I won't disagree there. We are working on remedying that problem by producing a VC-1 Encoder SDK that ISVs will be able to use to build VC-1 encoding tools (HD-DVD compliant too) without dependencies on WMV encoder DMOs. As with everything, this takes time - but it's on its way.


That's good to hear and exactly what is needed. Please keep us updated.


... why does everyone keep looking at Microsoft to make this happen? Sony and Apple didn't write x264, Haali, MeGUI, and the plethora of other free H.264 tools that dominate this forum. So why does everyone keep expecting Microsoft to provide all VC-1 tools? Don't get me wrong - we'd *love* to provide Microsoft authored VC-1 tools for every nook and corner of the market, including the free stuff - but we simply don't have the resources to do so and we're doing the best we can with what we've got. The whole point of standardizing WMV9 into VC-1 was to try to get more people on board - and now that it's finally a standard (same licensing rules as with H.264), everyone is still waiting for MS to make it successful. It's like telling somebody to throw a party at their house and then not showing up because not enough "cool people" were invited.

Nice one. The "party" analogy is cool and really describes it.

[Golgot13]

The original version was FPGA based, but they now have a software only version. Also, there have been a lot of quality improvements.

To my mind, FPGA card is the best solution because all process
(video preprocessing and encoding) are in real time !!!
And the Inlet tool is nice: muxer, demuxer, dump, flag remover,...
Inlet Semaphore is too a good software to analyze WMV or VC1 stream


They'll have HD DVD support eventually, I'm sure, but that'll be up to them to announce.

Not sure because they gave (last year) lot of announce about that
but now, this year at NAB2007, nothing ( ?? ).

It is really a good FPGA card (good Processor Unit power) which can now capture and
encode in VC1, H264, FLV, MPEG2 and MPEG4part2. May be with a little help of MS team
this product can be a HD DVD real time encoding solution (real time for one pass process).
And I think more companies will use VC1 codec for HD DVD,
if they have a hardware VC1 card (like Inlet Fathom).

[Golgot13]

That's good to hear and exactly what is needed. Please keep us updated.

Yes, but there are some counterparts (support or push only one format or codec)...

It is good but I am being wary about MS (sorry Ben and Zambelli).

[zambelli]

And when some other studios (the company where I work was not alone)
asked for only software (no support because it was impossible), we received some email
from you or Ben (thanks for answer) but nothing more (nothing from MS Europe)....
I'm sorry you didn't get a reply from MS Europe at the time. The European deployments of PEP were fairly limited, from what I recall. The goal was never to give out PEP for free to everybody but to focus on customers we could support, get direct feedback from and expect a solid VC-1 production volume from. I realize that might seem unfair to those who didn't get included, but for the design and improvement of PEP it was very important to be able to focus on only as many customers as we could handle at a time.

Today, it's easy because we can buy it at a extern MS company (Sonic with Cinevision PSE).
But there was lot of change at the end of 2006 from MS (Technical Training for HD DVD, you gave the VC1 encoder,...).
That's true, there were changes made. One of the reasons the deal with Sonic was made was exactly to get some help with the support and sales aspect of the product, allowing the MS codec team to focus more on product development. I realize it hasn't been an easy transition for a lot of studios that used to get PEP for free but it's a decision that was made to help expand the customer base of the product.

[zambelli]

OK, that didn't come as I ment it. I wasn't saying ISVs didn't get support. I wanted to point out the support bias towards big business. They got PEP, SDKs and ES specs for instance and all under NDA.
The expectation is that the end users will be served by the ISVs making products which will integrate our VC-1 SDK. Many companies in the codec business operate in this way (MainConcept comes to mind).

As for independent developers not getting support... Take the DMO codecs that shipped in WMP11 and Vista for example. They are fully documented on MSDN (http://msdn2.microsoft.com/en-us/library/bb288690.aspx). Those video and audio codecs can actually be used independent of ASF and WMF SDK. One could use the MSDN documentation to write an encoder app that produces VC-1 ES streams or muxes them into MPEG-TS, MP4, AVI, etc. The free stuff is certainly out there but it does indeed take work on both sides to create good tools and applications.

[Golgot13]

Hello all!

we can restart this thread. Ben will give (after 7month) the video.
We need to change the name (not HDDVD but BD today :( ).

About video restriction, I'm sure some people will give BD specification of all codec.

Sagitaire, do you have the last version of PeP core?



Regards,


Golgot13

[Sagittaire]

Hello all!

we can restart this thread. Ben will give (after 7month) the video.
We need to change the name (not HDDVD but BD today :( ).


I will change specification: BD9, BD25 and BD50 ...
Where is the source from ben ... ???


About video restriction, I'm sure some people will give BD specification of all codec.

I will change that too


Sagittaire, do you have the last version of PeP core?

Yes ... VC1 core from CinevisionPSE and VC1 core from SDK. VC1 core from CinevisionPSE is by far better at low bitrate than VC1 core from SDK. Anyway it's not the same price ... ;-)

[Inventive Software]

Um, Golgot? You seen this, right? http://forum.doom9.org/showthread.php?t=135938

You even posted in this thread! He has other deadlines, so give him a break! He doesn't get paid to provide us with source material. ;)

And Sagittaire: before you change this thread's original post, may I suggest you add BluRay to the bottom of it, still keeping the HD-DVD encoding specs please?

[Sharktooth]

since this thread is already 21 pages long i suggest to start a new one or ppl will get lost reading it...

[Sagittaire]

Well where is the 1080p source ... ???

[benwaggoner]

Well where is the 1080p source ... ???
I'll get back to it again after NAB, but I'm looking for feedback on the content I presented and suggestions on how it can be further tuned to be a useful test for this organization.

[Golgot13]

Hi Ben,

If you want to show at all studio that VC1 is good codec, you must to ask MS
to participate at "Annual MSU Codec Comparison". You can see at NAB one company,
Mainconcept, say they win the last codec comparison.

Ben, you can resume me what you will say at your DVDA presentation ?

I hope to be at this NAB, but my company must to finish some BD project
(in VC1 :(... from HDDVD product made by another company).


But I have some friends who will go.

[benwaggoner]

Hi Ben,

If you want to show at all studio that VC1 is good codec, you must to ask MS to participate at "Annual MSU Codec Comparison". You can see at NAB one company, Mainconcept, say they win the last codec comparison.
Is the MSU test that relevant? Last I looked at their methodology, it was on an older single-core P4 with some pretty tight encoding-time requirements. It seemed much more of a test of optimizing quality/encode time than visual quality in a more typical workflow. And by using such an old processor, they're missing the benefit of most recent performance optimization, like spatial multithreading and SSE3/4.

No argument that speed is one factor in comparing codec implementations, but it seems to me any speed test should at least run on typical compression workstations. I doubt anyone is using less than Core 2 Duo these days, and I don't think I've seen a new machine with less than four cores in the last couple of years. I've got 8-core on both by main encoding boxes.

Ben, you can resume me what you will say at your DVDA presentation ?
I'm not quite parsing your question here.

I hope to be at this NAB, but my company must to finish some BD project (in VC1 :(... from HDDVD product made by another company).

But I have some friends who will go.
Yeah? Here's my NAB schedule if anyone wants to attend one of my sessions or drop by the Microsoft booth when I'm there.

http://www.on10.net/blogs/benwagg/21804/

Anyone around on Tuesday night is welcome to come to the "Compressionist's Party" - just let me know you're coming so I can track snack requirements.

[Dark Shikari]

I listen many news from you at NAB from my contact...
You're a liar? :rolleyes:
VC1 give better quality than H264 at same bitrate (more detail) !!!!Its called marketing. Everyone wants to be able to claim they're the best, so they use contrived tests to prove their superiority. This is how VC-1 can claim to be "superior" to H.264 when it actually ends up being drastically worse in basically every situation. They probably compared against the JM, or compared against some of the terrible encoders available back in 2004 when they first marketed it as an H.264 competitor.

Other companies do the same; this isn't unique. Though unlike most others at least VC-1 has some advantage (faster playback).

Real claims their RV30/RV40, which are basically direct ripoffs of H.264 (x264 can be modified to output RV30), are superior to H.264. Of course, maybe they're superior to the JM, but I have never actually seen a test where they remotely came close to any competent encoder.

Same with On2, who make similar claims about VP7: its both faster and better quality than H.264. Of course, in reality, encoding is slow, playback is slower than ffh264, and quality is worse; but that doesn't stop marketing, does it? ;)

[benwaggoner]

I listen many news from you at NAB from my contact...
You're a liar? :rolleyes:
VC1 give better quality than H264 at same bitrate (more detail) !!!!
If I'm parsing you right, are you talking about the DVDA event on Saturday? What your contact may be thinking of is my discussion of PEP's VC-1 implementation as doing a better job of maintaining the texture of film grain compared to competing proudcts. For this, I'm quoting recent feedback from the compressionists at major studios who are evaluating the various professional encoder products.

Now that the format war is over, a number of BD-only studios are adopting VC-1. At this point there is only a single studio not actively working on VC-1 encoded Blu-ray titles.

I know you disagree with this, but the growing consensus among the Hollywood compressionists I get reports from is that PEP provides better overall quality and workfow at BD data rates than the H.264 encoders targeting the same market that they're evaluating.

And remember, this isn't a comparison of codec standards in this case, but implementations in particular products for particular workflows.

[benwaggoner]

Its called marketing. Everyone wants to be able to claim they're the best, so they use contrived tests to prove their superiority. This is how VC-1 can claim to be "superior" to H.264 when it actually ends up being drastically worse in basically every situation. They probably compared against the JM, or compared against some of the terrible encoders available back in 2004 when they first marketed it as an H.264 competitor.
Well, I don't know that we're doing any VC-1 marketing right now at all, so I don't even know what Microsoft's official opnion on the topic could be said to be :).

I'll get my presentations from NAB posted in the next few days for everyone to check out, but I'm talking about a particular case where feedback from professionals is that the output of our VC-1 tool outperforms the output of competing H.264 tools.

There's lots of scenarios where VC-1 can outperform H.264 for particular goals, but the converse is certainly true as well. It all depends on what you're trying to do and what you're trying to do it with, and to.

[Dark Shikari]

I have noticed a number of unbelievably badly encoded Blu-ray discs lately. This is probably for the same marketing reasons as previously mentioned; many companies are still marketing really bad encoders. Its ironic to see that real-time broadcast encoders can do better jobs than Blu-ray encoders

One particularly bad one I saw had the following properties:
1. No P or B subpartitions.
2. 8x8dct only.
3. i8x8 only; no other block types.
4. Ridiculously long motion vectors throughout the frame in nearly static scenes.

[benwaggoner]

I have noticed a number of unbelievably badly encoded Blu-ray discs lately. This is probably for the same marketing reasons as previously mentioned; many companies are still marketing really bad encoders. Its ironic to see that real-time broadcast encoders can do better jobs than Blu-ray encoders!
Yeah, I'm a judge for the DVDA Excellence Awards, and just got done judging a number of DVD and BD discs. I was really surprised how problematic many of the BD discs were, particularly in dark areas. Tons of blocking in black and other problems.

Keeping low-luma looking good was a major focus of all our work in PEP for VC-1, and one of the reasons why many compressionists prefer it over the H.264 products. Apropos of what what I was saying above, I don't think there's anything particular about VC-1 that made it easeir to do this; it was a matter of hearing the feedback that this had become a big problem due to all the consumer displays with non-perceptually-uniform gamma an elevated blacks, and then our spending a ton of time tweaking the encoder to do well in that case.

One particularly bad one I saw had the following properties:
1. No P or B subpartitions.
2. 8x8dct only.
3. i8x8 only; no other block types.
4. Ridiculously long motion vectors throughout the frame in nearly static scenes.
Wow. Can you share what title that was?

I'm not aware of any commercial BD encoders that are THAT bad, although I haven't done stream analysis of the output of all of them by any means. Being all 8x8 seems particularly odd.

[Dark Shikari]

Wow. Can you share what title that was?Cowboy Bebop: The Movie. An Ateme employee (bobobolo) suggested to me that it might be using the Vegas encoder. And a correction: it didn't only use 8x8dct, it almost only used 8x8dct. There are some very few choice blocks where it doesn't use 8x8dct (but intra is all 8x8dct). For AQ it used what appeared to be some sort of lumimasking.

I have found it quite odd that the Blu-ray encoders are so drastically behind the times; its as if everyone has leapfrogged them in the past 4 years.

[CruNcher]

Last edited by benwaggoner : Today at 02:06. Reason: Sorry, accidental edit due to still learning mod interface :)


Huh did i miss something, congratz to the mod position :D


it was a matter of hearing the feedback that this had become a big problem due to all the consumer displays with non-perceptually-uniform gamma an elevated blacks, and then our spending a ton of time tweaking the encoder to do well in that case.


Yep and this is indeed a big problem and the high quantization behavior of H.264 does indeed really bad @ those cases visually , and for sure Microsoft put allot off effort in this especially tweaking all the bells and whistles out of the encoder "visually" to win the Race @ the Studios.
And they succeeded with this because most of the H.264 codec implementer are still concentrating more on mathematical efficiency then finding solutions for certain visual problems (speaking of HVS) and unfortunately that is still the case, there seem to be only a few companies that really put allot of research into this area of improvement (and of course X264 slow but steadily).
My visual experience from what i saw so far is also that the Adaptive behavior (in all ranges Scenecut,B-frame placement decision,Adaptive Deadzones,Partition decisions) of the VC-1 encoder is much better refined @ the moment then for example it is in case of X264 (X264s Adaptive behavior even seems to hurt in some cases more than it helps visually) and that allot of tweaking effort was put into this by Microsoft over the years of development and research ahead of the others, because they knew it's not only about efficiency alone but about a good balance for a given target which in that case would be HD Film Content and they really did there work.
Dark Shikari sure the DVD Forum tests where long ago but it doesn't change the fact that the visual results @ that time where already more pleasing for VC-1 and that this started the existence of FRExt on H.264's side, and this tells already allot imho FRExt seems just like a workaround of a Problem that Microsoft solved before H.264 even realized it is existing (would High Profile even exist without the DVD Forum test results vs VC-1?) ;).
Tough what i don't understand is why FGM isn't still used for this Problem, modeling Grain instead of Preserving it and keeping the bandwidth free for more detail seems a much better solution then FreXt or Microsoft's internal changing partition approaches that try to preserve it @ all costs which results in a heavy encoding speed and bandwidth lose, but it doesn't seem to be used yet by the Studios, they rather still like to compress the Grain than to model it?.


At this point there is only a single studio not actively working on VC-1 encoded Blu-ray titles.

Disney?

[Sagittaire]

There's lots of scenarios where VC-1 can outperform H.264 for particular goals, but the converse is certainly true as well. It all depends on what you're trying to do and what you're trying to do it with, and to.

Well H264 outperform VC1 at high quantisation encoding (aka "low bitrate"). For low quantisation all the advanced fonctionality from H264 (adaptative partition, inloop, multiref, wpred, cabac) became useless and HVS fonctionaly are more and more important. In this case It's possible that good VC1 implementation outperform H264 implementation not specifiquely optimised for low quantizer encoding.


Yeah, I'm a judge for the DVDA Excellence Awards, and just got done judging a number of DVD and BD discs. I was really surprised how problematic many of the BD discs were, particularly in dark areas. Tons of blocking in black and other problems.

Well it's not a VC1 particularity. VC1 implementation (PEP or CinevisionPSE) from MS use particular HVS tweak for DarK Area
- Internal Dark Noise Filtering (pre-process with 3D filtering with luma masking)
- Adaptative Dead Zone (certainely with luma masking too)
- Adaptative Qunatisation (certainely with luma masking too)

All these HVS tweak can be used for H264 (easy for Dark Shikari to implement that with x264 I think). Anyway you can make that too with actual commercial H264 implementation like Cinevision 2.5 with Mainconcept/elecard implementation:
- Internal Dark Noise Filtering (call "black normalisation level")
- Adaptative Quantisation (call "AQ with luma masking")

[CruNcher]

Yes and that's also why the PEP Encoder is not 100% the same like the consumer encoder it is especialy tuned for Film Content the same for Cinevision and Cinemacrafts Encoder and in those regards X264 is still @ the start it is more tuned for Anime then anything else tough it's high bitrate visual results with Film Content improving constantly since some time now (and also it's very flexible due to it's wide variety of settings that can be adapted for certain source encoding scenarios) :)

[Inventive Software]

I must admit, since VAQ made it into x264's trunk, I've noticed encodes not only needing less bitrate, but also looking better(?) than without it! However VC-1 still wins in the high bitrate (20+ Mbits) scenario, since it doesn't throw away detail when quantisers are lowered like MPEG-2 and H.264.

[Golgot13]

Ben,

you can go to see Sony or Thomson on NAB, they show their H264 encoder and you will understand what can do
a H264 encoder (better than the software that you used for DVDA session)....

If you, Ben, can put some video we will show you (same that DVDA session or other in Full HD)
I can use some H264 studio encoder if you want...


About evolution of encoding process in H264 encoder, I understand that KDDI make a good demo
about better quantizer use when their many informations on picture: so if somebody can go to see
the demo to report all information.
NHK do a demo about broadcast UHD (Ultra HD: 8K !!!) in H264 at 128Mbps in realtime encoding and decoding.
NHK use only H264 solution (no VC1, it's really strange...) for HD and 3D HD (3D video in HD format)...
I understand there is only MS which show VC1 solution (except some transcoder solution for SD size).

Last, we will have soon more HD channel in H264 because many companies show
H264 HD statistic encoder and broadcasted multiplexer.

[benwaggoner]

Yes and that's also why the PEP Encoder is not 100% the same like the consumer encoder it is especialy tuned for Film Content the same for Cinevision and Cinemacrafts Encoder and in those regards X264 is still @ the start it is more tuned for Anime then anything else tough it's high bitrate visual results with Film Content improving constantly since some time now (and also it's very flexible due to it's wide variety of settings that can be adapted for certain source encoding scenarios) :)
Actually, the VC-1 Encoder SDK is a pretty close derivative of PEP (although it was forked before the most recent PEP release). There's a lot of the film-tuned quality improvements in there, even if not all apps chose to expose them. But even a prosumer-esque app like Expression Encoder 2 exposes the PEP-derived features like Adaptive Deadzone, Differential Quantization, and our noise reduction filter.

VC-1 Encoder SDK is absolutely meant to enable consumer/professional apps to provide VC-1 Blu-ray encoding quality like using PEP in 2-pass mode.

[Sagittaire]

Actually, the VC-1 Encoder SDK is a pretty close derivative of PEP (although it was forked before the most recent PEP release). There's a lot of the film-tuned quality improvements in there, even if not all apps chose to expose them. But even a prosumer-esque app like Expression Encoder 2 exposes the PEP-derived features like Adaptive Deadzone, Differential Quantization, and our noise reduction filter.

VC-1 Encoder SDK is absolutely meant to enable consumer/professional apps to provide VC-1 Blu-ray encoding quality like using PEP in 2-pass mode.

Well I have big difference at low bitrate between VC1 from SDK and VC1 from PEP. I use this command line with VC1 SDK:

@REM -----------------------------------------------------------
@REM
@REM Profil BluRay 1080p23.976 2 passes extra high quality
@REM
@REM -----------------------------------------------------------


@REM Source file name (suffit de mettre la source ici)
set E_SRC=Encodage_HD_NTSC_1080p.avs

@REM Set of bitrates (ici le bitrate)
set E_BR=10000

@REM Set of max bitrates (ici le bitrate max)
set MAX_BR=24000

@REM Set of Buffer (ici le buffer)
set BUF_BR=3750000

@REM Profil (ici le nom des fichiers de sortie)
AVS2ASF.exe -i %E_SRC% -o azerty.vc1 -rate %E_BR% -peakrate %MAX_BR% -vbv %BUF_BR%
-framerate 23.976 -ratecontrol 3 -profiletype 2 -maxkeydist 24 -bframes 1 -bdeltaqp 1 -adaptiveGOP
-keyPop 2 -inloop 1 -overlap 1 -complexity 5 -motionsearchlevel 2 -mesearchmethod 1 -mbcost 1
-mvcost 1 -mvrange 4 -adaptivequant 1 -dquantoption 1

pause

and equivalent setting for pep/pse. Bug in avs2asf.exe ... ?

[Golgot13]

Hi Ben,

NAB is finish, so don't forget us we wait the video.
About LV, the Wynn hotel is very nice and there is a golf !!! :cool:
I hope you tested it.

About H264 encoder, did you see the new Sony and Thomson encoder ?
My contact said me this encoder are good, so better than PeP/PSE,
because he use it but not for long time now...

[benwaggoner]

Speaking of which, here's my presentations from NAB:

http://www.on10.net/blogs/benwagg/22040/

[benwaggoner]

...and here's a torrent of an ATSC-compliant encode of the 1080i source, for a better example of what a final clip looks like.

http://216.99.212.233:6969/torrents/TallShip_1080i_ATSC.zip.torrent?9BA0395FC0E7B5D2203F9BEF4CB3AB54B0B8D367

[Sagittaire]

Speaking of which, here's my presentations from NAB:

http://www.on10.net/blogs/benwagg/22040/

Well my 2 cents:

MPEG-2
• Standard for HD broadcast for 10+ years
• Well understood
• Mature tools
• Approaching limit of compression efficiency
• Transparent compression requires much higher data
rates than other codecs
• Needs 50-100% more bitrate than VC-1 or H.264
• Limits quality for longer titles on SL discs
• But MPEG-2 can look great @ BD‟s 40 Mbps peak
• Remains useful for transcoding consumer content
• From HDV or ATSC without recompression

In fact with good encoder MPEG2 at HD resolution/bitrate never needs 100% more bitrate. MPEG2 is a really good codec for BD50 encoding. Can be a really good codec for BD25 encoding with medium/short movie.


VC-1
• VC-1 is SMPTE designation (SMPTE 421M-2006)
• Licensing handled by MPEG-LA
• Standardization of Windows Media Video 9
• Microsoft works closely with major studios to support
VC-1 encoding within their workflow
• Best codec for preserving texture detail at lower bitrates
• We expect wide support in HD authoring tools
• VC-1 Encoder SDK free for license
• Used on most HD DVD titles, roughly 1/3rd of Blu-ray
• Can make single VC-1 encode for both HD DVD and BD
• Warner VC-1 BD titles use same encode as HD DVD

I have Rate Control problem with VC1 SDK. VC1 from pep/pse produce by far better quality with equivalent setting.

H264 is by far the best codec in high quantisation encoding scenario. Cabac, more powerfull inloop, wpred, multiref produce are big advantage in this case.

You can use the same encoding for VC1, MPEG2 and H264 for HDDVD and BD.


AVC/H.264
• AVC, H.264, MPEG-4 Part just different names
• Defined by MPEG and ITU
• High 4:2:0 profile supported in BD/HD DVD
• Adds 8x8 blocks to Main Profile‟s 4x4 blocks
• Improves ability to handle textures
• Main Profile behind VC-1/MPEG-2 in DVD Forum tests
• Deliver low artifacts, but may lose texture detail
• Highest processing requirement for decoding
• A concern for software players, not CE devices
• BD spec requires at least 3 “slices” be used to ease
CABAC decode

H264 preserve texture and detail even at low bitrate. H264 can use low deadzone or adaptative threshold exactly like VC1.

At this time the best software decoding use less CPU for H264 than for VC1 (coreavc decoder outperform MS VC1 DMO decoder). VC1, MPEG2 or H264 decoding are not a problem with actual GPU generation.


My opinion, for 24p film content
• 480p: 1.5 Mbps
• 720p: 4 Mbps
• 1080p: 8 Mbps

For the same quantisation level (aka quality by pixel) there are a simple and empirical equation for that:

bitrate / ( H * W * Fps ) ^ N with N ~ 0.75

For the same source with the same average quantizer value:
• 480p: 1.5 Mbps
• 720p: 3.1 Mbps
• 1080p: 5.8 Mbps

And compression artefact for 1080p are less noticable simply because the relative size of artefact are less important for 1080p. 8x8 structure for all codec imply same absolute artefact size for 1080p or 480p. That's mean that equivalent subjective quality bitrate are even more close. For equivalent subjective quality IMO N ~ 0.6 is a good value for the previous empirical formulation.

Well now the bitrate equivalence for MPEG2 if my reference is 480p at 6 Mbps:
• 480p: 6.0 Mbps
• 720p: 12.5 Mbps
• 1080p: 23.0 Mbps


Nice things about encoding for download
• Don‟t have to worry about optical limits
• Can use longer GOPs for more efficient encoding
• Less risk of keyframe popping
• Average to Peak bitrate ratios often much higher
• Reduces segment reencoding needs

Optical limit for BluRay are really not a problem for ~ 8 Mbps "download encoding"
- GOP at 1 sec is not a really short gop. infinite GOP (keyframe only for scenecut) imply not a big improvement. It's easy to fight keyframe popping if you use really low ratio between intra-inter frames.
- Average bitrate at 8 Mbps with max at 40 Mbps with buffer at 30 Mbits is in practice unconstrained rate control encoding.

[MarcioAB]

Adding a BPP perspective:

Benwaggoner
480p: 1.5 Mbps = 0.15 BPP
720p: 4 Mbps = 0.18 BPP
1080p: 8 Mbps = 0.16 BPP
(hum...)

Mpeg4 (empirical equation)
480p: 1.5 Mbps = 0.15 BPP
720p: 3.1 Mbps = 0.14 BPP
1080p: 5.8 Mbps = 0.12 BPP
These are almost the BPP numbers I normally see.
I work with 0.01 BPP above those.

Mpeg2
480p: 6.0 Mbps = 0.61 BPP
720p: 12.5 Mbps = 0.57 BPP
1080p: 23.0 Mbps = 0.46 BPP
(obs: a well encoded Mpeg2)

[benwaggoner]

Adding a BPP perspective:

Benwaggoner
480p: 1.5 Mbps = 0.15 BPP
720p: 4 Mbps = 0.18 BPP
1080p: 8 Mbps = 0.16 BPP
(hum...)

Mpeg4 (empirical equation)
480p: 1.5 Mbps = 0.15 BPP
720p: 3.1 Mbps = 0.14 BPP
1080p: 5.8 Mbps = 0.12 BPP
These are almost the BPP numbers I normally see.
I work with 0.01 BPP above those.

Mpeg2
480p: 6.0 Mbps = 0.61 BPP
720p: 12.5 Mbps = 0.57 BPP
1080p: 23.0 Mbps = 0.46 BPP
(obs: a well encoded Mpeg2)
Okay, I can't claim I did a whole lot of emperical testing on those. The numbers I provided conflated a number of things.

Video and audio data rates
Assumptions of audience quality expectations for each tier
Content with film grain, where bpp doesn't seem to scale to 0.75 as closely as for cleaner content

[IgorC]

Sorry for offtopic.

benwaggoner
WMA Pro 10 outperforms AC-3 2-3x at low rates
Since when VC1 is optimizied for low rates to be used with audio multichannel tracks at low rates?

Is there any public test that shows it?
there is only one http://www.ebu.ch/CMSimages/en/tec_doc_t3324-2007_tcm6-53801.pdf

And there is no proof for such statement.

There is no 2x improvement even over MP3 at some usefull range of bitrate. Compare state of art HE-AAC 64 kbit/s vs LAME 128 kbit/s.

[benwaggoner]

Sorry for offtopic.

benwaggoner

Since when VC1 is optimizied for low rates to be used with audio multichannel tracks at low rates?

Is there any public test that shows it?
there is only one http://www.ebu.ch/CMSimages/en/tec_doc_t3324-2007_tcm6-53801.pdf

And there is no proof for such statement.

There is no 2x improvement even over MP3 at some usefull range of bitrate. Compare state of art HE-AAC 64 kbit/s vs LAME 128 kbit/s.
VBR WMA Pro 10 stereo @ 48 Kbps outperforms AC-3 stereo at CR 160 Kbps. Part of the practical advantage for WMA Pro for VOD is that we've got 2-pass VBR implementations, while AC-3 is almost always implemented as CBR. Rate-controlled VBR audio can be a big with with soundtracks, since they vary so much in complexity.

[Dark Shikari]

VBR WMA Pro 10 stereo @ 48 Kbps outperforms AC-3 stereo at CR 160 Kbps.I find this highly doubtful, given that 160kbps AC-3 is basically transparent, while 64kbps WMA sounds atrocious.

Then again, this is yet another case of "ours is better than everyone else's despite all indicators to the contrary" syndrome, a marketing concept that has persisted for decades despite the fact that almost nobody falls for it. Of course, the mere fact that VC-1, VP7, and RV30/40 exist as marketable products shows that a fool and their money are indeed soon parted.

[benwaggoner]

Is there any public test that shows it?
there is only one http://www.ebu.ch/CMSimages/en/tec_doc_t3324-2007_tcm6-53801.pdf
Also, I note that only tested WMA 10 Pro at 192+ Kbps. That excludes the frequency synthesis modes used in the 32-96 Kbps range where the biggest efficiency improvements come.

But even still, WMA 10 Pro's 128 Kbps VBR with 5.1 can produce quite good quality with soundtracks, at a bitrate AC- struggles at with stereo and can't reach with 5.1.

[IgorC]

VBR WMA Pro 10 stereo @ 48 Kbps outperforms AC-3 stereo at CR 160 Kbps.
Really? Link to public test?

[benwaggoner]

I find this highly doubtful, given that 160kbps AC-3 is basically transparent, while 64kbps WMA sounds atrocious.
That doesn't match my experience, but this is an emperical question. Can you share what source you're thinking of, and what settings you used?

Note I'm speaking of 48 Kbps 2-pass VBR WMA 10 Pro, and with soundtrack content. Both CBR encoding and test clips of more consistant complexity would be less advantageous to WMA 10 Pro.

[benwaggoner]

Really? Link to public test?
No, that's data coming internally, and my own anecdotal experience.

I would like to see a new hydrogen audio test for low bitrates soon. Their last round that included WMA 10 Pro wasn't a full apples to apples, as it compared CBR WMA 10 Pro to fixed-quality modes in the other codecs. I'd love to see the results of an independent double-blind test using either all CBR or all VBR for the advanced codecs. I think we'd do well, but it's always good to have community validation.

[IgorC]

No, that's data coming internally, and my own anecdotal experience.

Internally? hm....

Thank you for information.
Good bye.

[Dark Shikari]

That doesn't match my experience, but this is an emperical question. Can you share what source you're thinking of, and what settings you used?OK, I just did a quick test. Since I don't have an AC-3 encoder handy, I compared AAC-HE 2pass 48kbps to WMA Pro 2pass 48kbps in a blind test using Winamp (put both in playlist, randomely skip a few dozen times so I don't know which is which, and then listen to the two in order).

WMA sounded atrocious. It was literally painful to listen to. Nero AAC sounded just fine, very few noticeable issues with the sound.. LAME MP3 128kbps sounded just fine too, and I suspect that is similar to 160kbps AC-3.

Source was "Jupiter", from Gustav Holst's "The Planets."

[IgorC]

I open this topic in HA forum. Let's see what audio professionals say.
http://www.hydrogenaudio.org/forums/index.php?showtopic=62889

[Golgot13]

@ Dark Shikari, @ IgorC and at all,


After many request, from this forum and thread, they changed many information on MS VC1 website
like "VC1 is much better than MPEG2/H264" (and they updated last year, 2007, with new from 2004-2005)....
Don't forget MS prefer to say like "internally test" because "external re-test" could not prouve it...


If MS or Ben want to prouve officially someting about VC1 (best codec for... make presentation or may be make bretzel ;) )
you can participate at MSU annual comparison codec (MS don't want since comparison between MS Photo and JPEG2000 ?).


Ben, what it's the low bitrate for VC1 ("best to preserve detail texture....) for you.
Can you explain the internally test to compare H264 (from Mainconcept you said) and VC1?
- VC1 file made exactly with VC1 core encoder only or core encoder + video preprocessing
- H264 file made only with H264 encoder (no preprocessing ?)
- Preset of H264
...

[benwaggoner]

OK, I just did a quick test. Since I don't have an AC-3 encoder handy, I compared AAC-HE 2pass 48kbps to WMA Pro 2pass 48kbps in a blind test using Winamp (put both in playlist, randomely skip a few dozen times so I don't know which is which, and then listen to the two in order).[QUOTE]
CBR or VBR?

[QUOTE]WMA sounded atrocious. It was literally painful to listen to. Nero AAC sounded just fine, very few noticeable issues with the sound.. LAME MP3 128kbps sounded just fine too, and I suspect that is similar to 160kbps AC-3.
Atrocious? I wonder if something else went on there. Did you use WME for rate conversion perhaps?

Also, note I was talking about movie soundtrack encoding above, not orchestral music. Orchestral music, which is more consistent than a soundtrack, would have less advantage for WMA Pro's VBR mode versus CBR codecs.

[Golgot13]

Also, note I was talking about movie soundtrack encoding above, not orchestral music. Orchestral music, which is more consistent than a soundtrack, would have less advantage for WMA Pro's VBR mode versus CBR codecs.

So the soundtrack must be specific: movie not orchestral music
But what sort of movie you talked to have a better detail texture with VC1 than H264 ?

[Dark Shikari]

CBR or VBR?VBR unless otherwise specified.

Atrocious? I wonder if something else went on there. Did you use WME for rate conversion perhaps?No, no rate conversion, its just that WMA sounds terrible at low bitrates. This isn't surprising; most audio formats do.

Also, note I was talking about movie soundtrack encoding above, not orchestral music. Orchestral music, which is more consistent than a soundtrack, would have less advantage for WMA Pro's VBR mode versus CBR codecs.Aren't movie soundtracks almost exclusively orchestral music?

[benwaggoner]

Aren't movie soundtracks almost exclusively orchestral music?
Ah, I think I see our confusion. I meant soundtrack in the sense of the actual final mixed audio for a movie. So music, voice, SFX, etcetera. In a typical soundtrack, there's a fair amount of silence and dialog that's easy to encode, allowing the more complex parts (like orchestral music) get substantially more bits than the straight ABR would allow.

Might be interesting to use something like the Elephant's Dream 2-channel mix for this comparison. IIRC that's a pretty typical mix of elements.

[Inventive Software]

I do find WMA quite good at 5.1 audio. I did an encode of Elephants Dream with 6 WAVs (from the FLACs), and the encoder was set in WME to 192 Kbps 5.1. (Most AC-3 audio at that bitrate is 2 channel. ;)) It was very good, I couldn't tell much difference between this and the original.

[benwaggoner]

I do find WMA quite good at 5.1 audio. I did an encode of Elephants Dream with 6 WAVs (from the FLACs), and the encoder was set in WME to 192 Kbps 5.1. (Most AC-3 audio at that bitrate is 2 channel. ;)) It was very good, I couldn't tell much difference between this and the original.
Yeah, I found VBR 128 5.1 fine for ED as a soundtrack (didn't try headphone audio-only listening, which is a lot pickier).

Note that, from an efficiency perspective, the WMA 10 Pro multichannel encoder doesn't implement the low bitrate frequency synthesis modes, so <128 Kbps is almost twice as efficient as the higher bitrates.

[benwaggoner]

But what sort of movie you talked to have a better detail texture with VC1 than H264 ?
That's a quote from the director of a recent Oscar winning film when a neutral studio showed him encodes of that film produced by PEP and several Blu-ray H.264 encoders. After the demo, he mandated that all his films be encoded with VC-1 for Blu-ray.

I'll see if I can get permission to share the director's name; no promises there.

It's also the broad consensus of Hollywood compressionists, which is why we're seeing the use of VC-1 on Blu-ray going up substantially now that the format war is over. There's only one studio left who doesn't have a substantial number of VC-1 titles in production right now.

[smok3]

Yeah, I found VBR 128 5.1 fine for ED as a soundtrack (didn't try headphone audio-only listening, which is a lot pickier).
yeah, and you would need 6 ears as well, hard one.

After the demo, he mandated that all his films be encoded with VC-1 for Blu-ray.
was that Ed Wood or somebody else?

[Dark Shikari]

After the demo, he mandated that all his films be encoded with VC-1 for Blu-ray.Odd, I would think he could get the same effect simply by using Avisynth's Blur() command.

[benwaggoner]

Odd, I would think he could get the same effect simply by using Avisynth's Blur() command.
That was his complaint; the H.264 encodes he was shown lost detail he wished to preserve, and which the VC-1 encode did a better job of retaining.

[Manao]

Dark Shikari : quiet down. Read benwaggoner carefully before answering. He said PEP was compared to "several Blu-ray H.264 encoders", and that it was deemed better than those encoders.

Never did he say VC1 > H264. He says PEP > professionnal Bluray encoders, which wouldn't surprise me at all.

[Dark Shikari]

Dark Shikari : quiet down. Read benwaggoner carefully before answering. He said PEP was compared to "several Blu-ray H.264 encoders", and that it was deemed better than those encoders.

Never did he say VC1 > H264. He says PEP > professionnal Bluray encoders, which wouldn't surprise me at all.I haven't seen that in my experience either though; on the one hand it wouldn't surprise me, but the few "VC-1 vs H.264" comparisons between movies available in both formats were... less than impressive... for VC-1. In particular, it looked like someone ran a blur filter over the grain of the video, while the H.264 versions retained their sharpness.

[Golgot13]

That's a quote from the director of a recent Oscar winning film when a neutral studio showed him encodes of that film produced by PEP and several Blu-ray H.264 encoders. After the demo, he mandated that all his films be encoded with VC-1 for Blu-ray.

MS have good power of persuasion, and everything is nice, eg on your compressionist Tuesday
On Wynn Palace (with Golf in Las vegas) with good food (?)....

I can not judge anything with this comment:
- He win a Oscar because he used PEP, no...
- several BluRay H264 encoder: which ? Preset ? ...
And you know that many (and more I think) compressionist use default parameter to encode the movie.
PEP is good tool, to my mind, he have a good video preprocessing but a bad codec format (VC1).

If you can provide the video I will make the test (H264 encoding) for this guy, but not nice hotel and good food with me...



I'll see if I can get permission to share the director's name; no promises there.


I don't need. I want only some video to try to prouve you that H264 is the best codec.
I need the video source (from you or Oscar winner)


It's also the broad consensus of Hollywood compressionists, which is why we're seeing the use of VC-1 on Blu-ray going up substantially now that the format war is over. There's only one studio left who doesn't have a substantial number of VC-1 titles in production right now.

No sure, may be if you give for free PEP or make many presentation (with your MS persuasion's power)
at video director, productor, realisator,... of movie who order only VC1 on their BD title....


Last I need the video source use for DVDA test to make for you the H264 encoding.
And all people on AVSForum and Doom9 will see and give their conclusion, on parallel at PSNR-SSIM measure...

[Dark Shikari]

Here's an example of the "incredible" grain retention power of VC-1.

For reference, here's a crop of a keyframe from the source, which is probably good enough quality to use as a reference:

http://img178.imageshack.us/img178/1286/keyframetb6.png

An interframe:

http://img518.imageshack.us/img518/7914/vc1de9.png

Seriously, that's just awful.

(Source: 300, VC-1)

[Golgot13]

Never did he say VC1 > H264. He says PEP > professionnal Bluray encoders, which wouldn't surprise me at all.


Yes, the video preprocessing of PEP is really good.

[benwaggoner]

I haven't seen that in my experience either though; on the one hand it wouldn't surprise me, but the few "VC-1 vs H.264" comparisons between movies available in both formats were... less than impressive... for VC-1. In particular, it looked like someone ran a blur filter over the grain of the video, while the H.264 versions retained their sharpness.
Links?

Also, were they of encoded of the same source encoded with the same overall parameters?

[Dark Shikari]

Links?

Also, were they of encoded of the same source encoded with the same overall parameters?I don't have them, I saw them a while ago. It was a link b0bor gave me a while back, I think.

I have no idea about parameters; that doesn't even make sense, since VC-1 and H.264 take totally different parameters. I'm not the studios, so I can't say what parameters/etc they're using.

[benwaggoner]

I have no idea about parameters; that doesn't even make sense, since VC-1 and H.264 take totally different parameters. I'm not the studios, so I can't say what parameters/etc they're using.
I mean bitrate and such. If it's comparing a 20 Mbps Blu-ray encode to a 10 Mbps VC-1 encode...

[Dark Shikari]

I mean bitrate and such. If it's comparing a 20 Mbps Blu-ray encode to a 10 Mbps VC-1 encode...Ah, that would be true in the case of an HD DVD vs Blu-ray comparison.

Either way, given the screenshot above, the performance of VC-1 for grain retention, at least, can be pretty embarrassing ;)

[benwaggoner]

Either way, given the screenshot above, the performance of VC-1 for grain retention, at least, can be pretty embarrassing ;)
Without identifying the movie, it's hard to say much about it at all. We don't know bitrates, source, which version of the encoder...

[Dark Shikari]

Without identifying the movie, it's hard to say much about it at all. We don't know bitrates, source, which version of the encoder...I named the movie at the bottom of the post :rolleyes:

300

[Thunderbolt8]

according to avsforums the bitrate for the '300' videotrack is 16.80 (1:56:32 playtime, 2.40 AR)
and from my remux of that movie I know that the size of the videotrack is ~13 GB

[Dark Shikari]

according to avsforums the bitrate for the '300' videotrack is 16.80 (1:56:32 playtime, 2.40 AR)
and from my remux of that movie I know that the size of the videotrack is ~13 GBYes, that's about right. Though I don't have a VC-1 stream analyzer, I suspect the scene where that screenshot came from hit the bitrate limit.

[Sagittaire]

I make actualy test with Casino Royal (High Quality Source) with high grain/noise level at 6.9 Mbps (BD9 encoding). All the H264 encoder (highest possible quality level) outperform really VC1 (from pep/pse or SDK) for grain retention and all the other quality sector (blocking, ringing, banding, texture quality, detail level ... etc).

Here little sample with really high quality level at 6.9 Mbps for 1080p and 144 min movie:

High motion with strong grain:
http://jfl1974.free.fr/upload/Casino_MCCLI_BD9-005.mkv

Really High Motion:
http://jfl1974.free.fr/upload/Casino_MCCLI_BD9-014.mkv

Slow Motion with fine grain:
http://jfl1974.free.fr/upload/Casino_MCCLI_BD9-017.mkv


I make the same external high quality pre-process for all codec (dithering, dark noise filtering). I use cinevisionPSE at highest possible quality level with this xml quality profil:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/DigitalMedia/Codecs/2007/05/24/ParallelEncoderProject">
<ProjectSettings>
<Bitrate>6900</Bitrate>
<BufferSize>3750000</BufferSize>
<BufferSizeEnum>5</BufferSizeEnum>
<ClosedCaptionsPresent>false</ClosedCaptionsPresent>
<Comment/>
<DisplayHeight>1080</DisplayHeight>
<DisplayWidth>1920</DisplayWidth>
<EncodedFrameRate>23.976</EncodedFrameRate>
<EncodedFrameRateEnum>1</EncodedFrameRateEnum>
<EncodingHeight>1080</EncodingHeight>
<EncodingMode>1</EncodingMode>
<EncodingWidth>1920</EncodingWidth>
<InterlaceMode>0</InterlaceMode>
<LegacyDQuant>false</LegacyDQuant>
<OverlapDeblocking>false</OverlapDeblocking>
<PeakBitrate>20000</PeakBitrate>
<ProjectName>Project1</ProjectName>
<PublishedFileURL>D:\Mes dossiers\PSEViewer\Projects\Project1.vc1</PublishedFileURL>
<SegmentFilesDirectory>D:\Mes dossiers\PSEViewer\Projects</SegmentFilesDirectory>
<Segments>1</Segments>
<SourceColorSpace>1</SourceColorSpace>
<SourceFrameRate>23.976</SourceFrameRate>
<SourceFrameRateEnum>1</SourceFrameRateEnum>
<SourceHeight>1080</SourceHeight>
<SourceMarkIn>0</SourceMarkIn>
<SourceMarkOut>207442</SourceMarkOut>
<SourceTopFieldFirst>true</SourceTopFieldFirst>
<SourceWidth>1920</SourceWidth>
<StartingTelecinePhase>0</StartingTelecinePhase>
<ColorFormat>
<Off>
</Off>
</ColorFormat>
<LetterboxPillarbox>
<LetterboxManual>
<Bottom>939</Bottom>
<MarkIn>86400</MarkIn>
<MarkOut>86400</MarkOut>
<Top>140</Top>
</LetterboxManual>
</LetterboxPillarbox>
<PixelAspect>
<PixelAspectRatioIndex>1</PixelAspectRatioIndex>
</PixelAspect>
<SourceFrameZeroTimecode>
<SMPTEHours>0</SMPTEHours>
<SMPTEMinutes>0</SMPTEMinutes>
<SMPTESeconds>0</SMPTESeconds>
<SMPTEFrames>0</SMPTEFrames>
</SourceFrameZeroTimecode>
<Sources>
<Source>G:\azerty.yuv</Source>
</Sources>
<UIData>
<RecentPublishedFileURL/>
</UIData>
</ProjectSettings>
<FirstAndSecondPassSettings>
<AdaptiveDeadZone>true</AdaptiveDeadZone>
<CommonSettings>
<AdaptiveBFramePositioning>true</AdaptiveBFramePositioning>
<BFrames>1</BFrames>
<GOPLength>24</GOPLength>
<InLoopDeblocking>true</InLoopDeblocking>
<InterBlockDeadZone>1.50</InterBlockDeadZone>
<IntraBlockDeadZone>1.20</IntraBlockDeadZone>
<KeyFramePulseReduction>1</KeyFramePulseReduction>
<MaxLuma>255</MaxLuma>
<MedianFilterSmooth>0</MedianFilterSmooth>
<MedianFilterTextured>0</MedianFilterTextured>
<MinLuma>0</MinLuma>
<SceneChangeDetection>true</SceneChangeDetection>
<DarkRegionDenoise>
<Off>
</Off>
</DarkRegionDenoise>
<Denoise>
<Off>
</Off>
</Denoise>
</CommonSettings>
<Quantization>
<On>
<BDeltaQP>1.0</BDeltaQP>
<BFrameAggressiveBitUsage>2</BFrameAggressiveBitUsage>
<DarkRegionBias>0</DarkRegionBias>
<DarkRegionThreshold>8</DarkRegionThreshold>
<MinEncodeQP>1.0</MinEncodeQP>
<PFrameAggressiveBitUsage>1</PFrameAggressiveBitUsage>
</On>
</Quantization>
</FirstAndSecondPassSettings>
<FirstPassSettings>
<ChromaSearch>0</ChromaSearch>
<EncoderComplexity>2</EncoderComplexity>
<MotionMatch>0</MotionMatch>
<MotionSearchRange>4</MotionSearchRange>
<ThreadCount>0</ThreadCount>
</FirstPassSettings>
<SecondPassSettings>
<ChromaSearch>2</ChromaSearch>
<EncoderComplexity>4</EncoderComplexity>
<MotionMatch>2</MotionMatch>
<MotionSearchRange>4</MotionSearchRange>
<ThreadCount>0</ThreadCount>
</SecondPassSettings>
<ReEncodeSettings>
</ReEncodeSettings>
</Project>


IMO make internal test is not a good idea: it's by definition no objective test.

[IgorC]

I named the movie at the bottom of the post :rolleyes:

300

THIS IS ...... Yahoo!!!

Sorry, I couldn't deny

[MarcioAB]

...and here's a torrent of an ATSC-compliant encode of the 1080i source, for a better example of what a final clip looks like.

Great image, thank you.

HD Mpeg2 @ 0.31 BPP - at least for me, that is impressive for Mpeg2. (19.45 Mbps for the ones that prefer bitrate)

Ben, as we know, I use BPP because it's nothing more than an easier form to say the final compression index relative the raw YV12 (12 as 12 BPP), that is the starting point to compress. It seems reasonable quality "gravitates" around that range of compression indexes (or BPP).

The "Lady" was compressed almost 40x ( 12 : 0.31 ) relative it's YV12 raw source.

Regard Sagittaire "Cassino's", that is a 0.14 BPP HD encode is almost 90x compressed relative it's YV12 source.

I think for that level of extremely high compression H264 is unbeatable. The question may be: reducing a little the compression (let's say 50x or 0.24 BPP), how is the behavior between H264 and VC1 ?
I say that because, we may need to specify the targets: download or physical media.

Thanks

[benwaggoner]

Ben, as we know, I use BPP because it's nothing more than an easier form to say the final compression index relative the raw YV12 (12 as 12 BPP), that is the starting point to compress. It seems reasonable quality "gravitates" around that range of compression indexes (or BPP).
For similar content, sure. But there can be a huge difference between fast-shutter sports and a nice dreamy DNR'ed 35mm film source. I'd say the BPP ratio between easiest and hardest real-world content is maybe 3:1. But yes, it's certainly one of the more useful numbers to have.

Regard Sagittaire "Cassino's", that is a 0.14 BPP HD encode is almost 90x compressed relative it's YV12 source.

I think for that level of extremely high compression H264 is unbeatable. The question may be: reducing a little the compression (let's say 50x or 0.24 BPP), how is the behavior between H264 and VC1 ?
I say that because, we may need to specify the targets: download or physical media.
There's certainly no argument that x264 in high profile can outperform any VC-1 implementation I've seen when the challenge is "lowest bitrate without visually unappealing artifacts."

One thing that makes it hard to compare H.264 and VC-1 in the abstract is that there are different implementations used in different markets; no one is using x264 for optical disc production. So it's really about comparing the best readily available implementation of each codec for each scenario.

Another thing that complicates comparisons at lower bitrates is that H.264 decoders generally don't have postprocessing, while VC-1 decoders do, so is the appropriate comparison point looking at the native decode (codec to codec) or what actually gets displayed (experience to experience).

But overall, I'd say:

H.264 does well when lowest bitrate without distracting artifacts is the goal.

VC-1 does well when quality/MIPS in software decoders is the goal (VC-1 Main Profile outperforms H.264 baseline profile).

VC-1 does well at moderate bitrates when texture and grain retention is the goal.

Both converge at reasonably high data rates.

And, one thing we can't ever forget (and which I'm constantly and painfully reminded of in my various projects), source quality and preprocessing best practices are overwhelmingly more important than codec! Almost all the bad compressed video out there isn't bad due to codec implementation, but to errors earlier in the workflow or in the use of the codec.

When I'm working with customers on challenging projects, or doing challenging projects of my own, I'd say time goes 80% to source and preprocessing issues, and only 20% to codec tuning.

[Sagittaire]

One thing that makes it hard to compare H.264 and VC-1 in the abstract is that there are different implementations used in different markets; no one is using x264 for optical disc production. So it's really about comparing the best readily available implementation of each codec for each scenario.

Mainconcept/Elecard SDK build produce similar result to x264. Professional product like Cinevision use Mainconcept/Elecard SDK build for optical disc production. I make previous Casino encoding with Mainconcept/Elecard build and the grain retention is really good at 7 Mbps. Mainconcept/Elecard outperform VC1 in this case.


Another thing that complicates comparisons at lower bitrates is that H.264 decoders generally don't have postprocessing, while VC-1 decoders do, so is the appropriate comparison point looking at the native decode (codec to codec) or what actually gets displayed (experience to experience).

Bluray don't use particular post-process for VC1. Moreover if particular post-process can improve visual quality for VC1 then the same post-process can certainly improve quality for the other codec.


H.264 does well when lowest bitrate without distracting artifacts is the goal.

Yes for BD9 for example. Or for really long movie on BD25.


VC-1 does well at moderate bitrates when texture and grain retention is the goal.

Yes. VC1 is a really good codec for BD25 encoding in 99% of the case.


Both converge at reasonably high data rates.

Yes. IMO H264 and VC1 are simply useless for BD50.


And, one thing we can't ever forget (and which I'm constantly and painfully reminded of in my various projects), source quality and preprocessing best practices are overwhelmingly more important than codec! Almost all the bad compressed video out there isn't bad due to codec implementation, but to errors earlier in the workflow or in the use of the codec. When I'm working with customers on challenging projects, or doing challenging projects of my own, I'd say time goes 80% to source and preprocessing issues, and only 20% to codec tuning.

Certainely true. But good pre-process will be the same for VC1, H264 and MPEG2. Don't change anything in this case for the codec problematic.

[benwaggoner]

Mainconcept/Elecard SDK build produce similar result to x264. Professional product like Cinevision use Mainconcept/Elecard SDK build for optical disc production. I make previous Casino encoding with Mainconcept/Elecard build and the grain retention is really good at 7 Mbps. Mainconcept/Elecard outperform VC1 in this case.
But CineVision non-PSE isn't used for any major studio Blu-ray titles that I'm aware of. It's the Sony, Toshiba, and CinemaCraft that I hear people evaluating.

Bluray don't use particular post-process for VC1. Moreover if particular post-process can improve visual quality for VC1 then the same post-process can certainly improve quality for the other codec.
Yeah, in WMP postprocessing is generally applied only for sub 1 Mbps content, and I think only SD or lower resolutions. It's not at all relevant to HD or higher bitrates.

Certainely true. But good pre-process will be the same for VC1, H264 and MPEG2. Don't change anything in this case for the codec problematic.
Agreed. My point is that most of the hard work, and most of where good quality comes from, is upstream of the codec. When we're at the point where differences in codec implementation make a difference in final quality, we're all happy since that means all the hard stuff got done right in the first place.

With problematic source, AVISynth + MPEG-1 handily beats a QuickTime Player Pro export to H.264 :).

[Sagittaire]

But CineVision non-PSE isn't used for any major studio Blu-ray titles that I'm aware of. It's the Sony, Toshiba, and CinemaCraft that I hear people evaluating.

Major studio are not representative of the complet market:

1) Major studio use BD50 in most case. H264 will always produce high quality encoding at 30 Mbps and more, even with bad H264 implementation.

2) Sony, Toshiba and Cinecraft use certainely intensive parallel encoding and not Cinevision.

I don't test Sony, Toshiba and Cinecraft implementation but if VC1 from CinevisionPSE produce better quality it's perhaps the time to change their implementation ... :devil:

[Golgot13]

But CineVision non-PSE isn't used for any major studio Blu-ray titles that I'm aware of.


Not agree...



It's the Sony, Toshiba, and CinemaCraft that I hear people evaluating.


So you compare H264 by "hear people evaluating"!!!!
You don't make like many people on this forum the test yourself ?
I'm sure you hear this, many month (year) ago.
Did you see last update of Sony encoder (available at NAB)?
Do you know Thomson encoder (Nexcode), KDDi, ... ?



Last, this discussion change anything about this thread codec comparison:
we compare the codec by the best version of each codec.

VC1 can not be better than H264 (first round of test)...

Give a video source, Ben, and we will see (I can useif you want some others H264 encoder)

[Inventive Software]

Major studio are not representative of the complet market:

1) Major studio use BD50 in most case. H264 will always produce high quality encoding at 30 Mbps and more, even with bad H264 implementation.


Quicktime (especially on Windows) begs to differ. ;)

[benwaggoner]

Not agree...
Can you name some studio titles that did you CineVision's H.264 or VC-1 implementations? Note that non-PSE is Main Concept's VC-1 as well.

So you compare H264 by "hear people evaluating"!!!!
You don't make like many people on this forum the test yourself ?
I'm sure you hear this, many month (year) ago.
Did you see last update of Sony encoder (available at NAB)?
Do you know Thomson encoder (Nexcode), KDDi, ... ?
I'm sharing info from the community of Hollywood-based professional compressionists doing work for the major studios. They spend more time with all these tools than I ever could, with more real-world projects.

[Golgot13]

Can you name some studio titles that did you CineVision's H.264 or VC-1 implementations? Note that non-PSE is Main Concept's VC-1 as well.


I can not like you to give some name...
But I can say:
BlockBuster movie from USA sell in France with a hero who drive a moto...



I'm sharing info from the community of Hollywood-based professional compressionists doing work for the major studios. They spend more time with all these tools than I ever could, with more real-world projects.


What do you want to defend:
VC1 from PeP is better than bad implementation use by some studio?


This thread is to compare your codec, VC1, and H264.
Give your video...

[MarcioAB]

H264 will always produce high quality encoding at 30 Mbps and more, even with bad H264 implementation.

Still on the contextualization of the HD scenario: At +30 Mbps ( or +0.6 BPP ) ALL codecs are the same (or no ?). Example is recent Ben's "Lady Washington" Mpeg2 @ 0.31 BPP. It's almost perfect.

One scenario is for HD on optical media (level of compression beyond +0.6 BPP). I wonder based on what one can decide which codec to use at that level of compression ... price ? legacy experience ?

Another scenario is for HD video download, SD video conferencing, SD limited devices (where compression level is below 0.14 BPP) ... I think this is the scenario we are interested here, don't ?

By the way, the "Lady Washington" encode is right in the middle of those edges scenarios.

Scenario contextualization is key to compare anything.

[Inventive Software]

One scene in that encode where far more bits were needed was right near the end with the camera pointing at the sea and the sun shining on it. Noticable blocks. ;)

[MarcioAB]

One scene in that encode where far more bits were needed was right near the end with the camera pointing at the sea and the sun shining on it. Noticable blocks. ;)

Hum ... better eyes than mine. Any way, that's at 0.31 BPP encode. How the "blockage" should be at 0.75 BPP for optical BD storage ? And how should it be at 0.14 ? The 2 edges contexts.

[CruNcher]

Still on the contextualization of the HD scenario: At +30 Mbps ( or +0.6 BPP ) ALL codecs are the same (or no ?). Example is recent Ben's "Lady Washington" Mpeg2 @ 0.31 BPP. It's almost perfect.

One scenario is for HD on optical media (level of compression beyond +0.6 BPP). I wonder based on what one can decide which codec to use at that level of compression ... price ? legacy experience ?

Another scenario is for HD video download, SD video conferencing, SD limited devices (where compression level is below 0.14 BPP) ... I think this is the scenario we are interested here, don't ?

By the way, the "Lady Washington" encode is right in the middle of those edges scenarios.

Scenario contextualization is key to compare anything.

I almost can guarantee you Ben used Rhozet Carbon Encoders Mpeg-2 Engine (Mainconcept) for this 1080i encode :)

One scene in that encode where far more bits were needed was right near the end with the camera pointing at the sea and the sun shining on it. Noticable blocks. ;)

yeah chaotic movement will allways be problematic especialy for Mpeg-2 with AVC it got much better even @ low bitrates tough VC-1 seems to still have problems with it (in low bitrates)

[benwaggoner]

Still on the contextualization of the HD scenario: At +30 Mbps ( or +0.6 BPP ) ALL codecs are the same (or no ?). Example is recent Ben's "Lady Washington" Mpeg2 @ 0.31 BPP. It's almost perfect.
Really? I think it's a lot better than most ATSC content out there, but it definitely shows blocking artifacts in some shots, particularly when there's lots of random motion in the water, or very fast pans.

Scenario contextualization is key to compare anything.
QFT!

[benwaggoner]

I almost can guarantee you Ben used Rhozet Carbon Encoders Mpeg-2 Engine (Mainconcept) for this 1080i encode :)
It was Carbon. but Carbon has always used the Canopus MPEG-2 encoder, which I've preferred for years. I haven't tried the latest Main Concept version with MPEG-2, but a couple of years ago when I was doing a lot of ATSC, the Main Concept rate control at 1080i kept exceeding the VBV even at max ATSC bitrates.

[MarcioAB]

Really?

I displayed the film in an 42-inch HD-ready (1366x768) to my family (wife and teenagers) and some friends and they unanimously give that comment. They know about blocky film because we have lots of 0.14 BPP H264 HD-content and we know how high compressed H264 behaves on dark scenes. By the way, the begining of the "Lady Washington" is really dark and it's far away from my reference of blocky under high compressed content.
The most perceivable compression-effect in a few points to me is a kind of "heat-effect" around the ship (the same one we see on the road under sun). I think it's relative to bad Motion Estimation. By the way, I do not see that issue on H264.

[Dark Shikari]

That isn't surprising; VC-1 is known for blocking issues. Example from 300 (link goes to full):

http://img186.imageshack.us/img186/2748/vc1failqv3.png (http://shrani.si/f/h/Tn/2c57NLIq/295.png)

[CruNcher]

oops yeah sorry Canopus Encoder :) not Mainconcept , this reminds me that also a Tech shootout between Canopus, Cinemacraft and Mainconcept and as OSS FFMPEGS Mpeg-2 Encoder could be quiet interesting :D
Tough very strict Broadcast or Standalone Encoding always was a OSS problem (no matter which Technology used) allot of work and special care is required compared to non restricted encoding in every field (especially rate control,interlacing and error correction) and yeah the visual results in that case for Canopus Encoder speak for themselves tough im sure also the other evolved and DivX/Mainconcept/Elecard can hold against it same as Cinemacraft nowdays. About FFMPEG im not so sure i guess Sagittaire could answer here if it could holdup in a restricted environment with it's ratecontroll nowdays, at least his last HD-DVD restricted encoding results seemed very good and promising in that regard :).

[Inventive Software]

I see myself asking how HC would fair in the ATSC encoding market........

[IgorC]

I make the same external high quality pre-process for all codec (dithering, dark noise filtering). I use cinevisionPSE at highest possible quality level with this xml quality profil:


What version of cinevisonPSE was it? Is there available version of cinevisionPSE to try its pre-process?

[Golgot13]

What version of cinevisonPSE was it? Is there available version of cinevisionPSE to try its pre-process?

I think Sagitaire use the last version available on underground area, CinevisionPSE2.01.
But there is a version CinevisionPSE2.1, available before NAB...

I repeat me:
Ben where is the HD video...:rolleyes:

Dark Shikari, ;), make some nice development for grain optimization on x264.
x264 better than PeP ? (yes from me sure)

Ben don't worry I will use for you some H264 studio solution and if you wait
I will do a encoding with real time encoder (at high bitrate: start at 14-16Mbps).

[benwaggoner]

Ben where is the HD video...:rolleyes:
Continuing to hope that you'll be as vigorous in helping out making it as you are in bugging me about it :).

I posted a question about it earlier today in the apropos thread.

[Golgot13]

Continuing to hope that you'll be as vigorous in helping out making it as you are in bugging me about it :).

When the video will be available, we will can start the encoding process...
You're promised the video in August...

To my mind, there is no sense to talk about sort of video (lanscape, more colour,...)
because the metric give the big part a result to compare the encoder(and, for me, the "codec").

[benwaggoner]

When the video will be available, we will can start the encoding process...
You're promised the video in August...

To my mind, there is no sense to talk about sort of video (lanscape, more colour,...)
because the metric give the big part a result to compare the encoder(and, for me, the "codec").
Because, as I've explained many times before, I want to make this a useful clip for testing codecs in general, so I'm trying to get community feedback on what they'd like to see in such a clip.

For example, what should the end credits look like to be a reasonable approximation of the real thing in size and relative duration? What makes a realistically challenging opening motion graphics sequence realistically challenging?

[Inventive Software]

When the video will be available, we will can start the encoding process...
You're promised the video in August...

To my mind, there is no sense to talk about sort of video (lanscape, more colour,...)
because the metric give the big part a result to compare the encoder(and, for me, the "codec").

With that kind of response, I'm struggling not to strangle you in my head...

@Ben: opening titles vary quite a lot between films and TV shows. TV shows, normally, would have a montage of previous clips. Movies can have just about anything, but lately, I've seen opening credits and titles on the main film background. Hope that helps.

[benwaggoner]

Oh, and I got around to sticking up the 1080i30 source with 5.1 audio:

http://216.99.212.233:6969/torrents/TallShip_lag_YUY2_5.1.avi.torrent?96548FD06299672814021EB0D5BD9FA826024E68

I'm out of town for most of the week, so here's something for my bandwidth to do.

[Golgot13]

With that kind of response, I'm struggling not to strangle you in my head...


Sorry but when you listen some companies which don't say truth
and know what they say at "professional" you will understand.

You never ask yourself why we don't see VC1 on MSU comparison,
why there are not many VC1 developpment (camcorder, player,...)
....

There were many update in MS website (about VC1 exactly) because I said many things
(bad for some people, good for other one). Like scientific, I prefer proof only and
this thread will be helpful.




Thank you Ben for the video. :eek: :)
I start to download it.

I hope to have right, H264 will win (good luck Ben).

Ben can you make the VC1 encoding with your CinevisionPSE 2.1 ?

[benwaggoner]

Sorry, but when you went lot of time the video and you listen what some company can say at "professional" you will understand.
I have no idea what you're trying to say there.

You never ask yourself why we don't see VC1 on MSU comparison, why there are not many VC1 developpment (camcorder, player,...)
There's tons of players for VC-1 in all kinds of devices. As for camcorders, we've been approached about that market plenty of times but fundamentally aren't big believers in interframe codecs for acquisition. The pain of editing AVCHD bears this out I believe :).

Thank you Ben for the video. :eek: :)
I start to download it.

I hope to have right, H264 will win (good luck Ben).

Ben can you make the VC1 encoding with your CinevisionPSE 2.1 ?
When I can get around to it; I've got a series of trips over the next few weeks so I'm not sure when it'd be. But even WME can do pretty good 2-pass VBR interlaced these days with the right registry keys.

Anyone want to define an interlaced test?

I really have no idea where things stack up in PEP versus H.264 implementations for interlaced encoding. It's not something I've done any of for a while. I'm not going to make any predictions here.

[Golgot13]

There's tons of players for VC-1 in all kinds of devices. As for camcorders, we've been approached about that market plenty of times but fundamentally aren't big believers in interframe codecs for acquisition. The pain of editing AVCHD bears this out I believe :).


I don't talk about broadcasting HDTV, DVB receiver, mobil phone, webcam security,...

Yes there are some VC1 device player because it use chipset developped for HDDVD and BD
(sigma design, broadcom,...).

[Golgot13]

Anyone want to define an interlaced test?

I really have no idea where things stack up in PEP versus H.264 implementations for interlaced encoding. It's not something I've done any of for a while.

We test a progressive source so why change?
Majority of BD and HDDVD are in 24P/23.976P, :rolleyes:
why you want to introduce interlace? :confused:
Why you make interlace with progressive source?


I will upload a true film source (with movie grain, 35mm)
at the end of week. This small video will be in 1080p24 (no audio)
in PNG and enough to test the efficient of three codec.

[benwaggoner]

We test a progressive source so why change?
Majority of BD and HDDVD are in 24P/23.976P, :rolleyes:
why you want to introduce interlace? :confused:
Why you make interlace with progressive source?
It was the same shoot, but two sets of cameras; 1080i30 and 35mm film.

The 1080i edit was completed (by a real editor!) some time ago, so I thought it might be of interest to folks as well. This is in parallel to the 1080p24 source, which I'm still working on.

I will upload a true film source (with movie grain, 35mm) at the end of week. This small video will be in 1080p24 (no audio) in PNG and enough to test the efficient of three codec.
Why PNG? Might be better to use Lagarith AVI in YV12 so we don't need to worry about color space conversion issues in comparisons. PNG is just 8-bit, so it wouldn't give us a chance to do anything interesting with 10-bit or 8-bit conversion anyway.

[Dark Shikari]

Why PNG? Might be better to use Lagarith AVI in YV12Lagarith, however, is not available as part of libavcodec and as such is Windows-only.

A better idea would be HuffYUV using FFDshow's HuffYUV encoder.

[benwaggoner]

Lagarith, however, is not available as part of libavcodec and as such is Windows-only.

A better idea would be HuffYUV using FFDshow's HuffYUV encoder.
That can be problematic if someone has the VfW Huffyuv and not ffdshow installed, since it seems like it SHOULD work, but doesn't.

The nice thing about Lagarith is that there's only one implementation. Compression is better as well.

[Golgot13]

PNG is just 8-bit, so it wouldn't give us a chance to do anything interesting with 10-bit or 8-bit conversion anyway.

Just 8bit like video on BD and HDDVD.
We want to compare the encoding efficiency of all codec, not the preprocessing.

If you remember all my posts, you will know that I said PeP have a good preprocessing
and good tool have nice tool to convert video before encoding (like 0bit -> 8bit with dithering filter, ...).

[Golgot13]

A better idea would be HuffYUV using FFDshow's HuffYUV encoder.

Ok for HuffYUV (8bit), I choose 1080p23.976 (not 24p) because it can be played on HDDVD and BD hardwares players.

[benwaggoner]

Just 8bit like video on BD and HDDVD.
We want to compare the encoding efficiency of all codec, not the preprocessing.

If you remember all my posts, you will know that I said PeP have a good preprocessing
and good tool have nice tool to convert video before encoding (like 0bit -> 8bit with dithering filter, ...).
Aren't we agreeing here? I'm suggesting that we use a 4:2:0 codec so preprocessing wouldn't be part of the mix.

[Inventive Software]

For the record, I can't do any encoding, as I dropped my laptop whilst it was running, and I think it killed the hard disk. Moral of the story: don't drop it. Ever.

[Dark Shikari]

The nice thing about Lagarith is that there's only one implementation. Compression is better as well.But if it doesn't work on an operating system that a large number of Doom9 members use, there's no point in using it. Of course, if you want to offer a port of Lagarith to ffmpeg, that'd be great.

[Inventive Software]

Hey, sounds like a project I could actually get done this summer! :D

[akupenguin]

The nice thing about Lagarith is that there's only one implementation.
There's only one implementation of ffvhuff too, some people just call it by the wrong name.

[benwaggoner]

Hey, sounds like a project I could actually get done this summer! :D
That would certainly be welcome. Given how long it's taking everyone to download my 15 GB clip via Torrent, I wouldn't want to give up ANY compression effciency :).

[Dark Shikari]

That would certainly be welcome. Given how long it's taking everyone to download my 15 GB clip via Torrent, I wouldn't want to give up ANY compression effciency :).Try FFV1 or H.264 lossless?

[Inventive Software]

FFV1 isn't exactly fast decoding, and the only H.264 implementation widely used is x264, which doesn't do RGB. ;)

[kolak]

That would certainly be welcome. Given how long it's taking everyone to download my 15 GB clip via Torrent, I wouldn't want to give up ANY compression effciency :).

Ben, use Cineform :)
It will shrink your video at least 5 times and keep very good quality (with 10bit if you need). Everyone can use free Cineform decoder (you have to only pay to encode it :))

Andrew

[benwaggoner]

Ben, use Cineform :)
It will shrink your video at least 5 times and keep very good quality (with 10bit if you need). Everyone can use free Cineform decoder (you have to only pay to encode it :))

Yeah, I considered that as well. I've been a big fan of CineForm for years.

I can't remember why I decided not to use it, actually...

[Inventive Software]

Cineform AFAIK isn't lossless.

[smok3]

cineform is not lossless, also 10bpc is not something we really need for testing codecs imho.

[CruNcher]

visual lossless yeah but then you could also use AVC as intermediate and get even better results and if you go that way then you could also do VC-1 intermediate 50 mbit in both cases should be fine, should easily beat VC-3 tough should fail beating VC-2, but those 3 would definietly be able to beat cineform & canopus HQ easily :) (VC-1,VC-2,AVC)

[kolak]

visual lossless yeah but then you could also use AVC as intermediate and get even better results and if you go that way then you could also do VC-1 intermediate 50 mbit in both cases should be fine, should easily beat VC-3 tough should fail beating VC-2, but those 3 would definietly be able to beat cineform & canopus HQ easily :) (VC-1,VC-2,AVC)

I wouldn't be so sure. Cineform is designed to replace uncompressed format and it does it quite well. It's I frame only, nicely optimized for multicore PCs, 8, 10, 12 (also 4:2:2 and 4:4:4) bit modes, supports metadata- it's more than just a codec.
In it's best mode (12bits, 4:4:4 mode) the quality is better than HDCAM SR (at bitrates around 400Mbit avg. for full HD). You can playback 4K on a decent machine- try to do it with AVC at 200Mbits and 4K resolution :)
AVC, VC-1 solution are more theoretical for now- Cineform is there and it works.

Canopus HQ is also great: extreamly fast, good quality at mostly 200Mbit for full HD, but it's 8bit only and doesn't offer full colour sampling.


Andrew

[kolak]

cineform is not lossless, also 10bpc is not something we really need for testing codecs imho.

No, but quality is a way good enough as a source for encoding at 25Mbits.
You need 10bit (or nicely optimized 8bit- Ben can do it :)) to see how codecs deal with gradients.

Andrew

[Golgot13]

In it's best mode (12bits, 4:4:4 mode) the quality is better than HDCAM SR (at bitrates around 400Mbit avg. for full HD). You can playback 4K on a decent machine- try to do it with AVC at 200Mbits and 4K resolution :)

Hi Andrew,

NHK (and many other) use for UHD AVC codec :) (no VC1 and others).
I'm not sure than Cineform or Canopus codec can support UHD
(7680×4320 P or I in H264 at 128Mbps, audio is 22.2 HE-AAC).

[Golgot13]

I need some help to share the video.
I can put it on special french server (like free.fr)
but I'm not sure all people will can donwload it quickly
(before the server remove the file).

[IgorC]

(7680×4320 P or I in H264 at 128Mbps, audio is 22.2 HE-AAC).
HE-AAC is more efficient than LC-AAC only up to 40-45 kbps per channel.

22.2 is supposed to be achieve at transparent bitrates (> 64 kbps per channel)

[Golgot13]

HE-AAC is more efficient than LC-AAC only up to 40-45 kbps per channel.

22.2 is supposed to be achieve at transparent bitrates (> 64 kbps per channel)

Some people will say that 128Mbps is too low for UHD video,
but it's to show a broadcast process by satellite
(so hardware satellite limitation...).
And it's same for audio 22.2.

[kolak]

Hi Andrew,

NHK (and many other) use for UHD AVC codec :) (no VC1 and others).
I'm not sure than Cineform or Canopus codec can support UHD
(7680×4320 P or I in H264 at 128Mbps, audio is 22.2 HE-AAC).

Cineform supports any resolution. Have anyone tried to playback 2K AVC at 200Mbit?
If I will have some time I'll make a test with AVC and 4K to see playback performance.

Andrew

[guada2]

Hello Golgot13 & IgorC,

Just a question:
Why use HE-AAC instead of HD-AAC?

[CruNcher]

@kolak
i have some 2k sources here to test most blue screen stuff but also some nice other scenes but no 4k unfortunately but nevertheless 4k is still rarely used if @ all in DI currently :P
but you also have to use a high performance decoder for that like CoreAVC if you would like to get nice results and you should start low @ the bottom without cabac as this would let the decoding speed suffer extremely in this intermediate scenario. I guess with CoreAVC and low profile overhead it should be no problem to reach the same decoding speed as Cineform with H.264 :)

[shon3i]

Hello Golgot13 & IgorC,

Just a question:
Why use HE-AAC instead of HD-AAC?
There is no such a ting as "HD-AAC" in MPEG-AAC standard, only HE-AAC and LC-AAC and some other which not interest now.

HE-AAC is more efficient than LC-AAC only up to 80-96kbps per channel, and for example in classic 5.1 multichannel encoding, HE-AAC should be used up to 256kbps.

[guada2]

@shon3i
Thank you for this clarification

Could you believe that this format should be used for pure audio?

[Golgot13]

Hi all,

I have a little problem to share the video on the web.
I must to use a Lossless codec...
The video will be on french website (like http://dl.free.fr ).

[kolak]

@kolak
i have some 2k sources here to test most blue screen stuff but also some nice other scenes but no 4k unfortunately but nevertheless 4k is still rarely used if @ all in DI currently :P
but you also have to use a high performance decoder for that like CoreAVC if you would like to get nice results and you should start low @ the bottom without cabac as this would let the decoding speed suffer extremely in this intermediate scenario. I guess with CoreAVC and low profile overhead it should be no problem to reach the same decoding speed as Cineform with H.264 :)

I've done some small test and 2K (I frames only) at 200Mbit was unplayable at all on my 8 core machine (neither on PS3 :) ) :(

Andrew

[ocal5]

NHK (and many other) use for UHD AVC codec :) (no VC1 and others).
I'm not sure than Cineform or Canopus codec can support UHD
(7680×4320 P or I in H264 at 128Mbps, audio is 22.2 HE-AAC).

NHK is using 4 // encoders to do that ; image is split. ( As far as I know, since I'm unable to find this information. Online documents say "1 encoder" )

[Golgot13]

NHK is using 4 // encoders to do that ; image is split. ( As far as I know, since I'm unable to find this information. Online documents say "1 encoder" )

Yes, it's true I saw many live demo, because there are no solution to decode it in realtime ;)
The problem are from chipset and CPU's power...

It's like H264 High422, there are no DVB feed in HD H264 which use it
because there's not solution (but it will change NTT chipset are available since May)