@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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.