Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Juliusz Chroboczek <jch@irif.fr>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Guillaume Denis <gdenispro@gmail.com>, galene@lists.galene.org
Subject: [Galene] Re: about packet pacers
Date: Sat, 07 Aug 2021 01:01:47 +0200	[thread overview]
Message-ID: <87lf5edvok.wl-jch@irif.fr> (raw)
In-Reply-To: <87mtpu5n3r.fsf@toke.dk>

>> 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

  reply	other threads:[~2021-08-06 23:01 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
2021-08-06 23:01   ` Juliusz Chroboczek [this message]
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=87lf5edvok.wl-jch@irif.fr \
    --to=jch@irif.fr \
    --cc=galene@lists.galene.org \
    --cc=gdenispro@gmail.com \
    --cc=toke@toke.dk \
    /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