Created attachment 201230 [details]
test case which will construct a playbin2. run with arguments <uri> <fragments-cache>

when setting the fragments-cache property progammatically inside a playbin2, the beginning of the playback may still be delayed until it has finished downloading more fragments than specified

it appears that the amount of extra fragments it leeches before going into PLAYING is proportional to the fragment size!

i've compiled a little testcase for this

GST_DEBUG=*hls*:4,*HLS_LATENCY*:5 ./hls_latency "http://devimages.apple.com/iphone/samples/bipbop/gear4/prog_index.m3u8" 2
this will actually start playing after the 3rd fragment
while this stream here:
GST_DEBUG=*hls*:4,*HLS_LATENCY*:5 ./hls_latency "http://qthttp.apple.com.edgesuite.net/1010qwoeiuryfg/3340_vod.m3u8" 2
starts directly after the first fragment is finished (as expected)

i have another stream, which is unfortunately non-public with very short 8 second/750kb-fragments where it doesn't start playing until the 5th fragment

the INFO                hlsdemux gsthlsdemux.c:576:gst_hls_demux_loop:<hlsdemux0> First fragments cached successfully actually pops up after the specified amount of fragments have been downloaded. i've also debugged this and the fragments-cache property is actually being treated correctly inside hlsdemux itself