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

[Nico]

Arpi wrote:

>Hi,
>
>I'm introducing a new thing for g2, called Framer.
>It's a layer between the demuxer and the VP layer (decoder/filter/vo/encoder).
>The goal of this thing to frame raw data to frames/packets.
>
>So i've found the solution today: add yet another stream type to demuxer
>layer, besides audio, video and subtitles: the muxedstream type.
>
>  
>
100% agree

>In case of multi-layer muxed streams (like ogg-in-avi, rawdv-in-avi,
>mpegps-in-mov, mpegps-in-mpegts etc) 
>
eh? maybe you mean pes-in-ps and pes-in-ts

>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.
>
>
>A'rpi / Astral & ESP-team
>
>  
>

This new layer gives the chance to introduce clean fixup functions after 
seeking
(e.g. sync to the next GOP boundary in case of mpeg1/2 (that is really 
nasty currently)
or something more complicated if needed).

IMO the concept of "dump" should be rethought: usually when I want to 
dump video
I want the terminal video stream (that currently is inaccessible in g1 
in case of a chained demuxer)
but I could also want one of the many intermediate chained streams (e.g. 
for debugging).


        Nico