GNOME Bugzilla – Bug 738696
hlsdemux: send missing stream start
Last modified: 2014-10-25 12:13:20 UTC
If the demuxer is restarted (by a seek for example) after reaching end of playlist, it should send stream-start even if it re-uses the old pad as well as marking the first buffer as discont.
Created attachment 288766 [details] [review] hlsdemux: send missing stream start
Review of attachment 288766 [details] [review]: ::: ext/hls/gsthlsdemux.c @@ +269,3 @@ demux->group_id = G_MAXUINT; + + demux->need_stream_start = FALSE; Shouldn't it be TRUE by default? Also reset to TRUE in the reset() function? @@ +981,3 @@ + + gst_pad_push_event (demux->srcpad, event); + g_free (stream_id); This code looks duplicated, refactor it into a helper function @@ +2218,3 @@ + demux->end_of_playlist = FALSE; + demux->discont = TRUE; + demux->need_stream_start = TRUE; This seems weird. It should probably stay at end_of_playlist until a FLUSH or reset happens... and after EOS no new stream-start event is needed usually.
Created attachment 289015 [details] [review] hlsdemux: reset end_of_playlist attribute when we receive a seek
(In reply to comment #2) > Review of attachment 288766 [details] [review]: > This seems weird. It should probably stay at end_of_playlist until a FLUSH or > reset happens... and after EOS no new stream-start event is needed usually. The whole patch is not needed then. I've attached a new patch that reset the end_of_playlist attribute when we receive a seek so it reflects Note that the end_of_playlist attribute is not used anywhere, and can possibly be removed.
commit 7fb584b08788323bad2cbd7e651531dd2ce191b4 Author: Matthieu Bouron <matthieu.bouron@collabora.com> Date: Tue Oct 21 12:39:14 2014 +0200 hlsdemux: reset end_of_playlist attribute when we receive a seek https://bugzilla.gnome.org/show_bug.cgi?id=738696