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

Moritz Bunkus moritz at bunkus.org
Wed Jun 25 10:22:00 CEST 2003


Heya.

> 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).

Well I'm not so sure if this should be automatic, although it'd be good
for spec compliance, of course. At the moment I'm ok with what I've
implemented myself, it's not that much code (maybe 20 lines).

> 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).

> 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).

No, 1024 is used as often as the three others together. Here's a typical
distribution (for the 800megs sample file I mentioned in my last email):

 244706 1024
  81674 128
  27815 576
      1 64

So it HAS to be 1024, everything else would a yet another minor waste of
space :)

> 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:

> >    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).

On the other hand that would break backwards compatibility. So maybe
adding another element would be better...

But I strongly believe that we should add something like that in order
to keep the number of BlockDuration elements that have to be written to
a minimum.

> IMO it's not a capital MAJOR as you said it first. I expected something much
> worse !

:)

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

Yes, I know, at the moment I work with ms precision internally. I'll
have to change that to us or ns (us will suffice, I hate too long
numbers ;)) this week. Major task with more places to introduce bugs
than an anthill has ants :)

> 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.

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



More information about the Matroska-devel mailing list