BRPI1012236A2 - Sistema e método para compressão de quadros de vídeo ou partes dos mesmos com base em informação de retorno de um dispositivo cliente - Google Patents

Sistema e método para compressão de quadros de vídeo ou partes dos mesmos com base em informação de retorno de um dispositivo cliente Download PDF

Info

Publication number
BRPI1012236A2
BRPI1012236A2 BRPI1012236-2A BRPI1012236A BRPI1012236A2 BR PI1012236 A2 BRPI1012236 A2 BR PI1012236A2 BR PI1012236 A BRPI1012236 A BR PI1012236A BR PI1012236 A2 BRPI1012236 A2 BR PI1012236A2
Authority
BR
Brazil
Prior art keywords
video
game
frames
user
client
Prior art date
Application number
BRPI1012236-2A
Other languages
English (en)
Inventor
Stephen G. Perlman
Roger Van der Laan
Timothy Cotter
Robert McCool
Ian Buckley
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
Application filed by Onlive, Inc. filed Critical Onlive, Inc.
Publication of BRPI1012236A2 publication Critical patent/BRPI1012236A2/pt

Links

Classifications

    • 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/25—Output arrangements for video game devices
    • 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
    • A63F13/12—
    • 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
    • A63F13/355—Performing operations on behalf of clients with restricted processing capabilities, e.g. servers transform changing game scene into an encoded video 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
    • 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/71—Game security or game management aspects using secure communication between game devices and game servers, e.g. by encrypting game data or authenticating players
    • 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/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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream 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 or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234363—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the spatial resolution, e.g. for clients with a lower screen resolution
    • 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 or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream 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 or manipulating encoded video stream 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H04N21/25833—Management of client data involving client hardware characteristics, e.g. manufacturer, processing or storage capabilities
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • 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/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/6583—Acknowledgement
    • 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
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Graphics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

SISTEMA E MÉTODO PARA COMPRESSÃO DE QUADROS DE VÍDEOS OU PARTES DOS MESMOS COM BASE EM INFORMAÇÃO DE RETORNO DE UM DISPOSITIVO CLIENTE. A presente invenção refere-se a um sistema implementado por computador e método para realizar compressão de vídeo. Por exemplo, um método de acordo com uma modalidade compreende: codificar uma pluralidade de quadros de vídeo ou partes dos mesmos de acordo com um primeiro formato de codificações; transmitir a pluralidade de quadros de vídeo codificados ou partes para um dispositivo cliente; receber informação de retorno a partir do dispositivo cliente, a informação de retorno útil para determinar se dados contidos nos quadros de vídeo ou partes não tenham sido recebidos com sucesso e/ou decodificados; em resposta à detecção de que um quadro de vídeo ou parte do mesmo não tenha sido recebido com sucesso e/ou decodificado, codificar um quadro de vídeo ou parte do mesmo de acordo com um segundo formato de codificação; e transmitir os quadros de vídeo ou partes dos mesmos para o dispositivo cliente.

Description

É Relatório Descritivo da Patente de Invenção para "SISTEMA E |
MÉTODO PARA COMPRESSÃO DE QUADROS DE VÍDEO OU PARTES
DOS MESMOS COM BASE EM INFORMAÇÃO DE RETORNO DE UM DISPOSITIVO CLIENTE". — Pedido Relacionado f | Este pedido reivindica prioridade para o Pedido provisório US de | Nº Serial 61/210.888, depositado em 23 de março de 2009, intitulado, "Sistema e Método para Compressão de Vídeo Usando Realimentação de .” E Informação", que é uma continuação em parte do Pedido US de Nº Serial US 12/359.150 co-pendente, depositado em 23 de janeiro de 2009, intitulado, "Sistema e Método para Proteção de Certos Tipos de Dados Multimídia Transmitidos Sobre um Canal de Comunicação", e é uma continuação em . parte do Pedido US de Nº Serial US 11/999.475 co-pendente, depositado em 5 de dezembro de 2007, intitulado, "Hospedagem e Difusão de Eventos iá 15 Virtuais Usando Vídeo Interativo de Fluxo Contínuo" que é uma continuação em parte (CIP) do Pedido de Nº Serial 10/315.460 depositado em 10 de dezembro de 2002 intitulado, "APARELHO E MÉTODO PARA JOGOS EM VÍDEO SEM FIO", que é designado para o requerente do presente pedido CIP. Campo da Técnica A presente invenção refere-se em geral ao campo de sistemas de processamento de dados que melhoram a habilidade de um usuário para te manipular e acessar mídia de áudio e vídeo. , Antecedentes Mídia gravada de áudio e imagem em movimento tem sido um aspecto da sociedade desde os tempos de Thomas Edison. No início do século 20 ouve uma ampla distribuição de mídia de áudio gravada (cilindros e discos) e mídia de imagem em movimento (cinemas (nickelodeons) e fil- mes), mas ambas as tecnologias ainda estavam em sua infância. No final dos anos 1920s imagens em movimento foram combinadas com áudio com base em um mercado de massa, seguidos por imagens em movimento colo- ridas com áudio. A difusão de rádio evoluiu gradualmente largamente supor-
| tada por propaganda em uma forma de difusão de mídia de áudio para mer- | cado de massa.
Quando foi estabelecido um padrão de difusão de televisão | | (TV) no meio dos anos 1940s, a televisão juntou-se ao rádio como uma for- | j ma de difusão de mídia de mercado de massa trazendo imagens em movi- : | 5 mento previamente gravadas ou ao vivo para dentro de casa. a | No meio do século 20, uma grande porcentagem de residências | US tinha tocadores de gravação fonográfica para ticar mídia de áudio grava- ! da, um rádio para receber difusão de áudio ao vivo e um conjunto de televi- E são para tocar difusão mídia de áudio/vídeo (A /V)ao vivo.
Muito frequente- mente estes 3 "tocadores de mídia" (tocador de gravação, rádio e TV) foram combinados em um gabinete compartilhando alto-falantes comuns o que se tornou uma "central de mídia" para as residências.
Embora as escolhas de " mídia fossem limitadas para o consumidor, o "ecossistema" de mídia era f bastante estável.
A maior parte dos consumidores sabia como usar os "to- f 15 —cadores de mídia" e eram capazes de aproveitar completamente seus recur- sos.
Ao mesmo tempo, os publicadores de mídia (largamente os estúdios de filmes e televisões, e as companhias de música) eram capazes de distribuir suas mídias tanto para cinemas como para as residências sem sofrer de pi- rataria ou "segundas vendas", ou seja, a revenda de mídia usada.
Tipica- mente as publicadoras não derivam receita de segundas vendas, e, portanto, isto reduz as receitas que os publicadores poderiam de outra forma derivar do comprador de mídia usada para novas vendas.
Embora certamente fos- TF sem usadas gravações vendidas durante a metade do século 20, estas ven- . das não tinham o grande impacto nos publicadores de gravação, diferente deum filme ou programa de vídeo - que é tipicamente assistido uma vez ou apenas umas poucas vezes por um adulto - uma trilha de música pode ser ouvida centenas ou mesmo milhares de vezes.
Assim, mídia de música é muito menos "perecível" (ou seja, a mesma tem valor duradouro para um consumidor adulto) do que uma mídia de filme/vídeo.
Uma vez tendo sido comprada uma gravação, se o consumidor gostou da música, o consumidor provavelmente irá mantê-la por um longo tempo.
Do meio do século 20 até os dias atuais, o ecossistema de mídia
! tem passado por uma série de mudanças radicais, tanto em benefício como i em detrimento dos consumidores e publicadores.
Com a introdução da am- pla difusão de gravadores de áudio, especialmente fitas cassete com som estéreo de alta qualidade, certamente houve um maior grau de conveniência | 5 do consumidor.
Mas isto também marcou o início do que é agora uma práti- | ca amplamente difundida com mídia de consumidor: pirataria.
Certamente, [ muitos consumidores usaram as fitas cassete para gravar suas próprias gra- À vações por conveniência, mas uma quantidade crescente de consumidores (por exemplo, estudantes em um dormitório com acesso direto a coleções de gravações de outros) faria cópias pirateadas.
Também, consumidores grava- riam músicas tocadas pelo rádio em vez de comprar uma gravação ou fita do publicador. ft O advento do VCR para consumidor levou a ainda maior conve- niência do consumidor, uma vez que um VCR podia ser ajustado para gravar Ê 15 um programa de TV para ser assistido em um momento posterior, e isto também levou a criação de um negócio de aluguel de vídeo, onde filmes bem como programas de TV podiam ser acessados em uma base sob de- manda.
O rápido desenvolvimento do mercado de massa dos dispositivos de mídia domésticos a partir do meio dos anos 1908s levou a um nível sem precedentes de escolha e conveniência para o consumidor, e também levou a uma rápida expansão do mercado de mídia publicitária.
Hoje, os consumidores se deparam com uma pletora de esco- - lhas de mídia bem como uma pletora de dispositivos de mídia, muitos dos - quais são ligados a formas particulares de mídia de publicadores particula- res.
Eo consumidor ávido por mídia pode ter uma pilha de dispositivos co- nectados a TVs e computadores em várias salas da residência, resultando em um "ninho de rato" de cabos para um ou mais conjuntos de TV e /ou computadores pessoais (PCs) bem como a um grupo de controles remotos. : (No contexto do presente pedido, o termo "computador pessoal" ou "PC" refere-se a qualquer tipo de computador adequado para uso em residência ou escritório, incluindo um computador de mesa, um Macintoshº ou outros computadores não Windows, dispositivos compatíveis com Windows, varia-
| ções de Unix, computadores portáteis, etc.). Estes dispositivos podem incluir i uma console de jogos de vídeo, VCR, tocador de DVD, amplifica- dor/processador de som ambiente para áudio, conjuntos de decodificadores de satélite, etc.
E, para um consumidor ávido, pode haver múltiplos dispositi- Í 5 voscom funções similares devido a questões de compatibilidade.
Por exem- | plo, o consumidor pode possuir tanto um DVD-HD como um tocador de BDB Blu-ray, ou tanto um sistema de jogos de vídeo Microsoft Xbox? como um Sony Playstationº.
De fato, devido à incompatibilidade de alguns jogos atra- vés de versões de consoles de jogos, o consumidor pode possuir tanto um XBox como uma versão posterior, tal como um Xbox 360º.
Frequentemente, : os consumidores são confundidos como com qual entrada de vídeo ou con- trole remoto usar. mesmo após um disco ser colocado no tocador correto " (por exemplo, DVD, HD-DVD, Blu-ray, Xbox ou Playstation), a entrada de vídeo e áudio ser selecionada para aquele dispositivo, e o controle remoto À 15 correto ser achado, o consumidor ainda se depara com desafios técnicos.
Por exemplo, no caso de um DVD de tela panorâmica (wide-screen), o usuá- rio pode ter que primeiro determinar e em seguida configurar a relação de aspecto correta em sua TV ou tela de monitor (por exemplo, 4:3, Completa, Aproximação (Zoom), Aproximação Panorâmica (Wide Zoom), Panorâmica de Cinema, etc). De maneira similar, o usuário pode ter que primeiro deter- minar e em seguida configurar o formato correto do sistema de som ambien- te de áudio (por exemplo, AC-3, Dolby Digital, DTS, etc.). Muitas vezes, o - consumidor não está consciente de que ele pode não estar aproveitando o , conteúdo da mídia com toda a capacidade de seu sistema de televisão e áudio (por exemplo, assistindo um filme achatado ou com relação de aspec- to errada, ou ouvindo o áudio em estéreo em vez de em som ambiente). Cada vez mais, dispositivos de mídia com base em Internet têm sido adicionados a pilha de dispositivos.
Dispositivos de áudio tais como o sistema de áudio de fluxo contínuo de Música Digital Sonosº diretamente da Internet.
Da mesma forma, dispositivos como o gravador e tocador de entre- tenimento Slingboxº grava vídeo e distribui o mesmo em fluxo contínuo atra- vés de uma rede doméstica ou para fora através da Internet onde o mesmo pode ser assistido através de um PC. E serviços de Televisão por Protocolo | Internet (IPTV) oferecem serviços semelhantes à TV a cabo através de Linha Digital de Assinante (DSL) Ou outras conexões domésticas de Internet. tam- bém tem havido recentes esforços para integrar múltiplas funções de mídia | 5 em um único dispositivo, tal como Central de Mídia Moxiº” e PCs rodando T | Edição de Central de Mídia (Media Center Edition) do Windows XP. Embora | cada um destes dispositivos ofereça um elemento de conveniência para as | funções que o mesmo executa, cada um carece de acesso simples e ubíquo : a maior parte de mídia. Adicionalmente, estes dispositivos frequentemente à custam centenas de dólares para fabricar, frequentemente devido à necessi- dade de processamento e/ou armazenamento locais que são caros. Adicio- nalmente, estes dispositivos eletrônicos modernos de consumidor tipicamen- F te consomem uma grande quantidade de energia, mesmo quando inativos, o que significa que os mesmos são caros ao longo do tempo e desperdiçam É 15 recursos de energia. Por exemplo, um dispositivo pode continuar a operar se o consumidor esquece de desligá-lo ou comuta para uma entrada de vídeo diferente. E, devido a nenhum dos dispositivos ser uma solução completa, o mesmo precisa ser integrado com uma outra pilha de dispositivos na resi- dência, o que ainda deixa o usuário com um ninho de rato de fios e um mar de controlesremotos.
Além disso, quando muitos dispositivos mais novos com base em Internet não funcionam corretamente, os mesmos tipicamente oferecem - mídia de uma forma mais genérica do que poderia estar disponível de outra : forma. Por exemplo, dispositivos que exibem vídeo através da Internet fre- quentemente exibem apenas o material do vídeo, não os "extras" interativos que frequentemente acompanham os DVDs, tais como os vídeos de "basti- dores", jogos, ou comentários do diretor. Isto é devido ao fato de que fre- quentemente o material interativo é produzido em um formato particular des- tinado a um dispositivo particular que trata a interatividade localmente. Por exemplo, cada disco de DVD, HD-DVDs e Blu-ray têm seu próprio formato interativo particular. Qualquer dispositivo de mídia doméstico ou computador local que poderia ser desenvolvido para suportar todos os formatos popula-
| É res exigiria um nível de sofisticação e flexibilidade que provavelmente o tor- | naria proibitivamente caro e complexo para o consumidor operar. | Adicionando ao problema, se um novo formato é introduzido posteriormente o dispositivo local pode não ter a configuração de hardware para suportar o novo formato, que pode significar que o consumidor tenha L que comprar um dispositivo de mídia local atualizado.
Por exemplo, se vídeo i de maior resolução ou vídeo estereoscópico (por exemplo, um fluxo contínuo para cada olho) forem introduzidos em uma data posterior, o dispositivo local . pode não ter a capacidade computacional para decodificar o vídeo, ou o mesmo pode não ter o hardware para fornecer o vídeo no novo formato (por l exemplo, assumindo que estereoscopia é alcançada através de vídeo a 120fps sincronizado com óculos com obturadores, com 60fps entregues para - cada olho, se o hardware do vídeo do consumidor pode suportar apenas ví- deo de 60fps esta opção estaria indisponível afora uma compra de hardware “15 atualizado). A questão da obsolescência e complexidade do dispositivo de mídia é um problema sério quando vem para mídia interativa sofisticada, especialmente jogos de vídeo.
Aplicações modernas de jogos de vídeo são largamente dividi- das em quatro plataformas de hardware não portáveis principais: Sony PlayStationº 1, 2 e 3 (PS1, PS2, e PS3); Microsoft Xbox” e Xbox 360º; e Nintendo Gamecubeº e Wii""; e jogos com base em PC.
Cada uma destas - plataformas é diferente das outras de modo que os jogos escritos para rodar - em uma plataforma geralmente não rodam em outra plataforma.
Também — podem haver problemas de compatibilidade de uma geração do dispositivo para a próxima.
Apesar de a maior parte dos desenvolvedores de software de jogos criarem softwares de jogos que são independentes de uma plata- forma particular, a fim de rodar um jogo particular em uma plataforma espe- cífica uma camada de software proprietário (frequentemente chamada "me- canismo de desenvolvimento de jogo") é necessária para adaptar o jogo pa- ra uso em uma (plataforma específica. cada plataforma é vendida para o consumidor como uma "console" (ou seja, uma caixa separada ligada a uma
TV ou monitor/alto-falantes) ou é ela própria um PC.
Tipicamente, os jogos de vídeo são vendidos em mídia ótica tal como um Blu-ray DVD, DVD-ROM | ou CD-ROM, que contém o jogo de vídeo incorporado como uma aplicação de software sofisticada em tempo real.
Como as velocidades de banda larga | 5 residenciais tem aumentado, os jogos de vídeo estão se tornando cada vez P Í mais disponíveis para download. | As exigências específicas para obter compatibilidade de plata- forma com software de jogo de vídeo é extremamente exigente devido à na- tureza de tempo real e alta exigência computacional de jogos de vídeo avan- À çados.
Por exemplo, poder-se-ia esperar compatibilidade total de jogo de uma geração para a próxima dos jogos de vídeo (por exemplo, de XBox para XBox 360, ou de Playstation 2 ("PS2") para Playstation 3 ("PS3"), uma vez a que existe uma compatibilidade geral de aplicações de produtividade (por exemplo, Microsoft Word) de um PC para outro com uma unidade de pro- À 15 cessamento ou núcleo mais rápido.
Entretanto, este não é o caso com jogos de vídeo.
Devido a os fabricantes de jogos estarem tipicamente buscando a performance mais alta possível para um dado ponto de preço quando uma geração de jogos de vídeo é liberada, mudanças de arquitetura dramáticas ao sistema são feitas frequentemente de modo que muitos jogos escritos parao sistema de geração anterior não funcionam no sistema de geração posterior.
Por exemplo, XBox foi baseado na família de processadores x86, enquanto que o XBox 360 foi baseado na família PowerPC. - Podem ser utilizadas técnicas que emulam uma arquitetura ante- - rior, mas dado que jogos de vídeo são aplicações de tempo real, frequente- mente é inviável obter exatamente o mesmo comportamento em uma emu- lação.
Isto em detrimento ao consumidor, o fabricante de console de jogos de vídeo e o publicador de software de jogos de vídeo.
Para o consumidor, isto significa a necessidade de manter tanto a velha como a nova geração de consoles de jogos conectada a TV para ser capaz de jogar todos os jogos.
Parao fabricante de console isto significa custo associado com emulação e adoção mais lenta das novas consoles.
E para o publicador isto significa que múltiplas versões de novos jogos podem ter que ser liberadas a fim de al-
] cançar todos os consumidores em potencial - não apenas liberando uma | versão para cada marca de jogo de vídeo (por exemplo, XBox, Playstation), ! mas frequentemente uma versão para cada versão de uma dada marca (por exemplo, PS2 e PS3). Por exemplo, uma versão separada do "Madden NFL | 5 08” da Electronic Arts foi desenvolvida para XBox, XBox 360, PS2, PS3, ( j Gamecube, Wii, e PC, dentre outras plataformas. | Dispositivos portáteis, tais como telefones celulares e tocadores ' de mídia portáteis também apresentam desafios para desenvolvedores de jogos. Cada vez mais estes dispositivos são conectados a redes de dados semfioe são capazes de baixar jogos de vídeo. Mas, existe uma ampla va- h riedade de telefones celulares e dispositivos de mídia no mercado, com uma ampla variedade de diferentes resoluções de exibição e recursos computa- e cionais. Também, devido a estes dispositivos terem tipicamente restrições de consumo de energia, custo e peso, os mesmos tipicamente não possuem À 15 hardware de aceleração gráfica avançado tal como uma Unidade de Proces- samento Gráfico ("GPU"), tal como os dispositivos feitos pela NVIDIA de Santa Clara, CA. Consequentemente, os desenvolvedores de software de jogos tipicamente desenvolvem um dado titulo de jogo simultaneamente para muitos tipos diferentes de dispositivos portáteis. Um usuário pode achar que um dado título de jogo não está disponível para o seu telefone celular ou tocador de mídia portátil particular.
No caso de consoles de jogos residenciais, fabricantes de plata- - forma de hardware tipicamente cobram um direito de exploração aos desen- ' volvedores de software de jogos para permitir a publicação de um jogo em sua plataforma. Operadoras de telefone celular sem fio também cobram tipi- camente um direito de exploração ao publicador do jogo para baixar um jogo no telefone celular. No caso de jogos de PC, não existe direito de exploração pago para jogos publicados, mas os desenvolvedores de jogos tipicamente se deparam com altos custos devido à maior sobrecarga de serviço ao clien- te para suportar uma ampla variedade de problemas de configurações e ins- talações de PC que podem surgir. Também, os PCs tipicamente apresen- tam menos barreiras para a pirataria do software de jogo uma vez que os
| mesmos são prontamente reprogramáveis por um usuário tecnicamente qua- | lificado e os jogos podem ser pirateados mais facilmente e distribuídos mais | facilmente (por exemplo, através da Internet). Portanto, para um desenvol- | vedor de software de jogos, existem custos e desvantagens em publicar em | | 5 consoles de jogos, telefones celulares e PCs. r Í Para publicadores de software de jogos de console e PC, os custos não param aí.
Para distribuir jogos através de canais varejo, os publi- cadores cobram um preço de atacado abaixo do preço de venda para que o varejista tenha uma margem de lucro.
O publicador também tipicamente tem que pagar o custo de fabricar e distribuir a mídia física contendo o jogo.
Fre- quentemente também é cobrada ao publicador uma "taxa de proteção de preço" pelo varejista para cobrir possíveis contingências tais como onde o à. jogo não vende, ou se o preço do jogo é reduzido, ou se o varejista tem que restituir parte ou todo o preço de atacado e/ou receber uma devolução de Í 15 um jogo do comprador.
Adicionalmente, os varejistas tipicamente também cobram taxas aos publicadores para ajudar o mercado de jogos em panfletos de propaganda.
Além disso, os varejistas estão tipicamente cada vez mais comprando de volta os jogos dos usuários que acabaram de jogá-los, e en- tão os vendem como jogos usados, tipicamente não compartilhando nada da venda do jogo usado com o publicador do jogo.
Adicionando a carga de cus- tos colocada sobre os publicadores de jogos está o fato de que os jogos fre- quentemente são pirateados e distribuídos através da Internet para usuários = baixarem e fazerem cópias gratuitas. - Conforme as velocidades de banda larga de Internet tem aumen- tadoea conectividade de banda larga tem se tornado mais difundida nos EUA e por todo o mundo, particularmente para as residências e Internet "ca- fés" onde PCs conectados a Internet são alugados”, os jogos estão cada vez mais sendo distribuídos através de downloads para PCs ou consoles.
Co- : nexões de banda larga também são cada vez mais usadas para jogar jogos emlinhamultijogadores e multijogadores em larga escala (ambos os quais são referenciados na presente invenção pelo acrônimo "MMOG"). Estas mu- danças mitigam alguns dos custos e problemas associados com a distribui-
| ção por varejo.
Baixar jogos em linha endereça algumas das desvantagens | | para os publicadores de jogos pelo fato de que os custos de distribuição tipi- camente são menores e existem pequenos ou nenhum custo pela mídia não | vendida.
Mas os jogos baixados ainda são sujeitos a pirataria, e devido ao | 5 seutamanho (frequentemente um tamanho de muitos gigabytes) os mesmos F podem demorar um tempo muito longo para baixar.
Adicionalmente, múlti- ; plos jogos podem encher completamente pequenos discos, tais como aque- | les vendidos com computadores portáteis ou com consoles jogos de vídeo.
Entretanto, no âmbito em que os jogos ou MMOGs requerem uma conexão emlinha para o jogo ser jogável, o problema de pirataria é mitigado uma vez : que usualmente é requerido que o usuário tenha uma conta de usuário váli- da.
Diferente de mídia linear (por exemplo, vídeo e música) que podem ser 1 copiados por uma câmera filmando o vídeo de uma tela de exibição ou um microfone gravando áudio de alto falantes, cada experiência de jogo de víi- É 15 deoé única, e não pode ser copiada usando uma simples gravação de ví- deo/áudio.
Portanto, mesmo em regiões onde as leis de direitos autorais não são fortemente aplicadas e a pirataria é excessiva, os MMOGs podem ser protegidos da pirataria e portanto um negócio pode ser suportado.
Por exemplo, o MMOG "World of Warcraft" da Vivendi SA foi lançado com su- cesso sem sofrer de pirataria por todo o mundo E muitos jogos em linha ou MMOG, tais como o MMOG "Second Life" da Linden Lab geram receita para os operadores dos jogos através de modelos econômicos construídos dentro bs dos jogos onde recursos podem ser comprados, vendidos e mesmo criados . usando ferramentas em linha.
Portanto, mecanismos adicionais às compras ou subscrições de software de jogos convencionais podem ser usados para pagar o uso de jogos em linha.
Embora a pirataria possa ser frequentemente mitigada devido à natureza dos jogos em linha ou MMOGSs, o operador de jogos em linha ainda se depara com desafios remanescentes.
Muitos jogos requerem recursos de — processamento locais (ou seja, in-home) substanciais para os jogos em linha ou MMOGs funcionarem adequadamente.
Se um usuário tem um computa- dor local de baixa performance (por exemplo, um sem uma GPU, tal como
| um computador portátil básico), o mesmo pode não ser capaz de jogar o jo- | go.
Adicionalmente, as consoles de jogos envelhecem, as mesmas ficam | adicionalmente atrás do estado da técnica e não são capazes de manipular | jogos mais avançados.
Mesmo assumindo que o PC local do usuário é ca- r :; 5 —pazde controlaras exigências computacionais de um jogo, frequentemente r | existem complexidades de instalação.
Pode haver incompatibilidades de a- cionador (driver) (por exemplo, se um novo jogo é baixado, o mesmo pode ! instalar uma nova versão de um acionador de gráfico que torna um jogo ins- talado previamente, compatível com uma versão mais velha do acionador de gráfico, inoperante). Uma console pode ficar sem espaço em disco conforme i mais jogos são baixados.
Jogos complexos tipicamente recebem correções baixadas ao longo do tempo a partir do desenvolvedor do jogo quando erros E são descobertos e corrigidos, ou se são feitas modificações ao jogo (por exemplo, se o desenvolvedor do jogo descobre que um nível do jogo é muito É 15 difícil ou muito fácil de jogar). Estas correções requerem novos downloads.
Mas algumas vezes nem todos os usuários completam os downloads de to- das as correções.
Outras vezes, as correções baixadas introduzem outros problemas de compatibilidade ou de consumo de espaço em disco.
Também, quando se joga o jogo, podem ser requeridos grandes downloads de dados para fornecer gráficos ou informações comportamentais para o PC ou console local.
Por exemplo, se o usuário entra em uma sala em um MMOG e encontra um cenário ou personagem construído de dados à. gráficos ou com comportamentos que não estão disponíveis na máquina lo- : cal do usuário, então os dados daquele cenário ou personagem têm que ser — baixados. isto pode resultar em um atraso substancial enquanto se joga o jogo se a conexão de Internet não for rápida o suficiente.
E, se o cenário ou personagem encontrado exigir espaço de armazenamento ou capacidade computacional além daquela do PC ou console local, isto pode criar uma situação em que o usuário não pode prosseguir no jogo, ou tem que conti- —nuar com qualidade gráfica reduzida.
Portanto, jogos em linha ou MMOG frequentemente limitam suas exigências de armazenamento e/ou complexi- dade computacional.
Adicionalmente, os mesmos frequentemente limitam a
| i quantidade de transferências de dados durante o jogo.
Jogos em linha ou | MMOSG também podem estreitar o mercado de usuários que podem jogar os | jogos.
Além disso, usuários com conhecimento técnico estão cada vez | 5 maisfazendo engenharia reversa nas cópias locais dos jogos e modificando F os jogos de forma que eles possam trapacear.
As trapaças talvez tão sim- ! ples como fazer uma repetição de pressionamento de botão mais rápida do ! que humanamente possível (por exemplo, como para atirar com um revólver rapidamente). Em jogos que suportam transações de recursos no jogo a tra- ; paça pode alcançar um nível de sofisticação que resulta em transações fraudulentas envolvendo recursos de valor econômico real.
Quando um mo- delo econômico em linha ou MMOG é baseado nestas transações de recur- : sos, isto pode resultar em consequências prejudiciais substanciais aos ope- radores de jogos. f 15 Os custos para desenvolver um novo jogo têm crescido confor- me os PCs e consoles são capazes de produzir jogos cada vez mais sofisti- cados (por exemplo, com gráficos mais realistas, tal como um rastreamento em tempo real, e comportamentos mais realistas, tal como simulação física em tempo real). No início da indústria de jogos de vídeo, o desenvolvimento de jogos de vídeo era muito similar ao processo de desenvolvimento de software de aplicação, ou seja, a maior parte do custo do desenvolvimento era no desenvolvimento do software, ao contrário do desenvolvimento de = gráfico, áudio e elementos comportamentais ou "recursos", tais como aque- : les desenvolvidos para um filme com muitos efeitos especiais.
Hoje, muitos esforços de desenvolvimento de jogos de vídeo sofisticados se assemelham mais proximamente ao desenvolvimento de filmes ricos em efeitos especiais do que ao desenvolvimento de software.
Por exemplo, muitos jogos de vídeo proporcionam simulações de mundos em 3-D, e geram personagens, aces- sórios e ambientes cada vez mais fotorrealísticos (ou seja, gráficos de com- —putador que parecem tão realistas quanto conjunto de imagens de ação ao vivo registrada fotograficamente). Um dos aspectos mais desafiadores do desenvolvimento de jogos é criar uma face humana gerada por computador
| i que seja indistinguível de uma face humana em ação ao vivo.
Tecnologias | de captura facial tais como Contour"“ Reality Capture desenvolvida pela Mova de San Francisco, CA captura e rastreia a geometria precisa de uma face de um ator em alta resolução enquanto a mesma está em movimento. 1 5 — Estatecnologia permite que uma face em 3D seja representada em um PC L ou console de jogo que seja virtualmente indistinguível de uma face captura- da em ação ao vivo.
Capturar e representar uma face humana "foto-realista" precisa é útil em diversos aspectos.
Primeiro, celebridades ou atletas alta- E mente conhecidos são frequentemente usados em jogos de vídeo (frequen- É temente contratados a alto custo), e imperfeições podem ficar aparentes pa- ra o usuário, tornando a experiência de visualização confusa ou não praze- rosa.
Frequentemente é exigido um alto grau de detalhe para obter um alto - grau de foto-realismo - exigindo a renderização de uma grande quantidade de polígonos e texturas de alta resolução, potencialmente com os polígonos  15 e/outexturas mudando em uma base quadro a quadro quando a face se move.
Quando um cenário com grande quantidade de polígonos com texturas detalhadas muda rapidamente, o PC ou console de jogo que supor- ta o jogo pode não ter suficiente RAM para armazenar dados de polígonos e textura suficientes para a quantidade requerida de quadros de animação ge- rados no segmento do jogo.
Adicionalmente, o único controlador ótico ou único controlador de disco tipicamente disponível em um PC ou console de = jogo é usualmente muito mais lento do que a RAM, e tipicamente não pode - manter-se com a taxa de dados máxima que a GPU pode aceitar na renderi- zação de polígonos e texturas.
Os jogos atuais tipicamente carregam a mai- or parte dos polígonos e texturas dentro da RAM, o que significa que um da- do cenário é grandemente limitado em complexidade e duração pela capaci- dade da RAM.
No caso de animação facial, por exemplo, isto pode limitar um PC ou uma console de jogo a ou uma face de resolução baixa que não é foto-realista ou a uma face foto-realista que somente pode ser animada por uma quantidade limitada de quadros, antes de o jogo pausar, e carregar po- lígonos e texturas (e outros dados) para mais quadros.
i , Í Assistir a uma barra de progresso se mover lentamente pela tela ! quando um PC ou console exibe uma mensagem similar a "Carregando..." é aceito como um problema inerente pelos usuários atuais de jogos de vídeo | complexos.
O atraso enquanto o próximo cenário carrega do disco ("disco" F ! 5 —nestedocumento, a menos que qualificado de outra forma, refere-se à mídia - Í ótica ou magnética não volátil, bem como a mídia não disco tal como uma | memória "Flash" de semicondutor) pode demorar diversos segundos ou mesmo diversos minutos.
Isto é uma perda de tempo e pode ser muito frus- trante para quem está jogando.
Como discutido previamente, grande parte outodoo atraso pode ser devido ao tempo para carregar polígono, texturas . e outros dados de um disco, mas também pode ser o caso de que parte do tempo é gasto enquanto o processador e/ou GPU no PC ou console prepara bh dados para o cenário.
Por exemplo, um jogo de vídeo de futebol pode permi- tir que os jogadores escolham entre uma grande quantidade de jogadores, times, estádios e condições climáticas.
Assim, dependendo de qual combi- nação particular é escolhida, diferentes polígonos, texturas e outros dados (coletivamente "objetos") podem ser requeridos para o cenário (por exemplo, times diferentes tem cores e padrões diferentes em seus uniformes). Pode ser possível enumerar muitas ou todas as várias permutações e pré- computar muitos ou todos os objetos antecipadamente e armazenar os obje- tos no disco usado para armazenar o jogo.
Mas se a quantidade de permu- tações é grande, a quantidade de armazenamento requerida para todos os ii objetos pode ser muito grande para caber no disco (ou muito pouco prático : ser carregada). Portanto, os sistemas de PC e console existentes são tipi- —camente são restritos tanto na complexidade como duração do jogo de da- dos cenários e sofrem com longos tempos de carregamento para cenários complexos.
Outra limitação significativa com sistemas de jogos de vídeo e sistemas de software de aplicação da técnica anterior é que os mesmos es- tão cada vez mais usando grandes bancos de dados, por exemplo, de obje- tos 3D tais como polígonos e texturas, que precisam ser carregados para o PC ou console de jogo para processamento.
Como discutido acima, estes
| bancos de dados podem demorar um longo tempo para carregar quando | armazenados localmente em um disco.
Tempo de carregamento, entretanto, é usualmente muito mais severo se o banco de dados é armazenado em uma localização remota e é acessado através da Internet.
Em uma situação como esta isto pode levar minutos, horas ou mesmo dias para baixar um ! grande banco de dados.
Adicionalmente, estes bancos de dados são fre- Í quentemente criados com grande custo (por exemplo, um modelo 3D de uma veleiro com mastros altos para uso em um jogo, filme, ou documentário histórico) e são destinados a venda para o usuário final local.
Entretanto, o : banco de dados tem o risco de ser pirateado uma vez que o mesmo tenha sido baixado para o usuário local.
Em muitos casos, um usuário quer baixar um banco de dados simplesmente para o propósito de avaliá-lo para ver se o " mesmo se adéqua as necessidades do usuário (por exemplo, se uma roupa 3D para um personagem de jogo tem uma aparência ou aspecto satisfatório À 15 quando o usuário realiza um movimento particular). Um tempo de carrega- mento longo pode ser desencorajante para o usuário avaliar o banco de da- dos 3D antes de decidir fazer uma compra.
Problemas similares ocorrem em MMOGs, particularmente com jogos que permitem que os usuários utilizem personagens cada vez mais personalizados.
Para um PC ou console de jogo exibir um personagem o mesmo precisa ter acesso ao banco de dados de geometria 3D (polígonos, texturas, etc.) bem como aos comportamentos (por exemplo, se o persona- - gem tem um escudo, se o escudo é forte o bastante para desviar uma lança - ou não t) para aquele.
Tipicamente, quando um MMOG é jogado pela primei- ra vez por um usuário, uma grande quantidade de bancos de dados para personagens já estão disponíveis com a cópia inicial do jogo, que está dis- ponível localmente no disco ótico do jogo ou baixado para um disco.
Mas, conforme o jogo progride, se o usuário encontra um personagem ou objeto cujo banco de dados não está disponível localmente (por exemplo, se outro usuário tiver criado um personagem personalizado), antes que aquele per- sonagem ou objeto possam ser exibidos, seu banco de dados tem que ser baixado.
Isto pode resultar em um grande atraso do jogo.
Dada à sofisticação e complexidade dos jogos de vídeo, outro | desafio para os desenvolvedores e publicadores de jogos de vídeo com as i consoles de jogos da técnica anterior, é que o mesmo frequentemente leva 2 L a 3 anos para desenvolver um jogo de vídeo ao custo de dezenas de mi- | ' 5 lhõesde dólares.
Dado que novas plataformas de console de jogos de vídeo ç | são introduzidas a uma taxa de aproximadamente uma vez a cada cinco a- | nos, os desenvolvedores de jogos precisam iniciar o trabalho de desenvol- vimento naqueles jogos anos antes da liberação da nova console de jogos a fim de ter os jogos de vídeo disponíveis concorrentemente quando a nova E plataforma for liberada.
Diversas consoles de fabricantes concorrentes são algumas vezes liberadas quase ao mesmo tempo (por exemplo, dentro de um ano ou dois uma da outra), mas o que resta para ser visto é a populari- dade de cada console, por exemplo, qual console produzirá as maiores ven- das de software de jogos de vídeo.
Por exemplo, em um recente ciclo de É 15 consoles, o Microsoft XBox 360, o Sony Playstation 3, e o Nintendo Wii fo- ram programados para serem introduzidos aproximadamente na mesma ja- nela de tempo.
Mas anos antes da introdução os desenvolvedores de jogos tiveram que essencialmente que "fazer suas apostas" em quais plataformas de console teriam mais sucesso do que outras e destinar seus recursos de desenvolvimento adequadamente.
Companhias de produção de filmes tam- bém têm que dividir seus recursos de produção limitados baseado no que eles estimam ser o provável sucesso de um filme muito antecipadamente a Fr liberação do filme.
Dado o nível crescente de investimentos exigidos para - jogos de vídeo, a produção de jogos está cada vez mais ficando semelhante à produção de filmes, e as companhias de produção de jogos rotineiramente dedicam seus recursos de produção baseados em suas estimativas de su- cesso futuro de um jogo de vídeo particular.
Mas, diferente das companhias de filmes, esta aposta não é simplesmente baseada no sucesso da própria produção; em vez disso, é pressuposta no sucesso que a console de jogo em que o jogo é destinado a rodar.
A liberação do jogo em múltiplas conso- les de uma vez pode mitigar o risco, mas este esforço adicional aumenta o custo, e frequentemente atrasa a liberação real do jogo.
Í Software aplicativo e ambientes de usuário em PCs estão se | tornando mais intensivos, dinâmicos e interativos computacionalmente, não apenas para torná-los mais atrativos visualmente para os usuários, mas também para torná-los mais úteis e intuitivos.
Por exemplo, tanto o novo sis- ; 5 tema operacional Windows Vista " e sucessivas versões do sistema opera- j ! cional Macintoshº incorporam efeitos de animação visual.
Ferramentas gráfi- | cas avançadas tais como MayaTM da Autodesk, Inc., proporcionam recursos de renderização e animação em 3D muito sofisticados que pressiona os limi- tes das CPUS e GPUs do estado da técnica.
Entretanto, as exigências com- —putacionais destas novas ferramentas cria uma quantidade de questões téc- nicas para usuários e desenvolvedores de software destes produtos.
Uma vez que a exibição visual de um sistema operacional (SO) a tem que trabalhar em uma ampla variedade de classes de computadores -- incluindo computadores de gerações anteriores não mais vendidos, mas que É 15 ainda são atualizáveis com o novo SO — as exigências gráficas do SO são limitadas em um alto grau por um mínimo denominador comum dos compu- tadores para os quais o SO é direcionado, o que tipicamente inclui computa- dores que não incluem uma GPU.
Isto limita severamente a configuração gráfica do SO.
Além disso, computadores portáteis alimentados por bateria (por exemplo, computadores de colo(laptops)) limitam a configuração de exi- bição visual uma vez que alta atividade computacional em uma CPU ou GPU tipicamente resulta em maior consumo de energia a menor vida da bateria. 7 Computadores portáteis tipicamente incluem softwares que reduzem ativida- , de do processador automaticamente para reduzir o consumo de energia —quandoo processador não é utilizado.
Em alguns modelos de computadores o usuário pode reduzir a atividade do processador manualmente.
Por exem- plo, o computador de colo VGN-SZ280P da Sony contém um comutador chamado "Stamina" em um lado (para baixa performance, mais vida de bate- ria) e "Speed" do outro lado (para alta performance, menos vida de bateria). Um OS rodandoem um computador portátil precisa ser capaz de funcionar adequadamente mesmo no caso de o computador estar rodando com uma fração de sua capacidade de performance de pico.
Portanto, a performance
| gráfica de OS frequentemente permanece muito abaixo da capacidade com- | putacional disponível no estado da técnica.
Aplicações de alta qualidade computacionalmente intensivas como Maya são frequentemente vendidas com a expectativa de que as | | 5 mesmas serão usadas em PCs de alta performance.
Isto tipicamente estabe- LD lece um mínimo denominador comum de exigência de performance muito ! mais alto, mais caro e menos portátil.
Como consequência, estas aplicações tem um público alvo muito mais limitado do que um SO de propósito geral (ou aplicação de produtividade de propósito geral, tal como Microsoft Office) ; etipicamente vende volume muito menor do que software de SO ou software aplicativo de propósito geral.
A audiência potencial é limitada adicionalmente porque muitas vezes é difícil para um futuro usuário testar antecipadamente ' estas aplicações computacionalmente intensivas.
Por exemplo, supondo que um estudante quer aprender como usar o Maya ou um comprador potencial É 15 que já tem conhecimento sobre estas aplicações quer testar o Maya antes de fazer o investimento na compra (o que também pode envolver a compra de um computador de alta qualidade capaz de rodar o Maya). Embora tanto o estudante como o comprador potencial possam baixar, ou obter uma cópia de mídia física de uma versão de demonstração do Maya, se eles não tive- rem um computador capaz de rodar o Maya em todo o seu potencial (por exemplo, manipulando um cenário 3D complexo), então eles serão incapa- zes de fazer uma avaliação completa do produto.
Isto limita substancialmen- = te a audiência para estas aplicações de alta qualidade.
Isto também contribui ta para um alto preço de venda uma vez que o custo de desenvolvimento é —amortizado através de uma quantidade muito menor de compras do que a- quelas de uma aplicação de propósito geral.
Aplicações de alto preço também criam mais incentivo para indi- víduos e empresas usarem cópias piratas do software aplicativo.
Como re- sultado o software aplicativo de alta qualidade sofre de pirataria excessiva, a despeito dos significativos esforços feitos pelos publicadores de tais softwa- res para mitigar esta pirataria através de várias técnicas.
Ainda, mesmo quando usando aplicações de alta qualidade pirateadas, os usuários não
| podem remediar a necessidade de investimento em PCs caros do estado da Í técnica para rodar as cópias piratas.
Assim, embora eles possam obter o uso de um software aplicativo por uma fração de seu preço de venda real, ainda é requerido que os usuários de software pirateado comprem ou obtenham umbPCcõcaro afim de utilizar completamente a aplicação.
E O mesmo é verdade para usuários jogos de vídeo de alta per- formance pirateados.
Embora piratas possam ter os jogos por uma fração de seu preço real ainda é requerido que eles comprem hardware de computa- ção caro (por exemplo, um PC equipado com uma GPU, ou uma console de F jogo de vídeo de alta qualidade tal como XBox 360) necessário para jogar o jogo adequadamente.
Dado que jogos de vídeo são tipicamente um passa- tempo. para os consumidores o custo adicional para um sistema de jogo de vídeo de alta qualidade pode ser proibitivo.
Esta situação é pior em países (por exemplo, China) onde a renda média anual dos trabalhadores atualmen- f 15 teé muito baixa relativa àquela dos Estados Unidos da América.
Como re- sultado, uma porcentagem muito menor da população possui um sistema de jogo de vídeo system de alta qualidade ou um PC de alta qualidade.
Nestes países, "Internet cafés", nos quais os usuários pagam uma taxa para usar um computador conectado à Internet, são muito comuns.
Frequentemente, estes Internet cafés têm modelos mais velhos ou PCs básicos sem caracte- rísticas de alta performance, tal como uma GPU, o que poderia de outra for- ma permitir que os jogadores jogassem jogos de vídeo de computação in- = tensiva.
Este é um fator chave no sucesso dos jogos que rodam em PCs " básicos, tal como o "World of Warcraft" da Vivendi que é um grande suces- sona China, e comumente jogado em Internet cafés naquele país.
Ao con- trário, é muito menos provável que um jogo computacionalmente intensivo, tal como o "Second Life" possa ser jogado em um PC instalado em um Inter- net café chinês.
Estes jogos são virtualmente inacessíveis para usuários que apenas têm acesso a PCs de baixa performance em Internet cafés.
Também existem barreiras para usuários que estão consideran- do a compra de um jogo de vídeo gostariam de primeiro tentar uma versão de demonstração do jogo baixando uma demonstração através da Internet para sua residência.
Uma demonstração de jogo de vídeo é frequentemente | uma versão de pleno direito do jogo com algumas características não habili- tadas, ou com limites determinados na quantidade a ser jogada.
Isto pode envolver um longo processo (as vezes horas) para baixar gigabytes de da- j 5 dos antes que o jogo possa ser instalado e executado ou em um PC ou em E | uma console.
No caso de um PC, Isto também envolve solucionar quais a- Í cionadores especiais são necessários (por exemplo, acionadores DirectX ou OpenGL) para o jogo, baixar a versão correta, instalá-las, e então determinar Ee se o PC é capaz de jogar o jogo.
Esta última etapa pode envolver determinar ; seoPC tem capacidade de processamento suficiente (CPU e GPU), RAM suficiente, e um OS compatível (por exemplo, alguns jogos rodam no Win- dows XP, mas não no Vista). Portanto, após um longo processo de tentativa f para rodar uma demonstração de jogo de vídeo demo, o usuário pode final- mente descobrir que a demonstração do jogo de vídeo não é possível de ser É 15 jogada, dada a configuração do PC do usuário.
Pior, uma vez que o usuário tenha baixado novos acionadores a fim de testar a demonstração, estes a- cionadores podem ser incompatíveis com outros jogos ou aplicações que o usuário usa regularmente no PC, portanto a instalação de uma demonstra- ção pode tornar inoperáveis jogos ou aplicações operáveis previamente.
Es- tas barreiras não são apenas frustrantes para o usuário, mas as mesmas criam barreiras para os publicadores de software de jogo de vídeo e desen- volvedores de jogos de vídeo comercializarem seus jogos. e Outro problema que resulta em ineficiência econômica tem a ver . com o fato de que o dado PC ou console de jogo é usualmente projetado para acomodar um certo nível de exigência de performance para aplicações e/ou jogos.
Por exemplo, alguns PCs têm mais ou menos RAM, CPUs mais rápidas ou mais lentas, e GPUs mais rápidas ou mais lentas, se é que têm uma GPU.
Alguns jogos ou aplicações tiram vantagem de toda a potência computacional de um dado PC ou console, enquanto outros jogos ou aplica- ções não.
Se uma aplicação ou jogo de escolha do usuário fica aquém da capacidade de pico de performance do PC ou console local, então o usuário pode ter desperdiçado dinheiro no PC ou console para características não utilizadas. No caso de uma console, o fabricante da console pode ter pago ! mais do que o necessário para subsidiar o custo da console. Outro problema que existe na compra e venda e satisfação de jogos de vídeo envolve permitir que um usuário assista outros jogando os d 5 jogos antes de o usuário arriscar a compra daquele jogo. Existem algumas abordagens da técnica anterior para a gravação de jogos de vídeo para re- | : prisar em um momento posterior. Por exemplo, a Patente US de Nº !
5.558.339 ensina a gravar informação de estado de jogo, incluindo ações do controlador do jogo, durante a execução do jogo no computador cliente do É jogo de vídeo (pertencente ao mesmo usuário ou diferente). Esta informação de estado pode ser usada em um momento posterior para reprisar alguma ou toda a ação do jogo em um computador cliente do jogo de vídeo (por e- i xemplo, PC ou console). Uma questão significativa com esta abordagem é que para um usuário visualizar o jogo gravado, o usuário tem que possuir um É 15 computador cliente do jogo de vídeo capaz de jogar o jogo e tem que ter a aplicação do jogo de vídeo rodando naquele computador, de modo que a execução do jogo é idêntica quando o estado do jogo gravado é reprisado. Além disso, a aplicação de jogo de vídeo tem que ser escrita de uma tal for- ma que não exista possibilidade de diferença de execução entre o jogo gra- vadoe ojogo reproduzido. Por exemplo, os gráficos de jogo são geralmente computados em uma base quadro a quadro. Para muitos jogos, a lógica do jogo algumas Fm vezes pode levar mais ou menos do que um tempo de quadro para computar Ea os gráficos exibidos para o próximo quadro, dependendo de se a cena é par- ticularmente complexa, ou se existem outros atrasos que desaceleram a e- xecução (por exemplo, em um PC, pode estar rodando outro processo que tire ciclos de CPU das aplicações de jogos). Em um jogo como este, um quadro "limite" que é computado e pouco menos do que um tempo de qua- dro (digamos uns poucos ciclos de CPU a menos) pode ocorrer eventual- mente. Quando aquele cenário é computado novamente usando a informa- ção exata do mesmo estado do jogo, isto pode facilmente tomar alguns ci- clos de CPU a mais do que um tempo de quadro (por exemplo, se um bar-
| ramento interno de CPU está ligeiramente fora de fase com o barramento de DRAM e o mesmo introduz uns poucos tempos de ciclo de CPU de atraso, | mesmo se não existir grande atraso de outro processo tomando milissegun- dos de tempo de CPU do processamento do jogo). Portanto, quando o jogo [ ) 5 é reproduzido o quadro é calculado em dois tempos de quadro em vez de | | um único tempo de quadro.
Alguns comportamentos são baseados em como | ó geralmente o jogo calcula um novo quadro (por exemplo, quando o jogo busca a entrada dos controladores de jogo.
Enquanto o jogo é jogado, esta assa discrepância na referência de tempo para comportamentos diferentes não impacta a jogabilidade, mas isto pode resultar no jogo reproduzido produzir um resultado diferente.
Por exemplo, se uma balística de bola de basquete é calculada a uma taxa de 60 fps estável, mas a entrada do controlador de À jogo é amostrada baseada na taxa de quadros computados, a taxa de qua- dros computados pode ser de 53 fps quando o jogo foi gravado, mas 52 fps quando o jogo é reprisado, o que pode fazer uma diferença entre se a bola de basquete é bloqueada no trajeto para dentro da cesta ou não, resultando em uma saída diferente.
Portanto, usar o estado do jogo para gravar jogos de vídeo exige um projeto de software de jogo muito cuidadoso para garantir que a reprise, usando a informação de estado de jogo, produza exatamente amesma saída.
Outra abordagem da técnica anterior para gravar jogos de vídeo é simplesmente gravar a saída de vídeo de um PC ou sistema de jogo de e vídeo (por exemplo, para um gravador de VCR, DVD, ou para uma placa de " captura de vídeo em um PC). O vídeo pode então ser retornado e reprisado, ou alternativamente, o vídeo gravado carregado para a Internet, tipicamente após ser comprimido.
Uma desvantagem desta abordagem é que quando uma sequência de jogo 3D é reproduzida, o usuário é limitado a ver a se- quência do único ponto de vista em que a sequência foi gravada.
Em outras palavras, o usuário não pode mudar o ponto de vista do cenário.
Adicionalmente, quando vídeo comprimido de uma sequência de jogo gravada jogada em um PC residencial ou console de jogo é disponibili- zada para outros usuários na Internet, mesmo se o vídeo for comprimido em
| tempo real, pode ser impossível carregar o vídeo comprimido em tempo real | para a Internet.
A razão é porque muitas residências no mundo conectadas a Internet têm conexões de banda larga altamente assimétricas (por exemplo, DSL e modems a cabo tipicamente tem uma banda largura de banda de flu- | 5 xodedescidamuitomais alta do que a largura de banda de fluxo de subida). F ij Sequências de vídeo de alta resolução comprimidas frequentemente têm i i larguras de banda mais altas do que a capacidade de largura de banda de fluxo de subida da rede, tornando impossível o carregamento em tempo re- ns al.
Portanto, haveria um atraso significativo após a sequência de jogo ser : jogada (Talvez minutos ou mesmo horas) antes que outro usuário na Internet fosse capaz de visualizar o jogo.
Embora este atraso seja tolerável em cer- tas situações (por exemplo, para assistir o desempenho de um jogador que ocorreu em um momento anterior), o mesmo elimina a possibilidade de as- sistir a um jogo ao vivo (por exemplo, um torneio de basquete jogado por jogadores campeões) ou com um recurso de "reapresentação instantânea" quando o jogo é jogado ao vivo.
Outra abordagem da técnica anterior permite que um espectador com um receptor de televisão assista a jogos ao vivo, mas apenas sob o controle da equipe de produção da televisão.
Alguns canais de televisão tan- tonosEUA como em outros países fornecem canais de visualização de jo- gos de vídeo onde o público de espectadores de televisão pode assistir cer- tos usuários de jogos de vídeo (por exemplo, jogadores de alta classificação e jogando torneios) em canais de jogos de vídeo.
Isto é realizado tendo a saí- - da de sistemas de jogo de vídeo (PCs e/ou consoles) transmitida dentro do equipamento de distribuição e processamento para o canal de televisão.
Isto não é diferente de quando o canal de televisão está difundindo um jogo de basquete ao vivo no qual diversas câmeras fornecem transmissões ao vivo de diferentes ângulos em volta da quadra de basquete.
O canal de televisão então é capaz de usar seu equipamento de processamento e efeitos de áu- —dio/vídeo para manipular a saída de vários sistemas de jogos de vídeo.
Por exemplo, o cana! de televisão pode sobrepor texto sobre o vídeo de um jogo de vídeo que indica o status de vários jogadores (exatamente como os
| mesmos podem sobrepor texto durante um jogo de basquete ao vivo), e o | canal de televisão pode sobrepor áudio de um comentarista que pode discu- tir a ação que está ocorrendo durante os jogos.
Adicionalmente, a saída do jogo de vídeo pode ser combinada com câmeras de gravação de vídeo dos | 5 jogadores reais dos jogos (por exemplo, mostrando suas reações de respos- L ! ta ao jogo). Í Um problema com esta abordagem é que estas transmissões de vídeo ao vivo tem que estar disponíveis para o equipamento de distribuição e processamento de vídeo do canal de televisão em tempo real a fim de ter a emoção de uma difusão ao vivo.
Entretanto, como discutido anteriormente, frequentemente isto é impossível quando o sistema de jogo de vídeo está rodando de residência, especialmente se parte da difusão inclui vídeo ao vivo de uma câmera que captura vídeo do mundo real do jogador.
Adicio- nalmente, em uma situação de torneio, existe uma preocupação de que um É 15 jogador em sua residência possa modificar o jogo e trapacear, como descrito previamente.
Por estas razões, estas difusões de jogo de vídeo em canais de televisão são frequentemente organizadas com jogadores e sistemas de jogos de vídeo juntos em uma localização comum (por exemplo, em um es- túdio de televisão ou em uma arena) onde o equipamento de produção de televisão possa receber transmissões de vídeo dos múltiplos sistemas de jogo de vídeo e potencialmente de câmeras ao vivo.
Embora estes canais de televisão de jogo de vídeo da técnica ht! anterior possam fornecer uma apresentação muito emocionante para o pú- * blico espectador de televisão que é uma experiência semelhante a um even- tode esporte ao vivo, por exemplo, com os jogadores do jogo de vídeo apre- sentados como "atletas", tanto em termos de suas ações no mundo do jogo de vídeo world, como em termos de suas ações no mundo real, estes siste- mas de jogos de vídeo são frequentemente limitados a situações onde os jogadores estão em grande proximidade física uns aos outros.
E, uma vez que canais de televisão são difundidos, cada canal de televisão difundido pode mostrar apenas um fluxo de vídeo contínuo, que é selecionado pela equipe de produção do canal de televisão.
Devido a estas limitações e ao
| alto custo do tempo de difusão, equipamento de produção e equipes de pro- | | dução, estes canais de televisão tipicamente mostram apenas jogadores de ] alta classificação jogando em torneios de alto nível. | Adicionalmente, um dado canal de televisão difundindo uma i- 7 5 — magem de tela cheia de um jogo de vídeo para todo o público espectador da f televisão mostra apenas um jogo de vídeo por vez.
Isto limita severamente | as escolhas de um espectador da televisão.
Por exemplo, um espectador de í televisão pode não estar interessado no(s) jogo(s) apresentados em um da- ; do momento.
Outro espectador pode estar interessado apenas em assistir o jogo jogado por um jogador particular que não é apresentado pelo canal de televisão em um dado momento.
Em outros casos, um espectador pode es- tar interessado apenas em assistir como um jogador experiente se comporta em um nível particular em um jogo.
Outros espectadores podem ainda que- rer controlar o ponto de vista pelo qual um jogo é visto, que é diferente da- quele escolhido pelo time da produção, etc.
Em resumo, um espectador de televisão pode ter uma miríade de preferências quando assiste jogos de vídeo que não são acomodadas pela difusão particular de uma rede de tele- visão, mesmo se diversos canais de televisão diferentes estiverem disponí- veis.
Por todas as razões mencionadas acima, canais de televisão de jogo de vídeo da técnica anterior têm limitações significativas na apresentação de jogos de vídeo para espectadores de televisão.
Outros problemas dos sistemas de jogos de vídeo e sistemas de - software aplicativo da técnica anterior é que os mesmos são complexos, e - comumente sofrem com erros, falhas e/ou comportamentos não intencionais eindesejados (coletivamente "erros"). Embora jogos e aplicativos tipicamen- te passem por um processo de depuração e ajuste fino (frequentemente chamado "Certificação de Qualidade de Software" ou SQA) antes da libera- ção, quase invariavelmente uma vez que o jogo ou aplicação é liberado para um público amplo no campo os erros surgem.
Infelizmente, é difícil para o desenvolvedor de software identificar e rastrear muitos dos erros após a libe- ração.
Pode ser difícil para desenvolvedores de software ficarem cientes dos erros.
Mesmo quando eles aprendem sobre um erro, pode haver apenas
| uma quantidade limitada de informação disponível para eles identificarem o | que causou o erro.
Por exemplo, um usuário pode ligar para m alinha de | serviço de cliente para desenvolvedor do jogo e deixar uma mensagem ex- pondo que quando joga o jogo, a tela começou a piscar, então mudou para d 5 uma cor sólida azul eo PC congelou.
Isto fornece muito pouca informação ! útil para o time de SQA rastrear um erro.
Alguns jogos ou aplicações que i | são conectados em linha algumas vezes fornecem mais informação em cer- tos casos.
Por exemplo, um processo "cão de guarda" pode ser usado algu- mas vezes para monitorar "falhas" no jogo ou aplicação.
O processo cão de guarda pode coletar estatísticas sobre o status do processo do jogo ou apli- cações (por exemplo, o status do uso da ilha de memória, quão longe o jogo ou aplicações têm progredido, etc.) quando o mesmo falha e em seguida carregar aquela informação para o time de SQA através da Internet.
Mas em um jogo ou aplicação complexo, esta informação pode demorar muito tempo E 15 para decifrar a fim de determinar com precisão o que o usuário estava fa- zendo no momento da falha.
Mesmo assim, pode ser impossível determinar qual sequência de eventos levou à falha.
Ainda outro problema associado com PCs e consoles de jogos é que os mesmos são muito sujeitos a problemas no serviço que incomodam muitoo consumidor.
Problemas de serviço também impactam o fabricante do PC ou console de jogo uma vez que eles tipicamente eles são solicitados a enviar uma caixa especial para despachar com segurança o PC ou conso- nr le, e então incorrem no custo do conserto se o PC ou console está na garan- r tia.
O publicador do jogo ou software aplicativo também pode ser impactado —pelaperdade vendas (ou uso do serviço em linha) pelos PCs e/ou consoles ficando em estado de reparo.
A figura 1 ilustra um sistema de jogos de vídeo da técnica ante- rior tal como um Sony Playstationº 3, Microsoft Xbox 360º, Nintendo Wii", computador pessoa baseado em Windows ou Apple Macintosh. cada um destes sistemas inclui uma unidade central de processamento (CPU) para executar código de programa, tipicamente uma unidade de processamento gráfica (GPU) para executar operações gráficas avançadas, e múltiplas for-
| mas de entrada/saída (I/O) para se comunicar com dispositivos e usuários i externos.
Por simplicidade, estes componentes são combinados como uma única unidade 100. O sistema de jogos da técnica anterior da figura 1 tam- bém é mostrado incluindo um controlador de mídia ótica 104 (por exemplo, um controlador de DVD-ROM); um controlador de disco rígido 103 para ar- t Í mazenar código de programa e dados de jogo de vídeo; uma conexão de | rede 105 para jogar jogos multijogadores, para descarregar jogos, correções, demonstrações ou outra mídia; uma memória de acesso randômico (RAM) 101 para armazenar código de programa sendo correntemente executado pelaCPU/GPU 100; um controlador de jogo 106 para receber comandos de entrada do usuário durante o jogo; e um dispositivo de exibição 102 (por e- xemplo, um SDTV /HDTV ou um monitor de computador). f O sistema da técnica anterior mostrado na figura 1 sofre de di- versas limitações.
Primeiro, controladores óticos 104 e controladores de Í 15 disco rígido 103 tendem a ter velocidades de acesso muito mais lentas quando comparados àquela da RAM 101. Quando trabalha diretamente da RAM 101, a CPU/GPU 100 pode, na prática, processar muito mais polígonos por segundo do que é possível quando o código de programa e dados são lidos diretamente a partir do controlador de disco rígido 103 ou controlador ótico 104 devido ao fato de que a RAM 101 tem geralmente uma largura de banda muito maior e não sofre com atrasos relativamente longos de busca dos mecanismos de disco.
Mas apenas uma quantidade limitada de RAM é Pr fornecida nestes sistemas da técnica anterior (por exemplo, 256 a . 512Mbytes). Portanto, uma sequência "Carregando..." na qual a RAM 101 é periodicamente carregada com dados para o próximo cenário do jogo de vídeo é requerida frequentemente.
Alguns sistemas tentam sobrepor o carregamento do código de programa concorrentemente com a execução do jogo, mas isto pode ser feito apenas quando existe uma sequência conhecida de eventos (por e- —xemplo,se o carro está percorrendo uma estrada, a geometria para as edifi- cações que se aproximam nos lados da estrada pode ser carregada enquan- to o carro está viajando). Para mudanças complexas e/ou rápidas, este tipo de sobreposição usualmente não funciona.
Por exemplo, no caso onde o | usuário está no meio de uma batalha e a RAM 101 está completamente pre- enchida com dados que representam objetos dentro da visão naquele mo- mento, se o usuário move a visão rapidamente para à esquerda para ver — objetos que não estão atualmente carregados na RAM 101, resultará em | uma descontinuidade na ação uma vez que não existe tempo suficiente para Á : carregar os novos objetos do controlador de disco rígido 103 ou mídia ótica 104 para a RAM 101. Outro problema com o sistema da figura 1 surge devido à limita- . ções na capacidade de armazenamento dos controladores de disco rígido 103 e mídia ótica 104. Embora dispositivos de armazenamento possam ser fabricados com uma capacidade de armazenamento relativamente grande (por exemplo, 50 gigabytes ou mais), os mesmos ainda não fornecem capa- cidade de armazenamento suficiente para certos cenários encontrados nos E 15 jogos de vídeo atuais.
Por exemplo, como mencionado previamente, jogo de vídeo de futebol pode permitir que o usuário escolha dentre dezenas de ti- mes, jogadores e estádios por todo o mundo.
Para cada time, cada jogador e cada estádio são necessários uma grande quantidade de mapas de textura e mapas de ambiente para caracterizar as superfícies 3D no mundo (por e- —xemplo, cada time tem uma camiseta única que requer um mapa de textura único). Uma técnica usada para endereçar este último problema é o jo- m go pré-computar mapas de textura e ambiente uma vez que os mesmos são ' selecionados pelo usuário.
Isto pode envolver uma quantidade de processos —computacionalmente intensivos, incluindo a descompressão de imagens, mapeamento 3D, sombreamento, organização de estruturas de dados, etc.
Como resultado, pode haver um atraso para o usuário enquanto o jogo de vídeo está realizando estes cálculos.
Uma forma de reduzir estes atrasos, em princípio, é executar todas estas computações — incluindo toda permuta- — ção de time, lista de jogadores, e estádio — quando o jogo foi originalmente desenvolvido.
A versão liberada do jogo deve então incluir todos estes dados pré-processados armazenados na mídia ótica 104, ou em um ou mais servi-
| dores na Internet com apenas os dados pré-processados selecionados para | um dado time, lista de jogadores, seleção de estádios descarregados atra- vês da Internet para o controlador de disco rígido 103 quando o usuário faz uma seleção.
Como um caso prático, entretanto, estes dados pré- carregados de todas as permutações possíveis para jogar o jogo podem fa- t i cilmente atingir terabytes de dados, que é muito mais do que a capacidade | dos dispositivos atuais de mídia ótica.
Além disso, os dados para um dado time, lista de jogadores, seleção de estádio podem ser facilmente centenas de megabytes de dados ou mais.
Com uma conexão de rede residencial de, "a digamos, 10Mbps, seria mais demorado descarregar estes dados através da conexão de rede 105 do que seria para computar os dados localmente.
Portanto, a arquitetura de jogo da técnica anterior mostrada na É figura 1 sujeita o usuário a atrasos significativos entre transições de cenários principais de jogos complexos.
Outro problema com a abordagem da técnica anterior tal como aquela mostrada na figura 1 é que ao longo dos anos os jogos de vídeo ten- dem a se tornar mais avançados e exigir mais capacidade de processamen- to da CPU/GPU.
Portanto, mesmo assumindo uma capacidade ilimitada de RAM, as exigências de hardware dos jogos de vídeo vai além do nível de pico da capacidade de processamento disponível nestes sistemas.
Como resultado, é requerido que os usuários atualizem seu hardware de jogos a cada poucos anos para manter o ritmo (ou jogar jogos mais novos com ní- - veis de qualidade mais baixo). Uma consequência da tendência de jogos de . vídeo cada vez mais avançados é que as máquinas para jogar jogos de víi- deo para uso doméstico são tipicamente ineficientes economicamente por- que seu custo normalmente é determinado pelas exigências da maior per- formance que o jogo pode suportar.
Por exemplo, um XBox 360 pode ser usado para jogar um jogo como "Gears of War", que demanda uma CPU, GPU de alta performance e centenas de megabytes de RAM, ou o XBox 360 —pode ser usado para jogar Pac Man, um jogo dos anos 1970s que requer apenas kilobytes de RAM e uma CPU de performance muito baixa.
Na ver- dade, um XBox 360 tem potência computacional suficiente para hospedar muitos jogos simultâneos Pac Man. j Máquinas de jogos de vídeo ficam tipicamente desligadas a mai- or parte das horas de uma semana.
De acordo com um estudo da Nielsen Entertainment de julho de 2006 dos jogadores ativos de 13 anos ou mais, na j 5 média, jogadores ativos gastam quatorze horas/semana jogando jogos de | vídeo na console, ou apenas 12% do total de horas de uma semana.
Isto i significa que a console de jogo de vídeo fica ociosa 88% do tempo, o que é um uso ineficiente de um recurso caro.
Isto é particularmente significativo F dado que as consoles de jogos frequentemente são subsidiadas pelos fabri- cantes para baixar o preço de compra (com a expectativa de que o subsídio será recebido de volta pelos direitos de uso de futuras compras de software de jogos de vídeo). h Consoles de jogos de vídeo também incorrem em custos associ- ados com quase todos dispositivos eletrônicos para consumidor.
Por exem- É 15 plo, a eletrônica e mecanismos precisam ser alojados em um gabinete.
O fabricante precisa oferecer um serviço de garantia.
O varejista que vende o sistema precisa receber uma margem em cada venda do sistema e /ou na venda do software do jogo de vídeo.
Todos estes fatores adicionam custo à console de jogo de vídeo, que têm que ser subsidiados pelo fabricante, re- passado para o consumidor, ou ambos.
Adicionalmente, a pirataria é um problema importante para a in- dústria de jogos de vídeo.
Os mecanismos de segurança utilizados em virtu- - almente a maior parte dos sistemas de jogos de vídeo têm sido "quebrados" r ao longo dos anos, resultando em uma cópia não autorizada de jogos de vídeo.
Por exemplo, o sistema de segurança do Xbox 360 foi quebrado em julho de 2006 e agora os usuários são capazes de descarregar cópias ilegais em linha.
Jogos que são descarregáveis (por exemplo, jogos para PC ou Mac) são particularmente vulneráveis a pirataria.
Em certas regiões do mun- do onde a pirataria é fracamente policiada não existe essencialmente ne- —nhum mercado viável para software de jogo de vídeo individual porque os usuários podem comprar cópias pirateadas tão facilmente como cópias le- gais por uma mínima fração do custo.
Também, em muitas partes do mundo
| o custo de uma console de jogo é um percentual tão alto da renda que | mesmo que a pirataria fosse controlada, poucas pessoas poderiam ter um sistema de jogos do estado da técnica.
Adicionalmente, o mercado de jogos usados reduz venda para a | 5 indústria de jogos de vídeo.
Quando um usuário cansa de um jogo, ele pode T i vender o jogo para uma loja que irá revender o jogo para outros usuários. | Esta prática não autorizada mas comum reduz significativamente as vendas de publicadores de jogos.
De maneira similar, uma redução nas vendas da EA ordem de 50% ocorre comumente quando existe uma transição de platafor- maem um período de poucos anos.
Isto se dá porque os usuários param de comprar jogos para as plataformas antigas quando eles sabem que uma no- va plataforma está para ser liberada (por exemplo, quando o Playstation 3 ú estava próximo a ser liberado, os usuários pararam de comprar jogos para Playstation 2). Combinados, as perdas de vendas e sustos de desenvolvi À 15 mento aumentados associados as novas plataformas podem ter um impacto adverso muito significativo na lucratividade dos desenvolvedores de jogos.
Novos consoles de jogos também são muito caras.
O Xbox 360, o Nintendo Wii, e o Sony Playstation 3 são todos vendidos por centenas de dólares.
Sistemas de jogos de computador pessoal de alta potência podem custar até US$ 8.000. Isto representa um investimento significativo para os usuários, particularmente considerando que o hardware se torna obsoleto após uns poucos anos e o fato de que muitos sistemas são comprados para r crianças. r Uma abordagem para os problemas acima referenciados é de jogosem linha nos quais o código e dados de programa de jogo são hospe- dados em um servidor e entregues para as máquinas clientes sob demanda como vídeo comprimido e áudio transmitidos sobre uma rede de banda larga digital.
Algumas companhias tais como a G-Cluster a Finlândia (agora uma subsidiária da SOFTBANK Broadmedia japonesa) fornece estes serviços em linha atualmente.
Serviços similares de jogos têm se tornado disponíveis em redes locais, tais como aquelas de dentro de hotéis e oferecidas por prove- dores de televisão a cabo e DSL.
Um grande problema destes sistemas é o
| problema de latência, ou seja, o tempo que leva para o sinal se deslocar pa- ! ra e do servidor, que é tipicamente localizado em uma "estação transmisso- ra" do operador". Jogos de vídeo de ação rápida (também conhecidos como jogos de vídeo de "espasmo") requerem uma latência muito baixa entre o | ! 5 tempo que o usuário executa uma ação com o controlador de jogo e o tempo Í E em que a tela de exibição é atualizada mostrando o resultado da ação do ! | usuário.
A baixa latência é necessária para que o usuário tenha a percepção de que o jogo está respondendo "instantaneamente". Os usuários podem ser satisfeitos com diferentes intervalos de latência dependendo do tipo de jogo ' edo nível de conhecimento do usuário.
Por exemplo, 100 ms de latência podem ser toleráveis para um jogo casual lento (como gamão) ou um jogo de interpretação de papel (role playing game) de ação lenta, mas em jogos de ação rápida uma latência acima de 70 ou 80 ms pode fazer com que o usuário se saia pior no jogo, e portanto é inaceitável.
Por exemplo, em um : 15 jogo que requer tempo de reação rápido existe um forte declínio na precisão se a latência cresce de 50 para 100 ms.
Quando um servidor de jogo ou aplicação é instalado em um ambiente de rede controlado próximo, ou um onde o percurso de rede para o usuário é previsível e/ou pode tolerar picos de largura de banda, é muito maisfácil controlar a latência, tanto em termos de latência máxima como em termos de consistência da latência (por exemplo, de modo que o usuário observe um movimento uniforme a partir do fluxo contínuo de vídeo através = da rede). Este nível de controle pode ser alcançado entre uma estação de : transmissão de rede de TV a cabo para uma residência de assinante de TV acabo oude um escritório central de DSL para uma residência de assinante de DSL, ou em um ambiente de Rede de área Local (LAN) de m escritório comercial a partir de um servidor ou de um usuário.
Também, é possível ob- ter conexões ponto a ponto privadas de graduação especial entre empresas que tenham latência e largura de banda garantidas.
Mas em um sistema de jogo ou aplicação que hospeda jogos em um centro de servidores conectado a Internet em geral e então transmite vídeo comprimido para o usuário atra- vés de uma conexão de banda larga, a latência ocorre a partir de muitos fa-
| tores, resultando em limitações severas na implementação de sistemas da | técnica anterior.
Í Em uma residência conectada em banda larga típica, um usuário 1 pode ter um modem DSL ou a cabo para serviço de banda larga. Estes ser- 7 5 viçosde banda larga incorrem em latência de ida e volta de até 25 ms (e algumas vezes mais) entre a residência do usuário e a Internet em geral. Adicionalmente, existem latências no percurso de ida e volta que ocorrem do encaminhamento de dados através da Internet para um centro de servidores. A latência através da Internet varia baseada na rota que os dados percorrem enos atrasos em que os mesmos incorrem quando são encaminhados. Adi- cionalmente aos atrasos de encaminhamento, a latência de ida e volta tam- bém ocorre devido ao deslocamento à velocidade da luz através da fibra óti- ca que interconecta a maior parte da Internet. Por exemplo, para cada 1600 quilômetros (1000 milhas), são somados 22 ms na latência de ida e volta É 15 devido a velocidade da luz através da fibra ótica e outras sobrecargas.
Pode ocorrer latência adicional devido à taxa de dados dos da- dos transmitidos através da Internet. Por exemplo, se um usuário tem um serviço DSL que é vendido como "serviço DSL de 6Mbps", na prática, pro- vavelmente o usuário terá menos do que 5Mbps de capacidade de enlace de descida, e provavelmente verá a conexão degradar periodicamente devido a vários fatores tais como congestionamento durante horas de pico no Multi- plexador de Linha de Acesso de Assinante Digital (DSLAM). Uma questão ” similar pode ocorrer reduzindo a taxa de dados de um modem a cabo usado 7 para uma conexão vendida como "serviço de modem a cabo de 6Mbps" para muito menos do que, se existir um congestionamento no circuito de cabo coaxial local compartilhado através da vizinhança, ou em qualquer outro lo- cal na rede do sistema de modem a cabo. Se os pacotes de dados a uma taxa estável de 4Mbps são transmitidos em formato de sentido único em Protocolo de Datagrama de Usuário (UDP) a partir de um centro de servido- res através de tais conexões, se tudo estiver funcionando bem, os pacotes de dados passarão sem incorrer em latência adicional, mas se existir con- gestionamento (ou outros impedimentos) e estiverem disponíveis apenas 3,5
| Mbps para transmitir dados para o usuário, então em uma situação típica ou I | serão descartados pacotes, resultando dados perdidos, ou pacotes irão enfi- leirar no ponto de congestionamento, até que possam ser enviados, deste 7 modo introduzindo latência adicional.
Pontos diferentes de congestionamen- 7 5 totêm diferentes capacidades de enfileiramento para manter pacotes atra- | sados, assim em alguns casos os pacotes que não fazê-lo através do con- gestionamento são descartados imediatamente.
Em outros casos, alguns megabits de dados são enfileirados e eventualmente enviados.
Mas, em quase todos os casos, as filas em pontos de congestionamento têm limites 3 : 10 de capacidade, e uma vez que estes limites sejam excedidos, as filas irão transbordar e pacotes serão descartados.
Portanto, para evitar a ocorrência de latência adicional (ou pior, perda de pacotes), é necessário evitar exceder a capacidade da taxa de dados do servidor do jogo ou aplicação para o usuário.
Í 15 A latência também corre pelo tempo requerido para comprimir vídeo no servidor e descomprimir no dispositivo cliente.
A latência ocorre adicionalmente enquanto um jogo de vídeo está calculando o próximo qua- dro a ser exibido.
Os algoritmos de compressão de vídeo atualmente disponíi- veis sofrem ou de altas taxas de dados ou alta latência.
Por exemplo, JPEG em movimento é um algoritmo de compressão apenas intra-quadro com per- das que é caracterizado por baixa latência.
Cada quadro de vídeo é compri- mido independentemente de cada outro quadro de vídeo.
Quando um disposi- " tivo cliente recebe um quadro de vídeo de JPEG em movimento comprimido, " o mesmo pode imediatamente descomprimir o quadro e exibi-lo, resultando em baixalatência.
Mas devido a cada quadro ser comprimido separadamente, o algoritmo é incapaz de explorar similaridades entre quadros sucessivos, e como resultado algoritmos de compressão de vídeo apenas intra-quadro so- frem com taxas de dados muito altas.
Por exemplo, 60 fps (quadros por se- gundo) de vídeo JPEG em movimento 640x480 requerem 40Mbps (megabits — por segundo) ou mais de dados.
Estas altas taxas de dados para tais janelas de vídeo de baixa resolução seriam proibitivamente caras em muitas aplica- ções de banda larga (e certamente para a maior parte das aplicações basea-
| das em Internet). Adicionalmente, devido a cada quadro ser comprimido inde- | pendentemente, é provável que artefatos nos quadros que podem resultar das | perdas de compressão apareçam em diferentes lugares em quadros sucessi- ! vos.
Isto pode resultar em o que aparece para um espectador como artefatos | em movimento quando o vídeo é descomprimido. [ Á Outros algoritmos de compressão, tais como MPEG2, H.264 ou VC9 da Microsoft Corporation como são usados em configurações da técni- ca anterior, podem obter altas taxas de compressão, mas ao custo de alta latência.
Estes algoritmos usam compressão inter-quadro bem como intra- É 10 quadro.
Periodicamente, estes algoritmos executam uma compressão ape- nas intra-quadro de um quadro.
Este quadro é conhecido como o quadro chave (tipicamente referenciado como um quadro "I”). Então, estes algorit- É mos tipicamente comparam o quadro | tanto com quadros anteriores como com quadros sucessivos.
Em vez de comprimir os quadros anteriores e qua- E 15 —dros sucessivos independentemente, o algoritmo determina o que foi muda- do na imagem do e quadro | para os quadros anterior e sucessivo, e então armazena estas mudanças como o que são chamados quadros "B" para as mudanças que precedem o quadro | e quadros "P" para as mudanças que seguem o quadro |. Isto resulta em taxas de dados muito mais baixas do que a compressão apenas intra-quadro.
Mas, vem tipicamente através de um custo de maior latência.
Um quadro | é tipicamente muito maior do que um quadro B ou P (frequentemente 10 vezes maior), e como resultado, o mes- - mo é proporcionalmente mais demorado para transmitir a uma dada taxa. o Considerando, por exemplo, uma situação onde os quadros | são10Xo tamanho dos quadros B e P, e que existem 29 quadros B + 30 quadros P = 59 inter-quadros para cada intra-quadro |, ou 60 quadros no total para cada "Grupo de Quadros" (GOP). Assim, a 60 fps, existe 1 60- quadro GOP a cada segundo.
Supondo que um canal de transmissão tenha uma taxa de dados de aproximadamente 2Mbps.
Para obter a melhor quali- —dade de vídeo no canal, o algoritmo de compressão deve produzir um fluxo contínuo de dados de 2Mbps, e dadas as taxas acima, isto deve resultar em 2 Megabits (Mb) /(59+10) = 30.394 bits por inter-quadro e 303.935 bits por
| quadro |. Quando o fluxo contínuo de vídeo comprimido é recebido pelo al- | | goritmo de descompressão, para que o vídeo passe de forma estável, cada quadro precisa ser descomprimido e exibido a um intervalo regular (por e- xemplo, 60 fps). Para alcançar este resultado, se qualquer quadro é sujeito a latência todos os quadros precisam ser atrasados por pelo menos aquela | latência, assim o pior caso de latência de quadro definirá a latência para to- i dos os quadros de vídeo.
Os quadros | introduzem as maiores latências de transmissão uma vez que os mesmos são maiores, e um quadro | inteiro deve ter que ser recebido antes que o quadro | possa ser descomprimido e : 10 exibido (ou qualquer inter-quadro dependente do quadro |). Dado que a taxa de dados do canal é de 2Mbps, levará 303.935/2Mb = 145 ms para transmitir um quadro |. " Um sistema de compressão de vídeo inter-quadro como descrito acima usando uma grande porcentagem de largura de banda do canal de transmissão estará sujeito a longas latências devido ao grande tamanho de um quadro | relativo ao tamanho médio de um quadro.
Ou, para colocar de outra forma, embora os algoritmos de compressão inter-quadro da técnica anterior obtém uma taxa de dados média por quadro mais baixa do que os algoritmos de compressão apenas intra-quadro (por exemplo, 2Mbps vs. —A40Mbps), eles ainda sofrem de uma taxa de dados de pico por quadro alta (por exemplo, 303.935 * 60 = 18,2Mbps) devido aos quadros |. Tendo em mente, entretanto que a análise acima assume que os quadros P e B são - muito menores do que os quadros |. Embora isto seja verdadeiro em geral, " isto não é verdadeiro para quadros com alta complexidade de imagem não —correlacionados com o quadro anterior, muito movimento, ou mudanças de cenário.
Nestas situações, os quadros P ou B podem se tornar tão grandes quanto os quadros | (se um quadro P ou B se torna maior do que um quadro |, um algoritmo de compressão sofisticado irá tipicamente "forçar" um quadro | e substituir o quadro P ou B por um quadro 1). Assim, os picos de taxa de — dados dimensionados por quadro | podem ocorrer a qualguer momento em um fluxo contínuo de vídeo digital.
Portanto, com vídeo comprimido, quando a taxa de dados de vídeo médias se aproxima da capacidade de taxa de da-
: 37/182 | dos dos canais de transmissão (como é frequentemente o caso, dada as altas demandas de taxa de dados para vídeo) As altas taxas de dados de pico dos quadros | ou grandes quadros P ou B resultam em uma alta latência | de quadro. | | 5 Naturalmente, a discussão acima apenas caracteriza a latência | | do algoritmo de compressão criada por quadros B, P ou | grandes em um GOP.
Se quadros B são usados, a latência será ainda maior.
A razão é por- que antes de um quadro B poder ser exibido, todos os quadros B após o quadro B e o quadro | têm que ser recebidos.
Portanto, em uma sequência y & 10 de grupo imagem (GOP) tal como BBBBBIPPPPPBBBBBIPPPPP, onde e- xistem 5 quadros B antes de cada quadro |, o primeiro quadro B não pode ser exibido pelo descompressor de vídeo até que os quadros B e quadro | E subsequentes sejam recebidos.
Assim, se o vídeo está sendo transmitido a 60fps (ou seja, 16,67ms/quadro), antes de o primeiro quadro B poder ser E 15 — descomprimido, cinco quadros B e o quadro | levarão 16.67 * 6 = 100ms pa- ra ser recebidos, não importa quão rápida seja a largura de banda do canal, e isto com apenas 5 quadros B.
Sequências de vídeo comprimido com 30 quadros B são bastante comuns.
E, em uma largura de banda de canal bai- xa como 2Mbps, o impacto da latência causada pelo quadro | é grandemente —aditiva ao impacto devido à espera pela chegada de quadros B.
Portanto, em um canal de 2Mbps com uma grande quantidade de quadros B é muito fácil exceder 500ms de latência ou mais usando tecnologia de compressão de - vídeo da técnica anterior.
Se não são usados quadros B (ao custo de uma r menor taxa de compressão para dado nível de qualidade), não ocorre a la- tênciade quadro B, mas a latência causada pelos tamanhos de quadro de pico, descrita acima, ainda ocorre.
O problema é muito exacerbado pela natureza de muitos jogos de vídeo.
Algoritmos de compressão de vídeo que utilizam a estrutura de GOP descrita acima têm sido muito otimizados para uso com material de vídeo ao vivo ou filmes para visualização passiva.
Tipicamente, a câmera (ou uma câmera real, ou uma câmera no caso de uma animação gerada por computador) e cenário são relativamente estáveis, simplesmente porque se
| a câmera ou cenário se movem ao redor muito aos trancos, o material de vídeo ou filme é (a) tipicamente desprazeroso para assistir e (b) se está sen- | do assistido, usualmente o espectador não está seguindo a ação de perto | quando a câmera arranca subitamente (por exemplo, se a câmera sofre um impacto quando está filmando uma criança apagando as velas em um bolo | | de aniversário e repentinamente desvia para longe do bolo e volta novamen- te, os espectadores estão tipicamente focados na criança e no bolo, e des- consideram a breve interrupção quando a câmera se move). N caso do vi- deo de uma entrevista, ou uma teleconferência de vídeo, a câmera pode ser : 10 “mantida em uma posição fixa e não se mover, resultando em muito poucos picos de dados.
Mas jogos de vídeo 3D de muita ação são caracterizados por movimento constante (por exemplo, considerando uma corrida em 3D, f onde o quadro inteiro está em movimento rápido pela duração da corrida, ou considerando atiradores em primeira pessoa, onde a câmera virtual está constante mente se movendo aos trancos). Estes jogos de vídeo podem re- sultar em sequências de quadro com picos grandes e frequentes onde o u- suário pode precisar ver claramente o que está acontecendo durante estes movimentos súbitos.
Assim, artefatos de compressão são muito menos tole- ráveis em jogos de vídeo de muita ação em 3D.
Portanto, a saída de vídeo de muitos jogos de vídeo, por sua natureza, produz um fluxo contínuo de vídeo comprimido com picos muito altos e frequentes.
Dado que os usuários de jogos de vídeo de ação rápida têm ia pouca tolerância a alta latência, e dadas todas as causas de latência acima, " até hoje tem existido limitações a jogos de vídeo hospedados em servidor que transmite vídeo pela Internet.
Adicionalmente, usuários de aplicações que requerem um alto grau de interatividade sofrem com limitações similares se as aplicações são hospedadas na Internet em geral e transmitem vídeo.
Estes serviços requerem uma configuração de rede na qual os servidores hospedeiros são configurados diretamente em uma estação transmissora (no caso de banda larga por cabo) ou no escritório central (no caso de Li- nhas de Assinante Digitais (DSL)), ou dentro de uma LAN (ou em conexões privadas altamente graduadas) em uma configuração comercial, de modo
| que a rota e distância do dispositivo cliente para o servidor é controlada para minimizar a latência e picos podem ser acomodados sem incorrer em latên- cia. LANs (tipicamente classificadas em 100Mbps a 1Gbps) e linhas aluga- das com largura de banda adequada tipicamente podem suportar exigências de pico de largura de banda (por exemplo, pico de largura de banda de | 18Mbps é uma pequena fração da capacidade de LAN de 100Mbps).
Ê Exigências de pico de largura de banda também podem ser á acomodadas pela infra-estrutura de banda larga residencial se são feitas acomodações especiais. Por exemplo, em um sistema de TV a cabo, pode ser dada uma largura de banda dedicada de tráfego de vídeo que trate os picos, tais como grandes quadros |. E em um sistema DSL, pode ser forne- cido um modem DSL de maior velocidade, que permita picos altos, ou pode A ser fornecida uma conexão de graduação especial que possa tratar taxas de dados mais altas. Mas, modem de cabo e infra-estrutura DSL convencionais conectados a Internet têm muito menos tolerância para exigência de largura de banda de pico para vídeo comprimido. Assim, serviços em linha que hos- pedam jogos de vídeo o aplicações em centros de servidores a longa distân- cia dos dispositivos de clientes, e então transmitem saída de fluxo contínuo de vídeo comprimido output pela Internet através de conexões de banda lar- ga residenciais convencionais sofrem de limitações de latência e largura de banda de pico significativas — particularmente com respeito a jogos e aplica- ções que requerem baixa latência (por exemplo, tiro em primeira pessoa e " outros jogos de ação interativos multiusuários, ou applications que reque- ia rem um tempo de resposta rápido). Breve Descrição dos Desenhos A presente invenção será mais entendida mais completamente a partir da descrição detalhada a seguir e a partir dos desenhos em anexo, que entretanto, não devem ser tomados para limitar o objeto revelado às modalidades específicas mostradas, mas apenas para explicação e enten- dimento. A figura 1 ilustra uma arquitetura de um sistema de jogos da téc- nica anterior.
| As figuras 2a e b ilustram uma arquitetura de sistema de alto ní- ! vel de acordo com uma modalidade.
A figura 3 ilustra taxas de dados real, classificada e requerida para comunicação entre um cliente e um servidor.
A figura 4a ilustra um serviço de hospedagem e um cliente em- | i pregado de acordo com uma modalidade. | A figura 4b ilustra latências exemplificativas associadas com ! comunicação entre um cliente e serviço de hospedagem.
A figura 4c ilustra um dispositivo cliente de acordo com uma mo- . dalidade.
A figura 4d ilustra um dispositivo cliente de acordo com outra modalidade. f figura 4€ ilustra um diagrama de blocos exemplificativo do dispo- sitivo cliente na figura 4c.
É 15 figura 4f ilustra um diagrama de blocos exemplificativo do dispo- sitivo cliente na figura 4d.
A figura 5 ilustra uma forma exemplificativa de compressão de vídeo que pode ser empregada de acordo com uma modalidade.
A figura 6a ilustra uma forma exemplificativa de compressão de vídeo que pode ser empregada em outra modalidade.
A figura 6b ilustra picos de taxa de dados associados com trans- missão de uma sequência de vídeo de baixa complexidade e baixa ação, - A figura 6c picos de taxa de dados associados com transmissão = de uma sequência de vídeo de alta complexidade e alta ação.
As figuras 7a e b ilustram técnicas de compressão de vídeo e- xemplificativas empregadas em uma modalidade.
A figura 8 ilustra técnicas de compressão de vídeo exemplificati- vas adicionais empregadas em uma modalidade.
As figuras 9a a 9c ilustram técnicas de processamento de taxa —de quadro empregados em uma modalidade da invenção.
As figuras 10a e b ilustram uma modalidade que empacota efici- entemente recortes de imagem dentro de pacotes.
| As figuras 11a a 11d ilustram modalidades que empregam técni- | cas de correção de erro de encaminhamento.
A figura 12 ilustra uma modalidade que usa unidades de proces- 7 samento multinúcleo para compressão. 7 5 As figuras 13a e b ilustram posicionamento geográfico e comuni- cação entre serviços de hospedagem de acordo com várias modalidades. ! A figura 14 ilustra latências exemplificativas associadas com ó communication entre um cliente e um serviço de hospedagem.
A figura 15 ilustra um exemplo de arquitetura de centro de servi- ; dores de serviço de hospedagem.
A figura 16 ilustra uma fotografia de exemplo de uma modalida- de de uma interface de usuário que inclui uma pluralidade de janelas de ví- fr deo ao vivo.
A figura 17 ilustra a interface de usuário da figura 16 seguindo a É 15 seleçãode uma janela de vídeo particular.
A figura 18 ilustra a interface de usuário da figura 17 seguindo a aproximação da janela de vídeo particular para o tamanho inteiro da tela.
A figura 19 ilustra um exemplo de dados de vídeo de usuário co- laborativo na tela de um jogo multijogador.
A figura 20 ilustra um exemplo de página de usuário para um jo- gador em um serviço de hospedagem.
A figura 21 ilustra um exemplo de propaganda interativa em 3D. - A figura 22 ilustra um exemplo de sequência de etapas para r produzir uma imagem foto-realista que tenha uma superfície texturizada da captura de superfície de uma performance ao vivo.
A figura 23 ilustra um exemplo de página de interface de usuário que permite a seleção de conteúdo de mídia linear.
A figura 24 é um gráfico que ilustra a quantidade de tempo que passa antes de da página de web versus a velocidade de conexão.
As figuras 25a e b ilustram modalidades da invenção que em- pregam um canal de realimentação de informação do dispositivo cliente para o serviço de hospedagem.
; 42/182 | As figuras 26a e b ilustram uma modalidade na qual codifica re- | cortes /quadros baseado no último recorte/quadro conhecido a ter sido rece- | bido com sucesso.
As figuras 27a e b ilustram uma modalidade na qual o estado de umjogo ou aplicação é portado de um primeiro serviço de hospedagem ou | servidor para um segundo serviço ou servidor de hospedagem. i : A figura 28 ilustra uma modalidade o estado de um jogo ou apli- ! cação é portado usando dados de diferença.
A figura 29 ilustra uma modalidade da invenção que emprega : um decodificador temporário no dispositivo cliente.
A figura 30 ilustra como "recortes |" são intercalados através de "quadros R" de acordo com uma modalidade da invenção.
As figuras 31a a h ilustram modalidades da invenção que geram um fluxo contínuo de vídeo e/ou um ou mais fluxos contínuos de HQ.
À 15 Descrição de Modalidades de Exemplo Na descrição a seguir são demonstrados detalhes específicos, tais como tipos de dispositivos, configurações de sistema, métodos de co- municação, etc., a fim de fornecer um entendimento completo da presente invenção.
Entretanto, pessoas que tem conhecimentos básicos nas técnicas relevantes avaliarão que estes detalhes específicos podem não ser necessá- rios para praticar as modalidades descritas.
As figuras 2a e b fornecem uma arquitetura de alto nível de duas - modalidades nas quais jogos de vídeo e aplicações de software são hospe- = dadas por um serviço de hospedagem 210 e acessadas por dispositivos cli- entes 205 nas premissas de usuário 211 (deve ser observado que as "pre- missas de usuário" significa o lugar onde o usuário está localizado, incluindo locais externos se estiver usando um dispositivo móvel) através da Internet 206 (ou outra rede pública ou privada) sob um serviço de assinatura.
Os dis- positivos clientes 205 podem ser computadores de propósito geral tais como — Microsoft Windows ou PCs baseados em Linux ou computadores Macintosh da Apple, Inc. com uma conexão por cabo ou sem fio à Internet com um dis- positivo de exibição interno ou externo 222, ou os mesmos podem ser dispo-
| sitivos clientes dedicados tais como um decodificador (com uma conexão | por cabo ou sem fio à Internet) que fornece saída de vídeo e áudio para um conjunto de monitor ou TV 222, ou os mesmos podem ser dispositivos mó- veis, presumidamente com uma conexão sem fio à Internet. ] 5 Qualquer um destes dispositivos pode ter seus próprios disposi- E | tivos de entrada (por exemplo, teclados, botões, telas sensíveis ao toque, dispositivo apontador ou dispositivos sensíveis à inércia, câmeras de captura de vídeo e/ou câmeras de rastreamento de movimento, etc.), ou os mesmos podem usar dispositivos de entrada externos 221 (por exemplo, teclados, — ratos (mice), controladores de jogo, dispositivos sensíveis à inércia, câmeras de captura de vídeo e/ou câmeras de rastreamento de movimento, etc.), co- nectados por cabos ou sem fio, como descrito em mais detalhes abaixo, o ; serviço de hospedagem 210 servidores de vários níveis de performance, incluindo aqueles com CPU/GPU de alta capacidade de processamento.
Du- : 15 rante um jogo ou uso de uma aplicação no serviço de hospedagem 210, dis- positivo cliente 205 residencial ou de escritório recebe entradas de teclado e/ou controlador do usuário, e em seguida transmite a entrada do controla- dor através da Internet 206 para o serviço de hospedagem 210 que executa o código do programa de jogo em resposta e gera quadros sucessivos de —saídade vídeo (uma sequência de imagens de vídeo) para o jogo ou softwa- re aplicativo (por exemplo, se o usuário pressiona um botão que dirige um personagem na tela para se mover para a direita, o programa de jogo então - cria uma sequência de imagens de vídeo que mostra o personagem se mo- ms vendo para a direita). Esta sequência de imagens de vídeo é então compri- —mida usando um compressor de vídeo de baixa latência, e o serviço de hos- pedagem 210 então transmite o fluxo contínuo de vídeo de baixa latência através da Internet 206. O dispositivo cliente residencial ou de escritório en- tão decodifica o fluxo contínuo de vídeo comprimido e entrega as imagens de vídeo descomprimido em um monitor ou TV.
Consequentemente, as exi- —gênciasde hardware de computação e gráfico do dispositivo cliente 205 são significativamente reduzidas.
O cliente 205 precisa apenas ter poder de pro- cessamento para encaminhar a entrada do teclado/controlador para a Inter-
net 206 e decodifica e descomprime um fluxo contínuo de vídeo comprimido recebido da Internet 206, o que virtualmente qualquer computador pessoal é | capaz de fazer hoje em software em sua CPU (por exemplo, uma CPU Core ! Duo da Intel Corporation rodando a aproximadamente 2GHz é capaz de | —descomprimir HDTV de 720p codificado usando compressores tais como | H.264 e Windows Media VC9). E, no caso de quaisquer circuitos integrados | (chips) dedicados de dispositivos clientes também poderem executar des- compressão de vídeo para estes padrões em tempo real a um custo muito menor e com muito menos consumo de energia do que uma CPU de propó- ia ' 10 sito geral tal como seria requerido por um PC moderno.
Notavelmente, para executar a função de encaminhar a entrada do controlador e descompressão de vídeo, os dispositivos clientes residenciais 205 não requerem quaisquer unidades de processamento gráfico especializadas (GPUs), controlador ótico ou controlador de discos rígidos, tal como o sistema de jogo de vídeo da técnica anterior mostrado na figura 1. Conforme os jogos e softwares aplicativos se tornam mais com- plexos e fotorrealísticos, os mesmos exigirão CPUs e GPUs de maior per- formance, mais RAM, e controladores de disco maiores e mais rápidos, e o poder de computação no serviço de hospedagem 210 pode ser continua- mente atualizado, mas não é requerido que o usuário final atualize a plata- forma cliente residencial ou do escritório 205 uma vez que suas exigências de processamento permanecerão constantes para uma resolução de exibi- E ção e taxa de quadros com um dado o algoritmo de descompressão de ví- i deo.
Portanto, as limitações de hardware e problemas de compatibilidade Vistos atualmente não existem no sistema ilustrado nas figuras 2a e b.
Adicionalmente, devido ao jogo e software aplicativo executarem apenas em servidores no serviço de hospedagem 210, nunca existe uma cópia do jogo ou software aplicativo (seja na forma de mídia ótica, ou como software descarregado) na residência ou escritório do usuário ("escritório" — como usado neste documento a menos que qualificado de outra forma deve incluir qualquer configuração não residencial, incluindo, por exemplo, salas escolares). Isto mitiga significativamente a probabilidade de um jogo ou software aplicativo ser copiado ilegalmente (pirateado), bem como mitiga a | probabilidade de que um banco de dados valioso que pode ser usado por | | um jogo ou softwares aplicativos seja pirateado.
Na verdade, se são requeri- E dos servidores especializados (por exemplo, requer equipamento muito caro í 5 grande e ruidoso) para jogar o jogo ou software aplicativo que não são práti- Í j cos para uso residencial ou de escritório, então mesmo se uma cópia pirate- ada do jogo ou software aplicativo for obtida, o mesmo não deve ser operá- ! vel na residência ou escritório.
Em uma modalidade, o serviço de hospedagem 210 fornece fer- —ramentas de desenvolvimento de software para os desenvolvedores de jogo ou software aplicativo (que refere-se geralmente a companhias de desenvol- vimento de software, estúdios de jogo ou filme, ou publicadores de jogo ou softwares aplicativos) 220 que projetam jogos de vídeo de modo que os mes- : mos possam projetar jogos capazes de ser executados no serviço de hospe- dagem 210. Estas ferramentas permitem que desenvolvedores explorem ca- racterísticas do serviço de hospedagem que normalmente não estão disponí- veis em um PC ou console de jogo autônomos (por exemplo, acesso rápido a bancos de dados muito grandes de geometria complexa ("geometria" a menos que qualificada de outra forma deve ser usada neste documento para se refe- rira comportamentos de polígonos, texturas, montagem, iluminação e outros componentes e parâmetros que definem estruturas de dados 3D)). São possíveis diferentes modelos de negócios sob esta arquite- " tura.
Em um modelo, o serviço de hospedagem 210 coleta uma taxa de as- x sinatura do usuário final e paga um direito de uso para os desenvolvedores 220,como mostrado na figura 2a.
Em uma implementação alternativa, mos- trada na figura 2b, os desenvolvedores 220 coletam uma taxe de assinatura diretamente do usuário e pagam o serviço de hospedagem 210 para hospe- dar o conteúdo do jogo ou aplicação.
Estes princípios subjacentes não são limitados a qualquer modelo de negócio para fornecer jogos em linha ou — hospedagem de aplicações.
Características de Vídeo Comprimido Como discutido anteriormente, um problema significativo com
B 46/182 | fornecimento de serviços de jogos de vídeo ou serviços de software de apli- | cação em linha é o da latência.
Uma latência de 70 a 80 ms (do ponto em [| que um dispositivo de entrada é acionado por um usuário até o ponto onde | 7 uma resposta é exibida no dispositivo de exibição) está no limite superior 1 5 —parajogos e aplicações que exigem um tempo de resposta rápido.
Entretan- Í Í to, isto é muito difícil de alcançar no contexto das arquiteturas mostradas nas | ! figuras 2a e 2b devido a uma quantidade de restrições práticas e físicas.
Como indicado na figura 3, quando um usuário assina um servi- ço de Internet, a conexão é tipicamente classificada por uma taxa de dados : “máxima nominal 301 para a residência ou escritório do usuário.
Dependendo das políticas do provedor e capacidade do equipamento de encaminhamen- to, aquela taxa de dados máxima pode ser mais ou menos aplicada estrita- f mente, mas tipicamente a taxa de dados disponível real é menor por uma de E muitas razões diferentes.
Por exemplo, pode haver muito tráfego na rede no escritório central de DSL ou no circuito de modem de cabo local, ou pode haver ruído no cabeamento que provoca perda de pacotes ou o provedor pode estabelecer uma quantidade máxima de bits por mês por usuário.
Atu- almente, a taxa de dados máxima serviços de cabo e DSL varia tipicamente de algumas centenas de Kilobits/segundo (Kbps) a 30 Mbps.
Serviços celu- lares são tipicamente limitados a centenas de Kbps de fluxo de descida de dados.
Entretanto, a velocidade de serviços de banda larga e a quantidade de usuários que assina serviços de banda larga aumentará dramaticamente : ao longo do tempo.
Atualmente, alguns analistas estimam que 33% dos as- ba sinantes de banda larga nos EUA tenham uma taxa de dados para fluxo de —descidade 2Mbps ou mais.
Por exemplo, alguns analistas prevêem que em 2010, acima de 85% dos assinantes de banda larga nos EUA terá uma taxa de dados de 2Mbps ou mais.
Como indicado na figura 3, a taxa de dados máxima disponível : atual 302 pode flutuar ao longo do tempo.
Portanto, em um contexto de jo- gos e software aplicativo de baixa latência em linha algumas vezes é difícil prever a taxa de dados disponível para um fluxo contínuo de vídeo particular.
Se a taxa de dados 303 requerida para sustentar um dado nível de qualida-
E 47/182 | de a uma dada quantidade de quadros por segundo (fps) a uma dada reso- | lução (por exemplo, 640 x 480 (Q 60 fps) para uma certa complexidade de cenário e movimento sobe acima da taxa de dados máxima disponível atual 302 (como indicado pelo pico na figura 3), então podem ocorrer diversos Íi 5 — problemas.
Por exemplo, alguns serviços de Internet simplesmente perderão | pacotes, resultando em perda de dados e imagens destorcidas /perdidas na ! Á tela de vídeo do usuário.
Outros serviços irão armazenar temporariamente h (ou seja, enfileirar) os pacotes adicionais e fornecer os pacotes para o clien- te na taxa de dados disponível, resultando em um aumento na latência — um É 10 — resultado inaceitável para muitos jogos de vídeo e aplicações.
Finalmente, alguns provedores de serviço de Internet verão o aumento na taxa de dados como um ataque malicioso, tal como um ataque de recusa de serviço (uma f técnica bem conhecida usada pelos hackers para desabilitar conexões de E rede), e cortarão a conexão de Internet do usuário por um determinado perí- odo de.
Portanto, as modalidades descritas neste documento tomam medi- das para garantir que a taxa de dados requerida por um jogo de vídeo não exceda a taxa de dados máxima disponível.
Arquitetura de Serviço de Hospedagem A figura 4a ilustra uma arquitetura do serviço de hospedagem 210 de acordo com uma modalidade.
O serviço de hospedagem 210 pode ser localizado ou em um único centro de servidores, ou pode ser distribuída por uma pluralidade de centros de servidores (para fornecer conexões de " baixa latência para usuários que têm percursos de menor latência para cer- ias tos centros de servidores do que para outros, para fornecer um balancea- —mento de carga entre os usuários, e para fornecer redundância no caso de um ou mais centros de servidores falharem). O serviço de hospedagem 210 pode incluir eventualmente centenas de milhares ou mesmo milhões de ser- vidores 402, servindo uma base de usuários muito grande.
Um sistema de controle de serviço de hospedagem 401 fornece controle geral para o servi- —çode hospedagem 210, e controla servidores, roteadores, sistemas de com- pressão de vídeo, sistemas de faturamento e contabilidade, etc. em uma modalidade, o sistema de controle de serviço de hospedagem 401 é imple-
Ê 48/182 | mentado em um sistema baseado em Linux distribuído ligado à matrizes de j RAID usadas para armazenar bancos de dados para informação de usuário, informação de servidor e estatísticas de sistema.
Nas descrições acima, as várias ações implementadas no serviço de hospedagem 210, a menos que | 5 atribuídas a outros sistemas específicos, são iniciadas e controladas pelo | sistema de controle de serviço de hospedagem 401. Í : O serviço de hospedagem 210 inclui uma quantidade de servido- Ê res 402 tais como aqueles disponíveis pela Intel, IBM e Hewlett Packard, e | outros.
Alternativamente, os servidores 402 podem ser montados em uma configuração personalizada de componentes, ou podem ser eventualmente integrados assim um servidor inteiro é implementado como um único circuito integrado.
Embora este diagrama mostre uma pequena quantidade de servi- E dores 402 para o propósito de ilustração, em um desenvolvimento atual po- E dem haver tão poucos como apenas um servidor 402 ou tantos como mi- lhões de servidores 402 ou mais.
Os servidores 402 podem ser todos confi- gurados da mesma forma (como exemplo de alguns parâmetros de configu- ração, com o mesmo tipo e performance de CPU; com ou sem uma GPU, e se com uma GPU, com o mesmo tipo e performance de GPU; com a mesma quantidade de CPUs e GPUs; com a mesma quantidade e tipo/velocidade de "RAM; e com a mesma configuração de RAM), ou vários subconjuntos dos servidores 402 podem ter a mesma configuração (por exemplo, 25% dos servidores podem ser configurados de uma certa forma, 50% de uma forma - diferente, e 25% ainda de outra forma), ou cada servidor 402 pode ser dife- , rente.
Em uma modalidade, os servidores 402 são sem disco, ou seja, em vez de terem seu próprio armazenamento de massa (seja ele armaze- namento ótico ou magnético, ou armazenamento baseado em semicondutor tal como memória Flash ou outros meios de armazenamento de massa ser- vindo para uma função similar), cada servidos acessa armazenamento de —massa compartilhado através de um painel passivo ou conexão de rede.
Em uma modalidade, esta conexão rápida é uma Rede de Área de Armazena- mento (SAN) 403 conectada a uma série de Matrizes redundantes de Discos
: 49/182 | Independentes (RAID) 405 com conexões entre dispositivos implementada | usando Gigabit Ethernet. Como é conhecido pelos indivíduos versados na | técnica, uma SAN 403 pode ser usada para combinar muitas matrizes de RAID 405, resultando em largura de banda extremamente alta — se aproxi- 7 5 —mando ou potencialmente excedendo a largura de banda disponível a partir Í da RAM usada nas consoles de jogos e PCs. E, embora matrizes de RAID | baseadas em mídia rotativa, tal como mídia magnética, frequentemente te- nham latência de tempo de busca significativo, matrizes de RAID baseadas em armazenamento de semicondutor podem ser implementadas com muito J " 10 menos latência de acesso. em outra configuração, alguns ou todos os servi- dores 402 fornecem parte ou todo o seu armazenamento de massa local- mente. Por exemplo, um servidor 402 pode armazenar informação acessada : frequentemente tal como seu sistema operacional e uma cópia de um jogo ; de vídeo ou aplicação em armazenamento baseado em Flash local de baixa latência, mas o mesmo pode utilizar o SAN para acessar matrizes de RAID 405 baseadas em mídia rotativa com latência de busca maior para acessar grandes bancos de dados de geometria ou informação de estado do jogo em bases menos frequentes. Adicionalmente, em uma modalidade, o serviço de hospedagem 210 emprega lógica de compressão de vídeo de baixa latência 404 descrita em detalhes abaixo. A lógica de compressão de vídeo 404 pode ser imple- mentada em software, hardware, ou qualquer combinação dos mesmos (cer- - tas modalidades das quais são descritas abaixo). Lógica de compressão de - vídeo 404 inclui lógica para comprimir áudio bem como material visual.
Em operação, enquanto joga um jogo de vídeo ou usa uma apli- cação nas premissas de usuário 211 através de um teclado, rato, controlador de jogo ou outro dispositivo de entrada 421, a lógica de sinal de controle 413 no cliente 415 transmite sinais de controle 406a e b (tipicamente na forma de pacotes UDP) que representam pressionamentos de botões (e outros tipos de entradas de usuário) acionados pelo usuário para o serviço de hospeda- gem 210. Os sinais de controle de um dado usuário são encaminhadas para o servidor de aplicação apropriado (ou servidores, se múltiplos servidores
S 50/182 são responsivos ao dispositivo de entrada de usuário) 402. Como ilustrado | | na figura 4a, sinais de controle 406a podem ser encaminhados para os ser- ] vidores 402 através da SAN.
Alternativa ou adicionalmente, sinais de con- l trole 406b podem ser encaminhados diretamente para os servidores 402 - 5 sobre a rede do serviço de hospedagem (por exemplo, uma rede de área | | local baseada em Ethernet). Independentemente de como os mesmos são i transmitidos, o servidor ou servidores executam o jogo ou software aplicativo em resposta aos sinais de controle 406a e b.
Embora não ilustrados na figu- ra 4a, vários componentes de rede tal como um firewall(s) e/ou porta(s) de y ligação podem processar tráfego de entrada e de saída na borda do serviço de hospedagem 210 (por exemplo, entre o serviço de hospedagem 210 e a Internet 410) e/ou na borda das premissas de usuário 211 entre a Internet f 410 e o cliente residencial ou de escritório 415. A saída gráfica ou de áudio E do jogo ou software aplicativo executado — ou seja, novas sequências de imagem de vídeo — são fornecidas para a lógica de compressão de vídeo de baixa latência 404 que comprime as sequências de imagens de vídeo de acordo com as técnicas de compressão de vídeo de baixa latência, tais co- mo aquelas descritas neste documento e transmite um fluxo contínuo de víi- deo comprimido, tipicamente com áudio comprimido e não comprimido, de voltaparao cliente 415 sobre a Internet 410 (ou como descrito abaixo, sobre um serviço de rede de alta velocidade otimizado que desvia da Internet ge- ral). Lógica de descompressão de vídeo de baixa latência 412 no cliente 415 y em seguida descomprime os fluxos contínuos de vídeo e áudio e entrega o m fluxo contínuo de vídeo descomprimido, e tipicamente toca o fluxo contínuo —deáudiodescomprimido em um dispositivo de exibição 422. Alternativamen- te, o áudio pode ser tocado em alto-falantes separados do dispositivo de e- xibição 422 ou não absolutamente.
Deve ser observado que, apesar do fato de que o dispositivo de entrada 421 e dispositivo de exibição 422 serem mostrados como dispositivos autônomos nas figuras 2a e 2b, os mesmos — podem ser integrados em dispositivos clientes tais como computadores por- táteis ou dispositivos móveis.
Cliente residencial ou de escritório 415 (descrito anteriormente
E 51/182 | como cliente residencial ou de escritório 205 nas figuras 2a e 2b) pode ser um disposítivo muito barato e de baixa potência, com performance de com- putação ou gráfica muito limitada e pode ter armazenamento der massa local 7 muito limitado ou nenhum.
Ao contrário, cada servidor 402, acoplado a uma 7 5 SAN 403e múltiplas RAIDs 405 pode ser um sistema de computação de performance excepcionalmente alta, e na verdade, se múltiplos servidores ! são usados cooperativamente em uma configuração de processamento pa- ralelo, quase não existe limite na quantidade de potência de processamento e gráfica que pode ser trazida para o suporte.
E, devido a compressão de vídeo de baixa latência 404 e compressão de vídeo de baixa latência 412, perceptivamente para o usuário, a potência de computação dos servidores 402 está sendo fornecida para o usuário.
Quando o usuário pressiona um ' botão no dispositivo de entrada 421, a imagem na exibição 422 é atualizada E em resposta ao pressionamento do botão sem nem um atraso significativo —perceptivamente, como se o jogo ou software aplicativo estivessem rodando localmente.
Portanto, com um cliente residencial ou de escritório 415 que é um computador de performance muito baixa ou apenas um circuito integrado barato que implementa a descompressão de vídeo de baixa latência e lógica de controle de sinal 413, é fornecido para o usuário uma potência de compu- tação efetivamente arbitrária a partir de uma localização remota que parece ser disponível localmente.
Isto dá ao usuário potência para jogar os mais avançados jogos de vídeo de processador intensivo (tipicamente Novos) e as . aplicações de performance mais alta. 7 A figura 4c mostra um dispositivo cliente 465 muito básico e ba- rato. este dispositivo é uma modalidade de cliente residencial ou de escritó- rio 415 das figuras 4a e 4b.
O mesmo tem aproximadamente 5 centímetros de comprimento.
O mesmo tem uma tomada Ethernet 462 que faz interface com um cabo Ethernet com Energia sobre Ethernet (PoE), a partir do qual o mesmo deriva sua energia e sua conectividade para a Internet.
O mesmo é capaz de rodar Tradução de Endereço de Rede (NAT) dentro de uma rede que suporta NAT.
Em um ambiente de escritório, muitos novos comutadores Ethernet têm PoE e trazem PoE diretamente para uma tomada Ethernet em
| um escritório.
Em uma situação como esta, tudo que é requerido é um cabo ! Ethernet de uma tomada de parede para o cliente 465. Se a conexão Ether- | net disponível não transportar energia (por exemplo, em uma residência com um modem DSL ou cabo, mas nenhum PoE), então existem "tijolos" de pa- | rede baratos (ou seja, fontes de energia) disponíveis que aceitam cabo | | Ethernet e fornecem Ethernet com PoE. ; ! O cliente 465 contém lógica de controle de sinal 413 (da figura 4a) que é acoplada a uma interface sem fio Bluetooth, que faz a interface com dispositivos de entrada Bluetooth 479, tais como um teclado, rato, con- fe! 10 —trolador de jogo e/ou microfone e/ou fone de ouvido.
Também, uma modali- dade de cliente 465 é capaz de fornecer vídeo a 120fps acoplado com um dispositivo de exibição 468 capaz de suportar 120fps de vídeo e sinal (tipi- camente através de infravermelho) um par de óculos obturado 466 para fe- . char alternada mente um olho, depois o outro com cada quadro sucessivo.O efeito percebido pelo usuário é o de uma imagem estereoscópica 3D que "salta para fora" da tela de exibição.
Um dispositivo de exibição 468 como este que suporta tal operação é o Samsung HL-T5076S.
Uma vez que o flu- xo contínuo de vídeo para cada olho é separado, em uma modalidade dois fluxos contínuo de vídeo independentes são comprimidos pelo serviço de hospedagem 210, os quadros são entrelaçados no tempo, e os quadros são descomprimidos como dois processos de descompressão independentes dentro do cliente 465. E O cliente 465 também contém lógica de descompressão de ví- iai deo de baixa latência 412, que descomprime vídeo e áudio e fornece através do conector HDMI (Interface Multimídia de Alta Definição) 463 que conecta em uma SDTV (Televisão de Definição Padrão) ou HDTV (Televisão de Alta Definição) 468, fornecendo vídeo e áudio para a TV, ou para um monitor 468 que suporte HDMI.
Se o monitor do usuário 468 não suporta HDMI, então pode ser usado um HDMI para DVI (Interface Visual Digital), mas o áudio — será perdido.
Sob o padrão HDMI, as capacidades de exibição (por exemplo resoluções suportadas, taxas de quadro) 464 são comunicadas do dispositi- vo de exibição 468, e esta informação é então passada de volta através da conexão de Internet 462 de volta para o serviço de hospedagem 210 assim o | mesmo pode transmitir vídeo comprimido em um formato adequado para o dispositivo de exibição.
A figura 4d mostra um dispositivo cliente residencial ou de escri- | 5 tório 475 queéomesmo que o dispositivo cliente residencial ou de escritório | | 465 mostrado na figura 4c exceto pelo fato de que tem mais interfaces ex- | ternas.
Também, o cliente 475 pode aceitar ou PoE para energia, ou a mes- ma pode escoar de um adaptador de fonte de alimentação externa (não mostrado) que conecta na parede.
Usando entrada USB do cliente 475,a : câmera de câmera 477 fornece vídeo comprimido para o cliente 475, que é carregado pelo cliente 475 para o serviço de hospedagem 210 para o uso descrito abaixo.
A câmera embutida 477 é um compressor de baixa latência ' que utiliza as técnicas de compressão descritas abaixo.
Adicionalmente a ter um conector Ethernet para sua conexão a Internet, o cliente 475 também tem uma interface sem fio 802.119 para a Internet.
Ambas interfaces são capazes de usar NAT dentro de uma rede que suporta NAT.
Também, adicionalmente a ter um conector HDMI para fornecer vi- deo e áudio, o cliente 475 também tem um conector Dual Link DVI, que inclui saída analógica (e com um cabo adaptador padrão fornecerá saída VGA). O mesmo também tem saída analógica para vídeo composto e S-vídeo.
Para áudio, o cliente 475 tem tomadas esquerda /direita RCA es- - téreo analógicas, e para saída de áudio digital o mesmo tem uma saída ii TOSLINK.
Adicionalmente a uma interface sem fio Bluetooth para dispositi- vos de entrada 479, o mesmo tem tomadas USB para fazerem interface com dispositivos de entrada.
A figura 4e mostra uma modalidade da arquitetura interna do cli- ente 465. Todos ou alguns dispositivos mostrados no diagrama podem ser implementados em um Arranjo de Lógica Programável no Campo, um ASIC personalizado ou em diversos dispositivos discretos, ou projetados persona- lizados ou de prateleira.
E 54/182 Ethernet com PoE 497 conecta a Interface Ethernet 481. A ener- j gia 499 é derivada da Ethernet com PoE 497 e é conectada ao resto dos dispositivos no cliente 465. O barramento 480 é um barramento comum para | comunicação entre dispositivos. | A CPU de controle 483 (quase qualquer CPU pequena, como Í j uma CPU da série MIPS R4000 a 100MHz com RAM embutida é adequada) | ! que executa um pequeno aplicativo de controle de cliente da Flash 476 im- planta a pilha de protocolo para a rede (ou seja, interface Ethernet) e tam- bém comunica com o Serviço de Hospedagem 210, e configura todos os dispositivos no cliente 465. Também manuseia as interfaces com os disposi- tivos de entrada 469 e envia os pacotes de volta para o serviço de hospeda- gem 210 com dados de controlador de usuário, protegido por Correção de f Erro Antecipada, se necessário.
Ademais, a CPU de controle 483 monitora o . tráfego de pacote (por exemplo, se os pacotes são perdidos ou atrasados, e também carimba com data/hora sua chegada). Essas informações são envi- adas de volta para o serviço de hospedagem 210 de modo que possa moni- torar constantemente a conexão de rede e ajustar o que envia consequen- temente.
A memória rápida 476 é inicialmente carregada no momento da fabricação com o programa de controle para a CPU de controle 483 e tam- bém com um número de série que é único para a unidade de Cliente 465 particular.
Esse número de série permite que o serviço de hospedagem 210 para identificar de maneira única a unidade de cliente 465. " A interface de Bluetooth 484 se comunica com dispositivos de ba entrada 469 sem fio através de sua antena, interna ao cliente 465. O descompressor de vídeo 486 é um descompressor de vídeo de baixa latência configurado para implantar a descompressão de vídeo descrita no presente documento.
Um número grande de dispositivos de des- compressão de vídeo existe, ou em circulação, ou como Propriedade Intelec- tual (IP) de um design que pode ser integrado em um FPGA ou um ASIC padrão.
Uma empresa que oferece um IP para um decodificador H.264 é a Ocean Logic de Manily, NSW Austrália.
A vantagem de usar IP é que as téc- nicas de compressão usadas no presente documento não se conformam aos
: 55/182 | padrões de compressão.
Alguns descompressores padrão são flexíveis o suficiente para serem configurados para acomodar as técnicas de compres- : são do presente documento, mas alguns não podem.
Porém, com IP, há | uma flexibilidade completa no reprojeto do descompressor, conforme neces- | 7 5 sário.
A saída do descompressor de vídeo é acoplada ao subsistema de saída de vídeo 487, que acopla o vídeo à saída de vídeo da interface de HDMI 490. O subsistema de descompressão de áudio 488 é implantado ou - 10 como uso de um descompressor de áudio padrão que está disponível, ou pode ser implantado como IP, ou a descompressão de áudio pode ser im- plantada no processador de controle 483 que poderia, por exemplo, implan- f tar o descompressor de áudio Vorbis (disponível em Vorbis.com). é O dispositivo que implanta a descompressão de áudio é acopla- do ao subsistema de saída de áudio 489 que acopla o áudio à saída de áu- dio da interface de HDM! 490. A figura 4f mostra uma modalidade da arquitetura interna do cli- ente 475. Conforme pode ser visto, a arquitetura é a mesma que a do cliente 465 exceto pelas interfaces adicionais e potência de CD externa opcional de um adaptador de abastecimento elétrico que se pluga à parede, e se for u- sado, substituía a potência que viria do Eternet PoE 497. À funcionalidade j que está em comum com o cliente 465 não será repetida abaixo, mas a fun- " cionalidade adicional é como segue. m A CPU 483 se comunica com e configura os dispositivos adicio- nais.
O subsistema de WiFi 482 fornece acesso à Internet sem fio como uma alternativa à Eternet 497 através de sua antena.
Os subsistemas de WiFi estão disponíveis junto a uma ampla gama de fabricantes, incluindo Atheros Communications of Santa Clara, CA.
O subsistema de USB 485 fornece uma alternativa para a comu- nicação do tipo Bluetooth para dispositivos e entrada de USB com fio 479, Os subsistemas de USB são padrão e prontamente disponíveis para FPGAs
' 56/182 | e ASICs, bem como frequentemente embutidos dispositivos em circulação ; que realizam outras funções, como descompressão de vídeo.
O subsistema de saída de vídeo 487 produz uma faixa mais am- 7 pla de saídas de vídeo que no cliente 465. Além do fornecimento de saída 7 5 de vídeode HDMI! 490, o mesmo fornece DVI-| 491, S-vídeo 492, e vídeo | Í compósito 493. Além disso, quando a interface DVI-| 491 é usada para vídeo digital, as capacidades de exibição 464 são passadas de volta para o dispo- sitivo de exibição para a CPU de controle 483 de modo que possa notificar o serviço de hospedagem 210 as capacidades do dispositivo de exibição 478. é Todas as interfaces fornecidas pelo subsistema de saída de vídeo 487 são interfaces padrão e prontamente disponíveis sob muitas formas.
O subsistema de saída de áudio 489 emite áudio digitalmente a- ' través da interface digital 494 (S/PDIF e/ou Toslink) e áudio sob a forma : analógica através da interface analógica estéreo 495. —Análisede Latência de Ciclo Naturalmente, para que os benefícios do parágrafo anterior se- jam realizados, a latência de ida e volta entre a ação do usuário que usa o dispositivo de entrada 421 e tendo em vista a consequência daquela ação sobre o dispositivo de exibição 420 não deveria ser maior que 70 a 80 ms.
Esta latência deve considerar todos os fatores no caminho do dispositivo de entrada 421 nas premissas de usuário 211 para o serviço de hospedagem 210 e de volta novamente para as premissas de usuário 211 para o disposi- y tivo de exibição 422. A figura 4b ilustra os vários componentes e redes so- m bre os quais os sinais devem percorrer, e acima destes componentes e re- desestáuma linha de tempo que lista latências exemplificadoras que se es- peram em uma implantação prática.
Notar que a figura 4b está simplificada de modo que apenas o roteamento do caminho crítico seja mostrado.
Outro roteamento de dados usado para outros recursos do sistema está descrito abaixo.
Setas com duas pontas (por exemplo, seta 453) indicam latência de idae volta e setas com uma ponta (por exemplo, seta 457) indicam latência de um único trajeto, e "" denota uma medição aproximada.
Deve-se apontar que haverá situações de mundo real nas quais as latências listadas não po-
: 57/182 | dem ser alcançadas, mas em um número maior de casos no US, com o uso de DSL e conexões de modem a cabo em relação às premissas de usuário 211, estas latências podem ser alcançadas nas circunstâncias descritas no próximo parágrafo, Além disso, notar que, embora a conectividade sem fio —celularcom a Internet trabalhará certamente no sistema mostrado, a maioria | os sistemas de dados celulares de US (como EVDO) incorre em latências ! muito elevadas e não seriam capazes de alcanças as latências mostradas na figura 4b.
Entretanto, estes princípios subjacentes podem ser implanta- dos em futuras tecnologias de celular que podem ser capazes de implantar este nível de latência.
Adicionalmente, há cenários de aplicativos e jogos (por exemplo, jogos que não exigem tempo rápido de reação de usuário, como xadrez) onde a latência incorreu através de um sistema de dados de celular de US, embora notável pelo usuário, seria aceitável para o jogo ou E aplicativo.
A partir do dispositivo de entrada 421 nas premissas do usuário 211, uma vez que o usuário aciona o dispositivo de entrada 421, um sinal de controle de usuário é enviado ao cliente 415 (que pode ser um dispositivo autônomo como um conversor digital, ou pode ser software ou hardware em execução em outro dispositivo como um computador pessoal ou um disposi- tivo móvel), e é distribuído em pacotes (no formato UDP em uma modalida- de) e o pacote recebe um endereço de destino para alcançar o serviço de hospedagem 210. O pacote também irá conter informações para indicar de " qual usuário os sinais de controle estão sendo originados.
O(s) pacote(s) de f sinal(is) de controle é/são então emitidos através do dispositivo de Fire- wallRoteador/NAT (Tradução de Endereço de Rede) 443 para a interface WAN 442. A interface WAN 442 é o dispositivo de interface fornecido às premissas do usuário 211 por meio do ISP do usuário (Provedor de Serviços de Internet). A Interface WAN 442 pode ser um cabo ou modem DSL, um transceptor WiMax, um transceptor de fibra, uma interface de dados de celu- lar, uma interface de protocolo IP por rede elétrica, ou qualquer outra dentre muitas interfaces com a Internet.
Além disso, o dispositivo de Fire- walllRoteador/NAT 443 (e, possivelmente, a interface WAN 442) potte ser
. 58/182 integrado ao cliente 415. Um exemplo disso seria um telefone móvel, que ! | inclui software para implantar a funcionalidade do cliente domiciliar ou corpo- | rativo 415, bem como os meios para roteamento e conexão com a Internet ] por meio de comunicação sem fio através de algum padrão (por exemplo, ) 7 5 802119). A interface WAN 442, então, efetua o roteamento dos sinais de controle para o que poderia ser chamado na presente invenção de "ponto de presença" 441 do Provedor de Serviços de Internet (ISP) do usuário, que são as instalações que oferecem uma interface entre o transporte WAN co- À 10 —nectado às premissas do usuário 211 e a Internet geral ou rede privada.
As características do ponto de presença irão variar dependendo da natureza do serviço de Internet oferecido.
Em DSL, este tipicamente será um escritório É central de uma empresa de telefonia onde um DSLAM está localizado.
Para E modens a cabo, este tipicamente será um ponto central de recepção de si- nais da multioperadora de sistemas a cabo (MSO). Para sistemas de celula- res, este tipicamente será uma sala de controle associada à torre de celular.
Mas seja qual for a natureza do ponto de presença, este, então, irá efetuar o roteamento do(s) pacote(s) de sinal(is) de controle para a Internet geral 410. O(s) pacote(s) de sinal(is) de controle será/serão então roteado(s) para a interface WAN 441 do serviço de hospedagem 210, através daquilo que pro- vavelmente será uma interface do transceptor de fibra.
A WAN 441 irá, en- tão, efetuar o roteamento dos pacotes de sinais de controle para a lógica de - roteamento 409 (que pode ser implantada de diversas e diferentes maneiras, x incluindo comutadores Ethernet e servidores de roteamento), que avalia o endereço do usuário e efetua o roteamento do(s) sinal(is) de controle para o servidor correto 402 do usuário específico.
O servidor 402, então, adota os sinais de controle como entrada para o jogo ou aplicativo de software que está operando no servidor 402 e usa os sinais de controle para processar o próximo quadro do jogo ou aplica- tivo.
Uma vez que os próximos quadros | são gerados, o vídeo e o áudio são emitidos a partir do servidor 402 para o compressor de vídeo 404. O vídeo e o áudio podem ser emitidos a partir do servidor 402 para o compressor 404
E 59/182 J através de vários meios.
Para iniciar isto, o compressor 404 pode ser embu- tido no servidor 402, então, a compressão pode ser implantada localmente | | no interior do servidor 402. Ou, o vídeo e/ou áudio pode ser emitido na forma 1 de pacotes através de uma conexão de rede tal como uma conexão de E- 7 5 thernet para uma rede que é uma rede privada entre o servidor 402 e o ! compressor de vídeo 404, ou através de uma rede compartilhada, tal como | SAN 403. Ou, o vídeo pode ser emitido através de um conector de saída de | vídeo do servidor 402, tal como um conector DVI ou VGA e, então, captura- do pelo compressor de vídeo 404. Ademais, o áudio pode ser emitido a partir fasdaaa 10 do servidor 402 como áudio digital (por exemplo, através de um conector TOSLINK ou S/PDIF) ou como áudio analógico, que é digitalizado e encodi- ficado por lógica de compressão de áudio dentro do compressor de vídeo É 404. t Uma vez que o compressor de vídeo 404 capturou o quadro de vídeoeo áudio gerado durante aquele tempo de quadro do servidor 402, o compressor de vídeo irá comprimir o vídeo e o áudio com o uso de técnicas descritas abaixo.
Uma vez que o vídeo e o áudio é comprimido, isto é dis- posto em pacotes com um endereço para enviá-lo de volta para o cliente do usuário 415, e é roteado para a Interface WAN 441, que, então, roteia os pacotes de vídeo e áudio através da Internet geral 410, que, então, roteia os pacotes de vídeo e áudio para o ponto ISP de presença do usuário 441, que roteia os pacotes de vídeo e áudio para a interface WAN 442 nas premissas ” do usuários, que roteia os pacotes de vídeo e áudio para o dispositivo de à.
Firewall/Roteador/NAT 443, que, então, roteia os pacotes de vídeo e áudio paraocliente 415. O cliente 415 descomprime o vídeo e o áudio e, então, exibe o vídeo no dispositivo de exibição 422 (ou no dispositivo de exibição embutido no cliente) e envia o áudio para o dispositivo de exibição 422 ou para ampli- ficador/alto-falantes separados ou amplificador/alto-falantes embutidos no cliente.
Para o usuário perceber que todo o processo descrito agora está perceptivamente sem defasagem, o atraso de ida e volta precisa ser menor
; 60/182 | que 70 ou 80 ms.
Alguns dos atrasos de latência na trajetória de ida e volta descrita estão sob o controle do serviço de hospedagem 210 e/ou do usuário e outros não estão.
Entretanto, com base na análise e no teste de um gran- de número de cenários do mundo real, as seguintes são medições apropria- das O tempo de transmissão de um caminho para enviar os sinais de 1 controle 451 é tipicamente menor do que 1 ms, o roteiro de ida e volta atra- vés das premissas de usuário 452 é tipicamente realizado, usando pronta- mente comutadores Firewall/Router/NAT de grau de consumo disponíveis na Ethernet em cerca de 1 ms.
O ISPs de usuário pode variar amplamente em seus atrasos de ida e volta 453, mas com DSL e fornecedores de modem a cabo, se vê tipicamente entre 10 e 25 ms.
A latência de ida e volta na Inter- net geral 410 pode variar enormemente dependendo de como o tráfico é ro- E teado e se existem quaisquer falhas na rota (e essas questões são discuti- das abaixo), mas, tipicamente, a Internet geral fornece rotas justamente óti- mas e a latência é amplamente determinada pela velocidade da luz através de fibra óptica, dada a distância para o destino.
Conforme discutido adicio- nalmente abaixo, foram estabelecidas 1.000 milhas como uma distância a- proximadamente maior do que a esperada para colocar um serviço de hos- —pedagem 210 longe de premissas de usuário 211. Em 1.000 milhas (2.000 milhas de ida e volta) o tempo de transito prático para um sinal através da Internet é de aproximadamente 22 ms.
A Interface WAN 441 para o serviço " de hospedagem 210 é tipicamente uma interface de alta velocidade de fibra 5 de grau comercial com latência negligenciável.
Dessa forma, a latência da Internet geral 454 é tipicamente entre 1 e 10 ms.
A latência da rota de um caminho 455 através do serviço de hospedagem 210 pode ser alcançada em menos do que 1 ms.
O servidor 402 tipicamente computará um novo quadro para um jogo ou um aplicativo em menos do que um tempo de quadro (que em 60 fps é 16,7 ms) de modo que 16 ms seja uma latência de um caminho “máxima razoável 456 para o uso.
Em uma implantação de hardware otimi- zada da compressão de vídeo e algoritmos de compressão de áudio descrito aqui, a compressão 457 pode ser finalizada em 1 ms.
Em versões menos
; 61/182 | otimizadas, a compressão pode levar tanto quanto 6 ms (naturalmente, mesmo as versões menos otimizadas poderiam levar mais tempo, mas es- sas implantações impactariam na latência geral de ida e volta e exigiriam que outras latências fossem mais curtas (por exemplo, a distância permitida | 5 através da Internet geral poderia ser reduzida) para manter o alvo de latên- : í cia de 70 a 80 ms). As latências de ida e volta da Internet 454, ISP de Usuá- ! | rio 453 e Roteamento de Premissas do Usuário 452 foram ainda considera- das, de modo que o que resta é a latência da descompressão de vídeo 458 que, dependendo de se a descompressão de vídeo 458 é implantada em E. 10 hardware dedicado ou se é implantada em software em um dispositivo clien- te 415 (como um dispositivo móvel ou PC) essa pode variar dependendo do tamanho da exibição e do desempenho da CPU de descompressão. Tipica- mente, a descompressão 458 leva entre 1 e 8 ms.
. Dessa forma, ao adicionar todas as latências de pior caso vistas na prática, pode-se determinar a pior latência de caso de ida e volta que po- de ser esperada para ser experimentada por um usuário do sistema mostra- do na figura 4a. Essas são: 1+1+25+22+1+16+6+8 = 80 ms. E, de fato, na prática (com avisos discutidos abaixo), isso é aproximadamente a latência de ida e volta vista com o uso de versões de protótipo do sistema mostrado na figura 4a, usando PCs de Windows padrão como dispositivos clientes e conexões de modem a cabo e DSL home dentro do US. Naturalmente, os cenários melhores do que o pior caso podem resultar em latências muito Y mais curtas, mas esses não podem ser confiáveis mediante o desenvolvi- sã mento de um serviço comercial que é usado amplamente.
A fim de alcançar as latências listadas nas figuras 4b sobre a In- ternet em geral requer que o compressor de vídeo 404 e descompressor de vídeo 412 da figura 4a no cliente 415 gere um fluxo de pacote com caracte- rísticas muito particulares, de modo que a sequência de pacotes gerada a- través de todo o caminho desde o serviço de hospedagem 210 até o disposi- —tivode exibição 422 não está sujeito a atrasos ou perda de pacote excessiva e, em particular, se encaixa consistentemente com as restrições da largura de banda disponível ao usuário através da conexão à Internet do usuário
: 62/182 | através da interface WAN 442 e Firewall/Roteador/NAT 443. Adicionalmente, o compressor de vídeo deve criar um fluxo de pacote que é robusto o sufici- ente para tolerar a perda de pacote e reordenação de pacote inevitável que ' ocorre em transmissões de Internet e rede normais. | Compressão de Vídeo de Baixa Latência F | Para atingir os objetivos precedentes, uma modalidade utiliza Í ! uma nova abordagem para a compressão de vídeo que diminui os requeri- mentos de largura de banda para a latência e o pico para a transmissão de vídeo.
Antes da descrição destas modalidades, uma análise de técnicas de "compressão de vídeo atuais serão fornecidas com respeito à figura 5 e figu- ras 6a a b.
Naturalmente, estas técnicas podem ser empregadas de acordo com princípios fundamentais se o usuário é fornecido com largura de banda o suficiente para suportar a taxa de dados requisitada por estas técnicas.
E Note-se que a compressão de áudio não é tratada no presente documento a não ser para afirmar que a mesma é implementada simultaneamente e em sincronia com a compressão de vídeo.
Existem técnicas de compressão de áudio anteriores que satisfazem os requerimentos para este sistema.
A figura 5 ilustra uma técnica anterior em particular para com- primir vídeo no qual cada quadro de vídeo individual 501 a 503 é comprimido através de lógica de compressão 520 com o uso de um algoritmo de com- pressão particular para gerar uma série de quadros comprimidos 511 a 513. Uma modalidade desta técnica é "IPEG em movimento" na qual cada qua- Y dro é comprimido de acordo com um algoritmo de compressão de Grupo de Fl Peritos Fotográfico Comum (JPEG), baseado no transformação discreta de —cosseno(DCT). Vários tipos diferentes de algoritmos de compressão podem ser empregados, entretanto, embora ainda cumpra com esses princípios fundamentais (por exemplo, algoritmos de compressão baseados em ondas pequenas, como JPEG-2000). Um problema com este tipo de compressão é que reduz a taxa de dados de cada quadro, mas não explora as similaridades entre os quadros sucessivos para reduzir uma taxa de dados do fluxo contínuo total de vídeo.
Por exemplo, como ilustrado na figura 5, supondo uma taxa de
É 63/182 | quadro de 640x480x24bits/pixel = 640*480*24/8/1024=900 Kilobites/quadro (KB/quadro), para uma dada qualidade de imagem, movimento JPEG pode | apenas comprimir o fluxo por um fator de 10, resutando em um fluxo de | dados de 90 KB/quadro.
A 60 quadros/s, isto necessitaria de uma largura de | — banda de canal de 90 KB * 8 bits * 60 quadros/s = 42,2Mbps, o que seria ! | uma largura de banda muito grande para quase todas as as conexões É caseiras de internet nos Estados Unidos hoje em dia, e uma largura de banda muito grande para muitas conexões de internet de escritórios.
De fato, sabendo-se que precisa-se de um fluxo constante de dados em uma largura de banda tão grande, e estaria apenas servindo um usuário, mesmo em um ambiente LAN de escritório, consumiria uma grande porcentagem de uma largura de banda Ethernet LAN 100Mbps e sobrecarregar muito a É comutação de Ethernet que suporta a LAN.
Deste modo, a compressão para ; vídeo de moviento é ineficiente quando comparada com outras técnicas de compressão (como aquelas descritas abaixo). Além disso, um quadro único de algoritmos de compressão como JPEG e JPEG-2000 que usa algoritmos de compressão em perda produz artefatos de compressão que podem não estar visíveis em imagens estáticas (por exemplo, um artefato dentro de uma vegetação densa na cena pode não aparecer como um artefato, uma vez que os olhos não conhecem exatamente como a vegetação densa deve aparecer). Porém, uma vez que a cena está em movimento, um artefato pode se destacar uma vez que os olhos detectam que o artefato foi alterado " de quadro a quadro, apesar do fato de o artefato estar em uma área da cena Fm em que pode não estar visível em uma imagem estática.
Isto resulta na percepção do "ruído de fundo" na sequência de quadros, de aparência similar ao ruído do tipo "neve" visível durante recepção de TV analógica marginal.
Naturalmente, esse tipo de compressão pode ser usado ainda em certas modalidades descritas no presente documento, porém, em geral, para evitar ruído de fundo na cena, uma elevada taxa de dados (ou seja, uma baixa taxa de compressão) é necessária para uma determinada qualidade perceptiva.
Outros tipos de compactação, como H.264, ou Windows Media
. 64/182 | VC9, MPEG2 e MPEGA são mais eficientes para compactar um fluxo de vií- | deo, pois esses exploram as similaridades entre quadros sucessivos.
Essas | técnicas contam com as mesmas técnicas gerais de compactação de vídeo. ! Assim, embora o padrão H.264 seja descrito, os mesmos princípios gerais | se aplicam a vários outros algoritmos de compactação.
Um grande número | | de compactadores e descompactadores H.264 está disponível, inclusive a ' biblioteca de software de fonte aberta x264 para compactar H.264 e as bibli- otecas de software de fonte aberta FFmpeg para descompactar H.264. As figuras 6a e 6b ilustram uma técnica de compactação da téc- ; nica anterior exemplificativa em que uma série de quadros de vídeos des- compactados 501-503, 559-561 é compactada por lógica de compactação 620 em uma série de "quadros |" 611, 671; "P-quadros" 612-613; e "B- quadros" 670. O eixo geométrico vertical na figura 6a geralmente significa o : tamanho resultante de cada quadro codificado (embora os quadros não se- jam representados em escala). Como descrito acima, a codificação de vídeo utilizando I-quadros, B- quadros e P-quadros é bem entendida pelos elemen- tos versados na técnica.
Brevemente, um I-quadro 611 é uma compactação baseada em DCT de um quadro descompactado completo 501 (similar à imagem JPEG compactada como descrito acima). Os P-quadros 612-613 geralmente são significativamente menores em tamanho do que os |- quadros 611, pois esses tiram vantagem dos dados no I-quadro anterior ou P-quadro; ou seja, esses contêm dados indicando as alterações entre o " quadro | anterior ou P-quadro.
Os B-quadros 670 são similares àqueles de = P-quadros exceto pelo fato de que os B-quadros utilizam o quadro no se- guinte quadro de referência bem como potencialmente o quadro no quadro de referência anterior.
Para a discussão a seguir, supõe-se que a taxa de quadro dese- jada seja 60 quadros/segundo, que cada |-quadro seja aproximadamente 160 Kb, a média de P-quadro e B-quadro seja 16 Kb e que um novo |-quadro seja gerado a cada segundo.
Com esse conjunto de parâmetros, a taxa de dados média poderia ser: 160 Kb + 16 Kb 59 = 1,1Mbps.
Essa taxa de da- dos está bem situada dentro da taxa de dados máxima para muitas cone-
. 65/182 | xões de Internet de banda larga atuais a residências e escritórios.
Essa téc- nica também tende a evitar o problema de ruído de fundo de codificação somente intraquadro, pois os P e B quadros rastreiam diferenças entre os quadros, então os artefatos de compactação não tendem a aparecer e desa- 7 5 parecer de quadro para quadro, reduzindo assim o problema de ruído de | fundo descrito acima. | Um problema com os tipos anteriores de compactação é que : embora a taxa de dados média seja relativamente baixa (por exemplo, 1,1Mbps), um único I|-quadro pode levar vários tempos de quadro para reali- : 10 zara transmissão.
Por exemplo, utilizando as práticas da técnica anterior, uma conexão de rede de 2,2 Mbps (por exemplo, DSL ou modem a cabo com pico de 2,2Mbps de taxa de dados máxima disponível 302 da figura 3a) Ú poderia ser tipicamente adequada para transmitir o vídeo em 1,1 Mbps com ; um quadro | de 160Kbps a cada 60 quadros.
Isso poderia ser realizado ao enfileirar o descompactador 1 segundo de vídeo antes de descompactar o vídeo.
Em 1 segundo, 1,1Mb de dados poderia ser transmitido, isso poderia ser facilmente acomodado por uma taxa de dados máxima disponível de 2,2Mbps, mesmo supondo que a taxa de dados disponível possa cair perio- dicamente até 50%. Infelizmente, essa abordagem da técnica anterior pode- ria resultar em uma latência de 1 segundo para o vídeo devido ao buffer de vídeo de 1 segundo no receptor.
Tal atraso é adequado para muitas aplica- ções da técnica anterior (por exemplo, a reprodução de vídeo linear), porém ; é uma latência longa para videogames de ação rápida que não podem tole- FF rar mais de 70 a 80ms de latência.
Se uma tentativa for feita para eliminar o buffer de vídeo de 1 segundo, ainda não poderia resultar em uma redução adequada em latência para videogames de ação rápida.
Para alguém, o uso de B-quadros, como anteriormente descrito, poderia precisar da recepção de todos os B-quadros que precedem um I-quadro bem como o I-quadro.
Se for considerado que os — 59 não-l quadros são mais ou menos divididos entre os P e B quadros, então poderia haver pelo menos 29 B-quadros e um |-quadro recebido antes que qualquer B-quadro possa ser exibido.
Assim, independente da largura de
- 66/182 | banda disponível do canal, poderia ser necessário um atraso de 29+1=30 quadros de duração de 1/60 segundo cada, ou 500ms de latência.
Clara- mente que é excessivamente longo.
Assim, outra abordagem poderia ser eliminar os B-quadros e uti-
lizar apenas os | e P-quadros. (Uma consequência disso é que a taxa de | dados poderia aumentar para um determinado nível de qualidade, porém em | consideração à consistência nesse exemplo, continua-se a considerar que É cada I|-quadro possui 160Kb e o P-quadro médio possui 16Kb de tamanho, e assim a taxa de dados ainda é 1,1Mbps). Essa abordagem elimina a latência inevitável introduzida por B-quadros, visto que a decodificação de cada P- quadro depende apenas do quadro recebido anterior.
Um problema que permanece com essa abordagem é que um I-quadro é muito maior do que
: um P-quadro médio, aquele em um canal de largura de banda baixa, como é ; típico na maioria das residências e em muitos escritórios, a transmissão do |-
— quadro acrescenta latência substancial.
Isso é ilustrado na figura 6b.
A taxa de dados de fluxo de vídeo 624 está abaixo da taxa de dados máxima dis- ponível 621 exceto para os I|-quadros, onde a taxa de dados pico exigida para os |-quadros 623 excede muito a taxa de dados máxima disponível 622 (e ainda a taxa de dados máxima classificada 621). A taxa de dados exigida pelos P-quadros é menor do que a taxa de dados máxima disponível.
Mes- mo que a taxa de dados máxima disponível chegue ao máximo em 2,2Mbps essa permanece constante em sua taxa de pico de 2,2Mbps, serão necessá-
y rios 160Kb/2,2Mb=71ms para transmitir o l|-quadro, e se a taxa de dados ias máxima disponível 622 cair para 50% (1,1Mbps), serão necessários 142ms para transmitir o I-quadro.
Então, a latência para transmitir o I-quadro será reduzida em algum lugar entre 71 a 142ms.
Essa latência é aditiva às latên- cias identificadas na figura 4b, que no pior caso adicionou 70 ms, então isso poderia resultar em uma latência de ida e volta total de 141 a 22Pms a partir do ponto que o usuário atua o dispositivo de entrada 421 até uma imagem aparecer no dispositivo de exibição 422, essa é muito alta.
E se a taxa de dados máxima disponível cair abaixo de 2,2Mbps, a latência irá aumentar adicionalmente.
- 67/182 | Nota-se também que geralmente há consequências severas pa- ra "interferência" de um ISP com taxa de dados de pico 623 que excede mui- to a taxa de dados disponível 622. O equipamento em ISPs diferentes irão se comportar de forma diferente, porém os comportamentos a seguir são | 7 5 — muito comuns entre DSL e ISPs de modem a cabo quando os pacotes forem Í recebidos em uma taxa de dados muito maior do que a taxa de dados dispo- | nível 622: (a) atrasar os pacotes ao colocar os mesmos na fila (latência de Í introdução), (b) descartar alguns ou todos os pacotes, (c) desabilitar a cone- xão durante um período de tempo (mais provavelmente devido ao ISP ser Eaiaas 10 — referido como um ataque malicioso, como ataque de "negação de serviço"). Assim, a transmissão de um fluxo de pacotes em taxa de dados total com características como aquelas mostradas na figura 68b não é uma opção viá- f vel.
Os picos 623 podem ser enfileirados no serviço de hospedagem 210 e " enviados em uma taxa de dados abaixo da taxa de dados máxima disponí- vel, introduzindo a latência inaceitável descrita no parágrafo anterior.
Ademais, a sequência de taxa de dados de fluxo de vídeo 624 mostrada na figura 6b é uma sequência de taxa de dados de fluxo de vídeo É muito "enfadonha" e poderia ser a classificação de sequência de taxa de dados que alguém poderia esperar que resulte da compactação do vídeo de uma sequência de vídeo que não muda muito e possui muito pouco movi- mento (por exemplo, como é comum em teleconferência de vídeo onde as câmeras estão em uma posição fixa e possuem pouco movimento, e os ob- y jetos, na cena, por exemplo, pessoas conversando sentadas, mostram pou- FF co movimento). A sequência de taxa de dados de fluxo de vídeo 634 mostrada na figura 6c é uma sequência típica do que alguém poderia esperar ver do vídeo com muito mais ação, conforme deve ser gerado em um filme cinema- tográfico ou um videogame, ou em algum software de aplicativo.
Nota-se que além dos picos de I-quadro 633, também há picos de P-quadro como 635 e636 que são muito grandes e excedem a taxa de dados máxima dis- ponível em muitas ocasiões.
Embora esses picos de P-quadro não sejam tão grandes quanto os picos de |-quadro, esses ainda são muito grandes para
E 68/182 ! serem transmitidos pelo canal em taxa de dados total, e conforme com os picos de I|-quadro, esses picos de P-quadro devem ser lentamente transmiti- dos (com isso há cada vez mais latência). | Em um canal de largura de banda alta (por exemplo, uma LAN | 5 —de100Mbps, ou uma conexão privada de largura de banda alta de 100Mbps) | a rede poderia ser capaz de tolerar grandes picos, como picos de |-quadro 633 ou picos de P-quadro 636, e em princípio, a baixa latência poderia ser mantida.
Porém, tais redes são frequentemente compartilhadas entre muitos iSsSa usuários (por exemplo, em um ambiente de trabalho), e tais dados "com pi e. 10 cos" poderiam causar um impacto no desempenho da LAN, particularmente se o tráfego de rede for roteado até uma conexão compartilhada privada (por exemplo, de um centro de dados remoto até um escritório). Para começar, á deve-se ter em mente que esse exemplo possui um fluxo de vídeo de reso- lução relativamente baixa de 640x480 pixels em 60fps.
Os fluxos de HDTV de 1920x1080 em 60fps são facilmente manipulados por computadores e monitores modernos, e as exibições de resolução 2560x1440 em 60fps es- tão cada vez mais disponíveis (por exemplo, monitor da Apple, Inc.'s 30"). É Uma sequência de vídeo de alta ação em 1920x1080 em 60fps pode exigir 4,5 Mbps utilizando compactação H.264 para um nível de qualidade razoá- vel Se for adotado o pico de |-quadros em 10X a taxa de dados nominal, que poderia resultar em picos de 45Mbps, bem como o pico de P-quadro menor, porém ainda considerável.
Se vários usuários estiverem recebendo - fluxos de vídeo na mesma rede de 100Mbps (por exemplo, uma conexão de f rede privada entre um escritório e um centro de dados), é fácil observar co- moos picos de fluxo de vídeo de vários usuários poderiam se alinhar, co- brindo a largura de banda da rede, e potencialmente cobrindo a largura de banda das placas traseiras dos comutadores que sustentam os usuários na : rede.
Mesmo no caso de uma rede Gigabit Ethernet, se usuários suficientes possuírem picos suficientes alinhados de uma só vez, isso poderia cobrir a rede ou comutadores de rede.
E, uma vez que o vídeo de resolução 2560x1440 se torna mais comum, a taxa de dados de fluxo de vídeo média pode ser 9,5Mbps, resultando talvez em uma taxa de dados de pico de ái 69/182 í 95Mbps.
É evidente que uma conexão de 100Mbps entre um centro de da- dos e um escritório (que hoje em dia é uma conexão excepcionalmente rápi- | da) poderia ser completamente ocupada pelo tráfego de picos de um único | | usuário.
Assim, mesmo que as LANs e conexões de rede privada possam r Í 5 —sermais tolerantes de vídeo de fluxo com picos, o vídeo de fluxo com altos | i picos não é desejado e deve exigir planejamento e acomodação especial por | um departamento de IT do escritório. " Naturalmente, para aplicações de vídeo lineares padrão, essas questões não são um problema, pois a taxa de dados é "atenuada" no ponto detransmissão e os dados de cada quadro abaixo da taxa de dados dispo- nível máxima 622, e um buffer nos armazenamentos de cliente uma sequên- cia de |, P e B quadros antes de serem descompactados.
Assim, a taxa de á dados sobre a rede permanece próxima à taxa de dados média do fluxo de " vídeo.
Infelizmente, isso introduz latência, mesmo que os B-quadros não sejam usados, isso é inaceitável para aplicações de baixa latência como vi- deogames e aplicações que exigem tempo de resposta rápido.
Uma solução da técnica anterior para mitigar os fluxos de vídeo Á que possuem altos picos é utilizar uma técnica geralmente referida como codificação de "Taxa de Bits Constante" (CBR). Embora possa parecer que otermo CBR sugere que todos os quadros sejam compactados para possuir a mesma taxa de bits (ou seja, tamanho), o que geralmente refere-se é um paradigma de compactação onde uma taxa de bits máxima sobre um deter- = minado número de quadros (nesse caso, 1 quadro) é permitida.
Por exem- plo, no caso da figura 6c, se uma restrição de CBR for aplicada à codificação que limitou a taxa de bits, por exemplo, a 70% da taxa de dados máxima classificada 621, então o algoritmo de compactação poderia limitar a com- pactação de cada quadro de modo que qualquer quadro que poderia ser normalmente compactado utilizando mais de 70% da taxa de dados máxima classificada 621 possa ser compactado com menos bits.
O resultado disso é — que os quadros que normalmente poderiam exigir mais bits para manter um determinado nível de qualidade poderiam ser "privados" de bits e a qualida- de de imagem desses quadros poderia ser pior do que aquele de outros quadros que não exigem mais bits do que 70% da taxa de dados máxima | classificada 621. Essa abordagem pode produzir resultados aceitáveis para determinados tipos de vídeo compactado onde há (a) pouco movimento ou alterações de cena são esperadas e (b) os usuários podem aceitar a degra- i 5 dação de qualidade periódica. Um bom exemplo de uma aplicação adequa- f | da para CBR é a teleconferência de vídeo visto que há poucos picos, e se a [ qualidade se degradar brevemente (por exemplo, se a câmera for deslocada, resultando em movimento de cena significativo e grandes picos, durante o deslocamento pode não haver bits suficientes para compactação de imagem dealta qualidade, que poderia resultar em qualidade de imagem degradada), é aceitável para a maioria dos usuários. Infelizmente, a CBR não é bem a- dequada para muitas outras aplicações que possuem cenas de alta comple- ii xidade ou um movimento muito grande e/ou quando um nível de qualidade . razoavelmente constante for exigido.
A lógica de compactação de baixa latência 404 empregada em uma modalidade utiliza diversas técnicas diferentes para atender a faixa de problemas com o fluxo de vídeo compactado de baixa latência, enquanto . mantém a alta qualidade. Primeiro, a lógica de compactação de baixa latên- cia 404 gera apenas |-quadros e P-quadros, reduzindo assim a necessidade de esperar vários tempos de quadro para decodificar cada B-quadro. Ade- mais, como ilustrado na figura 7a, em uma modalidade, a lógica de compac- tação de baixa latência 404 subdivide cada quadro não compactado 701-760 = em uma série de "blocos" e codifica individualmente cada bloco como um |- : quadro ou um P-quadro. O grupo de |-quadros e P-quadros compactados é referido aqui como "quadros R" 711-770. No exemplo específico mostrado na figura 7a, cada quadro não compactado é subdividido em uma matriz 4 x 4 de 16 blocos. Entretanto, esses princípios subjacentes não são limitados a nenhum esquema de subdivisão particular.
; Em uma modalidade, a lógica de compactação de baixa latência 404 divide o quadro de vídeo em inúmeros blocos, e codifica (ou seja, com- pacta) um bloco de cada quadro como um I|-quadro (ou seja, o bloco é com- pactado como se fosse um quadro de vídeo separado de 1/16 o tamanho da
: 71/1182 | imagem total, e a compactação usada para esse "mini" quadro é a compac- | tação de I-quadro) e os blocos restantes como P-quadros (ou seja, a com- | pactação usada para cada "mini" 1/16"" quadro é a compactação de P- quadro). Os blocos compactados como I-quadros e como P-quadros devem | | 5 serreferidos como "blocos |" e "blocos P", respectivamente.
Com cada qua- r | dro de vídeo sucessivo, o bloco que será codificado como um I-bloco é alte- [ rado.
Assim, em um determinado tempo de quadro, apenas um bloco dos blocos no quadro de vídeo é um I-bloco, e o restante dos blocos consiste EEE nos blocos P.
Por exemplo, na figura 7a, o bloco O de quadro não compacta- do7016é codificado como o |-I-tiley e o restante de 1 a 15 blocos é codificado : como blocos P P, a P15 para produzir o quadro R 711. No próximo quadro de vídeo não compactado 702, o bloco 1 de quadro não compactado 701 é co- À dificado como o I-I-tile, e os blocos restantes 0 e 2 a 15 são codificados co- : mo blocos P, Po e Pa P15, para produzir o quadro R 712. Assim, os blocos | eos blocos P para os blocos são progressivamente intercalados em tempo sobre os sucessivos quadros.
O processo continua até um bloco R 770 ser gerado com o último bloco na matriz codificada como um I-bloco (ou seja, É l15). O processo então começa gerando outro quadro R como quadro 711 (ou seja, codificando um I-bloco para o bloco 0) etc.
Embora não ilustrado na figura7a, em uma modalidade, o primeiro quadro R da sequência de vídeo de quadros R contém apenas os blocos (ou seja, de modo que os P-quadros subsequentes possuam dados de imagem de referência a partir dos quais = calcula-se o movimento). Alternativamente, em uma modalidade, a sequên- " cia de inicialização utiliza o mesmo padrão de I-bloco normal, porém não —incluio blocos P daqueles blocos que ainda não foram codificados com um |- bloco.
Em outras palavras, alguns blocos não são codificados com nenhum dado até o primeiro I-bloco chegar, evitando assim os picos de inicialização h na taxa de dados de fluxo de vídeo 934 na figura 9a, que é explicada em mais detalhes abaixo.
Ademais, como descrito abaixo, vários tamanhos e formatos diferentes podem ser usados para os blocos enquanto ainda estão de acordo com os princípios subjacentes.
A lógica de descompactação de vídeo 412 que é executada no
E 72/182 | cliente 415 descompacta cada bloco como se fosse uma sequência de vídeo separada de quadros pequenos | e P, e então apresenta cada bloco ao dis- | positivo de exibição de direção de buffer de quadro 422. Por exemplo, lo e Po L de quadros R 711 a 770 são usados para descompactar e apresentar o blo-
co0Odaimagem de vídeo.
Similarmente, |, e P, de quadros R 711 a 770 são | | usados para reconstruir o bloco 1, e assim por diante.
Como mencionado [ ' acima, a descompactação de I-quadros e P-quadros é bem conhecida na i técnica, e a descompactação de blocos | e blocos P pode ser realizada com : múltiplas instâncias de um descompactador de vídeo que é executado no cliente 415. Embora pareça que os processos de multiplicação aumentam a Ê carga computacional no cliente 415, isso de fato na ocorre devido ao fato de os próprios blocos serem proporcionalmente menores em relação ao número : de processos adicionais, então o número de pixels exibido é o mesmo como se houvesse um processo e utilizando quadros | e P de tamanho total con- vencionais.
Essa técnica de quadro R mitiga significativamente os picos de largura de banda tipicamente associados aos I-quadros ilustrados nas figu- É ras 6b e 6c, pois qualquer determinado quadro é geralmente constituído de P-quadros que são tipicamente menores do que os I-quadros.
Por exemplo, —supondo-se novamente que um l|-quadro típico seja 160Kb, então os | blocos de cada um dos quadros ilustrados na figura 7a poderiam ser aproximada- mente 1/16 desse total ou 10Kb.
Similarmente, supondo-se que um P- - quadro típico tenha 16 Kb, então os P-quadros de cada um dos blocos ilus- : trados na figura 7a podem ter aproximadamente 1Kb.
O resultado final é um quadro R de aproximadamente 10Kb + 15 * 1Kb = 25Kb.
Então, cada se- quência de 60 quadros poderia ter 25Kb * 60 = 1,5Mbps.
Então, em 60 qua- dros/segundo, poderia ser exigido um canal capaz de sustentar uma largura de banda de 1,5Mbps, porém com picos muito menores devido ao fato de os | blocos serem distribuídos ao longo do intervalo de 60 quadros.
Nota-se que em exemplos anteriores com as mesmas taxas de dados presumidas para os |-quadros e P-quadros, a taxa de dados média era de 1,1Mbps.
Isso porque nos exemplos anteriores, um novo l-quadro foi
| introduzido somente uma vez a cada 60 tempos de quadro, enquanto nesse Í exemplo, os 16 blocos que constituem um ciclo de I-quadro em 16 tempos de quadro, e com isso o equivalente de um |-quadro é introduzido a cada 16 tempos de quadro, resultando em uma taxa de dados média ligeiramente maior.
Na prática, no entanto, a introdução de quadros | mais frequentes não [ | aumenta a taxa de dados de maneira linear.
Isso se deve ao fato de que um Í P-quadro (ou um bloco P) codifica principalmente a diferença do quadro an- ' terior para o próximo.
Então, se o quadro anterior for muito similar ao próxi- aasaa mo quadro, o P-quadro será muito pequeno, se o quadro anterior for muito diferente do próximo quadro, o P-quadro será muito grande.
Porém, devido ao fato de um P-quadro ser amplamente derivado do quadro anterior, em vez do quadro real, o quadro codificado resultante pode conter mais erros Í (por exemplo, artefatos visuais) do que um I-quadro com um número ade- : quado de bits.
E, quando um P-quadro acompanhar outro P-quadro, o que pode ocorrer é um acúmulo de erros que fica pior quando há uma sequência longa de P-quadros.
Agora, um compactador de vídeo sofisticado irá detec- tar o fato que a qualidade da imagem está se degradando após uma se- É quência de P-quadros e, se necessário, esse irá alocar mais bits nos P- quadros subsequentes para criar a qualidade ou, se esse for o curso de a- çãomais eficiente, substitui-se um P-quadro por um I|-quadro.
Então, quando sequências de P-quadros longas forem usadas (por exemplo, 59 P-quadros, como nos exemplos anteriores acima) particularmente quando a cena possui - uma complexidade e/ou movimento muito grande, tipicamente, mais bits são " necessários para os P-quadros à medida que são mais afastados de um |- quadro.
Ou, para considerar os P a partir do ponto de vista oposto, os P- quadros que acompanham estreitamente um |-quadro tendem a exigir me- nos bits do que os P-quadros que estão mais afastados de um |-quadro.
En- tão, no exemplo mostrado na figura 7a, nenhum P-quadro está afastado —maisdo que 15 quadros de um |-quadro que precede o mesmo, enquanto no exemplo anterior, um P-quadro poderia estar 59 quadros afastado de um |- quadro.
Assim, com |-quadros mais frequentes, os P-quadros são menores.
E 74/182 Naturalmente, os tamanhos relativos exatos irão variar com base na nature- Í za do fluxo de vídeo, porém no exemplo da figura 7a, se um bloco possuir ] 10Kb, os blocos P em média, podem possuir apenas 0,75kb de tamanho, resultando em 10Kb + 15 * 0,75Kb = 21,25Kb, ou em 60 quadros por segun- : 5 do, ,ataxade dados poderia possuir 21,25Kb * 60 = 1,3Mbps, ou taxa de da- [ Í dos cerca de 16% maior do que um fluxo com um | acompanhado por 59 P- | quadros em 1,1Mbps. Novamente, os resultados relativos entre essas duas | abordagens para a compactação de vídeo irão variar dependendo da se- E quência de vídeo, porém tipicamente, descobriu-se empiricamente que a utilização de quadros R exige cerca de 20% mais bits para um determinado : nível de qualidade do que a utilização de sequências de I-quadro/P. Porém, naturalmente, os quadros R reduzem dramaticamente os picos que tornam Í as sequências de vídeo utilizáveis com muito menos latência do que as se- . quências de I-quadro/P.
Os quadros R podem ser configurados em uma variedade de formas diferentes, dependendo da natureza da sequência de vídeo, da con- fiabilidade do canal, e da taxa de dados disponível. Em uma modalidade al- É ternativa, um número de blocos que não 16 é usado em uma configuração 4x4. Por exemplo, 2 blocos podem ser usados em uma configuração 2x1 ou 1x2,4 blocos podem ser usados em uma configuração 2x2, 4x1 ou 1x4, 6 blocos podem ser usados em uma configuração 3x2, 2x3, 6x1 ou 1x6 ou 8 blocos podem ser usados em uma configuração 4x2 (como mostrado na fi- ” gura 7b), 2x4, 8x1 ou 1x8. Nota-se que os blocos não precisam ser quadra- g dos, nem o quadro de vídeo deve ser quadrado, ou ainda retangular. Os blo- cos podem ser divididos em qualquer formato que melhor se ajustar ao fluxo de vídeo e à aplicação usada.
Em outra modalidade, o ciclo dos blocos | e P não é limitado ao número de blocos. Por exemplo, em uma configuração 4x2 de 8 blocos, uma sequência de 16 ciclos ainda pode ser usada como ilustrado na figura 7b. Os quadros não compactados sequenciais 721, 722, 723 são divididos em 8 blocos, O a 7 e cada bloco é individualmente compactado. A partir do quadro R 731, apenas o bloco O é compactado como um I-bloco, e os blocos restan-
E 75/182 tes são compactados como P blocos.
Para o quadro R subsequente 732 to- | dos os 8 blocos são compactados como P blocos, e então para o quadro R subsequente 733, o bloco 1 é compactado como um I-bloco e os outros blo- cos são compactados como P blocos.
E, então o sequenciamento continua | | 5 durante 16 quadros, com um I-bloco gerado apenas a cada outro quadro, Í ! então o último I-bloco é gerado para o bloco 7 durante o 15 tempo de qua- | dro (não mostrado na figura 7b) e durante o 16º tempo de quadro R o quadro 780 é compactado utilizando todos os P blocos.
Então, a sequência começa E novamente com o bloco O compactado como um I-bloco e os outros blocos compactados como P blocos.
Como na modalidade anterior, o primeiro qua- dro de toda a sequência de vídeo poderia ser tipicamente todos os | blocos, para fornecer uma referência para P blocos daquele ponto em diante.
O ciclo í dos | blocos e P blocos ainda não precisa ser um múltiplo par do número de - blocos.
Por exemplo, com 8 blocos, cada quadro com um I-bloco pode ser acompanhado por 2 quadros com todos os P blocos, antes de outro I-bloco ser usado.
Ainda em outra modalidade, alguns blocos podem ser sequencia- dos com blocos mais frequentemente do que outros blocos se, por exemplo, : considera-se que determinadas áreas da tela exigem mais movimento de | blocos frequentes, enquanto outras são mais estáticas (por exemplo, mos- trando uma pontuação de um jogo) exigindo blocos menos frequentes.
Ade- mais, embora cada I-quadro seja ilustrado nas figuras 7a-b como um único |- bloco, múltiplos | blocos podem ser codificados em um único quadro (depen- - dendo da largura de banda do canal de transmissão). Em contrapartida, de- r terminados quadros ou sequências de quadro podem ser transmitidos sem —oslblocos (ou seja, apenas os P blocos). O motivo no qual as abordagens do parágrafo anterior funcio- nam bem é que embora não tenha | blocos distribuídos para cada quadro único, pode parecer que resulte em picos maiores, o comportamento do sis- tema não é tão simples.
Visto que cada bloco é compactado separadamente dos outros blocos, à medida que os blocos ficam menores, a codificação de bloco pode se tornar menos eficiente, pois o compactador de um determina- do bloco não é capaz de explorar características de imagem similares e mo-
! vimento similar dos outros blocos.
Assim, a divisão da tela em 16 blocos ge- | ralmente irá resultar em uma codificação menos eficiente do que a divisão da tela em 8 blocos.
Porém, se a tela for dividida em 8 blocos e isso fizer com que os dados de um quadro total | sejam introduzidos a cada 8 quadros | 5 emvezdea cada 16 quadros, irá resultar em um total de taxa de dados mui- [ | to maior.
Então, ao introduzir um quadro total | a cada 16 quadros em vez de | a cada 8 quadros, a taxa de dados total é reduzida.
Também, ao utilizar 8 blocos maiores em vez de 16 blocos menores, a taxa de dados total é redu- E zida, isso também mitiga até determinado ponto os picos de dados causados pelos blocos maiores.
E Em outra modalidade, a lógica de compactação de vídeo de bai- xa latência 404 nas figuras 7a e 7b controla a alocação de bits nos vários É blocos nos quadros R mediante pré-configuração por configurações, com E base em características conhecidas da sequência de vídeo que será com- —pactada, ou automaticamente, com base em uma análise contínua da quali- dade de imagem em cada bloco.
Por exemplo, em alguns jogos de corrida, a frente do carro do jogador (que está relativamente estática na cena) ocupa É uma grande parte da metade inferior da tela, enquanto a metade superior da tela é completamente preenchida com a estrada em sentido contrário, edifí- ciose paisagem, que quase sempre está em movimento.
Se a lógica de com- pactação 404 alocar um número igual de bits em cada bloco, então os blocos sobre a metade inferior da tela (blocos 4 a 7) no quadro não compactado 721 - na figura 7b, serão geralmente compactados com qualidade superior aos blo- + cos na metade superior da tela (blocos O a 3) no quadro não compactado 721 —nafigura7b.
Se for considerado que esse jogo particular, ou essa cena parti- cular do jogo possui tais características, então os operadores do serviço de hospedagem 210 podem configurar a lógica de compactação 404 para alocar : mais bits nos blocos na parte superior da tela do que nos blocos na parte infe- rior da tela.
Ou, a lógica de compactação 404 pode avaliar a qualidade da compactação dos blocos após os quadros serem compactados (utilizando uma ou mais das várias métricas de qualidade de compactação, como Razão Máxima Entre Sinal-Ruído (PSNR)) e se for determinado que sobre uma de-
terminada janela de tempo, alguns blocos estão consistentemente produzindo | melhores resultados de qualidade, então essa aloca gradualmente mais bits í nos blocos que estão produzindo resultados de qualidade inferior, até os vá- rios blocos atingirem um nível de qualidade similar.
Em uma modalidade al- | 5 ternativa, a lógica de compactador 404 aloca bits para atingir uma qualidade Fr Í superior em um bloco particular ou grupo de blocos.
Por exemplo, a mesma | pode proporcionar uma melhor aparência perceptual geral para possuir maior qualidade no centro da tela do que nas bordas. ; Em uma modalidade, para aprimorar a resolução de algumas re- giões do fluxo de vídeo, a lógica de compactação de vídeo 404 utiliza blocos . menores para codificar áreas do fluxo de vídeo com complexidade e/ou mo- vimento de cena relativamente maior do que as áreas do fluxo de vídeo com complexidade e/ou movimento de cena relativamente menor.
Por exemplo, E como ilustrado na figura 8, blocos menores são empregados em torno de um personagem em movimento 805 em uma área de um quadro R 811 (poten- cialmente acompanhada por uma série de quadros R com os mesmos tama- nhos de bloco (não mostrados)). Então, quando o personagem 805 se move f para uma nova área da imagem, blocos menores são usados em torno des- sa nova área dentro de outro quadro R 812, como ilustrado.
Como mencio- nado acima, vários tamanhos e formatos diferentes podem ser empregados como "blocos" enquanto ainda estão de acordo com esses princípios subja- centes. = Embora os blocos I/P cíclicos descritos acima reduzam substan- : cialmente os picos na taxa de dados de um fluxo de vídeo, esses não elimi- nam os picos completamente, particularmente no caso de imagem de vídeo altamente complexa ou que muda rapidamente, como ocorre com imagens em movimento, videogames, e algum software de aplicação.
Por exemplo, durante uma transição repentina de cena, um quadro complexo pode ser acompanhado por outro quadro complexo que é completamente diferente.
Mesmo que vários blocos | possam ter precedido a transição de cena em apenas alguns tempos de quadro, esses não ajudam nessa situação, pois o material do novo quadro não tem relação com os blocos | anteriores.
Em tal
| situação (e em outras situações em que mesmo que nada mude, grande par- te da imagem muda), o compactador de vídeo 404 irá determinar que mui- | tos, se não todos, os blocos P são codificados de maneira mais eficiente que | os blocos |, e o resultado é um pico muito grande na taxa de dados daquele F | 5 quadro. L : Como anteriormente discutido, é simplesmente o caso que com | a maior parte das conexões de Internet a nível de consumidor (e muitas co- nexões de escritório), simplesmente não é viável "obstruir" dados que exce- E dem a taxa de dados máxima disponível mostrada como 622 na figura 6c, juntamente com a taxa de dados máxima classificada 621. Nota-se que a a taxa de dados máxima classificada 621 (por exemplo, "DSL de 6Mbps") é essencialmente um número de marketing para usuários considerando a a- F quisição de uma conexão de Internet, porém geralmente não garante um E nível de desempenho. Para os propósitos dessa aplicação, é irrelevante, visto que a única preocupação é a taxa de dados máxima disponível 622 no momento em que o vídeo é transmitido através da conexão. Consequente- mente, nas figuras 9a e 9c, como descrito aqui uma solução para o problema Í de formação de pico, a taxa de dados máxima classificada é omitida do grá- fico, e apenas a taxa de dados máxima disponível 922 é mostrada. A taxa de dados de fluxo de vídeo não deve exceder a taxa de dados máxima disponí- vel 922.
Para atender isso, a primeira coisa que o compactador de vídeo i-: 404 faz é determinar uma taxa de dados de pico 941, que é uma taxa de dados que o canal é capaz de manipular constantemente. Essa taxa pode ser determinada por inúmeras técnicas. Uma tal técnica é enviar gradual- mente um fluxo de teste de taxa de dados cada vez maior do serviço de hospedagem 210 para o cliente 415 nas figuras 4a e 4b, e fazer com que o cliente forneça um retorno ao serviço de hospedagem para o nível de perda de e latência. À medida que a perda de pacote e/ou latência começa a mos- trar um forte aumento, que é uma indicação que a taxa de dados máxima disponível 922 está sendo atingida. Após isso, o serviço de hospedagem 210 pode reduzir gradualmente a taxa de dados do fluxo de teste até o cliente
À 415 relatar que um período de tempo razoável no qual o fluxo de teste foi | recebido com um nível de perda de pacote e latência aceitável é quase míi- nimo.
Isso estabelece uma taxa de dados máxima de pico 941, que será en- | tão usada como uma taxa de dados de pico para transmitir o vídeo.
Ao longo i 5 dotempo, a taxa de dados de pico 941 irá flutuar (por exemplo, se outro u- [ ! suário em uma família começar a usar excessivamente a conexão de Inter- i net), e o cliente 415 precisará monitorar constantemente o mesmo para ob- servar se a perda de pacote ou latência aumentou, indicando que a taxa de NENE) dados máxima disponível 922 está caindo abaixo da taxa de dados de pico anteriormente estabelecida 941, e nesse caso, a taxa de dados de pico 941. : Similarmente, se ao longo do tempo o cliente 415 notar que a perda de pa- cote e latência permanecem em níveis ótimos, o mesmo pode solicitar que o : compactador de vídeo aumenta lentamente a taxa de dados para observar F se a taxa de dados máxima disponível aumentou (por exemplo, se outro u- —suário em uma família parou de usar excessivamente a conexão de Inter- net), e novamente aguarda até a perda de pacote e/ou latência maior indicar que a taxa de dados máxima disponível 922 foi excedida, e novamente um É nível inferior pode ser encontrado para a taxa de dados de pico 941, porém há um que talvez seja maior do que o nível antes de testar uma taxa de da- dos aumentada.
Então, ao utilizar essa técnica (e outras técnicas como es- sa) uma taxa de dados de pico 941 pode encontrada, e ajustada periodica- mente quando necessário.
A taxa de dados de pico 941 estabelece a taxa de rm dados máxima que pode ser usada pelo compactador de vídeo 404 para o fluxo de vídeo até o usuário.
A lógica para determinar a taxa de dados de pico pode ser implementada nas premissas de usuário 211 e/ou no serviço de hospedagem 210. Nas premissas de usuário 211, o dispositivo de cliente 415 realiza os cálculos para determinar a taxa de dados de pico e transmitir essas informações novamente para o serviço de hospedagem 210; no servi- ço de hospedagem 210, um servidor 402 no serviço de hospedagem realiza os cálculos para determinar a taxa de dados de pico com base nas estatísti- cas recebidas do cliente 415 (por exemplo, perda de pacote, latência, taxa de dados máxima, etc).
A figura 9a mostra um exemplo de taxa de dados de fluxo de vi- | deo 934 que possui complexidade e/ou movimento de cena substancial que foi gerada utilizando as técnicas compactação de 1/P bloco cíclico anterior- mente descritas e ilustradas nas figuras 7a, 7b e 8. O compactador de vídeo | 5 404 foiconfigurado para emitir o vídeo compactado em uma taxa de dados [ ! média que está abaixo da taxa de dados de pico 941, e nota-se que, na mai- | É or parte do tempo, a taxa de dados de fluxo de vídeo permanece abaixo da ; taxa de dados de pico 941. Uma comparação de taxa de dados 934 com a e) taxa de dados de fluxo de vídeo 634 mostrada na figura 6c criada utilizando 1/P/Boul/P quadros mostra que a compactação de I/P bloco cíclico produz uma taxa de dados muito mais suave.
Ainda, no quadro 2x pico 952 (que é aproximadamente 2x a taxa de dados de pico 942) e no quadro 4x pico 954 : (que é aproximadamente 4x a taxa de dados de pico 944), a taxa de dados E excede a taxa de dados de pico 941, que é inaceitável.
Na prática, mesmo comum vídeo de alta ação de videogames que mudam rapidamente, os pi- cos que ultrapassam a taxa de dados de pico 941 ocorrem em menos de 2% dos quadros, os picos que ultrapassam 2x a taxa de dados de pico 942 ocor- É rem raramente, e os picos que ultrapassam 3x a taxa de dados de pico 943 ocorrem quase nunca.
Porém, quando esses ocorrem (por exemplo, durante uma transição de cena), a taxa de dados exigida por esses é necessária pa- ra produzir uma imagem de vídeo de qualidade satisfatória.
Uma maneira para resolver esse problema é simplesmente con- F figurar o compactador de vídeo 404 de modo que sua saída de taxa de da- ' dos máxima seja a taxa de dados de pico 941. Infelizmente, a qualidade de saída de vídeo resultante durante os quadros de pico é insatisfatória visto que o algoritmo de compactação é "privado" de bits.
O resultado é o surgi- mento de artefatos de compactação quando há transições repentinas ou movimento rápido, e a tempo, o usuário vem a perceber que os artefatos sempre surgem quando há mudanças repentinas ou movimento rápido, e esses se tornam um tanto desagradáveis.
Embora o sistema visual humano seja muito sensível a artefatos visuais que aparecem durante mudanças repentinas ou movimento rápido, o
| Í mesmo não é muito sensível à detecção de uma redução na taxa de quadro em tais situações.
Na verdade, quando tais mudanças repentinas ocorrerem, | parece que o sistema visual humano está preocupado em rastrear as mu- | danças, e não percebe se a taxa de quadro cai brevemente de 60fps para TP —3Ofps,e então retorna imediatamente para 60fps.
E, no caso de uma transi- L : ção muito dramática, como uma mudança de cena repentina, o sistema vi- | sual humano não percebe se a taxa de quadro cai para 20fps ou ainda 15fps, e então retorna imediatamente para 60fps.
Desde que a redução de ESSSSS taxa de quadro ocorra apenas raramente, para um observador humano, pa- rece que o vídeo está sendo continuamente executado em 60fps.
S Essa propriedade do sistema visual humano é explorada pelas técnicas ilustradas na figura 9b.
Um servidor 402 (das figuras 4a e 4b) pro- é duz um fluxo de saída de vídeo não compactado em uma taxa de quadro - constante (em 60fps em uma modalidade). Uma linha de tempo mostra cada saída de quadro 961-970 a cada 1/60 segundo.
Cada quadro de vídeo não compactado, começando com o quadro 961, é emitido para o compactador de vídeo de baixa latência 404, que compacta o quadro em menos de um Í tempo de quadro, produzindo para o primeiro quadro um quadro compactado 1 981. Os dados produzidos para o quadro compactado 1 981 podem ser maiores ou menores, dependendo de muitos fatores, como anteriormente descrito.
Se os dados forem pequenos o suficiente para que possam ser transmitidos para o cliente 415 em um tempo de quadro (1/60 segundo) ou = menos na taxa de dados de pico 941, então esses são transmitidos durante r o tempo de transmissão (tempo xmit) 991 (o comprimento da seta indica a duração do tempo de transmissão). No próximo tempo de quadro, o servidor 402 produz um quadro não compactado 2 962, o mesmo é compactado para compactar o quadro 2 982, e o mesmo é transmitido para o cliente 415 du- rante o tempo de transmissão 992, que é menor do que um tempo de quadro : na taxa de dados de pico 941. Então, no próximo tempo de quadro, o servidor 402 produz um quadro não compactado 3 963. Quando o mesmo for compactado pelo com- pactador de vídeo 404, o quadro compactado resultante 3 983 possui mais
! dados que podem ser transmitidos na taxa de dados de pico 941 em um | tempo de quadro.
Então, o mesmo é transmitido durante o tempo de trans- | missão (2x pico) 993, que refere-se a todo o tempo de quadro time e parte do próximo tempo de quadro.
Agora, durante o próximo tempo de quadro, o servidor 402 produz outro quadro não compactado 4 964 e emite o mesmo Í | para o compactador de vídeo 404, porém os dados são ignorados e ilustra- [ : dos com 974. Isso se deve ao fato de o compactador de vídeo 404 ser confi- gurado para ignorar os quadros de vídeo adicionalmente não compactados e que chegam enquanto ainda estão transmitindo um quadro compactado an- terior.
Naturalmente, o descompactador de vídeo do cliente 415 não conse- : guirá receber o quadro 4, porém o mesmo continua simplesmente a exibir no dispositivo de exibição 422 o quadro 3 para 2 tempos de quadro (ou seja, É reduz brevemente a taxa de quadro de 60fps para 30fps). Para o próximo quadro 5, o servidor 402 emite o quadro não compactado 5 965, é compactado no quadro compactado 5 985 e transmiti- do dentro de 1 quadro durante o tempo de transmissão 995. O descompac- tador de vídeo do cliente 415 descompacta o quadro 5 e exibe o mesmo no i dispositivo de exibição 422. Depois, o servidor 402 emite o quadro não com- pactado 6 966, o compactador de vídeo 404 compacta o mesmo no quadro compactado 6 986, porém desta vez os dados resultantes são muito gran- des.
Os |-quadros compactados são transmitidos durante o tempo de trans- missão (4x o pico) 996 na taxa de dados de pico 941, porém leva quase 4 r tempos de quadro para transmitir o quadro.
Durante os próximos 3 tempos ' de quadro, o compactador de vídeo 404 ignora 3 quadros do servidor 402, e o descompactador do cliente 415 mantém o quadro 6 estacionário no dispo- sitivo de exibição 422 para 4 tempos de tempos de quadro (ou seja, reduz brevemente a taxa de quadro de 60fps para 15fps). Então por fim, o servidor 402 emite o quadro 10 970, o compactador de vídeo 404 compacta o mesmo no quadro compactado 10 987, e é transmitido durante o tempo de transmis- são 997, e o descompactador do cliente 415 descompacta o quadro 10 e exibe o mesmo no dispositivo de exibição 422 e novamente o vídeo reinicia em 60fps.
Nota-se que embora o compactador de vídeo 404 ignore qua- | dros de vídeo do fluxo de vídeo gerado pelo servidor 402, o mesmo não re- move dados de áudio, independente de qual áudio são originados, e conti- | nua a compactar os dados de áudio quando os quadros de vídeo forem igno- D — radose transmite os mesmos ao cliente 415, que continua a descompactar Fr 1 os dados de áudio e fornecer o áudio para qualquer dispositivo que for usa- | do pelo usuário para reproduzir o áudio.
Assim, o áudio continua no mesmo i ritmo durante períodos quando os quadros são ignorados.
O áudio compac- NEN tado consome uma porcentagem relativamente pequena de largura de ban- da, comparado com o vídeo compactado, e como resultado não possui um á impacto importante sobre a taxa de dados total.
Embora não seja ilustrado em nenhum diagrama de taxa de dados, há sempre uma capacidade de taxa . de dados reservada para o fluxo de áudio compactado dentro da taxa de : dados de pico 941. O exemplo descrito na figura 9b foi selecionado para ilustrar co- mo a taxa de quadro cai durante picos de taxa de dados, porém não é ilus- trado que quando as técnicas de I/P bloco cíclico anteriormente descritas ó forem usadas, tais picos de taxa de dados, e os quadros ignorados conse- quenciais forem raros, mesmo durante sequências de alta complexida- de/ação de cena como aquelas que ocorrem em videogames, imagens em movimento e algum software de aplicação.
Consequentemente, as taxas de quadro reduzidas são pouco frequentes e breves, e o sistema visual humano = não as detecta.
F Se o mecanismo de redução de taxa de quadro descrito acima for aplicado à taxa de dados de fluxo de vídeo ilustrada na figura 9a, a taxa de dados de fluxo de vídeo resultante é ilustrada na figura 9c.
Nesse exem- plo, o pico 2x 952 foi reduzido para pico nivelado 2x 953, e pico 4x 955 foi reduzido pico 4x nivelado 955, e toda a taxa de dados de fluxo de vídeo 934 permanece na ou abaixo da taxa de dados de pico 941. Assim, utilizando-se as técnicas descritas acima, um fluxo de ví- deo de alta ação pode ser transmitido com baixa latência através da Internet geral e através de uma conexão de Internet a nível de consumidor.
Ademais,
| em um ambiente de escritório em uma LAN (por exemplo, 100Mbs Ethernet | ou 802.11g sem fio) ou em uma rede privada (por exemplo, conexão de | 100Mbps entre um centro de dados e um escritório) um fluxo de vídeo de | alta ação pode ser transmitido sem picos de modo que múltiplos usuários | 5 (por exemplo, transmitindo 1920x1080 em 60fps em 4,5Mbps) possa utilizar r ! a LAN ou conexão de dados privada compartilhada sem ter picos sobrepos- tos cobrindo a rede ou as placas traseiras dos comutadores de rede.
Ajuste de Taxa de Dados EEsEEa Em uma modalidade, o serviço de hospedagem 210 avalia inici- almente a taxa de dados máxima disponível 622 e a latência do canal para E determinar uma taxa de dados apropriada para o fluxo de vídeo e então em resposta ajusta dinamicamente a taxa de dados.
Para ajustar a taxa de dados, f o serviço de hospedagem 210 pode, por exemplo, modificar a resolução de imagem e/ou o número de quadros/segundo do fluxo de vídeo que será envi- ado para o cliente 415. Também, o serviço de hospedagem pode ajustar o nível de qualidade do vídeo compactado.
Quando se altera a resolução do fluxo de vídeo, por exemplo, de uma resolução 1280 x 720 para 640 x 360, a É lógica de descompactação de vídeo 412 no cliente 415 pode ampliar a escala da imagem para manter o mesmo tamanho de imagem na tela de exibição.
Em uma modalidade, em uma situação onde o canal foi comple- tamente abandonado, o serviço de hospedagem 210 pausa o jogo.
No caso de um jogo para vários jogadores, o serviço de hospedagem relata aos ou- - tros usuários que o usuário abandonou o jogo e/ou pausa o jogo para os ou- tros usuários.
Pacotes gnorados ou Atrasados Em uma modalidade, se os dados forem perdidos devido à per- da de pacote entre o compactador de vídeo 404 e o cliente 415 nas figuras 4a ou 4b, ou devido ao fato de um pacote ser recebido fora de ordem que chega muito tarde para ser descompactado e cumpre as exigências de la- tênciado quadro descompactado, a lógica de descompactação de vídeo 412 é capaz de mitigar os artefatos visuais.
Em uma implementação de |/P- quadro de fluxo, se houver um pacote perdido/atrasado, toda a tela sofre o
! impacto, fazendo potencialmente com que a tela congele completamente | durante um período de tempo ou mostre outros artefatos visuais em tela pla- na.
Por exemplo, se um pacote perdido/atrasado causar a perda de um LF | quadro, então o descompactador não irá dispor de uma referência para to- r —dososP-quadrosque acompanham até um novo I-quadro ser recebido.
Se F ! um P-quadro for perdido, então causará um impacto sobre os P-quadros pa- | ra toda a tela que os acompanha.
Dependendo de quanto tempo levará an- tes de um I-quadro surgir, isso causará um impacto visual maior ou menor. mESNEas Utilizando-se I/P blocos intercalados como mostrado nas figuras 7a e 7b, é muitomenos provável que um pacote perdido/atrasado cause impacto sobre toda a tela visto que isso afetará apenas os blocos contidos no pacote afeta- do.
Se cada dado do bloco for enviado dentro de um pacote individual, então É se um pacote for perdido, isso afetará apenas um bloco.
Naturalmente, a E duração do artefato visual irá depender da possibilidade de um pacote de 1 bloco ser perdido e, se um P bloco for perdido, quantos |-quadros levarão até um | bloco aparecer.
Porém, uma vez que os blocos diferentes na tela estão sendo atualizados com lI-quadros muito frequentemente (potencial- E mente a cada quadro), mesmo que um bloco na tela seja afetado, outros blocos podem não ser.
Ademais, se algum evento causar uma perda de vá- riospacotes de uma só vez (por exemplo, um pico de energia próximo a uma linha DSL que interrompe brevemente o fluxo de dados), então alguns blo- cos serão afetados mais do que outros, porém devido ao fato de alguns blo- = cos serem rapidamente renovados com um novo | bloco, esses serão ape- + nas brevemente afetados.
Também, com uma implementação de I/P-quadro de fluxo, não só |-quadros são mais os | quadros mais críticos, porém os |- quadros são extremamente grandes, então se houver um evento que origine um pacote ignorado/atrasado, há uma probabilidade maior que um I|-quadro seja afetado (ou seja, se qualquer parte de um I|-quadro for perdida, é impro- vável que o I|-quadro possa ser descompactado) do que um | bloco muito menor.
Devido a todos esses motivos, a utilização de I/P blocos resulta em muito menos artefatos visuais quando os pacotes forem ignorados/atrasados do que com I/P-quadros.
| Uma modalidade tenta reduzir o efeito de pacotes perdidos ao | armazenar de forma inteligente os blocos compactados dentro dos pacotes TCP (protocolo de controle de transmissão) ou pacotes UDP (protocolo de datagrama de usuário). Por exemplo, em uma modalidade, os blocos são ; 5 alinhados com os limites de pacote sempre que possível.
A figura 10a ilustra T ! como os blocos devem ser acondicionados dentro de uma série de pacotes i 1001-1005 sem implementar esse recurso.
Especificamente, na figura 10a, os blocos cruzam os limites de pacote e são armazenados de maneira inefi- Es ciente de modo que a perda de um único pacote resulta na perda de múlti- —plos quadros.
Por exemplo, se os pacotes 1003 ou 1004 forem perdidos, três blocos são perdidos, resultando em artefatos visuais.
Em contrapartida, a figura 10b ilustra a lógica de armazenamen- É to de bloco 1010 para armazenar os blocos de maneira inteligente dentro de * pacotes para reduzir o efeito de perda de pacote.
Primeiro, a lógica de ar- mazenamento de bloco 1010 alinha os blocos com os limites de pacote.
As- sim, os blocos T1, T3, T4, T7, e T2 são alinhados com os limites de pacotes 1001-1005, respectivamente.
A lógica de armazenamento de bloco também Á tenta ajustar os blocos dentro de pacotes da maneira mais eficiente possível, sem cruzar os limites de pacote.
Com base no tamanho de cada bloco, os blocosT1eT6 são combinados em um pacote 1001; T3 e T5 são combina- dos em um pacote 1002; os blocos T4 e T8 são combinados em um pacote 1003; o bloco T8 é adicionado ao pacote 1004; e o bloco T2 é adicionado ao - pacote 1005. Assim, sob esse esquema, uma única perda de pacote irá re- p sultar na perda de não mais que 2 blocos (em vez de 3 blocos como ilustra- donafigura 0a). Um benefício adicional da modalidade mostrada na figura 10b é que os blocos são transmitidos em uma ordem diferente em que esses são exibidos dentro da imagem.
Desse modo, se os pacotes adjacentes forem ! perdidos a partir do mesmo evento interferindo na transmissão, isso irá afe- taráreas que não estão próximas umas às outras na tela, criando um artefa- to menos visível no monitor.
Uma modalidade emprega técnicas de correção antecipada de
Ê erros (FEC) para proteger determinadas partes do fluxo de vídeo contra er- ros de canal. Conforme conhecido na técnica, as técnicas FEC como Reed- Solomon e Viterbi geram e anexam informações de dados de correção de erros a dados transmitidos através de um canal de comunicação. Se ocorrer 7 5 um erro nos dados subjacentes (por exemplo, um I|-quadro), então a FEC [ | pode ser usada para corrigir o erro. | Os códigos FEC aumentam a taxa de dados da transmissão, en- tão de modo ideal, esses são apenas usados quando for necessário. Se os E EcSSSA dados que estão sendo enviados não pudessem resultar em um artefato vi- sual muito visível, pode ser preferido não utilizar códigos FEC para proteger õ os dados. Por exemplo, um P bloco que precede imediatamente um | bloco que foi perdido irá criar apenas um artefato visual (ou seja, o bloco na tela À não será atualizado) para 1/60 de segundo na tela. Tal artefato visual é difi- E cilmente detectável pelo olho humano. Visto que os P blocos estão mais a- trás de um | bloco, a perda de um P bloco se torna cada vez mais visível.
Por exemplo, se um padrão de ciclo de bloco for um | bloco seguido por 15 P blocos antes de um | bloco estar disponível novamente, então se o P bloco É que acompanha imediatamente um | bloco for perdido, isso irá resultar no fato de que o bloco mostra uma imagem incorreta durante 15 tempos de quadro (em 60 fps, que poderiam ser 250ms). O olho humano irá detectar facilmente uma interrupção em um fluxo durante 250ms. Então, um P bloco mais atrás pertence a um novo | bloco (ou seja, quanto mais próximo um P - bloco acompanha um | bloco), mais visível será o artefato. Como anterior- ' mente discutido, embora, em geral, quanto mais próximo um P bloco acom- —panha um! bloco, menores serão os dados para aquele P bloco. Assim, os P blocos que acompanham os | blocos não só são mais críticos de se proteger contra perda, como também são menores em tamanho. E, em geral, quanto menores forem os dados que precisam ser protegidos, menor será o código FEC que precisa ser protegido.
Então, como ilustrado na figura 11a, em uma modalidade, devido à importância de | blocos no fluxo de vídeo, apenas os | blocos são forneci- dos com códigos FEC. Assim, a FEC 1101 contém um código de correção
| de erros para | bloco 1100 e a FEC 1104 contém um código de correção de : erros para | bloco 1103. Nessa modalidade, nenhuma FEC é gerada para os P blocos.
Em uma modalidade ilustrada na figura 11b, os códigos FEC r também são gerados para P que são mais prováveis de causar artefatos r | visuais se forem perdidos.
Nessa modalidade, as FECs 1105 fornecem códi- | gos de correção de erros para os primeiros 3 P blocos, porém não para os P que acompanham.
Em outra modalidade, os códigos FEC são gerados para iasassaas P blocos que são menores em tamanho de dado (que tenderá a auto- selecionar os P blocos que ocorrem logo após um | bloco, que são os mais críticos de se proteger). Em outra modalidade, em vez de enviar um código FEC com um bloco, o bloco é transmitido duas vezes, cada vez em um pacote diferente.
E Se um pacote for perdido/atrasado, o outro pacote é usado.
Em uma modalidade, mostrada na figura 11c, os códigos FEC 1111 e 1113 são gerados para pacotes de áudio, 1110 e 1112, respectiva- mente, transmitidos do serviço de hospedagem simultaneamente com o ví- É deo.
É particularmente importante manter a integridade do áudio em um flu- xo de vídeo, pois o áudio distorcido (por exemplo, ruído impulsivo ou ruído de fundo) irá resultar em uma experiência particularmente indesejada de u- suário.
Os códigos FEC ajudam a garantir que o conteúdo de áudio seja a- presentado no computador de cliente 415 sem distorção. = Em outra modalidade, em vez de enviar um código FEC com : dados de áudio, os dados de áudio são transmitidos duas vezes, cada vez emum pacote diferente.
Se um pacote for perdido/atrasado, o outro pacote é usado.
Ademais, em uma modalidade ilustrada na figura 11d, os códi- gos FEC 1121 e 1123 são usados para comandos de entrada de usuário ; 1120 e 1122, respectivamente (por exemplo, pressionamentos de botão) transmitidos a montante do cliente 415 para o serviço de hospedagem 210. Isso é importante, pois a ausência de um pressionamento de botão ou um movimento de mouse em um videogame ou um aplicativo poderia resultar em uma experiência de usuário indesejada. | Em outra modalidade, em vez de enviar um código FEC com dados de comando de entrada de usuário, os dados de comando de entrada Í de usuário são transmitidos duas vezes, cada vez em um pacote diferente.
Seum pacote for perdido/atrasado, o outro pacote é usado.
Em uma modalidade, o serviço de hospedagem 210 avalia a qualidade do canal de comunicação com o cliente 415 para determinar se ! deve-se utilizar FEC e, se for o caso, quais as partes dos comandos de ví- e deo, áudio e usuário às quais a FEC deve ser aplicada.
À avaliação da "qua- lidade" do canal pode incluir funções como avaliação de perda de pacote, É latência, etc, como descrito acima.
Se o canal não for particularmente confi- ável, então o serviço de hospedagem 210 pode aplicar FEC a todos os | blo- É cos, P blocos, comandos de áudio e usuário.
Em contrapartida, se o canal for confiável, então o serviço de hospedagem 210 pode aplicar FEC apenas a comandos de áudio e usuário, ou pode não aplicar FEC a áudio ou vídeo, ou pode não utilizar FEC de modo algum.
Várias outras permutações da a- plicação de FEC podem ser empregadas enquanto ainda estão de acordo ' com os princípios subjacentes.
Em uma modalidade, o serviço de hospeda- gem 210 monitora continuamente as condições do canal e, consequente- mente, altera a política de FEC.
Em outra modalidade, com referência às figuras 4a e 4b, quando um pacote for perdido/atrasado resultando na perda de dados de bloco ou Fr se, talvez devido a uma perda de pacote particularmente prejudicial, a FEC é é incapaz de corrigir os dados de bloco perdidos, o cliente 415 avalia quantos quadros são deixados antes de um novo | bloco ser recebido e compara o mesmo com a latência de ida e volta do cliente 415 do serviço de hospeda- gem 210. Se a latência de ida e volta for menor do que o número de quadros antes de um novo | bloco estar para chegar, então o cliente 415 envia uma mensagem ao serviço de hospedagem 210 solicitando um novo | bloco.
Es- samensagem é roteada até o compactador de vídeo 404, e em vez de gerar um P bloco para o bloco cujos dados foram perdidos, essa gera um 1 bloco.
Visto que o sistema mostrado nas figuras 4a e 4b é projetado para fornecer uma latência de ida e volta que é tipicamente menor que 80ms, isso resulta em um bloco que está sendo corrigido dentro de 80ms (em 60fps, os qua- dros possuem 16,67ms de duração, assim, em tempos de quadro totais, 80ms de latência poderiam resultar em um bloco corrigido dentro de 83,33ms, que é 5 tempos de quadro - uma interrupção visível, porém muito E menos visível do que, por exemplo, uma interrupção de 250ms durante 15 | quadros). Quando o compactador 404 gerar tal | bloco fora de sua ordem cíclica comum, se o | bloco puder fazer com que a largura de banda daquele ISNNSa quadro exceda a largura de banda disponível, então o compactador 404 irá atrasar os ciclos dos outros blocos de modo que os outros blocos recebam P blocos durante tal tempo de quadro (mesmo que um bloco se deva normal- mente a um | bloco durante aquele quadro), e então começando com o pró- ximo quadro o ciclo comum irá continuar, e o bloco que normalmente poderia - receber um | bloco no quadro anterior irá receber um | bloco.
Embora essa ação atrase brevemente a fase do ciclo de R quadro, isso não será normal- mente visualmente evidente.
À Implementação de Compactador/Descompactador de Vídeo e Áudio É Afigura 12 ilustra uma modalidade particular em que um multinú- cleo e/ou multiprocessador 1200 é usado para compactar 8 blocos em para- lelo Em uma modalidade, um processador dual, um sistema de computador quad core Xeon CPU que executa em 2,66 GHz ou mais é usado, com cada núcleo implementando o compactador de fonte aberta x264 H.264 como um TF processo independente.
Entretanto, várias outras configurações de hardwa- re/software podem ser usadas enquanto ainda estão de acordo com esses princípios subjacentes.
Por exemplo, cada núcleo de CPU pode ser substitu- ído por um compactador H.264 implementado em um FPGA.
No exemplo mostrado na figura 12, os núcleos 1201-1208 são usados para processar simultaneamente os | blocos e P blocos como oito segmentos independen- tes.
Como conhecido na técnica, os sistemas atuais de multinúcleo e muiti- processador são inerentemente capazes de multi-segmentação quando inte- grados com sistemas de operação de multi-segmentação como Microsoft Windows XP Professional Edition (edição de 64 bits ou 32 bits) e Linux.
| Na modalidade ilustrada na figura 12, visto que cada um dos 8 | núcleos é responsável por apenas um bloco, o mesmo opera independente- | mente de outros núcleos, cada um executando uma instanciação separada de x264. Uma placa de captura DVI baseada em PCI Express x1, como " 5 Sendero Video Imaging IP Development Board de Microtronix de Oosterhout, ' The Netherlands é usado para capturar o vídeo não compactado em resolu- | ção 640x480, 800x600, ou 1280x720, e FPGA na placa utiliza Acesso de Memória Direto (DMA) para transferir o vídeo capturado através do barra- E mento DVI no sistema RAM.
Os blocos são dispostos em uma disposição 4x2 1205 (embora esses sejam ilustrados como blocos quadrados, nessa modalidade esses são resolução 160x240). Cada instanciação de x264 é configurada para compactar um dos 8 160x240, e esses são sincronizados Á de modo que, após uma compactação de | bloco inicial, cada núcleo entre em um ciclo, cada quadro fora de fase com o outro, para compactar um | bloco acompanhado por sete P blocos, e ilustrado na figura 12. Cada tempo de quadro, os blocos compactados resultantes são Í combinados em um fluxo de pacote, utilizando as técnicas anteriormente É descritas, e então os blocos compactados são transmitidos para um cliente de destino 415. Embora não ilustrado na figura 12, se a taxa de dados dos 8 blo- cos combinados exceder uma taxa de dados de pico 941 especificada, então todos os processos 8 x264 são suspensos por quantos tempos de quadro FE forem necessários até os dados dos 8 blocos combinados serem transmiti- . dos.
Em uma modalidade, o cliente 415 é implementado como soft- ware em um PC que executa 8 instanciações de FFmpeg.
Um processo de recepção recebe os 8 blocos, e cada bloco é roteado até uma instanciação FFmpeg, que descompacta o bloco e apresenta o mesmo a um local de blo- co adequado no dispositivo de exibição 422. O cliente 415 recebe entrada de teclado, mouse, ou controlador de jogo dos drivers de dispositivo de entrada do PC e transmite a mesma para o servidor 402. O servidor 402 então aplica os dados de dispositivo de entrada recebidos e aplica os mesmos ao jogo ou aplicativo que é executado | no servidor 402, que é um PC que executa Windows utilizando uma CPU | Intel 2. 16GHz Core Duo.
O servidor 402 então produz um novo quadro e emite o mesmo através de sua saída DVI, a partir de um sistema gráfico ba- : 5 —seadoem placa-mãe, ou através de uma saída de DVI da placa NVIDIA í | 8800GTX PCI Express.
À Simultaneamente, o servidor 402 emite o áudio produzido pelo jogo ou aplicações através de sua saída de áudio digital (por exemplo, oo S/PDIF), que é acoplado à entrada de áudio digital no PC baseado em dual quad-core Xeon que está implementando a compactação de vídeo.
Um | compactador de áudio de fonte aberta Vorbis é usado para compactar o áu- dio simultaneamente com o vídeo utilizando qualquer núcleo disponível para É o encadeamento de processo.
Em uma modalidade, o núcleo que conclui a - compactação de seu bloco primeiro, executa a compactação de áudio.
O áudio compactado é então transmitido juntamente com o vídeo compactado, e é descompactado no cliente 415 utilizando um descompactador de áudio f Vorbis.
É Distribuição Central do Servidor de Serviço de Hospedagem O vidro atravessante de luz, tal como uma fibra óptica, viaja em alguma fração da velocidade da luz em um vácuo, e, logo, pode-se determi- nar uma velocidade exata de propagação para luz em fibra óptica.
Porém, na prática, permitindo-se tempo para retardos de roteamento, ineficiências de = transmissão, e outro overhead, observa-se que as latências ótimas na Inter- + net refletem velocidades de transmissão mais próximas a 50% da velocidade daluz Portanto, uma latência ótima de ida e volta de 1000 milhas é aproxi- madamente igual a 22ms, e uma latência ótima de ida e volta de 3000 mi- lhas é igual a cerca de 64ms.
Portanto, um único servidor em uma costa dos EUA estará muito afastado para servir clientes na outra costa (que pode es- tar até 3000 afastada) com a latência desejada.
No entanto, conforme ilus- trado na figura 13a, se a central de servidor 1300 do serviço de hospedagem 210 estiver localizada no centro dos EUA (por exemplo, Kansas, Nebraska, etc.), de tal modo que a distância par qualquer ponto na parte continental dos EUA seja de aproximadamente 1500 milhas ou menor, a latência de ida e volta da Internet pode tão baixa quanto 32 ms.
Referindo-se à figura 4b, | nota-se que embora as piores latências permitidas ao usuário ISP 453 seja | igual a 25ms, tipicamente, observam-se latências mais próximas a 10-15ms [ com sistemas DSL e modem a cabo.
Da mesma forma, a figura 4b supõe E uma distância máxima a partir do local do usuário 211 até a central de hos- | pedagem 210 de 1000 milhas.
Portanto, com uma latência típica de ida e volta de usuário ISP igual a 15ms usada e uma distância máxima da Internet igual a 1500 milhas para uma latência de ida e volta de 32ms, a latência total deidae volta a partir do ponto que um usuário ativa o dispositivo de entrada 421 e observa uma resposta no dispositivo de exibição 422 é igual a 1+1+15+32+1+16+6+8 = 8Oms.
Logo, o tempo de resposta de 80ms pode : ser tipicamente alcançado por uma distância de Internet de 1500 milhas.
Isto - permitiria que qualquer local de usuário com uma latência de usuário curta o suficiente 453 na parte continental dos EUA acesse uma única central de servidor que esteja centralmente localizada.
À Em outra modalidade, ilustradas na figura 13b, as centrais de : servidor do serviço de hospedagem 210, HS1-HS6, estão estrategicamente posicionadas nos Estados Unidos (ou em outra região geográfica), com de- terminadas centrais de servidor de serviço de hospedagem maiores posicio- nadas próximas a grandes centros populacionais (por exemplo, HS2 e HS5). Em uma modalidade, as centrais de servidor HS1-HS6 trocam informações Tr através de uma rede 1301 que pode ser a Internet ou uma rede privada ou uma combinação de ambas.
Com múltiplas centrais de servidor, os serviços podem ser proporcionados em uma latência inferior aos usuários que te- nham uma alta latência de usuário ISP 453. Embora a distância na Internet seja obviamente um fator que contribui para a latência de ida e volta através da Internet, algumas vezes, surgem outros fatores que não sejam amplamente relacionados à latência. — Algumas vezes, um fluxo de pacote é roteado através da Internet até um local distante e volta novamente, resultando em latência a partir do loop lon- go.
Algumas vezes, existe um equipamento de roteamento na trajetória que não esteja operando apropriadamente, resultando em um retardo da trans- missão.
Algumas vezes, existe um tráfego sobrecarregando uma trajetória que introduz retardo.
E, algumas vezes, existe uma falha que evita que o ISP | do usuário roteie até um determinado destino.
Portanto, embora a Internet b geralmente proporcione conexões a partir de um ponto para outro com uma [ rota claramente confiável e ótima e uma latência que seja amplamente de- | terminada pela distância (especialmente com conexões de longa distância i que resultam em um roteamento fora da área local do usuário), tal confiabili- dade e latência não são garantidas de forma alguma e, frequentemente, não podem ser obtidas a partir do local de um usuário até um determinado desti-- á no na Internet.
Em uma modalidade, quando um cliente de usuário 415 se co- : nectar inicialmente ao serviço de hospedagem 210 para jogar um videogame e ou usar um aplicativo, o cliente se comunica com cada uma das centrais de servidor de serviço de hospedagem HS1-HS6 disponíveis mediante a inicia- lização (por exemplo, utilizando-se as técnicas descritas anteriormente). Se a latência for baixa o suficiente para uma conexão particular, então, utiliza-se É tal conexão.
Em uma modalidade, o cliente se comunica com todas, ou com um subconjunto das centrais de servidor de serviço de hospedagem e aque- lacom a conexão de menor latência é selecionada.
O cliente pode selecio- nar a central de serviço com a conexão de menor latência ou as centrais de serviço podem identificar aquela com a conexão de menor latência e propor- F cionar estas informações (por exemplo, sob a forma de um endereço da ln- F ternet) ao cliente.
Se uma central de servidor de serviço de hospedagem particular estiver sobrecarregada e/ou o jogo ou aplicativo do usuário puder tolerar à latência à outra central de servidor de serviço de hospedagem menos carre- gada, então, o cliente 415 pode ser redirecionado à outra central de servidor de serviço de hospedagem.
Nessa situação, o jogo ou aplicativo que o usuá- rio está executando seria pausado no servidor 402 na central de servidor sobrecarregada do usuário, e os dados de estado de jogo ou aplicativo seri- am transferidos a um servidor 402 em outra central de servidor de serviço de
| hospedagem. Então, o jogo ou aplicativo seria retomado. Em uma modalida- de, o serviço de hospedagem 210 aguardaria até que o jogo ou aplicativo j tenha alcançado um ponto de pausa natural (por exemplo, entre os níveis em um jogo, ou após o usuário iniciar uma operação "salvar" no aplicativo) ] 5 pararealizara transferência. Ainda em outra modalidade, o serviço de hos- : pedagem 210 aguardaria até que a atividade do usuário cesse durante um [ período específico de tempo (por exemplo, 1 minuto) e, então, iniciaria a i transferência neste momento. ! eo Conforme descrito anteriormente, em uma modalidade, o serviço de hospedagem 210 se subscreve a um serviço de desvio de Internet 440 da : figura 14 para tentar proporcionar uma latência prometida a seus clientes. Os serviços de desvio de Internet, conforme o uso em questão, são serviços . que proporcionam rotas de rede privada de um ponto para outro na Internet - com as características prometidas (por exemplo, latência, taxa de dados, etc). Por exemplo, se o serviço de hospedagem 210 estiver recebendo uma grande quantidade de tráfego a partir dos usuários que utilizam o serviço DSL da AT&T oferecido em São Francisco, ao invés de rotear aos escritórios centrais baseados em São Francisco da AT&T, o serviço de hospedagem 210 pode arrendar uma conexão de dados privados de alta capacidade a partirde um provedor de serviço (talvez o próprio AT&T ou outro provedor) entre os escritórios centrais sediados em São Francisco e uma ou mais cen- trais de servidor para serviço de hospedagem 210. Então, se as rotas a partir io de todas as centrais de servidor de serviço de hospedagem HS1-HS6 atra- h vés da Internet geral até um usuário em São Francisco usarem o resultado —AT&T DSL em uma latência muito alta, então, a conexão de dados privados poderia ser usada no lugar. Embora as conexões de dados privados sejam genericamente mais dispendiosas do que as rotas através da Internet geral, contanto que estas permaneçam uma pequena porcentagem das conexões de serviço de hospedagem 210 aos usuários, o impacto geral de custos será baixo, e os usuários passarão por uma experiência de serviço mais consis- tente.
Geralmente, as centrais de servidor têm duas camadas de fonte
| de energia de backup no caso de queda de energia.
Tipicamente, a primeira camada é a fonte de energia de backup de baterias (ou de uma fonte de e- f nergia disponível imediatamente alternativa, tal como um volante que é man- tido funcionando e fixado a um gerador), que proporciona energia imediata- mente quando a rede elétrica falhar e manter a central de servidor funcio- [ Í nando.
Se a queda de energia for breve, e a rede elétrica retornar rapida- [ mente (por exemplo, dentro de um minuto), então, as baterias são tudo o Í que seria necessário para manter a central de servidor funcionando.
Porém, se a queda de energia ocorrer por um período mais longo de tempo, então, tipicamente, inicializam-se os geradores (por exemplo, movidos a diesel) que À substituem as baterias e podem funcionar até que tenham combustível.
Es- ses geradores são extremamente dispendiosos visto que devem ser capazes ; de produzir mais energia do que a central de servidor normalmente obtém a - partir da rede elétrica.
Em uma modalidade, cada um dos serviços de hospedagem HS1-HS5 compartilha dados de usuário entre si, de tal modo que se uma Í central de servidor tiver uma queda de energia, a mesma pode pausar os É jogos e aplicações que estiverem em processo, e, então, transferir os dados de estado de jogo ou aplicativo a partir de cada servidor 402 aos servidores 402 em outras centrais de servidor, e, então, notificará o cliente 415 de cada usuário a direcionar as comunicações ao novo servidor 402. Visto que situa- ções como estas ocorrem raramente, pode ser aceitável transferir um usuá- = rio a uma central de servidor de serviço de hospedagem que não seja capaz y de proporcionar uma latência ótima (isto é, o usuário simplesmente precisará tolerar uma latência superior pela duração da queda de energia), que pro- porcionará uma faixa muito mais de opções para transferir usuários.
Por e- xemplo, dadas as diferenças de fuso-horário nos EUA, os usuários na Costa Leste podem ir dormir às 11:30 PM enquanto os usuários na Costa Oeste às 8:30 PM estão atingido o uso de pico de videogames.
Se houver uma queda de energia em uma central de servidor de serviço de hospedagem na Costa Oeste neste horário, podem não existir servidores suficientes na Costa Oes- te 402 em outras centrais de servidor de serviço de hospedagem para mani-
| pular todos os usuários. Nessa situação, alguns usuários podem ser transfe- | ridos para as centrais de servidor de serviço de hospedagem na Costa Leste | que tenham servidores disponíveis 402, e a única consequência aos usuá- rios seria uma latência maior. Uma vez que os usuários forem transferidos a 7 5 —partirda central de servidor que perdeu energia, a central de servidor pode, | então, iniciar um desligamento sistemático de seus servidores e equipamen- | tos, de tal modo que todo o equipamento seja desligado antes que as bateri- as (ou outro backup de energia imediato) se esgotem. Desta forma, podem- . se evitar os custos de um gerador para a central de servidor.
Em uma modalidade, durante horários de carregamento pesado do serviço de hospedagem 210 (seja devido ao carregamento de usuário de pico, ou pelo fato de um ou mais centrais de servidor falharem) os usuários Í são transferidos a outras centrais de servidor com base nos requerimentos - de latência do jogo ou aplicativo que eles estiverem usando. Logo, os usuá- rios que usam os jogos ou aplicativos que requerem baixa latência dariam preferência às conexões de servidor com baixa latência quando existir um ' suprimento limitado. : Recursos de Serviço de Hospedagem A figura 15 ilustra uma modalidade de componentes de uma central de servidor para serviço de hospedagem 210 utilizada nas descrições de recurso a seguir. Assim como no serviço de hospedagem 210 ilustrado na figura 2a, os componentes desta central de servidor são controlados e coor- à denados por um sistema de controle 401 do serviço de hospedagem 210 F exceto onde qualificado em contrário.
O tráfego de entrada da internet 1501 proveniente dos clientes de usuário 415 é direcionado ao roteamento de entrada 1502. Tipicamente, o tráfego de entrada da internet 1501 entrará na central de servidor através de uma conexão de alta velocidade por fibra óptica à Internet, porém, qual- quer meio de conexão de rede com largura de banda adequada, confiabili- dade de latência baixa será suficiente. O roteamento de entrada 1502 é um sistema de rede (a rede pode ser implementada como uma rede Ethernet, uma rede de canal de fibra, ou através de qualquer outro meio de transporte)
| tendo comutações e servidores de roteamento que suportam as comutações ! que recolhem os pacotes de chegada e roteiam cada pacote ao servidor de aplicativo/jogo ("app/jogo") apropriado 1521-1525. Em uma modalidade, um pacote que é distribuído a um servidor particular de app/jogo representa um | 5 — subconjunto dos dados recebidos a partir do cliente e/ou pode ser converti- F | do/alterado por outros componentes (por exemplo, componente de rede, tais | como gateways e roteadores) na central de dados.
Em alguns casos, os pa- cotes serão roteados a mais de um servidor 1521-1525 em um período, por re exemplo, se um jogo ou aplicativo estiver sendo executado de uma vez em paralelo em múltiplos servidores.
As matrizes RAID 1511-1512 são conecta- dos à rede de roteamento de entrada 1502, de tal modo que os servidores de app/jogo 1521-1525 possam ler e gravar às matrizes RAID 1511-1512. É Além disso, uma matriz RAID 1515 (que pode ser implementada como múlti- - plas matrizes RAID) também é conectada ao roteamento de entrada 1502 e os dados provenientes da matriz RAID 1515 podem ser lidos a partir dos servidores de app/jogo 1521-1525. O roteamento de entrada 1502 pode ser À implementado em uma ampla faixa de arquiteturas de rede da técnica ante- ' rior, incluindo uma estrutura em árvore de comutações, com o tráfego de entrada da internet 1501 em sua raiz; em uma estrutura em malha que inter- conecta todos os vários dispositivos; ou como uma série de sub-redes inter- conectadas, com tráfego concentrado entre os dispositivos de intercomuni- cação diferenciado do tráfego entre outros dispositivos.
Um tipo de configu- - ração de rede é um SAN que, embora tipicamente usado para dispositivos F de armazenamento, também pode ser usado para transferência de dados em alta velocidade entre dispositivos.
Da mesma forma, os servidores de app/jogo 1521-1525 podem ter múltiplas conexões de rede ao roteamento de entrada 1502. Por exemplo, um servidor 1521-1525 pode ter uma conexão de rede a uma sub-rede conectada às Matrizes RAID 1511-1512 e outra co- ! nexão de rede a uma sub-rede conectada a outros dispositivos.
Os servidores de app/jogo 1521-1525 podem ser todos configu- rados igualmente, alguns diferentemente, ou todos diferentemente, conforme descrito previamente em relação aos servidores 402 na modalidade ilustrada
| na figura 4a. Em uma modalidade, cada usuário, ao utilizar o serviço de hos- ; | pedagem, está tipicamente usando pelo menos um servidor de app/jogo | 1521-1525. Por motivos de simplicidade de explicação, deve-se supor que um determinado usuário está usando o servidor de app/jogo 1521, porém, i 5 múltiplos servidores podem ser usados por um usuário, e múltiplos usuários ! podem compartilhar um único servidor de app/jogo 1521-1525. A entrada de [ controle do usuário, enviada a partir do cliente 415 conforme descrito previ- ; amente é recebida como tráfego de entrada de Internet 1501, e roteada a- EEE través do roteamento de entrada 1502 ao servidor de app/jogo 1521. O ser- vidorde app/jogo 1521 usa a entrada de controle do usuário como uma en- À trada de controle ao jogo ou aplicativo executado no servidor, e computa o próximo quadro de vídeo e o áudio associado a este. Então, o servidor de É app/jogo 1521 emite o vídeo/áudio não-compactado 1529 à compactação de - vídeo compartilhado 1530. O servidor de app/jogo pode emitir o vídeo não- compactado através de qualquer meio, incluindo uma ou mais conexões Gi- gabit Ethernet, porém, em uma modalidade, o vídeo é emitido através de É uma conexão DVI e o áudio e outras informações de estado de compactação É e canal de comunicação são emitidas através de uma conexão de Barra- mento Serial Universal (USB). A compactação de vídeo compartilhado 1530 compacta o vídeo e o áudio não-compactados a partir dos servidores de app/jogo 1521-1525. A compactação pode ser totalmente implementada em hardware, ou em um = software executado em hardware. Pode existir um compactador dedicado : para cada servidor de app/jogo 1521-1525, ou se os compactadores forem rápidos o suficiente, um determinado compactador pode ser usado para compactar o vídeo/áudio a partir de mais de um servidor de app/jogo 1521-
1525. Por exemplo, em 60fps um tempo de quadro de vídeo é igual a 16,67 ms. Se um compactador for capaz de compactar um quadro em I1ms, à então, tal compactador pode ser usado para compactar o vídeo/áudio a partir de até16 servidores de app/jogo 1521-1525 adotando-se a entrada proveni- ente de um servidor após o outro, com o compactador salvando o estado de cada processo de compactação de vídeo/áudio e comutando o contexto à
| medida que realiza um ciclo entre os fluxos de vídeo/áudio a partir dos servi- dores. Isto resulta em economias substanciais de custos em hardware de compactação. Visto que diferentes servidores completarão os quadros em | diferentes momentos, em uma modalidade, os recursos de compactador se Í 5 encontram em um pool compartilhado 1530 com um meio de armazenamen- to compartilhado (por exemplo, RAM, Flash) que serve para armazenar o | estado de cada processo de compactação, e quando um quadro de servidor ! 1521-1525 estiver completo e pronto para que seja compactado, um meio de ENA controle determines qual recurso de compactação está disponível em tal momento, proporciona ao recurso de compactação o estado do processo de ô compactação do servidor e o quadro de vídeo/áudio não-compactado a ser comprimido.
À Nota-se que parte do estado para cada processo de compacta- E ção de servidor inclui informações sobre a própria compactação, tais como osdados de buífer de quadro descompactado do quadro anterior que podem ser usados como uma referência para P blocos, a resolução da saída de vi- À deo; a qualidade da compactação; a estrutura lado a lado; a alocação de bits É por blocos; a qualidade de compactação, o formato de áudio (por exemplo, estéreo, sistema surround, Dolby? AC-3). No entanto, o estado de processo de compactação também inclui informações de estado de canal de comuni- cação referentes aos dados à taxa de pico de dados 941 e se um quadro anterior (conforme ilustrado na figura 9b) está sendo atualmente emitido (e = como resultado o quadro atual deve ser ignorado), e potencialmente se exis- F tem características de canal que devem ser consideradas na compactação, tal como uma perda excessiva de pacote, que afete as decisões para a compactação (por exemplo, em termos da frequência de | blocos, etc). À medida que a taxa de pico de dados 941 ou outras características de canal se alteram com o passar do tempo, conforme determinado por um servidor de app/jogo 1521-1525 que suporta cada um dos dados de monitoramento de usuário enviados a partir do cliente 415, o servidor de app/jogo 1521- 1525 envia informações relevantes à compactação de hardware comparti- lhado 1530.
A compactação de hardware compartilhado 1530 também em- | | pacota o vídeo/áudio compactado utilizando-se meios como aqueles descri- | tos anteriormente, e, se apropriado, aplicar códigos FEC, duplicar determi- | nados dados, ou adotar outras etapas para garantir adequadamente a capa- | 5 cidade do fluxo de dados de vídeo/áudio a ser recebido pelo cliente 415 e E descompactado com uma maior qualidade e confiabilidade possível. ! Alguns aplicativos, tais como aqueles descritos mais adiante, re- querem que a saída de vídeo/áudio de um determinado servidor de app/jogo E 1521-1525 esteja disponível em múltiplas resoluções (ou em outros múltiplos formatos) simultaneamente.
Se o servidor de app/jogo 1521-1525 notificar o recurso de compactação de hardware compartilhado 1530, então, o áu- dio/vídeo não-compactado 1529 de tal servidor de app/jogo 1521-1525 será E simultaneamente compactado em diferentes formatos, diferentes resoluções, - e/ou em diferentes estruturas de correção de pacote/erro.
Em alguns casos, alguns recursos de compactação podem ser compartilhados entre múltiplos processos de compactação que compactam o mesmo vídeo/áudio (por e- É xemplo, em muitos algoritmos de compactação, existe uma etapa por meio À da qual a imagem é escalonada em múltiplos tamanhos antes de aplicar a compactação.
Se for necessário que imagens com tamanhos diferentes se- jam emitidas, então, esta etapa pode ser usada para servir vários processos de compactação de uma vez). Em outros casos, os recursos de compacta- ção separada serão necessários para cada formato.
Em qualquer caso, o FE vídeo/áudio compactado 1539 de todas as várias resoluções e formatos ne- : cessários para um determinado servidor de app/jogo 1521-1525 (seja este um ou muitos) será emitido de uma vez ao roteamento de saída 1540. Em uma modalidade, a saída do vídeo/áudio compactado 1539 se encontra em um formato UDP, logo, este consiste em um fluxo unidirecional de pacotes.
A rede de roteamento de saída 1540 compreende uma série de servidores e comutadores de roteamento que direcionam cada fluxo de ví- —deo/áudio compactado ao(s) usuário(s) destinado(s) ou outros destinos atra- vés da interface de tráfego de saída de Internet 1599 (que, tipicamente, co- nectaria uma interface de fibra à Internet) e/ou de volta ao buffer de retardo
1515, e/ou de volta ao roteamento de entrada 1502, elou para fora através | de uma rede privada (não mostrada) para distribuição de vídeo. Nota-se que ! (conforme descrito anteriormente) o roteamento de saída 1540 pode emitir | um determinado fluxo de vídeo/áudio a múltiplos destinos de uma vez. Em r | 5 uma modalidade, este é implementado utilizando-se multicast de Protocolo r Í de Internet (IP) no qual se radiodifunde um determinado fluxo UDP destinado ! | a realizar um fluxo contínuo em múltiplos destinos de uma vez, e a radiodifu- i são é repetida pelos servidores e comutadores de roteamento no roteamento sESESSNEE! de saída 1540. Os múltiplos destinos da radiodifusão podem ser clientes de múltiplos usuários 415 através da Internet, a múltiplos servidores de F app/jogo 1521-1525 através do roteamento de entrada 1502, e/ou a um ou mais buffers de retardo 1515. Portanto, a saída de um determinado servidor Á 1521-1522 é compactada em um ou múltiplos formatos, e cada fluxo com- - pactado é direcionado a um ou a múltiplos destinos.
Além disso, em outra modalidade, se múltiplos servidores de app/jogo 1521-1525 forem simultaneamente usados por um usuário (por e- f xemplo, em uma configuração de processamento paralelo para criar uma É saída em 3D de uma cena complexa) e cada servidor estiver produzindo par- te da imagem resultante, a saída de vídeo de múltiplos servidores 1521-1525 pode ser combinada pela compactação de hardware compartilhado 1530 em um quadro combinado, e a partir deste ponto em diante, tratada conforme descrito anteriormente como se fosse proveniente de um único servidor de 7 app/jogo 1521-1525. : Nota-se que em uma modalidade, uma cópia (em pelo menos uma resolução do vídeo, ou em uma resolução superior, observada pelo u- suário) de todo o vídeo gerado pelos servidores de app/jogo 1521-1525 é gravada no buffer de retardo 1515 durante pelo menos alguns minutos (15 minutos em uma modalidade). Isto permite que cada usuário "rebobine" o vídeo a partir de cada sessão com a finalidade de rever ações ou proezas anteriores (no caso de um jogo). Portanto, em uma modalidade, cada fluxo de saída de vídeo/áudio compactado 1539 sendo roteado a um cliente de usuário 415 também está sendo realizado multicast a um buffer de retardo
| 1515. Quando o vídeo/áudio for armazenado em um buffer de retardo 1515, i um diretório no buffer de retardo 1515 proporciona uma referência cruzada | entre o endereço de rede do servidor de app/jogo 1521-1525 que seja a fon- te do vídeo/áudio retardado e o local no buffer de retardo 1515 onde o vi- | j 5 —deo/áudioretardado pode ser encontrado. r ! Jogos ao Vivo, Instantaneamente Visualizáveis e Jogáveis ' Os servidores de app/jogo 1521-1525 podem não apenas ser u- sados para executar um determinado aplicativo ou videogame para um usuá- Eae rio, mas eles também podem ser usados para criar os aplicativos de interface de usuário para o serviço de hospedagem 210 que suporta navegação atra- | vés do serviço de hospedagem 210 e outros recursos.
Uma captura de tela de tal aplicativo de interface de usuário é mostrada na figura 16, uma tela "Game Á Finder". Esta tela de interface de usuário particular permite que um usuário . veja 15 jogos que estão sendo jogados ao vivo (ou retardados) por outros u- —suários.
Cada uma das janelas de vídeo "em miniatura", tal como 1600 é uma janela de vídeo ao vivo em movimento mostrando o vídeo do jogo de um usu- ário.
A vista mostrada na miniatura pode ser a mesma vista que o usuário está ' vendo, ou pode ser uma vista retardada (por exemplo, se um usuário estiver jogando um jogo de luta, um usuário pode não desejar que outros usuários vejam onde ele está se escondendo e pode escolher retardar qualquer vista de seu jogo durante um período de tempo de digamos 10 minutos). A vista também pode ser uma vista de câmera de um jogo que seja diferente de Fr qualquer vista do usuário.
Através de seleções de menu (não mostradas nesta r ilustração), um usuário pode escolher uma seleção de jogos para visualizar de uma vez, com base em uma variedade de critérios.
Como uma pequena a- mostragem de escolhas exemplificadoras, o usuário pode selecionar uma se- leção aleatória de jogos (tal como aquela mostrada na figura 16), todos de um tipo de jogos (todos sendo jogados por diferentes jogadores), apenas os joga- dores mais bem classificados de um jogo, jogadores em um determinado nível — no jogo, ou jogadores com pior classificação (por exemplo, se o jogador esti- ver aprendendo o básico), jogados que sejam "amigos" (ou rivais), jogos que tenham o maior número de espectadores, etc.
Em geral, nota-se que cada usuário decidirá se o vídeo de seu | jogo ou aplicativo pode ser visualizado por terceiros e, se puder, quais tercei- | ros, e quanto pode ser visualizado por outros, se apenas for visualizável com um retardo.
Í 5 O servidor de app/jogo 1521-1525 que estiver gerando a tela de | interface de usuário mostrada na figura 16 adquire os 15 feeds de vi | deo/áudio enviando-se uma mensagem ao servidor de app/jogo 1521-1525 : para cada usuário cujo jogo está sendo solicitado. A mensagem é enviada E através do roteamento de entrada 1502 ou outra rede. A mensagem incluirá otamanho eo formato do vídeo/áudio solicitado, e identificará o usuário vi- À sualizando a tela de interface de usuário. Um determinado usuário pode es- colher selecionar o modo de "privacidade" e não permitir quaisquer outros À usuários visualizem o vídeo/áudio de seu jogo (seja a partir de seu ponto de . vista ou a partir de outro ponto de vista), ou conforme descrito no parágrafo anterior, um usuário pode escolher permitir a visualização de vídeo/áudio de : seu jogo, porém, retardar o vídeo/áudio visualizado. Um usuário servidor de app/jogo 1521-1525 que recebe e aceita uma solicitação para permitir que E seu vídeo/áudio seja visualizado reconhecerá como tal ao servidor de solici- tação, e também notificará a compactação de hardware compartilhado 1530 da necessidade de gerar um fluxo de vídeo compactado adicional no formato solicitado ou tamanho de tela (supondo que o formato e tamanho de tela se- jam diferentes daqueles já gerados), e também indicará o destino para o vi- = deo compactado (isto é, o servidor de solicitação). Se o vídeo/áudio solicita- g do for apenas retardado, então, o servidor de solicitação de app/jogo 1521- 1525 será notificado, e adquirirá o vídeo/áudio retardado a partir de um buf- fer de retardo 1515 procurando-se o local do vídeo/áudio no diretório em um buffer de retardo 1515 e o endereço de rede do servidor de app/jogo 1521- 1525 que seja a fonte do vídeo/áudio retardado. Uma vez que todas essas solicitações tiverem sido geradas e manipuladas, até 15 fluxos de vídeo ao vivoem miniatura serão roteados a partir do roteamento de saída 1540 até o roteamento de entrada 1502 ao servidor de app/jogo 1521-1525 que gera a tela de interface de usuário, e serão descompactados e exibidos pelo servi-
| dor.
Os fluxos de vídeo/áudio retardados podem estar em um tamanho de tela muito grande, e, se estiverem, o servidor de app/jogo 1521-1525 des- ! compactará os fluxos e reduzir a escala dos fluxos de vídeo ao tamanho em j miniatura.
Em uma modalidade, as solicitações por áudio/vídeo são enviadas | : 5 (e gerenciadas por) um serviço de "gerenciamento" central similar ao siste- [ | ma de controle de serviço de hospedagem da figura 4a (não mostrado na | figura 15) que, então, redireciona as solicitações ao servidor de app/jogo apropriado 1521-1525. Ademais, em uma modalidade, nenhuma solicitação ea pode ser requerida devido ao fato de as miniaturas serem "enviadas por pu- sh"aosclientes daqueles usuários que as permitem.
À
Os áudios dos 15 jogos todos mixados simultaneamente podem criar uma cacofonia de som.
O usuário pode escolher mixar todos os sons
. juntos desta forma (talvez apenas captar a sensação do "ruído" criado por
- todas as ações sendo visualizadas), ou o usuário pode escolher apenas es-
—cutaro áudio de um jogo de uma vez.
À seleção de um único jogo é realiza-
À da movendo-se a caixa de seleção amarela 1601 (que aparece como um contorno retangular preto na renderização em preto e branco da figura 16)
É para um determinado jogo (o movimento da caixa amarela pode ser realiza-
da utilizando-se as teclas direcionais em um teclado, movendo-se um mou-
se, movendo-se um joystick, ou apertando-se botões direcionais em outro dispositivo, tal como um telefone móvel). Uma vez que um único jogo for se-
lecionado, reproduz-se apenas o áudio deste jogo.
Da mesma forma, as in- Fr formações de jogo 1602 são mostradas.
No caso deste jogo, por exemplo, o y logotipo do publicador (por exemplo, "EA" para "Electronic Arts") e o logotipo
—dojogo, "por exemplo, Need for Speed Carbon" e uma barra horizontal la-
ranja (renderizada na figura 16 como uma barra com faixas verticais) indica em termos relativos o número de pessoas jogando ou visualizando o jogo neste momento particular (muitos, neste caso, logo, o jogo é "Hot"). Propor-
cionam-se "Stats" adicionais (isto é, estatísticas), indicando que existem 145 jogadores ativamente jogando 80 instanciações diferentes do Jogo Need for
Speed (isto é, pode ser jogado por um jogador individual ou por jogadores múltiplos), e existem 680 espectadores (dentre os quais este usuário é um).
Nota-se que estas estatísticas (e outras estatísticas) são coletadas pelo sis- tema de controle de serviço de hospedagem 401 e são armazenadas em | matrizes RAID 1511-1512, para manter registros da operação do serviço de hospedagem 210 e para cobrar apropriadamente os usuários e os publicado- | 5 res pagantes que proporcionam conteúdos.
Algumas dessas estatísticas são | gravadas devido às ações pelo sistema de controle de serviço 401, e algu- | i mas são reportadas ao sistema de controle de serviço 401 pelo servidor de : app/jogo individual 1521 - 1525. Por exemplo, o servidor de app/jogo 1521- EEE 1525 executando este aplicativo Game Finder envia mensagens ao sistema de controle de serviço de hospedagem 401 quando os jogos estiverem sen- : do visualizados (e quando sua visualização for cessada) de tal modo que possa atualizar as estatísticas de quantos jogos se encontram em visualiza- . ção.
Algumas dessas estatísticas estão disponíveis para aplicativos de inter- - face de usuário, tal como este aplicativo Game Finder.
Se o usuário clicar um botão de ativação em seu dispositivo de À entrada, ele verá o vídeo em miniatura na caixa amarela maximizada en- quanto continua a jogar o vídeo ao vivo em tela cheia.
Este efeito é mostrado no processo da figura 17. Nota-se que a janela de vídeo 1700 foi ampliada em tamanho.
Objetivando implementar este efeito, o servidor de app/jogo 1521-1525 solicita que o servidor de app/jogo 1521-1525 que executa o jogo selecionado tenha uma cópia do fluxo de vídeo para um tamanho em tela cheia (na resolução do dispositivo de exibição do usuário 422) do jogo rote- -. ado ao mesmo.
O servidor de app/jogo 1521-1525 que executa o jogo notifi- : ca o compactador de hardware compartilhado 1530 que uma cópia em mini- —atura do jogo não é mais necessária (a não ser que outro servidor de app/jogo 1521-1525 requeira tal miniatura), e, então, ordena que o mesmo envie uma cópia de tamanho em tela cheia do vídeo ao servidor de app/jogo 1521-1525 aplicando zoom ao vídeo.
O usuário que joga o jogo pode ter ou i não um dispositivo de exibição 422 tendo a mesma resolução do usuário que maximiza o jogo.
Além disso, outros espectadores do jogo podem ter ou não dispositivos de exibição 422 tendo a mesma resolução do usuário que ma- ximiza o jogo (e pode ter diferentes meio de reprodução de áudio, por exem-
| plo, estéreo ou sistema surround). Portanto, o compactador de hardware compartilhado 1530 determina se já foi gerado um fluxo de vídeo/áudio com- | pactado adequado que satisfaça os requerimentos do usuário que solicita o | fluxo de vídeo/áudio e se não existir, o mesmo notifica o roteamento de saí- | da1540arotear uma cópia do fluxo ao servidor de app/jogo 1521-1525 apli- [ | cando zoom ao vídeo, se não compactar outra cópia do vídeo que seja ade- | quada para tal usuário e instrui o roteamento de saída a enviar o fluxo de : volta ao roteamento de entrada 1502 e ao servidor de app/jogo 1521-1525 INNNNNNNNNNa que aplica zoom ao vídeo.
Este servidor, que agora recebe uma versão em telacheia do vídeo selecionado o descompactará e gradualmente ampliará a É : . escala para tamanho máximo.
A figura 18 ilustra como a tela se parece após o jogo ter sido É completamente maximizado até o modo em tela cheia e o jogo é mostrado . em uma resolução máxima do dispositivo de exibição do usuário 422 con- forme indicado pela imagem apontada pela seta 1800. O servidor de E app/jogo 1521-1525 que executa o aplicativo Game Finder envia mensagens aos outros servidores de app/jogo 1521-1525 que proporcionaram miniaturas que não sejam mais necessárias e mensagens ao servidor de controle de serviço de hospedagem 401 que os outros jogos não estão sendo mais visu- —alizados.
Neste ponto, a única exibição que está gerando é uma sobreposi- ção 1801 no topo da tela que fornece informações e controles de menu ao usuário.
Nota-se que à medida que este jogo foi progredido, a audiência au- = mentou para 2.503 espectadores.
Com tantos espectadores, limitam-se co- r mo sendo muitos espectadores com dispositivos de exibição 422 que te- nham uma resolução igual ou quase igual (cada servidor de app/jogo 1521- 1525 tem a capacidade de escalonar o vídeo para ajustar a instalação). Devido ao fato de o jogo mostrado ser um jogo de múltiplos jo- gadores, o usuário pode decidir entrar no jogo em algum momento.
O servi- ço de hospedagem 210 pode permitir ou não que o usuário entre no jogo por uma variedade de razões.
Por exemplo, o usuário pode ter que pagar para jogar o jogo e escolher por não fazê-lo, o usuário pode não ter ranking sufi- ciente para entrar neste jogo em particular (por exemplo, não seria competi-
tivo aos outros jogadores), ou a conexão de Internet do usuário pode não ter uma latência baixa o suficiente para permitir que o usuário jogue (por exem- plo, não existe uma restrição de latência para visualizar jogos, logo, um jogo que estiver sendo jogado distante (de fato, em outro continente) pode ser | 5 visualizado sem questões de latência, porém, para um jogo a ser jogado, a [ À latência deve ser baixa o suficiente para que o usuário (a) aproveite o jogo, e | (b) esteja em iguais condições aos outros jogadores que podem ter cone- xões de latência inferior). Se o usuário tiver permissão para jogar, então, o o servidor de app/jogo 1521-1525 que forneceu a interface de usuário Game Finder ao usuário solicitará que o servidor de controle de serviço de hospe- " dagem 401 inicie (isto é, localize e inicialize) um servidor de app/jogo 1521- 1525 que seja adequadamente configurado para jogar o jogo em particular Á para carregar o jogo a partir de uma matriz RAID 1511-1512, e, então, o ser- vidor de controle de serviço de hospedagem 401 instruirá o roteamento de entrada 1502 a transferir os sinais de controle a partir do usuário ao servidor de app/jogo que agora esteja hospedando o jogo e instruirá a compactação de hardware compartilhado 1530 a comutar de compactar o vídeo/áudio a É partir do servidor de app/jogo que estava hospedando o aplicativo Game Finder para compactar o vídeo/áudio a partir do servidor de app/jogo que agora esteja hospedando o jogo.
A sincronização vertical do serviço de app/jogo Game Finder e o novo servidor de app/jogo que hospeda o jogo não estão sincronizados, e, como resultado, provavelmente ocorrerá uma diferen- Fr ça de tempo entre as duas sincronizações.
Devido ao fato de o hardware de h compactação de vídeo compartilhado 1530 começar a compactação do jogo mediante um servidor de app/jogo 1521-1525 que completa um quadro de vídeo, o primeiro quadro proveniente do novo servidor pode ser completo an- tes de um tempo de quadro completo do servidor antigo, que pode ser acon- tecer antes de o quadro anteriormente compactado completar sua transmis- são (por exemplo, considera-se o tempo de transmissão 992 da figura 9b: se o quadro não-compactado 3 963 tiver completado metade de um tempo de quadro antecipadamente, isto afetaria o tempo de transmissão 992). Nesta situação, o hardware de compactação de vídeo compartilhado 1530 ignorará o
| primeiro quadro do novo servidor (por exemplo, como o Quadro 4 964 é igno- : rado 974), e o cliente 415 manterá o último quadro do servidor antigo por um | tempo extra de quadro, e o hardware de compactação de vídeo compartilhado | 1530 começará a compactar o próximo vídeo de tempo de quadro do novo [ | 5 —servidorde app/jogo que hospeda o jogo.
Visualmente, ao usuário, a transição ç ! de um servidor de app/jogo para outro será contínua.
Então, o servidor de | controle de serviço de hospedagem 401 notificará o servidor de app/jogo 1521-1525 que estava hospedando o Game Finder a comutar para um estado EEEEEEEZ ocioso, até que este seja novamente necessário.
Então, o usuário está apto a jogar o jogo.
E, o que é excepcional : é que o jogo será jogado de modo instantaneamente perceptual (visto que será carregado no servidor de app/jogo 1521-1525 a partir de uma matriz É RAID 1511-1512 em velocidade de gigabit/segundo), e o jogo será carrega- do em um servidor exatamente adequado para o jogo junto a um sistema operacional exatamente configurado para o jogo com as unidades ideais, À configuração de registro (no caso do Windows), e sem outros aplicativos e- xecutados no servidor que podem competir com a operação do jogo.
Ô Da mesma forma, à medida que o progride através do jogo, cada um dos segmentos do jogo será carregado no servidor em velocidade de gigabitl/segundo (isto é, 1 gigabyte carrega em 8 segundos) a partir da matriz RAID 1511-1512, e por causa da vasta capacidade de armazenamento da matriz RAID 1511-1512 (visto que é um recurso compartilhado entre muitos i-: usuários, pode ser muito grande, ainda pode ter uma boa relação custo- , benefício), configuração de geometria ou outra configuração de segmento de jogo pode ser pré-computada e armazenada na matriz RAID 1511-1512 e carregada de modo extremamente rápido.
Ademais, devido ao fato de a con- figuração de hardware e as capacidades computacionais de cada servidor de app/jogo 1521-1525 serem conhecidas, os sombreados de pixel e vértice podem ser pré-computados.
Portanto, o jogo será inicializado quase instantaneamente, será executado em um ambiente ideal, e os segmentos subsequentes serão car- regados quase instantaneamente.
Porém, além dessas vantagens, o usuário será capaz de ver ter- ceiros jogando o jogo (através do Game Finder, previamente descrito e por outros meios) e ambos decidem se o jogo está interessante, e, se estíver, aprendem dicas assistindo aos outros. E, o usuário será capaz de demons- 1 5 trarojogo instantaneamente, sem precisar aguardar por um download gran- Í | de e/ou instalação, e o usuário será capaz de jogar o jogo instantaneamente, | h talvez em uma base experimental por uma pequena taxa, ou em longo pra- zo. E, o usuário será capaz de jogar o jogo em um PC Windows, em um Ma- EEE cintosh, em um aparelho de televisão, em casa, quando estiver viajando, e mesmo em um telefone móvel, com uma conexão sem fio com latência baixa : o suficiente (embora a latência não seja uma questão para os meros espec- tadores). E, isto pode ser realizado sem nunca ter posse física do jogo.
E Conforme mencionado anteriormente, o usuário pode decidir não " permitir que seu jogo seja visualizável por terceiros, permitir que seu jogo seja visualizável após um retardo, permitir que seu jogo seja visualizável por usuários selecionados, ou permitir que seu jogo seja visualizável por todos os usuários. Independentemente, o vídeo/áudio será armazenado, em uma f modalidade, durante 15 minutos em um buffer de retardo 1515, e o usuário será capaz de "rebobinar" e assistir a seu jogo anterior, e pausar, o reprodu- zirem câmera lenta, avançar rapidamente, etc., assim como seria capaz as- sistir TV com um Gravador de Vídeo Digital (DVR). Embora neste exemplo, o usuário esteja jogando um jogo, a mesma capacidade "DVR" se encontra = disponível se o usuário estiver utilizando um aplicativo. Isto pode ser útil na - revisão de um trabalho anterior e em outras aplicações, conforme descrito mais adiante. Além disso, se o jogo tiver sido projetado com a capacidade de rebobinagem com base nas informações de estado do jogo, de tal modo que a vista de câmera possa ser alterada, etc., então, esta capacidade "3D DVR" também será suportada, porém, exigirá que o jogo seja projetado para su- portá-la. A capacidade "DVR" utilizando-se um buffer de retardo 1515 fun- cionarácom qualquer jogo ou aplicativo, limitado naturalmente, ao vídeo que foi gerado quando o jogo ou aplicativo foi usado, porém, no caso de jogos com capacidade 3D DVR, o usuário pode controlar um "sobrevoo" em 3D de um segmento previamente jogado, e ter o buffer de retardo 1515 gravado no vídeo resultante e ter o estado do jogo do segmento de jogo gravado.
Por- | tanto, um "sobrevoo" particular será gravado como vídeo compactado, po- DP rém, visto que o estado do jogo também será gravado, um sobrevoo diferen- | ! 5 teserá possível em uma data posterior do mesmo segmento do jogo. [ | Conforme descrito mais adiante, os usuários no serviço de hospe- | dagem 210 terão uma User Page, onde eles podem postar informações sobre eles mesmos e outros dados.
Dentre as coisas que os usuários serão capazes oo de postar encontram-se os segmentos de vídeo de um jogo que eles salvaram.
Por exemplo, se o usuário tiver superado um desafio particularmente difícil em um jogo, o usuário pode "rebobinar" até um pouco antes do local onde ele ob- teve sua grande realização no jogo, e, então, instruir o serviço de hospedagem E 210 a salvar um segmento de vídeo de certa duração (por exemplo, 30 segun- . dos) na User Page do usuário para que outros usuários assistam.
Objetivando implementar isto, esta consiste simplesmente em uma questão do servidor de . app/jogo 1521-1525 que o usuário está usando para reproduzir o vídeo arma- zenado em um buffer de retardo 1515 a uma matriz RAID 1511-1512 e, então, É indexar este segmento de vídeo na User Page do usuário.
Se o jogo tiver a capacidade de 3D DVR, conforme descrito an- teriormente, então, as informações de estado do jogo requeridas para o 3D DVR também podem ser gravadas pelo usuário e tornadas disponíveis para a User Page do usuário. = No caso onde um jogo é projetado para que tenha "espectado- - res" (isto é, usuários que sejam capazes de viajar através do mundo 3D e observar a ação sem participar no mesmo) além dos jogadores ativos, então, o aplicativo Game Finder permitirá que os usuários entrem nos jogos como espectadores assim como jogados.
A partir de um ponto de vista de imple- mentação, não existe diferença ao sistema de hospedagem 210 se um usuá- rio for um espectador ao invés de um jogador ativo.
O jogo será carregado emum servidor de app/jogo 1521-1525 e o usuário estará controlando o jogo (por exemplo, controlando uma câmera virtual que visualiza neste mundo). À única diferença será a experiência de jogo do usuário.
| Colaboração de Múltiplos Usuários Outro recurso do serviço de hospedagem 210 é a capacidade de múltiplos usuários colaborarem enquanto assistem a um vídeo ao vivo, mesmo se utilizarem dispositivos amplamente discrepantes para visualiza- ! 5 ção Istoé útiltanto ao se jogar os jogos como ao se utilizar os aplicativos. [ | Muitos PCs e telefones móveis são equipados com câmeras de ! vídeo e apresentam a capacidade de realizar uma compactação de vídeo em f tempo real, particularmente quando a imagem for pequena.
Da mesma for- ce ma, estão disponíveis câmeras pequenas que possam ser conectadas a uma televisão, e não seja difícil implementar uma compactação em tempo í real em software ou utilizando-se um entre os muitos dispositivos de com- pactação de hardware para compactar o vídeo.
Da mesma forma, muitos É PCs e todos os telefones móveis têm microfones, e fones de ouvido estão j disponíveis com microfones.
Essas câmeras e/ou microfones, combinados com a capacidade . de compactação local de vídeo/áudio (particularmente empregando as técni- cas de compactação de vídeo com baixa latência descritas no presente do- À cumento) permitirão que um usuário transmita vídeo e/ou áudio a partir dos locais do usuário 211 ao serviço de hospedagem 210, junto aos dados de controle do dispositivo de entrada.
Quando essas técnicas forem emprega- das, então, uma capacidade ilustrada na figura 19 é obtenível: um usuário pode ter seu vídeo e áudio 1900 aparecendo na tela no jogo ou aplicativo de = outro usuário.
Este exemplo é um jogo de múltiplos jogadores, onde parcei- : ros de equipe colaboram em uma corrida de carros.
Um vídeo/áudio do usu- —áriopode ser seletivamente visualizável/escutável apenas por seus parceiros de equipe.
E, visto que efetivamente não existiria latência, utilizando-se das técnicas descritas anteriormente, os jogadores seriam capazes de conversar ou realizar movimentos entre si em tempo real sem um retardo perceptível.
Esta integração de vídeo/áudio é realizada tendo-se o vídeo e/ou áudio compactados a partir da câmera/microfone de um usuário chegando como um tráfego de entrada da internet 1501. Então, o roteamento de entra- da 1502 roteia o vídeo e/ou áudio aos servidores de app/jogo 1521-1525 que
| têm permissão para ver/escutar ao vídeo e/ou áudio.
Então, os usuários dos respectivos servidores de app/jogo 1521-1525 que escolhem usar o vídeo | e/ou áudio os descompactam e integram conforme desejado para aparecer | no jogo ou aplicativo, tal como ilustrado por 1900. F ] 5 O exemplo da figura 19 mostra como tal colaboração é usada | | em um jogo, porém, essa colaboração pode ser uma ferramenta imensa- [ mente poderosa para aplicativos.
Considerando-se uma situação onde um i grande edifício esta sendo projetado para a cidade de Nova York por arquite-
SENSESNS| tos em Chicago para um construtor imobiliário baseado em Nova York, po- rém,a decisão envolve um investidor financeiro que está viajando e calha de É mo mesmo estar em um aeroporto em Miami, e uma decisão precisa ser to-
mada sobre determinados elementos de projeto do edifício em termos de
Í como este se combina com os edifícios próximos ao mesmo, para satisfazer f tanto o investidor como o construtor imobiliário.
Supõe-se que a firma de ar-
quitetura tenha um monitor de alta resolução com uma câmera conectada a
: um PC em Chicago, o construtor imobiliário tem um laptop com uma câmera em Nova York, e o investidor tem um telefone móvel com uma câmera em
À Miami.
A firma de arquitetura pode usar o serviço de hospedagem 210 para hospedar um aplicativo de projeto arquitetônico poderoso que seja capaz de renderizar de modo altamente realístico em 3D, e pode fazer uso de um grande banco de dados dos edifícios na cidade de Nova York, assim como um banco de dados do edifício sob projeto.
O aplicativo de projeto arquitetô- Fm nico executar em um, ou se requerer uma grande quantidade de potência '
computacional, em muitos, dos servidores de app/jogo 1521-1525. Cada um
—dos3 usuários em locais discrepantes se conectará ao serviço de hospeda-
gem 210, e terá uma vista simultânea da saída de vídeo do aplicativo de pro-
jeto arquitetônico, porém, estará apropriadamente dimensionado pela com-
pactação de hardware compartilhado 1530 para o determinado dispositivo e características de conexão de rede que cada usuário tem (por exemplo, a firma de arquitetura pode ver uma exibição 2560x1440 60fps através de uma conexão comercial à Internet de 20Mbps, o construtor imobiliário em Nova
York pode ser uma imagem de 1280x720 60fps por uma conexão DSL de 6
| Mbps em seu laptop, e o investidor pode ver uma imagem de 320x180 60fps | por uma conexão de dados via celular de 250Kbps em seu telefone móvel. |
Cada parte escutará a voz das outras partes (a chamada de conferência se-
rá manipulada por qualquer entre os muitos pacotes de sofiware de chama- Í 5 da de conferência amplamente disponíveis no(s) servidor(es) de app/jogo [ : 1521-1525) e, através do acionamento de um botão em um dispositivo de ! entrada de usuário, um usuário será capaz de fazer com que o vídeo apare- i ça utilizando-se sua câmera local.
À medida que a reunião procede, os ar-
quitetos serão capazes de mostrar como o edifício se parece à medida que o giraeo leva para próximo a outro edifício na área, com uma renderização fee À em 3D extremamente fotorrealística, e o meso vídeo será visível a todas as partes, na resolução de cada dispositivo de exibição.
Não importará que ne-
É nhum dos dispositivos locais usados por qualquer parte seja incapaz de ma-
r nusear animação em 3D com tal realismo, deixado sozinho transferindo por download ou até mesmo armazenando um vasto banco de dados requerido
: para renderizar os edifícios vizinhos na cidade de Nova York.
À partir do ponto de vista de cada um dos usuários, apesar da distância, e apesar dos
Ê dispositivos locais discrepantes, eles simplesmente terão uma experiência contínua com um grau incrível de realismo.
E, quando uma parte desejar que seurosto seja visto para melhor transmitir seu estado emocional, ela pode fazê-lo.
Além disso, se o construtor imobiliário ou o investidor desejarem as-
sumir o controle do programa arquitetônico e usar seu próprio dispositivo de Fr entrada (seja um teclado, mouse, teclado numérico ou tela sensível ao to- :
que), eles podem, e responderão sem latência perceptual (supondo-se que sua conexão de rede não tenha uma latência irracional). Por exemplo, no caso do telefone móvel, se o telefone móvel estiver conectado a uma rede
WiFi no aeroporto, este terá uma latência muito baixa.
Porém, se utilizar as redes de dados celulares disponíveis atualmente nos EUA, provavelmente sofrerão de um tempo de retardo considerável.
Ainda, para a maioria dos propósitos da reunião, onde o investidor está vendo os arquitetos controla-
rem o edifício ou conversando em teleconferência, até mesmo a latência ce-
lular deve ser aceitável.
! Finalmente, ao fim da chamada de conferência colaborativa, o construtor imobiliário e o investidor farão seus comentários e sairão do servi- | ço de hospedagem, a firma de arquitetura será capaz de "rebobinar" o vídeo E da conferência que foi gravado em um buffer de retardo 1515 e analisar os r ] 5 comentários, expressões faciais e/ou ações aplicadas ao modelo em 3D do L ; edifício realizadas durante a reunião.
Se existirem segmentos particulares | que eles desejam salvar, estes segmentos de vídeo/áudio podem ser movi- dos do buffer de retardo 1515 para uma matriz RAID 1511-1512 para um ' " armazenamento arquivado e reprodução posterior.
Da mesma forma, a partir de uma perspectiva de custos, se os : arquitetos apenas precisarem usar a potência computacional e o grande banco de dados da cidade de Nova York durante uma chamada de confe- É rência de 15 minutos, eles precisam apenas pagar pelo tempo que os recur- f sos foram usados, ao invés de precisar ter estações de trabalho fortes e ad- —quiriruma cópia cara de um grande banco de dados. k Serviços Comunitários Predominantemente Visuais O serviço de hospedagem 210 permite uma oportunidade sem Í precedentes para estabelecer serviços comunitários predominantemente visuais na Internet.
A figura 20 mostra uma User Page exemplificadora para um jogador no serviço de hospedagem 210. Assim como o aplicativo Game Finder, o User Page é um aplicativo que é executado em um dos servidores de app/jogo 1521-1525. Todas as miniaturas e janelas de vídeo nesta página r mostram vídeos constantemente em movimento (se os segmentos forem + curtos, eles executam loop). Utilizando-se uma câmera de vídeo ou carregando-se vídeo, o usuário (cujo nome de usuário é "KILLHAZARD") é capaz de postar um ví- deo dele mesmo 2000 que outros usuários possam ver.
O vídeo é armaze- nado em uma matriz RAID 1511-1512. Da mesma forma, quando outros u- suários visitaaem a User Page de KILLHAZARD, se KILLHAZARD estiver usado o serviço de hospedagem 210 no momento, o vídeo ao vivo 2001 de qualquer coisa que ele estiver fazendo (supondo-se que ele permite que u- suários entrem em sua User Page para vê-lo) será mostrado.
Isto será reali-
i zado pelo servidor de app/jogo 1521-1525 que hospeda o aplicativo de User | Page solicitado a partir do sistema de controle de serviço 401 se KILLHA- ZARD estiver ativo, e, se estiver, o servidor de app/jogo 1521-1525 que ele está usando.
Então, utilizando-se os mesmos métodos usados pelo aplicati- | 5 voGame Finder, um fluxo de vídeo compactado em uma resolução e forma- Í | to adequados será enviado ao servidor de app/jogo 1521-1525 que executa | o aplicativo User Page e o mesmo será exibido.
Se um usuário selecionar a : janela com o jogo ao vivo de KILLHAZARD, e, então, clicar apropriadamente em seu dispositivo de entrada, a janela será maximizada (novamente utili- zando-se os mesmos métodos dos aplicativos Game Finder, e o vídeo ao vivo preencherá a tela, na resolução do dispositivo de exibição do usuário espectador 422, apropriada para as características da conexão de Internet do usuário espectador. f Uma vantagem principal disto em relação às abordagens da téc- nica anterior é que o usuário visualizando a User Page é capaz de ver um E jogo jogado ao vivo que o usuário não possui, e pode muito bem não ter um computador local ou console de jogo capaz de jogar o jogo.
Isto oferece uma É grande oportunidade para o usuário veja o usuário mostrado na User Page "em ação" jogando jogos, e uma oportunidade para aprender sobre um jogo queo usuário espectador pode desejar tentar ou se aperfeiçoar.
Os videoclipes gravados por câmera ou carregados dos amigos de KILLHAZARD 2002 também são mostrados na User Page, e abaixo de - cada videoclipe tem um texto que indica que o amigo está online jogando um " jogo (por exemplo, six shot está jogando o jogo "Eragon" (mostrado aqui como Game4) e MrSnuggles99 está Offline, etc.). Clicando-se em um item de menu (não mostrado), os videoclipes do amigo trocam de vídeos grava- dos ou carregados para vídeo ao vivo de o que os amigos que estão atual- mente jogando os jogos no serviço de hospedagem 210 estão fazendo neste momento em seus jogos.
Logo, torna-se um grupamento Game Finder para os amigos.
Se o jogo de um amigo for selecionado e o usuário clicar no mesmo, este será maximizado em tela cheia, e o usuário será capaz de as- sistir ao jogo jogado ao vivo em tela cheia.
| Novamente, o usuário assistindo ao jogo do amigo não possui | uma cópia do jogo, nem recursos de console de computação/jogo local para jogar o jogo.
A visualização do jogo é efetivamente instantânea.
Conforme previamente descrito, quando um usuário jogar um jo- E 5 —gonoserviçode hospedagem 210, o usuário é capaz de "rebobinar" o jogo e ! encontrar um segmento de vídeo que ele deseja salvar, e, então, salva o | segmento de vídeo em sua User Page.
Estes são denominados como "Brag Clips'Y". Os segmentos de vídeo 2003 são todos Brag Clips 2003 salvos por eee KILLHAZARD a partir de jogos anteriores que ele jogou.
O número 2004 mostra quantas vezes um Brag Clip foi visualizado, e quando o Brag Clip for visualizado, os usuários têm uma oportunidade de classificá-los, e os ícones com formato de fechadura de número laranja (mostrados como contornos E pretos) 2005 indicam o quão alta é a classificação.
Os Brag Clips 2003 exe- í. cutam loop constantemente quando um usuário visualizar a User Page, junto aorestante do vídeo na página.
Se o usuário selecionar e clicar em um dos Dk Brag Clips 2003, ele maximiza para apresentar o Brag Clip 2003, junto aos controles de DVR de modo a permitir que o clipe seja reproduzido, pausado, rebobinado, avançado rapidamente, saltado, etc.
A reprodução de Brag Clip 2003 é implementada pelo servidor de app/jogo 1521-1525 que carrega o segmento de vídeo compactado ar- mazenado em uma matriz RAID 1511-1512 quando o usuário gravou o Brag Clip e o descompacta e o reproduz. = Os Brag Clips 2003 também podem ser segmentos de vídeo "3D DVR" (isto é, uma sequência de estado de jogo a partir do jogo que pode ser reproduzido novamente e permite que o usuário altere o ponto de vista da câmera) a partir de jogos que suportam tal capacidade.
Neste caso, as in- formações de estado de jogo são armazenadas, além de uma gravação de vídeo compactado do "sobrevoo" particular que o usuário realizou quando o segmento de jogo foi gravado.
Quando a User Page estiver sendo visualiza- da,etodasas miniaturas e janelas de vídeos estiverem constantemente e- xecutando loop, um Brag Clip 3D DVR 2003 constantemente executará loop do Brag Clip 2003 que foi gravado como um vídeo compactado quando o
! usuário gravou o "sobrevoo" do segmento de jogo.
Porém, quando um usuá- | rio selecionar um Brag Clip 3D DVR 2003 e clicar no mesmo, além dos con- troles de DVR para permitir que o Brag Clip de vídeo compactado seja re- produzido, o usuário será capaz de clicar em um botão que fornece a eles | 5 uma capacidade de 3D DVR para o segmento de jogo.
Eles serão capazes i de controlar por si próprios uma câmera de "sobrevoo" durante o segmento | de jogo, e, se desejarem (e o usuário que possui a página de usuário permi- ti), serão capazes de gravar um Brag Clip de "sobrevoo" alternativo em uma eee forma de vídeo compactado que estará disponível a outros espectadores da página de usuário (seja imediatamente, ou após o proprietário da página de : usuário tiver uma chance de analisar o Brag Clip). Esta capacidade de Brag Clip 3D DVR 2003 é habilitada ativan- E do-se o jogo que está para reproduzir novamente as informações de estado f de jogo gravadas em outro servidor de app/jogo 1521-1525. Visto que o jogo pode ser ativado quase instantaneamente (conforme descrito anteriormente), . não é difícil ativá-lo, com seu jogo limitado ao estado de jogo gravado pelo segmento Brag Clip, e, então, permitir que o usuário realize um "sobrevoo" com uma câmera enquanto grava o vídeo compactado em um buffer de re- tardo 1515. Uma vez que o usuário tiver completado a realização do "sobre- voo",ojogo é desativado.
A partir do ponto de vista do usuário, a ativação de um "sobre- voo" com um Brag Clip 3D DVR 2003 não é mais difícil do que controlar os = controles DVR de um Brag Clip linear 2003. Estes podem não saber nada h sobre o jogo ou nem mesmo como jogá-lo.
Estes consistem apenas em um operador de câmera virtual visualizando em um mundo 3D durante um seg- mento de jogo gravado por outro.
Os usuários também serão capazes de realizar overdub em seu próprio áudio em Brag Clips que seja gravado a partir de microfones ou car- í regado.
Desta forma, os Brag Clips podem ser usados para criar animações — personalizadas, utilizando-se os personagens e as ações dos jogos.
Esta técnica de animação é comumente conhecida como "machinima". À medida que os usuários progridem através dos jogos, eles a-
| tingirão diferentes níveis de habilidade.
Is jogos jogados reportarão as reali- | zações ao sistema de controle de serviço 401, e estes níveis de habilidade serão mostrados nas User Pages.
Propagandas Animadas Interativas r | 5 As propagandas online realizaram uma transição de texto, para r | imagens imóveis, para vídeo, e agora para segmentos interativos, tipicamen- É te implementados utilizando-se clientes finos de animação como Adobe Fla- f sh.
A razão pela qual os clientes finos de animação serem usados é que os ' E usuários tipicamente têm pouca paciência para serem retardados ao privile- giode terem um produto ou serviço estabelecido a eles.
Da mesma forma, : os clientes finos são executados em PCs de desempenho muito baixo e, como tal, o anunciante pode ter um alto grau de confidência que a propa- f ganda interativa funcionará de modo apropriado.
Infelizmente, os clientes tu finos de animação, tal como Adobe Flash são limitados ao grau de interativi- dadee à duração da experiência (para atenuar o tempo de download e ser E operável em quase todos os dispositivos de usuário, incluindo PCs de baixo desempenho e Macs sem GPUs ou CPUs de alto desempenho). À A figura 21 ilustra uma propaganda interativa onde o usuário deve selecionar as cores exteriores e interiores de um carro enquanto o carro gira em uma sala de exibição, enquanto o traçamento de raios em tempo real mostra como o carro se parece.
Então, o usuário escolhe um avatar para dirigir o carro, e, então, o usuário pode pegar o carro para uma volta seja em uma pista de io corrida, ou em um local exótico, tal como Mônaco.
O usuário pode selecionar : um motor maior, ou melhores pneus, e, então, pode ver como a configuração alterada afeta a capacidade do carro para acelerar ou se manter na pista.
Naturalmente, a propaganda consiste efetivamente em um vide- ogame em 3D sofisticado.
Porém, tal propaganda a ser exibida em um PC ou em um console de videogame talvez requeira um download de 100MB e, no caso do PC, pode requerer a instalação de drivers especiais, e pode não ser executada se o PC não tiver uma capacidade computacional CPU ou GPU.
Portanto, essas propagandas são impraticáveis em configurações da técnica anterior.
| No serviço de hospedagem 210, tais propagandas são iniciadas Í quase instantaneamente, e são perfeitamente rodadas, sem importar quais sejam as capacidades do cliente de usuário 415. Logo, elas são iniciadas mais rapidamente do que as propagandas interativas de cliente fino, são vastamente mais ricos em experiência, e altamente confiáveis. f ! Geometria de Fluxo Contínuo durante Animação em Tempo Real | A matriz RAID 1511-1512 e o roteamento de entrada 1502 po- ; dem proporcionar taxas de dados que sejam tão rápidas e com latências tão Ea baixas que seja possível projetar videogames e aplicativos que dependem da matriz RAID 1511-1512 e do roteamento de entrada 1502 para distribuir ô confiavelmente a geometria de saída no meio do jogo ou em um aplicativo durante uma animação em tempo real (por exemplo, um sobrevoo com um E banco de dados complexo.) ki Através dos sistemas da técnica anterior, tal como um sistema de videogame mostrado na figura 1, os dispositivos de armazenamento em a massa disponíveis, particularmente em dispositivos domiciliares práticos, são muito lentos para geometria de fluxo contínuo durante o jogo exceto em À situações onde a geometria requerida for de alguma forma previsível.
Por exemplo, em um jogo de direção onde existe uma pista específica, a geome- triapara edifícios que surgem em vista pode ser razoavelmente bem prevista e os dispositivos de armazenamento em massa podem buscar antecipada- mente ao local onde a geometria de entrada está localizada. = Porém, em uma cena complexa com alterações imprevisíveis : (por exemplo, em uma cena de batalha com personagens complexos) se a RAM no PC ou sistema de videogame for completamente preenchida com geometria para objetos atualmente em vista, e, então, o usuário gira repenti- namente seu personagem para ver o que tem atrás do personagem, se a geometria não tiver sido pré-carregada em RAM, então, pode haver um re- tardo antes de o mesmo poder ser exibido.
No serviço de hospedagem 210, as matrizes RAID 1511-1512 podem realizar fluxo contínuo em dados em excesso de velocidade Gigabit Ethernet, e com uma rede SAN, é possível alcançar uma velocidade de 10 gigabit/segundo em uma Ethernet de 10 Gigabit ou por outras tecnologias de ! rede. 10 gigabits/segundo carregarão um gigabyte de dados em menos de | um segundo.
Em um tempo de quadro de 60fps (16,67ms), aproximadamen- te 170 megabits (21MB) de dados podem ser carregados.
Naturalmente, gi- : 5 rara mídia mesmo em uma configuração RAID ainda incorrerá latências [ | maiores do que um tempo de quadro, porém, o armazenamento RAID base- | | ado em Flash será eventualmente tão grande quanto as matrizes RAID de mídia e não incorrerá tal latência alta.
Em uma modalidade, utiliza-se arma- : É zenamento em cache por gravação massiva em RAM para proporcionar a- cesso de latência muito baixa.
Portanto, com uma velocidade de rede suficientemente alta, e um armazenamento em massa com latência suficientemente baixa, a geo- É metria pode realizar fluxo contínuo em servidores de app/jogo 1521-1525 tão ã rapidamente quanto os CPUs e/ou GPUs podem processar os dados em 3D.
Logo, no exemplo dado previamente, onde um usuário gira seu personagem : repentinamente e olha para trás, a geometria para todos os personagens atrás pode ser carregada antes de o personagem completar a rotação, e, : portanto ao usuário, parecerá que ele se encontra em um mundo foto- realistico que seja tão real quando uma ação ao vivo.
Conforme previamente discutido, uma das últimas fronteiras em animação computacional fotorrealística é o rosto humano, e por causa da sensibilidade dos olhos humanos a imperfeições, o menos erro de um rosto F foto-real pode resultar em uma reação negativa do espectador.
A figura 22 - mostra como um desempenho ao vivo capturado utilizando-se a Tecnologia de Captura de Realidade Contour'"" (assunto dos pedidos co-pendentes: "Apparatus and method for capturing the motion of a performer," Ser.
Nº 10/942.609, depositado em 15 de setembro de 2004; "Apparatus and me- thod for capturing the expression of a performer," Ser.
Nº 10/942.413 deposi- tado em 15 de setembro de 2004; "Apparatus and method for improving marker identification within a motion capture system," Ser.
Nº 11/066.954, depositado em 25 de fevereiro de 2005; "Apparatus and method for perfor- ming motion capture using shutter synchronization," Ser.
Nº 11/077.628, de-
positado em 10 de março de 2005; "Apparatus and method for performing | motion capture using a random pattern on capture surfaces," Ser.
Nº 11/255.854, depositado em 20 de outubro de 2005; "System and method for performing motion capture using phosphor application techniques," Ser.
Nº | 5 11/449131, depositado em 7 de junho de 2006; "System and method for | performing motion capture by strobing a fluorescent lamp," Ser.
Nº | | 11/449.043, depositado em 7 de junho de 2006; "System and method for Í : three dimensional capture of stop-motion animated characters," Ser.
Nº eo 11/449.127, depositado em 7 de junho de 2006", sendo que cada um desses é atribuído ao requerente do presente pedido CIP) resulta em uma superfície capturada bastante suave, então, uma superfície rastreada por contagem de polígonos (isto é, o movimento poligonal segue o movimento do rosto preci- Á samente). Finalmente, quando o vídeo do desempenho ao vivo for mapeado EF na superfície rastreada para produzir uma superfície texturizada, produz-se um resultado foto-real . Muito embora uma tecnologia GPU atual seja capaz de renderi- zar o número de polígonos na superfície rastreada e texturizar e iluminar a É superfície em tempo real, se os polígonos e texturas forem alterados a cada tempo de quadro (que produzirá os resultados mais foto-reais), rapidamente —consumirão toda a RAM disponível de um PC moderno ou de um console de videogame.
Utilizando-se as técnicas de geometria de fluxo contínuo descri- - tas anteriormente, torna-se prático alimentar continuamente a geometria nos - servidores de app/jogo 1521-1525 de tal modo que possam animar rostos fotoreais continuamente, permitindo a criação de videogames com rostos que sejam quase indistinguíveis de rostos de ação ao vivo.
Integração de Conteúdo Linear com Recursos Alternativos Filmes de cinema, programação de televisão e material de áudio (coletivamente, "conteúdo linear") estão amplamente disponíveis para usuá- rios domésticos e corporativos em muitas formas.
O conteúdo linear pode ser adquirido em mídia física, como mídia de CD, DVD e Blu-ray.
Também pode ser registrado por DVRs a partir de radiodifusão de TV a cabo e satéli-
! te. Ademais, está disponível como conteúdo pay-per-view (PPV) através de | satélite e TV a cabo e como vídeo sob demanda (VOD) em TV a cabo.
Crescentemente, o conteúdo linear está disponível através da In- ternet, tanto como conteúdo transferido por download quanto como conteúdo j 5 —defluxocontínuo. Atualmente, não há de fato um local para ir a fim de expe- | rimentar todos os recursos associados à mídia linear. Por exemplo, DVDs e | outra mídia óptica de vídeo têm tipicamente recursos interativos não dispo- níveis em qualquer lugar, como comentários do diretor, clipes de "making ES aaaaaaNaa of", etc. Os sites de música online abrangem informações sobre arte e can- ções geralmente não disponíveis em CDs, mas nem todos os CDs estão disponíveis online. E os sites da web associados à programação de televisão têm frequentemente recursos, blogs e, algumas vezes, comentários extra É dos atores ou pessoal de criação. f Adicionalmente, com muitos filmes de cinema ou eventos espor- tivos, existem frequentemente vídeo games que são liberados (no caso de . filmes de cinema) frequentemente junto com a mídia linear ou (no caso de esportes) podem estar estritamente atrelados a eventos do mundo real (por | exemplo, o comércio de jogadores). O serviço de hospedagem 210 é bem adequado para a distribui- ção de conteúdo linear na ligação de formas distintas de conteúdo relacio- nado. Certamente, a distribuição de filmes de cinema não é mais desafiado- ra que a distribuição de vídeo games altamente interativos, e o serviço de " hospedagem 210 é capaz de distribuir conteúdo linear para uma ampla faixa ' de dispositivos, no lar ou no escritório, ou para dispositivos móveis. A figura 23 mostra uma página de interface de usuário exemplificativa para serviço de hospedagem 210 que mostra uma seleção de conteúdo linear.
Mas, diferentemente da maioria dos sistemas de distribuição de conteúdo linear, o serviço de hospedagem 210 também é capaz de distribuir componentes interativos relacionados (por exemplo, os menus e recursos em bDVDs,as sobreposições interativas em HD-DVDs, e animação em Ado- be Flash (conforme explicado abaixo) em sites da web). Dessa forma, as limitações do dispositivo do cliente 415 não mais introduzem limitações com
Í para as quais os recursos estão disponíveis. i Adicionalmente, o sistema de hospedagem 210 é capaz de unir | o conteúdo linear com conteúdo de vídeo game dinamicamente, em tempo real.
Por exemplo, se um usuário estiver assistindo uma partida de Quadribol | 5 em um filme do Harry Potter, e decide que quer tentar jogar Quadribol, ele ! pode apenas clicar em um botão e o filme irá pausar e imediatamente ele será transportado para o segmento de Quadribol de um vídeo game do Har- ! ny Potter.
Após jogar a partida de Quadribol, um outro clique de um botão, e ISSSSSNSSNNNS o filme irá reiniciar instantaneamente.
Com tecnologia de produção e gráficos fotorreais, onde o vídeo capturado fotograficamente é indistinguível a partir de personagens de ação ao vivo, quando um usuário realiza uma transição de um jogo de Quadribol em um filme de ação ao vivo para um jogo de Quadribol em um vídeo game F em um serviço de hospedagem conforme descrito no presente documento, as duas cenas são virtualmente indistinguíveis.
Isto fornece opções criativas : totalmente novas para diretores tanto de conteúdo linear quanto de conteúdo interativo (por exemplo, vídeo game) conforme as linhas entre as duas pala- É vras se tornam indistinguíveis.
Através da utilização da arquitetura de serviço de hospedagem mostrada na figura 14, o controle da câmera virtual em um filme 3D pode ser oferecido ao expectador.
Por exemplo, em uma cena que ocorre dentro de um vagão de trem, seria possível permitir que o expectador controle a câme- - ra virtual e observe em torno do vagão, enquanto o roteiro progride.
Consi- - dera-se que todos os objetos 3D ("ativos") no vagão estejam disponíveis bem como um nível adequado de potência de computação capaz de produzir as cenas em tempo real bem como o filme original E até mesmo para entretenimento não gerado por computador, existem muito recursos interativos excitantes que podem ser oferecidos.
Por exemplo, o filme de cinema de 2005 "Pride and Prejudice" teve muitas cenas em mansões inglesas antigas ornadas.
Para certas cenas da mansão, o u- suário pode pausar o vídeo e, então, controlar câmera para fazer um tour pela mansão, ou talvez a área circundante.
Para implantar isto, uma câmera
| poderia ser carregada através da mansão com uma lente olho de peixe pos- | to que deixa um rastro de sua posição, bem como o QuickTime VR da Apple, ! Inc. da técnica anterior é implementado.
Os vários quadros seriam, então, | transformados, então, as imagens não são distorcidas e, então, armazena- | 5 dosem matriz RAID 1511-1512 junto com o filme, e reproduzidos novamente : ! quando o usuário escolhe participar de um tour virtual. à Com eventos esportivos, um evento de esportes ao vivo, tal co- i mo um jogo de basquetebol, pode ser transmitido através do serviço de hos- EssEsNssaa pedagem 210 para usuários assistir, como se fosse para TV regular.
Após os usuáriosterem assistidos um jogo particular, um vídeo game do jogo (even- Ã tualmente com jogadores de basquetebol parecidos com os jogadores reais) poderia aparecer com os jogadores iniciando na mesma posição, e os usuá- rios (talvez cada um tomando controle de um jogador) poderiam refazer a partida para ver se eles poderiam fazer melhor que os jogadores.
O serviço de hospedagem 210 descrito no presente documento é extremamente bem adequado para suportar este mundo futurístico, pois é capaz de suportar potência computacional e recursos de armazenamento Í em massa que são impraticáveis para a instalação em um lar ou na maioria das instalações de um escritório, e também seus recursos computacionais estãosempre atualizados, com o último hardware de computação disponível, enquanto que em uma instalação doméstica, sempre haverá lares com PCs e vídeo games de geração mais antiga.
Ademais, no serviço de hospedagem be 210, toda esta complexidade computacional é escondida do usuário, mesmo . que este possa estar usando sistemas muito sofisticados, do ponto de vista do usuário, é simples como trocar os canais da televisão.
Adicionalmente, o usuário seria capaz de acessar toda a potência computacional e as experi- ências da potência computacional seriam trazidas de qualquer cliente 415. Jogos para Múltiplos Jogadores Desde que um jogo seja um jogo para múltiplos jogadores, en- tão, este será capaz de se comunicar tanto com servidores de jogo/aplicativo 1521-1525 através de rede de roteamento de entrada 1502 quanto com uma ponte de rede com a Internet (não mostrada) com máquinas de jogo ou ser-
Í vidores que não estão operando no serviço de hospedagem 210. Quando se | joga jogos para múltiplos jogadores com computadores na Internet geral, ! então, os servidores de jogo/aplicativo 1521-1525 terão o benefício de aces- so extremamente rápido à Internet (em comparação a se o jogo estava ope- i 5 randoem um servidor no lar), mas eles seriam limitados pelas capacidades f Í dos outros computadores que executam o jogo em conexões mais lentas, e T também potencialmente limitados pelo fato de que os servidores do jogo na ! Internet foram designados para acomodar o menor denominador comum, o À ISENASSNSNNAs que seria para computadores domésticos em conexões de Internet do con- sumidor relativamente lentas. ; Mas quando um jogo para múltiplos jogadores é jogado total- mente dentro de um centro servidor de serviço de hospedagem 210, então, um mundo de diferença é alcançável. Cada servidor de jogo/aplicativo 1521- f 1525 que hospeda um jogo para um usuário será interconectado com outros servidores de jogo/aplicativo 1521-1525 bem como quaisquer servidores que kb estão hospedando o controle central para o jogo para múltiplos jogadores com velocidade extremamente alta, conectividade de latência extremamente : baixa e muitos arranjos de armazenamento muito rápidos. Por exemplo, se Gigabit Ethernet for usado para a rede de roteamento de entrada 1502, en- tão,os servidores de jogo/aplicativo 1521-1525 estarão se comunicando uns com os outros e se comunicando com quaisquer servidores que hospedam o controle central para o jogo para múltiplos jogadores em velocidade de giga- r bit/segundo com potencialmente apenas 1ms de latência ou perda. Adicio- " nalmente, os arranjos RAID 1511-1512 serão capazes de responder muito rapidamente e, então, transferir dados em velocidades de gigabit/segundo.
Como exemplo, se um usuário personalizar um personagem em termos de aparência e equipamentos de tal modo que o personagem tenha uma gran- de quantidade de geometria e comportamentos que são exclusivos para o personagem, com sistemas da técnica anterior limitados ao cliente de jogo que opera no lar em um PC ou console de jogo, se aquele personagem esti- ver sendo visualizado por outro usuário, o usuário teria que esperar pela conclusão de uma transferência por download lenta e vagarosa de modo que
I todos os dados de geometria e comportamento carreguem em seu computa- | dor.
Dentro do serviço de hospedagem 210, a mesma transferência por download poderia ser por Gigabit Ethernet, servido a partir de um arranjo RAID 1511-1512 em velocidade de gigabit/segundo.
Mesmo se o usuário domésticoteve uma conexão com a Internet de 8Mbps (que é extremamente Í | rápida para os padrões atuais), a Gigabit Ethernet é 100 vezes mais rápida. | Então, o que levaria um minuto pela conexão de Internet rápida, levaria me- nos de um segundo pela Gigabit Ethernet. ea Agrupamentos e Torneios de Melhor Jogador O serviço de hospedagem 210 é extremamente bem adequado para torneios.
Devido ao fato de que nenhum jogo está sendo executado em um cliente local, não há oportunidade para usuários conversaram (por e- À xemplo, conforme seria o caso em um torneio da técnica anterior através da f modificação da cópia do jogo que está sendo executado em seu PC local para proporcioná-los uma vantagem injusta). Ademais, devido à capacidade : do roteamento de saída 1540 em multidifundir os fluxos de UDP, o serviço de hospedagem 210 é capaz de radiodifundir os principais torneios para mi- lhares ou mais pessoas na audiência de uma só vez.
Na realidade, quando existem certos fluxos de vídeo que são muito populares em que milhares de usuários estão recebendo o mesmo fluxo (por exemplo, mostrando visualizações de um torneio principal), pode ser mais eficaz enviar o fluxo de vídeo para uma Rede de Distribuição de fe Conteúdo (CDN) tal como Akamai ou Limelight para distribuição de massa , para muitos dispositivos do cliente 415. Um nível similar de eficácia pode ser obtido quando uma CDN é usada para mostrar uma página de Game Finder de melhores agrupamentos de jogador.
Para torneios principais, um locutor famoso ao vivo pode ser u- sado para fornecer comentário durante certas partidas.
Embora um grande número de usuários esteja assistindo um torneio principal e um número rela- tivamente pequeno esteja jogando no torneio.
O áudio do locutor famoso pode ser roteado para os servidores de jogo/aplicativo 1521-1525 que hos-
pedam os usuários que jogam no torneio e que hospedam quaisquer cópias i do modo espectador do jogo no torneio, e o áudio pode ser depurado em | | cima do áudio do jogo.
O vídeo de um locutor famoso pode ser sobreposto 7 nos jogos, talvez, somente em visualizações de espectador. 7 5 Aceleração de Carregamento de Página da Web [ A World Wide Web e seu protocolo de transporte primário, Pro- | tocolo de Transferência de Hipertexto (HTTP), foram concebidos e definidos em uma era em que somente empresas tinham conexões com a Internet de E alta velocidade, e os consumidores que estiveram online estavam usando modems de discagem ou ISDN.
Naquele tempo, o "padrão de ouro" para uma conexão rápida era uma linha T1 que fornecia 1,5Mbps de taxa de da- dos simetricamente (isto é, com taxa de dados igual em ambas as direções). Á Atualmente, a situação é completamente diferente.
A velocidade f de conexão doméstica média através de conexões por cable modem ou DSL em grande parte do mundo desenvolvido tem taxa de dados a jusante muito . mais alta que uma linha T1. De fato, em algumas partes do mundo, a fibra até a calçada (FTTC) está trazendo taxas de dados tão altas quanto 50 a 100Mbps para o lar.
Desafortunadamente, o HTTP não foi arquitetado (nem implan- tado) para levar vantagem de modo eficaz sobre estes aprimoramentos de velocidade dramáticos.
Um site da web é uma coleção de arquivos em um servidor remoto.
Em termos muito simples, o HTTP solicita o primeiro arqui- - vo, espera que o arquivo seja transferido por download e, então, solicita o - segundo arquivo, espera que o arquivo seja transferido por download, etc.
Na realidade, o HTTP permite que mais de uma "conexão aberta", isto é, mais de um arquivo seja solicitado por vez, mas, devido aos padrões con- sentidos (e um desejo de impedir que os servidores da web sejam sobrecar- regados) somente muito poucas conexões abertas são permitidas.
Além dis- so, por causa da maneira na qual as páginas da web são construídas, os — navegadores frequentemente não estão atentos às múltiplas páginas simul- tâneas que poderiam estar disponíveis para transferência por download ime- diatamente (isto é, somente após a passagem de uma página que se torna
| evidente que um novo arquivo, como uma imagem, precisa ser transferido | por download). Dessa forma, os arquivos em site da web são essencialmen- te carregados um por um.
Ademais, por causa do protocolo de solicitação e resposta usado por HTTP, há aproximadamente (acessando servidores da | 5 web típicosnos EUA) uma latência de 100ms associada a cada arquivo que ! é carregado. | ó Com conexões de velocidade relativamente baixa, isto não cau- | sa muito problema, devido ao fato de o tempo de transferência por download Se para os próprios arquivos domina o tempo de espera para as páginas da web.
Mas, conforme as velocidades de conexão crescem, especialmente : com páginas da web complexas, problemas começam a surgir.
No exemplo mostrado na figura 24, um site da web comercial ti- : pico é mostrado (este site da web particular era de uma marca de calçados r atléticos principal). O site da web tem 54 arquivos.
Os arquivos incluem ar- — quivos HTML, CSS, JPEG, PHP, JavaScript e Flash, e incluem conteúdo de : vídeo.
Um total de 1,5MBytes precisa ser carregado antes que a página es- teja no ar (isto é, o usuário pode clicar nisto e começar a usar). Existe inú- É meras razões para o grande número de arquivos.
Uma delas é uma página da web complexa e sofisticada e, a outra, é uma página da web que é mon- tada dinamicamente com base nas informações sobre o usuário que acessa a página (por exemplo, qual país de origem do usuário, qual língua, se o u- suário fez compras antes, etc.), e dependente de todos estes fatores, dife- - rentes arquivos são transferidos por download.
Ainda, é uma página da web . comercial muito típica.
A figura 24 mostra a quantidade de tempo que decorre antes que a página da web esteja no ar conforme a velocidade de conexão cresce.
Com uma velocidade de conexão de 1,5 Mbps 2401, com o uso de um ser- vidor da web convencional com um navegador da web convencional, isto leva 13,5 segundos até que a página da web esteja no ar.
Com uma veloci- dade de conexão de 12 Mbps 2402, o tempo de carga é reduzido para 6,5 segundos, ou cerca de duas vezes.
Mas com uma velocidade de conexão de 96 Mbps 2403, o tempo de carga é somente reduzido em cerca de 5,5 se-
| gundos.
A razão pela qual é porque em tal velocidade de transferência por i download alta, o tempo para transferir por download os próprios arquivos é | mínimo, mas a latência por arquivo, aproximadamente 100 ms cada, ainda permanece, resultando em 54 arquivos * 100 ms = 5,4 segundos de latência.
Dessa forma, não importa quão rápida a conexão para o lar é, este site da [ : web levará sempre pelo menos 5,4 segundos até que esteja no ar.
Um outro | fator é o enfileiramento do lado do servidor; cada solicitação de HTTP é adi- ! cionada na parte posterior da fila, então, em um servidor ocupado isto terá Ae um impacto significativo porque para cada item pequeno a ser obtido a partir do servidor da web, as solicitações de HTTP precisam esperar por sua vez.
Uma maneira de resolver estas questões consiste em descartar ou redefinir HTTP.
Ou, talvez para conseguir que o proprietário do site da É web consolide melhor seus arquivos em um único single arquivo (por exem- T plo, em formato de Adobe Flash). Mas, como uma questão prática, esta em- presa, bem como muitas outras, tem uma grande transação de investimento x em sua arquitetura do site da web.
Adicionalmente, embora alguns lares te- nham conexões de 12 a 100 Mbps, a maioria dos lares ainda tem velocida- : des inferiores, e HTTP funciona bem em baixa velocidade.
Uma alternativa é hospedar navegadores da web em servidores de jogo/aplicativo 1521-1525, e hospedar os arquivos para os servidores da web nos arranjos RAID 1511-1512 (ou potencialmente em RAM ou em ar- mazenamento local nos servidores de jogo/aplicativo 1521-1525 que hospe- - dam os navegadores da web.
Por causa da interconexão muito rápida atra- - vés do roteamento de entrada 1502 (ou armazenamento local), em vez de ter100ms de latência por arquivo com o uso de HTTP, haverá menos latên- cia por arquivo com o uso de HTTP.
Então, em vez de o usuário em sua ca- sa acessar a página da web através de HTTP, o usuário pode acessar a pá- gina da web através do cliente 415. Então, mesmo com uma conexão de 1,5 Mbps (por causa disto a página da web não requer muita largura de vídeo para seu vídeo), a página da web estará no ar em menos de 1 segundo por linha 2400. Essencialmente, não haverá latência antes de o navegador da web que opera em um servidor de aplicativo/jogo 1521-1525 estar exibindo
| uma página no ar, e não haverá latência detectável antes de o cliente 415 | exibir a saída de vídeo do navegador da web.
Conforme o usuário movimen- ta o mouse em torno e/ou digita na página da web, as informações de entra- da de usuário serão enviadas para o navegador da web que opera no servi- : 5 — dorde aplicativo/iogo 1521-1525, e o navegador da web irá responder con- [ i sequentemente. | Uma desvantagem desta abordagem é se o compressor estiver constantemente transmitindo dados de vídeo, então, a largura de vídeo é O á usada, mesmo se a página da web se tornar estática.
Isto pode ser remedia- do através da configuração do compressor para transmitir somente dados quando (e se) a página da web alterar e, então, somente transmitir dados para as partes da página que se alteram.
Embora existam algumas páginas Á da web com banners piscando, etc. que estão constantemente em alteração, iá tais páginas da web tendem a ser perturbadoras, e usualmente as páginas da web são estáticas salvo se houver uma razão para algo estar em movi- . mento (por exemplo, um clipe de vídeo). Para tais páginas da web, é mais provável o caso em que menos dados serão transmitidos com o uso do ser- É viço de hospedagem 210 que um servidor da web convencional, devido ao fato de que somente as imagens exibidas reais serão transmitidas, nenhum código executável por cliente pequeno, e nenhum objeto grande que nunca pode ser visualizado, tais como imagens giratórias.
Dessa forma, com o uso do serviço de hospedagem 210 para = hospedar páginas da web de legado, os tempos de carregamento da página y da web podem ser reduzidos para o point em que abrir uma página da web é como alterar canais em uma televisão: a página da web está no ar eficaz e instantaneamente.
Facilitação de Depuração de Jogos e Aplicativos Conforme mencionado anteriormente, os vídeo games e aplicati- vos com gráficos em tempo real são aplicativos muito complexos e tipica- mente quando são liberados no campo contêm erros.
Embora os desenvol- vedores de software obtenham retroalimentação de usuários sobre erros, e possam ter alguns meios para superar o estado da maquina após crashes, é
| muito difícil identificar exatamente o que causou a pane em um jogo ou apli- i cativo em tempo real ou a execução inapropriada.
Quando um jogo ou aplicativo opera no serviço de hospedagem 210, a saída de vídeo/áudio do jogo ou aplicativo é constantemente registra- . 5 daem uma memória temporária de atraso 1515. Adicionalmente, um pro- [ | cesso de monitoração opera em cada servidor de aplicativo/jogo 1521-1525 | que relata regularmente ao sistema de controle de serviço de hospedagem | 401 que o servidor de aplicativo/jogo 1521-1525 está operando suavemente. = Se o processo de monitoração falhar no relatório, então, o sistema de con- trole do servidor 401 irá tentar se comunicar com o servidor de aplicati- vo/jogo 1521-1525, e se bem sucedido, irá coletar qual estado de máquina está disponível.
Quaisquer que sejam as informações disponíveis, junto com É o vídeo/áudio registrado pela memória temporária de atraso 1515 serão en- f viadas para o desenvolvedor do software.
Dessa forma, quando o desenvolvedor do software de jogo ou . aplicativo obter o aviso de uma pane do serviço de hospedagem 210, ele obtém um registro quadro a quadro de o que levou à pane.
Estas informa- ções podem ser imensamente valiosas no rastreamento de erros e no con- serto dos mesmos.
Note também que quando um servidor de aplicativo/jogo 1521- 1525 entra em pane, o servidor é reiniciado no ponto reiniciável mais recen- te, e uma mensagem é fornecida para o usuário com desculpas pela dificul- = dade técnica. . Compartilhamento de Recurso e Economias de Custo O sistema mostrado nas figuras 4a e 4b fornece uma variedade de benefícios tanto para usuários finais quanto para desenvolvedores de jogo e aplicativo.
Por exemplo, tipicamente, sistemas de cliente doméstico e corpo- rativo (por exemplo, PCs ou consoles de jogo) estão somente em uso por uma pequena porcentagem de horas em uma semana.
De acordo com uma publi- cação de 5 de outubro de 2006 de Nielsen Entertainment "Active Gamer Benchmark Study" (http://www.prnewswire.com/cgi- bin/stories.pl PACCT=104&STORY=/www/story/1 0-05-2006/00044461 15&EDATE=)
! os jogadores ativos gastam em média 14 horas por semana jogando em consoles de vídeo game e cerca de 17 horas por semana em portáteis.
O relatório também relata que para toda atividade de jogo (incluindo console, | portátil e jogo em PC), os jogadores ativos gastam em média 13 horas por [ | 5 semana.
Levando em consideração a figura superior do tempo de jogo em ç Í console de vídeo game, existe 24*7=168 horas em uma semana, o que im- [ plica em dizer que um lar do jogador ativo, um console de vídeo game está em uso somente 17/168=10% das horas de uma semana.
Ou, 90% do tem- Seo po, o console de vídeo game está inativo.
Dado o alto custo de consoles de vídeo game, e o fato de que os fabricantes subsidiam tais dispositivos, isto é um uso muito ineficiente de um recurso dispendioso.
Os PCs em empresas são também tipicamente usados somente em uma fração das horas da se- E mana, especialmente, PCs do tipo desktop não portáteis frequentemente requeridos para aplicativos de alta tecnologia tal como Autodesk Maya.
Em- bora algumas empresas operem em todas as horas e em feriados, e alguns . PCs (por exemplo, portáteis trazidos para casa para a realização de traba- lhos à noite) são usados em todas as horas e feriados, a maioria das ativi- dades empresariais tende a estar em torno de 9 h às 17 h, em uma determi- nada zona de tempo empresarial, de segunda-feira à sexta-feira, menos feri- ados e pausas (tal como almoço), e uma vez que a maioria dos usos do PC ocorre enquanto o usuário está ativamente engajado com o PC, a utilização do PC do tipo desktop tende a seguir estas horas de operação.
Se for consi- FR derado que os PCs são utilizados constantemente de 9 h a 17 h, 5 dias por - semana, isto implicaria no fato de que os PCs são utilizados 40/168=24% das horasda semana.
Os PCs do tipo desktop de desempenho alto são in- vestimentos muito dispendiosos para empresas, e isto reflete um nível de utilização muito baixo.
As escolas que estão ensinando em computadores do tipo desktop podem usar computadores para uma fração ainda menor da semana, e embora isto varie dependendo das horas e ensino, a maioria das aulas ocorre durante as horas do dia de segunda-feira a sexta-feira.
Então, em geral, os PCs e os consoles de vídeo game são utilizados somente em uma pequena fração das horas da semana.
Notavelmente, devido ao fato de que muitas pessoas estão tra- | balhando em empresas ou em escola durante as horas do dia de segunda- feira a sexta-feira sem contar feriados, estas pessoas geralmente não estão jogando vídeo games durante estas horas e, então, quando elas jogam ví- — deo games, isto ocorre geralmente durante outras horas, tais como noites, Á finais de semana e feriados. | ! Dada a configuração do serviço de hospedagem mostrado na fi- gura 4a, os padrões de uso descritos nos dois parágrafos acima resultam em E utilização de recursos muito eficiente.
Obviamente, há um limite no número de usuários que podem usufruir do serviço de hospedagem 210 em um de- . terminado instante, particularmente, se os usuários estão requerendo capa- cidade de resposta em tempo real para aplicativos complexos como vídeo É games 3D sofisticados.
Mas, diferentemente de um console de vídeo game : em uma casa ou um PC usado por uma empresa, que tipicamente estão ina- tivos a maior parte do tempo, os servidores 402 podem ser reutilizados por . diferentes usuários em diferentes instantes.
Por exemplo, um servidor de desempenho alto 402 com CPUs duplos de desempenho alto e GPUs duplos É e uma grande quantidade de RAM pode ser utilizado por empresas e esco- las de 9 h às 17 h em dias úteis, mas ser utilizado por jogadores que jogam um vídeo game sofisticado nas noites, fins de semana e em feriados.
Simi- larmente, os aplicativos de desempenho baixo podem ser utilizados por em- presas e escolas em um servidor de desempenho baixo 402 com um CPU Fr Celeron, sem GPU (ou um GPU muito sem recurso) e RAM limitada durante . as horas de trabalho e um jogo de baixo desempenho pode utilizar um servi- —dorde desempenho baixo 402 durante as horas de folga.
Adicionalmente, com a disposição de serviço de hospedagem descrita no presente documento, os recursos são compartilhados eficiente- mente dentre milhares, se não milhões, de usuários.
Em geral, os serviços online têm somente uma pequena porcentagem de sua base de usuário total como uso do serviço em um determinado instante.
Se for considerado as estatísticas de uso de vídeo game de Nielsen mencionadas anteriormente, é fácil observar o porquê.
Se os jogadores ativos jogam jogos de consoles
| somente 17 horas de uma semana, e se for considerado que o tempo de uso | pico para jogo é durante as horas típicas de folga das noites (17 h às O h, 7*5 dias=35 horas/semana) e final de semana (8 h as O h, 16*2=32 ho- ras/semana), então, existem 35+32=65 horas pico por semana para 17 ho- —rasdejogo.A carga de usuário pico exata no sistema é difícil de estimar por 1 muitas razões: alguns usuários irão jogar durante tempos fora de pico, pode ! À haver certos instantes no dia em que existem picos de usuários agrupados, os tempos de pico podem ser afetados pelo tipo de jogo jogado (por exem- Eee plo, jogos para crianças serão jogados provavelmente mais cedo na noite), etc Mas, posto que o número médio de horas exibido por um jogador é mui- : to menor que o número de horas do dia quando um jogador está provavel- mente jogando um jogo, somente uma fração do número de usuários do ser- É viço de hospedagem 210 estará usando isto em um determinado instante.
À á título de análise, devemos considerar que a carga de pico é 12,5%. Dessa forma, somente 12,5% dos recursos de computação, compressão e largura . de vídeo são usados em um determinado instante, resultando somente em 12,5% do custo de hardware para suportar um determinado usuário para jogar um jogo de determinado nível de desempenho devido à reutilização de recursos.
Além disso, tendo em vista que alguns jogos e aplicativos reque- rem mais potência computacional que outros, os recursos podem ser aloca- dos dinamicamente com base no jogo a ser jogado ou dos aplicativos execu- = tados por usuários.
Então, um usuário que seleciona um jogo ou aplicativo - de baixo desempenho será alocado em um servidor de baixo desempenho (menos dispendioso) 402, e um usuário que seleciona um jogo ou aplicativo de alto desempenho será alocado em um servidor de alto desempenho (mais dispendioso) 402. Na realidade, um determinado jogo ou aplicativo pode ter seções de desempenho inferior e desempenho superior do jogo ou aplicativos, e o usuário pode ser trocado de um servidor 402 para outro ser- —vidor402 entre seções do jogo ou aplicativo para manter o operando no ser- vidor de custo inferior 402 que satisfaz as necessidades do jogo ou do apli- cativo.
Observa-se que os arranjos RAID 405, que serão bem mais rápidos
| que um único disco, estão disponíveis para todos os servidores de desem- | penho baixo 402, que terão o benefício das taxas de transferência de disco mais rápidas. Então, custo médio por servidor 402 por todos os jogos a se- rem jogados ou aplicativos a serem usados é muito menor que o custo do | 5 servidor mais dispendioso 402 que executa os jogos ou aplicativo de de- | sempenho mais altos, ainda até mesmo os servidores de desempenho baixo | 402, irão derivar benefícios de desempenho de disco dos arranjos RAID 405. ! Adicionalmente, um servidor 402 no serviço de hospedagem 210 E pode ser nada mais que uma placa mãe de PC sem um disco ou interfaces : periféricas além de uma interface de rede e, no instante, podem ser integra- do em um único chip com somente uma interface de rede rápida para SAN
403. Ademais, Os arranjos RAID 405 provavelmente serão compartilhados : dentre muito mais usuários que discos, então, o custo do disk por usuário f ativo será muito menor que uma unidade de disco. Todo este equipamento irá provavelmente residir em uma prateleira em um ambiente de servidor . ambientalmente controlado. Se um servidor 402 falhar, isto pode ser pron- tamente reparado ou substituído no serviço de hospedagem 210. Adversa- mente, um PC ou console de jogo no lar ou escritório precisa ser um apare- lho autônomo e resistente que precisa ser capaz de resistir a desgaste razo- ável contra choque ou queda, exigindo um alojamento, ter pelo menos uma unidade de disco, resistir condições ambientais adversas (por exemplo, ser expandido em um gabinete AV superaquecido com outra instalação), requer b uma garantia de serviço, ser embalado e transportado, e vendido por um - varejista que irá coletar um lucro de varejo. Adicionalmente, um PC ou con- —solede jogo precisa ser configurado para satisfazer o desempenho pico da maioria dos jogos ou aplicativos antecipados computacionalmente intensos a serem usados no mesmo instante, apesar de jogos ou aplicativos com de- sempenho inferior (ou seções de jogos ou aplicativos) podem ser jogados a í maior parte do tempo. Ademais, se o PC ou console falhar, é um processo dispendioso e demorado (que impacta adversamente no fabricante, usuário e desenvolvedor do software) repará-lo. Dessa forma, posto que o sistema mostrado na figura 4a fornece
| uma experiência ao usuário comparável a de um recurso computacional lo- cal, para um usuário no lar, escritório ou escola para experimentar um de- terminado nível de capacidade computacional, é muito menos dispendioso fornecer esta capacidade computacional através da arquitetura mostrada na | figurada. | | Eliminação da Necessidade de Atualização á Adicionalmente, os usuários não precisam mais se preocupar sobre atualizar PCs e/ou consoles para jogar novos jogos ou manipular no- o vos aplicativos de desempenho superior.
Qualquer jogo ou aplicativos no serviço de hospedagem 210, independentemente de qual tipo de servidor 402 é requerido para aquele jogo ou aplicativos, está disponível para o usuá- rio, e todos os jogos e aplicativos operam quase instantaneamente (por e- Á xemplo, carregamento rápido dos arranjos RAID 405 ou armazenamento É local em servidores 402) e apropriadamente com as últimas atualizações e consertos de erro (isto é, desenvolvedores do software serão capazes de . escolher uma configuração de servidor ideal para o(s) servidor(es) 402 que opera(m) um determinado jogo ou aplicativo e, então, configurar o(s) servi- E dor(es) 402 com unidades ideais e, então, ao longo do tempo, os desenvol- vedores serão capazes de fornecer atualizações, consertos de erro, etc. pa- ratodas as cópias do jogo ou aplicativo no serviço de hospedagem 210 de uma só vez). Na realidade, após o usuário iniciar o uso do serviço de hospe- dagem 210, é provável que o usuário ache que aqueles jogos e aplicativos - continuam a fornecer uma melhor experiência (por exemplo, através de atua- r lizações e/ou consertos de erro) e pode ser o caso em que um usuário des- cobre um ano depois que um novo jogo ou aplicativo se tornou disponível no serviço 210 que está utilizando a tecnologia computacional (por exemplo, uma GPU de desempenho superior) que não havia um ano antes, então, seria impossível que o usuário comprasse a tecnologia um ano antes para que jogasse o jogo ou executasse aplicativos um ano depois.
Tendo em vis- taqueo recurso computacional que está executando o jogo ou o aplicativo é invisível para o usuário (isto é, a partir da perspectiva do usuário, o usuário está simplesmente selecionando um jogo ou aplicativo que começa a operar
| quase instantaneamente (como se o usuário tivesse trocado os canais em Í uma televisão), o hardware do usuário terá sido "atualizado" sem o usuário mesmo estando ciente da atualização.
Eliminação da Necessidade por Cópias de Segurança Um outro problema principal para usuários em empresas, esco- [ ! las e lares são as cópias de segurança.
As informações armazenadas em Í Á um PC local ou console de vídeo game (por exemplo, no caso de um conso- i le, as conquistas e a classificação do jogo do usuário) podem ser perdidas ! E se um disco falhar, ou se houver um apagamento inadvertido.
Existem mui- tos aplicativos disponíveis que fornecem cópias de segurança manuais ou . automáticas para PCs, e o estado do console de jogo pode ser transferido por upload para um servidor online para cópia de segurança, mas cópias de Ú segurança locais são tipicamente copiadas para um outro disco local (ou f outro dispositivo de armazenamento não volátil) que precisa ser armazenado em algum local seguro e organizado, e as cópias de segurança para servi- . ços online são frequentemente limitadas, por causa da velocidade a montan- te lenta disponível através de conexões de Internet típicas de baixo custo.
À Com o serviço de hospedagem 210 da figura 4a, os dados que são armaze- nados em arranjos RAID 405 podem ser configurados com o uso das técni- cas de configuração RAID da técnica anterior bem conhecida por aqueles elementos versados na técnica de tal modo que se um disco falhar, nenhum dado será perdido, e um técnico no centro do centro de servidor que aloja o ba disco falho será avisado e, então, irá substituir o disco, que, então, será au- - tomaticamente atualizado de modo que o arranjo RAID seja novamente tole- rante á falha.
Adicionalmente, uma vez que todas as unidades de disco es- tão próximas umas das outras e com redes locais rápidas entre elas através do SAN 403, não é difícil em um centro de servidor fazer com que todos os sistemas de disco tenham cópias de segurança em uma base regular para armazenamento secundário, que pode ser armazenado no centro de servi- —dorourelocado externamente.
Do ponto de vista dos usuários de serviço de hospedagem 210, seus dados estão simplesmente seguros a todo instante, e eles nunca precisam se preocupar com cópias de segurança.
| Acesso a Demonstrações | Os usuários frequentemente desejam experimentar jogos ou a- Í plicativos antes de comprá-los. Conforme descrito anteriormente, existem meios da técnica anterior através dos quais se demonstra jogos e aplicativos | 5 (a forma verbal de "demonstração" significa experimentar uma versão de | demonstração, que também é chamada de "demonstração", mas como um | substantivo), mas cada um deles sofre de limitações e/ou inconveniências.
Com o uso do serviço de hospedagem 210, é fácil e conveniente para os usuários experimentar demonstrações. Na realidade, tudo que o usuário é selecionar a demonstração através de uma interface de usuário (tal como uma descrita abaixo) e experimentar a demo. A demonstração irá carregar quase instantaneamente sobre um servidor 402 apropriado para a demons- Á tração, e irá operar justamente como qualquer outro jogo ou aplicativo. Se a f demonstração requerer um servidor de desempenho muito alto 402, ou um servidor de desempenho baixo 402, e independentemente do tipo de cliente » de lar ou escritório 415 o usuário está usando, a partir do ponto de vista do usuário, a demonstração irá somente funcionar. O divulgador do software da demonstração do jogo ou do aplicativo será capaz de controlar exatamente qual demonstração o usuário é permitido a experimentar e por quanto tempo e, obviamente, a demonstração pode incluir elementos de interface de usuá- rio que oferecem ao usuário uma oportunidade de obter acesso a uma ver- são completa do jogo ou aplicativo demonstrado.
F Uma vez que as demonstrações são propensas a serem ofereci- .
das abaixo do custo ou livre de impostos, alguns usuários podem tentar usar demonstrações repetidas (particularmente, demonstrações de jogo, que po- dem ser divertidas para jogar repetidamente). O serviço de hospedagem 210 pode empregar várias técnicas para limitar o uso de demonstração para um determinado usuário. A abordagem mais fácil consiste em estabelecer um ID de usuário para cada usuário e limitar o número de vezes que um determi- —nadolD de usuário é permitido a jogar uma demonstração. Um usuário, en- tretanto, pode definir múltiplos IDs de usuário, especialmente, se forem gra- tuitos. Uma técnica para abordar este problema é limitar o número de vezes
| que um determinado cliente 415 é permitido a jogar uma demonstração.
Se | o cliente for dispositivo autônomo, então, o dispositivo terá um número de Série, e o serviço de hospedagem 210 pode limitar o número de vezes que uma demonstração pode ser acessada por um cliente com aquele número | 5 desérie.
Se o cliente 415 estiver operando como software em um PC ou ou- f | tro dispositivo, então, um número de série pode ser atribuído pelo serviço de á hospedagem 210 e armazenado no PC e usado para limitar o uso de de- | monstração, mas tendo em vista que os PCs podem ser reprogramados pe- eee los usuários, e o número de série apagado ou alterado, uma outra opção é que o serviço de hospedagem 210 mantenha um registro do endereço de Controle de Acesso de Mídia (MAC) do adaptador de rede do PC (e/ou ou- tros identificadores específicos de máquina tais como números de série de discos rígidos, etc.) e limitar o uso de demonstração para isto.
Posto que os endereços MAC dos adaptadores de rede podem ser alterados, entretanto, estenãoé um método à prova de falha.
Uma outra abordagem consiste em . limitar o número de vezes em que uma demonstração pode ser reproduzida para um determinado endereço de IP.
Embora os endereços de IP possam ser periodicamente reatribuídos por provedores de cable modem e DSL, isto não acontece na prática muito frequentemente, e se puder ser determinado (por exemplo, através do contato com a ISP) que o IP está em um bloco de endereços de IP para acessos por DSL ou cable modem residenciais, então, um número pequeno de usos de demonstração pode tipicamente ser estabe- = lecido para um determinado lar.
Ademais, podem haver múltiplos dispositi- E vos em um lar por trás de um roteador NAT que compartilha o mesmo ende- reçodelP, mas tipicamente em uma instalação residencial, há um número limitado de tais dispositivos.
Se o endereço de [IP estiver em um bloco que serve empresas, então, um número maior de demonstrações pode ser esta- belecido para uma empresa.
Mas, no fim, uma combinação de todas as a- bordagens anteriormente mencionadas é a melhor maneira de limitar o nú- mero de demonstrações em PCs.
Embora possa não haver uma maneira à prova de falha para que um determinado usuário tecnicamente adepto possa ser limitado no número de demonstrações reproduzidas repetidamente, cri-
ando um grande número de barreiras para criar um empecilho suficiente de | | tal modo que não seja válido para a maioria dos usuários de PC usuários | À abusar do sistema de demonstração, e, em vez disso, eles irão usar as de- | monstrações da forma pretendida: para experimentar novos jogos e aplicati- 7 5 vos.
Benefícios para Escolas, Empresas e Outras Instituições | Benefícios significativos se acumulam particularmente para em- presas, escolas e outras instituições que utilizam o sistema mostrado na fi- E E gura 4a.
As empresas e escolas têm custos substanciais associados à insta- lação, manutenção e atualização de PCs, particularmente, quando vêm de PCs para operar aplicativos de alto desempenho, tal como Maya.
Conforme determinado anteriormente, os PCs são geralmente utilizados por somente Á uma fração de horas da semana, e, como no lar, o custo do PC com um de- 1 terminado nível de capacidade de desempenho é muito maior em um ambi- entede escritório ou escola que em um ambiente de centro de servidor. . No caso de empresas ou escolas maiores (por exemplo, grandes universidades), pode ser prático para os departamentos de TI de tais entida- À des definir centros do servidor e manter computadores que são remotamente acessados através conexões em LAN.
Existem inúmeras soluções para a- cesso remoto de computadores por uma LAN ou através de conexão de lar- gura de vídeo alta privada entre escritórios.
Por exemplo, com o Windows Terminal Server da Microsoft, ou através de aplicativos computacionais de be rede virtual como VNC, da RealVNC, Ltd., ou através de meios de cliente - pequenos da Sun Microsystems, os usuários podem obter acesso remoto —paraPCs ou servidores, com uma faixa de qualidade em tempo de resposta de gráficos e experiência de usuário.
Adicionalmente, tais centros de servi- dores autogerenciados são tipicamente dedicados para uma única empresa ou escola e como tal, são incapazes de levar vantagem da sobreposição de uso que é possível quando aplicativos distintos (por exemplo, aplicativos de entretenimento e negócios) utilizam os mesmos recursos computacionais em diferentes momentos da semana.
Então, muitas empresas e escolas perdem a escala, recursos ou perícia para configurar um centro de servidor propria-
| mente que tenha uma conexão de rede com velocidade de LAN para cada | usuário.
Na realidade, uma grande percentual de escolas e empresas tem as mesmas conexões de Internet (por exemplo, DSL, cable modems) que os lares. | 5 Ainda, tais organizações podem ter a necessidade de computa- L | ção de desempenho muito alto, em uma base regular ou em uma base peri- | ódica.
Por exemplo, uma pequena empresa de arquitetura pode ter somente i um número pequeno de arquitetos, com necessidades computacionais rela- E A tivamente modestas quando se faz trabalho de projeto, mas pode requerer . computação 3D com desempenho muito alto periodicamente (por exemplo, quando se cria uma apresentação flutuante em 3D de um novo projeto arqui- tetônico para um cliente). O sistema mostrado na figura 4a é extremamente bem adequado para tais organizações.
As organizações precisam de nada mais que o mesmo tipo de conexão de rede que é oferecido para lares (por exemplo, DSL, cable modems) e é tipicamente muito barato.
Eles podem . utilizar PCs baratos como o cliente 415 ou dispensar todos os PCs e utilizar dispositivos dedicados baratos que implantam simplesmente a lógica de si- À nal de controle 413 e descompressão de vídeo de baixa latência 412. Estes recursos são particularmente atrativos para escolas que podem ter proble- mas com furto de PCs ou dano aos componentes delicados no interior dos PCs.
Tal disposição resolve inúmeros problemas para tais organiza- = ções (e muitas destas vantagens também são compartilhadas por usuários - domésticos de computação para fins gerais). Primeiramente, o custo opera- cional (que definitivamente precisa ser superado de alguma forma pelos u- suários a fim de ter um negócio viável) pode ser muito menor, devido ao fato de que (a) os recursos computacionais são compartilhados com outros apli- cativos que têm diferentes tempos de uso pico durante a semana, (b) as or- ganizações podem obter acesso a (e incorrer o custo de) recursos computa- cionais de alto desempenho somente quando necessário, (c) as organiza- ções não precisam ter que fornecer recursos para cópia de segurança ou, de outro modo, manutenção de recursos computacionais de alto desempenho.
| Eliminação de Pirataria | Além disso, jogos, aplicativos, filmes interativos, etc., não podem | ser mais pirateados como hoje em dia.
Devido ao fato de que cada jogo é armazenado e executado no serviço de hospedagem 210, os usuários não | 5 —são dotados de acesso ao código de programa subjacente, então, não há [ | nada para piratear.
Mesmo se um usuário estiver copiando o código fonte, o Í usuário não seria capaz de executar o código em um console de jogo ou É computador domestico padrão.
Isto abre mercado em locais do mundo tal lasasaE. como China, onde o vídeo game padrão não é disponível.
A revenda de jo- gos usados também não é possível, pois não existem cópias de jogos distri- buídos para usuários.
Para desenvolvedores de jogos, existem menos descontinuida- des de mercado como é o caso hoje em dia quando novas gerações de con- ; soles de jogo ou PCs são introduzidas no mercado.
O serviço de hospeda- gem210 pode ser gradualmente atualizado com a tecnologia computacional x mais avançada ao longo do tempo como alteração de requisitos de jogo, em contraste à situação atual em que uma geração completamente nova de tec- À nologia de console ou PC força os usuários e os desenvolvedores a atualiza- rem e o desenvolvedor do jogo é dependente da distribuição periódica da plataforma de hardware para o usuário (por exemplo, no caso do PlayStation 3, sua introdução foi atrasada em mais de um ano, e os desenvolvedores tiveram que esperar até estivesse disponível e números significativos de u- = nidades foram compradas). - Transmissão de Vídeo Interativa As descrições acima fornecem uma ampla faixa de aplicativos viabilizados pelo conceito subjacente inovador de transmissão de baixa la- tência baseada em Internet geral de vídeo interativo (que implicitamente in- clui áudio junto com o vídeo, conforme usado no presente documento). Os sistemas da técnica anterior que forneceram transmissão de vídeo através dalnternettêm somente aplicativos viabilizados que podem ser implantados interações de alta latência.
Por exemplo, os controles de reprodução básicos para vídeo linear (por exemplo, pausa, retrocesso, avanço rápido) funcionam
| adequadamente com alta latência, e é possível selecionar dentre as alimen- | | tações de vídeo linear.
Ademais, conforme determinado anteriormente, a | natureza de alguns vídeo games os permite que sejam executados com alta | latência.
Porém, a alta latência (ou baixa razão de compressão) das aborda- " 5 gensda técnica anterior para transmissão de vídeo tem limitado gravemente os aplicativos potenciais de transmissão de vídeo ou estreitado suas dispo- | sições em ambientes de rede especializados e, mesmo em tais ambientes, i as técnicas anteriores introduzem sobrecargas substanciais nas redes.
À À E Eaaaa tecnologia descrita no presente documento abre a porta para a ampla faixa de aplicativos possíveis com transmissão de vídeo de baixa latência de vi- : deo interativo através da Internet, particularmente, aqueles viabilizados atra- vés de conexões de Internet de grau de consumidor. : Na realidade, com os dispositivos do cliente tão pequenos quan- á to o cliente 465 da figura 4c suficientes para fornecer uma experiência de usuário acentuada com uma quantidade arbitrária efetivamente de potência . computacional, quantidade arbitraria de armazenamento rápido e rede ex- tremamente rápida dentre servidores potentes, é viável uma nova era de À computação.
Adicionalmente, devido ao fato de que os requisitos de largura de vídeo não crescem conforme a potência computacional do sistema cresce (istoé, devido ao fato de os requisitos de largura de vídeo estarem somente atrelados à resolução, qualidade e taxa de quadro de exibição), uma vez que a conectividade de Internet de banda larga é onipresente (por exemplo, atra- = vés de cobertura sem fio de baixa latência expandida), confiável e de largura , de vídeo suficientemente alta para satisfazer as necessidades dos dispositi- vos de exibição 422 de todos os usuários, a questão será se os clientes grandes (tais como PCs ou telefone móvel que executam Windows, Linux, OSKX, etc.) ou ainda os clientes pequenos (tal como Adobe Flash ou Java) são necessários para aplicativos corporativos e de consumidor típicos.
O advento de vídeo interativo de fluxo contínuo resulta na refor- —mulação de suposições acerca da estrutura de arquiteturas da computação.
Um exemplo disso é a modalidade de centro de servidor de serviço de hos- pedagem 210 mostrada na figura 15. O caminho de vídeo para armazena-
| mento temporário de atraso e/ou vídeo de grupo 1550 é um laço de retorno | em que a saída de vídeo interativo de fluxo contínuo de multicast dos servi- dores de aplicativo/jogos 1521 a 1525 é fornecida como retorno nos servido- res de aplicativos/jogos 1521 a 1525 ou em tempo real através de um cami- Í 5 nho1552 ou após um atraso selecionável através do caminho 1551. Isso | permite uma ampla variedade de aplicações práticas (por exemplo, como aquelas ilustradas nas figuras 16, 17 e 20) quer seriam ou impossíveis ou : irrealizáveis pelo servidor ou arquiteturas computacionais da técnica anterior.
A Porém, como uma característica arquitetônica mais geral, o que o laço de ' retorno 1550 fornece é a recursão no nível de vídeo interativo de fluxo contí- nuo, já que o vídeo pode ser enlaçado novamente indefinidamente conforme o aplicativo solicita do mesmo.
Isso permite uma ampla variedade de possi- ]j bilidades de aplicação não disponíveis anteriormente.
Í Outra característica arquitetônica chave é que os fluxos de vídeo —sãofluxos de UDP unidirecionais.
Isso permite efetivamente um grau arbitrá- . rio de multicast de vídeo interativo de fluxo contínuo (em contraste, fluxos de duas vias, como fluxos TCP/IP, criariam cada vez mais obstruções de log de É tráfego nas redes a partir das comunicações de ida e volta, conforme o nú- mero de usuários aumentava). Multicasting é uma capacidade importante no centro de servidor porque permite que o sistema seja responsivo às neces- sidades crescentes dos usuários da Internet (e, de fato, da população mun- dial) de comunicar em uma base de um para muitos ou mesmo de muitos - para muitos.
Novamente, os exemplos discutidos aqui, como na figura 16, - que ilustra o uso de ambos a recursão de vídeo interativo de fluxo contínuo e omulticast, ilustram apenas a ponta de um grande iceberg de possibilidades.
Peering de Não Trânsito Em uma modalidade, o serviço de hospedagem 210 tem uma ou mais conexões de peering a um ou mais Provedores de Serviço de Internet (ISP) que também fornecem serviço de Internet a usuários, e, dessa forma, o serviço de hospedagem 210 também pode ser capaz de comunicar com o usuário através de uma rota de não-trânsito que fica na rede daquele ISP.
Por exemplo, se o serviço de hospedagem 210 Interface de WAN 441 co-
| nectado diretamente à rede de Comcast Cable Communications, Inc., e as | premissas de usuário 211 foram supridas com serviço de banda larga com ] um modem a cabo Comcast, uma rota entre o serviço de hospedagem 210 e | ) o cliente 415 pode ser estabelecida totalmente na rede de Comcast. As van- | 7 5 tagens potenciais disso seria incluir um custo mais baixo para as comunica- | ções (já que os custos de trânsito de IP entre duas ou mais redes ISP po- dem ser evitadas), uma conexão potencialmente mais confiável (no caso, havia congestão ou outras interrupções de trânsito entre redes ISP), e latên- í SSNNNESE cia inferior (no caso, havia congestão, rotas ineficientes ou outros atrasos entreredesdelSP). Nessa modalidade, quando o cliente 415 inicialmente entra em contato com o serviço de hospedagem 210 no início de uma sessão, o servi- À ço de hospedagem 210 recebe o endereço de IP das premissas de usuário Ê 211. Então, usa tabelas de endereço de IP disponíveis, por exemplo, a partir de ARIN (Registro Americano para Números da Internet), para verificar se o . endereço de IP é aquele alocado a um ISP particular conectado ao serviço E de hospedagem 210 que pode levar às premissas do usuário 211 sem o trânsito de IP até outro ISP. Por exemplo, se o endereço de IP estava entre
76.21.0.0 e 76.21.127.255, então o endereço de IP é designado à Comcast Cable Communications, Inc. Nesse exemplo, se o serviço de hospedagem 210 mantiver as conexões aos ISPs de Comcast, AT&T e Cox, então sele- ciona Comcast como o ISP mais provável a fornecer um caminho ótimo ao - usuário particular. 5 Compressão de Vídeo com o Uso de Retorno Em uma modalidade, o retorno é fornecido a partir do dispositivo de cliente para o serviço de hospedagem indicar ladrilho bem sucedido (ou malsucedido) e/ou entrega de quadro. As informações de retorno fornecidas a partir do cliente são, então, usadas para ajustar as operações de compres- são de vídeo no serviço de hospedagem. Por exemplo, as figuras 25a a b ilustram uma modalidade da in- venção na qual um canal de retorno 2501 é estabelecido entre o dispositivo do cliente 205 e o serviço de hospedagem 210. O canal de retorno 2501 é
| usado pelo dispositivo de cliente 205 para enviar reconhecimentos empaco- Í tados de ladrilhos/quadros recebidos com sucesso e/ou indicações de ladri- Í lhos/quadros recebidos sem sucesso.
Em uma modalidade, depois de receber com sucesso cada ladri- Í 5 lho/quadro, o cliente transmite uma mensagem de reconhecimento ao servi- | ço de hospedagem 210. Nessa modalidade, o serviço de hospedagem 210 | j detecta uma perda de pacote se não receber um reconhecimento após um período de tempo especificado e/ou se receber um reconhecimento de que o NASNAI dispositivo de cliente 205 recebeu um ladrilho/quadro subsequente ao invés do que foi enviado.
Alternativamente, ou adicionalmente, o dispositivo de cliente 205 pode detectar a perda de pacote e transmitir uma indicação de perda de pacote ao serviço de hospedagem 210 junto com uma indicação dos ladrilhos/quadros afetados pela perda de pacote.
Nessa modalidade, o É reconhecimento contínuo de ladrilhos/quadros entregues com sucesso não é exigido. . Independentemente da maneira como uma perda de pacotes é detectada, na modalidade ilustrada nas figuras 25a a 25b, após a geração É de um conjunto inicial de I-ladrilhos para uma imagem (não mostrada na fi- gura 25a), o encodificador gera subsequentemente apenas P-ladrilhos até que uma perda de pacotes seja detectada.
Observe que na figura 25a, cada quadro, como o 2510, é ilustrado na forma de 4 ladrilhos verticais.
O quadro pode ser ladrilhado em uma configuração diferente, como 2x2, 2x4, 4x4 etc., 7 ou o quadro pode ser totalmente encodificado sem ladrilhos (isto é, como 1 ta ladrilho grande). Os exemplos precedentes de configurações de ladrilhagem de quadro são fornecidos para o propósito de ilustração desta modalidade da invenção.
Os princípios fundamentais da invenção não são limitados a qualquer configuração de ladrilhagem de quadro particular.
A transmissão de apenas P-ladrilhos reduz os requisitos de lar- gura de banda do canal por todas as razões apresentadas acima (isto é, P- ladrilhos são geralmente menores que l-ladrilhos). Quando uma perda de pacotes é detectada por meio do canal de retorno 2501, novos l-ladrilhos são gerados pelo encodificador 2500, conforme ilustrado na figura 25b, para reinicializar o estado do decodificador 2502 no dispositivo do cliente 205. i Conforme ilustrado, em uma modalidade, os I-ladrilhos são distribuídos ao Il longo de múltiplos quadros encodificados para limitar a largura de banda consumida por cada quadro encodificado individual.
Por exemplo, na figura 25,em que cada quadro inclui 4 ladrilhos, um único I-ladrilho é transmitido | : em uma posição diferente dentro de 4 quadros encodificados sucessivos. | O encodificador 2500 pode combinar as técnicas descritas em | relação a esta modalidade com outras técnicas de encodificação descritas na presente invenção.
Por exemplo, além de gerar |-ladrilhos em resposta a : uma perda de pacotes detectada, o encodificador 2500 pode gerar |-ladrilhos em outras circunstâncias em que os lI-ladrilhos podem ser benéficos para reproduzir de maneira apropriada a sequência de imagens (como em res- ] posta a transições de cena repentinas). É A figura 26a ilustra outra modalidade da invenção que se baseia em um canal de retorno 2601 entre o dispositivo do cliente 205 e o serviço . de hospedagem 210. Em vez de gerar novos l-ladrilhos/quadros em resposta a uma perda de pacotes detectada, o encodificador 2600 desta modalidade ' ajusta as dependências dos P-ladrilhos/quadros.
Como um assunto inicial, deve ser observado que os detalhes específicos apresentados neste exem- —plonão são necessários para o cumprimento dos princípios fundamentais da invenção.
Por exemplo, embora este exemplo seja descrito com o uso de P- ladrilhos/quadros, os princípios fundamentais da invenção não são limitados 7 a nenhum formato de encodificação particular.
F Na figura 26a, o encodificador 2600 encodifica uma pluralidade de ladrilhos/quadros descomprimidos 2605 em uma pluralidade de P-ladrilhos/quadros 2606 e transmite os P-ladrilhos/quadros por meio de um canal de comunicação (por exemplo, a Internet) para um dispositivo do clien- te 205. Um decodificador 2602 no dispositivo do cliente 205 decodifica os P-ladrilhos/quadros 2606 para gerar uma pluralidade de ladrilhos/quadros —descomprimidos 2607. O(s) estado(s) anterior(es) 2611 do encodificador 2600 é/são armazenado(s) em um dispositivo de memória 2610 no serviço de hospedagem 210 e o(s) estado(s) anterior(es) 2621 do decodificador
| 2602 é/são armazenado(s) em um dispositivo de memória 2620 no dispositi- vo do cliente 205. O "estado" de um decodificador é um termo bem conhe- cido na técnica de sistemas de codificação de vídeo, como MPEG-2 e MPEG.
Em uma modalidade, o(s) "estado(s)" anterior(es) armazenado(s) —nasmemórias compreende(m) os dados combinados de P-ladrilhos/quadros : anteriores.
As memórias 2611 e 2621 podem ser integradas no encodifica- | i dor 2600 e no decodificador 2602, respectivamente, em vez de serem sepa- ! radas do encodificador 2600 e do decodificador 2602, conforme mostrado na SSSNNa figura 26a.
Além disso, vários tipos de memórias podem ser usados, inclu- indo, atítulo de exemplo e não de limitação, memória de acesso aleatório.
Em uma modalidade, quando não ocorre perda de pacotes, o encodificador 2600 encodifica cada P-ladrilho/quadro para que seja depen- À dente do P-ladrilho/quadro anterior.
Dessa maneira, conforme indicado pela i notação usada na figura 26a, o P-ladrilho/quadro 4 é dependente do P-Hadrilho/quadro 3 (identificado com o uso da notação 43); o P-ladri- . lIho/quadro 5 é dependente do P-ladrilho/quadro 4 (identificado com o uso da notação 54); e o P-ladrilho/quadro 6 é dependente do P-ladrilho/quadro 5 À (identificado com o uso da notação 65). Neste exemplo, o P-ladrilho/quadro 43 foi perdido durante a transmissão entre o encodificador 2600 e o decodifi- —cador 2602. A perda pode ser comunicada ao encodificador 2600 de várias maneiras, incluindo, sem limitação, aquelas descritas acima.
Por exemplo, cada vez que o decodificador 2606 recebe e/ou decodifica com êxito um la- - drilho/quadro, essas informações podem ser comunicadas pelo decodifica- 7 dor 2602 ao encodificador 2600. Se o encodificador 2600 não receber uma indicação de que um ladrilho/quadro particular foi recebido e/ou decodificado após um período de tempo, o encodificador 2600 irá admitir que o ladri- lho/quadro não foi recebido com êxito.
Alternativamente, ou além disso, o decodificador 2602 pode notificar o encodificador 2600 quando um ladri- lho/quadro particular não for recebido com êxito.
Em uma modalidade, independente de como o ladrilho/quadro perdido for detectado, uma vez que este o é, o encodificador 2600 encodificada o próximo ladrilho/quadro que usa o último ladrilho/quadro
| conhecido como tendo sido recebido com sucesso pelo decodificador 2602. | No exemplo mostrado na figura 26a, os ladrilhos/quadros 5 e 6 não são considerados como tendo sido "recebidos com sucesso" porque estes não podem ser apropriadamente decodificados pelo decodificador 2602 devido a perda de ladrilho/quadro 4 (isto é, a decodificação de ladrilho/quadro 5 | | depende do ladrilho/quadro 4 e a decodificação de ladrilho/quadro 6 | ! depende do ladrilho/quadro 5). Portanto, no exemplo mostrado na figura | 26a, o encodificador 2600 encodifica o ladrilho/quadro 7 para ser ; aaaaa dependente do ladrilho/quadro 3 (o último ladrilho/quadro recebido com À sucesso) ao invés de ladrilho/quadro 6 que o decodificador 2602 não pode ser decodificar apropriadamente.
Embora não ilustrado na figura 26a, o ladrilho/quadro 8 irá ser subsequentemente encodificado para ser É dependente do ladrilho/quadro 7 e o ladrilho/quadro 9 irá ser encodificado ; para ser dependente do ladrilho/quadro 8, assumindo que nenhuma perda adicional de pacote seja detectada. . Conforme mencionado acima, tanto o encodificador 2600 quanto o decodificador 2602 mantém os estados passados de encodificador e decodificador, 2611 e 2621, dentro de memórias 2610 e 2620, respectivamente.
Portanto, quando encodificando o ladrilho/quadro 7, o encodificador 2600 recupera o estado anterior do encodificador associado com o ladrilho/quadro 3 da memória 2610. De maneira similar, a memória 2620 associada com decodificador 2602 armazena pelo menos o último 7 conhecido estado bom de decodificador (o estado associado com P- - telha/quadro 3 no exemplo). Consequentemente, o decodificador 2602 recupera a informação de estado passado associada com o ladrilho/quadro 3 de modo que o ladrilho/quadro 7 possa ser decodificado.
Como um resultado das técnicas descritas acima, o vídeo interativo, de baixa latência e em tempo real pode ser encodificado e transmitido usando uma largura de banda relativamente pequena porque — nenhum ladrilho/quadro é requerido (exceto para inicializar o decodificador e o encodificador no início da transmissão). Ademais, enquanto a imagem de vídeo produzida pelo decodificador pode incluir temporariamente distorções
! não desejadas que resultam do ladrilho/quadro perdido 4 e os | | ladrilhos/quadros 5 e 6 (que não podem ser apropriadamente decodificados devido a perda de ladrilho/quadro 4), essa distorção será visível por uma 1 duração muita curta.
Ademais, se os ladrilhos forem usados (ao invés de ! 7 5 — quadros de vídeo completo), a distorção irá ser limitada a uma região em Í particular da imagem de vídeo renderizada.
Um método de acordo com uma modalidade da invenção é ilustrado na figura 26b.
Em 2650, um ladrilho/quadro é gerado com base em .. um ladrilho/quadro gerado previamente.
Em 2651, um ladrilho/quadro . perdido é detectado.
Em uma modalidade, o ladrilho/quadro perdido é detectado com base na informação comunicada do encodificador para o decodificador, como descrito acima.
Em 2652, o próximo ladrilho/quadro é Á gerado com base em um ladrilho/quadro que é conhecido como tendo sido É recebido com sucesso e/ou decodificado no decodificador.
Em uma modalidade, o encodificador gera o próximo ladrilho/quadro carregando o . estado associado com o ladrilho/quadro da memória recebido com sucesso : e/ou decodificado.
De maneira similar, quando o decodificador recebe o novo ladrilho/quadro, este decodifica o ladrilho/quadro carregando o estado associado com o ladrilho/quadro da memória recebido com sucesso e/ou decodificado.
Em uma modalidade o próximo ladrilho/quadro é gerado com base no último ladrilho/quadro recebido com sucesso e/ou decodificado no - encodificador.
Em outra modalidade, o próximo ladrilho/quadro gerado é um ba |-ladrilho/quadro.
Em ainda outra modalidade, a escolha de quando gerar o próximo ladrilho/quadro com base em um ladrilho/quadro previamente recebido com sucesso ou como um | quadro é com base em quantos ladrilhos/quadros foram perdidos e/ou a latência do canal.
Em uma situação em que um número relativamente pequeno (por exemplo, 1 ou 2) de ladrilhos/quadros são perdidos e a latência de ida e volta é relativamente — baixa (por exemplo 1 ou 2 quadro por vez), então este pode ser ótima para gerar um P-ladrilho/(quadro desde que a diferença entre o último ladrilho/quadro recebido com sucesso e o gerado recentemente pode ser
! relativamente pequeno. Se diversos ladrilhos/quadros forem perdidos ou a | latência de ida e volta for alta, então está pode ser ótima para gerar um |- | ladrilho/quadro desde que a diferença entre o último ladrilho/quadro recebido 7 com sucesso e o gerado recentemente pode ser grande. Em uma 7 5 —modalidade, um limite de perda ladrilho/quadro e/ou um valor de limite de ] latência é ajustado para determinar se deve transmitir um I-ladrilho/quadro ou um P-ladrilho/quadro. Se o número de ladritlhos/quadros perdidos for abaixo do limite de perda de ladrilho/quadro e/ou se a latência de ida e volta for abaixo da do valor limite de latência, então um novo |-ladrilho/quadro é “gerado; de outra forma, um novo P-ladrilho/quadro é gerado.
Em uma modalidade, o encodificador sempre tenta gerar um P- ladrilho/quadro relativo ao último ladrilho/quadro recebido com SUCESSO, e se no processo de encodificação o encodificador determinar que o P- á ladrilho/quadro irá ser provavelmente maior que um |Hadrilho/quadro (por exemplo se este comprimiu 1/8 do ladrilho/quadro e o tamanho comprimido . for maior que 1/8 do tamanho do |ladrilho/quadro médio comprimido anteriormente), então o encodificador abandonará a compressão do P- Í ladrilho/quadro e irá comprimir um I-ladrilho/quadro.
Se os pacotes perdidos ocorrem raramente, os sistemas descrita acima com o uso de retroalimentação para relatar uma ladrilho/quadro solto resulta tipicamente em uma perturbação muito ligeira no fluxo de vídeo para o usuário devido ao fato de que um ladrilho/quadro que foi perturbado por y um pacote perdido é substituído aproximadamente no tempo de um ciclo r entre o dispositivo do cliente 205 e o serviço de hospedagem 210 presumin- doque o codificador 2600 compreende o ladrilho/quadro em um curto perío- do de tempo. E, devido ao fato de que o novo ladrilho/quadro, que é com- primido, é baseado m um último quadro no fluxo de vídeo descomprimido, o fluxo de vídeo não fica para trás do fluxo de vídeo não comprimido. Porém, sem um pacote que contém o novo ladrilho/quadro também for perdido, en- tãoistoresulta em um atraso de pelo menos dois ciclos para solicitar e envi- ar novamente outro novo ladrilho/quadro, que, em situações práticas, resul- tará em perturbação notável para o fluxo de vídeo. Como consequência, é
| muito importante que o ladrilho/quadro recém-codificado enviado após o la- ! drilho/quadro ignorado ser enviado com sucesso do serviço de hospedagem Í 210 para o dispositivo do cliente 205.
] Em uma modalidade, técnicas de codificação de correção de er- 7 5 ros de repasse (FEC), como aquelas descritas anteriormente e ilustradas Í nas figuras 11a, 11b, 11c e 11d, são usadas para mitigar a probabilidade de i perda do ladrilho/quadro recém-codificado. Se a codificação de FEC já esti- ver sendo usada na transmissão de ladrilhos/quadros, então um código de E FEC mais forte é usado para o ladrilho/quadro recém-codificado.
Uma causa potencial de pacotes ignorados é uma perda repen- tina na largura de banda de canal, por exemplo, se algum ouro usuário da conexão de banda larga nas premissas de usuário 211 inicia com o uso de À uma grande quantidade de largura de banda. Se um ladrilho/quadro recém- É gerado também for perdido devidos aos pacotes ignorados (mesmo se for usado FEC), então, em uma modalidade quando o serviço de hospedagem . 210 for notificado pelo cliente 415 que um segundo ladrilho/quadro recente- mente codificado foi ignorado, o compressor de vídeo 404 reduz a taxa de dados quando codifica um ladrilho/quadro recém-codificado subsequente. Diferentes modalidades reduzem a taxa de dados com o uso de diferentes técnicas. Por exemplos, em uma modalidade, esta redução da taxa de da- dos é realizada ao baixar a qualidade do ladrilho/quadro codificado através do aumento da razão de compressão. Em outra modalidade, a taxa de da- - dos é reduzida ao baixar a taxa de quadro do vídeo (por exemplo, de 60fps r para 30fps) e, consequentemente, baixar a taxa de transmissão de dados.
Em uma modalidade, ambas as técnicas para reduzir a taxa de dados são usadas (por exemplo, reduzindo a taxa de quadro e aumentando a razão de compressão). Se essa taxa inferior de transmissão de dados obter sucesso na mitigação dos pacotes ignorados, então, de acordo com a detecção da taxa de dados de canal e métodos de ajuste anteriormente descrita, o servi- çode hospedagem 210 continuará a codificar a uma taxa de dados menor e, então, ajustar gradualmente a taxa de dados par cima ou para baixo confor- me o canal permitir. A recepção contínua de dados de retroalimentação re-
| lacionados aos pacotes ignorados e/ou à latência permite que o serviço de | hospedagem 210 ajuste dinamicamente a taxa de dados baseado nas con- dições atuais do canal.
Gerenciamento de Estado em um Sistema de Jogo Online Uma modalidade da invenção emprega técnicas para armazenar i | de forma eficaz e portar o estado atual de um jogo ativo entre servidores. | Embora as modalidades descritas no presente documento estejam relacio- nadas ao jogo online, os princípios subjacentes da invenção podem ser usa- dos para vários outros tipos de aplicações (por exemplo, aplicativos de mo- delo, processadores de palavras, software de comunicação como correio eletrônico ou mensagem instantânea etc). A figura 27a ilustra uma arquite- tura de sistema exemplificador para a implantação desta modalidade e a fi- Ã gura 27b ilustra um método exemplificador.
Embora o método e a arquitetu- ' ra de sistema sejam descritos concorrentemente, o método ilustrado na figu- ra27bnão se limita a nenhuma arquitetura de sistema particular. - Em 2751 da figura 27b, um usuário inicia um novo jogo online game em um serviço de hospedagem 210a de um dispositivo do cliente 205. À Em resposta, em 2752, uma imagem "limpa" do jogo 2702a é carregada do armazenamento (por exemplo, um disco rígido, ou conectado diretamente a um servidor que executa o jogo, ou conectado a um servidor através de uma rede) à memória (por exemplo, RAM) no serviço de hospedagem 210a.
A imagem "limpa" compreende o código de programa de tempo de execução e = dados para o jogo antes da iniciação de qualquer jogo (por exemplo, como ba quando o jogo é executado pela primeira vez). O usuário joga então o jogo em72753, fazendo com que a imagem "limpa" mude para uma imagem não- limpa (por exemplo, um jogo em execução representado por "Estado A" na figura 27a). Em 2754, o jogo é interrompido ou finalizado, ou pelo usuário ou pelo serviço de hospedagem 210a.
Em 2755, a lógica de gerenciamento de estado 2700a no serviço de hospedagem 210a determina as diferenças entre aimagem "limpa" do jogo e o estado de jogo atual ("Estado A"). Várias técnicas conhecidas podem ser usadas para calcular a diferença entre duas imagens binárias incluindo, por exemplo, aquelas usadas no serviço "diff'
| conhecido disponível no sistema operacional Unix.
Certamente, os princí- | pios subjacentes da invenção não se limitam a nenhuma técnica particular para o cálculo da diferença. 1 Independente de como as diferenças são calculadas, uma vez 7 5 queasmesmas tenham sido feitas, os dados diferenciais são armazenados localmente dentro de um dispositivo de armazenamento 2705a e/ou transmi- | tidos para um serviço de hospedeiro diferente 210b.
Se transmitidos para um serviço de hospedeiro diferente 210b, os dados diferenciais podem ser ar- mazenados em um dispositivo de armazenamento (não mostrado) no novo iss. 10 — serviço de hospedeiro 210b.
Em ambos os casos, os dados diferenciais são associados com a conta do usuário no serviço de hospedeiros de modo que os mesmos possam ser identificados na próxima vez em que o usuário reali- ó za o login no serviço de hospedeiros e inicia o jogo.
Em uma modalidade, ao É invés de serem transmitidos imediatamente, os dados diferenciais não são transmitidos para um novo serviço de hospedeiro até a próxima vez em que . o usuário tenta jogar o jogo (e um serviço de hospedeiro diferente é identifi- cado como a melhor escolha para hospedar o jogo). Retornando ao método mostrado na figura 27b, em 2757, o u- suário reinicia o jogo a partir de um dispositivo cliente, que pode ser o mes- mo dispositivo cliente 205 a partir do qual o usuário inicialmente jogou o jogo ou um dispositivo cliente diferente (não mostrado). Em resposta, em 2758, lógica de gerenciamento de estado 2700b no serviço de hospedeiro 210b Y recupera a imagem "limpa" do jogo a partir de um dispositivo de armazena- à mento e dos dados diferenciais.
Em 2759, a lógica de gerenciamento de es- —tado2700b combina a imagem limpa e dados de diferença para reconstruir o estado em que o jogo estava no serviço de hospedeiro original 210a ("Esta- do A"). Diversas técnicas conhecidas podem ser usadas para recriar o esta- do de uma imagem binária usando os dados diferenciais incluindo, por e- xemplo, aqueles usados do bem conhecido função "remendo" disponível no sistema operacional Unix.
As técnicas de cálculo de diferenças usadas em programas de cópia de segurança bem conhecidos como PC Backup tam- bém podem ser usados.
Os princípios fundamentais da invenção não se limi-
| tam a qualquer técnica em particular ao usar dados de diferença para recriar | a imagem binária. Além disso, em 2760, dados dependentes de plataforma 2710 são incorporados na imagem de jogo final 2701b. Os dados dependentes de — plataforma 2710 podem incluir quaisquer dados que sejam exclusivos para a | plataforma do servidor de destino. A título de exemplo, e não de limitação, os dados dependentes de plataforma 2710 podem incluir o endereço de Contro- le de Acesso ao Meio (MAC) da nova plataforma, o endereço TCP/IP, a hora do dia, números seriais de hardware (por exemplo, para o disco rígido e “O CPU), endereços de servidor de rede (por exemplo, servidores DHCP/Wins), e número(s) serial(is) /código(s) de ativação de software (incluindo núme- ro(s) serial(is)/código(s) de ativação do Sistema Operacional). À Outros dados dependentes de plataforma relacionados ao clien- ] te/usuário podem incluir (mas não se limitam a) os seguintes:
1. A resolução de tela do usuário. Quando o usuário retoma o . jogo, o usuário pode estar usando um dispositivo diferente com uma resolu- ção diferente. ' 2. A configuração de controle do usuário. Quando o jogo é reto- mado, o usuário pode ter trocado de um controle de jogo para um tecla- — do/mouse.
3. Direitos do usuário, como se uma taxa de desconto expirou (por exemplo, se o usuário estava jogando o jogo durante um período pro- . mocional e está agora jogando durante um período normal com custos mais o altos) ou se o usuário ou dispositivo tem algumas restrições de idade (por exemplo, os pais do usuário podem ter mudado as configurações para uma criança, de modo que a criança não seja permitida a ver material adulto, ou se o dispositivo onde o jogo é jogado (por exemplo, um computador em uma biblioteca pública) tem certas restrições sobre se o material adulto pode ser exibido).
4. A classificação do usuário. O usuário pode ter sido permitido a jogar um jogo de múltiplos jogadores em uma certa liga, mas devido ao fato de alguns outros usuários terem excedido a classificação do usuário, o usuá-
| rio pode ter sido rebaixado para uma liga inferior.
Os exemplos precedentes de dados dependentes de plataforma 2710 são fornecidos para fins de ilustração desta modalidade da invenção.
Os princípios fundamentais da invenção não se limitam a qualquer conjunto — particular de dados dependentes de plataforma.
| A figura 28 ilustra graficamente como a lógica de gerenciamento de estado 2700a no primeiro serviço de hospedeiro extrai dados de diferen- j ça 2800 a partir do jogo sendo executado 2701a. A lógica de gerenciamento de estado 2700b no segundo serviço de hospedeiro então combina a ima- fee 10 gem limpa 2702b com os dados diferenciais 2800 e dados dependentes de plataforma 2710 para regenerar o estado do jogo sendo executado 2701b.
Conforme mostrado em geral na figura 28, o tamanho dos dados diferenci- E ais é significativamente menor do que o tamanho de toda a imagem do jogo Ê 2701a e, consequentemente, uma quantidade significativa de espaço de ar- —mazenamento e a largura de banda é conservada através do armazenamen- . to/transmissão de somente dados de diferença. Embora não mostrado na figura 28, os dados dependentes de plataforma 2700 podem sobrescrever  alguns dos dados diferenciais quando os mesmos são incorporados na ima- gem de jogo final 2701b.
Embora uma implementação de videogame online seja descrita acima, os princípios fundamentais da invenção não se limitam a videoga- mes. Por exemplo, as técnicas de gerenciamento de estado precedentes " podem ser implementadas dentro do contexto de qualquer tipo de aplicativo õ hospedado online.
TécnicasPara Manter um Decodificador de Cliente Em uma modalidade da invenção, o serviço de hospedeiro 210 transmite um novo decodificador para o dispositivo de cliente 205 cada vez que o usuário solicita uma conexão com o serviço de hospedeiro 210. Con- sequentemente, nessa modalidade, o decodificador usado pelo dispositivo declienteé sempre atualizado e unicamente adaptado ao hardware/software implantado no dispositivo de cliente.
Conforme ilustrado na figura 29, nessa modalidade, o aplicativo
| que é permanentemente instalado no dispositivo de cliente 205 não inclui um | decodificador.
Especialmente, esse é um aplicativo de transferência por | transferência por download de cliente 2903 que gerencia a transferência por L download e instalação de um decodificador temporário 2900 cada vez que o | | 5 dispositivo de cliente 205 se conecta ao serviço de hospedeiro 210. O aplica- E | tivo de transferência por download 2903 pode ser implantado em hardware, ! software, firmware ou em qualquer combinação dos mesmos.
Em resposta a ' uma solicitação do usuário para uma nova sessão online, o aplicativo de eita transferência por download 2903 transmite informações relacionadas ao dis- positivo de cliente 205 sobre uma rede (por exemplo, a Internet). As informa- | ções podem incluir dados de identificação que identificam o dispositivo de cliente e/ou a configuração de hardware/software do dispositivo de cliente f (por exemplo, processador, sistema de operação, etc). É Com base nessas informações, um aplicativo de transferência por download 2901 no serviço de hospedeiro 210 seleciona um decodifica- . dor temporário apropriado 2900 para ser usado no dispositivo de cliente 205. O aplicativo de transferência por download 2901 no serviço de hospedeiro, À então, transmite o decodificador temporário 2900 e o aplicativo de transfe- rência por download 2903 no dispositivo de cliente, verifica e/ou instala o decodificador no dispositivo de cliente 205. O encodificador 2902, então, en- codifica o conteúdo de áudio/vídeo usando qualquer uma das técnicas des- critas no presente documento e transmite o conteúdo 2910 para o decodifi- - cador 2900. Uma vez que o novo decodificador 2900 é instalado, esse deco- - difica o conteúdo para a sessão online atual (isto é, usando uma ou mais das técnicas de descompressão de áudio/vídeo descritas no presente documen- to). Em uma modalidade, quando a sessão é finalizada, o decodificador 2900 é removido (por exemplo, desinstalado) do dispositivo de cliente 205. ; Em uma modalidade, o aplicativo de transferência por download 2903 caracteriza o canal como o decodificador temporário 2900 que está sendo transferido por download, realizando avaliações do canal como a taxa de dados executável no canal (por exemplo, determinando quanto tempo leva para que dados sejam transferidos por download), a taxa de perda do pacote no canal e a latência do canal.
O aplicativo de transferência por | download 2903 gera dados de caracterização do canal que descrevem as | avaliações do canal.
Esses dados de caracterização do canal são, então, | | transmitidos do dispositivo de cliente 205 para o aplicativo de transferência r —pordownload 2901 do serviço, que usa os dados de caracterização do canal r para determinar como utilizar o canal da melhor forma para transmitir meios | para o dispositivo de cliente 205. | É O dispositivo de cliente 205 tipicamente enviará de volta mensa- E gens ao serviço de hospedeiro 205 durante a transferência por download do decodificador temporário 2900. Essas mensagens podem incluir mensagens . de reconhecimento que indicam se os pacotes foram recebidos com ou sem erros.
Em adição, as mensagens fornecem retorno para O aplicativo de É transferência por download 2901 como para a taxa de dados (calculada com Á base na taxa nas quais pacotes são recebidos), a taxa de erros do pacote (com base na porcentagem de pacotes relatados recebidos com erros) e a : latência de ida e volta do canal (com base na quantidade de tempo que leva antes de o aplicativo de transferência por download 2901 receber retorno f sobre um dado pacote que foi transmitido). A titulo de exemplo, se a taxa de dados for determinada como sendo de 2 Mbps, então, o aplicativo de transferência por download pode escolher uma resolução de janela de vídeo menor para o encodificador 2902 (por exemplo, 640x480 a 60 fps) do que se a taxa de dados fosse de- n terminada como sendo de 5 Mbps (por exemplo, 1.280x720 a 60 fps). Dife- HF rentes correções antecipadas de erro (FEC) ou de estruturas de pacote po- dem ser escolhidas, dependendo da taxa de perda do pacote.
Se a perda de pacote for muito baixa, então, o áudio e vídeo comprimidos podem se transmitidos sem qualquer correção de erro.
Se a ; perda de pacote for mediana, então, o áudio e vídeo comprimidos podem ser transmitidos com técnicas que codificam correções de erro (por exemplo, como aquelas previamente descritas e ilustradas nas figuras 11a, 11b, 11ce 11d). Se a perda de pacote for muito alta, pode ser determinado que um flu- xo audiovisual de qualidade adequada não pode ser transmitido e o disposi-
tivo de cliente 205 ou pode notificar ao usuário que o serviço de hospedeiro | | não esta disponível através do canal de comunicação (isto é, "link”), ou pode | tentar estabelecer uma rota diferente para o serviço de hospedeiro que tem uma perda de pacote inferior (conforme descrito abaixo). Se a latência for baixa, então, o áudio e vídeo comprimidos po- Í ! dem ser transmitidos com abaixa latência e uma sessão pode ser estabele- | cida.
Se a latência for muito alta (por exemplo, maior do que 80 ms) então, para jogos que necessitam de baixa latência, o dispositivo de cliente 205 EE pode notificar ao usuário que o serviço de hospedeiro não está disponível através do link, que um link esta disponível, mas o tempo de resposta para a . entrada de usuário será lento ou "atrasado," ou que o usuário pode tentar estabelecer uma rota de diferença para o serviço de hospedeiro que tem uma latência inferior (conforme descrito abaixo). O Dispositivo de cliente 205 pode tentar ser conectado ao Servi- çodo hospedeiro 210 através de outra rota através da rede (por exemplo, a : Internet) para ver se defeitos são reduzidos (por exemplo, a perda de pacote é menor, a latência é menor, ou mesmo se a taxa de dados for maior). Por À exemplo, o serviço do hospedeiro 210 pode ser conectado à Internet de múl- tiplos locais geograficamente (por exemplo, um centro hospedeiro em Los —Angelese um em Denver), e talvez haja uma grande perda de pacote devido à congestão em Los Angeles, mas não há congestão em Denver.
Além dis- so, o serviço do hospedeiro 210 pode se conectar à Internet através de múl- - tiplos provedores de serviço de internet (por exemplo, AT&T e Comcast). h Por causa da congestão ou outros problemas entre o dispositivo de cliente205 e um dos provedores de serviço (por exemplo, AT&T), perda de pacote e/ou alta latência e/ou taxa de dados constrita podem resultar.
Entretanto, se o dispositivo de cliente 205 se conecta ao serviço do hospe- : deiro 210 através de outro provedor de serviço (por exemplo, Comcast), po- de ser capaz de conectar sem problemas de congestão e/ou baixa perda de pacote e/ou baixa latência e/ou taxa de dados mais alta.
Deste modo, se o dispositivo de cliente 205 experimentar uma perda de pacote acima de um limite especificado (por exemplo, um número específico de pacotes ignora-
| dos através de uma duração especificada), latência acima de um limite es- ] peciíficado e/ou uma taxa de dados abaixo de um limite especificado enquan- | | to acontece o download do decodificador temporário 2900, em uma modali- | dade, este tenta reconectar ao serviço do hospedeiro 210 através de uma | 1 5 rota alternativa (tipicamente através de conectar a um endereço IP diferente E : ou um nome de domínio diferente) para determinar se uma conexão melhor ] pode ser obtida. ! Se a conexão ainda estiver experimentando defeitos inaceitáveis NESNSNNSSNAR após as opções de conexões alternativas serem esgotadas, pode ser porque aconexão local de dispositivo de cliente 205 à Internet está sofrendo falhas, : ou porque fica muito longe do serviço do hospedeiro 210 para alcançar uma latência adequada.
Em tal caso o dispositivo de cliente 205 pode notificar o & usuário que o serviço do hospedeiro não está disponível através do link ou que é apenas disponível com defeitos, e/ou apenas certos tipos de jo- —gos/aplicações baixa-latência são disponíveis. ” Já que esta avaliação e melhora potencial das características de link entre o serviço do hospedeiro 210 e o dispositivo de cliente 205 ocorre : enquanto o decodificador temporário está sendo transferido por download, este reduz a quantidade de tempo que o dispositivo de cliente 205 precisaria para gastar separadamente transferindo por download o decodificador tem- porário 2900 e avaliando as características de link.
Apesar disto, em outra modalidade, a avaliação e melhora potencial das características de link são hai desempenhadas pelo dispositivo de cliente 205 separadamente da transfe- rência por download do decodificador temporário 2900 (por exemplo, através do uso de dados de teste fictício em vez do código de programa de decodifi- cador). Há inúmeras razões porque esta pode ser uma implantação prefe- rencial.
Por exemplo, em algumas modalidades, o dispositivo de cliente 205 é implantado parcial ou inteiramente no hardware.
Deste modo, para estas modalidades, não há um decodificador de software para este necessário pa- raodownload.. Compressão Que usa Tamanhos de Ladrilhos Baseados em Padrões Como mencionado acima, quando uma compressão baseada em ladrilho é usada, os princípios de base da invenção não são limitados a | nenhuma orientação, formato ou tamanho de ladrilho particular.
Por exem- | plo, em um sistema de compressão baseado em DCT como MPEG-2 e MPEG, os ladrilhos pode ter o tamanho de macroblocos (componentes —usadosem compressão de vídeo que representa tipicamente um bloco de 16 por 16 pixels). Esta modalidade fornece um nível muito bom de granulosi- | dade para trabalhar com azulejos.
Além disso, independente do tamanho do ladrilho, diversos tipos de padrões de padrões de ladrilho podem ser usados.
Por exemplo, a figura 30ilustra uma modalidade em que múltiplos I-ladrilhos são usados em cada . quadro R 3001-3004. Um padrão de rotação é usado em que as |-telhas são dispersadas através de cada quadro R, de modo que um quadro inteiro | é É gerado a cada quatro quadros R.
A dispersão de |- ladrilhos desta maneira irá reduzir os efeitos de uma perda de pacote (limitando a perda de uma pe- — quena região de exibição). . Os ladrilhos podem também ser conformados em uma estrutura nativa integral do algoritmo de compressão de base.
Por exemplo, se o al- É goritmo de compressão H.264 for usado, em uma modalidade, os ladrilhos são determinados para serem do tamanho de "fatias" H.264. Isto permite que as técnicas descritas no presente documento sejam facilmente integra- das no contexto de diversos algoritmos de compressão de padrões diferen- tes como H.264 e MPEG-4. Uma vez que o tamanho do ladrilho é determi- mm nado a uma estrutura de compressão nativa, as mesmas técnicas como a- queles descritas acima podem ser implantadas.
Técnicas Para Retrocesso de Fluxo e Operações de Reprodução Como anteriormente descrito em conexão com a figura 15,0 fluxo de vídeo/áudio não comprimido1529 gerado por um servidor de aplica- tivo/jogo 1521-1525 pode ser comprimido por compressão compartilhada de hardware 1530 em múltiplas resoluções resultando simultaneamente em múltiplos fluxos de vídeo/áudio comprimidos 1539. Por exemplo, um fluxo de vídeo/áudio gerado por servidor de aplicativo/jogo 1521 pode ser comprimido em 1280x720x60fps pela compressão compartilhada de hardware 1530 e transmitido para um usuário por roteamento de saída 1540 como tráfego de ] Internet de saída 1599. Este mesmo fluxo de vídeo/áudio pode ser simulta-
neamente subescalonado ao tamanho de miniatura (por exemplo, 200x113)
| pela compressão compartilhada de hardware 1530 via caminho 1552 (ou r através do buffer de atraso 1515) ao servidor de aplicativo/jogo 1522 para -
ser exibido como uma miniatura 1600 de uma coleção de miniaturas na figu- | ra 16. Quando a miniatura 1600 é ampliada através de tamanho intermediá- ' rio 1700 na figura 17 ao tamanho 1800 (1280x720x60fps) na figura 18, en- tão em vez de descomprimir o fluxo de miniatura, servidor de aplicativo/jogo faabãao 10 1522 pode descomprimir uma cópia do fluxo de 1280x720x60fps sendo en- : viado ao usuário de servidor de aplicativo/jogo 1521, e escalonar o vídeo de maior resolução à medida que é ampliado a partir de tamanho de miniatura f para o tamanho1280x720. Esta abordagem apresenta a vantagem de reutili- zar o fluxo comprimido 1280x720 duas vezes.
Mas há várias desvantagens: (a) ofluxode vídeo comprimido enviado ao usuário pode variar em qualida- de de imagem se o rendimento de dados da conexão de Internet do usuário varia resultando em uma qualidade imagem variante vista pelo usuário "es- É pectador" de servidor de aplicativo/jogo 1522, mesmo se tal conexão de In- ternet do usuário não variar, (b) servidor de aplicativo/jogo 1522 terá que usar recursos de processamento para descomprimir toda a imagem 1280x720 e então escalonar tal imagem (e da mesma forma aplicar um filtro de reamostragem) para exibir tamanhos muito menores (por exemplo, - 640x360) durante a ampliação, (c) se quadros são ignorado devido à largura de banda limitada de conexão de Internet e/ou pacotes perdi —dos/corrompidos, e o usuário espectador "retrocede" e "pausa" o vídeo gra- vado no buffer de atraso 1515, o usuário espectador descobrirá que os qua- dros ignorados estão faltando no buffer de atraso (isto será particularmente aparente se o usuário "avançar" quadro a quadro), e (d) se o usuário espec- ; tador retrocede para encontrar um quadro particular no vídeo gravado no buffer de atraso, então o servidor de aplicativo/jogo 1522 terá que encontrar um | quadro ou | ladrilhos antes do quadro procurado no fluxo de vídeo gra- vado no buffer de atraso, e então descomprimir todos os P quadros/ladrilhos
| até que o quadro desejado seja alcançado.
Estas mesmas limitações não Í seriam aplicáveis para usuários "espectadores" do fluxo de vídeo/áudio ao vivo, mas usuários (incluindo o usuário que gerou o fluxo de vídeo/áudio) | assistindo a uma cópia arquivada (por exemplo, "Brag Clip") do fluxo de ví- | 5 —deo/áudio. i Uma modalidade alternativa da invenção aborda estes proble- | : mas ao comprimir o fluxo de vídeo em mais de um tamanho e/ou estrutura. | Um fluxo (o fluxo "Ao Vivo") é comprimido da melhor forma para fluir até o " —— usuário final, como descrito aqui, baseado nas características da conexão de rede (por exemplo, largura de banda de dados, confiabilidade de pacote) e : as capacidades do cliente local do usuário (por exemplo, capacidade de descompressão, resolução de exibição). Outros fluxos (referidos aqui as flu- Â xos "HQ") são comprimidos em alta qualidade, em uma ou mais resoluções, e em uma estrutura receptiva à reprodução de vídeo, e tais fluxos HQ são roteados e armazenados dentro do centro servidor 210. Por exemplo, em . uma modalidade, os fluxos HQ comprimidos são armazenados em um arran- jo de disco RAID 1515 e são utilizados para fornecer funções como pausar, | retroceder, e outras funções de reprodução (por exemplo, "Brag Clips" que podem ser distribuídos para outros usuários para visualização). Como ilustrado na figura 31a, uma modalidade da invenção compreende um encodificador 3100 capaz de comprimir um fluxo de vídeo em pelo menos dois formatos: um que periodicamente inclui I-Ladrilhos ou 1- ii Quadros 3110 e um que não inclui |-Ladrilhos ou I-Quadros 3111, a menos F que seja necessário devido um distúrbio do fluxo ou porque um I-Ladrilho ou —l-Quadro é determinado para ser menor do que um I-Ladrilho ou |-Quadro (como descrito acima). Por exemplo, o fluxo "Ao Vivo" 3111 transmitido ao usuário enquanto joga um videogame pode ser comprimido ao utilizar ape- nas P-Quadros (a menos que I-Ladrilhos ou |-Quadros sejam necessários ou menores como descrito acima). Em adição, o encodificador 3100 desta mo- —dalidade comprime ao mesmo tempo fluxo de vídeo Ao Vivo 3111 em um segundo formato que, em uma modalidade, inclui periodicamente I-Ladrilhos ou I-Quadros (ou tipo similar de formato de imagem).
Enquanto as modalidades descritas acima empregam |- | Ladrilhos, I-Quadros, P-Ladrilhos e P-Quadros, os princípios subjacentes da ] invenção não estão limitados a qualquer algoritmo de compressão em parti- | ! cular.
Por exemplo, qualquer tipo de formato de imagem no qual quadros Tr | 5 —são dependentes de quadros anteriores ou subsequentes pode ser utilizado Ç no lugar de P-Ladrilhos ou P-Quadros.
De forma similar, qualquer tipo de | ! formato de imagem que não é dependente de quadros anteriores ou subse- ! quentes pode ser substituído em favor dos I-Ladrilhos ou I|-Quadros descritos ER acima. õ Conforme mencionado acima, o Fluxo HQ 3110 inclui |-Quadros À periódicos (por exemplo, em uma modalidade, a cada 12 quadros aproxima- damente). !sto é significante devido ao fato de que se o usuário quiser rebo- á binar rapidamente o fluxo de vídeo armazenado para um ponto particular, Ladrilhos ou I-Quadros são necessários.
Com um fluxo comprimido de so- mente P-Quadro (isto é, sem o primeiro quadro da sequência sendo um - fr Quadro), seria necessário que o decodificador voltasse ao primeiro quadro da sequência (que pode estar a horas de distância) e descomprime P- À quadros até o ponto ao qual o usuário quer rebobinar.
Com um I|-Quadro a cada 12 quadros armazenados no Fluxo HQ 3110, o usuário pode decidir rebobinar até um ponto particular spot e o |-Quadro precedente mais próxi- mo do fluxo HQ não está a mais que 12 quadros antes do quadro desejado.
Mesmo se a taxa de decodificação máxima do decodificador for em tempo mr real (por exemplo, 1/60 de um segundo para um fluxo de 60 quadro/seg), : então 12 (quadros)/60 (quadros/seg) = 1/5 segundo afastado de um |- Quadro.
E, em muitos casos, os decodificadores podem operar muito mais rápido que em tempo real, por exemplo, em 2x o tempo real, um decodifica- dor poderia decodificar 12 quadros em 6 quadros, que é apenas 1/10 de um segundo atraso para um "rebobinar". Não é necessário dizer que mesmo um decodificador rápido (por exemplo, 10x o tempo real) poderia ter um atraso — inaceitável se o |-Quadro precedente mais próximo fosse um número grande de quadros anteriores a um ponto de rebobinagem (por exemplo, poderia tomar 1 hora/10=6 minutos para realizar a "rebobinagem"). Em outra modali-
| dade, I-Ladrilhos periódicos são usados, e neste caso quando o usuário pro- | | cura rebobinar o decodificador encontrará o I-Ladrilho precedente mais pró- ximo antes do ponto de rebobinagem, e então começar a decodificação da- quele ladrilho a partir daquele ponto até que todos os ladrilhos sejam decodi- | 5 —ficados até o ponto de rebobinagem.
Embora I-Ladrilhos ou 1-Quadros perió- [ Í dicos resultem em compressão de menos eficiência que eliminar |-Quadros | completamente, o serviço hospedeiro 210 tipicamente tem largura de banda localmente disponível mais que suficiente e capacidade de armazenamento no para gerenciar o fluxo HQ.
Em outra modalidade, o decodificador 3100 encodifica o fluxo . HQ com I-Ladrilho ou |-Quadros periódicos, seguidos pelos P-Ladrilhos ou P-Quadro, conforme previamente descrito, mas também precedidos pelos B- Í Ladrilhos ou B-Quadros.
Os B-Quadros, conforme descritos previamente, são quadros que precedem um I|-Quadro e são baseados em diferenças de — quadro do |-Quadro que trabalha para trás no tempo.
Os B-Ladrilhos são a - contraparte do ladrilho, que precede um I-Ladrilho e com base em diferenças de quadro que trabalha para trás a partir do I-Ladrilho.
Nesta modalidade, se o ponto de rebobinagem desejado for um B-Quadro (ou contiver B- Ladrilhos), então o decodificador encontrará o I|-Quadro ou I-Ladrilho seguin- temais próximo e decodificará para trás no tempo até o ponto de rebobina- gem desejado ser decodificado, e então como a reprodução de vídeo pros- segue a partir daquele pondo para frente, o decodificador decodificará B- Fr Quadros, I-Quadros e P-Quadro (ou suas contrapartes de ladrilho) em qua- : dros sucessivos que vão para frente.
Uma vantagem de empregar B- Quadros ou B-Ladrilhos em adição a tipos | e P é que, normalmente uma qualidade mais alta em uma dada razão de compressão pode ser atingida.
Já em outra modalidade, o encodificador 3100 encodifica o fluxo HQ como todos os I-Quadros.
Uma vantagem desta abordagem é que o 1 ponto de rebobinagem é um |-Quadro, e como resultado, nenhum outro qua- — dro precisa ser decodificado a fim de alcançar o ponto de rebobinagem.
Uma desvantagem é a taxa de dados comprimidos será muito alta comparada a encodificação de fluxo |, P ou |, P, B.
Outras ações de reprodução de fluxo de vídeo (por exemplo, re- | bobinagem rápida ou lenta, avanço rápido ou lento, etc.), tipicamente são muito mais praticamente realizadas com |-Quadros ou I-Ladrilhos periódicos | (sozinhos ou combinados com contrapartes P e/ou B), já que em cada caso ] ofluxoé reproduzido em um diferente quadro à fim de avançar quadro por Fr quadro no tempo, e como resultado, o decodificador precisa encontrar e de- | codificar um quadro particular, frequentemente arbitrário, na sequência.
Por É exemplo, no caso de avanço muito rápido (por exemplo, velocidade de == 100x), cada quadro sucessivo exibido é de 100 quadros após o quadro ante- rior Mesmo com um decodificador que roda a 10x o tempo real e decodifica À 10 quadros em tempo de 1 quadro, ainda seria 10x mais lendo para atingir avanço rápido de 100x.
Entretanto, com l|-Quadros ou I-Ladrilhos periódicos E conforme descritos acima, o decodificador é capaz de procurar o |-Quadro ou I-Ladrilhos aplicáveis mais próximos ao quadro que precisa ser exibido em seguida e semente decodifica os quadros ou ladrilhos interveniente ao * ponto do quadro alvo.
Em outra modalidade as |-Quadros são codificadas no fluxo HQ É em uma periodicidade consistente (por exemplo, sempre a cada 8 quadros) e os multiplicadores de velocidade colocados à disposição do usuário para o avanço rápido e retrocesso que são mais rápidos que a taxa de |-Quadro são múltiplos exatos da periodicidade de I|-Quadro.
Por exemplo, se a perio- dicidade de I-Quadro é 8 quadros, então as velocidades de avanço rápido e r retrocesso disponibilizadas ao usuário podem ser 1X, 2X, 3X, 4X, 8X, 16X, 64X e 128X e 256X.
Para as velocidades mais rápidas que a periodicidade —del-Quadro, o decodificador irá pular para frente até I|-Quadro mais próximo que é número de quadros à frente na velocidade (por exemplo, se o quadro exibido atualmente for 3 quadros antes de um |-Quadro, então em 128K, O decodificador irá pular para um quadro 128+3 quadros à frente) e, então, para cada quadro sucessivo o decodificador irá pular o número exato de — quadros conforme a velocidade escolhida (por exemplo, na velocidade esco- lhida de 128X, o decodificador pularia 128 quadros) que estabeleceria exa- tamente em um |-Quadro cada vez.
Dessa forma, dado que todas as veloci-
dades mais rápidas que a periodicidade de |-Quadro são múltiplos exatos da | periodicidade de |-Quadro, o decodificador nuca precisará decodificar quais- | 1 quer quadros precedentes ou seguintes para buscar o quadro desejado e L | terá somente que decodificar um 1|-Quadro por quadro exibido.
Para as velo- | | 5 — cidadesmais lentas que a periodicidade de I|-Quadro (por exemplo, 1X, 2X, E i 3X, 4X), ou para velocidades mais rápidas que não são múltiplas da periodi- | cidade de I-Quadro, para cada quadro exibido, o decodificador busca sejam | quais forem os quadros, exigem pelo menos quadros recentemente decodifi- ! e cados adicionais para exibir o quadro desejado, seja um |-Quadro não deco- í dificado ou um quadro já decodificado ainda disponível na forma decodifica- da (em RAM ou outro armazenamento rápido) e então, decodificam quadros intervenientes, conforme necessário, até o quadro desejador ser decodifica- : do e exibido.
Por exemplo, em 4X avanço rápido, em uma sequência codifi- cada 1,P com 8X periodicidade de I-Quadro, se o quadro atual for um P- quadro que é 1 quadro que segue um |-quadro, estão o quadro desejado a T ser exibido está 4 quadros adiante, que seria o 5º P-Quadro que segue o |- quadro precedente.
Se o quadro exibido atualmente (que acabara de ser É decodificado) for usado como um ponto de partida, o decodificador precisará decodificar mais 4 P-quadros para exibir o quadro desejado.
Se o |-Quadro precedente for usado, o decodificador precisará decodificar 6 quadros (o |- Quadro e os 5 P-Quadros seguintes) a fim de exibir o quadro desejado. (Ca- ramente, neste caso, é vantajoso usar o quadro exibido atualmente para mi- = nimizar os quadros adicionais a decodificar). Então, o próximo quadro a ser decodificado, 4 quadros a frente, seria o 1º Quadro que segue um |-Quadro.
Neste caso, se o quadro decodificado atualmente foi usado como um ponto de partida, o decodificador precisaria decodificar mais 4 quadros (2 P- Quadros, um I|-Quadro e um P-Quadro). Mas, se o próximo |-Quadro foi usa- do no lugar, o decodificador precisaria somente decodificar o |I-Quadro e o P- Quadro seguinte. (Claramente, neste caso, é vantajoso usar o próximo |- — quadro como um ponto de partida para minimizar os quadros adicionais a decodificar). Dessa forma, neste exemplo, o decodificador alternaria entre usar o quadro decodificado atualmente como um ponto de partida e usar um
I-Quadro subsequente como um ponto de partida.
Como um princípio geral, | | independente do modo de reprodução de fluxo de vídeo HQ (avanço rápido, | retrocesso ou etapa) e velocidade, o decodificador começaria com qualquer | quadro, seja um |-Quadro ou um quadro decodificado anteriormente, exige | 5 pelomenos o número de quadros decodificados recentemente para exibir o L ! quadro desejado para cada quadro sucessivo exibido para esse modo de | reprodução e velocidade.
Conforme ilustrado na figura 31b, uma modalidade do serviço iara de hospedeiro 210 inclui a lógica de repetição de fluxo 3112 para administrar requerimentos do usuário para repetir o fluxo HQ 3110. A lógica de repetição g de fluxo 3112 recebe os requerimentos do cliente que contêm comandos de reprodução de vídeo (por exemplo, pausa, retrocesso, reprodução de um Í ponto especificado, etc), interpreta os comandos e decodifica o fluxo HQ 3110 do ponto especificado (ou começando com ou um |-Quadro ou um quadro decodificado anteriormente, conforme apropriado e, então, proce- - dendo para frente ou para trás ao ponto especificado). Em uma modalidade, um fluxo HQ decodificado é fornecido para um encodificador 3100 (potenci- À almente o encodificador próprio 3100, se capaz de codificar mais que um fluxo ao mesmo tempo ou um encodificador separado 3100) de modo que possa ser recomprimido (usando as técnicas descritas na presente inven- ção) e transmitido ao dispositivo de cliente 205. O decodificador 3102 no dispositivo de cliente, então, decodifica e passa o fluxo conforme descrito = acima. h Em uma modalidade, a lógica de repetição de fluxo 3112 não —decodificao fluxo HQ e, então, faz com que o encodificador 3100 recodifique o fluxo.
Particularmente, ele simplesmente transmite o fluxo HQ 3110 dire- tamente para o dispositivo de cliente 205 a partir do ponto especificado.
O decodificador 3102 no dispositivo de cliente 205, então, decodifica o fluxo HQ.
Como as funções de reprodução descritas na presente invenção não têm tipicamente os mesmos requerimentos de baixa latência que reproduzir um videogame em tempo real (por exemplo, se o jogador está simplesmente revendo o jogo anterior e não jogando ativamente), a latência adicionada
| tipicamente inerente no fluxo HQ usualmente de qualidade mais alta pode | resultar em uma experiência de usuário final aceitável (por exemplo, com latência mais alta, mas vídeo de qualidade mais alta). | A título de exemplo, e não limitação, se o usuário está jogando :; 5 videogame, o encodificador 3100 está fornecendo um fluxo Ao vivo de es- [ | sencialmente todos os P-quadros otimizados para a conxão do usuário e | | cliente local (por exemplo, aproximadamente 1,4 Mbps em uma resolução de 1 640 x 360). Ao mesmo tempo, o encodificador 3100 também comprime o . = fluxo de vídeo como um fluxo HQ 3110 dentro do serviço de hospedeiro 310 e armazena o fluxo HQ em um arranjo de Decodificador de Vídeo Digital (RAID) local em, por exemplo, 1280 x 720 a 10 Mbps com I-quadros cada 12 quadros.
Se o usuário aperta um botão "Pause", o jogo então será pausado : no último quadro decodificado do cliente e a tela congelará.
Depois, se o usuário aperta um botão "Rewind", a lógica de repetição de fluxo 3112 irá ler ofluxo HQ 3110 a partir do RAID do DVR a começar do |-quadro mais pró- : ximo ou quadro já decodificado disponível, como descrito acima.
A lógica de repetição de fluxo 3112 descomprimirá os quadros P ou B que intervêm, co- É mo necessário, sequenciar novamente os quadros como necessário de for- ma que a sequência de reprodução é inverso na velocidade de rebobinar desejada, e então redimensiona (com o uso de técnicas de escalonamento de imagem da técnica anterior bem conhecidas na técnica) o decodificado desejado que deveria ser exibido de 1280 x 720 a 640 x 360, e o encodifica- ms dor de fluxo Ao vivo 3100 comprimirão novamente o fluxo sequenciado no- vamente na resolução 640 x360 e transmitir o mesmo ao usuário.
Se o usuá- rio pausar novamente, e depois etapas individuais através do vídeo para as- sistir uma sequência de perto, o fluxo HQ 3110 sobre o RAID do DVR terá cada quadro disponível para realizar etapas individuais (ainda que o fluxo Ao vivo original possa ter quadros ignorados por qualquer uma dentre as muitas razões descritas no presente documento). Além disso, a qualidade da repro- dução do vídeo será bem alta em cada ponto no fluxo HQ, enquanto que podem existir pontos no fluxo Ao vivo onde, por exemplo, a largura de banda foi comprometida, o que resulta em uma redução temporária na qualidade da imagem comprimida. Embora a qualidade da imagem comprometida por um | breve período de tempo, ou em uma imagem em movimento, possa ser acei- tável para o usuário, se o usuário para em um quadro em particular (ou len- | tamente em etapas individuais) e estuda os quadros de perto, a qualidade Í 5 comprometida pode não ser aceitável. É também fornecida ao usuário a ha- | bilidade de avanço rápido, ou pular para um ponto em particular, mediante especificação de um ponto dentro do fluxo HQ (por exemplo, 2 minutos an- | tes). Todas estas operações seriam impraticáveis em sua generalidade ple- EE na e em alta qualidade com um fluxo de vídeo Ao vivo que foi P-quadro- somente ou raramente (ou imprevisivelmente) teve |-Quadros. À Em uma modalidade, é fornecido ao usuário uma janela de vídeo (não mostrada) tal como uma janela de vídeo Apple QuickTime ou Adobe É Flash com um "purificador" (ou seja, um controle deslizante esquerda-direita) que permite que o usuário faça uma varredura para frente e para trás atra- —vésdo fluxo de vídeo, até onde o fluxo HQ armazenou o vídeo. Embora pa- . reça ao usuário como se ele ou ela estivesse "purificando" através do fluxo Ao vivo, na realidade, ele ou ela purifica o fluxo armazenado HQ 3110,0 É qual é depois redimensionado e recomprimido como um fluxo Ao vivo. Em adição, como mencionado previamente, se o fluxo HQ por qualquer outra pessoa ao mesmo tempo, ou pelo usuário em um momento diferente, pode ser assistido uma resolução maior (ou menor) do que a resolução do fluxo Ao vivo enquanto o fluxo HQ encodificado simultaneamente, e a qualidade FE tão alta quanto a qualidade do fluxo Ao vivo do espectador, potencialmente Y até a qualidade do fluxo HQ.
Assim, mediante a encodificação simultânea tanto do fluxo Ao vivo (como descrito no presente documento de uma maneira apropriada por suas exigências de baixa latência, largura de banda e tolerância a erros de ! pacote) e um fluxo HQ com suas exigências de alta qualidade, ação de re- Í produção de fluxo, é fornecido, desse modo, ao usuário uma configuração — desejada para ambos os cenários. E, na realidade, é efetivamente transpa- rente ao usuário que existem dois fluxos diferentes encodificados de modo diferente. Da perspectiva do usuário, a experiência é altamente responsiva
| com baixa latência, apesar de executar sobre uma conexão de Internet com | | uma largura de banda relativamente baixa e altamente variável, apesar de a | 1 funcionalidade do Gravador de Vídeo Digital (DVR) é qualidade muito alta, L
Í | com ações flexíveis e velocidades flexíveis.
Como um resultado das técnicas descritas acima, o usuário re- L | cebe os benefícios tanto de fluxo de vídeo Ao vivo e HQ durante jogo online | ou outra interação online, sem sofrer de nenhuma das limitações ou de um i fluxo Ao vivo ou de um fluxo HQ. EE A figura 31c ilustra uma modalidade de uma arquitetura de sis- tema para realizar as operações acima. Como ilustrado, nesta modalidade, o encodificador 3100 encodifica uma série de fluxos "Ao vivo" 3121L, 3122L, e 3125L e uma série correspondente de fluxos "HQ" 3121H1-H3, 3122H1-H3, E e 3125H1-H3, respectivamente. Cada fluxo HQ H1 é encodificado em reso- lução completa, enquanto cada encodificador H2, e H3 escalona ao fluxo de vídeo para um tamanho menor antes da encodificação. Por exemplo, se o - fluxo de vídeo fosse de resolução 1280x720, H1 encodificaria em resolução 1280x720, enquanto H2 poderia escalonar a 640x360 e encodificar naquela É resolução e H3 poderia escalonar a 320x180 e encodificar naquela resolu- ção. Qualquer número de escalonador/encodificadores Hn simultâneos po- deriam ser utilizados, que fornecem encodificações de HQ simultâneas múl- tiplas em uma variedade de resoluções. Cada um dos fluxos de vídeo Ao vivo opera em resposta a sinais = de retorno de canais 3161, 3162 e 3165 recebidos através de uma conexão ' de internet de entrada 3101, conforme descrito acima (consultar, por exem- plo, a discussão dos sinais de retorno 2501 e 2601 nas figuras 25 e 26). Os fluxos de vídeo Ao vivo são transmitidos pela Internet (ou outra rede) através de uma lógica de roteamento de saída 3140. Os compressores ao vivo 3121L a 3125L incluem lógica para adaptar os fluxos de vídeo comprimidos i (incluindo quadros escalonados, ignorados etc.) com base em retorno de canal.
Os fluxos de HQ são roteados por lógica de roteamento de en- trada 3141 e 1502 para armazenamentos temporários de atraso interno (por exemplo, série RAID 3115) ou outros dispositivos de armazenamento de da- ] dos através do caminho de sinal 3151 e/ou são fornecidos como retorno a- | | través do caminho de sinal 3152 em servidores de aplicativo/jogo e no codi- Í ficador 3100 para processamento adicional.
Conforme descrito acima, os | 5 fluxosde HQ 3121Hn a 3125Hn são transmitidos para usuários finais por j solicitação (consultar, por exemplo, s figura 31b e o texto associado). | Em uma modalidade, o encodificador 3100 é implantado com a ! lógica de compressão compartilhada de hardware 1530, mostrado na figura : En 15. Em outra modalidade, algum ou todos os encodificadores e escalonado- res são subsistemas individuais.
Os princípios subjacentes da invenção não : estão limitados a qualquer compartilhamento particular de recursos de esca- lonamento ou compressão e/ou configuração de hardware/software. : Uma vantagem da configuração da figura 31c é que os Servido- res de Aplicativo/Jogo 3121 a 3125 que exigem janelas de vídeo de tamanho completo menores não precisarão processar e descomprimir uma janela de . tamanho completo.
Além disso, os Servidores de Aplicativo/Jogo 3121 a 3125 que exigem tamanhos de janelas intermediários podem receber um É fluxo comprimido que é próximo do tamanho de janela desejado e, então, escalonar para cima ou para baixo para o tamanho de janela desejado.
Além disso, se múltiplos Servidores de Aplicativo/Jogo 3121 a 3125 solicitarem o mesmo tamanho de fluxo de vídeo a partir de outro Servidor de Aplicati- vol/Jogo 3121 a 3125, o Roteador de Entrada 3141 pode implantar técnicas a! de multicast de IP, como as conhecidas na técnica, e difundir o fluxo solicita- do para múltiplos Servidores de Aplicativo/Jogo 3121 a 3125 de uma vez, sem solicitar um fluxo independente para cada Servidor de Aplicativo/Jogo que faça uma solicitação.
Se algum servidor de Aplicativo/Jogo que recebe uma difusão alterar o tamanho de uma janela de vídeo, ele pode comutar : para a difusão de um tamanho de vídeo diferente.
Assim, um número arbitra- riamente grande de usuários pode assistir a um fluxo de vídeo de Servidor de Aplicativo/Jogo, cada um com a flexibilidade de escalonar suas janelas de vídeo e sempre ter o benefício de um fluxo de vídeo escalonado próximo do tamanho de janela desejada.
| Uma desvantagem com a abordagem mostrada na figura 31c é | | que em muitas implantações práticas do Serviço de Hospedeiro 210, nunca | | há um momento em que todos os fluxos de HQ comprimidos, muito menos todos os tamanhos de todos os fluxos de HQ comprimidos, são assistidos de uma vez Quando o encodificador 3100 é implantado como um recurso com- ! partilhado (por exemplo, um escalonador/compressor, cada um implantado | em software ou hardware), este desperdício é mitigado. Mas podem haver | questões práticas em conectar um grande número de fluxos descomprimidos : Oo para um recurso compartilhado comum, devido à largura de banda envolvi- da Por exemplo, cada fluxo 1080p60 é quase 3 Gbps, que é muito além até õ mesmo de Gigabit Ethernet. As modalidades alternativas a seguir confron- tam esta questão.
Ê A figura 31d mostra uma modalidade alternativa do Serviço de Hospedeiro 210 em que cada Servidor de Aplicativo/Jogo 3121 a 3125 tem dois compressores alocados para ele: (1) um compressor de fluxo Ao vivo s 3121L a 3125L, que adapta o fluxo de vídeo comprimido com base no Re- torno de Canal 3161 a 3165, e (2) um compressor de fluxo de HQ que envia um fluxo de HQ de resolução completa, conforme descrito acima. Notavel- mente, o compressor Ao vivo é dinâmico e adaptável, utilizando comunica- ções de duas vias com o cliente 205, enquanto o fluxo de HQ é não adaptá- vel e de uma via. Outra diferença entre o fluxo é que a qualidade do fluxo Ao vivo pode variar drasticamente, dependendo das condições do canal e da a! natureza do material de vídeo. Alguns quadros podem ser de baixa qualida- F de, e podem haver quadros ignorados. Além disso, o fluxo Ao vivo pode ser — quase inteiramente de P-quadros ou P-ladrilhos, com I|-quadros ou I-ladrilhos aparecendo com pouca frequência. O fluxo de HQ tipicamente será uma ta- xa de dados muito maior do que o Fluxo Ao vivo, e fornecerá alta qualidade ij consistente, sem ignorar qualquer quadro.O fluxo de HQ pode ser todo de |-quadros, ou pode ter |-quadros ou l-ladrilhos frequentes elou regulares.
—OfluxodeHQ pode também incluir B-quadros ou B-ladrilhos.
Em uma modalidade, o escalonamento e a recompressão de ví- deo Compartilhado 3142 (detalhado abaixo) seleciona apenas determinados
Í fluxos de vídeo de HQ 3121H1 a 3125H1 para serem escalonados e recom- | primidos em uma ou mais resoluções diferentes, antes de enviar para o Ro- | teamento de Entrada 3141 para rotear conforme descrito anteriormente.
Ca- 1 da um dos outros fluxos de vídeo de HQ são atravessados em seu tamanho r | 5 completo parao Roteamento de Entrada 3141 para rotear, conforme descrito r I anteriormente, ou não são atravessados de qualquer modo.
Em uma moda- | | lidade, a decisão em que fluxos de HQ são escalonados e recomprimidos 1 e/ou em que fluxos de HQ são atravessados de qualquer modo é determina- Í da com base em se há um Servidor de Aplicativo/Jogo 3121 a 3125 que está solicitando fluxo de HQ particular na resolução particular (ou uma resolução À próximo da resolução escalonada ou completa). Através deste meio, os úni- cos fluxos de HQ que são escalonados e recomprimidos (ou potencialmente atravessados de qualquer modo) são fluxos de HQ que são realmente ne- cessários.
Em muitas aplicações do Servidor de Hospedeiro 210, isto resulta em uma redução drástica de recursos de escalonamento e compressão.
A- - lém disso, dado que todo fluxo de HQ é ao menos comprimido em sua reso- lução completa pelos compressores 3121H1 a 3125H1, a largura de banda ; necessária para ser roteado para e dentro de escalonamento e recompres- são de vídeo Compartilhado 3142 é reduzida drasticamente como se fosse aceito vídeo descomprimido.
Por exemplo, um fluxo 1080p60 descomprimido de 3GBps poderia ser comprimido para 10Mbps e ainda retém qualidade muito alta.
Assim, com conectividade Gigabit Ethernet, em vez de ser inca- mr paz de portar até mesmo um fluxo de vídeo de 3Gbps descomprimido, seria possível portar dezenas de fluxos de vídeo de 10Mbps, com redução pouco aparente de qualidade. figura 31f mostra detalhes do escalonamento e recompressão do Vídeo compartilhado 3142, junto com um grande número de compresso- res de vídeo de HQ, HQ 3121H1-3131H1. O roteamento interno 3192 atra- vés de solicitações por fluxos de vídeo particulares escalonados para tama- —nhos particulares dos servidores de Aplicativo/Jogo 3121-3125 seleciona geralmente um subconjunto de fluxos de HQ comprimidos por compressores de vídeo de HQ, HQ 3121H1-3131H1. Um fluxo dentro desse subconjunto j selecionado de fluxos é roteado tanto através de um Descompressor 3161- | 3164 se o fluxo solicitado for escalonado, ou roteado no Caminho de vídeo não escalonado 3196 se o fluxo solicitado estiver em resolução completa. Os fluxos a serem escalonados são descomprimidos a vídeos descomprimidos ] 5 pelos Descompressores 3161-3164, depois, cada um é escalonado ao ta- [ | manho solicitado pelos Escalonadores 3171-3174, depois, cada vídeo com- | primido pelos Compressores 3181-3184. Observe que se um fluxo de HQ particular é solicitado em mais de uma resolução, depois o Roteamento In- EL terno 3192 faz o multicast do fluxo (usando a tecnologia de multicasting de IP que é bastante conhecida pelos versados na técnica) para um ou mais Descompressores 3161-3164 e (se um tamanho solicitado se completa reso- lução) ao Roteamento de Saída 3193. Todos os fluxos solicitados, tanto es- E calonados (a partir dos Compressores 3181-3184) ou não (a partir do Rote- amento Interno 3192), são então enviados ao Roteamento de Saída 3193. O Roteamento 3193 então envia cada fluxo solicitado ao servidor de Aplica- - tivo/Jogo 3121-3125 que fez a solicitação. Em uma modalidade, se mais de um servidor de Aplicativo/Jogo solicitar o mesmo fluxo na mesma resolução, É então o Roteamento Externo 3193 faz o multicast do fluxo para todos os ser- vidores de Aplicativo/Jogo 3121-3125 que estão fazendo a solicitação. Na modalidade preferencial presente do escalonamento e com- pressão de Vídeo compartilhado 3142, o roteamento é implantado pelo uso de comutadores Gigabit Ethernet, e a descompressão, escalonamento, e a! compressão é implantada por dispositivos semicondutores especializados . distintos que implantam cada função. A mesma funcionalidade poderia ser implantada com um maior nível de integração no hardware ou por processa- dores muito rápidos. figura 31e mostra outra modalidade de Serviço de Hospedeiro 210, em que a função de Armazenamento temporário de atraso 3115, descri- to previamente, é implantada em um armazenamento temporário de atraso de Vídeo compartilhado, subsistema de escalonamento e descompressão
3143. Os detalhes do subsistema 3143 são mostrados na figura 31g. A ope- ração do subsistema 3143 é similar a do subsistema 3142 mostrada na figu-
| ra 31f, exceto que 3191 seleciona primeiro quais fluxos de vídeo de HQ se- | rão roteados, através de solicitações dos servidores de Aplicativos/Jogos 3121-3125, e depois, os fluxos de HQ que são solicitados a serem atrasados são roteados através do Armazenamento temporário de atraso 3194, implan- —tadocomo arranjo de RAID na modalidade preferencial presente (mas pode- | ria ser implantada em qualquer meio de armazenamento de largura de ban- | da e capacidade), e fluxos que não são solicitados para serem atrasados | são roteados através do Caminho de vídeo não atrasado 3195. A saída do = Armazenamento temporário de atraso 3194 e Vídeo não atrasado 3195 são ' 16 então roteadas pelo Roteamento Interno 3192 com base no fato de fluxos solicitados serem escalonados ou não.
Fluxos escalonados são roteados através dos Descompressores 3161-3164, Escalonadores 3171-3174 e : Compressores 3181-3184 ao Roteamento de saída 3193, e o Vídeo não es- calonado 3196 é também enviado ao Roteamento de saída 3193, e depois o Roteamento de saída 3193 envia o vídeo em modo unicast ou multicast aos - servidores de Aplicativo/Jogo da mesma maneira que descrito anteriormente no subsistema 3142 da figura 31f.
E Outra modalidade de armazenamento temporário de vídeo, sub- sistema de escalonamento e descompressão é mostrado na figura 31h.
Nessa modalidade um Armazenamento temporário de atraso individual de HQ 3121D-HQ 3131D é fornecido para cada fluxo de HQ.
Por causa do rápi- do declínio de custo de RAM e Flash ROM, os quais podem ser usados para r atrasar um fluxo de vídeo comprimido, isso pode acabar sendo menos dis- : pendioso e/ou mais flexível de que ter um Armazenamento Temporário de atraso 3194. Ou, em ainda outra modalidade, um único Armazenamento temporário de atraso 3197 (mostrado em linha pontilhada) pode fornecer atraso para todos os fluxos de HQ individualmente em recurso coletivo de alto desempenho (por exemplo, disco, Flash ou RAM muito rápidos). Em qualquer caso, cada Armazenamento temporário de atraso de HQ 3121D- 3131D é capaz de atrasar variavelmente um fluxo da fonte de vídeo de HQ, ou passar o fluxo não atrasado.
Em outra modalidade, cada armazenamento temporário de atraso é capaz de fornecer fluxos múltiplos com diferentes quantidades de atraso. Todos os atrasos ou não atrasos são solicitados por | Serviços de Aplicativo/Jogo 3121-3125. Em todos esses casos fluxos de ví- deo atrasados e não atrasados 3198 são enviados ao Roteamento Interno 3192, e procedem através do resto do subsistema 3143 como descrito previ- ij 5 amenteem relação às figuras 319.
! Nas modalidades precedentes relativas as várias figuras 31n | : observa-se que o Fluxo ao vivo utiliza uma conexão de duas vias a é adap- ! tado para um usuário particular, com mínima latência. Os fluxos de HQ utili E zam conexões de uma via e são tanto unicast quanto multicast. Observe que : enquanto a função multicast é ilustrada nessas figuras como uma única uni- dade, como poderia ser implantada em um comutador Gigabit Ethernet, em um sistema de larga escala, a função multicast seria implantada através de É uma árvore de comutadores múltiplos. De fato, no caso de um fluxo de vídeo de um jogador de vídeo game de alta classificação, pode ser que o fluxo de HQ do jogador seja assistido por milhões de usuários simultaneamente.
- Nesse caso, provavelmente haveria um grande número de comutadores in- dividuais em estágios sucessivos difundindo o fluxo de HQ que sofreu multi- É cast.
Para ambos os propósitos de diagnóstico, e para fornecer reali- mentação para o usuário (por exemplo, informar ao usuário sobre a popula- ridade de seu desempenho de jogo), em uma modalidade, o serviço de hos- pedagem 210 rastrearia a quantidade de espectadores simultâneos que há TF de cada fluxo de vídeo de Servidor de Aplicação/Jogo 3121 a 3125. Isso po- : de ser realizado mantendo-se uma contagem de execução do número de solicitações ativas por Aplicação/Servidores de jogo para um fluxo de vídeo particular. Então, um jogador que tem 100.000 espectadores simultâneos saberá que seu jogo é muito popular, e isso criará um incentivo para que ; jogadores tenham um melhor desempenho e atraiam espectadores. Quando há um grande número de espectadores de fluxos de vídeo (por exemplo, de uma partidade videogame de um campeonato), pode-se desejar que Os co- mentaristas falem durante a partida de videogame de tal modo que alguns ou todos os usuários assistindo ao multicast possam ouvir seus comentários.
| As Aplicações e Jogos sendo executados em Aplica- ção/Servidores de jogo serão fornecidos com uma Interface de Programa de Aplicação (API) em que a Aplicação e/ou Jogo possa submeter solicitações | para fluxos de vídeo particulares com características particulares (por exem- [ plo, resolução e quantidade de atraso). Ademais, esses APIs, submetidos a [ | um ambiente de operação sendo executado em Aplicação/Servidor de jogo, ! ou a um Sistema de Controle de Serviço de Hospedagem 401 da figura 4a i pode rejeitar tais solicitações por uma variedade de motivos. Por exemplo, o Í EEE fluxo de vídeo solicitado pode ter certas restrições de direitos de licença (por exemplo, de modo que possa ser visualizado somente por um único espec- : tador, e não difundido para outros), pode haver restrições de assinatura (por exemplo, o espectador pode ter que pagar pelo direito de visualizar o fluxo), pode haver restrições de idade (por exemplo, o espectador pode ter que ter 18 anos para visualizar o fluxo), pode haver restrições de privacidade (por exemplo, a pessoa que usa a Aplicação ou que está jogando o jogo pode e limitar a visualização a somente um número ou classe selecionada de es- pectadores (por exemplo, seus "amigos"), ou pode não permitir a visualiza- À ção completamente), e pode haver restrições que exigem que o material seja atrasado (por exemplo, se o usuário está jogando um jogo de camuflagem em que sua posição pode ser revelada). Há inúmeras outras restrições que limitariam a visualização do fluxo. Em qualquer um desses casos, a solicita- ção por Aplicação/Servidor de jogo seria rejeitada com um motivo para a E rejeição e, em uma modalidade, com alternativas através das quais a solici- - tação seria aceita (por exemplo, estabelecer a taxa que seve ser paga para uma assinatura).
Os fluxos de vídeo de HQ que estão armazenados em Armaze- namentos Temporários de Atraso, em qualquer uma das modalidades pre- í cedentes, podem ser exportados para outros destinos fora do Serviço de É Hospedagem 210. Por exemplo, um fluxo de vídeo particularmente interes- —sante pode ser solicitado por uma Aplicação/Servidor de jogo (tipicamente, através da solicitação de um usuário) para ser exportado para o YouTube.
Em tal caso, o fluxo de vídeo seria transmitido através da Internet em um
| formato consentido pelo YouTube, junto com informações descritivas ade- quadas (por exemplo, o nome do usuário jogador, o jogo, o tempo, a pontua- | ção, etc.). Isso poderia ser implantado através do multicast, em um fluxo se- L parado, do áudio de comentários para todos os Servidores de Jo- í 5 —go/Aplicação 3121 a 3125 solicitando tais comentários.
Os Servidores de | ! Jogo/Aplicação fundiriam o áudio do comentário, com o uso de técnicas de | : mixagem de áudio bem conhecidas pelos versados na técnica, ao fluxo de : áudio enviado às premissas de usuário 211. Poderia haver múltiplos comen- ! o taristas (por exemplo, com diferentes pontos de vista, ou em diferentes idio- É mas),eos usuários poderiam selecionar entre esses.
De modo similar, os fluxos de áudio separados poderiam ser mi- xados em ou funcionar como substituição para trilha de áudio de fluxos de vídeo particulares (ou fluxos individuais) no Serviço de Hospedagem 210, mixando ou substituindo o áudio do fluxo contínuo de vídeo em tempo real oude um Armazenamento Temporário de Atraso.
Tal áudio pode ser um comentário ou narração, ou poderia fornecer vozes para personagens no fluxo de vídeo.
Isso permiítira que Machinima (animações de geração por É usuário de fluxos de vídeo de videogame) fosse prontamente criado por u- suários.
Os fluxos de vídeo descritos ao longo desse documento são mostrados como capturados a partir da saída de vídeo de Servidores de A- plicação/Jogo, e, então, submetido a fluxo e/ou atraso e reutilizado ou distri- gr buído em uma variedade de maneiras.
Os mesmos Armazenamentos Tem- , porários de Atraso podem ser usados para manter o material de vídeo pro- —veniente das fontes diferentes do Servidor de Aplicação/Jogo e fornecem o mesmo grau de flexibilidade para reprodução e distribuição, com restrições adequadas.
Tais fontes incluem alimentações ao vivo a partir de estações de televisão (através do ar, ou não através do ar, como CNN, e outros liberados mediante pagamento, como HBO, ou gratuitos). Tais fontes também incluem fimes ou programas de televisão, filmes caseiros, propagandas e, ainda, alimentações de teleconferência de vídeo ao vivo pré-gravados.
As alimen- tações ao vivo seriam gerenciadas como a saída ao vivo de um Servidor de
| Jogo/Aplicação.
Os material pré-gravado seria gerenciado como a saída de Í um Armazenamento Temporário de Atraso.
Em uma modalidade, os diversos módulos funcionais ilustrados aqui e as etapas associadas podem ser realizadas por componentes de i 5 hardware específicos que contêm lógica fisicamente conectada para realizar as etapas, como um circuito integrado específico de aplicação ("ASIC") ou | através de qualquer combinação de componentes de computador programa- É dos e componentes de hardware personalizados.
É E Em uma modalidade, os módulos podem ser implantados em um á processador de sinal digital programável ("DSP"), como uma arquitetura TMS320x da Texas Instruments (por exemplo, um TMS320C6000, TMS320C5000, etc). Diversos DSPs diferentes podem ser usados enquanto ainda estão em conformidade com esses princípios fundamentais.
As modalidades podem incluir diversas etapas, conforma esta- —belecido acima.
Essas etapas podem ser incorporadas em instruções execu- - táveis por máquina que fazem com que um processador de propósito geral ou de propósito especial realize determinadas etapas.
Diversos elementos que não são relevantes para esses princípios fundamentais, como uma me- mória de computador, disco rígido, dispositivos de entrada, foram deixados de fora de algumas ou de todas as figuras para evitar o obscurecimento dos aspectos pertinentes.
Os elementos do assunto apresentado também podem ser for- E necidos como um meio legível por máquina para armazenar as instruções : executáveis por máquina.
O meio legível por máquina pode incluir, mas sem limitação, memória rápida, discos ópticos, CD-ROMs, DVD ROMs, RAMs, EPROM;s, EEPROMs, cartões magnéticos ou ópticos, meio de propagação ou outro tipo de meio legível por máquina adequado para armazenar instru- ções eletrônicas.
Por exemplo, a presente invenção pode ser transferida por download como um programa de computador que pode ser transferido a par- tirdeum computador remoto (por exemplo, um servidor) para um computa- dor que fez a solicitação (por exemplo, um cliente) por meio de sinais de da- dos incorporados em uma onda portadora ou outro meio de propagação a-
través de um link de comunicação (por exemplo, um modem ou conexão de rede). Deve-se compreender, ainda, que elementos do assunto apre- sentado também podem ser fornecidos como um produto de programa de | 5 computador que pode incluir um meio legível por máquina que tem instru- L ções instaladas no mesmo que pode ser usado para programar um compu- Í tador (por exemplo, um processador ou outro dispositivo eletrônico) para b realizar uma sequência de operações.
Alternativamente, as operações po- mENDNNS) dem ser realizadas através de uma combinação de hardware e software. : O meio legível por máquina pode incluir, mas sem limitação, disquetes, dis- cos ópticos, CD-ROMs e discos magnético-ópticos, ROMs, RAMs, EPROMs, EEPROMSs, cartões magnéticos ou ópticos, meio de propagação ou outro tipo de mídia/meio legível por máquina adequado para armazenar instruções eletrônicas.
Por exemplo, elementos do assunto descrito a serem transferi- dos por download como um produto de programa de computador, em que o - programa pode ser transferido a partir de um computador remoto ou disposi- tivo eletrônico para um progresso por solicitação através de sinais de dados É incorporados em uma onda portadora ou outro meio de propagação por meio de um link de comunicação (por exemplo, um modem ou conexão de rede). Além disso, embora o assunto apresentado tenha sido descrito em conjunto com modalidades específicas, diversas modificações e altera- ções são bem conhecidas no escopo da presente descrição.
Consequente- n mente, o relatório descritivo e os desenhos devem ser considerados como ilustrativos ao invés de serem considerados em um sentido restritivo.

Claims (21)

  1. a. 17 É |
    REIVINDICAÇÕES L 1. Método implementado por computador para executar com- pressão de vídeo compreendendo as etapas de: i i receber uma solicitação a partir de um cliente através de uma rede para jogar vídeo game online ou executar um aplicativo online em uma central de serviço de hospedagem compreendida de uma pluralidade de ser- vidores de hospedagem; receber sinais de controle transmitidos a partir de um cliente a- través da rede a um primeiro servidor em uma central de serviço de hospe- —dagem indicando a entrada do usuário a um cliente na medida que o usuário está jogando o vídeo game ou usando o aplicativo e executa responsiva- mente o vídeo game ou aplicativo em um servidor na primeira central de ser- viço de hospedagem para gerar saída de vídeo compreendendo sequencias de imagens de vídeo do vídeo game ou aplicativo; codificar a saída de vídeo para gerar uma pluralidade de qua- dros de vídeo comprimidos ou partes dos mesmos, em que a etapa de codi- ficar compreende gerar um primeiro conjunto de quadros de vídeos que não são dependentes dos quadros de vídeos anteriores e um segundo conjunto de quadros de vídeos que são dependentes dos quadros de vídeos anterio- res transmitir continuamente a pluralidade de quadros de vídeo comprimidos ou partes para uma dispositivo do cliente, os quadros de vídeo comprimidos ou partes sendo decodificados por um decodificador em um cliente e renderizado no cliente na medida que o usuário joga o vídeo game ouusao aplicativo, em que o primeiro conjunto de quadros é decodificado sem referência aos quadros anteriores e em que o segundo conjunto de quadros é decodificado com referência aos quadros anteriores; em que as operações de receber os sinais de controle transmiti- dos a partir do dispositivo do cliente, executar o vídeo game ou aplicativo, codificar e transmitir continuamente o fluxo de vídeo de baixa latência ao dispositivo do cliente, e decodificar o fluxo de vídeo de baixa latência no dis- positivo do cliente são realizadas de modo que o usuário tenha a percepção
    Chhhhhirhhhhhhhhhhhhhr———nrsssshu e 27
    Y de que o vídeo game ou aplicativo selecionados estão respondendo instan- ' taneamente aos sinais de controle recebidos a partir do dispositivo do clien- te.
  2. 2. Método, de acordo com a reivindicação 1, ainda compreen- dendoas etapas de: receber uma informação de retorno a partir do dispositivo do cli- ente, a informação de retorno sendo utilizável para determinar as caracteris- ticas de canal atuais de um canal de comunicação entre o primeiro servidor e o cliente; codificar a pluralidade de quadros de vídeo comprimidos para in- cluir uma razão do primeiro conjunto de quadros com o segundo conjunto de quadros, pelo menos em parte nas características de canal detectadas.
  3. 3. Método, de acordo com a reivindicação 2, em que os quadros ou partes dos mesmos compreendem P-quadros ou P-blocos, respectiva- mente, quando codificados de acordo com o primeiro formato de codificação e em que os quadros ou partes dos mesmos codificados compreendem |- quadros ou I-blocos, respectivamente, quando codificados de acordo com o segundo formato de codificação.
  4. 4. Método, de acordo com a reivindicação 1, em que a informa- çãode retorno compreende uma indicação de que os quadros ou partes dos mesmos foram recebidos com sucesso e/ou decodificados no dispositivo do cliente.
  5. 5. Método, de acordo com a reivindicação 1, em que a informação de retorno compreende uma indicação de que os quadros ou partesdosmesmos não foram recebidos com sucesso e/ou decodificados no dispositivo do cliente.
  6. 6. Método, de acordo com a reivindicação 1, em que os quadros de vídeo compreendem imagens de um vídeo game sendo jogado no dispositivo do cliente.
  7. 7. Método, de acordo com a reivindicação 1, compreendendo ainda as etapas de: decodificar os quadros de vídeo codificados ou partes dos
    : 37
    Y mesmos no dispositivo do cliente; e " exibir imagens associadas com cada um dos quadros de vídeo ou partes dos mesmos em uma tela no dispositivo do cliente. lá
  8. 8. Sistema compreendendo uma memória para armazenar —códigode programa e um processador para processar o código de programa para executar as operações de: receber uma solicitação a partir de um cliente através de uma rede para jogar vídeo game online ou executar um aplicativo online em uma central de serviço de hospedagem compreendida de uma pluralidade de ser- vidoresde hospedagem; receber sinais de controle transmitidos a partir de um cliente a- través da rede a um primeiro servidor em uma central de serviço de hospe- dagem indicando a entrada do usuário a um cliente na medida que o usuário está jogando o vídeo game ou usando o aplicativo e executa responsiva- mente o vídeo game ou aplicativo em um servidor na primeira central de ser- viço de hospedagem para gerar saída de vídeo compreendendo sequencias de imagens de vídeo do vídeo game ou aplicativo; codificar a saída de vídeo para gerar uma pluralidade de qua- dros de vídeo comprimidos ou partes dos mesmos, em que a etapa de codi- ficar compreende gerar um primeiro conjunto de quadros de vídeos que não são dependentes dos quadros de vídeos anteriores e um segundo conjunto de quadros de vídeos que são dependentes dos quadros de vídeos anterio- res; transmitir continuamente a pluralidade de quadros de vídeo comprimidos ou partes para uma dispositivo do cliente, os quadros de vídeo comprimidos ou partes sendo decodificados por um decodificador em um cliente e renderizado no cliente na medida que o usuário joga o vídeo game ou usa o aplicativo, em que o primeiro conjunto de quadros é decodificado sem referência aos quadros anteriores e em que o segundo conjunto de — quadros é decodificado com referência aos quadros anteriores; em que as operações de receber os sinais de controle transmiti- dos a partir do dispositivo do cliente, executar o vídeo game ou aplicativo, a E N—— —o— ——— E —— — — — ——
    . 47 codificar e transmitir continuamente o fluxo de vídeo de baixa latência ao fi dispositivo do cliente, e decodificar o fluxo de vídeo de baixa latência no dis- positivo do cliente são realizadas de modo que o usuário tenha a percepção Í de que o vídeo game ou aplicativo selecionados estão respondendo instan- —taneamente aos sinais de controle recebidos a partir do dispositivo do clien- te.
  9. 9. Sistema, de acordo com a reivindicação 8, ainda compreen- dendo: receber uma informação de retorno a partir do dispositivo do cli- ente, a informação de retorno sendo utilizável para determinar as caracterís- ticas de canal atuais de um canal de comunicação entre o primeiro servidor e o cliente; codificar a pluralidade de quadros de vídeo comprimidos para in- cluir uma razão do primeiro conjunto de quadros com o segundo conjunto de quadros, pelo menos em parte nas características de canal detectadas.
  10. 10 Sistema, de acordo com a reivindicação 9, em que os quadros ou partes dos mesmos compreendem P-quadros ou P-blocos, respectivamente, quando codificados de acordo com o primeiro formato de codificação e em que os quadros ou partes dos mesmos codificados compreendem I-quadros ou I-blocos, respectivamente, quando codificados de acordo com o segundo formato de codificação.
  11. 11. Sistema, de acordo com a reivindicação 8, em que a informação de retorno compreende uma indicação de que os quadros ou partes dos mesmos foram recebidos com sucesso e/ou decodificados no dispositivo do cliente.
  12. 12. Sistema, de acordo com a reivindicação 8, em que a informação de retorno compreende uma indicação de que os quadros ou partes dos mesmos não foram recebidos com sucesso e/ou decodificados no dispositivo do cliente.
  13. 13. Sistema, de acordo com a reivindicação 8, em que quadros de vídeo compreendem imagens de um vídeo game sendo jogado no dispositivo do cliente.
    Et LO
    . 57
  14. 14. Sistema, de acordo com a reivindicação 8, compreendendo e código de programa adicional para fazer com que o processador execute as operações de: decodificar os quadros de vídeo codificados ou partes dos mesmos no dispositivo do cliente; e exibir imagens associadas com cada um dos quadros de vídeo ou partes dos mesmos em uma tela no dispositivo do cliente.
  15. 15. Meio legível por máquina tendo código de programa armazenado no mesmo que, quando executado por uma máquina, faz com queamáquina execute as operações de: receber uma solicitação a partir de um cliente através de uma rede para jogar vídeo game online ou executar um aplicativo online em uma central de serviço de hospedagem compreendida de uma pluralidade de ser- vidores de hospedagem; receber sinais de controle transmitidos a partir de um cliente a- través da rede a um primeiro servidor em uma central de serviço de hospe- dagem indicando a entrada do usuário a um cliente na medida que o usuário está jogando o vídeo game ou usando o aplicativo e executa responsiva- mente o vídeo game ou aplicativo em um servidor na primeira central de ser- viçode hospedagem para gerar saída de vídeo compreendendo sequencias de imagens de vídeo do vídeo game ou aplicativo; ' codificar a saída de vídeo para gerar uma pluralidade de qua- dros de vídeo comprimidos ou partes dos mesmos, em que a etapa de codi- ficar compreende gerar um primeiro conjunto de quadros de vídeos que não são dependentes dos quadros de vídeos anteriores e um segundo conjunto de quadros de vídeos que são dependentes dos quadros de vídeos anterio- res; transmitir continuamente a pluralidade de quadros de vídeo comprimidos ou partes para uma dispositivo do cliente, os quadros de vídeo —comprimidos ou partes sendo decodificados por um decodificador em um cliente e renderizado no cliente na medida que o usuário joga o vídeo game ou usa o aplicativo, em que o primeiro conjunto de quadros é decodificado
    - 67 sem referência aos quadros anteriores e em que o segundo conjunto de . quadros é decodificado com referência aos quadros anteriores; em que as operações de receber os sinais de controle transmiti- ' dos a partir do dispositivo do cliente, executar o vídeo game ou aplicativo, codificar e transmitir continuamente o fluxo de vídeo de baixa latência ao dispositivo do cliente, e decodificar o fluxo de vídeo de baixa latência no dis- positivo do cliente são realizadas de modo que o usuário tenha a percepção de que o vídeo game ou aplicativo selecionados estão respondendo instan- taneamente aos sinais de controle recebidos a partir do dispositivo do clien- te
  16. 16. Meio legível por máquina, de acordo com a reivindicação 15, ainda compreendendo: | receber uma informação de retorno a partir do dispositivo do cli- ente, a informação de retorno sendo utilizável para determinar as caracteris- ticas de canal atuais de um canal de comunicação entre o primeiro servidor e o cliente; codificar a pluralidade de quadros de vídeo comprimidos para in- cluir uma razão do primeiro conjunto de quadros com o segundo conjunto de quadros, pelo menos em parte nas características de canal detectadas.
  17. 17. Meio legível por máquina, de acordo com a reivindicação 16, em que os quadros ou partes dos mesmos compreendem P-quadros ou P- blocos, respectivamente, quando codificados de acordo com o primeiro formato de codificação e em que os quadros ou partes dos mesmos codificados compreendem I-quadros ou I-blocos, respectivamente, quando codificados de acordo com o segundo formato de codificação.
  18. 18. Meio legível por máquina, de acordo com a reivindicação 15, em que a informação de retorno compreende uma indicação de que os quadros ou partes dos mesmos foram recebidos com sucesso e/ou decodificados no dispositivo do cliente.
  19. 19. Meio legível por máquina, de acordo com a reivindicação 15, em que a informação de retorno compreende uma indicação de que os quadros ou partes dos mesmos não foram recebidos com sucesso e/ou
  20. , 77 decodificados no dispositivo do cliente. - 20. Meio legível por máquina, de acordo com a reivindicação 15, em que os quadros de vídeo compreendem imagens de um vídeo game : endo jogado no dispositivo do cliente.
  21. 21. Meio legível por máquina, de acordo com a reivindicação 15, compreendendo código de programa adicional para fazer com que a máquina execute as operações de: decodificar os quadros de vídeo codificados ou partes dos mesmos no dispositivo do cliente; e exibir imagens associadas com cada um dos quadros de vídeo ou partes dos mesmos em uma tela no dispositivo docliente.
    | 1/55 Í
    F Disco Rígido ! 103
    RAM HA (E 101 a, 1 / IOOOD0000; Es SDTV/HDTV/Monitor Mídia boas a. CPU/GPU 1 " DR vo [O (<=) no - Conexão - de rede 105 ÁÃO = TT Controlador A y de jogo ESAÃ, We FAR) : U FIG. 1 (Técnica anterior)
    ij j 2/55 | pos e e a a e a a a a a a ss ss 1 i E sm | 1% so | É o | — ! 18 Ss ho 8 18 X [ E tz 3 o 7 S So | 8 DE = N 2a DB S | PSSaS e E D : 2 FS VD 2 ' 8 ' DB ma 7 " ' e 3 8 $| ' Ss E z.- = t go ES 2 INSIB) 2 1 1 508 3 o fls ã ! 1 68 Fls 2 8 ' : ê E) 1 B 1 a) ' [ MENNSNPNNNOSNSNSNSNNNAN ASNSNNRA! ISQNCNANNN! COSCSNNNNNCSNNNSA | e o oo = DE Se| ge [] Do & o [e] - os <OoO s/2ã o) oo 2/2 = STE uu õ o
    S 7 58 o Bm e E S o ss 8 SC o E Fr o o o = 2 S a 5º TV E =) o Boo ss o O wo E E o 200o|/ 200 Oo o SE> NTE So 53 [OS] 33 go no oO 8 — o 5 2 | fo
    O
    Í Í 3/55 | | e a ns een e ana perereca So 'E R 1 A F d ES > o e | | 12 5 n AR ' | 3 EA o is SS | 8 1 À | 18 Es) | So a 2 É | so 18 = TH ã | 1 =. a & aa NSSEENAS 1 Ê | ' ' i — U o i Dê s fl. 3 1 1a E Í E = 1 1$s CINE Ig8w» so | = S ê 1Eº S$ 3 | Ss Z i 182 S 8 â i 102 Õ ã 1
    TOS 1 or tores Ao ae oo FR oo Z POo | 8E 2 | 28| Ss qc SS 8s8| <o . 8 3 S ESA o À = 8 — 3 SS E à = 2 . & E e) = S ss
    S E ; . 8 d. E o o o B&o Ss 858, > 88 55 q o 2080 SH ocÇ = oz> Silo TB re > 23 = o EX Ss 8º |, 38 O < o o o 2
    Ô So
    O
    | 4/55 = | o 2 | ,: 5 | ] Ú Fr Í Í ” : o / 2 . vo So ! D2qN ' Ss ' — sãã ; Fr nx = A
    À x f ' í ; AE ai ' i : o% = o — a o ês * So 228 o) &
    Ê o = o o Oo ” Oo +
    SS SS no£S ie) Ee mr = o XZTO x OS GO Ê geo & O j 5/55 Í i | pes rmeensrnereseNEEEEnEeEssEEEEEEEEEEN==EA 1 qo : I 1 ES 1 | ' sá Ss, , n so 1 Í ELE IN SQ [53 1 Í 1Sl o À o X se 1o EIN 3 & 35 1 Í E 1 DO o O 1 | 1 3 Ses CU 1 15 8 822 Tasssiles i : 1885 838 E o 8 3 ' 17 288 2 o Ses Tilo> o ' 18 É o Tom SO O ' 8 EO 288 1 — 12 2 E CE : 1 É 8607 ESs* 1 Leoq=smmmm———————e —————-.—— o FIT as os 2 3u So o28 = + o o
    E =| 2 o O '- < 1 O 1 LL rTIrs=s=e=========A= —— LL TA ! ' If ! 1 T 1 38 ' ' Es Be. ! el i i ESSE oa o ' Sos, 2 EO | va 1 oO8RL | oES oo ' 355 [EST oO 1 ' STR s o RS FE: se 3 ' 1 aos 8/8 Tr 2 ES so U : Te se 1eES|l8&o Fo so co T|[8ES t 1 o 16º 6 1 E s 1 1 1 1 o 1 1 "3 1 ij 18 & ; 1 E << 18 s C ' = o V 1 oO | Zoo [| B1o| : 1& s | ss) 2 Ss ! 1 > o 8, Ss So N 1 o Ss ? 1 Ss : = 1 1 1 1 1 1 | BusENSSNNNCNNNCSNSNSPSNSANNCRNENONANNNNENENDNENNANENSNENANAANENEA,
    i | | 6/55 | | o
    E 8 A E ” LEE Ás É o N A ST (2) o : 23 04” o À o 2 o E f 3 8 i o” â os do Ss i PS, 88, = ES E 2 E ÉS Do) EZSS| 5 E De 8 QT ES Ss wo no
    Õ É q = E
    2. e. = S.- “m NNNNENNNN so FE =FE SE: 328 o 35 Esso | T=25 E53E8| ES 3 859) .e... EP PST > is FD ao or 8 co uu me e a a Jo a a o Ts a $8 sá RB, ES >| Tétf£S c=L5 2 fo 288188 ã 28 2888 3 É 28858
    SERS 23 ce 85
    OST ESSE E. BÉ Ss so E SERSE O E o. esc GG 2EEÕSE 2 IS SE 305 .e.... ———- 2ESSÕES * e : BSS 8E E 8s O
    E Eco s= o É fãs
    BSS E = cr =? SE.
    TS go £o o e - vs SI ls 82 | &N 78 Esso E os Eae: 5 |a5SS|| 58 | à |ês 7 O o E o 2 8 3 8 8 SS o 8 s o Ss ES) -s E o o o OT o Ss | ES! o s Ss 2 É SS] É o 5 3SSS| 5 8 8 EST: 8 | 328 os o 8 S SB e É 8 m o o
    | 7/55 |
    É => | S F > 58 | | o ! É 3 Y o | rm Ola E N/D À o O SL F T (O E À õ TD À o 3| | 2 E V 8 Ng: “OS, : hi / E QN 8 CrnK/ Bv ——B RUINS É So õ p Ss Conaaçõao o ae Seg, T =s Pp . + SD a LL vo en as NE 3 : às . 2 : eva NO ú E -. E ANS
    WZAW É DS g 2 Ns586 so PE o | 2 Sl =) 5
    S
    | 8/55 | | : Jg "o f S / ã É Se 8 [ i ES = 3 SA js E) 3 Í Vs k 8 E AF 8 Q à =. Ã ES O NY O " 2 ÊNIO 04)? mano O nO . (TD B o 1 D 8 Yo O = | o UMES 1 < s Postaçço o 8 À à NOASONSEA O eo O SODÃO o S | DA o À Ns MU 5 . v / Ss DA õ —— no = es O 28 3 E A 3 LL Los <sEo - SE eso Nx ã É o Ba Vo >2 : : so | 2º mA = 288 | e do EEE = E 288 Or — o: ossos mesrEsEnand
    E & + 8 É & E oê8 vv o Tv
    FS À go 8 Í no j É x = ' | gu = Tt [4 Rs | 1 o o vo NNASES Bo e 385 3ss8 ss T<T E o 1 SS eg O = =o ss ês 228, SoSS8| 52988 e TX 5 GOOrTy| | 28S 29656 $ 35 82 88 Ss = 2 = 3o nu. go 358 8 om ç O 2Ss ass do 8 2
    E o - Es É 3 - à 8 : m ss o e o
    S E SE | ES” & E es us Ex To <sT mn
    ' | 10/55 ] ê vz oe o 1 S a q T Í 28 8-7 o $ 8 p | FE 3 g 3 É oã Í | aã =-002 RS | 3 Z3>288 & ST 2 oO>3736J Soc IOV>0O À U< aaa > : Son Te 8 Eos 3So > SS s<S Óo (2) o O e Ses | se SET o PD, ET w& ES ES 88XTS SERES
    BETIS ODST ags& Sã E o8a i Ss > Lt .S oo so PE m no 8 4 7 sSE8 o o q EE & ES aos -s m dO o 8 > se Go e EN E E . E q + Emo 8 ss 8
    F 8 (3 = 55 s Ss >
    E su eg us o 3 a sm Deo so SL Do = oT 2 Lo uu
    | 11/55 | j ! ! | | ; ; H ' H ' i 1, | : : HW 1 ' , : ' h ' : 1 ; : o Ss oe e
    SEO FE 2EO sm SE Ss 26 8 oo o 8 >D Pa E 3 Z 2 o o S g 1 2 2 8 E Sã "nm É 8/ | ESPN Ds s EF & oE SS 38h S u 3 Ss o " 2 BE" Iê -. ê o 20 8 E E do 5 ú ã ê > o a 8 ” 88 - E 5 E 5 Er
    SE EE
    ES EEE BED à É 26 S oo o 842
    GOO o
    Í 12/55 | 3 TE ! ! E ES | Í SE. EE | f2E ES ISS Tas à
    E TL ss oo 9º o mn. = O SE 2 o 2ES do 5 Tais se SE ãL 2o oo 2 & À õ ; ; = ' í S i ' PS o ' E x Ss o Sã s 838 a Oo Tr o E A ó Ss ; ev ” &| [858 Ter| PS E E EE =, uu Ss õ aL Ss x 32o o o oo É
    S & oo Fa 6 > 3 SE sÍÃa = Ta 288 ses : S5 aL q õ oo oo ES... CS E. a se.
    ES BE NS ss SE ã* 36 = oo os n Ooo no q ses > o o j | 13/55 | = r Í o | = j : 5 /, Pç i x
    Q o <Q : -— qa o B 8 ; o OB 2 OD vg o o F— r SS "2 uu. oa Se o os Fs a vo O o go vs Ko o É x e = Ss EE = x ão $ o o 8 o S v E o o É SS GS So o DES RO o O XTN o2Q Er o USO XOqN o > õ g=s 82000 x O E o S É oo m 3 O Fr >
    | | 14/55 | : | o a : : o PR | | 7 É 7 o & ver 7 0 Mm i | oo ; ss : nã kW
    À
    É O Ó qo 8 E o Z ÉS à : 2 S 865 vs E Ts [PA : FE q= co Êo o vo E é à o | : 8 OS ven — PE Ger = 8 8 Go 3 es z 2 E 1 o o 3 E S Ses Bot o DES = So
    EE DE is Soo E SE o O, nesses < = o 588 Fr & O UT ms Foo
    OO oo
    | 15/55 |
    S eles] NGENS | oo =] Í WO o e z | SPNDOH EGENSS | oE Oo £e ! õ8 S 8
    S |els|ejs| [ee de MINHO [e e TE oo « o < SPRNDOH ele Es. £EB RE Bê o ns <R o :º as" ejo|e| EGENE Ss [els es) EHG68 e
    SD
    ETR [eira EGES e [4 St. o ejers| EGQNNSK SES Es E ER o o ejer sit jejo|o E eles 3o * [ers[s[s| [je e] TETE : É iris] EGNEN FF a e slo e elz de. FÊR = =| E x o a = ss | º/ºlº| je je ae E go = . [eisje|s]| ele je] o Sam %n E So e oo nos xo dOTg oe ado
    E é = E> a Co oo“ Fs3 os a [ele i fo 28 El e ' TER Te Ei = GE — j 230 Rr ão = o oo « ai Llee 8 SER " Er BEN Ciao oº ã õe 2 2o " — [e] [ele] R = À o) el o « f o SRI ele S,. ZE Es oro Se S So e" ** el] a E « " SE ele &. 2E Co
    SER ER Es 8 SE 1º] ee 2o = E el| [| ; E af ó so ai 2 382 o 8 E EE É o aB3S Es FE o oã Sc
    | 17/55 | : : : : ; : j : | i ' | ! | ! ! SE a (De | as 2 > 35º A DN] õ * di o 8 o Ss É S : co 2 ; ; = É o H ' : 8 : i [a : Ss j j = j :
    E oO x o õ a
    FE EO ZE ú - eE Ss er + 2320 õ ee De |
    IAN DI 8 os O ! 32 ST o aBsdo o EZ S x co os S
    | 8 8 8 8 Tx 8º à às às 1 do Dos Asa os r | o 8 2 eg o o o LT | voo v1o voo o.o ke) 88) 88) 88) r Pr Pr | ' 1 ' 1 = Í i i i 8 i ri õ | 1 1 ' VaNNNs 1 1 1 1 / 1 1 1 1 é 1 1 ' SENSO. ' 1 1 1 ' 1 1 1 , 1 1 1 saas 1 1 ' ro 1 1 1 Sassi 1 ' 1 1 k 1 1 ' 1 “ 1 1 1 ' ' 1 1 1 ir NaNA | ! X T 1 , |! 1 1 vo : A x ; . DT 1 1 PA 1 88 1 1 1 1 SS 1 1 A po i 1 2 S | | i et: " 1 1 ' TE = 1 1 ã | a x 1 1 ao 7 u ' ' BR 1 1 ' ao! x 1 1 1 1 ko ' 1 1 1 EE ! 1 1 AEE 1 1 1 N 1 1 ' 1 a 1 ' ' 1 1 ' 1 rasa - 1 ' 1 de " 1 ' 1 FA 1 1 ' ee 1 1 1 DA 1 1 ' Pa 1 1 1 rá í 1 1 1 i ! 1 1 ' 4 ' 1 1 1 No A ' ' 2 1 ' sv o Ee) o 8 = R v o Cos Fr AOE£ES« o o oxXEa So TE” ROS geo neste ã& O o 8 rr vEZÇO Foo To Fr >
    | ! |
    Í 8 os e SeE PEN s3 Bs EE S cen 2855 FR OS acto 3285 + Es | õ 8 õ8 sé ' o o à Ss S Est 8 se FESS: 55 Ss => êÊ = e int: s E Se 7358 5 8 ss s nr 8 8 $855B SE sZz2 oO sos — f- . 8 8 83. É St 2E5s$ EN SE gl [E 158 ES 8 ê SE 3 CA: a 3 o 3 = sei SE s . 2 oE ww SE gl 18 Ss E TE o SE & Ss o 3588 HH Eds B às ê ê: Õ si 8 o | E Bs 2oE mw Fo
    É FEZ s5 — ã 2 E sis, Es5 8 gs 3) |85E ES 8 " ê 3 ZE â õ Sô : s = 2oÊ SE "o & LE à 8% ss 23 8) ais SsZ£ o sê EE õ ss 8 + o = ZE ã VE eÊ 88 õ E- Eis tes g Est Ss FE 83. Cs õs8 ss í 2 é = ss E o É & 7 oe 3 no O OwT
    TOO ar g E> SS x o mM
BRPI1012236-2A 2009-03-23 2010-03-17 Sistema e método para compressão de quadros de vídeo ou partes dos mesmos com base em informação de retorno de um dispositivo cliente BRPI1012236A2 (pt)

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,054 US9314691B2 (en) 2002-12-10 2009-08-07 System and method for compressing video frames or portions thereof based on feedback information from a client device
US12/538,054 2009-08-07
PCT/US2010/027716 WO2010111096A1 (en) 2009-03-23 2010-03-17 System and method for compressing video frames or portions thereof based on feedback information from a client device

Publications (1)

Publication Number Publication Date
BRPI1012236A2 true BRPI1012236A2 (pt) 2021-03-23

Family

ID=42781398

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI1012236-2A BRPI1012236A2 (pt) 2009-03-23 2010-03-17 Sistema e método para compressão de quadros de vídeo ou partes dos mesmos com base em informação de retorno de um dispositivo cliente

Country Status (15)

Country Link
US (3) US9314691B2 (pt)
EP (1) EP2412159A1 (pt)
JP (1) JP2012521721A (pt)
KR (1) KR101788330B1 (pt)
CN (1) CN102428698A (pt)
AU (1) AU2010229092A1 (pt)
BR (1) BRPI1012236A2 (pt)
CA (1) CA2756299A1 (pt)
IL (1) IL215309A0 (pt)
MX (1) MX2011009972A (pt)
NZ (1) NZ595840A (pt)
RU (1) RU2011142769A (pt)
SG (2) SG174544A1 (pt)
TW (1) TWI558109B (pt)
WO (1) WO2010111096A1 (pt)

Families Citing this family (90)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7162035B1 (en) 2000-05-24 2007-01-09 Tracer Detection Technology Corp. Authentication method and system
US8171567B1 (en) 2002-09-04 2012-05-01 Tracer Detection Technology Corp. Authentication method and system
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
US8888592B1 (en) 2009-06-01 2014-11-18 Sony Computer Entertainment America Llc Voice overlay
US8968087B1 (en) 2009-06-01 2015-03-03 Sony Computer Entertainment America Llc Video game overlay
US8613673B2 (en) 2008-12-15 2013-12-24 Sony Computer Entertainment America Llc Intelligent game loading
US8147339B1 (en) 2007-12-15 2012-04-03 Gaikai Inc. Systems and methods of serving game video
US8926435B2 (en) 2008-12-15 2015-01-06 Sony Computer Entertainment America Llc Dual-mode program execution
US9723319B1 (en) 2009-06-01 2017-08-01 Sony Interactive Entertainment America Llc Differentiation for achieving buffered decoding and bufferless decoding
US9565479B2 (en) * 2009-08-10 2017-02-07 Sling Media Pvt Ltd. Methods and apparatus for seeking within a media stream using scene detection
US8676591B1 (en) 2010-08-02 2014-03-18 Sony Computer Entertainment America Llc Audio deceleration
US8707339B2 (en) * 2010-07-30 2014-04-22 CSC Holdings, LLC System and method for detecting hacked modems
WO2012037165A2 (en) 2010-09-13 2012-03-22 Gaikai, Inc. Add-on management
CN103442774B (zh) 2010-09-13 2016-08-10 索尼电脑娱乐美国公司 双模式程序执行和加载
US8676970B2 (en) * 2010-12-18 2014-03-18 Qualcomm Incorporated Methods and systems for managing device specific content
KR101312268B1 (ko) 2010-12-24 2013-09-25 주식회사 케이티 클라우드 컴퓨팅 환경에서 게임 서비스 제공 방법, 클라우드 컴퓨팅 서버, 및 클라우드 컴퓨팅 시스템
CN108366070A (zh) * 2011-03-16 2018-08-03 韩国电子通信研究院 用于提供媒体内容的方法和客户端
CN102739614B (zh) * 2011-04-07 2015-01-21 奇扬网科股份有限公司 远程影音分享方法
US8990351B2 (en) 2011-04-20 2015-03-24 Mobitv, Inc. Real-time processing capability based quality adaptation
US8171137B1 (en) * 2011-05-09 2012-05-01 Google Inc. Transferring application state across devices
US9553924B1 (en) * 2011-06-13 2017-01-24 Arris Enterprises, Inc. Load sharing among loosely coupled or independent video servers
US9378560B2 (en) 2011-06-17 2016-06-28 Advanced Micro Devices, Inc. Real time on-chip texture decompression using shader processors
EP2755096A4 (en) * 2011-09-05 2014-12-31 Kobayashi Manufacture Co Ltd WORK MANAGEMENT SYSTEM, WORK MANAGEMENT TERMINAL, WORK MANAGEMENT PROGRAM AND METHOD
US9389682B2 (en) * 2012-07-02 2016-07-12 Sony Interactive Entertainment Inc. Methods and systems for interaction with an expanded information space
US20150262208A1 (en) * 2012-10-04 2015-09-17 Bernt Erik Bjontegard Contextually intelligent communication systems and processes
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
US9700789B2 (en) * 2013-03-12 2017-07-11 Sony Interactive Entertainment America Llc System and method for combining multiple game or application views into a single media stream
US9125180B1 (en) 2013-03-15 2015-09-01 Google Inc. Techniques for automatically establishing a long-lasting connection across computing devices configured for short-range wireless communication
JP6225446B2 (ja) * 2013-03-26 2017-11-08 富士通株式会社 動画像データ配信装置、方法、プログラム、及びシステム
GB2514777B (en) * 2013-06-03 2018-12-19 Displaylink Uk Ltd Management of memory for storing display data
US11165842B2 (en) * 2013-10-25 2021-11-02 Louis Gurtowski Selective capture with rapid sharing of user or mixed reality actions and states using interactive virtual streaming
US9641592B2 (en) 2013-11-11 2017-05-02 Amazon Technologies, Inc. Location of actor resources
US9582904B2 (en) 2013-11-11 2017-02-28 Amazon Technologies, Inc. Image composition based on remote object data
US9634942B2 (en) * 2013-11-11 2017-04-25 Amazon Technologies, Inc. Adaptive scene complexity based on service quality
US9374552B2 (en) 2013-11-11 2016-06-21 Amazon Technologies, Inc. Streaming game server video recorder
US9805479B2 (en) 2013-11-11 2017-10-31 Amazon Technologies, Inc. Session idle optimization for streaming server
US9604139B2 (en) 2013-11-11 2017-03-28 Amazon Technologies, Inc. Service for generating graphics object data
US9578074B2 (en) 2013-11-11 2017-02-21 Amazon Technologies, Inc. Adaptive content transmission
JP2015192278A (ja) * 2014-03-28 2015-11-02 ソニー株式会社 画像処理装置および方法
US9842428B2 (en) * 2014-06-27 2017-12-12 Samsung Electronics Co., Ltd. Dynamically optimized deferred rendering pipeline
US10154072B2 (en) * 2014-09-17 2018-12-11 Microsoft Technology Licensing, Llc Intelligent streaming of media content
BE1021350B1 (nl) * 2014-11-26 2015-11-05 ROMAEN Hans en RYCKAERT Peter p/a Acerio BVBA Werkwijze en systeem voor het tonen van een opeenvolging van beelden
US9589543B2 (en) * 2015-03-18 2017-03-07 Intel Corporation Static frame image quality improvement for sink displays
US10554713B2 (en) * 2015-06-19 2020-02-04 Microsoft Technology Licensing, Llc Low latency application streaming using temporal frame transformation
US10405836B2 (en) * 2015-11-23 2019-09-10 Clarius Mobile Health Corp. Speckle reduction and compression improvement of ultrasound images
US9573062B1 (en) * 2015-12-06 2017-02-21 Silver VR Technologies, Inc. Methods and systems for virtual reality streaming and replay of computer video games
US10238965B2 (en) * 2016-04-28 2019-03-26 Sony Interactive Entertainment America Llc Cloud gaming device handover
US10123040B2 (en) * 2016-08-30 2018-11-06 Qualcomm Incorporated Intra-coded video frame caching for video telephony sessions
CN106331823B (zh) * 2016-08-31 2019-08-20 北京奇艺世纪科技有限公司 一种视频播放方法及装置
JP6797755B2 (ja) * 2017-06-20 2020-12-09 キヤノン株式会社 撮像装置、撮像装置の処理方法およびプログラム
US20190082195A1 (en) * 2017-09-08 2019-03-14 Roblox Corporation Network Based Publication and Dynamic Distribution of Live Media Content
US11818401B2 (en) 2017-09-14 2023-11-14 Apple Inc. Point cloud geometry compression using octrees and binary arithmetic encoding with adaptive look-up tables
US10861196B2 (en) 2017-09-14 2020-12-08 Apple Inc. Point cloud compression
US11113845B2 (en) 2017-09-18 2021-09-07 Apple Inc. Point cloud compression using non-cubic projections and masks
US10909725B2 (en) * 2017-09-18 2021-02-02 Apple Inc. Point cloud compression
KR102741389B1 (ko) * 2017-11-16 2024-12-11 인텔 코포레이션 분산형 소프트웨어 정의식 산업 시스템
US10741143B2 (en) * 2017-11-28 2020-08-11 Nvidia Corporation Dynamic jitter and latency-tolerant rendering
EP3766277B1 (en) * 2018-03-12 2024-06-26 Privilege Wireless Llc Method of measuring the quality of service in a wireless communications network
US10867414B2 (en) 2018-04-10 2020-12-15 Apple Inc. Point cloud attribute transfer algorithm
US11262839B2 (en) * 2018-05-17 2022-03-01 Sony Interactive Entertainment Inc. Eye tracking with prediction and late update to GPU for fast foveated rendering in an HMD environment
US11017566B1 (en) 2018-07-02 2021-05-25 Apple Inc. Point cloud compression with adaptive filtering
US11202098B2 (en) 2018-07-05 2021-12-14 Apple Inc. Point cloud compression with multi-resolution video encoding
GB2575463B (en) * 2018-07-10 2022-12-14 Displaylink Uk Ltd Compression of display data
US11012713B2 (en) 2018-07-12 2021-05-18 Apple Inc. Bit stream structure for compressed point cloud data
US11051058B2 (en) * 2018-09-24 2021-06-29 Hewlett Packard Enterprise Development Lp Real-time wireless video delivery system using a multi-channel communications link
US11367224B2 (en) 2018-10-02 2022-06-21 Apple Inc. Occupancy map block-to-patch information compression
US11430155B2 (en) 2018-10-05 2022-08-30 Apple Inc. Quantized depths for projection point cloud compression
US10846249B2 (en) * 2018-10-19 2020-11-24 Oracle International Corporation Bi-directional asynchronous I/O abstraction based upon pair of tightly coupled reactive streams flows
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
CN110113610B (zh) * 2019-04-23 2021-04-20 西安万像电子科技有限公司 数据传输方法及装置
KR102665291B1 (ko) 2019-05-08 2024-05-13 삼성전자 주식회사 전자 장치 및 전자 장치의 제어 방법
US11711544B2 (en) 2019-07-02 2023-07-25 Apple Inc. Point cloud compression with supplemental information messages
CN110324729B (zh) * 2019-07-18 2021-08-27 北京奇艺世纪科技有限公司 一种识别侵权视频链接的方法、装置、电子设备及介质
US11865434B2 (en) 2019-10-01 2024-01-09 Sony Interactive Entertainment Inc. Reducing latency in cloud gaming applications by overlapping receive and decode of video frames and their display at the client
US11524230B2 (en) 2019-10-01 2022-12-13 Sony Interactive Entertainment Inc. Encoder tuning to improve tradeoffs between latency and video quality in cloud gaming applications
US11020661B2 (en) * 2019-10-01 2021-06-01 Sony Interactive Entertainment Inc. Reducing latency in cloud gaming applications by overlapping reception and decoding of video frames and their display
US11395963B2 (en) 2019-10-01 2022-07-26 Sony Interactive Entertainment Inc. High speed scan-out of server display buffer for cloud gaming applications
US11539960B2 (en) 2019-10-01 2022-12-27 Sony Interactive Entertainment Inc. Game application providing scene change hint for encoding at a cloud gaming server
US11895307B2 (en) 2019-10-04 2024-02-06 Apple Inc. Block-based predictive coding for point cloud compression
US11638050B1 (en) * 2019-12-09 2023-04-25 Amazon Technologies. Inc. Managing video encoders utilizing IoT-based communications
US11798196B2 (en) 2020-01-08 2023-10-24 Apple Inc. Video-based point cloud compression with predicted patches
US20230118364A1 (en) * 2020-03-30 2023-04-20 Sony Group Corporation Information processing apparatus and information processing system
CA3174234A1 (en) * 2020-04-03 2021-10-07 Sam SCHWARTZSTEIN Sporting event television broadcast equipment and system
CN111882626B (zh) * 2020-08-06 2023-07-14 腾讯科技（深圳）有限公司 图像处理方法、装置、服务器及介质
US12423415B2 (en) 2020-12-26 2025-09-23 Intel Corporation Dynamic hardware integrity and/or replay protection
CN112788429B (zh) * 2021-02-25 2024-05-14 中国电子科技集团公司第五十二研究所 一种基于网络的屏幕共享系统
US11948338B1 (en) 2021-03-29 2024-04-02 Apple Inc. 3D volumetric content encoding using 2D videos and simplified 3D meshes
US12605625B2 (en) * 2022-10-24 2026-04-21 At&T Intellectual Property I, L.P. Method and apparatus for improving performance of a gaming application
US20240333780A1 (en) * 2023-03-30 2024-10-03 Adeia Guides Inc. Methods and system for improved control of presentation and experiences in video conference

Family Cites Families (497)

* 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
US4582324A (en) 1984-01-04 1986-04-15 Bally Manufacturing Corporation Illusion of skill game machine for a gaming system
US4616263A (en) 1985-02-11 1986-10-07 Gte Corporation Video subsystem for a hybrid videotex facility
US5225904A (en) 1987-10-05 1993-07-06 Intel Corporation Adaptive digital video compression system
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
US6692359B1 (en) 1991-02-15 2004-02-17 America Online, Inc. Method of interfacing on a computer network by visual representations of users, method of interacting and computer network
JPH04275784A (ja) 1991-03-04 1992-10-01 Matsushita Electric Ind Co Ltd 映像信号切り換え装置
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.
US5784631A (en) 1992-06-30 1998-07-21 Discovision Associates Huffman decoder
CA2139861A1 (en) 1992-07-08 1994-01-20 Bernard J. Craig Media server for supplying video and multi-media data over the public telephone switched network
US5845088A (en) 1992-11-16 1998-12-01 Multimedia Systems Corporation Method for the production and transmission of enhanced interactive multimedia information
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.
US6762733B2 (en) 1993-06-24 2004-07-13 Nintendo Co. Ltd. Electronic entertainment and communication system
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 キヤノン株式会社 画像符号化装置及びその方法、並びに画像復号化装置及びその方法
US5434860A (en) 1994-04-20 1995-07-18 Apple Computer, Inc. Flow control for real-time data streams
US5819034A (en) 1994-04-28 1998-10-06 Thomson Consumer Electronics, Inc. Apparatus for transmitting and receiving executable applications as for a multimedia system
US5558339A (en) 1994-05-05 1996-09-24 Perlman; Stephen G. Network architecture to support recording and playback of real-time video games
US5586257A (en) 1994-05-05 1996-12-17 Perlman; Stephen G. Network architecture to support multiple site real-time video games
JPH07319747A (ja) 1994-05-24 1995-12-08 Nec Telecom Syst Ltd データ更新システム
RU2121235C1 (ru) 1994-06-15 1998-10-27 Рка Томсон Лайсенсинг Корпорейшн Устройство для форматирования пакетированного цифрового потока данных, используемого для передачи телевизионной информации
KR100329304B1 (ko) 1994-06-15 2002-10-04 알씨에이 라이센싱 코오포레이숀 텔레비젼정보전달에적합한패킷화한디지털데이터스트림처리시스템
KR0152034B1 (ko) 1994-06-29 1998-10-15 김광호 인트라부호화방법
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
US5712976A (en) 1994-09-08 1998-01-27 International Business Machines Corporation Video data streamer for simultaneously conveying same one or different ones of data blocks stored in storage node to each of plurality of communication nodes
US5608458A (en) 1994-10-13 1997-03-04 Lucent Technologies Inc. Method and apparatus for a region-based approach to coding a sequence of video images
US5654746A (en) 1994-12-01 1997-08-05 Scientific-Atlanta, Inc. Secure authorization and control method and apparatus for a game delivery service
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
JPH08237666A (ja) 1995-02-23 1996-09-13 Toshiba Corp フレーム間帯域圧縮信号処理装置
US5623424A (en) 1995-05-08 1997-04-22 Kabushiki Kaisha Toshiba Rate-controlled digital video editing method and system which controls bit allocation of a video encoder by varying quantization levels
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
JP3519199B2 (ja) 1996-02-06 2004-04-12 株式会社ソニー・コンピュータエンタテインメント 画像生成装置
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
WO1997033402A1 (en) 1996-03-04 1997-09-12 Ericsson Inc. Digital communication system for adapting communications protocol based on a current communication channel condition
US5959592A (en) 1996-03-18 1999-09-28 Echostar Engineering Corporation "IF" bandstacked low noise block converter combined with diplexer
EP0965084A1 (en) 1996-03-21 1999-12-22 MPATH Interactive Inc. Network match maker for selecting clients based on attributes of servers and communication links
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
US5793985A (en) 1996-06-17 1998-08-11 Hewlett-Packard Company Method and apparatus for block-based motion estimation
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
US6014706A (en) 1997-01-30 2000-01-11 Microsoft Corporation Methods and apparatus for implementing control functions in a streamed video display system
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
US6173317B1 (en) 1997-03-14 2001-01-09 Microsoft Corporation Streaming and displaying a video stream with synchronized annotations over a computer network
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
US5884101A (en) 1998-04-17 1999-03-16 I-Cube, Inc. Apparatus for detecting data buffer faults
US6374078B1 (en) 1998-04-17 2002-04-16 Direct Wireless Corporation Wireless communication system with multiple external communication links
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
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
US6202589B1 (en) * 1998-05-29 2001-03-20 Advanced Micro Devices, Inc. Grounding mechanism which maintains a low resistance electrical ground path between a plate electrode and an etch chamber
JP2955561B1 (ja) 1998-05-29 1999-10-04 株式会社ディジタル・ビジョン・ラボラトリーズ ストリーム通信システム及びストリーム転送制御方法
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
JP3413759B2 (ja) 1998-07-17 2003-06-09 株式会社ケンウッド Ｂｓディジタル放送受信機
MXPA01000893A (es) 1998-07-27 2002-06-04 Webtv Networks Inc Acceso remoto a computadora.
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
US6295646B1 (en) 1998-09-30 2001-09-25 Intel Corporation Method and apparatus for displaying video data and corresponding entertainment data for multiple entertainment selection sources
GB2347332B (en) 1998-10-28 2003-07-09 Canon Kk Computer games apparatus
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
US6564380B1 (en) 1999-01-26 2003-05-13 Pixelworld Networks, Inc. System and method for sending live video on the internet
US6577849B1 (en) 1999-02-03 2003-06-10 Motorola, Inc. Method and apparatus for providing additional information about a broadcast
JP3439361B2 (ja) 1999-02-04 2003-08-25 日本電気株式会社 画像符号化装置および動画像伝送システム
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
KR20050044939A (ko) 1999-08-27 2005-05-13 노키아 코포레이션 Ｄｖｂ-ｔ용 이동 멀티미디어 단말기 및 대규모와 소규모셀 통신
US6430233B1 (en) 1999-08-30 2002-08-06 Hughes Electronics Corporation Single-LNB satellite data receiver
US6715145B1 (en) 1999-08-31 2004-03-30 Accenture Llp Processing pipeline in a base services pattern environment
US6205185B1 (en) 1999-09-01 2001-03-20 Sony Corporation Of Japan Self configuring multi-dwelling satellite receiver system
EP1087570B1 (en) 1999-09-22 2009-06-24 Sony Corporation Data transmission with error correction code and effective transmission time
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 シャープ株式会社 衛星放送受信システム、ならびに衛星放送受信システムで用いられるローノイズブロックダウンコンバータおよび衛星放送受信機
RU2159507C1 (ru) 1999-10-29 2000-11-20 Аликов Сергей Владимирович Узел кодирования и/или декодирования информации, система передачи информации с уплотнением каналов, система передачи информации в телекоммуникационной сети
US7028264B2 (en) 1999-10-29 2006-04-11 Surfcast, Inc. System and method for simultaneous display of multiple information sources
US6564003B2 (en) 1999-11-04 2003-05-13 Xm Satellite Radio Inc. Method and apparatus for composite data stream storage and playback
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
US6664969B1 (en) 1999-11-12 2003-12-16 Hewlett-Packard Development Company, L.P. Operating system independent method and apparatus for graphical remote access
CA2391410A1 (en) 1999-12-03 2001-06-07 Ourworld Live, Inc. Consumer access systems and methods for providing same
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
JP2001169281A (ja) 1999-12-13 2001-06-22 Matsushita Electric Ind Co Ltd 動画像符号化装置、および動画像符号化方法
EP1243141B1 (en) 1999-12-14 2011-10-19 Scientific-Atlanta, LLC System and method for adaptive decoding of a video signal with coordinated resource allocation
US20020019984A1 (en) 2000-01-14 2002-02-14 Rakib Selim Shlomo Headend cherrypicker with digital video recording capability
WO2001052093A2 (en) 2000-01-14 2001-07-19 Portable Websites.Com, Inc. Method and apparatus for creating relocatable internet web sites
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
AU2001234463A1 (en) 2000-01-14 2001-07-24 Andrew Corporation Repeaters for wireless communication systems
US20010034788A1 (en) 2000-01-21 2001-10-25 Mcternan Brennan J. System and method for receiving packet data multicast in sequential looping fashion
AU2001231175A1 (en) 2000-01-26 2001-08-07 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 (en) 2000-01-26 2001-08-02 Sony Corporation Data transmission system
KR100677083B1 (ko) 2000-01-27 2007-02-01 삼성전자주식회사 디지털 영상 데이터 통신 시스템에서의 오류 전파 억제를위한 송수신 데이터의 처리 방법 및 이를 위한 기록 매체
WO2001056285A1 (en) 2000-01-27 2001-08-02 Berberet Suzanne M System and method for providing broadcast programming, a virtual vcr, and a video scrapbook to programming subscribers
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
US20010044339A1 (en) 2000-02-17 2001-11-22 Angel Cordero Multi-player computer game, system and method
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 無線中継システム
EP1130839B1 (en) * 2000-03-02 2005-06-08 Matsushita Electric Industrial Co., Ltd. Method and apparatus for retransmitting video data frames with priority levels
US6836658B1 (en) 2000-03-03 2004-12-28 Ems Technologies, Inc. High data rate satellite communications system and method
AUPQ605900A0 (en) 2000-03-06 2000-03-30 Silverbrook Research Pty Ltd Thermal expansion compensation for printhead assemblies
US20010023201A1 (en) 2000-03-08 2001-09-20 Susumu Takatsuka Method of replaying game, recording medium, program, and entertainment system
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
KR100372899B1 (ko) 2000-04-04 2003-02-25 주식회사 게임위즈 인터넷을 통한 게임방송방법 및 그 장치
US6466248B1 (en) 2000-04-05 2002-10-15 Dialogic Corporation Videoconference recording
CA2405433A1 (en) 2000-04-10 2001-10-18 United Video Properties, Inc. Interactive media guide with media guidance interface
US7814208B2 (en) 2000-04-11 2010-10-12 Science Applications International Corporation System and method for projecting content beyond firewalls
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
US6711283B1 (en) 2000-05-03 2004-03-23 Aperio Technologies, Inc. Fully automatic rapid microscope slide scanner
US6873654B1 (en) 2000-05-16 2005-03-29 Redrock Semiconductor, Inc Method and system for predictive control for live streaming video/audio media
AUPQ759700A0 (en) 2000-05-17 2000-06-08 Access Systems Pty Limited Multiplayer gaming
US6699127B1 (en) 2000-06-20 2004-03-02 Nintendo Of America Inc. Real-time replay system for video game
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
EP1182875A3 (en) 2000-07-06 2003-11-26 Matsushita Electric Industrial Co., Ltd. Streaming method and corresponding system
JP2002027483A (ja) 2000-07-11 2002-01-25 Hitachi Ltd 画像符号化装置、画像復号化装置および記憶媒体
US6999432B2 (en) 2000-07-13 2006-02-14 Microsoft Corporation Channel and quality of service adaptation for multimedia over wireless networks
US20020028655A1 (en) 2000-07-14 2002-03-07 Rosener Douglas K. Repeater system
US7571244B2 (en) 2000-07-15 2009-08-04 Filippo Costanzo Audio-video data switching and viewing system
JP3446726B2 (ja) 2000-08-11 2003-09-16 株式会社村田製作所 可動端子、同軸コネクタ及び通信装置
US8932136B2 (en) 2000-08-25 2015-01-13 Opentv, Inc. Method and system for initiating an interactive game
US20020164024A1 (en) 2000-08-25 2002-11-07 Hiroshi Arakawa Data transmission method and data relay method
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 データ通信システム
FI20002129A7 (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
US8678902B2 (en) 2005-09-07 2014-03-25 Bally Gaming, Inc. System gaming
US7904542B1 (en) 2000-10-17 2011-03-08 Sprint Communications Company L.P. Probe device for testing broadband wireless 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
ATE381191T1 (de) 2000-10-26 2007-12-15 Prismedia Networks Inc Verfahren und system zur verwaltung von verteilten inhalten und entsprechenden metadaten
US20020156870A1 (en) 2000-11-08 2002-10-24 Equate Systems, Inc. Method and apparatus for dynamically directing an application to a pre-defined target multimedia resource
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
US20020080267A1 (en) 2000-11-28 2002-06-27 Allan Moluf High capacity, low-latency multiplexer
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
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
CA2432128A1 (en) 2000-12-13 2002-06-20 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
US7139794B2 (en) 2000-12-27 2006-11-21 3-D-V-U Israel (2000) Ltd. System and methods for network image delivery with dynamic viewing frustum optimized for limited bandwidth communication channels
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
CN1167271C (zh) 2001-01-10 2004-09-15 华为技术有限公司 压缩编码图像传输中的误码处理方法
US6761636B2 (en) 2001-01-16 2004-07-13 Fucom Company, Ltd. Real time data exchange system
FI109633B (fi) 2001-01-24 2002-09-13 Gamecluster Ltd Oy Menetelmä videokuvan pakkauksen nopeuttamiseksi ja/tai sen laadun parantamiseksi
US7587520B1 (en) 2001-01-24 2009-09-08 3Dlabs Inc. Ltd. Image display system with visual server
US7155515B1 (en) 2001-02-06 2006-12-26 Microsoft Corporation Distributed load balancing for single entry-point systems
US6868122B2 (en) 2001-02-07 2005-03-15 Sun Microsystems, Inc. Distributed intraframe transmission in digital video compression
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
EP1374430A4 (en) 2001-03-05 2005-08-17 Intervideo Inc SYSTEMS AND METHODS FOR ROBUST ERROR CODING
US6886029B1 (en) 2001-03-13 2005-04-26 Panamsat Corporation End to end simulation of a content delivery system
US6993353B2 (en) 2001-03-14 2006-01-31 At&T Corp. Cable data service method
US7188298B2 (en) 2001-03-14 2007-03-06 Matsushita Electric Industrial Co., Ltd. Error correction encoding and decoding methods and apparatuses for DVI audio data
US7031293B1 (en) 2001-03-26 2006-04-18 Tropos Networks, Inc. Method and system to provide increased data throughput in a wireless multi-hop network
US6475090B2 (en) 2001-03-29 2002-11-05 Koninklijke Philips Electronics N.V. Compensating for network latency in a multi-player game
US20020149617A1 (en) 2001-03-30 2002-10-17 Becker David F. Remote collaboration technology design and methodology
SE521645C2 (sv) 2001-04-11 2003-11-18 Ericsson Telefon Ab L M Metod och mobiltelefon och mobiltelefonsystem som möjliggör paus i fleranvändarspel då telefonsamtal tas emot
US20020154055A1 (en) 2001-04-18 2002-10-24 Robert Davis LAN based satellite antenna/satellite multiswitch
US20020154691A1 (en) 2001-04-19 2002-10-24 Kost James F. System and process for compression, multiplexing, and real-time low-latency playback of networked audio/video bit streams
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
WO2002092177A2 (en) 2001-04-26 2002-11-21 Oy Gamecluster Ltd Method and arrangement for providing an interactive game including three-dimensional graphics
JP4315414B2 (ja) 2001-05-01 2009-08-19 メタ４ハンド インク． 無線ネットワークコンピューティング
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
WO2002093808A2 (en) 2001-05-15 2002-11-21 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
US7272657B2 (en) 2001-07-30 2007-09-18 Digeo, Inc. System and method for displaying video streams ranked by user-specified criteria
US6745364B2 (en) 2001-06-28 2004-06-01 Microsoft Corporation Negotiated/dynamic error correction for streamed media
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
KR100915107B1 (ko) 2001-07-19 2009-09-03 톰슨 라이센싱 에스.에이. 페이드 내성 디지털 송신 및 수신 시스템
US6944785B2 (en) 2001-07-23 2005-09-13 Network Appliance, Inc. High-availability cluster virtual server system
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 データ送受信方法
US6820218B1 (en) 2001-09-04 2004-11-16 Microsoft Corporation Persistent stateful component-based applications via automatic recovery
US6721260B2 (en) 2001-09-04 2004-04-13 Hewlett-Packard Development Company L.P. Electromagnetically controlled drive system and method
JP2003087693A (ja) 2001-09-11 2003-03-20 Sony Corp 情報処理装置および方法、並びにプログラム
US20030048808A1 (en) 2001-09-12 2003-03-13 Stahl Thomas Anthony Method and apparatus for changing received streaming content channels
US7791641B2 (en) 2001-09-12 2010-09-07 Samsung Electronics Co., Ltd. Systems and methods for utilizing activity detection information in relation to image processing
US6910175B2 (en) 2001-09-14 2005-06-21 Koninklijke Philips Electronics N.V. Encoder redundancy selection system and method
JP4852228B2 (ja) 2001-09-26 2012-01-11 インタラクト デヴァイシーズ インコーポレイテッド メディア信号を通信するためのシステム及び方法
US7931533B2 (en) 2001-09-28 2011-04-26 Igt Game development architecture that decouples the game logic from the graphics logics
KR100819493B1 (ko) 2001-09-28 2008-04-07 엘지전자 주식회사 무선랜을 이용한 엠펙 데이터 송수신 장치
US20040192193A1 (en) 2001-10-09 2004-09-30 Silvester Kelan C. Mobile signal relay for cellular transmission in remote areas
US20030079016A1 (en) 2001-10-23 2003-04-24 Sheng (Ted) Tai Tsao Using NAS appliance to build a non-conventional distributed video server
US20030093806A1 (en) 2001-11-14 2003-05-15 Vincent Dureau Remote re-creation of data in a television system
DE60228636D1 (de) 2001-11-21 2008-10-09 Mineral Lassen Llc Zusammenschaltung drahtloser Kommunikationsvorrichtungen
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
US6985753B2 (en) 2001-12-07 2006-01-10 Dashsmart Investments Llc Portable navigation and communication systems
US7020203B1 (en) 2001-12-21 2006-03-28 Polycom, Inc. Dynamic intra-coded macroblock refresh interval for video error concealment
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
WO2003063505A1 (en) 2002-01-23 2003-07-31 Nokia Corporation Grouping of image frames in video coding
US6776715B2 (en) 2002-02-01 2004-08-17 Igt Method and apparatus for providing a personal wide area progressive for gaming apparatus
US20040071083A1 (en) 2002-02-22 2004-04-15 Koninklijke Philips Electronics N.V. Method for streaming fine granular scalability coded video over an IP network
US8972589B2 (en) 2002-03-01 2015-03-03 Enterasys Networks, Inc. Location-based access control in a data network
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
US7085848B2 (en) 2002-03-15 2006-08-01 Microsoft Corporation Time-window-constrained multicast using connection scheduling
US20030181162A1 (en) 2002-03-20 2003-09-25 Michael Matula " Satellite set-top box for mobile applications "
AU2002306998A1 (en) 2002-03-28 2003-10-13 Igt Gaming apparatus with an optical wireless system
US6908390B2 (en) 2002-03-29 2005-06-21 Igt Apparatus and method for a gaming tournament network
GB0208317D0 (en) 2002-04-11 2002-05-22 Koninkl Philips Electronics Nv Controlling a home electronics system
AU2003285850A1 (en) 2002-04-23 2004-04-30 Nokia Corporation Method and device for indicating quantizer parameters in a video coding system
TW578416B (en) 2002-04-26 2004-03-01 Inventec Tomorrow Work Studio Method and system for realizing on-line game
US7010265B2 (en) 2002-05-22 2006-03-07 Microsoft Corporation Satellite receiving system with transmodulating outdoor unit
ES2788534T3 (es) 2002-05-28 2020-10-21 Dolby Int Ab Método y sistemas para la estimación, comunicación y organización de modos de intra-predicción de imágenes
US7023918B2 (en) 2002-05-30 2006-04-04 Ess Technology, Inc. Color motion artifact detection and processing apparatus compatible with video coding standards
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
US7423990B2 (en) * 2002-06-18 2008-09-09 Vixs Systems Inc. Dynamically adjusting data rate of wireless communications
US8370744B2 (en) 2002-06-19 2013-02-05 Microsoft Corporation User interface for operating a computer from a distance
DE60322541D1 (de) 2002-06-21 2008-09-11 Qualcomm Inc Zwischenverstärker für drahtlose lokale netzwerke
EP1376360A3 (en) 2002-06-21 2004-01-07 Sharp Kabushiki Kaisha Automatic backup system
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
KR101150576B1 (ko) 2002-07-29 2012-06-08 콸콤 인코포레이티드 디지털 이미지 인코딩
JP2005534368A (ja) 2002-07-31 2005-11-17 ブルーストリーク テクノロジー インコーポレイテッド ビデオオンデマンドに基づくゲームのためのシステムおよび方法
DE60222890T2 (de) 2002-08-12 2008-02-07 Alcatel Lucent Verfahren und Vorrichtungen zur Implementerung von hochinteraktiven Unterhaltungsdiensten unter Verwendung der Medienströmungstechnologie, das die Bereitstellung auf Abstand von Virtuelle Realitätdiensten ermöglicht
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
JP2004128779A (ja) 2002-10-01 2004-04-22 Sony Corp 放送システム、記録装置、記録方法、プログラム、記録媒体
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
US20040092228A1 (en) 2002-11-07 2004-05-13 Force Charles T. Apparatus and method for enabling use of low power satellites, such as C-band, to broadcast to mobile and non-directional receivers, and signal design therefor
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
US7089319B2 (en) 2002-12-09 2006-08-08 Anton Lysenko Method and system for instantaneous on-demand delivery of multimedia content over a communication network with aid of content capturing component, delivery-on-demand client and dynamically mapped resource locator server
US7165194B2 (en) 2002-12-09 2007-01-16 International Business Machines Corporation Technical support for software products
US9192859B2 (en) * 2002-12-10 2015-11-24 Sony Computer Entertainment America Llc System and method for compressing video based on latency measurements and other feedback
US7684752B2 (en) 2002-12-10 2010-03-23 Onlive, Inc. Wireless network providing distributed video / data services
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
US8979655B2 (en) 2002-12-10 2015-03-17 Ol2, Inc. System and method for securely hosting applications
US8495678B2 (en) 2002-12-10 2013-07-23 Ol2, Inc. System for reporting recorded video preceding system failures
US20060154710A1 (en) 2002-12-10 2006-07-13 Nokia Corporation Method and device for continuing an electronic multi-player game, in case of an absence of a player of said game
US8711923B2 (en) * 2002-12-10 2014-04-29 Ol2, Inc. System and method for selecting a video encoding format based on feedback data
US9077991B2 (en) * 2002-12-10 2015-07-07 Sony Computer Entertainment America Llc System and method for utilizing forward error correction with video compression
US8387099B2 (en) 2002-12-10 2013-02-26 Ol2, Inc. System for acceleration of web page delivery
US8366552B2 (en) * 2002-12-10 2013-02-05 Ol2, Inc. System and method for multi-stream video compression
US7849491B2 (en) 2002-12-10 2010-12-07 Onlive, Inc. Apparatus and method for wireless video gaming
US8949922B2 (en) 2002-12-10 2015-02-03 Ol2, Inc. System for collaborative conferencing using streaming interactive video
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
AU2003300938A1 (en) 2002-12-16 2004-07-29 Widefi, Inc. Improved wireless network repeater
FI116016B (fi) 2002-12-20 2005-08-31 Oplayo Oy Puskurointijärjestely
US7321578B2 (en) 2002-12-31 2008-01-22 Carlos Rios Multiprotocol WLAN access point devices
JPWO2004073269A1 (ja) 2003-02-13 2006-06-01 富士通株式会社 伝送システム，配信経路制御装置，負荷情報収集装置および配信経路制御方法
US7590084B2 (en) 2003-02-14 2009-09-15 Onlive, Inc. Self-configuring, adaptive, three-dimensional, wireless network
US7593361B2 (en) 2003-02-14 2009-09-22 Onlive, Inc. Method of operation for a three-dimensional, wireless network
US7215660B2 (en) 2003-02-14 2007-05-08 Rearden Llc Single transceiver architecture for a wireless network
US20040263626A1 (en) 2003-04-11 2004-12-30 Piccionelli Gregory A. On-line video production with selectable camera angles
US20040207724A1 (en) 2003-04-17 2004-10-21 Siemens Information And Communication Networks, Inc. System and method for real time playback of conferencing streams
US7464319B2 (en) 2003-04-29 2008-12-09 Utah State University Forward error correction with codeword cross-interleaving and key-based packet compression
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
WO2005008419A2 (en) 2003-07-10 2005-01-27 Comcast Cable Holdings, Llc Distributed and scalable architecture for on demand session and resource management
US20050022245A1 (en) 2003-07-21 2005-01-27 Ramesh Nallur Seamless transition between video play-back modes
US20050047496A1 (en) 2003-08-13 2005-03-03 Mcintire William K. Modem with pilot symbol synchronization
CN1256847C (zh) 2003-09-17 2006-05-17 联想(北京)有限公司 动态调整视频传输的方法
US7865907B2 (en) 2003-09-25 2011-01-04 Fisher-Rosemount Systems, Inc. Method and apparatus for providing automatic software updates
IL158158A (en) 2003-09-29 2012-05-31 Bamboo Mediacasting Ltd Distribution of multicast data to users
JP4144749B2 (ja) 2003-10-02 2008-09-03 株式会社リコー 画像圧縮伸長システム、画像圧縮装置、画像伸長装置、画像圧縮方法及び画像伸長方法
US20050105538A1 (en) 2003-10-14 2005-05-19 Ananda Perera Switching system with distributed switching fabric
GB0324627D0 (en) 2003-10-22 2003-11-26 Waterleaf Ltd Redundant gaming system
US7822281B2 (en) 2003-10-31 2010-10-26 Canon Kabushiki Kaisha Digital video compression
US7016409B2 (en) * 2003-11-12 2006-03-21 Sony Corporation Apparatus and method for use in providing dynamic bit rate encoding
US7246183B2 (en) 2003-11-14 2007-07-17 Avocent California Corporation Phase optimization for wireless KVM transmission
US20050111835A1 (en) 2003-11-26 2005-05-26 Friel Joseph T. Digital video recorder with background transcoder
WO2005065085A2 (en) 2003-12-21 2005-07-21 Kremen Stanley H System and apparatus for recording, transmitting, and projecting digital three-dimensional images
US20050183120A1 (en) 2004-01-13 2005-08-18 Saurabh Jain Multi-user personalized digital multimedia distribution methods and systems
JP2007525884A (ja) 2004-01-16 2007-09-06 クリーク コミュニケーションズ エルエルシー 動的に構成された非対称エンドポイント・ビデオ交換のためのシステムおよび方法
TW200537941A (en) 2004-01-26 2005-11-16 Koninkl Philips Electronics Nv Replay of media stream from a prior change location
KR100627500B1 (ko) 2004-03-10 2006-09-21 엘지전자 주식회사 모바일폰의 단문 메시지 제공시스템 및 그 제공방법
KR100550567B1 (ko) 2004-03-22 2006-02-10 엘지전자 주식회사 무선 네트워크망을 통해 통신하는 서버 시스템 및 그동작방법
EP1585060A1 (en) 2004-04-06 2005-10-12 Visiowave S.A. Subband video coding with temporal prediction
EP1585061A1 (en) * 2004-04-07 2005-10-12 Deutsche Thomson-Brandt Gmbh Block adaptive predictive coding
US7222224B2 (en) 2004-05-21 2007-05-22 Rambus Inc. System and method for improving performance in computer memory systems supporting multiple memory access latencies
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
US20050286777A1 (en) 2004-06-27 2005-12-29 Roger Kumar Encoding and decoding images
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 ソニー株式会社 撮像装置及び撮像素子の集積回路
KR100641159B1 (ko) 2004-07-23 2006-11-02 엘지전자 주식회사 Ｒｔｃｐ패킷 기반의 적응적 멀티미디어 데이터 전송률추정방법
US7680904B2 (en) 2004-08-06 2010-03-16 Logic Controls, Inc. Diagnostic method and apparatus for detecting and locating computer network discontinuities
JP2006051251A (ja) 2004-08-13 2006-02-23 Aruze Corp ゲームシステム
CN100362782C (zh) 2004-08-24 2008-01-16 华为技术有限公司 对丢失数据单元进行恢复的方法
US8179962B2 (en) 2004-09-08 2012-05-15 Panasonic Corporation Motion image encoding method and motion image decoding method
US7458894B2 (en) 2004-09-15 2008-12-02 Microsoft Corporation Online gaming spectator system
US8568225B2 (en) 2004-09-16 2013-10-29 Bally Gaming, Inc. User interface system and method for creating and verifying signed content
US8719075B2 (en) 2004-09-23 2014-05-06 Overstock.Com, Inc. System, program product, and methods for online image handling
CN1280310C (zh) 2004-09-29 2006-10-18 清华大学 具有防治流感作用的融合蛋白及其编码基因与应用
US20060069662A1 (en) 2004-09-30 2006-03-30 Citrix Systems, Inc. Method and apparatus for remapping accesses to virtual system resources
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
JP4615958B2 (ja) 2004-10-15 2011-01-19 クラリオン株式会社 デジタル放送の送出装置、受信装置およびデジタル放送システム
JP2007065928A (ja) 2005-08-30 2007-03-15 Toshiba Corp 情報記憶媒体、情報処理方法、情報転送方法、情報再生方法、情報再生装置、情報記録方法、情報記録装置、及びプログラム
US7751324B2 (en) 2004-11-19 2010-07-06 Nokia Corporation Packet stream arrangement in multimedia transmission
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 通信装置および通信方法
WO2006100664A2 (en) 2005-03-21 2006-09-28 Yosef Mizrahi Method, system and computer-readable code for providing a computer gaming service
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
US7680038B1 (en) 2005-04-25 2010-03-16 Electronic Arts, Inc. Dynamic bandwidth detection and response for online games
JP2006304204A (ja) 2005-04-25 2006-11-02 Matsushita Electric Ind Co Ltd 画像処理装置
US8281351B2 (en) 2005-04-29 2012-10-02 Alcatel Lucent System, method, and computer readable medium rapid channel change
US7848409B2 (en) 2005-05-02 2010-12-07 Qualcomm Incorporated Macroblock level bit allocation
US7986335B2 (en) 2005-05-02 2011-07-26 Lifesize Communications, Inc. Set top box videoconferencing system
US20060282855A1 (en) 2005-05-05 2006-12-14 Digital Display Innovations, Llc Multiple remote display system
US20060277248A1 (en) 2005-05-12 2006-12-07 Baxter Eugene E Configuration-based application architecture using XML/XSLT
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
WO2007005911A2 (en) 2005-07-05 2007-01-11 White Technologies Group System for multimedia on demand over internet based network
US7702006B2 (en) 2005-07-05 2010-04-20 Microsoft Corporation Adjustment of transmission data rate based on data errors and/or latency
DE602006015650D1 (de) 2005-07-08 2010-09-02 Tag Networks Inc Videospielsystem mit vorcodierten makroblöcken
US7936819B2 (en) * 2005-07-08 2011-05-03 Tag Networks, Inc. Video encoder with latency control
US9061206B2 (en) 2005-07-08 2015-06-23 Activevideo Networks, Inc. Video game system using pre-generated motion vectors
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 삼성전자주식회사 가변 블록 변환 장치 및 방법 및 이를 이용한 영상부호화/복호화 장치 및 방법
US7965736B2 (en) 2005-08-24 2011-06-21 Qualcomm Incorporated Transmission of multiplex protocol data units in physical layer packets
US7794315B2 (en) 2005-09-09 2010-09-14 Microsoft Corporation Role play system
US20070060259A1 (en) * 2005-09-09 2007-03-15 Joze Pececnik Remote Live Automatic Electro-Mechanical and Video Table Gaming
JP2007080357A (ja) 2005-09-13 2007-03-29 Toshiba Corp 情報記憶媒体、情報再生方法、情報再生装置
EP1768346A1 (en) 2005-09-23 2007-03-28 Microsoft Corporation Provision of game applications across a network according to the display characteristics of a user terminal
US8229983B2 (en) 2005-09-27 2012-07-24 Qualcomm Incorporated Channel switch frame
US20070086528A1 (en) 2005-10-18 2007-04-19 Mauchly J W Video encoder with multiple processors
EP1777966A1 (en) 2005-10-20 2007-04-25 Siemens Aktiengesellschaft, A German Corporation Decomposition of a H.264-decoder on a playstation
US8548048B2 (en) 2005-10-27 2013-10-01 Qualcomm Incorporated Video source rate control for video telephony
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
CN101371312B (zh) * 2005-12-08 2015-12-02 维德约股份有限公司 用于视频通信系统中的差错弹性和随机接入的系统和方法
WO2007070056A1 (en) 2005-12-15 2007-06-21 Thomson Licensing An adaptive joint source and channel coding scheme for h.264 video multicasting over wireless networks
US20070143801A1 (en) 2005-12-20 2007-06-21 Madonna Robert P System and method for a programmable multimedia controller
WO2007073616A1 (en) 2005-12-28 2007-07-05 Intel Corporation A novel user sensitive information adaptive video transcoding framework
US20070156815A1 (en) 2005-12-30 2007-07-05 Nokia Corporation Method, system and entities for multicast content pushing
US7987415B2 (en) 2006-02-15 2011-07-26 Samsung Electronics Co., Ltd. Method and system for application of unequal error protection to uncompressed video for transmission over wireless channels
JP4649615B2 (ja) 2006-02-16 2011-03-16 国立大学法人三重大学 映像符号化、復号化装置および映像符号化、復号化方法、並びにそれらのプログラム
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
WO2007119236A2 (en) 2006-04-13 2007-10-25 Yosef Mizrachi Method and apparatus for providing gaming services and for handling video content
US8777737B2 (en) 2006-04-13 2014-07-15 Igt Method and apparatus for integrating remotely-hosted and locally rendered content on a gaming device
US8582660B2 (en) 2006-04-13 2013-11-12 Qualcomm Incorporated Selective video frame rate upconversion
EP2013987B1 (en) 2006-04-29 2012-12-26 Thomson Licensing Seamless handover of multicast sessions in internet protocol based wireless networks using staggercasting
US20070258527A1 (en) 2006-05-08 2007-11-08 Centillium Communications, Inc. Fast Dynamic Noise Detection/Adaptation System For DSL Modems
US20070265094A1 (en) 2006-05-10 2007-11-15 Norio Tone System and Method for Streaming Games and Services to Gaming Devices
JP2008005112A (ja) 2006-06-21 2008-01-10 Matsushita Electric Ind Co Ltd ストリームエンコーダ及びストリームデコーダ
US7841946B2 (en) * 2006-06-29 2010-11-30 Spawn Labs, Inc. System for remote game access
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
JP2008033652A (ja) 2006-07-28 2008-02-14 Nec Infrontia Corp クライアント・サーバ型分散システム、クライアント装置、サーバ装置及びそれらに用いる相互認証方法
US20080092172A1 (en) 2006-09-29 2008-04-17 Guo Katherine H Method and apparatus for a zooming feature for mobile video service
US9697019B1 (en) 2006-10-17 2017-07-04 Manageiq, Inc. Adapt a virtual machine to comply with system enforced policies and derive an optimized variant of the adapted virtual machine
US20080101455A1 (en) 2006-10-25 2008-05-01 Digital Deck, Inc. Apparatus and method for multiple format encoding
US20100227691A1 (en) * 2006-10-27 2010-09-09 Cecure Gaming Limited Online gaming system
US20080115185A1 (en) 2006-10-31 2008-05-15 Microsoft Corporation Dynamic modification of video properties
US8711929B2 (en) 2006-11-01 2014-04-29 Skyfire Labs, Inc. Network-based dynamic encoding
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
US8978085B2 (en) * 2006-12-28 2015-03-10 General Instrument Corporation Return data path in an HFC network
CN101212459B (zh) 2006-12-28 2012-08-08 华为技术有限公司 控制媒体编码速率的方法、系统和设备
US20080220878A1 (en) 2007-02-23 2008-09-11 Oliver Michaelis Method and Apparatus to Create or Join Gaming Sessions Based on Proximity
RU2336659C1 (ru) 2007-03-06 2008-10-20 Виктор Владимирович Степанов Система видеонаблюдения высокого разрешения
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
US20080263621A1 (en) 2007-04-17 2008-10-23 Horizon Semiconductors Ltd. Set top box with transcoding capabilities
EP2142977A4 (en) 2007-05-02 2010-05-19 Google Inc USER INTERFACES FOR WEB-BASED VIDEO PLAYER
US20080288983A1 (en) 2007-05-18 2008-11-20 Johnson Bradley G System and Method for Providing Sequential Video and Interactive Content
US7995478B2 (en) 2007-05-30 2011-08-09 Sony Computer Entertainment Inc. Network communication with path MTU size discovery
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
JP5075536B2 (ja) 2007-09-03 2012-11-21 株式会社東芝 Ｆｅｃ送信処理装置、ならびにｆｅｃ送信処理のための方法およびプログラム
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
US9498714B2 (en) 2007-12-15 2016-11-22 Sony Interactive Entertainment America Llc Program mode switching
US9211473B2 (en) 2008-12-15 2015-12-15 Sony Computer Entertainment America Llc Program mode transition
US8613673B2 (en) 2008-12-15 2013-12-24 Sony Computer Entertainment America Llc Intelligent game loading
US8050289B1 (en) 2008-02-01 2011-11-01 Zenverge, Inc. Media transmission using aggregated bandwidth of disparate communication channels
US20090300701A1 (en) 2008-05-28 2009-12-03 Broadcom Corporation Area of interest processing of video delivered to handheld device
US7953881B1 (en) 2008-06-12 2011-05-31 Juniper Networks, Inc. Network characteristic-based compression of network traffic
US8874661B2 (en) 2008-08-07 2014-10-28 Microsoft Corporation Method and system providing spectator information for a multimedia application
CN101359981B (zh) 2008-09-27 2011-05-11 腾讯科技（深圳）有限公司 一种数据包冗余编解码的方法、装置及系统
US8254704B2 (en) 2008-10-30 2012-08-28 Microsoft Corporation Remote computing platforms providing high-fidelity display and interactivity for clients
US8423071B1 (en) 2008-11-25 2013-04-16 Sprint Communications Company L.P. Resuming media objects delivered via live streaming services upon data reduction events
TWI387317B (zh) 2008-12-11 2013-02-21 Novatek Microelectronics Corp 產生重新取樣參考畫面之裝置及其方法與影像解碼系統
US8926435B2 (en) 2008-12-15 2015-01-06 Sony Computer Entertainment America Llc Dual-mode program execution
US8209430B2 (en) 2009-03-27 2012-06-26 Wyse Technology Inc. Apparatus and method for remote communication and bandwidth adjustments
US9508219B2 (en) 2009-04-03 2016-11-29 Bally Gaming, Inc. Dynamic management of wagering game availability
US9723319B1 (en) 2009-06-01 2017-08-01 Sony Interactive Entertainment America Llc Differentiation for achieving buffered decoding and bufferless decoding
GB2485687B (en) 2009-06-01 2017-11-01 Sony Computer Entertainment America Llc Game execution environments
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
CN103442774B (zh) 2010-09-13 2016-08-10 索尼电脑娱乐美国公司 双模式程序执行和加载
WO2012037165A2 (en) 2010-09-13 2012-03-22 Gaikai, Inc. Add-on management

Also Published As

Publication number Publication date
KR101788330B1 (ko) 2017-10-19
EP2412159A1 (en) 2012-02-01
MX2011009972A (es) 2012-03-29
US20160236083A1 (en) 2016-08-18
US9314691B2 (en) 2016-04-19
NZ595840A (en) 2013-07-26
US9643084B2 (en) 2017-05-09
CA2756299A1 (en) 2010-09-30
WO2010111096A1 (en) 2010-09-30
US20100166063A1 (en) 2010-07-01
IL215309A0 (en) 2011-12-29
SG10201400860XA (en) 2014-07-30
TW201119401A (en) 2011-06-01
JP2012521721A (ja) 2012-09-13
RU2011142769A (ru) 2013-04-27
KR20110132608A (ko) 2011-12-08
CN102428698A (zh) 2012-04-25
SG174544A1 (en) 2011-10-28
AU2010229092A1 (en) 2011-11-10
US9968847B2 (en) 2018-05-15
TWI558109B (zh) 2016-11-11
US20170239566A1 (en) 2017-08-24

Similar Documents

Publication Publication Date Title
US11336926B2 (en) System and method for remote-hosted video game streaming and feedback from client on received frames
BRPI1012236A2 (pt) Sistema e método para compressão de quadros de vídeo ou partes dos mesmos com base em informação de retorno de um dispositivo cliente
JP5568628B2 (ja) 複数のエンコーディングフォーマットを使用するマルチストリームビデオ圧縮のためのシステム及び方法
KR101757485B1 (ko) 가속 머신 스위칭을 위한 시스템 및 방법
CN101918934B (zh) 用于加速网页传送的系统
JP5677093B2 (ja) システム故障の前の記録されたビデオを報告するシステム
CN101918937B (zh) 使用流动互动式视频的用于合作会议的系统
CN101897183B (zh) 将线性内容与压缩后的交互式内容一起组合为流动交互式视频的方法
TWI459215B (zh) 用於將程式碼及資料儲存於應用程式主機代管中心內之系統及方法
TWI399982B (zh) 用以壓縮串流互動視訊之系統
TWI536804B (zh) 基於通信頻道之已偵測之資料速率以壓縮視訊的系統及方法
BRPI1012335B1 (pt) Sistema e método para selecionar um formato de codificação de vídeo baseado em informação de retorno
BRPI1012245B1 (pt) Método implementado por computador e meio legível por máquina para realizar compressão de vídeo
BRPI1012320B1 (pt) método, sistema e meio legível por máquina para compressão de vídeo usando retorno incluindo dados relacionados à recepção com sucesso do conteúdo de vídeo
BRPI1012235B1 (pt) Método implementado por computador para realizar compressão de vídeo
BRPI1012337B1 (pt) método implementado em computador para transmitir vídeo continuamente
BRPI1012243A2 (pt) sistema e método para compressão de vídeo multi-fluxo
BRPI1012339B1 (pt) método implementado por computador para transmitir vídeo continuamente a partir de um servidor para um cliente, e sistema para hospedar vídeo games ou aplicativos interativos de transmissão contínua de baixa latência
BRPI1107030A2 (pt) Sistema e método para efeitos de vídeo hospedados remotos
CN101918936A (zh) 流动交互式视频客户端装置
CN101918957A (zh) 用于保护通过通信信道传输的特定类型的多媒体数据的系统和方法
CN101889442A (zh) 用于结合多个实时流动互动式视频的视图的系统
CN101889274A (zh) 使用流动互动式视频来主机代管和广播虚拟事件
CN101918933A (zh) 用于智能地将客户端请求分配到服务器中心的系统和方法
CN101918958A (zh) 基于检测的帧内运动的用于压缩视频的系统及方法

Legal Events

Date Code Title Description
B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B15K Others concerning applications: alteration of classification

Free format text: A CLASSIFICACAO ANTERIOR ERA: H04N 7/12

Ipc: H04N 19/107 (2014.01), H04N 19/169 (2014.01),?...!

Free format text: A CLASSIFICACAO ANTERIOR ERA: H04N 7/12

Ipc: H04N 19/107 (2014.01), H04N 19/169 (2014.01),[...]

B25A Requested transfer of rights approved

Owner name: INSOLVENCY SERVICES GROUP, INC. (US)

B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B25A Requested transfer of rights approved

Owner name: OL2, INC. (US)

B07A Application suspended after technical examination (opinion) [chapter 7.1 patent gazette]
B07B Technical examination (opinion): publication cancelled [chapter 7.2 patent gazette]
B06A Patent application procedure suspended [chapter 6.1 patent gazette]
B11B Dismissal acc. art. 36, par 1 of ipl - no reply within 90 days to fullfil the necessary requirements