YV12 to YUY2

[unplugged]

Is there any YV12-YUY2 conversion command or method a bit like ConvertToYUY2 that doubles chroma rows and does NOT interpolates them?
To maintaing original image for frameserving CCE just like having YV12 direct conversion ;).
(damn, CCE doesn't really digest YV12 data?!?!? :-* ).

Thanks,
unplugged

[sh0dan]

Chroma is supposed to be interpolated due to the chroma placement in YV12. Chroma is placed _between_ the lines in YV12, and on the lines in YUY2.

Look at this MS explanation. (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp).

Unless CCE is buggy, it will move the YUY2 chroma half a line down, when converting it back to YV12.

[sh0dan]

The MPEG 1 standard has chroma centered between all four luma values. This is however not the case with MPEG2 & 4 - and since we're mostly dealing with those two formats as input, it would make most sense to adapt this scheme.

MPEG1 encoders will most likely move the chroma ifself, when they reciveve YUY2 input - if not - they're buggy!

[sh0dan]

Just edit them away, if you feel like it :)

I cannot remove individual posts anyway - only edit, or remove the entire thread.

[unplugged]

Ok, clear your reply. :)
Another thing regarding YV12 and Avisynth, since YV12 interlaced video needs two groups of chroma planes, one for top and another for bottom field how does avisynth handle this case?
As I can guess the memory layout of YV12 planes is different in this case (not with YUY2 because with one plane for color component can contain either progressive or intelaced data... right?)

Does avisynth have any flag-function to check or pass to interlaced mode color space in YV12?
(I mean reference flag as others like "field/frame based", "TFF/BFF"...)

[unplugged]

mmmm...
I have just start reading this from IanB at Avisynth.org forum
The new YV12 codebase has subsumed these definition and is using
FieldBased to imply Interlaced! Which is at odds with the original coding
intent and is causing subtle changes in the beviour of unrelated
verbs like Crop().

What is apparent is this needs to be clearly and concisely defined
and rigidly adheared to in the core Avisynth code.

I was proposing a new verb AssumeProgressive() to match with the
current AssumeTFF() and AssumeBFF() both which imply a
FrameBased interlaced source or indicate the parity with FieldBased
(i.e field separated) samples.
http://www.avisynth.org/forum/viewtopic.php?t=13

[Si]

@unplugged
i think the main discussion is going on here (http://forum.doom9.org/showthread.php?s=&threadid=46007&perpage=20&pagenumber=1)

regards
Simon

[Guest]

Originally posted by unplugged
Ok, clear your reply. :)
Presto!!!

[unplugged]

Originally posted by me
Ok, clear your reply. :)
Originally posted by neuron2
Presto!!!
??

eehmm... excuse me.
I meant "your reply was clear"