[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 ;-).
More information about the Matroska-general