"Codec bitrate limit" setting not working

[bar-g]

I tested if linphone would be usable to connect to classic sip servers and clients under low-volume/low-bandwidth constrains, but found that setting the audio preference "Codec bitrate limit" to a lower value still results in using higher bitrates than selected without it being necessary. Thus this setting still seems to need some fixes to actually do bitrate limitation besides for a connection between two manually and equally configured linphone clients. (Test setup and results below.)

Currently, the "Codec bitrate limit" functionality:

• Does not actually limit the bandwidth used. For example, if selecting the lowest available option of 10kbps . [EDIT(added from comment):] It will happily accept calls and choose G722 wide-band, G711, and iLBC. (In that order, when disabling one after the other.) My guess about what's needed to implement a correct bandwidth limit:

  • [ ] Disable all codecs with a minimal bitrate above the limit value (grey out?).
  • [ ] If a codec covers different annexes or has variable bitrates, limit each individual codec to its minimal bitrate (probably simplest) the selected bitrate limit.
  • [ ] If a bitrate limit is set, not only apply it to one direction (the sent/received?) stream, use the limit when deciding to accept/negotiate incoming stream codecs, and any variable accepted and sent stream bitrate. (EDITED: This point was added from the findings/comments below.)

• Is missing the general option to "minimize bandwidth usage". Implementing this "minimize bandwidth usage" option (i.e. instead of maximizing quality) is very similar to the above bitrate limit bugfix, just with:

  • [ ] Sorting the codec preference list by the codec's minimal bitrates. (To override the (hardcoded) quality preference order.)
  • [ ] If no bitrate limit is set, only allow the minimal bitrate of each codec with a variable bitrate.

  This should have the effect of strictly minimized bitrate usage that is only using a higher bitrate codec if no lower bitrate alternative can be used.

Interestingly, it would also become very useful to use both options together in combination, i.e. "minimize bandwidth usage" and "Codec bitrate limit" (possibly renamed to "Codec bitrate allowance" to give a better picture): Then, the bitrate "allowance" would actually allow higher bitrates for each codec, and so the user could readily improve the speech quality (and increase the bandwidth usage) by manually disabling lowest bitrate codecs which they deem too low-quality in order to flexibly(AVPF) using one with a slightly higher minimal, but variable, bitrate like opus, while still not exceeding the bitrate allowence. (Ideally/later still, the user could be allowed to manually position codecs to the end of the priority list, if needed, in order to not result in an unnecessarily reduced list of supported compatible codes.)

Test setup (10kbps limit): Since the order of codecs seems to be hardcoded I tried working around this first obstacle by manually disabling the higher bandwidth codecs and only leaving enabled: opus, speex-8000, and iLBC.

Results: Too bad that the by now free, I think, G.729 codec, the narrow band AMR codec (part of mobile OS?), and the "codec2" are not available in linphone. (#2009)

• [ ] The GSM option in Linphone never does half-rate (HR), always does full-rate (FR) according to the call info, even with the 10kbps limit set. (So I currently had to disable it as well, to get iLBC used.)

During a call the call info popup in linphone shows some bandwith values. However I got the impression that those might just be the "available bandwith estimates" from the adaptivity algo (AVPF). Because they always seemed a bit larger than what the codecs bitrates made me expect, and fluctuated even under LAN conditions and with "Adaptive rate control" disabled. And also because if connecting to a baresip client, baresip seems to show the actual average bitrates in its info pop up:

Even though the 10kbps limit was enabled in linphone, baresip showed an average bitrate above 50kbps with opus connections . If however, in addition, on the baresip side, the baresip option "Opus Bit Rate" was manually set to its minimal 6000, then the average bitrate that baresip showed actually did stay low: 3,4/3,6kbps (in a connection with the same linphone client).

---

Update: (after using the Opus codec with the current 10kbits/s limit setting and comparing)

With these settings the Opus sound qualtity in Linphone is degrated, practically unpleasant, and really worse than the 8000 kbps samples at: https://www.opus-codec.org/examples/

Think this is due to the fast Opus quality degradation below 8000kbps, and Linphone seems to be using much lower bitrate modes with the 10kbits/s limit according to the baresip call-info above. Note, that the opus website doesn't even offer samples with bitrates below 8000.

Speex does officially support bitrates of 4 and 6 kbps, and with much better quality. Hear samples at: https://www.speex.org/samples/ That's confirming the superiority of speex for lower bitrates as shown in this chart: https://en.wikipedia.org/wiki/Opus_(audio_format)#/media/File:Opus_quality_comparison_colorblind_compatible.svg

So, this means that:

• [ ] At least in "minimize bandwidth" mode, or always if we can dynamically switch different codecs, increase the min. bitrate for opus to 8000kbps, so that it won't be used for low bitrates before speex.
• [ ] Check that current speex 8000Hz (narrow band) option does make use of the superior 4 and 6 kbps speex modes.

With this the higher opus bitrates (superior quality) should get used if possible (i.e. when a large enough kbits/s limit is set) while the best low-bitrate codecs are used when minimizing bandwidth usage. (Removing the need to manually disable opus in order to not suffer from poor voice quality with a low limit or minimize setting.)

[bar-g]

Note: baresip needs a restart for the "Opus Bit Rate" setting to take effect.

[bar-g]

It occurred to me that I might have misinterpreted the baresip averages like 3,6/3,6 as current average/max. bitrates, but they could be the bitrates sent/received or received/sent.

If these are the sent and received values, then it really puzzles me why they differ like 64,4/3,6. Could it be that linphone currently only applies the rate limit to its outgoing stream, but not for accepting the incoming stream?

Do I see it correctly that with linphone the incoming stream is currently only limited with an additional limit setting on the other side?

• [ ] Also apply a bitrate limit to accepted incoming streams

The thing that seems to hint to that is that if completely removing the limit in linphone but keeping the"Opus Bit Rate" setting in baresip, then the average bitrates shown in baresip are still low like 3,4/3,6.

[bar-g]

-- contents now included in description --

[bar-g]

-- contents now included in description --

[bar-g]

-- contents now included in description --