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

[Rob Lanphier]

Hi Christian,

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.

Rob

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
> >  
> >
> Hi,
> 
> 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
> 
> Christian
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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

http://www.matroska.org