[Matroska-devel] Re: WavPack in Matroska

Paul Bryson paul at msn.com
Sun Jul 4 01:17:34 CEST 2004

"Steve Lhomme" wrote...
> IMO, we should add a new element for such a case. It's not a
> CodecPrivate data for each frame, but rather a secondary stream that
> makes sense only with the first one... So we have 2 choices :

> - add a track property to state that the track is not to be played and
> correspond to data for track XYZ. IMO that's not very clean and not
> backward compatible.

This element already exists on the Video side.
Adding it to the audio side of things seems like a pretty small task.  As far as
DirectShow goes, it shouldn't be hard to create two pins from the splitter, one
for the lossy data, and one for the correction data.  Then the decoder has two
input pins, one for each.  If there is only the lossy pin connected, then it
decodes lossy.  If both are connected, then it decodes both.  This makes it
necessary to create a seperate CodecID for the correction data.  Maybe somthing

The benefit of using two tracks is that because it uses the existing structures,
nothing really has to be rewritten to take advantage of it.

> - add a new element to the BlockGroup with a SecondaryData item. That's
> clean. But it only makes sense if the complementary data in WavPack is
> on a frame/block basis. David ??? This way it would be easy to have an
> option in mkvmerge like --strip-secondary to get only the lossy part of
> a content (could apply to other things too). If we go this way, we
> should investigate a bit more if it could be generalised to more
> content/codec/features.

>From David's reply, it appears that they share the exact same number of
samples/block.  This would certainly allow the use of another element in the
BlockGroup that indicates that it is an " optional enhancement" that is
bandwidth sensitive.

The benefit of this method is that it would use less overhead since it is using
the same BlockGroup and timecode data from the Block.


More information about the Matroska-devel mailing list