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 315214 - gstreamer flac encoder reports invalid data for sink query
gstreamer flac encoder reports invalid data for sink query
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.8.10
Other Linux
: High normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-09-04 08:33 UTC by Aaron Bockover
Modified: 2006-03-22 14:53 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Aaron Bockover 2005-09-04 08:33:27 UTC
Distribution/Version: SuSE 10 Beta 3

The GStreamer Flac Plugin returns same value for the total query as it does the
position query on a sink. The position query seems accurate, while the total
query is not (the two values are always the same).

GstFormat format = GST_FORMAT_BYTES;
gint64 position, total;
...
gst_element_query(sink, GST_QUERY_POSITION, &format, &position);
gst_element_query(sink, GST_QUERY_TOTAL, &format, &total);

The queries are performed inside a while(gst_bin_iterate(...)) loop, if it may
make any differnce. For reference, the source exhibiting the bug in Banshee is
here:
http://cvs.gnome.org/viewcvs/banshee/libbanshee/gst-encode.c?rev=1.3&view=markup

Other plugins (lame, xing, faac) return a proper total bytes.
Comment 1 Tim-Philipp Müller 2005-09-05 08:32:27 UTC
What is the exact pipeline you are using? And what's the format of the input file?

FWIW, none of those encoders implements a query function as far as I know. The
queries will be answered by the decoders.

Some notes on the code:
 - it should check the return value of gst_element_query()
 - it should use 'decodebin' instead of 'spider'

If all you want to know is encoding progress in percent, then querying the
decoders for time position and total time and calculating the % value from that
might be a safer bet. That should always work because it's used for players.

Cheers
 -Tim
Comment 2 Tim-Philipp Müller 2005-10-31 11:32:15 UTC
Seems to work fine here. Need more information to go on. Please reopen the bug
if you can tell me how to reproduce your issue.

Cheers
 -Tim

% gst-launch-0.8 filesrc location=foo.mp3 ! mad ! audioconvert ! flacenc !
progressreport update-freq=3 ! filesink location=/dev/null
RUNNING pipeline ...
progressreport0 ( 0: 0: 3): 1003392 / 6718864 unknown ( 15 %)
progressreport0 ( 0: 0: 6): 2302848 / 6718864 unknown ( 34 %)
progressreport0 ( 0: 0: 9): 3468672 / 6718864 unknown ( 52 %)
progressreport0 ( 0: 0:12): 4952448 / 6718864 unknown ( 74 %)
progressreport0 ( 0: 0:15): 6459264 / 6718864 unknown ( 96 %)
Execution ended after 523 iterations (sum 14377063000 ns, average 27489604 ns,
min 324000 ns, max 298195000 ns).


% gst-launch-0.8 filesrc location=foo.ogg ! decodebin ! audioconvert ! flacenc !
progressreport update-freq=5 ! filesink location=/dev/null
RUNNING pipeline ...
progressreport0 ( 0: 0: 5): 2198719 / 19133519 unknown ( 11 %)
progressreport0 ( 0: 0:10): 4350527 / 19133519 unknown ( 23 %)
progressreport0 ( 0: 0:15): 6668351 / 19133519 unknown ( 35 %)
progressreport0 ( 0: 0:20): 9069119 / 19133519 unknown ( 47 %)
progressreport0 ( 0: 0:25): 11767999 / 19133519 unknown ( 62 %)
progressreport0 ( 0: 0:30): 14077887 / 19133519 unknown ( 74 %)
progressreport0 ( 0: 0:35): 16631231 / 19133519 unknown ( 87 %)
Execution ended after 1561 iterations (sum 38859968000 ns, average 24894278 ns,
min 29000 ns, max 503783000 ns).