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.