From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) by mail.toke.dk (Postfix) with ESMTPS id 289968C4C93 for ; Tue, 28 Sep 2021 22:51:29 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ipLKQUiA Received: by mail-io1-xd2e.google.com with SMTP id 134so259407iou.12 for ; Tue, 28 Sep 2021 13:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Fg7MQ1Y5uSXC5pQalzwdpluBHhydmIu6yrAycE51CZ4=; b=ipLKQUiA1xe80y6HIgiS0Bqdm0XKlR5/j4LbOcbJqxhRuuox3QNf9VwKa+Er6XvCur gAnKrmmpfWoOBqZ91Qwwhnv+ezZm3oOVoeRLzlL31mlILhPMyMyEOp6vAGVHCt7CZ7Ya uTwHdpckcY/d2X2wvnxZ4H7KPsB37TBcSKHSSI5IzJnl9vwayNLM2oBKcxqhl2a6UZMb EOf+z4LuFqB662D6Oqf3eDC1T0XaBubX89GfcMbWEakDr01tqMMw8W/ZAgyBSdE0Y0jM d/vupaLAGGZaIzi+VyH6olS3fUCr8WUzC9TzQn+wWwRlBebIodtMsDJbRDo6lEXpjZ12 yLZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Fg7MQ1Y5uSXC5pQalzwdpluBHhydmIu6yrAycE51CZ4=; b=2BeKdRv90W9elKMp6cjy2DJT01ng1GXwJqvrFtXv4H4RnPKtJ8r2Je870Rla/dDE7O NqoOLHlYtd21e4soDGwEXtKo8RqbtSr3SxuzY1WWCC2bb7+FypJc0mfNFOsNkR0aucgR dblOsBuBQWK7fsDmw9CkN47clJkabur1Jzuh38n8fICZTCgbgZcjdXgudjczD7wD3ggI 6lLfK2ddXLhqPxkNM6bSj8dKmKsJQixsmnyA6nyor+T/n+Gt5kqS3a6B/RID3GCwPy2J jjTKPsbqoov/vreTmtD7CeT7AKGpGiiFLtyR+6rAKJ0y9v0Wsgvc0s+TKuCRc+/GkEtD tP7g== X-Gm-Message-State: AOAM532LX2DzqUI/aX6LPM0URAcNlPg7Hko8i7uFM7zcFiwgjDO4oQqZ LepmTCsIvRC1qsk3mzm++cUQF8s2sb7M8fa+nqc= X-Google-Smtp-Source: ABdhPJxdrxTrerUBnUBAEBvoyNnOGZAIi68aMVpojoOh1Dd9ytN/4t1eaYjwf7UasN79mcy2bJZgqdPI2QyoLWPo5YY= X-Received: by 2002:a05:6602:180e:: with SMTP id t14mr5271493ioh.204.1632862287951; Tue, 28 Sep 2021 13:51:27 -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: Dave Taht Date: Tue, 28 Sep 2021 13:51:15 -0700 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: HAUA2SP3KOZ6Z7FNXJTS2KRPWHNM6CTH X-Message-ID-Hash: HAUA2SP3KOZ6Z7FNXJTS2KRPWHNM6CTH X-MailFrom: dave.taht@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: 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: I was terribly busy when this thread went by. On Fri, Aug 6, 2021 at 4:01 PM Juliusz Chroboczek wrote: > > >> 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. That draft is old, and I don't know the right answer, but I'm pretty sure t= hat's not the right answer. > [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 would like to try this - as the simplest possible implementation to experiment with. > > 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. To be clear this is when you are dealing with galene being internally conge= sted, blocking so much on write that it needs to drop a 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). oh, excellent. Are you using this at all at this point, to probe for more bandwidth. > > -- Juliusz > _______________________________________________ > Galene mailing list -- galene@lists.galene.org > To unsubscribe send an email to galene-leave@lists.galene.org --=20 Fixing Starlink's Latencies: https://www.youtube.com/watch?v=3Dc9gLo6Xrwgw Dave T=C3=A4ht CEO, TekLibre, LLC