:: News ::
|
Case studiesThe following case studies are based on real situations that webcast producers face every day. They are intended to help illustrate the utility of StreamAware, both during and prior to a webcast event.Case 1: Setting up for a Webcast in a Foreign Location #1 Setting up for a Webcast in a Foreign LocationDays before an event at a hotel in New York City, the featured speakers demand that the event be webcast over the Internet. In fact, if the event isn’t webcast, they refuse to participate.So, a last-minute decision is made to proceed with setting up a live webcast of this event. The challenge, though, is that this event is being held at a remote location outside of the friendly confines of a corporate environment where webcasts are an everyday occurrence. To determine the feasibility of webcasting from this location, a number of questions must be answered quickly. How much bandwidth is available from the hotel? Can video be streamed, or does it need to be audio only? What’s the connectivity to my CDN like? Or, what CDN offers the best route for that live stream, considering both bitrate and format? The IT contact at the hotel where the event is being held claims there’s a reliable, dedicated 10Mbps connection available from the venue through which a webcast can be streamed out to the media server of choice. Yet, a quick run through of StreamAware’s network diagnostic tests proves this not to be the case. As it turns out, that supposed 10Mbps connection wasn’t good for anything beyond a 16Kbps audio stream. Plus there’s only one CDN in the Northeast that is able to receive a signal from this location within a reasonable number of hops. Within minutes, all of the necessary questions surrounding if an event can be webcast from this hotel are answered, and the webcast producer is able to generate a service level agreement that they feel confident can be delivered, considering the conditions of streaming from this remote location. #2 When a Live Stream Goes Down…To help facilitate efficient, effective corporate communications, a Fortune 500 company decides to webcast of its quarterly earnings report to investors and employees, potentially reaching an audience that numbers well into the tens of thousands.This webcast begins without a hitch, everything appears fine, when all of a sudden the stream is dropped and thousands of participants are left without a way to access the live feed. A quick call to the network engineers reveals nothing as they insist the problem stems from the encoder and that their server is fine. Yet, everything on the encoder appears to be functioning as it should. Meanwhile, the earnings call hasn’t stopped, and the webcast’s audience is growing increasingly impatient with what appears to be another failed experiment on the unproven Internet. Had the webcast producer charged with this event had StreamAware in hand, he or she would’ve been able to run the application without disconnecting the live stream so as to quickly ascertain the root of this problem: the media server had reached capacity on port 554 and that port had froze. With this knowledge in mind, the problem could have been resolved, saving the success of the webcast. But at that moment, there was nothing the webcast producer could do to prove their case that the point of failure wasn’t found on the encoder but instead existed on the network. As a result, the webcast was a total failure as the majority of its audience was unable to view the stream. And who got blamed? Not the network engineer, but instead the poor webcast producer who’d done nothing wrong but still had to suffer the brunt of the criticism following this unsuccessful live streaming event. |
|||
|
||||
