라이브 스트림 녹화 문제 해결: 가장 흔한 9가지 오류와 해결법

라이브 스트림을 녹화하기 시작했는데, 2시간 후 파일을 열어보니 30분 만에 녹화가 멈춰 있습니다. 또는 음성이 없거나, 파일을 재생할 수 없거나, 1080p로 고정했는데 해상도가 480p입니다.

라이브 녹화는 VOD 다운로드보다 더 많은 실패 모드를 가지고 있습니다. 왜냐하면 소스가 끊임없이 변하기 때문입니다 — manifest가 로테이션되고, segment가 타임아웃되고, 호스트의 bitrate가 변동하고, CDN이 세션 중간에 변경됩니다. 이 글은 가장 흔한 9가지 실패 현상의 진단 가이드, 각각의 원인, 그리고 해결법입니다.

1. 녹화가 스트림 중간에 임의로 멈춤

증상: 4시간 스트림을 녹화했는데 파일이 45분 길이이고 스트림은 여전히 진행 중입니다.

가장 가능성 있는 원인: manifest URL이 로테이션되었는데 녹화기가 따라가지 못했습니다.

Twitch는 HLS manifest 토큰을 대략 24시간마다 로테이션합니다. TikTok은 약 30분마다 로테이션합니다. Bilibili는 화질을 변경할 때마다 로테이션합니다. 원래 URL을 하드코딩한 단순한 녹화기는 그 URL이 403/404를 반환하는 순간 작동을 멈춥니다.

해결법: manifest URL을 주기적으로 다시 resolve하는 녹화기를 사용하세요. Video Downloader One-for-All은 모든 fetch 실패마다 이를 수행합니다. 여러분의 녹화기가 이를 하지 않으면 도구를 바꾸는 것이 유일한 해결책입니다.

기타 가능한 원인:

• 브라우저 탭이 일시 중단됨 (Chrome은 메모리 절약을 위해 백그라운드 탭을 적극적으로 일시 중단함) — 스트리밍 탭을 계속 보이게 유지하거나 고정하세요
• 네트워크 끊김 — 연결을 끊기에는 충분히 길지만 눈치채지 못할 정도
• 디스크 용량 부족

2. 파일에 음성이 누락됨

증상: 비디오는 정상 재생되지만 음성이 전혀 없습니다.

가장 가능성 있는 원인: 녹화기가 음성과 비디오를 믹싱하지 않았습니다.

대부분의 라이브 스트림은 음성과 비디오를 별도의 HLS variant로 제공합니다. 재생 가능한 파일을 만들려면 녹화기가 둘 다 fetch하고 demux한 후 하나의 컨테이너로 remux해야 합니다. 일부 녹화기 (특히 오래된 것이나 단순한 것)는 비디오 variant만 캡처하고 음성은 완전히 건너뜁니다.

해결법: 라이브 스트림에 대해 음성 muxing을 명시적으로 광고하는 녹화기를 선택하세요. 길게 녹화하기 전에 30초 테스트 녹화로 확인하세요.

기타 가능한 원인:

• 녹화 당시 음성 variant를 사용할 수 없었음 (드물지만 방송인의 기술적 문제로 발생)
• 플레이어가 시스템 전체에서 음소거되었고 녹화기가 somehow 스트림 녹화 대신 화면 캡처를 하고 있음 (비정상적임; 그렇다면 잘못된 도구를 사용하는 것입니다)

3. 파일이 VLC에서는 재생되지만 QuickTime / Windows Media Player에서는 안 됨

증상: VLC는 파일을 정상 열지만 OS 기본 플레이어가 오류를 표시합니다.

가장 가능성 있는 원인: 출력이 .flv 또는 .ts 파일이고 기본 플레이어는 이들을 지원하지 않습니다.

VLC와 MPV는 모든 컨테이너에 대응하도록 설계되었습니다. OS 번들 플레이어는 挑剔합니다. FLV (Bilibili Lives), TS (HLS source), MKV는 모두 VLC에서 작동하지만 QuickTime / Windows Media Player에서 문제를 일으킵니다.

해결법 옵션:

• 기본적으로 MP4를 출력하는 녹화기를 사용하세요 (TS/FLV → MP4 remuxing은 무손실이고 즉시)
• 파일을 ffmpeg -i input.flv -c copy output.mp4로 실행하여 re-encoding 없이 remux하세요
• 항상 녹화에 VLC를 사용하세요

4. 파일은 재생되지만 seeking이 broken

증상: 파일이 처음부터 정상 재생되지만 재생 헤드를 드래그하면 건너뛰거나 멈춥니다.

가장 가능성 있는 원인: moov atom이 MP4의 끝에 있고 처음에 없습니다.

MP4 메타데이터 (“moov atom”)는 플레이어에게 모든 keyframe의 위치를 알려줍니다. 끝에 있으면 플레이어가 seeking을 하기 전에 전체 파일을 다운로드해야 합니다. 로컬 파일의 경우 플레이어가 모두 로드하면 되지만 일부 플레이어는 seeking 중에 moov-at-end를 올바르게 처리하지 못합니다.

해결법: ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4를 실행하세요. 녹화기가 자동으로 이를 수행해야 합니다; 하지 않으면 녹화기 버그입니다.

Video Downloader One-for-All은 기본적으로 faststart MP4를 작성합니다.

5. 화질이 고정한 것보다 낮음

증상: 플레이어를 1080p60으로 고정했는데 파일이 720p입니다.

가장 가능성 있는 원인: 플레이어가 지각된 대역폭 압박으로 인해 스트림 중간에 화질을 낮췄고 녹화기가 그 저하를 따라갔습니다.

Auto-quality 논리는 대부분의 플레이어에 내장되어 있습니다. 1080p60으로 “고정”하더라도 일부 플레이어 (특히 Twitch의)는 네트워크가 혼잡하다고 생각하면 조용히 화질을 낮춥니다. 플레이어가 재생하는 것을 녹화하는 녹화기는 저하된 화질을 녹화합니다.

해결법:

• 플레이어가 현재 재생 중인 것과 무관하게 고유의 화질 variant를 fetch하는 녹화기를 사용하세요 — 이는 플레이어 결정과 무관하게 원본 화질을 보장합니다
• 또는 충분한 대역폭 여유를 확보하세요

기타 가능한 원인:

• 스트림이 고정한 화질로 never 사용 가능했음 (일부 방송인은 드롭다운이 뭘 말하든 720p로만 방송)
• 화질 메뉴에 여러 “1080p” 항목이 있었고 잘못된 것을 선택함 (Twitch는 때로 “1080p”와 “1080p60”을 나열하고 bitrate가 다름)

6. 녹화가 “no video detected”로 즉시 실패

증상: 확장 프로그램을 클릭하면, 팝업이 라이브 스트림이 재생 중인데도 “no video detected”라고 말합니다.

가장 가능성 있는 원인: 페이지가 확장 프로그램 설치 또는 새로고침 before 로드되었습니다.

브라우저 확장 프로그램은 네트워크 이벤트에 content script를 연결합니다. 스크립트가 로드되기 전에 발생한 이벤트는 사라집니다. manifest fetch가 페이지 로드 중에 발생했고 확장 프로그램이 아직 실행되지 않았으면 확장 프로그램은 스트림을 볼 수 없습니다.

해결법: 페이지를 새로고침하세요. manifest fetch가 다시 트리거되고 확장 프로그램이 이를 감지합니다.

기타 가능한 원인:

• 스트림이 확장 프로그램이 지원하지 않는 프로토콜을 사용 (2026년에는 드물음; HLS, DASH, FLV, WebRTC가 라이브 스트림의 약 99% 커버)
• 사이트가 DRM을 사용하고 있고 확장 프로그램이 올바르게 녹화를 거부 — Why You Can’t Record DRM-Protected Live Streams 참조

7. 녹화 크기가 예상보다 훨씬 작음

증상: 2시간 스트림을 녹화했는데 파일이 50MB입니다.

가장 가능성 있는 원인: 녹화기가 가장 낮은 화질 variant만 녹화했거나 음성만 녹화했거나 segment 없이 manifest만 녹화했습니다.

전형적인 Twitch bitrate에서 2시간 1080p60 녹화는 대략 3-6 GB여야 합니다. 50MB는 뭔가 매우 잘못되었다는 신호입니다.

해결법: 30초 테스트 녹화를 하고 결과 파일 크기를 확인하세요. 30초 1080p60 녹화는 25-50MB여야 합니다. 30초 테스트가 1-2MB면 녹화기가 근본적으로 broken — 도구를 바꾸세요.

8. 길게 녹화하는 동안 브라우저가 충돌

증상: Chrome이 녹화 몇 시간 후 멈추거나 충돌합니다.

가장 가능성 있는 원인: 녹화기가 모든 것을 메모리에 버퍼링하지 않고 디스크로 스트리밍합니다.

좋은 라이브 녹화기는 segment가 도착할 때 디스크에 write하고 메모리 버퍼를 폐기합니다. 나쁜 것은 Chrome이 할당된 RAM (전형적으로 renderer process 당 2-4GB)을 소진할 때까지 모든 것을 메모리에 축적한 후 충돌합니다.

해결법: segment를 연속으로 디스크에 write하는 녹화기를 선택하세요. OFA 확장 프로그램은 이를 합니다. 긴 방송 (12시간 이상)은 녹화 길이에 관계없이 약 50MB RAM을 사용해야 합니다.

9. 녹화가 완료되었지만 파일을 열 수 없음

증상: 녹화가 완료되었지만 파일이 모든 플레이어에서 “unknown format” 오류를 줍니다.

가장 가능성 있는 원인: 녹화기가 moov atom을 write하지 못했거나 파일을 올바르게 close하지 못했습니다.

녹화기가 충돌했거나 녹화 중간에 Chrome을 강제 종료했으면 MP4가 뒤의 moov atom을 놓칠 수 있습니다. 비디오 데이터는 있지만 어떤 플레이어도 이를 인덱싱할 수 없습니다.

해결법:

• ffmpeg -i broken.mp4 -c copy fixed.mp4를 실행하고 ffmpeg가 복구할 수 있는지 보세요 (보통 그렇습니다)
• untrunc (truncated MP4 복구 전용 오픈소스 도구)를 실행하세요 — 참조 healthy 파일에서 moov atom을 재구성할 수 있습니다
• 최악의 경우 녹화가 손실됩니다.

예방: 부분 파일이 녹화가 중단되어도 재생 가능하도록 incremental moov update를 write하는 녹화기를 선택하세요. 일부 녹화기는 또한 “fragment MP4” 출력을 제공하며 이는 녹화 중간에도 재생 가능하도록 설계되었습니다.

길게 녹화하기 전 진단 체크리스트

1시간 이상의 계획된 녹화의 경우 먼저 이 체크리스트를 실행하세요:

1. 같은 화질과 같은 소스에서 5분 테스트 녹화
2. 테스트 파일을 QuickTime / Windows Media Player에서 열기 (VLC가 아님 — VLC는 뭐든 재생)
3. 음성이 있는지 확인
4. seeking이 작동하는지 확인
5. 파일 크기가 합리적인지 확인 (1080p60에서 분당 약 50-100MB)

체크리스트의 무엇이든 실패하면 진짜 녹화를 시작하기 전에 고쳐세요. “6시간 스트림을 방금 녹화했는데 음성이 없다”에 대한 복구는 없습니다.

도구 디버깅을 멈추고 바꿀 때

2-3개의 다른 녹화기를 시도했고 같은 실패 현상이 계속 발생하면 (특히 #1, #2, #7), 문제는 여러분의 설정이 아닙니다 — 사용 가능한 녹화기가 충분히 성숙하지 않은 것입니다. 고려하세요:

• Twitch / Kick / YouTube Live의 경우: 모든 HLS-aware 녹화기가 작동해야 하고 Video Downloader One-for-All을 포함합니다
• Bilibili의 경우: 특별히 FLV 지원이 필요합니다 — 모든 HLS 녹화기가 이를 처리하지는 않습니다
• TikTok Live의 경우: 적극적으로 세션 중간 manifest 로테이션을 처리해야 합니다
• DRM-protected 스트림의 경우: 설계상 확장 프로그램이 작동하지 않습니다

결론

대부분의 라이브 녹화 실패는 9개의 패턴에 속하고 대부분은 도구를 바꿀 필요 없는 해결법이 있습니다. 가장 큰 이득은 다음에서 옵니다: 녹화를 시작하기 전에 페이지를 새로고침 (#6 해결), 녹화 전에 화질 고정 (#5 해결), manifest 로테이션을 처리하는 녹화기 사용 (#1 해결). 1시간 이상의 경우 항상 5분 테스트 녹화를 먼저 하세요 — 6시간 캡처가 6시간 뒤에 broken인 걸 알아내는 것은 최악의 시나리오입니다.