From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by mail.toke.dk (Postfix) with ESMTPS id B8A59870E3C for ; Tue, 10 Aug 2021 10:10:32 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=qzQMD6tX Received: by mail-ej1-x62c.google.com with SMTP id qk33so33834613ejc.12 for ; Tue, 10 Aug 2021 01:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gkXTj2FOXWE6vzrHZMxWitg/LTvkt4ypxvLTqIJysBo=; b=qzQMD6tXWc0qLEu8V0+yadx1ULeYLAkD6vK5Cp+RO0tpAaoGecnN1fo2psqfH11lDA g9HR1x6j5c0i9NpvjTZkS00k4YWJKMn9Anok+v1tqZlXbaU3FXMLzNR4LD8zyvq243NR vpwVsZYhoPN6tSvGwIs2k0UEZINlaT/ZqHE1xsRr/hJoSOCTvfL0abX8uINREABcKbgS b0YDHSmqeJVjxxzqk6ejKH7myCHkSHihsci8D6lKr85bJ/QqE/aAeTVJtGYfcG4jU2E+ lHjfoQUer8Z88IJPluNQdXum20Nka5K3IIrsVpXlIGZDpTelKyNSUcz8/l3nmdkOvCOR i2Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gkXTj2FOXWE6vzrHZMxWitg/LTvkt4ypxvLTqIJysBo=; b=lpzcDGdf+k6mixofH0z1zbSIGS2LiyJixxJPzvUvxisOZeLB0ijJunUXv2jTuk6/AW 0gAthVJDnFu0dDlJfPmHR8Al4lusVlwArAVk/xdFIwJ5ZhV+0mCrDK+caq2r4ZRNkaux 8t/9X3bMeWZlIVJYPEoUuijyS5JhhnIoaSIUjBAK9OuGg8gKgKvesloIUvoNsqGPASbn HFQQ3PRgDyTHBMk8f3Pp2DvFg54an0oMh5XopTXw6NyTcocSxmWvnYPvRP3DFzUqGatz oUCJU1SvizgeLtX15ZHGKyRoQOt6IaasD51/pBoVHMjICgYgCNnxoVWyWyl6IQaKOXyl +oew== X-Gm-Message-State: AOAM531Bej4/s/9XTg+DxBWV+CFu9BxJe152l5I/yBfiR1lAuO0vBb8B AqqyNelsAErFGcZADSlgy4R+JMGCxG9ubJy6Sx4= X-Google-Smtp-Source: ABdhPJwHw8AxjV6wwfbOjWkpKQ6vSYNLOJSEUkcTkqJ2HwIAPWSIvGd2bVGWKJa42ICdPT9i1n2G4G3YT4RyWfuDANk= X-Received: by 2002:a17:906:eb4b:: with SMTP id mc11mr27334195ejb.474.1628583031317; Tue, 10 Aug 2021 01:10:31 -0700 (PDT) MIME-Version: 1.0 References: <87mtpu5n3r.fsf@toke.dk> <87lf5edvok.wl-jch@irif.fr> In-Reply-To: <87lf5edvok.wl-jch@irif.fr> From: Guillaume Denis Date: Tue, 10 Aug 2021 10:10:20 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary="00000000000011a7a605c93009e7" Message-ID-Hash: UIFCZSNQYVSGHR6JX7SS5DTMFIU6CSID X-Message-ID-Hash: UIFCZSNQYVSGHR6JX7SS5DTMFIU6CSID X-MailFrom: gdenispro@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: galene@lists.galene.org X-Mailman-Version: 3.3.4 Precedence: list Subject: [Galene] Re: about packet pacers List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000011a7a605c93009e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Toke, Juliusz, thanks for your input. As a followup and even if it's off topic for Galene users I'll share this implementation of the GCC algorithm based on RTCP packets: https://github.com/creamlab/ducksoup/blob/main/sfu/mixer.go#L203 (with a resulting periodical update of GStreamer encoder bitrates) Using pacers is a bit too networky for me right now, I'll see how much I need it. Thanks, Guillaume Le sam. 7 ao=C3=BBt 2021 =C3=A0 01:01, Juliusz Chroboczek a = =C3=A9crit : > >> Toke, would you have some input regarding this: > >> - do you think that in this use case monitoring a pacer with the targe= t > >> bitrate would have real added value? > > > Hmm, so the idea here would be that we know the bitrate of the stream > > from the codec setting, and from that we can compute the packet-level > > bitrate (by adding the packet overhead) and pace out the packets at tha= t > > rate? [...] > > One question is whether the codec can be relied upon to stay within a > > certain bitrate and over what timescales? > > No, but we know where the current frame ends, and we know when the next > frame is due. So we can spread the current frame smoothly over the > interval between the current frame and the next one. That will break whe= n > we get variable frame-rate codecs, but we'll cross that bridge when we ge= t > there. > > This is not what the GCC draft recommends[1]: what they suggest is to > consider the target bitrate (the one that the congestion controller yield= s) > and send a burst of up to 5ms*rate every 5ms. > > [1] > https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02#section-4 > > > On Linux you can use the SO_TXTIME socket option to get the kernel to > > pace the packets for you; but that only works if there's a qdisc > > installed that can handle the pacing (such as sch_fq), and it's hardly > > cross-platform, so dunno if that will work? > > I'd rather we did the pacing in the application, since that will allow us > to drop packets more selectively: if we drop a packet due to congestion > control, then we want to continue dropping until the end of the frame. > What's more, both the VP8 and VP9 codecs can be configured in a mode wher= e > they regularly schedule a "droppable" frame that is not used for > intra-prediction (it's part of the simulcast implementation). > > -- Juliusz > --00000000000011a7a605c93009e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Toke, Juliusz, thanks for your input.

As a followup= and even if it's off topic for Galene users I'll share this implem= entation of the GCC algorithm based on RTCP packets:
https://github.co= m/creamlab/ducksoup/blob/main/sfu/mixer.go#L203
(with a resulting pe= riodical update of GStreamer encoder bitrates)

Using pacers is a bit= too networky for me right now, I'll see how much I need it.
Thanks,= Guillaume

Le=C2=A0sam. 7 ao=C3=BBt 2021 =C3=A0=C2=A001:01, Juliusz Ch= roboczek <jch@irif.fr> a =C3=A9cri= t=C2=A0:
>>= ; Toke, would you have some input regarding this:
>> - do you think that in this use case monitoring a pacer with the t= arget
>> bitrate would have real added value?

> Hmm, so the idea here would be that we know the bitrate of the stream<= br> > from the codec setting, and from that we can compute the packet-level<= br> > bitrate (by adding the packet overhead) and pace out the packets at th= at
> rate? [...]
> One question is whether the codec can be relied upon to stay within a<= br> > certain bitrate and over what timescales?

No, but we know where the current frame ends, and we know when the next
frame is due.=C2=A0 So we can spread the current frame smoothly over the interval between the current frame and the next one.=C2=A0 That will break = when
we get variable frame-rate codecs, but we'll cross that bridge when we = get
there.

This is not what the GCC draft recommends[1]: what they suggest is to
consider the target bitrate (the one that the congestion controller yields)=
and send a burst of up to 5ms*rate every 5ms.

[1] https://datatracker.ietf.= org/doc/html/draft-ietf-rmcat-gcc-02#section-4

> On Linux you can use the SO_TXTIME socket option to get the kernel to<= br> > pace the packets for you; but that only works if there's a qdisc > installed that can handle the pacing (such as sch_fq), and it's ha= rdly
> cross-platform, so dunno if that will work?

I'd rather we did the pacing in the application, since that will allow = us
to drop packets more selectively: if we drop a packet due to congestion
control, then we want to continue dropping until the end of the frame.
What's more, both the VP8 and VP9 codecs can be configured in a mode wh= ere
they regularly schedule a "droppable" frame that is not used for<= br> intra-prediction (it's part of the simulcast implementation).

-- Juliusz
--00000000000011a7a605c93009e7--