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

[Bertrand Baudet]

On Tuesday 20 November 2001 02:57 pm, you wrote:
> 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.

Ouppss, I meant STREAMTYPE...

> > 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

And I meant stream.c.... :( Damn, I should reread myself before posting.

> > 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.

Yop, I just wrote it wrong. I just touched the stream stuff not the demuxer.!

> 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)

Yes, exact.

> 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.

Ok, the same that is the same can be on a default function that any of the
'plugins' can point on it if they have nothing special to do.

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

Ok, nevermind. It was just my 2 cents :p

> > 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.

Once the enable_cache function is called the movie will start to be played.
I need to fill the cache with a certain amount of data before starting playing
the movie. This will allow avoid to hang the movie on a network congestion.
In ASF for example they provide the amount of data to bufferize before 
starting playing, that the preroll field in the asf properties object.
I tried to pass the -cache option in the command line, but the display didn't
start, and I don't have time for now to investigate more.

Bertrand