[Matroska-devel] Opus in Matroksa Cont.

Steve Lhomme slhomme at matroska.org
Wed May 29 21:24:49 CEST 2013


Didn't we say it should be "scaled" ie using the timecodescale ? Or is the
usual ms resolution too bad for that ? IMO it's fine. And as said before,
the sacling might benefit from future enhancements. The description should
say if it's scaled then.

I think PreSkip is more explanatory that CodecDelay.

A negative PreSkip would make no sense, so unsigned is fine.

Also, it doesn't say here, but PreSkip is a child of TrackEntry and
PostAdding a child of BlockGroup.

Are we all on the same page ?


On Tue, May 28, 2013 at 5:48 PM, Frank Galligan <frankgalligan at gmail.com>wrote:

> 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
>>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20130529/40eb6a4b/attachment.html>


More information about the Matroska-devel mailing list