[Bug 663858] New: [hlsdemux / playbin2] fragments-cache property ineffective when using playbin2

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=663858
  GStreamer | gst-plugins-bad | 0.10.22

           Summary: [hlsdemux / playbin2] fragments-cache property
                    ineffective when using playbin2
    Classification: Platform
           Product: GStreamer
           Version: 0.10.22
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: fraxinas at opendreambox.org
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=201230)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=201230)
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

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.