My friends on G+ have been inundated with excited posts by me late last night as I quickly received payoff for a minimal amount of work, so I apologize to those of you who are reading this for the bazillionth time. In the same day in which I lamented the lack of multi-input to Twitch from remote locations, I did some digging and found that yes, it is entirely possible to have broadcasters from remote locations stream to one Twitch channel. However, there’s a massive asterisk there. Twitch itself doesn’t allow re-broadcasting, so it’s basically one stream in from your broadcaster, one stream out through their player. You can fake it if you set up multiple viewers through Twitchify or Multitwitch, and isolate each player in its own layer through OBS, XSplit, FFSplit, or other broadcast software, but you’re probably going to suffer from re-broadcasting a broadcast. If you want to truly aggregate streams, you need an RTMP server. Here’s a handy diagram! Steve, Kelly, and Mittens are all playing MechWarriror Online with other members of their clan, and want to create a slick recruitment video. Using their broadcaster-of-choice, they all stream to a custom RTMP server using the url rtmp://server.address.com/[personal-channel]/[personal-key] instead of the predefined setup that allows them to stream directly to Twitch. The RTMP server handles the input and makes it available to the public at the same address each broadcaster uses for input. Another clan member — The Producer — isn’t playing. Instead, he’s got two apps running: a web browser which has multiple video viewers that display the RTMP streams on one page, à la Twichify, and a copy of XSplit. Unlike the broadcasters, The Producer needs to use XSplit because it’s the only broadcaster that can use RTMP streams as input (get on that, OBS and FFSplit!). Each RTMP stream behaves just like any other input within XSplit, allowing the producer to move and resize windows, aggregate them onto one canvas, or give them their own full-screen canvas. Each input displays what the individual streamers are streaming, so if Mittens has a webcam overlay on her game input, it’s what The Producer will see, and will have no control over moving multiple input sources from the broadcaster. Finally, The Producer uses the normal Broadcast to Twitch settings to pump the aggregated stream to the public. Why? This allows for streamers to get groups of people together into one broadcast, something that Twitch doesn’t support. With a producer at the helm, a group of people can make some pretty slick, near professional quality video without the need for post-processing. If one stream were a webcam focusing on some commentators who are watching the RTMP streams themselves, you could set up a League of Legends style eSports presentation. Also, by having one aggregate display, and then each stream on their own canvases, a group can create a pretty decent show, live and without post-processing. Also, if you have an embeded video player which can accept RTMP streams, you could put your own video player on your own website using Flowplayer or JWPlayer, and skip the Twitch ads! It’s entirely possible to have broadcasters input to the RTMP server, have a producer aggregate those streams, and then re-post to the RTMP server. If your embded video player picks up on any of those streams, it can be posted to your own website. Caveats First, you need the RTMP server. I did some leg-work, and found two commercial servers, and one free server. You need hosting, virtual or otherwise, or a box in your own home. Obviously, to make this work, you need someone to act as the producer who will aggregate all the streams and send it out to the public. Sadly, it can’t be one of the streamers, unless someone wants to run two broadcasters: one to send out, and one to aggregate and publish. While possible, that person would need a pretty hefty PC and a lot of bandwidth. Also, you have to use a broadcaster. Games which pump out the streams directly to Twitch won’t work, which also excludes the next generation of consoles (unless the broadcast destinations can be re-routed somehow). Technical Junk There are some commercial options available, like Wowza or Red 5, if you have dedication and money to burn. You’ll also need a physical server on which to run them. I set up a virtual Ubuntu server on Microsoft’s Azure cloud computing system and followed a set of instructions I found on the OBS forums for setting up the free and lightweight nginx web server with an RTMP plugin. I’m not a Linux guy, so I had to kick my way through the installation, but once I understood what I was doing wrong, everything went off without a hitch (which never happens for me when dealing with Linux!). I haven’t done a lot of deep testing, but I set up two distinct end-points on the same port, and was able to connect to both of them for both input and output, and the server didn’t even break a sweat. I believe that there needs to be distinct endpoints (rtmp://server.address.com/channel1, /channel2, /channel3) for each stream you want to accept. Finally, when setting up Twitch or other stream you need to provide an API key, but when connecting to nginx, the API key can be whatever the broadcaster wants it to be. It’s totally arbitrary in this case, but the producer will need to know what the broadcaster chose in order to pick up the stream from the RTMP server. An an example, I set up a channel called Scopique, so the RTMP URL would be rtmp://server.address.com/Scopique, and the API key I set up was whatever. Some output locations need a full URL (rtmp://server.address.com/Scopique/whatever) and some need just the channel (up to Scopique) with the API key in its own box. One of the benefits from this is that you can use this set up to also record streams to disk (on the server) or even to send the stream direct to Twitch from the RTMP server. This is basically replicating the functionality that the broadcast software offers out of the box, but it’s possible that there might be a situation out there that doesn’t offer a direct pipe to a broadcasting outlet, and putting an RTMP server in between might solve that issue.