Re: [discuss-webrtc] Adjusting to hardware capabilities....

[Alexandre GOUAILLARD]

dear ari,

the constraints are not honored as of yet. You can follow the following issue (by "staring" it) to be informed of when it will become available.

http://code.google.com/p/webrtc/issues/detail?id=1701

By default, webrtc will start with a reasonable assumption of the available bandwidth and will then slowly use whatever is available up to 2Mb.

You can modify directly the sdp to add a constraint for the time being by using for example the following code. No real black magic, so feel free to re-use it, (as in BSD licence) . If you like it, just give credit to alex.go...@temasys.com.sg

change 50 and 256 to whatever the bandwidth limit you want to be for audio and video streams, or make it an argument of the function if you want to make it more flexible (and potentially depend on prior hardware probing).

HTH, cheers.

alex.

//--------------------------------------------------------------------

// SDP Manipulation - full SDP

//

function limitBandwidth( sdp )

{

  // split sdp message into an array.

  // each element of the array is one line of the sdp

  var sdpLines = sdp.split('\r\n');

  // search for media, and then add bandwidth limit

  // Search for m line.

  for (var i = 0; i < sdpLines.length; i++)

    if (sdpLines[i].search('m=') !== -1)

      sdpLines = insertBandwidthLimit( sdpLines, i );

  // reconstruct the SDP message

  sdp = sdpLines.join('\r\n');

  return sdp;

}

//--------------------------------------------------------------------

// SDP Manipulation - Multiple lines

//

function insertBandwidthLimit( sdpLines, index )

{

  // compute limit depending on media type

  var limit;

  if( sdpLines[index].search('audio') !== -1 )

    limit = '50';

  else

    limit = '256';

  // create a new line

  newLine = "b=AS:" + limit;

  // insert the new line after the media line

  sdpLines.splice(index+1,0,newLine);

  return sdpLines;   

}

On Tue, May 28, 2013 at 1:34 AM, Ari <aso...@gmail.com> wrote:

We need a method to adjust the webRTC media quality to adapt to the hardware capabilities.  In other words we want to adjust the video size, numbers of frames/sec, etc. to reduce CPU utilization on lower powered hardware.   We tried to use get.User.Media  constraints and add.Stream constraints but it had no impact on the CPU utilization.  We are also unable to reduce the sending stream bit rate, which seems to always reach 2-2.2Mbs.  Any ideas?

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Mamadou]

We had same issue for the bitrate. Implementing draft-alvestrand-rmcat-
remb-02 in our products fixed the issue.
Just send RTCP-REMB items with our normal RR packets to adjust the
bitrate from chrome to your application. If you're using two chromes
the response from Alexandre is what you need.

[Sergio Garcia Murillo]

Hi Alexandre,

I have not been able to double-check the issue, but it seemed to me that when using the b:AS attribute in the SDP, chrome was not limiting the maximum bitrate, but setting the encoding bitrate to that value and not applying the bitrate adaptation/congestion control algorithm at all, which make it completely unusable. That is, if you set the limit of the call to 1.5mbps, chrome was sending 1.5mbps regardless of the connection status.

Can any one confirm it via  chrome://webrtci-internals? (my latpop is halting wildly and I can't test webrtc anymore for now.. :(

Best regards
Sergio

[Vikas]

Thanks for the feedback, i also observed from webrtc-internals that
chrome was not limiting maximum bit-rate after b=AS: was specified.
Will file an issue for this.

/Vikas

On May 29, 4:45 am, Sergio Garcia Murillo

<sergio.garcia.muri...@gmail.com> wrote:
> Hi Alexandre,
>
> I have not been able to double-check the issue, but it seemed to me that
> when using the b:AS attribute in the SDP, chrome was not limiting the
> maximum bitrate, but setting the encoding bitrate to that value and not
> applying the bitrate adaptation/congestion control algorithm at all,
> which make it completely unusable. That is, if you set the limit of the
> call to 1.5mbps, chrome was sending 1.5mbps regardless of the connection
> status.
>
> Can any one confirm it via  chrome://webrtci-internals? (my latpop is
> halting wildly and I can't test webrtc anymore for now.. :(
>
> Best regards
> Sergio
>

> El 28/05/2013 15:00, Alexandre GOUAILLARD escribi�:

>
>
>
>
>
>
>
> > dear ari,
>
> > the constraints are not honored as of yet. You can follow the
> > following issue (by "staring" it) to be informed of when it will
> > become available.
> >http://code.google.com/p/webrtc/issues/detail?id=1701
>
> > By default, webrtc will start with a reasonable assumption of the
> > available bandwidth and will then slowly use whatever is available up
> > to 2Mb.
>
> > You can modify directly the sdp to add a constraint for the time being
> > by using for example the following code. No real black magic, so feel
> > free to re-use it, (as in BSD licence) . If you like it, just give

> > credit to alex.gouaill...@temasys.com.sg
> > <mailto:alex.gouaill...@temasys.com.sg>

> >     <mailto:discuss-webrtc%2Bunsu...@googlegroups.com>.
> >     For more options, visithttps://groups.google.com/groups/opt_out.

[Vikas]

Created issue: https://code.google.com/p/webrtc/issues/detail?id=1846

[Sergio Garcia Murillo]

Thanxs!

El 29/05/2013 21:09, Vikas escribi�:

> Created issue: https://code.google.com/p/webrtc/issues/detail?id=1846
>
> On May 29, 12:00 pm, Vikas <vikasmarw...@webrtc.org> wrote:
>> Thanks for the feedback, i also observed from webrtc-internals that
>> chrome was not limiting maximum bit-rate after b=AS: was specified.
>> Will file an issue for this.
>>
>> /Vikas
>>
>> On May 29, 4:45 am, Sergio Garcia Murillo
>>
>>
>>
>>
>>
>>
>>
>> <sergio.garcia.muri...@gmail.com> wrote:
>>> Hi Alexandre,
>>> I have not been able to double-check the issue, but it seemed to me that
>>> when using the b:AS attribute in the SDP, chrome was not limiting the
>>> maximum bitrate, but setting the encoding bitrate to that value and not
>>> applying the bitrate adaptation/congestion control algorithm at all,
>>> which make it completely unusable. That is, if you set the limit of the
>>> call to 1.5mbps, chrome was sending 1.5mbps regardless of the connection
>>> status.
>>> Can any one confirm it via chrome://webrtci-internals? (my latpop is
>>> halting wildly and I can't test webrtc anymore for now.. :(
>>> Best regards
>>> Sergio

>>> El 28/05/2013 15:00, Alexandre GOUAILLARD escribi�: