저사양 Android 720p 컨텐츠 DECODE_OVERLOAD — lowPerf 플래그 미배선 두 실패 모드원인규명구현완료·검증중

요약 (TL;DR)

시간순 인과 다이어그램

세션 환경 (확정)

근본 원인 1 — 컨텐츠 영상이 720p로 재생됨 확신 높음

isLowPerformanceDevice는 guest-layout-content.tsx에서 단 한 곳에서만 쓰인다 — 아바타에, 그것도 split 모드에서만.

// guest-layout-content.tsx:203 — 유일한 사용처
<MeetAvatar isLowPerformanceDevice={isSplitMode && isLowPerformanceDevice()} />

// MeetVideo / MeetImage 에는 전달되지 않음 → props.isLowPerformanceDevice = undefined
<MeetVideo ... />   // isLowPerformanceDevice 없음
<MeetImage ... />   // isLowPerformanceDevice 없음

그 결과 meet-video.tsx는 getResourceUrl(fileName, undefined)를 호출하고, 서버 /api/resources/urls는 480p 변형 대신 원본(720p)을 반환한다.

720p가 왜 2GB 기기를 무너뜨리나

두 파일의 실질 차이는 해상도(+연동 비트레이트)뿐. 720p는 저사양 디코더에 여유가 0이라 프레임을 버릴 수밖에 없다.

두 실패 모드 — 영상별 디코더 상황 로그 확증

아동측 MEET_VIDEO 전체 타임라인(2400 엔트리 전체 로그)에서 영상별로 두 가지 뚜렷이 다른 실패가 관측됐다.

① 진행성 과부하 (인트로 story_01, 아바타 없음)

② 하드 프리즈 (아바타 있는 영상)

waitingCase 판정 로직

// meet-video.tsx:654-677 diagnoseWaitingCase
if (document.visibilityState === "hidden") return "TAB_BACKGROUNDED";
if (isRecentSeek) return "SEEK_REBUFFER";
if (corruptedVideoFrames > 0) return "CODEC_CORRUPT";
if (bufferedAheadSec > 1 && droppedVideoFrames > 10) return "DECODE_OVERLOAD";  // 진행성 과부하
if (bufferedAheadSec > 1) return "DECODE_OVERLOAD";                          // 데이터 있는데 정지 = hang 포함
if (video.currentTime < 1) return "INITIAL_LOAD";
return isBlob ? "BLOB_READ_STALL" : "NETWORK_STALL";

진행자 녹화 멈춤 — 별개 원인(버퍼 starvation) 확신 중~높음

서버 세션 녹화는 오디오 전용 mp3(아동 마이크 + 핑퐁이 TTS만, recordingManager.ts)라 비디오 트랙이 없다. 따라서 "진행자 녹화 영상"은 서버 녹화물이 아니라 진행자 화면 직접 녹화이고, 모니터는 컨텐츠 mp4를 자기 기기에서 독립 로컬 디코드한다.

부수 요인 — 네트워크 저하

해결책 구현 완료 (PPI-1143)

실제 구현 (배선)

구현 내역 PPI-1143

최종 머지에 남은 코드는 아래 3파일뿐이다(검증용 HUD/오버라이드는 제거 — 아래 표 하단 참조).

실기기 검증 — 아바타 pause 2026-07-21

동일 환경에서 아바타 스텝 → 영상 스텝(아바타 숨김) 이동 후, avatarPause OFF vs ON을 HUD로 실측. 핵심 지표는 전체 디코드 fps 합(= 실제 디코딩 중인 프레임/초).

노트북 (Chrome · mem 32GB · core 14)

iPad (WebKit)

검증 도구 — 디코드 부하 HUD 검증 후 제거됨

배포 없이 실기기에서 A/B 하기 위한 런타임 오버라이드 + 화면 내 수치 오버레이. 우선순위: URL 쿼리 > localStorage > 기본값.

// 진입 (mode=test면 세션까지 파라미터 전파)
/client-guest?mode=test&debugDecode=1

// 파라미터
debugDecode=1        # HUD 표시 (필수)
lowPerf=on|off       # 480p 강제 ON / 720p 강제 (없으면 auto 판정)
avatarPause=on|off   # 숨김 아바타 pause 최적화 (기본 on)

HUD 하단 토글 버튼은 localStorage에 기록 후 현재 URL을 새로고침하므로, 세션 안에서 파라미터 재입력 없이 즉시 A/B 가능하다.

HUD 지표 읽는 법

• 컨텐츠 해상도 854x480(480p✓) / 1280x720 — 480p 실제 적용 확증 (videoWidth×Height는 거짓 없음)
• 아바타 fps합 / 전체 디코드 fps 합 — pause 실효 판단의 핵심. .paused(재생중 개수)가 아니라 이 실측 fps로 봐야 한다 (일부 브라우저는 재생 플래그만 유지하고 디코드는 멈추기도 함)
• 컨텐츠 드롭% — 진행성 과부하 판별. 저사양 기기에서만 유의미(고사양은 ≈0)

판별법 (다음 동일 신고 시)

• "멈춤·끊김 + 위치 옮겨도 재발" 신고 → LogRocket export의 decode.droppedVideoFrames / deviceMemoryGB 확인
• 영상별 드롭 패턴으로 실패 모드 구분: 지속 高드롭+진행 = 진행성 과부하 / 조기 정지+드롭≈0 = 하드 프리즈(hang)
• RESOURCE_CACHE 요청 파일명에 _480p 유무로 480p 실제 적용 여부 확인 (미배선이면 720p)
• 진행자 녹화 멈춤은 bufferedAheadSec/dropped로 디코드 과부하 vs 버퍼 starvation 구분, 게스트와 독립
• 아바타 pause 실효를 재검증할 땐 실측 fps(requestVideoFrameCallback)로 봐야 한다 — .paused 재생중 개수는 브라우저가 재생 플래그만 유지할 수 있어 신뢰 불가 (검증 시 HUD로 확인, 위 "검증 도구" 참조)

관련 문서

• DECODE_OVERLOAD 인코딩·lowPerf 개선방안
• 노트북/데스크탑 DECODE_OVERLOAD 해결 (PR #651, PPI-975)
• MSI 240Hz 노트북 DECODE_OVERLOAD present stall 분석
• VideoEndWatchdog DECODE_OVERLOAD 반복 stall 미발화 원인 분석