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

[Moritz Bunkus]

Heya.

I've taken the time to implement timeslices. Here's what I did:

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.

This is no problem for all fixed sample rate formats (MP3, AAC, PCM,
AC3...) as for them all packets DO have the same duration - the default
track duration. Therefore no slices have to be added at all.

Unfortunately this is a MAJOR space hog for Vorbis :(

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.
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.
   b) If the block group contains more than one block then its duration
   is almost certainly different than the KaxTrackDefaultDuration.

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.

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.

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

-- 
 ==> Ciao, Mosu (Moritz Bunkus)
http://www.matroska.org