The BIG GAME 36 Streamy Scrubdown
(n.b does not involve sponge baths, sorry)
If you see something you’d like to comment on, right click what you’re concerned about and click Comment.
The Picam worked very well for the price, apart from some initial issues with the stream artifacting - these seemed to clear up after a while once I set it to 720p @ 25fps (which appears adequate). I’m assuming this was purely down to the Pi’s IO bus being unable to encode H264 AND pull in a good video feed at the same time. Latency was in the region of 2-3 seconds using RTSP (excellent) and 10-15 seconds using RTMP (probably out of limits). However, the quality at night was pretty much useless, even with the camera in low light mode (fig P1). Ilumos had the idea of using IR lighting to bathe the room and produce better night results, but I’m not sure how well this would work with the standard PiCam - there is a version of the cam without the IR filter installed, but removing it from our current one is a huge fiddle that isn’t guaranteed to work (and I’m unsure on what the quality would be like with said lighting).
P1 - The PiCam at night was a bit useless.
Someone on the crew (I think it was Jynx?) suggested we have more camera angles, and fade between them. I’ll go into more detail on the stream side of this later, but on the camera side we’ve got a couple of options - we can either buy more PiCams (~£50 a hit) and hope that IR lighting (~£?) works well, or use proper IP cameras (~£54.99 on ebay, see shopping list) that can do at least 720@30f at night with H264 (not MJPEG). This is going to come with a bandwidth hit though (RTP uses a pretty significant amount of bandwidth to do low latency)
Additionally, I’ve had a quick look into roaming cameras (for really super snazzy camera angles, especially during the final), and short of using Android phones with a RTMP app (which does work well, if you count cameraphones melting your hands as works well) there aren’t really any cheap options (see the Teradek Cube (or bolt) with super expensive cam or optionally plugging into a HDMI cam using longass HDMI cable) - if you’ve got a brainwave, it’d be appreciated.
Streambox did its job well, taking incoming feeds and cleanly switching between them. However, quality had to be taken down to 720@30fps (target is / was either 720@60f or 1080@30f) as it was simply overloading the box to transcode high resolution / framerate incoming streams (and that’s without using vMix). In an ideal world, we’d have beefier hardware to run vMix on Streambox itself (instead of just importing it from a beefy machine) - it mainly pushes CPU ( vmix recommends Core i7 or higher and I can pretty much vouch for that, it definitely pushes my 3770k) and any modern GPU newer than a GTX250 is fine. Also, something that I definitely think’s worth investing in is a decent capture device, for pulling in completely lossless 60fps video from PCs (or even consoles) without putting minimal (if any) strain on either side (pushing 60fps over network is extremely intensive on both network and PCs due to transcoding) - I think Maveric said he had an exceptionally long HDMI cable definitely not compensating that we can use if necessary. Capcards include the Blackmagic Intensity Pro or Shuttle USB3 (~£120), DeckLink cards (~£100, really only suitable if we’re using SDI stuff AKA ££££), or other gaming-oriented solutions from Elgato, Avermedia, and Hauppauge (to name but a few)
Elaborating on having multiple cams incoming from the Cameras section, it’s absolutely possible to do apart from it being a pain to get autotransition working. OBS does have global sources support which keeps each cam loaded all the time (then you’d just write a plugin to automatically cycle them), but this has a significant impact on resource usage (both network and CPU). vMix can do this very well, on the condition it has good hardware (as previously discussed) and working out how to get automatic switching working (although writing a plugin for vmix to do this wouldn’t be a hassle).
No issues here, Proxy had to be spun up as Box was too underpowered to handle both nginx-rtmp and OBS at the same time. This could possibly be renamed for next event to make it easier to find for local peeps (stream.biggame?), and I will make improvements to its UI and client pages.
Audio was one of the main issues encountered. Our original setup was pure digital - RTMP streams controlled the audio, and StreamBox simply played Spotify music when nothing was going on. However, once we realised that PA audio would be nice to have on stream, our setup complicated quite significantly.
A1 - The TBG36 audio setup at the close of play.
This worked okay, but had some serious flaws, not least involving issues with sound levels, and also having to climb the ladder to the Mezzanine every time audio had to be adjusted even a tiny amount (my hands still hurt). There’s a couple of ways around this, either have a smaller mixer at a downstairs dedicated mixing / streamy area and just have the upstairs mixer on passthrough (possible £ with this for the mixer, and there may still need to be a hardware presence in the mezz) or just move streaming and production upstairs next to the mixer and use the hardware already available up there (only need to buy / supply a fan to stop people passing out from the insane heat up there). The other option is to take audio mixing full software thro vMix, which thinking about it would actually work quite well, but it seems a shame to miss out on the nice hardware mixing kit that we have at our disposal.
I’m working on a flow for this new audio setup, but if someone’s got an idea let me know (drop a comment).
Also, I believe it was Blackstar with the idea to have PA audio available as an internal stream so that people with headphones on don’t get muffled out - this is dead easy to do, and will just require an aux connection from PA to any server (streamproxy or streambox, doesn’t matter)
Overall latency was as follows:
Latency can be improved when casting to the projector if we start using vMix on streambox, as it has a handy dandy slave monitor out function with zero latency. This wouldn’t be an option for Dota however (we’ll need a delay of some sort)