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 745921 - tsparse: Smoothing latency is in microseconds
tsparse: Smoothing latency is in microseconds
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal blocker
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-03-09 21:31 UTC by Olivier Crête
Modified: 2015-03-15 14:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Olivier Crête 2015-03-09 21:31:13 UTC 
Why is this new property in usecs, which are almost never used elsewhere in GStreamer? I think it would make sense to either use nanosecs like we do elsewhere, or millisecs/secs if we want something easy to manipulate, micro-secs are just a strange in-between.
Comment 1 Jan Schmidt 2015-03-13 16:22:01 UTC 
*shrug* nanoseconds seemed overly precise and milliseconds not precise enough. We use microseconds elsewhere - audio sources and sinks.

I'd think I'd rather not arbitrarily change it when people are already using the elements - it'd break in subtle ways, since there'd be no warning it had changed.

If you really want, we could add a smoothing-latency-ns or so?
Comment 2 Sebastian Dröge (slomo) 2015-03-15 13:38:23 UTC 
Not two properties please, that's just confusing.

What should we do about this? Someone needs to make a decision, or it just stays as is ;)
Comment 3 Jan Schmidt 2015-03-15 14:23:49 UTC 
My preference is just to wont-fix.