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ût 2021 à 01:01, Juliusz Chroboczek a écrit : > >> 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 >