초보자를 위한 FFmpeg: 실제로 필요한 명령어
내 첫 번째 FFmpeg 명령어는 작성하는 데 45분이 걸렸고 0바이트 파일을 생성했다. 나는 Stack Overflow에서 복사하고 입력 파일 이름을 변경한 다음 Enter를 눌렀고, "muxing overhead"와 "frame duplication"에 관한 암호 같은 메시지로 터미널이 스크롤되는 것을 지켜봤다. 그 후, 어떤 플레이어에서도 열 수 없는 파일이 생성되었다. 다시 시도해 보았다. 또 다른 0바이트 파일. 세 번째 시도에서는 내 노트북이 크래시됐다. 이제 7년이 지난 지금, 나는 잠들면서도 어떤 것이든 트랜스코딩할 수 있다. 나는 4K HDR 색상 보정부터 수백만 명의 시청자를 처리하는 실시간 스트리밍 파이프라인까지 모든 것에 대해 10,000개 이상의 FFmpeg 명령어를 작성했다. 나는 우리 회사의 내부 FFmpeg 위키를 관리하고 있으며, 이는 247페이지에 달하는 레시피, 억제된 문제, 그리고 다른 곳에서는 문서화되지 않은 코드 변종에 대한 지식을 담고 있다. 내가 첫날에 누군가 나에게 말해주기를 바랐던 것은 다음과 같다: FFmpeg는 문법이 복잡해서 어려운 것이 아니다. 그것이 어려운 이유는 정신 모델이 설명되지 않기 때문이다. FFmpeg가 스트림, 컨테이너 및 코덱에 대해 어떻게 생각하는지 이해하게 되면 모든 것이 제자리에 맞아 떨어진다. 명령어를 맹목적으로 복사하는 것을 멈추고 문장처럼 조합하기 시작한다. 이 가이드는 내가 매주 실제로 사용하는 명령어를 포함하고 있으며, 대부분의 튜토리얼을 채우고 있는 이국적인 엣지 케이스는 아니다. 이들은 실제 비디오 작업의 90%를 처리하는 메인 작업들이다. 각 명령어가 무엇을 하는지뿐만 아니라, 왜 작동하는지, 그리고 대안 대신 언제 사용할 것인지 설명할 것이다.FFmpeg가 실제로 작동하는 방식 (그리고 왜 당신의 첫 번째 명령이 실패했는가)
FFmpeg는 모두가 처음에 잘못 이해하는 간단한 원칙에 따라 작동한다: 입력에서 스트림을 읽고, 필터를 통해 처리하고, 출력으로 작성한다. 혼란은 단일 비디오 파일에 여러 개의 스트림이 포함되어 있기 때문에 발생한다—보통 하나의 비디오 스트림, 하나 이상의 오디오 스트림, 그리고 때때로 자막 스트림이나 메타데이터 스트림이다. `ffmpeg -i input.mp4 output.mp4`를 실행하면, FFmpeg는 당신이 원하는 것에 대해 많은 가정을 한다. 가장 "좋은" 비디오 스트림, 가장 "좋은" 오디오 스트림을 선택하고, 기본 인코더를 통해 복사하고, 이를 출력 컨테이너에 믹싱한다. 이 방법은 간단한 변환에는 잘 작동하지만, 제어가 필요할 때는 통하지 않는다. 내 첫 번째 명령어가 0바이트 파일을 생성한 이유는 내가 호환되지 않는 코덱과 컨테이너 조합을 지정했기 때문이다. 나는 VP9 비디오 스트림을 MP4 컨테이너에 넣으려고 했는데, 이는 지원되지 않는다. FFmpeg는 인코딩을 시작하고 출력을 쓸 수 없음을 깨닫고 포기했다. 오류 메시지는 내가 읽을 줄 몰랐던 200줄의 출력에 묻혀 있었다. 내게 모든 것을 바꾼 정신 모델은 다음과 같다: FFmpeg를 세 단계로 구성된 파이프라인으로 생각하라. 첫째, 디멀티플렉싱—FFmpeg가 입력 파일을 열고 개별 스트림으로 분리한다. 둘째, 처리—각 스트림이 코덱(인코더/디코더)과 선택적 필터를 통과한다. 셋째, 멀티플렉싱—처리된 스트림이 출력 컨테이너에 패키징된다. 모든 FFmpeg 명령어는 다음 패턴을 따른다: ``` ffmpeg [전역 옵션] [입력 옵션] -i 입력 [출력 옵션] 출력 ``` 순서가 매우 중요하다. `-i` 전에 있는 옵션은 입력에 적용되고, `-i` 이후의 옵션은 출력에 적용된다. `-c:v libx264`를 `-i` 전에 두면, FFmpeg는 입력을 H.264로 디코딩하려고 시도하는데, 이는 아마도 당신이 원하는 것이 아닐 것이다. `-i` 이후에 두면, 출력은 H.264로 인코딩된다. 또 다른 중요한 개념은 스트림 지정자이다. 당신이 `-c:v`를 쓸 때, 당신은 "이 코덱을 비디오 스트림에 적용하라"고 말하는 것이다. `-c:a`는 오디오 스트림을 목표로 하고, `-c:s`는 자막을 목표로 한다. 첫 번째 비디오 스트림에 대해 `-c:v:0`를 사용할 수 있고, 두 번째 오디오 스트림에 대해 `-c:a:1`로 사용할 수 있다. 이 구조를 이해한 후, 나는 더 이상 0바이트 파일을 생성하지 않았다. 나는 FFmpeg의 출력을 읽고 각 단계에서 내가 무엇을 하고 있는지 이해할 수 있었다. 문제를 디버깅할 수 있었고, 그 문제가 디멀티플렉싱, 처리, 혹은 멀티플렉싱에서 발생했는지 분리할 수 있었다.내가 50,000개의 비디오를 트랜스코딩한 날 (그리고 내가 배운 것)
삼 년 전, 우리 회사는 경쟁사를 인수했다. 인수의 일환으로 그들의 전체 비디오 라이브러리—우리가 지원하지 않는 형식의 50,000개의 비디오가 포함되었다. 그들은 특정 플레이어를 요구하는 독점 코덱을 사용했으며, 우리는 모든 것을 우리 플랫폼의 표준 H.264로 변환해야 했다. 순진한 접근 방식은 간단한 루프를 작성하는 것이었을 것이다: 각 비디오마다 기본 설정으로 FFmpeg를 실행하고, 완료될 때까지 기다린 후 다음으로 이동하기. 평균 2분의 비디오에 대해, 이는 연속 처리로 69일이 소요될 것이다. 우리는 2주가 있었다. 이 프로젝트는 나에게 지난 3년 동안 배운 것보다 FFmpeg에 대해 더 많이 가르쳐주었다. 나는 하드웨어 가속, 병렬 처리, 실제로 중요한 인코더 설정 수십 가지에 대해 배웠다. 어떤 품질 지표가 의미가 있고 어떤 것이 마케팅 헛소리인지 배웠다. 가장 중요한 것은 "최고의" FFmpeg 명령어가 전적으로 당신의 제약 사항에 따라 다르다는 것이다. 우리는 40대의 기계에서 동시에 200개의 비디오를 처리하는 분산 트랜스코딩 시스템을 구축하게 되었다. 각 기계는 CPU 사용을 극대화하기 위해 신중하게 조정된 5개의 FFmpeg 인스턴스를 실행했다. 가능할 경우 하드웨어 가속 디코딩을 사용했지만, 품질 차이가 우리 사용 사례에 상당했기 때문에 소프트웨어 인코딩을 사용했다. 우리가 설정한 명령은 다음과 같았다: ```bash ffmpeg -hwaccel auto -i input.mov \ -c:v libx264 -preset medium -crf 23 \ -c:a aac -b:a 128k \ -movflags +faststart \ -max_muxing_queue_size 1024 \ output.mp4 ``` 각 옵션이 중요한 이유를 설명하겠다. `-hwaccel auto`는 FFmpeg에게 가능한 경우 하드웨어 디코딩을 사용하라고 지시한다—이는 호환 가능한 GPU가 있는 기계에서 디코딩 시간을 60% 줄였다. `-preset medium`은 인코딩 속도와 압축 효율성의 균형을 맞춘다. 우리는 모든 프리셋을 테스트했으며; `medium`은 `slower`의 95% 품질을 절반의 시간에 제공하는 적절한 지점이었다. `-crf 23` 설정은 Constant Rate Factor를 사용하여 품질을 제어한다. 낮은 숫자는 더 높은 품질과 큰 파일을 의미한다. 우리는 100개의 비디오 샘플에서 CRF 값을 18에서 28까지 테스트했으며, 우리의 비디오 팀은 블라인드 품질 비교를 수행했다. 아무도 CRF 23과 CRF 20을 신뢰성 있게 구분할 수 없었지만, 파일 크기는 30% 작았다. `-movflags +faststart`는 moov 원자를 파일의 시작 부분으로 이동시켜 HTTP를 통한 진행형 재생을 허용한다. 이 플래그가 없다면, 브라우저는 재생을 시작하기 전에 전체 파일을 다운로드해야 한다. 이 단일 옵션은 우리의 사용자 경험 지표를 15% 향상시켰다. `-max_muxing_queue_size 1024` 옵션은 우리에게 3일의 디버깅 비용이 든 문제를 해결했다. 일부 소스 비디오는 FFmpeg의 내부 버퍼가 넘치는 원인인 가변 프레임 속도를 가지고 있었다. 기본 큐 크기는 8 패킷이다, 이는 VFR 콘텐츠에는 충분하지 않다. 이를 1024로 증가시키니 "출력 스트림을 위한 버퍼에 너무 많은 패킷이 준비됨" 오류가 해결되었다. 이는 우리의 변환 중 5%를 실패하게 만들었다. 우리는 11일 만에 프로젝트를 마쳤다. 분산 시스템은 하루에 4,545개의 비디오를 처리했으며, 성공률은 99.2%였다. 실패는 모두 손상된 소스 파일이거나 우리가 디코딩할 수 없는 코덱을 사용한 것이었다. 나는 여전히 오늘날 그 명령어의 변형을 사용하고 있으며—이는 우리의 전체 비디오 처리 파이프라인의 기초이다.코덱 및 컨테이너 호환성 매트릭스
FFmpeg 초보자에게 가장 좌절스러운 측면 중 하나는 어떤 코덱이 어떤 컨테이너와 호환되는지 이해하는 것이다. 완벽한 명령어를 만들기 위해 한 시간을 보낼 수 있지만, 호환되지 않는 코덱을 지원하지 않는 컨테이너에 넣으려고 해서 실패할 수 있다. 내가 자주 참조하는 호환성 매트릭스는 다음과 같다:| 컨테이너 | 비디오 코덱 | 오디오 코덱 | 최고 |
|---|---|---|---|
| MP4 | H.264, H.265, AV1 | AAC, MP3, Opus | 웹 재생, 모바일 기기, 보편적 호환성 |
| WebM | VP8, VP9, AV1 | Vorbis, Opus | 웹 스트리밍, 오픈 소스 프로젝트, YouTube |
| MKV | 무엇이든 | 무엇이든 | 보관, 여러 개의 오디오 트랙, 자막 |
| MOV | H.264, ProRes, DNxHD | AAC, PCM | 전문 편집, Apple 생태계 |
| AVI | MPEG-4, H.264 (제한적) | MP3, PCM | 구식 시스템 (신규 프로젝트에선 피할 것) |
| TS | H.264, H.265, MPEG-2 | AAC, MP3, AC-3 | 방송, HLS 스트리밍 |
아무도 제대로 설명하지 않는 품질 설정
모든 FFmpeg 튜토리얼은 "좋은 품질"을 위해 `-crf 23`을 사용하라고 하거나 "초당 5메가비트"를 위해 `-b:v 5M`을 사용하라고 한다. 그러나 아무도 이 설정이 실제로 무엇을 하는지 또는 콘텐츠에 맞는 올바른 값을 선택하는 방법을 설명하지 않는다. 나는 다양한 종류의 콘텐츠에서 품질 설정을 테스트하는 데 수백 시간을 보냈다. 내가 배운 것은 보편적인 "최고" 설정은 없다는 것이다. 최적의 품질 매개변수는 콘텐츠 유형, 목표 청중 및 배포 방법에 따라 다르다."Constant Rate Factor (CRF)는 품질 기반 인코딩 모드로, 품질 수준을 지정하고 인코더가 필요한 만큼의 비트를 사용하여 해당 품질을 달성하도록 한다. 낮은 CRF 값은 더 높은 품질과 큰 파일을 의미한다. H.264의 경우 범위는 0-51이며, 0은 무손실이고 51은 가능한 최악의 품질이다. 기본값은 23이며, 이는 대부분의 콘텐츠에 대해 '시각적으로 투명한' 것으로 간주된다—즉, 대부분의 사람들은 원본과 구별할 수 없다."CRF의 문제는 가변 비트 전송률 출력을 발생시킨다는 것이다. 높은 움직임의 액션 장면은 10 Mbps를 사용할 수 있는 반면, 정적인 화자 장면은 2 Mbps를 사용할 수 있다. 이는 파일 크기에 효율적이지만, 예측 가능한 대역폭 사용이 필요한 스트리밍에는 문제가 될 수 있다. 스트리밍에는 일정한 비트 전송률(CBR) 또는 제약이 있는 가변 비트 전송률(VBR)이 필요하다. 스트리밍을 위해 내가 사용하는 명령은 다음과 같다: ```bash ffmpeg -i input.mp4 \ -c:v libx264 -preset medium \ -b:v 5M -maxrate 5M -bufsize 10M \ -c:a aac -b:a 128k \ output.mp4 ``` `-b:v 5M`은 목표 비트 전송률을 초당 5메가비트로 설정한다. `-maxrate 5M`은 그 비율을 초과하지 않도록 보장한다. `-bufsize 10M`은 디코더 버퍼 크기를 비트 전송률의 두 배로 설정하는데, 이는 표준 권장 사항이다. 이는 버퍼링 없이 부드럽게 스트리밍되는 출력을 생성한다. 그러나 대부분의 사람들이 잘못 이해하는 점은: 비트 전송률 요구 사항이 해상도와 움직임에 따라 선형이 아닌 비율로 증가한다는 것이다. 1080p 비디오는 720p 비디오의 두 배 비트 전송률이 필요하지 않으며—대략 1.5배가 필요하다. 4K 비디오는 1080p의 네 배 비트 전송률이 필요하지 않고—대략 2.5배가 필요하다.
"인간의 시각 시스템은 선형이 아닌 로그 스케일이다. 비트 전송률을 두 배로 늘리는 것은 "