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.

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.

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.