[gst-devel] muxing proposal

David Schleef ds at schleef.org
Thu Jul 17 20:48:22 CEST 2008


Attempting to get Dirac muxing working correctly with most containers
has been a difficult task recently.  GStreamer has been the easiest
media framework *by* *far*; other frameworks like DirectShow and
QuickTime really only allow muxing into one specific container.  (In
some ways, gstreamer is the same way, with ogg.)

The main problems, as I see it, are:

 - All our muxers suck.

 - Each container format has special mapping requirements for streams.
   AVI needs special chunking of Dirac packets, MPEG-TS needs
   presentation timestamps, Ogg needs granulepos, etc.  Right now,
   each muxer reparses and/or attempts to reconstruct this information
   in the muxer (but mostly just does it wrong).

 - Adding a new format requires modifying the muxer.  This is the same
   problem as convincing Apple to add Dirac to their mp4 muxer, except
   that I'm lucky enough to have commit access here.


What I propose is this:

 - Muxers should be modified to implement a native stream format, e.g.,
   video/x-avi-part for avimux, with a fourcc describing the stream.
   Muxers may optionally accept other formats as they do now, but are
   responsible for parsing and discovering values that the container
   needs to store.  These streams have a well-defined structure, with
   the intention that buffers are directly encapsulated into output
   packets.
   
 - For each of these muxer substream formats, define additional
   stream-specific buffer flags as necessary and override
   GST_BUFFER_OFFSET_END() for stream- specific purposes (like granulepos.)

 - A set of new elements (or mods to parsers) that parse encoded streams
   into the correct format for muxers.  Thus, diracparseforavi would
   parse a dirac stream into the correct chunks to go into AVI, as well
   as setting the key frame flags correctly.  (Key frame flags in AVI and
   QuickTime are more restricted than MPEG or Ogg.)  diracparseforogg
   would add Ogg granulepos to each buffer.

   (I'm indifferent to using separate elements or a single diracparse
   element that can output many parsed formats.)

 - Theoretically, this should be backward compatible.  We can move toward
   using the native stream formats gradually.

 - Ogg will still require stream-specific code in the muxer.

Once parsers are responsible for delivering buffers to the muxer that
the muxer understands, I'm hoping that writing a muxer becomes a lot
closer to "while(1) { collect a buffer; encapsulate; push }".



dave...





More information about the gstreamer-devel mailing list