Inline Video - A New Application for Standard Mechanisms

Heiner Wolf, Abteilung Verteilte Systeme, Universitaet Ulm, D-89069 Ulm
wolf@informatik.uni-ulm.de http://www.informatik.uni-ulm.de/fakultaet/abteilungen/vs/Mitarbeiter/Wolf.html
Konrad Froitzheim Abteilung Verteilte Systeme Universitaet Ulm D-89069 Ulm
frz@informatik.uni-ulm.de http://www.informatik.uni-ulm.de/fakultaet/abteilungen/vs/Mitarbeiter/Froitzheim.html
Keywords:
GIF
Inline Video
cgi

Extended Abstract:

Introduction

HTML 2.0 conform WWW-pages currently contain text, graphics and dialog elements. Presentation of other data and media is restricted to external viewers. Usually, the presentation of such data begins after a data unit, e.g. a file, has been completely retrieved from a server. Thus contignuous media cannot be put directly (inline) on a WWW-page. A WWW-page has to be reloaded entirely, in order to get an updated view [Crocker94]. Discussions are going on about inline media other than graphics, like audio [Uhler94] and video. How this can be done is still subject of active research. New protocols, protocol elements and extensions to HTML have been proposed to achieve this [Soo94][KaasPinTaub94]. However, changes to existing standards which are widely and intensively used should be made very carefully. If possible, they should be avoided altogether. We therefore suggest that all capabilities of accepted standards be made use of first.

The demonstration presents a way to include moving images into ordinary WWW-pages without changing existing standard. It is based on the capabilities of the widely used GIF image encoding (Graphics Interchange Format [GIF87]) and of the HTTP-protocol.

Realization

The recent GIF specification allows not only the compression of still images. It specifies the encoding of a sequence of consecutive images. Images may replace each other according to the order in which they are decoded from the data stream. Many publicly available GIF-viewer support this feature. It is indeed possible to present a kind of movie with these viewers. Thus the principle of integration of a GIF coded image sequence is obvious. If a SRC attribute of an HTML IMG-element points to a GIF sequence, instead of a single GIF image, then a WWW-client will show this sequence, if it meets two requirements.

The client:

Clients, which do not support multiple images, will usually show the first one, as XMosaic does since version 2.2.

Of course the framerate depends heavily on the connection transfer rate. It may be too high in a local environment and too low over slow links. Our experiments showed, that some changes to the server system are very useful in order to distribute the images equally in time. We implemented a cgi-program which analyzes the GIF stream. It either delays data, or drops images in order to transmit images at the proper time. Such source controlled time synchronization is all but optimal, but it is by far better than a solution without any synchronization.

We implemented a simple WWW-browser, which is able to present an inline GIF-sequence. We will show the system in operation, either with a local (at the conference) or a remote server. The entire mechanism will be explained by a poster. A draft of the poster is appended to this abstract (Fig. 1).

Live Video

One example of an image sequence will be generated by the live camera of our interactive model railroad server. Grabbed frames are GIF encoded and on demand fed to the synchronizing cgi-program. The cgi-program is invoked by the server in response to a request for an image stream (Fig. 2).

In case of live video, caching has to be avoided. The server should mark the object with an already reached expiration date to avoid caching. In general the client may issue a pragma directive with parameter no-cache in the HTTP-request. This will prevent proxies from caching the stream. A client may notice this situation through a special URL. Clients, however, should make no deductions about an object from its URL. A final solution would therefore need an indication from the HTML parser, e.g. a STREAM-element instead of IMG-element.

Discussion of Counter-Arguments

We are aware, that a widespread use of inline GIF-sequences would add to the internet's bandwidth problem. But the GIF specification allows some kind of difference coding using unequally sized, overlapping images. This will reduce bandwidth requirements drastically for fixed camera sequences. We expect, that WWW service providers will adjust their image sequences to the load and to the bandwidth available, as they do now for the amount of images they provide. The recent problems of GIF due to UNISYS's LZW-copyright may lead to an other standard image format in the Web. But it is probable that a successor will allow the encoding of image sequences as well, e.g. PDS, GIF24 (a PNG [PNG95] metaformat).

Conclusions

We are showing a way to include live recorded image sequences into WWW-pages. This has been done without any modification to protocols or standards. The presented components work very well, especially in the local area. They are compatible to existing WWW-systems. We regard this proposal as a means of studying new enhanced interactive services in the WWW.

References

[Crocker94]
G. Crocker: web2mush: Serving Interactive Resources to the Web, http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/crocker/tech.html
[Uhler94]
S. Uhler : Incorporating real-time audio on the Web, http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/uhler/uhler.html
[Soo94]
J. C. Soo: Live Multimedia over HTTP, http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/soo/www94a.html
[KaasPinTaub94]
M. F. Kaashoek, T. Pinckney, J. A. Tauber: Dynamic Documents: Extensibility and Adaptability in the WWW, http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/pinckney/dd.html
[GIF87]
CompuServe, Incorporated: CompuServe GIF 87a, http://icib.igd.fhg.de/icib/it/defacto/company/compuserve/gif87a/gen.html
[PNG95]
T. Boutell, M. Adler, L. D. Crocker,T. Lane: PNG (Portable Network Graphics) Specification, http://sunsite.unc.edu/boutell/png.html
Figure 1: A Screendump of the interactive model railroad server with live inline video.

Figure 2: The HTML code: Standard HTML 2.0 without any extensions