▲
GN⁺ 8달전 | parent | ★ favorite | on: FFmpeg 8.0 릴리즈 (ffmpeg.org)
Hacker News 의견

  • FFmpeg 개발자들과 기여자들에게 감사를 전함

    • 오디오/비디오 자동화가 필요할 때마다 FFmpeg을 항상 사용해왔음, 온라인 비디오 툴들도 대부분 이 툴을 핵심 엔진으로 사용하거나 UI 래퍼로 활용하고 있음
    • 오늘 FFmpeg.Wasm 프로젝트(https://github.com/ffmpegwasm/ffmpeg.wasm)가 있다는 것도 알게 됨
    • 2024년 1월에 1993년 애니 영화의 프레임을 15분 단위로 추출한 뒤, Real-ESRGAN-ncnn-vulkan(https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan)을 사용하여 업스케일링하고, 결과 프레임을 4K로 다시 조합했던 경험 공유
    • 만약 이 작업 흐름에 UI를 추가했다면, 요즘 인기 있는 Topaz AI 같은 툴이 될 수 있었을 것이라는 생각을 해봄
    • 업스케일된 샘플 이미지도 공유함(샘플 이미지)
    • 직접 ffmpeg를 쓰지 않을 때조차 이를 내장한 도구들을 자주 사용함
      • 최근 오래된 DVD에서 추출한 저화질 애니를 k4yt3x/video2x를 통해 업스케일함, 설치가 쉬웠고 libffmpeg가 내장돼 있었음
      • 인코딩 시 FFmpeg와 동일한 인자를 쓸 수 있었음
      • 최적 인자 선택을 위해 ffmpeg로 짧은 장면을 여러 파라미터 세트로 인코딩, 다시 ffmpeg로 스틸 이미지를 추출해 비교함

  • FFmpeg가 컴퓨트 셰이더 기반 비디오 엔코더와 디코더를 도입한 점을 기쁘게 생각함

    • 하드웨어에서 널리 지원되는 코덱은 H.264, H.265, AV1 정도라서, 다른 코덱도 플랫폼 가속이 가능하면 좋을 것임 (효율이 좀 떨어지더라도 의미 있음)
    • 새로운 ProRes 인코더가 현재 진행 중인 프로젝트에 유용하게 느껴짐
    • 널리 사용되는 일반적인 코덱들은 병렬 디코딩에 적합하지 않아 지원이 어렵다는 설명이 이해감
    • 수만 개의 스레드를 사용해야 하는데, 프레임 간, 타일 간 데이터 의존성 때문에 병렬화가 쉽지 않음
    • 인코더는 디코더보다 융통성이 좀 더 있을 것 같은데, VP9(https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/) 같은 걸 컴퓨트 셰이더로 인코딩하는 건 도전적인 과제일 것 같음

    • 비디오 인코더/디코더를 컴퓨트 셰이더로 구현한 것에 대한 기쁜 소식을 다시 한 번 공유함

      • 과거에는 표준화된 인실리콘 하드웨어 인터페이스만 있었기 때문에 Vulkan 기반 인코더/디코더가 범용적인지 물었다가 웃음샀던 경험 있음
      • 이러한 개선이 구형 하드웨어에서도 제공되는 점이 정말 멋짐, 이런 식으로 새로운 코덱 및 전체 품질 향상 루트를 열 수 있기 바람

    • 디코더 최신 동향을 10년 넘게 살펴보지 않았지만, 직관적으로는 GPU 가속이 픽셀 데이터로 바뀌는 후반 처리에 큰 도움이 될 거라 예상함

      • 초기 디컴프레션은 CPU에서, 이후 디컴프레션된 데이터를 GPU로 전송해 최종 변환 작업(모션 벡터 적용, iDCT 등)을 하면 될 것 같음
      • 완성 프레임이 이미 GPU 텍스처로 있으면 디스플레이 오버헤드도 적음
      • 내 직감이 어느 정도 맞았는지 궁금함

    • FFmpeg 메인테이너들의 재능에 매번 놀라움을 느낌, 이런 고난이도 작업을 무료로 해주는 점이 대단함

    • 이 릴리즈 노트가 매우 흥미로움

      • 최근 몇 주 동안 WebGPU 컴퓨트 셰이더로 ProRes 디코더를 제작했는데, 충분히 빠르게 동작함 (Apple은 아마도 자체 하드웨어 가속을 쓸 것이라 생각함)
      • 이 경로가 Android의 새로운 APV 코덱에도 잘 맞을 것 같음
      • ProRes 비트스트림 스펙은 SMPTE에 제출되어 있지만, ProRes RAW에 관한 정보는 찾기 힘들었음
      • 소프트웨어 및 컴퓨트 기반 구현이 등장해 매우 흥미롭다고 느낌, 아마 ffmpeg 개발자들이 리버스 엔지니어링한 듯함
      • 코드 대강 보니 일반 ProRes와 크게 다르지 않아 보임
      • ProRes 스펙 문서

  • FFmpeg를 사용할 때마다 감탄하게 됨 (매뉴얼을 다시 찾아보거나 LLM의 도움을 받을 필요가 있긴 하지만, 시각적 옵션에서 명령을 만들어주는 GUI를 사용할 때조차도 느낌)

    • 이제는 필수적인 트랜스코딩 멀티툴이 된 듯함
    • Vulkan 1.3 기반 프로세싱을 도입한 건 좋은 결정으로 생각함
    • 어제 보니 Asahi Linux on Mac도 같은 표준을 지원한다는 것도 알게 됨

    • FFmpeg 인자는 ‘원조 프롬프트 엔지니어링’에 해당한다는 재치 있는 표현을 남김

    • LLM과 FFmpeg, ImageMagick 같은 복잡한 커맨드라인 툴은 환상적인 조합임

      • 원하는 작업을 자연어로 설명만 하면 바로 실현되는 완벽한 미래형 UI/UX라고 느낄 정도임
      • 예시로 폴더의 모든 이미지를 특정 크기로 크롭, 채도 조정, TIFF로 저장, 영상 루프로 조립해 웹용 인코딩까지 한 번에 처리하는 시나리오를 상상해봄

    • LLMs는 FFmpeg용 인터페이스로 훌륭하게 작동함

  • ffmpeg로 복잡한 CLI 명령을 만드느라 노력의 50%를 허비하고, 나머지 50%는 셸 이스케이프와 싸우느라 쓴다는 농담 섞인 현실을 공유함

    • 특히 텍스트를 영상에 입힐 때 텍스트 이스케이프가 매우 어렵게 다가옴
    • 파이썬에서 많은 인자(필터 등)와 함께 ffmpeg를 부를 때 완벽한 방법을 찾은 사람이 있는지 궁금함 (r-strings? heredocs? 등)

  • FFmpeg 다양한 기능을 쉽게 다룰 수 있는 좋은 GUI 프론트엔드가 있는지 궁금해함

    • 때로는 그냥 리멕스(remux)만 필요하거나, 동일 코덱의 영상/오디오 스트림을 결합만 하고 싶을 때가 있음

    • 영상 결합은 쉽게 들리지만 생각보다 변수와 이슈가 많다는 점을 강조함

      • 타임베이스, 시작 오프셋, 프레임 크롭, FPS 차이, B 프레임, 오픈 GOP 등의 변수로 인해 특정 재생 환경에서 문제 생길 수 있음
      • 오디오 역시 샘플레이트 차이 등 다양한 변수가 존재함
      • Lossless-Cut 프로그램이 언급되었는데, 호환성 검사 기능이 유용함
      • 하지만 영상을 MPEG-TS로 변환한 뒤 합치는 게 여러 문제를 우회하는데 좋음, 램디스크에서 빠르게 처리 가능함
      • 예시로 사용할 수 있는 ffmpeg 명령줄 시퀀스도 공유함

    • Handbrake가 그 역할을 잘 수행해줌

      • 기능 면에서 충분하며, 약간 올드하긴 하지만 여전히 유용하게 사용 가능함

    • 맥 사용자라면 ffWorks(https://www.ffworks.net/index.html)를 추천함

      • 대부분의 기능을 쉽게 접근할 수 있고, 배치 처리 및 프리셋 설정도 지원함
      • 개발자가 매우 적극적으로 지원해줘서 가장 좋아하는 앱 중 하나이며, 가치가 높아 도네이션도 하고 있음
      • Handbrake와 Losslesscut도 훌륭하지만, ffWorks의 완성도를 경쟁할 앱이 다른 플랫폼엔 없는 듯함

    • 본인에게 가장 좋은 프론트엔드는 ChatGPT라고 생각함

      • 자연어로 원하는 작업을 설명하면 굉장히 정확한 ffmpeg 명령어를 생성해줌

    • Lossless-cut 프로그램 확인을 권장함

  • FFmpeg의 변경내역(Changelog)을 확인할 수 있는 링크(https://github.com/FFmpeg/FFmpeg/blob/master/Changelog)를 공유함

  • 흥미로운 소식임을 짧게 표현함

    • 이 동영상이 풍자인지, 진지한지 궁금해함

  • ffmpeg가 ssl, zlib, sqlite 다음으로 가장 많이 쓰이는 라이브러리 4위가 아닐까 하는 개인적 의견을 제시함 (비디오가 2025년에는 정말 어디에나 존재한다는 전제에서)

    • 동의는 어렵다고 봄, 비디오 처리는 주로 미디어를 받는 서버에서 필요하기 때문임

      • 대부분의 휴대폰이 ffmpeg로 영상 처리하지 않는다는 점을 언급함

    • curl이 더 상위권일 수도 있고, "SSL"은 구현체가 다양해서 수치가 분산될 것임

    • NixOS 인프라의 fastly 메트릭 로그(https://github.com/NixOS/infra/blob/main/metrics/fastly/README.md)를 데이터 소스로 제안함

    • Qt, libpng, libusb 등 ffmpeg보다 더 많이 쓰이는 라이브러리들이 꽤 된다고 생각함

    • Arch Linux의 패키지 통계(https://pkgstats.archlinux.de/packages)도 확인해볼 만함

  • Vulkan 컴퓨트 셰이더 구현이 특히 FFv1과 ProRes RAW에서 멋지다고 생각함

    • 고정 기능 하드웨어 디코더를 완전히 우회하므로 메모리 대역폭 영향이 어떻게 되는지 궁금함
    • FFv1의 컨텍스트 적응형 산술 부호화는 본질적으로 연속적이라 속도 낼 수 없을 것 같지만, 매우 큰 속도 향상을 얻고 있다는 점에 놀람
    • 여러 심볼을 동시에 병렬화하거나 슬라이스 단위로 병렬화하는 방식인지, 전통적으로 GPU로 산술 부호화 가속이 힘든 이유가 있었는데 ffmpeg 팀이 어떤 트레이드오프를 했는지 궁금함
    • 해당 구현의 프로파일링 경험이 있는 사람이 있다면, 엔트로피 디코딩 단계에서의 점유율과 대역폭 선택에 대해 듣고 싶음

  • ffmpeg는 너무나도 많은 도구의 기반을 이루고 있음

    • 대중은 미디어 업계에 ffmpeg가 얼마나 기여했는지 잘 모르는 경우가 많음
    • 오디오/비디오 자동화가 필요할 때마다 항상 찾게 되는 툴임