[matroska-general] Re: [hxdiscuss] Re: Playing RealVideo/RealAudio content from other containers

Christian HJ Wiesner chris at matroska.org
Tue Jun 24 23:24:04 CEST 2003

Rob Lanphier wrote:

>It's entirely possible and legal to have a Matroska file format for the
>Helix DNA Client, Server, and Producer, and we would love to see that. 
>What's not legal is to put RealAudio or RealVideo data in a Matroska
>container. This is not a restriction that I'm personally wedded to.  Being the big,
>stupid company that we are (<g>), it's something that would take a fair
>amount of work for me to make the case we should allow this.  I'd be
>happy to make that case if I had a clear understanding of what new
>applications this would enable that aren't possible today.  Jory, could
>you help describe what this would enable? Rob

please allow me to try to answer this question for Jory. I am one of the 
founders and project admins of matroska and hope to be able to give some 
good explanations here.

matroska is pretty much a complementary thing to realmedia container, as 
its clearly targeted and designed for video editing and storage, and not 
for streaming purposes. With some tweaking it may be possible to use 
matroska for streaming also, but we expect that to be suboptimal, again, 
it wasnt designed for this purpose.

To understand why it may be a nice thing to have Real content in 
matroska files, its important to understand where it is different than 
other containers. If audio and video content is going to be put into a 
matroska file, the muxing app has to follow a number of very strict 
rules. This requires to make a clear description on our spec pages for 
*EVERY* compression format thats going to be put into matroska files, 
such that developers creating apps to read/write matroska files know 
exactly how it had to be done, and specific for every codec/format. 
While this policy may look stupid for many developers in first instance, 
as for them its lifting the value of the container to a level where it 
shouldnt be really, this has one clear advantage :

matroska files can be edited/cut/merged without the need for the editing 
application to have *ANY* knowledge about the actual content at all. A 
good example for that is the editing application we are currently 
working with, a mod of Virtualdub called 'VirtualdubMod' ( you guessed 
it ;-) ). Its main developer, Julien 'Cyius' Coloon, is limited a lot by 
the structure of the underlying Virtualdub, which is heavily based on 
VfW, and thus can only handle VCM and ACM codecs normally. However, the 
current CVS version is already able to handle a couple of different 
video codecs for editing and cutting of  matroska files, even those 
without a VCM codec, and basically EVERY audio format we can put into 
matroska already, being AAC, AC3, DTS, PCM, MP3, MP2, Real ATRAC and 
Real COOK . The same is valid for the various subtitle formats we 
support, such as SRT, SSA/ASS and USF.

We are in contact with people from the MPEG4IP team to investigate if 
matroska could be used as a powerful editing container to edit MP4 
files, by muxing the MP4 into MKV, edit them, and then mux back into MP4 
finally. The same could be done with Realmedia files in matroska editing 
applications, and with some good will from your side ( like a decoder 
DLL limited to decode keyframes only ) we could even implement some 
limited preview functions so the users know where to cut.

The architecture on which matroska is based on is a kind of binary 
version of XML and very flexible, to be able to extend the format for 
the future, but this is mainly necessary because of the very strict 
rules to put any kind of content into matroska files. We need to be 
flexible here, as we dont know yet what future codecs may require, but 
we certainly dont want to break our general policy of having advanced 
editability of matroska files. Again, matroska should be seen as a very 
powerful AVI replacement in first place, and its design goals are pretty 
much complementary to those of other containers such as Ogg, MP4 and RM. 
If there is a 'direct competition', it can be seen in MXF and AAF 
rather, but those wont offer any license free libraries AFAIK.

For the user matroska would give him a couple of advantages, like the 
ability to mix the Real codecs with every other supported compression 
format, or to use matroska's nice storage features like menues, chapters 
and attachement files.

I hope i could name a couple of advantages why it could be of interest 
to Real to allow muxing of Real media content into matroska container. 
In the end, to allow playback of these files from Real's players we had 
to add matroska parsing capabilities to Helix DNA client, so this may be 
of interest for you people also ;-).

Best regards



More information about the Matroska-general mailing list