[Matroska-devel] Opus in Matroksa Cont.
giles at thaumas.net
Fri Apr 12 21:15:14 CEST 2013
On 13-04-12 10:35 AM, Frank Galligan wrote:
> First, the number of samples to be skipped is not an integer multiple of
> compressed packets, so this isn't actually possible without clipping
> valid audio from the start of the stream.
> Ahh, this was one of my earlier questions.
> I don't think we should worry about a decoder that ignores CodecPrivate.
> Current decoders must handle CodecPrivate, so I think we can treat
> decoders that ignore CodecPrivate as broken.
Well sure, but they're less broken with Opus than with e.g. Vorbis,
which can't work at all. For mono and stereo Opus files, the only thing
that needs to be signaled outside the data stream is exactly the preskip
value. So ignoring CodecPrivate for Opus is no worse than not
implementing any hypothetical preskip element.
> Having to feed and then discard output from special data in CodecPrivate
> is moving away from a general container-level solution to this
> I agree.
> which is generally useful for other codecs as well, to
> implement trimming.
> Yes, I was leaning to include the data in CodecPrivate so we didn't need
> to change all players to handle this feature, as we could potentially
> hide it in the specific decoder.
Where is the specific decoder going to live though? Are you planning to
distribute a wrapper with which accepts the CodecPrivate data? Do you
think we should add that to the libopus API?
> If we truly think this will be useful
> to other codecs (currently or in the future) then we can try and
> generalize this feature.
Maybe it's helpful to think of video here. If I press 'record' in the
middle of a WebRTC session, how do we reprent the start point which
won't generally fall on a keyframe?
> Maybe we can 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. Otherwise the
> player would need to discard TimeToDiscard time. This should satisfy
> "preskip data does not have to be an integer multiple of compressed
> packets", while also preserving the timestamp of the Block matches the
> timestamp of the playback position.
Or under the TrackEntry element? Since it only happens at the start of
the track in the use cases I can think of.
I think you're still missing part of why the Ogg mapping shifts the
timestamp though. Part of what pre-skip is for is to account for
algorithmic delay. The encoder has some. If the original input isn't 48
kHz, then it went through a resampler, which can also have some. So
shifting the timecode is _necessary_ for sync. Without it, a peak in the
output won't align with a peak in the input.
More information about the Matroska-devel