[MPlayer-dev-eng] [PATCH]Allow longer url in demux_lavf.c

[wm4]

On Fri, 22 Jul 2016 09:42:13 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> On 20.05.2016, at 23:33, Roberto Togni <rxt at rtogni.it> wrote:
> 
> > On Thu, 19 May 2016 17:07:34 -0500
> > "Lu, Ran" <hephooey at gmail.com> wrote:
> >   
> >> Hi all,
> >> 
> >> I noticed when playing some live stream from twitch mplayer cannot update the 
> >> m3u8 playlist. The reason is the size of the mp_filename array is only 256 
> >> byte, so url like
> >> "http://video-edge-2aa234.iad02.hls.ttvnw.net/hls-835268/luzbelheim_21377489200_454740786/chunked/index-live.m3u8?token=id=7800187502285523477,bid=21377489200,exp=1463625667,node=video-edge-2aa234-1.iad02.hls.justin.tv,nname=video-edge-2aa234.iad02,fmt=chunked&sig=b511bc935cde4806c9412b53b1bc5c7c24eb416d"
> >> is truncated and the demuxer reports a "403 forbidden" error because the auth 
> >> code is incomplete.
> >> 
> >> The patch in the attachment simply increase the size of mp_filename to 2048. I 
> >> pick this to match the size used in ffmpeg url.
> >> 
> >> With this patch mplayer can play the stream without the help of other programs 
> >> like livestream. But it is still imperfect. I think mplayer apply the cache 
> >> mechanism to the initial m3u8 playlist instead of the real stream. As the 
> >> result the cache is always 0%, and every time the stream move to a new ts 
> >> chunk or update the m3u8 playlist there is a slight but noticeable pause, and 
> >> mplayer drop 3-4 frames depends on the speed of the internet. I had a quick 
> >> look at the source code but did not find a place I can wire the ffmpeg stream to 
> >> mplayer cache. Any suggestions?
> >>   
> > Patch applied, thanks.
> > 
> > You are right about the caching. MPlayer has its cache between the
> > stream layer and the demuxer layer, and this works for all the
> > standard cases where the stream handling (reading from network, disk,
> > file, ...) is separated from the demuxing.
> > 
> > But in hls case, FFmpeg implemented it as a demuxer only, where the
> > demuxer also includes the network code. This breaks MPlayer caching for
> > hls streams.
> > I have no idea why it was implemented this way.
> > I think that rtsp shares the same problem, but probably it's less
> > visible because you don't close and reopen the network connection like
> > for fragmented streaming.
> > 
> > There are imho basically two way to solve this:
> > 1 add a new caching layer between demuxer and decoders
> > 2 use the hls demuxer as as stream source.
> > 
> > To do 1 you need to add caching (queue) of demuxer packets. If it
> > involves running the demuxer in a separate thread/process you need to
> > be careful, since MPlayer is not designed to be thread-safe. Maybe you
> > can run only the lavf demuxer in a separate thread.  
> 
> It already exists, there is the audio and video packet queue.
> But currently it is designed for only a small number, and tries to minimize the amount of data stored.
> Still, a quick hack that is better than nothing (and needs to be enabled with a switch) should not be that hard.

That's what mpv does, including running the demuxer in its own thread.

FFmpeg's HLS demuxer is too bad to get really good results, though.