FFmpeg

• 컴퓨터 관련 정보 - 소프트웨어/목록

1 개요

공식 홈페이지

Michael Niedermayer의 주도하에 개발되고 있는 모든 동영상, 음악, 사진 포맷들의 디코딩과 인코딩을 목표로 만들어지고 있는 LGPL 또는 GPL라이센스를 따르는 오픈소스 프로젝트.

관련업계에서는 마이크로소프트+애플급의 영향력을 가지고 있는 멀티미디어계의 최종보스. 가능성 없는 이야기긴 하지만 이 프로그램이 유료화를 시전한다면 우리는 내일부터 동영상을 시청 못할수도 있다. 아래의 FFmpeg을 기반으로 하는 프로그램 리스트를 보면 알겠지만 이건 농담이 아니다.

한 일화로 NVIDIA와 AMD는 자사의 그래픽카드의 하드웨어 가속을 위해 FFmpeg에 '직접' 소스를 건내주고 FFmpeg이 시키는대로 수정하였다. 대부분의 멀티미디어 재생기가 FFmpeg을 기반으로 하기 때문에, FFmpeg에서 지원만 한다면 그 효과를 당장 볼 수 있기 때문.

2 FFmpeg에서 제공하는 것들

• ffmpeg - 미디어 포맷 변환 도구
• ffserver - 라이브 방송을 하는 멀티미디어 스트리밍 서버
• libavcodec - 오디오/비디오 코덱 라이브러리
• libavformat - 멀티미디어 컨테이너의 디먹서/먹서 라이브러리
• libavdevice - 입출력 장치 제어 라이브러리
• libavfilter - 미디어 필터 라이브러리
• libswscale - 이미지 처리 라이브러리
• libswresample - 오디오 처리 라이브러리

3 디코더

쉽게 이야기하면 동영상을 재생할때 쓰이는 코덱이다. FFmpeg의 영향력이 절대적이다. MAC, 안드로이드, iOS, 윈도우즈에서 유명한 코덱 내장형 동영상 플레이어들은 모두 FFmpeg의 libavcodec을 기반으로 하고 있다고 봐도 무방하다.

3.1 FFmpeg을 기반으로 하는 동영상 플레이어

• iOS : AV player, nPlayer
• 안드로이드 : Dice Player, MX 플레이어, 안드로이드용 곰플레이어, 안드로이드용 KMP
• 윈도우 : 다음 팟플레이어, 곰플레이어, KMP, MPC-HC
• 맥 : 무비스트
• 크로스 플랫폼인 VLC, MPlayer

여기에 적혀있는것만해도 무시무시하지 않은가? 하지만 여기에 적혀있는것들은 유명한 것들만 적힌 일부분에 불과하다(...)

3.2 FFmpeg을 기반으로 하는 코덱

• LAVFilters
• FFDshow
• 그리고 LAV필터와 FFDshow를 기반으로하는 수많은 통합코덱들

4 동영상 인코더

이쪽은 한마디로 정리가 가능하다. MeGUI를 뺀 나머지 인코더 프로그램들은 모두 FFmpeg기반이라고 해도 무리가 아니다. 곰 인코더? 바닥? 다음 팟인코더? 모두 FFmpeg의 서자들이다.
다만 2010년 쯤까지 FFmpeg의 인코딩 기능은 별로였다. 곰 인코더나 바닥, 다음 팟인코더 등이 멀티코어를 잘 지원하지 못하는 등의 이유는 바로 이것 때문이다. 하지만 2011년부터는 일취월장하여 꽤 쓸만한 수준까지 올라왔다. 물론 MEGUI의 아성을 넘보기에는 무리지만, 수많은 단계를 거쳐야하는 MeGUI에 비해 간단하면서 쓸만한 화질을 뽑아준다는 장점이 있다.
MeGUI의 경우도 보기에 따라 FFmpeg 기반이라고 할 수 있다. mencoder를 사용하는데 이 mencoder가 FFmpeg 기반이다. 다만 FFmpeg 외 추가적으로 다른 인코딩/디코딩 라이브러리를 사용할 수 있기 때문에 FFmpeg만을 쓰는 것에 비해 더 강력한 기능을 가진다.

4.1 특징

MeGUI와 비교하여 FFmpeg이 가지는 특징은 아래와 같다

• FFmpeg 프로젝트 자체가 모든 영상의 디코딩/인코딩을 지향하기 때문에 추가적인 코덱의 설치가 필요없다. ffmpeg.exe 파일 하나로도 인코딩이 가능하다.
• 멀티코어의 공식적인 지원 따로 옵션을 적지않으면 모든 코어를 사용한다.
• AVIsynth의 기능을 수행하는 VF(libavfilter) 기능 내장. 단 기능은 떨어진다.
• 쉽다. 얼마나 쉬운지는 한 번 직접 해보자. 다른 블로그 하지만 설정할 수 있는 기능은 MeGUI보다 적다. 예) ffmpeg -i 원본파일명 -vcodec libx264 -crf 23 -s 1280x720 -preset veryfast -acodec aac -b:a 112k 결과파일명 간단한 인코딩은 이정도만 적어도 가능하다.
• FFmpeg은 쉬운 인코딩을 위해 각종 프리셋을 포함하고 있다. 사실 아래의 인코더들을 쓰는 것보다 직접 FFmpeg을 이용해서 프리셋을 활용하는 것이 더 나은 화질을 보장한다. CLI 기반이라 어질어질 할 수도 있지만, 찾아보면 위의 블로그처럼 스크립트를 공개한 곳이 많다. 정 귀찮으면 위 블로그에 있는 배치파일을 그냥 쓰면 된다. 리플들을 보면 수정된 프리셋이 많다. 그래도 아래의 인코더들보다 화질이 훨씬 좋게 나온다. 정 귀찮으면 아래 나오는 인코더를 써도 된다.

4.2 FFmpeg을 기반으로 하는 인코더

• 제트오디오VX(무료 혹은 유료, 코원)
• 유마일
• 엔젤인코더
• 샤나인코더 - 개인 개발자가 만든 인코더 임에도 불구하고, 가볍게 인코딩하는 용도로는 매우 좋다. 무료
• Mencoder
• 곰인코더
• 팟인코더
• Handbrake
• WInff

물론 이 목록 말고도, 대다수의 쉬운 인코더를 자처하는 프로그램들은 대부분 FFmpeg기반이다.

4.3 FFmpeg를 기반으로 하는 서비스

• 니코니코 동화, 아프리카 등의 인터넷 동영상 사이트
  • 많은 인터넷 동영상 사이트들도 ffmpeg를 사용하고 있다. 영상 파일을 다운받아서 뜯어보면 알겠지만, Lavf(libavformat)를 사용하고 있으며 영상 인코딩에도 libavcodec를 사용하고 있다.

4.4 일반적인 옵션

• -i [input]
  • 입력 파일을 지정한다.

• -vcodec [codec], -acodec [codec] 또는 -c:v [codec], -c:a [codec]
  • 비디오 코덱, 오디오 코덱을 지정한다. 사용할 수 있는 코덱은 ffmpeg -encoders 로 확인할 수 있다. copy로 지정하면 기존 스트림을 인코딩 하지 않고(direct stream) 복사한다.

• -vf [filter], -af [filter]
  • 비디오, 오디오에 필터를 적용한다. 리사이즈를 하거나 스피드를 바꾸거나 ass, srt 자막을 입히는 등의 처리를 할 수 있다. 자세한 것은 ffmpeg의 필터 문서를 참고하자. 참고로 자막을 입히는 건 폰트 때문에 윈도에서는 환경변수를 지정해 줘야 한다.

• -b:v [bitrate], -b:a [bitrate]
  • 비디오, 오디오의 비트레이트를 지정한다.

• -crf [quality]
  • 비트레이트 대신 화질 기준으로 인코딩할 때 쓰는 옵션. 0-51, 0은 무손실, 디폴트는 23

• -y
  • 파일을 덮어쓸 일이 있어도 물어보지 않는다.

• -re
  • 인코딩 속도를 1x(실시간)으로 제한한다. 로컬 파일을 ffserver로 스트리밍 시 실시간으로 feed를 전송하기 위해서 필요하다.

• -f [container]
  • 출력 포맷을 지정한다. 따로 적지않으면 파일명에 맞춰서 해준다.

• -t [time]
  • 지정된 시간 (초 단위)만큼 인코딩한다.

• -ss [time]
  • 지정된 시간 (초 단위)만큼 건너뛰고 인코딩한다. hh:mm:ss 방식으로도 표기가 가능하다.

4.5 예시

위의 블로그에 나와있는 스크립트는 일반적인 TV영상에 맞춰서 된 것이고 애니메이션에는 적합하지 않은 설정이다

일반 영상을 스마트폰 등에 맞추어 재인코딩 할때나 블루레이 원본 영상을 인코딩할때 의 설정예시는 다음과 같다.

ffmpeg -y -i filename.mp4 -threads 0 -sn -vcodec libx264 -preset medium -crf 23 -tune animation -sws_flags lanczos -vf "scale=1280:-1" -acodec libmp3lame -ac 2 -ab 192k outfile.mkv

• "-i filename.mp4" - 입력 파일로 filename.mp4를 지정한다. 확장자를 포함시켜야 한다.
• "-threads 0" - 사용할 스레드 수를 지정한다 0은 모두. 0이 디폴트라 생략해도 무방하다.
• "-sn" - 내장자막을 인코딩하지 않겠다는 의미이다. 내장자막을 가져오고 싶으면 -scodec copy로 바꾸면 된다.
• "-vcodec libx264" - libx264를 사용하여 H.264로 인코딩. MPEG4를 쓰려면 libxvid, VP8을 쓰려면 libvpx로 설정해주면 된다. 밑은 옵션 중 libx264의 옵션을 사용하는 건 물론 달라지지만 대충 비슷하다. 다양한 옵션은 영어가 된다면 ffmpeg 위키 참조.
• "-preset medium" - libx264의 프리셋을 이용하는것으로 very slow, slower, slow, medium, fast, faster, veryfast 등의 옵션이 있다. ultrafast나 placebo (이렇게 느려지면 화질 개선이 플라시보 효과 이상의 무언가는 없다라는 수준) 등의 옵션도 있지만 범인들은 쓸 일 없다 (...) 당연히 slow쪽으로 갈 수록 인코딩은 느려진다. CRF방식으로 인코딩을 할때는 용량에 관여을 하며, 비트레이트 지정으로 인코딩을 할 시 화질에 관여된다. CRF인코딩 기준 slow의 경우 medium에 비해 인코딩 시간이 50~66% 늘어나지만 용량은 0~4%정도 줄어든다. veryslow의 경우는 약 4.5배정도 인코딩 시간이 늘어나며 용량 이득은 12%정도다.
• "-crf 23" - CRF는 고정 비트레이트 인코딩이 아닌 "가변 비트레이트 화질우선 인코딩"방식으로서 옵션값은 0에서 51까지의 설정이 가능한데 값이 낮을 수록 고화질이다. 18 정도면 거의 무손실이고 기본값인 23 정도면 상당히 고화질으로서 영화나 미드를 인코딩하는데 적절하다. 애니메이션은 보통 25~27의 값을 쓴다. 화질이 나쁜(깍두기 크리를 맞은) mpeg2방식의 HDTV원본을 재인코딩할때는 CRF방식으로 인코딩하면 원본보다 더 크게 인코딩 되는 경우가 있으므로 고정 비트레이트 방식으로 인코딩을 하는게 낫다. 고정 비트레이트 방식으로 인코딩을 하고 싶다면 -crf 23 대신에 -vb 2000k 이렇게 지정하면 된다.
• "-tune animation" - libx264의 tune 옵션을 사용한다. 색감과는 관계가 없고 deblock 위주로 옵션을 조정한다. animation 옵션은 deblock 값을 높여서 화면을 좀 더 뭉게준다. 일반적인 영화나 티비영상의 경우 film 옵션을 쓴다.
• "-sws_flags lanczos -vf "scale=1280:-1"" lanczos란 리사이즈 필터를 이용하여 720p로 리사이즈. -1은 화면비에 맞춰서 자동으로 세로사이즈를 결정한다. 자동으로 리사이즈하는 경우에는 1280:718 이런식으로 이상한 사이즈가 나올수 있으니 왠만하면 수동으로 지정해주자. 이 VF명령줄에 여러가지 필터를 넣을 수 있다. libass를 사용해서 자막을 하드코딩 할 수도 있고 yadif로 디인터레이싱도 가능하다 ivtc도 가능하다. ffmpeg 필터 문서 참조.
• "-acodec libmp3lame -ac 2 -ab 192k" MP3 코덱으로 192k정도에 맞춰서 2채널로 다운믹싱하여 인코딩한다. MP3와 같이 많이 쓰이는 AAC의 경우 FFmpeg의 내장된 AAC 인코더가 거의 쓰레기 수준이기 때문에 FFmpeg 내장 AAC 코덱으로 음성을 인코딩하는 것은 사실 추천하지 않는다. 꼭 AAC가 필요하다면 -acodec aac -strict experimental -ac 2 -ab 192k 옵션을 사용하면 된다. 고품질로 인코딩하고자 한다면 Nero나 Apple iTunes의 외장 AAC코덱을 사용하여 따로 인코딩후에 먹싱해 주거나, 프라운호퍼 AAC소스를 가져와서 직접 ffmpeg을 컴파일 해서 인코딩을 하거나, Vorbis를 이용하여 -acodec libvorbis -ac 2 -aq 4 이런식으로 인코딩 할 수 있다. 단 Vorbis의 경우 일반적인 기기에서 호환성은 떨어진다. 더 다양한 옵션은 오디오 인코딩 가이드 참조.
• "outfile.mkv" - 출력 파일명이다. 확장자에 따라 영상 컨테이너(avi, mp4, mkv같은)를 자동으로 선택해주긴 하지만, 가급적이면 -format 옵션으로 출력 포맷을 지정해 주도록 하자. 참고로 확장자가 mp4인 경우에는 음성코덱으로 AAC, MP2, MP3, AC3 만 가능하다. Vorbis, Opus 는 불가능함.

2015년 12월부로 ffmpeg의 내장 AAC 인코더가 대폭 개선되었다고 발표했다. 링크1 링크2 제작자는 libfdk_aac와 비슷하거나 좀 더 우수한 성능을 나타낸다고 했지만 써본 사용자에 의하면 VBR 모드로는 여전히 부족하다고 하지만 CBR 모드로는 썩 괜찮다카더라 링크. 참고로 ffmpeg측의 주장대로 내장 aac가 (스테레오채널) 128kbps정도에서 음질이 상당한 것은 사실이지만 libfdk_aac에 비해 인코딩 속도는 다소 느린편이다. (대신 빌드를 따로 할 필요 없어 Zeranoe FFmpeg Build 같이 라이선스 문제로 libfdk_aac는 포함되지 않았지만 필요한 것들은 대부분 포함해서 바이너리로 공개하는 것들을 걍 쓰던 사람들의 편리성은 극대화 된 듯)

4.6 프라운호퍼 AAC인코더 libfdk_aac 라이브러리 빌드

내장 AAC 인코더가 영 좋지 못하기 때문에 FFmpeg에서 보다 고품질의 AAC 오디오를 사용하려면 프라운호퍼 코덱을 쓰는게 최선의 방법이지만 라이센스 문제로 배포되지는 못하고 직접 컴파일해서 써야된다. 일본에서 쉽게 빌드할수 있도록 툴을 제공하는 사이트가 있다. [2] 구글 번역기로 충분히 따라갈수 있다.
단, 일본어 윈도우 전용으로 제작된 툴이라 마지막에 바탕화면에 빌드.lnk 파일을 생성하는 과정에서 .NET Framework 에러가 나면서 바탕화면에 아이콘이 생기지 않는다. 에러가 뜨면 Quit 버튼을 눌러서 종료하면 된다. 윈도우 일본어 언어팩을 깔아도 소용없으니 주의할 것. .NET Framework 일본어 언어팩이 설치되어 있어야만 에러가 나지 않는다. 오류로 바탕화면에 링크파일이 생성되지 않아도 실행파일을 직접 찾아서 빌드하면 된다.
32비트: \oreBuild\mingw32\msys\home\x86\_bin\ore_BuildTool.exe
64비트: \oreBuild\mingw64\msys\home\x64\_bin\ore_BuildTool.exe
빌드하는데 상당한 시간이 걸리며 2기가 정도의 용량이 필요하다. 빌드가 완료된 FFmpeg.exe 파일의 위치는 다음과 같다.
32비트: \oreBuild\mingw32\_ffmpeg_\ffmpeg.exe
64비트: \oreBuild\mingw64\_ffmpeg_\ffmpeg.exe
빌드가 완료되면 나머지 파일들은 지워도 된다. ffmpeg -encoders 실행해서 libfdk_aac가 보이면 성공이다. 이 파일을 무단배포하면 라이센스 위반이니 주의할 것. 혼자만 사용하자.
그런데 프라운호퍼AAC 인코더는 아무리 비트레이트를 올려도 17,000hz 이상의 주파수는 칼같이 무조건 다 날려버린다. 낮은 비트레이트 인코딩에선 이해가 가는 부분이지만 높은 비트레이트에서도 이러는건 아무리 봐도 정신줄을 놓은것처럼 보인다. 이 연구소에는 고주파는 못듣는 노인네들만 있는 모양이다. 이러니까 MP3인코더에서 Lame한테 관광을 당하지 비트레이트를 높여서 인코딩 할때는 이 부분의 지정이 반드시 필요하다. -cutoff 18000 옵션에서 컷오프 주파수를 지정해주자. 최대값은 20000. 단, 낮은 비트레이트에서 컷오프 주파수를 무리하게 높게 잡으면 잘 들리지도 않는 고주파 부분이 데이터를 다 잡아먹어서 정작 중요한 저주파영역 음질이 골룸해질수 있으니 잘 판단하자. 자세한 인코딩 옵션은 [3]에서 확인.
그 외에 FFmpeg Launcher도 같이 제공하고 있으므로 일본어 능력자라면 사용해 보자. 윈도우 상에서 쉽게 인코딩 할수 있다.

5 그외 ffmpeg을 이용하는 프로그램들

• Kodi(전 XBMC)

6 국산 플레이어의 GPL 위반 의혹

KMPlayer, 곰플레이어, 팟플레이어 3개 플레이어의 경우 GPL 위반 의혹이 있다. 이것은 FFmpeg이 GPL과 LGPL의 이중 라이선스를 제공하고, 가이드라인을 안 지키면 GPL로 판단하기 때문이다. 갖다 쓸 때 LGPL로 해석될 경우에는 소스를 공개 안 해도 되지만, GPL이라면 전체 소스를 공개해야 한다. 이 때문에 3개 플레이어 전부 FFmpeg을 별다른 생각 없이 내장했다가 GPL 위반 의혹을 사게 되었다.

이 문제가 제기된 이후 소스를 공개한 것은 팟플레이어로, LGPL 라이선스와 함께 수정된 FFmpeg 소스코드를 다운받을 수 있는 주소를 제공하고, 글로벌 버전을 출시하며 설치시 ffmpeg를 기본 설치에서 빼 버렸다. 나머지는 별다른 대응이 없다.

iOS의 AVPlayer의 경우 소스코드 전체를 공개하고 있다. #다운로드 페이지 iOS와 App Store 심사의 특성상 LGPL에서 허용하는 라이브러리 다이나믹 링크로 처리할 방법이 없기 때문에 아예 소스코드 전체를 공개한 듯 하다. 이 때문에 앱스토어에서 "무인코딩"으로 검색하면 AVPlayer 이외에도 다른 국산 플레이어가 여러 개 튀어 나온다. 물론 소스코드 공개 이런거 없다.

상기 프로그램은 그나마 유명세를 타고 개발자들 사이에서 논란이 한 번 됐기에 인구에 회자되고 있을 뿐, 구글 플레이의 한국산 앱들 중에서도 ffmpeg를 사용하면서 라이센스를 위반한 것으로 보이는 앱이 수두룩 빽빽하다. 애플 앱스토어는 라이센스 위반으로 앱을 신고하면 앱이 내려가는 사례도 왕왕 있으나, 라이센스 정책 뿐만 아니라 온갖 부분에서 정책이 허술한 구글 플레이 쪽은 사실상 그냥 무법지대로 방치되고 있는 중.

상용이든 무료든 내장 코덱을 이용하는 프로그램치고 오픈소스가 아닌 경우 GPL 위반에서 벗어나기는 불가능하다. 해당 라이센스는 포함된 프로그램 코드 전부를 원하기 때문이다. Hall of Shame에 등재되어 있지 않는 프로그램은 GPL 위반이 아니라서가 아니라 대중에게 비교적 덜 알려진 경우에 불과하다. FFmpeg에 포함된 코덱들도 라이센스 이슈에서 완전히 자유로운 것은 아니다. GPL라이센스는 비교적 법적인 재제가 심화되는 나라의 개발자들한테서 점차 기피되고 있다.
추가바람

7 ffmpeg? libav?

우분투등의 몇몇 리눅스 배포판에는 ffmpeg를 설치하면 ffmpeg대신 avconv가 설치되는데, 이는 ffmpeg의 포크이다. ffmpeg 안에서 파벌이 갈리고 싸움이 일어났는데, 그 결과 의견이 다른 사람들은 따로 나와서 libav 라는 새로운 포크를 만들었다. libav 쪽은 ffmpeg 쪽을 완전히 무시하고 있는 상황이지만, ffmpeg 는 자신들이 개발하는것에 더해서, libav 쪽을 계속 모니터링하면서(아무래도 오픈소스니...) libav 에서 만든것들도 좍 긁어다가 ffmpeg 에 그대로 편입시키고 있는 상황. 덕분에 왠지 ffmpeg 가 드러운것같긴 하지만, 사용자 입장에서는 ffmpeg 쪽이 기능면에서 낫다. 2015년 8월 1일, ffmpeg의 리더 개발자가 libav를 직접적으로 명시하진 않았지만 불화로 인해 ffmpeg에서 갈라져나온 포크 프로젝트들에게 화해를 공식적으로 제안했다.

ffmpeg와 libav의 갈등에 대한 자세한 역사는 #FFmpeg-libav 분쟁 기록을 참고하면 좋다.