Connecter un amiga à un APN WIFI
-
J’ai réupload un nouveau fichier et j’arrive à extraire 180 images (moiter d’images) avec FFmpeg
https://gofile.io/d/yzyt1TDonc le flux contient plusieurs images le premier fichier n’était pas générer avec 65536 il me semble c’est peut être pour ça
Ben oui le paramètre c’est un « au plus ». Les packets n’ont pas tous la même longueur car ils contiennent une image JPG, donc qui prends plus ou moins de volume suivant la compressibilité de l’image.
Je pige pas ce que tu fais avec Header$ ? Tu concatène les packets ? Quel est le but. De ce que j’ai vu du code java, chaque trame UDP reçu est décodée (offset 30 tout çà), et la partie utile est envoyée dans le flux vidéo. Bref, il faut décoder les données avant d’en faire une image video. Maintenant le format MJEG est probablement tolérant et saute « par dessus » les trucs en trop la plupart du temps. Le problème est que ca n’est que la plupart du temps, donc ca fini toujours tôt ou tard par merdouiller.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.) Non si c’était un bug, ce serait étonnant que tu sois le seul sur la planète à être tombé dessus malgré le fait que Hollywood existe sur pleins de machines avec pleins de jeux utilisant le réseau.
Une seule trame peut-être trop petite pour une image, aussi elle peut tenir sur plusieurs. Ce qu’il faut faire ce n’est pas de résonner en images, mais en flux. Tu dois décoder chacune des trames (offset 30 tout-ça), extraire les données, et les envoyer dans le flux. Si tu écris un fichier disk, ca veut dire que tu va ajouter à la fin du fichier les données utiles de la trame. Si tu construit le fichier en mémoire, ca veut dire que tu va ajouter à la chaine qui représente la vidéo les données utiles extraites de la trame.
Ma théorie actuelle épaulée par le code java qui marche est que le lumix envoie le flux vidéo constitué d’images jpg (c’est un flux mjpg) par paquet UDP. Ceux ci pouvant être trop petit pour l’image, ils ont fait plus intelligent. Plutôt que d’envoyer l’image brut dans le paquet, ils ont réalisé une encapsulation. Le début de trame contient des méta-infos de la caméra, et le reste les données vidéo. Toi tu ne veux que les données vidéo. Il te faut donc les extraire de chacune des trames reçues et faire ce que tu as avec. Si tu ne réalise pas l’opération d’extraction et que tu ajoute simplement les trames une à une, la partie de mata-data brouille les données. Le format mjpg sait +/- les ignorer mais pas toujours. Cela laisse croire que l’approche simple ne passant pas par le décorticage semble marcher… mais pas toujours. Bref: il faut faire comme en java: lire toute la trame, extraire les données, envoyer les données dans le flux vidéo et recommencer. Je répète: extraire les données pour chaque trame reçue, sinon bah ca fini par bloquer.
Enfin c’est comme ca que j’essayerais perso d’aborder le truc.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.) Non ça me semble vraiment être un bug j’en ai trouvé déjà pas dans Hollywood ils ont était corrigé mais ça ne m’étonne pas en tout cas. Quand je récupère le flux en faisant header$=header$..ReceiveUDPData(id,size) je devrais avoir les images complète mais non elles ne le sont pas j’ai testé tout les solutions a chaque fois j’ai la même chose des moitiées d’images. Et si je change la taille du paket en réception ça ne dépasse jamais 8192 donc pour moi c’est un bug quand je teste sur winuae c’est encore plus bugger et reconnu par le gars qui développe hollywood
Quand tu fais
header$=header$..ReceiveUDPData(id,size)tu ne décodes pas le contenu de la trame UDP. Ca peut marcher un temps, mais c’est un gros coup de chance à mon avis vu que tu injectes dans header$ (pourquoi ce nom d’abord? Ce sont des data) la première partie de la trame UDP qui contient des infos qui ne sont pas les données du flux vidéo.Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.) Il n’y a pas un question de taille de cache dans ton histoire ?, ou une limitation ‘système’ de tes variables ?
Perso j’aurai ajouter un serveur linux entre les deux et regarder la tête de ce qui passe exactement.
Savoir exactement ce qu’es envoyé
et ce qui est reçu
le tout avec un serveur qui n’a rien à voir dans l’histoire (donc complétement neutre).
ça permettrait de comprendre exactement ou est le problème et d’en être sûr à 100%
Après… je ne suis pas dev 🙂De toute façon ça explique pas la limite des 8192octets.
Je te l’ai expliqué plusieurs fois. C’est pas parce que tu demandes 65536 que tu aura 65536. Ca n’est pas un bug! Tu ne lis pas un fichier dont tu peux extraire 64ko de façon arbitraire, tu lis des trames UDP et ces dernières ont une certaine taille.
Si la trame fait moins que ce que tu demandes, tu aura moins, par exemple 8192 quand tu demandes 65536. C’est comme ca les api réseau. C’est pas toi qui décides de la taille trame à recevoir. C’est l’émetteur, et sa taille peut varier au cours du temps. Le flux peut être plus ou moins gros en fonction de la compression des images, ou lors de la connexion avec la box il a déterminé que 8ko était la meilleur taille d’envoi de packets pour la latence de ton réseau actuel par exemple.. il y a plein de raisons qui peuvent faire varier la taille des trames UDP envoyées par le Lumix.
La seule chose qu’on sache stable est que
1) une trame UDP fait maxi 64ko (length sur 16bits), mais c’est pas toi qui décide de la longueur. Tu dois accepter la longueur max, mais tu peux recevoir bien plus petit genre 8ko ou moins.
2) au niveau de la reception, on trouve à l’offset 30 de chaque trame le début des données vidéos dans le reste de la trame.Le Lumix t’envoie des trames de 8ko c’est bien. On sait pas pourquoi il fait ca ni ca va être à chaque fois pareil. Il peut y avoir pleins de raisons sur lesquelles tu ne peux influer: limitation de la puissance du processeur embarqué, limitation de la mémoire interne de la pile wifi, taille de l’image < 8ko, limite de la box pour les paquets udp locaux, taille optimale pour le lag, etc.
Si le Lumix a besoin de 3 ou 4 trames de 8ko pour envoyer une image mjpeg de 24ko, il va t’envoyer 3 ou 4 trames avec une première partie contenant des trucs internes dont à l’offset 30, l’endroit de la trame où trouver le bout d’image correspondant. Tu dois donc, de ton coté, pour chaque trame, extraire le bout d’image vidéo et l’envoyer au truc qui affiche ou l’ajouter à la fin du fichier que tu reconstruis sur disk.
Ah sinon, même pour le test, un bon nom permet de raisonner correctement et réduit les bugs. Parce que là tel que je te vois à mettre des données dans une variable que tu nommes « entête » ne va pas aider à lever les ambiguïtés ni les bugs quand tu va réanalyser le programme plus tard (parfois du jour au lendemain suffit pour oublier les conventions implicites comme ca). Enfin c’est toi qui vois et qui galèrera au final.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)Wiki concernant l’UDP :
À cause de l’absence du mécanisme d’établissement de liaison (handshaking), ce protocole expose le programme qui l’utilise aux problèmes éventuels de fiabilité du réseau ; ainsi, il n’existe pas de garantie de protection quant à la livraison, l’ordre d’arrivée, ou la duplication éventuelle des datagrammes.
Structure d’un datagramme UDP :
Longueur :: indique la longueur totale (exprimée en octets) du segment UDP (en-tête et données). La longueur minimale est donc de 8 octets (taille de l’en-tête).3.3 – Longueur : Le champ Longueur est codé sur 16 bits et il représente la taille de l’entête et des données. Son unité est l’octet et sa valeur maximale est 64 Koctets (216).
etc
Un site parmi tant d’autre : https://www.frameip.com/entete-udp/Tu devrais je pense décoder d’abord le header et en déduire les informations comme la longueur.
Ensuite traiter les données en question, extraires les ‘data’, les stockers en mémoire dans une variable.
Une fois que tu as ‘validation’ que tu as traiter toutes les ‘trames’ UDP, la tu peux écrire/afficher ce que tu veux.@Giants92 la routine ReceiveUDPData(id,size) d’Hollywood fait le décodage de l’en-tête UDP et retourne la partie payload (utile). Bref: la couche réseau est abstraite en Hollywood (on peut récup le port et l’ip de l’envoyeur, mais c’est avec une autre forme d’appel[*]).
Par contre il reste l’en-tête applicatif au niveau de là où Sinisrus travaille. Dans cet en-tête applicatif on trouve le type de data, et en particulier à l’offset 30, l’indice de début des données « vidéo ». C’est le fait de ne pas décoder cet offset pour chaque payload recu (ce qu’on appelle ici abusivement trame) qui coince.
Il faut vachement faire gaffe aux mots utilisé qui ajoutent à la confusion. Dès le début Sinisrus nous a parlé de décoder l’en-tête d’une trame UDP. Or il n’est rien de tout cela avec les communication avec un APN (en témoignent les sources java et python donnés plus haut). Les infos utiles pour Sinisrus sont dans l’en-tête applicatif du datagram . Tu vois d’où vient la confusion: En-tête réseau / en-tête applicatif. Or ca tombe bien l’applicatif est justement ce que ReceiveUDPData() fournit [*].
==> Bref oublie tous les problèmes de couche réseau (en tête, split de packets etc). C’est pas là que se situe le pb de Sinisrus. Son problème est (je pense) qu’il ne décode pas l’offset 30 de la partie applicative et se contente de les ajouter à la queue leu-leu sans analyse. Le format MJPEG est tolérant aux data en trop (comme en-tête applicative qu’il ne retire pas), mais jusqu’à un certain point. Ce qui fait qu’il ne récupère pas un flux très longtemps. Il faut travailler au niveau applicatif et ca roulera tout seul sans prise de tête.
___
[*] Plus d’infos sur ReceiveUDPData: https://www.hollywood-mal.com/docs/html/hollywood/ReceiveUDPData_.htmlReceiveUDPData() returns three values: The first return value is a string containing the data received from the UDP object. The second return value contains the IP address of the sender, and the third return value contains the port number of the sender.
Pour récupérer l’ip et le port (le checksum n’est pas récupérable. S’il est invalide la fonction retourne nil en data) on écrit
data,ip,port = ReceiveUDPData(id, max_length). La façon d’écrire de Sinisrus n’utilise que la partie « data ». Les valeurs ip et port sont ignorées ce qui est normal pour ce qu’on veut faire.Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)Effectivement, je n’avais pas compris qu’il ne décodait pas from scratch, de lui même ce qui transitait sur le réseau.
D’ou le ‘ReceiveUDPData(id,size) d’Hollywood’
La c’est effectivement on est plus dans le ‘réseau’ mais dans l’appli elle même et comment elle fonctionne.
Et la, pas du tout mon domaine. 🙂 Sam
En fait au départ avant que tu me donne la solution pour arrivé à l’offset 30 j’essayai d’extraire des information du header donc je faisais un truc dans le genre :
Data$=ReceiveUDPData(ID,Size)
IF IsNil(Header$)
Header$=Data$
ELSE
FullData$=FullData$..Data$
EndIFCe n’étais pas bon du tout puisque je recupèrer le premier packet dans header$ et pas l’en-tête.
Et c’est pour ça que j’ai mis un exemple de code avec header$ c’était un exemple mais je suis d’accord avec toi les variables doivent êtres correctement nommées.Sinon pour l’histoire d’une image sur plusieurs packet je veux bien mais dans ce cas là normalement quand je fais FullData$=FullData$..Data$ je devrais bien avoir les images au complet ou au pire si les paquets n’arrive pas dans l’ordre je devrais avoir des morceaux d’images mélangées mais ce n’est pas le cas j’ai toujours uniquement des hauts d’images et jamais des morceaux bas normalement une image commence par FFD8 et fini pas FFD9 je n’ai jamais de FFD9 dans mon fichier…
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › Connecter un amiga à un APN WIFI
