A Video-on-Demand VCR Interface

1995, BellSouth Interactive Media Services
Comments only; no documentation available.

Problem

Enable cable-television customers to play video-on-demand (VOD) movies.

In particular, enabled customers to do this their televisions, a custom-built cable TV box, and a standard-looking remote control with VCR (video-cassette recorder) buttons on it — play, pause, fast-forward, rewind, and stop.

Solution

The software I wrote enabled the customer to control a digital-video server. In general, this meant that when the user pressed the "play" button, I started streaming a particular MPEG file from the server. Many things had to be "faked," though.

For example, "rewinding" and "fast-forwarding" were an illusion; the video server did not support those concepts. Instead, the server contained three files for each movie. One file contained the movie itself; the other two files were "fast-forward" and "rewind" versions of that movie, containing only 1 out of every 10 frames in the original file.

The server's API allowed me to jump to a particular spot in a file. When the customer pressed the "fast-forward" button, I...

• noted how much the original movie had been played.
• stopped the Play file.
• loaded the matching Fast-Forward file.
• jumped to a position in that file proportional to the amount of the movie that had been played.
• started playing the Fast-Forward file.

When the user pressed the "play" button again, I did the same thing: determined how much of the fast-forward file had been played, stopped the FF file, went back to the Play file, jumped to a proportional position in the Play file, and began playing it again.

The project was challenging, in part, because all the software and hardware were experimental — custom operating systems, custom development environments, hand-soldered cable-TV set-top boxes, and so on. See Environment, below, for more information.

HCI Notes

I present this as an example of HCI because I went to some lengths to ensure that the VCR controls appeared to behave exactly as they do on an analog video-cassette recorder. This allowed customers to simply use the system, instead of thinking about it, calling for help, or reading an owner's manual.

For example: on an analog VCR, when you rewind the tape — using the "rewind while playing" mode, so that you actually see the movie playing backwards — the tape stops rewinding when it reaches the beginning. Then, when you press the "play" button, the video simply starts. On the VOD system, "rewinding" actually meant playing the Rewind file all the way to it's end; the Rewind file contained all the same frames as the Fast-Forward file, but in the reverse order. So when a user "rewound" to the "beginning" of the movie, I made the movie ready to play again: I stopped the Rewind file, loaded the Play file, and paused it immediately. Thus, when the customer hit the "Play" button, there was the shortest possible delay before the movie began again.

As another example: I provided standard VCR-like on-screen controls when the customer pressed the buttons on the remote control. If the customer pressed the fast-forward button, I displayed a copy of the remote control's FF icon on the screen. If the customer then pressed the Play button, I displayed a copy of the Play button until the movie began playing again, kept it visible for another 5 seconds, and then removed it.

The Project

The VCR interface was part of a full-fledged interactive-television system, offering an video on demand, near-video-on-demand (like today's pay-per-view), an interactive Prevue guide, and more. BellSouth Interactive Media Services was a division of BellSouth created to provide this service.

I was part of the 3-person team that wrote the Navigator, the customer's TV interface to the system. The Navigator contained many features, including the VCR controls described here.

Environment

The Navigator, including the VCR interface, was written in Gain Momentum, using its object-based Gain Extension Language (GEL). Gain was originally a Unix product very similar to Macromedia's Dreamweaver. By the time we were involved, it had been ported to PowerTV, the operating system used on our custom-built set-top boxes.

The Gain Momentum port, called Gain Interplay, was still very much in development when we began using it to build and test the Navigator. So were the video server, the set-top box, the operating system, and the hardware and software of the network itself. This made the project very interesting, since most of the tools we were using were still being developed while we were using them. For example, throughout much of the project, "debugging" involved rebuilding the operating system (with the Navigator inside it), burning the operating system onto a set-top box, turning on the power, and seeing where it crashed.

I eventually took over the source-code development for Gain Interplay, as well as the Navigator. Interplay was written in C.