Unfortunately, when the encoding computers stopped sending a stream to the origin (which they frequently would, eg when breaking for lunch), the origin would send a message to the edges to say “stream has stopped”. A single feed would go from our origin to each edge, and then viewers would connect to the edges to get the stream relayed to them. Instead, our in-house server would be what’s called an Origin Server, and we’d set up two more Wowza instances on Amazon EC2 to be our Edge Servers. However, no-one would connect to our in-house server, since the bandwidth requirements would be too much even for our top-notch internet connection. Our planned architecture was to have an in-house Wowza server (which would take video from our encoding computers running Wirecast). This worked fine when we were just using one streaming server, but we hit a snag when we tried to scale it. This would save us having to mess about with recordings: we’d simply note the timestamp when each speaker started and provide links that would send viewers directly to that point in the DVR stream. The original idea was to have a DVR stream: that is, whenever you first load up the streaming page, you can rewind back throughout the entire event. Having had experience with Wowza, and knowing that in theory it had the capabilities we needed, we went for that. That leaves three main players in the live streaming software game: Flash Media Server, Wowza Media Server (now Wowza Streaming Engine), and Flussonic. It’s probably most useful if I simply describe the architecture we used, along with its pros and cons.įirst off, why not use one of the existing streaming services such as Livestream, Ustream or DaCast? They are all fairly basic services, and don’t come with the flexibility we needed to be able to mingle recordings/DVR, mutiple bitrate streams, and all the accessibility options (live subtitles, etc). There are many tutorials online about how to do this, so I’m not going to present too much code/config.
0 kommentar(er)
