GNOME Bugzilla – Bug 647751
[hlsdemux] Fix usage of the element in players
Last modified: 2011-04-14 14:55:49 UTC
Testing with Philipe Normand the element with a player, we discovered a couple of bugs that makes it almost unusable. I mark it as a blocker since seek events makes it crash, the duration is not reported correctly and the end of playlists is not handled properly. Branch: https://gitorious.org/ylatuya-gstreamer/gst-plugins-bad/commits/hls andoni@andoni-desktop:~/gst/head/gst-plugins-bad (hls)$ git cherry -v origin/master + 5f7f1a708beb9992e5c64c4897d7edf0263de81a hlsdemux: dispose the fecther from the same thread it's created + e6656a08650c3501feb5cdb20affc735bedccd4a hlsdemux: fix example pipeline + c61c80bdc82c3f3230645b47959330e493a4455f hlsdemux: m3u8: return duration in nanoseconds + c6d7834e1b27a5d7b669f7d66e23d6ac922e7fb6 hlsdemux: ignore seek events until it's implemented + 4b3996bc9dd82ae26ed40e5d257fa437aaeb8d33 hlsdemux: fix handling of end of playlist
> + 5f7f1a708beb9992e5c64c4897d7edf0263de81a hlsdemux: dispose the fecther from > the same thread it's created This fetcher stuff doesn't really look particularly thread-safe to me in general, but I guess that change won't hurt. > + e6656a08650c3501feb5cdb20affc735bedccd4a hlsdemux: fix example pipeline Does this pipeline work for you? (Even after fixing up souphttp -> souphttpsrc) > + c61c80bdc82c3f3230645b47959330e493a4455f hlsdemux: m3u8: return duration in > nanoseconds Ok. > + c6d7834e1b27a5d7b669f7d66e23d6ac922e7fb6 hlsdemux: ignore seek events until > it's implemented There's a gst_event_unref() missing I think, will add. > + 4b3996bc9dd82ae26ed40e5d257fa437aaeb8d33 hlsdemux: fix handling of end of > playlist Ok.
(In reply to comment #1) > > + e6656a08650c3501feb5cdb20affc735bedccd4a hlsdemux: fix example pipeline > > Does this pipeline work for you? (Even after fixing up souphttp -> souphttpsrc) Replace gear1 with gear4 too. For low bitrates the queues in playbin2 are not filled until at least 4 or 5 fragemts are pushed downstream, so it's start playing after 10 or 20 seconds. Maybe adding a duration to the buffers can fix that?
Apparently multiqueue's limit is set in bytes and not in duration, so setting the duration in the buffers didn't help: multiqueue gstmultiqueue.c:858:update_time_level:<multiqueue0> queue 0, sink 0:00:40.317666666, src 0:00:00.000000000 multiqueue gstmultiqueue.c:1689:single_queue_check_full:<multiqueue0> queue 0: visible 2500/0, bytes 2097756/2097152, time 40317666666/0 multiqueue gstmultiqueue.c:1612:single_queue_overrun_cb:<multiqueue0> queue 0: visible 2500/0, bytes 2097756/2097152, time 40317666666/0 multiqueue gstmultiqueue.c:1612:single_queue_overrun_cb:<multiqueue0> queue 1: visible 933/0, bytes 29290/2097152, time 40320533333/0 multiqueue gstmultiqueue.c:1634:single_queue_overrun_cb:<multiqueue0> A queue is filled, signalling overrun For gear3, this happens when have received 40 seconds, that means 4 fragments, so it will start playing after having cached the first 3 fragments and waited 10 seconds to fetch the next one, which is when the queue is filled.
commit 9334e819e5f2cf1e7cce418cacb472a08e085de9 Author: Andoni Morales Alastruey <ylatuya@gmail.com> Date: Wed Apr 13 22:48:28 2011 +0200 hlsdemux: m3u8: return duration in nanoseconds commit 945400324970b166957f4c7df1c597ea93961617 Author: Andoni Morales Alastruey <ylatuya@gmail.com> Date: Wed Apr 13 23:35:50 2011 +0200 hlsdemux: fix handling of end of playlist Don't send the EOS event until we reached the end of the playlist and the queue is really empty. commit c890a212b622ffbdbe4b3fba851c1891e6e66bb8 Author: Andoni Morales Alastruey <ylatuya@gmail.com> Date: Wed Apr 13 22:25:57 2011 +0200 hlsdemux: fix example pipeline commit 3b19ade905fcda9e7b90f520a450b8304373901e Author: Andoni Morales Alastruey <ylatuya@gmail.com> Date: Wed Apr 13 23:06:18 2011 +0200 hlsdemux: ignore seek events until it's implemented commit b49461df48f68166abb8327c12402d568339a832 Author: Andoni Morales Alastruey <ylatuya@gmail.com> Date: Wed Apr 13 22:17:05 2011 +0200 hlsdemux: dispose the fetcher from the same thread it's created