[gst-devel] Video 3D support

[Martin Bisson]

Stefan Kost wrote:
> On 24.05.2010 01:52, Martin Bisson wrote:
>   
>> 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
>>   
>>     
>
> Lets see what david replies. I think he rather meant
>
> video/x-raw-yuv-stereo, format={"I420", "UVYV" ,..}, layout={"side-by-side", "over-under", ...}, ...
>   
You're right, this makes more sense...  I've started to experiment with 
the 3 new caps I've mentioned, but it would be simpler/better to use 
that layout.  It would still avoid the compatibility problems with 
elements that currently handle video/x-raw-yuv.

 From what I see now, it would be either that approach or the new FOURCC 
one, I'll reply to David's e-mail right after this one and we'll see.

>> 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.
>>   
>>     
> Reprendered Red/cyan is not really detectable and normaly we would just
> render it as it is. I one would want to convert read/cyan into grayscale
> over under one can use a hand-crafted pipeline. Also the red/cyan output
> from the 3dmuxer would not show any sign of being 3d on its caps anymore.
>   
Great.  That's how I saw that.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100525/b94ef4bd/attachment.htm>