1

Lets consider a P2P video conference with WebRTC where publisher is streaming in HD 1024x768 and a viewer joins that session and wants to view the video in say 320×240 to save bandwidth.

To give an anology it has to be like youtube's Quality option.

  1. Is it possible in WebRTC?
  2. If yes is this feature implemented in any of (agora | tokbox | vidyo | twilio)
marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Uday Reddy
  • 1,337
  • 3
  • 16
  • 38

3 Answers3

1

Is it possible in WebRTC?

Every peer will have a negotiation progress before they can receiving any stream. Senders already in this channel will know that they have to change their stream profiles during this progress.

If things happen to be someone already in this channel does not have enough bandwidth, the sender MediaOptimization module will know through RTCP receiver sent, and adjust the bitrate.

If yes is this feature implemented in any of (agora | tokbox | vidyo | twilio)

As far as I know, all they did at on the web are based on WebRTC (apparently they have rare choice).

Their native SDKs may have better quality on resolution switching, as they can use technologies like SVC, multi-streams and so on.

Galaxy
  • 1,129
  • 11
  • 27
0

I work at TokBox.

As far as implementing this with OpenTok yes it is possible. We support scalable video (simulcast) for "routed" sessions that go through our SFU. This means that you can send up HD resolution from the publisher and then subscribers can all subscribe at different resolutions depending on their bandwidth. You can also specify the preferred resolution using the setPreferredResolution API which will let you force it to use a lower resolution if eg. you know you are only displaying the subscriber at a small size.

Adam Ullman
  • 1,517
  • 7
  • 12
0

  • the only ways to change resolution in p2p mode, is to either to (a) tear down the peer connection, change the constraints to request a different resolution from the cam, and set up a new connection, (b) to renegotiate or (c) replace the track on the sender side. (c) is usually preferred as it does not force a new handshake which would potentially result in a visible glitch when changing resolution.

  • The good way to do this is to use a media server which receive several resolution of the source stream and only relay one depending on the capacity of the receiver. It can be achieved two ways: using an SVC codec like VP9, AV1, .... or if no SVC codec are available, using simulcast, i.e. use the same simple codec several times with different output resolution. Not every browser supports this today.

  • Most vendors will provide this option if you use their media server n the loop. It will be done out of the box in their native SDK in which they control the entire stack, and the support for the web will in turn depend on the browser support itself.

  • agora does not use webrtc really.

  • Vidyo is the SVC codec expert, but are blocked by browser implementations. I have not tested recently.

  • adam told you about tokbox they have had most of the possible options available for quite some time now.

  • I'm not current on twillio offering.

Dr. Alex Gouaillard
  • 2,078
  • 14
  • 13