브라우저에서 FFmpeg를 이용한 Direct AVI to MP4 Conversion: M3 Mac 스트레스 테스트 및 WebAssembly의 진실
최근 저는 FFmpeg 코어를 기반으로 브라우저 내에서 완전히 실행되는 비디오 변환 도구인 작은 유틸리티를 코딩하는 데 시간을 보냈습니다. 이 기능의 성능을 테스트하기 위해 제 MacBook Air M3(16GB RAM)를 실험 대상으로 삼아, 기존 AVI 파일을 Google Chrome에서 직접 MP4로 변환해 보았습니다.
결과는 꽤나 재미있으면서도 기술적으로 흥미로웠습니다. 스톱워치는 정확히 747.44초(약 12.5분)에 멈췄고, 발열 관리가 뛰어나기로 유명한 M3 칩 덕분에 알루미늄 섀시가 눈에 띄게 따뜻해진 것을 느낄 수 있었습니다.
그렇다면, 현재 시장에서 가장 강력한 칩 중 하나가 탑재된 컴퓨터가 단순히 비디오 포맷을 변경하는 데 12분 이상 '진땀을 빼야' 했던 이유는 무엇일까요? 이 글에서는 이 과정의 이면에 있는 기술적인 원리를 분석하고, 궁극적인 질문에 답해 보겠습니다. 이렇게 느리다면, 왜 굳이 브라우저 기반 처리 도구가 필요한 걸까요?
1. 첫 번째 병목 현상: Remux vs. Transcode
테스트에 이토록 오랜 시간이 걸린 가장 큰 이유는 기기 때문이 아니라 원본 파일 때문이었습니다. 제가 선택한 파일은 DivX나 Xvid와 같은 구형 압축 표준(코덱)을 사용하는 오래된 AVI 포맷이었습니다.
비디오 처리 분야에서는 다음 두 가지 핵심 개념을 구분해야 합니다.
- Remux (복사 - 매우 빠름): 원본 비디오가 이미 최신 코덱(예: H.264)을 사용하고 있다면, FFmpeg는 단순히 비디오와 오디오 '코어'를 추출하여 새로운 MP4 '래퍼(wrapper)'에 집어넣습니다. 이 과정은 본질적으로 데이터를 한 폴더에서 다른 폴더로 복사하는 것과 같으며 몇 초밖에 걸리지 않습니다.
- Transcode (Decode 및 Encode - 매우 느림): 제 AVI 파일은 MP4와 호환되지 않는 구형 표준을 사용했기 때문에, FFmpeg는 이를 '처음부터 다시 구축'해야만 했습니다. 오래된 비디오의 모든 프레임을 Decode한 다음, 그 방대한 프레임 더미를 최신 H.264/H.265 표준으로 Encode해야 했습니다. 이렇게 픽셀 단위로 작업하는 것은 CPU 리소스를 엄청나게 소모합니다.
2. 브라우저 환경에서의 WebAssembly (WASM)의 현실
...
