Streaming Media Technology

From Computing and Software Wiki

(Difference between revisions)
Jump to: navigation, search
(→Applications)
(→External links)
 
(35 intermediate revisions not shown)
Line 1: Line 1:
-
'''Streaming media''' is multimedia that is constantly received by, and normally displayed to, the end-user while it is being delivered by the provider.[1] Streaming media technolgy enables on-demand or real-time access to multimedia content via internet and allows users to play those contents without fully downloading them. After playing, there's no copy of played contents leaving on the receiving devices, which protects the copyright of the original mutimedia contents.  
+
"'''Streaming media''' is multimedia that is constantly received by, and normally displayed to, the end-user while it is being delivered by the provider."[1] Streaming media technolgy enables on-demand or real-time access to multimedia content via internet and allows users to play those contents without fully downloading them. After playing, there's no copy of played contents leaving on the receiving devices, which protects the copyright of the original mutimedia contents.  
[[Image:Streaming_Media.jpg|thumb|380px|right| Figure 1: Basic Streaming Media Transfer Process [2]]]
[[Image:Streaming_Media.jpg|thumb|380px|right| Figure 1: Basic Streaming Media Transfer Process [2]]]
-
== Introduction ==
+
== Basic Knowledge ==
When the user requests to play a media object that is stored on a remote server, the data blocks are retrieved from the remote server over a network, and passes to the client for display.[3] There are ususaly two ways of doing that. First, the player doesn't play until the media object is completely downloaded on the client. Second, the player can start to play while "streaming" the media as long as enough data has been received - without waiting for the fully downloading, which is so-called the streaming media.  
When the user requests to play a media object that is stored on a remote server, the data blocks are retrieved from the remote server over a network, and passes to the client for display.[3] There are ususaly two ways of doing that. First, the player doesn't play until the media object is completely downloaded on the client. Second, the player can start to play while "streaming" the media as long as enough data has been received - without waiting for the fully downloading, which is so-called the streaming media.  
-
Compared with the way of fully downloading, the way of streaming takes many advantages. First, there's almost no waiting time for downloading. Second, no copies are stored during the process, which protects the copyright and reduces the storage requirement of the client. Third, real-time events becomes possible. However, streaming is always limited by the network conditions. If the speed of the network is very slow, the way of streaming won't work well and some data may lost during the transport process.
+
Compared with the way of fully downloading, the way of streaming takes many advantages. First, there's almost no waiting time for downloading. Second, no copies are stored on the client, which protects the copyright and reduces the storage requirement of the client. Third, real-time events becomes possible. However, streaming is always limited by the network conditions. If the speed of the network is very slow, the way of streaming won't work well and some data may lost during the transport process.
== System Architecture ==
== System Architecture ==
Line 19: Line 19:
-
While a client requests the display of a media object from the server, the server schedules the retrieval of the blocks and delivers these blocks to the buffer of the client via network. The server stages a block of S(say S<sub>i</sub>) from the disk into main memory and delivers it to the buffer of the client. After being received, S<sub>i</sub> is displayed. The server schedules the retrieval and the delivery of S<sub>i+1</sub> before the completion of the display of S<sub>i</sub>. This process is repeated till all blocks of S have been retrieved, delivered and displayed. [3]
+
While a client requests the display of a media object from the server, the server schedules the retrieval of the blocks and delivers these blocks to the client via network. The server stages a block of S(say S<sub>i</sub>) from the disk into main memory and delivers it to the client. After being received, S<sub>i</sub> is displayed. The server schedules the retrieval and the delivery of S<sub>i+1</sub> before the completion of the display of S<sub>i</sub>. This process is repeated till all blocks of S have been retrieved, delivered and displayed. [3]
-
In order to endure the continous display and of object S without any hiccups, block S<sub>i+1</sub> must be available in the buffer of the client before the completion of the display of S<sub>i</sub>. [3]  
+
In order to ensure the continous display and of object S without any hiccups, block S<sub>i+1</sub> must be available in the buffer of the client before the completion of the display of S<sub>i</sub>. [3]  
   
   
Line 39: Line 39:
(since 1 megabyte = 8 * 1,048,576 bits = 8,388.608 kilobits)
(since 1 megabyte = 8 * 1,048,576 bits = 8,388.608 kilobits)
 +
'''Figure 2 '''shows the storage requirements for a 120 minute video clip digitized in different standard encoding formats.
'''Figure 2 '''shows the storage requirements for a 120 minute video clip digitized in different standard encoding formats.
[[Image:Storage.gif || Figure 2: Storage requirements for a 120 minute video clip digitized in different standard encoding formats]]
[[Image:Storage.gif || Figure 2: Storage requirements for a 120 minute video clip digitized in different standard encoding formats]]
 +
=== Bandwidth ===
=== Bandwidth ===
-
If the file is stored on a server for on-demand streaming and this stream is viewed by 100 people at the same time using a unicast protocol, you would need:
+
If the file is stored on a server for on-demand streaming and this stream is viewed by 100 people at the same time using a [http://en.wikipedia.org/wiki/Unicast Unicast] protocol, you would need:
250 kbit/s · 100 = 25,000 kbit/s = 25 Mbit/s of bandwidth  
250 kbit/s · 100 = 25,000 kbit/s = 25 Mbit/s of bandwidth  
-
While using a multicast protocol(which is commonly used), such a stream only need a 250 Kbit/s bandwidth. In order to play a streaming media object with no hanging, the bandwidth must be greater than or equal to the bit rate of the streaming meida. object.
+
While using a [http://en.wikipedia.org/wiki/Multicast Multicast] protocol(which is commonly used), such a stream only need a 250 Kbit/s bandwidth. In order to play a streaming media object with no hanging, the bandwidth must be greater than or equal to the bit rate of the streaming meida object.
== Data Compression ==
== Data Compression ==
 +
 +
A 120 minute uncompressed video clip digitized in HDTV format at 1.2 Gb/s requires 1055 Gbyte of storage as shown in the previous section. Although modern storage devices can provide larger capacities, it's not economical to store streaming media object uncompressed(even temporarily). Although the network speeds are increasing, it is not economically feasible to handle the display of a large number of streaming media objects over existing networks. To solve these problem, we need to compress these objects, where a smaller streaming media object requires less storage and less network bandwidth. [3]
=== Run-length encoding ===
=== Run-length encoding ===
 +
 +
'''Run-length encoding''' is one of the simplest data compression techniques. It replaces continously occurrences of a symbol with the combination of the number of times it occurs and the symbol itself.
 +
 +
For example, the string
 +
 +
LLLOOOOOOOVVEEEEEEEEEE
 +
 +
can be compressed as
 +
 +
3L7O2V10E
 +
 +
The run-length code represents the original 22 characters in only 9.
 +
 +
This compression techinque is most useful when symbols occur in long runs but doesn't work well if most adjacent symbols are different.
=== Relative encoding ===
=== Relative encoding ===
 +
 +
'''Relative encoding''' is also a simple data compressin techique. It replaces the actual value of an object O with the relative difference between O and the object before O.
 +
 +
For example, the series of pixel values
 +
 +
"50 130 257 135 70"
 +
 +
can be compressed as
 +
 +
"50+80+127-122-65"
 +
 +
In this example, the original values require 8 bits to represent while the difference requires only 7 bits to represent.
 +
 +
This compression techinque is most useful when adjacent objects are not greatly changing.
=== Huffman encoding ===
=== Huffman encoding ===
-
=== Transform encoding ===
+
"'''Huffman encoding''' is a very popular compression technique that assigns variable length codes to symbols, so that the most frequently occurring symbols have the shortest codes." [3]
-
To be filled
+
For example, if we want to encode a source of 5 symbols: a,b,c,d,e and the probabilities of these symbols are
 +
 
 +
P(a)=0.15, P(b)=0.17, P(c)= 0.25, P(d)= 0.20, p(e) =0.23, where P(a)+P(b)+P(c)+P(d)+P(e) = 1.
 +
 
 +
We represent a as 000, b as 001, c as 10, d as 01, e as 11 by using Huffman. The average length of the symbols is:
 +
 
 +
0.15*3 + 0.17*3 + 0.25*2 + 0.20*2 +0.23*2 = 2.32
 +
 
 +
Without using Huffman, we need 3 bit length to represent 5 symbols.
 +
 
 +
The Huffman encoding is very useful and not that simple as I described above. You can go to external links to find more about it.
== Network Protocols ==
== Network Protocols ==
 +
 +
The Internet is not naturally suitable for real-time traffic since the shared datagram property. Moreover, Internet Protocol (IP) has some fundamental problems in transmitting real-time data. Therefore, some more protocols are developed to support the quality of service(Qos) for streaming media applications.[3]
=== RTP ===
=== RTP ===
 +
 +
'''The Real-time Transport Protocol(RTP)''' is a transport protocol for delivering audio, video and other real-time applications over the internet. RTP use timestamping, sequence numbering, and other mechanisms to provide end to end transport for real-time applications over the datagram network.[3] The information is stored in the header of a RTP packet.
 +
 +
The RTP header size is 96 bits.
 +
 +
'''0-1''' indicate the version of the protocol.
 +
 +
'''2''' indicates if there are extra padding bytes at the end of the RTP packet.
 +
 +
'''3''' indicates if the externsion header is used.
 +
 +
'''4-7 '''indicate the number of source identifiers.
 +
 +
'''8''' is used as the application level to indicate if the data carrying have relevance with the application.
 +
 +
'''9-15 '''indicate the payload format as well as encoding method.
 +
 +
'''16-31''' are used to determine the correct order of packets(Sequence numbering).
 +
 +
'''32-63''' are timestamping which will be used by the receiver to reconstruct the original timing(Timestamping).
 +
 +
'''64-95''' indicate the synchronization source.
=== RTCP ===
=== RTCP ===
-
=== RTSP ===
+
'''Real-time Transport Control Protocol(RTCP)''' is the control protocol designed to work with RTP because RTP doesn't have error correction or flow control functionality.
-
=== RSVP ===
+
There are several types of RTCP packets:
 +
 
 +
''Receiver report packet'' contains quality feedback about the data delivery.
 +
 
 +
''Sender report packet'' contains a sender information section.
 +
 
 +
''Source description packet'' contains the information of sources.
 +
 
 +
''Application specific packet'' contains the experiment of new applications and new features.
 +
 
 +
By using these packets, RTCP can monitor the QoS, identify the source , synchronize  inter media and scale control information. [3]
 +
 
 +
=== RTSP ===
-
To be filled
+
'''Real Time Streaming Protocol(RTSP)''' is a client-server presentation protocol which allows client to remotely control a streaming media server to run some commands, such as play, fast-forward, fast-rewind, pause and stop. RTSP doesn't provide a way to transport data via internet, so it's always use RTP as its transport protocol.
== Applications ==  
== Applications ==  
Line 108: Line 186:
[4] Rosolak, Misha, "BuzzWords - Streaming Media", Software Engineering 3I03, McMaster University, Fall 2007.
[4] Rosolak, Misha, "BuzzWords - Streaming Media", Software Engineering 3I03, McMaster University, Fall 2007.
 +
 +
[5] Lee, Jack, ''Scalable Continuous Media Streaming System'', John Wiley & Sons Ltd, 2005
== See also ==
== See also ==
 +
*[[ ADSL]]
 +
*[[ Bandwidth Throttling ]]
*[[ Peer To Peer Network Security ]]
*[[ Peer To Peer Network Security ]]
 +
*[[ Secure Electronic Transaction (SET) Protocol]]
 +
*[[ TCP/IP Application Development ]]
 +
*[[ Web content filtering ]]
== External links ==
== External links ==
Line 117: Line 202:
* [http://en.wikipedia.org/wiki/Streaming_Media Streaming Media] - Streaming Media Wiki Page
* [http://en.wikipedia.org/wiki/Streaming_Media Streaming Media] - Streaming Media Wiki Page
* [http://en.wikipedia.org/wiki/TCP/IP_model TCP/IP_model] - Protocols on the Five-layer TCP/IP Model
* [http://en.wikipedia.org/wiki/TCP/IP_model TCP/IP_model] - Protocols on the Five-layer TCP/IP Model
 +
* [http://en.wikipedia.org/wiki/Huffman_encoding Huffman Encoding] - Huffman Encodeing Wiki Page
-
--[[User:Chuh|Chuh]] 15:58, 7 April 2008 (EDT)
+
--[[User:Chuh|Chuh]] 08:51, 12 April 2008 (EDT)

Current revision as of 12:51, 12 April 2008

"Streaming media is multimedia that is constantly received by, and normally displayed to, the end-user while it is being delivered by the provider."[1] Streaming media technolgy enables on-demand or real-time access to multimedia content via internet and allows users to play those contents without fully downloading them. After playing, there's no copy of played contents leaving on the receiving devices, which protects the copyright of the original mutimedia contents.

Figure 1: Basic Streaming Media Transfer Process [2]

Contents

Basic Knowledge

When the user requests to play a media object that is stored on a remote server, the data blocks are retrieved from the remote server over a network, and passes to the client for display.[3] There are ususaly two ways of doing that. First, the player doesn't play until the media object is completely downloaded on the client. Second, the player can start to play while "streaming" the media as long as enough data has been received - without waiting for the fully downloading, which is so-called the streaming media.

Compared with the way of fully downloading, the way of streaming takes many advantages. First, there's almost no waiting time for downloading. Second, no copies are stored on the client, which protects the copyright and reduces the storage requirement of the client. Third, real-time events becomes possible. However, streaming is always limited by the network conditions. If the speed of the network is very slow, the way of streaming won't work well and some data may lost during the transport process.

System Architecture

Assume a streaming media object S that contains n equal size blocks: S0, S1, ..., Sn-1, and is stored on a streaming media server. There are three important time variable needed to mention:

  • The retrieval time of each block is a function of the transfer rate of the server.
  • The delivery time of each block from the server to the client is a function of the network speed, traffic, and protocol used.
  • The display time of each block is a function of the display requirments of each object and the size of the block. For example, if the display requirement of the object S is 3 Mb/s and the size of each block, Si, is 3 Mbytes, then the display time of each block is 8 seconds. [3]


While a client requests the display of a media object from the server, the server schedules the retrieval of the blocks and delivers these blocks to the client via network. The server stages a block of S(say Si) from the disk into main memory and delivers it to the client. After being received, Si is displayed. The server schedules the retrieval and the delivery of Si+1 before the completion of the display of Si. This process is repeated till all blocks of S have been retrieved, delivered and displayed. [3]

In order to ensure the continous display and of object S without any hiccups, block Si+1 must be available in the buffer of the client before the completion of the display of Si. [3]


P.S.: The architecture described here is entirely learned and paraphrased from the book Streaming Media Server Design, which is listed as reference [3].

Storage and Bandwidth

Storage

Streaming media storage size is a funtion of bit rate and length:

SIZE (Kbit) = BIT RATE (Kbit/s) * LENGTH (s).

Becuause the result is usually a very large number, people always use Mbyte to describe the size of the storage.

SIZE (Mbyte) = BIT RATE (Kbit/s) * LENGTH (s)/ 8,388.608

(since 1 megabyte = 8 * 1,048,576 bits = 8,388.608 kilobits)


Figure 2 shows the storage requirements for a 120 minute video clip digitized in different standard encoding formats.

Figure 2: Storage requirements for a 120 minute video clip digitized in different standard encoding formats


Bandwidth

If the file is stored on a server for on-demand streaming and this stream is viewed by 100 people at the same time using a Unicast protocol, you would need:

250 kbit/s · 100 = 25,000 kbit/s = 25 Mbit/s of bandwidth

While using a Multicast protocol(which is commonly used), such a stream only need a 250 Kbit/s bandwidth. In order to play a streaming media object with no hanging, the bandwidth must be greater than or equal to the bit rate of the streaming meida object.

Data Compression

A 120 minute uncompressed video clip digitized in HDTV format at 1.2 Gb/s requires 1055 Gbyte of storage as shown in the previous section. Although modern storage devices can provide larger capacities, it's not economical to store streaming media object uncompressed(even temporarily). Although the network speeds are increasing, it is not economically feasible to handle the display of a large number of streaming media objects over existing networks. To solve these problem, we need to compress these objects, where a smaller streaming media object requires less storage and less network bandwidth. [3]

Run-length encoding

Run-length encoding is one of the simplest data compression techniques. It replaces continously occurrences of a symbol with the combination of the number of times it occurs and the symbol itself.

For example, the string

LLLOOOOOOOVVEEEEEEEEEE

can be compressed as

3L7O2V10E

The run-length code represents the original 22 characters in only 9.

This compression techinque is most useful when symbols occur in long runs but doesn't work well if most adjacent symbols are different.

Relative encoding

Relative encoding is also a simple data compressin techique. It replaces the actual value of an object O with the relative difference between O and the object before O.

For example, the series of pixel values

"50 130 257 135 70"

can be compressed as

"50+80+127-122-65"

In this example, the original values require 8 bits to represent while the difference requires only 7 bits to represent.

This compression techinque is most useful when adjacent objects are not greatly changing.

Huffman encoding

"Huffman encoding is a very popular compression technique that assigns variable length codes to symbols, so that the most frequently occurring symbols have the shortest codes." [3]

For example, if we want to encode a source of 5 symbols: a,b,c,d,e and the probabilities of these symbols are

P(a)=0.15, P(b)=0.17, P(c)= 0.25, P(d)= 0.20, p(e) =0.23, where P(a)+P(b)+P(c)+P(d)+P(e) = 1.

We represent a as 000, b as 001, c as 10, d as 01, e as 11 by using Huffman. The average length of the symbols is:

0.15*3 + 0.17*3 + 0.25*2 + 0.20*2 +0.23*2 = 2.32

Without using Huffman, we need 3 bit length to represent 5 symbols.

The Huffman encoding is very useful and not that simple as I described above. You can go to external links to find more about it.

Network Protocols

The Internet is not naturally suitable for real-time traffic since the shared datagram property. Moreover, Internet Protocol (IP) has some fundamental problems in transmitting real-time data. Therefore, some more protocols are developed to support the quality of service(Qos) for streaming media applications.[3]

RTP

The Real-time Transport Protocol(RTP) is a transport protocol for delivering audio, video and other real-time applications over the internet. RTP use timestamping, sequence numbering, and other mechanisms to provide end to end transport for real-time applications over the datagram network.[3] The information is stored in the header of a RTP packet.

The RTP header size is 96 bits.

0-1 indicate the version of the protocol.

2 indicates if there are extra padding bytes at the end of the RTP packet.

3 indicates if the externsion header is used.

4-7 indicate the number of source identifiers.

8 is used as the application level to indicate if the data carrying have relevance with the application.

9-15 indicate the payload format as well as encoding method.

16-31 are used to determine the correct order of packets(Sequence numbering).

32-63 are timestamping which will be used by the receiver to reconstruct the original timing(Timestamping).

64-95 indicate the synchronization source.

RTCP

Real-time Transport Control Protocol(RTCP) is the control protocol designed to work with RTP because RTP doesn't have error correction or flow control functionality.

There are several types of RTCP packets:

Receiver report packet contains quality feedback about the data delivery.

Sender report packet contains a sender information section.

Source description packet contains the information of sources.

Application specific packet contains the experiment of new applications and new features.

By using these packets, RTCP can monitor the QoS, identify the source , synchronize inter media and scale control information. [3]

RTSP

Real Time Streaming Protocol(RTSP) is a client-server presentation protocol which allows client to remotely control a streaming media server to run some commands, such as play, fast-forward, fast-rewind, pause and stop. RTSP doesn't provide a way to transport data via internet, so it's always use RTP as its transport protocol.

Applications

Figure 3: Streaming Media Applications [4]

There are two main forms of streaming media:[4]

  • On Demand: Typicllay requires the downloading of the media for short-term use and allows users to fast forward, pause, and rewind all media as they please.
  • Video Conferencing: Real-time streaming meant for use as it happens and typically is only available when live.


There are five applications which are very popular now.[4]

  • YouTube: Most similar to On Demand as users can download and access media at convenience. However, it's not true On Demand because users let content stream temporarily.
  • Webcasting: Most similar to Video Conferencing as it's typically broadcast over the internet at a certain time and users typically cannot choose exactly what they want to watch. However, it's not true Video Conferencing because material can be prepared beforehand even if it's presented as live.
  • RealPlayer: Functionally similar to YouTube but requires a platform to run it(with a built in explorer).
  • Quicktime: Similar to ASF but with more potential for pause/fast-forward/rewind control.
  • *.asf: A Windows Media format that combines the non-controllable streaming with the potential for On Demand access, but it requires a certain platform to run.

References

[1] Wikipedia, "Streaming Media", April 2008, "http://en.wikipedia.org/wiki/Streaming_media" .

[2] Sequence website, "http://www.sequence.co.uk/services/streamingmedia/howdoesitwork.html" .

[3] Dashti, Ali E.,Streaming Media Server Design, Prentice Hall, 2003

[4] Rosolak, Misha, "BuzzWords - Streaming Media", Software Engineering 3I03, McMaster University, Fall 2007.

[5] Lee, Jack, Scalable Continuous Media Streaming System, John Wiley & Sons Ltd, 2005

See also

External links


--Chuh 08:51, 12 April 2008 (EDT)

Retrieved from "http://wiki.cas.mcmaster.ca/index.php/Streaming_Media_Technology"
Personal tools