[vlc-devel] httplive.c: Improvement for Prefetch function?
Łukasz Korbel
korbel85 at gmail.com
Mon Apr 30 21:27:31 CEST 2012
2012/4/30 Frederic YHUEL <fyhuel at viotech.net>:
> On Sun, Apr 29, 2012 at 2:55 PM, Jean-Paul Saman <jpsaman at videolan.org> wrote:
>> On Sat, Apr 28, 2012 at 8:17 AM, Frederic YHUEL <fyhuel at viotech.net> wrote:
>>> Hello,
>>>
>>> 2012/4/27 Łukasz Korbel <korbel85 at gmail.com>:
>>>> Prefetch function downloads 2 segments before playback start to avoid
>>>> stalling (see http://trac.videolan.org/vlc/ticket/5197).
>>>>
>>>> Problem:
>>>> - unneeded delay for fast connection
>>>
>>> Indeed
>>
>> 3 segments was a recommended by the HLS draft writter
>>
>
> Ah ok
>
"3 segments was a recommended by the HLS draft writter " - I was
looking for that information in
http://tools.ietf.org/html/draft-pantos-http-live-streaming-08
All i have found is:
"The client SHALL choose which media segment to play first from the
Playlist when playback starts. If the EXT-X-ENDLIST tag is not
present and the client intends to play the media regularly (i.e. in
playlist order at the nominal playback rate), the client SHOULD NOT
choose a segment which starts less than three target durations from
the end of the Playlist file. Doing so can trigger playback stalls."
and:
"The client SHOULD attempt to load media segments in advance of when
they will be required for uninterrupted playback to compensate for
temporary variations in latency and throughput"
Can you tell me Paul where you found information to download 3
segments before starting playback?
Maybe I've missed something but if it isn't necessary then Prefetch
function won't be needed at all. I've tested HLS playback without
calling Prefetch and it works well for me. I guess its woth checking
because it will speed up playbacks start by the time of two downloads.
>>>
>>>> - doesn't solve the problem completely
>>>>
>>>
>>> Indeed, the right solution is my patch: http://patches.videolan.org/patch/306/
>>>
>
> That was a little presumptuous, but it seems to work well. What do you
> think of this patch?
>
IMHO this will do the job and its a lot better than another vlc option.
>>>> Posible solution:
>>>> add option for number of segments to prefetch (e.g.
>>>> --sout-hls-prefetchnum) with minimum set to 1 (must download first
>>>> segment at least).
>>>
>>> This is not a good solution IMO.
>>
>> +1
>>
>>> Hey, if you want to do something, why don't you try and work on
>>> resolution switches support? *That* would be really useful! This is
>>> the #1 problem of this module.
>>
>> The httplive module is a stream_filter which limits its support for
>> resolution/codec/samplerate switches.
>> Any changes that requires the codec to be re-instantiated is not
>> possible with this module type. The
>> module type needs to change to "access_demux".
>>
>
> Ok.
>
> IIRC Hugo tried something using input_Control(INPUT_RESTART_ES), which
> didn't work, but I was thinking: "if someone else try, who knows... ?"
>
I'm also interested in making bandwidth adaptation better, although
massive changes in module might a little bit too much for me.
Currently I'm think about ways to speed up playbacks start in HLS. Do
you have any ideas other then related to Prefetch function?
More information about the vlc-devel
mailing list