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 753737 - opusenc: Bitrate limit is too low
opusenc: Bitrate limit is too low
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-08-17 23:25 UTC by caiz8cw02
Modified: 2018-11-03 11:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
opusenc: Raise bitrate limit (1.81 KB, patch)
2015-08-17 23:25 UTC, caiz8cw02
reviewed Details | Review

Description caiz8cw02 2015-08-17 23:25:16 UTC
Created attachment 309431 [details] [review]
opusenc: Raise bitrate limit

The bitrate property has a limit of 650 kb/s. However the actual valid limit is around 255 kb/s per channel, and Opus supports up to 8 channels with defined mappings, and up to 255 channels with a user-defined mapping.
Comment 1 Sebastian Dröge (slomo) 2015-08-18 09:22:18 UTC
Comment on attachment 309431 [details] [review]
opusenc: Raise bitrate limit

Should we clamp the highest bitrate once we know how many channels are going to be used to the actual maximum?
Comment 2 caiz8cw02 2015-08-18 13:12:40 UTC
That's up to you. The worst that'll happen if you don't is that libopus will clamp the per-channel value to 300000 bps.
Comment 3 Sebastian Dröge (slomo) 2015-08-18 13:40:52 UTC
300000bps or 255kb/s as you said above? But anyway, the clamping happens inside libopus in any case?
Comment 4 caiz8cw02 2015-08-18 14:14:37 UTC
255 kbps is approximately the maximum useful value, in the sense that if you ask for more than this, libopus will either pad with zeros or use fewer bits (depending on other settings). But yes, it will clamp per-channel values inside libopus. I.e., the unclamped value is used to make allocations to each channel/stream, and then the per-stream values are clamped to 300000 kbps per channel, mostly to avoid problems with arithmetic overflow deeper inside the codec.
Comment 5 Tim-Philipp Müller 2016-03-03 18:45:40 UTC
Minded to apply after freeze. We can just warn if someone sets a limit that doesn't make sense for the number of channels.
Comment 6 GStreamer system administrator 2018-11-03 11:40:08 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/212.