[gst-devel] Video 3D support

[Rob Clark]

On 05/25/2010 08:42 AM, 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", ...}, ...
>    



One suggestion..  if we do introduce new caps mimetype values, can we 
tackle rowstride at same time?  (And maybe better support for normal 
interlaced?  And anything else that someone sees to be missing in 
current caps?)  I guess rowstride would simplify handling at least of 
side-by-side layout..

I've heard the argument against introducing new mimetypes because it 
would slow down caps negotiation..  well, I'm not usually dealing with 
pipelines with 100's of elements so I've not been too concerned with 
it.  But I guess if there are enough things that could be added as 
required fields in one go to justify video/x-raw-yuv-full (or something 
like that), then we could deprecate video/x-raw-yuv and that would solve 
the performance issue.

BR,
-R


>    
>> 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.
>
> Stefan
>
>    
>> 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
>