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

[Dark Shikari]

Dark Shikari : quiet down. Read benwaggoner carefully before answering. He said PEP was compared to "several Blu-ray H.264 encoders", and that it was deemed better than those encoders.

Never did he say VC1 > H264. He says PEP > professionnal Bluray encoders, which wouldn't surprise me at all.I haven't seen that in my experience either though; on the one hand it wouldn't surprise me, but the few "VC-1 vs H.264" comparisons between movies available in both formats were... less than impressive... for VC-1. In particular, it looked like someone ran a blur filter over the grain of the video, while the H.264 versions retained their sharpness.

[Golgot13]

That's a quote from the director of a recent Oscar winning film when a neutral studio showed him encodes of that film produced by PEP and several Blu-ray H.264 encoders. After the demo, he mandated that all his films be encoded with VC-1 for Blu-ray.

MS have good power of persuasion, and everything is nice, eg on your compressionist Tuesday
On Wynn Palace (with Golf in Las vegas) with good food (?)....

I can not judge anything with this comment:
- He win a Oscar because he used PEP, no...
- several BluRay H264 encoder: which ? Preset ? ...
And you know that many (and more I think) compressionist use default parameter to encode the movie.
PEP is good tool, to my mind, he have a good video preprocessing but a bad codec format (VC1).

If you can provide the video I will make the test (H264 encoding) for this guy, but not nice hotel and good food with me...



I'll see if I can get permission to share the director's name; no promises there.


I don't need. I want only some video to try to prouve you that H264 is the best codec.
I need the video source (from you or Oscar winner)


It's also the broad consensus of Hollywood compressionists, which is why we're seeing the use of VC-1 on Blu-ray going up substantially now that the format war is over. There's only one studio left who doesn't have a substantial number of VC-1 titles in production right now.

No sure, may be if you give for free PEP or make many presentation (with your MS persuasion's power)
at video director, productor, realisator,... of movie who order only VC1 on their BD title....


Last I need the video source use for DVDA test to make for you the H264 encoding.
And all people on AVSForum and Doom9 will see and give their conclusion, on parallel at PSNR-SSIM measure...

[Dark Shikari]

Here's an example of the "incredible" grain retention power of VC-1.

For reference, here's a crop of a keyframe from the source, which is probably good enough quality to use as a reference:

http://img178.imageshack.us/img178/1286/keyframetb6.png

An interframe:

http://img518.imageshack.us/img518/7914/vc1de9.png

Seriously, that's just awful.

(Source: 300, VC-1)

[Golgot13]

Never did he say VC1 > H264. He says PEP > professionnal Bluray encoders, which wouldn't surprise me at all.


Yes, the video preprocessing of PEP is really good.

[benwaggoner]

I haven't seen that in my experience either though; on the one hand it wouldn't surprise me, but the few "VC-1 vs H.264" comparisons between movies available in both formats were... less than impressive... for VC-1. In particular, it looked like someone ran a blur filter over the grain of the video, while the H.264 versions retained their sharpness.
Links?

Also, were they of encoded of the same source encoded with the same overall parameters?

[Dark Shikari]

Links?

Also, were they of encoded of the same source encoded with the same overall parameters?I don't have them, I saw them a while ago. It was a link b0bor gave me a while back, I think.

I have no idea about parameters; that doesn't even make sense, since VC-1 and H.264 take totally different parameters. I'm not the studios, so I can't say what parameters/etc they're using.

[benwaggoner]

I have no idea about parameters; that doesn't even make sense, since VC-1 and H.264 take totally different parameters. I'm not the studios, so I can't say what parameters/etc they're using.
I mean bitrate and such. If it's comparing a 20 Mbps Blu-ray encode to a 10 Mbps VC-1 encode...

[Dark Shikari]

I mean bitrate and such. If it's comparing a 20 Mbps Blu-ray encode to a 10 Mbps VC-1 encode...Ah, that would be true in the case of an HD DVD vs Blu-ray comparison.

Either way, given the screenshot above, the performance of VC-1 for grain retention, at least, can be pretty embarrassing ;)

[benwaggoner]

Either way, given the screenshot above, the performance of VC-1 for grain retention, at least, can be pretty embarrassing ;)
Without identifying the movie, it's hard to say much about it at all. We don't know bitrates, source, which version of the encoder...

[Dark Shikari]

Without identifying the movie, it's hard to say much about it at all. We don't know bitrates, source, which version of the encoder...I named the movie at the bottom of the post :rolleyes:

300

[Thunderbolt8]

according to avsforums the bitrate for the '300' videotrack is 16.80 (1:56:32 playtime, 2.40 AR)
and from my remux of that movie I know that the size of the videotrack is ~13 GB

[Dark Shikari]

according to avsforums the bitrate for the '300' videotrack is 16.80 (1:56:32 playtime, 2.40 AR)
and from my remux of that movie I know that the size of the videotrack is ~13 GBYes, that's about right. Though I don't have a VC-1 stream analyzer, I suspect the scene where that screenshot came from hit the bitrate limit.

[Sagittaire]

I make actualy test with Casino Royal (High Quality Source) with high grain/noise level at 6.9 Mbps (BD9 encoding). All the H264 encoder (highest possible quality level) outperform really VC1 (from pep/pse or SDK) for grain retention and all the other quality sector (blocking, ringing, banding, texture quality, detail level ... etc).

Here little sample with really high quality level at 6.9 Mbps for 1080p and 144 min movie:

High motion with strong grain:
http://jfl1974.free.fr/upload/Casino_MCCLI_BD9-005.mkv

Really High Motion:
http://jfl1974.free.fr/upload/Casino_MCCLI_BD9-014.mkv

Slow Motion with fine grain:
http://jfl1974.free.fr/upload/Casino_MCCLI_BD9-017.mkv


I make the same external high quality pre-process for all codec (dithering, dark noise filtering). I use cinevisionPSE at highest possible quality level with this xml quality profil:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/DigitalMedia/Codecs/2007/05/24/ParallelEncoderProject">
<ProjectSettings>
<Bitrate>6900</Bitrate>
<BufferSize>3750000</BufferSize>
<BufferSizeEnum>5</BufferSizeEnum>
<ClosedCaptionsPresent>false</ClosedCaptionsPresent>
<Comment/>
<DisplayHeight>1080</DisplayHeight>
<DisplayWidth>1920</DisplayWidth>
<EncodedFrameRate>23.976</EncodedFrameRate>
<EncodedFrameRateEnum>1</EncodedFrameRateEnum>
<EncodingHeight>1080</EncodingHeight>
<EncodingMode>1</EncodingMode>
<EncodingWidth>1920</EncodingWidth>
<InterlaceMode>0</InterlaceMode>
<LegacyDQuant>false</LegacyDQuant>
<OverlapDeblocking>false</OverlapDeblocking>
<PeakBitrate>20000</PeakBitrate>
<ProjectName>Project1</ProjectName>
<PublishedFileURL>D:\Mes dossiers\PSEViewer\Projects\Project1.vc1</PublishedFileURL>
<SegmentFilesDirectory>D:\Mes dossiers\PSEViewer\Projects</SegmentFilesDirectory>
<Segments>1</Segments>
<SourceColorSpace>1</SourceColorSpace>
<SourceFrameRate>23.976</SourceFrameRate>
<SourceFrameRateEnum>1</SourceFrameRateEnum>
<SourceHeight>1080</SourceHeight>
<SourceMarkIn>0</SourceMarkIn>
<SourceMarkOut>207442</SourceMarkOut>
<SourceTopFieldFirst>true</SourceTopFieldFirst>
<SourceWidth>1920</SourceWidth>
<StartingTelecinePhase>0</StartingTelecinePhase>
<ColorFormat>
<Off>
</Off>
</ColorFormat>
<LetterboxPillarbox>
<LetterboxManual>
<Bottom>939</Bottom>
<MarkIn>86400</MarkIn>
<MarkOut>86400</MarkOut>
<Top>140</Top>
</LetterboxManual>
</LetterboxPillarbox>
<PixelAspect>
<PixelAspectRatioIndex>1</PixelAspectRatioIndex>
</PixelAspect>
<SourceFrameZeroTimecode>
<SMPTEHours>0</SMPTEHours>
<SMPTEMinutes>0</SMPTEMinutes>
<SMPTESeconds>0</SMPTESeconds>
<SMPTEFrames>0</SMPTEFrames>
</SourceFrameZeroTimecode>
<Sources>
<Source>G:\azerty.yuv</Source>
</Sources>
<UIData>
<RecentPublishedFileURL/>
</UIData>
</ProjectSettings>
<FirstAndSecondPassSettings>
<AdaptiveDeadZone>true</AdaptiveDeadZone>
<CommonSettings>
<AdaptiveBFramePositioning>true</AdaptiveBFramePositioning>
<BFrames>1</BFrames>
<GOPLength>24</GOPLength>
<InLoopDeblocking>true</InLoopDeblocking>
<InterBlockDeadZone>1.50</InterBlockDeadZone>
<IntraBlockDeadZone>1.20</IntraBlockDeadZone>
<KeyFramePulseReduction>1</KeyFramePulseReduction>
<MaxLuma>255</MaxLuma>
<MedianFilterSmooth>0</MedianFilterSmooth>
<MedianFilterTextured>0</MedianFilterTextured>
<MinLuma>0</MinLuma>
<SceneChangeDetection>true</SceneChangeDetection>
<DarkRegionDenoise>
<Off>
</Off>
</DarkRegionDenoise>
<Denoise>
<Off>
</Off>
</Denoise>
</CommonSettings>
<Quantization>
<On>
<BDeltaQP>1.0</BDeltaQP>
<BFrameAggressiveBitUsage>2</BFrameAggressiveBitUsage>
<DarkRegionBias>0</DarkRegionBias>
<DarkRegionThreshold>8</DarkRegionThreshold>
<MinEncodeQP>1.0</MinEncodeQP>
<PFrameAggressiveBitUsage>1</PFrameAggressiveBitUsage>
</On>
</Quantization>
</FirstAndSecondPassSettings>
<FirstPassSettings>
<ChromaSearch>0</ChromaSearch>
<EncoderComplexity>2</EncoderComplexity>
<MotionMatch>0</MotionMatch>
<MotionSearchRange>4</MotionSearchRange>
<ThreadCount>0</ThreadCount>
</FirstPassSettings>
<SecondPassSettings>
<ChromaSearch>2</ChromaSearch>
<EncoderComplexity>4</EncoderComplexity>
<MotionMatch>2</MotionMatch>
<MotionSearchRange>4</MotionSearchRange>
<ThreadCount>0</ThreadCount>
</SecondPassSettings>
<ReEncodeSettings>
</ReEncodeSettings>
</Project>


IMO make internal test is not a good idea: it's by definition no objective test.

[IgorC]

I named the movie at the bottom of the post :rolleyes:

300

THIS IS ...... Yahoo!!!

Sorry, I couldn't deny

[MarcioAB]

...and here's a torrent of an ATSC-compliant encode of the 1080i source, for a better example of what a final clip looks like.

Great image, thank you.

HD Mpeg2 @ 0.31 BPP - at least for me, that is impressive for Mpeg2. (19.45 Mbps for the ones that prefer bitrate)

Ben, as we know, I use BPP because it's nothing more than an easier form to say the final compression index relative the raw YV12 (12 as 12 BPP), that is the starting point to compress. It seems reasonable quality "gravitates" around that range of compression indexes (or BPP).

The "Lady" was compressed almost 40x ( 12 : 0.31 ) relative it's YV12 raw source.

Regard Sagittaire "Cassino's", that is a 0.14 BPP HD encode is almost 90x compressed relative it's YV12 source.

I think for that level of extremely high compression H264 is unbeatable. The question may be: reducing a little the compression (let's say 50x or 0.24 BPP), how is the behavior between H264 and VC1 ?
I say that because, we may need to specify the targets: download or physical media.

Thanks

[benwaggoner]

Ben, as we know, I use BPP because it's nothing more than an easier form to say the final compression index relative the raw YV12 (12 as 12 BPP), that is the starting point to compress. It seems reasonable quality "gravitates" around that range of compression indexes (or BPP).
For similar content, sure. But there can be a huge difference between fast-shutter sports and a nice dreamy DNR'ed 35mm film source. I'd say the BPP ratio between easiest and hardest real-world content is maybe 3:1. But yes, it's certainly one of the more useful numbers to have.

Regard Sagittaire "Cassino's", that is a 0.14 BPP HD encode is almost 90x compressed relative it's YV12 source.

I think for that level of extremely high compression H264 is unbeatable. The question may be: reducing a little the compression (let's say 50x or 0.24 BPP), how is the behavior between H264 and VC1 ?
I say that because, we may need to specify the targets: download or physical media.
There's certainly no argument that x264 in high profile can outperform any VC-1 implementation I've seen when the challenge is "lowest bitrate without visually unappealing artifacts."

One thing that makes it hard to compare H.264 and VC-1 in the abstract is that there are different implementations used in different markets; no one is using x264 for optical disc production. So it's really about comparing the best readily available implementation of each codec for each scenario.

Another thing that complicates comparisons at lower bitrates is that H.264 decoders generally don't have postprocessing, while VC-1 decoders do, so is the appropriate comparison point looking at the native decode (codec to codec) or what actually gets displayed (experience to experience).

But overall, I'd say:

H.264 does well when lowest bitrate without distracting artifacts is the goal.

VC-1 does well when quality/MIPS in software decoders is the goal (VC-1 Main Profile outperforms H.264 baseline profile).

VC-1 does well at moderate bitrates when texture and grain retention is the goal.

Both converge at reasonably high data rates.

And, one thing we can't ever forget (and which I'm constantly and painfully reminded of in my various projects), source quality and preprocessing best practices are overwhelmingly more important than codec! Almost all the bad compressed video out there isn't bad due to codec implementation, but to errors earlier in the workflow or in the use of the codec.

When I'm working with customers on challenging projects, or doing challenging projects of my own, I'd say time goes 80% to source and preprocessing issues, and only 20% to codec tuning.

[Sagittaire]

One thing that makes it hard to compare H.264 and VC-1 in the abstract is that there are different implementations used in different markets; no one is using x264 for optical disc production. So it's really about comparing the best readily available implementation of each codec for each scenario.

Mainconcept/Elecard SDK build produce similar result to x264. Professional product like Cinevision use Mainconcept/Elecard SDK build for optical disc production. I make previous Casino encoding with Mainconcept/Elecard build and the grain retention is really good at 7 Mbps. Mainconcept/Elecard outperform VC1 in this case.


Another thing that complicates comparisons at lower bitrates is that H.264 decoders generally don't have postprocessing, while VC-1 decoders do, so is the appropriate comparison point looking at the native decode (codec to codec) or what actually gets displayed (experience to experience).

Bluray don't use particular post-process for VC1. Moreover if particular post-process can improve visual quality for VC1 then the same post-process can certainly improve quality for the other codec.


H.264 does well when lowest bitrate without distracting artifacts is the goal.

Yes for BD9 for example. Or for really long movie on BD25.


VC-1 does well at moderate bitrates when texture and grain retention is the goal.

Yes. VC1 is a really good codec for BD25 encoding in 99% of the case.


Both converge at reasonably high data rates.

Yes. IMO H264 and VC1 are simply useless for BD50.


And, one thing we can't ever forget (and which I'm constantly and painfully reminded of in my various projects), source quality and preprocessing best practices are overwhelmingly more important than codec! Almost all the bad compressed video out there isn't bad due to codec implementation, but to errors earlier in the workflow or in the use of the codec. When I'm working with customers on challenging projects, or doing challenging projects of my own, I'd say time goes 80% to source and preprocessing issues, and only 20% to codec tuning.

Certainely true. But good pre-process will be the same for VC1, H264 and MPEG2. Don't change anything in this case for the codec problematic.

[benwaggoner]

Mainconcept/Elecard SDK build produce similar result to x264. Professional product like Cinevision use Mainconcept/Elecard SDK build for optical disc production. I make previous Casino encoding with Mainconcept/Elecard build and the grain retention is really good at 7 Mbps. Mainconcept/Elecard outperform VC1 in this case.
But CineVision non-PSE isn't used for any major studio Blu-ray titles that I'm aware of. It's the Sony, Toshiba, and CinemaCraft that I hear people evaluating.

Bluray don't use particular post-process for VC1. Moreover if particular post-process can improve visual quality for VC1 then the same post-process can certainly improve quality for the other codec.
Yeah, in WMP postprocessing is generally applied only for sub 1 Mbps content, and I think only SD or lower resolutions. It's not at all relevant to HD or higher bitrates.

Certainely true. But good pre-process will be the same for VC1, H264 and MPEG2. Don't change anything in this case for the codec problematic.
Agreed. My point is that most of the hard work, and most of where good quality comes from, is upstream of the codec. When we're at the point where differences in codec implementation make a difference in final quality, we're all happy since that means all the hard stuff got done right in the first place.

With problematic source, AVISynth + MPEG-1 handily beats a QuickTime Player Pro export to H.264 :).

[Sagittaire]

But CineVision non-PSE isn't used for any major studio Blu-ray titles that I'm aware of. It's the Sony, Toshiba, and CinemaCraft that I hear people evaluating.

Major studio are not representative of the complet market:

1) Major studio use BD50 in most case. H264 will always produce high quality encoding at 30 Mbps and more, even with bad H264 implementation.

2) Sony, Toshiba and Cinecraft use certainely intensive parallel encoding and not Cinevision.

I don't test Sony, Toshiba and Cinecraft implementation but if VC1 from CinevisionPSE produce better quality it's perhaps the time to change their implementation ... :devil:

[Golgot13]

But CineVision non-PSE isn't used for any major studio Blu-ray titles that I'm aware of.


Not agree...



It's the Sony, Toshiba, and CinemaCraft that I hear people evaluating.


So you compare H264 by "hear people evaluating"!!!!
You don't make like many people on this forum the test yourself ?
I'm sure you hear this, many month (year) ago.
Did you see last update of Sony encoder (available at NAB)?
Do you know Thomson encoder (Nexcode), KDDi, ... ?



Last, this discussion change anything about this thread codec comparison:
we compare the codec by the best version of each codec.

VC1 can not be better than H264 (first round of test)...

Give a video source, Ben, and we will see (I can useif you want some others H264 encoder)

[Inventive Software]

Major studio are not representative of the complet market:

1) Major studio use BD50 in most case. H264 will always produce high quality encoding at 30 Mbps and more, even with bad H264 implementation.


Quicktime (especially on Windows) begs to differ. ;)

[benwaggoner]

Not agree...
Can you name some studio titles that did you CineVision's H.264 or VC-1 implementations? Note that non-PSE is Main Concept's VC-1 as well.

So you compare H264 by "hear people evaluating"!!!!
You don't make like many people on this forum the test yourself ?
I'm sure you hear this, many month (year) ago.
Did you see last update of Sony encoder (available at NAB)?
Do you know Thomson encoder (Nexcode), KDDi, ... ?
I'm sharing info from the community of Hollywood-based professional compressionists doing work for the major studios. They spend more time with all these tools than I ever could, with more real-world projects.

[Golgot13]

Can you name some studio titles that did you CineVision's H.264 or VC-1 implementations? Note that non-PSE is Main Concept's VC-1 as well.


I can not like you to give some name...
But I can say:
BlockBuster movie from USA sell in France with a hero who drive a moto...



I'm sharing info from the community of Hollywood-based professional compressionists doing work for the major studios. They spend more time with all these tools than I ever could, with more real-world projects.


What do you want to defend:
VC1 from PeP is better than bad implementation use by some studio?


This thread is to compare your codec, VC1, and H264.
Give your video...

[MarcioAB]

H264 will always produce high quality encoding at 30 Mbps and more, even with bad H264 implementation.

Still on the contextualization of the HD scenario: At +30 Mbps ( or +0.6 BPP ) ALL codecs are the same (or no ?). Example is recent Ben's "Lady Washington" Mpeg2 @ 0.31 BPP. It's almost perfect.

One scenario is for HD on optical media (level of compression beyond +0.6 BPP). I wonder based on what one can decide which codec to use at that level of compression ... price ? legacy experience ?

Another scenario is for HD video download, SD video conferencing, SD limited devices (where compression level is below 0.14 BPP) ... I think this is the scenario we are interested here, don't ?

By the way, the "Lady Washington" encode is right in the middle of those edges scenarios.

Scenario contextualization is key to compare anything.

[Inventive Software]

One scene in that encode where far more bits were needed was right near the end with the camera pointing at the sea and the sun shining on it. Noticable blocks. ;)

[MarcioAB]

One scene in that encode where far more bits were needed was right near the end with the camera pointing at the sea and the sun shining on it. Noticable blocks. ;)

Hum ... better eyes than mine. Any way, that's at 0.31 BPP encode. How the "blockage" should be at 0.75 BPP for optical BD storage ? And how should it be at 0.14 ? The 2 edges contexts.

[CruNcher]

Still on the contextualization of the HD scenario: At +30 Mbps ( or +0.6 BPP ) ALL codecs are the same (or no ?). Example is recent Ben's "Lady Washington" Mpeg2 @ 0.31 BPP. It's almost perfect.

One scenario is for HD on optical media (level of compression beyond +0.6 BPP). I wonder based on what one can decide which codec to use at that level of compression ... price ? legacy experience ?

Another scenario is for HD video download, SD video conferencing, SD limited devices (where compression level is below 0.14 BPP) ... I think this is the scenario we are interested here, don't ?

By the way, the "Lady Washington" encode is right in the middle of those edges scenarios.

Scenario contextualization is key to compare anything.

I almost can guarantee you Ben used Rhozet Carbon Encoders Mpeg-2 Engine (Mainconcept) for this 1080i encode :)

One scene in that encode where far more bits were needed was right near the end with the camera pointing at the sea and the sun shining on it. Noticable blocks. ;)

yeah chaotic movement will allways be problematic especialy for Mpeg-2 with AVC it got much better even @ low bitrates tough VC-1 seems to still have problems with it (in low bitrates)

[benwaggoner]

Still on the contextualization of the HD scenario: At +30 Mbps ( or +0.6 BPP ) ALL codecs are the same (or no ?). Example is recent Ben's "Lady Washington" Mpeg2 @ 0.31 BPP. It's almost perfect.
Really? I think it's a lot better than most ATSC content out there, but it definitely shows blocking artifacts in some shots, particularly when there's lots of random motion in the water, or very fast pans.

Scenario contextualization is key to compare anything.
QFT!

[benwaggoner]

I almost can guarantee you Ben used Rhozet Carbon Encoders Mpeg-2 Engine (Mainconcept) for this 1080i encode :)
It was Carbon. but Carbon has always used the Canopus MPEG-2 encoder, which I've preferred for years. I haven't tried the latest Main Concept version with MPEG-2, but a couple of years ago when I was doing a lot of ATSC, the Main Concept rate control at 1080i kept exceeding the VBV even at max ATSC bitrates.

[MarcioAB]

Really?

I displayed the film in an 42-inch HD-ready (1366x768) to my family (wife and teenagers) and some friends and they unanimously give that comment. They know about blocky film because we have lots of 0.14 BPP H264 HD-content and we know how high compressed H264 behaves on dark scenes. By the way, the begining of the "Lady Washington" is really dark and it's far away from my reference of blocky under high compressed content.
The most perceivable compression-effect in a few points to me is a kind of "heat-effect" around the ship (the same one we see on the road under sun). I think it's relative to bad Motion Estimation. By the way, I do not see that issue on H264.

[Dark Shikari]

That isn't surprising; VC-1 is known for blocking issues. Example from 300 (link goes to full):

http://img186.imageshack.us/img186/2748/vc1failqv3.png (http://shrani.si/f/h/Tn/2c57NLIq/295.png)

[CruNcher]

oops yeah sorry Canopus Encoder :) not Mainconcept , this reminds me that also a Tech shootout between Canopus, Cinemacraft and Mainconcept and as OSS FFMPEGS Mpeg-2 Encoder could be quiet interesting :D
Tough very strict Broadcast or Standalone Encoding always was a OSS problem (no matter which Technology used) allot of work and special care is required compared to non restricted encoding in every field (especially rate control,interlacing and error correction) and yeah the visual results in that case for Canopus Encoder speak for themselves tough im sure also the other evolved and DivX/Mainconcept/Elecard can hold against it same as Cinemacraft nowdays. About FFMPEG im not so sure i guess Sagittaire could answer here if it could holdup in a restricted environment with it's ratecontroll nowdays, at least his last HD-DVD restricted encoding results seemed very good and promising in that regard :).

[Inventive Software]

I see myself asking how HC would fair in the ATSC encoding market........

[IgorC]

I make the same external high quality pre-process for all codec (dithering, dark noise filtering). I use cinevisionPSE at highest possible quality level with this xml quality profil:


What version of cinevisonPSE was it? Is there available version of cinevisionPSE to try its pre-process?

[Golgot13]

What version of cinevisonPSE was it? Is there available version of cinevisionPSE to try its pre-process?

I think Sagitaire use the last version available on underground area, CinevisionPSE2.01.
But there is a version CinevisionPSE2.1, available before NAB...

I repeat me:
Ben where is the HD video...:rolleyes:

Dark Shikari, ;), make some nice development for grain optimization on x264.
x264 better than PeP ? (yes from me sure)

Ben don't worry I will use for you some H264 studio solution and if you wait
I will do a encoding with real time encoder (at high bitrate: start at 14-16Mbps).

[benwaggoner]

Ben where is the HD video...:rolleyes:
Continuing to hope that you'll be as vigorous in helping out making it as you are in bugging me about it :).

I posted a question about it earlier today in the apropos thread.

[Golgot13]

Continuing to hope that you'll be as vigorous in helping out making it as you are in bugging me about it :).

When the video will be available, we will can start the encoding process...
You're promised the video in August...

To my mind, there is no sense to talk about sort of video (lanscape, more colour,...)
because the metric give the big part a result to compare the encoder(and, for me, the "codec").

[benwaggoner]

When the video will be available, we will can start the encoding process...
You're promised the video in August...

To my mind, there is no sense to talk about sort of video (lanscape, more colour,...)
because the metric give the big part a result to compare the encoder(and, for me, the "codec").
Because, as I've explained many times before, I want to make this a useful clip for testing codecs in general, so I'm trying to get community feedback on what they'd like to see in such a clip.

For example, what should the end credits look like to be a reasonable approximation of the real thing in size and relative duration? What makes a realistically challenging opening motion graphics sequence realistically challenging?

[Inventive Software]

When the video will be available, we will can start the encoding process...
You're promised the video in August...

To my mind, there is no sense to talk about sort of video (lanscape, more colour,...)
because the metric give the big part a result to compare the encoder(and, for me, the "codec").

With that kind of response, I'm struggling not to strangle you in my head...

@Ben: opening titles vary quite a lot between films and TV shows. TV shows, normally, would have a montage of previous clips. Movies can have just about anything, but lately, I've seen opening credits and titles on the main film background. Hope that helps.

[benwaggoner]

Oh, and I got around to sticking up the 1080i30 source with 5.1 audio:

http://216.99.212.233:6969/torrents/TallShip_lag_YUY2_5.1.avi.torrent?96548FD06299672814021EB0D5BD9FA826024E68

I'm out of town for most of the week, so here's something for my bandwidth to do.

[Golgot13]

With that kind of response, I'm struggling not to strangle you in my head...


Sorry but when you listen some companies which don't say truth
and know what they say at "professional" you will understand.

You never ask yourself why we don't see VC1 on MSU comparison,
why there are not many VC1 developpment (camcorder, player,...)
....

There were many update in MS website (about VC1 exactly) because I said many things
(bad for some people, good for other one). Like scientific, I prefer proof only and
this thread will be helpful.




Thank you Ben for the video. :eek: :)
I start to download it.

I hope to have right, H264 will win (good luck Ben).

Ben can you make the VC1 encoding with your CinevisionPSE 2.1 ?

[benwaggoner]

Sorry, but when you went lot of time the video and you listen what some company can say at "professional" you will understand.
I have no idea what you're trying to say there.

You never ask yourself why we don't see VC1 on MSU comparison, why there are not many VC1 developpment (camcorder, player,...)
There's tons of players for VC-1 in all kinds of devices. As for camcorders, we've been approached about that market plenty of times but fundamentally aren't big believers in interframe codecs for acquisition. The pain of editing AVCHD bears this out I believe :).

Thank you Ben for the video. :eek: :)
I start to download it.

I hope to have right, H264 will win (good luck Ben).

Ben can you make the VC1 encoding with your CinevisionPSE 2.1 ?
When I can get around to it; I've got a series of trips over the next few weeks so I'm not sure when it'd be. But even WME can do pretty good 2-pass VBR interlaced these days with the right registry keys.

Anyone want to define an interlaced test?

I really have no idea where things stack up in PEP versus H.264 implementations for interlaced encoding. It's not something I've done any of for a while. I'm not going to make any predictions here.

[Golgot13]

There's tons of players for VC-1 in all kinds of devices. As for camcorders, we've been approached about that market plenty of times but fundamentally aren't big believers in interframe codecs for acquisition. The pain of editing AVCHD bears this out I believe :).


I don't talk about broadcasting HDTV, DVB receiver, mobil phone, webcam security,...

Yes there are some VC1 device player because it use chipset developped for HDDVD and BD
(sigma design, broadcom,...).

[Golgot13]

Anyone want to define an interlaced test?

I really have no idea where things stack up in PEP versus H.264 implementations for interlaced encoding. It's not something I've done any of for a while.

We test a progressive source so why change?
Majority of BD and HDDVD are in 24P/23.976P, :rolleyes:
why you want to introduce interlace? :confused:
Why you make interlace with progressive source?


I will upload a true film source (with movie grain, 35mm)
at the end of week. This small video will be in 1080p24 (no audio)
in PNG and enough to test the efficient of three codec.

[benwaggoner]

We test a progressive source so why change?
Majority of BD and HDDVD are in 24P/23.976P, :rolleyes:
why you want to introduce interlace? :confused:
Why you make interlace with progressive source?
It was the same shoot, but two sets of cameras; 1080i30 and 35mm film.

The 1080i edit was completed (by a real editor!) some time ago, so I thought it might be of interest to folks as well. This is in parallel to the 1080p24 source, which I'm still working on.

I will upload a true film source (with movie grain, 35mm) at the end of week. This small video will be in 1080p24 (no audio) in PNG and enough to test the efficient of three codec.
Why PNG? Might be better to use Lagarith AVI in YV12 so we don't need to worry about color space conversion issues in comparisons. PNG is just 8-bit, so it wouldn't give us a chance to do anything interesting with 10-bit or 8-bit conversion anyway.

[Dark Shikari]

Why PNG? Might be better to use Lagarith AVI in YV12Lagarith, however, is not available as part of libavcodec and as such is Windows-only.

A better idea would be HuffYUV using FFDshow's HuffYUV encoder.

[benwaggoner]

Lagarith, however, is not available as part of libavcodec and as such is Windows-only.

A better idea would be HuffYUV using FFDshow's HuffYUV encoder.
That can be problematic if someone has the VfW Huffyuv and not ffdshow installed, since it seems like it SHOULD work, but doesn't.

The nice thing about Lagarith is that there's only one implementation. Compression is better as well.

[Golgot13]

PNG is just 8-bit, so it wouldn't give us a chance to do anything interesting with 10-bit or 8-bit conversion anyway.

Just 8bit like video on BD and HDDVD.
We want to compare the encoding efficiency of all codec, not the preprocessing.

If you remember all my posts, you will know that I said PeP have a good preprocessing
and good tool have nice tool to convert video before encoding (like 0bit -> 8bit with dithering filter, ...).

[Golgot13]

A better idea would be HuffYUV using FFDshow's HuffYUV encoder.

Ok for HuffYUV (8bit), I choose 1080p23.976 (not 24p) because it can be played on HDDVD and BD hardwares players.

[benwaggoner]

Just 8bit like video on BD and HDDVD.
We want to compare the encoding efficiency of all codec, not the preprocessing.

If you remember all my posts, you will know that I said PeP have a good preprocessing
and good tool have nice tool to convert video before encoding (like 0bit -> 8bit with dithering filter, ...).
Aren't we agreeing here? I'm suggesting that we use a 4:2:0 codec so preprocessing wouldn't be part of the mix.