Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Guillaume Denis <gdenispro@gmail.com>, galene@lists.galene.org
Subject: [Galene] Re: about packet pacers
Date: Fri, 06 Aug 2021 22:34:16 +0200	[thread overview]
Message-ID: <87mtpu5n3r.fsf@toke.dk> (raw)
In-Reply-To: <CAB0ELa-TRP7md2=9xZip7QwJMyTJfHT0rjOQXLqymPMM_2LqiQ@mail.gmail.com>

Guillaume Denis <gdenispro@gmail.com> 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

  parent reply	other threads:[~2021-08-06 20:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-06 12:11 [Galene] " Guillaume Denis
2021-08-06 13:42 ` [Galene] " Juliusz Chroboczek
2021-08-06 20:34 ` Toke Høiland-Jørgensen [this message]
2021-08-06 23:01   ` Juliusz Chroboczek
2021-08-10  8:10     ` Guillaume Denis
2021-08-18 18:43       ` Juliusz Chroboczek
2021-08-18 21:32         ` Juliusz Chroboczek
2021-08-19  9:25           ` Guillaume Denis
2021-08-19 11:10             ` Juliusz Chroboczek
2021-09-28 20:51     ` Dave Taht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.galene.org/postorius/lists/galene.lists.galene.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mtpu5n3r.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=galene@lists.galene.org \
    --cc=gdenispro@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox