回答:
BLEは中程度の帯域幅のストリーミング（オーディオまたはビデオ）にも非常に適していません。これは、スリープ時間の長い、少数の小さなデータパケットの転送用に設計されているためです。これが、「低電力」ではなく「低エネルギー」と呼ばれる理由です。競合する標準に関して、小さなパケットのビットあたりのピコジュールの量を減らします。他の標準は、無線の効率が悪いためではなく、少なくとも無線トラフィックに比較的大きな変動がある場合でも受信機の電源が常にオンになっているため、および転送されたビットのかなりの部分がペイロードではなくオーバーヘッドであるため、主に多くの電力を使用します-プロトコルヘッダー、チェックサム、さらに空白スペース。BLEは、これらの不要な電力消費のほとんどを排除します。でも気にしてください トランシーバーがアクティブなときのトランシーバーの電力使用を魔法のように改善します。そして、ビデオ転送を行うとき、トランシーバーは常に電源が入っています。BLEの最大の利点を失います。
この設計上の選択は、あなたが好きなように少しのと本質的にオーバーヘッド削減するだけでなく、それは持っていないということになります任意のストリーミング機能が内蔵されたネイティブにパケットの再結合、遅延確認応答および非同期転送のような。実際には何も組み込まれていません。BLEは、nRF24とTI CC2x00を除いて、ワイヤレスインターフェイスに到達するのと同じくらい生のままです。その結果、ソフトウェアでこれを行う必要があります（マイクロコントローラーまたはユーザーデバイスのいずれかで）。これは、Bluetooth 3.0 EDRなどのハードウェア機能を備えた専用プロトコルを使用する場合よりも、はるかに多くのエネルギーを使用します。 Wi-Fi。
これにより、オーディオタイプのデータレート以上に入ると、Bluetooth Low Energyは実装によってはBluetooth 3.0よりも約2倍効率が悪くなり、メガビット範囲に入ると実質的にWiFiよりも効率が悪い。これがWiFiが存在する理由です。現在、両方の規格のトランシーバーは非常に同等ですが、それは間違いなく無線範囲です。WiFiにはオプションのMIMOと多様性があります。
したがって、少なくともビデオでは、Bluetoothが課す非常に制限された帯域幅と範囲の制限を考慮しない場合でも、この方法では低電力ビデオ転送の目標を達成できない場合があります。
まあ、100kbpsなら、低品質のビデオをポストスタンプのサイズでストリーミングできるかもしれません:-)
精度がなければ、H264で30fpsのHD（フルHDでもない）が必要だと想像します。平均モーション（ファクター2）で、おおよそのビットレートは次のようになります。
（1280px * 720px）* 30fps * 2 * 0.07〜= 3800kbps
したがって、これを38倍に減らす必要があります（少なくとも！）。
約320x200 @ 15fpsで落ち着いても、まだ少し上です（理論的な帯域幅で、期待は少ない）。
すべてのテストは2000オクテット/秒未満で終了しました
前提条件：
Android <-> Linux＆Bunget、Android <-> Linux＆Bleno、Android <-> ST-Micro Nucleus + blueNRGの間で行ったすべてのテスト。LinuxおよびNUCLEOはGATTサーバーを実行しています。Androidは主にGATTクライアントを実行しています。
Android-> GATTサーバーNOTIFICATION / WRITE NO RESPONSEは、13ミリ秒を超えて送信することはできません。その後、13ミリ秒を超えるパケット損失が発生しました。
サーバー-> Android NOTIFICATION / WRITE NO RESPONSEは15ミリ秒を超えて送信できない
これにより、最大1000ms / 13ms-> 77回/秒、20バイト= 1500オクテット/秒になります。