Changes

Jump to: navigation, search

MatroskaOpus

1,808 bytes added, 17:50, 3 June 2013
Handling Pre-skip data
SeekPreRoll is a new unsigned integer element added to the TrackEntry element. The value is the number of nanoseconds that must be discarded, for that stream, after a seek until the decoded data is valid to render.
Block timestamps will match how all other Codecs are handledPreSkip [56][AA] is a new unsigned integer element added to the TrackEntry element. I.eThe value is the number of nanoseconds that must be discarded, for that stream, from the start of that stream. The Block timestamp value is also the starting time number of nanoseconds that all encoded timestamps for that stream must be shifted to get the first PCM sample position in nanosecondspresentation timestamp. (This will fix Vorbis encoding as well.)
PostPadding [75][A2] is a new signed integer element added to the BlockGroup element. PostPadding is the duration in nanoseconds of the silent data added to the Block (padding at the end of the block). The duration of PostPadding is not calculated in the duration of the Track and should be discarded during playback. (This will fix Vorbis encoding as well.)  (TODO) Define layout of CodecPrivate.
== Muxing Recommendations ==
<ul>
<li>If the CodecPrivate is empty or not present and Channels is 1 or 2, players MAY treat it as a sane set of defaults, I guess. e.g. channel mapping family 0, no pre-skip or gain. For Channels > 2 the track MUST be rejected, since there's no way to map the encoded substreams to channels.
</li>
</ulli <liFor Channels >How does 2 the OpusHead pre-skip field interact with the timestamps?</li> <ul> <li>The SimpleBlock timestamp is signed 16 bitstrack MUST be rejected, so the format can signal about half of since there's no way to map the pre-skip if playback timestamps are encoded substreams to start at zero. Moritz suggests this won't work because the resolution of the timestamps is controlled by the muxer, so the SimpleBlock timestamp offset isn't sample accurate anyway.[[http://lists.matroska.org/pipermail/matroska-devel/2012-September/004254channels.html ref]]
</li>
  <li>One could set an incorrect timestamp on the skipped blocks, and rely on the decoder We would also have to drop them based decide on the OpusHead preskip a default value. As long as the initial blocks are timestamped <= start of output this shouldn't affect seekingfor OutputGain.
</li>
  <li>The SimpleBlock structure also has an 'invisible' bit, which tells the player to decode, but not display, the contained frames. This lets the muxer signal the pre-skip semantics with frame accuracy, but not sample accuracy. If players implement this it will at least help with sync. Libav does not appear to support the invisible bitVersion must be 1.
</li>
</ul>
 
<li>How important is it that timestamps start at zero in a Matroska file?</li>
<li>How can sample-accurate end-time trimming work in Matroska?</li>
<ul>
<li> We defined a new element added to a BlockGroup, PostPadding, which is defined as the number of nanoseconds to discard from the Block.
</ul>
<ul>
<li>Currently all software encapsulating Vorbis in Matroska is broken in this regard, and muxing a Vorbis file in Matroska causes it to get longer (i.e., produce more audio output than the original Ogg file). It would be unfortunate to repeat this disaster for Opus. This needs a new element specifying the number of samples to trim, perhaps a new BlockGroup child.
</li>
<ul>
<li>This has been addressed with PostPadding for Opus. PostPadding was speced to fix Vorbis (as well as other codecs) too.
</li>
</ul>
</ul>
== Handling Pre-skip data ==
 
<ul>
<li>'''On [http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel [Matroska-dev]] we decided to implement proposal one. [http://lists.matroska.org/pipermail/matroska-devel/2013-June/004475.html[ref]]'''
</li>
</ul>
<ul>
<li>UC3: Playback starts from the middle of the stream > SeekPreRoll time.</li>
<li>UC4: Playback starts from the middle of the stream < SeekPreRoll time.</li>
<li>UC5: Encode source stream to Opus, mux to Matroksa, then decode Opus stream, must have same number of samples as source stream.</li>
</ul>
</ul>
 
<ul>
</ul>
<li>seven: Negative timestamps.</li>
<ul>
<li>
The SimpleBlock timestamp is signed 16 bits, so the format can signal about half of the pre-skip if playback timestamps are to start at zero.
</li>
<li> One could set an incorrect timestamp on the skipped blocks, and rely on the decoder to drop them based on the OpusHead preskip value. As long as the initial blocks are timestamped <= start of output this shouldn't affect seeking.
</li>
 
<li>Cons:</li>
<ul>
<li>Moritz suggests this won't work because the resolution of the timestamps is controlled by the muxer, so the SimpleBlock timestamp offset isn't sample accurate anyway.[[http://lists.matroska.org/pipermail/matroska-devel/2012-September/004254.html ref]]</li>
</ul>
</ul>
</ul>
 
== Proposal 8 ==
 
The Ogg format uses granule positions which are converted to presentation
timecodes using codec specific information on a per logical stream basis.
The Matroska format uses absolute timecodes with an arbitrary per
segement accuracy for all tracks in the segment.
 
It is the belief of this tikiman that using a timecode offset of any kind in MKV is unholy.
 
The preskip is communicated to the media software via the Opus header
in the codec private data. At the begining of the track, the track
timecode is not increased until prekip samples are in track frames.
From then on audio is muxed as normal, however the audio should be
muxed >= 3840 samples behind video frames.
 
* i.e. Cluster Timecode: 5.000 seconds
* Video Track Key Frame 5.000 seconds
* Opus Track Frame 4.920 seconds
18
edits

Navigation menu