Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Juliusz Chroboczek <>
To: "Michael Ströder" <>
Subject: [Galene]  Re: Talk about Galène today (monday) at 17pm CET
Date: Mon, 22 Feb 2021 19:15:13 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

>> Once that is fixed, Galène will accurately estimate the bottleneck
>> throughput, and we can default « Send » to « unlimited ».  Right now,
>> setting « Send » to « unlimited » may cause lag unless the bottleneck
>> router is well implemented.

> In my experience setting send quality even just to "low" or "normal"
> results in pumping data traffic (up and down) even in a conference with
> just two users.

Yes, that's the symptom if you're oversubscribed and bufferbloated.
Galène pumps packets into the network, which buffers them, then suddently
starts dropping a whole burst of packets, which causes Galène to back off.
Then the cycle starts again.

In an ideal world, the router would start by dropping a tiny fraction of
packets, so that Galène can back off smoothly.  In the absence of
progressive dropping, Galène needs to react before the first packet drop
by monitoring the second derivative of packet delay — that's the bit
that's not implemented yet.

> Would it make sense to stop sending a video stream to a user if the user
> displays only one of the streams as full-screen?

The plan is to send a low-resolution, low-framerate version, so that when
the user unzooms they get a low-resolution image straight away rather than
a blank frame (while the client renegotiates).  That's the simulcast bit
near the end.  It should be possible to get a usable image at 50kbps,
perhaps even less.

We'll see how well it works.

> Hmm, to me [Panic] and [Mute] sometime feel redundant.

No, they're not redundant.  I use mute quite often — during a departmental
meeting, I'm muted most of the time, except when I am invited to speak by
the head of department.  So mute is a quick audio on/off switch.  The
Panic button is used less often, but it needs to be there in case
something goes horribly wrong.

I'm not going to change the logic, I like it.  But I am looking for
a better label.

>>> Especially since the [Logout] link is too hard to find.

>> In normal usage, you just close the browser tab, no?

> Ah, it seems my users and me are probably too disciplined. ;-)


-- Juliusz

  reply	other threads:[~2021-02-22 18:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22 13:32 [Galene] " Juliusz Chroboczek
2021-02-22 13:49 ` [Galene] " Gabriel Kerneis
2021-02-22 14:04   ` Juliusz Chroboczek
2021-02-22 17:07 ` Juliusz Chroboczek
2021-02-22 17:24   ` Michael Ströder
2021-02-22 17:32     ` Juliusz Chroboczek
2021-02-22 18:00       ` Michael Ströder
2021-02-22 18:15         ` Juliusz Chroboczek [this message]
2021-03-01 19:38 ` email
2021-03-02  6:14   ` Juliusz Chroboczek
2021-03-02  7:29     ` eric_G
2021-03-02 15:37       ` Juliusz Chroboczek
2021-03-02 16:55         ` Dave Taht
2021-03-02 17:21           ` Juliusz Chroboczek
2021-03-02 17:40             ` Dave Taht
2021-03-02 18:24               ` Nils Andreas Svee
2021-03-02 18:58                 ` Sean DuBois
2021-03-02 19:06                   ` eric_G

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:

  List information:

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

  git send-email \ \ \ \ \
    --subject='[Galene]  Re: Talk about Galène today (monday) at 17pm CET' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox