브라우저 비디오 처리 성능 벤치마크: FFmpeg WASM vs WebCodecs vs 네이티브

브라우저 비디오 처리 성능 주장은 대개 2종류:"충분히 빠르다, 믿어달라" 또는 "WASM은 네이티브보다 2배 느리다". 둘 다 쓸모없다. 이 글은 실제 하드웨어에서의 실제 데이터로, 방법론과 생 데이터를 곁들여, 브라우저가 워크로드를 처리할 수 있는지 스스로 판단할 수 있게 한다.

테스트 구성

하드웨어:

• Mac: MacBook Pro M2 Pro(12코어), 32GB RAM, macOS 14.5
• Windows: ThinkPad X1 Carbon Gen 11(Intel i7-1370P, 14코어), 32GB RAM, Windows 11 23H2
• 미드레인지: Acer Aspire 5(Ryzen 5 5500U, 8GB RAM), Windows 11

브라우저(모두 2026년 7월 기준 최신 안정 버전):

• Chrome 127
• Firefox 127
• Safari 17.5

워크로드:

1. 1080p HLS → MP4 리먹스——30분 영상, 300 TS 세그먼트, 약 500MB
2. 4K HLS → MP4 리먹스——30분 영상, 300 TS 세그먼트, 약 2.5GB
3. 8K HLS → MP4 리먹스——10분 영상, 100 TS 세그먼트, 약 4GB
4. 디코딩 + 프레임 추출(1080p, 매초 1프레임, 1800프레임)——WebCodecs 글에서 설명
5. DASH → MP4 리먹스——#1과 동일 영상이지만 DASH 소스(TS 디먹싱 불필요)

테스트 방법:

• 네이티브 FFmpeg(CLI, 베이스라인)——ffmpeg -f concat -safe 0 -i list.txt -c copy -f mp4 out.mp4
• FFmpeg WASM(싱글스레드)——@ffmpeg/ffmpeg 0.12.x, pthreads 없음
• FFmpeg WASM(멀티스레드)——@ffmpeg/ffmpeg 0.12.x, CORE_THREADS=8
• WebCodecs + Worker——디코딩 워크로드만, 리먹스 아님

각 테스트는 5회 실행, 중앙값 보고. 모든 시나리오에서 변동은 5% 미만.

결과: 1080p HLS → MP4 리먹스(30분 영상)

결론: 멀티스레드 FFmpeg WASM이 네이티브의 약 2-3배, 싱글스레드의 3-4배. 미드레인지 하드웨어에서 싱글스레드 FFmpeg WASM은 1080p에서 겨우 쓸만한 수준(30분을 180초 = 실시간의 0.16배). 멀티스레드는 문제없음(65초 = 실시간의 0.036배).

결과: 4K HLS → MP4 리먹스(30분 영상, 2.5GB)

결론: 4K 리먹스는 싱글스레드 FFmpeg WASM이 무너지는 경계점. 미드레인지 하드웨어(8GB)는 메모리 압력으로 크래시——WASM의 단일 인스턴스 메모리 상한이 2-4GB, 세그먼트 버퍼 + 디코딩 상태를 더하면 초과. 멀티스레드는 하이엔드 하드웨어에서 4K 처리 가능, 단 네이티브보다 2-3배 느리다.

미드레인지에서의 크래시가 가장 볼 만한 부분. 청크 처리(한 번에 N 세그먼트, OPFS에 쓰기, 메모리 해제)해도 4K TS 디먹싱은 많은 작업 메모리를 필요. 수정은 OPFS 스트리밍 모드——출력 전체를 메모리에 올리지 않는 것.

결과: 8K HLS → MP4 리먹스(10분 영상, 4GB)

결론: 2026년 시점에서 FFmpeg WASM은 8K를 처리 못 한다. 4GB의 단일 인스턴스 메모리 상한이 하드한 벽. 청크 스트리밍해도 8K HEVC TS 디먹싱은 PTS 재정렬을 위해 여러 100MB+ 세그먼트를 동시에 유지해야.

이건 알려진 제한. 제안 중인 WASM memory64 사양이 64비트 어드레싱으로 끌어올리지만, 2026년 시점 Chrome의 flag 뒤에 있고, Firefox/Safari에는 없다.

결과: DASH 리먹스(TS 디먹싱 불필요)

동일 1080p/4K 콘텐츠이되 DASH 소스(fMP4 세그먼트, 디먹싱 불필요):

결론: DASH는 디먹싱 단계가 없어 훨씬 빠르다——리먹스 글에서 이유를 설명. 순 JS 결합(FFmpeg을 완전히 쓰지 않는)은 DASH에서 가능, 메모리 대역폭의 한계 가까이까지 달린다.

이게 FlowPick의 DASH 경로가 HLS 경로보다 빠른 이유——HLS는 MPEG-TS를 디먹싱해야, DASH는 안 한다.

결과: 디코딩 + 프레임 추출(30분 1080p, 1800프레임)

결론: WebCodecs + worker 풀이 브라우저에서 가장 빠른 선택——하이엔드 하드웨어에서 네이티브의 2배 이내. 하드웨어 가속이 진짜 효과. 미드레인지 하드웨어에서는 FFmpeg WASM 멀티스레드가 WebCodecs 싱글 worker와 동등——Ryzen 5 5500U의 GPU가 약해서.

worker 풀의 스케일링이 중요:4 worker는 1 worker보다 약 2.5배 빠르다(GPU 경합으로 서브리니어). 8 worker는 큰 도움 안 됨——GPU는 4-6개의 동시 디코딩에서 포화.

결과: 브라우저 비교(Mac M2, 1080p 리먹스)

결론: Chrome이 모든 선택을 달릴 수 있는 유일한 브라우저. Firefox는 WASM pthreads와 WebCodecs 모두 부족(2026년 중반에 WebCodecs는 여전히 flag 뒤). Safari는 WebCodecs를 갖되 codec 지원 제한(AV1 없음, VP9 제한).

이게 FlowPick이 Chrome을 권장하는 이유——v1.0.0 릴리스 노트 참고.

메모리 사용

피크 메모리(Chrome 127, Mac M2, 1080p 리먹스):

4K 리먹스의 피크 메모리는 약 2배인 500MB(FFmpeg WASM 멀티스레드)——브라우저 탭의 2GB 소프트 상한 내이지만, 가까우니 다른 탭을 닫아야 할 수도.

메모리 프로필은 UX에 영향. 4K 리먹스가 8GB 머신에서 탭을 크래시시키는 건 최악의 경험. FlowPick의 청크 처리(한 번에 50세그먼트, OPFS에 쓰기, 메모리 해제)는 4K의 피크 메모리도 300MB 이내로 유지.

스트리밍 다운로드 벤치마크

세그먼트 자체를 얼마나 빨리 다운로드할 수 있는가? 이건 네트워크가 병목인 부분.

테스트:300 세그먼트, 각 약 1.7MB, 총 500MB, CloudFront CDN에서.

결론: 6-8개 병렬 연결이 스위트스팟. 그 이상은 CDN이 IP당 레이트 리미트를 시작. FlowPick은 기본 6.

"실효 대역폭"은 CDN에서 제한, 브라우저에서 제한 안 됨. 병렬을 무한히 늘려도 CDN이 허용하는 상한을 넘을 수 없다.

방법론의 세부

워밍업: 각 테스트는 2회 실행, 첫 번째는 폐기(WASM 컴파일, JIT 워밍업 등).

전원: 랩탭은 전원 연결, 성능 모드. 배터리 모드에서는 Mac이 약 30%, Windows가 약 50% 클럭 다운.

다른 탭: 없음. 백그라운드 탭은 CPU/메모리를 경합.

열: 모든 랩탭은 쿨링 패드 위. 열 스로틀은 실재——능동 쿨링 없이 4K 리먹스를 5분 연속하면 15-20% 떨어짐.

FFmpeg 파라미터: -c copy -f mp4 -movflags +faststart로 리먹스. 필터 없음, 트랜스코딩 없음.

WASM 버전: @ffmpeg/core 0.12.10, 멀티스레드 버전은 CORE_THREADS=8. SharedArrayBuffer 지원을 위한 COEP/COOP 헤더 올바르게 설정.

이 숫자들이 의미하는 것

1080p 콘텐츠(가장 일반적): 브라우저가 처리 가능. FFmpeg WASM 멀티스레드는 30분 1080p를 22-65초, 하드웨어에 따라. WebCodecs를 쓸 수 있으면 더 빠르다. 네이티브는 2-3배 빠르지만 설치 필요.

4K 콘텐츠: 하이엔드 하드웨어(16GB+ RAM, 최신 CPU)에서 브라우저가 처리 가능. 미드레인지 하드웨어는 고전. 청크 처리가 필수.

8K 콘텐츠: 2026년의 브라우저는 처리 불가. memory64 WASM을 기다리거나, 네이티브를 쓴다.

디코딩 집약(프레임 추출, 분석): WebCodecs + worker 풀이 명확한 승자. 좋은 하드웨어에서 네이티브의 2배 이내.

광범위 codec 지원: FFmpeg WASM. WebCodecs는 브라우저가 지원하는 codec으로 제한(H.264, H.265, VP9, AV1——브라우저마다 주의점 있음).

내 견해: 브라우저는 90% 시나리오에서 충분

"브라우저는 진짜 비디오 처리를 못 한다"는 말은 시대에 뒤떨어진 것. 1080p 리먹스와 디코딩——실제 사용의 대부분——은 현대 하드웨어에서 Chrome이 네이티브의 2-3배 이내. 충분히 빠르다. 수초의 지연 차이(30분 영상에서 몇 초 더 기다리는)는, 워크플로의 차이(설치 불필요, PATH 설정 불필요, FFmpeg 설치 불필요)에 비하면 중요하지 않다.

나머지 10%——미드레인지 하드웨어에서의 4K, 어디서든 8K, 희귀 codec——은 여전히 네이티브가 필요. 그리고 그건 괜찮다. 도구는 일에 맞춰.

FlowPick의 베팅:브라우저에서 90% 시나리오를 최적화, 나머지 10%에는 "yt-dlp를 써라"라고 제안. FlowPick vs. yt-dlp 비교에서 언제 어느 쪽을 쓸지 설명.

참고 자료

• FFmpeg WASM 문서——설정과 스레딩
• WebCodecs 브라우저 지원——호환성 표
• Memory64 제안——WASM의 4GB 메모리 상한을 끌어올리는 제안

마치며

브라우저 비디오 처리는 1080p 워크로드에서 현대 하드웨어로 실행 가능, 4K는 하이엔드 하드웨어에서 실행 가능. 8K는 WASM이 memory64를 내놓을 때까지 불가. FFmpeg WASM 멀티스레드가 가장 좋은 범용 도구. WebCodecs + worker는 디코딩 집약 작업에서 더 빠르지만 codec 제한 있음.

여기의 방법론은 재현 가능——테스트 파일은 참고 자료에 링크, FFmpeg 파라미터는 기재, 하드웨어는 명시. 다른 워크로드라면, 같은 패턴으로 자신의 테스트를.

이 숫자를 뒷받침하는 구현 패턴은, WebCodecs 글과 리먹스 글에서. 무엇을 처리할 수 있는지의 법적 고려는, 스트리밍 다운로드 합법성 가이드에서.

추천 글

• WebCodecs + Web Workers + OPFS: 브라우저 비디오 처리 실전——여기서 테스트한 구현 패턴
• 브라우저에서 비디오 리먹스: fMP4, ISOBMFF, 트랜스코딩하지 않는 이유——리먹스가 왜 빠르고 트랜스코딩이 왜 빠르지 않은지
• FlowPick은 어떻게 브라우저에서 수백 개의 비디오 세그먼트를 하나의 MP4로 합치는가——FlowPick의 구체적 구현
• FlowPick vs. yt-dlp——브라우저 vs 네이티브의 선택 시기
• HLS 딥: 암호화, 멀티트랙, 기억해야 할 EXT-X 태그——여기서 벤치마크한 HLS 포맷
• FlowPick v1.1.0: 더 똑똑한 미디어 감지——큰 파일의 청크 처리를 추가한 버전