Re: [MPlayer-dev-eng] [PATCH]Allow longer url in demux_lavf.c
- Date: Fri, 22 Jul 2016 09:42:13 +0200
- From: Reimar Döffinger <Reimar.Doeffinger@xxxxxx>
- Subject: Re: [MPlayer-dev-eng] [PATCH]Allow longer url in demux_lavf.c
On 20.05.2016, at 23:33, Roberto Togni <rxt@xxxxxxxxx> wrote:
> On Thu, 19 May 2016 17:07:34 -0500
> "Lu, Ran" <hephooey@xxxxxxxxx> 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
>> 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.
MPlayer-dev-eng mailing list