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

Steve Lhomme slhomme at matroska.org
Wed Feb 23 18:28:30 CET 2011

Hello Kirill,

Thanks for your input. I guess we will have to add some more possible
values for combined frames. In the end it doesn't matter if they are
used or not. But they need to be distinguished from each other. If
only to tell the user they can't be played.

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.

2011/2/23 Кирилл Гаврилов <gavr.mail at gmail.com>:
> Hi all, I new in this mail list.
> I am a movie player developer and found this discussion here:
>> Moving the discussion to the list at some other people may be interrested.
>> On Fri, Feb 4, 2011 at 6:49 PM, Dorian Muthig <contact at
>> dorianmuthig.com> wrote:
>> > Hello,
>> >
>> > Whilst converting a local library to the new format wouldn't be much of
>> > a problem, for files from a remote source I still can be sure about the
>> > format used, especially since people don't usually update their muxing
>> > software regularly and stick to what they know and rely on.
>> > The old format made sense very well. If the first or default video is a
>> > stream with stereo mode set to 1 or 2, I need to look for the second
>> > complementary stream that uses the stereo mode for the other eye. The
>> > playback software then combines the picture from both streams into a display
>> > or projector output for stereoscopic viewing.
>> > There may not have been a large consumer space for 3D viewing at home at
>> > the time, but small production environments and 3D movie theaters have used
>> > the format due to its codec versatility.
>> I understand. But it should not be left to guessing which track should
>> be combined with what other. Imagine you have 2 right eye and 2 left
>> eye tracks (for example a multi angle video). There was nothing to
>> know which should be used.
>> I think it's too late now to change the values again (and leave empty
>> the fields that were used). So since such systems use a custom player,
>> I guess they can be updated to check which mkvmerge value was used
>> (unless they also used custom muxers). It's not much more complex than
>> checking for a new field. Such players should also be updated to
>> handle the new TrackOperation system too.
> My player is based on FFmpeg libraries which has its own MKV parser. This
> time the stereomode flag is not used at all
> (no way to read it from FFmpeg objects and it doesn't read from the header).
> When I released first player version last summer I found that mkvmerge can
> define stereomode for video streams
> and thus mark them as mono (seems to be not saved into file), left, right
> and both (with unclear definition).
> I think that dedicated streams for each view (left and right are fit most
> needs) is a logical and most optimal way
> to save the stereoscopic video into MKV container. That time (last summer) I
> can not read the left/right marks in the player
> (I need to modify FFmpeg library or additionally to read MKV headers using
> mkv library (ugly)) and assume that if
> video contains 2 video streams - thats probably stereoscopic video with
> dedicated streams per view.
> Now I want to implement correct way to read this field (probably - modify
> FFmpeg sources) but go stuck that tag definition was completely changed!
> I found this definition in mkvinfo sources:
> enum mode {
>     invalid                        = -1,
>     unspecified                    = -1,
>     mono                           =  0,
>     side_by_side_left_first        =  1,
>     top_bottom_right_first         =  2,
>     top_bottom_left_first          =  3,
>     checkerboard_right_first       =  4,
>     checkerboard_left_first        =  5,
>     row_interleaved_right_first    =  6,
>     row_interleaved_left_first     =  7,
>     column_interleaved_right_first =  8,
>     column_interleaved_left_first  =  9,
>     anaglyph                       = 10,
>     side_by_side_right_first       = 11,
>   };
> I have no idea what the reason to store that huge list of modes while the
> most of them hopefully never used to store the stereovideo
> itself but were designed for representation on for specific device (without
> scaling):
> row-interleaved - was used in some old stereoscopic DVDs and is a native
> format for some monitors (Zalman etc);
> column interleaved - never heard it was used to store video but it is native
> format for some obsolete stereo-monitors (SeaReal I heard);
> checkerboard - never heard it was used to store video but it is native for
> some 3D-ready DLP TVs;
> anaglyph - have no idea what for player may use this flag, but to make it
> unambiguous the list should contain all 3 color filters variations (most
> popular Red/Cyan; Green/Purple; Yellow/Blue) and all marked which color left
> / right :-!!
> Top/Bottom, Side-By-Side and dedicated streams per view are really most
> demand by users. Others - device-specific formats and I hard to understand
> what for some person or software/hardware will create MKV in these formats.
> In fact, I really don't care who and why this list was created so huge. But
> I really sad that left/right options are lost!
> I understand that these options are not unambiguous in case of 3+ video
> streams in the container.
> In this case simple additional enumeration may be used (Left, 1; Left, 2;
> Right, 1; Right, 2) but to remove at all - not good solution.
>> While TrackCombinePlanes are a solution for new content with separate
>> video streams, they do not solve the playback problem with files muxed
>> according to the old specification.
> 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?
> Thanks!
> -----------------------------------------------
> Kirill Gavrilov,
> Software designer.
> official site: sview.ru
> e-mail: kirill at sview.ru
> _______________________________________________
> 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

Steve Lhomme
Matroska association Chairman

More information about the Matroska-devel mailing list