View Full Version : [HD-DVD Challenge] MPEG2, VC-1 and H264 with real uncompressed source movie
foxyshadis
13th October 2006, 09:26
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
13th October 2006, 20:51
Thanks Foxyshadis.
So... the first post of this thread needs a litle editing;)
drmpeg
14th October 2006, 05:22
@ 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
14th October 2006, 06:19
@foxyshadis
though I'm not sure,
doesn't every unit related to 'bitrate' mean powers-of-1000?
foxyshadis
14th October 2006, 13:48
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
14th October 2006, 20:45
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
17th October 2006, 21:21
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
19th October 2006, 01:09
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
19th October 2006, 04:47
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
19th October 2006, 10:49
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
19th October 2006, 15:35
...
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
23rd October 2006, 14:55
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
24th October 2006, 16:41
... 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
25th October 2006, 20:47
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
26th October 2006, 02:12
unfortunaly x264 don't respect the vbv buffer in multipass mode ...
zambelli
26th October 2006, 03:24
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
26th October 2006, 08:16
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
26th October 2006, 11:08
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
26th October 2006, 11:14
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
26th October 2006, 23:35
I'll ask again: why is VC-1 buffer size 14745 kbits, while H.264 buffer size is 30000 kbits?
guada 2
27th October 2006, 00:04
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
27th October 2006, 02:29
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
27th October 2006, 05:36
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
27th October 2006, 05:43
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
27th October 2006, 06:17
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
27th October 2006, 07:13
Anyone got a tool to check buffer use yet?
Tektronix.. :) (http://www.tek.com/products/video_test/mts4ea/index.html)
Sagittaire
27th October 2006, 09:50
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
27th October 2006, 10:13
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
27th October 2006, 10:56
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
27th October 2006, 11:07
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
27th October 2006, 13:30
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
28th October 2006, 05:40
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
28th October 2006, 11:55
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
28th October 2006, 13:24
I don't know, but H264 size max is 32182 Kbits.where do you have that info from?
Sergey A. Sablin
29th October 2006, 10:11
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
29th October 2006, 14:03
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
29th October 2006, 14:39
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
31st October 2006, 15:09
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
31st October 2006, 15:18
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
1st November 2006, 10:43
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
1st November 2006, 10:50
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
1st November 2006, 21:52
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
2nd November 2006, 00:21
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
2nd November 2006, 17:16
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
4th November 2006, 02:49
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
4th November 2006, 05:17
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
4th November 2006, 10:48
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
4th November 2006, 23:15
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
29th November 2006, 19:43
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
29th November 2006, 20:38
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
29th November 2006, 23:28
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
30th November 2006, 22:47
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
1st December 2006, 19:40
Related topic. http://forum.doom9.org/showthread.php?p=908902#post908902
It is about new metrics. Maybe it's good as SSIM.
trbarry
31st December 2006, 13:20
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
31st December 2006, 14:15
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
How about to compare mpeg2/avc/vc1 encoded in same tool as CineVision vs x264 (pro tool vs free encoder) ?
Sagittaire
24th June 2007, 20:03
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
25th June 2007, 12:47
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
26th June 2007, 04:59
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
28th June 2007, 20:45
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
1st July 2007, 04:41
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
1st July 2007, 04:53
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.
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).
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
1st July 2007, 17:31
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
1st July 2007, 19:04
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
1st July 2007, 20:52
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
1st July 2007, 20:54
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
1st July 2007, 21:01
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
2nd July 2007, 17:07
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
5th July 2007, 12:35
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
6th July 2007, 02:08
@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
6th July 2007, 07:02
@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
6th July 2007, 07:17
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
6th July 2007, 07:47
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
6th July 2007, 11:27
@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
6th July 2007, 12:16
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
6th July 2007, 15:34
... 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
6th July 2007, 15:39
... 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
6th July 2007, 15:55
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
6th July 2007, 16:05
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
6th July 2007, 16:06
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
6th July 2007, 16:11
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
6th July 2007, 16:17
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
6th July 2007, 16:54
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
6th July 2007, 17:03
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
6th July 2007, 17:41
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
6th July 2007, 18:08
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
6th July 2007, 21:39
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
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
7th July 2007, 00:28
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
7th July 2007, 00:44
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
7th July 2007, 01:13
... 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
7th July 2007, 03:53
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
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.
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
8th July 2007, 01:13
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
8th July 2007, 05:46
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
8th July 2007, 06:19
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
8th July 2007, 12:08
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
8th July 2007, 12:30
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
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...
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
9th July 2007, 02:48
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
9th July 2007, 03:01
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
10th July 2007, 03:25
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
12th July 2007, 10:05
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
13th July 2007, 03:22
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
30th July 2007, 11:08
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
30th July 2007, 16:47
How about Encoding Time, Decoding Complexity,Visual Compare of Key Sequences and the Settings used ?
Sagittaire
30th July 2007, 20:45
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
31st July 2007, 12:49
[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
31st July 2007, 15:01
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
31st July 2007, 15:28
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
31st July 2007, 16:11
Neither Ateme nor Mainconcept are being used at the major facilities.
Golgot13
31st July 2007, 17:07
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
31st July 2007, 17:27
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
31st July 2007, 17:46
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
31st July 2007, 18:12
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
31st July 2007, 18:15
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
31st July 2007, 19:52
[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
31st July 2007, 19:54
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
31st July 2007, 19:56
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
31st July 2007, 20:03
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
31st July 2007, 20:44
@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
31st July 2007, 21:01
...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
31st July 2007, 21:30
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
31st July 2007, 21:37
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
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
31st July 2007, 22:22
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
31st July 2007, 22:55
@ 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
31st July 2007, 23:05
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
31st July 2007, 23:10
@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
1st August 2007, 01:20
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
1st August 2007, 01:38
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
1st August 2007, 15:13
@diogen: http://forum.doom9.org/showthread.php?t=128498
Sagittaire
1st August 2007, 15:53
@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
2nd August 2007, 08:30
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
2nd August 2007, 09:27
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
2nd August 2007, 09:48
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
2nd August 2007, 09:48
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
2nd August 2007, 10:37
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
2nd August 2007, 11:02
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
2nd August 2007, 12:41
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
2nd August 2007, 12:53
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
2nd August 2007, 18:44
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
2nd August 2007, 20:01
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
2nd August 2007, 22:36
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
2nd August 2007, 22:44
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
3rd August 2007, 02:08
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
3rd August 2007, 02:39
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
5th April 2008, 11:19
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
5th April 2008, 18:21
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
5th April 2008, 18:53
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
9th April 2008, 18:47
since this thread is already 21 pages long i suggest to start a new one or ppl will get lost reading it...
Sagittaire
9th April 2008, 21:12
Well where is the 1080p source ... ???
benwaggoner
10th April 2008, 00:52
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
10th April 2008, 14:42
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
10th April 2008, 19:45
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
15th April 2008, 20:37
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
16th April 2008, 01:25
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
16th April 2008, 01:35
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
16th April 2008, 01:57
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
16th April 2008, 02:07
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
16th April 2008, 02:14
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
16th April 2008, 04:47
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
16th April 2008, 16:28
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
16th April 2008, 17:17
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
16th April 2008, 19:01
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
17th April 2008, 19:43
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
18th April 2008, 02:45
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
18th April 2008, 12:23
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
18th April 2008, 17:42
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
23rd April 2008, 02:22
Speaking of which, here's my presentations from NAB:
http://www.on10.net/blogs/benwagg/22040/
benwaggoner
24th April 2008, 07:33
...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
24th April 2008, 16:26
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
25th April 2008, 05:15
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
25th April 2008, 05:27
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
25th April 2008, 07:30
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
25th April 2008, 07:38
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
25th April 2008, 07:43
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
25th April 2008, 07:43
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
25th April 2008, 07:44
VBR WMA Pro 10 stereo @ 48 Kbps outperforms AC-3 stereo at CR 160 Kbps.
Really? Link to public test?
benwaggoner
25th April 2008, 07:45
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
25th April 2008, 07:49
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
25th April 2008, 07:51
No, that's data coming internally, and my own anecdotal experience.
Internally? hm....
Thank you for information.
Good bye.
Dark Shikari
25th April 2008, 07:57
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
25th April 2008, 08:01
I open this topic in HA forum. Let's see what audio professionals say.
http://www.hydrogenaudio.org/forums/index.php?showtopic=62889
Golgot13
25th April 2008, 09:59
@ 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
25th April 2008, 12:07
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
25th April 2008, 16:14
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
25th April 2008, 16:20
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
25th April 2008, 16:28
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
25th April 2008, 17:07
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
25th April 2008, 18:55
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
25th April 2008, 19:02
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
25th April 2008, 19:31
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
25th April 2008, 19:32
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
25th April 2008, 21:41
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
25th April 2008, 22:14
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
25th April 2008, 22:38
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
25th April 2008, 22:41
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
25th April 2008, 22:43
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
25th April 2008, 22:43
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
25th April 2008, 22:52
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
25th April 2008, 22:54
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
25th April 2008, 22:56
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
25th April 2008, 23:00
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
25th April 2008, 23:08
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
25th April 2008, 23:16
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
25th April 2008, 23:18
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
25th April 2008, 23:20
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
26th April 2008, 01:01
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
26th April 2008, 03:45
I named the movie at the bottom of the post :rolleyes:
300
THIS IS ...... Yahoo!!!
Sorry, I couldn't deny
MarcioAB
26th April 2008, 16:35
...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
26th April 2008, 18:11
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
26th April 2008, 22:23
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
27th April 2008, 05:13
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
27th April 2008, 10:18
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
27th April 2008, 15:39
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
27th April 2008, 16:30
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
27th April 2008, 17:01
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
27th April 2008, 17:17
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
27th April 2008, 22:26
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
27th April 2008, 22:35
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
27th April 2008, 22:57
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
28th April 2008, 00:08
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
28th April 2008, 01:27
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
28th April 2008, 01:32
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
28th April 2008, 02:49
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
28th April 2008, 03:07
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
28th April 2008, 03:20
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
28th April 2008, 04:50
I see myself asking how HC would fair in the ATSC encoding market........
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
5th May 2008, 23:10
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
5th May 2008, 23:13
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
5th May 2008, 23:20
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
5th May 2008, 23:35
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
6th May 2008, 01:14
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
6th May 2008, 07:50
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
6th May 2008, 13:08
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
6th May 2008, 16:24
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
6th May 2008, 18:13
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
7th May 2008, 14:41
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
7th May 2008, 18:17
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
7th May 2008, 18:25
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
7th May 2008, 18:35
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
7th May 2008, 18:47
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
7th May 2008, 18:50
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
7th May 2008, 18:51
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.
vBulletin® v3.8.4, Copyright ©2000-2009, Jelsoft Enterprises Ltd.