BLE 非常不适合中等带宽的流媒体（音频或视频），因为它是为传输少量和小型数据包而设计的，中间有很多睡眠时间。这就是为什么它被称为“低能量”而不是“低功率”的原因 - 它相对于竞争标准减少了小数据包的每比特皮焦耳量。其他标准大多使用更多的功率，不是因为它们的无线电效率较低，而是因为即使在无线电流量中存在相对较大的停顿时，至少接收器也会不断加电，并且因为传输的很大一部分比特不是有效载荷而是开销- 协议头、校验和，甚至只是空白。BLE 消除了大部分不必要的功耗。但请注意，它没有 t 在收发器处于活动状态时神奇地提高了收发器的功耗。在进行视频传输时，收发器会不断通电。你失去了BLE的最大优势。

这种设计选择基本上可以将开销减少到您喜欢的程度，但也使其本身没有任何内置的流媒体设施，如数据包重组、延迟确认和异步传输。您实际上没有内置任何东西，BLE 与无线接口一样原始，除了 nRF24 和 TI CC2x00。因此，您需要在软件中执行此操作（在微控制器上或在您的用户设备上），这比使用带有硬件设施的专用协议（如蓝牙 3.0 EDR 或无线上网。

这导致了一种有点违反直觉的概念，即一旦您开始使用音频类型的数据速率及以上，根据您的实施，低功耗蓝牙的效率将比蓝牙 3.0 低约 2 倍，而当您进入兆比特范围时，它会大大降低效率不如 WiFi。这就是 WiFi 存在的原因 - 可以说是无线范围，尽管现在两种标准的收发器非常等效。WiFi 仅具有可选的 MIMO 和多样性。

因此，即使不考虑 - 至少对于视频 - 蓝牙强加的非常严格的带宽和范围限制，您也可能无法使用这种方法实现低功耗视频传输的目标。

好吧，使用 100kbps，您也许可以流式传输邮票大小的低质量视频 :-)

如果没有任何精度，我会想象你想要 H264 中的高清（甚至不是全高清）@30fps，平均运动（因子 2），大概的比特率估计可能是：

(1280px*720px)*30fps*2*0.07 ~= 3800kbps

因此，您必须将其减少 38 倍（至少！）。

假设您满足于 ~320x200 @ 15fps，您仍然略高于（理论带宽，预计更少）。

我所有的测试都以低于 2000 字节/秒的速度结束

先决条件：

• Android：Nexus Gallaxy Tab 7 Android 6.0.1（GATT 客户端）
• Linux：R-PI + BCM20702A0（GATT 服务器）
• NUCLEO-F411RE：BlueNRG（关贸总协定服务器）

我在 Android <-> Linux & Bunget、Android <-> Linux & Bleno、Android <-> ST-Micro Nucleus+ blueNRG 之间完成的所有测试。运行 GATT 服务器的 Linux 和 NUCLEO。Android 主要运行 GATT 客户端。

• Android->GATT 服务器 NOTIFICATION/WRITE NO RESPONSE 不能经常发送超过 13 毫秒。通常超过 13 毫秒的数据包丢失。

• Server->Android NOTIFICATION/WRITE NO RESPONSE 不能经常发送超过 15 毫秒

• 双方，READ INDICATOR，因为不能经常调用超过 15..20 毫秒。

这导致高达 1000 毫秒/13 毫秒 - > 20 字节的 77 次/秒 = 1500 个八位字节/秒。