고사양 240Hz 노트북 DECODE_OVERLOAD — 디코드가 아니라 present 파이프라인 stall 분석 완료

마지막 업데이트 2026-07-22

유형: VOC "영상 재생 끊김" 기기: MSI Vector GP66 12UEO 영상: video_music_say_low_0 발생일: 2026-06-11 분석일: 2026-06-17

한 줄 결론

DECODE_OVERLOAD 라벨은 오해다. 고사양 노트북(RTX 3060)에서 30fps baseline 720p는 디코드 부하가 사실상 0(순수 SW로도 297배속). 실제로는 게스트 페이지가 동시에 돌리는 미디어 작업(카메라 인코딩·아바타 디코드·STT 오디오·240Hz 합성)에 디코드→표시(present) 파이프라인이 자원을 빼앗겨, 30fps 영상을 실시간으로 공급하지 못하고 약 67% 속도로 stall하며 끊긴 것. 파일·코덱·네트워크·하드웨어 스펙은 모두 정상.

이 문서는 특정 VOC 케이스(MSI 240Hz OLED 노트북)에 대한 정량 증거와 고주사율 각도를 더한 케이스 스터디다. DECODE_OVERLOAD가 meet-video.tsx의 catch-all 오분류라는 일반 분석은 관련 문서 참고.

기기 사양 (확정)

모델MSI Vector GP66 12UEO QHD OLED
CPUIntel Core i7-12650H (16스레드) — 로그 hardwareConcurrency: 16 일치
GPUNVIDIA RTX 3060 Laptop (140W TGP)
RAM8GB — 로그 deviceMemoryGB: 8 일치
디스플레이15.6" QHD(2560×1440) OLED, 주사율 240Hz
저사양 기기가 전혀 아니다. 따라서 디코드 절대 성능 부족은 원인이 될 수 없다. 240Hz라는 고주사율이 핵심 변수.

로그 증거 — 핵심은 "재생 속도" BUG

같은 영상 재생 중 [MEET_VIDEO] Video waiting [DECODE_OVERLOAD] 가 약 5초 간격으로 반복. 두 시점을 비교하면 결정적 사실이 나온다.

시각(wall)currentTimetotaldroppedbufferedAheadreadyState
11:06:52.76731.4129139 (1.0%)33.555s2
11:06:57.68734.711101153 (5.2%)30.256s2
11:07:22.43351.6011520251 (16.5%)13.366s2

① 영상이 실시간을 못 따라간다 (실제 stall)

로그1 → 로그2 사이 실제 시간 경과 4.92초(57.687 − 52.767), 영상 진행 3.30초(34.711 − 31.412).

→ 재생 속도 = 3.30 / 4.92 ≈ 67%

영상이 실시간의 약 67% 속도로밖에 안 나간다 = 멈췄다 가는 stall. VOC "끊김"과 정확히 일치.

② 드랍이 가속된다

누적 드랍: 1.0% → 5.2% → 16.5%로 악화. 로그1→로그2 구간만 보면 새 프레임 98개 중 44개 드랍 = 그 5초 창에서 ~45% 드랍. 31초 지점엔 거의 깨끗했다가 빠르게 무너진다.

③ readyState가 2(HAVE_CURRENT_DATA)에 고정

33초치 풀버퍼(bufferedAheadSec 33.555)인데도 readyState가 3/4로 못 올라간다. 바이트는 다 있는데 다음 프레임을 제때 준비하지 못한다는 신호 → 네트워크가 아니라 파이프라인 공급 문제.

검증 과정 — 파일/코덱은 무죄

원본 ffprobe

codec=h264  profile=Main  level=4.2  pix_fmt=yuv420p
1924×1076  24fps  ~8.97Mbps  1559프레임  64.96s

파이프라인 옵션(Lambda)으로 직접 재인코딩 결과

codec=h264  profile=Constrained Baseline  level=3.1  pix_fmt=yuv420p
1280×720  30fps  ~1.24Mbps  1949프레임
I-프레임 85슬라이스 / P-프레임 ~5슬라이스 / 프레임마다 AUD (slice-max-size=1500, nal-hrd=cbr)
Constrained Baseline 8-bit yuv420p 720p — NVDEC가 가장 쉽게 디코딩하는 포맷. SW 폴백 유발 요소 없음. 슬라이스 다수·AUD·CBR은 RTP 스트리밍용 잔재라 오버헤드 약간 있으나 디코드 부담엔 무의미.

순수 소프트웨어 디코드 벤치 (ffmpeg -benchmark)

frame=1949  speed=297x   (65초 영상을 0.22초에 디코드, ≈8900fps)
화면 표시 없이 순수 디코드는 297배속. 이 Mac에서도 이 정도면, i7-12650H + NVDEC에선 디코드를 "부하"라 부를 수도 없다. → 251 드랍은 디코드 실패가 아니라 표시(present) 단계에서 발생.
주의 — 30fps 확정: totalVideoFrames ÷ currentTime ≈ 29.5 → 콘텐츠는 30fps(처리본). 원본 24fps가 아님. 단 totalVideoFrames가 30fps에 비례하는 건 "콘텐츠 fps"일 뿐 벽시계를 따라갔다는 증거가 아니다. 벽시계 대비 stall은 ①의 67% 계산이 증명.

원인 후보 소거

후보판정근거
노트북 스펙 부족기각i7-12650H + RTX 3060, 16스레드. 진짜 디코드 과부하 불가
크롬 HW 디코딩 OFF기각chrome://gpu Video Decode: Hardware accelerated (초록)
영상 코덱 비호환(10bit/VP9/AV1)기각재인코딩 결과 Constrained Baseline 8-bit yuv420p
네트워크/버퍼링기각blob 풀버퍼 33초치, networkState 1
디코드 실패기각SW 디코드 297배속, corruptedVideoFrames 0
present 파이프라인 starvation확정67% 재생속도 + readyState 2 고정 + 드랍 가속. 동시 미디어 작업이 디코드→표시 슬롯을 빼앗음
240Hz 고주사율 기여 비중미확정4.2ms 마감 + 합성 4배 부담으로 악화 요인. 단 단독 원인은 아님(60Hz면 한가한 페이지는 30fps 멀쩡)

왜 "표시(present) 마감"을 놓치나

디코딩이 끝난 뒤에도 프레임을 화면에 띄우려면 매 화면 갱신마다 합성 작업이 남는다:

[디코딩 완료 프레임]  ← 297배속, 문제 없음
   ↓ 1. GPU 텍스처 업로드
   ↓ 2. 레이어 합성 (영상+아바타+UI+카메라 미리보기 겹치기)
   ↓ 3. 스케일/색공간 변환 (720p→1440p, YUV→RGB, OLED 보정)
   ↓ 4. OS 컴포지터에 제출
[vsync 시점에 표시]
240Hz의 이중 부담: ① 프레임당 예산 4.2ms(60Hz는 16.6ms) ② 1초에 240번 합성(60Hz의 4배). 이 와중에 GPU/메인스레드를 카메라 인코딩(NVENC)·아바타 디코드(NVDEC)·STT 오디오·React가 같이 쓰면, 준비된 프레임을 4.2ms 안에 못 올려 드랍 → 같은 화면 반복·건너뛰기 = 끊김.
게스트 동시 작업: 아동 카메라 캡처+WebRTC 인코딩 / 핑퐁이 아바타 영상 디코드 / Web Audio STT 그래프(HPF+Limiter) 상시 처리(사고 중간 11:07:19~22 WebSocket 재연결·그래프 재생성 정황) / 1440p·240Hz OLED 합성.

주범 확정용 테스트 (그 노트북에서)

두 테스트 중 어디서 67%가 100%로 회복되는지가 주범을 가른다.

권장 조치 (영향 큰 순)

관련 문서