Change default starting bitrate

[Nicholas Buchanan]

Is it possible to set the starting bitrate to some other value than Chrome's default 300kbps? In JS level? Or somewhere in the source?

[Alexandre GOUAILLARD]

webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc

On Sat, Aug 15, 2015 at 3:06 AM, Nicholas Buchanan <omnipot...@gmail.com> wrote:

Is it possible to set the starting bitrate to some other value than Chrome's default 300kbps? In JS level? Or somewhere in the source?

--

---
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/721db2b2-5596-495b-b7db-1f2f088cf12c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[Randell Jesup]

On 8/14/2015 3:06 PM, Nicholas Buchanan wrote:
> Is it possible to set the starting bitrate to some other value than
> Chrome's default 300kbps? In JS level? Or somewhere in the source?

I'm not sure if it's possible in Chrome in JS, though certainly in the
source, and possibly in some setting.

In Firefox, it can be set in about:config in older revs, but we recently
changed it to key off the video size for min/start/max rates (though
start rate probably only applies to the size of the initial frame;
changing it later likely doesn't affect the current bitrate - however,
most apps keep one input (camera) resolution throughout a call).

This helps a LOT with HD streams (and with very-low-resolution streams,
like QCIF)

--
Randell Jesup
randel...@jesup.org

[Nicholas Buchanan]

Or through SDP using b= ? I have seen some mentioning going there for setting the bandwidth, but this is a bitrate issue at the start, in order to send clear video frame from the beginning.

[Alexandre GOUAILLARD]

b=as will only cap, it does not help for the starting bitrate or the ramp up speed.

On Sat, Aug 15, 2015 at 4:02 AM, Nicholas Buchanan <omnipot...@gmail.com> wrote:

Or through SDP using b= ? I have seen some mentioning going there for setting the bandwidth, but this is a bitrate issue at the start, in order to send clear video frame from the beginning.

--

---
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e9524eb3-b51d-41c8-966d-4275043472e1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Nicholas Buchanan]

Thank you for your answer on this.

[Silvia Pfeiffer]

Actually, I would test that. In my experience in chrome a b=as sdp setting starts with that bandwidth setting rather than the default, before it adapts to actual available bandwidth.

Best Regards,
Silvia.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAHgZEq6DAwHuGnMRBkBoHouXK2w-3KVz_0nU4sDTzi%3Dbzw_upg%40mail.gmail.com.

[Alexandre GOUAILLARD]

interesting.

thanks silvia for the info. i did not test it recently, but it used to ramp up even with b=as.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAHp8n2mpdveYp4QnZPPKEFwww1ahNs24HScwJurqeOSx3DOEzg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Nicholas Buchanan]

I finally had the chance to test the SDP insertion and it did not help resolve the macroblock issue at the start. So next option is to compile chromium (Im actually working on node webkit) so it starts with a higher bitrate by default.

By the way, I did test with Canary v47 and the macroblocks at the start was still visible. I thought this was supposed to be resolved after v44. IIRC quality climbs quicker but doesnt actually start at the bitrate that matches the resolution given at the getUserMedia constraints.

[Nicholas Buchanan]

Downloaded chromium and recompiled it with 

  uint32_t bitrate_;

  uint32_t min_bitrate_configured_;

hardcoded to specific bitrate within SetSendBitrate and SetMinMaxBitrate but am not seeing any significant difference. I expected to see crisp clear video at the very first frame. Is this something that needs to be dealt within the video encoder space? Perhaps I could ask where to have it send iframe on the first packet, if that isn't already done.