[Matroska-devel] revisiting StereoMode tag and

Alok Ahuja waveletcoeff at gmail.com
Sat Aug 7 17:05:04 CEST 2010


The HDMI supported source stereo layouts are indicative of the type of
stereo source content out there - the hardware's capability for supporting
them is a different issue. This is corroborated by the stereo types
supported in H.264 also.

In this new variant, would the definitions be as follows?

StereoType
mono
left-right
top-bottom
checkerboard
row-interleaved
column-interleaved

StereoPosition
left
right
background

The new variant in itself looks pretty clear to me on the distinction of the
definitions. Thanks Steve.


On Sat, Aug 7, 2010 at 1:57 AM, Steve Lhomme <slhomme at matroska.org> wrote:

> Here is a new variant that I think should be good enough for all the cases
> mentioned. I'm still not sure if the "HDMI" track combination types are
> necessary of if it's more a hardware capability issue. For example we don't
> store in Matroska wether a track is interlaced or not.
>
> As you can see the "container combining" and "internal 3D track" are now
> clearly separated.
>
> single "mono" track
> <TrackEntry>
>   <TrackUID>123</TrackUID>
>   <StereoType>mono</StereoType>
>   ...
> </TrackEntry>
>
> stereo with 2 tracks combined
> <TrackDependency>
>   <DependencyType>stereo</DependencyType>
>   <TrackItem>
>     <TrackUID>234</TrackUID>
>     <StereoPosition>left</StereoPosition>
>   </TrackItem>
>   <TrackItem>
>     <TrackUID>123</TrackUID>
>     <StereoPosition>right</StereoPosition>
>   </TrackItem>
> </TrackDependency>
> <TrackEntry>
>   <TrackUID>123</TrackUID>
> </TrackEntry>
> <TrackEntry>
>   <TrackUID>234</TrackUID>
> </TrackEntry>
>
> single track with 2 planes
> <TrackEntry>
>   <TrackUID>123</TrackUID>
>   <StereoType>left-right</StereoType>
>   ...
> </TrackEntry>
>
> stereo with 3 tracks combined
> <TrackDependency>
>   <DependencyType>stereo</DependencyType>
>   <TrackItem>
>     <TrackUID>234</TrackUID>
>     <StereoPosition>left</StereoPosition>
>   </TrackItem>
>   <TrackItem>
>     <TrackUID>123</TrackUID>
>     <StereoPosition>right</StereoPosition>
>   </TrackItem>
>   <TrackItem>
>     <TrackUID>345</TrackUID>
>     <StereoPosition>background</StereoPosition>
>   </TrackItem>
> </TrackDependency>
> <TrackEntry>
>   <TrackUID>123</TrackUID>
> </TrackEntry>
> <TrackEntry>
>   <TrackUID>234</TrackUID>
> </TrackEntry>
> <TrackEntry>
>   <TrackUID>345</TrackUID>
> </TrackEntry>
>
> On Fri, Jul 30, 2010 at 10:59 PM, Steve Lhomme <slhomme at matroska.org>wrote:
>
>> On Fri, Jul 30, 2010 at 12:48 AM, Alok Ahuja <waveletcoeff at gmail.com>wrote:
>>
>>>
>>>
>>> On Thu, Jul 29, 2010 at 1:17 PM, Steve Lhomme <slhomme at matroska.org>wrote:
>>>
>>>> In Matroska the default value doesn't need to be stored. And the default
>>>> (and backward compatible) value for StereoPlane would be "mono" (which will
>>>> probably not be stored as strings). So wether it's superceded or not is not
>>>> an issue. Basically that tag means that the track cannot be used by current
>>>> 2D systems if it's something else than "mono". But in that case the codec
>>>> value will probably not be supported either. I don't think the current AVC
>>>> or MPEG2 can support non mono tracks ? They have to be combined from
>>>> independent tracks ?
>>>>
>>>>
>>> [Alok]: AVC or H.264 can support non-mono tracks by using an SEI message.
>>> This is a recent addition. I'm not aware of MPEG2 being able to support it.
>>>
>>>
>>>> What you propose sound good too. I'm just concerned wether current
>>>> players will be able to tell if the track is "internally 3D" or not, to know
>>>> if they can actually try to decode the stream or not. In other words if the
>>>> codec ID alone will *always* be sufficient to differentiate the 2 worlds or
>>>> if a flag has to be added at the current track level.
>>>>
>>>>
>>> [Alok]: I'm thinking of the MVC or H.264 with SEI message codec example.
>>> In this case, the codecID is not sufficient to differentiate between 3D and
>>> non-3D. This is because the bitstream specification for the aforementioned
>>> codecs contains the 3D info and that is optional (in case of H.264 with
>>> SEI).
>>>
>>> OK, so we need that information at the track level as well (2D systems
>> may decide they can't deal with it). Whichever though existing players will
>> have to be updated to make sure a 3D AVC track is not tried to be played on
>> existing systems. So it matters less if it's in the track entry as it is
>> today or the "upper" TrackDependency. Or it could still be handled at the
>> codec level. ie V_MPEG4/ISO/AVC and V_MPEG4/ISO/AVC3D. In matroska it
>> would not be possible to switch the stream kind in a segment. So it may
>> still be possible to split them that way. Current 2D decoders may choke on a
>> 3D AVC stream as well (not 100% sure). So it may be necessary anyway to make
>> this distinction.
>>
>> Steve
>>
>>
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20100807/49fe7e3a/attachment.html>


More information about the Matroska-devel mailing list