갤럭시 탭 S10 FE simulcast 인코딩 부하 검증 — 레이어별 로깅 + 1레이어 토글 검증 도구

한 줄 요약

배경 · 가설

아동 단말(S10 FE)은 수업 중 다음을 동시에 수행한다:

• 카메라 simulcast 3레이어 인코딩 (use-mediasoup-producer.ts 카메라 producer, 100k·300k·900k)
• 마이크·AI 오디오 인코딩
• OpenAI Realtime 세션
• 활동 영상 디코딩/재생 (meet-video.tsx)
• WebRTC/mediasoup 송수신

추가한 로깅 검증 신호

1. 인코딩 시작 시점 (1회) — [SIMULCAST-LOAD] Camera encoding config

레이어 구성, 원본 트랙 해상도/fps, 단말 식별 정보를 기록한다.

• encodings / layerCount: simulcast 설정
• sourceTrack: 원본 카메라 width/height/frameRate
• userAgent, hardwareConcurrency: 그 단말이 실제 S10 FE인지·CPU 코어 수 확인

2. 주기 측정 (2초마다) — [SIMULCAST-LOAD] Camera encoder stats

producer.getStats()의 outbound-rtp 통계를 레이어(ssrc/rid)별로 읽고, totalEncodeTime·framesEncoded의 구간 증가분으로 프레임당 인코딩 시간을 계산한다(누적값 아님 → 실시간 부하).

// 부하 걸린 상태 예시
[SIMULCAST-LOAD] Camera encoder stats {
  cpuLimited: true,                    ← 부하 O
  totalEncodeMsPerFrame: 28.5,         ← 3레이어 합산 부하
  activeLayers: 3,
  layers: [
    { fps: 12, encodeMsPerFrame: 14.2,
      qualityLimitationReason: "cpu",
      powerEfficientEncoder: false }   ← SW 인코딩 + CPU 제한
  ]
}

1레이어 전환 토글 A/B 비교

테스트 모드 디버그 패널(GuestDebugPanel)에 Camera Simulcast 1 Layer / 3 Layers 버튼을 추가했다. 클릭하면 카메라 producer를 닫고 새 encodings로 재생성한다.

• 3 Layers(기본): 100k(÷4) · 300k(÷2) · 900k
• 1 Layer: [{ maxBitrate: 900000 }] 단일 고화질만
• 전환 시 [SIMULCAST-LOAD] Switching camera simulcast layers to N 로그

노출 경로: use-mediasoup-producer → use-guest-page-session → guest-layout → GuestDebugPanel. 테스트 모드(isTestMode)에서만 노출되어 운영 게스트에는 보이지 않는다.

검증 절차 (A/B)

1. 3레이어 측정: [SIMULCAST-LOAD] Camera encoder stats에서 cpuLimited·totalEncodeMsPerFrame·레이어별 fps를 10~20초 안정화 후 기록
2. 1 Layer 버튼 클릭 → producer 재생성
3. 1레이어 측정: 같은 로그 재확인 후 비교

DECODE_OVERLOAD · 업링크 stall 연관성 분석

코드 확인 결과 공통 근본 원인(단말 리소스 포화)을 공유하지만 코드상 직접 인과는 없는 독립 증상이다.

↔ DECODE_OVERLOAD : 강함 (CPU/코덱 경합)

• DECODE_OVERLOAD(meet-video.tsx:553)는 버퍼는 1초 이상 충분(bufferedAheadSec>1)한데 프레임을 못 따라 디코딩(droppedVideoFrames>10)하는 로컬 디코딩 부하 신호
• utils.ts:44 주석이 직접 명시: "수업 중 WebRTC + 영상 디코드 동시 부하를 못 버텨 DECODE_OVERLOAD 발생"
• Android는 HW 코덱 인스턴스가 제한적 → 인코더 3개 + 활동영상 디코더가 코덱 HW/CPU 경합, SW 폴백 시 CPU 급증 → 디코드 굶김 = DECODE_OVERLOAD 시그니처

↔ socket.io 업링크 stall : 약함/간접 (대역폭 경합)

• 업링크 stall(socket-uplink-stall-detector.ts)은 5초 ack 타임아웃으로 "연결 살았는데 송신 정체"를 잡는 거친 네트워크 신호
• 인코딩은 보통 메인스레드 밖 → CPU 부하가 직접 emit을 5초 막긴 어려움. 연결 고리는 주로 업링크 대역폭: 3레이어(~1.3Mbps) vs 1레이어(~0.9Mbps), 모바일 업링크 좁으면 bufferbloat/혼잡 → ack 지연 가능

변경 파일 (브랜치 test/simulcast-load)

관련 문서

• 카메라 인코딩 경량화 — simulcast 고화질 레이어 낭비 개선 (개선 방안)
• 고사양 240Hz 노트북 DECODE_OVERLOAD — present 파이프라인 stall 분석
• DECODE_OVERLOAD 발생 감소 — 인코딩 파라미터 및 lowPerf 기준 개선
• 자동전환 미반영 — 게스트 socket.io 업링크 26초 stall 원인 분석 및 로깅