Streaming media

By

G.Susmitha

CVR COLLEGE OF ENGINEERING

1
Table of contents

Abstract 3

History 4-5

Streaming bandwidth and storage 6-7

Codec, bitstream, transport, controle 8

Protocol issues 9-11

Conclusion 12

2
Abstract

Streaming media is multimedia that is constantly received by and presented to an end-

user while being delivered by a streaming 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. Internet television is a commonly streamed medium.

Live streaming, more specifically, means taking the video and broadcasting it live over
the Internet. The process involves a camera for the video, an encoder to digitize the content, a
video publisher where the streams are made available to potential end-users and a content
delivery network to distribute and deliver the content. The media can then be viewed by end-
users live.

Security remains one of the main challenges with this new methodology. However, Digital rights
management (DRM) systems are the best way to keep the content secure.

3
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 related to streaming were:

• having enough CPU power and bus bandwidth to support the required data
rates
• creating low-latency interrupt paths in the operating system (OS) to prevent
buffer underrun.

However, computer networks were still limited, and media was usually delivered over non-
streaming channels, such as by downloading a digital file from a remote server and then saving it
to a local drive on the end user's computer or storing it as a digital file and playing it back from
CD-ROMs.

During 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 emerged to offer listeners a no-computer option for listening to
audio streams.

4
In general, multimedia content has a large volume, so media storage and transmission costs are
still significant; to offset this somewhat, media are generally compressed for both storage and
streaming.

Increasing consumer demand for streaming of high definition (HD) content to different devices
in the home has led the industry to develop a number of technologies, such as Wireless HD or
ITU-T G.hn, which are optimized for streaming HD content without forcing the user to install
new networking cables.

Increasing consumer demand for live streaming has prompted YouTube to implement their new
Live Streaming service to users.

A media stream can be streamed either by live or on demand. Live streams are generally
provided by a means called true streaming. True streaming sends the information straight to the
computer or device without saving the file to a hard disk. On Demand streaming is provided by a
means called progressive streaming or progressive download. Progressive streaming saves the
file to a hard disk and then is played from that location. On Demand streams are often saved to
hard disks and servers for extended amounts of time; while the live streams are only available at
one time only (e.g. during the Football game).

5
Streaming bandwidth and storage

Streaming media storage size is calculated from the streaming bandwidth and length of the media
using the following formula (for a single user and file):

storage size (in mebibytes) = length (in seconds) × bit rate (in bit/s) / (8 × 1024 × 1024)

note: 1 mebibyte = 8 × 1024 × 1024 bits.

Real world example:

One hour of video encoded at 300 kbit/s (this is a typical broadband video as of 2005 and it is
usually encoded in a 320 × 240 pixels window size) will be:

6
 (3,600 s × 300,000 bit/s) / (8×1024×1024) requires around 128 MiB 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, the requirement is:

300 kbit/s × 1,000 = 300,000 kbit/s = 300 Mbit/s of bandwidth

This is equivalent to around 135 GB 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.

The calculation for Live streaming is similar.

Assumptions: speed at the encoder, is 500kbps.

If the show last for 3 hours, with 3000 viewers then the calculation is :

Number of MB transferred = encoder speed (in kbps) × number of seconds ×

( number of viewer / (8 × 1024))

Number of MB transferred = 500 (kbps) × 3 × 3600 ( = 3 hours) × 3000 (nbr of viewers) /

(8 × 1024) = 1977539 MB

7
Codec, bitstream, transport, controle

 Audio stream is compressed using audio codec such as VMV9 or MPEG4.

 Video stream is compressed using video codec such as WMA or AAC.
 Audio and video encoded streams are assembled in a container bitstream such as ASF or
ISMA.
 The bitstream is delivered from a streaming server to streaming client using a transport
protocol, such as MMS or RTP.
 The streaming client may interact with the streaming server using a contrôle protocole,
such as MMS or RTSP

8
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. RTSP runs over a variety of transport protocols, while the latter two are
built on top of UDP.
• Another approach that seems to incorporate both the advantages of using a standard web
protocol and the ability to be used for streaming even live content is the HTTP adaptive
9
 bitrate streaming. HTTP adaptive bitrate streaming is based on HTTP progressive
download, but contrary to the previous approach, here the files are very small, so that
they can be compared to the streaming of packets, much like the case of using RTSP and
RTP.
• 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 this effect
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
experience a loss of fidelity if the delay that buffering contributes to exceeds 200 ms.
• 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.

Multicasting broadcasts the same copy of the multimedia over the entire network to a group of
clients

• Multicast protocols were developed to reduce the data replication (and consequent
server/network loads) that occurs 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. A multicast protocol, usually Internet Group Management Protocol, is
used to manage delivery of multicast streams to the groups of recipients on a LAN. One
10
 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
Protocol Independent Multicast can be used to deliver stream content to multiple Local
Area Network 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, and business issues.

11
Conclusion

Streaming media is not only innovative one but also a necessary tool for current
generation communications . still there is a need of efficient utilization of bandwidth in this
domain .

12