Preparing video for the Web

Expectations should shift from the quality expected in the broadcast world to what is acceptable to an Internet viewer. Broadcasters face a number of
Author:
Publish date:
Social count:
0

Expectations should shift from the quality expected in the broadcast world to what is acceptable to an Internet viewer.

Broadcasters face a number of variables as they select a technical solution to deliver video assets over the Internet. Broadcasters must consider streaming formats, data storage strategies, live streaming vs. video-on-demand strategies, reporting techniques, encoding bit rates, ad serving, costs and bandwidth. By closely examining the options available for anyone looking to make local-content Web channels available, many of the difficult decisions can be demystified.

The process of making video available on the Internet is in two stages for the purpose of this discussion: acquisition and delivery. Acquisition encompasses how the video is routed to the capturing system, edited and encoded into Internet-friendly formats. Delivery is just that — how the video stream is distributed to viewers. From acquisition to delivery, it is critical that expectations are shifted from the quality expected in the broadcast world to what is acceptable to an Internet viewer. A great deal of money can be spent trying to improve quality at each step of this process — quality that after encoding for delivery is hardly distinguishable. Consider that fact in any discussion of the economical methods of bringing video to the Internet.

The first questions to ask during the acquisition phase concern the daily workflow for the video handlers and what sources of video will likely be used. In one model, a journalist receives video from several sources, including line-level feeds, RF and tapes in various formats. As newsrooms migrate to digital platforms, there is access directly to the video servers as well. In this model, it is key to ensure the quality of the input signals — a good, clean RF feed works well. If encoding bit rates are going to be below 200K, there is no difference between line-level input and RF. Even at 300K, the differences are minimal. If the input signal is not clean, the quality will only worsen as acquisition proceeds, and nothing can be done to compensate for further degradation in quality.

The selection of the encoding and editing platform is dependent upon the skill and experience of the individual who will be doing the encoding. If that person is not a video journalist, but instead is from the Web-publishing world, a consumer-grade video editing package should be used, as the individual will only be selecting entry and exit points in the clips to be encoded. The captured segments are encoded into an MPEG file as an intermediate step for reasons discussed below. However, if a skilled video editor is available, many broadcast-quality video editing packages are capable of publishing into multiple, Web-ready formats. In terms of quality and workflow, this is often the optimal solution and should be pursued if available.

Now that the video has been edited and captured, the final step of the acquisition stage is to encode it in a format for viewing on the Web. The two most popular streaming formats are from Real and Microsoft; QuickTime is a distant third. Encoding into multiple formats will allow more users to see the posted video, as not everyone is capable of viewing every format. Choosing an appropriate bit rate is key. Minimally, choose one that is modem-friendly — 28K or 56K — or that gives a higher-quality experience like 128K. If resources are available, 300K is a popular next step and yields strong results. There are clear cost trade-offs here: The higher the bit rates and greater the number of streaming formats, the more expensive it will be to create and serve video.

Delivery

The second step in publishing video to the Web, delivery, is the process of distributing encoded video to the public.

The most important technical aspects of choosing between serving video internally and outsourcing are access to reasonable bandwidth (routers and switches of adequate capacity as well), and the ability to load balance the video servers for scalability and reliability.

Serving video is expensive, as is the disk space to store it. It uses significantly more bandwidth than traditional Web serving, especially at higher bit rates. Whereas a single T1 can serve a number of Web pages, just 10 simultaneous video streams can saturate it, rendering an entire website useless if it is sharing the same bandwidth. IBS regularly sees five- to tenfold traffic increases on breaking news days, the same days that it is most important to be up and serving. It would most likely be cost prohibitive for a smaller bandwidth consumer to maintain the necessary overhead to cover large spikes in traffic. Shop around before taking on the ambitious project of internally serving; it is a consumers' market for outsourced serving of video. Many of these vendors have effective methods of delivery that will provide the user with a superior overall viewing experience.

Other considerations

There are other important issues related to video serving that complete the environment, including ad serving, traffic reporting and live streaming.

The ability to serve ads with the video streams is an important consideration to serving video, especially if it is part of the revenue model. In addition to several outsourced solutions, there are stand-alone packages on the market that are capable of inserting ads as well. Consider where in the video stream the ad is to be inserted, how buffering is handled and product scalability — not all products are created equal. Outsourced solutions will often prove most economical for low-volume applications.

Consider traffic statistics when creating a video-serving environment. Traffic reports (including streams served, average length of stream served, media player and abandonment rates) are helpful in characterizing video usage and identifying problems. The ability to measure server and network traffic is vital for capacity planning as well as for identification of trends. Several stand-alone monitoring packages and outsourced solutions are available.

Until this point, discussion has centered on video-on-demand vs. live streaming. The principles are the same: ensure a quality input signal, encode into as many formats as is practical and point the resultant streams at servers that will be available and can handle the load.

For broadcasters, making video content available for the Web does not have to be excessively expensive or complex. Key issues are to identify realistic requirements for video acquisition and delivery quality, reporting and ad serving that meet the individual broadcaster's budget and business requirements. While getting started, do not hesitate to outsource all or some of this process to not only to get serving video more quickly but to learn from the experiences of others, ensuring a successful implementation.

Dave Abbott is chief technology officer for Internet Broadcasting Systems.