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

[wm4]

On Thu, 19 Sep 2013 19:46:07 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

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

It seems all complex network protocols are implemented as demuxers.
RTSP is another case. I can't get proper RTSP playback to work in my
mplayer fork, because it pretty much expects that you call
av_read_frame() all the time, and spending more than a few milliseconds
outside of it makes it drop packets. And of course, -cache will do
nothing because it's all implemented in the demuxer.

ffplay doesn't have this problem: the demuxer runs in its own thread,
so it can read ahead by a number of packets. This also acts as a cache.
So I would expect this works much better in ffplay (for RTSP it
definitely does).

So, the question is: is this really a FFmpeg misdesign, or a weak point
in mplayer's architecture?

Putting the demuxer in its own thread would probably be rather
involved. As a relatively simple hack, one could open the demuxer in
stream_ffmpeg.c, and send the packets as byte stream using some simple
encoding - then -cache would work.