[Matroska-devel] revisiting StereoMode tag and

Steve Lhomme slhomme at matroska.org
Sat Aug 7 10:57:36 CEST 2010


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20100807/f5dded57/attachment.html>


More information about the Matroska-devel mailing list