[Matroska-devel] Opus in Matroksa Cont.
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, [AA], Mandatory, Not Multiple, No Range, Default 0, Type i
> (Negative codec delay?),
> 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, [A2], Mandatory, Not Multiple, No Range, Default 0,
> Type i (Negative?),
> 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:
>>>> 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:
>>> Steve Lhomme
>>> Matroska association Chairman
>> Steve Lhomme
>> Matroska association Chairman
>> Matroska-devel mailing list
>> Matroska-devel at lists.matroska.org
>> Read Matroska-Devel on GMane:
> 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