Não é mais possível fazer postagens ou usar assinaturas novas da Usenet nos Grupos do Google. O conteúdo histórico continua disponível.
Dismiss

Firefox encoding bitrate control

733 visualizações
Pular para a primeira mensagem não lida

Alexander Abagian

não lida,
24 de dez. de 2015, 06:56:0724/12/2015
para mozilla-...@lists.mozilla.org
Hi All,

Is it possible to change encoding bitrate for video (VP8) in Firefox ?
Currently it'a about 300 kb/s, and I'd like to increase it.

For Chrome I'm using such an attribute to make it encode at 500 kb/s :

a=fmtp:100 x-google-start-bitrate=128; x-google-min-bitrate=380; x-google-max-bitrate=500


I tried to apply "b=AS" to offer SDP with no effect.

Eric Rescorla

não lida,
24 de dez. de 2015, 09:28:4724/12/2015
para Alexander Abagian, mozilla-...@lists.mozilla.org
Jesup is the expert on this code, but assuming I am reading the code
correctly,
the bitrate range is hardwired to 200-2000 (start = 300). kbps and can't
be changed via SDP.

However, this means that if your network is up to it, it should negotiate
upward
to 500kbps no problem.

Can you describe what you see?

-Ekr


On Thu, Dec 24, 2015 at 6:56 AM, Alexander Abagian <aaba...@gmail.com>
wrote:
> _______________________________________________
> dev-media mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media
>

Alexander Abagian

não lida,
24 de dez. de 2015, 11:05:1024/12/2015
para mozilla-...@lists.mozilla.org
I see a video with no lags and good FPS but not enough sharp and a little dirty.


Here Chrome stats graph (other side os Firefox) :

https://drive.google.com/file/d/0B6N7bihGDAcJTHpYd1lwaFhCcy1CRUthWE5NR2ZCc1ZVUW04/view?usp=docslist_api



Firefox statistics shows :

outbound_rtp_audio_0

Local: 19:00:46 GMT+0300 (Russia TZ 2 Standard Time) outboundrtp SSRC: 988192143 Sent: 13504 packets (2400.13 Kb)

outbound_rtp_video_1

Encoder: Avg. bitrate: 0.25 Mbps (0.07 SD) Avg. framerate: 24.54 fps (7.21 SD) Dropped frames: 19

Local: 19:00:46 GMT+0300 (Russia TZ 2 Standard Time) outboundrtp SSRC: 2861540971 Sent: 11129 packets (8380.93 Kb)

Eric Rescorla

não lida,
24 de dez. de 2015, 11:21:0324/12/2015
para Alexander Abagian, Randell Jesup, mozilla-...@lists.mozilla.org
Hmm.. That's not what I see on calls between Nightly and Chrome on apprtc.

This is more Jesup's area than mine, but I suggest that we're probably a
the point
where we're going to need logs from video engine.


On Thu, Dec 24, 2015 at 11:05 AM, Alexander Abagian <aaba...@gmail.com>
wrote:

Randell Jesup

não lida,
24 de dez. de 2015, 12:28:3824/12/2015
para dev-...@lists.mozilla.org
On 12/24/2015 11:20 AM, Eric Rescorla wrote:
> Hmm.. That's not what I see on calls between Nightly and Chrome on apprtc.

Right. I just tried an apprtc call to Chrome, and while we start around
300Kbps (as does Chrome), we both quickly ramp up. In my call, the ramp
up was basically identical to ~1.4Mbps, when we stop and Chrome
continuse up to ~3Mbps. The reason for this was that apprtc was using
1280x720 for Chrome, and 640x480 for Firefox. We adjust the bitrate
limits when sending according to the input resolution and framerate; for
640x480@~30fps we max out the video at 1.3Mbps. For 1280x720 we would
use a min of 600 and max of 2500Mbps.

Chrome used to use min 200, max 2000Mbps for everything, but that may
have been modified, or apprtc may be playing with b=AS lines, which they
allow apps to change and we don't (currently).

If video isn't adapting up, that implies that either you have poor
bandwidth, very large amounts of jitter in the network (poor WiFi?),
something is blocking RTCP (which will cause other problems too), or
there's some form of mis-negotiation or incorrect SDP munging.

Try an apprtc call between the same two machines and watch the network
stats. If that works normally, look at the negotiation, SDP munging,
etc. Copies of the local and remove SDPs might help.

--
Randell Jesup, Mozilla WebRTC

Alexander Abagian

não lida,
25 de dez. de 2015, 06:04:1125/12/2015
para mozilla-...@lists.mozilla.org
That means that there's not manual API controls for setting the needed bitrates in FireFox, right ? Only an automatic one. That's not good.

My setup is not p2p as AppRtc, it's a Chrome Client - Conferencing Server - Firefox Client. Remote SDPs are created programmaticaly. Maybe really something wrong with RTCP.

BTW AppRtc does not work at all at my both PCs at my workplace (clients can't connect) inspite of they are located in the same gigabit wired LAN (most other WebRTC examples and VoIPs, Jitsi, Skype etc. works) - maybe then need for some ports to be opened.

Eric Rescorla

não lida,
25 de dez. de 2015, 09:19:0025/12/2015
para Alexander Abagian, mozilla-...@lists.mozilla.org
On Fri, Dec 25, 2015 at 6:04 AM, Alexander Abagian <aaba...@gmail.com>
wrote:

> That means that there's not manual API controls for setting the needed
> bitrates in FireFox, right ? Only an automatic one. That's not good.
>

We will eventually process the SDP attributes, as well as RtpSender. We
just don't
know. Patches welcome.


My setup is not p2p as AppRtc, it's a Chrome Client - Conferencing Server -
> Firefox Client. Remote SDPs are created programmaticaly. Maybe really
> something wrong with RTCP.
>

That does seem like the place to look.


BTW AppRtc does not work at all at my both PCs at my workplace (clients
> can't connect) inspite of they are located in the same gigabit wired LAN
> (most other WebRTC examples and VoIPs, Jitsi, Skype etc. works) - maybe
> then need for some ports to be opened.
>

Perhaps.

-Ekr

Alexander Abagian

não lida,
29 de dez. de 2015, 06:19:3129/12/2015
para mozilla-...@lists.mozilla.org
1.4 mbps is also sad. Too much load for the server. For Chrome I decreased it from 2 to 0.5 - picture quality at 0.5 is good enough.

Eric Rescorla

não lida,
29 de dez. de 2015, 06:28:5429/12/2015
para Alexander Abagian, mozilla-...@lists.mozilla.org
I'm not sure what you're looking for here.

Nobody's arguing that we shouldn't implement these features, they're just
not at the top
of the priority list. If you'd like to submit a patch, it would certainly
be welcome and one
of us will be happy to review it. Other than that, I don't know what else
to tell you.

-Ekr



On Tue, Dec 29, 2015 at 6:19 AM, Alexander Abagian <aaba...@gmail.com>
wrote:

> 1.4 mbps is also sad. Too much load for the server. For Chrome I decreased
> it from 2 to 0.5 - picture quality at 0.5 is good enough.

ma...@stonethree.com

não lida,
27 de jan. de 2016, 15:59:3227/01/2016
para mozilla-...@lists.mozilla.org
Does the same apply for setting the encoding bitrate for opus?

I.e in chrome the following lines in the sdp can be used to control the encoding bitrate of the opus codec:

a=rtpmap: 109 opus/48000/2
a=fmtp:109 maxaveragebitrate=128000; stereo=1; sprop-stereo=1; cbr=1

Does firefox parse these parameters yet?

Kind regards,

Matthew Marsh

Randell Jesup

não lida,
27 de jan. de 2016, 18:05:4927/01/2016
para dev-...@lists.mozilla.org
On 1/27/2016 6:42 AM, ma...@stonethree.com wrote:
> Does the same apply for setting the encoding bitrate for opus?
>
> I.e in chrome the following lines in the sdp can be used to control the encoding bitrate of the opus codec:
>
> a=rtpmap: 109 opus/48000/2
> a=fmtp:109 maxaveragebitrate=128000; stereo=1; sprop-stereo=1; cbr=1
>
> Does firefox parse these parameters yet?

While I believe we parse them, we don't do anything with them currently.

--
Randell Jesup, Mozilla

Edsel Ayala

não lida,
18 de set. de 2020, 00:37:0318/09/2020
para mozilla-...@lists.mozilla.org
I have the same inquiry, I want to know if there's a way to change the encoding bit rate of opus

Nils Ohlmeier

não lida,
18 de set. de 2020, 00:41:0418/09/2020
para Edsel Ayala, mozilla-...@lists.mozilla.org


> On 15Sep, 2020, at 04:44, Edsel Ayala <ayala...@gmail.com> wrote:
>
> On Thursday, 28 January 2016 at 04:59:32 UTC+8, ma...@stonethree.com wrote:
> I have the same inquiry, I want to know if there's a way to change the encoding bit rate of opus

We actually landed support for all opus fmtp parameters some time ago. But unfortunately the feature is blocked by us switching to our new SDP parser. Right now it is not 100% when we are going to be able to fully switch over to the new parser.

Best regards
Nils Ohlmeier
0 nova mensagem