Re: [PATCH]Allow longer url in demux_lavf.c

On Fri, 20 May 2016 23:33:30 +0200
Roberto Togni <[email protected]> wrote:

> On Thu, 19 May 2016 17:07:34 -0500
> "Lu, Ran" <[email protected]> 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.

(mpv does this.)

> 
> To do 2 you need to create a stream module that uses the lavf hls
> demuxer, and then remuxes the content in a new container. This will
> then use the MPlayer caching mechanism.
> 
> 
> I haven't looked deeply into the details yet, even if I have it on my
> long-term todo list for a long time.
> My original plan was to do 2, but feel free to work on the way you like
> best if you decide to try to implement it.
> 
> Ciao,
>  Roberto
> _______________________________________________
> MPlayer-dev-eng mailing list
> [email protected]
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
_______________________________________________
MPlayer-dev-eng mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng