Re: How to set the video quality sent to a peer

On 03/17/2014 06:10 PM, giuseppe pes wrote:
>
> I need a bit of help with this new amazing technology called webRTC.
>
> Let's consider this scenario for a WebRTC mesh network with three 
> peers.. The Peer A has an HD stream from its cam and it is sharing 
> with the other 2 peers B and C. B and C are not sending any data. The 
> connection between A and B is rather good and the peer B can enjoy the 
> video at full HD. While the connection between A and C is not as good 
> as that between  A and B and it does not support an HD stream, thus B 
> is not having a smooth video stream. Nevertheless, the connection 
> between  C and A  would smoothly support a lower quality video, for 
> instance 640x480.
>
> I would like to provide a smooth video experience to both clients. I 
> could reduce the quality video of the source calling getUserMedia with 
> a lower quality but this is not a good solution because it would 
> reduce the quality of the video even for the peers that support HD (B) .
>
> What I would like to have is that the source peer ( A ) gets a stream 
> at its maximum quality, in this case HD. Then the quality of the video 
> to be sent to a peer is chosen according to the connection 
> characteristic between the source and that peer. In our previous example :
>
> |                    HD(1280x720)
>                /------------------->      B
>       A/
>    stream HD/
>   (1280x720)  \
>               \    HD(640x480)
>                \------------------->      C|
>
> How can I achieve this result? Can I modify the SDP descriptor to set 
> the video resolution just for that session?
>

What the spec says you should be able to do:

streama = 
getUserMedia({video:{mandatory:{width:{max:1280},height:{max:720}}}, ....)

streamb = streama.clone()
streamc = streama.clone()
// add streams to the various peerconnections
streamc.getVideoStreams[0].applyConstraints({mandatory{width: {max: 
640}, height:{max:480}}})

But I don't think any browser actually implements this yet.

Received on Tuesday, 18 March 2014 18:57:43 UTC