[MPlayer-G2-dev] framer API, demuxer chaining

[D Richard Felker III]

On Wed, Dec 31, 2003 at 04:41:53PM +0100, Arpi wrote:
> I think it could be implemented as the top object of the new VP layer.
> ie it would replace current codecs, and codecs would be just filters.
> The other way to go, is implementing it as independent layer.
> (codecs as conversion filters is not a new idea, it could help in cases
> of raw rgb video / pcm audio, hardware decoders (ac3/mpeg passthrough),
> framecopy encoding, transcoding (think of an div3->mpeg4 one) etc).
> 
> Since i don't know the new VP thing yet, i cantd ecide which one is
> the beter, but i hope it's cleaner to put into VP.

What are the choices you're trying to decide between? I can't really
tell from what you wrote, but I think it makes sense for the framer to
be the beginning of the vp chain (and eventually ap chain) with codecs
as filters. We need to decide on a sane way for storing encoded images
in mpi, and there might be some pts/dts issues to think about
(although IMO the framer should be able to provide pts for every frame
it gives).

> Yet another thing: demuxer chaining.
> (we've also discussed it on irc, ie its messy and automatic chaining
> should be solved somehow without ugly hacks)
> 
> So i've found the solution today: add yet another stream type to demuxer
> layer, besides audio, video and subtitles: the muxedstream type.
> 
> In case of multi-layer muxed streams (like ogg-in-avi, rawdv-in-avi,
> mpegps-in-mov, mpegps-in-mpegts etc) the top level demuxer (in case
> of ogg-in-avi the avi demuxer) could export the 2nd level demuxed
> steram as a new stream, with type muxedstream, and set format to the
> 2ndlevel demuxer name (if known, anyway it should be known...).
> So, in case of ogg-in-avi, teh avi demuxer opens the stram, and
> exports stream#1=video(format=div3) and stream#2=muxed(format=ogg),
> the the caller of demux_open (the main app) will see that we have
> muxed substreams, and it can create new virtual stream (type=ds)
> from it and call demux_open again with this stream as input.
> This way we can avoid callong demux_open and such from demuxers,
> and still have the whole mess simple. Also, if user doesnt want the
> muxed stream (for example, -nosound for ogg-in-avi) we dont need
> to work with that stream.

Question: If we don't open up all the demuxers at startup, how will
runtime stream selection work? Think of something idiotic like
ogg-inside-avi with two separate vorbis streams (2 languages) inside
the ogg. Bleh...

IMO some api should be provided for recursively opening all demuxers.
That way players don't have to implement this themselves unless the
specifically want to.

Rich