[matroska-devel] Re: time slices is a major space hog

Steve Lhomme steve.lhomme at free.fr
Wed Jun 25 09:58:30 CEST 2003


> Only if a block group contains more than one entry I used laces. A time
> slice is only created if the packet's duration is different than the
> KaxTrackDefaultDuration as stated in the specs.

Well, that's where I should add my sauce. I think I can make it automatic
and always add the timeslice when you add a frame (as you have to give the
duration of each frame), then only the ones that aren't the default value
will be written. (all these should be configurable).

> Unfortunately this is a MAJOR space hog for Vorbis :(

We knew that even before it existed :) But Vorbis is also THE reason why we
need to add it (maybe HE-AAC will need that too). As for many things in the
format, you are not forced to put TimeSlices if you really want to keep your
file small. But this is a new option to have more accurate timecodes. As
everything in this world, there is no win-win.

> Reasons:
>
> 1. Vorbis uses several numbers of samples per packet, mostly 128, 1024
>    and 2048 if I'm not mistaken (but others as well, e.g. 64 or 576. Yes
>    576, I'm not kidding). 128 is used rather seldom, 1024 is
>    used roughly as often as the other ones together. Therefore I set the
>    default duration to the one associated with 1024 samples.

If there is approx the same number of samples, you should set it to the
smallest duration. This way you put timeslice on the large frames (which is
nicer IMO).

> 2. There will have to be a lot of time slices - in about 40 to 50% of
>    all packets.
> 3. As the KaxBlockDuration's default value is ALSO the
>    KaxTrackDefaultDuration I have to add a lot of KaxBlockDuration
>    elements:
>    a) If the block group contains only one block then the duration must
>    be added in about 40 to 50% of all cases as 1024 and 2048 samples per
>    block occur roughly equally often.

Well, KaxBlockDuration should always be written, even if you don't use
TimeSlices (as it was the case so far). Because of the roundings, 1.3 + 1.3
+ 1.3 = 3.9 is different than 1 + 1 + 1 = 3. So it's good to have the sum
too.

>    b) If the block group contains more than one block then its duration
>    is almost certainly different than the KaxTrackDefaultDuration.

Yes. I agree there is a problem... The same duration is used when there is
one or more blocks...

> Here are some figures:
>
> Original OGM file:       829886456 bytes
> Matroska without slices: 824882356 bytes (diff: 5004100)
> Matroska with slices:    826028293 bytes (diff: 3858163)
>
> Ok, you might not call that 'major' but I do - especially as it does not
> gain us all that much.

IMO it's not a capital MAJOR as you said it first. I expected something much
worse !
The gain is that we have more accurate timing for each frame. This is
important IMO, because audio is used on most system as the clock reference.
We have found a way in the DSF of Matroska and Vorbis to rely only on
certain timecodes and consider other samples are contiguous. But maybe not
all systems can do that... That also means we have a better precision for
cutting a file...
Also TimeSlice will be usefull for codecs that can produce many frames from
a single buffer. But that's only in the future, for codec that don't exist
yet (where is GLDM ?).

> Yet another problem is like this:
>
> 1. The KaxTrackDefaultDuration is in ns, unscaled. High precision.
> 2. The KaxSliceDuration is in scaled units, so in ms in the normal case.
>
> The default duration for a lot of packets might be 21.333ms (in the case
> of Vorbis, 1024 samples, sampling frequency 48000). Now the current
> packet's number of samples is 128 samples which is 2.666ms - but I can
> only store 2ms.

Well, the rounding in this case should be 3ms.

> Dunno if this discrepancy is so bad that it might noticeable during
> playback but I thought i'd mention this.

That's whay we still need the BlockDuration. And keep in mind that the
scaling defines the precision the user want to achieve. If he chooses 1ms,
he *should not* expect better precision than that from the format.


http://www.matroska.org



More information about the Matroska-devel mailing list