Streaming Media

Joost (pronounced /j oo?st/ “Juiced”) is a system for distributing TV shows and other forms of video over the Web using peer-to-peer TV technology, created by Niklas Zennström and Janus Friis (founders of Skype and Kazaa).Joost began development in 2006. Working under the code name “The Venice Project”, Zennström and Friis assembled teams of some 150 software developers in about six cities around the world, including New York, London, Leiden and Toulouse. According to Zennström at a 25 July 2007 press conference about Skype held in Tallinn, Estonia, Joost has signed up more than a million beta testers and is on track for an end-of-year launch.The teams are currently in negotiations with FOX networks. It has signed up with Warner Music, Indianapolis Motor Speedway Productions (Indianapolis 500, IndyCar Series) and production company Endemol for the betaIn February 2007, Viacom entered into a deal with the company to distribute content from its media properties, including MTV Networks, BET and film studio Paramount Pictures.

* Streaming of high quality audio over IP networks is being increasingly used by broadcasters and others to provide high-quality audio contribution feeds (for example to provide audio links between a sports venue or concert hall and the broadcaster’s studios)
* Audio quality and delay (on duplex transmissions) are key issues for contribution links.
* In the past these links have made widespread use of ISDN services but these are becoming increasingly difficult or expensive to obtain in some parts of Europe and are being phased out in others

User Datagram Protocol (UDP) is one of the core protocols of the Internet protocol suite. Using UDP, programs on networked computers can send short messages sometimes known as datagrams (using Datagram Sockets) to one another. UDP is sometimes called the Universal Datagram Protocol. It was designed by David P. Reed in 1980.UDP does not guarantee reliability or ordering in the way that TCP does. Datagrams may arrive out of order, appear duplicated, or go missing without notice. Avoiding the overhead of checking whether every packet actually arrived makes UDP faster and more efficient, at least for applications that do not need guaranteed delivery. Time-sensitive applications often use UDP because dropped packets are preferable to delayed packets. UDP’s stateless nature is also useful for servers that answer small queries from huge numbers of clients. Unlike TCP, UDP is compatible with packet broadcast (sending to all on local network) and multicasting (send to all subscribers).

Common network applications that use UDP include: the Domain Name System (DNS), streaming media applications such as IPTV, Voice over IP (VoIP), Trivial File Transfer Protocol (TFTP) and online games.

IPTV (IP Television) is a system where a digital television service is delivered by using Internet Protocol over a network infrastructure, which may include delivery by a broadband connection. A general definition of IPTV is television content that, instead of being delivered through traditional broadcast and cable formats, is received by the viewer through the technologies used for computer networks.For residential users, IPTV is often provided in conjunction with Video on Demand and may be bundled with Internet services such as Web access and VoIP. The commercial bundling of IPTV, VoIP and Internet access is referred to as “Triple Play” service (adding mobility is called “Quadruple Play”). IPTV is typically supplied by a service provider using a closed network infrastructure. This closed network approach is in competition with the delivery of TV content over the public Internet, called Internet Television. In businesses, IPTV may be used to deliver television content over corporate LANs.

The Real-time Transport Protocol (or RTP) defines a standardized packet format for delivering audio and video over the Internet. It was developed by the Audio-Video Transport Working Group of the IETF and first published in 1996 as RFC 1889 which was made obsolete in 2003 by RFC 3550. Real time transport protocol can also be used in conjunction with RSVP protocol which enhances the field of multimedia applications.

RTP does not have a standard TCP or UDP port on which it communicates. The only standard that it obeys is that UDP communications are done via an even port and the next higher odd port is used for RTP Control Protocol (RTCP) communications. Although there are no standards assigned, RTP is generally configured to use ports 16384-32767. RTP can carry any data with real-time characteristics, such as interactive audio and video. Call setup and tear-down for VoIP applications is usually performed by either SIP or H.323 protocols. The fact that RTP uses a dynamic port range makes it difficult for it to traverse firewalls. In order to get around this problem, it is often necessary to set up a STUN server.

It was originally designed as a multicast protocol, but has since been applied in many unicast applications. It is frequently used in streaming media systems (in conjunction with RTSP) as well as videoconferencing and push to talk systems (in conjunction with H.323 or SIP), making it the technical foundation of the Voice over IP industry. It goes along with the RTCP and is built on top of the User Datagram Protocol (UDP). Applications using RTP are less sensitive to packet loss, but typically very sensitive to delays, so UDP is a better choice than TCP for such applications.

According to RFC 1889, the services provided by RTP include:

* Payload-type identification - Indication of what kind of content is being carried
* Sequence numbering - PDU sequence number
* Time stamping - allow synchronization and jitter calculations
* Delivery monitoring

The protocols themselves do not provide mechanisms to ensure timely delivery. They also do not give any Quality of Service (QoS) guarantees. These things have to be provided by some other mechanism.

Also, out of order delivery is still possible, and flow and congestion control are not supported directly. However, the protocols do deliver the necessary data to the application to make sure it can put the received packets in the correct order. Also, RTCP provides information about reception quality which the application can use to make local adjustments. For example if a congestion is forming, the application could decide to lower the data rate.

RTP was also published by the ITU-T as H.225.0, but later removed once the IETF had a stable standards-track RFC published. It exists as an Internet Standard (STD 64) defined in RFC 3550 (which obsoletes RFC 1889). RFC 3551 (STD 65) (which obsoletes RFC 1890) defines a specific profile for Audio and Video Conferences with Minimal Control. RFC 3711 defines the Secure Real-time Transport Protocol (SRTP) profile (actually an extension to RTP Profile for Audio and Video Conferences) which can be used (optionally) to provide confidentiality, message authentication, and replay protection for audio and video streams being delivered.

The Real Time Streaming Protocol (RTSP), developed by the IETF and created in 1998 as RFC 2326, is a protocol for use in streaming media systems which allows a client to remotely control a streaming media server, issuing VCR-like commands such as “play” and “pause”, and allowing time-based access to files on a server.The sending of streaming data itself is not part of the RTSP protocol. Most RTSP servers use the standards-based RTP as the transport protocol for the actual audio/video data, acting somewhat as a metadata channel. The RTSP server from RealNetworks also features Real’s proprietary RDT as the transport protocol.The protocol is similar in syntax and operation to HTTP but RTSP adds new requests. While HTTP is stateless, RTSP is a stateful protocol. A session ID is used to keep track of sessions when needed. This way, no permanent TCP connection is needed. RTSP messages are sent from client to server, although some exceptions exist where the server will send to the client. Below are the basic RTSP requests. A number of typical HTTP requests, like an OPTION request, are also frequently used.

Microsoft Media Services was Microsoft’s proprietary network streaming protocol used to transfer unicast data in Windows Media Services (previously called NetShow Services). MMS can be transported via UDP or TCP. The MMS default port is UDP/TCP 1755.

Microsoft deprecated MMS in favor of RTSP in 2003 with the release of the Windows Media Services 9 Series, but continued to support the MMS for some time in the interest of backwards compatibility. Support for the protocol was finally dropped in Windows Media Services 2008.

Note however that Microsoft still recommends using “mms://” as a “protocol rollover URL”. As part of protocol rollover a Windows Media Player 11 client opening an “mms://” URL will attempt to connect first with RTSP over UDP and if that fails it will attempt RTSP over TCP. Earlier Windows Media Player clients as well as version 11 after having failed RTSP will attempt MMS over UDP, then MMS over TCP. If MMS fails a modified version of a HTTP over TCP connection will be attempted, this modified version is also referred to as MMSH

Softwares which support MMS

• Windows Media Player
• Winamp
• mplayer

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 intellectual property 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.” 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 protection 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 / decrypt the content.

Using unpublished data formats is another way for streaming media providers to protect 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, license agreements, or national legislation that implements the anti-circumvention provisions of the WIPO Copyright Treaty.

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. CDN’s (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).

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*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.