[matroska-devel] Re: MPEG in Matroska

[Christian HJ Wiesner]

cc : virtualdubmod-devel at lists dot sf dot net
cc : pulco-citron at users dot sf dot net  ( author of the original MPEG2 
parser for VirtualdubMod )




Hi !

John Cannon wrote:
> I am coding a simple MPEG-1 parser i n hopes of making a transmuxer one day.
> Anyway, I was wondering what would be the best method of storing the frames?
> In MPEG-1 even, the quantizer table can change at every GOP if you want.  So
> do we just chop the stream and include these headers with the I frame or
> what?

John, this is making me really happy !!! If you say you are coding a 
MPEG parser, why dont you use existing code, like from fcchandlers 
Virtualdub_MPEG2 ?

In any case, i think its a good way to start with MPEG1 video, so we can 
learn how to do it, and then proceed to MPEG2 later. There is just one 
thing burning on my mind, this is a matter of priorities. Sure, 
everybody is free to work on the things he likes to do the most and as i 
see it all the *really* neccesary stuff for the launch of matroska is 
being worked on already ( there is no need for the file 
repair/optimization tool to be available on day 1 IMHO ), so you could 
jump into looking at this. Its just, i want to avoid that the other team 
members will be angry on me because i am pushing you into this now, 
while maybe there is a lot of other stuff to do right now ? Any opinions 
on this from the other team members ?

With respect to GOPs, i think we should bring the power of EBML in here 
and define a GOP EBML element ... i hope this was possible ? Alex 
'Foogod' Stewart was giving a breif overview to me what it would take to 
get this working. He was talking about several 'layers' or 'levels' of 
the MPEG container, and he himslef was not sure as to what layers could 
be dropped, as they are covered by existing matroska elements already, 
what layers would have to be copied from the MPEG without altering, like 
putting them into codec private data, and for what layers we would have 
to define new EBML elements.

> PS: an answer to the discussion earlier, B frames can reference any frame
> before or after them in the same GOP as long as it's not another B frame.
> And P frames can reference any single frame before them in the same GOP.
> (from a very trusted source :) )

Before of after them ? Does our current referencing principle allow this ?

Christian

http://www.matroska.org