[Matroska-devel] multiple video streams stereo 3D mode broken
slhomme at matroska.org
Sun Feb 27 09:54:02 CET 2011
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
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
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
> (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
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:
>> 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
> 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
> I should understand - it is in progress?
> 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.
Matroska association Chairman
More information about the Matroska-devel