GNOME Bugzilla – Bug 745281
HLS Vevo stream freezes after around 7 minutes
Last modified: 2015-05-29 07:34:19 UTC
This stream: http://vevoplaylist-live.hls.adaptive.level3.net/vevo/ch1/04/prog_index.m3u8 plays fine for about 7 to 8 minutes and then freezes.
Can your connection keep up with the stream until the stall or does it interrupt to resync sometimes?
I saw three problems/behaviors that are related when investigating this: 1) When falling behind in the live stream, hlsdemux will repoistion itself to a valid segment and will push it with the discont flag marked and its timestamp set. The problem is that this timestamp can be very inaccurate when compared with the 'real' timestamp inside the stream. In this case the timestamp will be smaller than the real one (the larger the playback time, the worse the difference). 2) h264parse seems to ignore input timestamps after the first one. When this buffer with a discont and old timestamp is received it retimestamps it to keep timestamps increasing. The audio branch doesn't do this and it will preserve the input timestamps. 3) tsdemux will flush its mpegts time -> gst time mapping information when it receives a discont, so the next buffers after the hls resync have a much smaller timestamp provided from hlsdemux (which is just an approximation) and tsdemux is not able to fix that using the mpegts timing information because it now has to reset the timing as it received a discont
Some preliminary ideas: 1) One could push a segment before the discont and it would make the stream playback correctly from the new position but this seems like a hack to me as hlsdemux is not starting a new segment, it just has inaccurate timestamps (always). So, from its POV everything should be correct. I believe it should be tsdemux's job to have its timestamps fixed. 2) This seems like a bug, perhaps a discont here should also mean that it needs to reset its timestamping data. Unit tests would be helpful. 3) Perhaps we want to make tsdemux keep its timestamping information after a discont? We could make it handle both discont and resync flags differently. Each means to reset a different type of data. Discont -> content, resync -> time. This could also apply to item '2' above
Ignore item 2, that was a false alarm
Created attachment 299010 [details] [review] tsdemux: do not reset time info on discont Could you check if it works applying this patch and the patch at https://bugzilla.gnome.org/show_bug.cgi?id=745927 ? This patch might still need some discussion but I just want to see if this is the only issue
Not resetting timing info after discont might not be a good idea, maybe also breaks reverse playback. After a discont you should resync with the timestamp on the buffer.
(In reply to Sebastian Dröge (slomo) from comment #6) > Not resetting timing info after discont might not be a good idea, maybe also > breaks reverse playback. After a discont you should resync with the > timestamp on the buffer. *nod* @Philippe Anyway please test this patch just to confirm if the timestamp difference in hls resyncs is what causes the stall. This should help us find another solution
I confirm these 2 patches fix this issue but one side-effect is that after the stall the video decoder drops frames, that freezes rendering for a bit, but later on the decoder and sink catch up, hopefully :)
This is most likely solved by the fix in this bug : https://bugzilla.gnome.org/show_bug.cgi?id=750028 Can you recheck with current git master and confirm ?
Yep it works nicely now, thanks. *** This bug has been marked as a duplicate of bug 750028 ***