[Matroska-devel] multiple video streams stereo 3D mode broken
gavr.mail at gmail.com
Wed Feb 23 21:40:59 CET 2011
Thanks for reply and for links.
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.
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
Technically both flags could be safely read for full compatibility. Am I
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?
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
- 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 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).
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
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.
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.
official site: sview.ru
e-mail: kirill at sview.ru
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Matroska-devel