[Matroska-devel] Opus in Matroksa Cont.

Steve Lhomme slhomme at matroska.org
Sat May 25 10:17:53 CEST 2013

Also I agree that we don't need this for Opus. But I think we're close to a
working solution.
On the other hand, if we decide the PreSkip is scaled, it's in the track,
so will benefit from a future update of the TrackTimecodeScale we're
talking about.

So do we agree on PreSkip ? We need an ID and a description.

We can still continue the fractional timestamp in parallel.

On Sat, May 25, 2013 at 10:16 AM, Steve Lhomme <slhomme at matroska.org> wrote:

> I agree with all that's said. But the goal is not to fit the new system to
> make it compatible with the old one, but to make the old one compatible
> with the new one, when the muxer picks sample accurate timecodes. We just
> know it's possible to make it work.
> About seeking. No matter what the resolution of the timecode, if you want
> to seek in the middle of 512 samples, you will need to decode the whole
> block that has the timecode just before the one you're looking for. The
> precision is not taken in account.
> On Sat, May 25, 2013 at 9:35 AM, Moritz Bunkus <moritz at bunkus.org> wrote:
>> Hey,
>> if your current timecode scheme is not sample-precise then scaling it
>> by a factor won't make it sample-precise. If a raw timecode of 1000
>> represents a full second then there is simply no way to express
>> sample-precision with such a low value for anything that uses a
>> sampling frequency higher than 1000 Hz -- e.g. all audio codecs.
>> Also: using the number of samples per packet as the numerator would
>> make timecode resolution a lot worse than it is with ms precision and
>> timecodes. A lot of times people want to shift audio or video by
>> amounts that are not simply a multiple of the basic interval (with
>> basic interval meaning the duration of a single frame for videos or a
>> full audio packet).
>> This simply won't work... So please can we drop the idea of cramming a
>> numerator/denominator scheme into this? We don't need it in order to
>> make a useful spec for Opus, and as can be seen by this discussion
>> doing so is far from trivial and requires a lot of thought. This
>> delays the implementation of Opus unnecessarily in my opinion.
>> Kind regards,
>> mosu
>> _______________________________________________
>> Matroska-devel mailing list
>> Matroska-devel at lists.matroska.org
>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>> Read Matroska-Devel on GMane:
>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
> --
> Steve Lhomme
> Matroska association Chairman

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

More information about the Matroska-devel mailing list