PlayStream - Streaming Media Solutions for Streaming Video & Streaming Audio
Customer Login
Streaming Audio & Video Solutions - Home Login Streaming Video & Audio Services Showcase- Webcasting and Streaming Media About PlayStream - Streaming Media Solutions Support for Audio/Video Streaming Services Contact us for Windows Media Streaming Solutions
Quote Wizard - Content Delivery Network Services
 
Calculate the file size and costs of your media content.
 
Contact Us for Content Delivery Services
 
Request Customer Support
Toll Free: 800.874.8855
 
Supported Formats for Content Delivery Network
 
 
 
How Does Live Webcasting Work?
 
Using PlayStream to deliver live audio/video instills the edge you need to stand out above the competition. We’ve built a high capacity, high quality, distributed network that directs your end users to the closest available datacenter; and each data center has many different major carriers from which to route your data. The end result is that your end users experience a better viewing performance. Broadcasting live with PlayStream is simple and requires text industry tools that are easily available and affordable.
Webcasting and Streaming Media Solutions
1. Capturing Your Live Broadcast To A Digital Format

The first of these steps is to capture your media. In order to do this, you will need an input device for your computer. For audio content, the input device can be a text sound card. For video content, you will need some type of video capture device.

Examples of typical video capture devices are a firewire port (firewire card) or a video capture card. Common video capture cards that we know work are the Osprey 220 from ViewCast or capture cards from Winnov or Pinnacle.

 
2. Converting Your Live Broadcast To A Streaming Format From An Encoding Station

An encoding station is simply a computer that runs encoding software (the "encoder") that converts your captured media to a streaming format. Most encoders require a reasonably fast computer to run. Normally a Pentium II with at least 128 MB of RAM is good if you're a PC user but, as always with computers, faster is better. Typically, We recommend that you use the encoding software that is provided by the manufacturer of the streaming format you have chosen. That is if you are a Windows user broadcasting a live Windows Media stream, we suggest you use the Windows Media Encoder. If you are broadcasting your content in RealMedia format, please use the newest encoder available for your operating system. For QuickTime Streaming we suggest the QuickTime Broadcaster for Mac OSX.

During a live streaming media broadcast the encoding software (the encoder) takes the data from your input device and converts it to a streaming format. Depending on the streaming platform (Windows Media, RealMedia or Quicktime) the server either "pulls" (contacts the encoder and requests the stream) or the encoder "pushes" (sends the stream to the server IP address) to rebroadcast the live stream. When the encoder converts the stream, it "buffers" (saves a certain amount of the stream data on the encoding work station) before the stream is distributed for rebroadcast through the servers in our data centers. This creates a certain amount of "latency" (lag time between the actual event and when your audience member sees it.) There are two other sources of latency during a live streaming media broadcast. The time it takes to get the stream across the Internet to our servers and the time it takes your audience member to receive the stream across the Internet. These vary according to the position of your encoding station on the Internet and the position of the computer of each of your audience members.

When you set up your stream for live broadcast, you must specify the bit rate (quality of the stream). This quality is constrained by the upstream bandwidth of your Internet connection and cannot exceed this limit or your stream will never reach our servers. Along the same lines, your audience member must have enough downstream bandwidth to allow all of the data from the encoded stream to play on their computer. If the encoded stream you are sending for rebroadcast exceeds the downstream bandwidth of your audience member, they will never receive the stream.

 
3. Broadcasting Live Through Our Content Delivery Network

Depending on how the servers are setup they will deliver the media stream in one of two ways. Either as a push configuration where servers are continuously sent a stream from the encoder, or in a pull configuration. A pull configuration makes a connection and "pulls" the stream when a player connects to it. Regardless of which configuration is being used (the Windows Media Server uses "pull" while the RealServer and Darwin Server for QuickTime use "push".) Once the feed is acquired on the inbound streaming server it is re-distributed throughout our two data centers via load-balancing.

When you set up your account, we send you a link to access your broadcast through our globally load balanced easy link system and you put this link into the HTML of your Web page. when someone visits your Web site and clicks a link for streaming audio or video, that request is directed to the data center closest to them and they stream your live broadcast through our servers.

By directing your audience member to the closest data center, we cut down on the time it takes to deliver your stream to them. Once the closest data center has been established, the streaming request is sent down one of the many backbones we are connected to via Internap's advanced "Synchronous-When-Optimal" routing service. Our system delivers your media by avoiding the often congested public and private peering points of the Internet, thus greatly increasing delivery performance and reducing problems such as rebuffering.

 
4. Delivering Your Live Stream To Your Audience
When a streaming media Player makes a connection to one of our streaming servers via our easy link technology or a reference file (RAM for RealMedia, ASX; WVX or WAX for Windows Media; or QTL for QuickTime), the server sends the player data via User Datagram Protocol (UDP) by default. If the streaming media player cannot accept this data, the server tries to resend it via the TCP protocol to several different ports, with port 80 as it's final attempt if each attempt fails. This process is called protocol rollover. If this negotiation is successful, and the server is either Windows Media or the RealServer, a check is made for the connection speed configured in the connection settings of the streaming media player. Based on the connection speed returned to the server from the player, the server will send the highest play supported stream from a multiple-bit-rate streaming file, the whole file in the case of a single-bit-rate streaming file, or just the audio portion of an audio/video streaming file if the player connection speed is not fast enough to accept all video data.
 
Home | Privacy Policy | Terms and Conditions | Contact | Sitemap
Copyright 1998-2014 PlayStream, Inc.
All rights reserved.