[Matroska-devel] Opus in Matroksa Cont.

[Steve Lhomme]

Hi everyone, sorry being late to the party, I don't have much "me time"
lately.


On Fri, Mar 22, 2013 at 10:24 PM, Frank Galligan <frankgalligan at gmail.com>wrote:

> *
>
> Open issues from [1] I want to address:
>
> 1. Seeking in Opus streams requires a pre-roll.
>
> 2. How does the OpusHead pre-skip field interact with the timestamps?
> *
>

First question that doesn't seem to be answered from past conversations: is
the pre-roll a constant time, a contact packet of data or not even
something constant ? It seems to be a constant time, given this but I want
to make sure we're on the same page.
http://tools.ietf.org/html/draft-terriberry-oggopus-01#section-4.2
Also pre-roll and pre-seek were mentioned. Are they actually the same thing
? I assume they are. (if not my following comments are only on pre-seek)

If it's a constant then all timecodes of the Opus track can be shifted of
that value to have the data to "render" or to "decode" (so it renders
properly at the time needed). I think for simplicity it's easier if that
shift is not visible at the muxer/demuxer level. That will avoid all kinds
of possible issues. While shifting time at the codec level is a very simple
operation. So I think the cleanest way to do that is let the codec do its
sample/timecode shift internally, by setting the pre-roll time in the
CodecPrivate, with a format to decide.

*
>
> 2.2 The pre-skip data must be contained in the first audio Block (or maybe
> in the CodecPrivate) with non-pre-skip encoded data.
>
> *
>
*
>
> Pros:
>
> - No demuxer changes to handle Opus audio. Only the decoder will need to
> know about the pre-skip data.
>
> - Block timestamps will match decoded timestamps for all time T.
>
> - No PreSkip element in the TrackHeader. The decoder will still have
> pke-skip from the CodecPrivate data.
>
> - No negative timestamps.
>
> Cons:
>
> - Data may need to be added to all Opus Blocks to delimit the pre-skip
> data.
> *
>

If it's just a timecode shift there is no additional data (apart from when
decoding starts) compared to the normal decoder flow.


> *
>
> - Does not help future formats that need a PreSkip.
> *
>

If a codec needs data pre-prended or non constant pre-skip then we may not
have a generic enough solution anyway.


> *
>
> - Muxers may have to special case the pre-skip data.
> *
>

I don't see how. The timecode shift is transparent outside of the codec.
The CodecPrivate data HAS to be passed to the codec, nothing is new here.


> *
>
> Questions:
>
> Can the decoder assume that a packet of timestamp 0 will have to decode
> and throw out pre-skip samples? Then we wouldn’t need to delimit all of the
> Opus Blocks.
> *
>

I think the codec should not output the pre-skip samples, ie samples before
0. After seeking the same should apply: samples that are in the pre-skip
timeframe should not be sent to the renderer as they are just there to get
the codec started internally and to avoid having garbage if decoding was
started right away.

-- 
Steve Lhomme
Matroska association Chairman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20130331/3f2f8673/attachment.html>