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

[wm4]

On Fri, 20 Sep 2013 21:20:13 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

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

Looking at the source, no. I've tried to set the rtsp_transport=tcp
option for libavformat. Finding out how to do this was a real adventure.
(You don't set it as avio option, you don't set it as AVFormatContext -
no, you set it on a AVDictionary you have to pass to
avformat_open_input()!)

With that, it works well. But still, isn't that only side-stepping the
issue?

I've talked to some developers who work on the Libav networking code,
and they sound pretty convinced that implementing these network
protocols it on the demuxer side is better due to various API issues.
(Such as saving bandwidth by reading only demuxer-level streams which
are selected by the user, and such.)

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

That's pretty violent. Of course you can get out of there _somehow_,
but not in a resumeable manner really supported by libavformat. It's
not even clear whether a seek lets the demuxer forget about canceling
the read violently (though it probably works for most things).

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

Yes, abort works by pretending the stream hit EOF. The way input
handling works you can make the player abort the current file, but you
can't interact with it in any way before that happens. In addition
to this, it looks pretty crappy if the window doesn't even redraw.