Subject: Re: Remote participation ( was Leading a moving target)

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Jul 2019 21:19:00 +0200

Thanks, Andy. Great to hear it did work out that well for you.

I always found the meetecho setup to be very good especially also the
support from the meetecho team. If there is anything to complain about
is that i think the quality of the video from remote participants was 
lower than even what i think to remember from the past. I wonder if its
really set to rate adapt to the available bandwidth or artifially limited
to some low maximum.  It really distracted from the experience, which
otherwise (especially also including the jabber channel) would have been
very close to the person being there in person.

Cheer
     Toerless

In-Reply-To: <CAA=duU2X1SjyPN0azuSpCykp4Wh8TNruO-knzYR=[email-masked]>

On Fri, Jul 26, 2019 at 12:35:40PM -0400, Andrew G. Malis wrote:
> With Adrian's post about our remote participation technology and the
> growing trend to remote participation, I would like to just post a
> reaction, while it's fresh in my mind, to being a remote participant for
> the first time.
> 
> I would like to start by saying that I was very pleased how how well
> Meetecho works. I watched the short online tutorial video (which is a bit
> out of date, and perhaps should be updated) and read the support page
> walkthrough of the various buttons, icons, etc., and didn't experience any
> problems during the week. While I was prepared to virtually raise my hand
> (I had a headset on just in case), I found that the integrated jabber
> window made it unnecessary - I was able to make my comments via jabber and
> the jabber scribe or WG chair read them to the room. I was also able to use
> the jabber window to communicate with @Meetcho if there were any mike or
> camera issues, and they were EXTREMELY responsive!
> 
> I also found Etherpad very useful when it's used. Not all WGs use it, but I
> would encourage all of those that don't use it to switch to it for the live
> meetings. There was a bit of trouble this meeting with duplicate Etherpads,
> but that's a tooling issue that I'm sure will be addressed for the next
> meeting. An excellent way to use Ethernet is prior to the meeting for the
> WG chair or secretary to paste in the meeting agenda, and then the notes
> for each item on the agenda can just be typed in following each agenda
> topic. It's also a good practice that if anyone is going to add to the
> Etherpad, they type in their name at the top of the page, so that their
> text color can be attributed to them.
> 
> Being a remote participant, I did miss the hallway conversations and such.
> But I didn't miss the airports, too-cold AC in the rooms, and other minor
> annoyances of travel. It's certainly a trade-off.
> 
> What could be improved? This probably isn't immediately feasible, but two
> cameras in each room (one pointed to the front, the other to the mike line)
> would be huge. That way you can watch both ends of the conversation at
> once. Also, in the Meetecho UI, it might be better to increase the size of
> the camera image and have the camera image and the slides vertically placed
> one on top of each other, rather than the smaller camera image over to the
> side. Or perhaps that could be an option. I know that you can make the
> camera image larger, but then you lose the slides.
> 
> But on the whole, being remote worked much better than I had expected, and
> for that I would like to thank everyone that's been working on making this
> possible, starting with the Meetecho team.
> 
> That said, my preference is still to attend in person if possible. :-)
> 
> Cheers,
> Andy

-- 
---
[email-masked]

---

From: Meetecho IETF support <[email-masked]>
Date: Wed, 31 Jul 2019 11:41:24 +0200

Il 26/07/19 21:19, Toerless Eckert ha scritto:
> I always found the meetecho setup to be very good especially also
> the support from the meetecho team. If there is anything to complain
> about is that i think the quality of the video from remote
> participants was lower than even what i think to remember from the
> past. I wonder if its really set to rate adapt to the available
> bandwidth or artifially limited to some low maximum.

We do cap the remote participants video bitrate. That cap has not been 
changed, though, so it's the same as last meetings.

> It really distracted from the experience, which otherwise (especially
> also including the jabber channel) would have been very close to the
> person being there in person.
> 
> Cheer Toerless
> 
> In-Reply-To:
> <CAA=duU2X1SjyPN0azuSpCykp4Wh8TNruO-knzYR=[email-masked]>
> 
>> With Adrian's post about our remote participation technology and
>> the growing trend to remote participation, I would like to just
>> post a reaction, while it's fresh in my mind, to being a remote
>> participant for the first time.
>> 
>> I would like to start by saying that I was very pleased how how
>> well Meetecho works. I watched the short online tutorial video
>> (which is a bit out of date, and perhaps should be updated) and
>> read the support page walkthrough of the various buttons, icons,
>> etc., and didn't experience any problems during the week. While I
>> was prepared to virtually raise my hand (I had a headset on just in
>> case), I found that the integrated jabber window made it
>> unnecessary - I was able to make my comments via jabber and the
>> jabber scribe or WG chair read them to the room. I was also able to
>> use the jabber window to communicate with @Meetcho if there were
>> any mike or camera issues, and they were EXTREMELY responsive!
>> 
>> I also found Etherpad very useful when it's used. Not all WGs use
>> it, but I would encourage all of those that don't use it to switch
>> to it for the live meetings. There was a bit of trouble this
>> meeting with duplicate Etherpads, but that's a tooling issue that
>> I'm sure will be addressed for the next meeting. An excellent way
>> to use Ethernet is prior to the meeting for the WG chair or
>> secretary to paste in the meeting agenda, and then the notes for
>> each item on the agenda can just be typed in following each agenda 
>> topic. It's also a good practice that if anyone is going to add to
>> the Etherpad, they type in their name at the top of the page, so
>> that their text color can be attributed to them.
>> 
>> Being a remote participant, I did miss the hallway conversations
>> and such. But I didn't miss the airports, too-cold AC in the rooms,
>> and other minor annoyances of travel. It's certainly a trade-off.
>> 
>> What could be improved? This probably isn't immediately feasible,
>> but two cameras in each room (one pointed to the front, the other
>> to the mike line) would be huge. That way you can watch both ends
>> of the conversation at once. Also, in the Meetecho UI, it might be
>> better to increase the size of the camera image and have the camera
>> image and the slides vertically placed one on top of each other,
>> rather than the smaller camera image over to the side. Or perhaps
>> that could be an option. I know that you can make the camera image
>> larger, but then you lose the slides.
>> 
>> But on the whole, being remote worked much better than I had
>> expected, and for that I would like to thank everyone that's been
>> working on making this possible, starting with the Meetecho team.
>> 
>> Cheers, Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 31 Jul 2019 09:46:16 -0400

Meetecho team,

(Removed the general IETF list, I don't think we need to include everyone
on what may become a Meetecho technical discussion).

I'm just curious, is there any particular reason for the cap? Loading
certainly isn't an issue for the IETF network or its uplinks. At the remote
end, there's just the one Meetecho connection, so why not use the available
bandwidth?

Thanks,
Andy

---

From: Meetecho IETF support <[email-masked]>
Date: Wed, 31 Jul 2019 15:56:54 +0200

Hi Andy,

as you figured it's not a matter of IETF network bandwidth. It's a 
matter of receiver-side bandwidth. The video sent by a remote 
participant is received by all other participants connected via 
Meetecho. Such participants are already receiving the videos we send 
from the physical room, namely the slides and camera feeds. If we don't 
set a cap, a remote presenter with plenty of bandwidth may send, e.g., 
2Mbps and overload the others.

The Meetecho team

Il 31/07/19 15:46, Andrew G. Malis ha scritto:
> Meetecho team,
> 
> (Removed the general IETF list, I don't think we need to include 
> everyone on what may become a Meetecho technical discussion).
> 
> certainly isn't an issue for the IETF network or its uplinks. At the 
> remote end, there's just the one Meetecho connection, so why not use the 
> available bandwidth?
> 
> Thanks,
> Andy
> 
> On Wed, Jul 31, 2019 at 5:41 AM Meetecho IETF support <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     <CAA=duU2X1SjyPN0azuSpCykp4Wh8TNruO-knzYR=[email-masked]
>     <mailto:[email-masked]>>
>      >

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 31 Jul 2019 10:04:41 -0400

Thanks, I can see that. For the next IETF, could you experiment with
raising the cap just enough to improve the quality a bit?

Cheers,
Andy

On Wed, Jul 31, 2019 at 9:56 AM Meetecho IETF support <[email-masked]>
wrote:

> >      >> That said, my preference is still to attend in person if
> possible.
> >      >> :-)
> >      >>
> >      >> Cheers, Andy
> >      >
> >
>

---

From: Meetecho IETF support <[email-masked]>
Date: Wed, 31 Jul 2019 18:35:20 +0200

Yeah that was the plan already.

Il 31/07/19 16:04, Andrew G. Malis ha scritto:
> On Wed, Jul 31, 2019 at 9:56 AM Meetecho IETF support <[email-masked] 
>      > On Wed, Jul 31, 2019 at 5:41 AM Meetecho IETF support
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >      > Thanks, Andy. Great to hear it did work out that well for you.
>      >      >
>      >      > I always found the meetecho setup to be very good
>     especially also
>      >      > the support from the meetecho team. If there is anything
>     to complain
>      >      > about is that i think the quality of the video from remote
>      >      > participants was lower than even what i think to remember
>     from the
>      >      > past. I wonder if its really set to rate adapt to the
>     available
>      >      > bandwidth or artifially limited to some low maximum.
>      >
>      >      > It really distracted from the experience, which otherwise
>     (especially
>      >      > also including the jabber channel) would have been very
>     close to the
>      >      > person being there in person.
>      >      >
>      >      > Cheer Toerless
>      >      >
>      >      > In-Reply-To:
>      >      >
>      >   
>       <CAA=duU2X1SjyPN0azuSpCykp4Wh8TNruO-knzYR=[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >      >
>      >      > On Fri, Jul 26, 2019 at 12:35:40PM -0400, Andrew G. Malis
>     wrote:
>      >      >> With Adrian's post about our remote participation
>     technology and
>      >      >> the growing trend to remote participation, I would like
>     to just
>      >      >> post a reaction, while it's fresh in my mind, to being a
>     remote
>      >      >> participant for the first time.
>      >      >>
>      >      >> I would like to start by saying that I was very pleased
>     how how
>      >      >> well Meetecho works. I watched the short online tutorial
>     video
>      >      >> (which is a bit out of date, and perhaps should be
>     updated) and
>      >      >> read the support page walkthrough of the various buttons,
>     icons,
>      >      >> etc., and didn't experience any problems during the week.
>     While I
>      >      >> was prepared to virtually raise my hand (I had a headset
>     on just in
>      >      >> case), I found that the integrated jabber window made it
>      >      >> unnecessary - I was able to make my comments via jabber
>     and the
>      >      >> jabber scribe or WG chair read them to the room. I was
>     also able to
>      >      >> use the jabber window to communicate with @Meetcho if
>     there were
>      >      >> any mike or camera issues, and they were EXTREMELY
>     responsive!
>      >      >>
>      >      >> I also found Etherpad very useful when it's used. Not all
>     WGs use
>      >      >> it, but I would encourage all of those that don't use it
>     to switch
>      >      >> to it for the live meetings. There was a bit of trouble this
>      >      >> meeting with duplicate Etherpads, but that's a tooling
>     issue that
>      >      >> I'm sure will be addressed for the next meeting. An
>     excellent way
>      >      >> to use Ethernet is prior to the meeting for the WG chair or
>      >      >> secretary to paste in the meeting agenda, and then the
>     notes for
>      >      >> each item on the agenda can just be typed in following
>     each agenda
>      >      >> topic. It's also a good practice that if anyone is going
>     to add to
>      >      >> the Etherpad, they type in their name at the top of the
>     page, so
>      >      >> that their text color can be attributed to them.
>      >      >>
>      >      >> Being a remote participant, I did miss the hallway
>     conversations
>      >      >> and such. But I didn't miss the airports, too-cold AC in
>     the rooms,
>      >      >> and other minor annoyances of travel. It's certainly a
>     trade-off.
>      >      >>
>      >      >> What could be improved? This probably isn't immediately
>     feasible,
>      >      >> but two cameras in each room (one pointed to the front,
>     the other
>      >      >> to the mike line) would be huge. That way you can watch
>     both ends
>      >      >> of the conversation at once. Also, in the Meetecho UI, it
>     might be
>      >      >> better to increase the size of the camera image and have
>     the camera
>      >      >> image and the slides vertically placed one on top of each
>     other,
>      >      >> rather than the smaller camera image over to the side. Or
>     perhaps
>      >      >> that could be an option. I know that you can make the
>     camera image
>      >      >> larger, but then you lose the slides.
>      >      >>
>      >      >> But on the whole, being remote worked much better than I had
>      >      >> expected, and for that I would like to thank everyone
>     that's been
>      >      >> working on making this possible, starting with the
>     Meetecho team.
>      >      >>
>      >      >> That said, my preference is still to attend in person if
>     possible.
>      >      >> :-)
>      >      >>
>      >      >> Cheers, Andy
>      >      >
>      >
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 31 Jul 2019 19:22:44 +0200

Thanks for the info,

In the ideal case, the meetecho mixer should prioritize bandwidth towards
participants for slides/audio and use whatever seems to be left
for the remote speaker video. Of course, no idea how
meetecho is designed to make this easy or difficult. Any docs ?

If nothing did change from prior IETF that's surprising, because this
time it felt specifically bad looking, Ghosty, blurry remote speakers.

Cheers
    Toerless

On Wed, Jul 31, 2019 at 06:35:20PM +0200, Meetecho IETF support wrote:
> > <mailto:[email-masked]>

-- 
---
[email-masked]

---

From: Meetecho IETF support <[email-masked]>
Date: Wed, 31 Jul 2019 19:43:58 +0200

Il 31/07/19 19:22, Toerless Eckert ha scritto:
> meetecho is designed to make this easy or difficult. 

There's no easy way of doing this.

> Any docs ?

https://ieeexplore.ieee.org/document/7992930

> time it felt specifically bad looking, Ghosty, blurry remote speakers.

This might be due to WebRTC bandwidth adaptation at remote speaker's 
side, i.e., the speaker was limiting its bitrate and/or resolution 
because the estimated available bandwidth was not enough. This is an 
automatic mechanism provided by browsers.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Jul 2019 14:42:14 -0400

I don't care that much about video quality (unless I have to lip-read..)

I care about audio quality, and echo cancellation.

It might be nice to have an option to mute speaker's headphones while they
are speaking, as often the echo is via the "analog hole" in the meeting room
itself. [%]

This really matters for non-native English speakers, as we need all the
fidelity there is in.

[%]-the solution of course is to remove the acoustic transmission media
    in the meeting rooms, and do all the meetings in vacuum.
    This also solves much of the temperature issues in the room.

    >> On Wed, Jul 31, 2019 at 9:56 AM Meetecho IETF support
    >> <[email-masked] <mailto:[email-masked]>> wrote:
    >> 
    >> Hi Andy,
    >> 
    >> from the physical room, namely the slides and camera feeds. If we
    >> don't set a cap, a remote presenter with plenty of bandwidth may send,
    >> e.g., 2Mbps and overload the others.
    >> 
    >> The Meetecho team
    >> 

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 31 Jul 2019 23:08:30 +0200

> are speaking, as often the echo is via the "analog hole" in the meeting room

The echo they hear themselves is one point.
There are also often problems with audio codecs that throttle down when there is other audio incoming.

We had several presentations with “underwater” audio this week, again; I don’t know whether that effect is related to this issue.  It would be good if there were a way to require a minimum audio quality (G.722 level, at least, well, Apollo 11 would already be great).

> This really matters for non-native English speakers, as we need all the

+1000.

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 31 Jul 2019 23:39:40 +0200

The main issue is that troubleshooting always takes time and
ideally someone with more expertise involved. SO you can not and do not
want to do it in any actual meeting.

Yada yada: offering some dry run/testing opportunity options would be
very helpful for remote participants to figure out what the best is they
can get.

On Wed, Jul 31, 2019 at 11:08:30PM +0200, Carsten Bormann wrote:
> We had several presentations with ???underwater??? audio this week, again; I don???t know whether that effect is related to this issue.  It would be good if there were a way to require a minimum audio quality (G.722 level, at least, well, Apollo 11 would already be great).
> 

-- 
---
[email-masked]