[matroska-general] Re: [hxdiscuss] Re: Playing RealVideo/RealAudio content from other containers
robla at real.com
Fri Jun 27 01:16:31 CEST 2003
Thanks for the feedback on this. I've forwarded this around internally,
and we'll be mulling this over. I can't make any promises that we'll
make any changes, and certainly can't make any promises on timeframe,
but I will try to keep you (and everyone else) posted.
On Tue, 2003-06-24 at 14:24, Christian HJ Wiesner wrote:
> 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
> To unsubscribe, e-mail: licensing-unsubscribe at open.helixcommunity.org
> For additional commands, e-mail: licensing-help at open.helixcommunity.org
Rob Lanphier, Helix Community Coordinator - RealNetworks
http://helixcommunity.org http://rtsp.org http://realnetworks.com
More information about the Matroska-general