[MPlayer-dev-eng] network streaming layer updated.

[Arpi]

Hi,

> While I was doing my changes I noticed that in the
> stream_fill_buffer function and in the stream_seek_long function,
> a switch are used based on the demuxer type.
> I'm wondering why not using 2 functions pointer inside the stream_t
> struct for read and seek (I'm doing that inside my streaming_ctrl_t struct)
> This 2 functions pointers can be initialised once the demuxer type is
> known and the functions pointer will be called inside stream_fill_buffer and
> stream_seek_long.
> This will avoid to have to change the demuxer.c code to handle a new
> stream type. Each file type will provide the way to read and seek.
> The default read handler can be the read syscall, and when reading
> from the network, for example, I will set the proper read handler.
> Is that something that was already though about? I will appreciate if 
you mixed demuxer and stream. they are 2 different, separated layer.
btw both layer suffers from this switch() problem, but they should not
mixed! stream is to handle input media (read syscall / vcd ioctl / dvd ifo
css reader / network stuff) and demuxer is to parse fileformat-specific
headers and flags and stuff and parse a single input stream to 1 or more
packet queue. demuxer also does other stuff, like fileformat detection, seek
with a-v sync, etc.

now, you are working on stream layer. afaik nothing with demuxers.
(only exception that you return a 'hint' for fileformat for the demuxer)

now, at stream layer 'plugins' should implement read (stream_fill_buffer)
and seek (stream_seek_long) functions and of course open/close (in open.c).
they are handled in single functions, using if() or switch() just to avoid
duplicating very similar code. you can notice that most of teh code is the
same, just a few lines differs depending on read or ioctl is used etc.
i don't much sense of using function pointers here.

> I find it clean ;)
I find it redundant :(

> BTW, the HTTP streaming is still working but the ASF MMS streaming 
> still doesn't worki for now, I might have an idea why, but I need more time 
> to investigate on it. I will let you know.
> And there is no more prebufferization for now, I will also work on this.
hmm. why? cache2 should do that.


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu