How to set unlimit googActualEncBitrate?

1,006 views
Skip to first unread message

신은철

unread,
May 23, 2019, 5:52:35 AM5/23/19
to discuss-webrtc
Hi, 

I use chrome, and try broadcasting 1080p at 6mp

I edit Sdp, add line b:AS=8000, and  x-google-start-bitrate, x-google-min-bitrate, x-google-max-bitrate to the codec I'm using

I started broadcast, enter Chrome://webrtc-internal,
and i show googAvailableSendBandwidth, googTransmitBitrate, and more

googAvailableSendBandwidth is 8mb but, googTransmitBitrate does not exceed 3mb


I found that browser limitations.
how can i set unlimit this bitrate

I want broadcast 1080 stream high quailty

Please Help
Thank you

Ju Ju

unread,
Mar 10, 2020, 6:21:37 PM3/10/20
to discuss-webrtc
As always in this GG, most of the time when there is an interesting question and a little complicated, there is no answer ...
so sad :(

Alexandre GOUAILLARD

unread,
Mar 11, 2020, 3:52:36 AM3/11/20
to discuss...@googlegroups.com
- what is the available bandwidth? if the available bandwidth is only 3Mbps, even if you cap the bandwidth usage to 8, it will still only be able to use 3.
- why setting so many flags, did you try to set only one value at a time and investigate the effect (black box testing)?
- what prevents you from:
  -- enabling logging to get more info without stopping any process
  -- recompile in debug mode to be able to see what s happening internally
  -- check in https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/ to see where those flags are used, how they are used, and manage expectation.

As a side note, please bear in mind that 1080p@30fps requires 6 to 7 Mbps even with H265 in two-pass best quality mode (see apple documentation here, specifically table 3). With a real time codec (one pass, real-time) the compression being lower, you should expect to use more bandwidth. 


--

---
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/14a2e1fa-98fb-4b05-80ba-6ed35b001fc1%40googlegroups.com.


--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------

Ju Ju

unread,
Mar 11, 2020, 8:01:17 AM3/11/20
to discuss...@googlegroups.com
Hi Alexandre,

Thanks for your contribution.

Regarding this sentence: As a side note, please bear in mind that 1080p@30fps requires 6 to 7 Mbps even with H265 in two-pass best quality mode

How do you explain Netflix and google are using a bitrate close to 2.5Mbps for their full HD stream ?

Bitrate vs SSIM
vp9-x264-x265-encoding-quality

2.5Mbps seems to be a good tradeoff between quality and bitrate, isn’t it ?

Second question: Why are you talking about H265 as this codec is not supported by browsers in webrtc (or maybe I miss something) ?


J-



You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/ZUigX7cSrdA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAHgZEq7eZSAob6Re-w4cdWRo%3Di%2BZ7EZ_jj0hSzFeXDSP3A-VJw%40mail.gmail.com.

Alexandre GOUAILLARD

unread,
Mar 11, 2020, 9:20:55 AM3/11/20
to discuss...@googlegroups.com
Hi ju, 

those are great questions, thank you for asking.


Regarding this sentence: As a side note, please bear in mind that 1080p@30fps requires 6 to 7 Mbps even with H265 in two-pass best quality mode

How do you explain Netflix and google are using a bitrate close to 2.5Mbps for their full HD stream ?

By google you mean ..... hangout? duo? stadia? youtube? meet? All of those google products use different solutions with different compromises and without knowing which one you refer to, I can't answer your question.

As for Netflix, the answer is easy, they are using two pass encoding, with both per-title (since 2015) and per-segment ML-optimized encoding. It takes forever to encode, but they don t care since, as a pre-recorded content provider, they have infinite time budget to encode. Not only that, but they switched to VP9 many years ago (with optimised implementation and GPu encoding), and more recently AV1, giving them an additional 25 to 30% (average across all the resolutions and content of their media library) improvement each time.

If you want to learn more about per-title and per-segment/GOP encoding, you can start by those two blog post:

Ane Aaron (Netflix director for encoding) presentations at live streaming east / west or IBC2019 INTEL event, where we also presented are also providing interesting insights:

All of that is just a google search away....
 

Bitrate vs SSIM
vp9-x264-x265-encoding-quality

2.5Mbps seems to be a good tradeoff between quality and bitrate, isn’t it ?

1. Both axis use logarithmic scales, which makes the 2.5mbps point difficult to visualise.
2. Without a reference point, you can compare the curves (the one on top is better), but you still cannot collude on wether it s good or not.
3. Libvpx is an entire library including several codecs like Vp8, VP9, ... I don't know which one has been used here. Equally, x264 and x265 references *implementations* and not codecs themselves. If we go down this path, you should compare all the H264 implementations against the one provided by chrome, and equally all VP8 or Vp9 implementations. 
the only thing I can conclude from your drawing is: x265 seems better than h264 everything else being equal.

 2.5 does not seem to be a good tradeoff. Moreover SSIM has but a poor correlation with perceived quality.


Second question: Why are you talking about H265 as this codec is not supported by browsers in webrtc (or maybe I miss something) ?

H.265 is not yet supported in browser, even though INTEL and Apple came together in November last year with our kind mediation, and implemented H.265 HW acceleration support in libwebrtc, webkit, and safari. 

The reasons why I took this one as a reference point are simple.

1. it's a newer/better codec than H.264 or VP8, the two codecs available for webrtc, especially for high resolution for which it has been especially designed (with larger maximum tiles size among other things), So if you cannot even achieve your target bitrate with that better codec, you should not expect to be able to do it with H.264/VP8. This is a "sanity-check". If you cannot drive that fast with a ferrari, do not even try with a fiat punt.

2. There is an industry standard reference table provided by Apple, used by everybody streaming to and from any apple product including apple TV, which is dependable, as opposed to some random blog post.

Hope this helps.

Ju Ju

unread,
Mar 11, 2020, 4:56:44 PM3/11/20
to discuss-webrtc
Hello Alex,

my answers below


Le mercredi 11 mars 2020 14:20:55 UTC+1, Alexandre GOUAILLARD a écrit :
Hi ju, 

those are great questions, thank you for asking.

It is newbie questions but thanks ;) 


Regarding this sentence: As a side note, please bear in mind that 1080p@30fps requires 6 to 7 Mbps even with H265 in two-pass best quality mode

How do you explain Netflix and google are using a bitrate close to 2.5Mbps for their full HD stream ?

By google you mean ..... hangout? duo? stadia? youtube? meet? All of those google products use different solutions with different compromises and without knowing which one you refer to, I can't answer your question.

sorry was talking about YouTube.
I made a capture while watching a 1080p @30 FPS video on YouTube (with chrome so using QUIC transport) and I did analyse it to know what is the average bitrate
As you can see below on my graph we are around 7.5 MBits


Of course it is 1 video and not the entire video so I can't conclude this happen on every fullhd video but it gave me an idea. Honestly I was surprised by the bitrate.


As for Netflix, the answer is easy, they are using two pass encoding, with both per-title (since 2015) and per-segment ML-optimized encoding. It takes forever to encode, but they don t care since, as a pre-recorded content provider, they have infinite time budget to encode. Not only that, but they switched to VP9 many years ago (with optimised implementation and GPu encoding), and more recently AV1, giving them an additional 25 to 30% (average across all the resolutions and content of their media library) improvement each time.

Ok good to know ! I am really surprise Netflix switch on VP9 as Netflix is available in appleTV and we all know how apple is VP9 fan.
I agree they have infinite time budget but it costs money so I assume we have closely study but codec fit the best ^^
I m so far less surprise to learn they have start using AV1 codec  .
Ok thanks I will have a look 


Ane Aaron (Netflix director for encoding) presentations at live streaming east / west or IBC2019 INTEL event, where we also presented are also providing interesting insights:

All of that is just a google search away....
 

Bitrate vs SSIM
vp9-x264-x265-encoding-quality

2.5Mbps seems to be a good tradeoff between quality and bitrate, isn’t it ?

1. Both axis use logarithmic scales, which makes the 2.5mbps point difficult to visualise.
Sure it is logarithmic but you can still find out where is 2.5...
 
2. Without a reference point, you can compare the curves (the one on top is better), but you still cannot collude on wether it s good or not.
I agree their curves are not easy to understand. I don't know if we can say that the quality double every 3db...
 
3. Libvpx is an entire library including several codecs like Vp8, VP9, ... I don't know which one has been used here.
it is in the title "VP9 vs h264" ^^ 
Equally, x264 and x265 references *implementations* and not codecs themselves. If we go down this path, you should compare all the H264 implementations against the one provided by chrome, and equally all VP8 or Vp9 implementations. 
the only thing I can conclude from your drawing is: x265 seems better than h264 everything else being equal.
yes you re right. I only interesting by chrome implementation but it is hard to find this kind of comparaison only in webrtc context 

 2.5 does not seem to be a good tradeoff. Moreover SSIM has but a poor correlation with perceived quality.

SSIM has not been invented because PNSR has a poor correlation with perceived quality ? 


Second question: Why are you talking about H265 as this codec is not supported by browsers in webrtc (or maybe I miss something) ?

H.265 is not yet supported in browser, even though INTEL and Apple came together in November last year with our kind mediation, and implemented H.265 HW acceleration support in libwebrtc, webkit, and safari. 
ok but as long H265 is not supported in the same way in android devices... 

The reasons why I took this one as a reference point are simple.

1. it's a newer/better codec than H.264 or VP8, the two codecs available for webrtc, especially for high resolution for which it has been especially designed (with larger maximum tiles size among other things), So if you cannot even achieve your target bitrate with that better codec, you should not expect to be able to do it with H.264/VP8. This is a "sanity-check". If you cannot drive that fast with a ferrari, do not even try with a fiat punt.

2. There is an industry standard reference table provided by Apple, used by everybody streaming to and from any apple product including apple TV, which is dependable, as opposed to some random blog post.

Ok for the future, but now we are stuck with H264 and VP8, barely encode by browser in software.... 

Hope this helps.

Actually I'm even more confused.
I have an broadcast event in 2 month using janus. Let's say it will be on a corp LAN (not true because of RTP forwarding on others janus server but ...)
I don't know : 
- what resolution pick (I have full HD DSLR + capture card)
- what codec pick (I was thinking of VP9 but reading this : http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X264_PCS_2013_preprint.pdf
 I have serious doubts
- what bitrate pick

thanks for your advice

J-
Reply all
Reply to author
Forward
0 new messages