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

[Roberto Togni]

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.

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