Changes

Jump to: navigation, search

MatroskaOpus

4,779 bytes added, 20:32, 12 April 2013
Handling Pre-skip data
Block timestamps will match how all other Codecs are handled. I.e. The Block timestamp is the starting time of the first PCM sample position in nanoseconds.
If (TODO) Define layout of CodecPrivate.  == Muxing Recommendations == In order to prevent extraneous parsing of muxed content for the CodecPrivate players that want to start playback at exactly time T, we will recommend muxers create files with another Cluster within N-1 at T-SeekPreRoll, where T is empty or the start time of Cluster N. Then add CuePoints for all the new T-SeekPreRoll Clusters with a CueTrack of the audio stream. The CuePoints for the video stream will not present change.  For example, a file is a muxed MKV with the following characteristics:- 5 second interval between video keyframes- Each video keyframe begins a new Cluster- Cues will contain video keyframe CuePoints- For each video keyframe at time T there will be new Cluster at T-SeekPreRoll- Cues will contain audio CuePoints for T-SeekPreRoll Clusters- Audio and Channels video are interleaved in monotonically increasing order Assume SeekPreRoll is 1 or 280 milliseconds, players MAY treat it as the first Cluster starts at 0 milliseconds with a video keyframe Block and has a duration of 4920 milliseconds. The second Cluster starts at 4920 milliseconds with an audio Block and has a sane set duration of defaults80 milliseconds. Just to be clear, I guessthe second Cluster can contain Blocks from all streams. eThe third Cluster starts at 5000 milliseconds with a video keyframe Block and has a duration of 4920 milliseconds.gThe fourth Cluster starts at 9920 milliseconds with an audio Block and has a duration of 80 milliseconds. channel mapping family 0, no pre With this recommendation players that want audio and video to start playback at time T can seek to Cluster T-skip or gainSeekPreRoll and start decoding the audio stream. For Channels > 2 This will work the track MUST be rejected, since there's no way to map the encoded substreams to channelssame for both local and HTTP playback.
== Open Questions ==
Seeking <ul> <li>Should we say muxers MAY or SHOULD NOT produce simple streams without filling in Opus files requires CodecPrivate?</li>  <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-roll (recommended to skip or gain. For Channels > 2 the track MUST be at least 80 ms). Howeverrejected, currently Matroska requires its index entries since there's no way to point directly map the encoded substreams to channels. </li> </ul>  <li>How does the data whose OpusHead pre-skip field interact with the timestamps?</li> <ul> <li>The SimpleBlock timestamp matches is signed 16 bits, so the format can signal about half of the corresponding seek pointpre-skip if playback timestamps are to start at zero. Moritz suggests this won't work because the resolution of the timestamps is controlled by the muxer, not some place arbitrarily before that so the SimpleBlock timestampoffset isn't sample accurate anyway.[[http://lists.matroska.org/pipermail/matroska-devel/2012-September/004254. These two requirements html ref]] </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 incompatibletimestamped <= start of output this shouldn't affect seeking. </li>  <li>The SimpleBlock structure also has an 'invisible' bit, and mean 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 bit. </li> </ul>  <li>How important is it that seeking timestamps start at zero in a Matroska file?</li>  <li>How can sample-accurate end-time trimming work in Matroska?</li>  <ul> <li>Currently all software encapsulating Vorbis in Opus will be Matroska is broken in all existing this regard, and muxing a Vorbis file in Matroska softwarecauses it to get longer (i. In particularly unlucky cases (e.g, 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> If new elements are required, around can they be defined so as to enable correct seeking in rolling intra (a transient.k.a intra refresh), playing back video as well? </li> <ul> <li>SeekPreRoll should work for rolling intra video.</li> </ul> </ul> == Handling Pre-skip data == <ul> <li>Use Cases:</li> <ul> <li>UC1: Playback starts from the beginning of the stream. Source stream time starts at 0.</li> <li>UC2: Playback starts from the beginning of the stream. Pre-skip data ends in middle of compressed packet.</li> <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> </ul></ul>  <ul>  <li>one: Timeshift the timestamps by pre-skip data <ul> <li> The Opus audio decoded without any stream pre-roll can produce extremely loud (possibly equipmentskip data starts from time 0 and adds the pre-damaging) resultsskip time to the normal audio time, like how Opus files are muxed into ogg files. We need would add a new element to signal thisthe TrackEntry element, PreSkip, and the player would adjust the timestamps of the decoded samples by subtracting PreSkip. All use cases should be covered. </li>  <li>Cons:</li> <ul> <li>The timestamp of the Block does not match the timestamp of the playback position.</li> <li>Does not generalize known "decode, but not render" data.</li> <li>Forces the player to handle the pre-skip samples. I.e.gnot the decoder.</li> </ul>  </ul>  <li>two: Add pre-skip data to CodecPrivate.</li> <ul> <li> On every discontinuity the decoder would need to decode and throw away the pre-skip data. </li>  <li>Cons:</li> <ul> <li>UC2 will throw away valid data and the AV sync will be off.</li> <li>UC3 will redundantly decode the pre-skip data.</li> </ul>  </ul>  <li>three: Add TimeToDiscard to Block.</li> <ul> <li> Add an element to the Block element, TimeToDiscard in nanoseconds. A value of -1 would not render the whole Block, which would have the same effect as setting the invisible bit. TrackHow would this affect the Block timestamp? Maybe the new element should be SamplesToDiscard or DataToDiscard? </li>  <li>Cons:</li>  </ul>  <li>four:TrackEntryBlocks that contain pre-skip data will set invisible flag.</li> <ul> <li> Blocks that contain pre-skip data have timestamps from the beginning of the stream. Blocks that only contain normal data have timestamps from the playback position. </li>  <li>Cons:</li> <ul> <li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li> <li>UC2 will throw away valid data and the AV sync will be off. Other use cases should be fine.</li> </ul>  </ul>  <li>five:PreRollForce pre-skip packets to be prepended to the first normal packet in the first Block.</li> <ul> <li> The first Block's timestmap will be set to the start time of the source playback position. We would add a new element to the TrackEntry element, PreSkip. All use cases should be covered. </li>
Should we say muxers MAY or SHOULD NOT produce simple streams without filling in CodecPrivate? <li>Cons:</li> <ul> <li>Does not generalize known "decode, but not render" data.</li> <li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li> </ul>
How does the OpusHead pre-skip field interact with the timestamps? 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. 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]]ul>
One could set an incorrect timestamp on <li>six: Create a new codec, OPUS_MKV.</li> <ul> <li> Basically the skipped blocks, and rely on codec will wrap Opus packets with data telling the decoder what type of Opus packet it contains. Essentially we would be creating a new codec to drop them based on handle pre-skip data within the OpusHead preskip valuedecoder. As long as the initial blocks are timestamped <= start of output this shouldn't affect seeking./li>
How important is it that timestamps start at zero in a Matroska file? <li>Cons:</li> <ul> <li>There will be two types of Opus data streams!</li> <li>Does not generalize known "decode, but not render" data.</li> </ul>
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 bit. </ul>
How can sample-accurate end-time trimming work in Matroska? 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.
If new elements are required, can they be defined so as to enable correct seeking in rolling intra (a.k.a intra refresh) video as well?</ul>
18
edits

Navigation menu