BLE only has a data payload of 100Kbps so I was wondering if it is possible to stream a live video using Bluetooth Low Energy?
Classic Bluetooth 4.0 has a data payload of 2Mbps which makes it easier to transmit the video but I am more concern about the total power so want to implement the BLE. Can I get the same result when I use BLE to stream the video?
BLE is very unsuitable for even medium bandwidth streaming (audio or video), because it is designed for transfer of few and small data packets with lots of sleeping time in between. This is why it is called 'low energy' and not 'low power' - it reduces the amount of picojoules per bit for small packets with respect to competing standards. Other standards mostly use more power not because they have less efficient radios, but because at least the receiver is constantly powered up even when there are comparatively huge lulls in radio traffic, and because a significant portion of the transferred bits are not payload but instead overhead - protocol headers, checksums, even just blanking space. BLE eliminates most of these unnecessary power draws. But mind you, it doesn't magically improve power use of the transceivers when they are active. And when doing video transfer, the transceivers are constantly powered up. You lose the biggest advantage of BLE.
This design choice reduces overhead to essentially as little as you like, but also makes it that it does not have any streaming facilities built-in natively like packet recombination, delayed acknowledgement and asynchronous transfers. You actually don't have anything built in, BLE is as raw as you can get to a wireless interface, barring maybe nRF24 and TI CC2x00. As a result, you'll need to do this in software (either on a microcontroller or on your user device) and this uses incredibly much more energy than if you use a purpose-built protocol with hardware facilities for this like Bluetooth 3.0 EDR or WiFi.
This leads to the somewhat counterintuitive notion that once you start getting into audio-type data rates and above, Bluetooth Low Energy becomes, depending on your implementation, about 2x less efficient than Bluetooth 3.0, and when you get into the megabit range it is substantially less efficient than WiFi. This is why WiFi exists - that and arguably wireless range, although nowadays transceivers for both standards are very much equivalent. WiFi just has optional MIMO and diversity.
So even when not taking into consideration the - at least for video - very restrictive bandwidth and range limits that Bluetooth imposes, you may not achieve the goal of low power video transfer with this method.
Well, with 100kbps, you may be able to stream a low quality video the size of a post stamp :-)
Without any precision, I will imagine you want HD (not even full HD) @30fps in H264, with average motion (factor 2), an approximate bitrate estimation could be :
(1280px*720px)*30fps*2*0.07 ~= 3800kbps
So you have to reduce this by a factor 38 (at least !).
Say you settle for ~320x200 @ 15fps, you're still a little above (the theoretical bandwidth, expect less).
All my test ended up at below 2000 octets/second
Prerequisites:
All tests I've done between Android <-> Linux & Bunget, Android <-> Linux & Bleno, Android <-> ST-Micro Nucleus+ blueNRG. Linux & NUCLEO running GATT servers. Android mainly running GATT client.
Android->GATT server NOTIFICATION/WRITE NO RESPONSE cannot be sent often than 13 ms. Ofthen than 13ms enaded up in packet lost.
Server->Android NOTIFICATION/WRITE NO RESPONSE cannot be sent often than 15 ms
That leads up to 1000ms/13ms - > 77 times / second of 20 bytes = 1500 octets/second.
