Everyone knows that broadcast-quality digital video files are too large to handle over a corporate LAN running 10 or 100 mbs Ethernet. That’s why television stations use Fibre Channel running at 1gbs to connect digital broadcast servers, such as the Leitch VR-300 server and NewsFlash editing system. Video systems with a client/server architecture present a tremendous advantage in the creation of television news programming and play-to-air because a single high-quality digital video file residing on the server can be shared among multiple users. In a true client/server design there is no need to wait while a video file copies from an editor to a play-to-air server. It is the same file.
Unfortunately, the expense of high bandwidth pipes and video mainframes discourages the widespread deployment of client/server video editing. It is simply too costly for most TV stations to provide an editing station to every journalist. The result is a traffic jam in the edit suites as too many users want access to too few machines. What would be ideal is if every journalist could have his or her own inexpensive client-based video editing station running on the PC already on their desk, and have the video files available from a server using the existing corporate LAN. An adaptation of an advanced technology developed for commercial database servers actually makes this possible.
For many years there has been a technology in database servers called the replication server. A replication server keeps a copy of the data on a server so that if that server would fail or lose connectivity to remote users it would still be possible to continue business as usual by connecting to the alternate database server. The design of such a system presents a challenge because when the connection between servers is later restored they must automatically resynchronize their data. A typical application would be for a company that has a server on each coast handling sales orders. The servers must track each other so that more items aren’t sold than exist in inventory even if the two servers temporarily lose contact with each other.
What makes replication servers relevant to video mainframes is that except when playing to air most video users don’t have the requirement that the replica be a perfect copy. On a broadcast server video is typically encoded at bitrates from 24 mbs to 48 mbs, while on a web server the same video content is encoded in MPEG-1 at 1.1 mbs (or less). This MPEG-1 video has a picture quality roughly comparable to VHS SLP-mode. That isn’t good enough for broadcast, but is quite adequate for shot logging and rough cuts.
Combine the facts that MPEG-1 can be effectively transmitted over conventional corporate LAN’s and will play back in Microsoft ActiveMovie which is included with Windows and things become very interesting. All that is required is to keep the broadcast server and the low bitrate replication server in sync. The web server recorders do this automatically. Any content changes made to the broadcast server will be mirrored in the databases and MPEG-1 files on the web server. The users access the high bitrate version for play-to-air or the low bitrate version for distribution to the desktop.
The hottest trend in desktop interface design is to use Java applets. Java has the advantage of running on almost any platform. Using Microsoft Internet Explorer (which is included with Windows) or Netscape enables the user to access the replication server without installing any additional software on the client machine. Java applets are programs that reside on the server but are executed on the client in the browser. For network systems administrators this greatly simplifies their world because they never need to install new versions of software to the users’ desktops. Upgrades are made at the server and everyone is inherently running the same version of the software.
Java has other advantages. Unlike most languages, with Java the same software will run on multiple platforms. Windows machines, Macintoshes, and Unix-based workstations all run the same Java applets. The network administrator installs just one version of the Java applet to support all these platforms. All platforms run the same program and users avoid the headache so prevalent in the Mac/Windows world of one platform supporting a newer version than the other.
Even though MPEG-1 files are relatively small as video files go, these are still huge files to routinely move across a corporate LAN. An MPEG-1 file is typically compressed at about 10 MB/min. A three minute spot is therefore 30 MB in size. In studying how users manipulate video files for editing, much of their time is spent scanning for the appropriate footage and marking in and out points. Using a filmstrip representation of the video enables these tasks to be done without transmitting the MPEG-1 files.
In effect yet another replication database is kept of the video, but this time as JPEG thumbnails sampled at one frame every two seconds. Each JPEG still image is about 2k in size. A three minute spot is therefore roughly 200k in size as a filmstrip, and 30 MB in size as an MPEG-1, and 550 MB in size as the original high bitrate digital video on the broadcast server.
Keeping three copies of a video obviously takes more storage, but the relative sizes of the copies at 5.5% and 0.04% respectively makes that insignificant. In fact, holding the copies after the originals have gone to tape archive is practical.
This architecture diagram provides an example of how these components may be laid out. Each browse recorder is connected to a broadcast video server. This browse recorder can march in lock step with the broadcast server recording the same clips as they are being ingested. Or, if the web server and broadcast server lose synchronization with each other the browse recorder can take machine control of the broadcast server to play out the missing segments or edited videos back into the web server.
The browse recorders place the MPEG-1 data and the JPEG stills onto the web server. A database is also created there to provide the data the Java applets need to display at the client desktops.
VANA is a video cataloger compatible with web-based architectures (see architecture figure). A video cataloger is conceptually the reverse of a browse editor in that it takes completed television content and disassembles it back into individual stories. It can take a network news broadcast and dice it into each individual story so that it can be keyword searched. This enables news analysts to query broadcast television content as conveniently as they would a web site. For example, the user can instantly retrieve a list of today’s broadcast news stories that contain the word "president."
This replication strategy has important implications for HDTV. Replication databases can mirror video encoded at any resolution or even film. A browse editor can easily support letterboxing at 16:9 and Panavision aspect ratios. And, NTSC and PAL are both converted into MPEG-1 enabling the same browse system to support many video standards interchangeably. No matter what the source format, the result is the same international-standard MPEG-1 video files that can play back on any PC.
With HDTV moving the video around the TV station is a huge cost. Once again it requires Fibre Channel connectivity or something like it to have adequate bandwidth to move such massive files. The expense of routing HDTV video everywhere in the manner in which stations have become accustomed to with analog television has discouraged some TV stations from embracing HDTV in the near term. However, with browse editors the amount of high bitrate routing needed is decreased.
The MPEG-1 replication copies can travel across the existing corporate LAN while keeping the HDTV video mainly in the central rack room. As edits are applied to the MPEG-1 clips the EDL (Edit Decision List) is propagated back to the original high resolution video. The EDL is simply a list of the names of the video clips being assembled with their in/out points and related data. In other words, it’s just a text file.
Using an EDL to synchronize edits across video replication servers means that users may detach from the network and carry the browse editor with them on their laptops. In conventional replication databases this same approach is used so that traveling sales reps can take orders without being continually connected to the server. Each day the sales rep dials up the server and reserves the stock he expects to sell that day keeping those items in a subset replicated database on his laptop. After taking orders during the day on the laptop its replication database is relinked temporarily with the main server and the two systems resynchronize. Likewise, an editor can copy to his laptop those files he expects to edit. Later the extremely lightweight EDL can be emailed back from the detached laptop to the server (even using a two-way pager) and applied against the original footage there.
Handling video content efficiently makes it practical to have the browse editor user connected by ISDN or cable-modem to a distant browse server. A TV station with a news bureau in another country could access their browse database remotely to extract just the video clips they need. Even though the resultant high bitrate video edit would be pretty big, it may be cheaper to send electronically by ftp than the alternative of putting a tape in a bag and having a courier deliver it.
By trimming the video duration down to the exact footage needed, it becomes practical to browse content over conventional communications infrastructures. For instance, a TV station in Manhattan could connect to its archive in New Jersey and cherry pick just the right clips to bring back. Even if a courier (sneaker-net) approach is more economic for transporting video in a particular situation, having a lightweight remote browse capability into the archive is a tremendous improvement for selecting what footage to have fetched back.
