Em teoria: É assim que o OnLive funciona?

Após a sensacional - e controversa - estreia na GDC do ano passado, pouco se ouviu à cerca do sistema de jogos em "cloud" OnLive. Durante o verão, a companhia lançou a fase de assinatura para a prometida beta, mas num mundo onde as fugas de informação das betas acontecem em poucas horas, a falta de um feedback parece nos dizer. Estará OnLive dentro do prazo? Na véspera de Natal, o momento escolhido: os beta testers de OnLive finalmente mostraram coisas, e uma enorme apresentação de 48 minutos do homem da frente da companhia foi mostrada.

Num espaço pequeno e intimista, os alunos da Columbia University, tinham um browser do OnLive ligado e uma micro-consola, apresentado o que equivale a uma re-apresentação mais informal da apresentação original na GDC do ano passado - na maioria sendo a mesma tecnologia, e foram mostrados as mesmos demos. Surgiram mais detalhes sobre a tecnologia, e o Perlman produziu uma deliciosa apresentação de Crysis a correr através do OnLive sobre o iPhone. As questões chave que muitos comentadores falaram como sendo um problema(latência e compressão de vídeo) também foram abordadas, ainda que de uma maneira extremamente vaga.

Assim, as grandes questões permanecem: em particular, como é que o OnLive compacta o vídeo? O Perlman sugere que OnLive criou um compressor de vídeo novo, que rompe com as convenções de uma codificação de vídeo normal: o chamado grupo de imagens (group of pictures - GOP). O GOP em suma é sobre reter e re-utilizar o maior número de informações de vídeo possíveis para reconstruir o frame actual. Elementos da imagem podem ser trazidos do passado ou futuros frames para garantir a mais alta compressão possível. Mas o OnLive tem um problema. Pegar nos elementos para frames futuros irá necessitar de os transmitir e isso introduz lag, o que ficava acima do tempo necessário para transmitir as informações através da internet, bem como a latência inerente ao jogo.

O Perlman disse que o OnLive não usa o GOP, e usa um sistema de compressão proprietária. O Jason Garrett-Glaser, um dos produtores chave do sistema de codificação usado em toda a indústria, o open-source x264 / h264, e muito bem relacionado, afirma o contrário.

"Tanto quanto sei, o OnLive está apenas a usar o H264, de modo que isto não é realmente a 'nova e alternativa' categoria, que ele escreveu no fórum Doom9 sob o seu apelido online, Dark Shikari. "A 'nova ideia' que eles falam, é dividir o fluxo em 16 fatias rectangulares, onde cada uma recebe o seu próprio codificador. Essa ideia brilhante, reduz maciçamente a compressão nas bordas entre as fatias quando a cena está em movimento e que os permite gabarem-se de uma latência 16 vezes inferior o que eles realmente têm."

O processo de cortar a imagem em pedaços e paralelizar a codificação de toda a imagem já é suportada pelas especificações do H264. Para muitos descodificadores por segmentação, tais como o que está dentro da PS3, o uso de fatias torna muito mais rápido para a reprodução de conteúdos desafiantes (por exemplo, o vídeos de WipEout HD 1080p60). No entanto, o Garrett-Glaser sugere que OnLive está fisicamente a cortar cada imagem em 16 pedaços e enviá-los para 16 codificadores independentes diferentes.

"Com as fatias, cada fatia pode ligar as informações em qualquer lugar do frame anterior", diz Garrett-Glaser. "Isso significa que, se algo se move da fatia A para a fatia B, não há problema: Uma fatia A pode apontar para ele com um vector de movimento como que se ela não cruzasse a borda. Mas o OnLive não está a usar as fatias: eles estão a codificar o vídeo como um monte de fluxos distintos. Estes fluxos estão completamente separados, e assim cada fluxo não consegue transmitir dados para os outros fluxos. Então, se algo atravessa a borda de uma fatia, não pode ser referenciado correctamente! Este efeito é normalmente bastante pequeno, pois ele apenas afecta as bordas do frame, mas com o método OnLive, ele afecta cerca de oito vezes o número de macro-blocos do que deveria, porque afecta ambos os lados das fronteiras da fatia em oposição em apenas às bordas do frame."

Mas é claro, que se ele faz o trabalho pedido e o faz bem, tentar saber qual o sistema de compressão e como ele funciona é algo irrelevante. Isso faz com que seja visível, e então a lag, como mencionado no artigo original, se aceitares uma certa quantidade de "perdas", que não combinam muito bem com todas as alegações da empresa, o OnLive irá passar de algo completamente fantástico, a algo muito real. Uma boa referencia é o Gaikai de David Perry. Não existe nada de absolutamente ultrajante em termos técnicos na apresentação de Perry em termos de frame-rate e os valores de largura de banda. Se aumentares a resolução e mantiveres os 30FPS, o nível de rendimento do OnLive 5Mbps para 720p com som surround 5.1 parece ser algo razoável.

Então, como é a qualidade da imagem? Um beta tester animado quebrou o seu NDA por mostrar a efectuar o download de um plug-in de 1MB para o seu browser e colocou estas imagens de Crysis, fazendo um bom trabalho por mostrar como o OnLive olha para o que parece ser em óptimas condições. Elas podem ser falsificadas, mas parece improvável tendo em conta como as configurações do Crysis parecem corresponder com as demos anteriores do OnLive.