JP2012521268A - マルチストリームビデオ圧縮のためのシステム及び方法 - Google Patents

マルチストリームビデオ圧縮のためのシステム及び方法 Download PDF

Info

Publication number
JP2012521268A
JP2012521268A JP2012502114A JP2012502114A JP2012521268A JP 2012521268 A JP2012521268 A JP 2012521268A JP 2012502114 A JP2012502114 A JP 2012502114A JP 2012502114 A JP2012502114 A JP 2012502114A JP 2012521268 A JP2012521268 A JP 2012521268A
Authority
JP
Japan
Prior art keywords
video
game
user
frame
stream
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2012502114A
Other languages
English (en)
Other versions
JP2012521268A5 (ja
Inventor
スティーブン ジー パールマン
デル ラーン ロジャー バン
ティモシー コッター
スコット ファーマン
ロバート マックール
イアン バックリー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OnLive Inc
Original Assignee
OnLive Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=42781402&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=JP2012521268(A) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by OnLive Inc filed Critical OnLive Inc
Publication of JP2012521268A publication Critical patent/JP2012521268A/ja
Publication of JP2012521268A5 publication Critical patent/JP2012521268A5/ja
Pending legal-status Critical Current

Links

Classifications

    • A63F13/12—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/24—Systems for the transmission of television signals using pulse code modulation
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/33—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections
    • A63F13/335—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections using Internet
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A63F13/355—Performing operations on behalf of clients with restricted processing capabilities, e.g. servers transform changing game scene into an MPEG-stream for transmitting to a mobile phone or a thin client
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A63F13/358—Adapting the game course according to the network or server load, e.g. for reducing latency due to different connection speeds between clients
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/131—Protocols for games, networked simulations or virtual reality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/107—Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/132—Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/188—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a video data packet, e.g. a network abstraction layer [NAL] unit
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/436—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation using parallelised computational arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/233—Processing of audio elementary streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43072—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of multiple content streams on the same device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/439—Processing of audio elementary streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4781—Games
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/77—Game security or game management aspects involving data related to game devices or game servers, e.g. configuration data, software version or amount of memory
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/40—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of platform network
    • A63F2300/402—Communication between platforms, i.e. physical link to protocol
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/40—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of platform network
    • A63F2300/407—Data transfer via internet
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/53—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing
    • A63F2300/534—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing for network load management, e.g. bandwidth optimization, latency reduction
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/53—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing
    • A63F2300/535—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing for monitoring, e.g. of user parameters, terminal parameters, application parameters, network parameters
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/53—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing
    • A63F2300/538—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing for performing operations on behalf of the game client, e.g. rendering
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55—Details of game data or player data management
    • A63F2300/552—Details of game data or player data management for downloading to client devices, e.g. using OS version, hardware or software profile of the client device
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/57—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of game services offered to the player
    • A63F2300/577—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of game services offered to the player for watching a game played by other players
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/10—Adaptations for transmission by electrical cable
    • H04N7/106—Adaptations for transmission by electrical cable for domestic distribution

Abstract

ビデオゲームサーバーは、オンラインビデオゲームに関連したユーザ入力を受け取ってビデオ映像のシーケンスをレンダリングし、第１のストリームエンコーダは、ビデオ映像のシーケンスを圧縮し、クライアント装置のユーザとの生のゲームセッション中に生のビデオストリームを発生し、第１のストリームエンコーダは、クライアント装置からチャンネルフィードバック信号を受信し、それに応答して、そのチャンネルフィードバック信号に基づいてビデオ映像のシーケンスの圧縮を適応させる。第２のストリームエンコーダは、ユーザとの生のゲームセッション中にチャンネルフィードバック信号とは無関係の特定のビデオ画質及び／又は圧縮比でビデオ映像のシーケンスを圧縮して、生のビデオストリームより比較的高いビデオ画質及び／又は低い圧縮比をもつ高画質（ＨＱ）ビデオストリームを発生し、そして記憶装置は、要求があった際にクライアント装置のユーザ及び他のユーザへその後に再生するためにＨＱビデオストリームを記憶する。
【選択図】図２ａ

Description

本発明は、一般的に、オーディオ及びビデオメディアを操作し及びそれにアクセスするユーザの能力を改善するデータ処理システムの分野に係る。
関連出願：本出願は、２００９年３月２３日に出願された“System And Method For Compressing Video Using Feedback”と題する米国プロビジョナル特許出願第６１／２１０，８８８号の優先権を主張するものであり、該出願は、２００９年１月２３日に出願された“System and Method for Protecting Certain Types of Multimedia Data Transmitted Over A Communication Channel”と題する同時係争中の米国特許出願第１２／３５９，１５０号の一部継続（ＣＩＰ）出願であると共に、２００７年１２月５日に出願された“Hosting And Broadcasting Virtual Events Using Streaming Interactive Video”と題する同時係争中の米国特許出願第１１／９９９，４７５号の継続出願であり、更に、該出願は、２００２年１２月１０日に出願され、本ＣＩＰ出願の譲受人に譲渡された“APPARATUS AND METHOD FOR WIRELESS VIDEO GAMING”と題する米国特許出願第１０／３１５，４６０号の一部継続出願である。
記録音声及び動画メディアは、トーマスエジソンの時代から世相を表している。２０世紀の初頭に、記録音声メディア（シリンダー及びレコード）及び動画メディア（ニコロデオン及び映画）が広く配給されたが、両技術は、まだ幼時期であった。１９２０年代後期に、動画が大量市場ベースで音声と結合され、その後、音声を伴うカラー動画となった。ラジオ放送は、大規模な広告支援形態の放送大量市場音声メディアへと徐々に進化した。１９４０年代中期にテレビ（ＴＶ）放送規格が確立されると、テレビは、予め録画された又は生の動画を家庭へ届ける放送大量市場メディアの一形式としてラジオに加わった。
２０世紀中期までは、米国の家庭の大部分は、記録音声メディアを再生する蓄音器レコードプレーヤ、生放送音声を受信するラジオ、及び生放送オーディオ／ビデオ（Ａ／Ｖ）メディアを上映するテレビ受像機を有していた。多くの場合に、これら３つの「メディアプレーヤ」（レコードプレーヤ、ラジオ及びＴＶ）は、共通のスピーカを共有する１つのキャビネットに結合されて、家庭の「メディアセンター」となった。メディアの選択肢は、消費者に制限されるが、メディア「エコシステム」は、かなり安定したものであった。ほとんどの消費者は、「メディアプレーヤ」をどのように使用するか知っており、それらの能力をフルに楽しむことができた。同時に、メディアの発行者（主に動画及びテレビスタジオ、並びに音楽会社）は、一般に普及した海賊版又は「二次販売」即ち中古メディアの再販から悩まされることなく、それらのメディアを劇場及び家庭の両方に配給することができた。典型的に、発行者は、二次販売から収入を得ず、従って、そうでなければ新規販売のために中古メディアの買い手から発行者が得るかもしれない収入が減少した。２０世紀の中期に販売された中古レコードは確かにあるが、そのような販売は、レコード発行者に大きな影響を及ぼさなかった。というのは、典型的に大人が一度又は数回見るだけの動画又はビデオ番組とは異なり、音楽トラックは、数百回又は数千回も聞かれるからである。従って、音楽メディアは、動画／ビデオメディアより遥かに「腐敗」しない（即ち、大人の消費者にとって価値が継続する）。レコードを購入すると、消費者がその音楽が好きな場合、消費者は、おそらくそれを長期間保持する。
２０世紀の中期から今日にかけて、メディアエコシステムは、消費者及び発行者の利益及び損害の両方にとって一連の根本的な変化を受けた。オーディオレコーダー、特に、高品質ステレオサウンド付きのカセットテープが広く導入されると、確かに高度の消費者便宜性があった。しかし、それは、消費者メディアと共に今や広く普及したもの、即ち海賊版の始まりも印した。確かに、大勢の消費者が彼ら自身のレコードを純粋に便宜性のためにテープ記録するのにカセットテープを使用したが、次第に多くの消費者（例えば、互いのレコードコレクションに手早くアクセスできる寄宿舎の学生）が海賊版コピーを作成した。又、消費者は、発行者からレコードやテープを買うのではなく、ラジオを経て演奏される音楽もテープ記録した。
消費者向けＶＣＲの出現は、新規なＶＣＲがＴＶショーを録画するようにセットでき、後で見ることができるので、更なる消費者便宜性を導くと共に、映画やＴＶ番組に「オンデマンド」ベースでアクセスできるビデオレンタルビジネスの創設も導いた。１９８０年代中期以来の大量市場家庭用メディア装置の急速な開発は、かつてない選択肢レベル及び消費者にとっての便宜性を導くと共に、メディア発行市場の急速な膨張も導いた。
今日、消費者は、過度のメディア選択肢及び過度のメディア装置に直面し、その多くは、特定の形式のメディア又は特定の発行者に結び付いたものである。熱心なメディア消費者は、家の種々の部屋にＴＶ及びコンピュータに接続された装置を積み重ねて有し、その結果、１つ以上のＴＶ受像機及び／又はパーソナルコンピュータ（ＰＣ）へのケーブルの「ネズミの巣穴」、並びにリモートコントローラのグループが生じている。（本出願に関して、「パーソナルコンピュータ」又は「ＰＣ」という語は、デスクトップ、Ｍａｃｉｎｔｏｓｈ（登録商標）又は他の非Ｗｉｎｄｏｗｓ（登録商標）コンピュータ、Ｗｉｎｄｏｗｓ適合装置、Ｕｎｉｘ（登録商標）バリエーション、ラップトップ、等を含めて、家庭又はオフィスで使用するのに適した任意の種類のコンピュータを指す。）これらの装置は、ビデオゲームコンソール、ＶＣＲ、ＤＶＤプレーヤ、オーディオサラウンド−サウンドプロセッサ／増幅器、衛星セットトップボックス、ケーブルＴＶセットトップボックス、等を含む。そして、熱心な消費者にとって、互換性の問題があるために、複数の類似機能装置が存在する。例えば、消費者は、ＨＤ−ＤＶＤ及びＢｌｕ−ｒａｙ ＤＶＤプレーヤの両方を所有したり、又はＭｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）及びＳｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ（登録商標）の両ビデオゲームシステムを所有したりすることがある。実際に、あるゲームはゲームコンソールのバージョンにわたって互換性がないために、消費者は、ＸＢｏｘと、その後のバージョン、例えば、Ｘｂｏｘ３６０（登録商標）との両方を所有することがある。多くの場合、消費者は、どのビデオ入力及びどのリモートコントローラを使用すべきか混乱する。ディスクが正しいプレーヤ（例えば、ＤＶＤ、ＨＤ−ＤＶＤ、Ｂｌｕ−ｒａｙ、Ｘｂｏｘ又はＰｌａｙｓｔａｔｉｏｎ）に入れられ、その装置に対してビデオ及びオーディオ入力が選択され、そして正しいリモートコントローラが見つかった後でも、消費者は、まだ、技術的な挑戦に直面する。例えば、ワイドスクリーンＤＶＤのケースでは、ユーザは、先ず、自分のＴＶ又はモニタスクリーンにおける正しいアスペクト比（例えば、４：３、フル、ズーム、ワイドズーム、シネマワイド、等）を決定し、次いで、セットすることが必要になる。同様に、ユーザは、先ず、正しいオーディオサラウンドサウンドシステムフォーマット（例えば、ＡＣ−３、ドルビーデジタル、ＤＴＳ、等）を決定し、次いで、セットすることが必要になる。多くの場合、消費者は、彼等のテレビ又はオーディオシステムのフル能力でメディアコンテンツを楽しんでいないことに気付かない（例えば、間違ったアスペクト比で押しつぶされた映画を見たり、又はサラウンドサウンドではなくステレオでオーディオを聞いたりしている）。
装置の積み重ね体には、インターネットベースのメディア装置が益々追加されている。Ｓｏｎｏｓ（登録商標）デジタルミュージックシステムのようなオーディオ装置は、インターネットからオーディオを直接ストリーミングしている。同様に、Ｓｌｉｎｇｂｏｘ（登録商標）エンターテイメントプレーヤのような装置は、ビデオを録画し、そしてホームネットワーク又はインターネットを通してそれをストリーミングし、遠隔位置でＰＣにおいてそれを見ることができる。インターネットプロトコルテレビジョン（ＩＰＴＶ）サービスは、デジタルサブスクライバーライン（ＤＳＬ）又は他のホームインターネット接続を通してケーブルＴＶ型のサービスを提供している。又、最近では、Ｍｏｘｉ（登録商標）メディアセンターや、Ｗｉｎｄｏｗｓ ＸＰメディアセンターエディションを実行するＰＣのような単一の装置へ複数のメディアファンクションを一体化する努力もなされている。これらの装置は、各々、それが遂行するファンクションに対する便宜性の要素を与えるが、偏在性及びほとんどのメディアへの簡単なアクセス性が欠如している。更に、このような装置は、多くの場合に高価な処理及び／又はローカル記憶が必要なために、製造コストがしばしば数百ドルに達する。更に、これらの近代的な消費者向け電子装置は、典型的に、アイドル状態である間も、多量の電力を消費し、これは、時間と共に経費高となり且つエネルギーリソースを浪費することを意味する。例えば、ある装置は、消費者がそれをターンオフするのを怠るか又は異なるビデオ入力へスイッチした場合に動作し続けることがある。そして、どの装置も完全な解決策ではないので、家庭内の装置の他の積み重ね体と一体化しなければならず、これでは、依然、ユーザをワイヤのネズミの巣穴及びリモートコントローラの海に残すことになる。
更に、多くの新しいインターネットベースの装置は、それが適切に機能するときには、典型的に、メディアを、それが入手できる以上に一般的な形態で提供する。例えば、インターネットを通してビデオをストリーミングする装置は、多くの場合、ビデオ、ゲームの「制作」又は演出家の解説のようなＤＶＤをしばしば付随する双方向「エキストラ」ではなく、ビデオ資料だけをストリーミングする。これは、多くの場合、双方向性をローカルに取り扱う特定の装置に意図された特定のフォーマットで双方向資料が発生されることによるものである。例えば、ＤＶＤ、ＨＤ−ＤＶＤ及びＢｌｕ−ｒａｙディスクは、それら自身の特定の双方向フォーマットを有している。普及型フォーマットを全てサポートするように開発されるホームメディア装置又はローカルコンピュータは、おそらく消費者が動作するには法外なほど高価で且つ複雑なものにするレベルの精巧さ及び融通性を要求することになる。
この問題に加えて、将来的に新規なフォーマットが導入された場合には、ローカル装置は、その新規なフォーマットをサポートするハードウェア能力をもたないことがあり、これは、消費者がアップグレード型のローカルメディア装置を購入しなければならないことを意味する。例えば、高解像度ビデオ又はステレオビデオ（例えば、各目に対して１つのビデオストリーム）が後日に導入された場合には、ローカル装置は、そのビデオをデコードする計算能力をもたないか、又は新たなフォーマットでビデオを出力するためのハードウェアをもたないことがある（例えば、各目に６０ｆｐｓが与えられて、１２０ｆｐｓのビデオがシャッター付き眼鏡と同期されることでステレオ感が達成されると仮定すれば、消費者のビデオハードウェアが６０ｆｐｓビデオしかサポートできない場合、このオプションは、アップグレード型ハードウェアを購入しなければ、利用できない）。
メディア装置の老朽化及び複雑さの問題は、精巧な双方向メディア、特に、ビデオゲームに至ったときには、重大な問題となる。
近代的なビデオゲームアプリケーションは、主として、４つの主要な非ポータブルハードウェアプラットホーム：即ち、Ｓｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ（登録商標）１、２及び３（ＰＳ１、ＰＳ２及びＰＳ３）、Ｍｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）及びＸｂｏｘ ３６０（登録商標）、Ｎｉｎｔｅｎｄｏ Ｇａｍｅｃｕｂｅ（登録商標）及びＷｉｉTM、並びにＰＣベースのゲーム、に分割される。これらプラットホームの各々は、他のものとは異なり、１つのプラットホームで実行するように書かれたゲームは、別のプラットホームでは実行されない。又、装置のある世代から次の世代への互換性の問題もある。ソフトウェアゲーム開発者の大半が、特定のプラットホームとは独立して設計されたソフトウェアゲームを創作しても、特定のゲームを特定のプラットホームで実行するためには、特定のプラットホームで使用するようにゲームを適応させるのに、ソフトウェアの専有レイヤ（しばしば「ゲーム開発エンジン」と称される）が必要になる。各プラットホームは、消費者へ「コンソール」（即ち、ＴＶ又はモニタ／スピーカに取り付けられるスタンドアローンボックス）として販売されるか、或いはＰＣそれ自体である。典型的に、ビデオゲームは、精巧なリアルタイムソフトウェアアプリケーションとして実施されるビデオゲームを含むＢｌｕ−ｒａｙ ＤＶＤ、ＤＶＤ−ＲＯＭ、又はＣＤ−ＲＯＭのような光学的メディアで販売される。家庭用ブロードバンドの速度が高まるにつれて、ビデオゲームは、ダウンロードに利用されることが益々増えている。
ビデオゲームソフトウェアとのプラットホーム互換性を得るための特定の要件は、進歩型ビデオゲームのリアルタイム性及び高計算要件のために極めて厳しいものである。例えば、あるＰＣから、より速い処理ユニット又はコアをもつ別のＰＣへの製造アプリケーション（例えば、マイクロソフトワード）の一般的な互換性と同様に、ビデオゲームのある世代から次の世代への（例えば、ＸＢｏｘからＸＢｏｘ３６０への、又はＰｌａｙｓｔａｔｉｏｎ２（ＰＳ２）からＰｌａｙｓｔａｔｉｏｎ３（ＰＳ３）への）完全なゲーム互換性が期待される。しかしながら、ビデオゲームでは、このようにならない。ビデオゲームの製造者は、典型的に、あるビデオゲーム世代が発売になるときに所与の価格点に対して考えられる最高の性能を求めているので、前世代システムに対して書かれた多くのゲームが後世代システムでは機能しないような急激なアーキテクチャー変更がシステムに対してしばしばなされる。例えば、ＸＢｏｘは、プロセッサのｘ８６ファミリーをベースとしたものであり、一方、ＸＢｏｘ３６０は、ＰｏｗｅｒＰＣファミリーをベースとしたものである。
従来のアーキテクチャーをエミュレートするための技術を利用できるが、ビデオゲームがリアルタイムアプリケーションであるとすれば、エミュレーションにおいて厳密に同じ挙動を達成することはしばしば不可能である。これは、消費者、ビデオゲームコンソール製造者、及びビデオゲームソフトウェア発行者にとって損害である。消費者については、全てのゲームをプレイできるようにするために、ビデオゲームコンソールの新旧の世代をＴＶに接続したままにする必要があることを意味する。コンソールの製造者については、エミュレーションに関連したコスト、及び新規コンソールの採用に手間取ることを意味する。又、発行者については、全ての潜在的な消費者に届くように、新たなゲームの複数のバージョンを発売する必要があり、即ちビデオゲームのブランド（例えば、ＸＢｏｘ、Ｐｌａｙｓｔａｔｉｏｎ）ごとのバージョンを発売するだけでなく、所与のブランドのバージョン（例えば、ＰＳ２及びＰＳ３）ごとのバージョンをしばしば発売する必要がある。例えば、他のプラットホームの中でも、ＸＢｏｘ、ＸＢｏｘ ３６０、ＰＳ２、ＰＳ３、Ｇａｍｅｃｕｂｅ、Ｗｉｉ及びＰＣに対して、エレクトロニックアーツ“Ｍａｄｄｅｎ ＮＦＬ ０８”の個別バージョンが開発されている。
セルラー（セル）電話及びポータブルメディアプレーヤのようなポータブル装置も、ゲーム開発者への挑戦を提示する。次第に、このような装置は、ワイヤレスデータネットワークに接続されており、ビデオゲームをダウンロードできるようになっている。しかし、市場には、広範囲な異なる表示解像度及び計算能力をもつ種々様々なセル電話及びメディア装置が出回っている。又、このような装置は、典型的に、電力消費、コスト及び重量に制約があるので、カリフォルニア州サンタクララのＮＶＩＤＩＡで製造される装置、等のグラフィックプロセッシングユニット（ＧＰＵ）のような進歩型グラフィック加速ハードウェアに欠けるものである。その結果、ゲームソフトウェアの開発者は、典型的に、多数の異なる形式のポータブル装置に対して所与のゲームタイトルを同時に開発する。ユーザは、自分の特定のセル電話又はポータブルメディアプレーヤに対して所与のゲームタイトルが得られないことが分かる。
家庭用ゲームコンソールの場合には、ハードウェアプラットホームの製造者は、典型的に、彼等のプラットホームでゲームを発行する能力についてソフトウェアゲーム開発者にロイヤリティを課する。セル電話の電信会社も、典型的に、ゲームをセル電話にダウンロードするためにゲーム発行者にロイヤリティを課する。ＰＣゲームの場合には、ゲームを発行するために支払われるロイヤリティはないが、ゲームの開発者は、典型的に、生じ得る広範囲のＰＣコンフィギュレーション及びインストール問題をサポートするための消費者サービス負担が大きいために、高いコストに直面する。又、ＰＣは、典型的に、ゲームソフトウェアの海賊行為に対してバリアがほとんどない。というのは、それらは、技術的知識のあるユーザによって再プログラムが容易であり、ゲームの海賊版を容易に作成して（例えば、インターネットを通して）容易に配布することができる。従って、ソフトウェアゲーム開発者については、ゲームコンソール、セル電話及びＰＣにおいて発行する上でコストがかかり且つ欠点があることになる。
コンソール及びＰＣソフトウェアのゲーム発行者にとって、コストは、これだけでは終わらない。小売チャンネルを通してゲームを配布するために、発行者は、利ざやを得るように小売店の販売価格より低い卸売価格を課する。又、発行者は、典型的に、製造コストを支払いそしてゲームを保持する物理的メディアを配布しなければならない。又、発行者は、例えば、ゲームが売れない場合、ゲームの価格が下がった場合、或いは小売店が卸売価格の一部又は全部を払い戻し及び／又はゲームを買い手から引き取らねばならない場合に考えられる不測の事態をカバーするために小売店により「価格保護費用」がしばしば課せられる。更に、小売店は、典型的に、広告チラシでゲームを市場に出す上で助けとなるように発行者に費用を課する。更に、小売店は、ゲームをプレイし終えたユーザからゲームを買い戻して、それを中古ゲームとして販売し、典型的に、中古ゲームの収入をゲーム発行者と分配しないことが増えている。ゲーム発行者に課せられるコスト負担に加えて、しばしばゲームの海賊版が作成されてインターネットを通して配布され、ユーザがそれをダウンロードして無料でコピーする事態になっている。
インターネットのブロードバンド速度が高まりつつあり、そして米国内及び世界中で、特に、家庭や、インターネット接続ＰＣがレンタルされるインターネット「カフェー」へのブロードバンド接続がより一般的になってきているので、ゲームは、ＰＣ又はコンソールへのダウンロードを経て益々配布されてきている。又、マルチプレーヤ及び大規模マルチプレーヤのオンラインゲームをプレイするためにブロードバンド接続が益々使用されてきている（それらは、両方とも、本開示では頭文字“ＭＭＯＧ”で参照される）。これらの変更は、小売配布に関連した問題及びコストをある程度軽減する。オンラインゲームをダウンロードすることは、配布コストが典型的に僅かであり且つ売れ残りメディアからのコストがほとんど又は全くないという点で、幾つかの欠点をゲーム発行者に差し向ける。しかし、ダウンロードされたゲームは、依然、海賊行為を受け、そしてそのサイズ（しばしば数ギガバイトのサイズ）のために、ダウンロードするのに非常に長い時間を要する。更に、ポータブルコンピュータ又はビデオゲームコンソールと共に販売されるような小さなディスク装置は複数のゲームで埋め尽くされる。しかしながら、ゲーム又はＭＭＯＧがプレイ可能なゲームのためのオンライン接続を要求する程度まで、海賊版の問題は、軽減されている。というのは、ユーザが、通常、有効なユーザアカウントを有することが要求されるからである。ディスプレイスクリーンのビデオを撮影するカメラ又はスピーカからの音声を録音するマイクロホンによりコピーできるリニアメディア（例えば、ビデオ及び音楽）とは異なり、各ビデオゲームの経験は独特なものであり、簡単なビデオ／オーディオ記録を使用してコピーすることができない。従って、著作権法が強力に施行されておらず、海賊行為が横行する地域でも、ＭＭＯＧは、海賊行為から遮蔽され、それ故、ビジネスをサポートすることができる。例えば、Ｖｉｖｅｎｄｉ ＳＡの“World of Warcraft”ＭＭＯＧは、世界中にわたって海賊行為で悩まされずに首尾良く展開された。そして、多くのオンライン又はＭＭＯＧゲーム、例えば、Ｌｉｎｄｅｎ Ｌａｂの“Second Life”ＭＭＯＧは、オンラインツールを使用して資産を買い、売り、そして形成するゲームに内蔵された経済的モデルを通してゲームのオペレータのための収入を発生する。従って、従来のゲームソフトウェアの購入又は契約に加えて、メカニズムを使用して、オンラインゲームを使用するための支払をすることができる。
オンラインの性質又はＭＭＯＧにより海賊行為をしばしば軽減できるが、オンラインゲームオペレータは、依然、残りの挑戦に直面している。多くのゲームは、オンライン又はＭＭＯＧが適切に機能するために実質的なローカル（即ち、家庭内）処理リソースを要求する。ユーザは、性能の低いローカルコンピュータ（例えば、ローエンドラップトップのような、ＧＰＵをもたないもの）を有する場合に、ゲームをプレイできないことがある。更に、ゲームコンソールが古くなるにつれて、最新型から徐々に後退し、より進歩したゲームを取り扱うことができなくなる。ユーザのローカルＰＣがゲームの計算要求を取り扱いできると仮定しても、しばしばインストールの複雑さがある。ドライバの互換性がないことがある（例えば、新たなゲームがダウンロードされる場合に、グラフィックドライバの新たなバージョンがインストールされ、これは、グラフィックドライバの古いバージョンに基づく以前にインストールされたゲームを不作動にすることがある）。コンソールは、より多くのゲームがダウンロードされるにつれて、ローカルディスクスペースを使い果たす。複雑なゲームは、典型的に、バグが見つかって修理されたとき、又はゲームに変更がなされた場合に（例えば、ゲームのレベルがプレイするのに難し過ぎるか又は容易過ぎるとゲーム開発者が分かった場合に）、ゲーム開発者から時間と共にダウンロードされたパッチを受け取る。これらのパッチは、新たなダウンロードを要求する。しかし、時々、全てのユーザが全てのパッチのダウンロードを完了するのではない。他のときには、ダウンロードされたパッチが他の互換性又はディスクスペース消費の問題を導入する。
又、ゲームのプレイ中に、グラフィック又は挙動情報をローカルＰＣ又はコンソールに与えるために大きなデータダウンロードが要求されることがある。例えば、ユーザがＭＭＯＧの部屋に入り、そしてグラフィックデータで作られるか又はユーザのローカルマシンでは得られない挙動をもつシーン又はキャラクタに遭遇する場合には、そのシーン又はキャラクタのデータをダウンロードしなければならない。その結果、インターネット接続が充分に高速でない場合には、ゲームのプレイ中に実質的な遅延を招く。そして、遭遇したシーン又はキャラクタが、ローカルＰＣ又はコンソールを越えるような記憶スペース又は計算能力を要求する場合には、ユーザがゲームを進められないか又は質の低いグラフィックで続けねばならない事態を招く。従って、オンライン又はＭＭＯＧゲームは、それらの記憶及び／又は計算の複雑さの要件をしばしば制限する。更に、それらは、ゲーム中のデータ転送の量をしばしば制限する。又、オンライン又はＭＭＯＧは、ゲームをプレイできるユーザの市場を狭めることもある。
更に、技術的知識のあるユーザがゲームのローカルコピーをリバースエンジニアリングし、そしてチートできるようにゲームを変更することが次第に増えてきている。チートは、人間的に可能である以上に速くボタン押しを繰り返すのと同程度に簡単である（例えば、銃を非常に速く撃つように）。ゲーム内資産トランザクションをサポートするゲームでは、チートが、実際の経済的価値の資産を含む詐欺的トランザクションを生じるレベルの精巧さに到達する。オンライン又はＭＭＯＧ経済的モデルがそのような資産トランザクションに基づくものであるときは、これは、ゲームオペレータに実質的に有害な結果をもたらす。
新たなゲームを開発するコストは、ＰＣ及びコンソールが（例えば、リアルタイムレイトレーシングのようなより現実的なグラフィック、及びリアルタイム物理的シミュレーションのようなより現実的な挙動と共に）益々精巧なゲームを作成できるのにつれて増大している。ビデオゲーム産業の初期には、ビデオゲーム開発は、アプリケーションソフトウェア開発に非常に類似したプロセスであり、即ち開発コストの大部分は、ソフトウェアの開発であり、グラフィック、オーディオ、及び挙動エレメント又は「資産」の開発、例えば、広範囲な特殊効果をもつ動画に対して開発されるものではない。今日、多くの精巧なビデオゲーム開発努力は、ソフトウェア開発よりも、特殊効果に富んだ動画開発に厳密に似ている。例えば、多くのビデオゲームは、３Ｄ世界のシミュレーションを与え、そして益々ホトリアリスティックな（即ち、生きた動きの映像写真撮影と同程度に現実的に見えるコンピュータグラフィックの）キャラクタ、プロップ及び環境を発生する。ホトリアリスティックなゲーム開発の最も挑戦的な観点の１つは、生きた動きの人間の顔と見分けがつかないようなコンピュータ発生の人間の顔を創作することである。カリフォルニア州サンフランシスコのＭｏｖａにより開発されたＣｏｎｔｏｕｒTMリアリティキャプチャーのような顔捕獲技術は、演技者の顔の正確な形状を運動中に高い解像度で捕獲し追跡する。この技術は、捕獲された生きた動きの顔と実質上区別できない３Ｄの顔をＰＣ又はゲームコンソール上にレンダリングできるようにする。「ホトリアル」な人間の顔を捕獲してレンダリングすることは、多数の観点で有用である。第１に、非常に認識し易い有名人又はスポーツプレーヤ（多くの場合に高い費用で雇われた）がビデオゲームにしばしば使用され、不完全さがユーザにとって明らかで、視覚体験(viewing experience)を混乱させ又は不快にさせることがある。又、多くの場合に、高度のホトリアリズムを達成するには高度の細部が要求され、即ち、潜在的に、顔が動くときに多角形及び／又はテクスチャがフレームごとに変化するようにして、多数の多角形及び高解像度テクスチャをレンダリングすることが要求される。
詳細なテクスチャを伴う多数の多角形のシーンが急速に変化するときには、ゲームをサポートするＰＣ又はゲームコンソールは、ゲームセグメントで発生される所要数のアニメーションフレームに対して充分な多角形及びテクスチャデータを記憶するに足るＲＡＭを有していないことがある。更に、ＰＣ又はコンソールに典型的に利用できる単一の光学的ドライブ又は単一のディスクドライブは、通常、ＲＡＭより非常に低速であり、そして典型的に、多角形及びテクスチャをレンダリングする際にＧＰＵが受け容れられる最大データレートを維持することができない。現在のゲームは、典型的に、多角形及びテクスチャの大部分をＲＡＭにロードし、これは、所与のシーンの複雑さ及び時間巾が主としてＲＡＭの容量により制限されることを意味する。例えば、顔のアニメーションの場合に、これは、ゲームが休止して多角形及びテクスチャ（及び他のデータ）をより多くのフレームに対してロードする前に、ＰＣ又はゲームコンソールを、ホトリアルでない低解像度の顔、又は限定された数のフレームについてのみアニメ化できるホトリアルな顔、のいずれかに制限する。
“Loading...”に類似したメッセージをＰＣ又はコンソールが表示するときに進行バーがスクリーンを横切ってゆっくり移動するのを見ていることは、複雑なビデオゲームの今日のユーザによって固有の欠点として容認されている。次のシーンがディスク（ここで、「ディスク」とは、特に指示のない限り、不揮発性の光学又は磁気メディア、並びに非ディスクメディア、例えば、半導体「フラッシュ」メモリを指す）からロードする間の遅延は、数秒又は数分を要する。これは、時間の浪費であり、ゲームプレーヤにとってかなりのフラストレーションとなる。上述したように、多くの又は全ての遅延は、多角形、テクスチャ又は他のデータをディスクからロードする時間によるものであるが、ＰＣ又はコンソール内のプロセッサ及び／又はＧＰＵがシーンのためのデータを準備する間にロード時間の一部分が費やされる場合もある。例えば、サッカービデオゲームは、プレーヤが、多数の選手、チーム、スタジアム及び天候条件の中から選択を行えるようにする。従って、どんな特定の組合せが選択されるかに基づいて、異なる多角形、テクスチャ及び他のデータ（集合的に「オブジェクト」）がシーンに対して要求される（例えば、異なるチームは、そのユニホームに異なるカラー及びパターンを有する）。多数の又は全ての種々の順列を列挙し、多数の又は全てのオブジェクトを前もって予め計算し、そしてそれらオブジェクトを、ゲームを記憶するのに使用されるディスクに記憶することができる。しかし、順列の数が多い場合には、全オブジェクトに対して要求される記憶の量が、ディスクに適合するには大き過ぎる（ダウンロードするには不可能である）ことがある。従って、既存のＰＣ及びコンソールシステムは、典型的に、所与のシーンの複雑さ及びプレイ時間巾の両方について制約があり、複雑なシーンに対する長いロード時間で悩まされている。
従来のビデオゲームシステム及びアプリケーションソフトウェアシステムに伴う別の顕著な制限は、それらが、例えば、ＰＣ又はゲームコンソールへ処理のためにロードされる必要のある多角形及びテクスチャのような３Ｄオブジェクトの大きなデータベースを次第に使用してきていることである。上述したように、このようなデータベースは、ディスクにローカルに記憶されるときに長いロード時間を要する。しかしながら、ロード時間は、通常、データベースがリモート位置に記憶されそしてインターネットを通してアクセスされる場合には更に厳しいものとなる。このような状態では、大きなデータベースをダウンロードするのに、数分、数時間、又は数日を要することがある。更に、このようなデータベースは、多くの場合に多大な費用で生成され（例えば、ゲーム、映画又は歴史ドキュメンタリーに使用するための詳細な高いマスト付きの帆船の３Ｄモデル）、そしてローカルエンドユーザに販売するように意図される。しかしながら、データベースは、ローカルユーザへダウンロードされると、海賊行為を受けるおそれがある。多くの場合、ユーザは、データベースを評価してそれがユーザのニーズに合うか（例えば、ユーザが特定の動きをするときにゲームキャラクタの３Ｄコスチュームが満足な見掛け又は外観を有するか）どうか調べるだけのためにデータベースのダウンロードを希望する。長いロード時間は、購入することを決断する前に３Ｄデータベースを評価するユーザにとって妨げになる。
ＭＭＯＧでは、特に、ユーザがカスタマイズされたキャラクタを次第に使用できるようなゲームとして、同様の問題が発生する。キャラクタを表示するためのＰＣ又はゲームコンソールの場合に、３Ｄ幾何学（多角形、テクスチャ、等）のデータベースへのアクセス及びそのキャラクタに対する挙動（例えば、キャラクタが盾を有する場合に、その盾が槍をそらすに充分な強度であるかどうか）を得ることが必要である。典型的に、ＭＭＯＧがユーザにより最初にプレイされるときには、キャラクタに対する多数のデータベースが、ゲームの初期コピーと共に予め入手でき、これは、ゲームの光学的ディスクにローカルで入手できるか又はディスクへダウンロードされる。しかし、ゲームが進行するにつれて、データベースがローカルで入手できないキャラクタ又はオブジェクトにユーザが遭遇する場合には（例えば、別のユーザがカスタマイズされたキャラクタを生成した場合には）、そのキャラクタ又はオブジェクトを表示できるまでに、そのデータベースがダウンロードされねばならない。これは、ゲームの実質的な遅延を生じさせる。
ビデオゲームの精巧さ及び複雑さがあるとすれば、従来のビデオゲームコンソールでのビデオゲーム開発者及び発行者の別の挑戦は、多くの場合、数千万ドルのコストで２ないし３年を掛けてビデオゲームを開発することである。新規なビデオゲームコンソールプラットホームがほぼ５年毎に一度の割合で導入されると仮定すれば、ゲーム開発者は、新規なプラットホームが発売されるのと同時にビデオゲームを入手できるようにするために、新規なゲームコンソールの発売よりこれらゲーム年だけ前に開発作業をスタートする必要がある。ほぼ同じ時期に（例えば、互いに１年又は２年以内に）競合する製造者から多数のコンソールが時々発売されるが、調べなければならないものは、各コンソールの人気であり、例えば、どのコンソールがビデオゲームソフトウェアの最大売り上げを生じるかである。例えば、近年のコンソールサイクルでは、Ｍｉｃｒｏｓｏｆｔ ＸＢｏｘ３６０、Ｓｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ３及びＮｉｎｔｅｎｄｏ Ｗｉｉがほぼ同じ一般的な時間枠で導入されるようにスケジュールされている。しかし、導入の何年か前に、ゲーム開発者は、どのコンソールプラットホームが他のものより成功するか本質的に「賭け」をし、それに応じて、開発リソースを捧げなければならない。又、動画制作会社も、映画の封切りの充分前に映画の成功の見込みの推定に基づいて限られた制作リソースを配分しなければならない。ビデオゲームに要求される投資レベルの増大を仮定すれば、ゲーム制作は、動画制作と益々類似してきており、ゲーム制作会社は、特定のビデオゲームの将来の成功の推定に基づいて制作リソースを日常的に捧げる。しかし、動画会社とは異なり、この賭けは、単に制作それ自体の成功に基づくものではなく、むしろ、ゲームの実行が意図されたゲームコンソールの成功に基づいたものである。複数のコンソールに対するゲームを一度に発売することでリスクを軽減できるが、この付加的な努力がコストを増大し、ゲームの実際の発売をしばしば遅らせる。
ＰＣにおけるアプリケーションソフトウェア及びユーザ環境は、ユーザに対してより視覚的に訴えるだけでなく、より有効で且つ直感的なものにするために、計算上より集中的で、動的で且つ双方向のものとなる。例えば、新規なＷｉｎｄｏｗｓ ＶｉｓｔａTMオペレーティングシステム、及びＭａｃｉｎｔｏｓｈ（登録商標）オペレーティングシステムの次々のバージョンは、視覚アニメーション効果を合体している。Ａｕｔｏｄｅｓｋ社からのＭａｙａTMのような進歩型グラフィックツールは、最新のＣＰＵ及びＧＰＵの限界を押し進める非常に精巧な３Ｄレンダリング及びアニメーション能力を与える。しかしながら、これら新規なツールの計算上の要件は、そのような製品のユーザ及びソフトウェア開発者にとって多数の実際上の問題を生じさせる。
オペレーティングシステム（ＯＳ）の視覚表示は、もはや販売されていないが新規なＯＳで依然アップグレード可能である前世代のコンピュータを含めて、広範囲な種類のコンピュータにおいて機能しなければならないので、ＯＳグラフィック要件は、典型的にＧＰＵを含まないコンピュータを含めたＯＳのターゲットであるコンピュータの最小公分母によって大きく制限される。これは、ＯＳのグラフィック能力を甚だしく制限する。更に、バッテリ作動式のポータブルコンピュータ（例えば、ラップトップ）は、視覚表示能力を制限する。というのは、ＣＰＵ又はＧＰＵにおける高い計算上のアクティビティが、典型的に、電力消費を高め、バッテリ寿命を短くするからである。ポータブルコンピュータは、典型的に、プロセッサが利用されないときに消費電力を下げるためにプロセッサのアクティビティを自動的に下げるソフトウェアを含む。あるコンピュータモデルでは、ユーザは、プロセッサのアクティビティを手動で下げることができる。例えば、ソニーのＶＧＮ−ＳＺ２８０Ｐラップトップは、（低性能、長バッテリ寿命のために）片側に“Ｓｔａｍｉｎａ”と表示され且つ（高性能、短バッテリ寿命のために）他側に“Ｓｐｅｅｄ”と表示されたスイッチを含む。ポータブルコンピュータで実行されるＯＳは、コンピュータがそのピーク性能能力の一部分で実行される場合でも、有用に機能することができねばならない。従って、ＯＳグラフィック性能は、入手可能な最新の計算能力より遥かに下に留まることがしばしばある。
Ｍａｙａのようなハイエンドの計算に強いアプリケーションは、高性能ＰＣに使用されるという期待でしばしば販売される。これは、典型的に、非常に高い性能と、より高価で且つ低ポータブル性の最小公分母要求を確立する。その結果、このようなアプリケーションは、汎用のＯＳ（又はＭｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅのような汎用の生産アプリケーション）より非常に限定されたターゲット視聴者を有し、典型的に、汎用のＯＳソフトウェア又は汎用のアプリケーションソフトウェアより相当に少ない量で販売される。又、多くの場合、見込みのあるユーザがこのような計算に強いアプリケーションを前もって試すことは困難であるから、潜在的な視聴者は更に限定される。例えば、学生がＭａｙａの使い方を学習することを希望し、又はこのようなアプリケーションについて既に知識のある潜在的な買い手が購入（Ｍａｙａを実行できるハイエンドコンピュータを買うことも含む）に投資する前にＭａｙａを試すことを希望すると仮定する。学生又は潜在的な買い手は、Ｍａｙａのデモバージョンをダウンロードするか又はその物理的メディアコピーを得ることはできるが、Ｍａｙａをそのフル能力（例えば、複雑な３Ｄシーンを取り扱う）で実行できるコンピュータがない場合には、製品の完全なインフォームドアセスメントを行うことができない。これは、このようなハイエンドアプリケーションの視聴者を制限するものである。又、これは、高い販売価格にも貢献する。というのは、開発コストは、通常、汎用アプリケーションより非常に少数の購入にわたって割賦されるからである。
又、高価格アプリケーションは、個人や企業がアプリケーションソフトウェアの海賊版コピーを使用する大きな誘因も生み出す。その結果、ハイエンドのアプリケーションソフトウェアは、種々の技術を通して海賊行為を軽減するためにそのようなソフトウェアの発行者による顕著な努力にも関わらず、海賊版がはびこることで悩まされている。海賊版のハイエンドのアプリケーションを使用するときでも、ユーザは、海賊版コピーを実行するために高価な最新のＰＣに投資する必要性を排除することはできない。従って、海賊版ソフトウェアのユーザは、その実際の小売価格の一部分でソフトウェアアプリケーションを使用できるが、そのアプリケーションをフルに利用するためには、高価なＰＣを購入又は入手することが依然要求される。
高性能の海賊版ビデオゲームのユーザについても同じことが言える。海賊行為者は、ゲームをそれらの実際の価格の一部分で得ることはできるが、ゲームを適切にプレイするのに必要な高価なコンピューティングハードウェア（例えば、ＧＰＵ増強型ＰＣ、又はＸＢｏｘ３６０のようなハイエンドのビデオゲームコンソール）を購入することが依然要求される。ビデオゲームが典型的に消費者にとって気晴らしであると仮定すれば、ハイエンドのビデオゲームシステムのための付加的なコストが法外なものとなる。この事態は、現在の労働者の平均年収が米国に比してかなり低い国（例えば、中国）では、一層悪いものである。その結果、ハイエンドのビデオゲームシステム又はハイエンドのＰＣを所有するのは、人口の非常に僅かな割合だけとなる。このような国々では、インターネットに接続されたコンピュータを使用するための料金をユーザが支払う「インターネットカフェ」が極めて一般的となる。多くの場合に、このようなインターネットカフェは、プレーヤが計算に強いビデオゲームをプレイできるようにするＧＰＵのような高性能特徴をもたない旧モデル又はローエンドＰＣしか有していない。これは、中国で非常に成功し、そこのインターネットカフェで一般にプレイされるＶｉｖｅｎｄｉの“World of Warcraft”のような、ローエンドＰＣで実行されるゲームの成功における重要なファクタである。それと対照的に、“Second Life”のような計算に強いゲームは、中国のインターネットカフェにインストールされたＰＣでプレイできる見込みが極めて低い。このようなゲームは、インターネットカフェの低性能ＰＣにしかアクセスできないユーザには、実質上アクセス不能である。
又、ビデオゲームの購入を考えており、先ず、インターネットを経て自分の家にゲームのデモバージョンをダウンロードすることによりそれを試してみたいユーザにとってもバリアが存在する。ビデオゲームのデモは、多くの場合、幾つかの特徴がディスエイブルされるか又はゲームのプレイ量に限度が課せられたゲームの一人前のバージョンである。これは、ＰＣ又はコンソールのいずれかにゲームをインストールして実行できるまでにギガバイトのゲームをダウンロードする長いプロセス（おそらく数時間）を伴うことがある。ＰＣの場合には、ゲームに対して必要とされる特殊なドライバ（例えば、ＤｉｒｅｃｔＸ又はＯｐｅｎＧＬドライバ）を計算し、正しいバージョンをダウンロードして、それらをインストールし、次いで、ＰＣがゲームをプレイできるかどうか決定することを含む。この後者のステップは、ＰＣが充分な処理（ＣＰＵ及びＧＰＵ）能力、充分なＲＡＭ、及び互換性のあるＯＳ（例えば、あるゲームは、Ｗｉｎｄｏｗｓ ＸＰで実行されるが、Ｖｉｓｔａでは実行されない）を有するかどうか決定することを含む。従って、ビデオゲームデモを実行するよう試みる長いプロセスの後に、ユーザは、ユーザのＰＣコンフィギュレーションを仮定すれば、ビデオゲームデモがおそらくプレイできないことを充分見出すことができる。悪いことに、ユーザが、デモを試すために新規なドライバダウンロードすると、それらのドライババージョンは、ユーザがＰＣにおいて普通に使用している他のゲーム又はアプリケーションとの互換性がないことがあり、従って、デモをインストールすると、以前に動作できたゲーム又はアプリケーションが不作動になることがある。これらのバリアは、ユーザにフラストレーションを与えるだけでなく、ゲームを市場に出すビデオゲームソフトウェア発行者及びビデオゲーム開発者にとってもバリアとなる。
経済的な非効率さを招く別の問題は、所与のＰＣ又はゲームコンソールが、通常、アプリケーション及び／又はゲームに対するあるレベルの性能要件を受け容れるように設計されていることに関する。例えば、あるＰＣは、多少のＲＡＭを有し、低速又は高速のＣＰＵを有し、そしてＧＰＵを有する場合には低速又は高速のＧＰＵを有する。あるゲーム又はアプリケーションは、所与のＰＣ又はコンソールの全計算パワーの利点を取り入れるが、多くのゲーム又はアプリケーションは、そうではない。ゲーム又はアプリケーションについてのユーザの選択が、ローカルＰＣ又はコンソールのピーク性能能力に達しない場合には、ユーザは、利用されない特徴に関してＰＣ又はコンソール上で金銭を浪費することになる。コンソールの場合には、コンソールの製造者は、コンソールコストを助成するために必要であった以上に支払ったことになる。
ビデオゲームを買って楽しむ際に存在する別の問題は、ユーザがゲームの購入を決める前に他の者がそのゲームをプレイしているのをユーザが見ることができるようにすることに関する。ビデオゲームを記録して後で再生するための多数の従来の解決策が存在する。例えば、米国特許第５，５５８，３３９号は、（同じユーザ又は異なるユーザにより所有された）ビデオゲームクライアントコンピュータでの「ゲームプレイ」中にゲームコントローラのアクションを含むゲーム情報体情報を記録することを教示している。この状態情報を後で使用して、ビデオゲームクライアントコンピュータ（例えば、ＰＣ又はコンソール）上で幾つか又は全てのゲームアクションを再生することができる。この解決策の顕著な欠点は、ユーザが記録されたゲームを見るために、ユーザは、ゲームをプレイできるビデオゲームクライアントコンピュータを所有すると共に、記録されたゲーム状態が再生されたときにゲームプレイが同一となるようにそのコンピュータ上で実行されるビデオゲームアプリケーションを有していなければならないことである。この他に、ビデオゲームアプリケーションは、記録されたゲームと再生されるゲームとの間に実行の相違がないように書かれねばならない。
例えば、ゲームグラフィックは、一般的に、フレームごとに計算される。多くのゲームの場合に、ゲームロジックは、時々、シーンが特に複雑であるかどうか、又は実行速度を下げる他の遅延があるかどうか（例えば、ＰＣにおいて、ゲームアプリケーションからＣＰＵサイクルを取り去る別のプロセスが実行されるかどうか）に基づいて、次のフレームに対して表示されるグラフィックを計算するのに１フレームより短い又は長い時間を要する。このようなゲームでは、１フレーム時間より若干短く（例えば、数ＣＰＵクロックサイクル短く）計算された「スレッシュホールド」フレームが最終的に発生する。その同じシーンが、全く同じゲーム状態情報を使用して再び計算されたときには、１フレーム時間より数ＣＰＵクロックサイクル長くかかることが容易に起きる（例えば、内部ＣＰＵバスが外部ＤＲＡＭバスと若干位相ずれし、そしてゲーム処理から数ミリ秒のＣＰＵ時間を取り去る別のプロセスによる大きな遅延がなくても、数ＣＰＵサイクルの時間遅延を導入する場合には）。それ故、ゲームが再生されるときには、フレームは、１つのフレーム時間ではなく、２つのフレーム時間で計算される。幾つかの挙動は、ゲームがどれほど頻繁に新たなフレームを計算するか（例えば、いつゲームがゲームコントローラから入力をサンプルするか）に基づいている。ゲームが表示されている間には、異なる挙動に対する時間基準のこの相違は、ゲームのプレイに影響しないが、再生されたゲームが異なる結果を生じさせることを招く。例えば、バスケットボールの弾道は、一定の６０ｆｐｓ速度で計算されるが、ゲームコントローラの入力が、計算されたフレームの速度に基づいてサンプリングされる場合には、計算されたフレームの速度は、ゲームが記録されたときは５３ｆｐｓであるが、ゲームが再生されるときは５２ｆｐｓとなり、これは、バスケットボールがバスケットへ入ることが阻止されるかどうかに差を生じさせ、異なる結果を招くことになる。従って、ゲーム状態を使用してビデオゲームを記録するには、同じゲーム状態情報を使用した再生が全く同じ結果を生じさせるよう保証するために非常に入念なゲームソフトウェア設計が要求される。
ビデオゲームを記録するための別の従来の解決策は、ＰＣ又はビデオゲームシステムのビデオ出力を（例えば、ＶＣＲ、ＤＶＤレコーダへ、又はＰＣ上のビデオ捕獲ボードへ）単に記録することである。次いで、ビデオは、巻き戻して再生することもできるし、或いは記録されたビデオを、典型的に、圧縮した後にインターネットへアップロードすることもできる。この解決策の欠点は、３Ｄゲームシーケンスが再生されるときに、ユーザは、シーケンスが記録された視点のみからシーケンスを見ることに限定されることである。換言すれば、ユーザは、シーンの視点を変更することができない。
更に、家庭用ＰＣ又はゲームコンソールで再生される記録されたゲームシーケンスの圧縮ビデオがインターネットを通して他のユーザに利用されるときには、ビデオがリアルタイムで圧縮された場合でも、その圧縮されたビデオをリアルタイムでインターネットにアップロードすることは不可能である。その理由は、インターネットに接続された世界中の多数の家庭が、極めて非対称的なブロードバンド接続を有する（例えば、ＤＳＬ及びケーブルモデムは、典型的に、アップストリーム帯域巾よりも遥かに広いダウンストリーム帯域巾を有する）からである。圧縮された高解像度ビデオシーケンスは、多くの場合に、ネットワークのアップストリーム帯域巾容量より広い帯域巾を有し、それらをリアルタイムでアップロードするのを不可能にする。従って、ゲームシーケンスが再生された後、インターネットの別のユーザがゲームを見ることができるまでに著しい遅延が生じる（おそらく数分又は数時間）。この遅延は、ある状況（例えば、以前に生じたゲームプレーヤの成績を見る）では許容できるが、ゲーム（例えば、チャンピオンプレーヤによりプレイされるバスケットボールトーナメント）を生で見る能力、又はゲームが生でプレイされるときの「瞬時再生」能力を排除する。
別の従来の解決策は、テレビジョン制作員の管理下でのみ、視聴者が、テレビ受像機でビデオゲームを生で見ることができるようにする。米国及び他の国々における幾つかのチャンネルは、ビデオゲーム視聴チャンネルを提供し、テレビ視聴者は、ビデオゲームチャンネル上で何人かのビデオゲームユーザ（例えば、トーナメントでプレイする最高評価プレーヤ）を見ることができる。これは、テレビジョンチャンネル用のビデオ配信及び処理装置へビデオゲームシステム（ＰＣ及び／又はコンソール）のビデオ出力をフィードすることにより達成される。これは、多数のカメラがバスケットボールコートの周囲で異なるアングルから生映像を送る生のバスケットボールゲームをテレビチャンネルが放送するときとは異なる。従って、テレビチャンネルは、それらのビデオ／オーディオ処理を活用して、種々のビデオゲームシステムからの出力を操作するように装置に作用することができる。例えば、テレビチャンネルは、異なるプレーヤの状態を示すテキストをビデオゲームからのビデオの上に重畳することができ（生のバスケットボールゲーム中のオーバーレイテキストであるかのように）、そしてテレビチャンネルは、ゲーム中に生じるアクションについて論じることのできるコメンテータからの音声をかぶせて録音することができる。更に、ビデオゲーム出力を、ゲームの実際のプレーヤのビデオを記録するカメラと合成することができる（例えば、ゲームに対する感情的応答を示す）。
この解決策に伴う１つの問題は、生放送の興奮を得るために、このような生のビデオフィードがテレビチャンネルのビデオ配信及び処理装置にリアルタイムで得られねばならないことである。しかしながら、上述したように、これは、ビデオゲームシステムが家庭から実行されるとき、特に、放送の一部分が、ゲームプレーヤの実世界ビデオを捕獲するカメラからの生ビデオを含む場合には、しばしば不可能である。更に、トーナメント状態において、上述したように、家庭内のゲーム遊技者がゲームを変更し及びチートする問題もある。これらの理由で、テレビチャンネルを経てのこのようなビデオゲーム放送は、プレーヤ及びビデオゲームシステムが共通の位置（例えば、テレビスタジオ又は競技場）に集合し、そこで、テレビ制作装置が多数のビデオゲームシステム及び潜在的な生カメラからのビデオフィードを受け容れることができるように、しばしば構成される。
このような従来のビデオゲームテレビチャンネルは、ビデオゲームの世界におけるアクション及び実世界におけるアクションの両方に関して、例えば、ビデオゲームプレーヤが「アスリート」として描かれるようにして、生のスポーツイベントに類似した体験である非常に興奮させる上映をテレビの視聴者に与えることができるが、これらのビデオゲームシステムは、プレーヤが互いに物理的に非常に接近した状態にしばしば限定される。そして、テレビチャンネルが放送されて以来、各放送チャンネルは、テレビチャンネルの制作員により選択された１つのビデオストリームしか示すことができない。これらの制限や、放送時間、制作装置及び制作員の高いコストのために、テレビチャンネルは、典型的に、トップトーナメントでプレイする最高評価プレーヤしか示さない。
更に、ビデオゲームのフルスクリーン映像を全テレビ視聴者に放送する所与のテレビチャンネルは、一度に１つのビデオゲームしか示さない。これは、テレビ視聴者の選択肢を甚だしく制限する。例えば、テレビ視聴者は、所与の時間に映されるゲームに関心がないことがある。別の視聴者は、所与の時間にテレビチャンネルによって特集されない特定のプレーヤのゲームプレイを見ることにしか関心がない。他のケースでは、視聴者は、専門プレーヤがゲームにおける特定のレベルをどのように取り扱うか見ることにしか関心がない。更に他の視聴者は、制作チーム等により選択されたものとは異なる、ビデオゲームを見る視点をコントロールすることを希望する。手短に言えば、テレビ視聴者は、多数の異なるテレビチャンネルが見られる場合でも、テレビネットワークの特定の放送によって受け容れられないビデオゲームを見ることに無数の好みをもっている。上述した全ての理由で、従来のビデオゲームテレビチャンネルは、テレビ視聴者にビデオゲームを示す上で著しい制限がある。
従来のビデオゲームシステム及びアプリケーションソフトウェアシステムの別の欠点は、それらが複雑であり、且つエラー、クラッシュ及び／又は意図されない及び望ましからぬ挙動（集合的に「バグ」）により通常悩まされていることである。ゲーム及びアプリケーションは、典型的に、発売までにデバッグ及びチューニングプロセス（しばしば「ソフトウェアクオリティアシュアランス」又はＳＱＡと称される）に通されるが、ほぼ常に、ゲーム又はアプリケーションがその分野の広範囲な視聴者に発売されると、バグが突然現れる。不都合なことに、ソフトウェア開発者は、発売後に多くのバグを識別して追跡することは困難である。ソフトウェア開発者がバグに気付くことは困難である。バグについて学習したときでも、何がバグを生じさせたか識別するために利用できる情報は、限られた量しかない。例えば、ユーザは、ゲーム開発者の顧客サービスラインに電話し、ゲームをプレイするときに、スクリーンがフラッシュを開始し、次いで、濃い青色に変化し、ＰＣがフリーズすることを示すメッセージを残す。これは、ＳＱＡチームに、バグを追跡するのに有用な非常に僅かな情報しか与えない。オンライン接続されたあるゲーム又はアプリケーションは、時々、幾つかのケースでは、多くの情報を与えることができる。例えば、ゲーム又はアプリケーションを「クラッシュ」について監視するために、時々「ウオッチドッグ」プロセスを使用することができる。ウオッチドッグプロセスは、ゲーム又はアプリケーションプロセスがクラッシュしたときにその状態（例えば、スタックの状態、メモリ使用状態、ゲーム又はアプリケーションがどれほど進行したか、等）に関する統計情報を収集し、次いで、その情報を、インターネットを経てＳＱＡチームへアップロードすることができる。しかし、複雑なゲーム又はアプリケーションでは、このような情報は、クラッシュ時にユーザが何を行ったか正確に決定するために解読するのに非常に長時間を要する。従って、どんな事象シーケンスがクラッシュを招いたか決定することが不可能である。
ＰＣ及びゲームコンソールに関連した更に別の問題は、消費者に相当不便をかけるサービスの問題を受けることである。又、これらサービスの問題は、ＰＣ又はゲームコンソールの製造者に影響を及ぼす。というのは、製造者は、壊れたＰＣ又はコンソールを安全に運搬するために特殊なボックスを送付し、ＰＣ又はコンソールが保証期間内である場合には修理のコストを負う必要があるからである。又、ゲーム又はアプリケーションソフトウェアの発行者は、ＰＣ及び／又はコンソールが修理の状態にあることによる販売の損失（又はオンラインサービス使用）によっても影響を受ける。
図１は、Ｓｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ（登録商標）３、Ｍｉｃｒｏｓｏｆｔ ＸＢｏｘ ３６０（登録商標）、Ｎｉｎｔｅｎｄｏ ＷｉｉTM、Ｗｉｎｄｏｗベースのパーソナルコンピュータ、又はＡｐｐｌｅ Ｍａｃｉｎｔｏｓｈのような従来のビデオゲームシステムを示す。これらシステムは、各々、プログラムコードを実行するための中央処理ユニット（ＣＰＵ）、典型的に、進歩型グラフィックオペレーションを遂行するためのグラフィック処理ユニット（ＧＰＵ）、並びに外部装置及びユーザと通信するための複数の形態の入力／出力（Ｉ／Ｏ）を備えている。簡単化のために、これらのコンポーネントは、単一のユニット１００として一緒に結合されて示されている。又、図１の従来のビデオゲームシステムは、光学的メディアドライブ１０４（例えば、ＤＶＤ−ＲＯＭドライブ）、ビデオゲームのプログラムコード及びデータを記憶するためのハードドライブ１０３、マルチプレーヤゲームをプレイし、ゲーム、パッチ、デモ又は他のメディアをダウンロードするためのネットワーク接続１０５、ＣＰＵ／ＧＰＵ１００により現在実行されているプログラムコードを記憶するためのランダムアクセスメモリ（ＲＡＭ）１０１、ゲームプレイ中にユーザからの入力コマンドを受け取るためのゲームコントローラ１０６、及びディスプレイ装置１０２（例えば、ＳＤＴＶ／ＨＤＴＶ又はコンピュータモニタ）を含むように示されている。
図１に示す従来のシステムは、多数の制限で悩まされている。第１に、光学的ドライブ１０４及びハードドライブ１０３は、ＲＡＭ１０１に比して非常に低速のアクセス速度を有する傾向がある。ＲＡＭ１０１を通して直接機能するときには、ＣＰＵ／ＧＰＵ１００は、実際に、プログラムコード及びデータがハードドライブ１０３又は光学ドライブ１０４から直接読み取られるときに可能であるより遥かに多くの多角形を毎秒処理することができる。というのは、ＲＡＭ１０１は、一般的に、帯域巾が非常に広く、ディスクメカニズムの比較的長いシーク遅延で悩まされないからである。しかし、これら従来システムでは、限定された量のＲＡＭしか設けられていない（例えば、２５６−５１２Ｍバイト）。それ故、ビデオゲームの次のシーケンスのためのデータでＲＡＭ１０１が周期的に埋められる“Ｌｏａｄｉｎｇ．．．”シーケンスがしばしば要求される。
あるシステムは、ゲームプレイと同時にプログラムコードのローディングを重畳させるように試みているが、これは、既知の事象シーケンスがあるときしか行うことができない（例えば、車を運転して道路を下る場合に、車を運転しながら、路傍にある接近してくるビルの幾何学形状をロードすることができる）。複雑で及び／又は急速なシーンの変化については、この形式の重畳は、通常、機能しない。例えば、ユーザが戦いの最中であり、そしてその瞬間に視野内のオブジェクトを表すデータでＲＡＭ１０１が完全に埋められるケースでは、ＲＡＭ１０１に現在ロードされていないオブジェクトを見るためにユーザが視野を素早く左へ動かした場合に、アクションの不連続状態が生じる。というのは、ハードドライブ１０３又は光学的メディア１０４から新たなオブジェクトをＲＡＭ１０１へロードするに充分な時間がないからである。
図１のシステムでは、ハードドライブ１０３及び光学的メディア１０４の記憶容量に制限があるために別の問題が生じる。比較的大きな記憶容量（例えば、５０ギガバイト以上）をもつディスク記憶装置を製造することはできるが、現在ビデオゲームで遭遇する幾つかのシーンについて充分な記憶容量をまだ与えることができない。例えば、上述したように、サッカーのビデオゲームは、世界中の多数のチーム、プレーヤ及びスタジアムの中からユーザが選択を行えるようにする。各チーム、各プレーヤ及び各スタジアムに対して、世界中の３Ｄ曲面を特徴付けるには非常に多数のテクスチャマップ及び環境マップが要求される（例えば、各チームが独特のジャージを有し、その各々が独特のテクスチャマップを要求する）。
この後者の問題に対処するために使用される１つの技術は、ユーザによってテクスチャ及び環境マップが選択されたときにゲームがそれらを予め計算することである。これは、映像の解凍、３Ｄマッピング、シェーディング、データ構造の編成、等を含めて、多数の計算上強いプロセスを含むことがある。その結果、ビデオゲームがこれらの計算を遂行する間にユーザにとって遅延が生じ得る。この遅延を減少するための１つの方法は、原理的に、ゲームが最初に開発されたときに、チーム、プレーヤ名簿及びスタジアムの各順列を含めて、これら計算の全てを遂行することである。従って、ゲームの発売バージョンは、光学的メディア１０４、又はインターネット上の１つ以上のサーバーに記憶された全てのこの前処理されたデータを、ユーザが選択を行うときにインターネットを通してハードドライブ１０３へダウンロードされる所与のチーム、プレーヤ名簿、スタジアム選択のための選択された前処理されたデータと共に含む。しかしながら、実際上の問題として、ゲームプレイにおいて考えられる各順列のこのような予めロードされるデータは、多分、今日の光学的メディア装置の容量を遥かに越えるテラバイトのデータになってしまう。更に、所与のチーム、プレーヤ名簿、スタジアム選択のためのデータは、多分、数百メガバイト以上のデータになってしまう。例えば、１０Ｍｂｐｓの家庭用ネットワーク接続では、ネットワーク接続１０５を通してこのデータをダウンロードするのに、データをローカルで計算する以上の時間を要することになる。
従って、図１に示す従来のゲームアーキテクチャーは、複雑なゲームの主要シーン移行間にユーザに著しい遅延を受けさせる。
図１に示す従来の解決策に伴う別の問題は、年々、ビデオゲームがより進歩する傾向にあり、より高いＣＰＵ／ＧＰＵパワーを要求することである。従って、限定された量のＲＡＭを仮定しても、ビデオゲームハードウェアの要件は、これらシステムに得られる処理パワーのピークレベルを越えてしまう。その結果、ユーザは、歩調を合わせるためにゲームハードウェアを数年毎にアップグレードする必要がある（又は新たなゲームを質の低いレベルでプレイする）。ビデオゲームが絶えず進歩する傾向の１つの結果として、家庭で使用するためのビデオゲームプレイマシンは、典型的に、それらのコストが、通常、サポートできる最高性能ゲームの要件により決定されるので、経済的に効率が悪い。例えば、ＸＢｏｘ ３６０は、高性能ＣＰＵ、ＧＰＵ、及び数百メガバイトのＲＡＭを必要とする“Gears of War”のようなゲームをプレイするのに使用されるか、又はＸＢｏｘ ３６０は、数キロバイトのＲＡＭ及び非常に低性能のＣＰＵしか要求しない１９７０年代のゲームであるＰａｃ Ｍａｎをプレイするのに使用される。実際に、ＸＢｏｘ ３６０は、Ｐａｃ Ｍａｎゲームを一度に多数同時にホストするに充分な計算パワーを有している。
ビデオゲームマシンは、典型的に、一週間のほとんどの時間中オフにされている。１３年以上経った現役ゲームに関するニールセン・エンターテーメント・スタディ２００６年７月号によれば、平均で、現役のゲームは、毎週１４時間をコンソールビデオゲームのプレイに費やしており、即ち一週間の合計時間の１２％に過ぎない。これは、平均でビデオゲームコンソールが８８％の時間アイドル状態であり、高価なリソースの使用効率が悪いことを意味する。購入価格を下げるためにビデオゲームコンソールが製造者によりしばしば助成されると仮定すれば（その助成金が将来のビデオゲームソフトウェアの購入からのロイヤリティにより還元されることを期待して）、これは、特に意義深いことである。
又、ビデオゲームコンソールは、ほとんどの消費者電子装置に関連したコストを負っている。例えば、システムの電子装置及びメカニズムは、エンクロージャ内に収容する必要がある。製造者は、修理保証を提供する必要がある。システムを販売する小売店は、システムの販売及び／又はビデオゲームソフトウェアの販売において利ざやを収集する必要がある。これらのファクタは、全てビデオゲームコンソールのコストに追加され、これは、製造者によって助成されねばならないか、消費者へ回されるか、又はその両方である。
更に、ビデオゲーム産業にとって海賊版が主たる問題である。実質上全ての主要ビデオゲームシステムに使用されるセキュリティメカニズムは、年々「クラック」されて、ビデオゲームの無断コピーが取られている。例えば、ＸＢｏｘ ３６０のセキュリティシステムは、２００６年７月にクラックされ、ユーザは、今や、不正コピーをオンラインでダウンロードすることができる。ダウンロード可能なゲーム（例えば、ＰＣ又はＭａｃ用のゲーム）は、特に海賊行為を受け易い。海賊行為の取り締まりが弱い世界のある地域では、スタンドアローンビデオゲームソフトウェアのための成功が見込める市場が本質的にない。というのは、ユーザが海賊版コピーを合法的コピーと同程度に容易にそのコストのほんの一部分で買えるからである。又、世界の多くの地域では、ゲームコンソールのコストが収入の高い割合であり、海賊版を取り締まっても、最新のゲームシステムを買う余裕がある人は僅かに過ぎない。
更に、中古ゲーム市場は、ビデオゲーム産業の収入を減少させる。ユーザは、ゲームに飽きると、ゲームを店に売ることができ、店は、ゲームを他のユーザに再販売する。この無許可であるが一般的な慣習は、ゲーム発行者の収入を著しく減少させる。同様に、数年毎にプラットホームの移行があるときには、通常、５０％の販売量低下が生じる。これは、ユーザが、新規バージョンプラットホームが発売されようとしていることを知ると、旧型プラットホーム用のゲームの購入を止める（例えば、Ｐｌａｙｓｔａｔｉｏｎ３が発売されようとしているときに、ユーザは、Ｐｌａｙｓｔａｔｉｏｎ２のゲームの購入を止める）からである。新規のプラットホームに関連した販売の損失及び開発コストの増加が相まって、ゲーム開発者の利益に非常に大きな影響が及ぶことになる。
又、新規なゲームコンソールは、非常に高価である。ＸＢｏｘ ３６０、Ｎｉｎｔｅｎｄｏ Ｗｉｉ、及びＳｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ３は、全て、数百ドルで小売される。ハイパワーのパーソナルコンピュータゲームシステムは、その価格が＄８０００までである。これは、特に、ハードウェアが数年後に旧式となり且つ多くのシステムが子供のために購入されることを考えると、ユーザにとって著しい投資を表す。
以上の問題に対する１つの解決策は、ゲームプログラムコード及びデータがサーバーにホストされそしてオンデマンドでクライアントマシンへデジタルブロードバンドネットワークを経てストリーミングされる圧縮されたビデオ及びオーディオとして配信されるオンラインゲームである。フィンランドのＧ−Ｃｌｕｓｔｅｒ（現在では、日本のソフトバンクブロードメディアの子会社）のような幾つかの会社は、これらのサービスをオンラインで提供する。同様のゲームサービスが、ホテル内にあるようなローカルネットワークにおいて利用でき、ＤＳＬ及びケーブルテレビジョンプロバイダーによって提供されている。これらシステムの主たる欠点は、待ち時間(latency)、即ちオペレータの「ヘッドエンド」に典型的に配置されたゲームサーバーへ信号が進み且つそこから進むのに要する時間の問題である。高速アクションビデオゲーム（「ツイッチ」ビデオゲームとしても知られている）は、ユーザがゲームコントローラでアクションを遂行する時間と、ディスプレイスクリーンが更新されてユーザアクションの結果を示す時間との間に非常に短い待ち時間を要求する。ゲームが「即座」に応答するという感覚をユーザがもつようにするため、短い待ち時間が必要とされる。ユーザは、ゲームの形式及びユーザの熟練度レベルに基づいて異なる待ち時間間隔で満足することができる。例えば、ゆっくりしたカジュアルなゲーム（バックギャモンのような）又は低速アクションの役割を演じるゲームについては１００ｍｓの待ち時間が許容できるが、高速アクションゲームでは、待ち時間が７０又は８０ｍｓを越えると、ユーザは、ゲームにおいて演技が不充分となり、受け容れられない。例えば、高速反応時間を要求するゲームでは、待ち時間が５０から１００ｍｓへ増加するにつれて、精度が鋭く低下する。
ゲーム又はアプリケーションサーバーが、近傍のコントロールされたネットワーク環境にインストールされるか、又はユーザへのネットワーク経路が予想可能で及び／又は帯域巾ピークを許容できる環境にインストールされるときには、最大待ち時間と、待ち時間の一貫性の両方について、待ち時間をコントロールすることが遥かに容易である（例えば、ユーザがネットワークを通してストリーミングするデジタルビデオから一定の動きを観察するように）。このようなレベルのコントロールは、ケーブルＴＶネットワークのヘッドエンドとケーブルＴＶ加入者の家庭との間、又はＤＳＬ中央オフィスからＤＳＬ加入者の家庭までの間、或いはサーバー又はユーザからの商業的オフィスのローカルエリアネットワーク（ＬＡＮ）環境において、達成することができる。又、保証された帯域巾及び待ち時間を有する会社間に特殊グレードのポイント対ポイントプライベート接続を得ることができる。しかし、一般的なインターネットに接続されたサーバーセンターにおいてゲームをホストし、次いで、ブロードバンド接続を経てユーザへ圧縮ビデオをストリーミングするゲーム又はアプリケーションシステムでは、多数のファクタから待ち時間を招き、従来システムの展開に甚だしい制限を生じさせる。
典型的なブロードバンド接続の家庭では、ユーザは、ブロードバンドサービスのためにＤＳＬ又はケーブルモデムをもつことができる。このようなブロードバンドサービスは、通常、ユーザの家庭と一般的なインターネットとの間に２５ｍｓ程度（時々はそれ以上の）の往復待ち時間を被る。更に、インターネットを経てサーバーセンターへデータをルーティングすることからも往復遅延を被る。インターネットを通しての待ち時間は、データが与えられるルート及びそれがルーティングされるときに被る遅延に基づいて変化する。ルーティング遅延に加えて、ほとんどのインターネットを相互接続する光ファイバを経て進む光の速度のために、往復遅延も被る。例えば、１０００マイルごとに、光ファイバを通る光の速度及び他のオーバーヘッドのために、約２２ｍｓの往復待ち時間を被る。
インターネットを経てストリーミングされるデータのデータレートのために、付加的な待ち時間が生じる。例えば、ユーザが「６Ｍｂｐｓ ＤＳＬサービス」として販売されるＤＳＬサービスを有する場合に、実際に、ユーザは、おそらく、せいぜい５Ｍｂｐｓ未満のダウンストリームスループットしか得ず、そしておそらく、デジタルサブスクライバーラインアクセスマルチプレクサ（ＤＳＬＡＭ）におけるピークロード時間中の混雑のような種々のファクタのために、接続の質低下を周期的に見ることになる。又、ケーブルモデムシステムネットワークにおける隣接部又は他のどこかを経てループされるローカル共有同軸ケーブルに混雑が生じる場合には、「６Ｍｂｐｓケーブルモデムサービス」として販売される接続に使用されるケーブルモデムのデータレートを遥かに低く減少する同様の問題が発生する。４Ｍｂｐｓの一定レートでのデータパケットがサーバーセンターからこのような接続を経てユーザデータグラムプロトコル（ＵＤＰ）フォーマットで一方向としてストリーミングされる場合には、全てがうまく機能すれば、データパケットが、付加的な待ち時間を被ることなく通過するが、混雑（又は他の障害）が存在し且つユーザへデータをストリーミングするのに３．５Ｍｂｐｓしか利用できない場合には、典型的な状態において、パケットがドロップされてデータロスを生じるか、又はパケットを送ることができるまで混雑点にパケットがキューイングされて付加的な待ち時間を招くか、のいずれかである。異なる混雑点は、遅延パケットを保持する異なるキューイング容量を有し、従って、あるケースでは、混雑を通過できないパケットが直ちにドロップされる。他のケースでは、数メガビットのデータがキューイングされ、最終的に、送出される。しかし、ほぼ全てのケースにおいて、混雑点におけるキューは、容量限界があり、これらの限界を越えると、キューがオーバーフローし、パケットがドロップされる。従って、付加的な待ち時間（又は更に悪い場合は、パケットのロス）を被るのを回避するために、ゲーム又はアプリケーションサーバーからユーザへのデータレート容量を越えないようにする必要がある。
又、サーバーにおいてビデオを圧縮しそしてクライアント装置においてビデオを解凍するのに要求される時間によっても待ち時間を被る。更に、サーバー上で実行されているビデオゲームが、表示されるべき次のフレームを計算する間にも待ち時間を被る。現在入手できるビデオ圧縮アルゴリズムは、高いデータレート又は長い待ち時間のいずれかで悩まされている。例えば、モーションＪＰＥＧは、待ち時間が短いことを特徴とするイントラフレーム専用ロッシー(intra frame-only lossy)圧縮アルゴリズムである。各ビデオフレームは、互いのビデオフレームと独立して圧縮される。クライアント装置は、圧縮されたモーションＪＰＥＧビデオのフレームを受け取ると、そのフレームを直ちに解凍して表示し、待ち時間を非常に短くする。しかし、各フレームは、別々に圧縮されるので、アルゴリズムは、連続するフレーム間の類似性を利用することができず、その結果、イントラフレーム専用ビデオ圧縮アルゴリズムは、非常に高いデータレートで悩まされている。例えば、６０ｆｐｓ（フレーム／秒）６４０ｘ４８０モーションＪＰＥＧビデオは、４０Ｍｂｐｓ（メガビット／秒）以上のデータを要求する。このように低い解像度のビデオウインドウに対するこのように高いデータレートは、多くのブロードバンドアプリケーションにおいて（及び確実にほとんどの消費者インターネットベースのアプリケーションに対して）法外に高価なものとなる。更に、各フレームは独立して圧縮されるので、ロッシー圧縮から生じ得るフレーム内の欠陥は、おそらく、連続するフレームの異なる場所に現れる。これは、ビデオが解凍されたときに、動く視覚上の欠陥として視聴者に見える。
マイクロソフト社からのＭＰＥＧ２、Ｈ．２６４、又はＶＣ９のような他の圧縮アルゴリズムは、従来の構成で使用されたときに、高い圧縮比を達成できるが、長い待ち時間が犠牲となる。このようなアルゴリズムは、インターフレーム及びイントラフレームの圧縮を使用する。周期的に、このようなアルゴリズムは、フレームのイントラフレーム専用圧縮を遂行する。このようなフレームは、キーフレーム（典型的に“Ｉ”フレームと称される）として知られている。次いで、これらのアルゴリズムは、典型的に、Ｉフレームを手前のフレーム及び連続するフレームの両方と比較する。手前のフレーム及び連続するフレームを独立して圧縮するのではなく、このアルゴリズムは、Ｉフレームから手前のフレーム及び連続するフレームへと映像の何が変化したか決定し、次いで、それらの変化を、Ｉフレームに先行する変化については“Ｂ”フレームとして、及びＩフレームに続く変化については“Ｐ”フレームとして記憶する。これは、イントラフレーム専用圧縮よりも非常にゆっくりしたデータレートを生じさせる。しかし、これは、典型的に、長い待ち時間を犠牲とする。Ｉフレームは、典型的に、Ｂ又はＰフレームより非常に大きく（しばしば１０倍以上）、その結果、所与のデータレートで送信するのに比例的に長い時間を要する。
例えば、Ｉフレームが、Ｂ及びＰフレームのサイズの１０倍であり、単一のＩイントラフレームごとに２９個のＢフレーム＋３０個のＰフレーム＝５９個のインターフレームがあるか、又は「フレームグループ（ＧＯＰ）」ごとに合計６０個のフレームがある状態を考える。従って、６０ｆｐｓでは、毎秒１つの６０フレームＧＯＰがある。送信チャンネルが２Ｍｂｐｓの最大データレートを有すると仮定する。チャンネルに最高クオリティのビデオを得るために、圧縮アルゴリズムは、２Ｍｂｐｓのデータストリームを発生し、上述した比を仮定すれば、これは、２メガビット（Ｍｂ）／（５９＋１０）＝３０，３９４ビット／イントラフレーム及び３０３，９３５ビット／Ｉフレームを生じさせる。圧縮されたビデオストリームが解凍アルゴリズムによって受信されるときには、ビデオを着実にプレイするために、各フレームを規則的な間隔（例えば、６０ｆｐｓ）で解凍して表示する必要がある。この結果を得るために、フレームが送信待ち時間を受ける場合には、全てのフレームを少なくともその待ち時間だけ遅延する必要があり、従って、最悪のケースのフレーム待ち時間は、各ビデオフレームに対する待ち時間を定義する。Ｉフレームは、最も大きなものであるから、最長の送信待ち時間を導入し、Ｉフレームを解凍して表示できるまでにＩフレーム全体を受信しなければならない（又はインターフレームがＩフレームに依存する）。チャンネルデータレートが２Ｍｂｐｓであると仮定すれば、Ｉフレームを送信するのに、３０３，９３５／２Ｍｂ＝１４５ｍｓを要することになる。
送信チャンネルの帯域巾の大部分を使用する上述したインターフレームビデオ圧縮システムは、フレームの平均サイズに対してＩフレームのサイズが大きいために長い待ち時間を受けることになる。又は、換言すれば、従来のインターフレーム圧縮アルゴリズムは、イントラフレーム専用圧縮アルゴリズムより低いフレーム当たり平均データレートを達成するが（例えば、２Ｍｂｐｓ対４０Ｍｂｐｓ）、大きなＩフレームのために、依然、高いフレーム当たりピークデータレートで悩まされている（例えば、３０３，９３５＊６０＝１８．２Ｍｂｐｓ）。前記分析は、Ｐ及びＢの両フレームがＩフレームより非常に小さいと仮定していることを銘記されたい。これは、一般的には、真であるが、高い映像複雑さが手前のフレーム、高モーション又はシーンの変化に相関していないフレームについては真ではない。このような状態では、Ｐ又はＢフレームがＩフレームと同程度の大きさになる（Ｐ又はＢフレームがＩフレームより大きくなると、精巧な圧縮アルゴリズムが、典型的に、Ｉフレームを「強制(force)」し、そしてＰ又はＢフレームをＩフレームに置き換える）。従って、デジタルビデオストリームには、いつでも、Ｉフレームサイズのデータレートピークが生じる。従って、圧縮されたビデオでは、平均ビデオデータレートが送信チャンネルのデータレート容量に接近するときに（ビデオに対する高いデータレート要求を仮定すると、しばしばそうである）、Ｉフレーム或いは大きなＰ又はＢフレームからの高いピークデータレートが長いフレーム待ち時間を生じさせる。
もちろん、以上の説明は、ＧＯＰにおける大きなＢ、Ｐ又はＩフレームによって生じる圧縮アルゴリズムの待ち時間を特徴付けるに過ぎない。Ｂフレームが使用される場合は、待ち時間がより長くなる。その理由は、Ｂフレームを表示できるまでに、Ｂフレーム及びＩフレーム後の全てのＢフレームを受信しなければならないからである。従って、各Ｉフレームの前に５個のＢフレームがあるＢＢＢＢＢＩＰＰＰＰＰＢＢＢＢＢＩＰＰＰＰＰのような画像グループ（ＧＯＰ）シーケンスにおいて、最初のＢフレームは、その後のＢフレーム及びＩフレームが受信されるまでビデオデコンプレッサによって表示することができない。従って、ビデオが６０ｆｐｓ（即ち、１６．６７ｍｓ／フレーム）でストリーミングされる場合には、最初のＢフレームを解凍できるまでに、チャンネル帯域巾がどれほど速くても、５個のＢフレーム及びＩフレームは、受信するのに１６．６７＊６＝１００ｍｓを要し、これは、ちょうど、５個のＢフレームである。３０個のＢフレームをもつ圧縮されたビデオシーケンスは、極めて一般的である。そして、２Ｍｂｐｓのような低いチャンネル帯域巾では、Ｉフレームのサイズにより生じる待ち時間の影響が、主として、Ｂフレームが到着するのを待機することによる待ち時間の影響に加えられる。従って、２Ｍｂｐｓチャンネルにおいて、非常に多数のＢフレームがある状態では、従来のビデオ圧縮技術を使用して、５００ｍｓ以上の待ち時間を越えるのは極めて容易である。Ｂフレームが使用されない（所与のクオリティレベルに対して低い圧縮比を犠牲にして）場合には、Ｂフレームの待ち時間を被らないが、上述したピークフレームサイズにより生じる待ち時間は、依然、被る。
この問題は、まさに多数のビデオゲームの性質により激化される。上述したＧＯＰ構造を使用するビデオ圧縮アルゴリズムは、主として、受動的な視聴に意図された生のビデオ又は動画資料で、使用上最適化されている。典型的に、カメラ（実際のカメラであるか、コンピュータ発生アニメーションの場合のバーチャルカメラであるかに関わらず）、及びシーンは、比較的安定である。というのは、単に、カメラ又はシーンがあまりに急に動く場合に、ビデオ又は映画資料が、（ａ）典型的に見るのに不快であり、そして（ｂ）それを見る場合に、カメラが突然グイと動くときに、通常、視聴者がアクションを厳密に追従できないからである（例えば、バースディケーキのキャンドルに息を吹きかける子供を撮影するときにカメラがバンプされ、そして突然ケーキから離れて戻るようにグイと動かされる場合に、視聴者は、典型的に、子供及びケーキに集中し、カメラが突然動くときの短い中断は無視する）。ビデオのインタビュー又はビデオ遠隔会議のケースでは、カメラを固定位置に保持して、全く動かさず、非常に僅かなデータピークしか生じさせない。しかし、３Ｄ高アクションビデオゲームは、一定の動きにより特徴付けられる（例えば、レースの期間中に全フレームが迅速な動きにあるような３Ｄレースを考えるか、又はバーチャルカメラが常にグイと動くようなファーストパーソンシューター(first-person shooter)を考える）。このようなビデオゲームは、これらの突然の動きの間に何が起きたかユーザがはっきり見る必要があるところの大きなそして頻繁なピークを伴うフレームシーケンスを生じさせる。従って、３Ｄ高アクションビデオゲームでは、圧縮欠陥は、ほとんど許容できない。従って、多くのビデオゲームのビデオ出力は、それらの性質により、非常に高く且つ頻繁なピークをもつ圧縮ビデオストリームを発生する。
高速アクションビデオゲームのユーザが長い待ち時間に対してあまり寛容度がないと仮定し、又、上述した全ての待ち時間の原因を仮定すれば、今日まで、インターネットを経てビデオをストリーミングするサーバーホスト型ビデオゲームには制限があった。更に、高度の双方向性を要求するアプリケーションのユーザは、そのアプリケーションが一般的なインターネット及びストリームビデオでホストされる場合には、同様に制限で悩まされている。このようなサービスは、ホスティングサーバーが、商業的な設定において、ヘッドエンド（ケーブルブロードバンドの場合）、又は中央オフィス（デジタルサブスクライバーライン（ＤＳＬ）の場合）、或いはＬＡＮ（又は特殊グレードのプライベート接続）内に直接設定されて、クライアント装置からサーバーへのルート及び距離が待ち時間を最小にするように制御され、且つ待ち時間を被ることなくピークを受け容れできるようなネットワークコンフィギュレーションを要求する。ＬＡＮ（典型的に１００Ｍｂｐｓから１Ｇｂｐｓ定格）及び充分な帯域巾の賃貸ラインは、典型的に、ピーク帯域巾要求をサポートすることができる（例えば、１８Ｍｂｐｓのピーク帯域巾は、１００ＭｂｐｓのＬＡＮ容量の小部分である）。
又、ピーク帯域巾要求は、特殊な受け容れがなされる場合には、住居用ブロードバンドインフラストラクチャーにより受け容れることができる。例えば、ケーブルＴＶシステムでは、デジタルビデオトラフィックに、大きなＩフレームのようなピークを取り扱うことのできる専用帯域巾が与えられる。そしてＤＳＬシステムでは、高速ＤＳＬモデムを準備して、高いピークを許すことができるか、又は高いデータレートを取り扱うことのできる特殊グレードの接続を準備することができる。しかし、一般的なインターネットに取り付けられる従来のケーブルモデム及びＤＳＬインフラストラクチャーは、圧縮ビデオのピーク帯域要件に対して遥かに低い寛容度しか有していない。従って、クライアント装置から長距離にあるサーバーセンターにおいてビデオゲーム又はアプリケーションをホストし、次いで、インターネットを経て従来の住居用ブロードバンド接続を通して圧縮ビデオ出力をストリーミングするオンラインサービスは、特に、非常に短い待ち時間を要求するゲーム及びアプリケーション（例えば、ファーストパーソンシューター及び他のマルチユーザ双方向アクションゲーム、又は高速応答時間を要求するアプリケーション）に関して、顕著な待ち時間及びピーク帯域巾制限で悩まされている。
本開示は、添付図面及び以下の詳細な説明から、より完全に理解されよう。しかしながら、ここに開示した要旨は、本発明を例示するものに過ぎず、ここに示す特定の実施形態に限定されるものではない。
従来のビデオゲームシステムのアーキテクチャーを示す。 一実施形態による高レベルシステムアーキテクチャーを示す。 一実施形態による高レベルシステムアーキテクチャーを示す。 クライアントとサーバーとの間の通信に対する実際のデータレート、定格データレート、及び要求されるデータレートを示す。 一実施形態により使用されたホスティングサービス及びクライアントを示す。 クライアントとホスティングサービスとの間の通信に関連した例示的待ち時間を示す。 一実施形態によるクライアント装置を示す。 別の実施形態によるクライアント装置を示す。 図４ｃのクライアント装置のブロック図である。 図４ｄのクライアント装置のブロック図である。 一実施形態により使用できるビデオ圧縮の一形式を例示する。 別の実施形態に使用できるビデオ圧縮の一形式を例示する。 低い複雑さ、低アクションのビデオシーケンスの送信に関連したデータレートのピークを示す。 高い複雑さ、高アクションのビデオシーケンスの送信に関連したデータレートのピークを示す。 一実施形態に使用されるビデオ圧縮技術を示す。 一実施形態に使用されるビデオ圧縮技術を示す。 一実施形態に使用される付加的なビデオ圧縮技術を示す。 本発明の一実施形態に使用されるフレームレート処理技術を示す。 本発明の一実施形態に使用されるフレームレート処理技術を示す。 本発明の一実施形態に使用されるフレームレート処理技術を示す。 映像タイルをパケット内に効率的にパックする一実施形態を示す。 映像タイルをパケット内に効率的にパックする一実施形態を示す。 順方向エラー修正技術を使用する実施形態を示す。 順方向エラー修正技術を使用する実施形態を示す。 順方向エラー修正技術を使用する実施形態を示す。 順方向エラー修正技術を使用する実施形態を示す。 圧縮のためのマルチコア処理ユニットを示す一実施形態を示す。 実施形態による地理的ポジショニング及びホスティングサービス間の通信を示す。 実施形態による地理的ポジショニング及びホスティングサービス間の通信を示す。 クライアントとホスティングサービスとの間の通信に関連した待ち時間を例示する。 ホスティングサービスのサーバーセンターアーキテクチャーを示す。 複数の生のビデオウインドウを含むユーザインターフェイスの一実施形態のスクリーンショットを例示する。 特定のビデオウインドウを選択した後の図１６のユーザインターフェイスを示す。 特定のビデオウインドウをフルスクリーンサイズへズーミングした後の図１７のユーザインターフェイスを示す。 マルチプレーヤゲームのスクリーンにオーバーレイされる共同ユーザビデオデータを例示する。 ホスティングサービスにおけるゲームプレーヤのためのユーザページを例示する。 ３Ｄ双方向広告を例示する。 生の演技の表面捕獲からのテクスチャ処理表面を有するホトリアルな映像を発生するための一連のステップを例示する。 リニアメディアコンテンツの選択を許すユーザインターフェイスページを例示する。 ウェブページが生である前に経過する時間長さを接続速度に対して示すグラフである。 クライアント装置からホスティングサービスへのフィードバックチャンネルを使用する本発明の実施形態を示す。 クライアント装置からホスティングサービスへのフィードバックチャンネルを使用する本発明の実施形態を示す。 首尾良く受信されるように最後に知られたタイル／フレームに基づきタイル／フレームをエンコードする実施形態を示す。 首尾良く受信されるように最後に知られたタイル／フレームに基づきタイル／フレームをエンコードする実施形態を示す。 ゲーム又はアプリケーションの状態が第１のホスティングサービス又はサーバーから第２のホスティングサービス又はサーバーへポートされる実施形態を示す。 ゲーム又はアプリケーションの状態が第１のホスティングサービス又はサーバーから第２のホスティングサービス又はサーバーへポートされる実施形態を示す。 異なるデータを使用してゲーム又はアプリケーションの状態がポートされる一実施形態を示す。 クライアント装置に一時的デコーダを使用する本発明の一実施形態を示す。 本発明の一実施形態により「Ｉタイル」が「Ｒフレーム」間にどのように散在されるか示す。 生のストリーム及び／又は１つ以上のＨＱストリームを発生する本発明の実施形態を示す。 生のストリーム及び／又は１つ以上のＨＱストリームを発生する本発明の実施形態を示す。 生のストリーム及び／又は１つ以上のＨＱストリームを発生する本発明の実施形態を示す。 生のストリーム及び／又は１つ以上のＨＱストリームを発生する本発明の実施形態を示す。 生のストリーム及び／又は１つ以上のＨＱストリームを発生する本発明の実施形態を示す。 生のストリーム及び／又は１つ以上のＨＱストリームを発生する本発明の実施形態を示す。 生のストリーム及び／又は１つ以上のＨＱストリームを発生する本発明の実施形態を示す。 生のストリーム及び／又は１つ以上のＨＱストリームを発生する本発明の実施形態を示す。
以下の説明では、本開示を完全に理解するために、装置の形式、システムコンフィギュレーション、通信方法、等の特定の細部について述べる。しかしながら、当業者であれば、ここに述べる実施形態を具現化するのに、これらの特定の細部は必要ないことが明らかであろう。
図２ａ−ｂは、ビデオゲーム及びソフトウェアアプリケーションが、契約サービスのもとでインターネット２０６（或いは他のパブリック又はプライベートネットワーク）を経てユーザの家屋２１１（「ユーザの家屋」とは、ユーザが所在する場所を意味し、移動装置を使用する場合には屋外も含む）においてホスティングサービス２１０によりホストされそしてクライアント装置２０５によりアクセスされるような２つの実施形態の高レベルアーキテクチャーを示す。クライアント装置２０５は、内部又は外部ディスプレイ装置２２２を有していてインターネットにワイヤード又はワイヤレス接続されるＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ又はＬｉｎｕｘベースのＰＣ又はＡｐｐｌｅ社のＭａｃｉｎｔｏｓｈコンピュータのような汎用コンピュータでもよいし、又はビデオ及びオーディオをモニタ又はＴＶ受像機２２２へ出力するセットトップボックス（インターネットにワイヤード又はワイヤレス接続される）のような専用クライアント装置でもよいし、或いはおそらくインターネットにワイヤレス接続される移動装置でもよい。
これらの装置は、いずれも、それ自身のユーザ入力装置（例えば、キーボード、ボタン、タッチスクリーン、トラックパッド又は慣性感知棒、ビデオ捕獲カメラ及び／又は運動追跡カメラ、等）を有してもよいし、又は有線又は無線で接続された外部入力装置２２１（例えば、キーボード、マウス、ゲームコントローラ、慣性感知棒、ビデオ捕獲カメラ、及び／又は運動追跡カメラ、等）を使用してもよい。以下に詳細に述べるように、ホスティングサービス２１０は、高パワーのＣＰＵ／ＧＰＵ処理能力を伴うものを含めて、種々の性能レベルのサーバーを含む。ゲームのプレイ中、又はホスティングサービス２１０におけるアプリケーションの使用中に、家庭又はオフィス用のクライアント装置２０５は、ユーザからのキーボード及び／又はコントローラ入力を受け取り、次いで、インターネット２０６を通してホスティングサービス２１０へコントローラ入力を送信し、このホスティングサービス２１０は、それに応答してゲームプログラムを実行し、そしてゲーム又はアプリケーションソフトウェアのためのビデオ出力の連続フレーム（一連のビデオ映像）を発生する（例えば、ユーザがボタンを押して、スクリーン上のキャラクタを右へ移動するように指令する場合には、ゲームプログラムが、右へ移動するキャラクタを示す一連のビデオ映像を生成する）。この一連のビデオ映像は、次いで、短待ち時間のビデオコンプレッサを使用して圧縮され、次いで、ホスティングサービス２１０は、インターネット２０６を通して短待ち時間のビデオストリームを送信する。家庭又はオフィス用クライアント装置は、次いで、圧縮されたビデオストリームをデコードし、そしてモニタ又はＴＶにおいてその解凍されたビデオ映像をレンダリングする。その結果、クライアント装置２０５のコンピューティング及びグラフィックハードウェア要件が著しく緩和される。クライアント２０５は、キーボード／コントローラ入力をインターネット２０６へ転送し、そしてインターネット２０６から受け取った圧縮されたビデオストリームをデコードし解凍するための処理パワーを有するだけでよく、これは、実質上、パーソナルコンピュータが、今日、そのＣＰＵにおいてソフトウケアで実行できることである（例えば、ほぼ２ＧＨｚで実行されるインテル社のＣｏｒｅ Ｄｕｏ ＣＰＵは、Ｈ．２６４及びＷｉｎｄｏｗｓ Ｍｅｄｉａ ＶＣ９のようなコンプレッサを使用してエンコードされた７２０ｐ ＨＤＴＶを解凍することができる）。そして、クライアント装置のケースでは、専用のチップも、このような規格に対するビデオ解凍を、リアルタイムで、遥かに低いコストにおいて、且つ近代的なＰＣに要求されるような汎用ＣＰＵより遥かに低い消費電力で遂行することができる。特に、コントローラ入力を転送しそしてビデオを解凍する機能を遂行するために、家庭用クライアント装置２０５は、特殊なグラフィック処理ユニット（ＧＰＵ）、光学的ドライブ又はハードドライブ、例えば、図１に示す従来のビデオゲームシステムを要求しない。
ゲーム及びアプリケーションソフトウェアが、より複雑になり且つよりホトリアリスティックになるにつれて、それらは、高性能ＣＰＵ、ＧＰＵ、より多くのＲＡＭ、及びより大きくて高速のディスクドライブを要求し、且つホスティングサービス２１０のコンピューティングパワーは、アップグレードし続けるが、エンドユーザは、家庭又はオフィス用のクライアントプラットホーム２０５を更新することが要求されない。というのは、その処理要件は、所与のビデオ解凍アルゴリズムでの表示解像度及びフレームレートに対して一定のままだからである。従って、図２ａ−ｂに示すシステムには、今日見られるハードウェア制限及び互換性の問題が生じない。
更に、ゲーム及びアプリケーションソフトウェアは、ホスティングサービス２１０のサーバーでのみ実行されるので、ゲーム又はアプリケーションソフトウェアのコピー（光学的メディアの形態又はダウンロードされたソフトウェアとして）がユーザの家庭又はオフィスに存在することはない（ここで使用する「オフィス」とは、特に指示のない限り、例えば、学校の教室を含めて、非住居設定を含むものとする）。これは、ゲーム又はアプリケーションソフトウェアが不法にコピーされる（海賊版作成される）おそれを著しく軽減すると共に、海賊版作成されるゲーム又はアプリケーションにより貴重なデータベースが使用されるおそれを軽減する。実際に、家庭又はオフィスでの使用に実際的でないゲーム又はアプリケーションソフトウェアをプレイするために特殊なサーバーが要求される（例えば、非常に高価で、大きく又はノイズを発生する装置が要求される）場合には、ゲーム又はアプリケーションソフトウェアの海賊版コピーが得られたとしても、家庭又はオフィスで動作することはできない。
一実施形態では、ホスティングサービス２１０は、ソフトウェア開発ツールをゲーム又はアプリケーションソフトウェア開発者（一般的に、ソフトウェア開発会社、ゲーム又は映画スタジオ、或いはゲーム又はアプリケーションソフトウェア発行者を指す）２２０に与え、この開発者は、ホスティングサービス２１０において実行できるゲームを設計するようにビデオゲームを設計する。そのようなツールは、スタンドアローンＰＣ又はビデオゲームコンソールでは通常利用できないホスティングサービスの特徴を開発者が利用できるようにする（例えば、複雑な幾何学形状の非常に大きなデータベースへの高速アクセス（「幾何学形状」とは、特に指示のない限り、ここでは、多角形、テクスチャ、リギング、照明、挙動、並びに３Ｄデータベースを定義する他のコンポーネント及びパラメータを指すものとする））。
このアーキテクチャーのもとでは、異なるビジネスモデルが考えられる。１つのモデルのもとで、ホスティングサービス２１０は、図２ａに示すように、エンドユーザから契約料金を収集し、そして開発者２２０にロイヤリティを支払う。図２ｂに示す別の具現化においては、開発者２２０がユーザから契約料金を直接収集し、そしてゲーム又はアプリケーションコンテンツをホストするためにホスティングサービス２１０に支払をする。これらの基礎的な原理は、オンラインゲーム又はアプリケーションホスティングを提供するための特定のビジネスモデルに限定されない。
圧縮ビデオ特性
上述したように、ビデオゲームサービス又はアプリケーションソフトウェアサービスをオンラインで提供することに伴う１つの顕著な問題は、待ち時間である。（ユーザにより入力装置が操作される点から、ディスプレイ装置に応答が表示される点までの）７０から８０ｍｓの待ち時間が、高速応答時間を要求するゲーム及びアプリケーションの上限である。しかしながら、図２ａ及び２ｂに示すアーキテクチャーの環境では多数の実際的及び物理的な制約があるために、これを達成することが非常に困難である。
図３に示すように、ユーザがインターネットサービスに契約するときに、その接続は、典型的に、ユーザの家庭又はオフィスへの公称最大データレート３０１によって定格付けされる。プロバイダーのポリシー及びルーティング装置の能力に基づいて、その最大データレートは、若干厳格に施行できるが、典型的に、実際に得られるデータレートは、多数の異なる理由の１つで、低いものとなる。例えば、ＤＳＬ中央オフィス又はローカルケーブルモデムループに非常に多くのネットワークトラフィックがあるか、又はケーブルにノイズが生じてパケットをドロップさせるか、或いはプロバイダーが最大ビット数／月／ユーザを確立することがある。現在、ケーブル及びＤＳＬサービスに対する最大ダウンストリームデータレートは、典型的に、数百キロビット／秒（Ｋｂｐｓ）から３０Ｍｂｐｓの範囲である。セルラーサービスは、典型的に、数百Ｋｂｐｓのダウンストリームデータに制限される。しかしながら、ブロードバンドサービスの速度及びブロードバンドサービスに契約するユーザの数は、時間と共に急激に増加する。現在、ある分析では、米国のブロードバンド加入者の３３％が２Ｍｂｐｓ以上のダウンストリームデータレートを有することが推定される。例えば、ある分析では、２０１０年までに、米国のブロードバンド加入者の８５％以上が２Ｍｂｐｓ以上のデータレートを有することが推定される。
図３に示すように、実際に利用可能な最大データレート３０２は、時間と共に変動し得る。従って、短い待ち時間のオンラインゲーム又はアプリケーションソフトウェアコンテクストでは、時々、特定のビデオストリームに対する実際に利用できるデータレートを予想することが困難である。所与の数値のフレーム／秒（ｆｐｓ）における所与のレベルのクオリティをある量のシーンの複雑さに対し所与の解像度（例えば、６４０ｘ４８０＠６０ｆｐｓ）において維持するためにデータレート３０３が要求され、そして（図３にピークで示されるように）実際に利用できる最大データレート３０２より上に動きが上昇する場合には、多数の問題が発生し得る。例えば、あるインターネットサービスは、単にパケットをドロップし、ユーザのビデオスクリーンにデータロス及び映像歪／ロスを招くことになる。他のサービスは、付加的なパケットを一時的にバッファし（即ち、キューイングし）、そして利用可能なデータレートでクライアントへパケットを与えて、待ち時間の増加、即ち多数のビデオゲーム及びアプリケーションにとって受け容れられない結果を招くことになる。最終的に、あるインターネットサービスプロバイダーは、データレートの増加を、悪意のある攻撃、例えば、サービス拒否攻撃（ネットワーク接続を無能化するためにハッカーにより使用される良く知られた技術）とみなし、そしてユーザのインターネット接続を指定期間中切断する。従って、ここに述べる実施形態は、ビデオゲームに要求されるデータレートが、利用可能な最大データレートを越えないことを保証するステップをとる。
ホスティングサービスアーキテクチャー
図４ａは、一実施形態によるホスティングサービス２１０のアーキテクチャーを示す。ホスティングサービス２１０は、単一サーバーセンターに配置することもできるし、又は複数のサーバーセンターにわたり分散することもできる（あるサーバーセンターへの経路が他のサーバーセンターより短い待ち時間となる短待ち時間接続をユーザに与え、ユーザ間に負荷バランスを与え、そして１つ以上のサーバーセンターがフェイルする場合に冗長性を与えるために）。ホスティングサービス２１０は、最終的に、数百又は数千或いは数百万のサーバー４０２を含み、非常に大きなユーザベースにサービスすることができる。ホスティングサービスコントロールシステム４０１は、ホスティングサービス２１０に対する全体的なコントロールを与え、ルーター、サーバー、ビデオ圧縮システム、ビリング及びアカウンティングシステム、等に指令する。一実施形態では、ホスティングサービスコントロールシステム４０１は、ユーザ情報、サーバー情報及びシステム統計情報のためのデータベースを記憶するのに使用されるＲＡＩＤアレイに結合された分散処理Ｌｉｎｕｘベースシステムにおいて具現化される。以上の説明では、ホスティングサービス２１０により具現化される種々のアクションは、他の特定システムに起因しない限り、ホスティングサービスコントロールシステム４０１により開始されコントロールされる。
ホスティングサービス２１０は、インテル、ＩＢＭ、ヒューレットパッカード、等から現在入手できるもののような多数のサーバー４０２を含む。或いは又、サーバー４０２は、コンポーネントのカスタム構成でアッセンブルすることもできるし、又は全サーバーが単一チップとして具現化されるように最終的に一体化することもできる。この図は、図示明瞭化のために、少数のサーバー４０２しか示していないが、実際の展開では、１つ程度のサーバー４０２があってもよいし、又は数百万以上のサーバー４０２があってもよい。サーバー４０２は、全てが同様に構成されてもよいし（幾つかの構成パラメータの例として、同じＣＰＵ形式及び性能で、ＧＰＵをもったりもたなかったりして、そしてＧＰＵをもつ場合には、同じＧＰＵ形式及び性能で、又、同じ数のＣＰＵ及びＧＰＵで、又、同じ量及び形式／速度のＲＡＭで、並びに同じＲＡＭ構成で）、又はサーバー４０２の種々のサブセットが同じ構成を有してもよいし（例えば、サーバーの２５％をある仕方で構成することができ、５０％を異なる仕方で構成することができ、そして２５％を更に別の仕方で構成することができ）、或いは各サーバー４０２が異なるものでもよい。
一実施形態では、サーバー４０２は、ディスクレスであり、即ちそれ自身のローカル大量記憶装置（光学又は磁気記憶装置、或いは半導体ベースの記憶装置、例えば、フラッシュメモリ又は同様の機能を果たす他の大量記憶手段）を有するのではなく、各サーバーは、高速バックプレーン又はネットワーク接続を通して共有大量記憶装置にアクセスする。一実施形態では、この高速接続は、一連の独立ディスク冗長アレイ（ＲＡＩＤ）４０５に接続された記憶エリアネットワーク（ＳＡＮ）４０３であり、装置間の接続がギガビットイーサネット（登録商標）を使用して具現化される。当業者に明らかなように、ＳＡＮ４０３は、多数のＲＡＩＤアレイ４０５を一緒に合成して、最終的に広い帯域巾を生じさせ、即ち現在のゲームコンソール及びＰＣに使用されるＲＡＭから得られる帯域巾に接近するか又はそれを潜在的に越えるのに使用される。そして、磁気メディアのような回転メディアをベースとするＲＡＩＤアレイは、著しいシーク時間アクセス待ち時間をしばしば有するが、半導体記憶装置をベースとするＲＡＩＤアレイは、相当に短いアクセス待ち時間で具現化することができる。別の構成では、サーバー４０２の幾つか又は全部が、それら自身の大量記憶装置の幾つか又は全部をローカルで与える。例えば、サーバー４０２は、そのオペレーティングシステムのような頻繁にアクセスされる情報、及びビデオゲーム又はアプリケーションのコピーを短待ち時間のローカルフラッシュベースの記憶装置に記憶するが、幾何学形状又はゲーム状態情報の大きなデータベースに時々アクセスするには、ＳＡＮを使用して、回転メディアをベースとするＲＡＩＤアレイ４０５に大きなシーク待ち時間でアクセスする。
更に、一実施形態では、ホスティングサービス２１０は、以下に詳細に説明する短待ち時間のビデオ圧縮ロジック４０４を使用する。このビデオ圧縮ロジック４０４は、ソフトウェア、ハードウェア又はその組合せで具現化することができる（その幾つかの実施形態を以下に説明する）。ビデオ圧縮ロジック４０４は、オーディオ及びビジュアル資料を圧縮するためのロジックを含む。
動作に際し、ユーザの家屋２１１において、キーボード、マウス、ゲームコントローラ又は他の入力装置４２１を経てビデオゲームをプレイするか又はアプリケーションを使用する間に、クライアント４１５のコントロール信号ロジック４１３は、ユーザにより作動されたボタン押圧（及び他の形式のユーザ入力）を表す（典型的にＵＤＰパケットの形態の）コントロール信号４０６ａ−ｂを送信する。所与のユーザからのコントロール信号は、適当なサーバー（又は複数のサーバーがユーザの入力装置に応答する場合には複数のサーバー）４０２へルーティングされる。図４ａに示すように、コントロール信号４０６ａは、ＳＡＮを経てサーバー４０２へルーティングされる。それとは別に又はそれに加えて、コントロール信号４０６ｂは、ホスティングサービスネットワーク（例えば、イーサネットベースのローカルエリアネットワーク）を経てサーバー４０２へ直接ルーティングされる。それらがどのように送信されるかに関わらず、サーバー（１つ又は複数）は、コントロール信号４０６ａ−ｂに応答してゲーム又はアプリケーションソフトウェアを実行する。図４ａに示されていないが、ファイアウオール（１つ又は複数）及び／又はゲートウェイ（１つ又は複数）のような種々のネットワークコンポーネントは、ホスティングサービス２１０の縁（例えば、ホスティングサービス２１０とインターネット４１０との間）において、及び／又はインターネット４１０と家庭又はオフィスクライアント４１５との間のユーザの家屋２１１の縁において到来するトラフィック及び出て行くトラフィックを処理することができる。実行されたゲーム又はアプリケーションソフトウェアのグラフィック及びオーディオ出力、即ちビデオ映像の新たなシーケンスは、短待ち時間のビデオ圧縮ロジック４０４へ供給され、このロジックは、ここに述べるような短待ち時間のビデオ圧縮技術に基づいてビデオ映像のシーケンスを圧縮し、そして圧縮されたビデオストリームを、典型的に、圧縮された又は非圧縮のオーディオと共に、インターネット４１０を経て（又は、以下に述べるように、一般的なインターネットをバイパスする最適な高速ネットワークサービスを経て）クライアント４１５へ返送する。クライアント４１５における短待ち時間のビデオ解凍ロジック４１２は、次いで、ビデオ及びオーディオストリームを解凍し、その解凍されたビデオストリームをレンダリングし、そして典型的に、その解凍されたオーディオストリームをディスプレイ装置４２２においてプレイする。或いは又、オーディオは、ディスプレイ装置４２２とは個別のスピーカで再生してもよいし、そうでなくてもよい。入力装置４２１及びディスプレイ装置４２２は、図２ａ及び２ｂでは独立した装置として示されているが、ポータブルコンピュータ又は移動装置のようなクライアント装置内に一体化されてもよいことに注意されたい。
家庭又はオフィスクライアント４１５（図２ａ及び２ｂにおいて家庭又はオフィスクライアント２０５として既に述べた）は、非常に安価で且つ低電力の装置で、計算又はグラフィック性能が非常に限定されていると共に、ローカルの大量記憶装置が非常に限定されたものであるか又はそれを全く有していない。対照的に、ＳＡＮ４０３及び複数のＲＡＩＤ４０５に結合された各サーバー４０２は、非常に高い性能のコンピューティングシステムであり、そして実際に、複数のサーバーが並列処理構成で協働的に使用される場合は、保持することのできる計算及びグラフィック処理パワーの量にほぼ制限がなくなる。そして、ユーザにとって知覚的に短待ち時間のビデオ圧縮４０４及び短待ち時間のビデオ圧縮４１２のために、サーバー４０２の計算パワーがユーザに与えられる。ユーザが入力装置４２１のボタンを押すと、ディスプレイ４２２上の映像は、ゲーム又はアプリケーションソフトウェアがローカルで実行されるかのように、知覚的に意義のある遅延を伴わずに、ボタンの押圧に応答して更新される。従って、短待ち時間のビデオ解凍及びコントロール信号ロジック４１３を具現化する非常に低性能のコンピュータ又は安価なチップである家庭又はオフィスクライアント４１５では、ローカルで利用できると思われるリモート位置から効果的な任意の計算パワーがユーザに与えられる。これは、最も進歩したプロセッサ集中の（典型的に新規な）ビデオゲーム及び最高性能のアプリケーションをプレイするパワーをユーザに与える。
図４ｃは、非常に基本的で且つ安価な家庭又はオフィスクライアント装置４６５を示す。この装置は、図４ａ及び４ｂからの家庭又はオフィスクライアント４１５の実施形態である。これは約２インチの長さである。これは、パワーオーバーイーサネット（ＰｏＥ）でイーサネットケーブルとインターフェイスするイーサネットジャック４６２を有し、そこから、インターネットへの電力及び接続が得られる。ネットワークアドレストランスレーション（ＮＡＴ）をサポートするネットワーク内でＮＡＴを実行することができる。オフィス環境では、多数の新規なイーサネットスイッチは、ＰｏＥを有し、そしてＰｏＥをオフィスのイーサネットジャックへ直接持って行く。このような状況では、壁ジャックからクライアント４６５へのイーサネットケーブルが要求されるだけである。利用できるイーサネット接続が（例えば、ＤＳＬ又はケーブルモデムをもつが、ＰｏＥはもたない家庭において）電力を搬送しない場合には、非給電イーサネットケーブル及びＰｏＥ付き出力イーサネットを受け容れる安価な壁「ブリック」（即ち電源）が利用できる。
クライアント４６５は、キーボード、マウス、ゲームコントローラ及び／又はマイクロホン及び／又はヘッドセットのようなブルーツース入力装置４７９とインターフェイスするブルーツースワイヤレスインターフェイスに結合された（図４ａの）コントロール信号ロジック４１３を含む。又、クライアント４６５の一実施形態は、１２０ｆｐｓビデオをサポートできるディスプレイ装置４６８に結合されるビデオを１２０ｆｐｓで出力し、そしてシャッター付き眼鏡４６６に信号を送って（典型的に赤外線により）、各次々のフレームで片方の目に、次いで、他方の目に交互にシャッター作動することができる。ユーザが認知する効果は、ディスプレイスクリーンを「跳び出す」ステレオ３Ｄ映像である。このようなオペレーションをサポートする１つのこのようなディスプレイ装置４６８は、Ｓａｍｓｕｎｇ ＨＬ−Ｔ５０７６Ｓである。各目のビデオストリームは個別であるから、一実施形態では、独立した２つのビデオストリームがホスティングサービス２１０により圧縮され、フレームは、時間的にインターリーブされ、そしてフレームは、クライアント４６５内の独立した２つの解凍プロセスとして解凍される。
又、クライアント４６５は、到来するビデオ及びオーディオを解凍してＨＤＭＩ（高鮮明度マルチメディアインターフェイス）を通して出力する短待ち時間のビデオ解凍ロジック４１２と、ＳＤＴＶ（標準鮮明度テレビジョン）又はＨＤＴＶ（高鮮明度テレビジョン）４６８に差し込まれてＴＶにビデオ及びオーディオを与えるか又はＨＤＭＩをサポートするモニタ４６８に差し込まれるコネクタ４６３とを含む。ユーザのモニタ４６８がＨＤＭＩをサポートしない場合には、ＨＤＭＩ対ＤＶＩ（デジタルビジュアルインターフェイス）を使用することができるが、オーディオが失われる。ＨＤＭＩ規格のもとでは、ディスプレイの能力（例えば、サポートされる解像度、フレームレート）４６４がディスプレイ装置４６８から通信され、この情報は、次いで、インターネット接続４６２を通してホスティングサービス２１０へ返送され、従って、ディスプレイ装置に適したフォーマットで圧縮ビデオをストリーミングすることができる。
図４ｄは、より多くの外部インターフェイスを有する以外は図４ｃに示す家庭又はオフィスクライアント装置４６５と同じである家庭又はオフィスクライアント装置４７５を示す。又、クライアント４７５は、電力に対してＰｏＥを受け容れることもできるし、又は壁に差し込まれる外部電源アダプタ（図示せず）から延びることもできる。クライアント４７５のＵＳＢ入力を使用すると、ビデオカメラ４７７は、圧縮されたビデオをクライアント４７５へ供給し、これは、クライアント４７５によってホスティングサービス２１０へアップロードされ、以下に述べるように使用される。カメラ４７７に内蔵されるのは、以下に述べる圧縮技術を使用した短待ち時間のコンプレッサである。
インターネット接続としてイーサネットコネクタを有するのに加えて、クライアント４７５は、インターネットへの８０２．１１ｇワイヤレスインターフェイスも有する。両インターフェイスは、ＮＡＴをサポートするネットワーク内でＮＡＴを使用することができる。
又、ビデオ及びオーディオを出力するためにＨＤＭＩコネクタを有するのに加えて、クライアント４７５は、アナログ出力を含む（且つ標準アダプタケーブルでＶＧＡ出力を与える）デュアルリンクＤＶＩ−Ｉコネクタも有する。又、これは、複合ビデオ及びＳ−ビデオのためのアナログ出力も有する。
オーディオに対して、クライアント４７５は、左右のアナログステレオＲＣＡジャックを、そしてデジタルオーディオ出力に対して、ＴＯＳＬＩＮＫ出力を有する。
又、入力装置４７９へのブルーツースワイヤレスインターフェイスに加えて、入力装置にインターフェイスするためのＵＳＢジャックも有する。
図４ｅは、クライアント４６５の内部アーキテクチャーの一実施形態を示す。図示された装置の全部又は幾つかを、フィールドプログラマブルロジックアレー、カスタムＡＳＩＣ、或いはカスタム設計又は既製の多数の個別装置で具現化することができる。
ＰｏＥを伴うイーサネット４９７がイーサネットインターフェイス４８１に取り付けられる。ＰｏＥを伴うイーサネット４９７から電力４９９が導出され、クライアント４６５内の残りの装置に接続される。バス４８０は、装置間の通信のための共通バスである。
フラッシュ４７６からの小さなクライアントコントロールアプリケーションを実行するコントロールＣＰＵ４８３（ほとんどの場合に、ＲＡＭが埋設された１００ＭＨｚのＭＩＰＳ Ｒ４０００シリーズＣＰＵのような小型のＣＰＵで充分である）は、ネットワーク（即ち、イーサネットインターフェイス）のためのプロトコルスタックを具現化し、又、ホスティングサービス２１０と通信し、そしてクライアント４６５内の全ての装置を構成する。又、これは、入力装置４６９とのインターフェイスを取り扱い、そして必要に応じて、「順方向エラー修正」で保護して、パケットをユーザコントローラデータと共にホスティングサービス２１０へ返送する。又、コントロールＣＰＵ４８３は、パケットトラフィックを監視する（例えば、パケットが失われるか遅延された場合、それらの到着にタイムスタンプも押す）。この情報は、ホスティングサービス２１０へ返送され、従って、ネットワーク接続を常時監視し、それに応じて何を送信するか調整することができる。フラッシュメモリ４７６は、最初に、製造時に、コントロールＣＰＵ４８３のコントロールプログラムがロードされると共に、特定のクライアント４６５ユニットにとって独特のシリアル番号もロードされる。このシリアル番号は、ホスティングサービス２１０がクライアント４６５ユニットを独特に識別できるようにする。
ブルーツースインターフェイス４８４は、クライアント４６５の内部にあるそのアンテナを通して入力装置４６９へワイヤレス通信する。
ビデオデコンプレッサ４８６は、ここに述べるビデオ解凍を具現化するように構成された短待ち時間のビデオデコンプレッサである。非常に多数のビデオ解凍装置が、既製品として、又はＦＰＧＡ又はカスタムＡＳＩＣへ一体化できる知的プロパティ（ＩＰ）設計として、存在する。Ｈ．２６４デコーダのためのＩＰを提供する１つの会社は、ＮＳＷオーストラリアのオーシャンロジックオブマンリー(Ocean Logic of Manly)である。ＩＰを使用する効果は、ここで使用する圧縮技術が圧縮規格に従わないことである。ある標準的なデコンプレッサは、ここに述べる圧縮技術を受け容れるように構成されるに充分なほど融通性があるが、あるものはそうではない。しかし、ＩＰでは、デコンプレッサを必要に応じて設計し直す上で完全な融通性がある。
ビデオデコンプレッサの出力は、ビデオ出力サブシステム４８７に結合され、これは、ビデオをＨＤＭＩインターフェイス４９０のビデオ出力に結合する。
オーディオ解凍サブシステム４８８は、入手可能な標準的オーディオデコンプレッサを使用して具現化されるか、又はＩＰとして具現化することもでき、或いはオーディオの解凍は、例えば、（Ｖｏｒｂｉｓ．ｃｏｍにおいて入手できる）Ｖｏｒｂｉｓオーディオデコンプレッサを具現化できるコントロールプロセッサ４８３内で具現化することもできる。
オーディオの解凍を具現化する装置は、オーディオ出力サブシステム４８９へ結合され、これは、オーディオをＨＤＭＩインターフェイス４９０のオーディオ出力へ結合する。
図４ｆは、クライアント４７５の内部アーキテクチャーの一実施形態を示す。明らかなように、このアーキテクチャーは、付加的なインターフェイスと、壁に差し込む電源アダプタからの任意の外部ＤＣ電力を除き、クライアント４６５と同じであり、その外部ＤＣ電力は、そのように使用される場合、イーサネットＰｏＥ４９７から到来する電力に取って代わる。クライアント４６５と共通の機能は、以下に説明を繰り返さず、付加的な機能を以下に説明する。
ＣＰＵ４８３は、付加的な装置と通信し、それを構成する。
ＷｉＦｉサブシステム４８２は、そのアンテナを通してイーサネット４９７への代替物としてワイヤレスインターネットアクセスを与える。ＷｉＦｉサブシステムは、カリフォルニア州サンタクララのアセロスコミュニケーションズ(Atheros Communications)を含めて幅広い製造者から入手できる。
ＵＳＢサブシステム４８５は、ワイヤードＵＳＢ入力装置４７９に対してブルーツース通信の代替物を与える。ＵＳＢサブシステムは、極めて標準的で、ＦＰＧＡ及びＡＳＩＣについて入手容易であり、且つビデオ解凍と同様に、他の機能を遂行する既製装置にしばしば内蔵される。
ビデオ出力サブシステム４８７は、クライアント４６５内よりも広範囲なビデオ出力を発生する。これは、ＨＤＭＩ４９０ビデオ出力を与えるのに加えて、ＤＶＩ−Ｉ４９１、Ｓ−ビデオ４９２及び複合ビデオ４９３を与える。又、ＤＶＩ−Ｉ４９１インターフェイスがデジタルビデオに対して使用されるときには、ディスプレイ能力４６４がディスプレイ装置からコントロールＣＰＵ４８３へ返送され、ディスプレイ装置４７８の能力をホスティングサービス２１０に通知できるようにする。ビデオ出力サブシステム４８７により与えられる全てのインターフェイスは、極めて標準的なインターフェイスであり、多数の形態で入手容易である。
オーディオ出力サブシステム４８９は、デジタルインターフェイス４９４（Ｓ／ＰＤＩＦ及び／又はＴｏｓｌｉｎｋ）を通してオーディオをデジタルで出力すると共に、ステレオアナログインターフェイス４９５を通してオーディオをアナログ形態で出力する。
往復待ち時間の分析
もちろん、以上の段落を理解するために、入力装置４２１を使用したユーザのアクションと、そのアクションの結果をディスプレイ装置４２０で見るときとの間の往復待ち時間は、７０−８０ｍｓ以下でなければならない。この待ち時間は、ユーザの家屋２１１内の入力装置４２１からホスティングサービス２１０へそしてユーザの家屋２１１へ戻って、ディスプレイ装置４２２へ至る経路における全てのファクタを考慮しなければならない。図４ｂは、信号が進行しなければならない種々のコンポーネント及びネットワークを示し、これらコンポーネント及びネットワークの上には、実際の具現化で予想できる待ち時間を列挙した時間線がある。図４ｂは、重要な経路ルーティングだけを示すように簡略化されていることに注意されたい。システムの他の特徴のために使用されるデータの他のルーティングは、以下で説明する。双頭矢印（例えば、矢印４５３）は、往復待ち時間を表し、単頭矢印（例えば、矢印４５７）は、片道待ち時間を表し、そして「〜」は、近似尺度を示す。列挙した待ち時間を達成できない実世界の状況があるが、米国内における多くのケースでは、ユーザの家屋２１１へのＤＳＬ及びケーブルモデム接続を使用し、次の段落で述べる環境においてこれら待ち時間を達成できることを指摘しなければならない。又、インターネットへのセルラーワイヤレス接続は、図示されたシステムにおいて確実に機能するが、ほとんどの現在のＵＳセルラーデータシステム（ＥＶＤＯのような）は、非常に長い待ち時間を被り、図４ｂに示す待ち時間を達成できないことにも注意されたい。しかしながら、これらの基礎的な原理は、このレベルの待ち時間を具現化できる将来のセルラー技術において具現化することができよう。更に、現在のＵＳセルラーデータシステムを経て被る待ち時間が、ユーザに気付くものであるが、ゲーム又はアプリケーションにとって許容できるようなゲーム及びアプリケーションシナリオ（例えば、チェスのような速いユーザ反応時間を要求しないゲーム）もある。
ユーザの家屋２１１における入力装置４２１からスタートして、ユーザが入力装置４２１を操作すると、ユーザコントロール信号がクライアント４１５へ送信され（これは、セットトップボックスのようなスタンドアローン装置でもよいし、或いはＰＣ又は移動装置のような別の装置で実行されるソフトウェア又はハードウェアでもよい）、そして（一実施形態ではＵＤＰフォーマットで）パケット化され、そのパケットには、ホスティングサービス２１０に到着するための行先アドレスが与えられる。又、パケットは、コントロール信号がどのユーザから到来するか指示する情報も含む。次いで、コントロール信号のパケット（１つ又は複数）は、ファイアウオール／ルーター／ＮＡＴ（ネットワークアドレストランスレーション）装置４４３を通してＷＡＮインターフェイス４４２へ転送される。ＷＡＮインターフェイス４４２は、ユーザのＩＳＰ（インターネットサービスプロバイダー）によりユーザの家屋２１１に与えられるインターフェイス装置である。ＷＡＮインターフェイス４４２は、ケーブル又はＤＳＬモデム、ＷｉＭａｘトランシーバー、ファイバートランシーバー、セルラーデータインターフェイス、インターネットプロトコル・オーバー・パワーラインインターフェイス、又はインターネットへの多数のインターフェイスの他のものでよい。更に、ファイアウオール／ルーター／ＮＡＴ装置４４３（及び潜在的にＷＡＮインターフェイス４４２）は、クライアント４１５に一体化されてもよい。その一例は、家庭又はオフィスクライアント４１５の機能を具現化するためのソフトウェアと、ある規格（例えば、８０２．１１ｇ）によりインターネットへワイヤレスでルーティング及び接続する手段とを含む移動電話である。
ＷＡＮインターフェイス４４２は、次いで、コントロール信号をユーザのインターネットサービスプロバイダー（ＩＳＰ）のための「存在点(point of presence)」４４１と称されるものへルーティングし、これは、ユーザの家屋２１１に接続されたＷＡＮトランスポートと、一般的インターネット又はプライベートネットワークとの間のインターフェイスをなすファシリティである。存在点の特性は、提供されるインターネットサービスの性質に基づいて変化する。ＤＳＬの場合、これは、典型的に、ＤＳＬＡＭが配置される電話会社の中央オフィスとなる。ケーブルモデムの場合、これは、典型的に、ケーブルマルチシステムオペレータ（ＭＳＯ）ヘッドエンドとなる。セルラーシステムの場合、これは、典型的に、セルラータワーに関連したコントロールルームとなる。しかし、存在点の性質が何であれ、これは、コントロール信号パケット（１つ又は複数）を一般的インターネット４１０へルーティングする。コントロール信号パケット（１つ又は複数）は、次いで、最も多くはファイバトランシーバーインターフェイスであるものを通して、ホスティングサービス２１０へのＷＡＮインターフェイス４４１へルーティングされる。ＷＡＮ４４１は、次いで、コントロール信号パケットをルーティングロジック４０９（これは、イーサネットスイッチ及びルーティングサーバーを含めて、多数の異なる仕方で具現化される）へルーティングし、これは、ユーザのアドレスを評価し、そしてコントロール信号を所与のユーザに対する正しいサーバー４０２へルーティングする。
サーバー４０２は、次いで、コントロール信号を、サーバー４０２で実行されるゲーム又はアプリケーションソフトウェアに対する入力として取り上げ、そしてそのコントロール信号を使用して、ゲーム又はアプリケーションの次のフレームを処理する。次のフレームが発生されると、サーバー４０２からビデオコンプレッサ４０４へビデオ及びオーディオが出力される。ビデオ及びオーディオは、サーバー４０２から種々の手段を経てコンプレッサ４０４へ出力される。先ず、コンプレッサ４０４は、サーバー４０２に組み込むことができ、従って、圧縮をサーバー４０２内でローカルに具現化することができる。又は、ビデオ及び／又はオーディオは、パケット化形態で、イーサネット接続のようなネットワーク接続を経て、サーバー４０２とビデオコンプレッサ４０４との間のプライベートネットワークであるネットワークへ、又はＳＡＮ４０３のような共有ネットワークを通して、出力することができる。或いは、ビデオは、サーバー４０２から、ＤＶＩ又はＶＧＡコネクタのようなビデオ出力コネクタを通して出力され、次いで、ビデオコンプレッサ４０４により捕獲されてもよい。又、オーディオは、サーバー４０２からデジタルオーディオとして（例えば、ＴＯＳＬＩＮＫ又はＳ／ＰＤＩＦコネクタを経て）出力されるか又はアナログオーディオとして出力されてもよく、アナログオーディオは、ビデオコンプレッサ４０４内のオーディオ圧縮ロジックによりデジタル化されエンコードされる。
ビデオコンプレッサ４０４は、ビデオフレーム、及びサーバー４０２からのそのフレーム時間中に発生されたオーディオを捕獲すると、以下に述べる技術を使用してビデオ及びオーディオを圧縮する。ビデオ及びオーディオが圧縮されると、アドレスと共にパケット化されて、ユーザのクライアント４１５へ返送され、ＷＡＮインターフェイス４４１へルーティングされ、このＷＡＮインターフェイスは、ビデオ及びオーディオパケットを一般的なインターネット４１０を経てルーティングし、このインターネットは、ビデオ及びオーディオパケットをユーザのＩＳＰ存在点４４１へルーティングし、この存在点は、ビデオ及びオーディオパケットをユーザの家屋のＷＡＮインターフェイス４４２へルーティングし、このインターフェイスは、ビデオ及びオーディオパケットをファイアウオール／ルーター／ＮＡＴ装置４４３へルーティングし、次いで、この装置は、ビデオ及びオーディオパケットをクライアント４１５へルーティングする。
クライアント４１５は、ビデオ及びオーディオを解凍し、次いで、ビデオをディスプレイ装置４２２（又はクライアントの内蔵ディスプレイ装置）に表示すると共に、オーディオをディスプレイ装置４２２又は個別の増幅器／スピーカへ或いはクライアントに内蔵された増幅器／スピーカへ送信する。
上述した全プロセスに知覚的に遅れがないことをユーザが認知するためには、往復遅延が７０又は８０ｍｓ未満である必要がある。前記往復経路における待ち時間遅延のあるものは、ホスティングサービス２１０及び／又はユーザのコントロールのもとにあり、他のものは、そうではない。それでも、非常に多数の実世界のシナリオの分析及びテストに基づき、おおよその測定値は次のようになる。
コントロール信号４５１を送信するための片道送信時間は、典型的に、１ｍｓ未満であり、ユーザの家屋４５２を通る往復ルーティングは、典型的に、イーサネット上に入手容易な消費者グレードのファイアウオール／ルーター／ＮＡＴスイッチを使用して約１ｍｓで達成される。ユーザＩＳＰは、その往復遅延４５３が広く変化するが、ＤＳＬ及びケーブルモデムプロバイダーでは、典型的に、１０ないし２５ｍｓである。一般的なインターネット４１０における往復待ち時間は、トラフィックがどのようにルーティングされるか及びルートに欠陥があるかどうか（これらの問題は以下で述べる）に基づいて大きく変化するが、典型的に、一般的なインターネットは、非常に最適なルートを与え、そして待ち時間は、行先までの距離が与えられると、主として光ファイバを通る光の速度によって決定される。以下に更に述べるように、ユーザの家屋２１１から離れてホスティングサービス２１０を発することが予想される最も遠いおおよその距離として１０００マイルを確立した。１０００マイル（往復２０００マイル）では、インターネットを通る信号の実際の通過時間は、約２２ｍｓである。ホスティングサービス２１０へのＷＡＮインターフェイス４４１は、典型的に、待ち時間を無視できる商業的グレードファイバの高速インターフェイスである。従って、一般的インターネットの待ち時間４５４は、典型的に、１ないし１０ｍｓである。ホスティングサービス２１０を通る片道ルーティング４５５の待ち時間は、１ｍｓ未満である。サーバー４０２は、典型的に、ゲーム又はアプリケーションのための新たなフレームを１フレーム時間（６０ｆｐｓでは１６．７ｍｓである）未満で計算し、従って、使用するために合理的な最大片道待ち時間は、１６ｍｓである。ここに述べるビデオ圧縮及びオーディオ圧縮アルゴリズムの最適なハードウェア具現化では、圧縮４５７を１ｍｓで完了することができる。あまり最適でない形態では、圧縮に６ｍｓ程度を要する（もちろん、もっと最適でない形態は、更に長い時間を要するが、このような具現化は、往復の全待ち時間に影響を及ぼし、７０−８０ｍｓの待ち時間目標を維持するには他の待ち時間を短縮する必要がある（例えば、一般的なインターネットを通る許容距離を短縮することができる））。インターネット４５４、ユーザＩＳＰ４５３及びユーザ家屋ルーティング４５２の往復待ち時間は、既に考慮されており、従って、残りは、ビデオ解凍４５８の待ち時間であり、これは、ビデオ解凍４５８が専用のハードウェアで具現化されるか、又は（ＰＣ又は移動装置のような）クライアント装置４１５においてソフトウェアで具現化されるかに基づいて、又、ディスプレイのサイズ及び解凍ＣＰＵの性能に基づいて、変化する。典型的に、解凍４５８は、１ないし８ｍｓを要する。
従って、実際上見られる最悪のケースの待ち時間を全部加算することにより、図４ａに示すシステムのユーザにより経験されると予想できる最悪のケースの往復待ち時間を決定することができる。それらは、１＋１＋２５＋２２＋１＋１６＋６＋８＝８０ｍｓである。そして、正に、実際に（以下に述べる注意と共に）、これは、図４ａに示すシステムのプロートタイプバージョンを使用し、既製品のＷｉｎｄｏｗｓ ＰＣをクライアント装置として及び米国内の家庭用ＤＳＬ及びケーブルモデム接続を使用して分かったおおよその往復待ち時間である。もちろん、最悪のケースより良好のシナリオでは、非常に短い待ち時間が得られるが、それは、広く使用される商業的サービスの開発に依存することができない。
一般的なインターネットを経て図４ｂに列挙する待ち時間を得るには、図４ａのビデオコンプレッサ４０４及びクライアント４１５のビデオデコンプレッサ４１２が、非常に特定の特性をもつパケットストリームを発生し、ホスティングサービス２１０からディスプレイ装置４２２までの全経路を経て発生されるパケットシーケンスが、遅延や過剰なパケットロスを受けず、且つ特に、ＷＡＮインターフェイス４４２及びファイアウオール／ルーター／ＮＡＴ４４３を通るユーザのインターネット接続を経てユーザに利用できる帯域巾の制約内に一貫して入るようにする必要がある。更に、ビデオコンプレッサは、通常のインターネット及びネットワーク送信において生じる不可避なパケットロス及びパケット並べ替えを許容できるに充分なほど頑丈なパケットストリームを生成しなければならない。
短待ち時間のビデオ圧縮
前記目標を達成するために、一実施形態は、待ち時間を減少し且つビデオを送信するためのピーク帯域巾要件を緩和するというビデオ圧縮の新規な解決策をとる。これらの実施形態を説明する前に、図５及び図６ａ−ｂを参照して、現在のビデオ圧縮技術の分析を行う。もちろん、これらの技術は、これらの技術で要求されるデータレートを取り扱うに充分な帯域巾がユーザに与えられる場合には、基礎的な原理に基づいて使用することができる。オーディオの圧縮は、ビデオの圧縮と同時に且つ同期して具現化されることを述べる以外、ここでは扱わないことに注意されたい。このシステムの要件を満足する従来のオーディオ圧縮技術が存在する。
図５は、ビデオを圧縮するための１つの特定の従来技術であって、特定の圧縮アルゴリズムを使用する圧縮ロジック５２０により各個々のビデオフレーム５０１−５０３を圧縮して、一連の圧縮されたフレーム５１１−５１３を発生する従来技術を示している。この技術の一実施形態は、「モーションＪＰＥＧ」であり、各フレームが、離散的コサイン変換（ＤＣＴ）に基づき、ジョイント・ピクチャー・エクスパート・グループ（ＪＰＥＧ）圧縮アルゴリズムに従って圧縮されるというものである。種々の異なる形式の圧縮アルゴリズムを使用してもよいが、これらの基礎的な原理（例えば、ＪＰＥＧ−２０００のようなウェーブレットベースの圧縮アルゴリズム）に依然適合させるようにする。
この形式の圧縮の１つの問題は、各フレームのデータレートを下げるが、連続フレーム間の類似性を利用してビデオストリーム全体のデータレートを下げるものでないことである。例えば、図５に示すように、映像の所与のクオリティに対し、６４０ｘ４８０ｘ２４ビット／ピクセル＝６４０＊４８０＊２４／８／１０２４＝９００キロバイト／フレーム（ＫＢ／フレーム）のフレームレートを仮定すれば、モーションＪＰＥＧは、１０のファクタでストリームを圧縮するだけであり、９０ＫＢ／フレームのデータストリームを生じさせる。６０フレーム／秒では、これは、９０ＫＢ＊８ビット＊６０フレーム／秒＝４２．２Ｍｂｐｓのチャンネル帯域巾を要求し、これは、今日の米国内のほぼ全ての家庭用インターネット接続に対して遥かに広い帯域巾となり、且つ多数のオフィス用インターネット接続に対しても非常に広い帯域巾となる。実際に、このような広い帯域巾で一定のデータストリームを要求し、且つオフィスＬＡＮ環境においても１人のユーザにしか役立たないとすれば、１００ＭｂｐｓのイーサネットＬＡＮ帯域巾の大きな割合を消費し、ＬＡＮをサポートするイーサネットスイッチに大きな負担を掛けることになる。従って、動画ビデオに対する圧縮は、（以下に述べるような）他の圧縮技術と比べたときに、非効率的である。更に、ロッシー圧縮アルゴリズムを使用するＪＰＥＧ及びＪＰＥＧ−２０００のような単一フレーム圧縮アルゴリズムは、静止映像では気付かない圧縮欠陥（例えば、シーンにおける密集した葉の中の欠陥は、その密集した葉がどのように見えるべきか目にとって厳密に分からないので、欠陥として見えないことがある）を生じる。しかし、シーンが動くと、欠陥が静止映像では気付かないシーンのエリアにあるにも関わらず、欠陥がフレームごとに変化することが目で検出されるので、欠陥が目立つようになる。その結果、余白的アナログＴＶ受信中に見える「スノー」ノイズに見掛けが類似した「バックグランドノイズ」がフレームのシーケンスにおいて知覚される。もちろん、この形式の圧縮は、ここに述べる幾つかの実施形態で依然使用できるが、一般的に述べると、シーンにおけるバックグランドノイズを回避するため、所与の知覚上のクオリティに対して高いデータレート（即ち、低い圧縮比）が要求される。
Ｈ．２６４、又はＷｉｎｄｏｗｓ ＭｅｄｉａＶＣ９、ＭＰＥＧ２及びＭＰＥＧ４のような他の形式の圧縮は、全て、連続するフレーム間の類似性を利用しているので、ビデオストリームの圧縮がより効率的である。これらの技術は、全て、ビデオを圧縮するための同じ一般的技術に依存している。従って、Ｈ．２６４規格について述べるが、他の種々の圧縮アルゴリズムにも同じ一般的原理が適用される。圧縮Ｈ．２６４のためのｘ２６４オープンソースソフトウェアライブラリー、及び解凍Ｈ．２６４のためのＦＦｍｐｅｇオープンソースソフトウェアライブラリーを含めて、非常に多数のＨ．２６４コンプレッサ及びデコンプレッサを利用することができる。
図６ａ及び６ｂは、従来の圧縮技術を例示するもので、一連の非圧縮のビデオフレーム５０１−５０３、５５９−５６１が、圧縮ロジック６２０により、一連の「Ｉフレーム」６１１、６７１、「Ｐフレーム」６１２−６１３、及び「Ｂフレーム」６７０へと圧縮される。図６ａの縦軸は、一般的に、エンコードされて得られる各フレームのサイズを表す（が、フレームは適切なスケールで描かれていない）。上述したように、Ｉフレーム、Ｂフレーム及びＰフレームを使用するビデオコーディングは、当業者に良く知られている。簡単に述べると、Ｉフレーム６１１は、完全非圧縮のフレーム５０１のＤＣＴベース圧縮である（上述した圧縮されたＪＰＥＧ映像と同様）。Ｐフレーム６１２−６１３は、一般的に、Ｉフレーム６１１よりサイズが著しく小さい。というのは、手前のＩフレーム又はＰフレームのデータの利点を取り入れるからであり、即ち手前のＩフレーム又はＰフレーム間の変化を示すデータを含むからである。Ｂフレーム６７０は、Ｐフレームと同様であるが、Ｂフレームは、後続する基準フレームにおけるフレームと、先行する基準フレームにおける潜在的なフレームとを使用する。
以下の説明では、望ましいフレームレートが６０フレーム／秒であり、各Ｉフレームが約１６０Ｋｂであり、平均Ｐフレーム及びＢフレームが１６Ｋｂであり、そして毎秒新たなＩフレームが発生されると仮定する。この１組のパラメータで、平均データレートは、１６０Ｋｂ＋１６Ｋｂ＊５９＝１．１Ｍｂｐｓとなる。このデータレートは、家庭及びオフィスへの多くの現在のブロードバンドインターネット接続に対する最大データレート内に充分入る。又、この技術は、イントラフレーム専用のエンコーディングからバックグランドノイズの問題を回避する傾向がある。というのは、Ｐ及びＢフレームは、フレーム間の差を追跡し、圧縮欠陥がフレームごとに現れたり消えたりする傾向がなく、前記バックグランドノイズの問題を緩和するからである。
前記形式の圧縮に伴う１つの問題は、平均データレートが比較的低い（例えば、１．１Ｍｂｐｓ）が、単一のＩフレームが送信に多数のフレーム分の時間を要することである。例えば、従来技術を使用すると、６０フレームごとに１６０ＫｂｐｓのＩフレームの状態で１．１Ｍｂｐｓでビデオをストリーミングするのに、典型的に、２．２Ｍｂｐｓのネットワーク接続（例えば、図３ａから２．２Ｍｂｐｓピークの利用可能な最大データレート３０２をもつＤＳＬ又はケーブルモデム）で充分である。これは、ビデオを解凍するまで解凍キューに１秒のビデオを入れておくことにより達成される。１秒で、１．１Ｍｂのデータが送信され、これは、利用可能なデータレートが周期的に５０％程度下がると仮定しても、２．２Ｍｂｐｓの利用可能な最大データレートによって容易に受け容れられる。不都合なことに、この従来の解決策は、１秒のビデオバッファが受信器にあるので、ビデオについて１秒の待ち時間を生じさせる。このような遅延は、多数の従来の用途（例えば、リニアビデオの再生）では充分であるが、７０−８０ｍｓを越える待ち時間を許容できない高速アクションのビデオゲームに対しては遥かに長い待ち時間である。
１秒のビデオバッファを排除する試みがなされたが、高速アクションビデオゲームのための充分な待ち時間短縮が得られていない。一例として、上述したＢフレームの使用は、Ｉフレームに先行する全てのＢフレーム及びＩフレームの受信を必要とする。ＰフレームとＢフレームとの間で５９個の非Ｉフレームがおおよそ分割されると仮定すれば、少なくとも２９個のＢフレームがあり、そしてＢフレームを表示できるまでにＩフレームが受信される。従って、チャンネルの利用可能な帯域巾に関わらず、各々１／６０秒巾の２９＋１＝３０フレームの遅延、即ち５００ｍｓの待ち時間が必要になる。明らかに、これは、遥かに長過ぎる。
従って、別の解決策は、Ｂフレームを排除し、そしてＩ及びＰフレームだけを使用することである。（その１つの結果として、所与のクオリティレベルに対してデータレートが増加することになるが、この例における一貫性のために、各Ｉフレームが１６０Ｋｂであり、平均Ｐフレームが１６Ｋｂのサイズであり、従って、データレートが依然１．１Ｍｂｐｓであると仮定し続ける。）この解決策は、Ｂフレームにより導入される不可避な待ち時間を排除する。というのは、各Ｐフレームのデコーディングが、以前に受信したフレームに依存するだけだからである。この解決策に伴う問題は、Ｉフレームが平均Ｐフレームより非常に大きいために、ほとんどの家庭及び多くのオフィスにおいて典型的である狭帯域巾チャンネルでは、Ｉフレームの送信が実質的な待ち時間を増大することである。これが図６ｂに示されている。Ｉフレームに要求されるピークデータレート６２３が、利用可能な最大データレート６２２を（及び定格最大データレート６２１も）遥かに越えるＩフレームを除いて、ビデオストリームのデータレート６２４は、利用可能な最大データレート６２１より低い。Ｐフレームにより要求されるデータレートは、利用可能な最大データレート未満である。２．２Ｍｂｐｓの利用可能な最大データレートのピークがその２．２Ｍｂｐｓのピークレートに着実に保たれるとしても、Ｉフレームを送信するのに１６０Ｋｂ／２．２Ｍｂ＝７１ｍｓを要し、利用可能な最大データレート６２２が５０％（１．１Ｍｂｐｓ）下がった場合には、Ｉフレームを送信するのに１４２ｍｓを要する。従って、Ｉフレームを送信する際の待ち時間は、７１から１４２ｍｓのどこかに入る。この待ち時間は、図４ｂに示された待ち時間に加算され、最悪の場合、これが７０ｍｓに加算され、従って、これは、ユーザが入力装置４２１を操作する時点から、ディスプレイ装置４２２に映像が現れるまで、１４１ないし２２２ｍｓの合計往復待ち時間を生じ、遥かに高いものとなる。そして、利用可能な最大データレートが２．２Ｍｂｐｓより下がる場合には、待ち時間は更に増大する。
又、一般的に、ピークデータレート６２３でＩＳＰを「ジャミング」させて、利用可能なデータレート６２２を遥かに越える厳しい結果が生じることにも注意されたい。異なるＩＳＰの装置は、異なる挙動をするが、利用可能なデータレート６２２より非常に高いデータレートでパケットを受け取るときには、次の挙動がＤＳＬ及びケーブルモデムＩＳＰの間で極めて一般的となる。（ａ）パケットをキューイングすることでパケットを遅延させ（待ち時間を導入し）、（ｂ）パケットの幾つか又は全部をドロップさせ、（ｃ）ある期間接続をディスエイブルする（おそらく、ＩＳＰに関するものであるから、「サービス拒絶」攻撃のような悪意のある攻撃である）。従って、図６ｂに示すような特性で全データレートにおいてパケットストリームを送信することは、実現可能な選択肢ではない。ピーク６２３は、ホスティングサービス２１０においてキューイングされ、そして利用可能な最大データレートより低いデータレートで送信され、上述した許容できない待ち時間を導入することがある。
更に、図６ｂに示すビデオストリームデータレートシーケンス６２４は、非常に「従順な」ビデオストリームデータレートシーケンスであり、そして著しく変化せず且つほとんど動きのないビデオシーケンスからビデオを圧縮することにより生じると予想される種類のデータレートシーケンスである（例えば、カメラが固定位置にあってほとんど動かず、そしてシーン内のオブジェクト、例えば、椅子に座って話している人がほとんど動きを示さないビデオ遠隔会議において一般的であるように）。
図６ｃに示すビデオストリームデータレートシーケンス６３４は、動画又はビデオゲーム或いはあるアプリケーションソフトウェアにおいて発生されるような、遥かに多いアクションを伴うビデオから見えると予想されるものに対して典型的なシーケンスである。Ｉフレームピーク６３３に加えて、極めて大きく且つ多くの場合に利用可能な最大データレートを越える６３５及び６３６のようなＰフレームピークもあることに注意されたい。これらのＰフレームピークは、Ｉフレームピークと同程度に大きいことはあまりないが、全データレートでチャンネルにより搬送されるには遥かに大き過ぎるもので、又、Ｉフレームピークと同様に、Ｐフレームピークは、ゆっくり送信されねばならない（従って、待ち時間が増大する）。
広帯域巾チャンネル（例えば、１００ＭｂｐｓのＬＡＮ、又は広帯域巾１００Ｍｂｐｓのプライベート接続））において、ネットワークは、Ｉフレームピーク６３３又はＰフレームピーク６３６のような大きなピークを許容することができ、そして原理的に、短い待ち時間を維持することができる。しかし、このようなネットワークは、多くの場合、大勢のユーザ間に共有され（例えば、オフィス環境において）、そしてこのような「ピーク」データは、特に、ネットワークトラフィックがプライベート共有接続へルーティングされた場合に（例えば、リモートデータセンターからオフィスへ）、ＬＡＮの性能に影響を及ぼす。先ず、この例は、６０ｆｐｓにおいて６４０ｘ４８０ピクセルの比較的低解像度のビデオストリームであることを銘記されたい。６０ｆｐｓにおいて１９２０ｘ１０８０のＨＤＴＶストリームは、近代的なコンピュータ及びディスプレイによって容易に取り扱われ、そして６０ｆｐｓにおいて２５６０ｘ１４４０解像度のディスプレイが益々入手可能になってきている（例えば、アップル社の３０”ディスプレイ）。又、６０ｆｐｓにおいて１９２０ｘ１０８０の高アクションビデオシーケンスは、適度なクオリティレベルに対してＨ．２６４圧縮を使用して４．５Ｍｂｐｓを必要とする。公称データレートの１０倍のＩフレームピークを仮定すれば、それは４５Ｍｂｐｓ以下のピークを生じるが、まだかなりのＰフレームピークがある。大勢のユーザが同じ１００Ｍｂｐｓのネットワーク（例えば、オフィスとデータセンターとの間のプライベートなネットワーク接続）を経てビデオストリームを受信する場合、大勢のユーザのビデオストリームからのピークがどのように整列して、ネットワークの帯域巾を圧倒し、そしてネットワーク上のユーザをサポートするスイッチのバックプレーンの帯域巾を潜在的に圧倒するか容易に見ることができる。ギガビットのイーサネットネットワークの場合でも、充分なユーザが充分なピークを一度に整列させる場合は、ネットワーク又はネットワークスイッチを圧倒することができる。そして、２５６０ｘ１４４０解像度のビデオがより平凡なものになると、平均ビデオストリームデータレートが９．５Ｍｂｐｓとなり、おそらく、９５Ｍｂｐｓのピークデータレートを生じさせる。言うまでもなく、データセンターとオフィスとの間の１００Ｍｂｐｓの接続（これは、今日、非常に高速な接続である）は、単一ユーザからのピークトラフィックによって完全に沈没される。従って、ＬＡＮ及びプライベートネットワーク接続が、ピークストリーミングビデオを更に許容できるとしても、高いピークを伴うストリーミングビデオは、望ましいものではなく、オフィスのＩＴ部門による特殊なプランニング及び適応を要求する。
もちろん、標準的なリニアビデオアプリケーションの場合、これらの事柄は、問題ではない。というのは、データレートが送信点において「平滑化」され、各フレームのデータが利用可能な最大データレート６２２より低く、そしてクライアントのバッファが、Ｉ、Ｐ及びＢフレームのシーケンスを、それらが解凍されるまで記憶するからである。従って、ネットワークにわたるデータレートは、ビデオストリームの平均データレートの近くに保たれる。不都合なことに、これは、Ｂフレームが使用されない場合でも待ち時間を導入し、即ち高速応答時間を要求するビデオゲーム及びアプリケーションのような短待ち時間アプリケーションについては受け容れられない。
高いピークを有するビデオストリームを軽減する１つの従来の解決策は、「コンスタントビットレート」（ＣＢＲ）エンコーディングとしばしば称される技術を使用することである。ＣＢＲという語は、全てのフレームが同じビットレート（即ち、サイズ）を有するように圧縮されることを意味すると思われるが、それが通常指すのは、ある数のフレーム（ここでは、１フレーム）にわたり最大ビットレートが許されるという圧縮パラダイムである。例えば、図６ｃのケースでは、ビットレートを、定格最大データレート６２１の例えば７０％に制限するエンコーディングにＣＢＲ制約が適用される場合に、圧縮アルゴリズムは、定格最大データレート６２１の７０％以上を使用して通常圧縮されるフレームが少ないビットで圧縮されるように、各フレームの圧縮を制限する。その結果、所与のクオリティレベルを維持するために通常より多くのビットを要求するフレームがビットの「欠乏」となり、これらフレームの映像クオリティは、定格最大データレート６２１の７０％以上のビットを要求しない他のフレームの場合より悪くなる。この解決策は、（ａ）予想される動き又はシーンの変化があまりなく、且つ（ｂ）ユーザが周期的なクオリティ低下を受け容れできるようなある形式の圧縮ビデオに対して、受け容れられる結果を生じさせることができる。ＣＢＲに適したアプリケーションの良い例は、ビデオ遠隔会議である。というのは、ピークが僅かしかなく、且つクオリティが短時間低下した場合に（例えば、カメラがパンして、著しいシーンの動き及び大きなピークを生じ、そのパン中に、高クオリティ映像圧縮に充分なビットがなく、映像クオリティの低下を招く場合に）、ほとんどのユーザにそれが受け容れられるからである。不都合なことに、ＣＢＲは、非常に複雑な又は多くの動きのあるシーンを有し、及び／又は適度な一定レベルのクオリティが要求される他の多数のアプリケーションにはあまり適していない。
一実施形態に使用される短待ち時間の圧縮ロジック４０４は、高いクオリティを維持しながら短待ち時間の圧縮ビデオをストリーミングすることに伴うある範囲の問題に対処するために多数の異なる技術を使用する。第１に、短待ち時間の圧縮ロジック４０４は、Ｉフレーム及びＰフレームしか発生せず、各Ｂフレームをデコードするために多数のフレーム分の時間を待機する必要性を緩和する。更に、図７ａに示すように、一実施形態では、短待ち時間の圧縮ロジック４０４は、各非圧縮フレーム７０１−７６０を一連の「タイル」へと細分化し、そして各タイルをＩフレーム又はＰフレームのいずれかとして個々にエンコードする。圧縮されたＩフレーム及びＰフレームのグループは、ここでは、「Ｒフレーム」７１１−７７０と称される。図７ａに示す特定例では、各非圧縮フレームが、１６タイルの４ｘ４マトリクスへと細分化される。しかしながら、これらの基礎的な原理は、特定の細分化スキムに限定されない。
一実施形態では、短待ち時間の圧縮ロジック４０４は、ビデオフレームを多数のタイルに分割し、そして各フレームからの１つのタイルをＩフレームとしてエンコード（即ち、圧縮）し（即ち、タイルは、フル映像サイズの１／１６の個別ビデオフレームであるかのように圧縮され、この「ミニ」フレームに使用される圧縮は、Ｉフレーム圧縮である）、そして残りのタイルをＰフレームとしてエンコード（即ち、圧縮）する（即ち、１／１６の各「ミニ」フレームに使用される圧縮は、Ｐフレーム圧縮である）。Ｉフレーム及びＰフレームとして圧縮されるタイルは、各々、「Ｉタイル」及び「Ｐタイル」と称される。各連続するビデオフレームでは、Ｉタイルとしてエンコードされるべきタイルが変化される。従って、所与のフレーム時間では、ビデオフレーム内のタイルのうちの１つのタイルだけがＩタイルであり、そして残りのタイルがＰタイルである。例えば、図７ａでは、非圧縮フレーム７０１のタイル０がＩタイルＩ0としてエンコードされ、そして残りの１−１５タイルがＰタイルＰ1−Ｐ15としてエンコードされ、Ｒフレーム７１１を形成する。次の非圧縮ビデオフレーム７０２では、非圧縮フレーム７０１のタイル１がＩタイルＩ1としてエンコードされ、そして残りのタイル０及び２から１５がＰタイルＰ0及びＰ2からＰ15としてエンコードされ、Ｒフレーム７１２を形成する。従って、タイルとしてＩタイル及びＰタイルは、連続するフレームにわたり時間的に次々にインターリーブされる。このプロセスは、マトリクス内の最後のタイルがＩタイル（即ち、Ｉ15）としてエンコードされてＲタイル７７０が発生されるまで続く。次いで、このプロセスが再開されて、フレーム７１１のような別のＲフレームを発生する（即ち、タイル０に対してＩタイルをエンコードし、等々）。図７ａには示されていないが、一実施形態では、Ｒフレームのビデオシーケンスのうちの第１のＲフレームがＩタイルしか含まない（即ち、その後のＰフレームが、動きを計算するための基準映像データを有するように）。或いは又、一実施形態では、スタートアップシーケンスが、通常と同じＩタイルパターンを使用するが、Ｉタイルでまだエンコードされていないタイルに対してＰタイルを含まない。換言すれば、あるタイルは、第１のＩタイルが到着するまでデータでエンコードされず、従って、以下に詳細に述べる図９ａのビデオストリームデータレート９３４におけるスタートアップピークを回避する。更に、以下に述べるように、これらの基礎的な原理に依然適合しつつ、タイルに対して種々の異なるサイズ及び形状を使用することができる。
クライアント４１５で実行されるビデオ解凍ロジック４１２は、各タイルを、小さなＩ及びＰフレームの個別のビデオシーケンスであるかのように解凍し、次いで、各タイルをフレームバッファドライブディスプレイ装置４２２へレンダリングする。例えば、Ｒフレーム７１１ないし７７０からのＩ0及びＰ0を使用して、ビデオ映像のタイル０を解凍し、レンダリングする。同様に、Ｒフレーム７１１ないし７７０からのＩ1及びＰ1を使用して、タイル１を再構成し、等々となる。上述したように、Ｉフレーム及びＰフレームの解凍は、良く知られた技術であり、Ｉタイル及びＰタイルの解凍は、クライアント４１５で実行されるビデオ解凍の複数のインスタンスを得ることにより遂行することができる。乗算プロセスは、クライアント４１５の計算負担を増大すると思われるが、実際には、そうではない。というのは、タイルそれ自体は、付加的なプロセスの数に対し比例的に小さく、従って、表示されるピクセルの数は、１つのプロセスがあって従来のフルサイズのＩ及びＰフレームを使用する場合と同じだからである。
このＲフレーム技術は、図６ｂ及び６ｃに示したＩフレームに典型的に関連した帯域巾ピークを著しく軽減する。というのは、所与のフレームが、大抵は、Ｉフレームより典型的に小さなＰフレームで作られるからである。例えば、典型的なＩフレームが１６０Ｋｂであると再び仮定すれば、図７ａに示す各フレームのＩタイルは、この量のほぼ１／１６即ち１０Ｋｂとなる。同様に、典型的なＰフレームが１６Ｋｂであると仮定すれば、図７ａに示す各タイルのＰフレームは、ほぼ１Ｋｂとなる。最終の結果として、ほぼ１０Ｋｂ＋１５＊１Ｋｂ＝２５ＫｂのＲフレームとなる。従って、各６０フレームシーケンスは、２５Ｋｂ＊６０＝１．５Ｍｂｐｓとなる。従って、６０フレーム／秒では、これは、１．５Ｍｂｐｓの帯域巾を維持することのできるチャンネルを要求するが、Ｉタイルのために相当に低いピークが６０フレームインターバル全体にわたって分布される。
Ｉフレーム及びＰフレームに対して同じデータレートを仮定した先の例では、平均データレートが１．１Ｍｂｐｓであったことに注意されたい。これは、先の例では、新たなＩフレームが６０フレームの時間ごとに一度しか導入されず、一方、この例では、１６フレームの時間、ひいては、Ｉフレームに等しい時間でＩフレームサイクルを作り上げる１６個のタイルが１６フレームの時間ごとに導入され、著しく高い平均データレートとなるからである。実際に、より頻繁にＩフレームを導入しても、データレートを直線的に高めることはない。これは、Ｐフレーム（又はＰタイル）が主として手前のフレームから次のフレームへの相違をエンコードするという事実のためである。従って、手前のフレームが次のフレームにかなり類似している場合には、Ｐフレームが非常に小さくなり、一方、手前のフレームが次のフレームとかなり相違がある場合には、Ｐフレームが非常に大きくなる。しかし、Ｐフレームは、主として、実際のフレームではなく、手前のフレームから導出されるので、それにより生じるエンコードされたフレームは、充分なビット数でＩフレームより大きなエラー（例えば、視覚欠陥）を含むことができる。そして、１つのＰフレームに別のＰフレームが続くときには、エラーの蓄積が生じ、長いシーケンスのＰフレームがあるときには悪化する。ここで、精巧なビデオコンプレッサは、一連のＰフレームの後に映像のクオリティが低下することを検出し、必要に応じて、より多くのビットをその後続Ｐフレームに割り当てて、クオリティを上げるか、又はそれが最も効率的なアクションのコースである場合には、ＰフレームをＩフレームに置き換える。従って、長いシーケンスのＰフレーム（例えば、上述した例のように５９個のＰフレーム）が使用されるとき、特に、シーンが多大な複雑さ及び／又は動きを有するときには、典型的に、ＰフレームがＩフレームから更に離れるにつれて、より多くのビットがＰフレームに必要とされる。
或いは、Ｐフレームを逆の視点から見ると、Ｉフレームに接近して続くＰフレームは、Ｉフレームから更に離れたＰフレームよりビットを必要としない傾向がある。従って、図７ａに示す例では、先行するＩフレームから１５フレーム以上離れたＰフレームはなく、一方、先の例では、Ｐフレームは、Ｉフレームから５９フレーム離れることができる。従って、より頻繁にＩフレームがあると、Ｐフレームは、より小さくなる。もちろん、厳密な相対的サイズは、ビデオストリームの性質に基づいて変化するが、図７ａの例では、Ｉタイルが１０Ｋｂである場合、Ｐタイルは、平均で、０．７５Ｋｂのみのサイズとなり、１０Ｋｂ＋１５＊０．７５Ｋｂ＝２１．２５Ｋｂとなるか、又は６０フレーム／秒では、データレートは、２１．２５Ｋｂ＊６０＝１．３Ｍｂｐｓとなり、又はＩフレームの後に５９個のＰフレームが続く１．１Ｍｂｐｓのストリームより約１６％高いデータレートとなる。この場合も、ビデオ圧縮に対するこれら２つの解決策間の相対的な結果は、ビデオシーケンスに基づいて変化するが、典型的に、Ｒフレームを使用すると、Ｉ／Ｐフレームシーケンスを使用する場合より、所与のクオリティレベルに対して約２０％多くのビットを要求することが実験で分かった。しかし、当然、Ｒフレームは、ピークを劇的に減少させ、Ｉ／Ｐフレームシーケンスより遥かに短い待ち時間でビデオシーケンスを使用可能にする。
Ｒフレームは、ビデオシーケンスの性質、チャンネルの信頼性、及び利用できるデータレートに基づいて、種々の異なる仕方で構成することができる。別の実施形態では、４ｘ４構成の１６とは異なる数のタイルが使用される。例えば、２枚のタイルを２ｘ１又は１ｘ２構成で使用することができ、４枚のタイルを２ｘ２、４ｘ１又は１ｘ４構成で使用することができ、６枚のタイルを３ｘ２、２ｘ３、６ｘ１又は１ｘ６構成で使用することができ、或いは８枚のタイルを４ｘ２（図７ｂに示すような）、２ｘ４、８ｘ１又は１ｘ８構成で使用することができる。タイルは、方形である必要がなく、又、ビデオフレームも、方形又は長方形である必要がないことに注意されたい。タイルは、使用するビデオフレーム及びアプリケーションに最も適した形状に分割することができる。
別の実施形態では、Ｉ及びＰタイルのサイクルがタイルの数に固定されない。例えば、８タイルの４ｘ２構成では、図７ｂに示すように１６サイクルシーケンスを依然使用することができる。順次の非圧縮フレーム７２１、７２２、７２３は、各々、８枚のタイル、０−７に分割され、各タイルが個々に圧縮される。Ｒフレーム７３１から、タイル０だけがＩタイルとして圧縮され、残りのタイルは、Ｐタイルとして圧縮される。その後のＲフレーム７３２については、８枚のタイル全部がＰタイルとして圧縮され、次いで、その後のＲフレーム７３３については、タイル１がＩタイルとして圧縮され、そして他のタイル全部がＰタイルとして圧縮される。従って、１６個のフレームについてシーケンスが続き、Ｉタイルは、１つおきのフレームのみに発生され、最後のＩタイルは、１５番目のフレーム時間中にタイル７について発生され（図７ｂには示さず）、そして第１６番目のフレーム時間中に、全Ｐタイルを使用してＲフレーム７８０が圧縮される。次いで、タイル０がＩタイルとして圧縮されそして他のタイルがＰタイルとして圧縮されるようにしてシーケンスが再開される。先の実施形態と同様に、全ビデオシーケンスの各第１フレームは、典型的に、全てＩタイルであり、その点から前方へのＰタイルの基準を与える。Ｉタイル及びＰタイルのサイクルは、タイルの数の偶数倍である必要がない。例えば、８枚のタイルでは、Ｉタイルをもつ各フレームの後に、全てＰタイルをもつ２つのフレームが続き、その後に、別のＩタイルが使用される。更に別の実施形態では、あるタイルは、例えば、スクリーンのあるエリアがより多くの動きを有し頻繁なＩタイルを要求すると分かっているが、他のエリアはより静的であって（例えば、ゲームのスコアを示す）頻繁なＩタイルをほとんど要求しない場合に、Ｉタイルが他のタイルより頻繁にある状態でシーケンスされる。更に、各フレームは、図７ａ−ｂにおいて単一のＩタイルと共に示されているが、（送信チャンネルの帯域巾に基づいて）単一のフレーム内で複数のＩタイルをエンコードすることもできる。逆に、あるフレーム又はフレームシーケンスを、Ｉタイルなしで（即ち、Ｐタイルのみで）送信することもできる。
先の段落で述べた解決策が良く機能する理由は、各単一フレームにわたってＩタイルを分布させないことで、大きなピークを生じると思われるが、システムの挙動は、そのように単純ではないことである。各タイルは、他のタイルとは個別に圧縮されるので、タイルが小さくなるほど、各タイルのエンコーディングは、効率的でなくなる。というのは、所与のタイルのコンプレッサが、他のタイルからの類似映像特徴及び類似の動きを利用できないためである。従って、スクリーンを１６枚のタイルに分割すると、一般的に、スクリーンを８枚のタイルに分割する場合よりエンコーディングの効率が低下する。しかし、スクリーンが８枚のタイルに分割され、そして全Ｉフレームのデータを、１６フレームごとではなく８フレームごとに導入させる場合には、全体的に非常に高いデータレートとなる。従って、８フレームごとではなく１６フレームごとに全Ｉフレームを導入することにより、全体的なデータレートが減少される。又、１６枚の小さなタイルではなく８枚の大きなタイルを使用することにより、全データレートが減少され、大きなタイルにより生じるデータピークをある程度軽減させる。
別の実施形態では、図７ａ及び７ｂの短待ち時間のビデオ圧縮ロジック４０４は、Ｒフレームにおける種々のタイルへのビットの割り当てを、圧縮されるべきビデオシーケンスの既知の特性に基づく設定で予め構成することにより、或いは各タイルにおける映像クオリティの進行中の分析に基づいて自動的に、コントロールする。例えば、ある競争ビデオゲームでは、（シーンにおいて比較的動きの少ない）プレーヤの車の前部が、シーンの下半分の大部分を占有し、一方、シーンの上半分が、ほぼ常に動いている接近する道路、ビル及び風景で完全に埋められる。圧縮ロジック４０４が各タイルに等しい数のビットを割り当てる場合には、図７ｂの非圧縮フレーム７２１のスクリーンの下半分のタイル（タイル４−７）が、一般的に、図７ｂの非圧縮フレーム７２１のスクリーンの上半分のタイル（タイル０−３）より高いクオリティで圧縮される。この特定のゲーム又はゲームのこの特定のシーンがこのような特性を有すると分かっている場合には、ホスティングサービス２１０のオペレータは、スクリーンの下部のタイルよりスクリーンの上部のタイルにより多くのビットを割り当てるように圧縮ロジック４０４を構成することができる。或いは、圧縮ロジック４０４は、フレームが圧縮された後に（ピーク信号対雑音比（ＰＳＮＲ）のような多数の圧縮クオリティメトリックの１つ以上を使用して）タイルの圧縮のクオリティを評価することができ、そしてある時間ウインドウにわたり、あるタイルが高いクオリティの結果を一貫して生じると決定する場合に、種々のタイルが同様のクオリティレベルに達するまで、低いクオリティの結果を生じるタイルにより多くのビットを徐々に割り当てる。別の実施形態では、圧縮ロジック４０４は、特定のタイル又はタイルのグループに高いクオリティを得るようにビットを割り当てる。例えば、スクリーンの縁より中心部のクオリティを高くするように全体的に良好な知覚上の見掛けを与えることができる。
一実施形態では、ビデオストリームのある領域の解像度を改善するために、ビデオ圧縮ロジック４０４は、シーンの複雑さ及び／又は動きが比較的大きいビデオスクリーンのエリアを、シーンの複雑さ及び／又は動きが比較的小さいビデオスクリーンのエリアより小さいタイルを使用してエンコードする。例えば、図８に示すように、１つのＲフレーム８１１の１つのエリア内の動くキャラクタ８０５の周りに小さなタイルが使用される（潜在的に、その後に、同じタイルサイズをもつ一連のＲフレーム（図示せず）が続く）。次いで、キャラクタ８０５が映像の新たなエリアへ移動すると、図示されたように、別のＲフレーム８１２内のこの新たなエリアの周りに小さなタイルが使用される。上述したように、これらの基礎的な原理に依然合致しながら、種々の異なるサイズ及び形状を「タイル」として使用することができる。
上述した循環するＩ／Ｐタイルは、ビデオストリームのデータレートのピークを実質的に減少するが、特に、動画、ビデオゲーム及びあるアプリケーションソフトウェアで発生する急速に変化する又は非常に複雑なビデオ映像の場合には、ピークを完全に排除することができない。例えば、突然のシーンの移行中に、複雑なフレームの後に、完全に異なる別の複雑なフレームが続くことがある。多数のＩタイルが若干のフレームの時間だけシーンの移行に先行することがあっても、それらは、この状態において助けとならない。というのは、新たなフレーム資料が手前のＩタイルと関係がないからである。このような状態（及び何もかもが変化しなくても、多くの映像が変化する他の状態）では、ビデオコンプレッサ４０４は、Ｐタイルの全部でなくてもその多くがＩタイルとしてより効率的にコード化され、その結果、そのフレームに対するデータレートに非常に大きなピークが生じると決定する。
上述したように、ほとんどの消費者グレードのインターネット接続（及び多くのオフィス接続）では、図６ｃに６２２として示す利用可能な最大データレートを越えるデータを定格最大データレート６２１と共に「ジャム(jam)」することが単純に実行できないケースがある。定格最大データレート６２１（例えば、“６Ｍｂｐｓ ＤＳＬ”）は、インターネット接続の購入を考えるユーザにとって本質的にマーケッティングナンバーであるが、一般的に、性能のレベルを保証するものではない。本発明の説明上、これは、無関係である。というのは、ビデオが接続を通してストリーミングされるときには、利用可能な最大データレート６２２だけが問題だからである。その結果、図９ａ及び９ｃにおいて、ピークの問題に対する解決策を説明するときに、定格最大データレートがグラフから削除され、利用可能な最大データレート９２２だけが示される。ビデオストリームデータレートは、利用可能な最大データレート９２２を越えてはならない。
これに対処するために、ビデオコンプレッサ４０４が第１に実行すべきことは、チャンネルが着実に取り扱うことのできるデータレートであるピークデータレート９４１を決定することである。このレートは、多数の技術によって決定することができる。１つのこのような技術は、図４ａ及び４ｂにおいて、ホスティングサービス２１０からクライアント４１５へ次第に高いデータレートテストストリームを徐々に送信し、そしてクライアントがパケットロス及び待ち時間のレベルに関してホスティングサービスへフィードバックを与えるようにさせるものである。パケットロス及び／又は待ち時間が鋭い増加を示し始めるときには、それは、利用可能な最大データレート９２２に到達しつつあるという指示である。その後、ホスティングサービス２１０は、適度な期間中受け容れられるパケットロスレベルでテストストリームが受信され且つ待ち時間がほぼ最小であることをクライアント４１５が報告するまで、テストストリームのデータレートを徐々に減少することができる。これは、ピーク最大データレート９４１を確立し、これは、次いで、ストリーミングビデオのためのピークデータレートとして使用される。時間と共に、ピークデータレート９４１が変動し（例えば、家の別のユーザがインターネット接続を激しく使用し始める場合に）、そしてクライアント４１５は、それを常時監視して、パケットロス又は待ち時間が増大するかどうか調べる必要があり、利用可能な最大データレート９２２が以前に確立されたピークデータレート９４１より降下することを指示し、そしてもしそうであれば、ピークデータレート９４１を指示する。同様に、時間と共に、クライアント４１５は、パケットロス及び待ち時間が最適なレベルに保たれることを見つけた場合には、ビデオコンプレッサがデータレートをゆっくり増加して利用可能な最大データレートが増加したかどうか調べることを要求でき（例えば、家の別のユーザがインターネット接続の激しい使用を止めた場合に）、そして利用可能な最大データレート９２２を越えたことをパケットロス及び／又は長い待ち時間が指示し、ピークデータレート９４１に対して低いレベルを再び見つけることができるが、それがおそらく増加データレートのテストの前のレベルより高いものとなるまで、再び待機する。従って、この技術（及びそれに類似した他の技術）を使用することにより、ピークデータレート９４１を見つけて、必要に応じて、周期的に調整することができる。ピークデータレート９４１は、ユーザへビデオをストリーミングするためにビデオコンプレッサにより使用できる最大データレートを確立する。ピークデータレートを決定するためのロジックは、ユーザの家屋２１１及び／又はホスティングサービス２１０において具現化することができる。ユーザの家屋２１１において、クライアント装置４１５は、計算を行ってピークデータレートを決定し、そしてその情報をホスティングサービス２１０へ返送し、ホスティングサービス２１０において、ホスティングサービスのサーバー４０２は、クライアント４１５から受け取った統計情報（例えば、パケットロス、待ち時間、最大データレート、等）に基づいて、計算を行ってピークデータレートを決定する。
図９ａは、図７ａ、７ｂ及び図８に示されて上述した循環Ｉ／Ｐタイル圧縮技術を使用して発生された実質的なシーンの複雑さ及び／又は動きを有するビデオストリームデータレート９３４を例示する。ビデオコンプレッサ４０４は、ピークデータレート９４１より低い平均データレートで圧縮ビデオを出力するように構成され、ほとんどの時間、ビデオストリームデータレートは、ピークデータレート９４１より低く保たれることに注意されたい。Ｉ／Ｐ／Ｂ又はＩ／Ｐフレームを使用して生成された図６ｃに示すビデオストリームデータレート６３４とデータレート９３４との比較は、循環Ｉ／Ｐタイル圧縮が非常に滑らかなデータレートを発生することを示している。更に、フレーム２ｘピーク９５２（これは２ｘピークデータレート９４２に接近する）及びフレーム４ｘピーク９５４（これは４ｘピークデータレート９４４に接近する）において、データレートは、ピークデータレート９４１を越え、受け容れられない。実際に、迅速に変化するビデオゲームからの高アクションビデオでも、ピークデータレート９４１を越えるピークがフレームの２％未満で発生し、２ｘピークデータレート９４２を越えるピークがまれに発生し、そして３ｘピークデータレート９４３を越えるピークはほとんど発生しない。しかし、それらが（例えば、シーンの移行中に）発生するときには、それらによって要求されるデータレートは、良好なクオリティのビデオ映像を発生するのに必要なものである。
この問題を解決する１つの方法は、最大データレート出力がピークデータレート９４１となるようにビデオコンプレッサ４０４を単に構成することである。不都合なことに、それによりピークフレーム中に生じるビデオ出力のクオリティは、圧縮アルゴリズムがビットについて「欠乏」しているので、不充分である。その結果、突然の移行又は高速な動きがあるときに圧縮欠陥が現れ、やがて、ユーザは、突然の変化又は急速な動きがあるときに常に欠陥が現れ、それが極めて迷惑であることを悟る。
人間の視覚系は、突然の変化又は急速な動きの間に現れる視覚上の欠陥には極めて敏感であるが、このような状態におけるフレームレートの減少の検出にはあまり敏感でない。実際に、このような突然の変化が生じたときに、人間の視覚系は、変化を追跡することに心を奪われ、フレームレートが短時間で６０ｆｐｓから３０ｆｐｓへ降下し、次いで、即座に６０ｆｐｓへ復帰することに気付かないと思われる。そして、突然のシーンの切り換えのような非常に急激な移行の場合には、人間の視覚系は、フレームレートが２０ｆｐｓ又は１５ｆｐｓへ降下し、次いで、即座に６０ｆｐｓへ戻ることに気付かない。観察する人間にとってフレームレートの減少が時々生じるだけである限り、ビデオは、６０ｆｐｓで連続的に動作したかのように見える。
人間の視覚系のこの特性は、図９ｂに示す技術により利用される。サーバー４０２（図４ａ及び４ｂからの）は、一定のフレームレート（一実施形態では６０ｆｐｓ）の非圧縮ビデオ出力ストリームを発生する。時間線は、各フレーム９６１−９７０を各々１／６０秒で示している。各非圧縮ビデオフレームは、フレーム９６１でスタートして、短待ち時間のビデオコンプレッサ４０４へ出力され、これは、フレームを１フレーム時間未満で圧縮し、第１フレームとして圧縮フレーム１ ９８１を発生する。圧縮フレーム１ ９８１に対して発生されるデータは、上述したように、多数のファクタに基づいて大きくてもよいし小さくてもよい。データが、フレーム時間（１／６０秒）内又はピークデータレート９４１未満でクライアント４１５へ送信できるに充分なほど小さい場合には、それが送信時間（ｘｍｉｔ時間）９９１中に送信される（矢印の長さは、送信時間の巾を示す）。次のフレーム時間において、サーバー４０２は、非圧縮フレーム２ ９６２を発生し、これは、圧縮フレーム２ ９８２へと圧縮され、そしてピークデータレート９４１においてフレーム時間未満である送信時間９９２中にクライアント４１５へ送信される。
次いで、次のフレーム時間に、サーバー４０２は、非圧縮フレーム３ ９６３を発生する。これがビデオコンプレッサ４０４により圧縮されると、それにより生じる圧縮フレーム３ ９８３は、１フレーム時間にピークデータレート９４１で送信できる以上のデータとなる。従って、それは、全フレーム時間と次のフレーム時間の一部分とを取り上げた送信時間（２ｘピーク）９９３中に送信される。ここで、次のフレーム時間中に、サーバー４０２は、別の非圧縮フレーム４ ９６４を発生し、それをビデオコンプレッサ４０４へ出力するが、データは、無視され、９７４で示されている。これは、ビデオコンプレッサ４０４が、手前の圧縮フレームをまだ送信している間に到着する更に別の非圧縮ビデオフレームを無視するように構成されているからである。もちろん、クライアント４１５のビデオデコンプレッサは、フレーム４を受信せず、２フレームの時間中、フレーム３をディスプレイ装置４２２に単に表示し続ける（即ち、フレームレートを６０ｆｐｓから３０ｆｐｓへ簡単に減少する）。
次のフレーム５に対して、サーバー４０２は、非圧縮フレーム５ ９６５を出力し、これは、圧縮フレーム５ ９８５へと圧縮され、そして送信時間９９５中の１フレーム以内に送信される。クライアント４１５のビデオデコンプレッサは、フレーム５を解凍し、ディスプレイ装置４２２に表示する。次いで、サーバー４０２は、非圧縮フレーム６ ９６６を出力し、ビデオコンプレッサ４０４は、それを圧縮フレーム６ ９８６へと圧縮するが、このときには、得られるデータが非常に長い。圧縮フレームは、送信時間（４ｘピーク）９９６中にピークデータレート９４１で送信されるが、フレームを送信するのに、ほぼ４フレームの時間を要する。次の３フレームの時間中に、ビデオコンプレッサ４０４は、サーバー４０２からの３フレームを無視し、そしてクライアント４１５のデコンプレッサは、フレーム６を４フレームの時間中にディスプレイ装置４２２に着実に保持する（即ち、フレームレートを６０ｆｐｓから１５ｆｐｓへ簡単に減少する）。次いで、最終的に、サーバー４０２は、フレーム１０ ９７０を出力し、ビデオコンプレッサ４０４は、それを圧縮フレーム１０ ９８７へ圧縮し、これは、送信時間９９７中に送信され、そしてクライアント４１５のデコンプレッサは、フレーム１０を解凍してディスプレイ装置４２２に表示し、そしてもう一度ビデオが６０ｆｐｓで再開する。
ビデオコンプレッサ４０４は、サーバー４０２により発生されたビデオストリームからビデオフレームをドロップするが、オーディオがどんな形態で到来するかに関わらずオーディオデータはドロップせず、ビデオフレームがドロップされるときにオーディオデータを圧縮し続けて、それらをクライアント４１５へ送信し、クライアントは、オーディオデータを解凍し続け、そしてオーディオを、ユーザにより使用される装置へ供給し、オーディオを再生することに注意されたい。従って、オーディオは、フレームがドロップされる期間中は非減衰状態を続ける。圧縮オーディオは、圧縮ビデオに比して、帯域巾の比較的僅かな割合を消費するだけであり、その結果、全体的なデータレートに大きな影響は及ぼさない。いずれのデータレート図にも示されていないが、ピークデータレート９４１内で圧縮オーディオストリームに対して常にデータレート容量が予約されている。
図９ｂについて上述した例は、データレートピーク中にフレームレートがいかに降下するか示すために選択されたものであるが、先に述べた循環Ｉ／Ｐタイル技術が使用されるときに、そのようなデータレートピーク及びそれによりドロップされるフレームは、ビデオゲーム、動画及びあるアプリケーションソフトウェアにおいて生じるような高いシーン複雑さ／高いアクションのシーケンス中でもまれであることは、示されていない。従って、フレームレートの減少は、時々で且つ短時間であり、人間の視覚系は、それを検知しない。
上述したフレームレート減少メカニズムが、図９ａに示すビデオストリームデータレートに適用される場合に、それにより生じるビデオストリームデータレートが図９ｃに示されている。この例では、２ｘピーク９５２が平坦な２ｘピーク９５３へ減少され、４ｘピーク９５５が平坦な４ｘピーク９５５へ減少され、そして全ビデオストリームデータレート９３４がピークデータレート９４１以下に保たれる。
従って、上述した技術を使用して、高アクションビデオストリームを、一般的なインターネット及び消費者グレードのインターネット接続を通して短い待ち時間で送信することができる。更に、ＬＡＮ（例えば、１００Ｍｂｓイーサネット又は８０２．１１ｇワイヤレス）、或いはプライベートネットワーク（例えば、データセンターとオフィスとの間の１００Ｍｂｐｓ接続）におけるオフィス環境では、高アクションビデオストリームをピークなしに送信することができ、大勢のユーザ（例えば、４．５Ｍｂｐｓにおいて６０ｆｐｓで１９２０ｘ１０８０を送信する）が、ネットワーク又はネットワークスイッチバックプレーンを圧倒する重畳ピークをもたずに、ＬＡＮ又は共有プライベートデータ接続を使用できるようにする。
データレートの調整
一実施形態では、ホスティングサービス２１０は、最初、利用可能な最大データレート６２２及びチャンネルの待ち時間にアクセスして、ビデオストリームのための適当なデータレートを決定し、次いで、それに応答してデータレートを動的に調整する。データレートを調整するために、ホスティングサービス２１０は、例えば、映像の解像度、及び／又はクライアント４１５へ送信されるビデオストリームのフレーム数／秒を変更することができる。又、ホスティングサービスは、圧縮ビデオのクオリティレベルを調整することもできる。ビデオストリームの解像度を、例えば、１２８０ｘ７２０解像度から６４０ｘ３６０へ変更するときに、クライアント４１５のビデオ解凍ロジック４１２は、ディスプレイスクリーン上に同じ映像サイズを維持するように映像をスケールアップすることができる。
一実施形態では、チャンネルが完全にドロップアウトする状況において、ホスティングサービス２１０は、ゲームを休止する。マルチプレーヤゲームの場合には、ホスティングサービスは、ユーザがゲームからドロップアウトしたことを他のユーザに報告し、及び／又は他のユーザに対してゲームを休止する。
ドロップ又は遅延したパケット
一実施形態において、図４ａ又は４ｂにおけるビデオコンプレッサ４０４とクライアント４１５との間のパケットロスのために、或いはパケットが順序ずれして受け取られて、解凍するには遅過ぎ且つ解凍フレームの待ち時間要件を満足するには遅過ぎる到着であるために、データが失われる場合に、ビデオ解凍ロジック４１２は、視覚上の欠陥を軽減することができる。ストリーミングＩ／Ｐフレーム具現化において、失われ／遅延したパケットがある場合には、スクリーン全体に影響が及び、潜在的に、ある期間中スクリーンを完全に凍結させるか、又は他のスクリーン巾の視覚上の欠陥を表示させる。例えば、失われ／遅延したパケットがＩフレームの損失を生じさせる場合には、デコンプレッサは、それに続く全てのＰフレームに対する基準を、新たなＩフレームが受け取られるまで欠くことになる。Ｐフレームが失われた場合には、それに続く全スクリーンのためのＰフレームに影響を及ぼすことになる。Ｉフレームが現れるまでどれほど長いかに基づき、これは、長い又は短い視覚上の影響となる。図７ａ及び７ｂに示すインターリーブされたＩ／Ｐタイルを使用すると、失われ／遅延したパケットは、スクリーン全体に影響を及ぼすおそれが非常に僅かになる。というのは、影響を受けるパケットに含まれたタイルにしか影響しないからである。各タイルのデータが個々のパケット内で送信される場合には、パケットが失われた場合に、それが１つのタイルにしか影響しない。もちろん、視覚上の欠陥の巾は、Ｉタイルパケットが失われるかどうか、及びＰタイルが失われた場合には、Ｉタイルが現れるまでにどれほど多くのフレームを要するか、に依存する。しかし、スクリーン上の異なるタイルがＩフレームで頻繁に（潜在的にフレームごとに）更新されるとすれば、スクリーン上の１つのタイルが影響を受ける場合でも、他のタイルは、そうではない。更に、ある事象が一度に多数のパケットのロスを生じさせる場合には（例えば、ＤＳＬラインに続く電力のスパイクでデータ流を短時間中断するもの）、あるタイルが、他のタイル以上に影響を受けるが、あるタイルは、新たなＩタイルで素早く更新されるので、短時間影響を受けるだけである。又、ストリーミングＩ／Ｐフレーム具現化では、Ｉフレームが最も重要なフレームであるだけでなく、非常に大きなフレームでもあり、従って、ドロップされ／遅延されたパケットを生じさせる事象がある場合には、Ｉフレームが影響を受ける確率が、非常に小さなＩタイルより高くなる（即ち、Ｉフレームが一部分でも失われた場合には、Ｉフレームを解凍できる見込みが全くなくなる）。これら全ての理由で、Ｉ／Ｐタイルを使用すると、パケットがドロップされ／遅延されるときに、視覚上の欠陥は、Ｉ／Ｐフレームの場合より遥かに少なくなる。
一実施形態では、圧縮されたタイルをＴＣＰ（送信コントロールプロトコル）パケット又はＵＤＰ（ユーザデータグラムプロトコル）パケット内にインテリジェントにパッケージすることにより失われたパケットの作用を減少することが試みられる。例えば、一実施形態では、タイルが、可能であれば、パケット境界に整列される。図１０ａは、この特徴を具現化せずに、タイルを一連のパケット１００１−１００５内にどのようにパックするか示す。より詳細には、図１０ａにおいて、単一パケットのロスが複数のフレームのロスを生じるように、タイルがパケット境界に交差し、非効率的にパックされる。例えば、パケット１００３または１００４が失われる場合に、３つのタイルが失われ、視覚上の欠陥を招く。
対称的に、図１０ｂは、パケットロスの作用を減少するためにパケット内にタイルをインテリジェントにパッキングするためのタイルパッキングロジック１０１０を示す。第１に、タイルパッキングロジック１０１０は、タイルをパケット境界に整列させる。従って、タイルＴ１、Ｔ３、Ｔ４、Ｔ７及びＴ２は、各々、パケット１００１−１００５の境界に整列される。又、タイルパッキングロジックは、パケット境界に交差せずに、考えられる最も効率的な仕方で、パケット内にタイルを嵌合させることも試みる。各タイルのサイズに基づいて、タイルＴ１及びＴ６は、１つのパケット１００１内で合成され、Ｔ３及びＴ５は、１つのパケット１００２内で合成され、タイルＴ４及びＴ８は、１つのパケット１００３内で合成され、タイルＴ８は、パケット１００４に追加され、そしてタイルＴ２は、パケット１００５に追加される。従って、このスキムのもとでは、単一パケットのロスは、（図１０ａに示す３つのタイルではなく）２つ以下のタイルのロスを招くことになる。
図１０ｂに示す実施形態に対する１つの付加的な利益は、タイルが、映像内に表示されるのとは異なる順序で送信されることである。このように、隣接パケットが送信を妨げる同じ事象から失われた場合に、スクリーン上の互いに近隣でないエリアに影響を及ぼし、ディスプレイ上の欠陥をあまり目立たなくする。
一実施形態では、順方向エラー修正（ＦＥＣ）技術を使用して、ビデオストリームの幾つかの部分をチャンネルエラーから保護する。この技術で知られているように、リードソロモン及びビタビのようなＦＥＣ技術は、エラー修正データ情報を発生して、通信チャンネルを経て送信されるデータに添付させる。基礎的なデータ（例えば、Ｉフレーム）にエラーが発生した場合には、ＦＥＣを使用して、エラーを修正することができる。
ＦＥＣコードは、送信のデータレートを高め、従って、理想的には、それらが最も必要とされるところに使用されるだけである。非常に目立つ視覚上の欠陥を生じないデータが送信される場合には、データを保護するためにＦＥＣコードを使用しないのが好ましい。例えば、失われるＩタイルの直前のＰタイルは、スクリーン上に１／６０秒だけ視覚上の欠陥を生じさせる（即ち、スクリーン上のタイルは更新されない）。このような視覚上の欠陥は、人間の目でかろうじて検知できる。ＰタイルがＩタイルから更に後方にある場合には、Ｐタイルを失うと、益々目立つことになる。例えば、タイルサイクルパターンが、Ｉタイルの後に１５個のＰタイルが続き、その後、Ｉタイルが再び得られるというものである場合、Ｉタイルの直後のＰタイルが失われると、そのタイルは、１５フレームの時間中誤った映像を示すことになる（６０ｆｐｓでは、それは、２５０ｍｓである）。人間の目は、２５０ｍｓ間のストリームの中断は容易に検知する。従って、Ｐタイルが新たなＩタイルから更に後方にあるほど（即ち、Ｐタイルがより接近してＩタイルに続くほど）、欠陥がより目立ったものになる。上述したように、一般的に、Ｐタイルがより接近してＩタイルに続くほど、そのＰタイルに対するデータがより小さくなる。従って、Ｉタイルに続くＰタイルは、失われないよう保護するのがより重要であるだけでなく、サイズが小さいことも重要である。そして、一般的に、保護される必要のあるデータが小さいほど、それを保護するために必要なＦＥＣコードも小さくなる。
従って、図１１ａに示すように、一実施形態では、ビデオストリームにおけるＩタイルの重要性のために、ＩタイルだけにＦＥＣコードが与えられる。従って、ＦＥＣ１１０１は、Ｉタイル１１００に対するエラー修正コードを含み、そしてＦＥＣ１１０４は、Ｉタイル１１０３に対するエラー修正コードを含む。この実施形態では、Ｐタイルに対してＦＥＣは発生されない。
図１１ｂに示す一実施形態では、失われた場合に視覚上の欠陥を生じさせるおそれが最もあるＰタイルについてもＦＥＣコードが発生される。この実施形態では、ＦＥＣ１１０５は、最初の３つのＰタイルに対してエラー修正コードを与えるが、それに続くＰタイルについては与えない。別の実施形態では、データサイズが最も小さいＰタイルについてＦＥＣコードが発生される（Ｉタイルの後に最も早く発生して、保護することが最も重要なＰタイルを自己選択する傾向がある）。
別の実施形態では、ＦＥＣコードをタイルと共に送信するのではなく、タイルが２回、そのたびに異なるパケットで、送信される。１つのパケットが失われ／遅延された場合には、他のパケットが使用される。
図１１ｃに示す一実施形態では、ＦＥＣコード１１１１及び１１１３は、ビデオと同時にホスティングサービスから送信されるオーディオパケット１１１０及び１１１２に対して各々発生される。ビデオストリームにおいてオーディオの完全性を維持することが特に重要である。というのは、歪んだオーディオ（例えば、カチカチ音又はスー音）は、特に望ましからぬユーザの経験を招くからである。ＦＥＣコードは、オーディオコンテンツがクライアントコンピュータ４１５において歪なくレンダリングされることを保証する上で助けとなる。
別の実施形態では、ＦＥＣコードをオーディオデータと共に送信するのではなく、オーディオデータが２回、そのたびに異なるパケットで、送信される。１つのパケットが失われ／遅延された場合には、他のパケットが使用される。
更に、図１１ｄに示す一実施形態では、クライアント４１５からホスティングサービス２１０へと上流に送信されるユーザ入力コマンド１１２０及び１１２２（例えば、ボタン押圧）に対してＦＥＣコード１１２１及び１１２３が各々使用される。これは重要である。というのは、ビデオゲーム又はアプリケーションにおいてボタン押圧又はマウス移動が欠落すると、望ましからぬユーザ経験を招くからである。
別の実施形態では、ＦＥＣコードをユーザ入力コマンドデータと共に送信するのではなく、ユーザ入力コマンドデータが２回、そのたびに異なるパケットで、送信される。１つのパケットが失われ／遅延された場合には、他のパケットが使用される。
一実施形態では、ホスティングサービス２１０がクライアント４１５との通信チャンネルのクオリティを評価して、ＦＥＣを使用すべきかどうか決定し、もしそうであれば、ビデオ、オーディオ及びユーザコマンドのどの部分にＦＥＣを適用すべきか決定する。チャンネルの「クオリティ」を評価することは、上述したように、パケットロス、待ち時間、等を評価するようなファンクションを含む。チャンネルに特に信頼性がない場合には、ホスティングサービス２１０は、Ｉタイル、Ｐタイル、オーディオ及びユーザコマンドの全てにＦＥＣを適用することができる。対照的に、チャンネルに信頼性がある場合には、ホスティングサービス２１０は、オーディオ及びユーザコマンドのみにＦＥＣを適用するか、又はオーディオ又はビデオにＦＥＣを適用するか、或いはＦＥＣを全く使用しない。これら基礎的な原理に依然合致しながら、ＦＥＣの適用の種々の他の順列を使用することができる。一実施形態では、ホスティングサービス２１０は、チャンネルの状態を常時監視し、それに応じてＦＥＣポリシーを変更する。
別の実施形態では、図４ａ及び４ｂを参照すれば、パケットが失われ／遅延されてタイルデータを失うことになるか、又はおそらく特に悪いパケット損失のために、ＦＥＣが、失われたタイルデータを修正できない場合には、クライアント４１５は、新たなＩタイルが受け取られる前にどれほど多くのフレームが残っているか評価し、それをクライアント４１５からホスティングサービス２１０への往復待ち時間と比較する。その往復待ち時間が、新たなＩタイルが当然到着するまでのフレームの数より少ない場合には、クライアント４１５は、新たなＩタイルを要求するメッセージをホスティングサービス２１０へ送信する。このメッセージは、ビデオコンプレッサ４０４へルーティングされ、このコンプレッサは、データが失われたところのタイルに対してＰタイルを発生するのではなく、Ｉタイルを発生する。図４ａ及び４ｂに示すシステムが、典型的に８０ｍｓ未満の往復待ち時間を与えるように設計されているとすれば、それにより、タイルが８０ｍｓ以内に修正される（６０ｆｐｓにおいて、フレームは、１６．６７ｍｓの巾であり、従って、全フレームの時間において、８０ｍｓの待ち時間で、５フレームの時間である８３．３３ｍｓ以内にタイルが修正され、即ち、これは、目立った中断であるが、例えば、１５フレームに対する２５０ｍｓの中断よりは遥かに目立たないものである）。コンプレッサ４０４がその通常の循環順序からＩタイルを発生するときに、Ｉタイルによりそのフレームの帯域巾が利用可能な帯域巾を越える場合は、コンプレッサ４０４は、他のタイルのサイクルを遅延させて、他のタイルがそのフレーム時間中にＰタイルを受け取るようにし（１つのタイルが通常そのフレーム中に当然Ｉタイルであるべき場合でも）、次いで、次のフレームでスタートして、通常の循環が続き、そして通常はその手前のフレームでＩタイルを受信するタイルが、Ｉタイルを受信するようにする。このアクションは、Ｒフレーム循環の位相を短時間遅延するが、通常は、視覚上、目立つものではない。
ビデオ及びオーディオコンプレッサ／デコンプレッサ具現化
図１２は、マルチコア及び／又はマルチプロセッサ１２００を使用して８枚のタイルを並列に圧縮する１つの特定の実施形態を示す。一実施形態では、２．６６ＧＨｚ以上で動作するデュアルプロセッサ・クオドコアＸｅｏｎ ＣＰＵコンピュータシステムが使用され、各コアは、オープンソースｘ２６４ Ｈ．２６４コンプレッサを独立プロセスとして具現化する。しかしながら、これら基礎的な原理に依然合致しながら、種々の他のハードウェア／ソフトウェアコンフィギュレーションが使用されてもよい。例えば、ＣＰＵコアの各々を、ＦＰＧＡで具現化されるＨ．２６４コンプレッサに置き換えることができる。図１２に示す例では、コア１２０１−１２０８を使用して、Ｉタイル及びＰタイルを８個の独立したスレッドとして同時に処理する。この技術で良く知られているように、現在のマルチコア及びマルチプロセッサコンピュータシステムは、本来、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＸＰプロフェッショナルエディション（６４ビット又は３２ビットエディション）及びＬｉｎｕｘのようなマルチスレッドオペレーティングシステムと一体化されたときにマルチスレッディング可能である。
図１２に示す実施形態では、８個のコアの各々は、１つのタイルについてのみ役立つので、ｘ２６４の個別インスタンス生成を各々実行する他のコアとは主として独立して動作する。ＰＣＩ Ｅｘｐｒｅｓｓ ｘ１ベースのＤＶＩ捕獲カード、例えば、オランダ、オーステルハウトのマイクロトロニクスからのセンデロ・ビデオ・イメージングＩＰデベロープメント・ボードを使用して、６４０ｘ４８０、８００ｘ６００、又は１２８０ｘ７２０解像度で非圧縮ビデオを捕獲し、そしてこのカードのＦＰＧＡは、直接メモリアクセス（ＤＭＡ）を使用して、ＤＶＩバスを経て捕獲されたビデオをシステムＲＡＭへと転送する。タイルは、４ｘ２配列１２０５に配列される（それらは、方形タイルとして示されているが、この実施形態では、１６０ｘ２４０解像度である）。ｘ２６４の各インスタンス化は、８個の１６８ｘ２４０タイルの１つを圧縮するように構成され、そしてそれらは、最初のＩタイル圧縮の後に、各コアがサイクルに入り、各１つのフレームが他のフレームと位相ずれし、１つのＩタイル、その後、７つのＰタイルを圧縮するように、図１２に示すように、同期される。
フレーム時間ごとに、得られた圧縮されたタイルが、上述した技術を使用して、パケットストリームへと合成され、次いで、その圧縮されたタイルが、行先クライアント４１５へ送信される。
図１２には示されていないが、合成される８枚のタイルのデータレートが特定のピークデータレート９４１を越える場合には、その合成される８枚のタイルのデータが送信されてしまうまで必要に応じて多数のフレームの時間中、全部で８ｘ２６４のプロセスが保留される。
一実施形態では、クライアント４１５は、ＦＦｍｐｅｇの８個のインスタンスを実行するＰＣにおいてソフトウェアとして具現化される。受信プロセスは、８枚のタイルを受信し、そして各タイルは、ＦＦｍｐｅｇへルーティングされ、これは、タイルを解凍して、ディスプレイ装置４２２上の適当なタイル位置にレンダリングする。
クライアント４１５は、ＰＣの入力装置ドライバからキーボード、マウス、又はゲームコントローラ入力を受け取り、そしてそれをサーバー４０２へ送信する。サーバー４０２は、次いで、その受け取った入力装置データを、サーバー４０２で実行されるゲーム又はアプリケーションに適用し、サーバー４０２は、Ｉｎｔｅｌ ２．１６ＧＨｚＣｏｒｅ Ｄｕｏ ＣＰＵを使用してＷｉｎｄｏｗｓを実行するＰＣである。次いで、サーバー４０２は、新たなフレームを発生し、そしてそのＤＶＩ出力を通して、マザーボードベースのグラフィックシステムから、或いはＮＶＩＤＩＡ８８００ＧＴＸ ＰＣＩエクスプレスカードのＤＶＩ出力を通して、それを出力する。
同時に、サーバー４０２は、ゲーム又はアプリケーションにより形成されたオーディオを、そのデジタルオーディオ出力（例えば、Ｓ／ＰＤＩＦ）を通して出力し、これは、ビデオ圧縮を具現化するデュアルクオドコアＸｅｏｎベースＰＣのデジタルオーディオ入力に結合される。Ｖｏｒｂｉｓオープンソースオーディオコンプレッサは、プロセススレッドに対して利用可能なコアを使用して、オーディオをビデオと同時に圧縮するように使用される。一実施形態では、タイルの圧縮を完了するコアが、オーディオ圧縮を最初に実行する。圧縮されたオーディオは、次いで、圧縮されたビデオと共に送信され、そしてクライアント４１５においてＶｏｒｂｉｓオーディオデコンプレッサを使用して解凍される。
ホスティングサービスサーバーセンター配布
光ファイバのようなガラスを通る光は、真空中の光の速度の一部分で進行し、従って、光ファイバにおける光の厳密な伝播速度を決定することができる。しかし、実際には、ルーティング遅延の時間、送信の非効率さ、及び他のオーバーヘッドを考慮すると、インターネット上の最適な待ち時間は、光速のほぼ５０％の送信速度を反映することが観察される。従って、最適な１０００マイル往復待ち時間は、約２２ｍｓであり、そして最適な３０００マイル往復待ち時間は、約６４ｍｓである。従って、米国の一方の海岸にある単一のサーバーは、（３０００マイル程度離れた）他方の海岸にあるクライアントに望ましい待ち時間でサービスするには離れ過ぎている。しかしながら、図１３ａに示すように、ホスティングサービス２１０のサーバーセンター１３００が、米国の中央部（例えば、カンザス、ネブラスカ、等）に位置されて、米国大陸の任意の点までの距離が約１５００マイル以下となる場合には、往復インターネット待ち時間を３２ｍｓ程度に小さくすることができる。図４ｂを参照すれば、ユーザＩＳＰ４５３に許された最悪のケースの待ち時間は、典型的に、２５ｍｓであるが、ＤＳＬ及びケーブルモデムシステムでは、１０から１５ｍｓに近い待ち時間が観察されていることに注意されたい。又、図４ｂは、ユーザの家屋２１１からホスティングセンター２１０までの最大距離が１０００マイルであると仮定している。従って、１５ｍｓの典型的なユーザＩＳＰ往復待ち時間が使用され、３２ｍｓの往復待ち時間に対して１５００マイルの最大インターネット距離では、ユーザが入力装置４２１を操作しそしてディスプレイ装置４２２上に応答を見る点からの合計往復待ち時間は、１＋１＋１５＋３２＋１＋１６＋６＋８＝８０ｍｓとなる。従って、８０ｍｓの応答時間が、典型的に、１５００マイルのインターネット距離にわたって得られる。これは、米国大陸において充分短いユーザＩＳＰ待ち時間４５３をもつユーザの家屋が、中央部に位置する単一のサーバーにアクセスできるようにする。
図１３ｂに示した別の実施形態では、ホスティングサービス２１０のサーバーセンターＨＳ−１ないしＨＳ６が、米国（又は他の地理的領域）に戦略的に配置され、ある大きなホスティングサービスサーバーセンター（例えば、ＨＳ２及びＨＳ５）は、人口の多いセンターの付近に配置される。一実施形態では、サーバーセンターＨＳ１ないしＨＳ６は、インターネット又はプライベートネットワーク或いはその両方の組合せであるネットワーク１３０１を経て情報を交換する。複数のサーバーセンターがある状態では、長いユーザＩＳＰ待ち時間４５３をもつユーザに対して短い待ち時間でサービスを提供することができる。
インターネット上の距離は、確実に、インターネットを通しての往復待ち時間に貢献するファクタであるが、時々、待ち時間にあまり関係のない他のファクタが影響するようになる。時々、パケットストリームがインターネットを通して離れた位置へルーティングされそして再び戻り、長いループから待ち時間を招く。時々、適切に動作しないルーティング装置が経路上にあり、送信遅延を招く。時々、経路に過負荷となるトラフィックがあって、遅延を導入する。そして、時々、ユーザのＩＳＰが所与の行先へルーティングされるのを全く阻止する故障が生じる。従って、一般的なインターネットは、通常、距離により主として決定される非常に信頼性のある最適なルート及び待ち時間で（特に、ユーザのローカルエリアの外部へのルートを生じさせる長距離接続で）、ある点から別の点への接続を与えるが、このような信頼性及び待ち時間は、保証されるものではなく、多くの場合、ユーザの家屋から一般的なインターネット上の所与の行先まで得ることができない。
一実施形態では、ユーザクライアント４１５が、最初にホスティングサービス２１０に接続して、ビデオゲームをプレイするか又はアプリケーションを使用するときに、クライアントは、始動時に利用可能なホスティングサービスサーバーセンターＨＳ１ないしＨＳ６の各々と通信する（例えば、上述した技術を使用して）。特定の接続に対して待ち時間が充分短い場合には、その接続が使用される。一実施形態では、クライアントは、最短待ち時間接続をもつものが選択されたところのホスティングサービスサーバーセンターの全部又はサブセットと通信する。クライアントが最短待ち時間接続をもつサービスセンターを選択してもよいし、又はサービスセンターが最短的時間接続をもつものを識別しそしてこの情報を（例えば、インターネットアドレスの形態で）クライアントに与えてもよい。
特定のホスティングサービスサーバーセンターが過負荷状態になり及び／又はユーザのゲーム又はアプリケーションが、別の負荷の少ないホスティングサービスサーバーセンターへの待ち時間を許容できる場合には、クライアント４１５は、他のホスティングサービスサーバーセンターに向け直される。このような状況では、ユーザが実行しているゲーム又はアプリケーションは、ユーザの過負荷状態にサーバーセンターにおけるサーバー４０２上で休止され、そしてゲーム又はアプリケーションの状態データは、別のホスティングサービスサーバーセンターにおけるサーバー４０２へ転送される。次いで、ゲーム又はアプリケーションが再開される。一実施形態では、ホスティングサービス２１０は、ゲーム又はアプリケーションが自然の休止点（例えば、ゲームにおけるレベル間、又はユーザがアプリケーションにおいて「セーブ」オペレーションを開始した後）に到達して転送を行うまで、待機する。更に別の実施形態では、ホスティングサービス２１０は、ユーザのアクティビティが特定の期間中（例えば１分間）休止するまで待機し、次いで、その時点で転送を開始する。
上述したように、一実施形態では、ホスティングサービス２１０は、そのクライアントに保証された待ち時間を与えるよう試みるために、図１４のインターネットバイパスサービス４４０に契約する。ここで使用されるインターネットバイパスサービスとは、保証された特性（例えば、待ち時間、データレート、等）をもつインターネットにおいてある点から別の点へのプライベートネットワークルートを与えるサービスである。例えば、ホスティングサービス２１０が、ＡＴ＆Ｔのサンフランシスコベースの中央オフィスへのルーティングではなく、サンフランシスコで提供されるＡＴ＆ＴのＤＳＬサービスを利用してユーザから大量のトラフィックを受信した場合に、ホスティングサービス２１０は、サンフランシスコベースの中央オフィスと、ホスティングサービス２１０のための１つ以上のサービスセンターとの間のサービスプロバイダー（おそらくＡＴ＆Ｔそれ自体又は別のプロバイダー）から大容量のプライベートデータ接続をリースすることができる。次いで、全てのホスティングサービスサーバーセンターＨＳ１ないしＨＳ６から一般的なインターネットを経てＡＴ＆ＴのＤＳＬを使用するサンフランシスコのユーザへのルートが非常に長い待ち時間を生じる場合には、それに代わって、プライベートデータ接続を使用することができる。プライベートデータ接続は、一般的に、一般的なインターネットを通るルートより費用が高いが、それがユーザへのホスティングサービス２１０接続の僅かな割合に保たれる限り、全コストへの影響は低く、ユーザは、より一貫したサービスを経験することになる。
サービスセンターは、多くの場合、停電時に２層のバックアップ電源を有する。第１の層は、典型的に、バッテリから（又は発電機に取り付けられてランニング状態に保たれるフライホイールのような別の直ちに利用できるエネルギー源から）のバックアップ電源であって、主電源が停電したときに直ちに電力を供給して、サーバーセンターをランニング状態に保持する。停電が短時間で、主電源が素早く（例えば、１分以内に）回復する場合には、バッテリは、全て、サーバーセンターをランニング状態に保持するために必要とされる。しかし、停電が長期間である場合には、典型的に、発電機（例えば、ジーゼル付勢）が始動され、バッテリを引き継いで、燃料がある限り運転することができる。このような発電機は、サーバーセンターが通常主電源から得るのと同程度の電力を発生できねばならないので、非常に高価である。
一実施形態では、ホスティングサービスＨＳ１ないしＨＳ５の各々は、互いにユーザデータを共有し、１つのサーバーセンターが停電した場合に、進行中のゲーム及びアプリケーションを休止し、次いで、ゲーム又はアプリケーションの状態データを各サーバー４０２から他のサーバーセンターのサーバー４０２へ転送し、そして各ユーザのクライアント４１５に通知して、新たなサーバー４０２と通信するように指令する。このような状態が頻繁に生じないとすれば、最適な待ち時間を与えることのできないホスティングサービスサーバーセンターへのユーザの転送を受け容れることができ（即ち、ユーザは、単に停電期間中に長い待ち時間を許容するだけでよく）、これは、ユーザを転送するための非常に広範囲のオプションを許す。例えば、米国を横切る時間ゾーン差が与えられると、東海岸のユーザは、ＰＭ１１時３０分には就寝するが、ＰＭ８時３０分の西海岸のユーザは、ビデオゲームの使用がピークになり始めている。その時間に西海岸のホスティングサービスサーバーセンターに停電が生じた場合に、他のホスティングサービスサーバーセンターには、全てのユーザを取り扱うに充分な西海岸サーバー４０２が存在しないことがある。このような状況では、利用できるサーバー４０２を有する東海岸のホスティングサービスサーバーセンターへあるユーザを転送することができ、それらユーザに対してのみ長い待ち時間となる。ユーザが、停電したサーバーセンターから転送されると、サーバーセンターは、次いで、そのサーバー及び装置の整然とした遮断を開始し、バッテリ（又は他の即座の電源バックアップ）が尽きるまでに全ての装置を遮断することができる。このように、サーバーセンター用の発電機のコストを回避することができる。
一実施形態では、ホスティングサービス２１０の激しい負荷の時間中に（ピークユーザ負荷によるか、又は１つ以上のサーバーセンターが停電したために）、ユーザは、彼等が使用しているゲーム又はアプリケーションの待ち時間要件に基づいて他のサーバーセンターへ転送される。従って、短待ち時間を要求するゲーム又はアプリケーションを使用しているユーザは、電源に制限があるときに、利用可能な短待ち時間サーバー接続への優先権が与えられる。
ホスティングサービスの特徴
図１５は、以下の特徴説明に使用されるホスティングサービス２１０のためのサーバーセンターのコンポーネントの実施形態を示す。図２ａに示されたホスティングサービス２１０と同様に、サーバーセンターのコンポーネントは、特に指示のない限り、ホスティングサービス２１０の制御システム４０１により制御され整合される。
ユーザクライアント４１５からのインバウンドインターネットトラフィック１５０１は、インバウンドルーティング１５０２に向けられる。典型的に、インバウンドインターネットトラフィック１５０１は、インターネットへの高速光ファイバ接続を経てサーバーセンターに入るが、適当な帯域巾、信頼性及び短待ち時間のネットワーク接続手段で充分である。インバウンドルーティング１５０２は、ネットワーク（ネットワークは、イーサネットネットワーク、ファイバチャンネルネットワークとして、或いは他の搬送手段を経て具現化できる）スイッチ、及びスイッチをサポートするルーティングサーバーのシステムであり、これは、到着するパケットを取り上げ、そして各パケットを適当なアプリケーション／ゲーム（ａｐｐ／ｇａｍｅ）サーバー１５２１−１５２５へルーティングする。一実施形態では、特定のａｐｐ／ｇａｍｅサーバーに配送されるパケットは、クライアントから受信されたデータのサブセットを表し、及び／又はデータセンター内の他のコンポーネント（例えば、ゲートウェイ及びルーターのようなネットワークコンポーネント）によって変換／変更されてもよい。あるケースでは、例えば、ゲーム又はアプリケーションが複数のサーバー上で並列に一度実行される場合に、パケットが一度に２つ以上のサーバー１５２１−１５２５へルーティングされる。ＲＡＩＤアレイ１５１１−１５１２は、インバウンドルーティングネットワーク１５０２へ接続され、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５がそれらＲＡＩＤアレイ１５１１−１５１２の読み取り及び書き込みを行えるようにする。更に、ＲＡＩＤアレイ１５１５（複数のＲＡＩＤアレイとして具現化できる）も、インバウンドルーティング１５０２に接続され、ＲＡＩＤアレイ１５１５からのデータは、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５から読み出すことができる。インバウンドルーティング１５０２は、インバウンドインターネットトラフィック１５０１を根にもつスイッチのツリー構造、全ての種々の装置を相互接続するメッシュ構造、或いは相互通信装置間の集中トラフィックが他の装置間の集中トラフィックから分離されるようにして相互接続された一連のサブネットを含めて、広範囲な従来のネットワークアーキテクチャーで具現化することができる。ネットワークコンフィギュレーションの一形式は、ＳＡＮであり、これは、典型的に記憶装置として使用されるが、装置間の一般的な高速データ転送に使用することもできる。又、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、各々、インバウンドルーティング１５０２への複数のネットワーク接続を有する。例えば、サーバー１５２１−１５２５は、ＲＡＩＤアレイ１５１１−１５１２に取り付けられたサブネットへのネットワーク接続と、他の装置に取り付けられたサブネットへの別のネットワーク接続とを有することができる。
ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、図４ａに示す実施形態におけるサーバー４０２に関して上述したように、全部が同じに、幾つかが異なるように、又は全部が異なるように構成されてもよい。一実施形態では、各ユーザは、ホスティングサービスを利用するときに、典型的に、少なくとも１つのａｐｐ／ｇａｍｅサーバー１５２１−１５２５を使用する。説明を簡略化するため、所与のユーザがａｐｐ／ｇａｍｅサーバー１５２１を使用すると仮定するが、１人のユーザが複数のサーバーを使用することができると共に、複数のユーザが単一のａｐｐ／ｇａｍｅサーバー１５２１−１５２５を共有することができる。上述したようにクライアント４１５から送られるユーザ制御入力は、インバウンドインターネットトラフィック１５０１として受け取られ、そしてインバウンドルーティング１５０２を通してａｐｐ／ｇａｍｅサーバー１５２１へルーティングされる。ａｐｐ／ｇａｍｅサーバー１５２１は、ユーザの制御入力を、サーバー上で実行されるゲーム又はアプリケーションへの制御入力として使用し、そしてビデオ及びそれに関連したオーディオの次のフレームを計算する。次いで、ａｐｐ／ｇａｍｅサーバー１５２１は、非圧縮のビデオ／オーディオ１５２９を共有ビデオ圧縮１５３０へ出力する。ａｐｐ／ｇａｍｅサーバーは、非圧縮のビデオを、１ギガビット以上のイーサネット接続を含む手段を経て出力できるが、一実施形態では、ビデオがＤＶＩ接続を経て出力され、そしてオーディオ及び他の圧縮並びに通信チャンネル状態情報は、ユニバーサルシリアルバス（ＵＳＢ）接続を経て出力される。
共有ビデオ圧縮１５３０は、ａｐｐ／ｇａｍｅサーバー１５２１ないし１５２５からの非圧縮ビデオ及びオーディオを圧縮する。圧縮は、完全にハードウェアで具現化されてもよいし、又はハードウェア実行ソフトウェアで具現化されてもよい。各ａｐｐ／ｇａｍｅサーバー１５２１ないし１５２５に対する専用コンプレッサがあってもよいし、又はコンプレッサが充分高速である場合には、所与のコンプレッサを使用して、２つ以上のａｐｐ／ｇａｍｅサーバー１５２１ないし１５２５からのビデオ／オーディオを圧縮することができる。例えば、６０ｆｐｓでは、ビデオフレーム時間は、１６．６７ｍｓである。コンプレッサがフレームを１ｍｓで圧縮できる場合には、そのコンプレッサを使用して、１６個程度のａｐｐ／ｇａｍｅサーバー１５２１ないし１５２５からのビデオ／オーディオを圧縮することができ、これは、あるサーバーからの入力を別のサーバーの後に取り上げ、コンプレッサが各ビデオ／オーディオ圧縮プロセスの状態をセーブし、そしてコンテクストを、それがサーバーからのビデオ／オーディオストリーム間で循環するときにスイッチすることにより行われる。その結果、圧縮ハードウェアにおいて実質的なコスト節約が得られる。異なるサーバーが異なる時間にフレームを完了するので、一実施形態では、コンプレッサリソースが、各圧縮プロセスの状態を記憶するための共有記憶手段（例えば、ＲＡＭ、フラッシュ）と共に共有プール１５３０にあり、サーバー１５２１−１５２５のフレームが完了して圧縮の準備ができると、制御手段は、どの圧縮リソースがそのとき利用できるか決定し、圧縮リソースに、サーバーの圧縮プロセスの状態と、圧縮すべき非圧縮ビデオ／オーディオのフレームとを与える。
各サーバーの圧縮プロセスの状態の一部分は、圧縮それ自体に関する情報、例えば、Ｐタイルの基準として使用できる以前のフレームの解凍フレームバッファデータ、ビデオ出力の解像度；圧縮のクオリティ；タイル構造；タイル当たりのビットの割り当て；圧縮のクオリティ、オーディオフォーマット（例えば、ステレオ、サラウンドサウンド、Ｄｏｌｂｙ（登録商標）、ＡＣ−３）を含むことに注意されたい。しかし、圧縮プロセスの状態は、ピークデータレート９４１に関する通信チャンネル状態情報、以前のフレーム（図９ｂに示す）が現在出力されるかどうか（その結果、現在フレームを無視すべきかどうか）、そして潜在的に、圧縮に考慮すべきチャンネル特性、例えば、圧縮の判断に影響する過剰なパケットロス（例えば、Ｉタイルの頻度、等に関して）があるかどうか、も含む。クライアント４１５から送られるデータを監視する各ユーザをサポートするａｐｐ／ｇａｍｅサーバー１５２１−１５２５により決定されるように、ピークデータレート９４１又は他のチャンネル特性が時間と共に変化するときに、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、共有ハードウェア圧縮１５３０へ関連情報を送信する。
又、共有ハードウェア圧縮１５３０は、上述したような手段を使用して、圧縮されたビデオ／オーディオをパケット化し、そしてもし適当であれば、ＦＥＣコードを適用し、あるデータを複写し、又は他のステップを行って、ビデオ／オーディオデータストリームをクライアント４１５により受信しそしてできるだけ高いクオリティ及び信頼性で解凍するという能力を充分に確保するようにする。
以下に述べるような幾つかのアプリケーションでは、所与のａｐｐ／ｇａｍｅサーバー１５２１−１５２５のビデオ／オーディオ出力を同時に複数の解像度で（又は他の複数のフォーマットで）得られることが要求される。従って、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５が共有ハードウェア圧縮１５３０のリソースを通知する場合には、そのａｐｐ／ｇａｍｅサーバー１５２１−１５２５の非圧縮ビデオ／オーディオ１５２９が、異なるフォーマット、異なるリソース、及び／又は異なるパケット／エラー修正構造で同時に圧縮される。あるケースでは、幾つかの圧縮リソースを、同じビデオ／オーディオを圧縮する複数の圧縮プロセス間で共有することができる（例えば、多くの圧縮アルゴリズムには、圧縮を適用する前に映像を複数のサイズにスケーリングするステップがある。異なるサイズの映像を出力することが要求される場合に、このステップを使用して、一度に多数の圧縮プロセスに応じることができる）。他のケースでは、フォーマットごとに個別の圧縮リソースが要求される。いずれにせよ、所与のａｐｐ／ｇａｍｅサーバー１５２１−１５２５に要求される全ての種々の解像度及びフォーマットの圧縮されたビデオ／オーディオ１５３９は、（１つであっても多数であっても）アウトバウンドルーティング１５４０へ一度に出力される。一実施形態では、圧縮されたビデオ／オーディオ１５３９の出力はＵＤＰフォーマットであり、従って、パケットの位置方向性ストリームである。
アウトバウンドルーティングネットワーク１５４０は、圧縮された各ビデオ／オーディオストリームを、アウトバウンドインターネットトラフィック１５９９インターフェイス（これは、典型的に、インターネットへのファイバインターフェイスに接続される）を通して意図されたユーザ（１人又は複数）又は他の行先へ向け、及び／又は遅延バッファ１５１５へ戻し、及び／又はインバウンドルーティング１５０２へ戻し、及び／又はビデオ配布のためにプライベートネットワーク（図示せず）を通して向ける一連のルーティングサーバー及びスイッチを備えている。（以下に述べるように）アウトバウンドルーティング１５４０は、所与のビデオ／オーディオストリームを一度に複数の行先へ出力できることに注意されたい。一実施形態では、これは、一度に複数の行先へストリーミングされることが意図された所与のＵＤＰストリームをブロードキャストし、そしてこのブロードキャストをアウトバウンドルーティング１５４０内のルーティングサーバー及びスイッチにより繰り返すようなインターネットプロトコル（ＩＰ）マルチキャストを使用して具現化される。ブロードキャストの複数の行先は、インターネットを経て複数のユーザのクライアント４１５、インバウンドルーティング１５０２を経て複数のａｐｐ／ｇａｍｅサーバー１５２１−１５２５、及び／又は１つ以上の遅延バッファ１５１５である。従って、所与のサーバー１５２１−１５２２の出力は、１つ又は複数のフォーマットへ圧縮され、そして各圧縮されたストリームは、１つ又は複数の行先へ向けられる。
更に、別の実施形態では、複数のａｐｐ／ｇａｍｅサーバー１５２１−１５２５が１人のユーザにより同時に使用され（例えば、複雑なシーンの３Ｄ出力を生成するために並列処理構成で）そして各サーバーが出来上がる映像の一部分を発生する場合には、複数のサーバー１５２１−１５２５のビデオ出力を共有ハードウェア圧縮１５３０により合成フレームへと合成することができ、そしてその点以降は、それが単一のａｐｐ／ｇａｍｅサーバー１５２１−１５２５から到来したかのように、上述したように取り扱われる。
一実施形態では、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５により発生される全ビデオのコピー（少なくともユーザが見るビデオの解像度又はそれ以上）が、少なくとも数分（一実施形態では、１５分）、遅延バッファ１５１５に記録されることに注意されたい。これは、各ユーザが、以前の働き又は成績（ゲームの場合）を再検討するために各セッションからビデオを「巻き戻し」できるようにする。従って、一実施形態では、ユーザクライアント４１５へルーティングされる圧縮された各ビデオ／オーディオ出力１５３９のストリームは、遅延バッファ１５１５へもマルチキャストされる。ビデオ／オーディオが遅延バッファ１５１５に記憶されるときには、遅延バッファ１５１５のディレクトリが、遅延されたビデオ／オーディオのソースであるａｐｐ／ｇａｍｅサーバー１５２１−１５２５のネットワークアドレスと、遅延されたビデオ／オーディオを見つけることのできる遅延バッファ１５１５上の位置との間の相互参照を与える。
生の、瞬時に見られる、瞬時にプレイ可能なゲーム
ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、ユーザのための所与のアプリケーション又はビデオゲームを実行するのに使用できるだけでなく、ホスティングサービス２１０によるナビゲーション及び他の特徴をサポートするホスティングサービス２１０のためのユーザインターフェイスアプリケーションを生成するのにも使用できる。１つのこのようなユーザインターフェイスアプリケーションのスクリーンショットが図１６に示されており、即ち「ゲームファインダー」スクリーンである。この特定のユーザインターフェイススクリーンは、ユーザが、他のユーザにより生で（又は遅延されて）プレイされている１５のゲームを見ることができるようにする。１６００のような「サムネール」ビデオウインドウの各々は、動きのある生のビデオウインドウで、１人のユーザのゲームからのビデオを示している。サムネールに示される視野は、ユーザが見ている同じ視野でもよいし、遅延された視野でもよい（例えば、ユーザがコンバットゲームをプレイする場合、ユーザは、自分がどこに隠れているか他のユーザから見えるのを望まず、又、ゲームプレイの視野を、ある期間、例えば、１０分遅らせることを選択してもよい）。又、視野は、ユーザの視野とは異なるゲームのカメラ視野でもよい。メニュー選択肢（この図には示さず）を通して、ユーザは、種々の基準に基づいて、一度に見るゲームの選択を選ぶことができる。例示的選択の小さな例として、ユーザは、（図１６に示すような）ゲームのランダムな選択、（異なるプレーヤにより全てプレイされる）一種類の全てのゲーム、ゲームのトップランクプレーヤのみ、ゲームの所与のレベルのプレーヤ、低いランクのプレーヤ（例えば、プレーヤが基礎を学習している場合）、「相棒」（又はライバル）であるプレーヤ、視聴者の最も多いゲーム、等を選ぶことができる。
一般的に、各ユーザは、自分のゲーム又はアプリケーションからのビデオが他人に見られるかどうか判断し、もしそうであれば、どんな他人、いつ他人に見られるか、遅れて見られるだけかどうか、判断することに注意されたい。
図１６に示すユーザインターフェイススクリーンを発生するａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、ゲームが要求される各ユーザについてａｐｐ／ｇａｍｅサーバー１５２１−１５２５へメッセージを送信することにより１５個のビデオ／オーディオフィードを取得する。このメッセージは、インバウンドルーティング１５０２又は別のネットワークを通して送信される。このメッセージは、要求されたビデオ／オーディオのサイズ及びフォーマットを含み、ユーザインターフェイススクリーンを見ているユーザを識別する。所与のユーザは、「プライバシー」モードを選択し、他のユーザが彼のゲームのビデオ／オーディオを（彼の視点又は別の視点から）見るのを許さないことを選ぶか、或いは前記段落で述べたように、ユーザは、彼のゲームからのビデオ／オーディオを見るのを許すが、見るビデオ／オーディオを遅らせることを選んでもよい。ビデオ／オーディオを見ることを許すための要求を受け取って受け容れるユーザａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、要求側サーバーに確認を送り、共有ハードウェア圧縮１５３０に、要求されたフォーマット又はスクリーンサイズで付加的な圧縮されたビデオストリームを発生する要求も通知し（フォーマット及びスクリーンサイズが、既に発生されたものとは異なると仮定すれば）、そしてその圧縮されたビデオの行先（即ち、要求側サーバー）も指示する。要求されたビデオ／オーディオが遅延されるだけである場合には、要求側ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、そのように通知され、そして遅延バッファ１５１５のディレクトリにおけるビデオ／オーディオの位置と、遅延されたビデオ／オーディオのソースであるａｐｐ／ｇａｍｅサーバー１５２１−１５２５のネットワークアドレスとをルックアップすることにより、遅延バッファ１５１５から遅延されたビデオ／オーディオを取得する。これらの要求が全て発生されて処理されると、１５までの生のサムネールサイズのビデオストリームが、アウトバウンドルーティング１５４０から、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５へのインバウンドルーティング１５０２へルーティングされて、ユーザインターフェイススクリーンを発生し、そしてサーバーにより解凍されて表示される。遅延されたビデオ／オーディオストリームは、スクリーンサイズが大き過ぎることがあり、もしそうであれば、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、ストリームを解凍して、ビデオストリームをサムネールサイズへスケールダウンする。一実施形態では、オーディオ／ビデオのための要求が、図４ａのホスティングサービス制御システムと同様の中央「管理」サービス（図１５には示さず）へ送られ（及びそれにより管理され）、これは、次いで、その要求を適当なａｐｐ／ｇａｍｅサーバー１５２１−１５２５へ向け直す。更に、一実施形態では、サムネールが、それを許すユーザのクライアントへ「プッシュ」されるので、要求が発せられないこともある。
全て同時に混合される１５個のゲームからのオーディオは、不快な音を発することがある。ユーザは、このように全ての音を一緒に混合することを選んでもよいし（おそらく、見ている全てのアクションにより生じる騒音の感覚を単に得るために）、又はユーザは、一度に１つのゲームからのオーディオのみを聞くことを選んでもよい。単一ゲームの選択は、黄色の選択ボックス１６０１（図１６の白黒レンダリングでは、黒い長方形の輪郭として現われる）を所与のゲームへ移動することにより達成される（黄色のボックスの移動は、キーボード上の矢印キーを使用するか、マウスを移動するか、ジョイスティックを動かすか、又は移動電話のような別の装置の方向ボタンを押すことにより達成できる）。単一のゲームが選択されると、そのゲームからのオーディオだけが再生される。又、ゲーム情報１６０２も示される。このゲームの場合には、例えば、発行者ロゴ（例えば、「電子アートについては、“ＥＡ”）及びゲームロゴ、例えば、“Need for Speed Carbon”、及びオレンジの水平バー（図１６では、縦縞をもつバーとしてレンダリングされる）は、その特定の瞬間にゲームをプレイするか又は見ている人々の数を相対的な表現で指示する（この場合は、多数、従って、ゲームは、「ホット」）。更に、「スタッツ(Stats)」（即ち、統計値）も設けられ、これは、１４５人のプレーヤがNeed for Speed Gameの８０個の異なるインスタンス化を能動的にプレイしており（即ち、個人プレーヤゲーム又はマルチプレーヤゲームのいずれかによりプレイできる）、そして６８０人の視聴者がいる（このユーザは、そのうちの１人である）ことを示している。これらの統計値（及び他の統計値）は、ホスティングサービス２１０のオペレーションのログを保持すると共に、ユーザに適宜請求し、又、コンテンツを提供する発行者に支払するために、ホスティングサービス制御システム４０１により収集され、そしてＲＡＩＤアレイ１５１１−１５１２に記憶される。統計値のあるものは、サービス制御システム４０１によりアクションによって記録され、そしてあるものは、個々のａｐｐ／ｇａｍｅサーバー１５２１−１５２５によりサービス制御システム４０１へ報告される。例えば、この「ゲームファインダー」アプリケーションを実行するａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、ゲームを見ているとき（及びゲームを見終えたとき）ホスティングサービス制御システム４０１へメッセージを送信し、どれほど多くのゲームが見られているかの統計値を更新できるようにする。統計値のあるものは、この「ゲームファインダー」アプリケーションのようなユーザインターフェイスアプリケーションに利用される。
ユーザは、入力装置のアクチベーションボタンをクリックした場合に、フルスクリーンサイズへの生のビデオのプレイを続けながら黄色のボックス内のサムネールビデオをズームアップして見ることができる。この効果が図１７のプロセスに示されている。ビデオウインドウ１７００は、サイズが増大していることに注意されたい。この効果を具現化するために、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、選択されたゲームを実行しているａｐｐ／ｇａｍｅサーバー１５２１−１５２５から、そこにルーティングされたゲームのフルスクリーンサイズのビデオストリームのコピーを取ることを要求する（ユーザのディスプレイ装置４２２の解像度で）。ゲームを実行しているａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、共有ハードウェアコンプレッサ１５３０に、ゲームのサムネールサイズのコピーがもはや必要ない（別のａｐｐ／ｇａｍｅサーバー１５２１−１５２５がそのようなサムネールを要求しない限り）ことを通知し、次いで、ビデオのフルスクリーンサイズコピーを、ビデオをズームしているａｐｐ／ｇａｍｅサーバー１５２１−１５２５へ送信することを指令する。ゲームをプレイしているユーザは、ゲームをズームアップしているユーザと同じ解像度のディスプレイ装置４２２を有していても、いなくてもよい。更に、ゲームを見る他の者も、ゲームをズームアップしているユーザと同じ解像度のディスプレイ装置４２２を有していても、いなくてもよい（且つ異なるオーディオ再生手段、例えば、ステレオ又はサラウンドサウンドを有してもよい）。従って、共有ハードウェアコンプレッサ１５３０は、ビデオ／オーディオストリームを要求しているユーザの要件を満足する適当に圧縮されたビデオ／オーディオストリームが既に発生されたかどうか決定し、もしそれが存在する場合には、ビデオをズームしているａｐｐ／ｇａｍｅサーバー１５２１−１５２５へストリームのコピーをルーティングするようにアウトバウンドルーティング１５４０に通知し、又、もしそうでなければ、そのユーザに適したビデオの別のコピーを圧縮して、ビデオをズームしているａｐｐ／ｇａｍｅサーバー１５２１−１５２５及びインバウンドルーティング１５０２へストリームを返送するようにアウトバウンドルーティングに命令する。選択されたビデオのフルスクリーンバージョンを現在受信しているこのサーバーは、それを解凍し、フルサイズまで徐々にスケールアップする。
図１８は、ゲームがフルスクリーンへ完全にズームアップされた後にスクリーンがどのように見えるか示しており、ゲームは、矢印１８００で指された映像により示すように、ユーザのディスプレイ装置４２２の全解像度で示されている。ゲームファインダーアプリケーションを実行しているａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、もはや必要でないサムネールを発生した他のａｐｐ／ｇａｍｅサーバー１５２１−１５２５へメッセージを送信すると共に、他のゲームがもはや見られていないホスティングサービス制御サーバー４０１へメッセージを送信する。この点において、発生される表示は、スクリーンの頂部にあって、情報及びメニュー制御をユーザに与えるオーバーレイ１８０１である。このゲームが進行するにつれて、観衆は、２５０３人の視聴者まで増加したことに注意されたい。このように大勢の視聴者では、同じ又はほぼ同じ解像度をもつディスプレイ装置４２２に大勢の視聴者が結び付けられる（各ａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、適合性を調整するためにビデオをスケーリングする能力を有する）。
図示されたゲームは、マルチプレーヤゲームであるから、ユーザは、ある点でゲームに加わることを決定できる。ホスティングサービス２１０は、種々の理由で、ユーザがゲームに加わるのを許しても許さなくてもよい。例えば、ユーザは、ゲームをプレイするために支払しなければならず、又、プレイしないことを選んでもよく、ユーザは、その特定のゲームに加わるに充分なランキングを有していないことがあり（例えば、他のプレーヤとの競争に耐えない）、或いはユーザのインターネット接続は、ユーザがプレイするのに充分な短い待ち時間を有していないことがある（例えば、ゲームを見るための待ち時間制約がなく、従って、遠くで（実際上、別の大陸で）プレイされるゲームを、待ち時間の問題なしに見ることはできるが、プレイするゲームについては、待ち時間は、（ａ）ゲームを楽しむために、及び（ｂ）短い待ち時間接続を有する他のプレーヤと平等の立場であるために、ユーザにとって充分短いものでなければならない）。ユーザがプレイを許された場合には、ユーザに対して「ゲームファインダー」ユーザインターフェイスを与えたａｐｐ／ｇａｍｅサーバー１５２１−１５２５は、ホスティングサービス制御サーバー４０１が、特定のゲームをプレイするために適当に構成されたａｐｐ／ｇａｍｅサーバー１５２１−１５２５を始動して（即ち、探索し始動して）、ＲＡＩＤアレイ１５１１−１５１２からゲームをロードし、次いで、ホスティングサービス制御サーバー４０１が、ゲームを現在ホストしているａｐｐ／ｇａｍｅゲームサーバーへユーザから制御信号を転送するようにインバウンドルーティング１５０２に命令すると共に、「ゲームファインダー」アプリケーションをホストしたａｐｐ／ｇａｍｅサーバーからのビデオ／オーディオを圧縮することから、ゲームを現在ホストしているａｐｐ／ｇａｍｅサーバーからのビデオ／オーディオを圧縮することへスイッチするように共有ハードウェアコンプレッサ１５３０に命令することを要求する。「ゲームファインダー」ａｐｐ／ｇａｍｅサービス、及びゲームをホストしている新たなａｐｐ／ｇａｍｅサーバーの垂直同期は、同期されず、その結果、２つの同期間におそらく時間差が生じる。共有ビデオ圧縮ハードウェア１５３０は、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５がビデオフレームを完成したときにビデオの圧縮を開始するので、新たなサーバーからの第１のフレームは、古いサーバーのフルフレーム時間より早期に完成され、これは、その手前の圧縮されたフレームがその送信を完了する前である（例えば、図９ｂの送信時間９９２を考えると、非圧縮フレーム３ ９６３がフレーム時間の半分早期に完成された場合に、送信時間９９２に影響を及ぼす）。このような状況では、共有ビデオ圧縮ハードウェア１５３０は、新たなサーバーからの第１のフレームを無視し（例えば、フレーム４ ９６４が無視される(９７４)のと同様に）、クライアント４１５は、古いサーバーからの最後のフレームを特別のフレーム時間中保持し、そして共有ビデオ圧縮ハードウェア１５３０は、ゲームをホストする新たなａｐｐ／ｇａｍｅサーバーからの次のフレーム時間ビデオの圧縮を開始する。視覚上、あるａｐｐ／ｇａｍｅサーバーから他のａｐｐ／ｇａｍｅサーバーへの移行は、シームレスである。ホスティングサービス制御サーバー４０１は、次いで、「ゲームファインダー」をホストしていたａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５に、それが再び必要になるまでアイドル状態にスイッチするように通知する。
次いで、ユーザは、ゲームをプレイすることができる。そして、何が優れているかと言えば、ゲームは、知覚上即座にプレイされ（ギガビット／秒の速度でＲａｉｄアレイ１５１１−１５１２からａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５にロードされるので）、そしてゲームは、理想的なドライバ、レジストリ構成（Ｗｉｎｄｏｗｓの場合）をもち、且つゲームのオペレーションと競合し得るサーバーで実行される他のアプリケーションをもたずに、ゲームに対して厳密に構成されたオペレーティングシステムと一緒にゲームに厳密に適したサーバーにロードされる。
又、ユーザがゲームを通して進行するにつれて、ゲームの各セグメントが、ＲＡＩＤアレイ１５１１−１５１２からギガビット／秒の速度でサーバーへロードされ（即ち、１ギガバイトの負荷が８秒で）、そしてＲＡＩＤアレイ１５１１−１５１２の膨大な記憶容量のために（これは多数のユーザ間の共有リソースであるから、非常に大きく、又、コスト効率がよい）、幾何学的な設定又は他のゲームセグメント設定を予め計算して、ＲＡＩＤアレイ１５１１−１５１２に記憶し、そして非常に迅速にロードすることができる。更に、各ａｐｐ／ｇａｍｅサーバー１５２１−１５２５のハードウェア構成及び計算能力が既知であるから、ピクセル及び頂点シェーダーを予め計算することができる。
従って、ゲームは、ほぼ瞬間的に始動し、理想的な環境で実行され、そしてその後のセグメントがほぼ瞬間的にロードされる。
しかし、これらの効果を越えて、ユーザは、ゲームをプレイする他人を見ることができ（上述した「ゲームファインダー」及び他の手段を経て）、そしてゲームに関心があるかどうか判断し、もしそうであれば、他人を見ることから秘訣を学習することができる。そして、ユーザは、大きなダウンロード及び／又はインストールを待機する必要なく、ゲームを瞬時にデモすることができ、又、ユーザは、おそらく、僅かな費用の試行ベースで、又は長期間ベースで、ゲームを瞬時にプレイすることができる。そして、ユーザは、ゲームを、ウインドウズＰＣ、マッキントッシュ、家のＴＶ受像機で、又、旅行中も、移動電話で、充分短い待ち時間のワイヤレス接続によりプレイすることができる（見物するだけでは、待ち時間は問題にならないが）。又、これは、全て、ゲームのコピーを物理的に所持せずに行うことができる。
上述したように、ユーザは、自分のゲームプレイを他人に見られることを許さないか、自分のゲームを遅延の後に見られるのを許すか、自分のゲームを選択されたユーザにより見られるのを許すか、又は自分のゲームを全てのユーザにより見られるのを許すかを判断することができる。それにも関わらず、ビデオ／オーディオは、一実施形態では、１５分間、遅延バッファ１５１５に記憶され、そしてユーザは、デジタルビデオレコーダ（ＤＶＲ）でＴＶを見ていたときに行うことができたのと同様に、自分の以前のゲームプレイを「巻き戻して」見ることができ、又、休止し、スローで再生し、早送りし、等々を行うことができる。この例では、ユーザは、ゲームをプレイするが、ユーザがアプリケーションを使用する場合には、同じ“ＤＶＲ”能力を利用することができる。これは、以前の行動を再検討すること及び以下に述べる他のアプリケーションでも有用である。更に、カメラの視野を変更できる、等のように、ゲーム状態情報の利用に基づいて巻き戻することができるようにゲームが設計されている場合は、この“３Ｄ ＤＶＲ”能力もサポートされるが、それをサポートするようにゲームを設計することが要求される。遅延バッファ１５１５を使用する“ＤＶＲ”能力は、もちろん、ゲーム又はアプリケーションが使用されたときに発生するビデオに限定して、ゲーム又はアプリケーションと共に機能するが、３Ｄ ＤＶＲ能力をもつゲームの場合には、ユーザは、以前にプレイしたセグメントの３Ｄにおける「フライスルー(fly through)」を制御することができ、そしてそれにより得られるビデオを遅延バッファ１５１５で記録させ、ゲームセグメントのゲーム状態を記録させることができる。従って、特定の「フライスルー」が、圧縮されたビデオとして記録されるが、ゲーム状態も記録されるので、後日、ゲームの同じセグメントについて異なるフライスルーが考えられることになる。
以下に述べるように、ホスティングサービス２１０におけるユーザは、各々、彼等に関する情報及び他のデータを掲示することのできる「ユーザページ」を有する。ユーザが掲示することのできるものの中には、彼等がセーブしたゲームプレイからのビデオセグメントがある。例えば、ユーザがゲームにおいて特に困難な挑戦を克服した場合には、ユーザは、ゲームにおいて偉大な成果をなし得た点の直前まで「巻き戻し」、次いで、他のユーザが見るために、ある時間巾（例えば、３０秒）のビデオセグメントをユーザの「ユーザページ」にセーブするようにホスティングサービス２１０に命令することができる。これを達成するには、ユーザが、遅延バッファ１５１５に記憶されたビデオをＲＡＩＤアレイ１５１１−１５１２へ再生してユーザの「ユーザページ」においてそのビデオセグメントをインデックスするように使用するという、単なるａｐｐ／ｇａｍｅサーバー１５２１−１５２５の問題である。
ゲームが、上述した３Ｄ ＤＶＲの能力を有する場合には、３Ｄ ＤＶＲに要求されるゲーム状態情報もユーザによって記録して、ユーザの「ユーザページ」に利用することができる。
能動的なプレーヤに加えて「観客」（即ち３Ｄの世界を進んで、アクションに関与せずにそれを観察できるユーザ）をもつようにゲームが設計されている場合には、「ゲームファインダー」アプリケーションは、ユーザが観客及びプレーヤとしてゲームに加わることができるようにする。具現化の視点から、ユーザが能動的なプレーヤではなく観客である場合も、ホスティングシステム２１０に対して差はない。ゲームは、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５にロードされ、そしてユーザは、ゲームを制御する（例えば、世界を見るバーチャルカメラを制御する）。唯一の相違は、ユーザのゲーム経験である。
複数ユーザの協力
ホスティングサービス２１０の別の特徴は、複数のユーザが、大きく異なる視聴装置を使用していても、生のビデオを見ながら協力する能力である。これは、ゲームをプレイするとき及びアプリケーションを使用するときの両方に有用である。
多くのＰＣ及び移動電話は、ビデオカメラを装備しており、且つ特に、映像が小さいときには、リアルタイム映像圧縮を行う能力を有している。又、テレビに取り付けることのできる小型カメラも入手でき、リアルタイム圧縮を、ソフトウェアで具現化するか、又はビデオを圧縮するための多数のハードウェア圧縮装置の１つを使用して具現化するのは、困難なことではない。又、多数のＰＣ及び全ての移動電話は、マイクロホンを有し、又、マイクロホンと共にヘッドセットが利用できる。
このようなカメラ及び／又はマイクロホンは、ローカルのビデオ／オーディオ圧縮能力（特に、ここに述べる短待ち時間のビデオ圧縮技術を使用する）と合成されると、ユーザが、ユーザの家屋２１１からのビデオ及び／又はオーディオを入力装置の制御データと共にホスティングサービス２１０へ送信できるようにする。このような技術が使用されるときには、図１９に示す能力を達成でき、即ちユーザは、自分のビデオ及びオーディオ１９００を別のユーザのゲーム又はアプリケーション内のスクリーンに出現させることができる。この例は、カーレースにおいてチームメートが協力するマルチプレーヤゲームである。ユーザのビデオ／オーディオは、チームメートだけにより選択的に見る／聞くことができる。そして、実質上、待ち時間がないので、上述した技術を使用すると、プレーヤは、気付くほどの遅延を伴うことなく、互いにリアルタイムで話したり動いたりすることができる。
このビデオ／オーディオの一体化は、ユーザのカメラ／マイクロホンからの圧縮されたビデオ及び／又はオーディオをインバウンドインターネットトラフィック１５０１として到着させることにより達成される。次いで、インバウンドルーティング１５０２が、ビデオ及び／又はオーディオを、それを見る／聞くことが許されたａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５へルーティングする。次いで、ビデオ及び／又はオーディオを使用することを選択する各ａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５のユーザは、それを解凍し、そして１９００で示されたように、必要に応じて、ゲーム又はアプリケーション内に現れるように一体化する。
図１９の例は、このような協力がゲームにおいてどのように利用されるか示しているが、このような協力は、アプリケーションにとって非常にパワフルなツールである。ニューヨーク市ではニューヨークに本拠地を置く不動産開発業者のためにシカゴの建築家により大きなビルが設計されているが、その判断には、旅行中でマイアミの空港にたまたまいる金融投資家が含まれ、そして投資家と不動産開発業者の両方を満足させるために、周囲のビルにどのように調和させるかに関してそのビルの幾つかの設計要素について判断をする必要がある状況を考える。建設会社は、シカゴにおいてカメラがＰＣに取り付けられた高解像度モニタを有し、不動産開発業者は、ニューヨークにおいてカメラ付きのラップトップを有し、そして投資家は、マイアミにおいてカメラ付きの移動電話を有している。建設会社は、ホスティングサービス２１０を使用して、非常に現実的な３Ｄレンダリングを行うことのできるパワフルな建設設計アプリケーションをホストすることができ、ニューヨーク市内のビルの大きなデータベース及び設計中のビルのデータベースを使用することができる。建設設計アプリケーションは、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５の１つで実行され、又は多大な計算パワーを要求する場合には、その幾つかにおいて実行される。異なる位置にいる３人のユーザの各々は、ホスティングサービス２１０に接続され、そしてその各々は、建設設計アプリケーションのビデオ出力の同時ビューを有するが、これは、各ユーザが有する所与の装置及びネットワーク接続特性に対して共有ハードウェア圧縮１５３０により適当なサイズにされる（例えば、建設会社は、２０Ｍｂｐｓの商業的インターネット接続を通して２５６０ｘ１４４０の６０ｆｐｓディスプレイを見ることができ、ニューヨークの不動産開発業者は、自分のラップトップの６ＭｂｐｓのＤＳＬ接続を経て１２８０ｘ７２０の６０ｆｐｓ映像を見ることができ、そして投資家は、自分の移動電話の２５０Ｋｂｐｓのセルラーデータ接続を経て３２０ｘ１８０の６０ｆｐｓ映像を見ることができる。各当事者は、他の当事者の音声を聞き（会議コールは、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５において広く利用できる多数の会議コールソフトウェアパッケージのいずれかにより取り扱われ）、そしてユーザ入力装置上のボタンの操作を通して、ユーザは、ローカルカメラを使用してそれら自身のビデオ出演をすることができる。ミーティングが進むにつれて、建築家は、そのビルを回転し且つそのエリアの他のビルの近くを飛行したときにそのビルがどのように見えるか、非常にホトリアルな３Ｄレンダリングで示すことができ、そして同じビデオを、各当事者のディスプレイ装置の解像度で全ての当事者が見ることができる。当事者により使用されるローカル装置が、どれも、このようなリアリズムで３Ｄアニメーションを取り扱いできないことは問題ではないが、ニューヨーク市の周囲のビルをレンダリングするために要求される膨大なデータベースをダウンロードするか又は記憶することは言うまでもない。各ユーザの視点から、距離が離れているにも関わらず、又、異なるローカル装置であるにも関わらず、ユーザは、単純に、信じられないほどのリアリズムで繋ぎ目のない経験をする。そして、１人の当事者が顔を見えるようにして感情を良く伝えたいときには、そのようにすることができる。更に、不動産開発業者又は投資家のいずれかが建設プログラムの制御を手に入れてそれら自身の入力装置（キーボード、マウス、キーパッド又はタッチスクリーン）を使用したい場合には、知覚上待ち時間なしに応答でき、又、応答することになる（それらのネットワーク接続が不合理な待ち時間をもたないと仮定して）。例えば、移動電話の場合には、その移動電話が空港のＷｉＦｉネットワークに接続された場合には、待ち時間が非常に短くなる。しかし、米国で今日利用できるセルラーデータネットワークを使用する場合には、おそらく、顕著な遅れで悩まされることになる。更に、投資家が見ているミーティングのほとんどの目的では、建築家がビルの接近飛行を制御し、又はビデオ遠隔会議で話をするためには、セルラー待ち時間でも許容できねばならない。
最終的に、協力会議コールの終わりに、不動産開発業者及び投資家は、ホスティングサービスから彼等のコメントを発し且つ署名し、建設会社は、遅延バッファ１５１５に記録された会議のビデオを「巻き戻し」、そしてコメント、顔の表情、及び／又はミーティング中に作られたビルの３Ｄモデルに加えられたアクションを再検討することができる。セーブしたい特定のセグメントがある場合は、ビデオ／オーディオのそれらセグメントを、記録保管及び後で再生するために遅延バッファ１５１５からＲＡＩＤアレイ１５１１−１５１２へ移動することができる。
又、コストの観点から、建築家が計算パワー及びニューヨーク市の大きなデータベースを１５分の会議コールにしか使用する必要がない場合には、ハイパワーのワークステーションを所有し且つ大きなデータベースの高価なコピーを購入するのではなく、リソースを使用した時間について支払するだけでよい。
ビデオリッチなコミュニティサービス
ホスティングサービス２１０は、インターネットにビデオリッチなコミュニティサービスを確立するための空前の機会を可能にする。図２０は、ホスティングサービス２１０におけるゲームプレーヤのための規範的「ユーザページ」を示す。「ゲームファインダー」アプリケーションと同様に、「ユーザページ」は、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５の１つにおいて実行されるアプリケーションである。このページにおけるサムネール及びビデオウインドウは、全て、絶えず動くビデオ（セグメントが短い場合は、ループになる）を示す。
ビデオカメラを使用するか、又はビデオをアップロードすることにより、ユーザ（ユーザ名は“ＫＩＬＬＨＡＺＡＲＤ”である）は、自分自身のビデオ２０００を掲示することができ、他のユーザがこれを見ることができる。このビデオは、ＲＡＩＤアレイ１５１１−１５１２に記憶される。又、他のユーザがＫＩＬＬＨＡＺＡＲＤの「ユーザページ」に到来するときに、ＫＩＬＬＨＡＺＡＲＤがそのときホスティングサービス２１０を使用していれば、（ユーザが彼を見るために彼の「ユーザページ」を見ることを許すと仮定すれば）彼が何を行おうとその生のビデオ２００１が示される。これは、サーバー制御システム４０１から要求される「ユーザページ」アプリケーションをホストするａｐｐ／ｇａｍｅサーバー１５２１−１５２５により達成され、ＫＩＬＬＨＡＺＡＲＤがアクティブであるかどうか、そしてもしそうであれば、彼が使用するａｐｐ／ｇａｍｅサーバー１５２１−１５２５により達成される。次いで、「ゲームファインダー」アプリケーションにより使用される同じ方法を使用して、適当な解像度及びフォーマットの圧縮されたビデオストリームが、「ユーザページ」アプリケーションを実行するａｐｐ／ｇａｍｅサーバー１５２１−１５２５へ送信され、そして表示される。ユーザがＫＩＬＬＨＡＺＡＲＤの生のゲームプレイでウインドウを選択し、次いで、その入力装置を適当にクリックする場合は、ウインドウがズームアップされ（この場合も「ゲームファインダー」アプリケーションと同じ方法を使用して）、そして生のビデオが、見ているユーザのインターネット接続の特性に適した、見ているユーザのディスプレイ装置４２２の解像度でスクリーンを埋める。
従来に勝るこの解決策の重要な効果は、「ユーザページ」を見ているユーザが、自分が所有していないゲームの生のプレイを見ることができ、且つ非常に良いことに、ゲームをプレイできるローカルコンピュータ又はゲームコンソールをもたなくてよいことである。これは、ゲームをプレイする「アクション中」である「ユーザページ」に示されたユーザをユーザが見る良い機会を与えると共に、見ているユーザが試してみたい又は上手くなりたいゲームに関して学習する機会でもある。
ＫＩＬＬＨＡＺＡＲＤの相棒２００２からのカメラ記録又はアップロードされたビデオクリップも「ユーザページ」に示され、そして各ビデオクリップの下には、相棒がオンラインでゲームをプレイしているかどうか示すテキストがある（例えば、ｓｉｘ＿ｓｈｏｔは、ゲーム“Ｅｒａｇｏｎ”をプレイしており（ここでは、Ｇａｍｅ４として示す）、ＭｒＳｎｕｇｇｌｅｓ９９は、オフラインであり、等）。メニューアイテム（図示せず）をクリップすることにより、相棒のビデオクリップは、記録又はアップロードされたビデオを示すものから、ホスティングサービス２１０上で現在ゲームをプレイしている相棒がそのときゲームにおいて何をしているかの生のビデオへとスイッチする。従って、これは、相棒のためのゲームファインダーグループとなる。相棒のゲームが選択されそしてユーザがそれをクリックする場合には、全スクリーンをズームアップし、そしてユーザは、全スクリーンでプレイされるゲームを生で見ることができる。
この場合も、相棒のゲームを見ているユーザは、ゲームのコピーも、ゲームをプレイするためのローカルコンピューティング／ゲームコンソールリソースも、所有していない。ゲームを見るのは、実際上、瞬間的である。
上述したように、ユーザがホスティングサービス２１０においてゲームをプレイするときには、ユーザは、ゲームを「巻き戻し」、セーブしたいビデオセグメントを見出し、次いで、ビデオセグメントを自分の「ユーザページ」へセーブする。これらは、「自慢のクリップ(Brag Clips)(TM)」と称される。ビデオセグメント２００３は、全て、プレイした以前のゲームからＫＩＬＬＨＡＺＡＲＤによりセーブされた「自慢のクリップ」２００３である。番号２００４は、「自慢のクリップ」が何回見られたかを示し、そして「自慢のクリップ」が見られるときに、ユーザは、それを格付けする機会を得、オレンジ（ここでは黒の輪郭として示す）のキー穴形状のアイコン２００５の数は、どれほど高い格付けであるかを示す。「自慢のクリップ」２００３は、ユーザが「ユーザページ」を見るとき、そのページにおけるビデオの残りと共に絶えずループする。ユーザが「自慢のクリップ」２００３の１つを選択してクリックする場合には、それがズームアップし、「自慢のクリップ」２００３を、クリップの再生、休止、巻き戻し、早送り、ステップスルー、等を行えるようにするＤＶＲコントロールと共に提示する。
「自慢のクリップ」２００３の再生は、ユーザが「自慢のクリップ」を記録し、それを解凍して再生するときに、ＲＡＩＤアレイ１５１１−１５１２に記憶された圧縮ビデオセグメントをａｐｐ／ｇａｍｅサーバー１５２１−１５２５がロードすることにより具現化される。
又、「自慢のクリップ」２００３は、“３Ｄ ＤＶＲ”ビデオセグメント（即ち、再生でき且つユーザがカメラの視点を変更するのを許すゲームからのゲーム状態シーケンス）でもあり、これは、そのような能力をサポートするゲームからのものである。この場合、ゲームセグメントが記録されたときにユーザが作った特定の「フライスルー」の圧縮ビデオ記録に加えて、ゲーム状態情報が記憶される。「ユーザページ」が見られ、そして全てのサムネール及びビデオウインドウが絶えずループ化するときには、３Ｄ ＤＶＲ「自慢のクリップ」２００３は、ユーザがゲームセグメントの「フライスルー」を記録したときに圧縮ビデオとして記録された「自慢のクリップ」２００３を絶えずループ化する。しかし、ユーザが３Ｄ ＤＶＲ「自慢のクリップ」２００３を選択してそれをクリップするときには、圧縮ビデオの「自慢のクリップ」を再生できるようにするＤＶＲコントロールに加えて、ユーザは、ゲームセグメントに対する３Ｄ ＤＶＲ能力を与えるボタンをクリックすることができる。それらは、彼等自身でゲームセグメント中にカメラの「フライスルー」を制御することができ、そしてそれらが望む（及びユーザページを所有するユーザがそれを許す）場合に、別の「自慢のクリップ」の「フライスルー」を圧縮ビデオ形態で記録することができ、これは、次いで、ユーザページの他の視聴者に利用可能となる（直ちに、又はユーザページの所有者が「自慢のクリップ」を再検討する機会をもった後に）。
この３Ｄ ＤＶＲ「自慢のクリップ」２００３の能力は、記録されたゲーム状態情報を別のａｐｐ／ｇａｍｅサーバー１５２１−１５２５において再生しようとしているゲームを作動することによりイネーブルされる。ゲームは、ほぼ瞬間的に作動できるので（上述したように）、「自慢のクリップ」により記録されたゲーム状態にプレイを限定してゲームを作動し、次いで、ユーザが、圧縮ビデオを遅延バッファ１５１５に記録しながらカメラで「フライスルー」を実行できるようにするのは、困難ではない。ユーザが「フライスルー」の実行を完了すると、ゲームが不作動にされる。
ユーザの視点から、３Ｄ ＤＶＲの「自慢のクリップ」２００３で「フライスルー」を作動することは、リニアな「自慢のクリップ」２００３のＤＶＲコントロールを制御することより努力が要らない。それらは、ゲームについて又はゲームをどのようにプレイするかについて何も知らなくてよい。それらは、別の者により記録されるゲームセグメント中に３Ｄ世界を凝視するバーチャルカメラオペレータに過ぎない。
又、ユーザは、それら自身のオーディオを、マイクロホンから記録されるか又はアップロードされる「自慢のクリップ」にオーバーダビングすることもできる。このようにして、「自慢のクリップ」は、ゲームからのキャラクタ及びアクションを使用して、カスタムアニメーションを生成するのに使用できる。このアニメーション技術は、「マシニマ(machinima)」として一般に知られている。
ユーザがゲームを進めるにつれて、異なるスキルレベルを達成する。プレイしたゲームは、達成度をサービスコントロールシステム４０１へ報告し、それらのスキルレベルが「ユーザページ」に示される。
双方向アニメ化広告
オンライン広告は、テキストから、静止映像へ、ビデオへ、そして今や、Ａｄｏｂｅ Ｆｌａｓｈのようなアニメーションシンクライアントを使用して典型的に具現化される双方向セグメントへと推移してきた。アニメーションシンクライアントを使用する理由は、ユーザが、典型的に、製品やサービスが彼等に推薦される特典に対する遅れが耐え難いからである。又、シンクライアントは、非常に低性能のＰＣで実行され、従って、広告主は、双方向アドが適切に機能するという高い信頼度をもつことができる。不都合なことに、Ａｄｏｂｅ Ｆｌａｓｈのようなアニメーションシンクライアントは、双方向性の度合い及び経験の巾が制限される（ダウンロード時間を軽減し、そしてＧＰＵをもたない低性能ＰＣ及びＭａｃ、又は高性能ＣＰＵを含むほぼ全てのユーザ装置で動作するために）。
図２１は、ショールーム内で車を回転させ、車がどのように見えるかリアルタイムレイトレーシングで示しながら、ユーザが車の外部及び内部の色を選択する双方向広告を示している。ユーザは、車を運転するアバターを選択し、次いで、ユーザは、レーストラック上、又はモナコのようなエキゾチックな場所でドライブするように車を取り出すことができる。ユーザは、より大きなエンジン又はより優れたタイヤを選択することができ、次いで、その変更した構成が車の加速性能又は路面の食い付きにどのように影響するか見ることができる。
もちろん、広告は、実際上、精巧な３Ｄビデオゲームである。しかし、ＰＣ又はビデオゲームコンソール上に再生できる広告については、おそらく、１００ＭＢダウンロードを要求し、そしてＰＣの場合には、特殊なドライバのインストールを要求すると共に、ＰＣが充分なＣＰＵ又はＧＰＵ計算能力に欠ける場合には全く実行されないことがある。従って、このような広告は、従来の構成では不可能である。
ホスティングサービス２１０では、このような広告は、ほぼ瞬時に起動し、そしてユーザのクライアント４１５の能力がどんなものであっても、完全に実行される。従って、それらは、シンクライアント双方向アドより素早く起動し、著しく経験に富み、且つ非常に信頼性が高い。
リアルタイムアニメーション中のストリーミング幾何学形状
ＲＡＩＤアレイ１５１１−１５１２及びインバウンドルーティング１５０２は、リアルタイムアニメーション（例えば、複雑なデータベースを伴うフライスルー）中にゲームプレイ又はアプリケーションの中間において幾何学形状をオンザフライで確実に配信するためにＲＡＩＤアレイ１５１１−１５１２及びインバウンドルーティング１５０２に依存するビデオゲーム及びアプリケーションを設計できるように高速で且つ短待ち時間のデータレートを与えることができる。
図１に示すビデオゲームシステムのような従来のシステムでは、特に実際の家庭用装置に使用できる大量記憶装置は、要求される幾何学形状をある程度予想できる状況を除き、ゲームプレイ中に幾何学形状をストリームするには遥かに低速である。例えば、特定の道路が存在するドライブゲームにおいて、視野に入って来るビルの幾何学形状は、合理的に充分なほど予想でき、そして大量記憶装置は、近づきつつある幾何学形状が位置している場所を前もって探すことができる。
しかし、予想できない変化を伴う複雑なシーンにおいて（例えば、あたり一面に複雑なキャラクタが存在する戦闘のシーンにおいて）、ＰＣ又はビデオゲームシステムのＲＡＭが、現在視野にある物体に対する幾何学形状で完全に埋められており、次いで、ユーザが突然それらのキャラクタを、それらキャラクタの背後の視野へ方向転換する場合に、幾何学形状がＲＡＭに予めロードされていなければ、それを表示できるまでに遅延が生じることになる。
ホスティングサービス２１０において、ＲＡＩＤアレイ１５１１−１５１２は、ギガビットイーサネット速度以上でデータをストリームすることができ、そしてＳＡＮネットワークでは、１０ギガビットのイーサネット又は他のネットワークに勝る１０ギガビット／秒の速度を達成することができる。１０ギガビット／秒は、ギガバイトのデータを１秒未満でロードする。６０ｆｐｓのフレーム時間（１６．６７ｍｓ）では、ほぼ１７０メガビット（２１ＭＢ）のデータをロードすることができる。当然、ＲＡＩＤ構成にある回転するメディアは、１フレーム時間より大きな待ち時間を依然被るが、フラッシュベースのＲＡＩＤ記憶装置は、結局、回転するメディアＲＡＩＤアレイと同程度の大きさであり、そのような長い待ち時間は被らない。一実施形態では、大量ＲＡＭライトスルーキャッシングを使用して、非常に短い待ち時間のアクセスを与える。
従って、充分に高いネットワーク速度及び充分に短い待ち時間の大量記憶では、ＣＰＵ及び／又はＧＰＵが３Ｄデータを処理できるのと同程度の速さでａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５へ幾何学形状をストリームすることができる。従って、ユーザがそのキャラクタを突然方向転換しそして後を見る上述した例では、後方の全てのキャラクタに対する幾何学形状を、キャラクタが回転を完了する前にロードすることができ、従って、ユーザにとって、生のアクションと同程度にリアルなホトリアルな世界にいるかのように思える。
上述したように、ホトリアルなコンピュータアニメーションにおける最後の未開拓の１つは、人間の顔であり、不完全さに対して人間の目が敏感であるために、ホトリアルな顔からの若干のエラーが視聴者から否定的なリアクションを招くことがある。図２２は、ＣｏｎｔｏｕｒTM「リアリティキャプチャーテクノロジー」（本ＣＩＰ出願の譲受人に各々譲渡された同時係争中の特許出願、即ち２００４年９月１５日に出願された第１０／９４２，６０９号“Apparatus and method for capturing the motion of a performer”、２００４年９月１５日に出願された第１０／９４２，４１３号“Apparatus and method for capturing the expression of a performer”、２００５年２月２５日に出願された第１１／０６６，９５４号“Apparatus and method for improving marker identification within a motion capture system”、２００５年３月１０日に出願された第１１／０７７，６２８号“Apparatus and method for performing motion capture using shutter synchronization”、２００５年１０月２０日に出願された第１１／２５５，８５４号“Apparatus and method for performing motion capture using a random pattern on capture surfaces”、２００６年６月７日に出願された第１１／４４９，１３１号“System and method for performing motion capture using phosphor application techniques”、２００６年６月７日に出願された第１１／４４９，０４３号“System and method for performing motion capture by strobing a fluorescent lamp”、２００６年６月７日に出願された第１１／４４９，１２７号“System and method for three dimensional capture of stop-motion animated characters”の要旨）を使用して捕獲される生の演技が、非常に滑らかな捕獲表面を、次いで、高多角形数追跡表面（即ち、多角形の動きが顔の動きに正確に追従する）をどのように生じるか示している。最終的に、生の演技のビデオが追跡表面にマップされて、テクスチャ処理表面を形成するときに、ホトリアルな結果が得られる。
現在のＧＰＵ技術は、追跡表面における多角形の数及びテクスチャをレンダリングしそして表面をリアルタイムで照明することができるが、多角形及びテクスチャがフレーム時間ごとに変化する（これは、最もホトリアルな結果を生じる）場合には、近代的ＰＣ又はビデオゲームコンソールの利用可能な全てのＲＡＭを急速に消費してしまう。
上述したストリーミング幾何学形状技術を使用すると、ａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５へ幾何学形状を連続的に供給して、ホトリアルな顔を連続的にアニメ化し、生の動きの顔とほとんど見分けがつかない顔をもつビデオゲームを作成できるようにするが実際的である。
リニアなコンテンツと双方向特徴との一体化
動画、テレビ番組及びオーディオ資料（集合的に「リニアコンテンツ」）は、家庭及びオフィスのユーザに多数の形態で広く利用することができる。リニアコンテンツは、ＣＤ、ＤＶＤ及びＢｌｕ−ｒａｙメディアのような物理的なメディアにおいて取得することができる。又、これは、衛星及びケーブルＴＶ放送からＤＶＲにより記録することもできる。そして、衛星及びケーブルＴＶを通してペイパービュー（ＰＰＶ）コンテンツとして、及びケーブルＴＶのビデオオンデマンド（ＶＯＤ）として利用することもできる。
益々多くのリニアコンテンツが、インターネットを通して、ダウンロードされたコンテンツとして及びストリーミングコンテンツとして利用できるようになった。今日、リニアメディアに関連した全ての特徴を経験するための場所は、実際に１つではない。例えば、ＤＶＤ及び他のビデオ光学メディアは、典型的に、演出家の解説、「メーキングオブ(making of)」特徴、等のように、他の場所では利用できない双方向特徴を有する。オンライン音楽サイトは、一般的にＣＤでは入手できないカバー技術及び歌情報を有するが、全てのＣＤをオンラインで入手できるのではない。又、テレビ番組に関連したウェブサイトは、しばしば、特別な特徴、ブログ、及びときには、俳優又は創作スタッフからのコメントを有する。
更に、多くの動画又はスポーツの出来事では、（動画の場合）しばしばリニアメディアと一緒に発売されるか、或いは（スポーツの場合）実世界の出来事（例えば、プレーヤのトレード）に密接に結びついたビデオゲームがしばしばある。
ホスティングサービス２１０は、異なる形態の関連コンテンツと一緒にリンクしてリニアコンテンツを配布するのに良く適している。確かに、動画の配信は、もはや、高度な双方向性のビデオゲームを配信する挑戦ではなく、ホスティングサービス２１０は、リニアコンテンツを家庭又はオフィスの広範な装置或いは移動装置へ配信することができる。図２３は、リニアコンテンツの選択を示すホスティングサービス２１０の規範的なユーザインターフェイスページを示している。
しかし、ほとんどのリニアコンテンツ配信システムとは異なり、ホスティングサービス２１０は、関連する双方向コンポーネント（例えば、ＤＶＤにおけるメニュー及び特徴、ＨＤ−ＤＶＤにおける双方向オーバーレイ、及びウェブサイトにおけるＡｄｏｂｅ Ｆｌａｓｈアニメーション（以下に述べる））を配信することもできる。従って、クライアント装置４１５の制限は、どの特徴が利用できるかについて、もはや制限を導入しない。
更に、ホスティングサービス２１０は、リニアコンテンツをビデオゲームコンテンツと動的に且つリアルタイムでリンクすることができる。例えば、ユーザがハリーポッターの映画においてクィディッチの試合を見て、クィディッチのプレイにトライしたい場合に、ボタンをクリックするだけで、映画を休止し、直ちに、ハリーポッタービデオゲームのクィディッチセグメントへ移ることができる。クィディッチの試合をプレイした後に、ボタンの別のクリックで、即座に映画が再開する。
写真的に捕獲されたビデオが生の動きのキャラクタと見分けがつかないようなホトリアルなグラフィック及び制作技術では、ユーザが、生の動きの映画におけるクィディッチゲームから、ここに述べるホスティングサービスにおけるビデオゲームのクィディッチゲームへ移行するときに、２つのシーンは、実質上、見分けがつかない。これは、２つの世界の間の線が見分けられないのでリニアコンテンツ及び双方向（例えば、ビデオゲーム）コンテンツの両方の演出家にとって全く新しい創作オプションを与える。
図１４に示すホスティングサービスアーキテクチャーを使用して、３Ｄ映画のバーチャルカメラの制御権を視聴者に与えることができる。例えば、列車の車両内で生じるシーンでは、視聴者がバーチャルカメラを制御して、ストーリーが進行する間に車両の周囲を見ることができる。これは、車両内の全ての３Ｄオブジェクト（アセット）が利用できると共に、シーンをリアルタイムでレンダリングできる充分なレベルの計算パワー、及びオリジナルの映画を仮定している。
そして、非コンピュータ発生娯楽であっても、非常にエキサイティングな双方向特徴を提供することができる。例えば、２００５動画“高慢と偏見(Pride and Prejudice)”は、華麗な古い英国風大邸宅における多くのシーンを有している。大邸宅の幾つかのシーンに対し、ユーザは、ビデオを休止し、次いで、カメラを制御して、大邸宅の塔、又はおそらく、周囲のエリアを撮影することができる。これを具現化するために、従来のアップル社のＱｕｉｃｋＴｉｍｅ ＶＲが具現化されたのと同様に、位置を見失わないように魚眼レンズをつけて大邸宅を通してカメラを搬送することができる。次いで、種々のフレームが変換され、従って、映像は歪むことなく、映画と共にＲＡＩＤアレイ１５１１−１５１２に記憶され、そしてユーザがバーチャルの塔に行くことを選択したときに再生することができる。
スポーツ行事では、バスケットボールゲームのような生のスポーツ行事を、ユーザが普通のＴＶで見るために、ホスティングサービス２１０を通してストリーミングすることができる。ユーザが特定のプレイを見た後に、ゲームのビデオゲーム（最終的には実際のプレーヤと同程度ホトリアルに見えるバスケットプレーヤを伴う）を、プレーヤが同じ位置でスタートして始めることができ、そしてユーザ（おそらく各々１人のプレーヤの制御権を得ている）がプレイをやり直して、プレーヤよりうまくいくかどうか確かめることができる。
ここに述べるホスティングサービス２１０は、この未来派的な世界をサポートするのに非常に良く適している。というのは、家庭又はほとんどのオフィス設定でインストールするのが不可能である計算パワー及び大量記憶リソースを保持することができ、又、家庭用設定では常に古い世代のＰＣ及びビデオゲームをもつものとなるが、その計算リソースは、入手可能な最新の計算ハードウェアで、常に、最新のものだからである。そして、ホスティングサービス２１０では、この計算の複雑さが全てユーザから隠され、従って、非常に精巧なシステムを使用しても、ユーザの観点から、テレビのチャンネルを切り換えるように簡単である。更に、ユーザは、全ての計算パワーにアクセスし、そして計算パワーがクライアント４１５から得られるところの経験にアクセスすることができる。
マルチプレーヤゲーム
ゲームがマルチプレーヤゲームであるという点で、インバウンドルーティング１５０２のネットワークを通してａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５と通信できると共に、インターネット（図示せず）へのネットワークブリッジで、ホスティングサービス２１０において実行されないサーバー又はゲームマシンと通信することができる。一般的なインターネットにおけるコンピュータでマルチプレーヤゲームをプレイするときには、ａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５は、インターネットへのアクセスが非常に速い（ゲームが家庭のサーバーで実行された場合に比して）という利点を有するが、低速な接続でゲームをプレイする他のコンピュータの能力により制限を受けると共に、インターネット上のゲームサーバーが、比較的低速の消費者用インターネット接続上の家庭用コンピュータである最小公分母を受け容れるように設計されたことによっても潜在的に制限を受ける。
しかし、マルチプレーヤゲームが完全にホスティングサービス２１０のサーバーセンター内でプレイされるときには、差の世界を達成することができる。ユーザのためのゲームをホストする各ａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５は、他のａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５と、非常に高速で非常に短待ち時間の接続及び膨大な非常に高速の記憶アレイをもつマルチプレーヤゲームのための集中制御をホストするサーバーとに相互接続される。例えば、インバウンドルーティング１５０２のネットワークにギガビットのイーサネットが使用される場合には、ａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５は、ギガビット／秒の速度において潜在的に１ｍｓ以下の待ち時間で、互いに通信すると共に、マルチプレーヤゲームのための集中制御をホストするサーバーとも通信する。更に、ＲＡＩＤアレイ１５１１−１５１２は、非常に迅速に応答し、そしてギガビット／秒の速度でデータを転送することができる。例えば、家庭においてＰＣ又はゲームコンソールで実行されるゲームクライアントに制限された従来のシステムで、キャラクタが大量の幾何学形状及びそのキャラクタ独特の挙動を有するように、容貌及び服装に関してユーザがキャラクタをカスタマイズする場合に、そのキャラクタが別のユーザの視野に入ってきた場合には、ユーザは、長くて低速のダウンロードが完了して全ての幾何学形状及び挙動データがコンピュータにロードされるまで、待機しなければならなくなる。ホスティングサービス２１０内では、その同じダウンロードを、ＲＡＩＤアレイ１５１１−１５１２から対応されるギガビットのイーサネットを経てギガビット／秒の速度で行うことができる。家庭のユーザが８Ｍｂｐｓのインターネット接続（これは、今日の規格では非常に高速である）を有する場合でも、ギガビットイーサネットは、１００倍も高速である。従って、高速インターネット接続で１分かかるものが、ギガビットイーサネットでは１秒未満である。
トッププレーヤグループ及びトーナメント
ホスティングサービス２１０は、トーナメントに非常に良く適している。ローカルクライアントでゲームが実行されないので、ユーザがチートする機会がない（例えば、従来のトーナメントにおいてローカルＰＣで実行されるゲームのコピーを変更して不公平な利益を与えることにより得られる）。又、出力ルーティング１５４０がＵＤＰストリームをマルチキャストできるので、ホスティングサービス２１０は、メジャートーナメントを観衆の中の数千以上の人々に一度にブロードキャストすることができる。
実際に、数千のユーザが同じストリーム（例えば、メジャートーナメントのビューを示す）を受信するように普及した幾つかのビデオストリームがあるときは、多くのクライアント装置４１５へ大量配布するためにＡｋａｍａｉ又はＬｉｍｅｌｉｇｈｔのような「コンテンツデリバリーネットワーク」（ＣＤＮ）へビデオストリームを送信するのがより効率的である。
ＣＤＮを使用してトッププレーヤグループの「ゲームファインダー」ページを示すときには、同様の効率レベルを得ることができる。
メジャートーナメントの場合、生の有名アナウンサを使用して、ある試合中に実況放送することができる。メジャートーナメントを見ているのは大勢のユーザであるが、トーナメントでプレイするのは比較的少数である。有名アナウンサからの音声は、トーナメントでプレイしているユーザをホストすると共にトーナメントにおけるゲームの観客モードコピーをホストするａｐｐ／ｇａｍｅゲームサーバー１５２１−１５２５へルーティングすることができ、そしてその音声は、ゲーム音声の上にオーバーダビングすることができる。有名アナウンサの映像も、ゲームにオーバーレイし、おそらくは、観客のビューにオーバーレイすることができる。
ウェブページロードの加速
ワールドワイドウェブ及びその一次トランスポートプロトコルであるハイパーテキストトランスファープロトコル（ＨＴＴＰ）は、ビジネスだけが高速インターネット接続をもちそしてオンラインにいる消費者がダイヤルアップモデム又はＩＳＤＮを使用していた時代に考えられ定義されたものである。そのとき、高速接続用の「黄金律(gold standard)」は、１．５Ｍｂｐｓのデータレートを対称的に（即ち、両方向に等しいデータレートで）与えるＴ１ラインであった。
今日、状況は、完全に異なる。開発された世界の多くにおいてＤＳＬ又はケーブルモデム接続を通る平均的な家庭用接続の速度は、Ｔ１ラインより遥かに高いダウンストリームデータレートを有している。実際に、世界の幾つかの部分では、ファイバー・ツー・ザ・カーブ(fiber-to-the-curb)が、５０ないし１００Ｍｂｐｓ程度の高さのデータレートを家庭へ運ぶ。
不都合なことに、ＨＴＴＰは、これらの急激な速度改善の利点を効果的に取り入れるように構成されてこなかった（又、具現化もされなかった）。ウェブサイトは、リモートサーバーにおけるファイルの集合である。非常に簡単に言えば、ＨＴＴＰは、第１のファイルを要求し、そのファイルがダウンロードされるのを待機し、次いで、第２のファイルを要求し、そのファイルがダウンロードされるのを待機し、等々である。実際に、ＨＴＴＰは、２つ以上の「オープン接続」を許し、即ち一度に２つ以上のファイルを要求できるようにするが、合意された規格（及びウェブサーバーが過負荷にならないよう防止する要望）があるために、非常に僅かなオープン接続しか許されない。更に、ウェブページが構成される方法のために、ブラウザは、多くの場合、直ちにダウンロードに利用できる複数の同時のページに気付かない（即ち、ページをパーズした後にのみ、映像と同様に、新たなファイルをダウンロードする必要があることが明らかとなる）。従って、ウェブサイトのファイルは、本質的に１つ１つロードされる。そして、ＨＴＴＰによって使用される要求及び応答プロトコルのために、ロードされる各ファイルに関連して（米国で典型的なウェブサーバーにアクセスすると）おおよそ１００ｍｓの待ち時間がある。
比較的低速の接続では、これにより大きな問題が導入されることはない。というのは、ファイルそれ自体のダウンロード時間がウェブページの待ち時間を支配するからである。しかし、接続速度が上がるにつれて、特に、複雑なウェブページでは、問題が起き始める。
図２４に示す例では、典型的な商業的ウェブサイトが示されている（この特定のウェブサイトは、一流運動選手用の靴のブランドからのものである）。このウェブサイトには、５４のファイルがある。これらファイルは、ＨＴＭＬ、ＣＳＳ、ＪＰＥＧ、ＰＨＰ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、及びＦｌａｓｈファイルを含むと共に、ビデオコンテンツを含む。ページが生になる（即ち、ユーザがそれをクリックして、それを使用し始める）前に、合計１．５Ｍバイトをロードしなければならない。多数のファイルには、多くの理由がある。１つのこととして、複雑で且つ精巧なウェブページであり、そして別のこととして、ページにアクセスするユーザに関する情報（例えば、ユーザの母国、言語、以前に購入したかどうか、等）に動的に基づいてアッセンブルされるウェブページであり、そしてこれら全てのファクタに基づいて、異なるファイルがダウンロードされる。依然、これは、非常に典型的な商業用ウェブページである。
図２４は、接続速度が上がるにつれてウェブページが生になるまでに経過する時間量を示している。１．５Ｍｂｐｓの接続速度２４０１では、従来のウェブブラウザを伴う従来のウェブサーバーを使用すると、ウェブページが生になるまでに１３．５秒を要する。１２Ｍｂｐｓの接続速度２４０２では、ロード時間は、６．５秒に短縮され、即ち約２倍の速さになる。しかし、９６Ｍｂｐｓの接続速度２４０３では、ロード時間は、約５．５秒までしか短縮されない。その理由として、このように高いダウンロード速度では、ファイルそれ自体をダウンロードするための時間は最小であるが、ファイル当たりの待ち時間、各々約１００ｍｓが依然あって、その結果、５４ファイル＊１００ｍｓ＝５．４秒の待ち時間となる。従って、家庭への接続がどれほど速くても、このウェブサイトは、常に、それが生となるまでに少なくとも少なくとも５．４秒を要する。別のファクタは、サーバー側のキューイングであり、即ち各ＨＴＴＰ要求がキューの後部に追加され、従って、ビジーのサーバーでは、これが大きな影響を及ぼす。というのは、ウェブサーバーから小さなアイテムを得るたびに、ＨＴＴＰ要求がその方向転換を待機する必要があるためである。
これらの問題を解決する１つの仕方は、ＨＴＴＰを破棄するか又は再定義することである。或いは、おそらく、ウェブサイト所有者がそのファイルを単一のファイル（例えば、Ａｄｏｂｅ Ｆｌａｓｈフォーマットの）へうまく合併することである。しかし、実際的な問題として、この会社及び多くの他の者は、そのウェブサイトアーキテクチャー多大な投資をしている。更に、ある家庭は、１２−１００Ｍｂｐｓの接続を有するが、大多数の家庭は、依然、ゆっくりした速度であり、ＨＴＴＰも、低速度で機能する。
１つの別の仕方は、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５のウェブブラウザをホストすると共に、ＲＡＩＤアレイ１５１１−１５１２のウェブサーバーに対するファイルをホストすることである（或いは潜在的にウェブブラウザをホストするａｐｐ／ｇａｍｅサーバー１５２１−１５２５のＲＡＭ又はローカル記憶装置において）。インバウンドルーティング１５０２を通して（又はローカル記憶装置への）非常に高速の相互接続があるために、ＨＴＴＰを使用してファイル当たり１００ｍｓの待ち時間となるのではなく、ＨＴＴＰを使用してファイル当たり最小の待ち時間となる。従って、家にいるユーザがＨＴＴＰを通してウェブページにアクセスするのではなく、ユーザは、クライアント４１５を通してウェブページにアクセスすることができる。次いで、１．５Ｍｂｐｓの接続では（このウェブページがそのビデオに対して著しい帯域巾を要求しないので）、ウェブページは、線２４００当たり１秒未満で生となる。本質的に、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５で実行されるウェブブラウザが生のページを表示するまでは待ち時間がなく、そしてクライアント４１５がウェブブラウザからのビデオ出力を表示するまでは検出可能な待ち時間がない。ユーザがウェブページ上でマウス操作し及び／又はタイプするときに、ユーザの入力情報がａｐｐ／ｇａｍｅサーバー１５２１−１５２５で実行されるウェブブラウザへ送信され、そしてウェブブラウザが適宜に応答する。
この解決策の１つの欠点は、コンプレッサがビデオデータを常時送信する場合に、ウェブページが静的なものとなっても、帯域巾が使用されることである。これは、ウェブページが変化するときだけ（及びその場合にのみ）データを送信し、次いで、変化したページの部分にのみデータを送信するようにコンプレッサを構成することにより、改善することができる。常時変化するフラッシングバナー、等をもつ幾つかのウェブページがあるが、このようなウェブページは、うっとうしい傾向となり、通常、ウェブページは、何かが動く（例えば、ビデオクリップ）理由がない限り静的なものとなる。このようなウェブページの場合、おそらく、従来のウェブサーバーよりも少ないデータがホスティングサービス２１０を使用して送信される。というのは、実際に表示される映像だけが送信され、シンクライアント実行コードも、決して見ることのない大きなオブジェクト、例えば、ロールオーバー映像も、送信されないからである。
従って、ホスティングサービス２１０を使用して、レガシーウェブページをホストすると、ウェブページのロード時間は、ウェブページをオープンすることがテレビのチャンネルを切り換えることと同じである点まで短縮することができ、即ちウェブページは、実際上瞬時に生となる。
ゲーム及びアプリケーションのデバッグの容易化
上述したように、リアルタイムグラフィックを伴うビデオゲーム及びアプリケーションは、非常に複雑なアプリケーションであり、典型的に、市場に発売されるときに、バグを含むことがある。ソフトウェア開発者は、バグに関してユーザからフィードバックを得、そしてクラッシュ後にマシン状態を還元するための何らかの手段を有するが、ゲーム又はリアルタイムアプリケーションに何が起きてクラッシュさせ又は不適切に機能させたか厳密に識別することは非常に困難である。
ゲーム又はアプリケーションがホスティングサービス２１０で実行されるときに、ゲーム又はアプリケーションのビデオ／オーディオ出力は、遅延バッファ１５１５に常時記録される。更に、ウオッチドッグプロセスが、各ａｐｐ／ｇａｍｅサーバー１５２１−１５２５で動作し、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５が円滑に動作することをホスティングサービスコントロールシステム４０１に規則的に報告する。ウオッチドッグプロセスが報告を怠った場合には、サーバーコントロールシステム４０１は、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５と通信するように試み、それが成功すれば、どんなマシン状態が得られてもそれを収集する。どんな情報が得られてもそれが、遅延バッファ１５１５に記録されたビデオ／オーディオと共に、ソフトウェア開発者へ送信される。
従って、ゲーム又はアプリケーションソフトウェアの開発者が、ホスティングサービス２１０からクラッシュの通知を得ると、何がクラッシュを招いたかのフレームごとの記録を得る。この情報は、バグを追跡して修理する上で非常に価値がある。
又、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５がクラッシュすると、サーバーは、最も最近の再スタート可能な点において再スタートされ、そして技術的な困難さについて謝罪するメッセージがユーザに与えられる。
リソースの共有及びコストの節約
図４ａ及び４ｂに示されたシステムは、エンドユーザとゲーム及びアプリケーションの開発者の両方に種々の利益を与える。例えば、典型的に、家庭及びオフィスのクライアントシステム（例えば、ＰＣ又はゲームコンソール）は、一週間に僅かな時間しか使用されない。ニールセンエンターテイメント“Active Gamer Benchmark Study”(http://www.prnewswire.com/cgibin/stories.pl?ACCT=104&STORY=/www/story/10-05-2006/0004446115&EDATE=)による２００６年１０月５日プレスリリースによれば、積極的なゲーマーは、一週間に平均１４時間を費やしてビデオゲームコンソールをプレイし、そして一週間に約１７時間をハンドヘルド状態にしている。又、このレポートは、（コンソール、ハンドヘルド及びＰＣゲームプレイを含む）全てのゲームプレイ活動に対し、積極的なゲーマーは、一週間に平均１３時間を費やすと述べている。コンソールビデオゲームのプレイ時間が高い数値であることを考慮すれば、一週間は、２４＊７＝１６８時間であり、これは、積極的なゲーマーの家では、ビデオゲームコンソールが一週間の時間のうち１７／１６８＝１０％しか使用されないことを意味する。即ち、９０％の時間は、ビデオゲームコンソールがアイドル状態である。高いコストのビデオゲームコンソールであり、そして製造者がこのような装置に助成しているとすれば、高価なリソースの非常に非効率的な使い方である。会社の中のＰＣも、典型的に、一週間のうち僅かな時間しか使用されず、特に、Ａｕｔｏｄｅｓｋ Ｍａｙａのようなハイエンドアプリケーションにしばしば要求される非ポータブルのデスクトップＰＣがそうである。ある会社は、全ての時間及び休日も営業し、そしてあるＰＣ（例えば、夜家で仕事をするために持ち運ばれるポータブル）は、全ての時間及び休日も使用されるが、会社のほとんどの活動は、月曜日から金曜日まで所定の営業時間ゾーンのほぼＡＭ９時からＰＭ５時までを中心とする傾向があり、休日や休息時間（昼食時のような）にはほとんど行われず、又、ほとんどのＰＣ使用は、ユーザがＰＣに積極的に関わる間に生じるので、デスクトップＰＣの使用は、これらの営業時間に従う傾向となる。ＰＣが、週５日間、ＡＭ９時からＰＭ５時まで恒常的に使用されると仮定すれば、ＰＣが週の時間の４０／１６８＝２４％使用されることを意味する。高性能デスクトップＰＣは、会社にとって非常個高価な投資であり、これは、非常に低い利用レベルを反映している。デスクトップコンピュータで授業する学校は、週のより小さな時間巾でもコンピュータを使用し、授業時間に基づいて変化するが、ほとんどの授業は、月曜日から金曜日までの昼間の時間中に行われる。従って、一般的に、ＰＣ及びビデオゲームコンソールは、週の時間の僅かな部分でしか利用されない。
特に、多くの人々は、平日月曜日から金曜日の昼間の時間中は会社や学校にいるので、これらの人々は、一般的に、これらの時間中はビデオゲームをプレイせず、従って、ビデオゲームをプレイするのは、一般的に、夜や週末や休日のような他の時間中である。
図４ａに示すホスティングサービスの構成が与えられると、上述した２つの段落で述べた使用パターンは、リソースの非常に効率的な利用を生じる。明らかなように、特に、ユーザが、精巧な３Ｄビデオゲームのような複雑なアプリケーションに対してリアルタイム応答を要求する場合には、所与の時間にホスティングサービス２１０によってサービスを受けることのできるユーザの数に限度がある。しかし、典型的にほとんどの時間アイドル状態にある家庭のビデオゲームコンソールや会社で使用されるＰＣとは異なり、サーバー４０２は、異なる時間に異なるユーザにより再利用することができる。例えば、高性能のデュアルＣＰＵ及びデュアルＧＰＵと大容量のＲＡＭとを伴う高性能サーバー４０２は、平日のＡＭ９時からＰＭ５時まで会社及び学校により利用することができるが、夜、週末及び休日には精巧なビデオゲームをプレイするゲーマーにより利用することができる。同様に、低性能のアプリケーションは、Ｃｅｌｅｒｏｎ ＣＰＵをもち、ＧＰＵをもたず（又は非常にローエンドのＧＰＵをもち）且つ制限されたＲＡＭをもつ低性能サーバー４０２において会社の時間中に会社及び学校によって利用することができ、そして低性能ゲームは、会社の時間中でないときに低性能サーバー４０２を利用することができる。
更に、ここに述べるホスティングサービス構成では、数百万でなくても数千のユーザ間でリソースが効率的に共用される。一般的に、オンラインサービスは、所与の時間にサービスを利用する全ユーザベースの僅かな割合しかもたない。上述したニールセンのビデオゲーム使用統計値を考えると、なぜそうなるか調べることは容易である。積極的なゲーマーがコンソールゲームを一週間に１７時間しかプレイしない場合に、ゲームのピーク使用時間が、夜（５−ＡＭ１２、７＊５日＝３５時間／週）及び週末（ＡＭ８−ＡＭ１２、１６＊２＝３２時間／週）の典型的な非仕事非会社時間中であると仮定すると、１７時間のゲームプレイに対して一週間に３５＋３２＝６５ピーク時間ある。システムに対する厳密なピークユーザ負荷は、多くの理由で推定が困難であり、即ちあるユーザは、オフピーク時間中にプレイし、ある日中の時間にユーザの集団ピークがあり、ピーク時間は、プレイするゲームの形式により影響され（例えば、子供のゲームは、おそらく、夜の早い時間にプレイされ）、等々である。しかし、ゲーマーがプレイする平均時間数が、ゲーマーがおそらくゲームをプレイする日の時間数より遥かに少ないとすれば、所与の時間にホスティングサービス２１０のユーザ数の一部分がそれを使用するだけである。この分析のためには、ピーク負荷が１２．５％であると仮定しなければならない。従って、計算、圧縮及び帯域巾リソースの１２．５％が所与の時間に使用されるだけであり、その結果、リソースの再使用により所与の性能レベルのゲームをプレイするように所与のユーザをサポートするのにハードウェアコストの１２．５％だけとなる。
更に、あるゲーム及びアプリケーションが他のものより多くの計算パワーを要求するとすれば、ユーザによってプレイされるゲーム又は実行されるアプリケーションに基づいてリソースを動的に割り当てることができる。従って、低性能ゲーム又はアプリケーションを選択するユーザには、低性能（低廉な）サーバー４０２が割り当てられ、そして高性能ゲーム又はアプリケーションを選択するユーザには、高性能（より高価な）サーバー４０２が割り当てられる。実際に、所与のゲーム又はアプリケーションは、ゲーム又はアプリケーションの低性能区分及び高性能区分を有し、そしてユーザは、ゲーム又はアプリケーションのニーズを満足する最低コストのサーバー４０２でのユーザの動作を保持するように、ゲーム又はアプリケーションの区分間で、あるサーバー４０２から別のサーバー４０２へスイッチすることができる。単一のディスクより遥かに高速のＲＡＩＤアレイ４０５が、低性能のサーバー４０２でも使用でき、高速ディスク転送レートの利益を得る。従って、プレイされるゲーム又は使用されるアプリケーションの全部にわたるサーバー４０２当たりの平均コストは、最高性能のゲーム又はアプリケーションをプレイする最も高価なサーバー４０２のコストよりかなり低く、更に、低性能サーバー４０２は、ＲＡＩＤアレイ４０５からディスク性能の利益を導出する。
更に、ホスティングサービス２１０のサーバー４０２は、ネットワークインターフェイス以外のディスク又は周辺インターフェイスをもたないＰＣマザーボード以上のものではなく、やがて、ＳＡＮ４０３への高速ネットワークインターフェイスのみをもつ単一チップへと一体化される。又、ＲＡＩＤアレイ４０５は、おそらく、ディスクより遥かに多数のユーザ間で共用され、従って、活動的なユーザ当たりのディスクコストは、１つのディスクドライブより遥かに低い。この装置は、全て、おそらく、環境的に制御されたサーバールーム環境においてラック内に存在する。サーバー４０２がフェイルした場合に、ホスティングサービス２１０において容易に修理又は交換することができる。対照的に、家庭又はオフィスにおけるＰＣ又はゲームコンソールは、叩かれたり落とされたりすることによる適度な摩耗及び引き裂きに生き残ることができねばならず、ハウジングを要求し、少なくとも１つのディスクドライブを有し、悪い環境条件（例えば、他のギアでオーバーヘッドＡＶキャビネットへ詰め込まれる）に生き残らねばならず、サービス保証を要求し、パッケージされて出荷されねばならず、且つおそらく小売利ざやを徴収する小売店により販売される頑強なスタンドアローン機器でなければならない。更に、ＰＣ又はゲームコンソールは、ほとんどの時間に低性能ゲーム又はアプリケーション（或いはゲーム又はアプリケーションの区分）がプレイされても、将来のある時点で使用される最も計算上強いと予想されるゲーム又はアプリケーションのピーク性能を満足するように構成されねばならない。そして、ＰＣ又はコンソールがフェイルした場合に、それを修理するのは、高価で且つ時間のかかるプロセス（製造者、ユーザ及びソフトウェア開発者に悪影響が及ぶ）である。
従って、図４ａに示すシステムがローカル計算リソースに匹敵する経験をユーザに与えるとすれば、家庭、オフィス又は学校のユーザが所与のレベルの計算能力を経験するために、図４ａに示すアーキテクチャーを通してその計算能力を与えるのにかなり低廉なものとなる。
アップグレードの必要性の排除
更に、ユーザは、新たなゲームをプレイし又はより高い性能の新たなアプリケーションを取り扱うためにＰＣ及び／又はコンソールをアップグレードすることに関して心配する必要はもはやない。ホスティングサービス２１０におけるゲーム又はアプリケーションは、そのゲーム又はアプリケーションのためにどんな形式のサーバー４０２が要求されるかに関わらず、ユーザに利用することができ、全てのゲーム及びアプリケーションは、ほぼ即座に（例えば、サーバー４０２上のＲＡＩＤアレイ４０５又はローカル記憶装置から素早くロードされて）且つ最新の更新及びバグ修理で適切に実行される（即ち、ソフトウェア開発者は、所与のゲーム又はアプリケーションを実行するサーバー４０２にとって理想的なサーバー構成を選択し、次いで、最適なドライバを伴うサーバー４０２を構成することができ、そして時間の経過と共に、開発者は、ホスティングサービス２１０におけるゲーム又はアプリケーションの全てのコピーに更新、バグ修理、等を一度に与えることができる）。実際に、ユーザがホスティングサービス２１０の使用を開始した後に、ユーザは、おそらく、（例えば、更新及び／又はバグ修理を通じて）優れた経験を与え続けるゲーム及びアプリケーションを見出し、そしてユーザは、１年前に存在しなかったコンピューティング技術（例えば、高性能ＧＰＵ）を使用するサービス２１０に新たなゲーム又はアプリケーションを利用できることを１年後に発見し、ひいては、１年後にゲームをプレイし又はアプリケーションを実行する技術を１年前に買うことがユーザにとって不可能であったことを発見することになろう。ゲームをプレイし又はアプリケーションを実行する計算リソースは、ユーザには見えないから（即ち、ユーザの観点から、ユーザは、テレビのチャンネルを切り換えるのと同様に、ほぼ瞬時に実行を開始するゲーム又はアプリケーションを単に選択するだけであるから）、ユーザのハードウェアは、ユーザが絶えずアップグレードに気付かなくても「アップグレード」されている。
バックアップの必要性の排除
会社、学校及び家庭においてユーザに対する別の主たる問題は、バックアップである。ローカルＰＣ又はビデオゲームコンソールに記憶された情報（例えば、コンソールの場合には、ユーザのゲーム成績及びランキング）は、ディスクがフェイルするか、又は偶発的な消去があった場合に、失われる。ＰＣのための手動又は自動バックアップを与えるアプリケーションは、多数入手でき、ゲームコンソールの状態をバックアップのためにオンラインサーバーへアップロードできるが、ローカルバックアップは、典型的に、別のローカルディスク（又は他の不揮発性記憶装置）へコピーして、これをどこか安全な場所に保管し組織化しなければならず、又、オンラインサービスに対するバックアップは、典型的な低コストインターネット接続を通して利用できるのがゆっくりのアップストリーム速度であるから、しばしば制限がある。図４ａのホスティングサービス２１０では、ＲＡＩＤアレイ４０５に記憶されるデータは、当業者に良く知られた従来のＲＡＩＤ構成技術を使用して、ディスクがフェイルした場合にも、データが失われず、そのフェイルしたディスクを収容しているサーバーセンターの専門家が通知を受けて、ディスクを交換し、ＲＡＩＤアレイがもう一度フェイル許容となるよう自動的に更新されるように、構成することができる。更に、全てのディスクドライブが互いに近くにあり、そしてそれらの間にはＳＡＮ４０２を通して高速ローカルネットワークがあるので、サーバーセンターにおいて全てのディスクシステムを規則的に二次記憶装置でバックアップし、この二次記憶装置をサーバーセンターに保管するか又は離れた場所へ移すことは困難ではない。ホスティングサービス２１０のユーザの視点から、データは、単純に常時セキュアなものであり、バックアップについて考える必要はない。
デモへのアクセス
ユーザは、多くの場合に、ゲーム又はアプリケーションを購入する前にそれを試したがる。上述したように、ゲーム及びアプリケーションをデモする従来の手段があるが（「デモ」の動詞形は、デモンストレーションバージョンを試すことを意味し、これは、名詞として「デモ」とも称される）、それらの各々は、制限及び／又は不便さで悩まされている。ホスティングサービス２１０を使用すると、ユーザがデモを試すのが容易で且つ便利になる。実際に、全てのユーザがユーザインターフェイス（以下に述べるような）を通してモデを選択して、デモを試す。デモは、デモに適したサーバー４０２へほぼ瞬間的にロードを行い、そして他のゲーム又はアプリケーションと同様に実行するだけである。デモが非常に高性能のサーバー４０２を要求するか低性能のサーバー４０２を要求するかに関わらず、又、どんな形式の家庭又はオフィスクライアント４１５をユーザが使用しても、ユーザの観点から、デモは、きちんと機能する。ゲーム又はアプリケーションデモのソフトウェア発行者は、どんなデモをどれほど長くユーザが試すことが許されるか厳密に制御することができ、そしてもちろん、デモは、デモンストレーションされるゲーム又はアプリケーションのフルバージョンにアクセスする機会をユーザに与えるユーザインターフェイスエレメントを含むことができる。
デモは、おそらく、価格未満又は無料で提供されるので、あるユーザは、デモ（特に、繰り返しプレイするのが楽しいゲームデモ）を繰り返し使用することを試みる。ホスティングサービス２１０は、所与のユーザに対してデモの使用を制限する種々の技術を使用することができる。最も単純な解決策は、ユーザごとにユーザＩＤを確立して、所与のユーザＩＤがデモをプレイすることが許される回数を制限することである。しかしながら、ユーザは、ユーザＩＤが無料の場合には、複数のユーザＩＤを設定することができる。この問題に対処する１つの技術は、所与のクライアント４１５がデモをプレイすることが許される回数を制限することである。クライアントがスタンドアローン装置である場合には、装置がシリアルナンバーを有し、ホスティングサービス２１０は、そのシリアルナンバーをもつクライアントによりデモをアクセスできる回数を制限することができる。クライアント４１５がＰＣ又は他の装置のソフトウェアとして実行される場合には、ホスティングサービス２１０によりシリアルナンバーを指定してＰＣに記憶し、これを使用してデモの使用を制限できるが、ＰＣをユーザが再プログラムでき且つシリアルナンバーを消去又は変更できるとすれば、ＰＣネットワークアダプタ「メディアアクセスコントロール（ＭＡＣ）」アドレス（及び／又は他のマシン特有の識別子、例えば、ハードドライブのシリアルナンバー、等）のレコードを保持して、それに対してデモの使用を制限するという別のオプションがホスティングサービス２１０に対して設けられる。しかしながら、ネットワークアダプタのＭＡＣアドレスを変更できるとすれば、これは、フールプルーフな方法ではない。別の解決策は、所与のＩＰアドレスに対してデモをプレイできる回数を制限することである。ＩＰアドレスは、ケーブルモデム及びＤＳＬプロバイダーによって周期的に再指定できるが、実際にはあまり頻繁に行われず、ＩＰが、住居ＤＳＬ又はケーブルモデムアクセスに対するＩＰアドレスのブロック内にあると決定できる場合には（例えば、ＩＳＰにコンタクトすることによって）、典型的に、所与の家庭に対して少数のデモ使用を確立することができる。又、家庭において同じＩＰアドレスを共有するＮＡＴルーターの後方に複数の装置が存在することもあるが、典型的に、住居設定では、このような装置は限定された数だけである。ＩＰアドレスが、会社にサービスするブロック内にある場合には、１つの会社に対して多数のデモを確立することができる。しかし、結局、ＰＣにおけるデモの数を制限する最良の方法は、上述した全ての解決策の組合せである。断固とした技術的に熟練したユーザが、繰り返しプレイされるデモの数を制限できるフールプルーフの方法はないが、多数のバリアを生成することで、ほとんどのＰＣユーザにとってデモシステムを悪用するトラブルは価値がなく、むしろ、デモをそれらが意図されたように使用して新たなゲーム及びアプリケーションを試せるように、充分な抑止力を生み出すことができる。
学校、会社及び他の施設の利益
特に、図４ａに示すシステムを利用する会社、学校及び他の施設に対して著しい利益が得られる。会社及び学校は、ＰＣをインストールし、維持し及びアップグレードすることに関連して著しいコストがかかり、それが、Ｍａｙａのような高性能アプリケーションを実行するためのＰＣになったときには、特にそうである。上述したように、ＰＣは、一般的に、週の時間の僅かな部分しか利用されず、そして家庭の場合と同様に、所与のレベルの性能能力を伴うＰＣのコストは、オフィス又は学校環境の方がサーバーセンター環境よりも遥かに高い。
大きな会社又は学校（例えば、大規模な大学）の場合には、そのようなエンティティのＩＴ部門がサーバーセンターを設定し、そしてＬＡＮグレード接続を経てリモートアクセスされるコンピュータを維持するのが実際的である。ＬＡＮを経て又はオフィス間のプライベートな広帯域巾接続を通してコンピュータにリモートアクセスするための解決策は、多数存在する。例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓターミナルサーバーでは、又はＲｅａｌＶＮＣ社からのＶＮＣのようなバーチャルネットワーク計算アプリケーションを通して、或いはＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓからのシンクライアント手段を通して、ユーザは、グラフィック応答時間及びユーザ経験においてある範囲のクオリティでＰＣ又はサーバーへのリモートアクセスを得ることができる。更に、このような自己管理型のサーバーセンターは、典型的に、単一の会社又は学校専用であり、従って、異種のアプリケーション（例えば、娯楽及び会社アプリケーション）が週の異なる時間に同じ計算リソースを利用するときに考えられる使用の重複の利点を取り入れることができない。従って、多くの会社及び学校は、各ユーザへのＬＡＮ速度ネットワーク接続を有するサーバーセンターをそれ自身で設定するスケール、リソース又は専門知識に欠ける。実際に、学校及び会社の大部分は、家庭と同じインターネット接続（例えば、ＤＳＬ、ケーブルモデム）を有する。
このような組織は、定常的ベース又は周期的ベースのいずれかで非常に高性能の計算の必要性を依然有している。例えば、小さな建築会社は、少数の建築家しかおらず、設計の仕事をするときに計算の必要性が比較的僅かであるが、非常に高性能の３Ｄ計算を周期的に必要とする（例えば、クライアントに対する新たな建築設計の３Ｄフライスルーを創作するときに）。図４ａに示すシステムは、このような組織に非常に良く適している。組織は、典型的に非常に安価な、家庭に提供されるものと同じ種類のネットワーク接続（例えば、ＤＳＬ、ケーブルモデム）以上のものを必要としない。それらは、安価なＰＣをクライアント４１５として利用するか、或いはＰＣを全く省き、制御信号ロジック４１３及び短待ち時間ビデオ解凍４１２を簡単に具現化する安価な専用装置を利用するかのいずれかである。これらの特徴は、ＰＣの窃盗や、ＰＣ内の専用コンポーネントへのダメージに伴う問題がある学校にとって特に魅力的である。
このような構成は、このような組織の多数の問題を解決する（そしてこれら効果の多くは、一般的な計算を行う家庭のユーザによっても共用される）。その１つとして、運営コスト（最終的に、実現可能な取引を得るためにある形態でユーザへ還元されねばならない）を非常に低くすることができる。というのは、（ａ）計算リソースが、週内に異なるピーク使用時間を有する他のアプリケーションと共有され、（ｂ）組織が、必要な時だけ高性能計算リソースにアクセスする（及びそのコストを被る）ことができ、（ｃ）組織が、高性能計算リソースをバックアップ又は維持するためのリソースを設ける必要がないからである。
海賊行為の排除
更に、ゲーム、アプリケーション、双方向映画、等は、今日のように海賊行為を受けることがもはやない。各ゲームは、記憶されて、ホスティングサービスセンター２１０で実行されるので、ユーザには、基礎的なプログラムコードへのアクセス権が与えられず、従って、海賊行為を受けるものは何もない。ユーザがソースコードをコピーする場合でも、ユーザは、標準的なゲームコンソール又は家庭用コンピュータにおいてコードを実行することはできない。これは、標準的なビデオゲームが入手できない中国のような世界の場所に市場を開く。又、ユーザに配布されたゲームのコピーがないので、中古ゲームの再販売はできない。
ゲームの開発者にとって、今日、新たな世代のゲームコンソール又はＰＣが市場に導入されるときに、市場の中断は僅かである。ホスティングサービス２１０は、コンソール又はＰＣ技術の完全に新たな世代がユーザや開発者にアップグレードを強制し且つゲーム開発者がユーザへのハードウェアプラットホームの適時の配信に依存する現在の状況（例えば、ＰｌａｙＳｔａｔｉｏｎ３の場合には、その導入が１年以上遅らされ、開発者は、それが入手できるようになり且つ著しい数のユニットが購入されるまで待たねばならなかった）とは対照的に、ゲームの要件が変化するにつれて時間と共に更に進歩したコンピューティング技術で徐々に更新することができる。
ストリーミング双方向ビデオ
以上の説明は、一般的インターネットをベースとする短待ち時間のストリーミング双方向ビデオ（これは、ここで使用されるオーディオもビデオと一緒に暗示的に含む）の新規な基礎的概念により可能となる広範囲なアプリケーションを述べるものである。インターネットを通してストリーミングビデオを与える従来のシステムは、長待ち時間の双方向性で具現化できるアプリケーションを可能にするだけである。例えば、リニアビデオのための再生コントロール（例えば、休止、巻き戻し、早送り）は、長い待ち時間で充分に機能し、リニアビデオフィードの中から選択することができる。そして、上述したように、あるビデオゲームの性質は、それらを長待ち時間でプレイすることを許す。しかし、ストリーミングビデオのための従来の解決策の長待ち時間（又は低圧縮比）は、ストリーミングビデオの潜在的なアプリケーションを甚だしく制限するか、又はそれらの開発を特殊なネットワーク環境へと狭め、そしてそのような環境においても、従来の技術は、ネットワークに実質的な負担を導入する。ここに述べる技術は、インターネットを通る短待ち時間のストリーミング双方向ビデオ、特に、消費者グレードのインターネット接続を通して可能になるもの、で考えられる広範囲なアプリケーションに対してドアを開く。
実際上任意の量の計算パワー、任意の量の高速記憶、並びにパワフルなサーバーの中の非常に高速なネットワークでユーザ経験の向上を果たすに充分な、図４ｃのクライアント４６５と同程度に小さいクライアント装置で、実際に、新しい計算の時代を可能にする。更に、帯域巾要件は、システムの計算パワーが増大するにつれて拡大しないので（即ち、帯域巾要件は、表示解像度、クオリティ及びフレームレートに結び付いているだけであるので）、ブロードバンドインターネット接続が偏在し（例えば、広く普及した短待ち時間のワイヤレスカバレージを通して）、信頼性があり、且つ全ユーザのディスプレイ装置４２２のニーズを満足するに充分な広い帯域巾であるときには、典型的な消費者及び会社向けアプリケーションに対して、（Ｗｉｎｄｏｗｓ、Ｌｉｎｕｘ、ＯＳＸ、等を実行するＰＣ又は移動電話のような）シッククライアントが必要か、又は（Ａｄｏｂｅ Ｆｌａｓｈ又はＪａｖａのような）シンクライアントでもよいかが問題となる。
ストリーミング双方向ビデオの出現は、計算アーキテクチャーの構造についての仮定を考え直す結果となった。その一例が、図１５に示すホスティングサービス２１０のサーバーセンター実施形態である。遅延バッファ及び／又はグループビデオ１５５０のためのビデオ経路は、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５のマルチキャストされたストリーミング双方向ビデオ出力が、経路１５５２を経てリアルタイムで、又は経路１５５１を経て選択可能な遅延の後に、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５へフィードバックされる。これは、従来のサーバー又はローカル計算アーキテクチャーでは不可能であるか又は実現不能な広範囲の実際的なアプリケーション（例えば、図１６，１７及び２０に示すもののような）を可能にする。しかし、より一般的なアーキテクチャー上の特徴として、フィードバックループ１５５０が与えるものは、ストリーミング双方向ビデオレベルでの反復である。というのは、アプリケーションが要求したときに、ビデオを不定にループバックできるからである。これは、従来得られなかった広範囲のアプリケーションの可能性を実現できるようにする。
別の重要なアーキテクチャー上の特徴は、ビデオストリームが単一方向のＵＤＰストリームであることである。これは、実際上、ストリーミング双方向ビデオのマルチキャスティングを任意の度合いで行えるようにする（対照的に、ＴＣＰ／ＩＰストリームの両方向ストリームは、ユーザの数が増えるにつれて前後通信からネットワークに益々大きな渋滞を生じることになる）。マルチキャスティングは、サーバーセンター内で重要な能力である。というのは、システムが、インターネットユーザ（及び実際には世界の人口）の増大するニーズに応答して、１対多又は多対多で、通信を行えるようにするからである。この場合も、ストリーミング双方向ビデオ反復及びマルチキャスティングの両方の使用を示す図１６について述べた例は、可能性についての非常に大きな氷山の一角に過ぎない。
非トランジットピアリング
一実施形態において、ホスティングサービス２１０は、ユーザへインターネットサービスも提供する１つ以上のインターネットサービスプロバイダー（ＩＳＰ）への１つ以上のピア接続を有し、このようにして、ホスティングサービス２１０は、ＩＳＰネットワーク内に留まる非トランジットルートを通してユーザと通信することができる。例えば、ホスティングサービス２１０のＷＡＮインターフェイス４４１がコムキャストケーブルコミュニケーションズ社(Comcast Cable Communications Inc.)のネットワークに直結され、そしてユーザの家屋２１１にコムキャストケーブルモデムでブロードバンドサービスが供給される場合には、ホスティングサービス２１０とクライアント４１５との間のルートがコムキャストのネットワーク内に完全に確立される。その潜在的な効果は、通信コストが低く（２つ以上のＩＳＰネットワーク間のＩＰトランジットコストが回避されるので）、接続の信頼性が潜在的に高く（ＩＳＰネットワーク間に混雑又は他のトランジット混乱がある場合に）、及び待ち時間が短い（ＩＳＰネットワーク間に混雑、非効率的なルート又は他の遅延がある場合に）ことを含む。
この実施形態では、クライアント４１５が、最初に、セッションの始めに、ホスティングサービス２１０に連絡するときに、ホスティングサービス２１０は、ユーザの家屋２１１のＩＰアドレスを受け取る。例えば、ＡＲＩＮ（American Registry for Internet Numbers）からの利用可能なＩＰアドレステーブルを使用して、そのＩＰアドレスが、別のＩＳＰを通してＩＰトランジットせずにユーザの家屋２１１へルーティングできるホスティングサービス２１０に接続された特定のＩＳＰに割り当てられたものであることを調べる。例えば、ＩＰアドレスが７６．２１．０．０と７６．２１．１２７．２５５との間である場合には、そのＩＰアドレスは、コムキャストケーブルコミュニケーションズ社に指定される。この例において、ホスティングサービス２１０が、コムキャスト、ＡＴ＆Ｔ、及びＣｏｘ ＩＳＰへの接続を維持する場合には、特定のユーザへの最適なルートを与える見込みが最も高いＩＳＰとしてコムキャストを選択する。
フィードバックを使用するビデオ圧縮
１つの実施形態において、首尾良い（又は不首尾な）タイル及び／又はフレームの配信を指示するためにクライアント装置からホスティングサービスへフィードバックが与えられる。次いで、クライアントから与えられるフィードバック情報を使用して、ホスティングサービスにおいてビデオ圧縮動作を調整する。
例えば、図２５ａ−ｂは、クライアント装置２０５とホスティングサービス２１０との間にフィードバックチャンネル２５０１が確立される本発明の一実施形態を示す。フィードバックチャンネル２５０１は、首尾良く受信されたタイル／フレームのパケット化された確認、及び／又は受信が不首尾なタイル／フレームの指示を送信するためにクライアント装置２０５によって使用される。
１つの実施形態において、各タイル／フレームを首尾良く受信した後に、クライアントは、ホスティングサービス２１０へ確認メッセージを送信する。この実施形態では、ホスティングサービス２１０は、指定の期間の後に確認を受信しない場合、及び／又は送信されたものではないその後のタイル／フレームをクライアント装置２０５が受信したという確認を受信した場合には、パケットロスを検出する。それとは別に又はそれに加えて、クライアント装置２０５は、パケットロスを検出し、そしてパケットロスの指示を、そのパケットロスにより影響を受けるタイル／フレームの指示と共に、ホスティングサービス２１０へ送信する。この実施形態では、首尾良く配信されたタイル／フレームの連続的な確認は、要求されない。
パケットロスがどのように検出されるかに関わらず、図２５ａ−ｂに示す実施形態では、映像のためのＩタイルの最初のセット（図２５ａには示さず）を発生した後に、エンコーダは、それに続いて、パケットロスが検出されるまでＰタイルしか発生しない。図２５ａにおいて、２５１０のような各フレームは、４つの垂直タイルとして示されていることに注意されたい。フレームは、２ｘ２、２ｘ４、４ｘ４、等の異なる構成でタイル化されてもよいし、或いはフレームは、タイルなしに（即ち、１つの大きなタイルとして）全体的にエンコードされてもよい。フレームタイル化構成の以上の例は、本発明のこの実施形態を例示するために取り上げたものである。本発明の基礎となる原理は、特定のフレームタイル構成に限定されない。
Ｐタイルのみを送信することで、上述した全ての理由で（即ち、Ｐタイルは、一般に、Ｉタイルより小さい）、チャンネルの帯域巾要求が緩和される。フィードバックチャンネル２５０１を経てパケットロスが検出されたときには、クライアント装置２０５におけるデコーダ２５０２の状態を再初期化するために、図２５ｂに示すように、新たなＩタイルがエンコーダ２５００により発生される。図示されたように、１つの実施形態では、各個々のエンコードされたフレームにより消費される帯域巾を限定するために、複数のエンコードされたフレームにわたってＩタイルが分散される。例えば、各フレームが４個のタイルを含む図２５では、４つの連続するエンコードされたフレーム内の異なる位置で単一のＩタイルが送信される。
エンコーダ２５００は、この実施形態について述べる技術を、ここに述べる他のエンコード技術と合成することができる。例えば、検出されたパケットロスに応答してＩタイルを発生するのに加えて、エンコーダ２５００は、映像シーケンスを適切にレンダリングするのにＩタイルが有益である他の環境においてＩタイルを発生することができる（例えば、突然のシーン移行に応答して）。
図２６ａは、クライアント装置２０５とホスティングサービス２１０との間のフィードバックチャンネル２６０１に依存する本発明の別の実施形態を示す。検出されたパケットロスに応答して新たなＩタイル／フレームを発生するのではなく、この実施形態のエンコーダ２６００は、Ｐタイル／フレームの依存性を調整する。最初の事柄として、この例について述べる特定の細部は、本発明の基礎的な原理に合致する必要がないことに注意されたい。例えば、この例は、Ｐタイル／フレームを使用して説明するが、本発明の基礎的な原理は、特定のエンコードフォーマットに限定されない。
図２６ａにおいて、エンコーダ２６００は、複数の非圧縮のタイル／フレーム２６０５を複数のＰタイル／フレーム２６０６へとエンコードし、そしてそれらＰタイル／フレームを、通信チャンネル（例えば、インターネット）を経てクライアント装置２０５へ送信する。クライアント装置２０５のデコーダ２６０２は、Ｐタイル／フレーム２６０６をデコードして、複数の解凍されたタイル／フレーム２６０７を発生する。エンコーダ２６００の過去の状態２６１１は、ホスティングサービス２１０のメモリ装置２６１０内に記憶され、そしてデコーダ２６０２の過去の状態２６２１は、クライアント装置２０５のメモリ装置２６２０内に記憶される。デコーダの「状態」は、ＭＰＥＧ−２及びＭＰＥＧ−４のようにビデオコード化システムにおいて良く知られた用語である。１つの実施形態では、メモリ内に記憶された過去の「状態」は、以前のＰタイル／フレームからの合成データを含む。メモリ２６１１及び２６２１は、図２６ａに示すように、エンコーダ２６００及びデコーダ２６０２から取り外されるのではなく、エンコーダ２６００及びデコーダ２６０２内に一体化されてもよい。更に、例えば、これに限定されないが、ランダムアクセスメモリを含む種々の形式のメモリが使用されてもよい。
１つの実施形態において、パケットロスが生じないときには、エンコーダ２６００は、各Ｐタイル／フレームを、手前のＰタイル／フレームに依存すべくエンコードする。従って、図２６ａに使用された表記法で示されたように、Ｐタイル／フレーム４は、Ｐタイル／フレーム３（表記４3を使用して識別される）に依存し、Ｐタイル／フレーム５は、Ｐタイル／フレーム４（表記５4を使用して識別される）に依存し、そしてＰタイル／フレーム６は、Ｐタイル／フレーム５（表記６5を使用して識別される）に依存する。この例では、エンコーダ２６００とデコーダ２６０２との間の送信中にＰタイル／フレーム４3が失われる。このロスは、上述したもの（これに限定されないが）を含む種々の仕方でエンコーダ２６００へ送信することができる。例えば、デコーダ２６０２がタイル／フレームを首尾良く受信し及び／又はデコードするたびに、この情報をデコーダ２６０２からエンコーダ２６００へ通信することができる。エンコーダ２６００が、特定のタイル／フレームが受信され及び／又はデコードされたという指示をある期間の後に受信しない場合には、エンコーダ２６００は、タイル／フレームが首尾良く受信されなかったと仮定する。それとは別に又はそれに加えて、デコーダ２６０２は、特定のタイル／フレームが首尾良く受信されなかったときにエンコーダ２６００に通知することができる。
１つの実施形態において、失われたタイル／フレームがどのように検出されるかに関わらず、それが生じると、エンコーダ２６００は、デコーダ２６０２により首尾良く受信されたことが分かっている最後のタイル／フレームを使用して次のタイル／フレームをエンコードする。図２６ａに示す例では、タイル／フレーム５及び６は、「首尾良く受信された」と考えられない。というのは、それらは、タイル／フレーム４のロスのためにデコーダ２６０２により適切にデコードできないからである（即ち、タイル／フレーム５のデコーディングは、タイル／フレーム４に依存し、そしてタイル／フレーム６のデコーディングは、タイル／フレーム５に依存する）。従って、図２６ａに示す例では、エンコーダ２６００は、タイル／フレーム７を、デコーダ２６０２が適切にデコードできないタイル／フレーム６ではなくて、タイル／フレーム３（最後に首尾良く受信されたタイル／フレーム）に依存すべくエンコードする。図２６ａには示されていないが、付加的なパケットロスが検出されないと仮定すれば、タイル／フレーム８は、その後、タイル／フレーム７に依存すべくエンコードされ、そしてタイル／フレーム９は、タイル／フレーム８に依存すべくエンコードされる。
上述したように、エンコーダ２６００及びデコーダ２６０２は、両方とも、過去のエンコーダ及びデコーダ状態２６１１及び２６２１を各々メモリ２６１０及び２６２０に維持する。従って、タイル／フレーム７をエンコードするときに、エンコーダ２６００は、タイル／フレーム３に関連した以前のエンコーダ状態をメモリ２６１０から検索する。同様に、デコーダ２６０２に関連したメモリ２６２０は、少なくとも最後に知られた良好なデコーダ状態（この例では、Ｐタイル／フレーム３に関連した状態）を記憶する。その結果、デコーダ２６０２は、タイル／フレーム７をデコードできるようにタイル／フレーム３に関連した過去の状態情報を検索する。
上述した技術の結果として、Ｉタイル／フレームが要求されないので（ストリームのスタートにデコーダ及びエンコーダを初期化する以外）、比較的小さな帯域巾を使用して、リアルタイム、短待ち時間の双方向ビデオをエンコードし、ストリーミングすることができる。更に、デコーダにより発生されるビデオ映像は、失われたタイル／フレーム４及び（この失われたタイル／フレーム４のために適切にデコードできない）タイル／フレーム５及び６から生じる望ましからぬ歪を一時的に含むが、この歪は、非常に短い時間中、見ることができる。更に、（フルビデオフレームではなく）タイルが使用される場合には、歪は、レンダリングされるビデオ映像の特定の領域に限定される。
本発明の一実施形態による方法が図２６ｂに示されている。２６５０において、以前に発生されたタイル／フレームに基づいて、タイル／フレームが発生される。２６５１において、失われたタイル／フレームが検出される。１つの実施形態では、失われたタイル／フレームは、上述したように、エンコーダからデコーダへ通信される情報に基づいて検出される。２６５２において、首尾よく受信され及び／又はデコーダでデコードされたと分かっているタイル／フレームに基づいて次のタイル／フレームが発生される。１つの実施形態では、エンコーダは、首尾良く受信され及び／又はデコードされたタイル／フレームに関連した状態をメモリからロードすることにより次のタイル／フレームを発生する。同様に、デコーダは、新たなタイル／フレームを受信すると、首尾良く受信され及び／又はデコードされたタイル／フレームに関連した状態をメモリからロードすることによりタイル／フレームをデコードする。
１つの実施形態において、首尾良く受信され及び／又はエンコーダにおいてデコードされた最後のタイル／フレームに基づいて、次のタイル／フレームが発生される。別の実施形態では、発生される次のタイル／フレームがＩタイル／フレームである。更に別の実施形態では、以前に首尾良く受信されたタイル／フレームに基づいて次のタイル／フレームを発生するか又はＩフレームとして発生するかの選択は、どれほど多くのタイル／フレームが失われたか、及び／又はチャンネルの待ち時間に基づく。比較的少数（例えば、１又は２）のタイル／フレームが失われ、そして往復待ち時間が比較的短い（例えば、１又は２フレームの時間）状況では、Ｐタイル／フレームを発生するのが最適である。というのは、首尾良く受信された最後のタイル／フレームと、新たに発生されるタイル／フレームとの間の差が比較的小さいからである。多数のタイル／フレームが失われるか又は往復待ち時間が長い場合には、Ｉタイル／フレームを発生するのが最適である。というのは、首尾良く受信された最後のタイル／フレームと、新たに発生されるタイル／フレームとの間の差が大きいからである。１つの実施形態では、Ｉタイル／フレームを送信するか、Ｐタイル／フレームを送信するか決定するために、タイル／フレームロススレッシュホールド及び／又は待ち時間スレッシュホールド値がセットされる。失われたタイル／フレームの数がタイル／フレームロススレッシュホールドより低く、及び／又は往復待ち時間が待ち時間スレッシュホールド値より低い場合には、新たなＩタイル／フレームが発生され、さもなければ、新たなＰタイル／フレームが発生される。
１つの実施形態において、エンコーダは、常に、首尾良く受信された最後のタイル／フレームに対してＰタイル／フレームを発生するように試み、そしてエンコーディングプロセスにおいて、Ｐタイル／フレームがおそらくＩタイル／フレームより大きいことをエンコーダが決定した場合には（例えば、それがタイル／フレームの圧縮された１／８を有し、そして圧縮されたサイズが、以前に圧縮された平均Ｉタイル／フレームのサイズの１／８より大きい場合には）、エンコーダは、Ｐタイル／フレームの圧縮を断念し、それに代わって、Ｉタイル／フレームを圧縮する。
失われたパケットの発生が頻繁でない場合には、ドロップしたタイル／フレームを報告するためにフィードバックを使用する前記システムは、典型的に、ユーザへのビデオストリームに生じる混乱を非常に僅かなものにする。というのは、エンコーダ２６００がタイル／フレームを短時間で圧縮すると仮定すれば、失われたパケットにより混乱を受けるタイル／フレームが、ほぼ１往復の時間に、クライアント装置２０５とホスティングサービス２１０との間で置き換わるからである。そして、圧縮される新たなタイル／フレームは、非圧縮のビデオストリームの後期フレームに基づくものであるから、ビデオストリームが非圧縮ビデオフレームの後方に入ることはない。しかし、新たなタイル／フレームを含むパケットも失われた場合には、少なくとも２往復の遅延を招き、別の新たなタイル／フレームを再び要求及び送信することになり、これは、多くの実際的な状況において、ビデオストリームに著しい混乱を招くことがある。その結果、ドロップしたタイル／フレームの後に送信される新たにエンコードされたタイル／フレームがホスティングサービス２１０からクライアント装置２０５へ首尾良く送信されることが非常に重要である。
１つの実施形態において、図１１ａ、１１ｂ、１１ｃ及び１１ｄに示されて上述されたもののような順方向エラー修正（ＦＥＣ）コード化技術を使用して、新たにエンコードされたタイル／フレームを失う確率を軽減する。タイル／フレームを送信するときにＦＥＣコーディングが既に使用されている場合には、新たにエンコードされるタイル／フレームに対してより強いＦＥＣコードが使用される。
ドロップしたパケットの１つの潜在的な原因は、例えば、ユーザの家屋２１１におけるブロードバンド接続の他のユーザが多量の帯域巾を使用し始める場合にチャンネル帯域巾が突然失われることである。（ＦＥＣが使用される場合でも）新たに発生されたタイル／フレームもパケットのドロップのために失われる場合には、１つの実施形態において、新たにエンコードされた第２のタイル／フレームがドロップしたことがクライアント４１５によりホスティングサービス２１０に通知されるとき、ビデオコンプレッサ４０４は、その後に新たにエンコードされるタイル／フレームをエンコードするときにデータレートを下げる。異なる実施形態では、異なる技術を使用してデータレートが減少される。例えば、１つの実施形態において、このデータレートの低下は、圧縮比を高めることにより、エンコードされたタイル／フレームのクオリティを下げることで、達成される。別の実施形態では、ビデオのフレームレートを下げ（例えば、６０ｆｐｓから３０ｆｐｓへ）、それに応じて、データ送信のレートを低速にすることで、データレートが下げられる。一実施形態では、データレートを下げるために両方の技術が使用される（例えば、両方とも、フレームレートを下げ、圧縮比を上げる）。データ送信のこの低いレートが、パケットのドロップを首尾良く軽減する場合には、上述したチャンネルデータレート検出及び調整方法により、ホスティングサービス２１０は、低いデータレートでエンコーディングを続け、次いで、チャンネルが許すとき、データレートを徐々にアップ方向又はダウン方向に調整する。ドロップしたパケット及び／又は待ち時間に関連したフィードバックデータを受信し続けることで、ホスティングサービス２１０は、現在チャンネル状態に基づいてデータレートを動的に調整することが許される。
オンラインゲームシステムにおける状態管理
本発明の一実施形態は、能動的ゲームの現在状態を効率的に記憶してサーバー間で搬送する技術を使用する。ここに述べる実施形態は、オンラインゲームに係るものであるが、本発明の基礎的な原理は、種々の他の形式のアプリケーション（例えば、設計アプリケーション、ワードプロセッサ、ｅ−メール又はインスタントメッセージングのような通信ソフトウェア、等）にも使用することができる。図２７ａは、この実施形態を具現化するための規範的なシステムアーキテクチャーを示し、図２７ｂは、規範的な方法を示す。この方法及びシステムアーキテクチャーは、同時に説明するが、図２７ｂに示す方法は、特定のシステムアーキテクチャーに限定されない。
図２７ｂの２７５１において、ユーザは、クライアント装置２０５からホスティングサービス２１０の新たなオンラインゲームを開始する。それに応答して、２７５２において、ゲーム２７０２ａの「クリーン」映像が記憶装置（例えば、ゲームを実行するサーバーに直結されるか、又はネットワークを通してサーバーに接続されるかに関わらず、ハードドライブ）から、ホスティングサービス２１０ａのメモリ（例えば、ＲＡＭ）へロードされる。「クリーン」映像は、（例えば、ゲームを初めて実行するときのように）ゲームのプレイを開始する前のゲームのためのランタイムプログラムコード及びデータを含む。ユーザは、次いで、２７５３において、ゲームをプレイし、「クリーン」映像を非クリーン映像（例えば、図２７ａにおいて「状態Ａ」で表された実行ゲーム）へ変化させる。２７５４において、ユーザ又はホスティングサービス２１０ａによってゲームが休止又は終了される。２７５５において、ホスティングサービス２１０ａの状態管理ロジック２７００ａは、ゲームの「クリーン」映像と現在ゲーム状態（状態Ａ）との間の相違を決定する。例えば、Ｕｎｉｘオペレーティングシステムで利用できる良く知られた“ｄｉｆｆ”ユーティリティに使用されるものを含む２つのバイナリ映像間の差を計算するために、種々の既知の技術を使用することができる。もちろん、本発明の基礎的な原理は、差を計算するための特定の技術に限定されない。
どのように差を計算するかに関わらず、それらが計算されると、差のデータが記憶装置２７０５ａ内にローカル記憶され、及び／又は異なるホスティングサービス２１０ｂへ送信される。異なるホスティングサービス２１０ｂへ送信される場合には、差のデータが、新たなホスティングサービス２１０ｂにおける記憶装置（図示せず）に記憶される。いずれの場合にも、差のデータは、ホスティングサービスにおけるユーザのアカウントに関連付けられ、ユーザがホスティングサービスにログインしてゲームを開始する次のときに、それが識別される。１つの実施形態では、直ちに送信されるのではなく、ユーザがゲームのプレイを試みる（且つ異なるホスティングサービスが、ゲームをホストする最良の選択肢として識別される）次のときまで、差のデータは、新たなホスティングサービスへ送信されない。
図２７ｂに示す方法に戻ると、２７５７において、ユーザは、ユーザが最初にゲームをプレイした同じクライアント装置２０５であるか、又は異なるクライアント装置（図示せず）であるクライアント装置からゲームを再開する。それに応答して、２７５８において、ホスティングサービス２１０ｂの状態管理ロジック２７００ｂは、ゲームの「クリーン」映像を記憶装置及び差のデータから検索する。２７５９において、状態管理ロジック２７００ｂは、クリーン映像及び差のデータを合成して、ゲームがオリジナルのホスティングサービス２１０ａにあったときの状態（状態Ａ）を再構成する。例えば、Ｕｎｉｘオペレーティングシステムで利用できる良く知られた“パッチ”ユーティリティに使用されるものを含む差のデータを使用してバイナリ映像の状態を再構成するために、種々の既知の技術を使用することができる。ＰＣバックアップのような良く知られたバックアッププログラムに使用される差の計算技術を使用してもよい。本発明の基礎的な原理は、差のデータを使用してバイナリ映像を再生成する特定の技術に限定されない。
加えて、２７６０において、プラットホーム依存データ２７１０が最終的なゲーム映像２７０１ｂに合体される。プラットホーム依存データ２７１０は、行先サーバープラットホームに対して独特のデータを含む。例えば、これに限定されないが、プラットホーム依存データ２７１０は、新たなプラットホームのメディアアクセスコントロール（ＭＡＣ）アドレス、ＴＣＰ／ＩＰアドレス、１日の時刻、ハードウェアシリアル番号（例えば、ハードドライブ及びＣＰＵのための）、ネットワークサーバーアドレス（例えば、ＤＨＣＰ／Ｗｉｎｓサーバー）、及びソフトウェアシリアル番号／アクチベーションコード（オペレーティングシステムシリアル番号／アクチベーションコードを含む）を含む。
クライアント／ユーザに関連した他のプラットホーム依存データは、次のものを含む（これに限定されないが）。
１．ユーザスクリーンの解像度。ユーザがゲームを再開するときに、ユーザは、異なる解像度の異なる装置を使用してもよい。
２．ユーザコントローラの構成。ゲームが再開するとき、ユーザは、ゲームコントローラからキーボード／マウスへスイッチすることができる。
３．割引率が終了になったかどうか（例えば、ユーザが促進期間中にゲームをプレイしていたが、今や、通常期間の高いコストでプレイする場合）、又はユーザ又は装置に何らかの年齢制約があるかどうか（例えば、ユーザの親が子供に対する設定を切り換え、子供が成人向け資料を見られないようにする）、又はゲームをプレイする装置（例えば、パブリックライブラリのコンピュータ）が、成人向け資料を表示できるかどうかについて何らかの制約を有するかどうか、のようなユーザの資格。
４．ユーザのランク。ユーザは、あるリーグにおいてマルチプレーヤゲームをプレイすることが許されているが、他の若干のユーザがユーザランクを越えるために、ユーザは、より低いリーグへ格下げされる。
プラットホーム依存データ２７１０の以上の例は、本発明の実施形態を例示するために取り上げられたものである。本発明の基礎的な原理は、プラットホーム依存データの特定のセットに限定されない。
図２８は、第１のホスティングサービスにおける状態管理ロジック２７００ａが実行ゲーム２７０１ａから差のデータ２８００をどのように抽出するかグラフで示す。第２のホスティングサービスにおける状態管理ロジック２７００ｂは、次いで、クリーン映像２７０２ｂを差のデータ２８００及びプラットホーム依存データ２７１０と合成し、実行ゲーム２７０１ｂの状態を再生する。図２８に一般的に示すように、差のデータのサイズは、全ゲーム映像２７０１ａのサイズより著しく小さく、その結果、差のデータだけを記憶／送信することで、著しい量の記憶スペース及び帯域巾が保存される。図２８には示されていないが、プラットホーム依存データ２７００は、若干の差のデータを、それが最終的なゲーム映像２７０１ｂに合体されるときに、オーバーライトすることができる。
オンラインビデオゲームの具現化について上述したが、本発明の基礎的な原理は、ビデオゲームに限定されない。例えば、以上の状態管理技術は、任意の形式のオンラインホストアプリケーションの環境内で具現化することができる。
クライアントデコーダを維持する技術
本発明の一実施形態において、ホスティングサービス２１０は、ユーザがホスティングサービス２１０への接続を要求するたびに、クライアント装置２０５へ新たなデコーダを送信する。従って、この実施形態では、クライアント装置により使用されるデコーダは、常に、最新のものであり、クライアント装置において具現化されるハードウェア／ソフトウェアに対して独特に仕立てられる。
図２９に例示されたように、この実施形態では、クライアント装置２０５に永久的にインストールされるアプリケーションは、デコーダを含まない。むしろ、クライアント装置２０５がホスティングサービス２１０に接続されるたびに一時的デコーダ２９００のダウンロード及びインストールを管理するのはクライアントダウンローダーアプリケーション２９０３である。このダウンローダーアプリケーション２９０３は、ハードウェア、ソフトウェア、ファームウェア、又はその組み合わせで具現化することができる。新たなオンラインセッションに対するユーザ要求に応答して、ダウンローダーアプリケーション２９０３は、クライアント装置２０５に関連した情報を、ネットワーク（例えば、インターネット）を経て送信する。この情報は、クライアント装置及び／又はクライアント装置のハードウェア／ソフトウェア構成（例えば、プロセッサ、オペレーティングシステム、等）を識別する識別データを含む。
この情報に基づき、ホスティングサービス２１０のダウンローダーアプリケーション２９０１は、クライアント装置２０５に使用されるべき適当な一時的デコーダ２９００を選択する。ホスティングサービスのダウンローダーアプリケーション２９０１は、次いで、一時的デコーダ２９００を送信し、そしてクライアント装置のダウンローダーアプリケーション２９０３は、クライアント装置２０５のデコーダを検証し及び／又はインストールする。エンコーダ２９０２は、次いで、ここに述べるいずれかの技術を使用してオーディオ／ビデオコンテンツをエンコードし、そしてコンテンツ２９１０をデコーダ２９００へ送信する。新たなデコーダ２９００がインストールされると、現在オンラインセッションに対するコンテンツをデコードする（即ち、ここに述べるオーディオ／ビデオ解凍技術の１つ以上を使用して）。一実施形態において、セッションが終了したときに、デコーダ２９００がクライアント装置２０５から除去される（例えば、アンインストールされる）。
一実施形態では、ダウンローダーアプリケーション２９０３は、一時的デコーダ２９００がダウンロードされるときに、チャンネルにおいて達成できるデータレート（例えば、データをダウンロードするのにどれほどの時間を要するか決定することにより）、チャンネルにおけるパケットロスレート、及びチャンネルの待ち時間のようなチャンネル評価を行うことにより、チャンネルを特徴付ける。ダウンローダーアプリケーション２９０３は、チャンネル評価を表すチャンネル特徴付けデータを発生する。このチャンネル特徴付けデータは、次いで、クライアント装置２０５からホスティングサービスのダウンローダー２９０１へ送信され、このダウンローダーは、チャンネル特徴付けデータを使用して、クライアント装置２０５へメディアを送信するためにチャンネルをどのように最良に使用するか決定する。
クライアント装置２０５は、典型的に、一時的デコーダ２９００のダウンロード中にホスティングサービス２１０へメッセージを返送する。これらのメッセージは、パケットがエラーなく受信されたかエラーがあったかを指示する確認メッセージを含むことができる。加えて、これらのメッセージは、データレート（パケットが受信されるレートに基づいて計算された）、パケットエラーレート（エラーを伴って受信されたと報告されたパケットのパーセンテージに基づく）、及びチャンネルの往復待ち時間（送信された所与のパケットに関するフィードバックをダウンローダー２９０１が受信するまでに要した時間長さに基づく）に関してダウンローダー２９０１へフィードバックを与える。
例えば、データレートが２Ｍｂｐｓと決定された場合には、ダウンローダーは、データレートが５Ｍｂｐｓと決定された場合（例えば、６０ｆｐｓにおいて１２８０ｘ７２０）より小さなビデオウインドウ解像度をエンコーダ２９０２に対して選択する（例えば、６０ｆｐｓにおいて６４０ｘ４８０）。パケットロスの割合に基づいて、異なる順方向エラー修正（ＦＥＣ）又はパケット構造を選択することができる。
パケットロスが非常に低い場合には、圧縮されたオーディオ及びビデオは、エラー修正なしに送信される。パケットロスが中程度の場合には、圧縮されたオーディオ及びビデオは、エラー修正コード技術（例えば、図１１ａ、１１ｂ、１１ｃ及び１１ｄに示されて上述されたような）で送信される。パケットロスが非常に高い場合には、充分なクオリティのオーディオビジュアルストリームを送信できないと決定され、クライアント装置２０５は、通信チャンネル（即ち、「リンク」）を通してホスティングサービスを利用できないことをユーザに通知するか、又はパケットロスの低いホスティングサービスへの異なるルートを確立するよう試みることができる（以下に述べるように）。
待ち時間が短い場合には、圧縮されたオーディオ及びビデオを短い待ち時間で送信してセッションを確立することができる。待ち時間が非常に長い（例えば、８０ｍｓより長い）場合には、短い待ち時間を要求するゲームにとって、クライアント装置２０５は、リンクを通してホスティングサービスを利用できないか、又はリンクは利用できるが、ユーザ入力に対する応答時間が鈍いか又は「遅れる」か、或いは待ち時間の短いホスティングサービスへの異なるルートの確立をユーザが試みることができることを、ユーザに通知することができる（以下に述べるように）。
クライアント装置２０５は、ネットワーク（例えば、インターネット）を通る別のルートを経てホスティングサービス２１０への接続を試み、障害が減少されたかどうか（例えば、パケットロスが低くなったか、待ち時間が短くなったか、又はデータレートが高くなったか）調べることができる。例えば、ホスティングサービス２１０は、地理的に多数の位置（例えば、ロスアンジェルス及びデンバーのホスティングセンター）からインターネットに接続することができ、おそらく、ロスアンジェルスでは混雑のためにパケットロスが高いが、デンバーでは混雑がない。又、ホスティングサービス２１０は、複数のインターネットサービスプロバイダー（例えば、ＡＴ＆Ｔ及びＣｏｍｃａｓｔ）を通してインターネットに接続することができる。
クライアント装置２０５と、サービスプロバイダーの１つ（例えば、ＡＴ＆T）との間の混雑又は他の問題のために、パケットロス及び／又は長い待ち時間及び／又は制約のあるデータレートを招くことがある。しかしながら、クライアント装置２０５が別のサービスプロバイダー（例えば、Ｃｏｍｃａｓｔ）を通してホスティングサービス２１０に接続される場合には、混雑の問題なく、及び／又は低いパケットロス及び／又は短い待ち時間及び／又は高いデータレートで接続することができる。従って、クライアント装置２０５は、指定のスレッシュホールド（例えば、指定の期間にわたる指定のドロップパケット数）を越えるパケットロス、指定のスレッシュホールドを越える待ち時間、及び／又は一時的デコーダ２９００をダウンロードする間の指定のスレッシュホールドより低いデータレートを経験した場合に、一実施形態では、（典型的に異なるＩＰアドレス又は異なるドメイン名へ接続することにより）別のルートを経てホスティングサービス２１０への再接続を試み、より良い接続が得られるかどうか決定する。
別の接続オプションが尽きた後に接続がまだ受け容れられない障害を経験している場合には、インターネットへのクライアント装置２０５のローカル接続が障害を被っているか、又は適度な待ち時間を達成するのにホスティングサービス２１０から離れ過ぎている。このような場合には、クライアント装置２０５は、リンクを通してホスティングサービスが利用できないか、又は障害を伴う状態でしか利用できないか、及び／又はある形式の短待ち時間ゲーム／アプリケーションしか利用できないことをユーザに通知する。
一時的デコーダがダウンロードされている間にホスティングサービス２１０とクライアント装置２０５との間のリンク特性のこの評価及び潜在的な改善が行われるので、クライアント装置２０５が一時的デコーダ２９００のダウンロードとリンク特性の評価とに別々に費やす必要のある時間量が短縮される。それでも、別の実施形態では、リンク特性の評価及び潜在的な改善は、クライアント装置２０５により、一時的デコーダ２９００をダウンロードすることから別々に遂行される（例えば、デコーダプログラムコードではなく、ダミーテストデータを使用することにより）。これが好ましい具現化であることの理由は多数ある。例えば、ある実施形態では、クライアント装置２０５は、その一部分又は全体がハードウェアで具現化される。従って、これらの実施形態では、ダウンロードに必要なソフトウェアデコーダは存在しない。
規格ベースのタイルサイズを使用する圧縮
上述したように、タイルベースの圧縮が使用されるときに、本発明の基礎的な原理は、特定のタイルサイズ、形状又は方向に限定されない。例えば、ＭＰＥＧ−２及びＭＰＥＧ−４のようなＤＣＴベースの圧縮システムでは、タイルは、マクロブロック（１６ｘ１６ピクセルのブロックを典型的に表すビデオ圧縮に使用されるコンポーネント）のサイズである。この実施形態は、タイルと共に作用するための非常に微細な粒度レベルを与える。
更に、タイルサイズに関わりなく、種々の形式のタイルパターンを使用することができる。例えば、図３０は、各Ｒフレーム３００１−３００４に複数のＩタイルが使用される一実施形態を示す。Ｉタイルが各Ｒフレーム全体に分散されて、４個のＲフレームごとに１つの完全なＩフレームが発生されるような回転パターンが使用される。このように、Ｉタイルを分散することで、パケットロスの影響が減少される（ロスをディスプレイの小さな領域に制限する）。
又、タイルは、基礎的な圧縮アルゴリズムの一体的なネーティブ構造に対するサイズであってもよい。例えば、Ｈ．２６４圧縮アルゴリズムが使用される場合には、１つの実施形態において、タイルがＨ．２６４「スライス」のサイズにセットされる。これは、ここに述べる技術を、Ｈ．２６４及びＭＰＥＧ−４のような種々の異なる標準圧縮アルゴリズムの環境に容易に一体化できるようにする。タイルサイズがネーティブな圧縮構造にセットされると、上述したものと同じ技術を具現化することができる。
ストリーム巻き戻し及び再生動作の技術
図１５を参照して上述したように、ａｐｐ／ｇａｍｅサーバー１５２１−１５２５により発生される非圧縮のビデオ／オーディオストリーム１５２９は、複数の解像度の共有ハードウェア圧縮１５３０により同時に圧縮されて、複数の圧縮されたビデオ／オーディオストリーム１５３９を生じる。例えば、ａｐｐ／ｇａｍｅサーバー１５２１により発生されたビデオ／オーディオストリームは、共有ハードウェア圧縮１５３０により１２８０ｘ７２０ｘ６０ｆｐｓで圧縮され、アウトバウンドインターネットトラフィック１５９９としてアウトバウンドルート１５４０を経てユーザへ送信される。その同じビデオ／オーディオストリームは、共有ハードウェア圧縮１５３０によりａｐｐ／ｇａｍｅサーバー１５２２への経路１５２２を経て（又は遅延バッファ１５１５を通して）サムネールサイズ（例えば、２００ｘ１１３）へ同時にスケールダウンされ、図１６のサムネールの集合体の１つのサムネール１６００として表示される。サムネール１６００が図１７の中間サイズ１７００を通して図１８のサイズ１８００（１２８０ｘ７２０ｘ６０ｆｐｓ）へとズームされるときに、サムネールストリームを解凍するのではなく、ａｐｐ／ｇａｍｅサーバー１５２２は、ａｐｐ／ｇａｍｅサーバー１５２１のユーザへ送られる１２８０ｘ７２０ｘ６０ｆｐｓストリームのコピーを解凍し、そして高解像度ビデオを、それがサムネールサイズからズームされるときに、１２８０ｘ７２０サイズへとスケーリングする。この解決策は、１２８０ｘ７２０の圧縮されたストリームを、２回、再使用するという効果を有する。しかし、幾つかの欠点もある。（ａ）ユーザへ送信される圧縮されたビデオストリームは、ユーザのインターネット接続のデータスループットが変化する場合には画質が変化し、たとえそのユーザのインターネット接続が変化しなくても、ａｐｐ／ｇａｍｅサーバー１５２２の「見物」ユーザが見る画質が変化することになり、（ｂ）ａｐｐ／ｇａｍｅサーバー１５２２は、処理リソースを使用して、１２８０ｘ７２０映像全体を解凍し、次いで、ズーム中に相当に小さいサイズ（例えば、６４０ｘ３６０）を表示するためにその映像をスケーリング（及びおそらく再サンプリングフィルタを適用）しなければならず、（ｃ）インターネット接続帯域巾の制限及び／又はパケットの消失／崩壊のためにフレームがドロップし、そして見物ユーザが遅延バッファ１５１５に記録されたビデオを「巻き戻し」及び「休止」する場合には、見物ユーザは、ドロップしたフレームが遅延バッファに見つからないことが分かり（これは、ユーザがフレームごとに「ステップ」する場合には特に明らかであり）、及び（ｄ）見物ユーザが遅延バッファに記録されたビデオにおける特定のフレームを見出すために巻き戻す場合には、ａｐｐ／ｇａｍｅサーバー１５２２は、遅延バッファに記録されたビデオストリームにおける探し求めるフレームの前にＩフレーム又はＩタイルを見出し、次いで、希望のフレームに到達するまで全てのＰフレーム／タイルを解凍しなければならない。この同じ限定が、ビデオ／オーディオストリームを生で「見物している」ユーザに適用されるだけでなく、ビデオ／オーディオストリームのアーカイブ（例えば、“Ｂｒａｇ Ｃｌｉｐ”）コピーを見ているユーザ（ビデオ／オーディオストリームを発生したユーザを含む）にも適用される。
本発明の別の実施形態は、ビデオストリームを２つ以上のサイズ及び／又は構造で圧縮することによりこれらの問題に対処する。１つのストリーム（「生」のストリーム）は、ここに述べるように、ネットワーク接続の特性（例えば、データ帯域巾、パケット信頼性）、及びユーザのローカルクライアント能力（例えば、解凍能力、表示解像度）に基づいて、エンドユーザへのストリームへと最適に圧縮される。他のストリーム（“ＨＱ”ストリームと称される）は、高いクオリティ、１つ以上の解像度、及びビデオ再生可能な構造で圧縮され、このようなＨＱストリームは、ルーティングされて、サーバーセンター２１０内に記憶される。例えば、１つの実施形態において、ＨＱ圧縮ストリームは、ＲＡＩＤディスクアレイ１５１５に記憶され、そして休止、巻き戻し及び他の再生機能（例えば、他のユーザへ配布されて見られる“Ｂｒａｇ Ｃｌｉｐ”）を与えるのに使用される。
図３１ａに示すように、本発明の一実施形態は、ストリームの混乱のために、或いはＩタイル又はＩフレームが（上述した）Ｉタイル又はＩフレームよりおそらく小さいと決定されるために、必要でない限り、１つはＩタイル又はＩフレーム３１１０を周期的に含みそしてもう１つはＩタイル又はＩフレーム３１１１を含まない少なくとも２つのフォーマットでビデオストリームを圧縮できるエンコーダ３１００を備えている。例えば、ビデオゲームをプレイしている間にユーザへ送信される「生の」ストリーム３１１１は、Ｐフレームのみを使用して圧縮される（上述したように、Ｉタイル又はＩフレームが必要でも小さいものでもない限り）。加えて、この実施形態のエンコーダ３１００は、生のビデオストリーム３１１１を、一実施形態においてＩタイル又はＩフレームを周期的に含む第２のフォーマット（又は同様の形式の映像フォーマット）で同時に圧縮する。
上述した実施形態は、Ｉタイル、Ｉフレーム、Ｐタイル及びＰフレームを使用するが、本発明の基本的な原理は、特定の圧縮アルゴリズムに限定されない。例えば、フレームが以前の又はその後のフレームに依存する任意の形式の映像フォーマットを、Ｐタイル又はＰフレームに代わって使用することができる。同様に、以前の又はその後のフレームに依存しない任意の形式の映像フォーマットを、前記Ｉタイル又はＩフレームに置き換えることもできる。
上述したように、ＨＱストリーム３１１０は、周期的なＩフレーム（例えば、一実施形態では、１２フレームごと、等々）を含む。これは、ユーザが記憶されたビデオストリームを特定のポイントへ素早く巻き戻すことを希望する場合に、Ｉタイル又はＩフレームが要求されるので、意義深いことである。Ｐフレームだけの圧縮されたストリームでは（即ち、シーケンスの第１フレームがＩフレームでないと）、デコーダは、（数時間の長さのこともある）シーケンスの第１フレームへ戻り、ユーザが巻き戻しを希望するポイントまでＰフレームを解凍する必要がある。ＨＱストリーム３１１０に記憶された１２フレームごとのＩフレームでは、ユーザは、特定のスポットへ巻き戻すことを決心し、その直前のＨＱストリームのＩフレームは、希望のフレームより１２以下のフレームだけ前である。デコーダの最大デコードレートがリアルタイム（例えば、６０フレーム／秒のストリームに対して１／６０秒）である場合でも、１２（フレーム）／６０（フレーム／秒）＝１／５秒だけＩフレームから離れている。そして、多くの場合に、デコーダは、リアルタイムより非常に速く動作することができ、例えば、２ｘリアルタイムで、デコーダは、６フレーム内に１２フレームをデコードすることができ、これは、「巻き戻し」に対する第２の遅延の１／１０に過ぎない。言うまでもなく、高速デコーダ（例えば、１０ｘリアルタイム）でも、直前のＩフレームが巻き戻しポイントより多数のフレーム分だけ前にある場合には受け容れられない遅延をもつことになる（例えば、「巻き戻し」を行うのに１時間／１０＝６分を要する）。別の実施形態では、周期的なＩタイルが使用され、この場合に、ユーザが巻き戻しを求めるとき、デコーダは、直前のＩタイルを巻き戻しポイントの前に見出し、次いで、巻き戻しポイントまで全てのタイルがデコードされるまで、そのポイントからそのタイルのデコーディングを開始する。周期的なＩタイル又はＩフレームは、Ｉフレーム全体を排除するより効率の悪い圧縮となるが、ホスティングサービス２１０は、典型的に、ＨＱストリームを管理するのに充分過ぎるローカル利用帯域巾及び記憶容量を有する。
別の実施形態において、エンコーダ３１００は、ＨＱストリームを、上述したように、周期的なＩタイル又はＩフレームで、それに続いて、Ｐタイル又はＰフレームでエンコードするが、それに先行して、Ｂタイル又はＢフレームでエンコードする。Ｂフレームは、上述したように、Ｉフレームに先行するフレームであり、時間的に後方に作用するＩフレームからのフレーム差に基づくものである。Ｂタイルは、Ｉタイルに先行するタイル対応部であり、Ｉタイルから後方に作用するフレーム差に基づくものである。この実施形態において、望ましい巻き戻しポイントがＢフレームである（又はＢタイルを含む）場合には、デコーダは、直前のＩフレーム又はＩタイルを見出し、そして希望の巻き戻しポイントがデコードされるまで時間的に後方にデコードし、次いで、ビデオの再生がそのポイントから前方に進むにつれて、デコーダは、前方に向かう次々のフレームにおいて、Ｂフレーム、Ｉフレーム及びＰフレーム（又はそれらのタイル対応部）をデコードする。Ｉ及びＰ形式に加えてＢフレーム又はＢタイルを使用する効果は、所与の圧縮比においてしばしば高いクオリティを達成できることである。
更に別の実施形態では、エンコーダ３１００は、ＨＱストリームを全てのＩフレームとしてエンコードする。この解決策の効果は、各巻き戻しポイントがＩフレームであり、その結果、巻き戻しポイントに到達するために他のフレームをデコードする必要がないことである。欠点は、圧縮データレートが、Ｉ、Ｐ又はＩ、Ｐ、Ｂストリームのエンコーディングに比して非常に高いことである。
他のビデオストリーム再生アクション（例えば、高速又は低速巻き戻し、高速又は低速送り、等）は、典型的に、周期的なＩフレーム又はＩタイルで（単独であるか又はＰ及び／又はＢ対応部と組み合わされて）非常に実際的に達成される。というのは、各々の場合に、ストリームは、フレームごとに時間的に前方にではなく、異なるフレーム順序で再生され、その結果、デコーダは、シーケンスにおける特定のしばしば任意のフレームを見出してデコードする必要があるからである。例えば、非常に高速の送り（例えば、１００ｘ速度）の場合には、再生される各次々のフレームが、手前のフレームより１００フレーム後である。１０ｘリアルタイムで動作し、１フレームの時間内に１０フレームをデコードするデコーダでも、１００ｘ高速送りを達成するには、依然、１０ｘ遅過ぎである。一方、上述した周期的なＩフレーム又はＩタイルでは、デコーダは、次に表示する必要のあるフレームに対して最も近い適用可能なＩフレーム又はＩタイルを探し、そしてターゲットフレームポイントまでの介在するフレーム又はタイルのみをデコードすることができる。
別の実施形態では、Ｉフレームは、ＨＱストリームにおいて一貫した周期（例えば、常に、８フレームごと）でエンコードされ、そしてＩフレームレートより速い高速送り及び巻き戻しに対してユーザに使用できる速度乗数は、Ｉフレーム周期の厳密な倍数である。例えば、Ｉフレーム周期が８フレームである場合には、ユーザに使用できる高速送り又は巻き戻しの速度は、１Ｘ、２Ｘ、３Ｘ、４Ｘ、８Ｘ、１６Ｘ、６４Ｘ、１２８Ｘ及び２５６Ｘである。Ｉフレーム周期より速い速度の場合には、デコーダは、最初、その速度でのフレーム数だけ先の最も近いＩフレームへ前進ジャンプし（例えば、現在表示されているフレームが、Ｉフレームより３フレーム前の場合には、１２８Ｘにおいて、デコーダは、フレーム１２８＋３フレーム先へジャンプし）、次いで、各次々のフレームに対し、デコーダは、選択された速度として厳密なフレーム数だけジャンプし（例えば、１２８Ｘの選択された速度では、デコーダは、１２８フレームジャンプし）、そのたびにＩフレームに厳密に着地する。従って、Ｉフレーム周期より速い全ての速度がＩフレーム周期の厳密な倍数であるとすれば、デコーダは、希望のフレームを探すためにその先行又は後続フレームをデコードする必要がなく、表示フレーム当たり１つのＩフレームをデコードするだけでよい。Ｉフレーム周期よりゆっくりとした速度（例えば、１Ｘ、２Ｘ、３Ｘ、４Ｘ）、又はＩフレーム周期の倍数でない速い速度の場合には、デコーダは、希望のフレームを表示するために付加的な新たにデコードされるフレームを最低限しか必要としないのはどのフレームか求め、未デコードのＩフレーム又は既にデコードされたフレームは、デコードされた形態で依然利用できるようにし（ＲＡＭ又は他の高速記憶装置において）、次いで、希望のフレームがデコードされ表示されるまで、介在フレームを必要に応じてデコードする。例えば、４Ｘの高速送りでは、８ＸのＩフレーム周期性をもつＩ、Ｐエンコードシーケンスにおいて、現在フレームが、Ｉフレームの１フレーム後のＰフレームである場合に、表示されるべき希望のフレームは、４フレーム後となり、これは、先行するＩフレームに続く５番目のＰフレームである。現在表示されたフレーム（丁度デコードされた）がスタートポイントとして使用される場合には、デコーダは、希望のフレームを表示するのに更に４個のＰフレームをデコードする必要がある。先行するＩフレームが使用される場合には、デコーダは、希望のフレームを表示するのに６個のフレーム（Ｉフレーム及びその後の５個のＰフレーム）をデコードする必要がある。（明らかに、この場合には、デコードすべき付加的なフレームを最小にするために、現在表示されているフレームを使用するのが効果的である。）次いで、４フレーム先にある次にデコードされるべきフレームは、Ｉフレームに続く１番目のＰフレームである。このケースでは、現在デコードされたフレームがスタートポイントとして使用される場合に、デコーダは、更に４個のフレーム（２個のＰフレーム、Ｉフレーム及びＰフレーム）をデコードする必要がある。しかし、それに代わって、次のＩフレームが使用される場合には、デコーダは、Ｉフレーム及びそれに続くＰフレームをデコードするだけでよい。（明らかに、この場合には、デコードすべき付加的なフレームを最小にするために、次のＩフレームをスタートポイントとして使用するのが効果的である。）従って、この例では、デコーダは、現在デコードされたフレームをスタートポイントとして使用することと、その後のＩフレームをスタートポイントとして使用することを交互に行う。一般に重要なこととして、ＨＱビデオストリームの再生モード（高速送り、巻き戻し又は停止）及び速度に関わらず、デコーダは、Ｉフレームであるか又は以前にデコードされたフレームであるかのどちらかのフレームでスタートし、その再生モード及び速度に対して表示される各次々のフレームについて希望のフレームを表示するのに、新たにデコードされるフレームを最小数しか必要としない。
図３１ｂに示すように、ホスティングサービス２１０の１つの実施形態は、ＨＱストリーム３１１０をリプレイするユーザ要求を管理するためのストリームリプレイロジック３１１２を含む。このストリームリプレイロジック３１１２は、ビデオ再生コマンド（例えば、休止、巻き戻し、特定のポイントからの再生、等）を含むクライアント要求を受け取り、それらコマンドを解釈し、そして特定のポイントからのＨＱストリーム３１１０をデコードする（適宜、Ｉフレーム又は以前にデコードされたフレームのいずれかでスタートし、次いで、前方又は後方に特定の位置まで進む）。１つの実施形態では、デコードされたＨＱストリームは、エンコーダ３１００（一度に２つ以上のストリームをエンコードできる場合は潜在的に同じエンコーダ３１００、又は個別のエンコーダ３１００）へ送られて、再圧縮され（ここに述べる技術を使用して）、そしてクライアント装置２０５へ送信される。クライアント装置のデコーダ３１０２は、次いで、上述したように、ストリームをデコードし、レンダリングする。
１つの実施形態において、ストリームリプレイロジック３１１２は、ＨＱストリームをデコードせず、エンコーダ３１００がストリームを再エンコードするようにさせる。むしろ、ＨＱストリーム３１１０を特定のポイントからクライアント装置２０５へ単に直接的にストリーミングさせる。次いで、クライアント装置２０５のデコーダ３１０２がＨＱストリームをデコードする。ここに述べる再生機能は、典型的に、リアルタイムビデオゲームをプレイするのと同じ短待ち時間要求を有するものではないので（例えば、プレーヤが能動的にプレイせずに、ゲームプレイの前に単にレビューするだけである場合に）、通常の高品質ＨＱストリームに典型的に本来ある追加の待ち時間は、受け容れられるエンドユーザ経験（例えば、待ち時間は長いが、高品質ビデオである）を生じさせる。
例えば、これに限定されないが、ユーザがビデオゲームをプレイする場合に、エンコーダ３１００は、ユーザの接続及びローカルクライアントに対して最適化された本質的に全てのＰフレームの生のストリームを与える（例えば、６４０ｘ３６０解像度においてほぼ１．４Ｍｂｐｓ）。又、同時に、エンコーダ３１００は、ビデオストリームをホスティングサービス３１０内でＨＱストリーム３１１０として圧縮し、そしてそのＨＱストリームを、例えば、１２フレームごとにＩフレームを伴い１０Ｍｂｐｓにおいて１２８０ｘ７２０でローカルデジタルビデオデコーダＲＡＩＤアレイに記憶する。ユーザが「休止(Pause)」ボタンに触ると、クライアントの最後にデコードされたフレームでゲームが休止され、スクリーンがフリーズする。次いで、ユーザが「巻き戻し(Rewind)」ボタンに触れると、ストリームリプレイロジック３１１２は、上述したように、最も近いＩフレーム又は既にデコードされた使用可能なフレームから始めて、ＤＶＲ ＲＡＩＤからＨＱストリーム３１１０を読み取る。ストリームリプレイロジック３１１２は、介在するＰ又はＢフレームを必要に応じて解凍し、それらフレームを必要に応じて再シーケンシングして、再生シーケンスが希望の巻き戻し速度で後方に進むようにし、次いで、表示されることが意図された希望のデコードされたものを（良く知られた従来の映像スケーリング技術を使用して）１２８０ｘ７２０から６４０ｘ３６０へサイズ変更し、そして生のストリームエンコーダ３１００は、６４０ｘ３６０解像度の再シーケンシングされたストリームを再圧縮してユーザへ送信する。ユーザが再び休止し、次いで、ビデオを通して単一ステップして、シーケンスを厳密に見る場合には、ＤＶＲ ＲＡＩＤのＨＱストリーム３１１０は、単一ステップに各フレームを使用できるようにする（元の生のストリームが、ここに述べる多数の理由のいずれかで、フレームをドロップしても）。更に、ビデオ再生の画質は、ＨＱストリームの各ポイントにおいてかなり高いが、生のストリームには、例えば、帯域巾が損なわれて、圧縮映像の画質に一時的な低下を招くポイントが生じ得る。短期間中の、又は動画における損なわれた画質は、ユーザにとっては受け入れられるが、ユーザが特定のフレームで停止し（又はゆっくり単一ステップし）、フレームを厳密に調査する場合には、損なわれた画質を受け容れることができない。又、ユーザには、ＨＱストリーム内のポイント（例えば、２分前）を指定することにより、高速送り又は特定スポットへジャンプする能力も与えられる。これら全ての動作は、Ｐフレームのみであるか、又はＩフレームを稀に（又は予期せず）有する生のビデオストリームでは、完全な普遍性及び高い画質において不可能である。
一実施形態では、ＨＱストリームがビデオを記憶する限り、ユーザがビデオストリームを通して前後にスイープできるようにする「スクラバー」（即ち左右のスライダーコントロール）を伴うアップルクイックタイム又はアドベフラッシュビデオウインドウのようなビデオウインドウ（図示せず）がユーザに与えられる。ユーザには、生のストリームを通して「スクラビング」しているように見えるが、実際には、ユーザは、記憶されたＨＱストリーム３１１０を通してスクラビングし、これは、次いで、生のストリームとしてサイズ変更され再圧縮される。更に、上述したように、誰か他の者がＨＱストリームを同時に見るか、又はユーザが別の時間に見る場合には、生のストリームの解像度より高い（又は低い）解像度で見ることはできが、ＨＱストリームは、同時にエンコードされ、そしてその画像は、潜在的にＨＱストリームの画像までは、見る者の生のストリームの画質と同程度となる。
従って、生のストリーム（ここに述べるように、短い待ち時間、帯域巾及びパケットエラー許容要求に適するように）、及び高画質ストリーム再生アクション要求を伴うＨＱストリームの両方を同時にエンコードすることにより、ユーザには、両シナリオの望ましい構成が与えられる。そして、実際に、ユーザにとって、２つの異なるストリームが異なる仕方でエンコードされることが効果的に良く分かる。ユーザの観点から、非常に変化し易く且つ比較的低い帯域巾のインターネット接続で実行されるにも関わらず、その経験は、短い待ち時間で非常に敏感であり、しかも、デジタルビデオレコーディング（ＤＶＲ）の機能は、非常に高画質で、柔軟なアクション及び柔軟な速度を伴う。
上述した技術の結果として、ユーザは、オンラインゲームプレイ又は他のオンライン相互作用の間に、生のストリーム又はＨＱストリームのいずれの制限の影響もなく、生のストリーム及びＨＱビデオストリームの両方の利益を受ける。
図３１ｃは、前記動作を遂行するためのシステムアーキテクチャーの一実施形態を示す。図示されたように、この実施形態では、エンコーダ３１００は、一連の「生の」ストリーム３１２１Ｌ、３１２２Ｌ及び３１２５Ｌと、それに対応する一連の「ＨＱ」ストリーム３１２１Ｈ１−Ｈ３、３１２２Ｈ１−Ｈ３及び３１２５Ｈ１−Ｈ３とを各々エンコードする。各ＨＱストリームＨ１は、全解像度でエンコードされ、一方、各エンコーダＨ２及びＨ３は、ビデオストリームをエンコーディング前の小さなサイズにスケーリングする。例えば、ビデオストリームが１２８０ｘ７２０の解像度である場合には、Ｈ１は、１２８０ｘ７２０の解像度でエンコードし、一方、Ｈ２は、６４０ｘ３６０へスケーリングしてその解像度でエンコードし、そしてＨ３は、３２０ｘ１８０へスケーリングしてその解像度でエンコードする。多数の同時Ｈｎスケーラー／エンコーダを使用して、タスの同時ＨＱエンコーディングを種々の解像度で与えることができる。
生のストリームの各々は、上述したように、インバウンドインターネット接続３１０１を経て受け取ったチャンネルフィードバック信号３１６１、３１６２及び３１６５に応答して動作する（例えば、図２５−２６のフィードバック信号２５０１及び２６０１の説明を参照されたい）。生のストリームは、インターネット（又は他のネットワーク）を通りアウトバウンドルーティングロジック３１４０を経て送信される。生のコンプレッサ３１２１Ｌ−３１２５Ｌは、チャンネルフィードバックに基づいて、圧縮されたビデオストリームを適応させるロジック（フレームをスケーリングし、ドロップさせ、等を含む）を含む。
ＨＱストリームは、インバウンドルーティングロジック３１４１及び１５０２により、信号経路３１５１を経て内部遅延バッファ（例えば、ＲＡＩＤアレイ３１１５）又は他のデータ記憶装置へルーティングされ、及び／又は信号経路３１５２を経てａｐｐ／ｇａｍｅサーバー及びエンコーダ３１００へ更なる処理のためにフィードバックされる。上述したように、ＨＱストリーム３１２１Ｈｎ−３１２５Ｈｎは、その後、要求があった際にエンドユーザへストリーミングされる（例えば、図３１ｂ及びそれに関連した説明を参照されたい）。
１つの実施形態において、エンコーダ３１００は、図１５に示す共有ハードウェア圧縮ロジック１５３０で具現化される。別の実施形態では、エンコーダ及びスケーラーの幾つか又は全部が個々のサブシステムである。本発明の基礎的な原理は、スケーリング又は圧縮リソース或いはハードウェア／ソフトウェア構成の特定の共有に限定されない。
図３１ｃの構成の効果は、フルサイズより小さいビデオウインドウを要求するＡｐｐ／Ｇａｍｅサーバー３１２１−３１２５は、フルサイズウインドウを処理し解凍する必要がないことである。又、中間のウインドウサイズを要求するＡｐｐ／Ｇａｍｅサーバー３１２１−３１２５は、希望のウインドウサイズ付近の圧縮されたストリームを受け取り、次いで、希望のウインドウサイズへスケールアップ又はダウンすることができる。又、Ａｐｐ／Ｇａｍｅサーバー３１２１−３１２５が、別のＡｐｐ／Ｇａｍｅサーバー３１２１−３１２５から同じサイズのビデオストリームを要求する場合には、インバウンドルーティング３１４１は、この技術で良く知られたもののようなＩＰマルチキャスト技術を具現化し、そして要求を行う各Ａｐｐ／Ｇａｍｅサーバーへの独立したストリームを必要とせずに、要求されたストリームを複数のＡｐｐ／Ｇａｍｅサーバー３１２１−３１２５へ一度に放送することができる。放送を受信するＡｐｐ／Ｇａｍｅサーバーがビデオウインドウのサイズを変更する場合には、異なるビデオサイズの放送へ切り換えることができる。従って、任意の大勢のユーザは、各々、それらのビデオウインドウをスケーリングしそして希望のウインドウサイズに厳密にスケーリングされたビデオストリームの利益を常に得るという柔軟性で、Ａｐｐ／Ｇａｍｅサーバービデオストリームを同時に見ることができる。
図３１ｃに示す解決策に伴う１つの欠点は、ホスティングサービス２１０の多数の実際的な具現化において、全ての圧縮されたＨＱストリームの全てのサイズをそのままにしておいて、全ての圧縮されたＨＱストリームが一度に見られるときがないことである。エンコーダ３１００が共有リソースとして具現化されるときには（例えば、ソフトウェア又はハードウェアのいずれかで具現化されるスケーラー／コンプレッサ）、この不経済さが軽減される。しかし、多数の未圧縮のストリームを共通の共有リソースに接続する際には、当該帯域巾のために、実際上の問題が生じる。例えば、各１０８０ｐ６０ストリームは、ほぼ３Ｇｂｐｓであり、ギガビットイーサネットを遥かに上回る。以下に述べる別の実施形態は、この問題に向けられる。
図３１ｄは、各Ａｐｐ／Ｇａｍｅサーバー３１２１−３１２５に次の２つのコンプレッサが割り当てられたホスティングサービス２１０の別の実施形態を示す。（１）チャンネルフィードバック３１６１−３１６５に基づいて圧縮されたビデオストリームを適応させる生のストリームのコンプレッサ３１２１−３１２５Ｌ、及び（２）上述したように全解像度のＨＱストリームを出力するＨＱストリームコンプレッサ。注意すべきことに、生のコンプレッサは、動的で且つ適応性があり、クライアント２０５との両方向通信を使用するが、ＨＱストリームは、非適応性で、一方向である。ストリーム間の他の相違は、生のストリームの画質がチャンネル条件及びビデオ資料の性質に基づいて劇的に変化することである。あるフレームは、画質が悪く、ドロップしたフレームが生じ得る。又、生のフレームは、ほぼ完全にＰフレーム又はＰタイルであり、Ｉフレーム又はＩタイルは稀に表れるだけである。ＨＱストリームは、典型的に、データレートが生のストリームより相当に高く、いずれのフレームもドロップせずに、一貫した高画質を与える。ＨＱストリームは、全てＩフレームでもよいし、又は頻繁で及び／又は規則的なＩフレーム又はＩタイルを有してもよい。又、ＨＱストリームは、Ｂフレーム又はＢタイルを含んでもよい。
１つの実施形態において、共有ビデオスケーリング及び再圧縮３１４２（以下で詳細に述べる）は、上述したルーティングのためにインバウンドルーティング３１４１へ送信される前に、１つ以上の異なる解像度でスケーリング及び再圧縮されるべきあるＨＱビデオストリーム３１２１Ｈ１−３１２５Ｈ１のみを選択する。他のＨＱビデオストリームは、上述したルーティングのためにフルサイズでインバウンドルーティング３１４１へ通されるか、或いは全く通されない。１つの実施形態では、どのＨＱストリームがスケーリング及び再圧縮され及び／又はどのＨＱストリームが全体に通されるかの判断は、その特定のＨＱストリームを特定の解像度（或いはスケーリングされた解像度又は全解像度に近い解像度）で要求しているＡｐｐ／Ｇａｍｅサーバー３１２１−３１２５があるかどうかに基づいて決定される。この手段により、スケーリング及び再圧縮される（又は潜在的に全体に通される）ＨＱストリームのみが、実際に必要とされるＨＱストリームである。ホスティングサービス２１０の多数のアプリケーションでは、これは、スケーリング及び圧縮リソースの劇的な減少を生じさせる。又、各ＨＱストリームが、少なくとも、コンプレッサ３１２１Ｈ１−３１２５Ｈ１によりその全解像度で圧縮されるとすると、共有ビデオスケーリング及び再圧縮３１４２内へルーティングされる必要のある帯域巾は、未圧縮のビデオが受け容れられる場合より劇的に減少される。例えば、３ＧＢｐｓの未圧縮の１０８０ｐ６０ストリームは、１０Ｍｂｐｓへ圧縮されても、依然、非常に高い画質を保持することができる。従って、ギガビットイーサネット接続では、１つの未圧縮の３Ｇｂｐｓビデオストリームすら搬送できないのではなく、画質の明らかな低下がほとんどない状態で、多数の１０Ｍｂｐｓのビデオストリームを搬送することができる。
図３１ｆは、共有ビデオスケーリング及び再圧縮３１４２の細部を、多数のＨＱビデオコンプレッサＨＱ３１２１Ｈ１−３１３１Ｈ１と共に示している。内部ルーティング３１９２は、Ａｐｐ／Ｇａｍｅサーバー３１２１−３１２５からの特定のサイズにスケーリングされた特定のビデオストリームの要求ごとに、典型的に、ＨＱビデオコンプレッサＨＱ３１２１Ｈ１−３１３１Ｈ１からの圧縮されたＨＱストリームのサブセットを選択する。この選択されたストリームサブセット内のストリームは、要求されたストリームがスケーリングされるべき場合には、デコンプレッサ３１６１−３１６４を通してルーティングされるか、又は要求されたストリームが全解像度である場合には、非スケーリングビデオ経路３１９６を経てルーティングされる。スケーリングされるべきストリームは、デコンプレッサ３１６１−３１６４により未圧縮ビデオへと解凍され、次いで、その各々がスケーラー３１７１−３１７４によって要求されたサイズへとスケーリングされ、次いで、その各々がコンプレッサ３１８１−３１８４により圧縮される。特定のＨＱストリームが２つ以上の解像度で要求される場合には、内部ルーティング３１９２は、そのストリームを（当業者に良く知られたＩＰマルチキャスト技術を使用して）１つ以上のデコンプレッサ３１６１−３１６４へ及び（１つが要求されたサイズで、全解像度である場合には）アウトバウンドルーティング３１９３へマルチキャストすることに注意されたい。要求された全てのストリームは、（コンプレッサ３１８１−３１８４から）スケーリングされるか（内部ルーティング３１９２から）されないかに関わらず、アウトバウンドルーティング３１９３へ送られる。ルーティング３１９３は、次いで、各々の要求されたストリームを、それを要求したＡｐｐ／Ｇａｍｅサーバー３１２１−３１２５へ送る。１つの実施形態において、２つ以上のＡｐｐ／Ｇａｍｅサーバーが同じ解像度の同じストリームを要求する場合には、アウトバウンドルーティング３１９３が、要求をなす全てのＡｐｐ／Ｇａｍｅサーバー３１２１−３１２５へストリームをマルチキャストする。
共有ビデオスケーリング及び再圧縮３１４２の現在好ましい実施形態では、ルーティングがギガビットイーサネットスイッチを使用して具現化され、そして解凍、スケーリング及び圧縮は、各機能を具現化する個別の特殊な半導体装置により具現化される。同じ機能を、ハードウェアにおける高い一体化レベルで、又は非常に高速なプロセッサで具現化することができる。
図３１ｅは、上述した遅延バッファ３１１５の機能が、共有ビデオ遅延バッファ、スケーリング及び解凍サブシステム３１４３において具現化されるホスティングサービス２１０の別の実施形態を示す。このサブシステム３１４３の細部が図３１ｇに示されている。サブシステム３１４３の動作は、図３１ｆに示すサブシステム３１４２と同様であるが、３１９１は、Ａｐｐ／Ｇａｍｅサーバー３１２１−３１２５からの要求ごとに、どのＨＱビデオストリームをルーティングすべきか最初に選択し、次いで、遅延されるべく要求されたＨＱストリームは、ここに示す好ましい実施形態においてＲＡＩＤアレイとして具現化された（しかし、充分な帯域巾及び容量の記憶媒体で具現化することもできる）遅延バッファ３１９４を通してルーティングされ、そして遅延されるべく要求されなかったストリームは、非遅延ビデオ経路３１９５を通してルーティングされる。遅延バッファ３１９４及び非遅延ビデオ３１９５の両出力は、要求されたストリームをスケーリングすべきか否かに基づいて内部ルーティング３１９２によりルーティングされる。スケーリングされたストリームは、デコンプレッサ３１６１−３１６４、スケーラー３１７１−３１７４、及びコンプレッサ３１８１−３１８４を通してアウトバウンドルーティング３１９３へルーティングされ、非スケーリングビデオ３１９６もアウトバウンドルーティング３１９３へ送られ、次いで、アウトバウンドルーティング３１９３は、ユニキャスト又はマルチキャストモードのビデオを、図３１ｆのサブシステム３１４２について上述したのと同様にＡｐｐ／Ｇａｍｅサーバーへ送信する。
ビデオ遅延バッファ、スケーリング及び解凍サブシステム３１４３の別の実施形態が図３１ｈに示されている。この実施形態では、ＨＱストリームごとに個々の遅延バッファＨＱ３１２１Ｄ−ＨＱ３１３１Ｄが設けられる。個々の圧縮されたビデオストリームを遅延するのに使用できるＲＡＭ及びフラッシュＲＯＭのコストが急速に低下しているとすれば、共有遅延バッファ３１９４を有する場合より費用が安く及び／又は柔軟性が高いことになる。或いは、更に別の実施形態では、単一の遅延バッファ３１９７（点線で示す）が、高性能の集合リソース（例えば、非常に高速なＲＡＭ、フラッシュ又はディスク）において全てのＨＱストリームに対して個々に遅延を与えることができる。いずれのシナリオにおいても、各遅延バッファＨＱ３１２１Ｄ−ＨＱ３１３１Ｄは、ＨＱビデオソースからのストリームに可変の遅延を与えることができ、又は遅延なしにストリームを通すことができる。別の実施形態では、各遅延バッファは、複数のストリームに異なる遅延量を与えることができる。Ａｐｐ／Ｇａｍｅサーバー３１２１−３１２５によって全ての遅延又は非遅延が要求される。これらの全てのケースにおいて、遅延及び非遅延ビデオストリーム３１９８が内部ルーティング３１９２へ送られ、そして図３１ｇについて上述したように、サブシステム３１４３の残り部分を通して進む。
種々の図３１ｎに対する前記実施形態では、生のストリームは、両方向接続を使用し、そして特定のユーザに対して最小の待ち時間で仕立てられることに注意されたい。ＨＱストリームは、一方向接続を使用し、ユニキャスト及びマルチキャストの両方である。マルチキャスト機能は、これらの図では、大規模なシステムにおけるギガビットイーサネットスイッチで具現化できるような単一ユニットとして示されているが、マルチキャスト機能は、おそらく、複数のスイッチのツリーを通して具現化される。実際に、トップランクのビデオゲームプレーヤからのビデオストリームの場合に、プレーヤのＨＱストリームは、数百万のユーザから同時に見られることになる。このようなケースでは、おそらく、マルチキャストＨＱストリームを放送する次々の段に多数の個々のスイッチが存在する。
診断の目的、及び（ユーザに彼のゲームプレイの成績がどれほど評判の良いものであるか知らせるために）ユーザにフィードバックを与えるため、の両方について、１つの実施形態では、ホスティングサービス２１０は、Ａｐｐ／Ｇａｍｅサーバー３１２１−３１２５の各ビデオストリームの同時視聴者がどれほどいるか追跡する。これは、特定のビデオストリームに対しＡｐｐ／Ｇａｍｅサーバーにより能動的な要求の数のランニングカウントを保持することにより達成できる。従って、１０００００人の同時視聴者がいるゲームプレーヤは、彼のゲームプレイが非常に評判の良いものであることを知り、そしてゲームプレーヤが良い成績を出して視聴者を引き付けるための刺激を生み出す。（例えば、ビデオゲーム選手権大会の）ビデオストリームが非常に大規模で非常に視聴者数が多いときには、ビデオゲームの試合中に解説者が話をして、そのマルチキャストを見ている何人かの又は全てのユーザがそのコメントを聞くことができるようにするのが望ましい。
Ａｐｐ／Ｇａｍｅサーバーで実行されるアプリケーション及びゲームには、特定の特性（例えば、解像度及び遅延量）をもつ特定のビデオストリームに対する要求をアプリケーション及び／又はゲームが提示できるようにするアプリケーションインターフェイス（ＡＰＩ）が設けられる。又、Ａｐｐ／Ｇａｍｅサーバーで実行されるオペレーティング環境、又は図４ａのホスティングサービスコントロールシステム４０１へ提示されるこれらのＡＰＩは、種々の理由で、このような要求を拒絶してもよい。例えば、要求されるビデオストリームは、幾つかのライセンス交付権制約を有し（例えば、１人の視聴者しか見ることができず、他の者へは放送されないように）、契約上の制約があり（例えば、視聴者は、ストリームを見る権利に対して支払しなければならない）、年齢制約があり（例えば、視聴者は、ストリームを見るには１８歳でなければならず）、プライバシーの制約があり（例えば、アプリケーションを使用するか又はゲームをプレイする個人は、選択された数又はクラスの視聴者（例えば、彼又は彼女の「友人」）のみに視聴を制限するか、或いは全く視聴を許さない）、そして資料の要求が遅延されるという制約がある（例えば、ユーザの位置が暴露されるステルスゲームをユーザがプレイする場合）。ストリームの視聴を制限する多数の他の制約がある。これらケースのいずれかにおいて、Ａｐｐ／Ｇａｍｅサーバーによる要求は、拒絶の理由のために拒絶され、そして一実施形態では、（契約に対してどんな料金を支払わねばならないか示す）要求を受け容れるところの代替物で拒絶される。
いずれかの前記実施形態において遅延バッファに記憶されたＨＱビデオストリームは、ホスティングサービス２１０以外の他の行先へエクスポートされる。例えば、特に関心のあるビデオストリームは、ＹｏｕＴｕｂｅへエクスポートされるべく、Ａｐｐ／Ｇａｍｅサーバーにより（典型的に、ユーザの要求により）要求することができる。このようなケースでは、ビデオストリームは、ＹｏｕＴｕｂｅと合意されたフォーマットでインターネットを通して、適当な記述情報（例えば、プレイするユーザの名前、ゲーム、時間、スコア、等）と一緒に送信される。これは、コメントを要求する全てのＡｐｐ／Ｇａｍｅサーバー３１２１−３１２５へ個別のストリームにおいてコメント音声をマルチキャストすることにより具現化できる。Ａｐｐ／Ｇａｍｅサーバーは、そのコメントの音声を、当業者に良く知られた音声混合技術を使用して、ユーザの家屋２１１へ送られる音声ストリームへ合流させる。複数の解説者（例えば、異なる視点又は異なる言語の）がいてもよく、又、それらの中からユーザが選択することができる。
同様に、個別の音声ストリームを、ホスティングサービス２１０において、リアルタイムのビデオストリームから又は遅延バッファからの音声と混合し又は置き換えることで、混合することもできるし、又は特定のビデオストリーム（又は個々のストリーム）の音声トラックに代わるものとして働くこともできる。このような音声は、コメント又はナレーションであるか、或いはビデオストリームにおけるキャラクタの音声を与えることもできる。これは、ユーザによってマシニマ（ビデオゲームビデオストリームからのユーザ発生アニメーション）を容易に制作できるようにする。
本書の全体にわたって述べたビデオストリームは、Ａｐｐ／Ｇａｍｅサーバーのビデオ出力から捕獲され、次いで、ストリーミング及び／又は遅延され、そして種々の仕方で再使用又は配布されるものとして示された。同じ遅延バッファを使用して、非Ａｐｐ／Ｇａｍｅサーバーソースから到来するビデオ資料を保持し、そして再生及び配布に対する同程度の柔軟性を、適当な制約と共に与えることができる。このようなソースは、テレビ局からの生のフィードを含む（オーバー・ジ・エア、又はＣＮＮのような非オーバー・ジ・エア、及びＨＢＯのような有料、又は無料のいずれか）。又、このようなソースは、事前に記録された映画又はテレビショー、ホームムービー、広告、及び生のビデオ遠隔会議フィードも含む。生のフィードは、Ａｐｐ／Ｇａｍｅサーバーの生の出力のように取り扱われる。事前に記録された資料は、遅延バッファの出力のように取り扱われる。
一実施形態では、ここに示す種々の機能的モジュール及び関連するステップは、そのステップを遂行するための固定布線ロジックを含む特定のハードウェアコンポーネント、例えば、特定用途向け集積回路（ＡＳＩＣ）により遂行されるか、又はプログラムされたコンピュータコンポーネント及びカスタムハードウェアコンポーネントの組合せにより遂行される。
一実施形態では、これらモジュールは、テキサスインスツルーメント社のＴＭＳ３２０ｘアーキテクチャー（例えば、ＴＭＳ３２０Ｃ６０００、ＴＭＳ３２０Ｃ５０００、等）のプログラム可能なデジタル信号プロセッサ（ＤＳＰ）において具現化される。これらの基礎的な原理に適合する種々の異なるＤＳＰを使用することができる。
これら実施形態は、上述した種々のステップを含むことができる。これらステップは、汎用プロセッサ又は特殊目的のプロセッサが幾つかのステップを遂行するようにさせるマシン実行可能なインストラクションにおいて実施することができる。これら基礎的な原理に関連しない種々の要素、例えば、コンピュータメモリ、ハードドライブ、入力装置は、当該観点を不明瞭にしないために図面から除外してある。
ここに開示する要旨の要素は、マシン実行可能なインストラクションを記憶するためのマシン読み取り可能なメディアとして与えられてもよい。マシン読み取り可能なメディアは、フラッシュメモリ、光学的ディスク、ＣＤ−ＲＯＭ、ＤＶＤ ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光学カード、電子的インストラクションを記憶するのに適した伝播メディア又は他の形式のマシン読み取り可能なメディアを含むが、これらに限定されない。例えば、本発明は、通信リンク（例えば、モデム又はネットワーク接続）を経ての搬送波又は他の伝播メディアで実施されるデータ信号によりリモートコンピュータ（例えば、サーバー）から要求側コンピュータ（例えば、クライアント）へ転送されるコンピュータプログラムとしてダウンロードすることができる。
又、ここに開示する要旨の要素は、一連のオペレーションを遂行するようにコンピュータ（例えば、プロセッサ又は他の電子装置）をプログラムするのに使用されるインストラクションが記憶されたマシン読み取り可能なメディアを含むコンピュータプログラム製品として提供されてもよいことを理解されたい。或いは又、オペレーションは、ハードウェア及びソフトウェアの組合せにより遂行されてもよい。マシン読み取り可能なメディアは、フロッピーディスケット、光学的ディスク、ＣＤ−ＲＯＭ、及び磁気・光学ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光学カード、電子的インストラクションを記憶するのに適した伝播メディア又は他の形式のメディア／マシン読み取り可能なメディアを含むが、これらに限定されない。例えば、ここに開示する要旨の要素は、通信リンク（例えば、モデム又はネットワーク接続）を経ての搬送波又は他の伝播メディアで実施されるデータ信号によりプログラムがリモートコンピュータ又は電子装置から要求側コンピュータへ転送されるようなコンピュータプログラム製品としてダウンロードすることができる。
更に、ここに開示する要旨は、特定の実施形態に関連して説明したが、本開示の範囲内で多数の変更や修正がなされ得る。従って、本発明及び添付図面は、単なる例示に過ぎず、それに限定されるものではない。
１００：ＣＰＵ／ＧＰＵ
１０１：ＲＡＭ
１０２：ディスプレイ装置
１０３：ハードドライブ
１０４：光学的メディアドライブ
１０５：ネットワーク接続
１０６：ゲームコントローラ
２０５：クライアント装置
２０６：インターネット
２１０：ホスティングサービス
２１１：ユーザの家屋
２２０：ソフトウェア開発者
２２１：入力装置
２２２：モニタ又はＴＶ受像機
３０１：最大データレート
３０２：実際に利用できる最大データレート
３０３：要求されたデータレート
４０１：ホスティングサービスコントロールシステム
４０２：サーバー
４０３：ＳＡＮ
４０４：低待ち時間のビデオ圧縮
４０５：ＲＡＩＤアレイ
４０６：コントロール信号
４１０：インターネット
４１２：低待ち時間の解凍
４１３：コントロール信号ロジック
４１５：家庭又はオフィスクライアント
４２１：入力装置
４２２：モニタ又はＨＤＴＶ
４４１：中央オフィス、ヘッドエンド、セルタワー、等
４４２：ＷＡＮインターフェイス
４４３：ファイアウオール／ルーター／ＮＡＴ
４４４：ＷＡＮインターフェイス
４５１：コントロール信号
４５２：ユーザの家屋ルーティング
４５３：ユーザＩＳＰ
４５４：インターネット
４５５：サーバーセンタールーティング
４５６：フレーム計算
４５７：ビデオ圧縮
４５８：ビデオ解凍
４６２：パワーオーバーイーサネット
４６３：ＨＤＭＩ出力
４６４：ディスプレイ能力
４６５：イーサネット対ＨＤＭＩクライアント
４６６：シャッター付き眼鏡
４６８：モニタ又はＳＤ／ＨＤＴＶ
４６９：ブルーツース入力装置
４７６：フラッシュ
４８０：バス
４８１：イーサネットインターフェイス
４８３：コントロールＣＰＵ
４８４：ブルーツース
４８６：ビデオデコンプレッサ
４８７：ビデオ出力
４８８：オーディオデコンプレッサ
４８９：オーディオ出力
４９０：ＨＤＭＩ
４９７：イーサネット
４９９：電力
２５００：エンコーダ
２５０１：フィードバックチャンネル
２５０２：デコーダ
２５１０：フレーム
２５１１：デコードされたフレーム
２６００：エンコーダ
２６０１：フィードバックチャンネル
２６０２：デコーダ
２６０５：未圧縮フレーム／タイル
２６０６：圧縮されたフレーム／タイル
２６０７：解凍されたフレーム／タイル
２６１０、２６２０：メモリ
２６１１：過去のエンコーダ状態
２６２１：過去のデコーダ状態
２９００：デコーダロジック
２９０１：ダウンローダー
２９０２：エンコーダ

Claims (30)

  1. オンラインゲームのためのコンピュータ実施システムにおいて、
    オンラインビデオゲームに関連したユーザ入力を受け取り、それに応答して、ビデオゲームのプログラムコードを実行して、ビデオ映像のシーケンスをレンダリングするビデオゲームサーバーと、
    ビデオ映像のシーケンスを圧縮し、クライアント装置のユーザとの生のゲームセッション中に生のビデオストリームを発生する第１のストリームエンコーダであって、クライアント装置からチャンネルフィードバック信号を受信し、それに応答して、そのチャンネルフィードバック信号に基づいてビデオ映像のシーケンスの圧縮を適応させ、更に、ユーザとの生のゲームセッション中にクライアント装置へ生のビデオストリームを送信し続ける第１のストリームエンコーダと、
    ユーザとの生のゲームセッション中に前記チャンネルフィードバック信号とは無関係の特定のビデオ画質及び／又は圧縮比でビデオ映像のシーケンスを圧縮して、生のビデオストリームより比較的高いビデオ画質及び／又は低い圧縮比をもつ高画質（ＨＱ）ビデオストリームを発生する第２のストリームエンコーダと、
    要求があった際にクライアント装置のユーザ及び他のユーザへその後に再生するために前記ＨＱビデオストリームを記憶する記憶装置と、
    を備えたシステム。
  2. 前記チャンネルフィードバック信号は、パケットがクライアント装置によって首尾良く受信及び／又はデコードされたかどうか指示し、前記第１のストリームエンコーダは、１つ以上のパケットが首尾良く受信及び／又はデコードされなかったと決定された際にその圧縮を動的に適応させる、請求項１に記載のシステム。
  3. 前記圧縮を動的に適応させることは、Ｉフレーム又はＩタイルを発生することを含む、請求項２に記載のシステム。
  4. 前記圧縮を動的に適応させることは、クライアント装置において首尾良く受信及び／又はデコードされたことが知られている最後のフレーム／タイルに依存すべき新たな圧縮フレーム／タイルを発生することを含む、請求項２に記載のシステム。
  5. 前記新たなフレーム／タイルは、Ｐフレーム／タイルであり、そしてクライアント装置において首尾良く受信及び／又はデコードされたことが知られている最後のフレーム／タイルは、Ｐフレーム／タイルである、請求項４に記載のシステム。
  6. 前記生のストリームエンコーダは、１つ以上のパケットが首尾良く受信及び／又はデコードされなかったことをチャンネルフィードバック信号が指示するまで、Ｐフレーム／タイルを使用してビデオ映像のシーケンスを圧縮する、請求項３に記載のシステム。
  7. 前記第１のストリームエンコーダは、ビデオ映像の圧縮されたシーケンスがクライアント装置へ送信されるときにチャンネルフィードバック信号において通信される待ち時間を短縮するようビデオ映像のシーケンスの圧縮を適応させる、請求項１に記載のシステム。
  8. 前記特定のビデオ画質は、特定のフレームレートでの特定の解像度を含む、請求項１に記載のシステム。
  9. 前記記憶装置は、１人以上のユーザへ送信する前にＨＱビデオストリームを一時的にバッファするための遅延バッファを含む、請求項１に記載のシステム。
  10. 前記ＨＱビデオストリームを、ユーザによって特定された新たな解像度へスケーリング及び再圧縮するためのスケーリング及び再圧縮ロジックを更に備えた、請求項１に記載のシステム。
  11. 前記ビデオ映像のシーケンスを、ユーザとの生のゲームセッション中に、チャンネルフィードバック信号とは無関係な対応する複数の特定のビデオ画質レベル及び／又は圧縮比で圧縮して、異なるビデオ画質レベル及び／又は圧縮比の複数のビデオストリームを発生するための複数の付加的なストリームエンコーダを更に備えた、請求項１に記載のシステム。
  12. １つ以上のＨＱストリーム及び複数の付加的なストリームを選択するためのルーティングロジックと、
    前記選択されたＨＱストリーム及び／又は複数の付加的なストリームを各々特定の解像度及び／又はサイズでスケーリング及び／又は再圧縮するスケーリング及び／又は再圧縮ロジックと、
    を更に備えた請求項１１に記載のシステム。
  13. １人以上の要求側ユーザのクライアント及び／又は１つ以上の他のゲームサーバーへ、要求があった際に、ＨＱストリームをマルチキャストするためのマルチキャストロジックを更に備えた、請求項１に記載のシステム。
  14. 他のゲームサーバー及び／又は要求側ユーザのクライアントへ、要求があった際に、ＨＱストリームを直接的にルーティングし、及び／又はある遅延の後に記憶装置からＨＱストリームを読み取って、その遅延されたＨＱストリームを、要求があった際に、他のゲームサーバー及び／又は要求側ユーザのクライアントへルーティングするためのルーティングロジックを更に備えた、請求項１に記載のシステム。
  15. 前記ＨＱビデオストリームと音声を混合するための混合ロジックと、
    その混合された音声及びＨＱビデオストリームを、要求があった際に、ユーザのクライアントへルーティングするためのルーティングロジックと、
    を更に備えた請求項１に記載のシステム。
  16. オンラインゲームのためのコンピュータ実施方法において、
    オンラインビデオゲームに関連したユーザ入力を受け取り、それに応答して、ビデオゲームのプログラムコードを実行し、ビデオ映像のシーケンスをレンダリングする段階と、
    ビデオ映像のシーケンスを圧縮し、クライアント装置のユーザとの生のゲームセッション中に生のビデオストリームを発生する段階と、
    クライアント装置からチャンネルフィードバック信号を受信し、それに応答して、そのチャンネルフィードバック信号に基づいてビデオ映像のシーケンスの圧縮を適応させる段階と、
    ユーザとの生のゲームセッション中にクライアント装置へ生のビデオストリームを送信し続ける段階と、
    ユーザとの生のゲームセッション中に前記チャンネルフィードバック信号とは無関係の特定のビデオ画質及び／又は圧縮比でビデオ映像のシーケンスを圧縮して、生のビデオストリームより比較的高いビデオ画質及び／又は低い圧縮比をもつ高画質（ＨＱ）ビデオストリームを発生する段階と、
    要求があった際にクライアント装置のユーザ及び他のユーザへその後に再生するために前記ＨＱビデオストリームを記憶装置に記憶する段階と、
    を備えた方法。
  17. 前記チャンネルフィードバック信号は、パケットがクライアント装置によって首尾良く受信及び／又はデコードされたかどうか指示し、前記方法は、更に、１つ以上のパケットが首尾良く受信及び／又はデコードされなかったと決定された際にその圧縮を動的に適応させる段階を含む、請求項１６に記載の方法。
  18. 圧縮を動的に適応させる前記段階は、Ｉフレーム又はＩタイルを発生することを含む、請求項１７に記載の方法。
  19. 圧縮を動的に適応させる前記段階は、クライアント装置において首尾良く受信及び／又はデコードされたことが知られている最後のフレーム／タイルに依存すべき新たな圧縮フレーム／タイルを発生することを含む、請求項１７に記載の方法。
  20. 前記新たなフレーム／タイルは、Ｐフレーム／タイルであり、そしてクライアント装置において首尾良く受信及び／又はデコードされたことが知られている最後のフレーム／タイルは、Ｐフレーム／タイルである、請求項１９に記載の方法。
  21. ビデオ映像のシーケンスを圧縮して生のビデオストリームを発生する前記段階は、１つ以上のパケットが首尾良く受信及び／又はデコードされなかったことをチャンネルフィードバック信号が指示するまで、Ｐフレーム／タイルを使用してビデオ映像のシーケンスを圧縮することを更に含む、請求項１８に記載の方法。
  22. 圧縮を適応させる前記段階は、更に、ビデオ映像の圧縮されたシーケンスがクライアント装置へ送信されるときにチャンネルフィードバック信号において通信される待ち時間を短縮するようビデオ映像のシーケンスの圧縮を変更させる、請求項１６に記載の方法。
  23. 前記特定のビデオ画質は、特定のフレームレートでの特定の解像度を含む、請求項１６に記載の方法。
  24. 前記記憶装置は、１人以上のユーザへ送信する前にＨＱビデオストリームを一時的にバッファするための遅延バッファを含む、請求項１６に記載の方法。
  25. 前記ＨＱビデオストリームを、ユーザによって特定された新たな解像度へスケーリング及び再圧縮する段階を更に備えた、請求項１６に記載の方法。
  26. 前記ビデオ映像のシーケンスを、ユーザとの生のゲームセッション中に、チャンネルフィードバック信号とは無関係な対応する複数の特定のビデオ画質レベル及び／又は圧縮比で圧縮して、異なるビデオ画質レベル及び／又は圧縮比の複数のビデオストリームを発生する段階を更に備えた、請求項１６に記載の方法。
  27. １つ以上のＨＱストリーム及び複数の付加的なストリームを選択する段階と、
    前記選択されたＨＱストリーム及び／又は複数の付加的なストリームを各々特定の解像度及び／又はサイズでスケーリング及び／又は再圧縮する段階と、
    を更に備えた請求項２６に記載の方法。
  28. １人以上の要求側ユーザのクライアント及び／又は１つ以上の他のゲームサーバーへ、要求があった際に、ＨＱストリームをマルチキャストする段階を更に備えた、請求項１６に記載の方法。
  29. 他のゲームサーバー及び／又は要求側ユーザのクライアントへ、要求があった際に、ＨＱストリームを直接的にルーティングし、及び／又はある遅延の後に記憶装置からＨＱストリームを読み取って、その遅延されたＨＱストリームを、要求があった際に、他のゲームサーバー及び／又は要求側ユーザのクライアントへルーティングする段階を更に備えた、請求項１６に記載の方法。
  30. 前記ＨＱビデオストリームと音声を混合する段階と、
    その混合された音声及びＨＱビデオストリームを、要求があった際に、ユーザのクライアントへルーティングする段階と、
    を更に備えた請求項１６に記載の方法。
JP2012502114A 2009-03-23 2010-03-17 マルチストリームビデオ圧縮のためのシステム及び方法 Pending JP2012521268A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US21088809P 2009-03-23 2009-03-23
US61/210,888 2009-03-23
US12/538,041 US8366552B2 (en) 2002-12-10 2009-08-07 System and method for multi-stream video compression
US12/538,041 2009-08-07
PCT/US2010/027725 WO2010111100A1 (en) 2009-03-23 2010-03-17 System and method for multi-stream video compression

Publications (2)

Publication Number Publication Date
JP2012521268A true JP2012521268A (ja) 2012-09-13
JP2012521268A5 JP2012521268A5 (ja) 2013-05-09

Family

ID=42781402

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012502114A Pending JP2012521268A (ja) 2009-03-23 2010-03-17 マルチストリームビデオ圧縮のためのシステム及び方法

Country Status (14)

Country Link
US (1) US8366552B2 (ja)
EP (1) EP2411944A4 (ja)
JP (1) JP2012521268A (ja)
KR (1) KR101723695B1 (ja)
CN (1) CN102428483A (ja)
AU (1) AU2010229096A1 (ja)
BR (1) BRPI1012243A2 (ja)
CA (1) CA2756331A1 (ja)
IL (1) IL215305A0 (ja)
MX (1) MX2011009976A (ja)
RU (1) RU2528152C2 (ja)
SG (1) SG174909A1 (ja)
TW (1) TWI475843B (ja)
WO (1) WO2010111100A1 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017084255A (ja) * 2015-10-30 2017-05-18 任天堂株式会社 情報処理装置、情報処理システム、情報処理方法、および情報処理プログラム
US10657674B2 (en) 2016-06-17 2020-05-19 Immersive Robotics Pty Ltd. Image compression method and apparatus
JP2020099725A (ja) * 2012-12-26 2020-07-02 ソニー インタラクティブ エンタテインメント アメリカ リミテッド ライアビリテイ カンパニー タグコンテンツおよびソーシャルネットワークコンテンツに基くクラウドで実行されたミニゲームをランク付けするシステムおよび方法
JP2021053182A (ja) * 2019-09-30 2021-04-08 株式会社コロプラ プログラム、方法、および配信端末
US11150857B2 (en) 2017-02-08 2021-10-19 Immersive Robotics Pty Ltd Antenna control for mobile device communication
US11153604B2 (en) 2017-11-21 2021-10-19 Immersive Robotics Pty Ltd Image compression for digital reality
US11553187B2 (en) 2017-11-21 2023-01-10 Immersive Robotics Pty Ltd Frequency component selection for image compression

Families Citing this family (146)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8711923B2 (en) * 2002-12-10 2014-04-29 Ol2, Inc. System and method for selecting a video encoding format based on feedback data
US8526490B2 (en) * 2002-12-10 2013-09-03 Ol2, Inc. System and method for video compression using feedback including data related to the successful receipt of video content
US20090118019A1 (en) 2002-12-10 2009-05-07 Onlive, Inc. System for streaming databases serving real-time applications used through streaming interactive video
US9314691B2 (en) * 2002-12-10 2016-04-19 Sony Computer Entertainment America Llc System and method for compressing video frames or portions thereof based on feedback information from a client device
US20080200261A1 (en) * 2005-07-18 2008-08-21 Mark Charles Spittle Electronic Entertainment Device
WO2007053417A1 (en) * 2005-11-01 2007-05-10 Wms Gaming Inc. Powering devices in wagering game machines
US7849211B2 (en) * 2006-05-12 2010-12-07 Broadcom Corporation Method and system for reliable multicast datagrams and barriers
US8888592B1 (en) 2009-06-01 2014-11-18 Sony Computer Entertainment America Llc Voice overlay
US9349201B1 (en) 2006-08-03 2016-05-24 Sony Interactive Entertainment America Llc Command sentinel
JP4238270B2 (ja) * 2007-02-09 2009-03-18 株式会社コナミデジタルエンタテインメント ゲーム端末、難度設定装置、プログラムおよび記録媒体
US7720986B2 (en) 2007-08-24 2010-05-18 At&T Intellectual Property I, L.P. Method and system for media adaption
US8147339B1 (en) 2007-12-15 2012-04-03 Gaikai Inc. Systems and methods of serving game video
US8613673B2 (en) 2008-12-15 2013-12-24 Sony Computer Entertainment America Llc Intelligent game loading
US9498714B2 (en) 2007-12-15 2016-11-22 Sony Interactive Entertainment America Llc Program mode switching
US8968087B1 (en) 2009-06-01 2015-03-03 Sony Computer Entertainment America Llc Video game overlay
US8070620B2 (en) * 2008-05-12 2011-12-06 Callaway Golf Company Method and apparatus for measuring golf green speeds
US20100146111A1 (en) * 2008-12-04 2010-06-10 Real Dice Inc. Efficient communication in a network
US8926435B2 (en) * 2008-12-15 2015-01-06 Sony Computer Entertainment America Llc Dual-mode program execution
US9190110B2 (en) 2009-05-12 2015-11-17 JBF Interlude 2009 LTD System and method for assembling a recorded composition
US11013995B2 (en) * 2009-06-01 2021-05-25 Sony Interactive Entertainment LLC Qualified video delivery methods
US9633379B1 (en) * 2009-06-01 2017-04-25 Sony Interactive Entertainment America Llc Qualified video delivery advertisement
US9426502B2 (en) 2011-11-11 2016-08-23 Sony Interactive Entertainment America Llc Real-time cloud-based video watermarking systems and methods
US9723319B1 (en) 2009-06-01 2017-08-01 Sony Interactive Entertainment America Llc Differentiation for achieving buffered decoding and bufferless decoding
US9350787B2 (en) * 2009-06-01 2016-05-24 Sony Interactive Entertainment America Llc Methods and systems for generation and execution of miniapp of computer application served by cloud computing system
US20110136577A1 (en) * 2009-12-09 2011-06-09 M5 Systems Llc Game manager with multi-platform api components
GB2479117B (en) * 2010-01-21 2016-06-01 Snb Tech Ltd Video conversation using sequences of queued user videos
US9607655B2 (en) * 2010-02-17 2017-03-28 JBF Interlude 2009 LTD System and method for seamless multimedia assembly
US11232458B2 (en) 2010-02-17 2022-01-25 JBF Interlude 2009 LTD System and method for data mining within interactive multimedia
US8711571B2 (en) * 2010-04-09 2014-04-29 Shenzhen Netcom Electronics Co., Ltd. Portable multimedia player
US20110285863A1 (en) * 2010-05-23 2011-11-24 James Burke Live television broadcasting system for the internet
US8560331B1 (en) 2010-08-02 2013-10-15 Sony Computer Entertainment America Llc Audio acceleration
US8267793B2 (en) * 2010-08-17 2012-09-18 Samsung Electronics Co., Ltd. Multiplatform gaming system
WO2012037170A1 (en) * 2010-09-13 2012-03-22 Gaikai, Inc. Dual mode program execution and loading
KR102230426B1 (ko) 2010-09-13 2021-03-22 소니 인터랙티브 엔터테인먼트 아메리카 엘엘씨 부가기능의 관리
US8520728B2 (en) * 2010-09-23 2013-08-27 Intel Corporation Adaptive data transmission rate control for a wireless display device
US8493981B2 (en) * 2010-11-03 2013-07-23 Broadcom Corporation Switch module
EP2453377A1 (en) * 2010-11-15 2012-05-16 Gemalto SA Method of loading data into a portable secure token
US8902970B1 (en) * 2010-12-01 2014-12-02 Amazon Technologies, Inc. Altering streaming video encoding based on user attention
KR101312268B1 (ko) 2010-12-24 2013-09-25 주식회사 케이티 클라우드 컴퓨팅 환경에서 게임 서비스 제공 방법, 클라우드 컴퓨팅 서버, 및 클라우드 컴퓨팅 시스템
JP5774314B2 (ja) * 2011-01-05 2015-09-09 任天堂株式会社 遅延測定システムおよび遅延測定方法
US8589423B2 (en) 2011-01-18 2013-11-19 Red 5 Studios, Inc. Systems and methods for generating enhanced screenshots
US8657680B2 (en) * 2011-05-31 2014-02-25 United Video Properties, Inc. Systems and methods for transmitting media associated with a measure of quality based on level of game play in an interactive video gaming environment
US8793313B2 (en) 2011-09-08 2014-07-29 Red 5 Studios, Inc. Systems, methods and media for distributing peer-to-peer communications
US20130085864A1 (en) * 2011-10-03 2013-04-04 Hassan Ahmed Mobile content delivery
US9769281B2 (en) * 2011-12-19 2017-09-19 Google Technology Holdings LLC Method and apparatus for determining a multimedia representation for a multimedia asset delivered to a client device
US10482100B1 (en) * 2012-01-25 2019-11-19 Zynga Inc. Method to detect and score users who are likely to make payments in online social games
US9252916B2 (en) 2012-02-13 2016-02-02 Affirmed Networks, Inc. Mobile video delivery
WO2013122387A1 (en) 2012-02-15 2013-08-22 Samsung Electronics Co., Ltd. Data transmitting apparatus, data receiving apparatus, data transceiving system, data transmitting method, and data receiving method
WO2013122385A1 (en) 2012-02-15 2013-08-22 Samsung Electronics Co., Ltd. Data transmitting apparatus, data receiving apparatus, data transreceiving system, data transmitting method, data receiving method and data transreceiving method
WO2013122386A1 (en) 2012-02-15 2013-08-22 Samsung Electronics Co., Ltd. Data transmitting apparatus, data receiving apparatus, data transreceiving system, data transmitting method, data receiving method and data transreceiving method
US9179169B2 (en) 2012-03-14 2015-11-03 Imagine Communications Corp. Adaptive media delivery
US8600220B2 (en) 2012-04-02 2013-12-03 JBF Interlude 2009 Ltd—Israel Systems and methods for loading more than one video content at a time
KR101609812B1 (ko) 2012-04-09 2016-04-20 엠파이어 테크놀로지 디벨롭먼트 엘엘씨 프로세싱 로드 분배
US20130342689A1 (en) * 2012-06-25 2013-12-26 Intel Corporation Video analytics test system
US8632411B1 (en) 2012-06-28 2014-01-21 Red 5 Studios, Inc. Exchanging virtual rewards for computing resources
US8628424B1 (en) 2012-06-28 2014-01-14 Red 5 Studios, Inc. Interactive spectator features for gaming environments
US8834268B2 (en) * 2012-07-13 2014-09-16 Red 5 Studios, Inc. Peripheral device control and usage in a broadcaster mode for gaming environments
US8795086B2 (en) 2012-07-20 2014-08-05 Red 5 Studios, Inc. Referee mode within gaming environments
US8475284B1 (en) 2012-07-31 2013-07-02 Scott Rudi Dynamic views within gaming environments
US8860882B2 (en) 2012-09-19 2014-10-14 JBF Interlude 2009 Ltd—Israel Systems and methods for constructing multimedia content modules
US9009619B2 (en) 2012-09-19 2015-04-14 JBF Interlude 2009 Ltd—Israel Progress bar for branched videos
WO2014055108A1 (en) * 2012-10-03 2014-04-10 Google Inc. Cloud-based gameplay video rendering and encoding
JP6133567B2 (ja) 2012-10-18 2017-05-24 任天堂株式会社 ゲームシステム、ゲーム装置、ゲームプログラム、およびゲーム処理制御方法
JP6306512B2 (ja) * 2012-11-05 2018-04-04 株式会社ソニー・インタラクティブエンタテインメント 情報処理装置
US9930082B2 (en) 2012-11-20 2018-03-27 Nvidia Corporation Method and system for network driven automatic adaptive rendering impedance
US8870661B2 (en) * 2012-12-21 2014-10-28 Sony Computer Entertainment America Llc Cloud-based game slice generation and frictionless social sharing with instant play
US10616086B2 (en) 2012-12-27 2020-04-07 Navidia Corporation Network adaptive latency reduction through frame rate control
US10137376B2 (en) * 2012-12-31 2018-11-27 Activision Publishing, Inc. System and method for creating and streaming augmented game sessions
US9257148B2 (en) 2013-03-15 2016-02-09 JBF Interlude 2009 LTD System and method for synchronization of selectably presentable media streams
US20140355665A1 (en) * 2013-05-31 2014-12-04 Altera Corporation Adaptive Video Reference Frame Compression with Control Elements
WO2014199412A1 (ja) 2013-06-12 2014-12-18 株式会社ソニー・コンピュータエンタテインメント 出力データ提供サーバおよび出力データ提供方法
US9832516B2 (en) 2013-06-19 2017-11-28 JBF Interlude 2009 LTD Systems and methods for multiple device interaction with selectably presentable media streams
US8732633B1 (en) * 2013-07-02 2014-05-20 Tamba Networks, Inc. Tunable design of an ethernet region of an integrated circuit
US8832613B1 (en) 2013-07-02 2014-09-09 Tamba Networks, Inc. Tunable design of an interlaken region of an integrated circuit
US9819604B2 (en) 2013-07-31 2017-11-14 Nvidia Corporation Real time network adaptive low latency transport stream muxing of audio/video streams for miracast
US10448119B2 (en) 2013-08-30 2019-10-15 JBF Interlude 2009 LTD Methods and systems for unfolding video pre-roll
US9530454B2 (en) 2013-10-10 2016-12-27 JBF Interlude 2009 LTD Systems and methods for real-time pixel switching
US9641898B2 (en) 2013-12-24 2017-05-02 JBF Interlude 2009 LTD Methods and systems for in-video library
US9520155B2 (en) 2013-12-24 2016-12-13 JBF Interlude 2009 LTD Methods and systems for seeking to non-key frames
WO2015104847A1 (en) 2014-01-09 2015-07-16 Square Enix Holdings Co., Ltd. Online game server architecture using shared rendering
US9333433B2 (en) * 2014-02-04 2016-05-10 Sony Computer Entertainment America Llc Online video game service with split clients
US9653115B2 (en) 2014-04-10 2017-05-16 JBF Interlude 2009 LTD Systems and methods for creating linear video from branched video
US9792026B2 (en) 2014-04-10 2017-10-17 JBF Interlude 2009 LTD Dynamic timeline for branched video
US10154072B2 (en) * 2014-09-17 2018-12-11 Microsoft Technology Licensing, Llc Intelligent streaming of media content
US9792957B2 (en) 2014-10-08 2017-10-17 JBF Interlude 2009 LTD Systems and methods for dynamic video bookmarking
US11412276B2 (en) 2014-10-10 2022-08-09 JBF Interlude 2009 LTD Systems and methods for parallel track transitions
US11351466B2 (en) 2014-12-05 2022-06-07 Activision Publishing, Ing. System and method for customizing a replay of one or more game events in a video game
US20160259453A1 (en) 2015-03-06 2016-09-08 Sony Computer Entertainment America Llc Dynamic adjustment of cloud game data streams to output device and network quality
RU2595945C1 (ru) * 2015-04-10 2016-08-27 Владимир Леонидович Карякин Способ оценки качества канала передачи данных в системе iptv по коэффициенту ber в режиме тв вещания и устройство для его осуществления
US9672868B2 (en) 2015-04-30 2017-06-06 JBF Interlude 2009 LTD Systems and methods for seamless media creation
US10582265B2 (en) 2015-04-30 2020-03-03 JBF Interlude 2009 LTD Systems and methods for nonlinear video playback using linear real-time video players
US10554713B2 (en) * 2015-06-19 2020-02-04 Microsoft Technology Licensing, Llc Low latency application streaming using temporal frame transformation
US10460765B2 (en) 2015-08-26 2019-10-29 JBF Interlude 2009 LTD Systems and methods for adaptive and responsive video
US9873056B2 (en) 2015-09-15 2018-01-23 Square Enix Holdings Co., Ltd. Game system including third party input
US10376781B2 (en) 2015-10-21 2019-08-13 Activision Publishing, Inc. System and method of generating and distributing video game streams
US10232272B2 (en) 2015-10-21 2019-03-19 Activision Publishing, Inc. System and method for replaying video game streams
US11128853B2 (en) 2015-12-22 2021-09-21 JBF Interlude 2009 LTD Seamless transitions in large-scale video
US11164548B2 (en) 2015-12-22 2021-11-02 JBF Interlude 2009 LTD Intelligent buffering of large-scale video
US10462202B2 (en) 2016-03-30 2019-10-29 JBF Interlude 2009 LTD Media stream rate synchronization
US10300390B2 (en) 2016-04-01 2019-05-28 Activision Publishing, Inc. System and method of automatically annotating gameplay of a video game based on triggering events
US11856271B2 (en) 2016-04-12 2023-12-26 JBF Interlude 2009 LTD Symbiotic interactive video
US10218760B2 (en) 2016-06-22 2019-02-26 JBF Interlude 2009 LTD Dynamic summary generation for real-time switchable videos
US9936238B2 (en) * 2016-07-29 2018-04-03 Infiniscene, Inc. Systems and methods for production and delivery of live video
US10123040B2 (en) 2016-08-30 2018-11-06 Qualcomm Incorporated Intra-coded video frame caching for video telephony sessions
CN106375292A (zh) * 2016-08-30 2017-02-01 郑州威科姆科技股份有限公司 视频、图文点播系统及其方法
US10158905B2 (en) 2016-09-14 2018-12-18 Dts, Inc. Systems and methods for wirelessly transmitting audio synchronously with rendering of video
CN107846633B (zh) * 2016-09-18 2023-07-14 腾讯科技（深圳）有限公司 一种直播方法及系统
US11050809B2 (en) 2016-12-30 2021-06-29 JBF Interlude 2009 LTD Systems and methods for dynamic weighting of branched video paths
US10405003B2 (en) * 2017-01-20 2019-09-03 Google Llc Image compression based on semantic relevance
JP6277503B1 (ja) * 2017-03-15 2018-02-14 株式会社コナミデジタルエンタテインメント サーバ装置、及びそれに用いられるコンピュータプログラム
GB201715124D0 (en) * 2017-09-19 2017-11-01 Real Time Objects Ltd Graphics streaming
US10741143B2 (en) * 2017-11-28 2020-08-11 Nvidia Corporation Dynamic jitter and latency-tolerant rendering
CN108111920A (zh) * 2017-12-11 2018-06-01 北京小米移动软件有限公司 视频信息处理方法及装置
US10257578B1 (en) 2018-01-05 2019-04-09 JBF Interlude 2009 LTD Dynamic library display for interactive videos
EP3747174B1 (en) 2018-02-02 2023-06-07 Microsoft Technology Licensing, LLC Estimating bandwidth savings for adaptive bit rate streaming
US20190373040A1 (en) * 2018-05-30 2019-12-05 Infiniscene, Inc. Systems and methods game streaming
US11601721B2 (en) 2018-06-04 2023-03-07 JBF Interlude 2009 LTD Interactive video dynamic adaptation and user profiling
US20200045352A1 (en) * 2018-08-02 2020-02-06 Imagine Communications Corp. System and process for generalized real-time transport protocol stream segmentation and reconstruction
US11810202B1 (en) 2018-10-17 2023-11-07 State Farm Mutual Automobile Insurance Company Method and system for identifying conditions of features represented in a virtual model
CN109391845A (zh) * 2018-11-23 2019-02-26 深圳市炬力北方微电子有限公司 跨设备显示的动态调整方法
US10873724B1 (en) 2019-01-08 2020-12-22 State Farm Mutual Automobile Insurance Company Virtual environment generation for collaborative building assessment
US10974153B2 (en) * 2019-01-17 2021-04-13 Disney Enterprises, Inc. Streamable compressed geometry for live broadcast
CN110880009B (zh) * 2019-01-20 2020-07-17 浩德科技股份有限公司 现场大数据动态调整方法
US10963365B2 (en) * 2019-03-20 2021-03-30 Electronic Arts Inc. System for testing command execution latency within an application
US11020658B2 (en) 2019-03-20 2021-06-01 Electronic Arts Inc. System for testing command execution latency within a video game
US11049072B1 (en) 2019-04-26 2021-06-29 State Farm Mutual Automobile Insurance Company Asynchronous virtual collaboration environments
US11032328B1 (en) 2019-04-29 2021-06-08 State Farm Mutual Automobile Insurance Company Asymmetric collaborative virtual environments
CN110297996B (zh) * 2019-05-21 2023-09-01 深圳壹账通智能科技有限公司 基于h5页面的动画显示方法、装置、设备及存储介质
JP7050032B2 (ja) 2019-06-10 2022-04-07 株式会社ソニー・インタラクティブエンタテインメント 情報処理システム
US11490047B2 (en) 2019-10-02 2022-11-01 JBF Interlude 2009 LTD Systems and methods for dynamically adjusting video aspect ratios
CN111221508A (zh) * 2019-11-14 2020-06-02 腾讯科技（深圳）有限公司 业务路径设计方法、设计装置、电子设备及存储介质
CN111107386A (zh) * 2019-12-27 2020-05-05 北京达佳互联信息技术有限公司 直播视频的回看方法、装置、电子设备、系统及存储介质
US11245961B2 (en) 2020-02-18 2022-02-08 JBF Interlude 2009 LTD System and methods for detecting anomalous activities for interactive videos
US11792408B2 (en) 2020-03-30 2023-10-17 Alibaba Group Holding Limited Transcoder target bitrate prediction techniques
US11470327B2 (en) 2020-03-30 2022-10-11 Alibaba Group Holding Limited Scene aware video content encoding
US11386873B2 (en) 2020-04-01 2022-07-12 Alibaba Group Holding Limited Method and apparatus for efficient application screen compression
CN111447482A (zh) * 2020-05-13 2020-07-24 威盛电子股份有限公司 串流媒体同步播放方法及串流媒体同步播放系统
CN112911340A (zh) * 2020-08-19 2021-06-04 赵蒙 基于云计算的媒体数据处理方法、系统及大数据平台
CN112449203A (zh) * 2020-11-24 2021-03-05 广州虎牙科技有限公司 一种游戏直播方法、装置、电子设备和存储介质
JP7018617B1 (ja) * 2020-12-11 2022-02-14 正啓 榊原 プレイ記録動画作成システム
CN112839241A (zh) * 2020-12-31 2021-05-25 贵阳动视云科技有限公司 一种云游戏图像丢帧补偿方法及装置
JP2024514060A (ja) * 2021-04-08 2024-03-28 インターディジタル・シーイー・パテント・ホールディングス・ソシエテ・パ・アクシオンス・シンプリフィエ ストリーミングアプリケーションにおけるビデオデータの微調整
US11882337B2 (en) 2021-05-28 2024-01-23 JBF Interlude 2009 LTD Automated platform for generating interactive videos
US11934477B2 (en) 2021-09-24 2024-03-19 JBF Interlude 2009 LTD Video player integration within websites
CN114125071B (zh) * 2021-11-23 2024-02-09 北京人大金仓信息技术股份有限公司 数据压缩传输方法及装置
CN116866674B (zh) * 2023-08-10 2024-02-27 广州阿凡提电子科技有限公司 应用人工智能的直播图像互动信息处理方法、系统及介质

Family Cites Families (324)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IT1157128B (it) * 1982-12-09 1987-02-11 Cselt Centro Studi Lab Telecom Codificatore e decodificatore di messaggi a lunghezza variabile per sistemi di trasmissione dati
US4539706A (en) 1983-02-03 1985-09-03 General Electric Company Mobile vehicular repeater system which provides up-link acknowledgement signal to portable transceiver at end of transceiver transmission
US4616263A (en) 1985-02-11 1986-10-07 Gte Corporation Video subsystem for a hybrid videotex facility
US6614768B1 (en) 1989-04-28 2003-09-02 Broadcom Corporation Enhanced mobility and address resolution in a wireless premises based network
GB8910997D0 (en) 1989-05-12 1989-06-28 Tunstall Telecom Ltd Radio transmission system
US5058199A (en) 1990-05-02 1991-10-15 Motorola, Inc. Inter-truncked radio systems bridge protocol
US5222246A (en) 1990-11-02 1993-06-22 General Electric Company Parallel amplifiers with combining phase controlled from combiner difference port
US5493644A (en) * 1991-07-11 1996-02-20 Hewlett-Packard Company Polygon span interpolator with main memory Z buffer
JPH0530000A (ja) * 1991-07-18 1993-02-05 Fujitsu Ltd 移動体通信方式
KR100254956B1 (ko) 1991-12-23 2002-12-18 코닌클리케 필립스 일렉트로닉스 엔.브이. 재귀비데오신호프로세서
US5357604A (en) 1992-01-30 1994-10-18 A/N, Inc. Graphics processor with enhanced memory control circuitry for use in a video game system or the like
US5926208A (en) 1992-02-19 1999-07-20 Noonen; Michael Video compression and decompression arrangement having reconfigurable camera and low-bandwidth transmission capability
EP0571138A3 (en) * 1992-05-20 1995-03-29 Codemasters Ltd Memory cartridge and interface for video game console.
WO1994001964A1 (en) 1992-07-08 1994-01-20 Bell Atlantic Network Services, Inc. Media server for supplying video and multi-media data over the public telephone switched network
FR2703199B1 (fr) * 1993-03-26 1995-06-02 Matra Communication Procédé de transmission radio-électrique utilisant des stations répétrices à retournement de spectre.
AU2123995A (en) 1994-03-18 1995-10-09 Micropolis Corporation On-demand video server system
CA2144253C (en) * 1994-04-01 1999-09-21 Bruce F. Naylor System and method of generating compressed video graphics images
JP3658011B2 (ja) * 1994-04-19 2005-06-08 キヤノン株式会社 画像符号化装置及びその方法、並びに画像復号化装置及びその方法
US5586257A (en) 1994-05-05 1996-12-17 Perlman; Stephen G. Network architecture to support multiple site real-time video games
US5558339A (en) 1994-05-05 1996-09-24 Perlman; Stephen G. Network architecture to support recording and playback of real-time video games
JPH07319747A (ja) 1994-05-24 1995-12-08 Nec Telecom Syst Ltd データ更新システム
US5606359A (en) 1994-06-30 1997-02-25 Hewlett-Packard Company Video on demand system with multiple data sources configured to provide vcr-like services
US6092117A (en) 1994-09-02 2000-07-18 Packard Bell Nec System and method for automatically reconnecting a wireless interface device to a host computer
US5654747A (en) 1994-12-29 1997-08-05 International Business Machines Corporation Intelligent multimedia set-top control method and apparatus in which billing signals are communicated to an information network upon presentation of downloaded media programs
NO960306L (no) * 1995-01-27 1996-07-29 Nec Corp Anordning ved mobil satelittkommunikasjon
US5618045A (en) * 1995-02-08 1997-04-08 Kagan; Michael Interactive multiple player game system and method of playing a game between at least two players
US6122482A (en) 1995-02-22 2000-09-19 Global Communications, Inc. Satellite broadcast receiving and distribution system
US5646676A (en) 1995-05-30 1997-07-08 International Business Machines Corporation Scalable interactive multimedia server system for providing on demand data
US5640386A (en) 1995-06-06 1997-06-17 Globalstar L.P. Two-system protocol conversion transceiver repeater
US5608412A (en) * 1995-06-07 1997-03-04 General Electric Company Protocol and mechanism for mutter mode communication for stationary master tracking unit
US5890055A (en) * 1995-07-28 1999-03-30 Lucent Technologies Inc. Method and system for connecting cells and microcells in a wireless communications network
US6132306A (en) 1995-09-06 2000-10-17 Cisco Systems, Inc. Cellular communication system with dedicated repeater channels
US5710719A (en) * 1995-10-19 1998-01-20 America Online, Inc. Apparatus and method for 2-dimensional data compression
US5732076A (en) * 1995-10-26 1998-03-24 Omnipoint Corporation Coexisting communication systems
US5742680A (en) * 1995-11-13 1998-04-21 E Star, Inc. Set top box for receiving and decryption and descrambling a plurality of satellite television signals
US5956088A (en) 1995-11-21 1999-09-21 Imedia Corporation Method and apparatus for modifying encoded digital video for improved channel utilization
US5915020A (en) 1995-11-21 1999-06-22 Hughes Electronics Corporation Portable satellite earth station
US6331856B1 (en) 1995-11-22 2001-12-18 Nintendo Co., Ltd. Video game system with coprocessor providing high speed efficient 3D graphics and digital audio signal processing
US5999808A (en) 1995-12-12 1999-12-07 Aeris Communications, Inc. Wireless gaming method
US5682204A (en) 1995-12-26 1997-10-28 C Cube Microsystems, Inc. Video encoder which uses intra-coding when an activity level of a current macro-block is smaller than a threshold level
US5872575A (en) * 1996-02-14 1999-02-16 Digital Media Interactive Method and system for the creation of and navigation through a multidimensional space using encoded digital video
US6160993A (en) 1996-02-23 2000-12-12 Scientific-Atlanta, Inc. Method and apparatus for command and control of remote systems using low earth orbit satellite communications
US6166703A (en) 1996-02-27 2000-12-26 Thomson Licensing S.A. Combination satellite and VHF/UHF receiving antenna
US5959592A (en) 1996-03-18 1999-09-28 Echostar Engineering Corporation "IF" bandstacked low noise block converter combined with diplexer
US6110041A (en) 1996-12-30 2000-08-29 Walker Digital, Llc Method and system for adapting gaming devices to playing preferences
US6175854B1 (en) * 1996-06-11 2001-01-16 Ameritech Services, Inc. Computer system architecture and method for multi-user, real-time applications
US6292589B1 (en) 1996-06-21 2001-09-18 Compaq Computer Corporation Method for choosing rate control parameters in motion-compensated transform-based picture coding scheme using non-parametric technique
US5828370A (en) 1996-07-01 1998-10-27 Thompson Consumer Electronics Inc. Video delivery system and method for displaying indexing slider bar on the subscriber video screen
US6757913B2 (en) 1996-07-15 2004-06-29 Gregory D. Knox Wireless music and data transceiver system
US5751378A (en) 1996-09-27 1998-05-12 General Instrument Corporation Scene change detector for digital video
JP4034380B2 (ja) 1996-10-31 2008-01-16 株式会社東芝 画像符号化／復号化方法及び装置
KR19980036429A (ko) 1996-11-18 1998-08-05 김광호 광 디스크 플레이어의 트레이
GB9720152D0 (en) 1996-12-18 1997-11-26 Mayup Limited Communications system and method
IL119928A (en) 1996-12-29 2001-01-11 Univ Ramot Model-based view extrapolation for interactive virtual reality systems
JPH10257009A (ja) 1997-03-10 1998-09-25 Oki Electric Ind Co Ltd 無線中継方法及び無線中継機
US6639945B2 (en) 1997-03-14 2003-10-28 Microsoft Corporation Method and apparatus for implementing motion detection in video compression
AU1941797A (en) 1997-03-17 1998-10-12 Mitsubishi Denki Kabushiki Kaisha Image encoder, image decoder, image encoding method, image decoding method and image encoding/decoding system
US5974503A (en) 1997-04-25 1999-10-26 Emc Corporation Storage and access of continuous media files indexed as lists of raid stripe sets associated with file names
US6708029B2 (en) 1997-06-02 2004-03-16 Hughes Electronics Corporation Broadband communication system for mobile users in a satellite-based network
US6057850A (en) 1997-07-15 2000-05-02 Silicon Graphics, Inc. Blended texture illumination mapping
US5987376A (en) 1997-07-16 1999-11-16 Microsoft Corporation System and method for the distribution and synchronization of data and state information between clients in a distributed processing system
US6484012B1 (en) * 1997-08-04 2002-11-19 Wireless Facilities, Inc. Inter-band communication repeater system
JP4014263B2 (ja) 1997-10-01 2007-11-28 松下電器産業株式会社 映像信号変換装置及び映像信号変換方法
US6188571B1 (en) * 1997-11-03 2001-02-13 Aiwa Raid Technology, Inc. High density RAID subsystem with highly integrated controller
US6404775B1 (en) 1997-11-21 2002-06-11 Allen Telecom Inc. Band-changing repeater with protocol or format conversion
US6292847B1 (en) 1997-12-03 2001-09-18 Kabushiki Kaisha Kobe Seiko Sho. Digital information reproducing apparatus and digital information distributing system
US6424817B1 (en) 1998-02-04 2002-07-23 California Amplifier, Inc. Dual-polarity low-noise block downconverter systems and methods
US6769990B2 (en) 1998-02-06 2004-08-03 Robert Cohen Networked search and tracking games
CA2248745C (en) 1998-02-13 2005-08-23 Arista Interactive Llc Wireless game control units
US6414725B1 (en) * 1998-04-16 2002-07-02 Leitch Technology Corporation Method and apparatus for synchronized multiple format data storage
US6788882B1 (en) 1998-04-17 2004-09-07 Timesurf, L.L.C. Systems and methods for storing a plurality of video streams on re-writable random-access media and time-and channel- based retrieval thereof
US6374078B1 (en) * 1998-04-17 2002-04-16 Direct Wireless Corporation Wireless communication system with multiple external communication links
US5884101A (en) * 1998-04-17 1999-03-16 I-Cube, Inc. Apparatus for detecting data buffer faults
US7028304B1 (en) * 1998-05-26 2006-04-11 Rockwell Collins Virtual line replaceable unit for a passenger entertainment system, method and article of manufacture
US6208636B1 (en) * 1998-05-28 2001-03-27 Northpoint Technology, Ltd. Apparatus and method for processing signals selected from multiple data streams
US6412112B1 (en) 1998-06-30 2002-06-25 Webtv Networks, Inc. System for transmitting digital data through a lossy channel
US20020015513A1 (en) * 1998-07-15 2002-02-07 Sony Corporation Motion vector detecting method, record medium on which motion vector calculating program has been recorded, motion detecting apparatus, motion detecting method, picture encoding apparatus, picture encoding method, motion vector calculating method, record medium on which motion vector calculating program has been recorded
EA199800706A1 (ru) 1998-08-13 1999-02-25 Александр Иванович Силаев Способ игры со ставками (варианты) и устройство для его осуществления
US6600730B1 (en) 1998-08-20 2003-07-29 Hughes Electronics Corporation System for distribution of satellite signals from separate multiple satellites on a single cable line
US6697869B1 (en) * 1998-08-24 2004-02-24 Koninklijke Philips Electronics N.V. Emulation of streaming over the internet in a broadcast application
US6323909B1 (en) 1998-10-28 2001-11-27 Hughes Electronics Corporation Method and apparatus for transmitting high definition television programming using a digital satellite system transport and MPEG-2 packetized elementary streams (PES)
US6409602B1 (en) 1998-11-06 2002-06-25 New Millenium Gaming Limited Slim terminal gaming system
US6241612B1 (en) 1998-11-09 2001-06-05 Cirrus Logic, Inc. Voice communication during a multi-player game
US6594313B1 (en) 1998-12-23 2003-07-15 Intel Corporation Increased video playback framerate in low bit-rate video applications
US6665872B1 (en) 1999-01-06 2003-12-16 Sarnoff Corporation Latency-based statistical multiplexing
US6754241B1 (en) 1999-01-06 2004-06-22 Sarnoff Corporation Computer system for statistical multiplexing of bitstreams
US6577849B1 (en) * 1999-02-03 2003-06-10 Motorola, Inc. Method and apparatus for providing additional information about a broadcast
JP3808660B2 (ja) * 1999-03-31 2006-08-16 株式会社東芝 通信システム及び端末装置
US6597891B2 (en) 1999-04-05 2003-07-22 International Business Machines Corporation Combining online browsing and on-demand data broadcast for selecting and downloading digital content
IL129345A (en) * 1999-04-06 2004-05-12 Broadcom Corp Video encoding and video/audio/data multiplexing device
US6473858B1 (en) 1999-04-16 2002-10-29 Digeo, Inc. Method and apparatus for broadcasting data with access control
US7178106B2 (en) 1999-04-21 2007-02-13 Sonic Solutions, A California Corporation Presentation of media content from multiple media sources
US6760487B1 (en) 1999-04-22 2004-07-06 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Estimated spectrum adaptive postfilter and the iterative prepost filtering algirighms
US6792615B1 (en) 1999-05-19 2004-09-14 New Horizons Telecasting, Inc. Encapsulated, streaming media automation and distribution system
US8266657B2 (en) 2001-03-15 2012-09-11 Sling Media Inc. Method for effectively implementing a multi-room television system
US6263503B1 (en) 1999-05-26 2001-07-17 Neal Margulis Method for effectively implementing a wireless television system
US7289478B1 (en) 1999-07-30 2007-10-30 At&T Corp. Method and apparatus for a fixed wireless broadband access and wireless LAN integration
JP2001111575A (ja) 1999-08-03 2001-04-20 Matsushita Electric Ind Co Ltd 無線ｌａｎクロスチャネル変換リピータ装置及び無線端末装置
US6690657B1 (en) * 2000-02-25 2004-02-10 Berkeley Concept Research Corporation Multichannel distributed wireless repeater network
CN1783997A (zh) 1999-08-27 2006-06-07 诺基亚有限公司 用于数字视频广播的移动多媒体终端
US6430233B1 (en) 1999-08-30 2002-08-06 Hughes Electronics Corporation Single-LNB satellite data receiver
US6205185B1 (en) * 1999-09-01 2001-03-20 Sony Corporation Of Japan Self configuring multi-dwelling satellite receiver system
US6678502B1 (en) * 1999-09-22 2004-01-13 Sony Corporation Wireless transmitting method, wire transmitting method, wireless transmitter and wired transmitter
US6785262B1 (en) 1999-09-28 2004-08-31 Qualcomm, Incorporated Method and apparatus for voice latency reduction in a voice-over-data wireless communication system
JP3653215B2 (ja) 1999-10-01 2005-05-25 シャープ株式会社 衛星放送受信システム、ならびに衛星放送受信システムで用いられるローノイズブロックダウンコンバータおよび衛星放送受信機
US6347216B1 (en) * 1999-11-04 2002-02-12 Xm Satellite Radio Inc. Method and system for providing geographic specific services in a satellite communications network
US6564003B2 (en) 1999-11-04 2003-05-13 Xm Satellite Radio Inc. Method and apparatus for composite data stream storage and playback
US6664969B1 (en) 1999-11-12 2003-12-16 Hewlett-Packard Development Company, L.P. Operating system independent method and apparatus for graphical remote access
US6810528B1 (en) 1999-12-03 2004-10-26 Sony Computer Entertainment America Inc. System and method for providing an on-line gaming experience through a CATV broadband network
WO2001041437A2 (en) 1999-12-03 2001-06-07 Ourworld Live, Inc. Consumer access systems and methods for providing same
JP2001169281A (ja) 1999-12-13 2001-06-22 Matsushita Electric Ind Co Ltd 動画像符号化装置、および動画像符号化方法
US20020059637A1 (en) 2000-01-14 2002-05-16 Rakib Selim Shlomo Home gateway for video and data distribution from various types of headend facilities and including digital video recording functions
WO2001052093A2 (en) 2000-01-14 2001-07-19 Portable Websites.Com, Inc. Method and apparatus for creating relocatable internet web sites
AU2001234463A1 (en) 2000-01-14 2001-07-24 Andrew Corporation Repeaters for wireless communication systems
US20020019984A1 (en) * 2000-01-14 2002-02-14 Rakib Selim Shlomo Headend cherrypicker with digital video recording capability
US20010047422A1 (en) 2000-01-21 2001-11-29 Mcternan Brennan J. System and method for using benchmarking to account for variations in client capabilities in the distribution of a media presentation
WO2001056231A1 (en) * 2000-01-26 2001-08-02 Vyyo, Ltd. Quality of service scheduling scheme for a broadband wireless access system
US7477688B1 (en) * 2000-01-26 2009-01-13 Cisco Technology, Inc. Methods for efficient bandwidth scaling of compressed video data
WO2001056244A1 (fr) * 2000-01-26 2001-08-02 Sony Corporation Systeme de transmission de donnees
KR100677083B1 (ko) * 2000-01-27 2007-02-01 삼성전자주식회사 디지털 영상 데이터 통신 시스템에서의 오류 전파 억제를위한 송수신 데이터의 처리 방법 및 이를 위한 기록 매체
US6741841B1 (en) 2000-01-28 2004-05-25 Rockwell Collins Dual receiver for a on-board entertainment system
EP1130920A3 (en) * 2000-02-03 2002-10-30 Lucent Technologies Inc. Method, apparatus and system for motion picture signal distribution
US6920110B2 (en) * 2001-02-14 2005-07-19 Microsoft Corporation System and method for transferring data over a network
US6724826B1 (en) * 2000-02-25 2004-04-20 Ampex Corporation Method and apparatus for improving the image quality of transmitted video signals via pre-filtering
JP2001244864A (ja) * 2000-02-29 2001-09-07 Hitachi Ltd 無線中継システム
EP1361690B1 (en) * 2000-03-02 2006-01-11 Matsushita Electric Industrial Co., Ltd. Method and apparatus for retransmitting data packets based on channel conditions
US6836658B1 (en) 2000-03-03 2004-12-28 Ems Technologies, Inc. High data rate satellite communications system and method
US6811113B1 (en) 2000-03-10 2004-11-02 Sky Calypso, Inc. Internet linked environmental data collection system and method
US6631410B1 (en) 2000-03-16 2003-10-07 Sharp Laboratories Of America, Inc. Multimedia wired/wireless content synchronization system and method
US6466248B1 (en) 2000-04-05 2002-10-15 Dialogic Corporation Videoconference recording
US6650869B2 (en) 2000-04-14 2003-11-18 Hughes Electronics Corporation System and method for managing return channel bandwidth in a two-way satellite system
US6721280B1 (en) * 2000-04-19 2004-04-13 Qualcomm Incorporated Method and apparatus for voice latency reduction in a voice-over-data wireless communication system
US6873654B1 (en) * 2000-05-16 2005-03-29 Redrock Semiconductor, Inc Method and system for predictive control for live streaming video/audio media
US7487112B2 (en) * 2000-06-29 2009-02-03 Barnes Jr Melvin L System, method, and computer program product for providing location based services and mobile e-commerce
US20020028655A1 (en) * 2000-07-14 2002-03-07 Rosener Douglas K. Repeater system
US8932136B2 (en) * 2000-08-25 2015-01-13 Opentv, Inc. Method and system for initiating an interactive game
US7099388B2 (en) 2000-08-25 2006-08-29 Cooper J Carl System and method for enabling compatibility between digital and analog television systems
US7295614B1 (en) 2000-09-08 2007-11-13 Cisco Technology, Inc. Methods and apparatus for encoding a video signal
US6728514B2 (en) 2000-09-08 2004-04-27 Wi-Lan Inc. Scalable wireless network topology systems and methods
US20030054827A1 (en) * 2000-09-11 2003-03-20 Schmidl Timothy M. Wireless communication channel selection using passive interference avoidance techniques
JP2002099458A (ja) * 2000-09-25 2002-04-05 Pioneer Electronic Corp データ通信システム
FI20002129A (fi) * 2000-09-28 2002-03-29 Nokia Corp Menetelmä ja järjestely paikallisen laajakaistaisen datavirran langattomaksi jakamiseksi
US7257832B2 (en) 2000-10-16 2007-08-14 Heartlab, Inc. Medical image capture system and method
CA2425628C (en) 2000-10-17 2007-07-24 Sprint Communications Company, L.P. Performance management system
US6745050B1 (en) 2000-10-23 2004-06-01 Massachusetts Institute Of Technology Multichannel multiuser detection
US6785511B1 (en) 2000-10-25 2004-08-31 Tyco Electronics Corporation Wireless vehicular repeater system
DE60131900T2 (de) 2000-10-26 2008-12-04 Flood, James C. jun., Portland Verfahren und system zur verwaltung von verteilten inhalten und verwandten metadaten
FI20002449A0 (fi) 2000-11-08 2000-11-08 Nokia Networks Oy Tapahtumien virittäminen
US7244181B2 (en) 2000-11-14 2007-07-17 Netamin Communication Corp. Multi-player game employing dynamic re-sequencing
JP3605353B2 (ja) 2000-11-21 2004-12-22 株式会社ソニー・コンピュータエンタテインメント 光ディスク装置、光ディスク装置の調整方法、及びエンタテインメント装置
US6874029B2 (en) 2000-11-22 2005-03-29 Leap Wireless International, Inc. Method and system for mediating interactive services over a wireless communications network
US20030177187A1 (en) 2000-11-27 2003-09-18 Butterfly.Net. Inc. Computing grid for massively multi-player online games and other multi-user immersive persistent-state and session-based applications
US6996742B2 (en) * 2000-11-28 2006-02-07 Sedna Patent Services, Llc Method for regenerating and streaming content from a video server using RAID 5 data striping
US20020080267A1 (en) 2000-11-28 2002-06-27 Allan Moluf High capacity, low-latency multiplexer
US7027633B2 (en) 2000-11-30 2006-04-11 Foran David J Collaborative diagnostic systems
US20020075382A1 (en) 2000-12-01 2002-06-20 Yoram Cohen Method and apparatus for implementing a thin-client videophone in a cable television network
EP1342375A1 (en) 2000-12-13 2003-09-10 The Chinese University Of Hong Kong Method and system for delivering media selections through a network
US6907070B2 (en) 2000-12-15 2005-06-14 Microsoft Corporation Drifting reduction and macroblock-based control in progressive fine granularity scalable video coding
US6850235B2 (en) * 2000-12-27 2005-02-01 Fly Over Technologies Inc. Efficient image parcel texture rendering with T-junction crack elimination
US6888893B2 (en) 2001-01-05 2005-05-03 Microsoft Corporation System and process for broadcast and communication with very low bit-rate bi-level or sketch video
US6761636B2 (en) 2001-01-16 2004-07-13 Fucom Company, Ltd. Real time data exchange system
US7155515B1 (en) 2001-02-06 2006-12-26 Microsoft Corporation Distributed load balancing for single entry-point systems
FR2821028B1 (fr) 2001-02-16 2003-10-17 Faurecia Sieges Automobile Dispositif d'assise comportant un dossier rabattable
US7113745B2 (en) 2001-02-21 2006-09-26 Ericsson Inc. Method to achieve diversity in a communication network
US6973667B2 (en) 2001-03-01 2005-12-06 Minerva Networks, Inc. Method and system for providing time-shifted delivery of live media programs
US6886029B1 (en) * 2001-03-13 2005-04-26 Panamsat Corporation End to end simulation of a content delivery system
WO2002073812A1 (fr) 2001-03-14 2002-09-19 Matsushita Electric Industrial Co., Ltd. Procede de codage de correction d'erreur, procede de decodage de correction d'erreur et appareils de codage et de decodage de correction d'erreur
US6993353B2 (en) * 2001-03-14 2006-01-31 At&T Corp. Cable data service method
US20020149617A1 (en) 2001-03-30 2002-10-17 Becker David F. Remote collaboration technology design and methodology
US20020154055A1 (en) 2001-04-18 2002-10-24 Robert Davis LAN based satellite antenna/satellite multiswitch
GB2374756B (en) 2001-04-20 2004-07-28 Discreet Logic Inc Image processing
US6671186B2 (en) 2001-04-20 2003-12-30 Hewlett-Packard Development Company, L.P. Electromagnetic interference shield
US6850571B2 (en) * 2001-04-23 2005-02-01 Webtv Networks, Inc. Systems and methods for MPEG subsample decoding
US20020157115A1 (en) 2001-04-24 2002-10-24 Koninklijke Philips Electronics N.V. Wireless communication point of deployment module for use in digital cable compliant devices
US7305691B2 (en) 2001-05-07 2007-12-04 Actv, Inc. System and method for providing targeted programming outside of the home
US20020170065A1 (en) 2001-05-08 2002-11-14 Pinnick Skyler D. Apparatus and method of managing compression of video and delivery of video over the internet
AU2002312747A1 (en) 2001-05-15 2002-11-25 Netadtack Aps Method and system for transmitting multicast data signals
JP4420584B2 (ja) 2001-05-21 2010-02-24 ソニー株式会社 携帯情報処理端末、情報処理方法、プログラム、および情報処理システム
JP4293740B2 (ja) * 2001-05-29 2009-07-08 株式会社リコー 画像圧縮装置
US20020184303A1 (en) 2001-05-31 2002-12-05 Virtaul Media, Inc. Embedded web server capable of managing dynamic content delivery of data stream, audio stream, or video stream
KR20020092022A (ko) 2001-06-01 2002-12-11 애드버츄얼 주식회사 가상이미지 삽입기술을 이용한 실시간 쌍방향 스트리밍비디오 시스템
TW551550U (en) 2001-06-04 2003-09-01 First Int Computer Inc Notebook computer having small type display panel
US20020181190A1 (en) 2001-06-05 2002-12-05 Callado Romulo Monteiro Laptop with separable touch sensitive display
US20020188955A1 (en) 2001-06-11 2002-12-12 Thompson Calvin Eugene Digital video recording and playback system for television
US20030017846A1 (en) * 2001-06-12 2003-01-23 Estevez Leonardo W. Wireless display
US6757735B2 (en) * 2001-07-03 2004-06-29 Hewlett-Packard Development Company, L.P. Method for distributing multiple description streams on servers in fixed and mobile streaming media systems
US7367885B2 (en) 2001-08-09 2008-05-06 Igt 3-D text in a gaming machine
JP2003060638A (ja) * 2001-08-15 2003-02-28 Sony Corp コンテンツ提供装置及びコンテンツ提供方法
JP2003152752A (ja) 2001-08-29 2003-05-23 Matsushita Electric Ind Co Ltd データ送受信方法
US6721260B2 (en) * 2001-09-04 2004-04-13 Hewlett-Packard Development Company L.P. Electromagnetically controlled drive system and method
US6820218B1 (en) 2001-09-04 2004-11-16 Microsoft Corporation Persistent stateful component-based applications via automatic recovery
US20030048808A1 (en) * 2001-09-12 2003-03-13 Stahl Thomas Anthony Method and apparatus for changing received streaming content channels
US6910175B2 (en) * 2001-09-14 2005-06-21 Koninklijke Philips Electronics N.V. Encoder redundancy selection system and method
KR100819493B1 (ko) 2001-09-28 2008-04-07 엘지전자 주식회사 무선랜을 이용한 엠펙 데이터 송수신 장치
US7931533B2 (en) * 2001-09-28 2011-04-26 Igt Game development architecture that decouples the game logic from the graphics logics
US20030079016A1 (en) * 2001-10-23 2003-04-24 Sheng (Ted) Tai Tsao Using NAS appliance to build a non-conventional distributed video server
AU2002365558A1 (en) 2001-11-21 2003-06-10 Marconi Intellectual Property (Us) Inc. Wireless communication device interconnectivity
US6853197B1 (en) * 2001-12-03 2005-02-08 Atheros Communications, Inc. Method and apparatus for insuring integrity of a connectorized antenna
US7299487B1 (en) 2001-12-04 2007-11-20 Unisys Corporation Control program, for a co-processor in a video-on-demand system, which uses transmission control lists to send video data packets with respective subgroups of internet protocol headers
GB0219509D0 (en) * 2001-12-05 2002-10-02 Delamont Dean Improvements to interactive TV games system
AU2002357064A1 (en) 2001-12-07 2003-06-23 Dashsmart Investments, Llc Portable navigation and communication systems
US20030124977A1 (en) 2001-12-28 2003-07-03 Smith Dwight Randall Self-positioning wireless transceiver system and method
US20040148235A1 (en) 2002-01-11 2004-07-29 Craig Mark S. Real time financial instrument image exchange system and method
US7634795B2 (en) 2002-01-11 2009-12-15 Opentv, Inc. Next generation television receiver
JP2005539409A (ja) 2002-03-01 2005-12-22 エンテラシス ネットワークス インコーポレイテッド 位置認識データネットワーク
US7916147B2 (en) 2002-03-01 2011-03-29 T5 Labs Ltd. Centralised interactive graphical application server
US7024224B2 (en) 2002-03-05 2006-04-04 Microsoft Corporation Detachable radio module
US6968153B1 (en) 2002-03-13 2005-11-22 Nokia Corporation Apparatus, method and system for a Bluetooth repeater
US20030181162A1 (en) 2002-03-20 2003-09-25 Michael Matula " Satellite set-top box for mobile applications "
US6908390B2 (en) 2002-03-29 2005-06-21 Igt Apparatus and method for a gaming tournament network
US7263125B2 (en) 2002-04-23 2007-08-28 Nokia Corporation Method and device for indicating quantizer parameters in a video coding system
US7010265B2 (en) 2002-05-22 2006-03-07 Microsoft Corporation Satellite receiving system with transmodulating outdoor unit
US20030226149A1 (en) 2002-05-31 2003-12-04 Kyong-Joon Chun Integrated home network system for providing multimedia services and integrated terminal device for the integrated home network system
US7543326B2 (en) 2002-06-10 2009-06-02 Microsoft Corporation Dynamic rate control
US7038676B2 (en) 2002-06-11 2006-05-02 Sony Computer Entertainmant Inc. System and method for data compression
US8370744B2 (en) 2002-06-19 2013-02-05 Microsoft Corporation User interface for operating a computer from a distance
CN1663147A (zh) 2002-06-21 2005-08-31 威德菲公司 无线局域网中继器
US7043559B2 (en) * 2002-06-27 2006-05-09 Seiko Epson Corporation System for distributing objects to multiple clients
US7072627B2 (en) 2002-06-27 2006-07-04 Microsoft Corporation Method and apparatus for adjusting signal component strength
WO2004012437A2 (en) * 2002-07-31 2004-02-05 Bluestreak Technology Inc. System and method for video-on-demand based gaming
EP1391226B1 (en) * 2002-08-12 2007-10-10 Alcatel Lucent Method and devices for implementing highly interactive entertainment services using interactive media-streaming technology, enabling remote provisioning of virtual reality services
US20040034865A1 (en) * 2002-08-13 2004-02-19 Barrett Peter T. Program guide for previous program broadcasts
US20040043819A1 (en) * 2002-09-03 2004-03-04 Daniel Willis Gaming system emulating a set top box
US6830515B2 (en) * 2002-09-10 2004-12-14 Igt Method and apparatus for supporting wide area gaming network
US7075987B2 (en) * 2002-09-23 2006-07-11 Intel Corporation Adaptive video bit-rate control
US20040203694A1 (en) 2002-10-21 2004-10-14 Wong Samuel L.C. Reconfigurable wireless-enabled network device
US20040080533A1 (en) * 2002-10-23 2004-04-29 Sun Microsystems, Inc. Accessing rendered graphics over the internet
US7230935B2 (en) 2002-10-24 2007-06-12 Widefi, Inc. Physical layer repeater with selective use of higher layer functions based on network operating conditions
US7287052B2 (en) 2002-11-09 2007-10-23 Microsoft Corporation Challenge and response interaction between client and server computing devices
US7878908B2 (en) * 2002-11-14 2011-02-01 Nintendo Co., Ltd. Multiplexed secure video game play distribution
US20040094194A1 (en) 2002-11-15 2004-05-20 Aldoretta David P. Solar panel unit
US20030158700A1 (en) 2002-11-27 2003-08-21 Forler Joseph Wayne Watchdog arrangement
US7219153B1 (en) 2002-12-02 2007-05-15 Cisco Technology, Inc. Methods and apparatus for distributing content
US7165194B2 (en) 2002-12-09 2007-01-16 International Business Machines Corporation Technical support for software products
US7684752B2 (en) * 2002-12-10 2010-03-23 Onlive, Inc. Wireless network providing distributed video / data services
JP2006509548A (ja) 2002-12-10 2006-03-23 ノキア コーポレイション 電子マルチプレイヤ用ゲームのプレイヤが不在の場合に前記ゲームを続行する方法および装置
US7493078B2 (en) * 2002-12-10 2009-02-17 Onlive, Inc. Antenna assembly for satellite and wireless services
US7558525B2 (en) 2002-12-10 2009-07-07 Onlive, Inc. Mass storage repository for a wireless network
US7849491B2 (en) 2002-12-10 2010-12-07 Onlive, Inc. Apparatus and method for wireless video gaming
JP2006510326A (ja) 2002-12-16 2006-03-23 ワイデファイ インコーポレイテッド 改良された無線ネットワーク中継器
US7321578B2 (en) 2002-12-31 2008-01-22 Carlos Rios Multiprotocol WLAN access point devices
US7590084B2 (en) 2003-02-14 2009-09-15 Onlive, Inc. Self-configuring, adaptive, three-dimensional, wireless network
WO2004073269A1 (ja) 2003-02-13 2004-08-26 Fujitsu Limited 伝送システム，配信経路制御装置，負荷情報収集装置および配信経路制御方法
US7215660B2 (en) 2003-02-14 2007-05-08 Rearden Llc Single transceiver architecture for a wireless network
US7593361B2 (en) 2003-02-14 2009-09-22 Onlive, Inc. Method of operation for a three-dimensional, wireless network
US7724818B2 (en) * 2003-04-30 2010-05-25 Nokia Corporation Method for coding sequences of pictures
US7455590B2 (en) 2003-05-09 2008-11-25 Microsoft Corporation Sending messages in response to events occurring on a gaming service
US6963353B1 (en) 2003-05-14 2005-11-08 Cisco Technology, Inc. Non-causal speaker selection for conference multicast
US7430187B2 (en) 2003-05-15 2008-09-30 At&T Intellectual Property I, Lp Methods, systems, and computer program products for providing different quality of service/bandwidth allocation to different susbscribers for interactive gaming
US7359004B2 (en) * 2003-05-23 2008-04-15 Microsoft Corporation Bi-level and full-color video combination for video communication
WO2005038599A2 (en) * 2003-10-14 2005-04-28 Raptor Networks Technology, Inc. Switching system with distributed switching fabric
US7016409B2 (en) 2003-11-12 2006-03-21 Sony Corporation Apparatus and method for use in providing dynamic bit rate encoding
US20050183120A1 (en) 2004-01-13 2005-08-18 Saurabh Jain Multi-user personalized digital multimedia distribution methods and systems
US20070271358A1 (en) 2004-01-16 2007-11-22 William Gaddy System and Method for Dynamically Configured, Asymmetric Endpoint Video Exchange
KR100627500B1 (ko) 2004-03-10 2006-09-21 엘지전자 주식회사 모바일폰의 단문 메시지 제공시스템 및 그 제공방법
TWI293833B (en) * 2004-03-10 2008-02-21 Ind Tech Res Inst Method and apparatus for mpeg-4 fgs performance enhancement
KR100550567B1 (ko) * 2004-03-22 2006-02-10 엘지전자 주식회사 무선 네트워크망을 통해 통신하는 서버 시스템 및 그동작방법
EP1603339A1 (en) 2004-06-01 2005-12-07 STMicroelectronics S.r.l. Method and system for communicating video data in a packet-switched network, related network and computer program product therefor
US7539187B2 (en) 2004-07-07 2009-05-26 Qvidium Technologies, Inc. System and method for low-latency content-sensitive forward error correction
JP4403396B2 (ja) 2004-07-13 2010-01-27 ソニー株式会社 撮像装置及び撮像素子の集積回路
JP2006051251A (ja) 2004-08-13 2006-02-23 Aruze Corp ゲームシステム
US8719075B2 (en) * 2004-09-23 2014-05-06 Overstock.Com, Inc. System, program product, and methods for online image handling
US8948266B2 (en) * 2004-10-12 2015-02-03 Qualcomm Incorporated Adaptive intra-refresh for digital video encoding
US20060078046A1 (en) * 2004-10-13 2006-04-13 Aegison Corp. Method and system for multi-path video delivery and distribution
JP2007065928A (ja) * 2005-08-30 2007-03-15 Toshiba Corp 情報記憶媒体、情報処理方法、情報転送方法、情報再生方法、情報再生装置、情報記録方法、情報記録装置、及びプログラム
US7369856B2 (en) * 2004-11-24 2008-05-06 Intel Corporation Method and system to support fast hand-over of mobile subscriber stations in broadband wireless networks
US7966485B2 (en) 2004-12-01 2011-06-21 Igt Universal operating system to hardware platform interface for gaming machines
US8634413B2 (en) 2004-12-30 2014-01-21 Microsoft Corporation Use of frame caching to improve packet loss recovery
US20060148571A1 (en) 2005-01-04 2006-07-06 Electronic Arts Inc. Computer game with game saving including history data to allow for play reacquaintance upon restart of game
US20060168291A1 (en) 2005-01-05 2006-07-27 Van Zoest Alexander Interactive multichannel data distribution system
US20060150055A1 (en) 2005-01-06 2006-07-06 Terayon Communication Systems, Inc. Adaptive information delivery system using FEC feedback
WO2006081634A2 (en) 2005-02-04 2006-08-10 Barco N.V. Method and device for image and video transmission over low-bandwidth and high-latency transmission channels
EP1694071A1 (en) 2005-02-11 2006-08-23 Vemotion Limited Interactive video applications
WO2006098008A1 (ja) * 2005-03-15 2006-09-21 Fujitsu Limited 通信装置および通信方法
US20080207322A1 (en) 2005-03-21 2008-08-28 Yosef Mizrahi Method, System and Computer-Readable Code For Providing a Computer Gaming Device
US7668914B2 (en) 2005-03-28 2010-02-23 Alcatel Lucent Milestone synchronization in broadcast multimedia streams
US20060230428A1 (en) 2005-04-11 2006-10-12 Rob Craig Multi-player video game system
US7848409B2 (en) 2005-05-02 2010-12-07 Qualcomm Incorporated Macroblock level bit allocation
US20060258463A1 (en) 2005-05-13 2006-11-16 Professional Interactive Entertainment, Inc. System and method for network interactive game match-up and server selection
WO2006134055A1 (fr) 2005-06-17 2006-12-21 France Telecom Procede de gestion de l'execution par un serveur d'une application offrant au moins un service multimedia interactif a au moins un terminal, produit programme d'ordinateur et serveur correspondants
US7548657B2 (en) 2005-06-25 2009-06-16 General Electric Company Adaptive video compression of graphical user interfaces using application metadata
US7702006B2 (en) * 2005-07-05 2010-04-20 Microsoft Corporation Adjustment of transmission data rate based on data errors and/or latency
US7936819B2 (en) * 2005-07-08 2011-05-03 Tag Networks, Inc. Video encoder with latency control
US8289370B2 (en) 2005-07-20 2012-10-16 Vidyo, Inc. System and method for scalable and low-delay videoconferencing using scalable video coding
KR101088375B1 (ko) * 2005-07-21 2011-12-01 삼성전자주식회사 가변 블록 변환 장치 및 방법 및 이를 이용한 영상부호화/복호화 장치 및 방법
JP2007080357A (ja) * 2005-09-13 2007-03-29 Toshiba Corp 情報記憶媒体、情報再生方法、情報再生装置
US8229983B2 (en) * 2005-09-27 2012-07-24 Qualcomm Incorporated Channel switch frame
US20070094700A1 (en) * 2005-10-25 2007-04-26 Jason Wolfe Game delivery system
US8135040B2 (en) 2005-11-30 2012-03-13 Microsoft Corporation Accelerated channel change
US8089892B2 (en) 2005-12-15 2012-01-03 Thomson Licensing Adaptive joint source and channel coding scheme for H.264 video multicasting over wireless networks
US20070156815A1 (en) 2005-12-30 2007-07-05 Nokia Corporation Method, system and entities for multicast content pushing
US8764566B2 (en) 2006-02-24 2014-07-01 Igt Internet remote game server
US20070260492A1 (en) 2006-03-09 2007-11-08 Microsoft Corporation Master patient index
US8392821B2 (en) 2006-03-17 2013-03-05 Viddler, Inc. Methods and systems for displaying videos with overlays and tags
EP1837060A1 (en) 2006-03-21 2007-09-26 In Fusio (S.A.) Method for displaying interactive video content from a video stream in a display of a user device
BRPI0621618B1 (pt) 2006-04-29 2019-10-22 Interdigital Ce Patent Holdings método e dispositivo móvel para recuperar perda de um pacote de dados quando o dispositivo móvel é transferido de controle entre células
JP2008005112A (ja) 2006-06-21 2008-01-10 Matsushita Electric Ind Co Ltd ストリームエンコーダ及びストリームデコーダ
DE102006029208B4 (de) 2006-06-26 2010-06-10 Franz Josef Summerer Spritzgießmaschine und Spritzgießverfahren zum Spritzgießen von Kunststoff-Formteilen mit mehreren Entformrichtungen
US7841946B2 (en) * 2006-06-29 2010-11-30 Spawn Labs, Inc. System for remote game access
US8004692B2 (en) * 2006-06-30 2011-08-23 Chian Chiu Li Optical interferometer and method
US20080032794A1 (en) * 2006-07-24 2008-02-07 Rambus, Inc. Partitioned game console system
US20080025196A1 (en) * 2006-07-25 2008-01-31 Jeyhan Karaoguz Method and system for providing visually related content description to the physical layer
EP2130189A1 (en) 2006-10-27 2009-12-09 Cecure Gaming Limited Online gaming system
US8825765B2 (en) 2006-11-28 2014-09-02 Verizon Patent And Licensing Inc. Cross platform gaming
US8401076B2 (en) * 2006-12-12 2013-03-19 Vantrix Corporation Video rate control for video coding standards
US20080220878A1 (en) 2007-02-23 2008-09-11 Oliver Michaelis Method and Apparatus to Create or Join Gaming Sessions Based on Proximity
US7957307B2 (en) 2007-03-14 2011-06-07 Microsoft Corporation Reducing effects of packet loss in video transmissions
US8494049B2 (en) 2007-04-09 2013-07-23 Cisco Technology, Inc. Long term reference frame management with error video feedback for compressed video communication
JP5503531B2 (ja) 2007-05-02 2014-05-28 グーグル インコーポレイテッド ウェブベースの映像プレイヤのためのユーザインタフェース
US8615630B2 (en) * 2007-06-28 2013-12-24 Apple Inc. Systems and methods for managing data storage
US20090003452A1 (en) * 2007-06-29 2009-01-01 The Hong Kong University Of Science And Technology Wyner-ziv successive refinement video compression
US20090028230A1 (en) * 2007-07-27 2009-01-29 Matsushita Electric Industrial Co., Ltd. Method and apparatus for improving quality of service for reception in digital television broadcast systems
US20090109988A1 (en) * 2007-10-26 2009-04-30 Chowdhary Musunuri Video Decoder with an Adjustable Video Clock
US8887218B2 (en) 2007-11-29 2014-11-11 Jan Maurits Nicolaas Fielibert Systems and methods of adjusting bandwidth among multiple media streams
US8171123B2 (en) 2007-12-04 2012-05-01 Sony Computer Entertainment Inc. Network bandwidth detection and distribution
US8147339B1 (en) 2007-12-15 2012-04-03 Gaikai Inc. Systems and methods of serving game video
CN100571396C (zh) * 2008-04-25 2009-12-16 清华大学 用于解码复杂度限制下的视频编码方法
US8874661B2 (en) * 2008-08-07 2014-10-28 Microsoft Corporation Method and system providing spectator information for a multimedia application
CN101360243A (zh) * 2008-09-24 2009-02-04 腾讯科技（深圳）有限公司 基于反馈参考帧的视频通信系统及方法
US8254704B2 (en) 2008-10-30 2012-08-28 Microsoft Corporation Remote computing platforms providing high-fidelity display and interactivity for clients
TWI387317B (zh) 2008-12-11 2013-02-21 Novatek Microelectronics Corp 產生重新取樣參考畫面之裝置及其方法與影像解碼系統
US8209430B2 (en) 2009-03-27 2012-06-26 Wyse Technology Inc. Apparatus and method for remote communication and bandwidth adjustments
GB2517102B (en) 2009-06-01 2015-03-25 Sony Comp Entertainment Us Qualified video delivery
US7974233B2 (en) 2009-07-29 2011-07-05 Wiviu Technology Inc. Systems and methods for transmitting and receiving data streams with feedback information over a lossy network

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020099725A (ja) * 2012-12-26 2020-07-02 ソニー インタラクティブ エンタテインメント アメリカ リミテッド ライアビリテイ カンパニー タグコンテンツおよびソーシャルネットワークコンテンツに基くクラウドで実行されたミニゲームをランク付けするシステムおよび方法
JP2017084255A (ja) * 2015-10-30 2017-05-18 任天堂株式会社 情報処理装置、情報処理システム、情報処理方法、および情報処理プログラム
US10657674B2 (en) 2016-06-17 2020-05-19 Immersive Robotics Pty Ltd. Image compression method and apparatus
US11151749B2 (en) 2016-06-17 2021-10-19 Immersive Robotics Pty Ltd. Image compression method and apparatus
US11150857B2 (en) 2017-02-08 2021-10-19 Immersive Robotics Pty Ltd Antenna control for mobile device communication
US11429337B2 (en) 2017-02-08 2022-08-30 Immersive Robotics Pty Ltd Displaying content to users in a multiplayer venue
US11153604B2 (en) 2017-11-21 2021-10-19 Immersive Robotics Pty Ltd Image compression for digital reality
US11553187B2 (en) 2017-11-21 2023-01-10 Immersive Robotics Pty Ltd Frequency component selection for image compression
JP2021053182A (ja) * 2019-09-30 2021-04-08 株式会社コロプラ プログラム、方法、および配信端末

Also Published As

Publication number Publication date
RU2528152C2 (ru) 2014-09-10
TW201041401A (en) 2010-11-16
KR101723695B1 (ko) 2017-04-05
EP2411944A4 (en) 2012-12-12
US8366552B2 (en) 2013-02-05
CN102428483A (zh) 2012-04-25
BRPI1012243A2 (pt) 2020-08-18
EP2411944A1 (en) 2012-02-01
RU2011142761A (ru) 2013-04-27
KR20110136875A (ko) 2011-12-21
US20100167816A1 (en) 2010-07-01
IL215305A0 (en) 2011-12-29
CA2756331A1 (en) 2010-09-30
MX2011009976A (es) 2012-03-29
WO2010111100A1 (en) 2010-09-30
AU2010229096A1 (en) 2011-11-10
SG174909A1 (en) 2011-11-28
TWI475843B (zh) 2015-03-01

Similar Documents

Publication Publication Date Title
JP6369999B2 (ja) 通信チャンネルを経て送信されるある形式のマルチメディアデータを保護するシステム及び方法
JP6106208B2 (ja) ストリーミング双方向ビデオを圧縮するシステム及び方法
JP6442461B2 (ja) 通信チャンネルにわたるパケットロスの影響を減少するためのビデオ圧縮システム及び方法
JP5568628B2 (ja) 複数のエンコーディングフォーマットを使用するマルチストリームビデオ圧縮のためのシステム及び方法
JP5677093B2 (ja) システム故障の前の記録されたビデオを報告するシステム
JP2015053719A (ja) 選択されたタイル及びタイル回転パターンを使用してビデオをエンコードするためのシステム及び方法
JP2012521268A (ja) マルチストリームビデオ圧縮のためのシステム及び方法
JP2012521719A (ja) フィードバックデータに基づいてビデオエンコーディングフォーマットを選択するためのシステム及び方法
JP2012521721A (ja) クライアント装置からのフィードバック情報に基づきビデオフレーム又はその一部分を圧縮するためのシステム及び方法
JP2012521269A (ja) 加速マシン切り換えのためのシステム及び方法
JP2012521725A (ja) ビデオ圧縮と共に順方向エラー修正を使用するためのシステム及び方法
JP2012521723A (ja) 一時的デコーダ装置及び方法
JP2012521718A (ja) 待ち時間測定及び他のフィードバックに基づいてビデオを圧縮するためのシステム及び方法
JP2012521720A (ja) ビデオコンテンツの首尾良い受信に関連したデータを含むフィードバックを使用してビデオを圧縮するシステム及び方法
JP2012105285A (ja) リモートホスト型ビデオ効果のためのシステム及び方法
JP2012101084A (ja) リモートホスト型ビデオ効果のためのシステム及び方法
JP2011507077A (ja) ストリーミング双方向ビデオサーバー間でユーザセッションを移行する方法
JP2011507341A (ja) ストリーミング双方向ビデオを使用したバーチャル事象のホスティング及びブロードキャスティング
JP2011507343A (ja) ウェブページ配信を加速するシステム
JP2011507350A (ja) ストリーミング双方向ビデオクライアント装置
JP2011507340A (ja) 記録されたビデオセグメントと一体化されたストリーミング双方向ビデオ
JP2011509545A (ja) ストリーミング双方向ビデオを使用して協力的に会議を行うシステム
JP2011507339A (ja) リアルタイムストリーミング双方向ビデオの複数のビューを合成するシステム
JP2011508478A (ja) リアルタイムストリーミング双方向ビデオのビューをマルチキャスティングする方法
JP2011507344A (ja) 記録されたアプリケーション状態をアプリケーションストリーミング双方向ビデオ出力と合成するシステム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130318

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130318

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20131018

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20131114

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20131203

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20140110

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20140512