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 785799 - urisourcebin: Buffering broken for adaptive streams with inactive streams
urisourcebin: Buffering broken for adaptive streams with inactive streams
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other Linux
: Normal major
: 1.12.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 775945 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-08-04 07:08 UTC by Sebastian Dröge (slomo)
Modified: 2017-08-11 08:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
queue2: Handle buffering levels on NOT_LINKED (2.46 KB, patch)
2017-08-07 10:28 UTC, Edward Hervey
committed Details | Review

Description Sebastian Dröge (slomo) 2017-08-04 07:08:56 UTC
Problem here is that urisourcebin adds a buffering queue2 after each adaptivedemux stream. But adaptivedemux is pausing streams that return not-linked (e.g. if you have 2 audio streams, one won't be linked) to keep bandwidth usage low.

These unlinked streams will obviously never reach 100% buffering unless they accidentially did before the first time not-linked was returned.


Maybe queue2 should post buffering 100% on not-linked, maybe something else should be done.
Comment 1 Edward Hervey 2017-08-07 07:54:37 UTC
Indeed, for unlinked streams it should mark it as "full", same as streams that are EOS (either from upstream or downstream).

Question is ... is an incoming stream is marked as sparse, should we also always consider it full ? multiqueue does, but not 100% sure if there's a use-case for queue2 where we would want to consider it non-full.
Comment 2 Edward Hervey 2017-08-07 10:28:26 UTC
Created attachment 357098 [details] [review]
queue2: Handle buffering levels on NOT_LINKED

When downstream returns NOT_LINKED, we return the buffering level
as being 100%.

Since the queue is no longer being consumed/used downstream, we
want applications to essentially "ignore" this queue for buffering
purposes.

If other streams are still being used, those stream buffering levels
will be used. If none are used, upstream will post an error message
on the bus indicating no streams are used.
Comment 3 Edward Hervey 2017-08-07 12:46:09 UTC
Comment on attachment 357098 [details] [review]
queue2: Handle buffering levels on NOT_LINKED

Actually I'm still seeing some issues with validate adaptive content testsuite, will investigate
Comment 4 Seungha Yang 2017-08-07 23:12:25 UTC
Hello all

I have encountered identical problem, and reported it on bug #775945. It seems to duplication of this bug :)
Comment 5 Sebastian Dröge (slomo) 2017-08-08 07:42:23 UTC
*** Bug 775945 has been marked as a duplicate of this bug. ***
Comment 6 Sebastian Dröge (slomo) 2017-08-08 07:46:14 UTC
Comment on attachment 357098 [details] [review]
queue2: Handle buffering levels on NOT_LINKED

Good to go, the remaining problems are bug #785951 which is independent of this here
Comment 7 Edward Hervey 2017-08-08 08:35:45 UTC
commit 4312119d167405f726c39ec5517d7124e1e99444
Author: Edward Hervey <edward@centricular.com>
Date:   Mon Aug 7 12:24:37 2017 +0200

    queue2: Handle buffering levels on NOT_LINKED
    
    When downstream returns NOT_LINKED, we return the buffering level
    as being 100%.
    
    Since the queue is no longer being consumed/used downstream, we
    want applications to essentially "ignore" this queue for buffering
    purposes.
    
    If other streams are still being used, those stream buffering levels
    will be used. If none are used, upstream will post an error message
    on the bus indicating no streams are used.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=785799