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

Steve Lhomme steve.lhomme at free.fr
Wed Jun 25 10:45:08 CEST 2003


> Heya.

Yo,

> > 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.
>
> Sure, I totally agree. I've argued in favour of blockduration everywhere
> from time to time, and I haven't changed my mind. It's just that for
> Vorbis file it's an overhead of over 1meg at 700megs - if we keep adding
> 'features' at this rate then we'll be bigger than the original ogm
> file. Ok to be honest I don't see any other features that are more or
> less mandatory and that take so much space (EDC is totally optional).

Well, when matroska was released I wasn't much into comparing sizes, because
the format/code didn't have all the tags implemented yet. And we know EBML
is verbose (that's why we try to make additions as small as possible).
That's why I'm still surprised we can do better than OGM.

> > 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.
>
> Ah. At the moment I don't write the BlockDuration - for the reason b)
> that I mentioned:

Yes, but it's good to have a more final accurate value. (nothing is exactly
accurate of course).

> > >    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...
>
> This could be solved by adding Yet Another Header Element(tm). OR by
> redefinig the DefaultDuration so that it is the default duration for a
> single block, not for the complete blockgroup. Therefore a blockgroup
> with more than one block would only need a blockduration in the
> 'variable number of samples per block' case (--> Vorbis), but not for
> formats with a fixed number of samples per block (MP3, PCM, AAC, AC3).

Yes. I'll have to think about this. Or maybe we make each (BlockDuration,
SliceDuration) exclusive. We have a bigger rounding problem. But only for a
few frames. If you have 1.3 + 1.3 + 1.3 you don't expect to have frames with
these durations : 1 + 1 + 2 ? I don't know if it's better or worse than 1 +
1 + 1.

> > 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.
>
> The scaling has a drawback as well, of course - the maximum duration of
> a cluster decreases with the increase in precision. With ms precision
> it's 65.535 seconds. The only 'valid' compromise that I could see would
> be a precision of about 100us and a maximum cluster length of 6.5535
> seconds. Of course all those longer numbers will take up more space than
> the shorter ones with ms precision. Again a no win-win scenario.

Yeah, but I think 6s for a Cluster is still a lot (for resync matters). So
I'm OK for 100us. Actually we already mentioned that it would be good to
have the precision a multiple of the video framerate. Actually it should be
better scaled to the more restrictive (not precise) audio framerate, as it's
used for the clock (always with audio only, and probably always with video
too). So in the case of 48000Hz it would be a multiple of 1/48000s (20.8333
us), ie 12x is good : 250us. For 44100 it would be 272us.


http://www.matroska.org



More information about the Matroska-devel mailing list