[Matroska-devel] revisiting StereoMode tag and

Steve Lhomme slhomme at matroska.org
Sat Aug 7 17:10:00 CEST 2010


The problem is really when tracks are combined via Matroska and not inside
the codec. So do "top-bottom", "checkerboard", etc make sense for the way to
"mono" tracks can be combined or not ?

As you can see, when the tracks are defined as dependent, they need to
define which part of the dependency they are. So what would it be in this
case ?

On Sat, Aug 7, 2010 at 5:05 PM, Alok Ahuja <waveletcoeff at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/708c9831/attachment.html>


More information about the Matroska-devel mailing list