Novell is now a part of Micro Focus

Multimedia Streaming with NetWare 5.1

Articles and Tips: article

Alan Mark
Corporate Technical Strategist
Novell, Inc.
amark@novell.com

01 Aug 2000


NetWare 5.1 has many features which make it a highly capable Web server. One of the key features is the ability to stream multimedia content such as audio and video data. This AppNote explores streaming media concepts, explains how they apply to the NetWare MultiMedia Server, and shows how they can be used in creating multimedia content for the Web.

Copyright 2000 by Novell, Inc. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the express written permission of Novell.

All product names mentioned are trademarks of their respective companies or distributors.

Introduction

Even before the advent of high-speed Internet access, optimized streaming protocols, and high-capacity servers, it was possible to distribute multimedia content on the World Wide Web. Back in 1996, I wrote a series of AppNotes on how to create great Web sites. In the last of these articles (see "Exploring the NetWare Web Server, Part 3: A Complete Innerweb Solution" in the September 1996 issue of Novell AppNotes), I used a fictitious company named Alan's Exotic Travel Co. to demonstrate how a Web site could be enhanced with QuickTime and AVI video files, Shockwave animations, and WAV music files. (The Web and sample documents from that AppNote are included on the NetWare 5.1 CD.)

Back then it was challenging enough just to reliably download data over the Internet. But a lot has changed in the multimedia world during the past four years. Technologies that were in their infancy in 1996--digital video, streaming protocols, digital content acquisition--are now much more mature.

What makes multimedia streaming so important is that it delivers content "on demand"--when the user wants it, directly to the desktop. No longer must the data be fully downloaded before it can be played. Full musical and video programs can be easily accessed, and with the added benefit of being able to jump to any point in the program instantaneously.

It has been said that 1999 was the turning point for streaming video. Remember when the Star Wars Episode I trailer was released on the Web? Downloads clogged the Internet for days. And the Victoria's Secret Super Bowl promo overwhelmed the capacity of even large servers and ISPs. Clearly, users want Web-based video content.

Even traditional content providers such as newspapers and magazines are now creating Web-specific programming. For example, check out sites like http://www.WashingtonPost.com to see how reporters and columnists are delivering their stories now. Companies such as Novell have entire sections of their Web site devoted to streaming webcasts (visit http://www.novell.com/news/webcast to see a list of Novell's archived programs). Seminars, workshops, and educational institutions are delivering live Web feeds to their students. Soon you won't have to physically be in a classroom to get an education. (Perhaps we'll eventually have to redefine the term "truancy.")

The key reasons why multimedia streaming is becoming so popular are:

  • Faster Internet connections

  • Better compression techniques for audio and video

  • Easier content acquisition

  • Faster PCs and servers for encoding and decoding material

About Streaming Media

Before I describe how NetWare 5.1 streams multimedia, it might be helpful to go over some basic multimedia concepts and discuss how content is delivered using streaming protocols.

Unless you've been living on a deserted island with no connections to the real world for the past few years, you've already used multimedia on your computer. But unlike the ease of watching a program on your TV, achieving a good quality streaming video on the PC platform can be difficult. The reason is that the whole connection pipeline is full of unpredictable behaviors that differ from system to system.

Unpredictable and unreliable data flow is the most difficult problem that streaming components (servers, clients, protocols, and codecs) try to solve. From monitor to display adapter to OS to bus to CPU to LAN adapter/modem to switches/routers/firewalls to the streaming system--the whole connection path is fraught with possible delays. In fact, it isn't always possible to even calculate the actual speed of the connection. A streaming video clip may play hiccup-free on one machine, but on another it could be annoyingly choppy and possibly incomprehensible.

The objective of streaming media services is to provide continuous content, in the best quality and quantity (frames per second) possible--depending on the speed of the link and the CPU speed of the receiving computer. The latest codecs can adjust quantity depending on the link speed, a value that can change during the transmission of content. But even codecs themselves can't always determine how you're connected. That's why there are usually two or more program options for a user to choose between: a low-resolution version for slow links (28-56 Kbps), and a high-resolution version for fast links (ISDN to T1/T3).

Many webcasts (including Novell's) have selections for 28.8Kbps, 56Kbps, and 100Kbps. This means that the user must know the connection speed and pick the right version. Otherwise, the content may not play well. It also means that the content provider must provide several versions of the same program.

The higher the quality, the more data that must be transferred, and therefore the faster the link that is needed. This statement gives rise to a major quandary: why go through all the trouble of making a good-looking video production only to compress it to 1/10 the size and lower the quality so that Web folks can view it? But with enough bandwidth, full-sized picture-perfect videos can be delivered to the desktop.

How Much Bandwidth Is Needed?

An uncompressed video signal requires about 27MBps (that's mega bytes per second)--way too much for current PC hardware to handle. A compressed signal that looks nearly like the original takes the bandwidth down to about 9MBps--still too high, unless special video boards are used.

Digital Video (DV) has a constant transfer rate of 3.6MBps and looks very good for most applications. Still, you need a dedicated high-speed channel to deliver DV-quality video to your PC. The channel of choice today is FireWire, also known as IEEE 1394, but it is used for connecting a DV camera (or other device) to a PC, not as a network topology.

Although satellite vendors may disagree, broadband cable seems to be the answer to the bandwidth problem. Broadband has the ability to deliver content in the 1-3 Mbps (megabits per second) range.

MP3 files are well-suited for streaming because they have variable data rates. Normal CD music is recorded at 44.1 KHz, meaning it was sampled 44,100 times per second, or 172 Kbps. Since the sample uses 16-bits and is in stereo, a one-minute song on a music CD is about 10.5 MB. By using compression, MP3 can reduce that to 128 Kbps with similar quality. For streaming on the Internet, a lower rate is used (32 Kbps or less).

WAV is the normal format for Windows sound files. It too has various compression options, but MP3 is multi-platform, which is why it's the choice for streaming on the Internet.

The Problems of Encoding and Decoding

Of course, just getting the data to the PC doesn't mean it will play correctly. Many PCs don't have the hardware necessary to decode high-resolution material.

For instance, the MPEG-1 format specifies a 1.2 Mbps data stream with a resolution of 352 x 240. Its quality versus file size is good because the codec is complex. Today's PCs can adequately decode an MPEG-1 video stream without additional hardware. But encoding material takes a lot more time (although expensive real-time systems do exist). So despite its VHS-like quality, MPEG-1 isn't used for streaming because there are better codecs available for that task. (These will be discussed later in this AppNote.)

MPEG-2, which is used for DVDs and satellite transmission, specifies full-frame encoding at 4-9 Mbps. Since it requires hardware-assisted playback, it is also unsuitable for streaming.

RTSP: The Streaming Protocol

Multimedia content can be streamed using HTTP (HyperText Transfer Protocol) or RTSP (Real-Time Streaming Protocol), both of which operate over IP using TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). Since HTTP isn't well suited for streaming, the Internet Engineering Task Force has defined RTSP as a specific protocol for the task.

Live video feeds, music files, QuickTime, or RealMedia can all use RTSP. As detailed in RFC 2326, RTSP is used to establish and maintain a communication channel between clients and servers for the sole purpose of streaming multimedia content. The exact format of the content is not defined by RTSP, only the interaction. The RFC describes many English verbs that are used to control a stream, such as Play, Pause, and Stop. Other verbs describe the content itself and what codecs it uses.

Note: For more information on RTSP and RFC 2326, see the Internet FAQ Archives at http://www.faqs.org/rfcs/rfc2326.html.

Data Flow Control. All the popular streaming formats use RTSP to control the flow of data to the client. If bottlenecks occur, the protocol tries to keep the sound flowing while cutting back on the video. Also, the content is buffered as it's being loaded (see Figure 1). This allows for continuous playback even if brief interruptions occur.

Figure 1: RTSP buffers content to allow for continuous playback in the event of network congestion.

During a session, the media stream can be controlled on a different TCP connection. Thus, data delivery takes place in an "out-of-band" protocol with both client and server being able to control the stream. If the port is empty or not given, port 554 is assumed.

Other RTSP transport settings can be made, as shown in Figure 2.

Figure 2: RTSP transport settings.

Sample Packet Trace. The packet trace shown in Figure 3 shows the initial setup using TCP, describing the content and what data ports are used (6970-6971).

Figure 3: Initial packet showing RTSP setup using TCP.

After the setup is complete, data is transferred using UDP. The end of the session uses TCP. Control parameters, such as PAUSE, are sent in plain English (see Figure 4).

Figure 4: Packet showing RTSP control parameters being sent over TCP.

The basic transaction is detailed below (some data have been removed for clarity). In packet 6, notice how the transmission speed is sent (115,200--the trace was performed on an Ethernet network). In packet 10, the client will use ports 6972-6973, and in packet 11, the server will use ports 1031-1032.

Packet 4 - ws to server

OPTIONS rtsp://10.1.1.1:554 RTSP/1.0

CSeq: 1

User-Agent: RealMedia Player Version 6.0.7.671 (win32)

ClientChallenge: 85653101a119527d76c0a0daf5aa0937

PlayerStarttime: [23/06/2000:16:18:39 00:00]

CompanyID: mBm13mdQLLFRDkjp++VtSw==

GUID: 00000000-0000-0000-0000-000000000000 RegionData:

ClientID: Win98_4.10_6.0.7.380_play32_LF61_en-US_586

Packet 5 - server to ws

RTSP/1.0 200 OK

CSeq: 1

Date: Wed, 24 Mar 1999 05:57:01 GMT

RealChallenge1: db688e98dabbe4594ccc7c7f2c8015b6 Public:

OPTIONS, DESCRIBE, SETUP, GET_PARAMETER, SET_PARAMETER,

PLAY, PAUSE, TEARDOWN

Packet 6 - ws to server

DESCRIBE rtsp://10.1.1.1:554/eric.rm RTSP/1.0 CSeq: 2

Accept: application/sdp

Bandwidth: 115200

GUID: 00000000-0000-0000-0000-000000000000 RegionData:

ClientID: Win98_4.10_6.0.7.380_play32_LF61_en-US_586

SupportsMaximumASMBandwidth: 1

Language: en-US, en, *

Require: com.real.retain-entity-for-setup

Packet 7 - server to ws

RTSP/1.0 200 OK CSeq: 2

Date: Fri, 23 Jun 2000 22:16:09 GMT

Content-Type: application/sdp

Content-Length: 1534

Packet 8 - server to ws

IN IP4 10.1.1.1s=<No Title<i=Eric Schmidt PBS <No Copyright<

a=Flags:integer;2a=StreamCount:integer;2a=Author:buffer;

"RXJpYyBTY2htaWR0IFBCUwA="t=0 0m=audio 0 RTP/AVP

101a=control:streamid=0a=rtpmap:101

x-pn-realaudio

a=length:npt=15.517000

a=mimetype:string;"audio/x-pn-realaudio"

a=StartTime:integer;0a=AvgBitRate:integer;

8500a=AvgPacketSize:integer;304a=Preroll:integer;

3434a=MaxPacketSize:integer;304a=MaxBitRate:integer;8500a=

...

"The Audio Stream"a=RMFF 1.0 Flags:buffer;"AAIAAgAA"

a=ASMRuleBook:string;"priority=5,averagebandwidth=8500,

PNMKeyFrameRule=T;priority=5,averagebandwidth=0,

PNMNonKeyFrameRule=T,

OnDepend=\"0\",OffDepend=\"0\";"m=video 0 RTP/AVP

101a=control:streamid=1a=rtpmap:101 x-pn-realvideo

a=length:npt=14.999000a=mimetype:string;

"video/x-pn-realvideo"

...

"The Video Stream"a=RMFF 1.0

averagebandwidth=47623

SETUP rtsp://10.1.1.1:554/eric.rm/streamid=0 RTSP/1.0

CSeq: 3

RealChallenge2: d462deb75cdd944940f019314b3e663e01d0a8e3,

sd=dd594146 RDTFeatureLevel: 2

Transport: x-real-rdt/mcast;client_port=6970;

mode=play,x-real-rdt/udp;client_port=6970;

mode=play,x-pn-tng/udp;client_port=6970;

mode=play,rtp/avp;unicast;client_port=6970-6971;mode=play

Packet 9 - ws to server

RTSP/1.0 200 OK CSeq: 3

Date: Wed, 24 Mar 1999 05:57:02 GMT

RealChallenge3:

9f40ffebbf8d18ee948795166b1ab4fd4f213d09,sdr=9fb1996b

Transport:

rtp/avp;unicast;client_port=6970-6971;server_port=1029-1030

Session: 1

Packet 10 - server to ws

SETUP rtsp://10.1.1.1:554/eric.rm/streamid=1 RTSP/1.0

CSeq: 4

Transport: rtp/avp;unicast;client_port=6972-6973;mode=play

Session: 1

Packet 11 - ws to server

RTSP/1.0 200 OK CSeq: 4

Date: Wed, 24 Mar 1999 05:57:02 GMT

RealChallenge3:

9f40ffebbf8d18ee948795166b1ab4fd4f213d09,sdr=9fb1996b

Transport: rtp/avp;unicast;client_port=6972-6973;

server_port=1031-1032 Session: 1

Codecs

Streaming codecs take source material and radically reduce the data in a number of ways. First, the normal 640x480 screen size is reduced to a fraction of that size, sometimes as small as 160x120. Second, the quality is reduced so that each frame has fewer colors (depth) and blocked patterns are evident. Third, the speed is reduced from 30 frames per second to a lower value. The resulting image often looks worse than those old home movies you took in the 1960s.

Notice the video comparison in Figure 5. The original DV clip was imported at 3.6 MBps (27.5 Mbps). The audio is 16-bit, 32KHz. The size is 640x480 (technically 720x480 because DV pixels are non-square). Notice how much smaller and less clear the encoded files are. But for most applications, they are still watchable.

Figure 5: Comparison of source and compressed video clips.

When it comes to sound, however, humans are much more picky. Stuttering video is merely annoying, whereas stuttering sound may be incomprehensible.

Acoustic research finds that we don't actually hear all of the sounds that we're presented. Therefore, audio codecs try to remove that extraneous sound--stuff that we won't miss--to create a smaller yet reasonably accurate sound file. But even that strategy produces large file sizes that don't stream well except on fast links. Further reducing the file size produces sound that's as clear as talking while gargling. For speech, that may be okay as long as it's understandable. For music, though, listening to an AM radio underwater may sound better.

The original source has a sound range up to 16KHz (normal human hearing rarely extends beyond that) and is in stereo. In the low-res version, one 8-bit channel only has a range of 8KHz--about that of AM radio. Figure 6 shows a comparison of these two audio versions.

Figure 6: Original source audio compared with low-res version.

Until we all get fast and reliable links, codecs will be necessary. That means picture and sound quality will suffer to varying degrees, depending on the codec being used.

Popular Codecs

For the past few years, the most popular codecs have been those from RealNetworks, Apple, and Microsoft. Each claims to have the best quality at a certain data rate. Since it's impossible to know what player a user might have, some Web sites offer two versions (typically Real and QuickTime). Or two competing Web sites might offer their own versions of the same content. For instance, movie trailers can be found in QuickTime at http://www.apple.com/trailers, and in Real format at http://www.film.com.

  • RealNetworks. Although RealMedia uses a proprietary format, the company claims that its quality can be as good as watching a VCR on your home TV-- with enough bandwidth. While you'll never get that quality over ordinary Internet links, the company is surely thinking about the future when fast broadband connections are plentiful. RealMedia has a wide range of encoding options, from 28.8 to something they call "WWW Video (Big)." Figure 7 shows an example of a video clip in Real format.

Figure 7: A video clip playing in Real format over the Internet.

  • Apple QuickTime. Apple was the first major vendor to support desktop video; the Macintosh has been able to play Quicktime movies for many years. Only recently, however, has QuickTime supported streaming. In 1999, Apple proposed making its QuickTime version 4 an open standard. By the end of that year, it was official: MPEG-4 was essentially QuickTime 4, with options to use codecs other than QuickTime's Sorensen. Other vendors, such as IBM and Sun, joined Apple to create content based on that standard.

  • Note: Things are continually changing on the codec front. For example, on June 12, 2000, Apple and RealNetworks, Inc. announced that RealNetworks had licensed Apple Intellectual Property for streaming digital video and audio over the Internet in the QuickTime format.

  • Windows Media. Microsoft has been slow to enter the streaming market, but with its desktop dominance it is a serious contender nonetheless. Its Windows Media Format uses proprietary and MPEG-4 codecs that offers various resolution and playback options. Microsoft is claiming "near-DVD" quality over 750 Kbps broadband links. The Screen Capture codec, useful for screen demos, can stream "pixel perfect" 640 480-pixel resolution video with an audio voice-over on a 28.8-Kbps modem.

  • Microsoft also claims to have pioneered "CD-quality audio in half the file size of MP3." The issue is not whether their claim is true, but whether the industry will use the format. MP3 is already entrenched in portable players and on thousands of Web sites around the world. Microsoft's new format is still in beta as of this writing.

Configuring the NetWare 5.1 Multimedia Server

Enabling streaming on NetWare 5.1 is simply a matter of clicking a few buttons on the NetWare Web Manager configuration screen. This section provides an overview of how to configure the NetWare Multimedia Server.

Installing the NetWare MultiMedia Server

If the NetWare MultiMedia Server hasn't been installed yet, do so now from the original NetWare 5.1 CD.

Configuring the MultiMedia Server

To configure the MultiMedia Server, you must log in to the server via your browser using an NDS connection with administrative rights. The Server Selector menu displays the Web components that are available (see Figure 8).

Figure 8: NetWare Server Selector screen showing available Web components.

When the NetWare MultiMedia Server is enabled, the MEDIA.NCF file loads the following NLMs:

  • MEDIASRVR (the media server)

  • WAVEPL (support for Windows sound files)

  • REALPL (support for RealMedia files)

  • MPEGPL (support for MPEG-1 Layer 3 files)

The NetWare MultiMedia Server supports the following file formats:

  • WAV (standard Windows audio format)

  • MP3 (MPEG-1 Layer 3, the Motion Picture Experts Group format for digital audio)

  • RM (RealMedia format)

  • Note: There are other RealMedia extensions, such as .RA, .RAM (RealAudio), and .RV (RealVideo), but only .RM is recognized by the Multimedia Server.

Configuration Settings. There are three configuration parameters for the MultiMedia Server, which can be changed in the NetWare MultiMedia Server Settings screen (see Figure 9).

Figure 9: The NetWare MultiMedia Server Settings screen.

Or, you can manually edit the SYS:/ETC/MEDIA.CFG file. This file contains three lines:

AdaptiveQOSMode 6

MmfilePath SYS:PUBLIC\MEDIACONTENT

MaxClients 50

These settings are explained below.

  • Adaptive Quality of Service. The AdaptiveQOSMode specifies the percentage of data packets to be dropped while sending content to the media clients, depending on network traffic. The possible values are from 0 to 100, with zero disabling Adaptive QoS. A value of 100 optimizes streaming even when there is high network traffic. By default, Adaptive QoS is disabled on the MultiMedia Server.

  • The idea behind QoS is to adjust the quantity of data to a client depending on the bandwidth available. If there is not enough bandwidth available to keep a steady flow of data to a client, the MultiMedia Server cuts back on the data sent to help relieve network congestion.

  • Location of Multimedia Files. The MmfilePath parameter specifies the location of multimedia files. The default is SYS:PUBLIC\MEDIACONTENT. This directory should have public access rights. Although multimedia files can be placed anywhere within the Web server's document directory (SYS:\Novonyx\suitespot\docs\mm), only files in the MmfilePath and in directories below will be delivered using RTSP.

  • Limiting the Number of Concurrent Client Connections. MaxClients specifies the maximum number of concurrent client connections. The default and maximum value is 50. Note that when CPU utilization is around 98%, no further client connections are possible.

  • Each client connection reduces overall server resources. For better performance, increase Maximum Packet Receive Buffers value to a higher value. A general rule is to allocate 100 buffers for each client connection.

Using RTSP versus HTTP

Since the MultiMedia Server uses RTSP for transport, the NetWare Web Server does not need to be loaded. However, this precludes the use of HTTP as a fallback. Some players, such as RealPlayer and QuickTime, can use HTTP for client streaming and other functions. However, using RTSP results in true server streaming and smaller UDP packets. In general, while HTTP over TCP may be more reliable, RTSP over UDP is faster and better suited for streaming.

A packet analysis of RealMedia Player 7 and the NetWare MultiMedia Server shows RealMedia's player using TCP for connection setup and teardown, and UDP for data transfer. If the file can't be found using RTSP, the RealMedia Player tries an HTTP request. If found, it uses TCP for the entire data transfer.

To explicitly use RTSP, use the following syntax (as illustrated in Figure 10):

RTSP://server/filename.ext

Figure 10: Specifying the use of the RTSP protocol when opening a file.

In this case, filename.ext is located in the directory specified in MmfilePath.

If a file outside of the path specified by MmfilePath is used, the player must use HTTP because the MultiMedia Server isn't involved in the transfer. Files in other directories will be thus served using HTTP. This means that streaming is purely a function of the client and not of the server.

Although the QuickTime 4 player supports RTSP, it does not work correctly with the NetWare MultiMedia Server. Only HTTP is supported with QuickTime 4 (see Figure 11).

Figure 11: When opening a QuickTime 4 file, you must use HTTP.

Guidelines for Creating Streaming Media Content

There are few challenges greater than creating great-looking streaming content. Naturally, your creative side wants interesting camera movement and fantastic backgrounds. But that type of production doesn't sit well with video encoders. When creating effective video content for the Web, you must limit yourself to basic shooting techniques. This section provides some rules and guidelines for creating video content for the Web.

Rule 1: Use the best video and sound equipment available.

Before you create the video, decide how it will be delivered. If it's destined for the Internet, you have to shoot carefully. For intranet delivery, you can be a bit more liberal. In either case, the number one rule is to shoot clean video on the best possible equipment.

Video and sound compressors take an image or sound and reduce its overall size. The codec makes assumptions about what we will see and hear. However, it uses mathematics, not intelligence, to make that determination. If there is noise present, the codec will assume that we want to see or hear that also--and by doing so, it leaves less room for the "real" content. Remember that the codec has a fixed amount of data it can play with to display an image or produce a sound.

"Noise" is any unwanted pixels in a video source, as in blurry images shot with poor cameras. Noisy audio contains hiss and hum. If there is less noise included in the original source, the codec will more cleanly encode the content. That is why it's best to shoot with Digital Video cameras than with S-VHS or other consumer formats. DV video records excellent images and clean sound.

Rule 2: Limit camera movement and shoot against simple backgrounds.

Even with DV, content may not get compressed very well if your footage looks like it came from an MTV shoot. With lots of quick shots and rotating camera movements, a 30 frames-per-second (fps) MTV video will look extremely jerky when streamed at 8 fps. The same is true for content with busy backgrounds.

For interviews, have the subject stand against a solid background. Use a tripod to eliminate unwanted camera movement.

Another point is to use longer takes instead of cutting to various scenes (like a news report). Codecs are good at optimizing these "talking head" segments without interjecting scenes.

If there is noise around the edges of the video, or if there are unwanted objects, crop that segment so those items won't be compressed.

Rule 3: Don't use transitions.

Transitions are those cool effects that distinguish one scene from another. The classic transition is the dissolve, where one scene fades out while the new scene fades in. Others have one scene flying away into oblivion, and animated barn doors opening to reveal the new scene. But as cool as they might look on the TV screen, transitions won't compress well for streaming. In fact, they'll probably end up looking very bad.

One transition that is appropriate for streaming is the freeze frame, which compresses extremely well. Have the sound continue while the image doesn't move, then cut to the new scene.

Rule 4: Make titles and main objects fill the screen.

Titles and subtitles can be unreadable when they're compressed. When a codec throws away pixels that make up a person's face, it may look ugly. But when it does the same with a title, it means that your viewers see a bunch of unrecognizable garbage on the screen. As a general rule, make subtitles fill 25% of the screen.

Since the video size will likely be small, use close-ups of people and other objects. If you're shooting a video about a man who served in the military, a normal shot may show him from the chest up so that his medals can be seen. For Web streaming, close in on his face, and show his medals in another shot.

Rule 5: Boost the audio.

On low bit-rate content, audio sounds horrible. This is because brightness and detail are reduced when compressed. To compensate for this, boost the sound signal during shooting or editing.

Rule 6: Cut to the chase.

When creating a video clip for Web viewers, don't pontificate on and on about a subjectPeople have much less patience when watching streaming video than they do when watching a home movie. In a similar vein, don' put needless diversions in a clip. Get to the point quickly and stay focused on it.

Rule 7: Have your subjects wear neutral clothing.

Video doesn't like solid black or patterned items. The best shirt to wear is a neutral color, like grey or brown. If your speaker must wear glasses, tilt his or her head down to avoid reflections.

An Example Streaming Project: Digital Airlines

As an example of the appropriate creation and use of streaming video and audio content for a Web site, I'll use another ficticious company. This one is named Digital Airlines (DA).

The CEO of Digital Airlines is Doug Knight (a.k.a. Novell's Vice President of Systems Engineering). Its CIO is Stafford Masie (a.k.a. a Corporate Business Strategist at Novell). The company wants to produce streaming videos for both its internal and external Web sites. In one video, the CEO will welcome visitors to its Internet Web site, and in another he'll thank employees for doing an outstanding job. In the CIO video, the CIO will only address employees.

This makes a total of six videos to produce:

  • CEO external, hi-res

  • CEO external, low-res

  • CEO internal, hi-res

  • CEO internal, low-res

  • CIO hi-res

  • CIO low-res

CEO Production

The CEO video segment was taped at the Provo, Utah airport in an airplane hanger. The hi-res versions start with a pan from the runway to the hanger, which is acceptable because of the higher bit rate (256Kbps). The details on the external version are given below:

Stream: RealVideo Stream - Single Rate

File Name: CEO ext hi.rm

Last Modified: Mon, 12 Jun 2000 05:23:44 GMT

File Size: 725,346 Bytes

Title: Digital Airlines CEO

Author: AM-hi

Copyright: Novell

Duration: 00:27.862

Buffer Time: 2.6 seconds

Max Bit Rate: 208.0 Kbps

Allow Download: off

Allow Recording: off

Perfect Play: enabled

Stream: 0 Audio Stream

MIME type: audio/x-pn-realaudio

Max Stream Bit Rate: 44.1 Kbps

Audio Codec: 44 Kbps Music (RealAudio G2) 44100 Khz

Stream: 1 Video Stream

MIME type: video/x-pn-realvideo

Max Stream Bit Rate: 163.9 Kbps

Dimensions: 256x192

Video Codec: 163.9 Kbps (RealVideo G2)

Player Compatibility: RealPlayer G2 or later

Figure 12 shows the settings used to format for this video for the Web. The application shown is Media Cleaner Pro (from http://www.terran.com), which can batch process files and convert them to various formats.

Figure 12: This sample screen shows that each file was compressed with a specific option.

The external low-res version is meant for slower 56 Kbps links. It doesn't have the beginning pan; it starts right with Doug. The details are given below.

Stream: RealVideo Stream - Single Rate

File Name: CEO ext low.rm

Last Modified: Mon, 12 Jun 2000 05:20:16 GMT

File Size: 101,296 Bytes

Title: Digital Airlines CEO

Author: AM-low

Copyright: Novell

Duration: 00:23.40

Buffer Time: 3.8 seconds

Max Bit Rate: 33.0 Kbps

Allow Download: off

Allow Recording: off

Perfect Play: enabled

Stream: 0 Audio Stream

MIME type: audio/x-pn-realaudio

Max Stream Bit Rate: 8.0 Kbps

Audio Codec: 8 Kbps Music (RealAudio G2) 8000 Khz

Stream: 1 Video Stream

MIME type: video/x-pn-realvideo

Max Stream Bit Rate: 25.0 Kbps

Dimensions: 160x120

Video Codec: 25.0 Kbps (RealVideo G2)

Player Compatibility: RealPlayer G2 or later

The two internal CEO videos were created in a similar fashion.

CIO Production

For the CIO, the hi-res video shows Stafford walking through the network operations center. In the low-res version, he is stationary. I cheated a bit by starting with a pan, because I wanted the audience to see the operations center. In this case, it worked because the pan is very slow.

Figure 13 shows a summary of the settings used to produce this video for the Web.

Figure 13: When converting a high-res file to a streaming format, there are various settings to configure, such as size and data rate.

The audio on the low-res versions was encoded at 8 KHz, which results in AM radio-like quality. The hi-res versions were encoded at 44.1 Khz, the same rate used for MPEG-2 and audio CDs. The DV sound source was recorded at 32 KHz, meaning the resulting sound was up-sampled.

Notice in Figure 14 how one minute of video takes nearly three minutes to compress. However, there are systems that do this process in real-time. Such systems would be suitable for producing live webcasts.

Figure 14: Output summary for creating one minute of video using the Real codec.

Once the video file's created and compressed, they were placed onto a NetWare 5.1 server. HTML links were generated to allow users to select the appropriate video for their connection type.

How do the video clips compare? Overall, it's about what you expect from streaming content: the quality is adequate to understand the message.

Future Enhancements to the Multimedia Server

As of this writing, several enhancements are planned for the NetWare MultiMedia Server. These include:

  • Fully multiprocessor enabled

  • Support for QuickTime player

  • Support for QuickTime movie files

  • Enhanced scalability (support for at least 150 concurrent clients)

  • Access and error logs

  • Improved Web Manager interface

Novell is also working on support of additional codecs for future releases.

Conclusion

Streaming video is all about getting a message across to your intended audience. Whether your message is a customer testimonial, a commercial, or a movie trailer, the Web is now a viable conduit to deliver multimedia-rich content to people around the globe. Faster links and computers, combined with better codecs, are contributing to the growing popularity of streaming content. With NetWare 5.1's Multimedia Server, a variety of content can be streamed to users over the Internet or on intranets. When this server is combined with all the features of the NetWare Web Server, you have a great platform to serve all sorts of data.

There is also a growing market for streaming video content. More video programming is now found on the Web than at your local video store. But until all our homes get really fast Internet access, we'll have to settle for small pictures and low-quality audio. For intranets, the story is better because fast switches and 100 Mbps Ethernet connections are common in the workplace environment. This allows content creators to produce better quality programming, as creative talents aren't stifled because the links are too slow. Remember, regardless of the delivery mechanism, it is creativity that makes multimedia content enjoyable.

Some day, major video and audio content will be available first on the Web. As a preview of this, visit http://www.trailervision.com, a site containing short films that are created for and featured only on the Web. It's kind of fun because the filmmakers seem to completely ignore Hollywood's rules of filmmaking. The result is a collection of low-budget flicks that anyone can watch for free.

Could big-budget movies be far behind? Only time will tell. But don't be surprised if one day your only choice to watch the latest Mission: Impossible movie is on your integrated PC/TV device--and, of course, the stream is being delivered from a NetWare server.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates