[MPlayer-dev-eng] [PATCH] Clean up demuxers

[Bertrand Baudet]

On Thursday 21 February 2002 05:29 am, you wrote: 
[...]

> anyway, you're right in one thing: that big switch(){...} is not good, and
> slow. it was added when there were 3 demuxers... now there are 18...
> anyway, i don't like the method you used to solve this. why don't we simply
> use a function pointer ? 

Hehe, I already suggested this idea when I was doing the network layer 
and actually it's what I'm doing with the network read/seek function call.
(see network.c stream.c) 
I have a generic/default read/seek function pointer. For the generic read
(nop_streaming_read) it will just read packet from the network and
return the unprocessed data. For ASF MMS, I replace the default
read by the asf_streaming_read function pointer so it will read the
data packet from the network removed the encapsulation layer and
return the paylaod.
All of this is transparent for the stream_fill_buffer that will only call
the streaming_read function pointer contains in the streaming_ctrl struct.

> and set up this pointer to the right demux_fill_*
> stuff at demux_open() ? the same thing can happen with seek functions.
> and finally it will move to a libao2/libvo-like modular API.

For example, the Linux Virtual File-system is based on functions pointers. 
If you want to provide a new filesystem you need to implement the read, seek
and other needed functions and return a struct (file_operations) that 
reference all the functions pointers. 

I think it's the good to way to look at this. We should have a struct that 
every module return at initialisation time. This struct will contains the
read, seek, demuxer_fill_* ... function pointers and the demuxer
core will only have to call the function pointer. No more case addition
to the switch statement when a new demuxer is needed.

When do we start? ;)

Anyway, it's only my 2 cents.
Bertrand

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com