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á é suportado 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.
Embora a natureza estática das imagens pouco testa o algoritmo de codificação, não há como negar que o OnLive corre de forma respeitável o Crysis.
As primeiras impressões são promissoras. Existem artefactos de compressão óbvios na folhagem de fundo e as cores parecem "sem vida" (o streaming de vídeo corre numa precisão mais baixa de pixeis por isso isto é esperado). O facto é que a pessoas que quebrou o NDA, escolheu tirar imagens de cenas completamente quase estáticas, o que significa que o codificador não está a ser puxado ao máximo. Não estamos a ver o Onlive em situações desafiantes, mas o que aponta para um melhor cenário – os beta testers falaram de um borrão que acompanha a filmagem em movimento. Num pensamento à parte, estas fotos não nos permitem confirmar que a imagem nativa é de 720p.
Num outro lado, afirmar que vai ser possível correr Crysis nas configurações máximas no Onlive não é bem verdade: tendo passado algum tempo com o jogo recentemente, a falta de definição nas texturas e iluminação sugerem que as configuração estão a nível médio. Para ser honesto, isto é provavelmente para o melhor. Mais detalhes significa mais pressão no codificador, e se detalhes finos forem perdidos no processo de codificação, existe um forte argumento que sugere que renderiza-lo em primeiro lugar não é uma boa ideia.
Tudo isto sugere que o Onlive tem lugar como um servidor de jogabilidade baixa/média, mas não o substituto do PC/consolas que tem dito ser. Mas claro que tudo isto depende na definição de "Baixo/médio". Para nós, jogadores exigentes acostumados a uma jogabilidade HD, a inevitável variação na qualidade de imagem e latência no conceito e tecnologia, põe o Onlive em desvantagem, mas e num ambiente típico de sala de estar? Sentados 3 metros da televisão, será que esta compressão importa tanto? Será que um jogador casual dará importância há existência de lag nos controlos?
A demonstração do Perlman mostra algumas novas possibilidades intrigantes – especificamente a noção da transmissão de jogabilidade a potenciais centenas de milhares de espectadores sobre IP. Para alcançar isto ele fala sobre dois níveis de codificação: o primeiro sendo o link directo ao jogador (a explicação de Jason Garrett-Glaser faz muito sentido no que se tem visto até agora, e pode ser testada quando a transmissão directa de vídeo de alta qualidade estiver disponível), o segundo stream está dedicado para a media e outras características da transmissão. Presumivelmente, esta é uma saída de banda larga da máquina hospedeira que pode depois ser re-codificada outra vez para serem enviadas para qualquer pessoa, se esta estiver a usar HD, SD ou até feeds móveis.
Não existe nada que não seja plausível neste conceito e o potencial é mesmo extraordinário. As produtoras de jogos com software em estado beta conseguem ver exactamente como é que jogo está a ser jogado e que problemas causa. Conseguem mesmo identificar partes do design do jogo que não funcionam como deviam através de ver os jogadores a desfrutarem o jogo, e usar isso como uma base para melhorarem o seu trabalho. Espectadores podem observar jogadores peritos e ver como progredir em áreas manhosas do jogo. Os jogadores podem salvar até clips de 15 segundos para partilharem com os amigos, os chamados "Brag Clips" que são também derivados desta media de stream.
Tendo a habilidade de alcançar isto com jogabilidade em vídeo e distribuir-lo em qualquer PC, MAC ou até telemóveis seleccionados demonstra como este conceito traz algo de novo para os jogos, e que provavelmente veremos algo semelhante na PSN e Xbox Live em algum ponto no futuro. Seria algo muito impressionante ver o Onlive integrar características como estas fora do seu ecossistema (por exemplo, os fóruns ou o Facebook).
A nossa resposta inicial ao Onlive após a GDC do ano passado foi contestar as alegações e as capacidades técnicas que rodeavam a estreia. Neste respeito, algumas coisas não mudaram. Ao ver o último vídeo da Universidade Columbia sentimos que ainda precisa de um exercício em filtrar as coisas que simplesmente não fazem sentido (num certo ponto, quando questionado sobre o algoritmo da compressão, Perlman chama-o literalmente "um conjunto de matemáticas") numa tentativa para conseguir alcançar o "coração" da tecnologia e o que realmente representa para os jogadores.
O exemplo do Perlman dos 80ms de latência do pressionar de um botão para a acção no ecrã, ainda não encaixa bem num mundo onde o Call of Duty 4 faz o update a 66ms locally quando está a correr em óptimas condições. Transmissão, recepção, codificação e descodificação em 14ms em cima da latência do controlador é inacreditável, e ainda não está claro se o Onlive está previsto alcançar os 60FPS ou não – o assunto parecia ausente na última apresentação de Perlman.
Ironicamente, a credibilidade do Onlive tem mais impulso que a equipa do Gaikai: não existe compreensão sobre a compressão do esquema, sobre o consumo da largura de banda figura directamente no ecrã, nenhuma conversa sobre codificadores a 1ms que ultrapassam a melhor performance que a indústria tem para oferecer, e nenhuma sugestão de um substituto para as consolas de experiência a 720p60. Se colocarmos as apresentações de Perry e Perlman lado-a-lado, se colocarmos o factor da largura de banda extra que o Onlive usa e retiramos o factor da conversa de marketing, de repente o Onlive parece uma proposta menos fantástica.
Aqui para nós, já ouvimos os beta testers a levantar questões sobre a latência, e se a qualidade da imagem é boa o suficiente, há ainda uma enorme quantidade de incertezas sobre a disponibilidade do servidor e como as escalas de serviço funcionam, quando a carga aumentar exponencialmente à medida que mais utilizadores querem participar. Mas aqui e agora, as porcas e os parafusos do sistema estão a trabalhar fora das condições de demos controladas pelo Onlive, apesar dos NDA, detalhes e experiências a emergir. No entanto, o desempenho de muitas alegações do Onlive continuam por verificar...
