1. "MJPEG은 데이터 사용랑 많음" (vs MJPEG)
"지난 POC 때 끊김이 심했던 이유는 MJPEG이 1초에 60장씩 전체 사진을 보내기 때문.
→ 이는 마치 1초에 60번씩 고화질 이미지를 다운로드하는 것과 같아서, 네트워크가 조금만 불안해도 바로 멈춤.
반면 H.264(Native) 방식을 쓰면 데이터 소모량을 줄일 수 있어 끊기지 않음"
2. "WebRTC 라이브러리는 우리 앱에 너무 무거움 (vs WebRTC Lib)
"물론 WebRTC가 표준이지만, GoogleWebRTC 라이브러리를 통째로 넣으면 앱 용량이 50MB 이상 늘어남. 용량 + 빌드시간 증가, 외부 의존성이 커지는 단점.
→ 우리는 단순히 '작은 PIP 화면'만 보내면 되는데, 오디오 믹싱이나 복잡한 NAT 통과 기능까지 포함된 거대 라이브러리를 넣는 건 배보다 배꼽이 더 큼"
3. "우리는 이미 '우리만의 WebRTC'를 가지고 있음" (Why Native?)
"이미 구축한 NetworkKit(P2P/WebSocket)이 WebRTC의 연결(Signaling) 역할을 완벽히 수행하고 있음. 여기에 애플이 기본 제공하는 VideoToolbox만 얹으면, 외부 라이브러리 하나 없이 WebRTC와 똑같은 성능(H.264 압축)을 낼 수 있음.
→ 이게 가장 가볍고(0MB 추가), 빠르고(하드웨어 가속), 구조에 딱 맞는 방법."
| 비교 항목 | 1. MJPEG (기존 POC) | 2. WebRTC (외부 라이브러리) | 3. Native H.264 (제안) |
|---|---|---|---|
| 압축 방식 | 매 프레임 전체 전송 (I-Frame Only) | 차이값 전송 (Inter-frame) | 차이값 전송 (Inter-frame) |
| 대역폭 (30fps) | 매우 높음 (~1.5 MB/s) | 낮음 (~0.1 MB/s) | 낮음 (~0.1 MB/s) |
| 앱 용량 증가 | 없음 (0 MB) | 큼 (+50~100 MB) → 외부 라이브러리 사용하기 때문 빌드 속도도 느려지고 의존성 생김 | 없음 (0 MB) |
| 네트워크 통합 | 쉬움 | 별도 채널 필요 | 기존 패킷 활용 - ping/pong 시그널링 활용 |
| 하드웨어 가속 | 지원 안 함 (CPU 부하 큼) | 지원함 | 지원함 (OS 레벨 최적화) |
| 결론 | ❌ 비효율적 (폐기) | ⚠️ Overkill (과잉) | ✅ Best Fit (최적) |
Native H.264 VideoToolbox 사용