Declaration of Rachel J. Watters on Authentication of Publication
`
`I, Rachel J. Watters, am a librarian, and the Head of Resource Sharing for the
`
`General Library System, Memorial Library, located at 728 State Street, Madison,
`
`Wisconsin, 53 706. Part of my job responsibilities include oversight of Wisconsin
`
`TechSearch ("WTS"), an interlibrary loan department at the University of Wisconsin(cid:173)
`
`Madison. I have worked as a librarian at the University of Wisconsin library system
`
`since 1998, starting as a graduate student employee in the Kurt F. Wendt Engineering
`
`Library and WTS, then as a librarian in Interlibrary Loan at Memorial Library. I began
`
`professional employment at WTS in 2002 and became WTS Director in 2011. In 2019,
`
`I became of Head of Resource Sharing for UW-Madison's General Library System. I
`
`have a master's degree in Library and Information Studies from the University of
`
`Wisconsin-Madison. Through the course ofmy studies and employment, I have
`
`become well informed about the operations of the University of Wisconsin library
`
`system, which follows standard library practices.
`
`This Declaration relates to the dates of receipt and availability of the following:
`
`Willebeek-LeMair, M.H., Kumar, K.G., and Snible, E.C. (March
`· · 1998). Bamba -Audio and video streaming over the Internet.
`IBM Journal of Research and Development, 42(2), 269-280.
`
`Standard operating procedures for materials at the University of Wisconsin(cid:173)
`
`Madison Libraries. When an issue was received by the Library, it would be checked in,
`
`stamped with the date of receipt, added to library holdings records, and made available
`
`1
`
`Amazon / WAG Acquisition
`Exhibit 1007
`Page 1
`
`

`

`Declaration of Rachel J. Watters on Authentication of Publication
`
`to readers as soon after its arrival as possible. The procedure normally took a few days
`
`or at most 2 to 3 weeks.
`
`Exhibit A to this Declaration is a true and accurate copy of the title page with
`
`library date stamp of IBM Journal of Research and Development (March 1998), from
`
`the University of Wisconsin-Madison Library collection. Exhibit A also includes an
`
`excerpt of pages 269 to 280 of that issue, showing the article entitled Bamba -Audio
`
`and video streaming over the Internet (March 1998). Based on this information, the
`
`date stamp on the journal title page indicates Bamba - Audio and video streaming over
`
`the Internet (March 1998) was received by the University of Wisconsin-Madison
`
`Libraries on June 23, 1998.
`
`Based on the information in Exhibit A, it is clear that the issue was received by
`
`the library on or before June 23, 1998, catalogued and available to library patrons within
`
`a few days or at most 2 to 3 weeks after June 23, 1998.
`
`Members of the interested public could locate the IBM Journal of Research and
`
`Development (March 1998) publication after it was cataloged by searching the public
`
`library catalog or requesting a search through WTS. The search could be done by title
`
`and/or subject key words. Members of the interested public could access the
`
`publication by locating it on the library's shelves or requesting it from WTS.
`
`I declare that all statements made herein of my own knowledge are true and that
`
`all statements made on information and belief are believed to be true; and further that
`
`2
`
`Amazon / WAG Acquisition
`Exhibit 1007
`Page 2
`
`

`

`Declaration of Rachel J. Watters on Authentication of Publication
`
`these statements were made with the knowledge that willful false statements and the like
`
`so made are punishable by fine or imprisonment, or both, under Section 1001 of Title 18
`
`of the United States Code.
`
`Date: February 10, 2022
`
`Memorial Library
`· 728 State Street
`Madison, Wisconsin 53706
`
`Head of Resource Sharing
`
`3
`
`Amazon / WAG Acquisition
`Exhibit 1007
`Page 3
`
`

`

`Amazon / WAG Acquisition
`Exhibit 1007
`Page 4
`
`

`

`The Cover
`An art ist's rendition of Figure 2 of the paper on video
`query, which describes. means for searching large video
`databases. The figure represents the user's video displ ay
`terminal. On the foo tball field displayed there are a
`number of football icons. By pointing to any of these, the
`use r ca n view the video of the play that begins at the
`corresponding point on th e field . (The photograph is of
`Chris McCoy, quarterback of the U.S. Nava l Academy
`Phil Hoffmann
`team in th e 1997 Army-Navy game.)
`Photography.
`
`Editorial Staff
`
`G. F. Hoffnagle Editor
`
`Associate Editors
`
`I. Ames
`J. L. Hibbard
`S. I. Raider
`J. L. Rosenfe ld
`
`J. H. Robinson
`
`Staff Editor
`
`R. M. Johnson Editorial Associate
`
`Publications
`Staff
`
`J. F. Musgrave Art Director and Business Advisor
`L. A. Fasone
`C. C. Coppola
`
`Circulation/Fulfillment
`
`Production Assistant
`
`M. A. Cargiulo Administrator Analyst
`
`S. E. Allen
`
`Systems and Internet
`
`Advisory Board
`
`P. M. Horn (Chairman)
`M. J. Attardo, J. P. Briant,
`E. Catania, B. E. Dies,
`N. M. Donofrio, W. A. Etherington,
`K. Ishida, A. F. Kohnstamm,
`N. C. Lautenbach,
`S. A. Mills, P. Rowley,
`R. M. Stephenson, D. M. Thomas,
`J. M. Thompson, J. T. Vanderslice,
`D. M . Welsh
`
`I
`
`Editorial Board
`
`R. I. Baum, Systems Technology & Architecture Division,
`A ustin, Texas; S. E. Bello, Microelectronics Division, Austin,
`Texas; J. P. Jacob, Research Division, A lmaden, Ca lifornia;
`C. Plougonven, Compagnie IBM France, Corbeil-Essonnes,
`France; L. Svobodova, Research Division, Zurich, Switzerland;
`D. A. Thompson, Research Division, A lm aden, Ca lifornia.
`
`The IBM Journal of Research and Developm ent is a refereed
`techni cal journal published bimo nthly by Inte rn at ional
`Business Machin es Co rporati o n, Armonk, New York 10504,
`U.S.A. Officers: Lo uis V. Gerstner, Jr. , Chairma n a nd
`Chi ef Executive Officer; Jeffrey D. Serkes, Treasure r;
`John E. Hickey, Secreta ry.
`
`The IBM Journ al of Research and Development welcomes
`submissio ns from th e IBM technical com munity. Helpful
`infor mat ion regard ing the prepara ti o n of ma nuscript s may be
`obtained fr om th e R + DJRNAL category of ! NEWS, a nd at
`URL http ://www.a lmade n.ibm.co m/journal/rda uth.html on the
`Wo rld Wid e Web. Manuscript submissions a nd a ll oth er
`co rrespo nde nce sho uld be ad dressed to th e Editor, IBM
`Journ al of Research and Development, P.O . Box 218, Yorktown
`He ights, NY 10598, U.S.A. Co rres ponde nce may also be sent
`electroni cally to th e fo llowing addresses : YNET: JO U R NA LS
`a t YKTYMY, or Interne t: jo urn als@watson .ibm .co m.
`
`Subscriptio n rate: $135.00 pe r cale nd a r yea r (single cop ies
`$34.00) . Overseas a nd ha ndling cha rges may apply.
`Disco unted rates a re ava ilable for IBM e mployees and
`qualifying custome rs. See inside back cover fo r subscriptio n
`and o rd erin g in format ion, electronic so urces, and abstractin g
`a nd reprod ucti o n se rvices.
`
`The IBM Journal of Research and Development (ISSN 001 8-
`8646) is published bimonthly by Inte rn a ti o nal Business
`Machines Co rpora ti o n, Old Orchard R oad , Armonk, NY
`10504. Periodicals class pos tage paid at Armo nk, NY, and
`add itional mailing offices. Postmaster: Send address cha nges to
`IBM Journ al of Research and Developm ent , IBM Co rporati o n,
`P .O. Box 218, Rt. 134, Yo rktow n H e ights, NY 10598-0218.
`
`Amazon / WAG Acquisition
`Exhibit 1007
`Page 5
`
`

`

`---- -
`----
`- - -
`- ----
`- - ---
`---· -
`- -----
`-----·-
`Jol\lrnal of
`Research and Development
`
`I
`R . J . Flynn and W. H. Tetzlaff
`
`A. Dan, S. I. Feldman, and
`D. N. Se rpanos
`
`R. L. Haskin
`
`T. Sanuki and Y. Asakawa
`
`M. Kumar
`
`R. M. Bolle, B.-L. Yeo,
`and M. M. Yeung
`
`V. Castell i, L. D . Bergman,
`I. Kontoyiannis, C.-S. Li ,
`J. T. Robinson, and J. J . T urek
`
`M. H. Willebeek-LeMair,
`K. G . Kum ar, and E. C. Sn ible
`
`C. Bisdikian, S. Brady,
`Y. N. Doganata, D . A. Foulger,
`F . Marconcini, M. Mourad ,
`H. L. Operowsky, G. Pacifici,
`an d A. N. Tantawi
`
`162
`
`165
`
`177
`
`185
`
`199
`
`219
`
`233
`
`253
`
`269
`
`281
`
`299
`
`305
`
`Papers on multimedia systems
`
`Preface
`
`Multimed ia-An introduction
`
`Evolution and challenges in multimedia
`
`Tiger Shark-A scalable fi le system for multimedia
`
`Design of a video-server complex for interactive
`television
`
`Video-server designs for supporting very large numbers
`of concurrent users
`
`Video query: Research directions
`
`Progressive search and retrieval in large image archives
`
`Bamba-Audio and video streaming over the Internet
`
`MultiMedia Digital Conferencing: A Web-enabled
`multimedia teleconferencing system
`
`Recent publications by IBM authors
`
`Patents
`
`Vol. 42, No. 2, pp. 161-312, March 1998
`
`<!:>Copyright 1998 by Inte rn at io na l Business Machines Co rpora ti on. See individua l a rticl es for copy ing _in forma ti on,- Pos_t-1994 a rti cles
`t hat carry a code at the bottom of th e fir st page may be copied, provided the per-copy fee md1 ca ted 111 the code 1s pa id through th e
`Copyright Clearance Ce nter, 222 Rosewood Drive, Danvers, MA 01923, U.S.A. Pages co ntaining th e tabl e of_co nte nts and " Rece nt
`publications by IBM a uth ors" may be freely cop ied a nd distributed in any form. ISSN 0018-8646. Pnnted 111 U.S .A.
`
`:,U.231991
`
`' i
`!
`
`l
`1
`
`Amazon / WAG Acquisition
`Exhibit 1007
`Page 6
`
`

`

`by M. H. Willebeek-LeMair
`K. G. Kumar
`E. C. Snible
`
`Bartlba-Audio
`and video
`streaming over
`the Internet
`
`I
`
`The World Wide Web has become a primary
`means of disseminating information, which is
`being presented increasingly through multiple
`media. The ability to broadcast audio and
`video information is becoming a reality with
`the advent of new media-streaming
`technologies. Most of the emerging streaming
`systems require high-bandwidth connections
`in order to deliver audio and video of suitable
`quality. In this paper we present a media(cid:173)
`streaming system, called Bamba, that delivers
`audio and video over low-bandwidth modem
`connections with the use of standard
`compression technologies. Bamba offers high(cid:173)
`quality audio and video over low-bit-rate
`connections and can operate using a standard
`HTTP server. The Bamba video is enhanced
`with special provisions for reducing the effect
`of errors in a lossy~network environment.
`Bamba adheres to existing standards wherever
`possible. Finally, Bamba has been fully
`implemented and deployed both internally at
`IBM and externally.
`
`1. Introduction
`The World Wide Web (WWW) has become a prim ary
`mea ns of disseminating in fo rm ati on. Initi ally, th e type of
`information distributed was primarily in the form of text
`and graphics. Later, im ages and stored ~udi o and video
`
`fil es emerged. These aud io and video fi les are down loaded
`from a server and stored at the client before they are
`pl ayed. Most rece ntly, strea med audi o and video have
`beco me available from both stored and live sources on th e
`Web. Audi o and video strea ming enabl es cli ents to select
`and receive audi o and video content fro m servers across
`the network and to begin hea ring and seeing th e content
`as soo n as the first few bytes of the strea m arrive at the
`cli ent. Streaming technology involves audio and video
`co mpress ion, schemes fo r stream fo rm atting and
`transmi ssion packeti zation , networking protoco ls and
`routing, cli ent des igns fo r di spl aying and synchro ni zing
`di ffe rent medi a streams, and se rver designs for content
`storage and delivery. In this paper we present a system
`for audio and video strea ming (with code name Bamba)
`developed at the IBM Th omas J. Watso n Resea rch
`Center. Bamba has been deployed within IBM and was
`demonstrated extern ally on the offi cial Web site of th e
`1996 Olympics. It has since been made ava il abl e fo r free
`downl oad from the IBM Alph a Works * Web site. 1
`Today's computer-netwo rk infrastru ctures, including the
`Internet, were not designed with streaming in mind .
`Strea ming medi a requires that data be transmitted from
`a serve r to a cli ent at a sustained bit rate that is high
`enough to maintain continu ous and smooth pl ayback at
`the rece iving client stati on. A prim ary obj ective in
`deve loping Bamba is to strea m audio and video across the
`Web through very- low-bit-ra te co nn ections. Audi o is
`
`I ht1p://www.A lplw lVorks. ibm .com
`
`C'Co pyright 1998 by Int e rn a tio nal Business Mac hines Co rpo rat io n. Copyin g in pri n ted fo r m fo r p ri va te use is pe rmitt ed withoul payme n t o f roya lt y provid ed that(! ) eac h
`re prod uc ti o n is d one with o ut a lt e ra tio n a nd (2) 1hc J011rnal refere nce a nd IBM co pyri ght no tice a rc in cluded o n the fi rst page . T he tit le a nd· abst_rn ~t, b ut no o tl_1e r po rt io ns,
`of this paper may be copied or distri bu ted royalty free wit hout fu rther pe rm ission by co mput e r-based and o th e r infor ma tio n-se rvice sys tems. Pe nrn sswn to rt'pubhsl, a ny o th er
`po n io n of th is pa pe r mu st be obta ined fro m 1he Edito r.
`
`269
`
`0018-8646/98/$5.00 © 1998 IBM
`
`IB M J . R ES. DEVELOP. VOL 42 NO . 2 MAR CH 1998
`
`M. H . \V IL LEB EE K-LEM A IR, K. G. KUMAR , AND E. C. SN IBL E
`
`Amazon / WAG Acquisition
`Exhibit 1007
`Page 7
`
`

`

`sufficiently compressed to stream over modem connections
`at 14.4 Kb/s, and video at 28.8 Kb/s. The system that has
`been developed not only achieves the low-bit-rate goal,
`but can also be extended to support higher-bit-rate
`streams to provide higher-quality streaming over intra nets
`or higher-bandwidth Internet connections. Furthermore,
`when streaming is not possible because of congestion or
`insufficient bandwidth availability, the Bamba player
`( client software) at the receiving client automatically
`calculates how much data to preload in order to maintain
`continuous playback. This allows clients connected via
`low-bit-rate connections to fall back to a download- and(cid:173)
`play mode and still receive the higher-bit-rate content.
`
`Existing audio and video streaming
`technologies
`In recent years, there has been much research and
`development in the areas of audio and video streaming
`as well as videoconferencing. Videoconferencing
`differs from audio and video streaming in that the
`communication is bidirectional, and end-to-end
`delays must be ve ry low ( < 200 ms) for interactive
`communication. In fact, videoconferencing stand ards are
`quite mature and have emerged from the International
`Telecommunication Union (ITU) in the form of the
`H. 3xx standards [1 , 2], and from the Internet Engineering
`T ask Force (IETF) in conjunction with the multicast
`backbone (MBone) [1 , 3, 4] . In general, the two camps
`use the same audio and video compression standards
`( defin ed by the ITU) but differ in their networking
`protocol specifications.
`Audio and video streaming differs technically from its
`videoconferencing counterpart in that it can afford
`greater fl exibility in end-to-end delays when the data is
`transmitted across a network and in the fact that sto red
`content may be manipulated off-line with additional
`processing. These begin to merge when one considers live
`audio and video streaming applications ( e.g. , Internet,
`radio, and TV) . The most relevant of the ITU standards is
`H.323, which defines audio/visual services over LANs for
`which quality of service cannot be gua ra nteed [5]. This
`standard specifies a variety of audio and video coders and
`decoders (CODECs) as well as signaling protocols to
`negotiate capabilities and set up and manage connections
`[6]. The underlying transport specified is the R eal-time
`Transport Protocol (RTP) [7]. This protocol , defined by
`the IETF, is intended to provide a means of transporting
`real-time streams over Internet Pro tocol (IP) netwo rks. A
`new protocol, the Real Time Streaming Protocol (RTSP),
`just proposed to the IETF, more directly addresses the
`issues of delive ring and managing multimedia streams [8].
`Clearly, this area is still evolving as new protocols are
`being defin ed and refin ed to satisfy a wide range of
`emerging networked multimedia applications.
`
`There are a large number of audio and video streaming
`systems available in the marke t today [9]. These include
`VDOLive **, 2 StreamWorks** ,3 Vosaic** ,4 VivoActive ** ,5
`InterVU **, 6 and EealA_udio ** .7 VDOLive, Streamworks,
`Vosaic, and RealAudio are based on proprietary
`client-server systems that transport their audio and video
`streams by means of User Datagram Protocol (UDP/IP)
`connections. This unreliable transport does not retra nsmit
`lost packets and is blocked by most firewalls unless they
`are specially reconfigured. The others use HTTP (b ased
`on T CP/IP) [10] . VDOLive employs a proprietary
`hi erarchical compression technique that allows the server
`to adapt the video-stream bandwidth to the available
`netwo rk connection bandwidth . StreamWo rks, Vosaic, and
`InterVu are based on MPE G** (lll, while Vivo uses H.263
`(12]. In general, these systems are designed to work over
`higher-bandwidth LAN connections and not at modem
`speeds. At modem speeds, the MPEG-based systems
`revert to slide-show-type video.
`Bamba is a streaming system that was designed to
`run over existing computer network infras tructures. In
`particular, it is versatile in dealing with the heterogeneous
`natu re of this environment and the unpredictable
`congestion behavior of today's network traffic. In the
`Bamba system, audio and video are compressed into a
`Bamba fil e. This file is specially fo rmatted to interleave
`the audio and video content and may even be extended to
`include other data types. The Bamba file is placed on a
`server. A client equipped with the appropriate Bamba
`software is able to communicate with the server and
`receive the Bamba audio/video file . If the network
`conditions are suitable (sufficient sustained bandwidth is
`available), this file, streaming across the network, is played
`at the client immediately. Otherwise, the fil e is played
`once uninterrupted playback can be ensured.
`The Bamba streaming system has several key features .
`The first of these is the quality of the audio and video,
`where the audio is set at a constant 6.3 Kb/s and the video
`ranges from very low bit rates of tens of kilobits per
`second to hundreds of kilobits per second . The second is
`the fact that both the audio and video compression are
`based on standard algorithms and can be performed by
`standards-compliant decoders. Third , the Bamba streaming
`system uses either a standard HTTP server or an
`enhanced video server running RTP over UDP/IP. In the
`HTTP case, no special server software is required to store
`and send Bamba clips, and the transmitted streams can
`traverse firewalls with no special firewall configuration
`requi re ments. In the case of the video server running RTP
`\
`
`2 http://www.vdo.net
`3 http://www.xingtech. com
`4 h1tp:/lwww. vosaic.com
`5 http://www.vivo.com
`6 http://www.intervu. com
`1 http://www.realaudio.com
`
`M. H. WILLEBEEK- LEMA IR , K. G. KUMA R, AND E. C. SN IBLE
`
`IBM J. RES. DEVELO P. VO L. 42 NO. 2 MARCH 1998
`
`270
`
`Amazon / WAG Acquisition
`Exhibit 1007
`Page 8
`
`

`

`HITP server
`
`t
`
`t
`
`File
`server
`
`Network
`
`interface B
`
`Netscape
`
`Plug-in interface
`
`EK decoder
`
`Video
`
`Network
`interface
`
`HITP
`
`Plug-in
`
`Audio
`decoder
`
`Video
`renderer
`
`Audio
`renderer
`
`Server
`
`Client
`
`Figure 1
`
`over UDP/IP, additional f~nctionality is provided by
`means of a control protocol between the client and server.
`This function ality includes pacing of the tra nsmission
`stream at a target bit rate as well as specific start and end
`times of tra nsmission within an audio or video fil e. Finally,
`the Bamba player has been implemented either as a
`helper application, which runs outside a Web browser, or
`as a browser plug-in, which enables application developers
`to embed audio and video clips easily within an HTML
`document or as a Java ** applet, which can be downloaded
`directly fro m a Web server containing Bamba clips without
`requiring special software installati on at the client.
`The rest of this paper is organized as fo llows. In Section
`2, we describe the underlying Bamba technology. This
`includes a description of the video-compression algorithm
`as well as de tails related to the overall system design. In
`Section 3, we describe several enhancements made to the
`basic Bamba streaming system, such as increased
`robustness in lossy-netwo rk environments. A description of
`the Live Bamba architecture is given in Secti on 4. The
`paper is summarized in Section 5.
`
`2. Bamba technology
`A base requi rement of the Bamba streaming system is to
`function within the WWW standard HTTP-based
`client-server architecture. In this section, we provide a
`descri ption of the overall client-server archi tectu re and
`present details concerning the compression algori thms. We
`also describe the Bamba fil e for mat and synchro nization
`technique.
`
`• Bamba streaming architecture
`A block diagram of the Bamba streaming system is
`presented in Figure 1. T he system consists of a client and
`a server component. The server is a standa rd HTTP Web
`
`server, which contains the stored Bamb a audio and video
`files. The client consists of a Web browser and the Bamba
`audio and video plug-in software.
`T he Bamba plug-ins are implemented as a set of
`dynamic link libraries that interface with the Web browser
`thro ugh the Netscape-defi ned plug-in API. Netscape
`has defined a set of plug-in routines th at are used to
`communicate between the plug-in and the browser. Each
`plug-in libra ry contains an initialization routine within
`which is decl ared what Netscape plug-in ro utines are used
`by the plug-in. These routines include mechanisms to
`create and delete instances of a plug-in, manage the plug(cid:173)
`in display window, control the fl ow of data streams to the
`plug-in, etc. In general, the plug-in is tightly in tegrated
`with the browser. Note that while Netscape was used in
`this example, the approach is similar fo r other browsers.
`Bamba fil es may be embedded in HTML pages by
`means of a URL pointing to a file on an HTTP or video
`server. When the U RL is requested , the server passes
`the metadata identifying the Bamba fil e and containing
`information about the fil e type to the client. The file type
`is used by the browser to launch the appropria te plug-in
`to play back the Bamba fi le.
`Bamba was designed to stream clips fro m standard
`HTTP Web servers without special streaming software
`on the server. As such, Bamba is limited to the
`communication mechanisms provided by the HTTP
`protocol. This approach has certain advantages, the
`greatest of which is that it is simple and maps gracefull y
`into the existing Web browsing architecture. As a res ul t,
`content creators can easily produce Bamba audio and
`video clips and embed them in stand ard HTML (13]
`pages, which are then loaded onto and accessed fro m a
`stand ard HTTP server. Since the underlying transport
`protocol used by HTTP is TCP/IP, which provides reliable
`
`IBM J. RES. DEVELO P. VOL. 42 NO. 2 MARCH 1998
`
`M. H . WILLEBEEK-LEMAIR, K. G. KU MAR, AND E. C. SNIBLE
`
`271
`
`Amazon / WAG Acquisition
`Exhibit 1007
`Page 9
`
`

`

`Motion vectors, _ _ _ __ _ _
`
`Macro block
`
`-
`
`11- I
`
`II
`
`□□ p
`
`11 -
`
`I
`
`II
`
`11+1
`
`n + 2
`
`(a)
`
`I
`
`p
`
`p
`
`p
`
`p
`
`p
`
`p
`
`I
`
`p
`
`p
`
`p
`
`I
`
`p
`
`p
`- .
`p
`
`I
`
`p
`
`p
`
`(
`
`Motion vectors
`
`(b)
`
`II+ I
`
`p
`
`I
`
`p
`
`p
`
`p
`
`p
`
`p
`
`p
`
`I
`
`Video-compression algorithms: (a) MPEG 1-, P-, and B-frame compression dependencies; (b) H.263 I and P macro-block dependencies.
`
`end-to-end network connectio ns, no special provisions are
`required for handling packe t loss within the network. In
`essence, a Bamba audio or video clip is treated like any
`other HTTP object, such as an HTML o r JPEG [1 4] file.
`If selected , the Bamba clip is transferred to the client
`(browser station) as fas t as TCP/IP can move it, and the
`client begins decoding and displaying the Bamba file as
`soon as the first few bytes arrive.
`Since Bamba uses TCP/IP as the underlying
`com munication protocol , the streams can traverse firewalls
`with no special configuration requirements. In general,
`systems based on UDP/IP cannot traverse firewalls without
`explicit pe rmission changes in th e firewall to allow passage
`to the UDP/IP packets. This is because UDP/IP packets
`are easier to imitate th an TCP/IP packe ts, since the
`UDP/IP protocol invo lves no end-to-e nd handshakes or
`seq uence numbers [1 5].
`
`• Bamba audio and video technology
`The audio and video technology used in Bamba is based
`on stand ard algorithms origin ally defined within the ITU
`H.324 standard for video telephony over regu lar phone
`lines [1 6]. T he audio standard, G .723, specifies two bit
`rates: 5.3 Kb/s and 6.3 Kb/s [1 7]. Bamba uses the higher(cid:173)
`bit-rate COD EC, which compresses an 8-kHz input of
`16-bit sa mples to a fixed 6.3Kb/s stream . This audi o
`algorithm is optimized to represent speech at high qu al ity
`over low-bit-rate connections. It encodes speech into
`30-ms frames by means of linea r predictive analysis-by(cid:173)
`synthesis cod ing [1 7]. The input signal for the higher-bit(cid:173)
`rate coder is Multipulse Maximum Likelihood
`Quantization (MP-MLQ) [1 7].
`T he Bamba video CODEC comp lies with the H. 263
`video compression standard [1 2], which uses an ap proach
`based on the discrete cosine transform (DCT). T hi s is
`
`similar to the technology used for MPEG. Unlike MPEG,
`which uses intrapicture frames (I-frames) , predicted
`frames (P-frames) and bidirectiona l predicted frames
`(B-frames) , H .263 does not define I- and P-frames , but
`rather I- and P-blocks-8-pixel by 8-pixel subregions of a
`frame. Figure 2(a) illustrates the MPEG dependencies
`among 1-, P- , and B-frames, while Figure 2(b) illustrates
`the partitioning of H .263 frames into I- and P-blocks and
`the dependencies between blocks. R epresen ting frames as
`collections of I- and P-blocks reduces the size variance
`between frames and adds flexibility in selecting the refresh
`distance between I-blocks for different regions of the
`video image. To maximize compression based on temporal
`redundancy, there may be long intervals between I-blocks
`for regions in the image that are not changing.
`The H .263 algorithm is designed to deliver video over
`very low-bit-rate ( < 64 Kb/s) dedicated connections. In this
`low-bit-rate ra nge, H.263 has bee'n de monstrated to
`outperform its predecessor, H.261 [1 8], by a 2.5:1 ratio [2]
`(i .e., at the same bandwidth, the signal-to-noise ratio of
`H.263 is 2.5 times higher than that of H.261. H.263 can
`also be easily extended to higher bit rates, in the
`100-200-Kb/s range . These rates are suitable for streaming
`over ISDN or intranet LAN-type connections. The H.263
`video compression algorithm uses a planar YVU12 format ,
`which contains three components: luminance (Y) and two
`chrominance planes (V and U) . The sizes of these planes
`vary as a fun ction of the video resolution. Two of the
`resolutions supported by Bamba are the Common
`Intermed iate Format (CIF) and the Quarter Common
`Intermediate Format (QCIF) [2]; the forma ts are
`presented in Table 1. Smaller and intermelate-size
`resolutions are also supported. The resoluti n and
`target bit rate are selected at po mpression time . T he
`compression target bit ra te may be set anyw here between
`10 and 356 Kb/s.
`
`M. H. W ILLEBEEK-LEMA IR , K. G. KUMAR , AND E. C. SN IBL E
`
`IBM J. RES. D EVE LOP. VOL. 42 NO. 2 MARCH 1998
`
`272
`
`Amazon / WAG Acquisition
`Exhibit 1007
`Page 10
`
`

`

`As with many compression standards, th e H. 263
`standard specifies the form at of th e video so that any
`standards-compliant decod er can successfully decode th e
`video stream. Typi ca lly, this !~aves much fl ex ibility in the
`actual encoding \technique and implementation. The H.263
`e ncoding used fqr Bamba uses an innovative algo rithm to
`trade frame rate for fr ame qu ality [19] . The art in vid eo
`compression lies in the decision of how best to apportion
`a few bits to different components in the compression
`process so th at the co mpressed stream, once decoded and
`di spl ayed, produ ces the highest qu ality as perceived by the
`e nd user. Qu ality is highly ambiguous and is perceived
`different ly by different users. A typical tradeo ff is between
`frame rate and frame quality (pixel quantiza tion) . For the
`same number of bits, it is possibl e to create two very
`different standards-co mpliant streams. One strea m may
`have a higher frame rate, whil e the other may have a fin er
`qu antiza tion of the fram e pixels, obtaining a sharper
`im age.
`The Bamba video implementation incorporates a
`dyn amic fram e-rate-control algorithm, which trades fram e
`rate for fr ame quality (bits per frame) whil e maintaining a
`co nstant average bit rate. This approach allows the video
`to balance between the two extremes and deliver smoother
`mot ion or sharper im ages as appropriate, depending on
`the content and scene changes in the video. T he algorithm
`behavior is illustrated in Figure 3. A video sequence with
`dynamically changing content is used to illustrate the
`algo rithm 's adaptable frame rate. The origin al clip is
`approximately 30 seconds long, captured at 15 frames per
`second for a total of 445 frames. It was compressed at a
`target bit rate of 20 Kb/s and resulted in a total of 332
`fr ames. Typically, larger fram es are followed by a drop in
`frame rate in order to maintain the co nstant bit rate. The
`spikes in th e fi gure correspond to larger frames, generated
`when the scene changes or th e amount of moti on in a
`scene is significa nt. These spikes are typically fo llowed by
`severa l frame periods in which no data is transmitted at
`all.
`The Bamba H.263 implementation includes special
`motion-estimation techniqu es (20] and fas t DCT
`algo rithms [21, 22], which result in very effici ent
`implementations.
`
`• Framing structure
`A simple frami_ng technique for smooth pl ayback was
`impl emented. Audio and video are interleaved into a
`single fil e to simplify the serve r function. Essenti ally, the
`server trea ts a Bamba fil e as any other data fil e. Audio
`and video data are interleaved proportionately to maintain
`a synchronous playback of both strea ms at the cli ent.
`Bamba fr ames consist of a 240-byte segmen1 of audio and
`a 240{3/a-byte segment of video, where a is the audio rate
`and /3 is the video rate.
`
`20
`
`10
`
`0
`
`200
`Frame number
`
`300
`
`400
`
`Illustration of Bamba video compression with dynamic-frame-rate(cid:173)
`control algorithm. The number of bits transmitted is shown for
`each frame of a sample video sequence.
`
`Table 1 CIF and QCIF planar YVU1 2 formats.
`
`Pixels/lin e
`
`L in es/fram e
`
`CIF luminance (Y)
`CIF chromin ance plane (V)
`CIF chromin ance plane (U)
`QCIF lumin ance (Y)
`QCIF chrominance pl ane ( V)
`QCIF chrominance pl ane ( U)
`
`352
`176
`176
`176
`88
`88
`
`288
`144
`144
`144
`72
`72
`
`• Streaming-control algorithm
`Wh en the Web is accessed, the actual connect ion speed
`between a client and a server in the network var ies
`depending on the access method (e.g. , modem or LAN) ,
`the network load , the server load, and even the client
`load. Hence, it is ra rely possibl e to guarantee performance
`in this "best-effort " environment, where process ing and
`bandwidth reso urces are typically evenly distributed among
`all competing applica tions. Co nsequ ently, wh en an audio
`and/or video clip is accessed over the network, there is no
`guarantee that the resources (bandwidth and processing)
`are available to play the clip smoothly. To handle this
`situation , Bamba has a built-in rate monitor that
`dynamically evaluates the effective data-transfer rate ( u)
`of a selected audio or video clip and compares this to the
`specified bit rate ( a + /3) for the clip, which is co ntained
`in the clip header. If the specifi ed rate is less th an the
`measured rate, the clip can be played immediately. If, on
`the other hand, th e specified rate exceeds the measured
`rate (a + /3 > u) , a fraction of the clip is buffered
`
`IBM J. RES. DEV E LOP. VOL. 42 NO. 2 MARC H 1998
`
`M. H . W ILL EBEEK-LEMA IR, K. G . KUMAR , AND E. C. SN IBLE
`
`273
`
`Amazon / WAG Acquisition
`Exhibit 1007
`Page 11
`
`

`

`·~
`
`Average
`Ta
`bandwidth
`
`Available
`
`\ TCP bandwidth
`
`TI=
`
`Illustration of TCP/IP bandwidth vari ation with time.
`
`suffici ent for the clip to pl ay to completion smoothly
`once playback is started. The amount of prebuffering is
`8 = L[l - u/( a + {3)], where L is the clip length .
`Thi s ca lcul ation is perfo rm ed on the basis of the initi al
`download rate a