[Matroska-devel] revisiting StereoMode tag and

Alok Ahuja waveletcoeff at gmail.com
Sat Aug 7 18:03:23 CEST 2010


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

> 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 ?
>
> [Alok] - I do not know of a practical example in which we have individual
tracks representing top view or bottom view only, or for that matter
checkerboard. Hence, they do not make sense for the StereoPosition tag


> 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 ?
>
>
> [Alok] - I think you have StereoPosition nailed correctly to define the
track dependency- left eye view, right eye view, background view. You could
consider an incremental and generic "reference view" track that could be
defined as a dependent of the other tracks. These references could be
numerous in nature, and it would be up to the codec to choose how they are
pertinent in the final representation.


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
>>
>
>
> _______________________________________________
> 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/1eaacb43/attachment.html>


More information about the Matroska-devel mailing list