[Matroska-devel] Opus in Matroksa Cont.
slhomme at matroska.org
Sat May 25 10:16:04 CEST 2013
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:
> 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,
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> Read Matroska-Devel on GMane:
Matroska association Chairman
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Matroska-devel