[Bug 594035] Add HTTP Live Streaming playback support

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=594035
  GStreamer | don't know | git

--- Comment #37 from Julien Isorce <julien.isorce at gmail.com> 2011-03-08 14:12:34 UTC ---
Created an attachment (id=182822)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=182822)
zipped log1.txt and log2.txt that contain output of 2 pipelines

log1.txt:

GST_DEBUG=decodebin2:5,hlssrc:5,GST_EVENT:5 gst-launch-0.10 souphttpsrc
location=http://etf1-apple-live.adaptive.level3.net/apple/etf1/etf1live/stc_1_0.m3u8
! hlssrc ! decodebin2 ! xvimagesink -v


log2.txt:

GST_DEBUG=decodebin2:5,hlssrc:5,GST_EVENT:5 gst-launch-0.10 souphttpsrc
location=http://etf1-apple-live.adaptive.level3.net/apple/etf1/etf1live/stc_1_0.m3u8
! hlssrc ! mpegtsdemux  ! decodebin2 ! xvimagesink -v


In the log1.txt it takes about 45 sec to reach the playing state whereas it
takes 14 sec in log2.txt

I noticed that in log1.txt decodebin2 does not appear between the 21.407182007
sec and the 45.868456809 sec
(gstdecodebin2.c:2538:multi_queue_overrun_cb:<decodebin20> multiqueue
'multiqueue0' (0x88b4ec0) is full).
It seems the pad was blocked and reaching the full condition woke it up. 

So it seems we are lucky here and a normal behavior would be to reach the
playing state before reaching the full condition.

-- 
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.