Ce transfert de fichiers n'utilise pas du tout Internet (decimen)
BBetter Stack
컴퓨터/소프트웨어가전제품/카메라AI/미래기술
스크립트
00:00:00Voici une question. Comment envoyer un fichier à quelqu'un sans utiliser de réseau et sans aucun
00:00:05appareil physique comme des clés USB ? Eh bien, la réponse est le transfert de fichiers optique. Un développeur nommé Evan
00:00:13Crawley vient de créer un outil appelé Deciman, capable d'envoyer un fichier d'un appareil à
00:00:19un autre simplement en flashant des codes QR et en les lisant. C'est une technique de transfert de fichiers super cool
00:00:26qui utilise des astuces d'ingénierie assez ingénieuses. Donc, dans la vidéo d'aujourd'hui, nous allons examiner
00:00:31Deciman, voir comment il fonctionne et le tester dans différents scénarios pour voir à quel point le transfert de fichiers
00:00:37optique est réellement puissant. Ça va être très amusant, alors plongeons dedans.
00:00:46Deciman fonctionne donc de cette manière. Un appareil affiche un flux de cadres ressemblant à des codes QR sur son écran
00:00:53et un autre appareil pointe une caméra vers lui et les décode pour en faire un fichier. Il n'y a donc aucune pile réseau
00:01:00impliquée. Si vous devez un jour échanger un fichier avec un appareil isolé (air-gapped), c'est le seul moyen
00:01:06de le faire sans brancher physiquement de périphériques externes tels que des clés USB. L'idée est de
00:01:12coder votre fichier sous forme de séquence de codes QR, de les flasher à l'écran l'un après l'autre et de faire capturer
00:01:19et décoder chaque cadre par une caméra de l'autre côté. Cela peut sembler simple, mais la complication vient
00:01:26du fait que les caméras ne capturent pas de manière instantanée et que les écrans ne se rafraîchissent pas
00:01:32instantanément. Vous faites donc concourir deux matériels différents, et s'ils se désynchronisent,
00:01:38les cadres sont corrompus ou complètement perdus. Mais la réponse de Deciman à ce problème est une méthode appelée codage fontaine.
00:01:46Au lieu d'envoyer le cadre 1, le cadre 2, le cadre 3 en espérant que chacun arrive à destination,
00:01:53il génère un flux pratiquement illimité de cadres encodés où chaque cadre est un mélange mathématique
00:02:00de parties du fichier original plutôt qu'un morceau spécifique de celui-ci. Cela signifie qu'aucun cadre n'est irremplaçable.
00:02:07Le récepteur n'a pas besoin précisément du cadre numéro 47, il lui suffit d'avoir assez de cadres, peu importe lesquels.
00:02:14Et si vous en ratez la moitié, cela n'a pas d'importance. Il continue simplement à diffuser jusqu'à ce que le récepteur en ait collecté
00:02:22suffisamment. Mais cette approche n'est en rien une solution miracle. Avec cette méthode, il y a une limite à la quantité de données
00:02:29que nous pouvons transférer. Par défaut, l'émetteur de Deciman pousse 2953 octets par cadre à 60 images par seconde.
00:02:37Si vous faites le calcul, vous obtenez une limite théorique d'environ 177 kilo-octets par seconde.
00:02:44Prenez en compte les surcoûts du codage fontaine, puisque certains de ces cadres mélangés sont essentiellement redondants par conception.
00:02:51Et ce qu'il vous reste correspond au chiffre que le fichier README de Deciman revendique réellement.
00:02:56Il atteint un pic d'environ 128 kilo-octets par seconde lorsqu'il est mesuré d'un téléphone à l'autre.
00:03:02Et la raison pour laquelle il utilise spécifiquement des morceaux de 2953 octets est que cela correspond au code QR version 40,
00:03:11la plus grande taille de code QR standard, soit une grille de 177 sur 177 modules individuels regroupés dans un seul cadre.
00:03:20C'est là que le véritable compromis apparaît. Si vous entassez plus de données dans un cadre, vous avez besoin de moins de cadres
00:03:26au total pour envoyer le même fichier, ce qui signifie que la caméra qui le lit doit avoir une meilleure résolution,
00:03:33une main plus stable et un meilleur autofocus pour distinguer un module du suivant.
00:03:38Tout le système est donc en réalité un exercice d'équilibre entre trois variables.
00:03:42Le nombre d'images par seconde que vous envoyez, la densité de chacun de ces cadres et la capacité réelle de la caméra
00:03:49réceptrice à résoudre cette densité. Deciman propose un équilibre prédéfini par défaut,
00:03:57et il est réglé pour un scénario précis qui, comme je l'ai découvert, n'est pas celui dans lequel je l'ai testé.
00:04:03Voici donc ma configuration : l'écran d'un ordinateur portable comme émetteur, placé à une distance normale d'un bras,
00:04:09comme vous l'utiliseriez en pratique. Avec cette configuration, mon transfert a atteint un plafond d'environ trois kilo-octets par seconde.
00:04:16À peu près un à deux pour cent des cadres transmis sont réellement décodés. Le reste est capturé et jeté.
00:04:23Il y a trois facteurs qui se liguent contre nous ici. Le premier et le plus grand obstacle est la non-concordance de la fréquence d'images.
00:04:30L'émetteur pousse 60 images par seconde, mais la caméra de mon téléphone capture à 30. Vous ne pouvez pas échantillonner 60 images distinctes
00:04:38avec un capteur qui n'en prend que 30. Et c'est pire que d'en rater la moitié, car la fenêtre d'exposition de chaque
00:04:45cadre capturé chevauche deux codes QR différents à l'écran. La caméra ne rate donc pas proprement un cadre, elle en fusionne deux en un seul qui ne donne rien au décodage.
00:04:56Et dans le fichier main.ts, il y a même une note qui indique qu'iOS fournira silencieusement 30 images par seconde, même lorsque l'application demande explicitement 60 à la caméra.
00:05:07La caméra ne vous donne tout simplement pas ce que vous avez demandé, et le code y remédie déjà.
00:05:12Un peu plus loin dans le même fichier, il y a un commentaire qui prédit pratiquement ce qui m'est arrivé lors de mon premier essai.
00:05:19Les valeurs par défaut, à savoir 2953 octets par cadre à 60 images par seconde, sont optimisées spécifiquement pour une démo de près entre téléphones.
00:05:29Et cette même combinaison est censée avoir du mal sur un moniteur ordinaire à distance de bras.
00:05:35En d'autres termes, le projet m'avait prévenu. Je n'avais simplement pas assez fait défiler le code pour le voir.
00:05:41Du côté de l'émission, un panneau d'ordinateur portable à 60 hertz a le même problème à l'inverse. Et les pixels LCD prennent beaucoup de temps pour effectuer une transition complète de gris à gris.
00:05:51Ce temps de latence signifie que le panneau n'a pas totalement affiché un code avant que le suivant ne commence à s'y superposer.
00:05:58Vous obtenez donc des artéfacts de rémanence. Le deuxième problème est la densité du code par rapport à la résolution de la caméra.
00:06:042953 octets correspondent à un code QR version 40, mais un décodage fiable nécessite environ trois à quatre pixels de caméra par module, ce qui représente plus de 600 pixels de large en netteté parfaite rien que pour le code.
00:06:20L'écran d'un ordinateur portable tenu à bout de bras remplit rarement autant le cadre de la caméra d'un téléphone, alors qu'une liaison de près entre téléphones remplit facilement tout le viseur.
00:06:30Le troisième problème concerne la luminosité et le contraste. C'est un problème secondaire, mais il aide si le binariseur du récepteur traite l'image proprement, sans toutefois pouvoir résoudre un décalage de fréquence d'images ou un code trop petit.
00:06:44Essayons maintenant de faire le même transfert, mais cette fois d'un téléphone à un autre téléphone.
00:06:50La seule chose qui change est l'émetteur. C'est un petit écran OLED lumineux tenu de près, remplissant tout le cadre du téléphone récepteur.
00:06:58À présent, la caméra peut s'approcher de sa véritable fréquence d'images.
00:07:02Le code remplit le cadre en haute résolution et il n'y a pas de rémanence LCD à combattre.
00:07:07C'est dans ce scénario que le chiffre de 128 kilo-octets par seconde du fichier README a réellement été mesuré.
00:07:14Il y a aussi un détail petit mais vraiment utile dans le code du récepteur.
00:07:18Il indique séparément les FPS de capture et les FPS de décodage. La capture indique ce que la caméra voit physiquement.
00:07:26Le décodage indique quelle portion de cela est réellement exploitable.
00:07:30Lorsque ces deux chiffres s'écartent l'un de l'autre, c'est-à-dire que la capture reste bonne tandis que le décodage s'effondre,
00:07:35vous observez un décalage entre la densité des cadres et ce que la caméra peut réellement résoudre à cette distance.
00:07:42Si votre cas d'usage réel est du PC portable vers le téléphone, la solution consiste à rééquilibrer ces trois variables du côté de l'émetteur.
00:07:50Vous devriez baisser le nombre d'octets par cadre à 1465, ce qui correspond à une version de QR plus grossière avec des modules plus grands et plus tolérants.
00:07:59Puis réduire délibérément les FPS de transmission à 24, en dessous de la limite des 30 FPS de la caméra.
00:08:07Ainsi, les cadres sont échantillonnés proprement un par un au lieu de se mélanger les uns aux autres.
00:08:12Et comme vous pouvez le voir, baisser ces chiffres génère un débit bien plus important.
00:08:16Cela montre bien que le transfert de fichiers optique n'est pas une solution universelle.
00:08:21Vous devez l'ajuster manuellement pour chaque cas d'usage en fonction du matériel que vous utilisez.
00:08:26Voilà donc, les amis.
00:08:27C'est Deciman en résumé.
00:08:29Dans l'ensemble, c'était un projet vraiment amusant à explorer.
00:08:32Le transfert de fichiers optique est une technique plutôt cool.
00:08:36Et voir le concept de codage fontaine appliqué dans un scénario réel était vraiment intéressant à observer.
00:08:44Pendant que j'explorais ce projet, je me demandais aussi où l'on utiliserait réellement ce type d'outil.
00:08:49Je suppose que la réponse évidente concerne les transferts isolés où l'on ne veut délibérément aucune connexion réseau.
00:08:57Ou peut-être des appareils qui n'ont même pas le Bluetooth ou le Wi-Fi, comme du vieux matériel ou des systèmes embarqués.
00:09:04Bref, partout où un écran et une caméra sont les deux seules choses sur lesquelles on peut compter.
00:09:10Mais que pensez-vous de cet outil ?
00:09:11Avez-vous déjà utilisé des outils de transfert optique ?
00:09:14Voyez-vous une application concrète pour cela ?
00:09:17Faites-le-nous savoir dans les commentaires ci-dessous.
00:09:19Et les amis, si vous aimez ce genre d'analyses techniques, faites-le-moi savoir en pulvérisant le bouton J'aime sous la vidéo.
00:09:25N'oubliez pas non plus de vous abonner à notre chaîne.
00:09:28C'était Andrus de BetterStack et je vous dis à bientôt dans de prochaines vidéos.
00:09:34Je vous dis à la prochaine vidéo.