[Matroska-devel] New lacing
steve.lhomme at free.fr
Sat Oct 25 10:50:36 CEST 2003
Moritz Bunkus wrote:
>>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