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 391543 - lame should add a tag with the chosen bitrate
lame should add a tag with the chosen bitrate
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
git master
Other Linux
: Normal enhancement
: 0.10.19
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2007-01-01 15:33 UTC by Julien MOUTTE
Modified: 2011-05-18 13:17 UTC
See Also:
GNOME target: ---
GNOME version: ---

Proposed patch fixing all those issues (4.14 KB, patch)
2007-01-01 15:54 UTC, Julien MOUTTE
rejected Details | Review

Description Julien MOUTTE 2007-01-01 15:33:58 UTC
the CHECK_AND_FIXUP_BITRATE macro is buggy and for bitrate <= 64 kbps it always end up rounding it up to the first 64 multiple, hence 64.
Comment 1 Julien MOUTTE 2007-01-01 15:51:58 UTC
while i m on lame, it would be nice to show the bitrate value in the src caps when using CBR encoding, that would allow muxers to store the bitrate correctly.

It would also be nice to provide a way to force the output sample rate instead of always letting lame select it for us.
Comment 2 Julien MOUTTE 2007-01-01 15:54:12 UTC
Created attachment 79142 [details] [review]
Proposed patch fixing all those issues

+ Add the bitrate to the caps in CBR.
+ Fix the bitrate check macro.
+ add an out_samplerate property.
Comment 3 Tim-Philipp Müller 2007-01-01 18:22:52 UTC
Looks good to me, but there are two small things I wonder about:

 - wouldn't "the GStreamer way" to force a specific output sample rate
   be filter caps after the lame element rather than a property?

 - why the bitrate in the caps and not in a tag event? Do we do it like this
   elsewhere as well?
Comment 4 Thomas Vander Stichele 2007-01-02 10:56:53 UTC
+1 on not adding a property to lame just to force outgoing sample rate - this is waht filtercaps are for.

Not sure about bitrate in the caps; I think it's ugly to communicate with a muxer this way - caps really are a way for elements to discuss together what they can and are going to do.  bitrate is not really a property of the stream the way all the other caps are.  Someone else should decide though.
Comment 5 Thomas Vander Stichele 2007-02-21 16:01:18 UTC
Woah, that lame bug was nasty.  Not being able to do 96 kbit/sec is silly :)

I commited a partial and updated patch for that issue to CVS, and improving on the reporting, giving a WARNING message to the pipeline.

We still need to decide how to inform the application of the bitrate chosen in some way.
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2007-03-02 15:13:28 UTC
I'd say lets use tags to inform the app:
#define             GST_TAG_BITRATE
#define             GST_TAG_NOMINAL_BITRATE
#define             GST_TAG_MINIMUM_BITRATE
#define             GST_TAG_MAXIMUM_BITRATE
Comment 7 Wim Taymans 2007-03-02 15:58:41 UTC
bitrate must be an element configure parameter, just like the other gazilion config options in lame. Caps are strictly for letting the peer element know about the media type, not its configuration (which could be in the data itself) or the parameters used for creating this file.
Comment 8 Stefan Sauer (gstreamer, gtkdoc dev) 2007-03-02 16:08:25 UTC
bitrate is a parameter already. the tag should be use to inform about which bitrate actualy got used.
Comment 9 Sebastian Dröge (slomo) 2011-05-18 13:17:54 UTC
Ok, this was fixed after a few years now :) But only for the new lamemp3enc element, the lame element is deprecated and will disappear in 0.11 anyway.

commit b0e7e273656ad49e7b5f91e369f74a315182bbe2
Author: Sebastian Dröge <>
Date:   Wed May 18 14:49:17 2011 +0200

    lamemp3enc: Post CODEC and BITRATE tags
    Also filter any CODEC/AUDIO_CODEC tags from incoming
    tag events.
    Fixes bug #391543.