Streaming media
From Wikipedia, the free encyclopedia
 |
This article does not cite any references or sources. Please help improve this article by adding citations to reliable sources (ideally, using inline citations). Unsourced material may be challenged and removed. (October 2007) |
 |
This article may require copy-editing for grammar, style, cohesion, tone or spelling. You can assist by editing it now. A how-to guide is available. (January 2008) |
Streaming media is multimedia that is constantly received by, and normally presented to, an end-user while it is being delivered by a streaming provider (the term "presented" is used in this article in a general sense that includes audio or video playback). The name refers to the delivery method of the medium rather than to the medium itself. The distinction is usually applied to media that are distributed over telecommunications networks, as most other delivery systems are either inherently streaming (e.g. radio, television) or inherently non-streaming (e.g. books, video cassettes, audio CDs). The verb 'to stream' is also derived from this term, meaning to deliver media in this manner.
Contents |
[edit] History
Attempts to display media on computers date back to the earliest days of computing, in the mid-20th century. However, little progress was made for several decades, primarily due to the high cost and limited capabilities of computer hardware.
From the late 1980s through the 1990s, consumer-grade personal computers became powerful enough to display various media. The primary technical issues with streaming were:
- having enough CPU power and bus bandwidth to support the required data rates
- creating low-latency interrupt paths in the OS to prevent buffer underrun[citation needed]
However, computer networks were still limited, and media was usually delivered over non-streaming channels, such as CD-ROMs.
The late 1990s and early 2000s, internet users saw:
- greater network bandwidth, especially in the last mile
- increased access to networks, especially the Internet
- use of standard protocols and formats, such as TCP/IP, HTTP, and HTML
- commercialization of the Internet
These advances in computer networking combined with powerful home computers and modern operating systems made streaming media practical and affordable for ordinary consumers. Stand-alone Internet radio devices are offering listeners a "no-computer" option for listening to audio streams. But it needs further adhoc references to it.
In general, multimedia content is large, so media storage and transmission costs are still significant; to offset this somewhat, media is generally compressed for both storage and streaming.
Increasing consumer demand for streaming of High definition (HD) content to different devices in the home has lead the industry to develop a number of technologies, such as WirelessHD or ITU-T G.hn, which are optimized for streaming of HD content without forcing the user to install new networking cables.
A media stream can be on demand or live. On demand streams are stored on a server for a long period of time, and are available to be transmitted at a user's request. Live streams are only available at one particular time, as in a video stream of a live sporting event.
Research in streaming and media is ongoing and representative research can be found at the Journal of Multimedia.
[edit] 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):
(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.
[edit] Protocol issues
Designing a network protocol to support streaming media raises many issues, such as:
- 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. While delay due to buffering is acceptable in video on demand scenarios, users of interactive applications, such as video conferencing, will feel a loss of fidelity, if the delay that buffering contributes to, exceeds 200 ms [1].
- 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.
Multicasting broadcasts the same copy of the multimedia over the entire network to all clients - 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.
[edit] References
- ^ Krasic, C. and Li, K. and Walpole, J., The case for streaming multimedia with TCP, Lecture Notes in Computer Science, pages 213--218, Springer, 2001
