From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by mail.toke.dk (Postfix) with ESMTPS id E632486EA78 for ; Fri, 6 Aug 2021 14:11:14 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ffoYeOdW Received: by mail-lf1-x12d.google.com with SMTP id g13so17455674lfj.12 for ; Fri, 06 Aug 2021 05:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wjwJLYslMwQcYwxYXa3b84316v7cHPJyTDRxBh35VMg=; b=ffoYeOdWsDc89Io49YEF3Hu9pFi4Cb9/ONaMbClFJRdP8a8WL82dNcX34JisYPVbUw BeofbrZPhiOx5YGFHKzsGNnS4eb0DFdtyLc0oHHDTk9//Rlxq5bFZowJdHLKKr1oSLU9 0yzDj9pWj9gZ4xZBri6RqCR1xIfW7gyDRYkFmeW1qadvw0zjAu9tmx3IN006hCqkPJZ8 Yi6bl/jlNWTNLwrB4GHBowmqMpYK3pb+h+DmuVgIoLMlnwFaE7JrEzUDDVj5Y6wk1gHw dgLTdrEAung05rAfUmVJvCwDbgjKZ2a7z1KbqvIu5KBDQFCirdkQDJlt8cPkjG5EaYoU DbEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wjwJLYslMwQcYwxYXa3b84316v7cHPJyTDRxBh35VMg=; b=RtojHTWR3bKM5OoQWc6eCj6FwCx7CxCOTgcQd+iqVvc7LDaoWC8D+FteYLSwZsQtEN f9+x50ZUqwo5HotANBcNpfssxaQAti6xw7trCcIRBCxD7vVq4zQTWGd5wJZE9XjZAAAb XtHZPTDjyl+feT/tL3wUBSt1lNht+QMzPssKlWINIXwXnIr6Uqz2aFTJFNL9j+DfCo/l /XLdywk2Xs0697AD9tW1gF9m6ITv3JOq18Jt5Q4qi4Gw2Xgeo5CUN6XyNfUvhxlzlr+x 0DjlZv1J9+QibtERChQjqQGkSKO4M23+vjIMfdEpST3S/a5US1JE/MNcfuuzN4MdIDy8 wn6Q== X-Gm-Message-State: AOAM530U4fnaDPJdtA0zfdexNMZHfuYk0MFCXviSaIg3TdFIfArKNBsU U+Ikqn9GiPc4EzJd6E66pVXvvKrbPXC5uIrpyKbEyaz3xYeotg== X-Google-Smtp-Source: ABdhPJz74hgNZHUnKTX1X4tjYCwu6+DXSjbRBKWNpZOB3RuMLOna+IYlr+OpdaYbzO04I+BwwsJ/Nk9IgqdppF22ITM= X-Received: by 2002:a19:5e02:: with SMTP id s2mr7561638lfb.265.1628251871816; Fri, 06 Aug 2021 05:11:11 -0700 (PDT) MIME-Version: 1.0 From: Guillaume Denis Date: Fri, 6 Aug 2021 14:11:01 +0200 Message-ID: To: galene@lists.galene.org Content-Type: multipart/alternative; boundary="0000000000006cb15b05c8e2ee5e" Message-ID-Hash: QE3A5CWL4JI4Y7QD6F2VPNOVYFKR4FQC X-Message-ID-Hash: QE3A5CWL4JI4Y7QD6F2VPNOVYFKR4FQC X-MailFrom: gdenispro@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 X-Mailman-Version: 3.3.4 Precedence: list Subject: [Galene] 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: --0000000000006cb15b05c8e2ee5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Gal=C3=A8ne, hello Toke (I might have a question for you below!) For a bit of context I am working on a project [1] that uses pion, in a different fashion than Gal=C3=A8ne since we transform audio/video streams a= nd add effects to them, implying that we decode and reencode them server side (with GStreamer). My initial question was about how to adapt encoder settings (bitrate) to network conditions, for instance not to send a 200KB/s video to a 100KB/s capable network. Juliusz pointed Google Congestion Control Algorithm [2] and Gal=C3=A8ne's implementation out to me: thanks to RTCP receiver and REMB reports, and thanks to the GCC algorithm, I can compute a desirable bitrate. Now this bitrate can be used to monitor encoder settings. This article https://www.aitrans.online/static/paper/Gcc-analysis.pdf also mentions that pacers and padders should be adapted. 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? - 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? - 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 Thanks, Guillaume [1] https://github.com/creamlab/ducksoup [2] https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02 --0000000000006cb15b05c8e2ee5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Gal=C3=A8ne,
hello Toke (I might have a question= for you below!)

For a bit of context I am working o= n a project [1] that uses pion, in a different fashion than Gal=C3=A8ne sin= ce we transform audio/video streams and add effects to them, implying that = we decode and reencode them server side (with GStreamer).

My initial question was about how to adapt encoder settings (bitrat= e) to network conditions, for instance not to send a 200KB/s video to a 100= KB/s capable network.
Juliusz pointed Google Congestion Control A= lgorithm [2] and Gal=C3=A8ne's implementation out to me: thanks to RTCP= receiver and REMB reports, and thanks to the GCC algorithm, I can compute = a desirable bitrate.

Now this bitrate can be used = to monitor encoder settings. This article=C2=A0https://www.aitrans.online/static/= paper/Gcc-analysis.pdf also mentions that pacers and padders should be = adapted.

Toke, would you have some input regarding= this:
- do you think that in this use case monitoring a pacer wi= th the target bitrate would have real added value?
- 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?
- are you aware of any reusable pacer implementation? I am also wond= ering if it would make more sense to be part of GStreamer processing or in = pion

Thanks,
Guillaume
<= br>
--0000000000006cb15b05c8e2ee5e--