VideoEndWatchdog DECODE_OVERLOAD 반복 stall 미발화 BUG DESIGN OPEN

증상 BUG

세션별 케이스 요약

아동303 25회기 · 2026-06-16 06:33 KST

로그: 6-019ecf1f-528a-7498-a6f5-5a503e103772_0_06168ae1-…-8fca0dcf3266.json  ·  디바이스: 8GB / 6코어 (정상 기기)

아동049 24회기 · 2026-06-16 20:00 KST

출처: Grafana ppi-socket Loki 로그 (LogRocket 파일은 부분/혼합 로그로 분석 불가, 소켓 서버 로그로 재조회)  ·  roomId: c53de64f-b555-43f8-981a-bae18acf9a0d_24  ·  디바이스: 8GB / 6코어 (정상 기기)

아동074 2회기 · 2026-06-16 10:00 KST

로그: 6-uuid-0424_0_c0fa9243-…-c660ac550477.json  ·  디바이스: 4GB / 8코어 (저사양 판정 경계 ≤4GB)

실패 타임라인 (아동303 25회기 대표 케이스)

arm() 시점부터 첫 tick까지 140초 대기, 첫 tick 이후 호스트 개입까지 단 6초. 이 6초 동안 maxStall(30s)이 누적될 수 없었음.

종료 경로 발화 여부

원인 분석 ROOT CAUSE

1) arm() 첫 tick 스케줄링 방식

VideoEndWatchdog.arm()은 정상 재생 중 불필요한 폴링을 피하려고 첫 tick을 예상 종료 시각에 맞게 단 하나만 예약한다. 그 이후부터 1초 폴링을 시작한다.

// video-end-watchdog.ts  arm()
const firstDelayMs = hasDuration
  ? Math.max(0, (s.duration - s.currentTime) * 1000)  // ← 예상 종료 시점까지 잠들기
  : this.pollIntervalMs;
this.scheduleNext(firstDelayMs);

이 전략은 정상 재생에는 효율적이지만, DECODE_OVERLOAD로 영상이 늦어지는 경우 첫 tick이 발화할 때는 이미 stall이 한참 진행된 상황이다.

2) stall 감지 방식: 연속 stall만 측정

tick()의 maxStall 체크는 마지막 진행 이후 연속 정지 시간만 측정한다.

// video-end-watchdog.ts  tick()
if (s.currentTime > this.lastTime + PROGRESS_EPSILON_SEC) {
  this.lastTime = s.currentTime;
  this.lastProgressAt = this.now();  // ← canplay 후 조금이라도 진행하면 리셋
  this.progressed = true;
} else if (this.progressed) {
  const stalledMs = this.now() - this.lastProgressAt;
  if (remaining <= this.nearEndWindowSec && stalledMs >= this.nearEndStallMs) { fire(); }
  if (stalledMs >= this.maxStallMs) { fire(); }  // 30s 연속 정지
}

3) DECODE_OVERLOAD의 stall-resume 사이클이 측정을 방해

DECODE_OVERLOAD는 완전 정지가 아니라 짧은 stall(~1.6s)과 resume이 반복되는 패턴이다. 매 resume 직후 currentTime이 미세하게라도 진행하면 lastProgressAt이 리셋되어 누적 stall이 쌓이지 않는다.

4) 케이스별 수치 비교

설계 한계 DESIGN

VideoEndWatchdog은 두 가지 케이스를 커버한다:

• 케이스 A: 영상이 끝에 도달했으나 ended 이벤트가 누락됨 → endThreshold(0.3s) 체크로 처리
• 케이스 B: 영상이 어딘가에서 완전히 멈춤 → maxStall(30s) 연속 체크로 처리

개선 방안

방안 1 (권장) — wall clock drift 감지 추가

arm() 시점의 wall clock과 currentTime을 기록해두고, tick마다 "지금쯤이면 영상이 끝났어야 한다"를 체크한다.

// arm() 에 추가
this.armWallClockMs = this.now();
this.armVideoTimeSec = s.currentTime;

// tick() 에 추가 (endThreshold 체크 직후)
const wallElapsedSec = (this.now() - this.armWallClockMs) / 1000;
const expectedElapsedSec = s.duration - this.armVideoTimeSec;
const DRIFT_MARGIN_SEC = 30;  // 예상 종료 시각 + 30s 초과 시 발화

if (this.progressed && wallElapsedSec > expectedElapsedSec + DRIFT_MARGIN_SEC) {
  this.fire();  // "wall clock 기준 오버듀" 발화
  return;
}

방안 2 — 누적 stall 시간 측정

연속 stall이 아닌 총 stall 누적 시간을 별도로 추적하여 임계치 초과 시 발화.

// tick() — stall 구간마다 누적
if (currentlyStalled) {
  this.totalStalledMs += tickElapsedMs;
}
if (this.totalStalledMs >= CUMULATIVE_STALL_THRESHOLD_MS) {
  this.fire();
}

방안 3 — DECODE_OVERLOAD 카운터 기반 조기 경보

meet-video.tsx에서 DECODE_OVERLOAD 횟수를 카운팅하여 일정 횟수 초과 시 Watchdog의 polling 간격을 단축하거나 별도 타이머를 시작. 근본 해결책은 아니지만 기존 구조를 유지하면서 부분 보완 가능.

로그 보강 (진단 목적)

Watchdog tick이 발화했으나 아무 조건도 충족 못 해 통과된 경우, 현재는 로그가 전혀 없다. tick 발화 로그 추가 시 "Watchdog이 동작은 했는데 왜 발화 안 했냐" 원인 추적이 용이해진다.

// tick() 마지막에 추가
logger.debug("Watchdog tick: no fire", {
  remaining, stalledMs, progressed: this.progressed, wallElapsedSec
});

관련 문서

• 영상 currentTime 앞으로 점프 (SEEK_REBUFFER) → near-end 조기 종료 — 정반대 실패 모드(끝에 너무 일찍 도달) (2026-07-16)
• 영상종료 자동전환 미발생 watchdog 분석 — duration timeout fallback isPlaying 가드 조기 종료 (2026-05-22)
• 노트북/데스크탑 DECODE_OVERLOAD 해결 (PR #651, PPI-975)
• 영상 종료 이벤트 미발생 — NAVER 인앱 브라우저 분석