[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reducing streaming latency



Hi Wookey (2019.03.21_03:57:25_+0200)
> Yes I agree what we have makes sense for what we currently try to
> achieve, and that none of this is simple, but if we changed the
> emphasis from 'making uploadable video which can also be watched
> live-ish' to 'must enable n-way discussion with some remote
> participants' then we'd make different tech choices.

I suspect the answer here is multiple tech choices.

e.g. a mumble / something real-time would be great for remote attendees
who get involved in a BoF are some question back-and-forth. IRC
questions usually have a good 30 seconds latency, and there's no real
opportunity to have a discussion.

That said, that level of interaction wouldn't be appropriate in most
talks (as Andy pointed out). It's BoFs that really benefit from
something more real-time.

> This is a big question and I don't have direct answers, but given the
> ubiquity of RTC video/audio meetings, I think we ought to be able to
> use that tech in debconf. So something like jitmeet integrated into
> the set-up so that someone could appear on-screen when asking a
> question, and get near-enough real-time video, ought to be
> possible. Perhaps a second screen with all the remote heads on (more
> or less like the old Ubuntu IRC screen), zooming in to a speaking
> head, would work.

Obviously this is more complexity in the setup, but it's something I'd
be interested in us pursuing. I suspect at a lower level of priority
than the recorded videos and streams.

And yes, the less integrated that is, the easier, probably. But it's
still extra stuff to figure out and manage.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272


Reply to: