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

[Reimar Döffinger]

On Fri, Sep 20, 2013 at 01:13:59PM +0200, wm4 wrote:
> On Fri, 20 Sep 2013 12:34:45 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
> > 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.
> 
> If it works for HLS, that's fine. I guess you don't care about ffmpeg
> RTSP, because you have other RTSP implementations which work better.

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.

> 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.
Do you know of some public URL to test?

> > 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.
> 
> Well, ffmpeg demuxers are so designed that they have to read data in a
> blocking manner. There is no way to "suspend" a read call, and resume
> I/O at a later point.

Actually there are mechanisms for that. But it is not relevant if you
already have a cache implementation.

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

> > > 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.
> 
> I'm not sure how ffmpeg would even do this, other than running parts of
> the stream implementations in a thread and would complicate its
> implementation.

As said, any cache will already do this.
"just" re-packing the RSTP data so it can be put into an ordinary
cache pretty much would solve things for the vast majority of programs
already implementing a cache.