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 683672 - [0.11] [API] GstAudioDecoder/Encoder: should set_latency/tolerance() argument be GstClockTime ?
[0.11] [API] GstAudioDecoder/Encoder: should set_latency/tolerance() argument...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.11.x
Other Linux
: Normal blocker
: 0.11.x
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-09-09 14:07 UTC by Tim-Philipp Müller
Modified: 2012-09-10 09:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Tim-Philipp Müller 2012-09-09 14:07:14 UTC 
Subject says it all, had an open FIXME about that somewhere.
Comment 1 Mark Nauwelaerts 2012-09-10 08:59:35 UTC 
Not sure about where/what that FIXME is, or what the problem is with having a GstClockTime argument.

However, situation currently is not quite consistent in that there are gint64 arguments and GstClockTime, and it probably does not hurt to change that to gint64 all around ?
Comment 2 Tim-Philipp Müller 2012-09-10 09:09:58 UTC 
Sorry, I meant to ask if it would make sense to change those from gint64 to GstClockTime.
Comment 3 Mark Nauwelaerts 2012-09-10 09:21:54 UTC 
OK, so changed to GstClockTime:

commit a29fab200c4a3e8a9277841677caed0704abf794
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Mon Sep 10 11:20:34 2012 +0200

    audio{de,en}coder: use GstClockTime parameters where appropriate
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=683672