@pulco-citron : ( Reposted, cc to vdubmod-devel ) MPEG2 video in matroska !!
"ChristianHJW" <[email protected]>
| Newsgroups | gmane.comp.multimedia.matroska.devel,gmane.comp.video.vdubmod.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, as i find this extremely important ( no other competing container can offer this, just imagine an existing, unaltered MPEG2 video stream with multiple recompressed Vorbis audio streams and USF subtitles in matroska ! ) pls. allow me to raise this issue again : Alex 'Foogod' Stewart knows the MPEG framing very very well it seems, but i guess we have to face it that he wont be contributing to matroska directly, only via the creation of UCI ( i really hope he will find the time to do so, as it seems he wants to actively participating in the MCF development now ). He said here : http://article.gmane.org/gmane.comp.video.mcf.devel/683 [quote]On Sun, Dec 01, 2002 at 02:18:36PM +0100, Steve Lhomme wrote: > alex <at> foogod.com wrote: > >AR information is encoded at the "sequence" layer. The sequence headers > >typically include the sort of information which MCF is also designed to > >hold > >(meta-information about the stream/file), so including the sequence level > >of an > >MPEG stream inside MCF would be highly redundant and probably bad practice. Actually, now that I've had time to think about this further, I'm realizing that it's not as simple as I'd made it sound at first. The MPEG "sequence start" and "sequence start extension" headers contain a lot of info that's redundant with MCF's encapsulation data, but unfortunately they also contain some critical stream metadata (such as huffman coding matrices) which must be included with any video frame data somewhere. One could just strip out these few important bits, but unfortunately then one is stuck with an MCF-specific way to represent them, since there's no standard way to represent them by themselves (outside of the sequence headers). It is probably better to include the whole sequence headers even though they contain some redundant information. The logical place for this would be in the "codec header" data for a track, I think. So you really would need to include the MPEG AR flags in the encapsulated data anyway, but I still think that if possible, that information should be copied into the MCF headers and handled by the MCF libraries instead of the codec, as it allows for more flexibility on the part of the application. > Yes, that's why I think the MPEG-in-MCF streams should remove some of > these headers. The problem is : is there some available > encoders/decoders that can do that ? The same UCI codec should be able > to handle the native MPEG way and the MCF way. Is this possible > transparently (you just say you use the MCF identification mode) or > should it be 2 different codecs ? Theoretically, I think most MPEG codecs could probably handle this if they were passed the appropriate information, but ultimately, as I mentioned above, it's probably better to just include the MPEG structures as-is, which makes the issue moot.[/quote] Sorry for the long 'sniplet' , but i thought its better to paste it completely here instead of only linking to the main thread. My questions here : 1. Are we sure we have all the necessary elements in the matroska specs to be able to mux MPEG2 video into our container ? Please try to understand from what Alex said above if this is the case or not. 2. Could Erik Waltinsens http://www.codecs.org , or more precisely http://www.codecs.org/libcodec/ ( once its complete ) with example code of how to parse MPEG streams ( he is talking about 'format conversion' ... misunderstanding from my side ? ) be used as a basis to understand MPEG container structure ? 3. VirtualdubMod has already the capability to parse MPEG2 streams ( funny enough only with a .vob extension, so MPEG has to be renamed for the time being ), i hear the code is taken from DVD2AVI AFAIK. Suiryc already had a look at the code that was submitted by pulco-citron, one of the project admins of VdubMod, but couldnt really understand it unfortunately ( Suiryc is subscribed to matroska Mls already, but i copy him on the email also ). @pulco-citron : any chance you could look into this ? 4. @spyder : Can JMStudio handle MPEG2 for demuxing and muxing also ? If you have 'javatroska' working, could we find a way to mux MPEG2 video into matroska with your tools ? 5. @myFUN : I dont see a UCI MPEG2 decoder anywhere down the road, so i guess we would have to use MPEG2 video in matroska in a form of GUID compatibility mode ( NOT FourCC/AVI/VfW compatibility mode ) and call existing MPEG2 Dshow filters for playback of the streams. Here a couple of questions to you : - Now, what type of stream do we need exactly to be able to pass the MPEG2 video data to the Dshow filter ? - What GUID does MPEG2 have ? - Is it maybe necessary to differentiate between MPEG2 stream in matroska in GUID ( DirectShow ) compatibility mode and 'native' MPEG2 streams muxed with a UCI encoder and decoded via UCI decoder ? - If we wanted to have MPEG2 support only natively in matroska ( no Dshow/GUID compatibility mode ), is there any chance to have a MPEG2 decoder hardcoded in the matroska parser, at least until a UCI decoder is here ? ( i wouldnt fear the threat from MPAA about MPEG2 decoder licenses, especially as at the beginning matroska parser will not be widely used ) Sorry if this is too early to bring this up again, i just wanted to make sure we have all necessary elements in the specs to do so ! Thanks for replying ! Regards Christian