From: "Toke Høiland-Jørgensen" <toke@toke.dk> To: Juliusz Chroboczek <jch@irif.fr>, Dave Taht <dave.taht@gmail.com> Cc: galene@lists.galene.org Subject: [Galene] Re: Congestion control and WebRTC [was: Logging] Date: Sun, 10 Jan 2021 23:23:41 +0100 [thread overview] Message-ID: <87eeismnwy.fsf@toke.dk> (raw) In-Reply-To: <87lfd04ye5.wl-jch@irif.fr> Juliusz Chroboczek <jch@irif.fr> writes: >> No, I don't think multiplexing more streams over the same five-tuple is >> a good idea if it can be avoided. If the bottleneck does per-flow >> queueing (like FQ-CoDel), you'd want each video flow to be scheduled >> separately I think. > > Tere's a tradeoff here. Using port multiplexing gives more information to > middleboxes, but using SSID multiplexing reduces the amount of ICE > negotation -- adding a new track to an already established flow requires > zero packet exchanges after negotiation (you just start sending data with > a fresh SSID), while adding a new flow for port multiplexing requires > a new set of ICE probes, which might take a few seconds in the TURN case. So in this instance a new flow happens when a new user joins and their video flow has to be established to every peer? >> Another couple of ideas for packet-level optimisations that may be worth >> trying (both originally articulated by Dave Taht): > > Why is Dave not here? I dunno; why aren't you here, Dave? :) >> In the presence of an FQ-CoDel'ed bottleneck it may be better to put >> audio and video on two separate 5-tuples: That would cause the audio >> stream to be treated as a 'sparse flow' with queueing priority and fewer >> drops when congested. > > Uh-huh. I'll send you a patch to do that, in case you find the time to > test it. Sounds good, thanks! >> (As an aside, is there a reference for the codec constraints in >> browsers? And is it possible to tweak codec parameters, say to burn some >> bandwidth to enable really high-fidelity audio for special use cases? Or >> is Opus so good that it doesn't matter?) > > A typical laptop microphone has rather poor frequency response, so Opus at > 48kbit/s is as good as the original. It's just not worth reducing the > audio rate upon congestion, it's the video rate that gets reduced. Right, I see. Looking at the commit that introduced codec support, it looks pretty straight-forward to crank up the bitrate; maybe I'll experiment with that a bit (but not using my laptop's microphone). > As to the video rate, you've got plenty of exciting knobs. > > 1. Congestion control. As implemented in modern browsers, WebRTC uses two > congestion controllers: a fairly traditional loss-based controller, and an > interesting delay-based one. This is described here: > > https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02 > > Unlike some other video servers, that mere forward congestion indictions > from the receivers to the sender, Galène terminates congestion control on > both legs. currently obeys congestion indication from the receivers, and > implements the loss-based congestion controller for data received from the > sender. > > https://github.com/jech/galene/blob/master/rtpconn/rtpconn.go#L956 > > We do not currently implement the delay-based controller, which causes > collapse if the sender is on a low-rate bufferbloated network. That is > why Galène's client limits the rate to 700kbit/s by default (in the > « Send » entry in the side menu). Right, but the browsers do? > Implementing the delay-based controller is number 1 on my wishlist. Your > help would be greatly appreciated. Can't promise any hacking time, unfortunately, at least not short-term. Happy to test out stuff, though :) > 2. Sender-side tweaks. The sender has a number of knobs they can tweak, > notably maximum bitrate (separately for each track), and hints about > whether to prefer framerate or image quality upon congestion. The sender > can also pick the webcam resolution, and they can request downscaling > before encoding. Ah, hence the "blackboard mode" - gotcha! > 3. SVC. The technology that excites me right now is scalable video coding > (SVC), which I believe will make simulcast obsolete. With VP8, the > sender can request that some frames should not be used as reference for > intra prediction; these « discardable » frames can be dropped by the > server without causing corruption. VP9 implements full scalability: > temporal scalability, as in VP8, spatial scalability, where the codec > generates a low resolution flow and a high resolution flow that uses the > low resolution flow for intra prediction, and quality scalability, where > the codec generates frames with varying quality. > > https://en.wikipedia.org/wiki/Scalable_Video_Coding > > I'm currently planning to skip simulcasting, which I feel is an > obsolescent technology, and experiment with SVC instead. Implementing the > delay-based controller is a higher prioerity, though. Uh, hadn't heard about that before; neat! >> Another packet-based optimisation that could be interesting to try out >> is to mark packets containing video key frames as ECN-capable. > > Keyframes can be huge (120 packets is not unusual), it wouldn't be > resonable to mark such a burst as ECN-capable without actually reacting to > CE. And if we drop part of the keyframe, we'll NACK the missing packets > and recover 20ms + 1RTT later. Hmm, right, okay I see what you mean... >>> Ideally you'd also actually respond to CE markings, >> RFC 6679. I don't know if it's implemented in browsers. > > It is not. Ah, too bad :( -Toke
next prev parent reply other threads:[~2021-01-10 22:23 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-07 21:38 [Galene] Logging Juliusz Chroboczek 2021-01-07 22:45 ` [Galene] Logging Michael Ströder 2021-01-08 0:35 ` Antonin Décimo 2021-01-08 12:40 ` Toke Høiland-Jørgensen 2021-01-08 13:28 ` Juliusz Chroboczek 2021-01-08 13:52 ` Toke Høiland-Jørgensen 2021-01-08 14:33 ` Michael Ströder 2021-01-08 15:13 ` Juliusz Chroboczek 2021-01-08 17:34 ` Michael Ströder 2021-01-08 18:00 ` Juliusz Chroboczek 2021-01-08 15:34 ` Juliusz Chroboczek 2021-01-08 19:34 ` Toke Høiland-Jørgensen 2021-01-08 19:56 ` Juliusz Chroboczek 2021-01-09 0:18 ` Toke Høiland-Jørgensen 2021-01-09 13:34 ` Juliusz Chroboczek 2021-01-10 13:47 ` Toke Høiland-Jørgensen 2021-01-10 15:14 ` [Galene] Congestion control and WebRTC [was: Logging] Juliusz Chroboczek 2021-01-10 15:23 ` [Galene] " Juliusz Chroboczek 2021-01-10 22:23 ` Toke Høiland-Jørgensen [this message] 2021-01-10 22:44 ` Dave Taht 2021-01-11 0:07 ` Juliusz Chroboczek 2021-01-11 0:20 ` Toke Høiland-Jørgensen 2021-01-11 0:28 ` Juliusz Chroboczek 2021-01-11 0:30 ` Dave Taht 2021-01-11 6:23 ` Dave Taht 2021-01-11 12:55 ` [Galene] Multichannel audio [was: Congestion control...] Juliusz Chroboczek 2021-01-11 17:25 ` [Galene] " Dave Taht 2021-01-11 13:38 ` [Galene] Re: Congestion control and WebRTC [was: Logging] Juliusz Chroboczek 2021-01-11 15:17 ` Toke Høiland-Jørgensen 2021-01-11 17:20 ` Dave Taht 2021-01-12 1:38 ` Juliusz Chroboczek 2021-01-10 15:17 ` [Galene] Re: Logging Juliusz Chroboczek
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://lists.galene.org/postorius/lists/galene.lists.galene.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87eeismnwy.fsf@toke.dk \ --to=toke@toke.dk \ --cc=dave.taht@gmail.com \ --cc=galene@lists.galene.org \ --cc=jch@irif.fr \ --subject='[Galene] Re: Congestion control and WebRTC [was: Logging]' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox