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

[Reimar Döffinger]

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.