[I’ve dredged this up from the Way Back Machine, see because it’s still relevant and potentially useful]
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 an example of how that works:
Steve, Kelly, and Mittens are all playing MechWarrior 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.
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, live, 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.
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, a lot of bandwidth, and insane multitasking abilities.
Also, you have to use stand-alone broadcasting software. Games which pump out the streams directly to Twitch won’t work, which also excludes the next generation of consoles (unless you do something like this).
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!).
If you want to have multiple inputs, each input will need it’s own endpoint. When using Twitch, this is the channel name: http://www.twitch.tv/CHANNEL_NAME. The OBS forum instructions explain how to set this up in the nginx.conf file (the config section labeled “live”), so if you have a team, name each endpoint by the streamer’s nickname and you should be all set.
Twitch has a layer of security in it’s broadcast key, but nginx isn’t so secure. You will need to provide a suffix to your RTMP url (http://www.myrtmp.com/CHANNEL_NAME/BROADCAST_KEY), but that broadcast key can be anything you want. The only thing to keep in mind is that the whole URL needs to be provided to whatever input catcher is being used. So when using XSplit or VNC to pick up the stream, you’ll need to include the URL, channel name, and whatever arbitrary broadcast key you decide to stream to. Change it, and the stream catcher will need to update it’s input URL. As if that wasn’t enough, some stream catchers may or may not need that broadcast key bit. Yeah, sorry about that. I know VNC (for monitoring the stream) does need it. XSplit may or may not. FlowPlayer may or may not. I have to run a few more tests to determine which ones need which data.
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.