Connecter un amiga à un APN WIFI
-
Et quid de Hollywood ? C’est lui qui manque à l’équation. Sans les deux membres, une équation est insoluble. Qu’est-ce qu’attends en entrée hollywood pour streamer une video?
De ce que je comprends de >>ce code source<<, une trame UDP contient une image MJPEG qui se tient à partir 32 + la valeur du mot stocké à l’offset 30 de la trame jusqu’à la fin de la trame. Ces données sont ensuite envoyées à FFMPEG qui se charge de les afficher dans la ram video du linux. Donc si hollywood est capable d’afficher une image MJPEG, il suffit de lui faire afficher les données reçues et ca roule..
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.)Je rejoins _Sam_, sans les connaissances dans un domaine, les outils ne te servirons à rien.
Il faut soit te former au métier d’ingénieur réseau, (iso-osi, les déférentes couches, etc.), soit trouver quelqu’un qui veut faire la même chose que toi et qui à ses compétences.
Aller manipuler des trames réseaux c’est pas à la porter du 1er venu, je pensais que tu avais déjà des bases.
Ah oui pardon pour hollywood j’ai posté mon message trop vite!!
Voici un lien vers la fonction hollywood qui récupère le flux
https://www.hollywood-mal.com/docs/html/hollywood/ReceiveUDPData.htmlComme hollywood est un langage basic et qu’il implémente le protocole UDP je pensé que cela serais plus ou moins accessible.
J’ai déjà écrie des programmes qui analyse la structure d’un GIF ou AnimGIF et je m’en étais pas trop mal sortie j’ai réussi à extraire les info que je voulais pour faire ce dont j’avais besoin
Mais là y a rien à faire j’arrive pas à extraire quoi que ce soit de compréhensible, je ne sais pas quelle fonction utiliser…
De ce que j’en comprends, une fois l’id créé pointant sur ton Lumix, tu dois faire un truc dans le genre:
data$, ip$, port = ReceiveUDPData(id, 65556)
pour récupérer toute la tramme UDP dans data$. Là dedans à l’offset 30, tu as un mot 16 bits qui donne une fois ajouté à 32 où trouver le début des données MJPG. Ca doit donner un truc genre:offset = 32 + Byte(data$, 30)*256 + Byte(data$,31) mjpg$ = MidStr(data$, offset)Ensuite tu dois pouvoir demander à Hollywood d’afficher mjpg$ comme une image (le flux vidéo n’est dans le cas du Lumix qu’une série d’image JPG (MJPG) chacune contenue dans une trame UDP). J’imagine qu’il faut pour cela sauver ces données dans fichier sur disk (dans le dossier temp typiquement, eg. T:image.mjpg) et faire afficher ce fichier par les api de manip d’image de hollywood directement.
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.) Merci Sam c’est déjà une bonne aide par contre
ReceiveUDPData(id) ne reçois pas tout le flux d’un seul coup je doit faire ça pour récupérer le tous.Data$=ReceiveUDPData(id)
FullData$=FullData$..Data$Mais je peux déjà analysé le premier Packet si je veux
Pourquoi tu multiplie par 256?
Et je ne comprend pas non plus pourquoi ajouter 32 au mot de 16bits pour avoir le début des donnée MJPG
Et le mot 16bits peut-on le décoder en clair ? Je veux dire le lire sous forme d’un string?
Bon désolé pour les question mais c’est tellement flou pour moi j’ai l’impression que en binaire on travail en aveugle sans aucun repère direct 😰Tu as oublié le parmètre 65536 dans ReceiveUDP, donc il tronçonne par petit bout (256 octets). Il ne faut pas faire comme ca, il faut mettre la taille max d’une trame (64ko) et récupérer le max qu’on peut qui contiendra l’inégralité de la trame. Sinon, tu as des risques en accumullant les appels par bout de 256 octets de ne pas savoir quand fini la trame courante et quand débute la suivante.
Et je ne comprend pas non plus pourquoi ajouter 32 au mot de 16bits pour avoir le début des donnée MJPG
Pourquoi 32 ? Par ce que c’est comme ca que le type qui a fait la rétro-ingénierie a trouvée qu’il fallait faire pour trouver le début de l’image.
Et le mot 16bits peut-on le décoder en clair ? Je veux dire le lire sous forme d’un string?
C’est pas une chaîne de 2 caractères, mais un nombre binaire sur 2 octets. Il faut donc convertir les caractères en entier (routine Byte()) et multiplier l’octet de poids fort par 256 et ajouter celui de poids faible. L’affichage en chaîne ne sert à rien. Le code ci-dessus te calcule déjà tout cela comme il faut je pense (j’ai supposé un encodage BigEndian, mais c’est peut-être l’inverse et il faut faire porter la multiplication par 256 sur l’autre octet).
r moi j’ai l’impression que en binaire on travail en aveugle sans aucun repère direct 😰
Ben oui tu t’attaques à une API propriétaire sans documentation officielle. Donc ben faut faire de la retro-ingénierie comme le lien que tu as donné ci-dessus. Ce lien t’explique qu’en plus ca marche pas si super bien que cela. Il y a plein de problèmes techniques qui s’ajoutent: des fois c’est pas à l’offset 30 qu’on trouve le décalage et on sait pas pourquoi. Des fois les paquets de 64ko sont coupés…. et on reçoit pas une image complète, dès fois les couches réseaux bufferisent les choses trop longtemps (pour recoller les paquets), et ca se met à laguer à mort, etc etc. Ce sont les joies de travailler sans doc officielles.
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.) Ah ouai c’est la mort :’-(
Merci pour toutes les explications j’ai pas tout compris mais c’est sympa de prendre le temps d’essayer
j’ai créer un fichier qui contient le flux : https://gofile.io/d/l69fcJ
Mais j’arrive toujours pas à extraire d’image…Ca semble marcher! J’ai pris ton fichier binaire. J’y trouve à l’offset 30 la valeur hexa $92. J’ajoute 32 ($20) et j’obtiens $B2 (=178). Je sauve le reste du fichier à partir de l’offset 178 sous le nom x.jpg que je peux ensuite ouvrir comme une image avec le 1er afficheur que j’ai sous la main.
On voit le début de quelque chose, mais l’image est corrompue. Soit que le fichier est tronqué, soit qu’il y a un beau mélange de trames à l’intérieur. Mais cela ne demande qu’à fonctionner. A mon avis le problème est maintenant d’ouvrir un “pipe:” sous Hollywood, de brancher FFMPEG ou l’api de lecture de flux vidéo en lecture sur ce pipe:, et à l’autre bout en écriture, d’avoir une petite boucle sous hollywood qui récupère les trames, décortique la partie utile (ce que j’ai fait au dessus), et envoit le résultat sur le “pipe:”. A l’autre bout FFMPEG ou VLC ou l’api de décodage vidéo se chargera de l’affichage.
Attachments:
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.) J’ai testé avec une commande FFMpeg
ffmpeg -i lumix_flux -vcodec copy frame%d.jpgJ’ai le même résultat que toi j’ai refait le fichier avec ReceiveUDPData(id, 65536)
j’ai pu extraire environs 70 images mais ça fait la même chose (une partie visible) je me demande si la fonction ReceiveUDPData() n’est pas buggéUDP n’est pas garanti sans perte de données non plus. Si cela peut aider, j’ai trouvé une API Python de pilotage d’un lumix: >>ICI<<. Peut-être qu’en modifiant la qualité de la vidéo, on arrive à faire tenir chaque image dans une trame plus petite qui passerait mieux sur le réseau.
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.)J’allais le dire 🙂
De mémoire UDP n’est en effet pas conseillé concernant le transport de donnée.
Il me semble même qu’il n’y a pas de contrôle de donnée ou alors un truc sommaire.
Putain, ça date tout ça…
Je regarde..Google me dit que le checksum est facultative en IPv4.
Suis même pas sûr que si le paquet est identifié comme ‘erroné’, il y ait retransmission.
Il me semble que ça dépend coté client. (pas sûr)En tout cas c’est bien tu avances 🙂
Merci pour le lien python sam ça peut servir !
Bon j’ai enfin réussi à extraire une image avec Hollywood depuis le même fichier pour le moment
Par contre c’est bizarre mais chez moi le $92 est à l’offset 31 même avec un editeur hexa je le trouve à 31HexStr(ByteAsc(Data$,31)+HexStr(32))
J’utilise la Fonction ByteAsc() je ne sais pas trop si c’est bien la bonne fonction ?! mais ça retourne la bonne valeur
Tu trouves le 92 en 31 car c’est le poids faible. Le poids fort (à 0) se trouve en 30. Dans ta formule
HexStr(ByteAsc(Data$,31)+HexStr(32)), on ne lit pas les 2 octets de l’offset, donc ca buggera sitôt que l’offset dépassera 256 (il manque le poids fort du mot 16 bits). Il y a aussi un mic-mac de conversion de chaine représentant des nombres en hexa (HexStr) et de nombres. Pourquoi as tu tout ces HexStr() ? Ca complique les chose et ralentit l’ensemble.Pourquoi la formule que je t’ai passée
32+ByteAsc(Sata$,30)*256+ByteAsc(Data$,31)ne marche pas ? (j’ai remplacé Byte par ByteAsc qui me semble être la bonne fonction pour retourner les octets entre 0 et 255 dan une chaîne de caractères en effet.)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.) J’utilise les HexStr() par ce que j’y connais rien en binaire donc je fais nimportequoi… 🙂
Ta formule marche très bien ! merci
Mais du coup vu qu’il y a plusieurs images dans mon fichier comment je fais pour me positionner sur les suivante ? il me semble que l’en-tête contient la longueur de l’image ??Ben à voir le code Java, il ne me semble y avoir qu’au plus une seule image par trame, donc à chaque trame son image et c’est tout, non ? Donc je pense que “taille image = la longueur de la trame UDP – l’offset”.
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.)
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › Connecter un amiga à un APN WIFI