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 A31C286EAE6 for ; Fri, 6 Aug 2021 15:42:55 +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 176DgrBj010920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Aug 2021 15:42:53 +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 176Dgr9x016203; Fri, 6 Aug 2021 15:42:53 +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 EDF9710542; Fri, 6 Aug 2021 15:42:53 +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 HD78E72z5AeG; Fri, 6 Aug 2021 15:42:52 +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 7CC8410540; Fri, 6 Aug 2021 15:42:52 +0200 (CEST) Date: Fri, 06 Aug 2021 15:42:51 +0200 Message-ID: <87a6lu665g.wl-jch@irif.fr> From: Juliusz Chroboczek To: Guillaume Denis In-Reply-To: References: 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]); Fri, 06 Aug 2021 15:42:53 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 06 Aug 2021 15:42:53 +0200 (CEST) X-Miltered: at korolev with ID 610D3C5D.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 610D3C5D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 610D3C5D.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 610D3C5D.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 : 610D3C5D.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 610D3C5D.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: R4LJV7G7J4G4LNTNMAE7APWOKUHJP4AS X-Message-ID-Hash: R4LJV7G7J4G4LNTNMAE7APWOKUHJP4AS 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: 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: I'll let Toke (or Dave?) answer the other points, but here's one I think I understand. > - I guess the pacer must act before the RTP packetizer so that timing > information present in RTP headers are correct/not modified by the pacer. Is > this correct? As far as I understand, the pacer is applied after the RTP packetiser. For each frame (or "picture" in VP9) produduced by the codec, the RTP packetiser will produce a burst of packets with the same timestamp. If these packets are sent in quick succession, they will temporarily congest the sending interface or the bottleneck router. The role of the pacer, as I undestand it, is to schedule the set of packets in a single frame so that they go out at regular intervals. The effect is a slight increase in delay (since the frame needs to be reassembled at the receiver before it can be processed), in jitter (since some packets might be larger than others), but a reduction in short-term network congestion and therefore in packet loss. The pacer does not rewrite RTP timestamps: the RTP timestamp describes where the packets fit in the reconstructed video, it has little to do with the time at which the packet is actually sent. (If the actual sending time is needed, there's the abs-send-time extension, which should be inserted after the pacer.) Galene does not use a pacer, since it merely forwards packets that have already been properly disciplined by the sender. (There is one exception, it's when we send a cached keyframe to a new receiver -- we currently send the keyframe as a burst, we should probably be conditioning it.) -- Juliusz