[Matroska-devel] New lacing

Steve Lhomme steve.lhomme at free.fr
Sat Oct 25 10:50:36 CEST 2003

Moritz Bunkus wrote:
> Hi.
>>Read & Write of different lacing methods is now supported, although it
>>needs more testing (with various sizes/methods).
> I've done a lot of coding/bug hunting/bug fixing tonight. I've
> implemented LACING_AUTO and fixed a couple of bugs you had produced in
> your new lacing code (and already committed it to CVS). LACING_AUTO will
> chose the best lacing method for each block automatically (Xiph, Ebml of
> fixed). If Xiph and Ebml are equally small then Ebml is chosen ;)
> Some numbers:
> 1) Source is a 800MB OGM file (one video track, one Vorbis track). Small
>    Vorbis packets let me expect that Xiph will be used rather often.
>    A very, very small gain only (181 bytes).
> 2) Source is a 700MB AVI (one video track, one VBR MP3 track). VBR means
>    different packet sizes, so fixed won't be used too often, but packets
>    are so big that Xiph will be inefficient most of the time.
>    A more substantial gain (128583 bytes).
> 3) Source is a 350MB AVI (one video track, one AC3 track). As AC3 is CBR
>    we should be able to have a lot of, or only, fixed lacing situations.
>    Definitely a substantial gain (317869 bytes).
> Summary: LACING_AUTO is the winner. The CLEAR winner :)
> Note: This code needs testing!

Wonderful work, as usual !!! These gains should be enough to convince 
people to update their tools.

I was going to implement it later. Now I'm going to improve the 
EBML-coded-size decoding, as it currently doesn't allow SizeUnknown. 
When it will I'll modify FindNextElement() and FindNextID() to use it.

Also the good thing is that these routines are in C so could be used in 
an EBML C library or any other code (like Gabest's muxer/demuxer).

More information about the Matroska-devel mailing list