[Matroska-devel] Opus in Matroksa Cont.

Frank Galligan frankgalligan at gmail.com
Sat May 25 00:00:15 CEST 2013


Okay, I'm fine with the units being nanoseconds. In theory, at worst we
would be off one sample due to rounding, but in practice I think we will be
fine more often than not.


On Fri, May 24, 2013 at 2:11 PM, Moritz Bunkus <moritz at bunkus.org> wrote:

> Hey,
>
> > I think making a big backwards-incompatible change is fine, at some
> point. I just don't think
> > trying to accurately represent how the encoders/muxers currently handle
> codec delay and
> > padding, warrants that kind of change.
>
> I agree with both statements. At one point we may have to take it to
> the next level and include a lot of incompatible changes including
> re-working how timecodes are calculated. But this doesn't seem to be
> the time for it. We have to easy-to-use solutions for representing
> preroll: either in samples (with "fields" being the "sample rate" for
> video tracks) or with a timecode that is not scaled by timecode scale
> (like we do with other elements), meaning a value representing a
> number of nanoseconds.
>
> Of those two I'd prefer the timecode-based version -- simply because
> it's a tiny bit more flexible (we could then use that field for other
> things that don't have a sample rate like subtitle tracks).
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20130524/48b1815a/attachment.html>


More information about the Matroska-devel mailing list