스크립트
00:00:00質問です。ネットワークを使わず、USBメモリのような
00:00:05物理デバイスも使わずに、どうやってファイルを送信しますか？答えは光ファイル転送です。Evan Crawleyという開発者が
00:00:13Decimanというツールを作りました。これはあるデバイスから別のデバイスへファイルを送信できるもので
00:00:19QRコードを点滅させ、それを読み取ることでファイル伝送を行います。非常にクールなファイル転送技術であり
00:00:26かなり巧妙なエンジニアリング戦術が使われています。本日の動画では
00:00:31Decimanを取り上げ、その仕組みを確認し、さまざまなシナリオでテストして、光ファイル転送が
00:00:37実際どれほど強力なのかを検証します。とても面白い内容ですので、早速見ていきましょう。
00:00:46Decimanの仕組みはこうです。1台のデバイスが画面上にQRコードのようなフレームのストリームを表示し
00:00:53もう1台のデバイスがそこにカメラを向けて、ファイルをデコードします。そのため、ネットワークスタックは
00:01:00一切関与しません。エアギャップ環境のデバイスとファイルをやり取りする必要がある場合、これが唯一の方法となります
00:01:06USBドライブなどの外付けデバイスを物理的に差し込む必要がありません。アイデアとしては、ファイルを
00:01:12QRコードのシーケンスにエンコードし、画面上で次々と点滅させ、反対側のカメラで
00:01:19各フレームをキャプチャしてデコードするというものです。シンプルに聞こえるかもしれませんが、問題は
00:01:26カメラが実際には瞬間的にキャプチャせず、画面も瞬時には
00:01:32更新されないという点から生じます。つまり、2つの異なるハードウェアが競合しており、同期がずれると
00:01:38フレームが破損したり、完全に失われたりします。しかし、この問題に対するDecimanの答えは「噴水符号（ファウンテン符号）」と呼ばれる手法です。
00:01:46フレーム1、フレーム2、フレーム3を順番に送り、すべてが届くことを願うのではなく
00:01:53実質的に無制限のエンコード済みフレームのストリームを生成します。各フレームは、特定のチャンクではなく
00:02:00元のファイルの断片の数学的なブレンドとなっています。つまり、どのフレームも代替不可能というわけではありません。
00:02:07受信側はフレーム番号47をピンポイントで必要とするわけではなく、届いたフレームを必要な数だけ集めればいいのです。
00:02:14半分を逃したとしても問題ありません。受信側が十分な量を収集するまで、ひたすらブロードキャストを続けられます。
00:02:22しかし、このアプローチが万能薬というわけではありません。この方法では、転送できるデータ量に上限があります。
00:02:29デフォルトでは、Decimanの送信側は秒間60フレームで1フレームあたり2953バイトをプッシュします。
00:02:37計算してみると、理論上の上限はおよそ秒間177キロバイトとなります。
00:02:44ファウンテン符号によるオーバーヘッドを考慮してください。ブレンドされたフレームの一部は、設計上本質的に冗長であるためです。
00:02:51その結果残るのが、DecimanのREADMEファイルが実際に主張している数値です。
00:02:56スマホからスマホへ計測した場合、ピーク時は秒間およそ128キロバイトになります。
00:03:02特に2953バイトのチャンクを使用する理由は、それが標準的な最大QRサイズであるバージョン40に対応しているからです。
00:03:111つのフレームに詰め込まれた177×177のグリッド状の個別モジュールです。
00:03:20ここに本当のトレードオフが現れます。1つのフレームに多くのデータを詰め込めば、同じファイルを送信するのに
00:03:26必要なフレーム数が少なくなりますが、それを読み取るカメラ側には、モジュール同士を区別するために
00:03:33より高い解像度、ブレない手元、そしてシャープなフォーカスが必要になります。
00:03:38したがって、システム全体は実質的に3つの変数の間のバランス調整となります。
00:03:42秒間何フレーム送信しているか、各フレームの密度がどれほどか、そして受信側の
00:03:49カメラがその密度をどれだけうまく解像できるかです。Decimanには特定のバランスがデフォルトで設定されていますが
00:03:57それは特定のシナリオ向けに調整されており、私が気づいたように、それは私がテストしたシナリオではありませんでした。
00:04:03これが私のセットアップです。送信側としてラップトップの画面を使い、実際の使用を想定して
00:04:09通常の腕の距離ほど離して配置しました。このセットアップでは、転送速度は秒間約3キロバイトに制限されました。
00:04:16送信されたフレームの約1%から2%しか実際にはデコードされていません。残りはキャプチャされて破棄されています。
00:04:23ここで私たちの前に立ちはだかる壁は3つあります。最大かつ最大のハードルは、フレームレートの不一致です。
00:04:30送信側は秒間60フレームで送信していますが、私のスマホのカメラは30フレームでキャプチャします。30フレームしか取得できないセンサーで
00:04:3860の異なる画像をサンプリングすることはできません。半分を見逃すだけならまだましですが、キャプチャされた
00:04:45各フレームの露光ウィンドウが画面上の2つの異なるQRコードにまたがってしまうためです。そのため、カメラはフレームをきれいに見逃すのではなく、2つをブレンドしてしまい、何もデコードできないものになってしまいます。
00:04:56main.tsファイルには、アプリがカメラに明示的に60フレームを要求した場合でも、iOSが暗黙的に秒間30フレームを配信するという注意書きさえあります。
00:05:07カメラは要求されたものを返してくれませんが、コードはすでに対処しています。
00:05:12同じファイルのもう少し下の方には、初めて試したときに私に起きたことを正確に予測しているコメントがあります。
00:05:19デフォルト（秒間60フレームで1フレームあたり2953バイト）は、近距離でのスマホ間デモ用に特別に調整されているということです。
00:05:29そして、同じ組み合わせでは、一般的なモニターを腕の距離で離して使用すると苦戦することが予想されます。
00:05:35言い換えれば、プロジェクトはあらかじめこうなると伝えてくれていたのです。私がコードをそこまでスクロールしていなかっただけでした。
00:05:41送信側では、60ヘルツのラップトップパネルでも逆の理由で同じ問題が発生します。LCDピクセルがグレーからグレーへ完全に色を遷移させるには時間がかかります。
00:05:51そのセトリングタイムがあるため、次のコードが上書きし始める前に、パネルが1つのコードに完全に到達していないことになります。
00:05:58したがって、ゴーストアーティファクトが発生します。そして第2の問題は、コード密度とカメラの解像度です。
00:06:042953バイトはQRバージョン40ですが、確実なデコードにはモジュールあたりおよそ3〜4個のカメラピクセルが必要であり、コード自体だけでもシャープなフォーカスで全体で600ピクセル以上になります。
00:06:20腕の距離で保持されたラップトップの画面がスマホのカメラフレームをそれほど多く満たすことはめったにありませんが、近距離のスマホ間であればファインダー全体を簡単に満たします。
00:06:30そして第3の問題は、明るさとコントラストです。これは二次的な問題であり、受信側の2値化スレッショルドが画像をきれいに処理するのに役立ちますが、フレームレートの不一致や小さすぎるコードを直すことはできません。
00:06:44それでは、今度は別のスマホからスマホへと同じ転送を試してみましょう。
00:06:50変わるのは送信側だけです。近くに保持された明るいOLEDの小さな画面が、受信側のスマホのフレーム全体を満たします。
00:06:58これでカメラは実際のフレームレートにより近づくことができます。
00:07:02コードが高解像度でフレームを満たし、戦うべきLCDのゴーストもありません。
00:07:07これが、READMEファイルの秒間128キロバイトという数値が実際に測定されたシナリオです。
00:07:14受信側のコードには、小さくても純粋に役立つ詳細もあります。
00:07:18キャプチャFPSとデコードFPSを別々に報告します。キャプチャは、カメラが物理的に何を見ているかを示します。
00:07:26デコードは、そのうちどれだけが実際に使用可能かを伝えます。
00:07:30これら2つの数値が乖離したとき、つまりキャプチャは正常なのにデコードが急降下するときは
00:07:35フレームの密度と、その範囲でカメラが実際に解像できるものとの間にミスマッチが生じていることになります。
00:07:42ラップトップからスマホへの転送が実際のユースケースである場合、解決策は送信側でこれら3つの変数を再調整することです。
00:07:50フレームあたりのバイト数を1465に減らします。これは、より大きく寛容なモジュールを持つ粗いQRバージョンに相当します。
00:07:59そして、カメラの30FPSの制限を意図的に下回る24まで送信FPSを下げます。
00:08:07これにより、フレーム同士が混ざり合うことなく、一度に1つずつ綺麗にサンプリングされます。
00:08:12ご覧のとおり、これらの数値を下げることで、はるかに大きなスループットが得られます。
00:08:16したがって、これは光ファイル転送が万能な解決策ではないことを示しています。
00:08:21使用しているハードウェアに応じて、すべてのユースケースで手動で微調整する必要があります。
00:08:26というわけで、皆さん。
00:08:27これがDecimanの概要です。
00:08:29全体として、これは掘り下げるのが純粋に楽しいプロジェクトでした。
00:08:32光ファイル転送は非常にクールな技術です。
00:08:36そして、ファウンテン符号の概念が実際のシナリオで応用されているのを見るのは本当に興味深かったです。
00:08:44このプロジェクトを探索している間、このようなツールを実際にどこで使うのだろうとも考えていました。
00:08:49明白な答えは、ネットワーク接続を意図的に完全に排除したいエアギャップ環境での転送でしょう。
00:08:57あるいは、古いハードウェアや組み込みシステムのように、BluetoothやWi-Fiすらないデバイスでしょうか。
00:09:04つまり、画面とカメラだけが頼りになる場所ならどこでもです。
00:09:10しかし、このツールについてどう思いますか？
00:09:11以前に光転送ツールを使ったことがありますか？
00:09:14これに対する実生活での応用例を見出せますか？
00:09:17下のコメント欄で教えてください。
00:09:19そして皆さん、このような技術的解説が気に入ったら、動画の下にある「いいね」ボタンを押して教えてください。
00:09:25また、チャンネル登録もお忘れなく。
00:09:28BetterStackのAndrusがお届けしました。次の動画でお会いしましょう。
00:09:34次の動画でお会いしましょう。