Streaming - A Practical Guide to Video and Audio Compression - page 347

correction built in that an occasional lost packet can be handled without the viewing expe-
rience being severely compromised.

20.4.1 HTTP

HTTP was originally designed for the delivery of Web pages, and those comprised a mix-
ture of text-based HTMP, CSS, and other varieties of marked-up content and code. Various
binary formats containing images, executable code objects, and other assets that help cre-
ate the human readable page are also delivered using HTTP.
The technique known as progressive downloading was developed in the mid-1990s.
It allows the HTTP connection to remain open, and the client continues to process the
stream incrementally as it arrives. This seemed to work for delivering audio and video
content, but because it was designed to operate on top of TCP, the delivery is not ideal for
real-time live broadcasting. Progressive downloading works reasonably well for deliver-
ing movie trailers or other short clips, since these are being sourced from a previously
encoded file and the client is simply electing to begin playing the content before it is fully
delivered.

20.4.2 RTSP

Early implementations of streaming servers and clients used RTP, but this has been super-
seded by RTSP. RTSP is an application-level protocol to control the delivery of data in real
time. The protocol is designed for on-demand delivery of real-time data, such as audio
and video. This includes live data feeds or stored clips. Multiple, simultaneous data-
delivery sessions are also supported.
RTSP is better than HTTP when long-form content is being delivered. Capturing
streaming protocols to disk is not usually possible in consumer-oriented applications
unless the broadcaster allows it, and even then the facilities are not obvious to an
untrained user—so the consumer is less able to capture and retain a copy of the content
than if a downloadable file based protocol were used. This is seen as a benefit from the
content provider's perspective. Capturing RTSP sessions is not overly difficult if you
know how, but it requires a solution that is beyond the average consumer user's technical
capabilities to deploy. So casual copying is less likely with RTSP than it would be with
HTTP. Relying on RTSP isn't a bad approach to security, but a properly developed DRM
policy would be better.
Refer to RFC 2326 for full technical details of RTSP and to RFC 1889 for details of RTP.
RFC documents are mirrored in many locations on the web. The most authoritative source
is the Internet Engineering Task Force ( IETF ). Other sources can be located via Google.
Additional information about RTSP is also available at the Real Networks web site.

Real Networks: http://www.real.com/technology/rtsp/index.html
IETF Org: http://www.ietf.org/
FAQs Org: http://www.faqs.org/rfcs/
RFC Archive: http://www.rfc-archive.org/