GNOME Bugzilla – Bug 729124
multiqueue: avoid signaling overrun on the first segment
Last modified: 2014-04-28 21:33:30 UTC
See attached patch. Easy to reproduce when switching bitrates with adaptive streams that use mpegts. The segment has a position of a few seconds usually and it leads to the multiqueue signaling overrun and making decodebin expose a group that has only audio/video as the mpegtsdemuxer hasn't exposed the other pad yet.
Created attachment 275359 [details] [review] multiqueue: avoid signaling overrun on the first segment When the first segment has position != 0 and position > max-size-time it will immediatelly cause the multiqueue to signal overrun. This can happen easily with adaptive streams when switching bitrates and starting a new group. The segment for this new group will have a position that is much greater than 0 and will lead to this issue. This is particularly harmful when the adaptive stream uses mpegts that doesn't emit no-more-pads and it might happen that only one of the stream pads was added when the multiqueue overruns and gets the group ready for exposing. So the user will only get audio or video. The solution is to copy immediately the first segment received from the sink to the source segment.
Sample: http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8
Looks good to me, and it is great to see a big informative comment.
Comment on attachment 275359 [details] [review] multiqueue: avoid signaling overrun on the first segment While the bug and analysis is correct, this seems like a rather awkward way of fixing it somehow :) Also can't the same situation on a segment update, i.e. if you already have a src segment but got a new one, didn't apply it yet and get a buffer that fills it all up?
(In reply to comment #4) > (From update of attachment 275359 [details] [review]) > While the bug and analysis is correct, this seems like a rather awkward way of > fixing it somehow :) Also can't the same situation on a segment update, i.e. if > you already have a src segment but got a new one, didn't apply it yet and get a > buffer that fills it all up? Yes, it could happen, but if you have a segment on your source pad and you receive either another segment or a buffer with a timestamp that makes it full you really have some 'data' inside the single queue to make it full. Even if this data is actually an indirect representation of a gap in the stream. One can argue that this is not really data, but I can see valid points either way. This patch fixes the situation where multiqueue would assume this gap would exist just because the default time for the source pad without any received data would be 0. In this case I can't see any way where this would be correct.
Created attachment 275372 [details] [review] multiqueue: avoid signaling overrun on the first segment Alternative solution after discussing on IRC. Changes: 1) adds a note on why 'has_src_segment' is preferred over using segment.format = UNDEFINDER 2) Instead of copying the segment to the src_segment, just use the sink_segment directly as a fallback in update_time_level
Thanks for the review. commit 0a3bc6be1fc09a8aabde43505f9c3f0dfaf2ed94 Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Mon Apr 28 13:02:11 2014 -0300 multiqueue: avoid signaling overrun on the first segment When the first segment has position != 0 and position > max-size-time it will immediatelly cause the multiqueue to signal overrun. This can happen easily with adaptive streams when switching bitrates and starting a new group. The segment for this new group will have a position that is much greater than 0 and will lead to this issue. This is particularly harmful when the adaptive stream uses mpegts that doesn't emit no-more-pads and it might happen that only one of the stream pads was added when the multiqueue overruns and gets the group ready for exposing. So the user will only get audio or video. The solution is to fallback to the sink segment while the source pad has no segment. https://bugzilla.gnome.org/show_bug.cgi?id=729124
Backported to 1.2 commit f8c6552e5ac570050ae9f283612eba07be5b3dc8 Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Mon Apr 28 13:02:11 2014 -0300 multiqueue: avoid signaling overrun on the first segment When the first segment has position != 0 and position > max-size-time it will immediatelly cause the multiqueue to signal overrun. This can happen easily with adaptive streams when switching bitrates and starting a new group. The segment for this new group will have a position that is much greater than 0 and will lead to this issue. This is particularly harmful when the adaptive stream uses mpegts that doesn't emit no-more-pads and it might happen that only one of the stream pads was added when the multiqueue overruns and gets the group ready for exposing. So the user will only get audio or video. The solution is to fallback to the sink segment while the source pad has no segment. https://bugzilla.gnome.org/show_bug.cgi?id=729124