Massive increase in video quality in chrome by setting "x-google-max-bitrate" in SDP (breaks bandwidth cap of 300KBps)

[wiegell]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Steps to reproduce

1. Start any video call
2. Monitor network traffic

Expected behaviour

Should use full bandwidth

Actual behaviour

Chrome webRTC by default is limited to 300 KBps (at least on macOS - can Windows / Linux users confirm?).

Proof of concept

This bottleneck can be lifted by setting "x-google-max-bitrate" in SDP.
Credit goes to Cyh: https://stackoverflow.com/questions/57653899/how-to-increase-the-bitrate-of-webrtc
Implemented in a quick and dirty implementation here: wiegell@5c94fe6
This increases a 1080p stream from 300 KBps to around 1 - 1.5 MBps and adds alot of details.

Further implementation

I have no clue how this could affect scenarios with more than a couple of participants.
Also i dont know if the iOS or Android apps have similar limitations.
I would expect to have this option at least as an opt-in in the settings.

Talk app

Talk app version: (see apps admin page: /index.php/settings/apps)
13.0.1

Custom Signaling server configured: yes/no and version (see additional admin settings: /index.php/index.php/settings/admin/talk#signaling_server)
No

Custom TURN server configured: yes/no (see additional admin settings: /index.php/settings/admin/talk#turn_server)
No

Custom STUN server configured: yes/no (see additional admin settings: /index.php/settings/admin/talk#stun_server)
No

Browser

Microphone available: yes

Camera available: yes

Operating system: macOS

Browser name: Chrome

Browser version: 96.0.4664.110

Server configuration

Operating system: Armbian

Web server: Nginx

Database: MariaDB

PHP version: 7.4

Nextcloud Version: Nextcloud Hub II (23.0.0)

List of activated apps:

Enabled:
  - accessibility: 1.9.0
  - activity: 2.15.0
  - bruteforcesettings: 2.3.0
  - circles: 23.0.0
  - cloud_federation_api: 1.6.0
  - comments: 1.13.0
  - dashboard: 7.3.0
  - dav: 1.21.0
  - federatedfilesharing: 1.13.0
  - files: 1.18.0
  - files_automatedtagging: 1.13.0
  - files_external: 1.15.0
  - files_rightclick: 1.2.0
  - files_sharing: 1.15.0
  - files_trashbin: 1.13.0
  - files_versions: 1.16.0
  - files_videoplayer: 1.12.0
  - groupfolders: 11.1.0
  - logreader: 2.8.0
  - lookup_server_connector: 1.11.0
  - music: 1.5.0
  - notifications: 2.11.1
  - oauth2: 1.11.0
  - photos: 1.5.0
  - previewgenerator: 3.4.1
  - provisioning_api: 1.13.0
  - settings: 1.5.0
  - spreed: 13.0.1
  - systemtags: 1.13.0
  - text: 3.4.0
  - theming: 1.14.0
  - twofactor_backupcodes: 1.12.0
  - user_status: 1.3.1
  - viewer: 1.7.0
  - weather_status: 1.3.0
  - workflow_script: 1.8.0
  - workflowengine: 2.5.0
Disabled:
  - admin_audit
  - contactsinteraction
  - encryption
  - federation
  - files_pdfviewer
  - firstrunwizard
  - flow_notifications
  - nextcloud_announcements
  - password_policy
  - privacy
  - recommendations
  - serverinfo
  - sharebymail
  - support
  - survey_client
  - updatenotification
  - user_ldap

Nextcloud configuration:

{
    "system": {
        "memcache.local": "\\OC\\Memcache\\APCu",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "overwritewebroot": "\/nextcloud",
        "overwrite.cli.url": "https:\/\/raddoc.duckdns.org\/nextcloud",
        "trusted_domains": [
            "raddoc.duckdns.org"
        ],
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "23.0.0.10",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "log_type": "file",
        "logfile": "\/var\/log\/nextcloud.log",
        "logfilemode": 416,
        "loglevel": "0",
        "logdateformat": "F d, Y H:i:s",
        "updater.secret": "***REMOVED SENSITIVE VALUE***",
        "maintenance": false,
        "music.lastfm_api_key": "c29a7c80783f9b8c478eecd3ef45436e",
        "mysql.utf8mb4": true
    }
}

[wiegell]

A side note: Firefox on macOS seems to have a similar cap at around 500KBps

[nickvergessen]

The main question is if it is even a good idea to implement this. Many people suffer from bad connections and implementing something like this will break it even more for them. So it at least needs to be optional or depending on the quality negotiation, etc.

[wiegell]

Yes that could be a problem, but "x-google-max-bitrate" is not dictating a minimum bandwidth (that flag exists as well), so hopefully the regular webRTC mechanism will figure out to throttle speed on unstable connection.
My use case is regular calls to one or two other people at a time - both ends on wired fiber optic connections. I've tested Teams, Skype, Meet/Chat and Facetime. Only the ladder can manage a decent full HD stream on the free tier, so Nextcloud could be a front runner on video quality if this was implemented.

[nickvergessen]

@danxuliu ever heard of this?

[danxuliu]

Chrome webRTC by default is limited to 300 KBps (at least on macOS - can Windows / Linux users confirm?).

As far as I can see that (2500 Kbps -> ~300 KBps) is the default limit in all platforms for videos > 960x540.

@danxuliu ever heard of this?

Not until now :-) x-google-max-bitrate is, obviously, a Chrome-specific extension, and it looks like a legacy one, as it seems to do the same as the standard RTCRtpSender.setParameters({ maxBitrate: XXX }) (and the RTCRtpSender parameters takes precedence over x-google-max-bitrate).

The maximum bitrate, no matter if set with x-google-max-bitrate or RTCRtpSender.setParameters, is also affected by max_bandwidth_bps; if there is no maximum bandwidth then the maximum bitrate is cleared (I did not check how or when that parameter is set, though).

Also keep in mind that, when the HPB is used, the maximum bitrate will be limited too by the signaling server configuration. With a direct connection between two browsers it might be limited as well if the other browser sets the b=AS parameter in the SDP, although I have not checked this nor if any browser does that.

Independently of that, I would not increase the limit by default. And with a setting? I am not sure, at least it would need extensive testing :-)