MatroskaOpus - Revision history

J^: /* Handling Pre-skip data */ PreSkip -> CodecDelay

2013-06-18T13:28:43Z

Handling Pre-skip data: PreSkip -> CodecDelay

← Older revision		Revision as of 13:28, 18 June 2013
Line 101:		Line 101:
	<ul>		<ul>
	<li>		<li>
-	The Opus audio stream pre-skip data starts from time 0 and adds the pre-skip time to the normal audio time, like how Opus files are muxed into ogg files. We would add a new element to the TrackEntry element, ~~PreSkip~~, and the player would adjust the timestamps of the decoded samples by subtracting ~~PreSkip~~. All use cases should be covered.	+	The Opus audio stream pre-skip data starts from time 0 and adds the pre-skip time to the normal audio time, like how Opus files are muxed into ogg files. We would add a new element to the TrackEntry element, CodecDelay, and the player would adjust the timestamps of the decoded samples by subtracting CodecDelay. All use cases should be covered.
	</li>		</li>

Line 154:		Line 154:
	<ul>		<ul>
	<li>		<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.	+	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, CodecDelay. All use cases should be covered.
	</li>		</li>

J^: /* Open Questions */ more PostPadding->DiscardPadding

2013-06-18T13:27:16Z

Open Questions: more PostPadding->DiscardPadding

← Older revision		Revision as of 13:27, 18 June 2013
Line 56:		Line 56:
	<li>How can sample-accurate end-time trimming work in Matroska?</li>		<li>How can sample-accurate end-time trimming work in Matroska?</li>
	<ul>		<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.	+	<li> We defined a new element added to a BlockGroup, DiscardPadding(previously PostPadding), which is defined as the number of nanoseconds to discard from the Block.
	</ul>		</ul>

Line 63:		Line 63:
	</li>		</li>
	<ul>		<ul>
-	<li>This has been addressed with ~~PostPadding~~ for Opus. ~~PostPadding~~ was speced to fix Vorbis (as well as other codecs) too.	+	<li>This has been addressed with DiscardPadding for Opus. DiscardPadding was speced to fix Vorbis (as well as other codecs) too.
	</li>		</li>
	</ul>		</ul>

J^: /* DRAFT */ rename elements to be in line with latest version of the matroska spec

2013-06-18T13:25:25Z

DRAFT: rename elements to be in line with latest version of the matroska spec

← Older revision		Revision as of 13:25, 18 June 2013
Line 13:		Line 13:
	The second 'OpusTags' header packet from Ogg Opus is not used in the Matroska encapsulation. Matroska has its own system for tag metadata, and this avoids duplicating it and the need for sub-framing to index multiple packets within the CodecPrivate element.		The second 'OpusTags' header packet from Ogg Opus is not used in the Matroska encapsulation. Matroska has its own system for tag metadata, and this avoids duplicating it and the need for sub-framing to index multiple packets within the CodecPrivate element.

-	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.	+	SeekPreRoll [56][BB] 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.

-	~~PreSkip~~ [56][AA] 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, from the start of that stream. The value is also the number of nanoseconds that all encoded timestamps for that stream must be shifted to get the presentation timestamp. (This will fix Vorbis encoding as well.)	+	CodecDelay [56][AA] 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, from the start of that stream. The value is also the number of nanoseconds that all encoded timestamps for that stream must be shifted to get the presentation 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.)	+	DiscardPadding [75][A2] is a new signed integer element added to the BlockGroup element. DiscardPadding is the duration in nanoseconds of the silent data added to the Block (padding at the end of the block). The duration of DiscardPadding is not calculated in the duration of the Track and should be discarded during playback. (This will fix Vorbis encoding as well.)

Frankgalligan: /* Handling Pre-skip data */

2013-06-03T17:50:33Z

Handling Pre-skip data

← Older revision		Revision as of 17:50, 3 June 2013
Line 78:		Line 78:

	== Handling Pre-skip data ==		== 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>		<ul>
Line 89:		Line 94:
	</ul>		</ul>
	</ul>		</ul>
-
-	~~<ul>~~
-	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]]
-	~~</ul>~~
-

	<ul>		<ul>

Frankgalligan: /* Handling Pre-skip data */

2013-06-03T17:49:35Z

Handling Pre-skip data

← Older revision		Revision as of 17:49, 3 June 2013
Line 88:		Line 88:
	<li>UC5: Encode source stream to Opus, mux to Matroksa, then decode Opus stream, must have same number of samples as source stream.</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>
		+	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]]
	</ul>		</ul>

Frankgalligan: /* DRAFT */

2013-06-03T17:43:52Z

DRAFT

← Older revision		Revision as of 17:43, 3 June 2013
Line 15:		Line 15:
	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.		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.

-	PreSkip [56][AA] 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, from the start of that stream. The value is also the number of nanoseconds that all encoded timestamps for that stream must be shifted to get the presentation timestamp.	+	PreSkip [56][AA] 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, from the start of that stream. The value is also the number of nanoseconds that all encoded timestamps for that stream must be shifted to get the presentation 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	+	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.)

Frankgalligan: /* Handling Pre-skip data */

2013-06-03T17:41:13Z

Handling Pre-skip data

← Older revision		Revision as of 17:41, 3 June 2013
Line 86:		Line 86:
	<li>UC3: Playback starts from the middle of the stream > SeekPreRoll time.</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>		<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>

Frankgalligan: /* Open Questions */

2013-06-03T17:38:41Z

Open Questions

← Older revision		Revision as of 17:38, 3 June 2013
Line 54:		Line 54:
	</ul>		</ul>

-	<li>How ~~does the OpusHead pre~~-~~skip field interact with the timestamps~~?</li>	+	<li>How can sample-accurate end-time trimming work in Matroska?</li>
	<ul>		<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. 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> We defined a new element added to a BlockGroup, PostPadding, which is defined as the number of nanoseconds to discard from the Block.
-	~~</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>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~~.	+
-	~~</li>~~	+
	</ul>		</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>		<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>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>		</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>		</ul>

Frankgalligan: /* Handling Pre-skip data */

2013-06-03T17:29:26Z

Handling Pre-skip data

← Older revision		Revision as of 17:29, 3 June 2013
Line 191:		Line 191:
	<li>Cons:</li>		<li>Cons:</li>
	<ul>		<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.[ref]</li>	+	<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>

Frankgalligan: /* Handling Pre-skip data */

2013-06-03T17:28:29Z

Handling Pre-skip data

← Older revision		Revision as of 17:28, 3 June 2013
Line 180:		Line 180:

	</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.[ref]</li>
		+	</ul>

-	</ul>	+	</ul>

		+	</ul>

	== Proposal 8 ==		== Proposal 8 ==