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

[Arpi]

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.

Why?

Some container formats store audio/video data in raw form. Ie. the
container has no information about the frame/packet boundaries, it just
keeps the streams separated. Some examples:
- raw mp3, raw ac3
- raw mpeg-es, raw h263, raw .264
- raw mjpeg
- audio and video stream of mpeg-ps
In these cases, we cannot ask the demuxer to 'give me a video frame', as
it doesn't know how long is it or even where does it starts.
Some other containers cleanly separates a/v packets, for example:
- avi
- rm
- asf
- mov
In these, you can read a demuxer packet, and it will contain a single
video or audio frame. (ok, in case of avi and mov, audio is tricky)

Also, some codecs can handle frames only (most win32 deocders), some can
handle raw data only (libmpeg2), and some can handle both (libavcodec).

This is not new anyway, in mplayer-g1 it was present, and implemented in
libmpdemux/video.c, in a very messy, ugly way.

I thought i can skip it in g2, by doing raw parsig inside the demuxers,
and/or the codecs, but it is also ugly and sometimes redundant code,
so the old idea came back.

Also, when we do streamcopy to a framed container from a raw one
(for example, mpeg-ps to avi) we need to parse the stream anyway,
without actual decoding. So placing framer into decoder is bad idea.

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.


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.


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu