[Matroska-devel] New lacing

Moritz Bunkus moritz at bunkus.org
Sat Oct 25 00:05:48 CEST 2003


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

   Results (number of times a specific scheme was chosen for a block):
   lacing: fixed: 42, xiph: 41350, ebml: 3751

   File sizes:
   823805473 v-newauto.mkv
   823805654 v-old.mkv

   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.

   lacing: fixed: 1261, xiph: 15, ebml: 23407

   File sizes:
   730793618 v2-newauto.mkv
   730922201 v2-old.mkv

   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.

   lacing: fixed: 11559, xiph: 0, ebml: 0
   Bingo! :)

   File sizes:
   364724855 v3-newauto.mkv
   365042724 v3-old.mkv

   Definitely a substantial gain (317869 bytes).

Summary: LACING_AUTO is the winner. The CLEAR winner :)

Note: This code needs testing!

 ==> Ciao, Mosu (Moritz Bunkus)

More information about the Matroska-devel mailing list