[Matroska-devel] SV7 to SV 8 conversion for matroska integration : call for opinions
Christian HJ Wiesner
chris at matroska.org
Sun Nov 16 23:30:18 CET 2003
please use the 'reply all' button of your mail client when replying, so
all lists get copied.
Frank convinced us that using SV7 in matroska is maybe not a good idea.
Therefore the matroska team was discussing a couple of options today
about MPC integration into matroska :
1. Wait for Frank to write a SV7 to SV8 'repacker' tool. This would
slightly increa'se overhead, but this way old existing SV7 files could
be packed into matroska, and all existing encoders could be used for
movie soundtrack encoding
2. Make an encoder filter for DirectShow or a little CLI app with
libmatroska based on Frank's 'alpha' SV8 encoder, which seems to be
quite usable and according to Frank was tuned to overcome some reported
sound limitations in the existing SV7 encoder. We could tag the current,
'alpha SV8 bitstream' as SV 7.2 , SV 7.5 or even SV8, and write the
blocks directly into matroska files, stripping even the block size from
the SV8 alpha bitstream to become as independant as possible from future
bitstream changes. The chances are good that these files would be 100%
SV8 compatible. If not, we could tag them differently, or convince Frank
to make SV9 instead of SV8 ;-) ....
3. matroska has a very powerful and complex lacing and frame handling
system, allowing us to even mux SV7 streams into matroska files, without
breaking the specs. For this case we could put 32 MPC frames into a
single matroska block and use either the enhanced EBML lacing or the
so-called time-slices, allowing us to group a complete 'self-decodable'
group of blocks into one matroska block. That way we even dont care if
single bits of one frame are attached to other frames, as they form an
entity in the matroska file.
I would like to hear your opinions on that. Everybody is clearly invited
to tell us his personal opinion about this, even if its not technically
More information about the Matroska-devel