Re: [matroska-devel] MPEG in Matroska
Christian HJ Wiesner <[email protected]>
| Newsgroups | gmane.comp.video.vdubmod.devel |
|---|---|
| Message-ID | <[email protected]> |
cc : virtualdubmod-devel@lists dot sf dot net cc : pulco-citron@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 ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp