Streaming media: Difference between revisions
Undid revision 197505352 by Grinsandfun (talk) |
Grinsandfun (talk | contribs) |
||
Line 187: | Line 187: | ||
* [[Akamai]] |
* [[Akamai]] |
||
* [[Limelight Networks]] |
* [[Limelight Networks]] |
||
* [[ |
* [[CDNetworks]] |
||
[[Category:Computer file formats]] |
[[Category:Computer file formats]] |
Revision as of 22:01, 11 March 2008
This article relies largely or entirely on a single source. (October 2007) |
Streaming multimedia is multimedia that is constantly received by, and normally displayed to, the end-user while it is being delivered by the provider. 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.
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, due primarily to the high cost and limited capabilities of computer hardware.
Academic experiments in the 1970s proved out the basic concepts and feasibility of streaming media on computers.[citation needed]
During the late 1980s, consumer-grade 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 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.
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.
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 media is ongoing and representative research can be found at the Journal of Multimedia.
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 * 1,048,576 bits = 8,388.608 kilobits)
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 kbit/s) / (8*1024) give around 130 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
This article may require copy editing for grammar, style, cohesion, tone, or spelling. (January 2008) |
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.
- Unicast protocols send a separate copy of the media stream from the server to each client. In terms of difficulty of implementing technically, these protocols are the most simplistic. At the cost of this simplicity, there can be massive duplication of the data being sent on the network.
- Multicast protocols were developed to try to cut down on the duplication that Unicast protocols cause. These protocols send only one copy of the media stream over any given network connection, i.e. along the path between any two network routers. Many of these protocols require special routing hardware capable of broadcasting the stream. These multicasts are one-way connections which very closely mirror the functionality of over the air television in that viewers lose their on-demand viewing abilities. Some of these lost viewing abilities include rewinding and fastforwarding a media file. There exist streaming media servers which combine Unicast and Multicast solutions to both cut down on the bandwidth requirements and provide users most of the on-demand functionality of a pure unicast.[1]
- IP Multicast, the most prominent of multicast protocols, must be implemented in all nodes between server and client including network routers. As of 2005, most routers on the Internet however do not support IP Multicast, and many firewalls block it.[citation needed] IP Multicast is most practical for organizations that run their own networks, such as universities and corporations. Since they buy their own routers and run their own network links, they can decide if the cost and effort of supporting IP Multicast is justified by the resulting bandwidth savings.
- Peer-to-peer (P2P) protocols arrange for media to be sent from clients that already have them to clients that do not. This prevents the server and its network connections from becoming a bottleneck. However, it raises technical, performance, quality, business, and legal issues.
An issue for streaming media is that some firewalls block UDP-based protocols to provide additional security for their owners. These blocks are in place because UDP is stateless and thus makes it difficult for a firewall to determine whether or not to allow the connection.[2]
Widespread deployment of streaming media raises scaling and Quality of Service issues. Testing service deployments is a significant problem. Vendors offer equipment to test streaming services across a number of test domains including Scalability, Quality of Service, Quality of experience, and protocol conformance.[citation needed]
Cost Issues
Although the internet will fundamentally change many industries, the fact remains that streaming large amounts of data (such as video) over IP is still expensive. CDNs (content distribution networks) are companies that provide the infrastructure (servers and pipes) required to reliably deliver data worldwide. As in other industries, the cost (usually priced per gigabyte) is a function of quantity. At the end of 2007, a rather small commitment of 750 GB per month costs about $1.50/GB while a commitment of 100,000 GB per month cost $.30 per GB (USD).
Social and legal issues
Some streaming broadcasters use streaming systems that interfere with the ability to record streams for later playback, either inadvertently, through poor choice of streaming protocols, or deliberately. Some of these broadcasters place these interferences on their media because they believe it is to their advantage to control their copyrighted material or necessary for compliance to licensing requirements by content providers. A concern for some broadcasters is that these copies of broadcasted material will result in lost sales. Whether users have the ability and the right to record streams has become a significant issue in the application of law to cyberspace.
According to some, there is no way to prevent a user from recording a media stream that has been delivered to their computer. Bruce Schneier once said, "Digital files cannot be made uncopyable, any more than water can be made not wet."[3] To date, efforts to prevent copying streaming media has been limited to making it inconvenient, illegal, or both.
One method of interfering in recording streaming media is DRM (Digital Rights Management) technologies. The DRM does not prevent a user from recording the streamed bits but the DRM gives some control of the reproductions or plays of the recorded file to a streaming media provider by requiring a key to unlock or decrypt the content.
Using unpublished data formats is another way for streaming media providers to prevent copying of their media. This security method can be reverse engineered, and encrypted streams must be decrypted with a key that resides on the consumer's computer, so these measures are security through obscurity, at best.
Efforts to make it illegal to record a stream may rely on copyrights, patents,[citation needed] license agreements, or national legislation that implements the anti-circumvention provisions of the WIPO Copyright Treaty.
Notes
- ^ "Chapter 8: Multicasts". Helix Server Administration. Retrieved 2008-01-09.
- ^ Phil Kostenbader. "Standards in desktop firewall policies". SecurityFocus. Retrieved 2008-01-09.
- ^ Bruce Schneier. "The Futility of Digital Copy Prevention". Retrieved 2008-01-09.
References
- Schneier, Bruce (May 15, 2001). The Futility of Digital Copy Prevention Crypto-Gram Newsletter.
- Schneier, Bruce (August 2000). The Fallacy of Trusted Client Software Information Security Magazine . also at The Fallacy of Trusted Client Software.
- Schneier, Bruce (October 15, 2001). SSSCA Crypto-Gram Newsletter.
External links
- streamingmedia.com - Streaming Media Industry News
See also
- Audio Contribution over IP
- Center for Democracy and Technology
- Comparison of streaming media systems
- Content Delivery Network
- Destreaming
- Electronic Frontier Foundation
- Internet radio (audio)
- Internet radio device
- IPTV
- List of codecs
- List of Internet stations
- List of streaming media systems
- P2PTV
- Quality of Service
- Stream recorder
- Voice over IP
- Webcast (video)
- Web TV
- Videoconferencing
- Video clip
- Video commerce
- Video on demand
- Video sharing
Streaming media technologies
Stream and transport protocols
Media container formats
Containers assemble video and audio tracks in a file or data stream. Common examples are AVI, Ogg, QuickTime, RealMedia, ISO MP4 and the Matroska Media Container. Note that old containers, like AVI, are not well suited for streaming.