Captured DV is showing up as YV12?

[Dopopopolis]

Ok, so its seems my Info() .avs just feeds me whatever format cedocida DV codec uses to decompress, how do i figure out what colorspace my original DV files are? Ive read conflicted reports that DV is "always YUV" or always "YV12". I cant seem to find a straight answer regarding this. Its not even the source DV footage that i want to know, its whether or not exporting from premiere causes the colorspace to be changed, and how cedocida's settings influence that change.

[yup]

Dopopopolis!
Welcome!
See link
http://www.mir.com/DMG/chroma.html
You can choose colorspace Cedocida codec as for decoding and for encoding. but I think if Your target DVD YV12 O'k.
yup.

[Dopopopolis]

The link explains alot about subsampling numbers, but i dont see any mention of whether your talking about YUY2 or YUV. I see all this YVUYVCbCr2UVUY gibberish slung around so much im beginning to realize that it must be some sort of slang. Despite hours upon hours of research i cant seem to find any resource that explains how they are all categorized, anyways i really just want to know how to tell what colorspace my files are in since Info() reports decoder information and not the video's actual colorspace.

edit: I noticed This link (http://www.lurkertech.com/lg/packings/index.html) on your site that might address my question:


How to Tell Which Colorspace You Have
In most SGI libraries, a single token encodes both colorspace and packing. Often, details of the colorspace are implicit. For the VL of divo and beyond, the two parameters are specified separately and explicitly, using VL_PACKING and VL_COLORSPACE. This section tells you which libraries use which colorspace when.

For OpenGL, IRIS GL, DM, and CL:

* the library constant indicates whether the data is "rgba" or "vyua"
* "rgba" data is full-range by default.
* "vyua" data in DM and CL may be full-range or headroom-range. You must determine this from context.
* "vyua" data in OpenGL is headroom-range by default. For information on the SGIX_ycrcb OpenGL extension, see glDrawPixels(3G), Displaying In-Memory Video Using OpenGL and Rendering graphics onto video.

For VL, using the traditional VL_PACKING tokens from IRIX 6.2:

* the VL_PACKING constant indicates whether the data is "rgba" or "vyua"
* "rgba" data on vino, ev1, cosmo2, ev3, and mvp will always be full-range by default.
* "vyua" data on vino, ev1, cosmo2, ev3, and mvp will always be headroom-range by default.
* you can program ev3 to deliver headroom-range "rgba" data (also called RP175 RGBA) by setting VL_FORMAT on the memory node to VL_FORMAT_DIGITAL_COMPONENT_RGB_SERIAL. This only works if the video signal at the jack is also VL_FORMAT_DIGITAL_COMPONENT_RGB* (ev3 will not automatically do color conversion like sirius does).
* ev3 has an optional high-quality colorspace converter which you can program to convert between all sorts of colorspaces using ev3-specific controls.
* on sirius, when you set up a vid-to-mem or mem-to-vid transfer, you must specify the range and color set you want explicitly. You do this by specifying VL_FORMAT on your memory node, like so:

Color Set Full-Range Components Headroom-Range Components
"rgba" VL_FORMAT_RGB not supported
"vyua" VL_FORMAT_SMPTE_YUV VL_FORMAT_DIGITAL_COMPONENT
Sirius will give you data in your desired range and color set regardless of the input signal format. If the colorspace implied by VL_FORMAT on the video node disagrees with that implied by VL_FORMAT on the memory node, then sirius will do colorspace conversion for you.

The VL that comes with the divo product and beyond makes all of the parameters (packing, set of colors, range of components) explicit in a clean way:

* You use VL_PACKING to specify only the memory layout. The new memory-only VL_PACKING tokens are disjoint from the old, and the old tokens are still honored, so this change is backwards-compatible.
* You use VL_COLORSPACE to specify the colorspace parameters:

Color Set Full-Range Components Headroom-Range Components
"rgba" VL_COLORSPACE_RGB VL_COLORSPACE_RP175
"vyua" VL_COLORSPACE_YUV VL_COLORSPACE_CCIR
There is also a VL_COLORSPACE_NONE, which is useful when you want to treat Rec. 601 digital video as a raw 10-bit data stream (as in SDDI).
* Like sirius, divo will perform colorspace conversion if the colorspace implied by VL_FORMAT on the video node disagrees with that implied by VL_COLORSPACE on the memory node.


None of that makes any sense. Are they suggesting i write my own drivers and hack into the openGL to make it reveal the colorspace? Is that really the only way?

[JohnnyMalaria]

Within the DV stream itself, the answer is "none of the above" strictly. The pixel layout depends on whether the DV is NTSC or PAL. In either case, the video is stored as compressed macroblocks consisting of four 8 x 8 Y blocks, one 8 x 8 Cb block and 8 x 8 Cr block (since we are talking about the strict naming, I've used YCbCr instead of YUV). Anyway, for NTSC, the chroma block maps to four horizontally stacked Y blocks (i.e., 32 x 8) and for PAL it is 16 x 16.

Whether you end up with YUV, YV12, RGB etc etc depends upon the *decoder*. It can choose to create a planar image (Y, U and V separate), keep the chroma sampling at one per luma pixel, interpolate to 1:1, duplicate to 1:1 etc.

So, in short, the *files* are always the same format as the DV stream. The concept of YUV vs. YV12 is strictly irrelevant at that level. Only once you decompress the video does the colorspace become meaningful and that depends on the decoder used.