Once again: Can VDub(Mod) handle YV12?

[LigH]

The more I try to find out why some people get error -2 when trying to convert an AviSynth script with YV12 output, and others don't have any problem, the more I get confused: What can VirtualDub, what can VirtualDubMod do with YV12 input under which circumstances?

Let's compare the behaviour:

Case 1A) No YV12 capable VfW codec installed, "Input preview [F9]" and "Output preview [F10]" are enabled

- VD does not open the AVS file: "Couldn't locate decompressor for format 'YV12' (unknown)..."
- VDM opens the AVS file: "Couldn't locate decompressor for format 'YV12' (unknown)... Only 'Direct stream copy' is available for this video."; Direct Stream Copy works well and creates uncompressed YV12 video.

Case 1B) No YV12 capable VfW codec installed, "Input preview [F9]" and "Output preview [F10]" are disabled

- VD: same as 1A
- VDM: same as 1A (although the YV12 FAQ #4 states that VDM only needs a helper codec for previews!)

Case 2) Koepi's XviD 1.0.1 is installed

- VD loads the AVS file, Direct Stream Copy saves YV12, the saved XviD AVI stored "16 bit" as source bit depth (typical for YUY2)
- VDM loads the AVS file, Direct Stream Copy saves YV12, the saved XVID AVI stored "12 bit" as source bit depth (typical for YV12)

So far, so fine; now I saved with both VD and VDM each an XviD AVI file using Fast and Normal recompression mode. Then I compared the AVIs bytewise (fc /b)...

Would you expect that the results of "Normal recompression using VDub" and "Normal recompression using VDubMod" shall be quite identical, except for some header details? Probably "yes, because both get RGB24 sources"? -- It's not quite so, the files started to differ from offset 0x00048182 = 295298. Well, could be an incident, a slightly different behaviour, ...

Would you expect that the results of "Fast recompression using VDub" and "Fast recompression using VDubMod" shall be quite identical, except for some header details? Probably "no, because VDub transfers YUY2 and VDubMod transfers YV12 sources"? -- It's not quite so, the files started to differ from offset 0x00048382 = 295810. Identical output almost up to the same point, but with different source video formats; a co-incident, due to perfectly identical image reconstruction inside the XviD codec?

Another member in the german doom9/Gleitz forum has two sample videos available (http://forum.gleitz.info/showpost.php?p=120208&postcount=33) which are absolutely identical (except for the headers) - but much shorter than my examples: I tested 1000 frames, his has only 25 frames.

I just wonder: Is it accident or intent?

[Suiryc]

I dunno how well behave bytewise comparison tools, but there are at least 2 'big' differences I am aware of between VirtualDub and VirtualDubMod:

1. In some AVI JUNK Chunk at the beginning of the file, the program writes its name and version (i.e. 'VirtualDub 1.5.10 (release build)' / 'VirtualDubMod 1.5.10.1 (release build)')

2. VirtualDubMod fill an INFO list Chunk where it writes its name in a ISFT subchunk (software name info)


I think each of those 2 differences could explain why the comparison won't help :p

[LigH]

@ Suiric:

As I already wrote: I'm just interested in differences after the other headers, only in the video data part of the AVI file. So I'd recommend to ignore differences in a range between 0x0000 .. ~0x3FFF, as well as at the end of the movie.

If two XviD AVIs are identical in their compression results, no matter if they get YUY2 or YV12 input, I wonder if keeping YV12 at any cost is worth the effort.

[Suiryc]

Oh my bad, didn't notice you were working on small samples.

However you should note VirtualDub handles YV12 in Fast Recompress since version 1.5.6, and you said that VD saves uncompressed YV12 (case 2).
So aren't VD and VDM handing over YV12 data to the codec ? in this case it is normal to see not much differences in the bitstreams.

Don't recall why VD use a bitdepth value of 16 and VDM 12 though ...

[Wilbert]

However you should note VirtualDub handles YV12 in Fast Recompress since version 1.5.6
I thought that Avery disabled that again in 1.5.10? Or, do I misunderstand what he's saying here:

(...) There used to be support for YV12/I420, but I removed it because it was reusing the MPEG decoder's converters and in recent versions those have strict alignment requirements for SSE2 optimization.

http://virtualdub.everwicked.com/index.php?act=ST&f=5&t=6985&hl=yv12&

[LigH]

Originally posted by Suiryc
Oh my bad, didn't notice you were working on small samples.
Not me... ;) 1000 Frames are enough to contain more than one I-Frame. And as you can read in that thread, there are more sample videos from 'Viperzahn' now with a bigger size.
__

Well; maybe even VirtualDub is indeed able to move YV12 through to the codec, then the issue is exactly the other way round.

Then there would only the small thing be left (required codec "only for preview" even with disabled preview). But that is less important: For now, we notice that a YV12 competent codec must be installed, although it is not used for shipping YV12 video to the codec.

[Didée]

Oh ... thinking "across" to another problem:
(...) There used to be support for YV12/I420, but I removed it because it was reusing the MPEG decoder's converters and in recent versions those have strict alignment requirements for SSE2 optimization.
Could this "reusing the MPEG decoder's converters" somehow be related to those brightness differences between mpeg-2 sources opened through Vdub(mod) and through AviSynth?

- Didée

[Wilbert]

Could this "reusing the MPEG decoder's converters" somehow be related to those brightness differences between mpeg-2 sources opened through Vdub(mod) and through AviSynth?
I thought about it. I mean, it must be some decoder problem. However, in that case, it shouldn't be difficult to replicate it.

A while ago I made an (out of bound) mpeg2 file (luma upper half = 0, lower half = 50) to test this:

http://www.geocities.com/wilbertdijkhof/mix.zip

If you open the mpeg2 file (mix2.mpg) in vdubmod (I used 1.5.10.1), and you open the avs file (mix2.mpg -> mix.d2v -> mix.avs) in vdubmod, I don't see a brightness difference.

[Suiryc]

Originally posted by Wilbert
I thought that Avery disabled that again in 1.5.10? Or, do I misunderstand what he's saying here:



http://virtualdub.everwicked.com/index.php?act=ST&f=5&t=6985&hl=yv12&
Don't recall seeing any move in that way in the code.
Maybe he is talking of his current devs (for 1.6.0), or the internal converters to RGB format (used in the filter pipeline) ...

[stephanV]

dont think so... 1.6.0 will support just about any useful colorspace there is, also for output.

but IIRC yv12 was is still not fully functional in the test build i got though