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

[Reimar Döffinger]

On Sat, Sep 21, 2013 at 02:32:31PM +0200, wm4 wrote:
> 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()!)

Yeah, I actually knew that. I just didn't know it wasn't hooked up yet.
I did that now.

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

Kind of. But as said, most people like mean cannot receive rtsp streams
over UDP either way because they use a NAT router.
Unless you do crazy stuff like UPnP or firewall hole punching rtsp does
not work in that case and will fall back to tcp.
However after looking at the messages I am fairly certain this is
already solved in FFmpeg:
[udp @ 0x7f494f3c7700]'circular_buffer_size' option was set but it is not supported on this build (pthread support is required)
So it's just broken due to the way we configure FFmpeg (assuming that
circular buffer is large enough to hold a few frames).

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

I hope you realize the irony of "better due to API issues"?
While I do kind of understand the point, this doesn't really
contradict my (somewhat unfairly mean) description of "too lazy to do
it properly").

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

The libavformat comes in the form of the interrupt_callback function.
It's clearly not a priority features, but I am pointing out that there
are mechanisms, from the OS level down to lavf.
They may not be pretty or be polished enough to work well, but they are
there. There is a good chance if someone really wanted to it would be
possible to make it work reasonable.

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

Sure, though personally I think the experience is going
to be crap anyway, why spend effort on "polishing a turd" so to say.
I know some people strongly disagree on these matters though.
And I am pointing out that I suspect even here some improvements could
be had if really desired even within the current architecture.
There is for example no need to go multi-threaded to just run the
libvo event loop so that redraws work.
If it's worth the code ugliness though is a different question,
on a personal level as said it's a no for me, so someone else
would have to advocate these kind of features if it's wanted...