[MPlayer-dev-eng] MPlayer streaming

[Arpi]

Hi,

> I have some few questions for A'rpi or any one who wish to
> give me some clues.
> 
> The purpose of the thread I'm using in the streaming network
> code is to handle network events. When a new packet is
> arrived the select loop will returned. Then I take this
> packet and feed the fifo and return in the select loop which
> will block until it received a new network packet. 
> I'm trying to find the best place to put this network event loop
> in mplayer main loop, but for now it's kind of confusing me.
> The select loop can be use as a timer (using timeval), so if a timer is
> used to sleep, it can be a good place for me to put the select loop.
> Which means that if the select loop return is either because of
> a network event or the end of the timer. If no sleeping is required,
> the timeval can be set to 0 (zero, not a NULL timeval) and select
> will return immediately. That allows to check if data is present
> in sockets. 
> I found some usec_sleep in the main loop and I want to be sure
> if that will be the appropriate place for me to look at.
> ( mplayer.c in the block "It's time to sleep..." starting line 1417 )
> The only inconvenient I can see by removing the network thread,
> is the time spend to complet the main loop once. If it's too long we
> can loss network packets (we can still play with the socket buffer
> queue size to reduce the packet lost). This mostly will happen
> with high bitrate streams. I will try this way and see the result.

No. nono.
With my new cache, the input layer runs in different process than
mplayer.c sleeping stuff.

You should implement the  int stream_fill_buffer(stream_t *s); at
stream.c, and leave the others to me. The only way to do: enable
the cache at config.h before compiling (enable will be the default soon,
as soon as i finished all testing) and use -cache option at commandline
or configfile. Otherwise the packet reading code in stream.c will block
and cause jerky picture. It's normal, handling blocking is not your job.
Same happens with slow CDROM or stdin too.

If it's enough to read a file stream (fd) then you can use the STDIN mode
as before (STREAMTYPE_STREAM).

> The other question is about CVS, I need to retreive MPlayer-0.50pre1
> to apply and check a patch. How can I get the CVS release tags?
releases weren't tagged (i forget :() and releases differs from cvs as I
changes few things for releases only (version numbers, including libavcodec
etc). you can download it from mplayer ftp, releases/old-versions subdir.

> When I try to retreive mplayer by giving the release name MPlayer-0.50pre1
> I got a error from CVS (cvs: lock.c:178: lock_name: Assertion...)
strange :)

> Last question is about cache2. 
> To use the cache on a stream, I need to enable the cache by using
> stream_enable_cache, but how do I push data into the cache?
it calls stream_fill_buffer() in an endless loop if there is some space in
the cache buffer. if cache is full, it does usleep(50000); and check again.

so the only thing to do - implement something in stream_fill_buffer() (in
libmpdemux/stream.c) and maybe steram_seek() too. but as i said, reading
from a given fd is already there, i think it's enough for you.

you shouldn't touch mplayer.c or cache2.c, only open.c and steram.c


A'rpi / Astral & ESP-team

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