From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=irif.fr (client-ip=2001:660:3301:8000::1:2; helo=korolev.univ-paris7.fr; envelope-from=jch@irif.fr; receiver=) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by mail.toke.dk (Postfix) with ESMTPS id 695F686F191; Sat, 7 Aug 2021 01:01:50 +0200 (CEST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 176N1nDY032307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 7 Aug 2021 01:01:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 176N1nob025014; Sat, 7 Aug 2021 01:01:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5435712E16; Sat, 7 Aug 2021 01:01:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id fVk0aRRuiizD; Sat, 7 Aug 2021 01:01:48 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 98D7412E13; Sat, 7 Aug 2021 01:01:48 +0200 (CEST) Date: Sat, 07 Aug 2021 01:01:47 +0200 Message-ID: <87lf5edvok.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= In-Reply-To: <87mtpu5n3r.fsf@toke.dk> References: <87mtpu5n3r.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 07 Aug 2021 01:01:49 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 07 Aug 2021 01:01:49 +0200 (CEST) X-Miltered: at korolev with ID 610DBF5D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 610DBF5D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 610DBF5D.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 610DBF5D.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 610DBF5D.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 610DBF5D.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Message-ID-Hash: SU6ILYU4GR3NSEXOALAUOAOBCRQPZTBC X-Message-ID-Hash: SU6ILYU4GR3NSEXOALAUOAOBCRQPZTBC X-MailFrom: jch@irif.fr 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: Guillaume Denis , 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: >> Toke, would you have some input regarding this: >> - do you think that in this use case monitoring a pacer with the target >> 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 that > 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 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 > 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 where they regularly schedule a "droppable" frame that is not used for intra-prediction (it's part of the simulcast implementation). -- Juliusz