Réception d'image par le biais de la messagerie Web

J'utilise websockify pour afficher des images d'un serveur python vers un canevas HTML5.

Je pense que j'ai réussi à envoyer des images avec succès à partir de mon serveur python, mais je ne peux pas afficher les images sur mon écran.

Je pense que le problème concerne le nombre d'octets que j'essaie d'afficher sur le canevas et je crois que je n'attends pas que l'image entière soit reçue, puis l'affichage de l'image sur le canevas.

Jusqu'à présent, j'ai:

La fonction de message. Lorsque j'ai envoyé une image, j'ai 12 MESSAGERECEIVED dans la console

  ws.on('message', function () { //console.log("MESSAGERECEIVED!") msg(ws.rQshiftStr()); });

La fonction msg où je reçois la chaîne et j'essaie de l'afficher sur toile. J'appelle la méthode 12 fois pour chaque image. Le format de la piqûre est 'xÙõKþ°pãüCY :

 function msg(str) { //console.log(str); console.log("RELOAD"); var ctx = cv.getContext('2d'); var img = new Image(); //console.log(str); img.src = "data:image/png;base64," + str; img.onload = function () { ctx.drawImage(img,0,0); } }

Des suggestions sur la façon de résoudre ce problème?

L'objectif de websockify + websock.js est de soutenir de manière transparente la transmission de données binaires (plus sur ce qui suit). Les données que vous obtenez de la file d'attente de réception sont déjà codées en base64. Toutefois, le schéma URI des données s'attend à une chaîne codée base64, donc vous devez coder les données d'image en base64. Vous pouvez utiliser la fenêtre intégrale.btoa () à base64 codant une chaîne codée binaire:

 img.src = "data:image/png;base64," + window.btoa(str);

Ou, pour une plus grande efficacité, vous pouvez utiliser le module Base64 à partir d'include / base64.js, mais vous devrez passer un ensemble d'octets que vous obtiendrez de rQshiftBytes:

 msg(ws.rQshiftBytes()); img.src = "data:image/png;base64," + Base64.encode(data); // str -> data

En ce qui concerne l'utilisation de base64 en mode Web:

Websockify utilise base64 pour coder les données pour prendre en charge les navigateurs qui ne prennent pas en charge les données binaires directement. En plus des navigateurs populaires de Hixie, tels que iOS Safari et Safari de bureau, certaines versions de navigateurs en mode sauvage utilisent HyBi mais manquent de support binaire. Et malheureusement, dans le cas de Chrome, ils avaient également un bug WebIDL en même temps qui empêche la détection du support binaire avant de créer une connexion.

En outre, l'option principale pour l'utilisation de WebSockets sur Opera, Firefox 3.6-5, IE 8 et 9 est le Web-socket-js . Web-socket-js prend en charge HyBi mais n'a pas de support binaire et ne sera probablement pas parce que la plupart des navigateurs anciens dont il cible ne prennent pas en charge les types binaires natifs (Blob et Typed Arrays).

La part de marché des navigateurs qui prennent en charge HyBi et les données binaires est actuellement assez faible. Cependant, à l'avenir, Websockify détectera (soit par détection d'objet, soit par détection de version de navigateur) si le navigateur prend en charge les données binaires et utilise ce support directement sans avoir besoin de codage / décodage base64.

La surcharge de latence (et CPU) de base64 encode / decode est assez faible et généralement éliminée par les latences de réseau de toute façon. La surcharge de bande passante des données codées base64 est d'environ 25% (c.-à-d. Les données brutes sont 33% plus grandes), mais elles vous donnent des données binaires sur WebSockets sur tous les navigateurs de la nature (avec le polyfill / shim web-socket-js qui est Utilisé de manière transparente par websock si nécessaire).