Connecter un amiga à un APN WIFI

[__sam__]

__sam__

#353279

FullData$=FullData$..Data$ je devrais bien avoir les images au complet ou

Non: dans data tu as l’en-tête de la partie applicative si tu n’extrait pas le bon bout via l’offset 30. Pour rappel un packet se décompose comme ca dans le cas du luminx:

<packet> = <en-tete applicatif> <data applicatif>
                   |           /|\
               offset 30        |
                   |____________|

Du coup dans FullData tu as un truc qui ressemble à ca (à supposer que tu extrait juste l’en-tête applicative du 1er packet): <data packet1> <en-tete appli packet2> <data packet 2> <en-tete appli packet 3> <data packet 3> ..etc.

Tu vois où ca coince ?. Tous ces <en-tete appli packet n> intermédiaires qui ne devraient pas être la parce tu n’extrait pas la partie utile au niveau applicatif en ajoutant tout le contenu de ReadUDP().

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.)

[sinisrus]

sinisrus

#353288

Le truc c’est que si je recupère chaque paket individuellement

Data$=ReceiveUDPData(af,65527)
Debugprint(32+ByteAsc(Data$,30)*256+ByteAsc(Data$,31))

J’ai bien le 178 à chaque fois, C’est pas logique !
Si j’ai un paket pour <l’en-tête + image> et les autres paket pour <le reste de l’image> je ne devrais pas avoir le 178 à chaque paket non ??

Si j’affiche ses images en supprimant l’en-tête j’ai touours la partie haute de l’image dans chaque paket ! (je precise que ce son bien des images différentes les une des autres je passe ma main devant l’objectif)

Ya t-il un moyen de connaître la taille reel du paket reçu ou de l’image reçu?

[__sam__]

__sam__

#353291

Data$=ReceiveUDPData(af,65527)
Debugprint(32+ByteAsc(Data$,30)*256+ByteAsc(Data$,31))

J’ai bien le 178 à chaque fois, C’est pas logique !

Ben si. Ca veut dire que la partie donnée commence pour ainsi dire à chaque fois à l’offset 178 dans les paquets que tu reçois. C’est cohérent et bon signe que le mot à l’offset 30 est correct. Il n’y a pas à réfléchir plus. Cherches pas un truc compliqué. Le format que t’envoie le lumix contient toujours un en-tête, et la partie donnée se trouve à l’offset du mot en 30. Toujours.

La taille du packet reçus tu l’as, c’est la longueur de la chaine retournée par ReceiveUDPData. La longueur de l’image n’existe pas vraiment. C’est un flux MJPEG continu que tu reçois. Il n’y a pas de début fin. C’est un flux, pas un fichier. Le traitement est en boucle: tu reçois des données par morceaux encapsulée avec un entête applicatif proprio du lumix. Cet entête te donne à l’offset 30 un mot big-endian indiquant où trouver les données dans ce paquet. Tu découpe ces données et tu les envoie à l’afficheur de vidéo, et tu reboucles. C’est tout. C’est pas plus compliqué.

Si tu veux extraire les images, ca se fait à un autre niveau à partir du flux mjpeg reconstruit. Il faut pour cela connaitre le détail des specs MJPEG, et c’est un autre sujet. Raisonne par niveau et ne mélange pas toutes les étapes dans une seule tout de suite.

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.)

[sinisrus]

sinisrus

#353292

@Sam

Argh c’est pénible quand je pense avoir compris ben en faite non!!!
Bon sinon il semble bien y avoir une limitation dans les pakets reçu par receiveUDPData() on ne peux pas dépasser 8192Octets donc si les pakets reçu son plus gros ça fait une perte non ?

[__sam__]

__sam__

#353313

Non il n’y a pas de perte. L’émetteur sait combien d’octets de son paquet ont pu être envoyés. Mettons qu’il prépare un paquet (en-tête + data) de 64ko.. il l’envoi à la couche réseau, qui lui dit: bon j’ai juste réussi à envoyer 8ko (genre c’est une limite de la box wifi). Lui se dit, ok pas de problème: je vais envoyer le reste des 64ko en plusieurs petits paquets de 8ko alors . Et hop, au lieu de recevoir un gros paquet (en-tête + data) de 64ko, tu en reçois 4 ou 5 plus petit de 8ko avec chacun en-tête + data(plus petit). Le maitre mot quand on fait du réseau l’adaptabilité.

Note que le lumix ne sait pas si toi tu as été capable de lire le paquet de 8ko. Ca protocole UDP ne permet pas d’avoir d’assurance. C’est à toi d’être capable d’accepter le paquet max théorique (64ko) et t’adapter si tu en reçois moins. Le protocole décrit plus haut: reception, lecture de l’offset, extraction des data, ajout des data au player, bouclage réponds à ce besoin en s’adaptant automatiquement à la taille et au nombre de paquets reçus.

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.)

[sinisrus]

sinisrus

#353316

Bon ok mais alors comment savoir où s’arrête l’image j’ai bien l’information en début à l’offset 30 > « FFD8 » mais je n’ai pas de fin d’image dans aucun paket 🙁

[__sam__]

__sam__

#353322

Tu as la taille de l’image (attention c’est pas la taille du packet) en la décodant. Je ne connais pas les spécifications détaillées des images présentes dans un flux MJPG, mais ca doit se trouver (quoi que… ah si en s’inspirant du standard MJPG pour usb).

D’après le code ici, ils ont l’air de dire que l’image stoppe au $FFD9 qui suit.

Ailleurs ils disent qu’il faut récupérer dans le flux tout ce qui se trouve entre deux (SOI, DQT)=$FFD8FFDB,

D’autres encore qu’il faut extraire tout entre deux SOI=$FFD8 seuls, puis depuis la fin tout effacer jusqu’au premier $FFD9 rencontré depuis la fin.

Bref: pas facile de savoir en fait.

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.)

[sinisrus]

sinisrus

#353330

Je ne sais pas comment faire avec les fonction Hollywood pour chercher dans une variable une information en binaire genre avec FindStr() ?!?

[__sam__]

__sam__

#353339

Oui peut-être, mais ce qui m’ennuie est que FindStr() utilise un encoding, c’est à dire qu’il interprète les octets ce qui ne convient pas pour du binaire (l’indice retourné est en caractères, pas en octet). Le plus sur serait de faire une boucle sur tous les octets de la chaine et comparer ByteVal(str$,i)==255 and ByteVal(str$,i+1)==0xB9.. Ca ne va pas être rapide.

Tu as vraiment besoin d’extraire les images une à une ?

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.)

[sinisrus]

sinisrus

#353344

Tu as vraiment besoin d’extraire les images une à une ?

Je ne vois pas d’autre solution pour voir les images

[__sam__]

__sam__

#353346

Tu peux aussi envoyer le flux à FFMPEG et lui demander de générer les images. Il fera cela très bien, c’est son métier. Je sais pas comment on ouvre un fichier de type « pipe » en Hollywood, mais sous lua c’est un truc du genre io.popen("commande", mode).

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.)

[sinisrus]

sinisrus

#353350

En Hollywood c’est facile on fait execute(ffmpeg….) Ou run(ffmpeg….)

[sinisrus]

sinisrus

#353352

Et avec Curl c’est pas possible ?

[__sam__]

__sam__

#353353

Es-ce que execute te retourne un fichier (flux) que tu peux lire/écrire ? Il faut que tu puisse envoyer le flot de données de la caméra vers FFMPEG et lui demander de générer les images. Un truc genre ffmpeg -i - sortie.jpg devrait pouvoir lire depuis son STDIN et sortir chaque image sous le nom sortie.jpg.

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.)

[sinisrus]

sinisrus

#353390

Merci SAM je teste ça ce week end