[Matroska-devel] Multi-Angle

Moritz Bunkus moritz at bunkus.org
Fri Sep 17 09:21:15 CEST 2004


Hey,

> - handle each angle as a separate video track

Sucks.

> - put the angles in the same track sequentially, and jump to other part 
> of the movie when using "managed" chapters (a bit ugly, especially 
> timecode-wise)

Sucks.

> - add support in Matroska frames/block for an angle number.

Sucks.

> IMO the latter is the cleanest. Any opinion ?

A fourth.

Ok, after being harsh I should explain why I think that all three
options suck.

What I would like to see is that multiangle files can be played on
current demuxers without throwing up (if they're bug free). Of course
current demuxers cannot select the other angles, but they should be able
to play the default angle completely without hickuping.

1. 'Seperate video track'

Bad because the players would think that there IS actually another video
track. The user might then select that video track and the player would
probably go to hell because it doesn't receive data for a long time,
only where there are two angles.

2. 'Put angles in the same track sequentially'

Bad because a) timecodes would not be continous, b) current demuxers
would show all angles after another totally breaking A/V sync, c)
interleaving would be completely off, d) would be non-compliant with the
specs (see BlockDuration, "When not written and with no DefaultDuration,
the value is assumed to be the difference between the timecode of this
Block and the timecode of the next Block in "display" order (not coding
order).")...

I could find even more arguments against it. 2 simply sucks.

3. 'add support in Matroska frames/block for angle number'

Nearly the same arguments as in 2. Mainly it would break playback on
current demuxers.

----------

My proposal is that we should create a new _track type_ for this kind of
thing. At the moment six track types are defined and three are used
(audio, video, subtitles; complex, logo, control). I'd like to add a
track that is 'associated' with another track. The track headers would
ONLY contain two or three (new) elements:

- TrackID, TrackUID (needed, currently used as well),
- TrackAssociatedUID (the track UID this track refers to),
- TrackSubID ("angle number", sub-ID for this track, defaults to 0,
  must/may also be written for the "main" track)

All the other elements must not be present. The "associated" track has
the same properties as the track it is associated to.

The data packets ( = blocks) are interleaved normally according to their
timecode. At those places where there are several angles available the
player can display other angles if the user/control wants that. This
would need small buffering IF and ONLY IF the sub-ID is != 0. If it is 0
then the demuxer can simply send all packets for that track
downstream.

If the sub-ID is != 0 then the player has to buffer exactly one packet
for that track. It reads until it finds either a packet with the same
timecode for the WANTED sub-ID or until it finds another packet with a
different timecode for the "main" stream.

Advantages:

- Current demuxers will see unknown tracks and skip them.
- Current demuxers will see blocks for a track they don't handle, so
  they just skip them.
- The overhead will not increase.
- We make use of Matroska's extensibility without requiring the user to
  update software -- only if they WANT the new features. "Normal" files
  created with those new tools will still play with old/current players.
- Those new files will be just as spec compliant as current ones
  are. Interleaving is kept intact.

Disadvantages:

None that I can see.

What do you think?

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds



More information about the Matroska-devel mailing list