[Matroska-devel] Opus in Matroksa Cont.

Frank Galligan frankgalligan at gmail.com
Tue May 28 17:48:26 CEST 2013


How about?

PreSkip, 3, [56][AA], Mandatory, Not Multiple, No Range, Default 0, Type i
(Negative codec delay?),
Description:
PreSkip is the duration in nanoseconds of the pre-skip data. The track
pre-skip data is prepended to the encoded track data. The pts of the Track
encoded data is shifted by PreSkip.



Should we name the element CodecDelay instead?


PostPadding, 3, [75][A2], Mandatory, Not Multiple, No Range, Default 0,
Type i (Negative?),
Description:
PostPadding is the duration in nanoseconds of the padding added to the last
Block. The duration of PostPadding is not calculated in the duration of the
Track and should be discarded.

Should we just name this Padding? or BlockPadding?



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

> 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
>
> _______________________________________________
> 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/20130528/8979f632/attachment.html>


More information about the Matroska-devel mailing list