Faut voir comment ça fonctionne. Déjà, on peut supposer que ce sera limité à du 30ips, sans quoi les besoins en bande-passante seraient énormes. Ensuite, hors de question de re-calculer l'image à chaque fois façon VNC ou serveur X, ce qui n'aurait aucun intérêt puisque ça reviendrait à déporter le moteur graphique sur la machine du client.
Donc soit envoyer les images une par une, ce qui là encore serait trop gourmant en bande-passante, ou sinon, en vidéo.
Dans tous les cas, une compression de l'image, ça veut dire un temps de calcul avant l'envoi pour encoder, le temps de l'envoi, et le temps du décodage. Si on ne fait pas du image par image, mais de la vidéo avec images-clé et images P/B calculées à partir de la différence, le temps d'encodage/décodage s'accroît encore, et plus la compression sera de qualité, plus celle-ci prendra du temps.
À titre d'exemple, entre la TNT encodée numériquement et l'hertzien analogique, il y a 3 secondes de décalage, et 4 secondes supplémentaires pour la TNT HD (temps calculé à l'instant avec les différentes versions de M6 et ma montre
) alors que c'est peu ou prou le même vecteur de diffusion : l'antenne.
Il n'y aura certes pas de lag entre les différents joueurs, mais entre l'état de l'action tel qu'il est vu par le joueur, l'état de l'action sur le serveur, l'état de l'action une fois que le serveur a reçu les commandes du joueur (en considérant bien sûr qu'il n'y a pas d'acquittement pour la vidéo, qui boufferait inutilement de la bande-passante en envoi), il y a de quoi se retrouver avec un certain merdier.
La compression/décompression devra donc être ultra-rapide, ce qui veut dire soit crade, soit gourmande en bande-passante, soit ultra-mega révolutionnaire, à enterrer le BluRay et le MPEG-4. Au fait, ai-je dit qu'avec ses mouvements constants et imprévisibles, cumulés aux contrastes importants qu'on y trouve souvent, le jeu vidéo était un cauchemar pour la compression vidéo ?
Après, si ce procédé me permet de jouer à DukeNukem Forever sur mon Mac avec CG intégrée à la carte-mère, j'en serai le premier ravi. Qui sait, on aura peut-être même la sortie simultanée ?
Donc soit envoyer les images une par une, ce qui là encore serait trop gourmant en bande-passante, ou sinon, en vidéo.
Dans tous les cas, une compression de l'image, ça veut dire un temps de calcul avant l'envoi pour encoder, le temps de l'envoi, et le temps du décodage. Si on ne fait pas du image par image, mais de la vidéo avec images-clé et images P/B calculées à partir de la différence, le temps d'encodage/décodage s'accroît encore, et plus la compression sera de qualité, plus celle-ci prendra du temps.
À titre d'exemple, entre la TNT encodée numériquement et l'hertzien analogique, il y a 3 secondes de décalage, et 4 secondes supplémentaires pour la TNT HD (temps calculé à l'instant avec les différentes versions de M6 et ma montre

Il n'y aura certes pas de lag entre les différents joueurs, mais entre l'état de l'action tel qu'il est vu par le joueur, l'état de l'action sur le serveur, l'état de l'action une fois que le serveur a reçu les commandes du joueur (en considérant bien sûr qu'il n'y a pas d'acquittement pour la vidéo, qui boufferait inutilement de la bande-passante en envoi), il y a de quoi se retrouver avec un certain merdier.
La compression/décompression devra donc être ultra-rapide, ce qui veut dire soit crade, soit gourmande en bande-passante, soit ultra-mega révolutionnaire, à enterrer le BluRay et le MPEG-4. Au fait, ai-je dit qu'avec ses mouvements constants et imprévisibles, cumulés aux contrastes importants qu'on y trouve souvent, le jeu vidéo était un cauchemar pour la compression vidéo ?
Après, si ce procédé me permet de jouer à DukeNukem Forever sur mon Mac avec CG intégrée à la carte-mère, j'en serai le premier ravi. Qui sait, on aura peut-être même la sortie simultanée ?

Commentaire