search

Kurento / bugtracker

[ARCHIVED] Contents migrated to monorepo: https://github.com/Kurento/kurento
46 stars 10 forks source link

setMaxVideoSendBandwidth and similar methods have no effect on receiving WebRtcEndpoint #293

Open t-mullen opened 6 years ago

t-mullen commented 6 years ago

KMS Version:

Kurento Media Server version: 6.7.1
Found modules:
    'core' version 6.7.1
    'elements' version 6.7.1
    'filters' version 6.7.1

Other libraries versions:

ii  gstreamer1.5-libav:amd64              1.8.2.1~20160909143244.96.g493eee4.trusty  amd64        libav plugin for GStreamer
ii  gstreamer1.5-nice:amd64               0.1.13.1~20160930090742.81.geebfdab.trusty amd64        ICE library (GStreamer plugin)
ii  gstreamer1.5-plugins-bad:amd64        1.8.1.1~20160909144557.99.gf836e53.trusty  amd64        GStreamer plugins from the "bad" set
ii  gstreamer1.5-plugins-base:amd64       1.8.1.1~20160909142623.55.g7b19cfd.trusty  amd64        GStreamer plugins from the "base" set
ii  gstreamer1.5-plugins-good:amd64       1.8.1.1~20160909143047.112.g9ee4248.trusty amd64        GStreamer plugins from the "good" set
ii  gstreamer1.5-plugins-ugly:amd64       1.8.1.1~20160909192513.89.g2685b0f.trusty  amd64        GStreamer plugins from the "ugly" set
ii  gstreamer1.5-pulseaudio:amd64         1.8.1.1~20160909143047.112.g9ee4248.trusty amd64        GStreamer plugin for PulseAudio
ii  gstreamer1.5-x:amd64                  1.8.1.1~20160909142623.55.g7b19cfd.trusty  amd64        GStreamer plugins for X11 and Pango
ii  kms-core                              6.7.1.trusty.20180322151212.47e0370        amd64        Kurento Core module
rc  kms-core-6.0                          6.6.3.trusty.20170811193010.2704d13        amd64        Kurento core module
ii  kms-elements                          6.7.1.trusty.20180322161851.5aaf4a0        amd64        Kurento Elements module
rc  kms-elements-6.0                      6.6.3.trusty.20170811201004.9e3fff4        amd64        Kurento elements module
ii  kms-filters                           6.7.1.trusty.20180322170020.7f2d045        amd64        Kurento Filters module
rc  kms-filters-6.0                       6.6.2.trusty.20170725133434.7b4c9ea        amd64        Kurento filters module
ii  kms-jsonrpc                           6.7.1.trusty~20180322150101.1.637bf2a      amd64        Kurento JSON-RPC library
rc  kms-jsonrpc-1.0                       1.1.3.trusty.20170725112926.ee575c6        amd64        Kurento jsonrpc library
ii  kmsjsoncpp                            1.6.3.trusty.20170725122830.d78deb7        amd64        Kurento jsoncpp library
ii  kurento-media-server                  6.7.1.trusty.20180322174246.dd49a2c        amd64        Kurento Media Server
rc  kurento-media-server-6.0              6.6.2.trusty.20170725135150.8e7ceee        amd64        Kurento Media Server
ii  libgstreamer-plugins-bad1.5-0:amd64   1.8.1.1~20160909144557.99.gf836e53.trusty  amd64        GStreamer development files for libraries from the "bad" set
ii  libgstreamer-plugins-base1.5-0:amd64  1.8.1.1~20160909142623.55.g7b19cfd.trusty  amd64        GStreamer libraries from the "base" set
ii  libgstreamer1.5-0:amd64               1.8.1.1~20160909144007.170.g0d6031b.trusty amd64        Core GStreamer libraries and elements
ii  libnice10:amd64                       0.1.13.1~20160930090742.81.geebfdab.trusty amd64        ICE library (shared library)
ii  openh264-gst-plugins-bad-1.5:amd64    1.8.1.1~20160909144557.99.gf836e53.trusty  amd64        GStreamer plugins from openh264

Client libraries

Browsers tested

System description: KMS and TURN is on an AWS EC2 instance. Public STUN.

What steps will reproduce the problem?

  1. Create a working WebRTCEndpoint receiving video from any other WebRTCEndpoint or RTPEndpoint. The WebRTCEndpoint must be receiving video (sending from WebRTCEndpoint works as expected).
  2. Add any/all of the following methods, where BANDWIDTH is any integer value: 
      endpoint.setMaxVideoSendBandwidth(BANDWIDTH)
  endpoint.setMinVideoSendBandwidth(BANDWIDTH)
  endpoint.setMaxVideoRecvBandwidth(BANDWIDTH)
  endpoint.setMinVideoRecvBandwidth(BANDWIDTH)
  endpoint.setOutputBitrate(BANDWIDTH)
  3. Observe no change in behaviour.

What is the expected result? The bandwidth or bitrate change results in an SDP change, visual change, or any change.

What happens instead? Nothing changes. The SDP is the same, no visual change, no noticeable change in sniffed traffic or bandwidth usage. Methods appear to have no effect whatsoever.

Does it happen with one of the tutorials? Yes, I've tried this with multiple tutorials that involve the WebRTCEndpoint.

Please provide any additional information below. Manually changing the SDP to add b-lines on the client (the typical way to manipulate bitrate in WebRTC), also has no effect, suggesting Kurento is actively ignoring these lines in addition to refusing to add them to it's own SDP.

I am calling these methods immediately after the endpoint is created (in the callback like so):

pipeline.create('WebRtcEndpoint', (err, endpoint) => {
   endpoint.setMaxVideoSendBandwidth(BANDWIDTH)
   // ...
   endpoint.processOffer(offer, (err, answer) => { /* ... */ })
})

The methods seem to be working as expected for RTPEndpoint.

joe-at-siemens commented 5 years ago

I have also observed this. I have verified that these properties are set, but the generated SDP has no lines starting with 'b='.

joe-at-siemens commented 5 years ago

Should the SDP messages change in response to changes to these properties? Or are they supposed to be used internally to manage the bitrates?

micaelgallego commented 5 years ago

They are used internally

joe-at-siemens commented 5 years ago

So if there is no effect on SDP offer generation, then how should we verify whether the methods are having an effect or not?

On 26. Oct 2018, at 09:25, Micael Gallego notifications@github.com<mailto:notifications@github.com> wrote:

They are used internally

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Kurento/bugtracker/issues/293#issuecomment-433313422, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AqaKcfTpYS0vdc-ZhsmoWU6JUciWGgPbks5uorjxgaJpZM4V-leg.

micaelgallego commented 5 years ago

When you limit bandwidth, you can test it in webrtc-internals, for example.

joe-at-siemens commented 5 years ago

I have checked there, and will check again. What would it take for this bug to be closed?

I have an urgent requirement for improved video quality. Would changing the defaults in the C/C++ code have an effect that we otherwise may not be seeing when changing the properties via API calls?

On 26. Oct 2018, at 10:13, Micael Gallego notifications@github.com<mailto:notifications@github.com> wrote:

When you limit bandwidth, you can test it in webrtc-internals, for example.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Kurento/bugtracker/issues/293#issuecomment-433325985, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AqaKcWhGEP3xar7J5TUUlPt3vO97IgYrks5uosQtgaJpZM4V-leg.

micaelgallego commented 5 years ago

What is exactly your problem? setMaxVideoSendBandwidth: sets maximum bitrate limits for video sent to remote peer. 0 is considered unconstrained.

If you want to restrict received video bandwidth you will need to change that in browser side, no?

joe-at-siemens commented 5 years ago

As the original poster of this bug explained setMaxVideoSendBandwidth and related methods seem to have no effect on WebRtcEndpoint. This is my experience also.

I would like to configure a higher maximum bandwidth for sending and receiving than the default 500 kbit/s (e.g. 1000kbit/s) but not necessarily unconstrained (0).

On 26. Oct 2018, at 10:24, Micael Gallego notifications@github.com<mailto:notifications@github.com> wrote:

What is exactly your problem? setMaxVideoSendBandwidth: sets maximum bitrate limits for video sent to remote peer. 0 is considered unconstrained.

If you want to restrict received video bandwidth you will need to change that in browser side, no?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Kurento/bugtracker/issues/293#issuecomment-433328981, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AqaKcVTXcsltQ7iW-y-C_qgOHdHBiC5Rks5uosbDgaJpZM4V-leg.

neilyoung commented 5 years ago

For me it works. I posted lately on this.

Sent from my iPhone

Am 26.10.2018 um 10:33 schrieb joe-at-siemens notifications@github.com:

As the original poster of this bug explained setMaxVideoSendBandwidth and related methods seem to have no effect on WebRtcEndpoint. This is my experience also.

I would like to configure a higher maximum bandwidth for sending and receiving than the default 500 kbit/s (e.g. 1000kbit/s) but not necessarily unconstrained (0).

On 26. Oct 2018, at 10:24, Micael Gallego notifications@github.com<mailto:notifications@github.com> wrote:

What is exactly your problem? setMaxVideoSendBandwidth: sets maximum bitrate limits for video sent to remote peer. 0 is considered unconstrained.

If you want to restrict received video bandwidth you will need to change that in browser side, no?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Kurento/bugtracker/issues/293#issuecomment-433328981, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AqaKcVTXcsltQ7iW-y-C_qgOHdHBiC5Rks5uosbDgaJpZM4V-leg. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

joe-at-siemens commented 5 years ago

Thanks for hints. I am investigating.

Joe

From: neilyoung [mailto:notifications@github.com] Sent: 26 October 2018 12:08 To: Kurento/bugtracker Cc: Newman, Joseph (CT RDA SDT IPV-DE); Comment Subject: Re: [Kurento/bugtracker] setMaxVideoSendBandwidth and similar methods have no effect on receiving WebRtcEndpoint (#293)

For me it works. I posted lately on this.

Sent from my iPhone

Am 26.10.2018 um 10:33 schrieb joe-at-siemens notifications@github.com:

As the original poster of this bug explained setMaxVideoSendBandwidth and related methods seem to have no effect on WebRtcEndpoint. This is my experience also.

I would like to configure a higher maximum bandwidth for sending and receiving than the default 500 kbit/s (e.g. 1000kbit/s) but not necessarily unconstrained (0).

On 26. Oct 2018, at 10:24, Micael Gallego notifications@github.com<mailto:notifications@github.com> wrote:

What is exactly your problem? setMaxVideoSendBandwidth: sets maximum bitrate limits for video sent to remote peer. 0 is considered unconstrained.

If you want to restrict received video bandwidth you will need to change that in browser side, no?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Kurento/bugtracker/issues/293#issuecomment-433328981, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AqaKcVTXcsltQ7iW-y-C_qgOHdHBiC5Rks5uosbDgaJpZM4V-leg. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Kurento/bugtracker/issues/293#issuecomment-433358409, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AqaKcQZm5nMujWQZHyqOpwj2Tj3Uo4yAks5uot7mgaJpZM4V-leg.

t-mullen commented 5 years ago

I eventually worked around this by munging the b lines into the SDP myself, but I don't think that setMaxVideoRecvBandwidth or setMinVideoRecvBandwidth are behaving correctly or do anything at all for WebRTC endpoints.

I was even able to set ridiculously small values like endpoint.setMaxVideoRecvBandwidth(1) (that's 1 kbps) and video still flowed as before, with identical quality.

neilyoung commented 5 years ago

After all I think I have to agree: Controlling the bandwidth used by the KMS transmitter seems to be not possible at all :(

EDIT: For sure not, if there is any kind of OpenCV filter involved.

chevonc commented 5 years ago

Hmm, hitting similar issues here @t-mullen can you elaborate a bit more on this? Did you do this on the browsers SDP offer to kurento? Or the returned kurento offer to the browser?

t-mullen commented 5 years ago

The browser's SDP offer to Kurento. The offer has the m-lines for the media, so it gets the b-lines too.

It's a client-side bitrate limit, so could be bypassed if you don't validate SDP.

joe-at-siemens commented 5 years ago

I have done a fresh round of testing and can verify that the methods

still have no discernible effect using

Kurento Media Server version: 6.10.0 Found modules: 'core' version 6.10.0 'elements' version 6.10.0 'filters' version 6.10.0

If fixing them is unlikely then it would be good to mark them as broken in the documentation.