Auteur Sujet: Code Shadow (Lu 60537 fois)

underground78 · « **Réponse #84 le:** 21 décembre 2016 à 15:15:50 »

Il me semble qu'ils en parlent quelque part de ça. Bien sûr c'est pour t'expliquer pourquoi en fait c'est moins important que ce qu'on pourrait croire mais j'avoue avoir eu la flemme de vérifier si l'argumentaire était crédible.

e-TE · « **Réponse #85 le:** 21 décembre 2016 à 16:29:01 »

Citation de: Nico le 21 décembre 2016 à 14:20:00

J'avais parlé d'Onlive ici :

pour le coup, je m’étais cantonné a des jeux solos (just cause 2 principalement), et les problèmes réseau était plutot bien compensé par la baise en direct de la qualité video (kit à avoir un tas de pixel

) mais j'avais pas besoin de réflexe de fou donc c'était globalement satisfaisant... après, j'avais eu les jeux gratuitement donc je n'avais pas non plus le même niveau d'attente que si j'avais payé pour le service!

hate de voir IRL comment va se passer codeshadow malgré tout les raccourcis fait sur le fonctionnement

BadMax · « **Réponse #86 le:** 21 décembre 2016 à 16:29:44 »

Citation de: mattmatt73 le 21 décembre 2016 à 14:55:44

Si je peux être là, pourquoi pas. Mais un test intéressant serait toi sur place et moi à Lyon ou quelqu'un plus loin encore.
De toutes façons, vu que vous en êtes aux lois physiques, si on part sur 50 images secondes, ça fait 20ms l'image (ce coup-ci on est encore plus ambitieux mathématiquement avec la division).

En partant sur des gros débits permettant du gop court ou codage intra, celà veux dire que l'on prend une image au codage de délai et une au décodage. Je vous laisse calculer le délai

Attention on parle là de MJPEG 2000 et consorts, donc pour de la HD, ça sort à 80/120Mb/s
pour des débits plus faible, on est très souvent plus loin en délai.

Je pense pas qu'on puisse résumer le flux envoyé à un simple flux vidéo : c'est un peu comme Microsoft RDP, tu ne mets à jour que le nécessaire, ce n'est pas un flux vidéo, l'écran déporté est une extension des directives d'affichages du point de vue système.

La carte graphique (note: c'est du spécifique, c'est le modèle GRID chez NVidia) met en forme les données à afficher suivant un format propriétaire et n'a sans doute recours qu'à une compression basique (un peu comme la compression de texture S3TC qui existe depuis +10ans et qui permettait déjà de décompresser des textures à la volée par le GPU).

https://developer.nvidia.com/grid-app-game-streaming

Néanmoins afficher un timecode avec une référence d'horloge précise (attention, un simple GPS n'est pas suffisant, il faut une source capable de fournir un signal PPS de qualité) et comparer entre la source et la réception est une bonne idée pour mesurer réellement la latence.

David75 · « **Réponse #87 le:** 21 décembre 2016 à 20:16:46 »

Attention qu'ils ne disent pas que c'est la gestion du time code qui explique la latence supplèmentaire par rapport à leur modèle théorique

mattmatt73 · « **Réponse #88 le:** 21 décembre 2016 à 21:16:46 »

Citation de: BadMax le 21 décembre 2016 à 16:29:44

c'est un peu comme Microsoft RDP, tu ne mets à jour que le nécessaire, ce n'est pas un flux vidéo,

et le MPEG ainsi que les codecs vidéo un tantinet sérieux, ils se pignolent en se faisant gratiner une tartiflette ?

Gop et compression inter images, ça ne sert pas à ma connaissance à vidanger une R25 chamonix avec sièges en velours côtelés.

edit : je ne sais plus si la r25 à sièges en velours côtelés n'était pas une édition val d'isère

vivien · « **Réponse #89 le:** 21 décembre 2016 à 21:20:33 »

Effectivement si on parle sur une transmission de la vidéo classique, le MJPEG s'impose.

Je revois mes slides quand j'étais à la RATP (en 2002), où la latence est très importante pour les caméra de surveillance. I était pour cette raison impossible d'utiliser du MPEG-2.

Le MJPEG consomme 8 Mb/s pour un flux SD...

La latence réseau est effectivement négligeable...

mattmatt73 · « **Réponse #90 le:** 21 décembre 2016 à 21:41:31 »

Citation de: vivien le 21 décembre 2016 à 21:20:33

Effectivement si on parle sur une transmission de la vidéo classique, le MJPEG s'impose.

Je revois mes slides quand j'étais à la RATP (en 2002), où la latence est très importante pour les caméra de surveillance. I était pour cette raison impossible d'utiliser du MPEG-2.

Le MJPEG consomme 8 Mb/s pour un flux SD...

La latence réseau est effectivement négligeable...

maintenant en mjpeg ou mpeg2000 ou mpeg intra, tu peux descendre à 1 image codage et 1 pour le décodage, soit en 50i, 40ms

vivien · « **Réponse #91 le:** 21 décembre 2016 à 21:52:56 »

Là tu ne prend pas en compte le délai pour faire la compression ?

Si on part sur le fait qu'une image est compressé pendant que la suivant est en acquisition, cela 40ms (acquisition image) + 40ms (compression) + 1ms (réseau) + 40ms décompression = 121ms en 25 images/seconde progressif.

Attention à la latence réseau : ce n'est pas la même entre un paquet de 50 octets et une image de 40Ko (poids d'une image SD à la RATP : 40 * 25 = 1 Mo/s = 8 Mb/s). Le temps mis sera plus long avec une interface 10 Mb/s vs 100 Mb/s, mais c'est vrai que cela reste négligeable.

BadMax · « **Réponse #92 le:** 21 décembre 2016 à 22:27:11 »

Citation de: mattmatt73 le 21 décembre 2016 à 21:16:46

et le MPEG ainsi que les codecs vidéo un tantinet sérieux, ils se pignolent en se faisant gratiner une tartiflette ?

Gop et compression inter images, ça ne sert pas à ma connaissance à vidanger une R25 chamonix avec sièges en velours côtelés.

edit : je ne sais plus si la r25 à sièges en velours côtelés n'était pas une édition val d'isère

Une session RDP peut se contenter d'une centaine de kbits/s : essaye donc en MPEG

C'est 2 utilisations différentes, d'ailleurs afficher une vidéo en RDP est affreusement moche, ça sacade, ça vomit, même sur du LAN Gb. Par contre, tu peux utiliser une session web ou faire de la bureautique.

hwti · « **Réponse #93 le:** 22 décembre 2016 à 05:29:00 »

Les délais dépendent beaucoup de comment l'image rendue est capturée, si le vsync est bien désactivé à la source (aucune raison d'attendre un "écran" virtuel, si les API le permettent on peut compresser et envoyer au plus vite), ...
Même si on reste assez loin de l'affichage local en vsync off (ou des G-Sync, FreeSync, moniteurs 120/144 Hz, ...), une solution optimisée peut en local faire mieux que qu'un affichage classique en vsync en double ou triple buffer à 60Hz, en prenant des raccourcis par rapport au pipeline de rendu classique de DirectX sous Windows.
http://www.hardware.fr/articles/950-5/mesures-latence.html

L'article indique que les solutions de streaming local utilisent du H264 sans B-frames, donc effectivement une fois qu'une image est rendue elle peut être compressée immédiatement.
Il est question de 30Mbps pour du 1080p60, et 100Mpbs en mode "illimité".

Si Code Shadow a une solution similaire à Nvidia+Steam Link, alors le résultat peut être correct si la latence réseau (aller pour les contrôles, et retour pour les images) est maîtrisée et les débits offerts assez élevés (et sans saturation), mais il faut voir en pratique.
En revanche, je suis sceptique sur la possibilité de monter en 1080p120/140 comme annoncé : il faudrait un gros bitrate pour éviter les artéfacts voire un flou généralisé.

mattmatt73 · « **Réponse #94 le:** 22 décembre 2016 à 06:40:52 »

Citation de: BadMax le 21 décembre 2016 à 22:27:11

Une session RDP peut se contenter d'une centaine de kbits/s : essaye donc en MPEG

C'est 2 utilisations différentes, d'ailleurs afficher une vidéo en RDP est affreusement moche, ça sacade, ça vomit, même sur du LAN Gb. Par contre, tu peux utiliser une session web ou faire de la bureautique.

Une centaine de kb/s pour ne rien faire ? MPEG sait le faire...

Rdp moche en vidéo ? Bien configuré non. On a des dessinateurs sous des VM autocad bi écrans full HD qui font des burst à plusieurs centaines de mb/s quand ils font des grands coups de roulette.

On a aussi des fois de la VM sous Adobe première qui marche correctement mais avec une connexion gigabit indispensable aux serveurs.

mattmatt73 · « **Réponse #95 le:** 22 décembre 2016 à 06:50:52 »

Citation de: hwti le 22 décembre 2016 à 05:29:00

.
En revanche, je suis sceptique sur la possibilité de monter en 1080p120/140 comme annoncé : il faudrait un gros bitrate pour éviter les artéfacts voire un flou généralisé.

Médisant, pour du 120p, level3 le fait a moins de 200mb/s qualité broadcast, jpeg2000 sur son réseau reliant les arénas US aux networks