Flow With The Stream

What Is Streaming Media? To understand the role of streaming
media, one needs to understand the functioning of the World Wide Web. Web
servers are often described as "stateless." What that basically means
is that the web server takes a request for information, pushes that information
out the door as fast as it can, completes the transaction, disconnects and goes
on to other requests by other users. On the client side, your Web browser takes
the information it receives, assembles it on the screen, and then ignores the
Web server until you click on a link. This stateless approach works very well
for media like graphics and text. Feed them into the browser and simply slap
them on the screen. However, moving images and sound are problematic. Unlike a
graphic, video, animation and sound have a time element to them. With the time
dimension, often comes a larger file size. Under the stateless approach, a Web
user would need to download the entire video clip before it can be viewed and
with the large file size that comes with even a short video clip, the wait
becomes unbearable.

With streaming media, the goal is to bypass the limitations
of the World Wide Web. So, rather than a stateless data connection, streaming
media is more of a continuous connection. There is a commitment there. Much like
TV or listening to the radio, you receive the images or audio just before you
see or hear them. Spaced out over time, the file size of the clip becomes less
of an issue. The reality is that raw file sizes for digital audio and video are
absolutely huge. So, to get them down to a size that works for a modem or LAN,
compression is used. The goal of streaming compression is to throw away data
that you don’t need. That makes the file size much smaller. Streaming audio
also makes it possible to broadcast live or pre-recorded music over the Internet
on a continuous basis. Internet "radio stations" can broadcast to a
worldwide audience.

Prior to streaming, a typical video file (*.avi) was
completely downloaded from the Internet before it could be played. With
streaming, only the first few seconds are downloaded (buffered) before the video
begins to play. As the streaming file is being viewed, it is also downloading in
the background.

Basic Concepts

Encoding

In the case of streaming media, encoding refers to the compression of media
files into a streaming format. Encoding is the process whereby media files are
prepared for streaming over the Internet.

On-demand encoding

Encoding from a file is as easy as pointing to the source file, setting a
name for the destination file, picking audio and video codecs, choosing the bit
rate, and clicking start. Most encoding software carry built-in wizard templates
to make the job even easier; simply pick the template describing the target
audience and the codecs and bit rates are automatically defined.

Live encoding

Live encoding is a little trickier than on-demand because the input to the
encoder comes from audio and video capture cards within the encoding computer.

Codec (compression/decompression)

Codecs are mathematical algorithms that allow media files to squeeze into a
smaller streaming format for decoding by the end-user’s player. Encoding
software uses codecs for compressing the file while decompression occurs during
the viewing process on the end user’s computer. The process is similar to
zipping and unzipping a file on a PC. Standard encoding software such as
Microsoft Encoder and Real Publisher encode locally stored content as well as
live feeds and inputs.

Multibitrate Codecs

Multibitrate codecs allow several streams of different bit rates to be bundled
into one file. The streaming server then communicates with the end user’s
media player to determine the optimum speed for delivery.

Key Products

The three most popular streaming-video products are Apple’s
QuickTime 4 (which has been integrated into the MacOS but which can also be
downloaded separately), Microsoft Windows Media 7 (which has been integrated
into Windows but which can also be downloaded separately), and RealNetworks’
RealVideo 8 (which runs on the company’s RealPlayer). The basic clients are
free, although Apple and RealNetworks also sell enhanced clients. Microsoft also
sells NetShow Theater Server, a high-end product that delivers full-screen,
broadcast-quality video over high-bandwidth networks. NetShow is primarily
designed for use over high-speed LANs and intranets, and its content can be run
on a standard Windows Media player. Users can access small-screen, lower quality
video from all three streaming-video products, with 56-Kbps and even slower
modems. However, users who want high-quality video must be able to access the
Internet at 500 Kbps for RealVideo 8,700 Kbps for QuickTime, 720 Kbps for
Windows Media 7, and up to 8 Mbps for NetShow. The difference in access
requirements is based on the products’ different codec algorithms.

Platform Support

The QuickTime streaming server supports the FreeBSD, Linux,
MacOS, Solaris, and Windows operating systems. The RealVideo server supports the
Linux, Solaris, and Windows operating systems. Both technologies’ clients
support all major platforms. The Windows Media server runs only on Windows,
while the client supports only the Macintosh and Windows platforms.

Advantage - QuickTime

QuickTime is the oldest of the online video technologies.
According to Frank Casanova, Apple’s director of QuickTime product marketing,
the product is supported by more applications, including Microsoft World and
Excel, than competing technologies.

Advantage - Windows Media

One advantage of Windows Media is that it is integrated with
other Windows based technologies. This makes it simpler to implement and utilize
for some Windows users, especially those without significant technical
experience. Windows Media also includes digital-rights management technology,
which protects the content providers’ intellectual property. The technology
lets content owners prevent recipients from distributing material without the
author’s permission.

Content producers are concerned about unauthorized
distribution of their material. Therefore, streaming media companies want to
convince producers that it’s safe to provide quality content for Windows
Media.

Advantage - Real Video

An advantage of RealVideo is that content providers can
encode files so that clients can access them at different speeds.

The client can then select the best access rate based on the
available bandwidth.

Streaming Media with Windows 2000 Server

A new component in Win 2000 Server Windows Media Services
allows you to stream media files on your Network.

Setting up a streaming server

Streaming can be done either as Unicast or Multicast. The
difference lies in how the streaming data is sent to clients. In Unicast
streaming, data is sent through a point-to-point connection between the client
and the server. Each client receives a separate, distinct stream from the
streaming server. Thus, the stream is demand-based, that is, it is sent out only
if requested by a client.

On the other hand, in multicast streaming, a single stream of
data is transmitted over the network, and all clients connect to this single
stream. The benefit of this is that it saves network bandwidth.

Streamable Data

Windows Media Services can stream all popular data formats.
However, some formats like AVI and WAV need to be encoded into another format
called Advanced Streaming Format (ASF) before they can be streamed. Consider ASF
as a "ready-to-be-streamed" format. You can either convert files to
ASF format using an encoding software like Microsoft Netshow, or encode them on
the fly with Windows Media Services and stream them. MP3 files don’t need to
be encoded before streaming.

Streaming and Receiving the Streams

Windows Media Services starts up like all other Win 2K
services. To configure streaming, three parameters have to be taken into
account: source, protocol and the publishing method. The first tells you the
type of data to be streamed, the second one is the choice of protocol that will
carry this stream, and the third involves how you would present the data to a
user. This could be as an HTM file, e-mail, or any other publishing method.
These three configuration parameters will vary, depending on whether you choose
unicast or multicast streaming.

All these setting are finally saved as ASX files. These files
connect clients to the correct IP address for receiving streamed content. Links
can be made to these files from a Web page, or it can directly be sent to
clients through e-mail. Alternatively, if the client has the exact reference URL
to the data (MP3, ASF, etc.) being streamed, he can directly connect to the
stream through his media player. This is talked about in detail later.

Unicast streaming

In unicast streaming you have two options: on-demand
publishing or broadcast publishing. While the former allows a user to actively
control playback content, the latter is a passive data stream for the user. It
is like a radio, where you can tune into it, but can’t control it. However,
being unicast, a separate stream will flow to each user who demands it.

For on-demand streaming, the source can be an ASF, WMA or MP3
file. You can place the ASF files in a default home directory (usually ASFRoot)
or any other local folder. The source can also be specified as a network folder,
or a shared folder on any other machine. There’s a configuration wizard for
this, which takes you through a series of steps for publishing your content.
Once you’ve specified the data source, you have to choose the protocol to
carry it. The choice is between MMS (Microsoft Media Server), UDP (User
..........)TCP. HTTP can also be used for streaming, but could involve resolving
some port conflicts. After this, give the source a reference URL, specify the
mode of publishing, and you’re ready to go.

At the client end, files can be accessed using Windows Media
player. Here, you have to specify the path for the streaming file in a specific
format. So click the File menu, and select Open. In the path box, specify the
path of the ASF to be accessed, for example, mms://Server_name/file_name.asf,
where Server_name is the name of the server (or the IP address) running your
media services and the filename is the name of the file to be accessed. The
Media player will connect to the server and on-demand streaming will start.
Choosing MMS as the protocol is advisable because it automatically rolls over to
other protocols (MMS-UDP or MMS-TCP) if required.

In broadcast publishing, the procedure is similar except for
source specifications. Here, the data source can be a Windows Media encoder
(local or remote); a remote broadcast station or a remote publishing point. The
first option involves using the Netshow encoder, which we’ve talked about
earlier. Here, you’ll need to use the MSBD protocol, and specify the name of
the machine running the encoder with the connecting port (which is usually 7007
by default). This is the case where encoding and transmission is done on the
fly. The encoder does the encoding and sends the data to the output port from
where the Win 2K server accesses it for further publishing.

Interestingly, the broadcast station - your server - can also
serve as a transmission station, by using a remote broadcast station (which
already uses MSBD or HTTP), or a remote publishing point (using MMS) as the
source. Here again, you need to specify the protocol and the publishing option
as in case of on-demand unicast publishing.

At the client end, access is through the MSBD protocol. The
syntax is msbd://Server_name/station_name where station name is the name you’ve
specified for the particular broadcast stream.

Multicast streaming

In this, a single stream is constantly broadcast over the
network and anyone can tune into it. Configuring a multicast stream is quite
similar to unicast. A wizard guides you through the steps of specifying the
source, which can be an ASF file, a remote publishing point, or a Windows Media
encoder. The method of setting the paths of the source is also the same as in
unicast streaming.

After this, you need to give the station name (the reference
to your stream), program name (which stores and organizes the content to be
broadcast) and stream names (the actual content), and you’re ready to publish.
You can program the multicast station to play once or loop forever. This is
again a passive stream to which users connect with the syntax mms://Server_name/station_name.

MM Vijay Sargunar and M Syed Masood, Department of Computer
Science, Engineering and Applications, Crescent Engineering College, Chennai

Next Month: Streaming Media with Apple Quicktime