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 766360 - pad: Don't drop LATENCY queries with default implementation
pad: Don't drop LATENCY queries with default implementation
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal normal
: 1.9.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-05-13 07:49 UTC by Edward Hervey
Modified: 2018-08-31 09:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
pad: Don't drop LATENCY queries with default implementation (2.12 KB, patch)
2016-05-13 07:49 UTC, Edward Hervey
rejected Details | Review

Description Edward Hervey 2016-05-13 07:49:42 UTC
See commit
Comment 1 Edward Hervey 2016-05-13 07:49:48 UTC
Created attachment 327755 [details] [review]
pad: Don't drop LATENCY queries with default implementation

If there is only one pad in the internal pads, when folding for
LATENCY queries it will just drop the response if it's not live.

This is maybe not the proper fix, but it will just accept the first
peer responses, and if there are any other pads, it will only take
them into account if the response is live.

This *should* properly handle the aggregation/folding behaviour of
multiple live peer responses, while at the same time handling the
simple one-pad-only-and-forward use-case
Comment 2 Edward Hervey 2016-05-13 09:38:42 UTC
commit 794944f779f954375fc74a3fffcc2067bba6a3e5
Author: Edward Hervey <bilboed@bilboed.com>
Date:   Fri May 13 09:43:14 2016 +0200

    pad: Don't drop LATENCY queries with default implementation
    
    If there is only one pad in the internal pads, when folding for
    LATENCY queries it will just drop the response if it's not live.
    
    This is maybe not the proper fix, but it will just accept the first
    peer responses, and if there are any other pads, it will only take
    them into account if the response is live.
    
    This *should* properly handle the aggregation/folding behaviour of
    multiple live peer responses, while at the same time handling the
    simple one-pad-only-and-forward use-case
    
    https://bugzilla.gnome.org/show_bug.cgi?id=766360
Comment 3 Sebastian Dröge (slomo) 2018-08-31 09:16:35 UTC
Comment on attachment 327755 [details] [review]
pad: Don't drop LATENCY queries with default implementation

This was reverted again as it results in invalid values in various cases:
a) if the first pad is not live but a following pad is live
b) generally, non-live latency values make no sense and can't be used in a meaningful way. Any code using them is most likely buggy.

Please re-open if the original bug reappears and you have a testcase :)