Streaming video and video on demand:
part of the new warfighting requirements

by LTC Jeff Girard

It�s a fact of life. Video streams in all their forms and sources are becoming a fixture in modern tactical-operations centers. Video streams are being used to pass intelligence, collaborate over plans, monitor public opinion, keep abreast of world news and even to entertain.

Most Signal officers who have been �raised� on mobile-subscriber-equipment networks shudder at thoughts of streaming video as they think of its impact on the relatively small datalinks in the area common-user network. I contend, however, that as automation officers, our job is to provide these resources to our customers. It�s our responsibility to devise ingenious and unorthodox solutions to achieve our commanders� requirements.

This article outlines how the Division Automation Office of 10th Mountain Division (Light Infantry) achieved those goals as part of the Coalition Forces Land Component Commander-Forward headquarters in a forward-deployed theater of operations supporting Operation Enduring Freedom. We devised, engineered, implemented and maintained a media server that delivered high-quality video and audio streams directly to the individual soldier�s laptop computer in his work area without any negative impact on the network, infrastructure or TOC bandwidth.

The key to our ability to provide our customers these video services is that we�ve migrated our TOC infrastructure from a hub-based to a switch-based architecture. As the following figure indicates, the TOC infrastructure provides for dedicated 10/100 megabits per second auto-sensing ports to every laptop and workstation in the TOC.

10th Mountain Division TOC infrastructure 10th Mountain Division's TOC infrastructure. The boxed area at the illustration's top shows the setup inside the data-management facility truck, mounted on 19-inch racks.

The theory behind the media server�s implementation is straightforward. A video or an audio stream is identified as being important to the commander and/or staff. These signals are then fed into the media server and are �captured.� A combination of specific hardware and software is then used to digitize these media streams and process them into a format that can be broadcast from the media server as digital packets of information. These packets are then immediately rebroadcast out of the server (in the case of a live-stream broadcast), or they are stored on a file server to be recalled and viewed at a later time (as video/audio on demand). In either case, these media streams are delivered via the TOC infrastructure to the individual�s laptop and are delivered to the user as streaming video using specialized software on the client machine.

The details of this process and the hardware/software required will be covered later in the article. The following figure shows a simple block diagram of the theory.

Media server theory Block diagram of theory behind implementation of the media server.

Media server�s �nuts and bolts�

This section will focus on the physical, electrical and procedural implementation of the media server in the TOC. The next section will outline our future plans for other connections and enhancements.

The only �feed� for the media server was the Armed Forces Radio and Television Service. An earth station near our TOC received the AFRTS signal. Installed inside the TOC was an AFRTS receiver � the point-of-presence for the media feed.

The physical connections began with this AFRTS receiver. From the AFRTS receiver�s output, the RG-59 coaxial cable went into a six-way splitter, each port of which led to a television set somewhere in and around the TOC area (battle-management element, commanding general�s office, public-affairs cell, distinguished-visitor quarters, commanding general�s sleep hooch, and the last port fed my media server). The RG-59 cable from the splitter was fed into the data-management facility that houses the media server. The RG-59 cable was connected to the input of a commercially available videocassette recorder/player.

Previously we had installed an Osprey-100 video-capture card into one of the server�s peripheral-component interface slots using software included on the installation compact disk. We used one-half of a standard Radio Corporation of America patch cable to connect the VCR�s video outport to the VCC�s Composite Video 1 jack.

We had also previously installed a SoundBlaster sound card into another of the server�s PCI slots using software included on the installation compact disk. We then used the other half of the standard RCA patch cable to connect the VCR�s audio outport to the sound card�s line-in jack. We had to install and use an adapter to adapt the physical connector from a female RCA to a 1/8-inch male mini-plug to connect to the sound card.

The server hardware we used was a Pentium III 633 megahertz processor with 256 megabytes of random-access memory and a 13-gigabyte hard drive. The server was running the Windows NT 4 server operating system as a backup domain controller. A detailed wiring diagram is at Figure [xx � girard3.tif 5�].

Media server wiring diagram Media server "wiring diagram."

The media server�s heart is the collection of software programs that capture, digitize, manipulate and serve the streams captured by the video and audio devices. Initially we chose the Real System package, although we later migrated. (That migration is discussed later in this article.) This software is also commercially available. The package includes two products called Real Producer and Real Server. The Real Producer software package received the media streams from the capture devices, digitized them, modified the information into the proprietary Real Media format, and then either stored the file to the hard drive or handed it off to the Real Server package if it was a live broadcast. We provided access to the media server via links from our webserver.

We began our testbed very simply. Our first test run was to rebroadcast the live stream we were receiving from the AFRTS feed over the TOC local-area network to the individual computers. This proved to be fairly simple and straightforward. Our second trial was to capture and record a newsclip from AFRTS, store it to the file server and then rebroadcast the file out as video/audio on demand.

After some trial and error, and understanding the ports being used by the software packages, we were able to rebroadcast the newsclip to multiple computers in the TOC as video on demand. Also, we found we were able to provide multiple iterations of the same recorded stream simultaneously, all being initiated at differing times and all streaming independently of each other.

We concluded our testing by connecting multiple computers to the live stream and multiple computers to the prerecorded stream, and confirming that each was operating satisfactorily and independently of each other.

After testing was completed, we integrated access to the media server via our webservers. We built a new webpage to support the media server and built various links. One link was to connect to the live broadcast stream, and the other links were to connect to recorded files stored on the file server.

After our great initial success, we decided to spread our wings. We took a blank videotape and recorded a portion of the news from the AFRTS feed. We then played that tape of the newsfeed and repeated the same tests as outlined previously. We were able to not only broadcast the VCR tape source as a live stream but also save the file to the hard drive for delivery as video on demand.

There are a great many uses for a system such as the one described. The options are really only limited by your video/audio sources and your imagination. I�ve outlined some potential uses:

 Live-stream news networks � yes, it is a reality and yes, it is a requirement. Commanders and staffs require news networks (for example, Cable News Network, Fox News Network, MSNBC, AFRTS). Not only is news used as a source of intelligence, it�s also one of the best means of gauging public opinion about military actions both at home and abroad. CNN can be brought into a TOC in variety of ways (small dish-satellite systems such as DirecTV), AFRTS networks and possibly a feed from Global Broadcast Service ground stations.

 Live-stream briefings � does any TOC have a location big enough to host all the people who show up at an operations-order briefing? Normally there�s only room for the commanders and primary staff officers. The solution is to set up a small camcorder on a tripod in the area and rebroadcast the live stream so battle captains and staff noncommissioned officers are able to hear the commander give his intent as well as hear the discussions first hand. All from the comparative comfort of their own work areas and laptops.

Consider all the briefings given repetitively such as newcomer�s briefings, commander�s welcome briefing, operations-area orientation, safety films and training tapes. Do you need to ensure all your soldiers watch an important training video on how to properly ignite an immersion heater? How are you going to train all your soldiers in a tactical environment where no one has a TV? All these materials can be recorded and preloaded on the file server, where they are accessible to soldiers 24 hours a day from their own workstations.

Record, store and play on-demand briefings, rock drills, etc. Consider the OPORD briefing discussed above. How many times have you had to go back to the boss and have him repeat something he said in the briefing? Wouldn�t it be nice to be able to review the 30-minute intelligence update at your leisure, when you can concentrate on the details you missed the first time? Wouldn�t it be nice to be able to give the G-3, G-2 and commander the ability to review the rock drill several hours after it has taken place and see how the plan will be impacted by new intelligence that has been developed?

The work described previously was a proof-of-concept and trial run based on a Windows NT operating system. We then investigated a Windows 2000-based server. We found that Windows 2000 server software has media production and serving software bundled in. Also, the Windows Media Server saves and produces streams using the Windows Active Streaming Format. The Windows Media Player software is bundled in as a component of all Windows operating systems, and this player reads the ASF format. Upon investigation, we found that WMS offers a very powerful producer tool and many alternatives in capturing and digitizing the media streams.

Through testing and use, we were able to identify some pitfalls with the hardware platform upon which we chose to execute this proof-of-concept. As this was proof-of-concept testing, we used a hardware platform we had readily available. The main shortcoming we found was that the server was underpowered. We used the same hardware platform to produce and serve the streams. We found that the single processor on our testbed machine was almost constantly performing at 100 percent of its central-processing-unit processing power.

These two functions (production and serving streams) don�t have to reside on the same platform, and the documentation actually says you will achieve better performance if these functions reside on different platforms. However, as money is a limited resource, we feel that one high-powered server should be able to adequately perform both functions. Following are the details of what we feel is a solid platform to be used as a dedicated media server:

Minimum dual P4 processor, recommended quad P4;

256 mb RAM;

100 mb network-interface card;

Appropriate number of PCI slots, determined by your intentions;

Hard-drive storage commensurate with your intentions. Through testing, we determined that a 30-minute full-motion video recorded at 30 feet per second requires 60 mb of storage space.

There are several brands of commercially available VCCs. Some cards allow multiple inputs to the single card. You must have enough capture ports to accommodate all the streams you expect to capture simultaneously.

As with the VCCs, there are several brands of commercially available sound cards. Again, if you intend to capture multiple streams simultaneously, you must have an audio-capture device per simultaneous stream.

We found two alternatives for media-server software, although there may be others. The first is the Real Systems product, and the second is the WMS bundled with the Windows 2000 server operating system.

What about the impact of video streams on throughput on the TOC LAN? The short answer is that the impact on the TOC LAN is so low it�s negligible. As previously described, we�ve installed a 100-mbps switched architecture throughout the entire TOC. This effectively creates a dedicated 100-mbps path from every machine back to the server farm in the DMF truck. Streaming video packets intended for one machine have no impact on other machines� ability to access the webserver, email server or wide-area network.

We�ve set our server to stream the live-video feeds at 500 kilobits per second and to stream the video-on-demand files at 300 kbps. The live stream is delivered via a broadcast stream to all recipients. This means that for the live stream, the number of recipients is immaterial; the stream is fed onto the network at 500 kbps regardless of the number of clients receiving the stream. The video on demand, however, is a unicast stream. Each client registers with the server software and requests to have a stream delivered from a stored file. As I said, this stream is delivered at 300 kbps.

I�ve analyzed the division�s network use via tools at my own workstation. The result was that over the entire period we had the media server operating, use of the link from the server to the DMF switch never exceeded 5 percent.

As I mentioned, the key to our ability to provide this service is that we have the switch-based architecture to support it. Access to the media server was obtained via links off the CFLCCFWD webpage � and therefore was easily accessible to anyone who could reach our homepage.

We were very cognizant of this fact and wanted to ensure the streams wouldn�t cross the WAN. This would ensure that users located on a hub-based network wouldn�t be allowed to disrupt that network by effectively denying access to other users on that collision domain. Therefore we implemented control measures to ensure that the streams didn�t leave the electrical confines of our TOC and that only authenticated domain users were allowed access to the media server.

We used a defense-in-depth scenario to accomplish this mission. First, we applied an access-control list to the router WAN ports. On this access list, we denied all packets that were sourced from the media server�s Internet-protocol address. As the media server provided no other functions (for example, domain controller, domain-name service, Windows Internet Naming Service), we were assured that the only packets leaving the media server were streaming video packets. By implementing an ACL on the router�s WAN ports, we filtered all these packets and prevented them from leaving the TOC edge-device router.

The second control measure we implemented was to only allow authenticated domain users access to the stored files. The third control mechanism we implemented was to deny access to the files and directories by restricting access to only those specific IP addresses authorized within the CFLCCFWD TOC.

Future connections, enhancements

I think everyone agrees the media server is a huge success and a great asset to the TOC. Our first future action is to build a dedicated media server. As I reported, this was a proof-of-concept test to assess the system�s viability. With the success we�ve achieved, our first post-testing mission is to resource and build a dedicated media-server machine that will be able to handle the anticipated load.

Our second objective is to interface the media server with the Army�s GBS Transportable Ground Receive Station. The 10th Mountain Division is scheduled to receive an advanced fielding of two systems in July. We intend to interface the output of the Receive Broadcast Manager as one of the dedicated inputs into my media server. In this way, we�ll be able to rebroadcast the feeds TGRS receives to the entire TOC. We�ll use the RBM as my point-of-presence for the video and audio feeds.

A third future enhancement to the system is to interface the output of the battlefield videoteleconference system and the media server. In this manner, people would be able to monitor the BVTC but wouldn�t be able to participate directly. This would enable everyone within the TOC to be an audience member of the BVTC session as it was occurring. Again, when one considers the physical-space limitations inside a TOC, one can understand how this would be an asset.

Pushing the technological edge

Streaming video and video on demand. These terms were, and in many places still are, profanity in the Signal community. �It will hog all your bandwidth,� �your network will self-destruct� and �it�s not possible with MSE� were phrases commonly associated with any of our discussions on streaming video. In many cases, these statements are still valid. However, it�s my belief, that as automators and champions of the digital world, it�s our duty and responsibility to push the technological edge. We should be focusing our efforts to find ways to achieve the end instead of becoming complacent with the status quo.

I�ve attempted to outline for you how we were able to provide streaming video within our tactical TOC. By investing a relatively small sum of money, we were able to greatly enhance operations within our TOC. I hope this article will help you do the same.

As I close, I want to acknowledge a soldier who was instrumental in developing this media server. I put SPC Michael Jory, a 74B, in charge of this project, provided him the resources and gave him the mission guidance, and he took charge from there. Jory was responsible for �building� the media server and for learning and understanding the software programs� intricacies. He was also responsible for most of the testing described in this article. I attribute the great success we�ve enjoyed in developing and using this server to his technical abilities and desire to succeed.

LTC Girard has been 10th Mountain Division (Light)�s division automation-management officer since 2000. His previous automation assignments include chief of artificial intelligence and networking at 111th Military Intelligence Brigade, Fort Huachuca, Ariz. His previous Signal assignments include Signal platoon leader, company commander, assistant S-3, S-3 and Signal battalion executive officer. He spent five years as a Signal staff officer for infantry and armor battalions and brigades. He has participated in three rotations to the National Training Center at Fort Irwin, Calif., and two rotations to the Joint Readiness Training Center, Fort Polk, La. He holds a master�s degree in artificial intelligence from Duke University.

Acronym quickscan
ACL � access-control list
AFRTS � Armed Forces Radio and Television Service
ASF � Active Streaming Format
BVTC � battlefield videoteleconference(ing)
CFLCCFWD � Coalition Forces Land Component Commander-Forward
CNN � Cable News Network
DMF � data-management facility
GBS � Global Broadcast Service
IP � Internet protocol
Kbps � kilobits per second
LAN � local-area network
Mb -- megabytes
Mbps � megabits per second
MSE � mobile-subscriber equipment
OPORD � operations order
PCI � peripheral-component interface
RAM � random-access memory
RBM � Receive Broadcast Manager
RCA � Radio Corporation of America
TGRS � Transportable Ground Receive Station
TOC � tactical-operations center
TV � television
VCC � video-capture card
VCR � videocassette recorder/player
WAN � wide-area network
WMS � Windows Media Server

dividing rule

Back issues on-line | "Most requested" articles | Article search | Subscriptions | Writer's guide

Army Communicator is part of Regimental Division, a division of Office Chief of Signal.

This is an offical U.S. Army Site |


This is an offical U.S. Army Site |