search

AlexChesser / lgtm-shipit

The project organization repository for the LGTM: ShipIt! podcast.
MIT License
3 stars 0 forks source link

Test complete livestream setup. #19

Open chillfox opened 3 years ago

chillfox commented 3 years ago

I noticed you mentioned livestreaming to YouTube and Twitch.

From having been part of a failed livestream (organised by someone else) I have learned that testing each component individually is not enough. You will need to do a complete test, that is steaming to both platforms simultaneous with the number of guests that you intend to have simultaneously, for about 10-20 minutes and then watch it back afterwards on both platforms. The audio can start to get garbled if the computer is struggling or there is not enough bandwith.

Depending upon how you set it up you could have one incoming and outgoing 1080p stream for each guest add two outgoing steams for the platforms and you are at 4 1080p streams from just one guest. That can quickly hit the limits of either bandwidth or what the computer can process.

AlexChesser commented 3 years ago

Thank you! Great advice.

I currently use restream.io to send to multiple platforms, but I hadn't actually considered the impact of how do we actually combine multiple guests simultaneously.

A few initial thoughts for further research & validation:

Some large twitch channels do "survivor style" shows where a bunch of twitch celebrities all get on the same screen at the same time. My understanding is that they use discord as the underlying service, which combines all the incoming streams and send it out as a single video.

It might be the case that professional, full time twitch streamers have a far greater incentive to spend the extra 20 minutes to couple hours of setting up and configuring any software that needs to be used there.

I imagine that zoom must work the same way. Otherwise how could I possibly get on to 20 person zoom calls every single day?

The advantage of using a third party service like zoom becomes really clear when I consider the number of hours in setup that are saved on behalf of guests who probably don't have anywhere near the same level of interest in the technical aspects of configuring something like OBS or downloading and installing discord.

I think potentially a reasonable setup would be as follows:

channel / host:

Looking at the zoom group HD documentation, has some more details https://support.zoom.us/hc/en-us/articles/207347086-Group-HD

Bandwidth requirements for group HD

Standard HD (720p)

1 on 1 video calls: 1.2 Mbps (up/down) Group video calls: 1.5 Mbps (up/down)

Full HD (1080p)

1:1 video calling: Receiving 1080p HD video requires a minimum of 1.8 Mbps Sending 1080p video requires a minimum of 1.8 Mbps

Group video calls:

Receiving 1080p HD video requires a minimum of 2.5 Mbps Sending 1080p video requires a minimum of 3.0 Mbps

One disadvantage of zoom is that the guest layouts can't be customized like what some really slick presenters like Jason Weimann are doing:

image image source

If you hop around in that video you'll see he actually has really high production values. He has transitions between scenes, he swaps between 3 up / 4 up displays as people leave and join the show.

In his case, at least 3 of his four guests are professional youtubers with large followings. (As an aside, I can really see the value of a few colored lights in the background adding depth to the scene. At the moment I'm more like Salim's setup with packing, boxes, and my 2 year old's tows all around me, mine are all just out of frame :) ).

In terms of getting content out the door I think the pragmatic approach if doing group/panel discussions would be to start with a zoom-pro account. The $200 / annual cost of zoom pro means I'd probably want to defer multi-user panel discussions until after I understand the basics a little more.

From a strategic perspective I want to try and build this using the "rules" and strategies I've been reading about on hackernews since ~2010 (when I first joined) ... start small, iterate, prove that it is viable, double down or pivot. etc...

Again unrelated... thank you for opening an issue! I woke up at 5AM after 4 hours sleep because I wanted to work on something for this. Seeing a spontaneous community issue arrive is literally one of the earliest tests of product viability that you'd want to see. Any participation is really encouraging.

//TODO:

  1. update readme with "bandwith guidelines" in the interview prep section
  2. end-to-end test before going live
  3. create "staging" channels to avoid sending unnecessary go-live notifications to audience (the channels live in their pockets! nobody sitting at dinner wants a dozen notifications like "try now" and "how about now"?)
  4. find a way to feature request "checklists" within github issues.
  5. nevermind number 4!: it's right here 😄
    image

TODO