Eolas Technologies Incorporated v. Adobe Systems Incorporated et al

Filing 1301

Opposed MOTION for Leave to File a Brief Re The Term "Browser Application" by Adobe Systems Incorporated, Amazon.com Inc., CDW Corporation, Google Inc., J.C. Penney Corporation, Inc., Staples, Inc., The Go Daddy Group, Inc., Yahoo! Inc., YouTube, LLC. (Attachments: # 1 Exhibit 1 - Defs Brief re the Term "Browser Application", # 2 Exhibit C to Brief - p353-meyrowitz82, # 3 Exhibit D to Brief - IRIS Hypermedia_Haan92, # 4 Exhibit E to Brief - ADBE0196713 Rowe92, # 5 Exhibit F to Brief - DBE0196715 Hindus93)(Wolff, Jason) (Additional attachment(s) added on 2/1/2012: # 6 Certificate of Authorization to File Under Seal, # 7 Text of Proposed Order) (mjc, ).

EXHIBIT E

Proc. 3rd Int. Workshop on Network and OS Support for
Digital Audio and Video, San Diego CA (November 1992)

A Continuous Media Player t
Lawrence A. Rowe and Brian C. Smith
Computer Science Division-EECS. University of California
Berkeley. CA 94720. USA
Abstract. The ~esign and implementation of a continuous media player for Unix workstations is described. The player can play synchronized digital video and audio read
from a file server. The system architecture and results of preliminary performance experiments are presented.

1. Introduction
Our goal is to develop a portable user interface and continuous media suppon library
that can be used to implement a variety of multimedia applications (e.g .• hypennedia
systems. video conferencing. multimedia presentation systems. etc.). A key component
of these applications is a continuous media (CM) player that can play scripts composed
of one or more synchronized data streams. Example data streams are: digitized video or
audio. animation sequences. image sequences. and text.
The initial application we are implementing to test our abstractions is a video
browser that allows a user to play high quality videos stored in a large database on a
shared file server. Figure 1 shows a screen dump of the browser interface. The window
on the left lists videos in the database. and the window on the right plays the video. The
VCR controls below the video window allow the user to play the video forwards or
backwards at several speeds or to access a particular position using the thumb in the
slider.
The player runs on a Sun Sparcstation with a Parallax XVIDEO board which has a
JPEG CODEC chip. The video stream is stored as a sequence of JPEG frames. and the
audio stream is stored in a standard Sparc audio file.
The system has a flexible architecture that will allow other data representations and
decompression technologies to be added. For example. we have implemented an MPEG
video decoder in software that will be added to the system. and we are anxiously awaiting compression hardware for other Unix workstations.
A special-purpose datagram protocol was implemented to send CM packets from
the file server to the client workstation. The current implementation runs on UDP. but it
was designed to use the real-time IP protocol being developed by another research
group at Berkeley [18]. We have run the player on a conventional ethemet and FDOI
network.
The remainder of the paper describes the design and implementation of the player.
the results of some initial perfonnance experiments. and related work.

t This research was supported by the National SCIence Foundation (Grant MIP·9014940) and the
Semiconductor Research Corporation WIth a matchIng granl from the Slate of Callforma·s MI·
CRO program. AddItional support was proVIded by FUjItsu AmerIca and Hcwlell-Packard.

Tony ... f'IItItI (60410
Tony ... f'IItItI (32OxZ4D

Gllalluswn
Gllalbiiswn
GIIa....wn
GllatllUswn
GIIa....wn
Shy Guy
Fan!

WI"'''

- lined
- twInIdB
- fDd
- '*'-

~-prrwO¥W

AlIens - IIrNmS
AlIens - rf'IUletiC
. AlIens - Mlf.
Quotes

0..- .....

Figure 1. eM player user interface.

2. System Architecture
Figure 2 shows the architecture of the player. The playback application controls the
user interface and the CM Server process. The application is responsible for creating
windows. responding to input events. and sending commands to the CM Server.
The CM Server receives CM data from the CM Source and dispatches it to the appropriate output device (e.g .. the DSP chip to play audio or the video window to play
video). The CM Server has a time-ordered play queue to synchronize the playing of audio and video packets. It communicates with CM Source processes on the file server
through interprocess communication channels. and it communicates with the X server
through shared memory. The system clocks on the different systems are synchronized
by the Network Time Protocol (NTP) [Ill so that actions in the CM Server and Sources
can be synchronized.
The CM Server will eventually be merged with the X server as in the ACME Server
[11. but for now it is convenient to separate the functionality for several reasons. First.
it makes the CM Server easy to change. Second. it reduces maintenance when a new X
server is delivered since we do not have to retrofit our changes. Lastly. source code for
the X server is not required which is important because we want to use commercial
video boards. Commercial video boards usually include a modified X server for which
source code is often difficult to obtain.
The CM Source processes read CM data and send it to the CM Server. CM data is
sent in Sk packets on a UDP connection. We have implemented retransmission and
adaptive flow control to improve reliability. throughput. and playback quality. Eventu-