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

[Reimar Döffinger]

wm4 <nfxjfg at googlemail.com> wrote:
>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.

That is exactly what my hackish patch makes MPlayer do. The code is mostly there, just by default MPlayer buffers as little data as possible after demuxing.
Whether a separate thread is even necessary would be a different question.
Note that buffering will cause some issues, so it should not be used if there is no real reason.

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

It is a design that pretty thoroughly breaks layering.
In case of rtsp this is mostly just to the degree that the protocol itself does it.
For hls I have doubts it was really justified instead if just the easy way for those implementing it.

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

I'd rather have FFmpeg do it. After all its cache:// protocol has the same issue. But there will be some issues with that, both practical and probably ideological objections.