들어오는 BMP 이미지 스트림을 비디오로 표시 할 수 있습니까? (Android 앱)

Q : "이 순진한 솔루션이 가능할까요 ...?"

예.

_{당신은 또한 이것 에 대한이 책을 좋아할 것 입니다.}

Q : "... H264 / 5로 인코딩해야하나요?"

그 지옥은 달려 있습니다.

Given the said 20 Hz BMP-image ingress-rate, there are about 50 [ms] per image for all the Visual-part of the (principally distributed) MVC-system.

Within those said 50 ms, there ought be zero time wasted & nothing might ever block.

So the receiving-engine must keep steady data-flow of the ingress, no traffic overloads by any other, un-coordinated bandwidth ( memory, I/O, ... ) eater ( BMP-images' size was not mentioned so far ) and must provide some means, what will get fed into the presenter-engine in cases the "next"-data due to get shown is not complete or present at all.

So what about the compression?

Compression is a double-sided sword - you obviously reduce the data-volume (with some SER/DES-codecs even at a cost of loosing some part of the original data-richness, yes, exactly - knowingly lossy compression schemes ), while typically adding some additional data-re-framing and, perhaps, R/S or other "line-code" error-detection/error-correction, so the final volume of data-to-xmit need not be as small as the pure compression-part itself allows in theory.

Result?

All that comes at remarkable costs - both on SER/coder-side, here to get as little data into the (knowingly low-bandwidth / fuzzy as most often un-manageable latency ) transport, and on the decoder/DES-side.

So, given the 20 Hz refresh rate leaves not more than a total 50 ms for one frame-repaint, the lump sum of the receiver-engine processing and presenter-engine processing cannot spend more than those 50 ms per frame. Any decode-related and DESerialiser-related processing is a deciding factor on this.

Yet, one may succeed, if proper design & flawless engineering took place for doing this right & robust enough.

Check your target device for all of:

• transport resources limits
  (i.e. how much time get burnt & what resources get allocated / locked per arrival),
• memory-I/O
  (latency and memory-I/O concurrency limits for any interleaved data-flow patterns),
• cache-hierarchy
  (if present on a device) sizes, costs and I/O-limits),
• processing limits
  (if multicore, the more if NUMA, beware of non-uniform memory-I/O traps)
• presenter-engine hardware bottlenecks
  (memory-I/O, display device buffer-I/O limits and any other add-on latencies)

since any of these details may de-rail your smooth flow of (error-resilient) data to get finally presented on a target device in a due time for the wished to get target 20 FPS.

Good luck!

<sub>참고 :
소스에서 바로 데이터 감소를 활용할 수 있다면 모든 대상 발표자 엔진 이 B / W이고 컬러 풀 한 BMP를 "보내"지 않는다는 선험적으로 알고있는 경우와 같이 기회를 잡고 실행하십시오 . 모든 프레임 별 색상 표 및 높은 수준의 색상 프로필 트릭을 제거하고 대상 터미널에 대한 최악의 처리 및 지연 시간 한도 시나리오와 일치하는 적절한 크기의 원시 래스터 데이터 이상을 스트리밍하지 않습니다. 장치.
일반 BMP 데이터 형식 정의의 중복되고 주로 낭비되는 (반복적 인) 부분을 모두주의 깊게 검토하고 다시 방송하지 마십시오

.)</sub>