[Matroska-devel] multiple video streams stereo 3D mode broken

Steve Lhomme slhomme at matroska.org
Sun Feb 27 10:11:25 CET 2011

I added a note about the older values of StereoMode:

2011/2/27 Steve Lhomme <slhomme at matroska.org>:
> Hi,
> 2011/2/23 Кирилл Гаврилов <gavr.mail at gmail.com>:
>> About backward compatibility. As I found, old stereomode (had only
>> mono/left/right/both values) was saved with ID 0x53B9.
>> The new stereomode flag has id 0x53B8 and has another values enumeration
>> with only combined modes.
> In fact I think the specs have always said 0x53B8 but libmatroska had
> 0x53B9 instead. It was fixed in libmatroska 0.9.0 released in may
> 2010.
> The oldeest revision of the specs we have with a date :
> http://www.matroska.org/node/1/revisions/1/view (also may 2010)
>> This mean that old flag will not be read by new parser at all (mkvinfo show
>> me 'DummyElement' for old files)
>> thus old value will not be reinterpret by any program in wrong way (but will
>> be ignored).
>> Technically both flags could be safely read for full compatibility. Am I
>> right?
> Yes, except this is due to a libmatroska bug. I don't know if other
> code was used to produce/read such files.
> Current readers should use the values pre-defined in StereoMode when:
> it's 0x53B8 and Matroska version EBMLReadVersion is 3 or more.
> Otherwise the old values can be assumed. In WebM 0x53B8 is sufficient
> to know it's the new values.
> And of course 0x53B9 will mean old values.
>> I found this in specification notice:
>>> The pixel count of the track (PixelWidth/PixelHeight) should be the raw
>>> amount of pixels (for example 3840x1080 for full HD side by side) and the
>>> DisplayWidth/Height in pixels should be the amount of pixels for one plane
>>> (1920x1080 for that full HD stream)
>> The only reason for this strange behaviour - to simplify DAR settings by the
>> user (if he know about this).
>> But if player has no support for stereoplayback and probably - doesn't fit
>> this special agreement, than video will be shown with wrong Display Aspect
>> Ratio
>> (because it will be applied for combined stereopair). This is sans logique
>> for me to apply different PAR/DAR for each combined mode.
>> Is this agreement is final and will never changed?
> It can change, but this is only the case when video is encoding
> side-by-side. If the reader doesn't know about StereoMode there's even
> less chance it would be able to tell the decoder to keep only one
> side. So in any case the display is screwed.
> In the case the playback chain knows about StereoMode and side-by-side
> then it's the way to tell if the resolution is half the regular one or
> the full one on the final display.
>> The only players I heard (I have no any) that do this like this - some
>> hardware stereoscopic players. But they do this regardless PAR/DAR settings
>> in container
>> - they just ALWAYS show 1080p/720p video (for combined stereopair - thus
>> video is anamorphic) as 16:9 for one plane (according to selected source
>> format).
> If they don't care about the PAR/DAR then there is no issue.
>> If agreement for PAR/DAR is final (at least for matroska container),
>> than FFmpeg library should ALWAYS apply special PAR conversion according
>> stereomode flag to fit the agreement
>> (thus video will be shown with correct aspect ratio regardless stereo
>> support in the player).
> Does FFmpeg have the flags to tell a video is side by side ?
> I think if you reencode a video with FFmpeg it will keep the aspect
> ratio on the output. So all you need is make sure the pixel resolution
> you set is still matching the side-by-side aspect.
>>> For the TrackCombinePlanes explanation you may want to look at this:
>>> http://www.matroska.org/technical/specs/notes.html#TrackOperation
>>> What you had with left, and right separated is now handled that way.
>>> These tracks remain but then you have a third virtual track that is
>>> the actual 3D version.
>> As I understand, virtual tracks declared are created in other layer (not as
>> track options).
> No, they are declared just like any other track. That's the whole
> point, that everything that applies to tracks apply to virtual ones as
> well.
>> And virtual tracks aware parser will just ignore this information (and
>> stereo video tracks will still be available
>> just without any way to distinct them while technically TrackPlaneType
>> currently has very simple definition).
>> Thats not bad.
> Parsers that don't know about TrackOperation will not be able to play
> these tracks. That's one of the reason for the bump to Matroska v3. A
> file marked as readable by v3 (and up) compliant readers and can only
> handle v2 may decide not to play the file. The left and right tracks
> may be marked as NOT Enabled as well (0xB9) and then the player ens up
> with just the virtual track that it can't play anyway.
>> Another of my question was:
>>> Could you explain me what this combine planes means and how it should be
>>> saved using mkvmerge and could/should be used in a player?
>> I fail to find support for combine planes in current mkv tools (mkvmerge and
>> mkvpropedit).
>> I should understand - it is in progress?
> Yes
>> To support new behaviour in my program I should change FFmpeg matroska
>> parser (and probably define some new definitions in API).
>> So, I want to ask - is someone from matroska developers responsible to save
>> FFmpeg implementation in sync?
>> I'm not yet FFmpeg developer but I'll try to create patch if noone from
>> resident developers is interest in it.
> I haven't followed the work on FFmpeg for a while, but no there is no
> direct contact to make this happen. Usually people add features in
> their programs when they encounter files they can't play. I suppose 3D
> is quite new and I don't think FFmpeg has been tweaked yet to handle
> all the 3D possibilities. The best way to find out is ask on their
> mailing lists or IRC channel.
> Steve
> --
> Steve Lhomme
> Matroska association Chairman

Steve Lhomme
Matroska association Chairman

More information about the Matroska-devel mailing list