After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 729124 - multiqueue: avoid signaling overrun on the first segment
multiqueue: avoid signaling overrun on the first segment
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal normal
: 1.2.5
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-04-28 16:20 UTC by Thiago Sousa Santos
Modified: 2014-04-28 21:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
multiqueue: avoid signaling overrun on the first segment (2.66 KB, patch)
2014-04-28 16:20 UTC, Thiago Sousa Santos
reviewed Details | Review
multiqueue: avoid signaling overrun on the first segment (3.57 KB, patch)
2014-04-28 19:04 UTC, Thiago Sousa Santos
committed Details | Review

Description Thiago Sousa Santos 2014-04-28 16:20:02 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.
Comment 1 Thiago Sousa Santos 2014-04-28 16:20:05 UTC
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.
Comment 2 Thiago Sousa Santos 2014-04-28 16:20:41 UTC
Sample: http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8
Comment 3 Luis de Bethencourt 2014-04-28 16:23:34 UTC
Looks good to me, and it is great to see a big informative comment.
Comment 4 Sebastian Dröge (slomo) 2014-04-28 17:03:22 UTC
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?
Comment 5 Thiago Sousa Santos 2014-04-28 17:18:53 UTC
(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.
Comment 6 Thiago Sousa Santos 2014-04-28 19:04:14 UTC
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
Comment 7 Thiago Sousa Santos 2014-04-28 21:17:13 UTC
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
Comment 8 Thiago Sousa Santos 2014-04-28 21:33:30 UTC
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