[gst-devel] Video 3D support

[Martin Bisson]

David Schleef wrote:
> I recommend using a new caps type, perhaps video/x-raw-yuv-stereo
> or some such, instead of using video/x-raw-yuv,stereo=true.  Using
> video/x-raw-yuv leads to endless compatibility problems: elements
> that currently handle video/x-raw-yuv would silently do the wrong
> thing with stereo video.  Using x-raw-yuv would mean width/height
> in the caps would be double the *actual* width/height of the mono
> video, which is hacky.  Also, converting from stereo to mono in
> many cases would require copying.
>
> Defining new fourccs:  This has the obvious disadvantage that
> we'd either need to keep these internal to GStreamer, or make them
> well-known enough for other people to use them.  Integrating with
> existing elements (and libgstvideo) is straightfoward.  Adding
> new layouts (side-by-side, top-bottom, memory consecutive, etc.)
> is simple, although adds *lots* more fourccs.
>   
This means that we would have something like :
- video/x-raw-yuv-stereo-side-by-side
- video/x-raw-yuv-stereo-top-bottom
- video/x-raw-yuv-stereo-row-interleaved

And the same thing for different layouts like yuy2 and uyvy?  Planar 
layouts like I420 might be problematic for row interleaving though, 
because the u and v values spread to 2 lines...

So these caps would describe 3D streams that carry the 2 images.  But 
what about streams that actually are combinations of the 2 images, like 
red/cyan streams?  I guess since these would be displayed on normal 
devices, they could just be normal streams, i.e. a 
video/x-raw-yuv-stereo-side-by-side stream could be converted to 
red/cyan stream with caps video/x-raw-yuv.

I think this caps approach sounds like a good, simple approach that 
would carry the information we need.  I'm not sure how I would deal with 
interlaced frames yet, I'll have to look into that.

Thanks for your reply,

Martin