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

[Reimar Döffinger]

On Thu, Sep 19, 2013 at 11:19:45AM +0200, Waldemar wrote:
> Hello list,
> when playing m3u8 live streams (hls-protocol), Mplayer dosen't use
> cache. This leads to a delay when MPlayer jumps from one segment of
> the playlist to the next and the hole stream becomes 'stutter'.

Due to the somewhat misdesigned way this is handled by FFmpeg, caching
HLS is not possible.
Or rather, it is only possible after the demuxer, where you'd have
to cache each stream (audio and video for example) separately.
MPlayer currently doesn't do this.
And there are more issues with the HLS demuxer I believe.
In general, unless it works much better in ffplay (I don't think so)
you'll have to ask FFmpeg about fixing it.

> So my question is are there any parameters I can tweak to enable
> cache? Or is it a bug in MPlayer?

I would say "no". It "works as intended".
Just in case you are a developer or know one you can ask a favour:
ds_fill_buffer in libmpdemux/demuxer.c could probably be hacked
with not too much effort to behave at least a bit like a cache.
Maybe even something as stupid as this will work (except for breaking any
audio-only files):
--- a/libmpdemux/demuxer.c
+++ b/libmpdemux/demuxer.c
@@ -709,6 +709,7 @@ int ds_fill_buffer(demux_stream_t *ds)
             if (!ds->first)
                 ds->last = NULL;
             --ds->packs;
+            if (vpacks < 100) demux_fill_buffer(demux, ds);
             return 1;
         }
         // avoid buffering too far ahead in e.g. badly interleaved files