From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1628282057; bh=2o6A4Zr0yDYJENi7fPuOybowEz4KRd5Pz/HjF56ymlk=; h=From:To:Subject:In-Reply-To:References:Date:From; b=fqyq5VU0IJCy6yUZeYBTOZlAFgTzLnjY5Z0OpnuS/Yna8CDUbxEJ0SJ0/BDQIbg1s MF01k0wHCjhe0Kxrr2apLwpfX3Cc2BdwUgTi1kLJED9Y7+ou3cEsgcOKCLt5c5vBp5 9JDh+wnL9jlSg6GUryfFxrXZZApAjbbSNMpvATIUff9/UL4GO/XrehuAH0eJlj38jA XFnHRsmvdyPZppkg3iDPH077eDWBYzW2R2T/XAqAdDjhDKAWzMmduXW6mAepW6YX0/ Ckez5r2ga26Cth9AnwlG5GeSmKTCSej7+eIfg2Hx03UWO4lKlze3rg6AjJgzk3lWK7 XaZzVhH2o1+XQ== To: Guillaume Denis , galene@lists.galene.org In-Reply-To: References: Date: Fri, 06 Aug 2021 22:34:16 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87mtpu5n3r.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Message-ID-Hash: Q6XURGRQPFU2G7GBJLK23QKFTP6VWUZL X-Message-ID-Hash: Q6XURGRQPFU2G7GBJLK23QKFTP6VWUZL X-MailFrom: toke@toke.dk 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 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: Guillaume Denis writes: > 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? As Juliusz says, that could alleviate some short-term congestion if the codec produces very bursty packet streams, which may be a win. One question is whether the codec can be relied upon to stay within a certain bitrate and over what timescales? If the pacer rate is set wrong, it could end up bottlenecking the codec output at the local sender, causing a queue to build there, which would probably be bad... > - 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? This one I think Juliusz answered in the negative (which is good, because I had no idea ;)) > - are you aware of any reusable pacer implementation? I am also > wondering if it would make more sense to be part of GStreamer > processing or in pion Well it would need to be at whatever level produces the packet data; you'd probably want to queue up fully-formed packets and buffer them to the send rate. Not really aware of any reusable pacer implementations. 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? -Toke