Yv12

[hms]

Made a new WinXP install and now CCE can no longer open my AviSynth script:
Ccspt 2.67.00.08
AviSynth 2.5
MPEG2Dec3dg.dll

This used to work in my previous WinXP installation but now error message:
“Couldn’t find appropriate video codec for ‘YV12’”

The very same AviSynth script will open correctly in Vdub and in TMPGEnc and even ZoomPlayer will show the video.

[SiXXGuNNZ]

save in notepad as yv12.reg

Windows Registry Editor Version 5.00

;Use DivX for decoding yv12, remove the ";" on the next two lines
;[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
;"VIDC.YV12"="divx.dll"

;Use XviD for decoding yv12, remove the ";" on the next two lines
;[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
;"VIDC.YV12"="xvidvfw.dll"

[hms]

It worked!!!!!
Thanks!!!!!!!!!!!!!

[SiXXGuNNZ]

Originally posted by hms
It worked!!!!!
Thanks!!!!!!!!!!!!!

no prob, mate :devil:

[RB]

Please read the CCE FAQ in this forum, especially Q14.4. Letting an external codec perform YV12 decoding is mostly bad, better convert to YUY2 in your AVISynth script.

[SiXXGuNNZ]

Originally posted by RB
Please read the CCE FAQ in this forum, especially Q14.4. Letting an external codec perform YV12 decoding is mostly bad, better convert to YUY2 in your AVISynth script.

that usually only applies to interlaced, but I do agree with you, there is no noticable speed difference when I switch from yv12 to yuy2 in the newest cce sp

it is always better to be safe then sorry

[hms]

Ok: I have read the discussion and it seems that conversion is if not better it certainly is safer.
In order to do this now would I first have to delete the modified registry entry?

[RB]

No.

[LigH]

I just had a nice discussion with Shunichi Takeuchi, a developer at Cinema Craft, and he told me why CCE will not support YV12:

Basically, the most important reason is that there is no reliable way to separate progressive 4:2:0 video (where the FourCC YV12 is good for) from interlaced 4:2:0 video (where a different FourCC shall be used, in his opinion). OpenDML AVIs may have an "interlaced" bit set, but many tools don't set it, so it is not reliable. And via AviSynth or VDF, it would never be known.

So for CCE, it will "always" be better to send YUY2, most preferably via "ConvertToYUY2(interlaced=?)" in AviSynth. At least in CCE Version 2.xx, I'd guess...

[Wilbert]

Basically, the most important reason is that there is no reliable way to separate progressive 4:2:0 video (where the FourCC YV12 is good for) from interlaced YV12 (where a different FourCC shall be used, in his opinion).
Assuming you are not doing any postprocessing in CCE, why does it need to know the difference? It should only mark the stream as progressive or interlaced, just let the user set it (like in QuEnc).

[sh0dan]

You should not let XviD do the conversion. Do it in AviSynth!

1) Interlaced YV12 will be upsampled INCORRECTLY to YUY2 or RGB when passed through XviD. Use ConvertToYUY2(interlaced=true).

2) AviSynth upsamplers have better quality than XviD. XviD is not designed to do these conversions, so the conversion filters are pretty basic.

[LigH]

Why upsampling? Should an MPEG encoder not be able to use planar 4:2:0 video as it is, and encode MPEG video directly out of it? Why shall an MPEG encoder upsample 4:2:0 to 4:2:2, if it will finally downsample to 4:2:0 (in usual Profiles@Levels) again?

When CCE gets YV12 video from AviSynth, but requests RGB or YUY2 only, it will use the next possible codec which is able to "decode" YV12 to YUY2 (e.g. DivX 5, XviD, or ffdshow's VfW inferface if properly configured). I would agree that using "ConvertToYUY2(interlaced=...)" shall be preferable.

The main question towards Cinema Craft is now (IMHO): Does CCE really need to request a progressive/interlaced state out of the video? Isn't it enough to rely on the user's configuration?

[LigH]

Shunichi Takeuchi is mainly afraid of having users who don't know enough about such facts, trusting in CCE being able to detect everything, and blaming CCE for creating bad results (although they would be liable for correctly setting up CCE).

[Wilbert]

I don't understand his response.

I mean, currently the user also has to set interlaced/progressive ('Progressive frame' in MPEG video setting). If you do that wrong it will be subsampled incorrectly (YUY2->YV12).

If it has YV12 support, and you mark the video as progressive (while it is interlaced) or vice versa, then it will be upsampled incorrectly by the mpeg2 player. Similar problem as above.

But, I'm not a programmer, so maybe I'm missing something :confused:

[LigH]

So do you think, Cinema Craft shall have the heart to release a "nerd version" with YV12 support, just to see if at least the members of the best informed video board :rolleyes: can cope with it?! ;)

[RB]

Originally posted by Wilbert
I don't understand his response.

I mean, currently the user also has to set interlaced/progressive ('Progressive frame' in MPEG video setting). If you do that wrong it will be subsampled incorrectly (YUY2->YV12). No, these options control how the output video is encoded not how the input is treated. With support for YV12 input they basically would have to add a checkbox "input is interlaced YV12" somewhere because there's no way to detect this automatically. Here is the response on this subject from Shunichi Takeuchi I got a few months ago:The reason we do not want to support YV12 (or 4:2:0 source) is
that it has potential problem in usage.

There is a difference between progressive 4:2:0 and interlace
4:2:0. In progressive 4:2:0, a chrominance sample represents
adjacent two lines in the same frame, say, line 0 and line 1.
But in interlaced 4:2:0, it represents adjacent two lines in the
same field, say, line 0 and line 2. But most of the users does
not recognize the difference, and they will blame CCE if the
quality of encoded image is bad even if the reason is because of
the mis-setting of 4:2:0 format.

I am afraid we will get into such trouble, therefore we do not
want to support YV12. I hope you understand this.

[Wilbert]

No, these options control how the output video is encoded not how the input is treated.
Yes, so it controls how the YUY2 clip is subsampled to YV12. I assumed that it also adds an interlaced or progressive mark to the header of the mpeg2 file?


With support for YV12 input they basically would have to add a checkbox "input is interlaced YV12" somewhere because there's no way to detect this automatically.
So? Why does it need to know whether the *input* file is interlaced or progressive ? It just has to add that info to the header of mpeg2 file.

Of course you need to know that if you do any denoising (is that possible in CCE?), but then again, in that case you also need to know whether the input YUY2 is interlaced or not.

[LigH]

From my basic knowledge, CCE would only need to know if the input is interlaced or progressive, if it upsamples to 4:2:2 before processing in general, and downsamples to 4:2:0 again while compressing (in usual Profiles@Levels -- remember, there are 4:2:2 MPEG-2 Profiles, although I'm not sure right here if CCE supports one).

But keep in mind, too, that several people "almost gave up" handling interlaced YV12, and finally decided to early convert to YUY2, to avoid so many traps in processing poorly subsampled chroma, and so trying to avoid more headache... ;)

[sh0dan]

If CCE will be converting 4:2:0 to 4:2:2 for filtering, and then converting it back to 4:2:0 for compression, then there will be no gain in having YV12 input anyway. Shunichi Takeuchi's argument about chroma placement only makes sense, if he needs to upsample chroma (to 4:2:2 or 4:4:4).

Can anyone confirm this is why he cannot implement YV12 input?

[fccHandler]

Basically, the most important reason is that there is no reliable way to separate progressive 4:2:0 video (where the FourCC YV12 is good for) from interlaced YV12 (where a different FourCC shall be used, in his opinion).
In my opinion this "most important" reason has absolutely no merit, because there is also no reliable way for CCE to separate progressive YUY2 video from interlaced YUY2, or progressive RGB from interlaced RGB. Besides, I always thought that was what the "progressive frame flag" checkbox was for.

[LigH]

... and so, the user is completely liable for his results. That's the opinion I would agree, even if this means that users of a professional encoder have to first read guides about video basics before use. But hey: Didn't we all start learning, several years ago? Somehow I'm afraid, learning is getting out of fashion... :rolleyes:

Just one point: DVD video producers almost always have their encoders set to use interlaced encoding, no matter which kind of material they got, just to ensure no encoding disaster due to "progressively encoding interlaced material by mistake". In this case, up- and downsampling for applying filters can use wrong luma samples.

Moreover: There are movies where the flavour may change from scene to scene, especially converted PAL material (like "StarTrek: TNG" - those DVDs are notorious!). But those "bastards" shall be handled in 4:2:2 as long as possible, anyway.