There is a major difference in Web Servers and Streaming Servers. Below you will find some interesting information about Streaming Audio/Video. If you would like information on the differences between Web Servers and Streaming Servers, the best explanation I have found is from Microsoft.
What is Streaming Audio/Video (media)?
Streaming media (in this instance we are talking about internet delivery only) is multimedia that is constantly received by, and normally presented to, an end-user. This is all done while it is being delivered by a streaming provider. This refers to the delivery method of the medium rather than to the medium itself. It can be either audio or video streaming.
With advances in computer networking along with more powerful computers and operating system, it has made streaming media more practical and affordable than ever before to all consumers.
Multimedia content, whether audio or video, in general, creates large files. This causes media storage and transmission costs to be significant. To help cut down the cost, these types of files are usually compressed for both storage and streaming purposes.
You can receive media streams either "live" or "on demand". A "live" stream is a video that is only available at one particular time (just like live TV). It is an event that is being streamed to the internet while it is happening. The "on demand" streams can be audio or video and are stored on a server indefinitely. They are available to be transmitted at the user's request.
What is Bandwidth?
In computer science or computer networking, digital bandwidth, network bandwidth or just bandwidth is a measure of available or consumed data communication resources expressed in bit/s or multiples of it (kbit/s, Mbit/s etc).
Bandwidth is either the bandwidth capacity or the bandwidth available in bit/s. This usually means the net bit rate, channel capacity or the maximum throughput of a physical or logical communication path in a digital communication system. An example is a bandwidth test implies measuring the maximum throughput of a computer network. Reasoning for this usage is the maximum data rate of a physical communication link is proportional to its bandwidth in hertz, which is sometimes called frequency bandwidth, radio bandwidth or analog bandwidth, the latter especially in computer networking literature.
Bandwidth can also refer to consumed bandwidth (bandwidth consumption), corresponding to achieved throughput or goodput (for example: average data rate of successful data transfer through a communication path). This meaning is for example used in expressions such as bandwidth shaping, bandwidth management, bandwidth throttling, bandwidth cap, bandwidth allocation (for example: bandwidth allocation protocol and dynamic bandwidth allocation), etc.
Digital bandwidth of a bit stream is proportional to the average consumed signal bandwidth in Hertz (the average spectral bandwidth of the analog signal representing the bit stream) during a studied time interval.
Digital bandwidth may also refer to average bitrate (ABR) after multimedia data compression (source coding), defined as the total amount of data divided by the playback time.
As for web site hosting, the term "bandwidth" is often used to describe the amount of data transferred to or from the web site or server within a prescribed period of time. Another more specific phrase used for this meaning of bandwidth is monthly data transfer.
This is also referred to as gross bit rate, net bit rate, channel capacity and throughput, to avoid confusion between digital bandwidth in bits per second and analog bandwidth in hertz.
Streaming Bandwidth and Storage
Streaming media storage size (in the common file system measurements megabytes, gigabytes, terabytes, and so on) is calculated from streaming bandwidth and length of the media with the following formula (for a single user and file): storage size (in megabytes) = length (in seconds) * bit rate (in kbit/s) / (8 * 1024)
(since 1 megabyte = 8 * 1024*1024 bits Real world example:
One hour of video encoded at 300 kbit/s (this is a typical broadband video for 2005 and it's usually encoded in a 320×240 pixels window size) will be: (3,600 s * 300,000 bit/s) / (8*1024*1024) give around 128 MB of storage
If the file is stored on a server for on-demand streaming and this stream is viewed by 1,000 people at the same time using a Unicast protocol, you would need: 300 kbit/s * 1,000 = 300,000 kbit/s = 300 Mbit/s of bandwidth
This is equivalent to around 125 GiB per hour. Of course, using a Multicast protocol the server sends out only a single stream that is common to all users. Hence, such a stream would only use 300 kbit/s of serving bandwidth. See below for more information on these protocols.
Protocol issues
Designing a network protocol to support streaming media raises many issues.
Datagram protocols, such as the User Datagram Protocol (UDP), send the media stream as a series of small packets. This is simple and efficient; however, there is no mechanism within the protocol to guarantee delivery. It is up to the receiving application to detect loss or corruption and recover data using error correction techniques. If data is lost, the stream may suffer a dropout.
The Real-time Streaming Protocol (RTSP), Real-time Transport Protocol (RTP) and the Real-time Transport Control Protocol (RTCP) were specifically designed to stream media over networks. The latter two are built on top of UDP.
Reliable protocols, such as the Transmission Control Protocol (TCP), guarantee correct delivery of each bit in the media stream. However, they accomplish this with a system of timeouts and retries, which makes them more complex to implement. It also means that when there is data loss on the network, the media stream stalls while the protocol handlers detect the loss and retransmit the missing data. Clients can minimize the effect of this by buffering data for display.
Unicast protocols send a separate copy of the media stream from the server to each recipient. Unicast is the norm for most Internet connections, but does not scale well when many users want to view the same program concurrently.
Multicast protocols were developed to reduce the data replication (and consequent server/network loads) that occur when many recipients receive Unicast content streams independently. These protocols send a single stream from the source to a group of recipients. Depending on the network infrastructure and type, Multicast transmission may or may not be feasible. One potential disadvantage of multicasting is the loss of video on demand functionality. Continuous streaming of radio or television material usually precludes the recipient's ability to control playback. However, this problem can be mitigated by elements such as caching servers, digital set-top boxes, and buffered media players.
IP Multicast provides a means to send a single media stream to a group of recipients on a computer network. One of the challenges in deploying IP multicast is that routers and firewalls between LANs must allow the passage of packets destined to multicast groups. If the organization that is serving the content has control over the network between server and recipients (i.e., educational, government, and corporate intranets), then routing protocols such as IGMP and PIM can be used to deliver stream content to multiple LAN segments.
Peer-to-peer (P2P) protocols arrange for prerecorded streams to be sent between computers. This prevents the server and its network connections from becoming a bottleneck. However, it raises technical, performance, quality, business, and legal issues.
Push technology
Push technology (also known as "server push") describes a style of Internet-based communication where the request for a given transaction originates with the publisher or central server. It is contrasted with pull technology, where the request for the transmission of information originates with the receiver or client.
Push services are often based on information preferences expressed in advance. This is called a publish/subscribe model. A client might "subscribe" to various information "channels". Whenever new content is available on one of those channels, the server would push that information out to the user.
Synchronous conferencing and instant messaging are typical examples of push services. Chat messages and sometimes files are pushed to the user as soon as they are received by the messaging service. Both decentralized peer-to-peer programs (such as WASTE) and centralized programs (such as IRC or Jabber) allow pushing files, this means the sender initiates the data transfer rather than the recipient.
Email is also a push system: the SMTP protocol on which it is based is a push protocol (see Push e-mail). However, the last step—from mail server to desktop computer—typically uses a pull protocol like POP3 or IMAP. Modern e-mail clients make this step seem instantaneous by repeatedly polling the mail server, frequently checking it for new mail. The IMAP protocol includes the IDLE command, which allows the server to tell the client when new messages arrive. The original BlackBerry was the first popular example of push technology in a wireless context.
Another popular type of Internet push technology was PointCast Network, which gained popularity in the 1990s. It delivered news and stock market data. Both Netscape and Microsoft integrated it into their software at the height of the browser wars, but it later faded away and was replaced in the 2000s with RSS (a pull technology).
Other uses are push enabled web applications including market data distribution (stock tickers), online chat/messaging systems (webchat), auctions, online betting and gaming, sport results, monitoring consoles and sensor network monitoring.
If you need help finding a Streaming Server contact us today!