Streaming media is multimedia that is continuously
received by, and normally displayed to, the end-user whilst 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.
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
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 to make 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 are 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.
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,388.608
(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,388.608 = 128.7 MB of storage
if the file is stored on a server for on-demand streaming. If this stream is
viewed by 1,000 people, you would need
300 kbit/s · 1,000 = 300,000 kbit/s = 300 Mbit/s of bandwidth
This is equivalent to 125.68 GiB per hour.
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,
packets are liable to be lost or corrupted in transit. Depending on the protocol
and the extent of the loss, the client may be able to recover the data with
error correction techniques, may interpolate over the missing data, or 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.
Another issue is that firewalls are more likely to block UDP-based protocols
than TCP-based protocols.
Unicast protocols send a separate copy of the media stream from the server to
each client. This is simple, but can lead to massive duplication of data on the
network. Multicast protocols undertake to send only one copy of the media stream
over any given network connection, i.e. along the path between any two network
routers. This is a more efficient use of network capacity, but it is much more
complex to implement.
Furthermore, the most prominent of multicast protocols, IP Multicast, must be
implemented in the network routers, as well as the servers. As of 2005, most
routers on the Internet however do not support IP Multicast, and many firewalls
block it. 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.
Newer camcorders stream video to a computer over a FireWire connection. This
uses a system of time-based reservations to ensure throughput, and can be
received by multiple clients at once.
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.
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 protocol, or deliberately, because they believe it is to
their advantage to do so. Broadcasters may be concerned that copies will result
in lost sales or that consumers may skip commercials. Whether users have the
ability and the right to record streams has become a significant issue in the
application of law to cyberspace.
In principle, there is no way to prevent a user from recording a media stream
that has been delivered to their computer. Thus, the efforts of broadcasters to
prevent this consist of making it inconvenient, or illegal, or both.
Broadcasters can make it inconvenient to record a stream, for example, by using
unpublished data formats or by encrypting the stream. Of course, data formats
can be reverse engineered, and encrypted streams must be decrypted with a key
that resides—somewhere—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,
license agreements, or—in the United States—the DMCA.
|