예제로 배우는 FFmpeg

 (ffmpegbyexample.com)
9P by GN⁺ | ★ favorite | 댓글 1개
  • FFmpeg 작업은 옵션 조합이 복잡해지기 쉬운데, FFmpeg By Example는 실제 명령 예제로 필요한 미디어 처리 방법을 빠르게 찾게 해주는 문서 사이트임
  • GitHub 저장소, Discord 커뮤니티, 기여 페이지를 함께 제공해 사용자가 새 FFmpeg 활용 아이디어를 직접 제출할 수 있음
  • testsrc 필터 예제처럼 입력 소스, 해상도, 프레임레이트, 출력 파일을 한 명령으로 보여줘 명령 구조를 그대로 따라 해볼 수 있음
  • 예제는 비트레이트 계산, 이미지 리사이즈, 오디오 노이즈 감소, 전환 효과, 스트림 매핑, 하드웨어 가속, 메타데이터 처리 등 미디어 처리 작업 전반을 다룸
  • 각 예제가 태그와 개별 페이지로 나뉘어 있어 특정 필터나 변환 목적을 기준으로 필요한 FFmpeg 명령을 탐색하기 쉬움

예제 중심 FFmpeg 문서 사이트

  • FFmpeg By Example는 FFmpeg를 사용하는 다양한 방법을 예제 단위로 정리한 웹사이트임
  • 커뮤니티 참여와 기여를 위한 링크도 함께 제공함

testsrc 테스트 영상 생성 예제

ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 testsrc.mpg

인코딩·변환·하드웨어 가속

오디오 처리

이미지와 애니메이션

필터와 시각 효과

추출·분석·메타데이터

생성 소스와 출력 파이프

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • ffmpeg를 쓰는 즐거움이 1000%는 늘었음
    예전엔 지루하게 Google로 Stack Overflow 답을 찾아 조합해 명령어를 만들었는데, 이제는 ChatGPT가 대신 명령어를 써줘서 훨씬 편해짐

    • LLM 덕분에 ffmpeg를 일주일에도 여러 번 씀
      내 llm cmd 도구의 최고 활용처임:

      uv tool install llm
      llm install llm-cmd

      llm cmd use ffmpeg to extract audio from myfile.mov and save that as mp3

      https://github.com/simonw/llm-cmd

    • 오랫동안 ffmpeg를 정규식과 같은 상자에 넣어뒀음: “정말 배워야 하는데, 엄청 싫어하게 될 것 같다”는 느낌이었음
      그런데 ChatGPT가 나타나서 둘 다 해결해줌

    • 나도 마찬가지임. 이런 일은 AI가 완전히 맡아버렸고, 나는 오류 추적을 복사해 붙여넣는 중개자일 뿐임

    • 다른 도구들도 많이 나왔지만, 이런 연쇄 명령을 꽤 단순화해주는 스크립트를 방금 만들었음: llmpeg https://github.com/jjcm/llmpeg
      ffmpeg가 설치돼 있고 OpenAI 환경 변수 API 키가 설정돼 있으면 바로 동작할 것임

      데모: https://image.non.io/1c7a92ef-0917-49ef-9460-6298c7a9116c.we...

    • 복합 필터가 어떻게 동작하는지 배우고 나니 ffmpeg 사용 경험이 더 좋아졌음

  • 디지털화한 가정용 비디오테이프를 장면 감지로 클립으로 바꾸는 방법을 정리해 공개해야겠다고 떠올랐음
    누군가 검색할 수도 있으니, 꽤 잘 동작했던 gist를 남김 [0]. 다만 카메라 플래시나 흔들림에 속는 경우가 있어 시작/끝 파일을 따로 주고 ffmpeg로 다시 이어 붙여야 했음 [1]

    이상한 점은 최신 Mac 업데이트에서 -c:v h264_videotoolbox 없이 더 성능이 좋았다는 것임. Sequoia의 성능 회귀일 수도 있는데 잘 모르겠음. Nvidia GPU가 있는 Windows 머신의 대응 플래그는 -c:v h264_nvenc임. ffmpeg가 왜 자동 감지하지 않는지 궁금함. 이걸로 약 8배 성능 향상을 얻음
    회사에서 정말 월급값을 한 유일한 순간은, 비디오 처리를 위해 GPU 달린 클라우드 서버를 비싸게 더 쓰려던 참에 설치된 ffmpeg가 GPU 가속 없이 컴파일돼 있었다는 걸 발견했을 때였음

    [0] https://gist.githubusercontent.com/nielsbom/c86c504fa5fd61ae...

    [1] https://gist.githubusercontent.com/jazzyjackson/bf9282df0a40...

    • 클라우드 CPU의 문제는 소비자용 CPU에 들어 있는 하드웨어 비디오 인코더가 없다는 점이라, 훨씬 비싼 GPU 머신으로 가야 함
      솔직히 클라우드에서 하드웨어 가속을 써서 제대로 가격 비교를 해보진 않았는데, 실제로 해봤고 비용 대비 괜찮았다는 뜻인지 궁금함

    • ffmpeg로 빈 장면 감지를 해봤음
      SFO 비행 경로를 향한 카메라가 있고, 움직임 없는 프레임을 모두 제거했더니 지루한 구간 없이 비행기가 지나가는 연속 영상만 남게 됨

    • -c:v h264_nvenc는 여러 비디오를 한꺼번에 인코딩하는 일괄 인코딩에 유용함. 인코딩 처리량을 더 높일 수 있기 때문임
      다만 예전에 제한적으로 실험했을 때 출력 품질은 libx264보다 약간 나빴음. 우회 방법이 있는지는 모르지만, 나만 겪은 일은 아니었음

    • ffmpeg가 이걸 자동 감지하지 않는 이유는, 하드웨어 인코딩이 보통 설정 폭이 좁고 정교한 소프트웨어 코덱보다 절충이 크며, 같은 매개변수라도 정확히 같은 결과를 내지 않기 때문임
      게다가 시스템에 선택 가능한 하드웨어 API가 여러 개 있는 경우도 많고, 기능도 서로 다름

      FFmpeg는 복잡한 명령줄 도구이고 세부를 배울 의지가 있는 사용자를 대상으로 하니, 가정에 기반해 기본값을 정하는 게 맞는지 잘 모르겠음

    • 스니펫을 보면 디인터레이스를 하지 않는 것 같음
      디지털화 전 클립이 이미 디인터레이스돼 있다면 괜찮지만, 아니라면 인터레이스 자료를 프로그레시브로 인코딩하면서 품질을 망가뜨리는 셈임. bwdif 필터를 추가해서 30i 콘텐츠가 60p로 인코딩되게 해보는 게 좋음. 원래 비디오테이프에 더 가까워 보일 것임

  • 시간이 지나며 ffmpeg의 여러 부분에 꽤 익숙해졌음. CLI에는 나름의 논리가 있고, 순서 의존적임. 모든 Unix CLI가 그렇지는 않음
    최근엔 좀 더 난해한 기능을 만져보고 있음. 예를 들어 꽤 느린 머신에서 비디오 카메라의 원시 영상을 바로 저장하는 일임. 현미경을 만들었고 카메라에서 120FPS로 원시 비디오 형식(YUYV 1280x720) 프레임을 읽는데, 그대로 디스크에 저장하면 분당 기가바이트 단위로 커짐. 디스크는 싸지만 낭비 같아서, 정확한 이미지를 빠르게 압축해 저장할 수 있는 거의 무손실 기법들을 살펴봤음

    ffmpeg에서 RGB24 변환이 매우 느리다는 걸 알게 돼서, 명령줄을 이것저것 만져본 끝에 다음으로 정착함:

    ffmpeg -f rawvideo -pix_fmt yuyv422 -s 1280x720 -i test.raw -vcodec libx264 -pix_fmt yuv420p movie.mp4 -crf 13 -y

    원시 비디오는 컨테이너가 없어서 “픽셀 형식”이나 “이미지 크기” 같은 메타데이터가 없으므로 직접 제공해야 함. 순서 의존적이라 -i test.raw 앞의 모든 것은 입력 디코딩용이고, 뒤의 모든 것은 출력 작성용임. 아주 작은 픽셀 형식 변환 하나만 수행하고(ffmpeg가 매우 빠르게 처리 가능), 컨테이너가 있는 거의 무손실 형식으로 데이터를 씀. 대부분의 경우 컨테이너는 .mkv가 가장 좋았음

    명령줄을 싫어해서 결국 ffmpeg-python을 사용했고, 다음 코드에서 명령줄을 조합하게 했음:

    self.process = (
    ffmpeg.
    input(
    "pipe:",
    format="rawvideo",
    pix_fmt="yuyv422",
    s="{}x{}".format(1280, 720),
    threads=8
    )
    .output(
    fname, pix_fmt="yuv422p", vcodec="libx264", crf=13
    )
    .overwrite_output()
    .global_args("-threads", "8")
    .run_async(pipe_stdin=True)
    )

    그리고 실제로는 그 프로세스의 표준 입력에 프레임을 write()함. 머신에 코어가 12개 있고 현미경 구동에 항상 최소 2개를 쓰기 때문에 스레드 수를 제한해야 했음

    아직도 더 좋고 더 빠른 무손실 YUV 인코딩을 찾는 중임

    • 순서 의존적인 건 적절함. Unix 파이프라인도 구성 요소의 순서에 의존하고, 복잡한 FFMpeg 호출은 그와 비슷한 일을 하기 때문임
      ffmpeg-python 같은 “유창한 인터페이스” 미학을 좋아하는 사람이 많지만, Python에서는 종종 Python답지 않다고 여겨짐. ffmpeg-python은 명령줄 순서를 가깝게 반영하도록 설계된 것으로 이해함

      표준 라이브러리와 내장 타입 설계가 강화하는 선호는 강한 https://en.wikipedia.org/wiki/Command%E2%80%93query_separati...임. 이 원칙이라면 대략 다음처럼 보일 것임:

      ffmpeg(global_args=..., overwrite_output=True).process_async(piped_input(...), output(...))

      입력을 별도 구성 과정으로 만들면 다른 런타임 타입이 생기고, 처리 코드에도 표준 입력에서 읽어야 한다는 신호를 줄 수 있음

    • 더 찾을 필요 없음: FFV1 https://trac.ffmpeg.org/wiki/Encode/FFV1

    • 한 단어만 추천하고 싶음: 램디스크
      중간 단계 처리를 하되 보관하고 싶지 않은 파일이 있다면 램디스크임. 정말 좋음

  • FFmpeg 숙련자가 쌓아온 지식을 모아 관리하는 웹사이트일 줄 알았는데, 처음 눌러본 예제에서 바로 실망했음
    https://www.ffmpegbyexample.com/examples/l1bilxyl/get_the_du...

    문자열 처리를 하려고 도구를 두 개나 더 호출하지 말아야 함. FFprobe만으로도 지속 시간이나 원하는 값을 바로 줄 수 있음:

    ffprobe -loglevel quiet -output_format csv=p=0 -show_entries format=duration video.mp4

    처음 동작하는 것에서 멈추지 말고, 동작한 뒤에는 더 개선할 방법이 있는지 생각해봐야 함

    • 원 글 작성자임. “미쳤다”라고 부르는 건 좀 과장 아닌가 싶음
      그래도 제시한 해법이 더 마음에 듦

  • 좋음. 내가 쓰는 ffmpeg 치트시트가 떠오름. ffmpeg를 자주 쓰는 사람은 다 비슷한 메모 모음을 갖고 있을 것 같음
    https://github.com/fastily/cheatsheet/blob/master/ffmpeg.md

  • FFmpeg는 너무 가끔 써서 정확한 문법이 절대 머리에 남지 않는 도구 중 하나임. 결국 필요한 명령줄은 LLM에게 받아 쓰게 됨
    비슷하게 힘들었던 유일한 도구는 LSI Logic의 1990년대식 MegaCLI였음. 그것도 해마다 거의 안 쓰지만, 압박 속에서 정확히 써야 하는 종류였음

    • FFMPEG를 15년 넘게 써왔지만 아직도 명령을 거의 기억하지 못함. 그래도 FFMPEG를 쓸 때 LLM은 정말 대단함
      ChatGPT와 Claude에 “비디오를 mkv로 리먹스하고, subtitle.srt를 파일에 포함하고, 0:00:05부터 0:01:00까지만 원한다”라고 하면 훌륭하게 처리함. 궁금할까 봐 결과는 이랬음: ffmpeg -i input.mp4 -i subtitle.srt -ss 00:00:05 -to 00:01:00 -map 0 -map 1 -c copy -c:s mov_text output.mkv

      ffmpeg 명령 생성만 목표로 한다면 얼마나 작은 LLM을 만들 수 있을지 궁금함. 정적 웹페이지에 올려 로컬에서 실행할 만큼 작아질 수도 있지 않을까?

    • 15년째 내가 자주 쓰는 문법을 담은 개인 메모 문서를 유지해왔음. 그래도 안 되면 bash 기록을 grep함

    • 나도 같음. 머리에 남는 건 형식 X에서 .mp4로 바꾸는 것뿐임. 나머지는 매번 다시 찾아봐야 함
      관련 XKCD https://xkcd.com/1168/

    • 며칠 전에 농담 반 진담 반으로, LLM이 내가 원하는 ffmpeg 플래그를 알려주기만 한다면 열대우림을 다 태워도 그만한 가치가 있을지 모른다고 했음

  • GStreamer도 있다는 걸 잊지 말아야 함. 파이프라인 기반이라 명령줄과 문서가 ffmpeg보다 조금 더 이해하기 쉽고, 조합도 좀 더 제정신임
    나는 무거운 비디오 작업에서는 ffmpeg를 완전히 그만두고 GStreamer만 씀

    • GStreamer는 프로그래밍으로 파이프라인을 만들 때 더 많은 제어권과 친절한 API를 줄 수 있음
      하지만 일회성 작업에는 ffmpeg가 훨씬 친절해 보임. 예를 들어 ffmpeg에는 합리적인 x264 기본값이 있지만, gst-launch로는 품질 좋은 x264 인코딩을 하려면 정말 뭘 하는지 알아야 함
    • FFmpeg도 파이프라인 기반이라고 생각했음. 필터 그래프가 있지 않나? 뭔가 놓치고 있는 건가
      소스, 싱크, 변환 필터의 복잡한 그래프를 구성할 수 있음
    • GStreamer는 방치된 프로젝트처럼 느껴짐. 최근 큰 취약점도 있었고 문서도 꽤 망가져 있음

  • 이 사이트를 보완하기 좋을 만한 ffmpeg 책 GitHub 저장소가 있음:
    https://github.com/jdriselvato/FFmpeg-For-Beginners-Ebook

  • ffmpeg는 늘 GUI 애플리케이션을 TUI 형식에 억지로 구겨 넣은 것처럼 느껴졌음
    C API도 몇 번 불쾌하게 써봤는데, 여러 면에서 직관적이긴 하지만 잘못된 상태를 표현하기가 너무 쉬움. “그냥 동작하는” 실시간 AV1 인코딩 프레임워크가 있으면 좋겠음

    • 기본적으로 GUI 대체 도구인 HandBrake를 먼저 찾게 되는 거의 유일한 도구임. 일괄 처리를 할 때만 예외임
      순수 ffmpeg GUI도 몇 가지 있음. 비디오 작업은 명령줄이 내 머릿속 처리 방식과 잘 맞지 않는 뭔가가 있음

    • API로는 GStreamer를 추천할 수 있음. Rust 바인딩을 써서 C API에는 아주 익숙하진 않지만 좋아 보였음
      GObject 때문에 장황해지는 부분은 있지만, 이해하고 나면 API의 모든 객체와 일관되게 상호작용할 수 있음. 필요한 복잡성이 정말 많지만(비디오는 어렵다), 설계와 구현, 문서화가 꽤 잘돼 있음

      일반적인 사용 사례라면 Bins(decodebin, transcodebin, playbin)가 꽤 쉽게 만들어줌. 더 복잡한 사용 사례라도 설계의 유연성 덕분에 가능함

    • 통찰은 마음에 들지만, TUI는 그래픽적인 무언가이고 ffmpeg는 그냥 CLI임
      TUI 도구가 있다면 멋질 것 같음. https://github.com/Twinklebear/fbed 같은 것이되 기능이 더 완성된 형태면 좋겠음

  • Linux 시스템에서는 ffmpeg를 정적 빌드하는 걸 좋아함. 배포판 버전이 너무 오래됐거나 선호하는 모듈이 빠져 있을 때가 있기 때문임
    이 컨테이너화된 버전이 아주 유용했음: https://github.com/wader/static-ffmpeg

답변달기