Ulllted States Patent
`
`[19]
`
`[11] Patent Number:
`
`5,996,022
`
`Krueger et al.
`
`[45] Date of Patent:
`
`Nov. 30, 1999
`
`US005996022A
`
`[54] TRANSCODING DATA IN A PROXY
`
`5,835,495
`5,864,678
`
`11/1998 Ferriere ................................. .. 370/465
`1/1999 Rlddle ................................... .. 709/235
`
`THE AUDIO DATA TO A CLIENT
`
`OTHER PUBLICATIONS
`
`Abstract, Anon, “Four Audio Distribution Options in the
`News,” Electron. Doc., vol. 4, No. 9, Sep. 1995, pp. 20-22.
`Abstract, Ratcliffe, M., “Real Progress: The Internet as
`Information Utility,” Digital Media, Vol. 4, No. 12, May 10,
`1995, pp. 19-22.
`Abstract, Vincent, 'l‘., “Digital Audio and Disabled Learn-
`ers,” Innovations in Education and Training International,
`vol. 33, No. 1, Feb. 1996, pp. 66-67.
`Abstract, “Realvideo Unveiled,” Computer Reseller News,
`N0 724» Feb 24> 1997» P~ 69
`Abstract, Smith, J ., “RealAudio client 3.0,” MacUser, vol.
`12, N0- 22, OCL 25, 1996, I1 72~
`“Four Audio Distribution Options In The News”, DIA-
`}§G1(§) $116 i48;tPI3R0’?je (]§)I[:;’%7G13$ 1;,t1“fI12a;;°I1ffii;Pg(~)
`ea
`10 cien.
`.
`,
`16
`I
`,
`C
`1997 P“ I“‘°§“a“°“*‘1> 1P3
`,
`,
`,
`,,
`Real Progress. The Internet As Information Utility , DIA-
`
`D1g“a1A“d1° and D1Sf‘b1‘?d ‘earners ; DIALQGO‘) F116
`IHSTIIUIIOII Of E1€Cl.I'1Cal E1'lg11'lCCI'S,
`Emerging Technologies—New Opportunities
`In Plat-
`forms”, DIALOG(R) File 647:CMP (C) 1997 CMP, 1pg.
`
`§§§?§?ZZ3‘f7?f£§7fZ;Z§£§ial4§‘§?§t
`Attorney, Agent, or Firm—Workman, Nydegger & Seeley
`
`[57]
`
`ABSTRACT
`,
`,
`A local server has a connection to a client and to a remote
`SerVer 0Ver the Internet The 10ea1 Server reee1VeS 21 request
`for an audio file from the client and, 111 response, transmits
`a requests for the audio file to the remote server. Upon
`receiving the audio file, the local server transcodes the audio
`file received from the remote server and then transmits the
`transcoded audio file to the client Transcoding may include
`.
`.
`‘
`.
`.
`chcelinging 111116 auditc:
`fllefIyp::i,.COI}I1lpI‘eS:1I1g the daudio fille,
`re ucing t e num er 0
`au 10 c anne s, or re ucing t e
`sampling rate of the data. The local server determines the
`extent and type of transcoding to be performed on the audio
`file as the audio file is downloaded from the remote server.
`The extent and type of transcoding are based on the file
`
`[75]
`
`IUVCTHOTS3 Mark H- Kruegera HigaShi'1.(u> Japan;
`Jay D- Logue» San JOSE» Cahf
`,
`7
`.
`,
`[73] Asslgnee‘ WebT‘ Networks’ Inc" Moumam
`Vlews Cahf
`
`l21l APPL N05 03/3349991
`[22]
`Filed:
`Apt 7’ 1997
`
`Related U.S. Application Data
`
`[63]
`
`C0ntinuati0n—in—part of application No. 08/656,924, Jun. 3,
`1995, Pate N0- 5,918,013
`Int. Cl." .............................. H04L 5/00; H04L 12/00,
`[51]
`G061: 13/00
`[52] U.s. Cl.
`.......................... 709/247, 709/202, 709/203,
`709/217; 709/227; 709/228; 709/231; 709/232;
`
`[58] Field of Search ............................ 395/200.3—200.33,
`
`709/200_203, 217, 218, 227_229, 231_235’
`246_247; 704/500’ 503; 370/235, 236
`
`[561
`
`Referenees Cited
`Us. PATENT DOCUMENTS
`
`4,972,484
`.......................... .. 704/227
`11/1990 Theile et al.
`5,325,423
`_ 379/93.08
`6/1994 I.ewis ...... ..
`5,488,411
`. . . . . . N 348/8
`1/1996 Lewis . . . _ . . . .
`5,526,353
`........................ .. 709/231
`6/1996 Henley et al.
`5,530,852
`6/1996 Meskei Jr. et a],
`,,,,,,,,,,,,,,,,,,, ,, 709/206
`5,538,255
`7/1996 Barker ......... ..
`.. 463/41
`5,550,853
`8/1996 Yllft et 61-
`-
`375/240
`5558339
`9/1996 Perlman
`~~~~ ~~ 463/42
`595649001
`10/1996 Lewis
`‘ 379/9308
`5,570,363
`10/1996 Helm
`.. 370/260
`5,586,257 12/1996 Perlman
`709/225
`5,612,730
`31,1997 Lewis ...... N
`348/8
`576367324
`6/1997 Teh et ,1.
`704/226
`..... N
`5,692,105
`11/1997 Leppanen et a].
`704/503
`
`5,742,773
`4/1998 B1omfie1d—Bmwn at a ,
`709/228
`5,768,535
`6/1998 Chaddha et al.
`...................... .. 709/247
`
`
`
`B 1%’: %WE I/ma
`
`
`
`
`
`Am|OFlLE
`
`
`r"""""""""""""""""
`
`
`
`E
`DATAHEOUESI’
`/ DATAREDUEST
`
`
`’
`
`E
`
`_ ______
`
`-5???‘______ __l
`
`YD wsarv
`CHEN’ 1 5”
`iamaconm
`NOTlFVDLlENYOF
`505
`THANSMW
`-TRANSGODED
`mo H15 T0
`cum]
`mwswwwsoonen FlLE 250,
`to CUENT
`
`
`
`RPX Exhibit 1245
`RPX V. DAE
`RPX Exhibit 1245
`RPX v. DAE
`
`

`
`5,996,022
`Page 2
`
`formats which the client is capable of handling, the size of
`the requested audio file, the memory capacity of the client,
`the bandwidth of the connection between the local server
`and the client, and the desired level of audio quality.
`Transcoding may be performed on-the-fly while the
`
`requested audio file is being downloaded to the local server
`from the remote server and while the modified audio file is
`being downloaded from the local server to the client.
`
`38 Claims, 6 Drawing Sheets
`
`

`
`U.S. Patent
`
`Nov. 30, 1999
`
`Sheet 1 of 6
`
`5,996,022
`
`REMOTE
`SERVER
`
`
`
` INTERNET
`
`VVEBTV
`SERVER
`
`
`
`3
`
` VVEBTV
`CUENT
`
`FIG. I
`
`

`
`U.S. Patent
`
`Nov. 30, 1999
`
`Sheet 2 of 6
`
`5,996,022
`
`

`
`U.S. Patent
`
`9,0,9,1nwivW0N“
`
`hRu
`
`0.10iv
`
`,0
`
`5,996,022
`
`wmmm>mmm>pmm;
`
`am
`
`mm<2
`
`mu<mopm
`
`
`
`
`
`mmm_>Em>._.mm>>._.zm_._omo
`
`$50OH._.m_zmm._.z_o._.
`
`andvflri
`
`

`
`U.S. Patent
`
`Nov. 30, 1999
`
`Sheet 4 of 6
`
`5,996,022
`
`INTERNET
`
`TRANSCODER
`
`TO / FROM
`
`
`§§
`
`I
`
`WEBTV SERVER 5
`_ _ _ _ _____l
`
`FIG. 4
`
`

`
`U.S. Patent
`
`Nov. 30, 1999
`
`Sheet 5 of 6
`
`5,996,022
`
`AUDIO FILE
`FROM REMOTE SERVER 4
`
`_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ._' _ .—|
`v
`WEBT
`SERVER .
`§_
`I
`
`|—
`
`
`DATA REQUEST
`
`‘é$‘F'{E”:\h
`CACHE
`
`71
`DATA REQUEST
`
`
`
`
`PROXY
`CONHGURE
`TRANSFORM
`
`
`
`HEADER
`
`TO WEBTV
`CLIENT 1
`
`E'I[i'_=3
`
`

`
`U.S. Patent
`
`N0v.30, 1999
`
`Sheet 6 of 6
`
`5,996,022
`
`601
`
`RECEIVE REQUEST FOR
`AUDIO FILE FROM CLIENT
`
`602
`
`FILE STORED IN CACHE?
`
`
`
`603
`
`NO
`
`REQUEST FILE FROM
`REMOTE SERVER
`
`607
`
`608
`
`BEGIN/CONTINUE RECEIVING
`FILE FROM REMOTE SERVER
`(vso IN RANDOM ACCESS MODE)
`
`YES
`
`YES
`
`604
`
`
`
`YES
`
` OALREADYTRANSCODED7
`
`HAVE ENOUGH DATA TO
`MAKE TRANSCODING
`DETERMINATION?
`
`YES
`
`61
`
`O
`
`MAKE TRANSCODING
`DETERMINATION
`
`SWITCH VSC TO SEQUENTIAL
`MODE
`
`61
`
`1
`
`612
`
`TRANSCODING TO BE
`PERFORMED?
`
`Y
`
`ES
`
`TRANSCODE FILE
`
`613
`
` TRANSMIT
`CLIENT
`
`
`NON-TRANSCODED
`AUDIO FILE TO
`
`NOTIFY CLIENT OF
`TRANSCODING
`
`605
`
`TRANSMIT TRANSCODED FILE
`TO CLIENT
`
`606
`
`

`
`5,996,022
`
`1
`TRANSCODING DATA IN A PROXY
`COMPUTER PRIOR TO TRANSMITTING
`THE AUDIO DATA TO A CLIENT
`
`The present application is a continuation-in-part of U.S.
`patent application Ser. No. 08/656,924, filed on Jun. 3, 1996,
`now U.S. Pat. No. 5,918,013.
`
`FIELD OF THE INVENTION
`
`The present invention pertains to the field of computer
`software. More particularly, the present invention relates to
`modifying audio files that are received and transmitted over
`a computer network.
`BACKGROUND OF THE INVENTION
`
`The number of homes and businesses using personal
`computers has increased substantially in recent years, and
`along with this increase has come an explosion in the use of
`the Internet and, in particular, the World-Wide Web (“the
`Web”). The Web is a collection of formatted hypertext pages
`and other data located on numerous computers around the
`world that are logically connected by the Internet. Although
`the Web has in the past been a source of primarily scientific
`and technical information, it is now a valuable resource for
`information relating to almost any subject,
`including
`business, entertainment, travel, and education, to name just
`a few. Advances in network technology, and especially in
`software such as “Web browsers” (software applications
`which provide a user interface to the Web), have made the
`Web accessible to a large segment of the population.
`There are problems associated with certain current Web-
`related technology, however, which can make browsing the
`Web unpleasant. One such problem is latency. People com-
`monly experience long, frustrating delays when browsing
`the Web, such as when one’s computer is establishing
`contact with a Web server or downloading a requested file.
`There are many possible causes of latency, including heavy
`communications traffic on the Internet, slow response time
`of Web servers, and the large size of some files that are
`downloaded. Latency tends to be particularly apparent when
`downloading audio files, for example, which tend to be large
`in comparison to other file types. It is desirable, therefore, to
`provide a technique for reducing certain latencies on the
`Web, such as those associated with audio files.
`The use of audio on the Web is becoming increasingly
`more popular. Numerous audio formats are currently in use
`on the Web, including .AU,
`.AIFF,
`.WAV, MPEG, MIDI,
`Mod, etc. Even live audio can be downloaded from certain
`Web sites, as provided for by the RealAudio file format.
`Unfortunately, many people browse the Web using equip-
`ment that lacks the capability to process many of these file
`types, due to limitations in hardware, software, or both.
`Hence, it is desirable to provide a technique by which a
`computer or other processing system can access and play
`audio in a variety of different formats without requiring
`special hardware or software.
`In addition, it is desirable for a computer or other pro-
`cessing system to be able to play an audio file without
`having to wait for the entire file to be downloaded from a
`remote server. One factor which makes this capability dif-
`ficult to provide is that many audio data formats use a data
`rate that is significantly higher than that of the communica-
`tion link between the server supplying the audio file and the
`requesting computer. As a result,
`in many systems,
`the
`requesting (client) computer would tend to run out of audio
`data if it attempted to play the data before the file was
`
`2
`completely downloaded. Although portions of the file might
`be downloaded into memory and played before the file has
`finished downloading, memory limitations in the requesting
`computer may render this approach impractical. Therefore,
`it is desirable to provide a technique to enable a requesting
`computer or other processing system to play audio data as it
`is being received from a remote Web server while reducing
`the amount of audio data that must first be downloaded into
`memory.
`
`SUMMARY OF THE INVENTION
`
`The present invention includes a method in a first com-
`puter system connected to a second computer system of
`providing audio data to the second computer system. In the
`method, first audio data is received, and second audio data
`is generated based on the first audio data. The second audio
`data is then provided to the second processing system.
`Other features of the present invention will be apparent
`from the accompanying drawings and from the detailed
`description which follows.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The present invention is illustrated by way of example
`and not
`limitation in the figures of the accompanying
`drawings, in which like references indicate similar elements
`and in which:
`
`FIG. 1 illustrates a WebTV client system connected to a
`WebTV server system.
`FIG. 2 illustrates a WebTV client system.
`FIG. 3 illustrates a WebTV server system.
`FIG. 4 illustrates a WebTV server including a proxy cache
`and a transcoder.
`
`FIG. 5 illustrates a WebTV server including components
`for transcoding audio data.
`FIG. 6 is a flow diagram illustrating a routine for
`transcoding audio data.
`DETAILED DESCRIPTION
`
`A method and apparatus for transcoding audio data are
`described.
`In the following description, for purposes of
`explanation, numerous specific details are set forth in order
`to provide a thorough understanding of the present inven-
`tion. It will be evident, however, to one skilled in the art that
`the present invention may be practiced without these specific
`details.
`In other instances, well-known structures and
`devices are shown in block diagram form in order to
`facilitate description of the present invention.
`In one embodiment, steps according to the present inven-
`tion are embodied in machine-executable software
`instructions, and the present invention is carried out in a
`processing system by a processor executing the instructions,
`as will be described in greater detail below.
`In other
`embodiments, hardwired circuitry may be used in place of,
`or in combination with, software instructions to implement
`the present invention.
`The present invention relates in one embodiment to a
`system in which a client computer system is connected to
`one or more server computer systems over the Internet. The
`client system enables its user to request and receive hyper-
`text documents and other data from remote servers on the
`
`World Wide Web. In accordance with the present invention,
`as will be described below in detail, at least one server acts
`as a proxy for the client by retrieving audio files requested
`by the client from other servers, transcoding (modifying) the
`
`5
`
`10
`
`15
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`
`5,996,022
`
`3
`retrieved audio files based on the hardware and software
`capabilities of the client and communication bandwidth
`constraints, and then downloading the transcoded audio files
`to the client.
`
`In one embodiment, the present invention relates to a
`system known as WebTVTM (WebTV), which uses a stan-
`dard television set as a display device for browsing the Web
`and which connects to a conventional network, such as the
`Internet, using a standard telephone, ISDN, or other com-
`munication link. In accordance with the present invention, a
`user of a WebTV client system can utilize WebTV network
`services provided by one or more remote WebTV servers.
`The WebTV network services are used in conjunction with
`software running in a WebTV client system to browse the
`Web, send electronic mail, and to make use of the Internet
`in various other ways. The WebTV servers function as
`proxies by retrieving from a remote server Web documents
`(e.g., Web pages) and other data requested by a WebTV
`client system and then transmitting the requested informa-
`tion to the WebTV client system.
`I. System Overview
`FIG. 1 illustrates a configuration of a WebTV network
`according to one embodiment. AWebTV client 1 is coupled
`to a modem pool 2 via direct—dial, bidirectional data con-
`nections 29, which may be a conventional telephone, i.e.,
`“plain old telephone service” (POTS), ISDN (Integrated
`Services Digital Network) link, Ethernet, or any other suit-
`able type of data connection. The modem pool 2 is coupled
`typically through a router, such as that conventionally
`known in the art,
`to a number of remote servers 4 (i.e.,
`conventional Web servers) via a conventional network infra-
`structure 3, such as the Internet. The WebTV system also
`includes a WebTV server 5, which implements WebTV
`Network services and specifically supports the WebTV
`client 1. The server 5 generally includes one or more
`conventional computer systems. The server 5 may actually
`comprise multiple physical and logical devices connected in
`a distributed architecture. The client 1 can connect to the
`
`server 5 through POTS, ISDN, or Ethernet connection or
`through the Internet 3 via the modem pool 2. Note that the
`modem pool 2 is a conventional modem pool, such as those
`found today throughout the world providing access to the
`Internet and private networks. The modem pool 2 may be
`provided by a local Internet Service Provider (ISP).
`A. Client System Architecture
`FIG. 2 illustrates a WebTV client system 1 according to
`one embodiment. The client system 1 includes an electronics
`unit 10 (hereinafter referred to as “the WebTV box 10” or
`“the box 10”), an ordinary television set 12, and a hand-held
`remote control 11.
`In an alternative embodiment
`(not
`shown), the WebTV box 10 is built into the television set 12
`as an integral unit. The box 10 includes hardware and
`software for providing the user with a graphical user
`interface, by which the 11ser can access the WebTV Network
`services, i.e., browse the Web, send e-mail, etc.
`The client system 1 uses the television set 12 as a display
`device and an audio output device. The box 10 is coupled to
`the television set 12 by a link 6. The link 6 includes an audio
`channel for generating sound from the television’s speaker
`and an RF (radio frequency), S-video, composite video, or
`other equivalent form of video channel. The data link 29
`between the box 10 and the WebTV server 5 is a conven-
`
`tional telephone (POTS), ISDN, Ethernet, or other suitable
`data connection. The box 10 receives AC (alternating
`current) power through a standard AC power line 7.
`Remote control 11 is operated by the user in order to
`control the client system 1 to browse the Web and otherwise
`
`10
`
`15
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`access the Internet. The box 10 receives cor11r11ands fron1
`
`remote control 11 via an infrared (IR) communication link.
`In alternative embodiments, the link between the remote
`control 11 and the box 10 may be an RF li11k or any other
`suitable type of link.
`B. Server System Architecture
`The WebTV server 5 generally includes one or more
`computer systems, each generally having the architecture
`illustrated in FIG. 3. It should be noted that the illustrated
`
`architecture is only exemplary; a WebTV server is not
`constrained to the illustrated architecture. The illustrated
`
`architecture includes a central processing unit (CPU) 50,
`read-only memory (ROM) 51,
`random access memory
`(RAM) 52, a mass storage device 53, a modem 54, a network
`interface card (NIC) 55, and various other input/output (I/O)
`devices 56. Mass storage device 53 includes any suitable
`non-volatile storage medium, such as a magnetic storage
`disk or
`tape, CD-ROM (Compact Disk ROM), CD-R
`(Compact Disk Recordable), or DVD (Digital Versatile
`Disk). I/O devices 56 may include any or all of devices such
`as a display monitor, keyboard, cursor control device, etc.
`Modern 54 is used to communicate data to and from remote
`servers 4 via the Internet. Note that modem 54 may represent
`a standard telephone modem or any other suitable data
`communication device, such as an ISDN adapter,
`for
`example.
`Because the server 5 may actually comprise multiple
`physical and logical devices connected in a distributed
`architecture, NIC 55 may be used to provide data commu-
`nication with other devices that are part of the WebTV
`services. Modern 54 may also be used to communicate with
`other devices that are part of the WebTV services and which
`are not located in close geographic proximity to the illus-
`trated device.
`
`invention includes steps which may be
`The present
`embodied as machine-executable instructions. For example,
`in one embodiment the present invention is carried out in the
`WebTV server 5 by the CPU 50 executing sequences of
`instructions contained in ROM 51, RAM 52, mass storage
`device 53, or a combination of these storage devices. More
`specifically, execution of the sequences of instructions
`causes the CPU 50 to perform the steps of the present
`invention. Such steps will be described below. Certain
`embodiments and aspects of the present invention may be
`carried out in the WebTV client system 1 instead of, or in
`addition to, being carried out in the WebTV server 5.
`Computer instructions embodying the present invention
`may be loaded into memory from a persistent store (e.g.,
`mass storage device 53) and/or from one or more other
`computer systems referred to collectively as a “host com-
`puter system”, over a network. For example, a host computer
`system may transmit the instructions to a requesting com-
`puter system in response to a message transmitted to the host
`computer system over the Internet 3 by the requesting
`computer system. As the requesting computer system
`receives the instructions via a network connection (e.g., a
`modem), the requesting computer system stores the instruc-
`tions in a memory. The requesting computer system may
`store the instructions for later execution or execute the
`
`instructions as they arrive over the network connection. In
`some embodiments,
`the downloaded instructions may be
`directly supported by the requesting computer system’s
`niicroprocessor. Consequently, execution of the instructions
`may be performed directly by the microprocessor. In other
`embodiments, the instructions may not be directly execut-
`able by the microprocessor. Under these circumstances, the
`
`

`
`5,996,022
`
`5
`instructions may be executed by causing the microprocessor
`to execute an interpreter that interprets the instructions, or by
`causing the microprocessor to execute instructions which
`convert the received instructions into instructions that can be
`directly executed by the microprocessor.
`In various embodiments, hardwired circuitry may be used
`in place of, or in combination with, software instructions to
`implement the present invention. Thus, the present invention
`is not
`limited to any specific combination of hardware
`circuitry and software, nor to any particular source for the
`instructions executed by a computer system.
`The WebTV server 5 generally functions as a proxy for
`the client 1 for purposes of providing the client 1 with access
`to a remote Web server 4 and to various services.
`In
`
`performing the proxy functions, the server 5 further provides
`caching and transcoding capabilities for the client 1, as
`illustrated in FIG. 4. Referring to FIG. 4, the WebTV server
`5 includes a transcoder 66 and a proxy cache 65, which are
`functionally coupled together and to the Internet 3. The
`function of the proxy cache 65 is to temporarily store Web
`documents, images, and other information that is requested
`frequently by either the WebTV client 1 or the server 5. The
`function of the transcoder 66 is to automatically modify
`certain documents and files retrieved from a remote server 4.
`Modification such as this is referred to herein as “transcod-
`ing”. Transcoding may be performed for various dilferent
`purposes, depending upon the type of data that is being
`transcoded.
`
`In accordance with the present invention, one function of
`the transcoder 66 is to transcode audio files requested by the
`client 1 to conform the audio files to the hardware and
`software capabilities of the client 1 and to meet bandwidth
`constraints of the communication link between the server 5
`and the client 1, as will now be described.
`II. Audio Transcoding
`Transcoding of audio data may include conversion of an
`audio file from one file type to another, compression of audio
`data, reduction of the number of audio channels represented
`by the audio data, or reduction of the sampling rate of the
`audio data, or a combination of these procedures. Transcod-
`ing in accordance with the present invention is not limited to
`the aforementioned operations, however.
`Various audio file types are currently known, such as .AU,
`.AIFF,
`.WAV, MPEG (Moving Picture Experts Group),
`MIDI (Musical Instrument Digital Interface), RealAudio,
`Mod (Module), etc. If the client 1 is not configured (in terms
`of hardware, software, or both) to accommodate the file type
`of an audio file which it requests,
`then transcoding is
`performed by the server 5 to convert the requested audio file
`into a file type which the client 1 can accommodate. As a
`more specific example,
`it may be desirable to convert a
`streamed audio format, such as RealAudio,
`to a non-
`streamed format, such as .AU. Note that audio files generally
`specify the file type in a header within the audio file, which
`enables the server 5 to quickly determine that transcoding is
`required even before the entire file has been retrieved from
`the remote server 4.
`
`Transcoding may include compression of audio data,
`reduction of the number of audio channels represented by
`the audio data, or reduction of the sampling rate of the audio
`data, in order to conform the data to the memory or other
`hardware configuration of the client 1 or the bandwidth of
`the communication link. For example, when a file is
`requested by the client 1, there is a download latency (delay)
`defined as the time from which the client 1 requests the file
`until the time at which the client 1 actually receives the file
`
`6
`in its entirety. This latency tends to be quite variable because
`of the variable nature of Internet
`traffic and server use.
`
`However, latencies associated with downloading of audio
`files tend to be high due to the relatively large size of many
`audio files. Download latency is further affected by the
`speed of the communication devices (i.e., modems) involved
`in the data transfer and the bandwidth capacity of the
`communication link. Therefore, data compression and other
`techniques for reducing the amount of data that must be
`downloaded may be desirable in order to reduce such
`latencies.
`In addition, because the client 1 has a finite
`amount of storage capability, it may be further desirable to
`reduce the size of certain audio files (e.g., unusually large
`files).
`In addition, transcoding according to the present inven-
`tion can enable the client 1 to begin playing an audio file
`without having to wait for the entire file to be downloaded.
`One factor which makes it difficult to provide such capabil-
`ity in the absence of the present invention is that many audio
`data formats have a data rate that is significantly higher than
`that of the communication link between the server 5 and the
`
`client 1. As a result, in certain systems, a client would tend
`to run out of audio data if it attempted to play the data before
`the file was completely downloaded. Therefore, it may be
`desirable in some cases to reduce the data rate of a requested
`audio file. Hence, transcoding to reduce the data rate enables
`audio data to be streamed to the client 1, which data would
`be otherwise unusable on a system which uses a low
`bandwidth connection and/or limited storage capabilities.
`A particular client 1 also might not be configured to play
`audio in stereo. Therefore, if a requested audio file includes
`stereo data, then the data can be transcoded into a single-
`channel (“mono”) format to reduce the file size.
`Transcoding may take the form of modification the audio
`file retrieved from the remote server 4, creation of an
`entirely separate audio file based on the audio file retrieved
`from the remote server 4, or both. In either case,
`the
`modified or new file is referred to as the “transcoded file”.
`
`the
`When an audio file is requested by the client 1,
`WebTV server 5 determines the extent and type of modifi-
`cations to be performed on the audio file as the audio file is
`received by the WebTV server 5 from the remote server 4.
`Note that the above-described audio transcoding techniques
`may result in a trade-off between the resulting file size and
`the quality of audio that can be generated. Therefore, the
`extent and type of the modifications to the data are deter-
`mined on the basis of the file format or formats which the
`
`10
`
`15
`
`30
`
`35
`
`40
`
`45
`
`50
`
`client 1 is configured to handle, the size of the requested
`audio file, the memory capacity of the client, 1 the band-
`width of the connection between the local server and the
`
`55
`
`60
`
`65
`
`client, and the level of audio quality that is desired or
`required. It is assumed that the WebTV server 5 has some
`form of knowledge of the hardware and software config11-
`ration of the client 1.
`
`The server 5 can use any of three different modes for
`transcoding of audio files: (1) streamed transcoding, (2)
`buffered transcoding, and (3) deferred transcoding.
`Streamed transcoding is the transcoding of a file on a
`byte-by-byte basis (or a number of bytes at a time) as the file
`is being both retrieved from a remote server 4 and down-
`loaded to the client 1—this mode is also referred to as
`transcoding “on-the-fly”. Streamed transcoding is most
`desirable in terms of reducing the latency experienced by the
`client 1. It should be noted that the streamed transcoding
`mode does involve limited buffering of audio data, as will be
`explained below.
`
`

`
`5,996,022
`
`7
`The buffered transcoding mode is used for certain files
`which must be completely buffered in the WebTV server 5
`before they are transcoded. That is, a file may need to be
`buffered before transmitting it to the client 1 if the type of
`changes to be n1ade can only be made after the entire file has
`been retrieved from the remote server 4. Because the process
`of retrieving and downloading a file to the client 1 increases
`latency and decreases throughput, it is not desirable to buffer
`all files. Therefore, the transcoder 66 uses any previously
`acquired information relating to requested audio files to
`determine whether a requested file must be buffered for
`purposes of transcoding, before the audio file is retrieved
`from a remote server 4. Such information may be stored in
`a persistent database within the WebTV server 5.
`In the deferred mode, transcoding is deferred until after a
`requested file has been downloaded to a particular client 1.
`The deferred mode therefore reduces latency experienced by
`the client 1 in receiving the (non-transcoded) file and allows
`the transcoded file to be downloaded to a client 1 at a later
`time. Transcoding may be performed immediately after
`downloading to the client 1 or at any time thereafter. For
`example,
`it may be convenient
`to perform transcoding
`during periods of low usage of WebTV services, such as at
`night.
`FIG. 5 illustrates functional modules of a WebTV server
`5 that are associated with the transcoding of audio data,
`according to one embodiment. The WebTV server 5 includes
`a virtual stream cache (VSC) 71 which receives a requested
`audio file from a remote server 4. The VSC 71 operates in
`either a random access mode or a sequential mode, as
`selected by the proxy transform module 72. In the random
`access mode, the VCS 71 buffers a small amount of a11dio
`data (rclativc to thc filc size) from thc audio filc bcing
`retrieved. This buffered data can be randomly accessed by
`the proxy transform module 72, the audio transcoder 66a, or
`both, as described below. Hence, when in the random mode,
`the VSC 71 effectively provides a file-like random access
`interface to otherwise sequential audio data. When switched
`to the sequential mode, any previously buffered audio data
`is discarded by the VSC 71 and any further audio data
`received by the VSC 71 is output sequentially (byte-by-byte
`or a number of bytes at a time) to the proxy transform
`module 72 or the audio transcoder 66a.
`
`By examining audio data buffered by the VSC 71, the
`proxy transform module 72 determines whether transcoding
`is appropriate and, if so, what “level” of transcoding (i.e., the
`type(s) and extent of transcoding) is to be performed. Once
`these determinations are made, the proxy transform module
`72 configures the audio transcoder 66a to perform the
`appropriate level (types or extent) of transcoding, as repre-
`sented by the signal CONFIGURE in FIG. 5. To make the
`transcoding determinations, the proxy transform module 71
`first configures the VSC 71 in random access mode and
`configures the VCS 71 to buffer some small amount of data
`(relative to tl1e size of the audio file). The proxy transform
`module 72 then requests and examines, in a random access
`manner, audio data buffered in the VSC 71, until the proxy
`transform module 72 is able to make the transcoding deter-
`minations. Once the determinations have been made,
`the
`proxy transform module 72 then immediately switches the
`VSC 71 to the sequential mode. Ilence, the VSC 71 buffers
`only as much data as is required to enable the transcoding
`determination to be made.
`
`Prior to transmitting a file to tl1e client, the proxy trar1s-
`form module 72 provides the client 1 with any information
`regarding the level of transcoding to be performed (if any)
`which may be required by the client 1 and which is not
`
`10
`
`15
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`in tlie transcoded file itself. This information is
`implicit
`provided to the client 1 in the form of a special-purpose
`header, as represented by the signal HEADER. This header
`may specify the new file type and/or compression used, for
`example.
`The audio transcoder 66a is a component of transcoder
`66. The audio transcoder 66a requests data from the VSC 71,
`transcodes the received data, and provides a transcoded file
`to the client 1, as represented by signal AUDIO FILE. The
`audio transcoder 66a generally requests data for transcoding
`while the VSC 71 is in the sequential mode. Transcoding
`may begin before the file has been completely received by
`the WebTV server 5 from the remote server 4, which helps
`to reduce the latency experienced by the client 1. Similarly,
`downloading of the transcoded file to the client 1 may begin
`before the original file has been completely transcoded
`and/or before the original file has been completely received
`by the WebTV server 5 from the remote server 4. Down-
`loading of the transcoded file to the client 1 can be per-
`formed by streaming the data, semi-streaming (in which
`relatively large portions of the file are transmitted at a time),
`or by transmitting the entire transcoded file in a single
`transmission.
`
`FIG. 6 illustrates a routine for transcoding audio data
`performed by the server 5. In step 601, the WebTV server 5
`receives a request for an audio file from the cl