BLE 또는 클래식 Bluetooth 4.0을 사용하여 비디오를 스트리밍 하시겠습니까?


10

BLE에는 100Kbps의 데이터 페이로드 만 있으므로 Bluetooth Low Energy를 사용하여 라이브 비디오를 스트리밍 할 수 있는지 궁금합니다.

Classic Bluetooth 4.0에는 2Mbps의 데이터 페이로드가있어 비디오를보다 쉽게 ​​전송할 수 있지만 총 전력에 대해 더 관심이 있으므로 BLE를 구현하고 싶습니다. BLE를 사용하여 비디오를 스트리밍 할 때 동일한 결과를 얻을 수 있습니까?


1
이 질문은 2M (bps) PHY를 가진 BLE 컨트롤러 용 Bluetooth 5에서는 구식입니다.
ZX9

답변:


12

BLE는 중간 대역폭 스트리밍 (오디오 또는 비디오)에도 적합하지 않습니다. 중간에 수면 시간이 많은 소수의 작은 데이터 패킷을 전송하도록 설계 되었기 때문입니다. 이것이 저전력이 아니라 '저에너지'라고 불리는 이유입니다. 경쟁 표준과 관련하여 작은 패킷의 비트 당 피코 볼의 양을 줄입니다. 다른 표준은 무선의 효율이 떨어지기 때문에가 아니라 무선 트래픽에 비교적 많은 양의 급등이 있더라도 수신기의 전원이 항상 켜져 있고 전송 된 비트의 상당 부분이 페이로드가 아니라 오버 헤드이기 때문에 더 많은 전력을 사용합니다. -프로토콜 헤더, 체크섬, 심지어 빈 공간. BLE는 이러한 불필요한 전력 소비를 대부분 제거합니다. 하지만 신경 쓰지 마 t 트랜시버가 활성화되어있을 때 전력 사용을 마술로 개선합니다. 비디오 전송을 수행 할 때 트랜시버의 전원이 지속적으로 켜집니다. BLE의 최대 장점을 잃습니다.

이 디자인 선택은 오버 헤드를 원하는만큼 줄여 줄뿐 아니라 패킷 재조합, 지연된 승인 및 비동기 전송과 같은 기본적으로 내장 된 스트리밍 기능을 갖지 않도록합니다 . 실제로 내장 된 것은 없으며 BLE는 nRF24 및 TI CC2x00을 제외하고 무선 인터페이스를 사용할 수있는만큼 원시적입니다. 결과적으로 소프트웨어 (마이크로 컨트롤러 또는 사용자 장치)에서이 작업을 수행해야하며, Bluetooth 3.0 EDR 또는 와이파이.

이는 오디오 유형의 데이터 전송률 이상을 시작하면 구현에 따라 Bluetooth 저에너지가 Bluetooth 3.0보다 약 2 배 덜 효율적이며 메가 비트 범위에 도달하면 상당히 직관적이라는 다소 반 직관적 인 개념으로 이어집니다. WiFi보다 효율성이 떨어집니다. 이것이 WiFi가 존재하는 이유입니다. 요즘에는 두 표준에 대한 트랜시버가 거의 동등하지만 무선 범위는 물론 무선 범위입니다. WiFi에는 옵션 MIMO 및 다양성이 있습니다.

따라서 Bluetooth가 부과하는 매우 제한적인 대역폭 및 범위 제한을 고려하지 않더라도이 방법으로는 저전력 비디오 전송의 목표를 달성하지 못할 수 있습니다.


8

100kbps를 사용하면 포스트 스탬프 크기의 저품질 비디오를 스트리밍 할 수 있습니다 :-)

정밀도가 없으면 H264에서 30fps의 HD (풀 HD는 아님)가 평균 모션 (요인 2) 인 경우 대략적인 비트 전송률 추정은 다음과 같습니다.

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

따라서 이것을 38 배 이상 줄여야합니다 (적어도!).

~ 320x200 @ 15fps에 만족한다고 가정하면 여전히 약간 높습니다 ( 이론적 대역폭은 적습니다).


1
평균 운동 계수는 무엇입니까? 그리고 0.07의 가치는 무엇입니까?
m.Alin

@ m.Alin 아마도 .07은 오디오일까요?
ZX9

0

내 모든 테스트는 2000 옥텟 / 초 미만으로 끝났습니다.

전제 조건 :

  • Android : Nexus Gallaxy Tab 7 Android 6.0.1 (GATT 클라이언트)
  • Linux : R-PI + BCM20702A0 (GATT 서버)
  • NUCLEO-F411RE : BlueNRG (GATT 서버)

Android <-> Linux & Bunget, Android <-> Linux & Bleno, Android <-> ST-Micro Nucleus + blueNRG 사이에서 수행 한 모든 테스트. GATT 서버를 실행하는 Linux 및 NUCLEO Android는 주로 GATT 클라이언트를 실행합니다.

  • Android-> GATT 서버 NOTIFICATION / WRITE NO RESPONSE는 13ms보다 자주 보낼 수 없습니다. 패킷 손실로 인해 13ms 이상이 발생했습니다.

  • 서버-> Android NOTIFICATION / WRITE NO RESPONSE는 15ms보다 자주 보낼 수 없습니다

  • 15..20 ms보다 자주 호출 될 수없는 양측 READ INDICATOR.

이는 최대 1000ms / 13ms-> 77 회 / 초의 20 바이트 = 1500 옥텟 / 초입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.