There are two groups of internationally accepted standards for video representation, the ITU-T recommendations H.261 and H.263, and the MPEG series. Both groups are represented on the Internet today: The ITU-T standards are implemented in video conferencing software along with ``moving JPEG'' and proprietary formats, while the two first MPEG standards, MPEG-1 and MPEG-2, typically are used for storing prerecorded video sequences. Freely available software encoders and decoders are available for both H.261 and MPEG, making it unnecessary to start entirely from scratch when implementing Web based services featuring these standards.
General data transfer methods may be used for video on demand systems when real-time play during transfer is not critical, that is, when the entire movie is downloaded to the local system before being played. General methods may also be used when the available bandwidth is sufficient to play the stream at real-time without modifying the quality of the movie.
Methods specialized in negotiating transfer options to cope with varying bandwidth exists, but most of them are either proprietary, or not through the entire standardization process. When using the Internet for video conferences, one also needs a set of protocols not directly related to video; protocols for session management.
Several mechanisms are available for extending Web browsers to support initially unsupported media types in general, and video in particular. The more promising methods seem to be plug-ins and Java applets, both supporting full integration within the browser window, and both being available in the more widely used browsers. A plug-in and a Java applet for video were implemented. The plug-in is capable of playing MPEG movies embedded in Netscape Navigator, while the Java applet receives and displays live video from a remote camera. The plug-in and the applet show that making video available from Web browsers is indeed possible, and not considerably harder than making a stand-alone video handling program.
A natural starting point for further work, is to extend the two programs implemented to make them fully usable. One of the main features lacking from both programs, is the ability to play audio along with the video. When combining video and audio, one has to take care of proper synchronization. For MPEG, synchronization issues are addressed in a separate part of the standard. For H.261/H.263, who are concerned with video only, audio and synchronization are specified in separate recommendations.
For full integration of various kinds of video inside Web browsers, some work will have to be left to the browser developers. The current plug-in model is built on the thought that what is transferred comes from a file on the remote end. The browser takes care of the transfer protocol details, and hands a stream of bytes to the plug-in that has announced it's capability of displaying the file type in question. Live video is typically not streamed, and real-time play requires continuous negotiation between the sender and the receiver, requiring other protocols than those used for regular file transfer. An extended plug-in model should not only allow plug-ins to announce what file types they can handle, but also any built in protocol support. Instead of sending a stream of bytes to such a plug-in, the browser would pass the URL, and leave it to the plug-in to parse it and take care of the communication.
Some extensions to the current Java API could simplify implementing video receivers. Writing decoders in Java is possible, but it is unclear how fast a pure Java implementation will be for the relatively advanced algorithms needed for H.261 and MPEG. Standardized class libraries for H.261 and MPEG would be very helpful, and could make access to hardware coders/decoders transparent to the user. Another useful approach would be to define classes for the CPU intensive tasks, such as the DCT transforms, motion compensation and statistical coding, and build coders and decoders using these tools. In addition, being able to grab video using Java without any user installed native code libraries, requires definition of classes for handling video camera input.