Open bar-g opened 11 months ago
Note: baresip needs a restart for the "Opus Bit Rate" setting to take effect.
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?
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.
-- contents now included in description --
-- contents now included in description --
-- contents now included in description --
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:
its minimal bitrate (probably simplest)the selected bitrate limit.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:
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)
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:
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.)