by Michael T. Erwin
Many Web sites are adding a sense of "now" by incorporating live, dynamic content-whether it be audio, video, or both. This up-to-the-minute content can enliven even a bland Web page. Before live media, the choice was limited to adding either static audio or static video files. These files are stored on your Web server and have to be requested by a browser to be played or retrieved. However, with live streaming media, information is generated in real time, as an event occurs, and is broadcast across the Internet in a continuous data stream. Hence the phrase "live streaming media."
An online radio station broadcasting live content to on the Internet is a perfect example of using streaming media. Other examples include near time broadcasts of news, sporting events, and even Internet talk shows. Realistically, this live media can be used by newspapers to incorporate news broadcasting as an addition to their existing print content.
This chapter explains how to add live streaming to your Web site and gives you an overview of the available products and methodologies for you to use as a Webmaster. It also explains the effects live streaming media will have on your bandwidth and hardware requirements.
One thing you will definitely learn in this chapter is that you need some real bandwidth to do much streamed audio or video. The more streaming you do, the more bandwidth you will need. I am not just talking about a 64Kbps ISDN line-I mean a lot of bandwidth-like a T1 or higher.
This required bandwidth is on the server side of the pipe. For example, if you plan on serving five different audio streams, and each audio stream is being encoded at 22Kbps, you will be pumping data out at almost 128Kbps.
By providing just five different audio streams in this example, you would be using almost 10% of the total throughput of a T1. So if you want the ability to provide multiple audio and video streams, you now have an idea of how important it will be to consider your available bandwidth.
You will also need to make sure that you consider the bandwidth used by other services and applications-like Web and UseNet traffic-when estimating the number of simultaneous users that your IP bandwidth can handle.
However, on the client side, they can only listen to, or receive, one audio stream at a time, which can be received very nicely on a 28.8 modem. If they try receiving more than one higher quality audio stream at a time, they will experience numerous dropped audio packets, making the audio almost unintelligible. This becomes a much bigger issue with regard to streaming video, which has much higher bandwidth considerations, depending on the quality of both the audio and video.
Having said that, you also need to know quite a bit about the hardware, software, and formats that are available to you as Webmaster.
All methods of providing live streaming audio or video require that you capture and place the audio and video content in an encoded digital format. Most of these encoded formats do not differ much from the format that is used to store audio on a CD. You will also find that you have several hardware and software options available to you as the Webmaster.
Some users erroneously believe that you can truly provide live streaming audio or video across the Web. What actually occurs is that the Web server has an embedded link to another file format, which causes the browser to launch a helper application, such as a player utility based on the MIME definitions defined by both the Web server and the browser.
The system that has been used for the longest time is called multicasting IP, or MBONE. MBONE was developed by the Internet Engineering Task Force's (IETF) audio broadcasting (audiocasting) experiments. IETF wanted to provide the audio and video from its meetings to members and other interested people around the world. Multicasting, or multimedia broadcasting, was first used at IETF's 1992 meeting in San Diego, California. Support for MBONE is currently a volunteer effort by many in the IETF community.
MBONE is a virtual network, residing on the Internet, through which audio and video IP packets are routed to and from individual workstations around the globe. The term MBONE comes from the creation of a multimedia Internet backbone. MBONE somewhat resembles the structure of a tree. The root of the tree is MBONE's data source, which continuously branches out through the data stream, until the data packets eventually get to a client. These data packets flow outwards from the source-the MBONE source server.
Because this is a virtual network, the workstations need to run a routing daemon called mrouted. The reason for this is that many clients not only listen to what is being received but also forward the data packets on to other clients, further out on the branch.
MBONE is an important open standard for providing multimedia broadcasting across the Internet. Since it is an open standard, various system platforms could support it, even though very few actually do.
One major benefit of MBONE's implementation strategy is the relatively low usage of the Internet's backbone IP bandwidth, compared to other streamed media options. If MBONE was used in a corporate or university setting, the MBONE implementation could provide multimedia broadcast across most WANs, with little performance or bandwidth degradation. And if you look deep enough into any of the proprietary streaming servers, you will find some resemblance to MBONE's source or root server.
Since the MBONE system is fairly technical and requires a lot of set up to get it going, it has a very limited hardware support. However, as stated earlier, it is an open standard that most platforms could incorporate relatively easily.
To use MBONE, you need at least a UNIX workstation, preferably
a Sun SPARC-based system or a Silicon Graphics RISC system. SGI
systems ship with support of MBONE already installed. The SGI
systems include not only the software needed for MBONE but also
additional hardware, such as a small color camera, audio microphone,
and stereo inputs.
| TIP |
The MBONE IP multicast software is available by anonymous FTP from the Vmtp-ip directory on host gregorio.stanford.edu. |
Audio encoding is provided by the built-in 64Kbps audio hardware in the Sun and SGI systems. For video, you do not need any special hardware because most of the newer Sun and SGI workstations have a video frame capture card built into the hardware. However, on most of the older Sun systems, you need a VideoPix card to capture the video.
Video is normally in a slow frame rate because audio and video decoding is done in software. Because the decoding or receiving of audio and video is in software, you do not need any additional hardware.
The slow frame video data rate is typically 25-150Kbps. As you can see, from these network traffic numbers, you probably need a dedicated connection to the Internet for MBONE to work.
Using MBONE is great if you are going to participate with the IETF and provide audio and video to others that can handle MBONE IP multicasting.
Another server requirement you must deal with is the use of MIME.
You can add MBONE content to your Web site by working with the
MIME types file on your server, and with the MIME types located
on the client side. This will link the MBONE connection via the
helper applications defined by the browser's MIME types file.
However, the major problem with MBONE is the hardware and technical
requirements needed to handle the MBONE multicasting.
| NOTE |
One of the problems with all streamed data types is the use of client-side utilities and the hardware requirements. First, not only does the client have to install and configure hardware that is supported, but they must also have software utilities that have to be installed and configured before the client can receive the streamed encoded data. This requirement will make the streamed content you generate unavailable to many on the Web. Therefore, you might want to take into consideration the clients' requirements. You might also want to consider providing an HTML-based summary or full transcript of what was discussed in the live feed. |
Once you have the MBONE server multicasting, or streaming, the encoded audio and video data packets, you can then integrate MBONE into your Web site.
One of the best examples is using the Web site as a staging area for classroom instruction. The instructor builds a Web page that has the embedded HTML link to the MBONE server. This page will have a lecture outline or other useful information. It can also include the starting time of the next lecture. At that time, the students (and others) can use their Web browser to link to the MBONE server. Then the browser will launch the MBONE listener, or player utility, which will enable the student to see and here the lecture live.
If you only need to deliver audio and want wide acceptance and usage by your visitors, take a look at the RealAudio Server by Progressive Networks. The RealAudio home page is shown in Figure 28.1.
Figure 28.1 : Progressive Network's RealAudio home page is located at http://www.realaudio.com/.
RealAudio is the oldest, and one of the most accepted, commercial streaming audio systems available for the Internet. Currently, there are more than one hundred companies and organizations that use RealAudio to send audio packets around the world.
RealAudio is a client/server based system. So not only do you need a server application for serving the audio files, but the visitors to your site also need client software for receiving the proprietary encoded audio packets.
RealAudio's protocol is a called a bi-directional, timed-based protocol. This protocol is based on the User Datagram Protocol, or UDP. Simply put, this protocol does not require the receiving client system to send an acknowledgment packet for each received audio packet. Like many protocols used on the Internet, this protocol is geared towards speed instead of reliability. The loss or dropping of packets is handled by a Progressive Networks' proprietary system in order to minimize the effects of the loss of audio packets by re-creating the missing packets of the audio stream.
When a visitor clicks a hyperlink to a RealAudio (RA) file, the browser helper application automatically launches the client-side application to play the RA file. The RealAudio player client application is shown in Figure 28.2. This application can also be a plug-in for Netscape's Navigator.
Figure 28.2 : The RealAudio player client interface as viewed from Windows 95.
| NOTE |
Netscape's Navigator version 3.0 supports special helper applications called plug-ins. These plug-ins allow you to add inline document support for audio, video, and other special formats. Many of the products discussed in this chapter have plug-ins available for Navigator to support live or streamed media content. |
Of course, to play the encoded RealAudio files, your computer needs to have a sound card installed and configured for your particular operating system.
The RealAudio server software works on a variety of Web server platforms and operating systems, including
Another benefit of RealAudio is that it works with a variety of Web servers. By adding RealAudio's MIME type to your Web server's MIME file, you can serve the encoded files from the Web server. Some of the compatible servers are the following:
The RealAudio Server is relatively small. It only uses 2M of RAM to run, assuming that the system resources are not overwhelmed from other applications running on the system. Additionally, the server software does not have a high impact on the CPU. RealAudio's documentation states that a 100 stream server, running on a 90MHz Pentium, uses less than 30% of the CPU cycles.
However, you should have adequate hard drive space. RealAudio encoded audio documents require approximately 1Kbps of recorded audio for 14.4 format and 1.6Kbps for 28.8 format. So if we expand that out some what, 1 hour of 14.4 format of recorded audio requires approximately 3.6M of disk space and 1 hour of 28.8 format of recorded audio requires approximately 6M of disk space after encoding and compression.
A system connected by a T1 line is likely to run out of bandwidth
before it runs out of memory and CPU horsepower. The RealAudio
server requires at least 10Kbps for 14.4 format and approximately
22Kbps for 28.8 format for each RealAudio client connected to
your server. That calculates out as follows: a 56Kbps leased line
can only accommodate approximately five simultaneous 14.4Kbps
connections. A T1 line, by contrast, can accommodate over 100
simultaneous 14.4 connections. So if you are planning on using
RealAudio for commercial applications, a T1 is the smallest IP
bandwidth connection you should use. Table 28.1 outlines the number
of RealAudio streams that your Internet connection can support,
assuming that no other service is using that bandwidth. Make sure
that you consider the bandwidth used by other services and applications-like
Web and UseNet traffic-when estimating the number of simultaneous
users that your IP bandwidth can handle.
| Available Bandwidth | RA 14.4 Format | RA 28.8 Format |
| Frame Relay (56Kbps) | 5 | 2 |
| ISDN (64Kbps) | 6 | 2 |
| ISDN (128Kbps) | 12 | 6 |
| T1 (1.5Mbps) | 150 | 68 |
| Ethernet LAN (10Mbps) | 1,000 | 454 |
| T3 (45Mbps) | 4,500 | 2,045 |
| 100BaseT/FDDI LAN (100Mbps) | 10,000 | 4,545 |
| NOTE |
Progressive Networks makes available for download a Personal RealAudio Server. You can download this version by just answering some questions. You can also download the documentation in either PostScript or Adobe Acrobat PDF format. The commercial version has a price starting at $2,490 for a 10-user license and increases to $13,490 for a 100-user license. Progressive Networks does offer a 60-day evaluation program to see if RealAudio meets your needs in providing audio on demand. |
The RealAudio server runs on an unprivileged port, so it is not
necessary to start the server as root. However, root
privileges are necessary when the RealAudio server needs to configure
itself to use additional system resources, as it can when a large
number of concurrent connections is expected. If the RealAudio
server is started as root, it changes its user ID after
the resource limits are adjusted and assumes the user and group
IDs entered into the configuration file.
| CAUTION |
Be careful of logging on as root; instead use the command su to switch to root after logging on as yourself. This helps in avoiding known securities holes in some UNIX platforms. |
Change directories into the top level directory of the RealAudio server installation and enter the following command:
bin/pnserver server.cfg
Again, remember that you need to change the drive letter, path,
and server configuration file name to reflect that of your actual
installation.
| TIP |
It's a good idea to edit your startup scripts so that the RealAudio server is started upon system reboots. You should also have your UNIX system administrator do this for you. |
When you are ready to stop the RealAudio server, enter the following at the prompt:
kill 'cat /pnserver/logs/pnserver.pid'
| NOTE |
RealAudio server, by default, uses the TCP/IP services port 7070. This TCP/IP port is used for accepting requests from clients and for sending the encoded audio data. During installation, RealAudio modifies your /etc/services file to reflect the use of this port. |
Creating the encoded files for use with the RealAudio player is a multi-part process. First, you need to create good quality .Au or .Wav files. To ensure that your files will convert to .Ra files, follow these steps:
After you have the audio in a usable audio format, you need to use RealAudio's Encoder utility, which is shown in Figure 28.3, to convert .Au or .Wav files to .Ra-compliant files.
To use the Encoder utility, follow these steps:
After you feel that you have your RealAudio server up and running, you can test the operation by starting the RealAudio player and selecting File ALT+F, Open Location CTRL+L. At that point you can enter the URL of your RealAudio server along with a requested .RA audio file. For example, the following:
pnm://198.77.21.195/test.ra
sends a request to the RealAudio server for the audio file Test.ra. If the file exists, the player starts playing the file as it arrives to the client.
Let's look at how you integrate RealAudio media into your Web page. For the most part, all of the different systems that you have seen in this chapter use a variation on a theme to achieve the Web page integration. All of the audio/video systems use a two-phase implementation.
RealAudio uses a defined MIME type to instruct the Web server to instruct the browser what type of file it is sending to the browser. For example, take a look at the following RealAudio Markup code, which is stored on the Web server as Start.ram:
file:complete file:thankyou
This tells the RealAudio player to request audio encoded files Complete.ra and Thankyou.ra. If you open this file from the RealAudio player, the player opens the actual audio files, and then plays them in the sequence in the .Ram file.
So to integrate RealAudio into your Web pages, you need to put something like the following HTML code in the Web document:
<A HREF="start.ram">Click Here</A> for RealAudio File.
When the user selects the Click Here hyperlink, the browser receives the text file Start.ram. If the RealAudio player has been set up in the MIME types of the browser, the simple text file is sent to the helper application Raplayer.exe. The RealAudio player client application is then read this text file, and the client application requests, from the RealAudio server, the audio files that are listed inside of the .Ram file.
After the RealAudio client starts receiving these files, the RealAudio player application starts playing the encoded audio.
Because many of you will want to provide both audio and video content through your Web site, you will need something other than an MBONE or RealAudio solution. One possibility is StreamWorks by Xing.
StreamWorks, as the name implies, is a content delivery system that uses streaming audio and video IP packets (see Figure 28.4). The StreamWorks server software works with several UNIX-based systems, but is also available for Windows NT. StreamWorks server is a Plug and Play implementation, using a TCP/IP unicast solution. StreamWorks delivers the audio and video content via the industry standard MPEG-1 and MPEG-2 formats.
Figure 28.4 : Xing's StreamWorks home page is located at http://www.xingtech.com/.
StreamWorks is also a true client/server application. To see or hear the content provided by the server, the end user needs an additional piece of software, client software. The client software works as a Netscape Navigator plug-in or helper application. The StreamWorks client is shown in Figure 28.5.
Figure 28.5 : This is the StreamWorks Player client interface for Windows 95.
| NOTE |
Xing's StreamWorks can use an integrated plug-in for Netscape's Navigator version 3.0. The plug-in works like the stand-alone helper application but is integrated into the browser. |
StreamWorks server uses a scaleable delivery system known as stream
scaling. This allows you to have a single source stream to be
delivered at multiple lower data rates. This uses your available
IP bandwidth much more effectively. StreamWorks has a low overhead,
which uses only three to five percent network overhead. StreamWorks
server is also topology independent, so you can use ethernet,
ATM, ISDN, PPP, and token ring. This type of server implementation
allows you to not only use it for Internet delivery, but also
as an intranet LAN/WAN solution.
| TIP |
For the best performance of providing content via StreamWorks server, you need at least a T1 connection to the Internet. |
To provide live, real-time audio and video feeds you need to use Xing's StreamWorks Transmitters. These dedicated hardware and software system transmitters give you live network encoding in a turnkey system. All you do is plug your audio or video source into the provided inputs on the transmitters. These transmitters require you to use ethernet. Using the built-in software interface, you can control the various parameters, such as picture size, sampling rate, data rate, and MPEG frame intervals.
Xing also has developed server software upgrades that are known
as StreamWorks Server plusPACKs. These optional software upgrades
allow virtual live feeds and streaming propagation capabilities,
similar to the capability of MBONE. One of these options, LiveFile,
enables you to provide simulated live broadcasts from prerecorded
files. This will allow you to create a library of events or stories
that you have made available on your Web site. By archiving past
events, news reports, or even music videos, you instill even more
value into the content. This gives others, like researchers, another
data information source.
| NOTE |
Windows NT users: If you are going to provide more than just the occasional audio and video feed, you might want to consider using a high-end Pentium or RISC system or move to a RISC-based UNIX system for content delivery. |
The LiveFile option also provides a method of audience extension through propagation. This propagation adds the capability to reach large audiences by propagating the StreamWorks feeds across multiple StreamWork servers. Propagation not only dramatically increases potential audience size, it economizes bandwidth requirements.
Because StreamWorks is a client/server application, you need to use the StreamWorks client to hear and view these streaming MPEG formats. Xing provides StreamWorks clients for the following systems:
To download the client software and updates, and retrieve general support information for StreamWorks, go to: http://www.xingtech.com/.
After you have the client software installed, be sure to check out one of the Internet radio stations like KPIG (see Figure 28.6). KPIG uses StreamWorks to broadcast live radio programming. They only broadcast audio, but they do have a Web camera set up to show you what the deejay is doing (see Figure 28.7).
Figure 28.6 : The KPIG Radio home page located athttp://www.kpig.com.
Figure 28.7 : A view of KPIG's StyCam located at http://www.kpig.com/welcome.htm.
Unlike MBONE, Xing's StreamWorks server software is a commercial
product. The pricing of Xing's StreamWorks products is based on
paying for bandwidth requirements. For example, the minimum pricing
of IP bandwidth is at 128Kbps. At 128Kbps, the server costs $795.
At that level, the PlusPack costs $200 and the Propagation server
is $400. And for the unlimited version you will spend $26,200
for the system. See Table 28.2 for Xing's software pricing at
the time of writing.
| Bandwidth Server | PlusPack | Propagation | Server |
| 128Kbps | $795.00 | $200.00 | $400.00 |
| 512Kbps | $1,495.00 | $400.00 | $750.00 |
| 1.54Mbps | $3,500.00 | $875.00 | $1,750.00 |
| 10Mbps | $4,950.00 | $1,250.00 | $2,500.00 |
| 45Mbps | $9,950.00 | $2,500.00 | $4,950.00 |
| Unlimited | $14,950.00 | $3,750.00 | $7,500.00 |
StreamWorks files integrate much the same way as RealAudio files and other types of MIME files. In this case, though, instead of a .Ram file extension, the browser is looking for an .Xdm extension. When the browser receives a file with a MIME sub-type of x-xdma, the browser sends the received markup text file to the helper application or plug-in application.
After the StreamWorks player receives the .Xdm file, the player then parses the information encoded in the file and requests the appropriate files from the StreamWorks server. For example, if you simulate the player receiving the .Xdm file, you can enter the following URL:
xdma://206.83.162.230/luvshow.ply
In this case, the player requests the encoded audio/video .Ply file. As the file is received, the player starts playing both the encoded audio and video.
If the requested file had actually been a live streamed multimedia
file, then the StreamWorks server would have composed the file
right before it sent it out across the Internet. The player will
start to receive the requested file; however, the player is tricked
into assuming that it is receiving a static multimedia file, when
it is actually receiving a live streaming broadcast.
Another popular audio and video delivery system is VDOLive (see Figure 28.8). This system is also a client/server-based system, like RealAudio and StreamWorks. VDOLive uses either a helper application or a Netscape plug-in application for audio and video. VDOLive's audio and video formats are proprietary.
Figure 28.8 : The VDOLive home page at the URL http://www.vdo.net/.
| NOTE |
VDOLive, like StreamWorks, can use an integrated plug-in for Netscape's Navigator version 2.x and 3.x. The plug-in works like the stand-alone helper application but is integrated into the browser. |
VDOLive delivers both audio and video, which is unlike StreamWorks, where you can deliver audio, video, or both. Like StreamWorks, VDOLive uses streaming IP packets to deliver the audio and video content to the client's computer.
VDOLive server software works with the following platforms:
| NOTE |
Like RealAudio, VDOLive has a personal edition, which is only available for Windows 95. It can be found on VDONet's Web site, located at http://www.vdo.net/. |
VDOLive servers deliver the audio and video content via proprietary format called VDOWave I and VDOWave II. The VDOLive Video Server can only transmit video clips that have been compressed with either the VDOWave I or VDOWave II audio codes.
The VDOLive server provides dynamic bandwidth scaling needed to maximize video quality throughout each client's connection. VDONet has also designed VDOLive to handle audio/video clips ranging from a couple of seconds to a couple of hours, serving both Internet and intranet users.
VDOLive server also include VDOLive Tools, to provide the basic capture and compression utilities to create VDOLive clips. Unlike some of the other solutions, Webmasters can also use other multimedia development tools, such as Adobe Premiere 4.2 for Windows or Ulead Media Studio.
However, unlike Xing's StreamWorks software, which can handle MPEG-1 and MPEG-2, and which, when viewed, can fill the entire screen, VDOLive can only handle 240´176 pixel resolution, which works well when placing the video actually within the Web page. For an example of this see Figure 28.9.
| NOTE |
If you receive the error message This file has an unsupported video size, you need to verify that the video clip has at least a 64´64 pixel frame dimension. The VDOLive server also has a maximum video frame dimension of 240´176 pixels. If the video is outside of those dimensions, you need to resize or recapture the frames using a digital editing software utility like Adobe's Premier. |
One of the nice features of VDOLive is the inclusion of two additional modes in which to view the encoded video. The first additional mode is the Storybook mode. In this mode, by using VDO Tools, you can synchronize static images to an audio track. This mode works well for presentations.
Another mode is the Flipbook mode. This mode reduces the frame count to provide clearer images. You still get an effect of full motion, however, it is not smooth. It works well in a tutorial type of Web-based application.
If you are using Netscape Navigator version 3.0, when you download the VDOLive player and run the setup, it automatically registers the .Vdo file type in the MIME configuration register.
Microsoft Internet Explorer If you use Microsoft Internet Explorer version 2.0, you get an error message the first time you click an HTML link to a .Vdo file. As a matter of fact, you get the Unknown File Type dialog box. To correct this, follow these steps:
Now, the next time you click a .Vdo link, the browser brings up the VDOLive player immediately. But, if you have downloaded the VDOLive player, and want to set up support for the .Vdo files while you are offline, you need to follow these instructions:
Now, the first time you click a .Vdo link in an HTML document,
you get the Confirm File Open dialog box. You can then uncheck
the Always Warn About Files of This Type check box. Then, click
the Open File button and you are ready to view inline VDOLive
files.
| NOTE |
The MS Explorer uses the standard Windows 95 file type registration to associate .Vdo files with the VDOLive player. |
VDOLive server software is also a commercial product. The pricing
of VDONet's VDOLive server is based on the number of concurrent
data streams that you need to handle. For example, the minimum
price is $995 for five concurrent streams. However, basic support
has a minimal annual cost of $360. At maximum cost, you can spend
$11,995 to handle 100 concurrent data streams, plus an additional
$3,599 for support, which gives an initial cost of $15,694. See
Table 28.3 for VDOLive software pricing at the time of writing.
| Concurrent Streams | Price | Basic Annual Support |
| 5 | $995 | $360 |
| 10 | $1,995 | $599 |
| 25 | $3,995 | $1,199 |
| 50 | $7,495 | $2,249 |
| 100 | $11,995 | $3,599 |
VDOLive based files are slightly different than the other method of Web page integration. With .Vdo files, you can actually use the HTML command to embed the audio/video files. Look at the following code:
<EMBED SRC="http://uttm.com/vdo/cbs0.vdo" AUTOSTART=TRUE STRETCH=TRUE WIDTH=178 HEIGHT=155 ALIGN=TOP ALT="You need the VDOLive Plugin to view this file">
This is the code that generates the VDOLive inline audio and video shown in Figure 28.9. When Netscape Navigator receives this line of HTML code, the browser parses the HTML code. Based on the HTML code, the browser reserves a space of 178 pixels wide and 155 pixels high on the rendered Web page.
The browser then requests the file /vdo/cbs0.vdo from a Web server located at uttm.com. Now, when the browser gets this .Vdo file, it looks up the MIME type. The browser then sends the .Vdo file to the appropriate plug-in application. In this case, the browser sends it to the VDOLive plug-in.
At this point, the VDOLive plug-in parses the .Vdo file and then sends the request for the encoded audio and video file from the VDOLive server that is referenced in the .Vdo file.
Because the received file is an embedded VDOLive file, the VDOLive
plug-in displays the contents of the encoded file as it is being
received. And like all streamed media, the received information
is just dumped into Never Neverland after it is received, also
known as bit bucket or /dev/null. So the received file
takes up no hard drive storage and makes it nearly impossible
to replay the files-unless the file is stored in an archive somewhere.
| TIP |
I highly recommend that you create an online archive of important live streamed events or reports. You can then add a library containing the prerecorded files that visitors can access. Think of this as television reruns, or newspaper archives. Not everyone will have seen or heard your streamed event the first time, but you give them the chance to see it at a later date. |