[MPlayer-users] There is no cache when playing m3u8 stream (hls-protocol)

[Reimar Döffinger]

On 20.09.2013, at 20:25, wm4 <nfxjfg at googlemail.com> wrote:

> On Fri, 20 Sep 2013 18:55:05 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
>> 
>> Actually I think the main reason is the RTSP over UDP doesn't work
>> for most people anyway and I am quite convinced that issue does not
>> exist for RTSP over TCP.
> 
> Yes, the URLs I tested seemed to use UDP. I'm not sure what part oif
> the RTSP protocol decides whether to use UDP or TCP.

Usually by UDP not working.
You can also explicitly tell it to.
I think the -rtsp-stream-over-tcp option might even be hooked up to the ffmpeg rtsp?

>>> If you want to use ffmpeg's RTSP implementation, the problem is that
>>> even just waiting for video vsync will give you a ridiculous amount of
>>> packet drops.
>> 
>> I suspect there might be a few things horribly broken in FFmpeg's
>> receive buffer use, it seems to force a value smaller than the
>> already ridiculously small default size.
>> Otherwise if you'd set net.core.rmem_max and net.core.rmem_default
>> to something ridiculous like 20 MB that issue should disappear
>> completely.
> 
> Doesn't seem to help.

As said, I think FFmpeg is broken and requests the buffer to be reduced to 60 kB or so, unless you set special options which I do not know if it is possible for rtsp.

>> Actually there are mechanisms for that. But it is not relevant if you
>> already have a cache implementation.
> 
> Like what mechanisms? Some streaming mechanisms can probably drop
> packets easily, but typical "desktop" (like mkv etc.) file formats
> don't easily allow this.

mkv and many other formats can resync after corrupted data. You could also use that to skip ahead. Not that I think anyone actually wants that...
But you said interrupting a read, and that can be done in the most literal sense by having interruptable syscalls and programming a SIGALARM. And there is async IO etc.

>>> So if a demuxer reads too "much" data, the best
>>> stream layer cache won't help you, and the whole player freezes. From
>>> this perspective, the demuxer should run in a separate thread anyway.
>> 
>> No, the part of the cache doing the reading must run in a separate
>> thread, and it already does in basically all implementations.
>> That is why the whole thing wouldn't be an issue if it wasn't
>> implemented as a demuxer.
> 
> The cache can become empty. The MPlayer cache blocks in this situation,
> blocking the playback core as well.

Actually it busy-waits/sleeps on the core side.
You could do something like make it provide dummy data or such or some other processing.
I believe it actually does handle pressing CTRL+C already now and prints a cache fill status I think.
It's just that there's not many things you can do that actually make things _better_ or are otherwise useful in that situation... Or at least I can't think of much.