▲

GN⁺: FFmpeg, 수십 년 만에 "가장 복잡한 리팩토링"으로 CLI 멀티스레딩 도입

 (phoronix.com)
2P by neo 11달전 | favorite | 댓글 1개

FFmpeg CLI 멀티스레딩 지원

  • FFmpeg 명령줄 인터페이스(CLI)가 멀티스레딩을 지원하는 기능이 FFmpeg Git에 병합됨.
  • 이는 FFmpeg 7.0이 내년 초에 출시되기 전에 이루어진 변화로, 비디오 트랜스코딩에 널리 사용되는 중요한 오픈소스 프로젝트에 있어 큰 개선임.
  • 멀티코어 프로세서가 일반화된 현재, 이러한 개선은 매우 유익함.

복잡한 리팩토링 작업

  • FFmpeg 개발자들은 최근 기술 발표에서 이 멀티스레딩 작업을 "수십 년 만에 FFmpeg CLI에서 이루어진 가장 복잡한 리팩토링 중 하나"라고 설명함.
  • 개발자들은 사용자들에게 테스트를 요청하며, 발견된 문제를 FFmpeg Trac에 보고해 달라고 촉구함.

구현된 기술적 변화

  • 병합된 패치에는 스레드 인식 트랜스코드 스케줄링 인프라 추가, 인코딩을 별도의 스레드로 이동, 그 외 여러 저수준 변경사항이 포함됨.
  • FFmpeg를 스레드 아키텍처로 전환하는 것은 각 구성 요소(디뮬서, 디코더, 필터, 인코더, 먹서)가 별도의 스레드에서 이미 실행되고 있었지만, 이제 실제로 병렬로 실행될 수 있게 됨을 의미함.

GN⁺의 의견

  • FFmpeg의 멀티스레딩 지원은 비디오 트랜스코딩 작업의 효율성을 크게 향상시킬 수 있는 중요한 발전임.
  • 이러한 복잡한 리팩토링 작업은 개발자들에게 많은 도전을 제시했으며, 이는 FFmpeg가 지속적으로 현대 컴퓨팅 환경에 적응하고 발전하고 있음을 보여줌.
  • 사용자들과 개발자들에게 이 변화가 실제 성능에 어떤 영향을 미칠지 관찰하는 것은 흥미로운 일이 될 것임.
▲
neo 11달전  [-]
Hacker News 의견

  • 멀티스레딩/프로세싱 최적화에 대한 이론

    • 과거에는 이미지 하나를 읽고 처리하며 렌더링하는 데 상당한 시간이 소요되었으나, 하드웨어와 소프트웨어 기술의 발전으로 이제는 훨씬 빨라짐.
    • 예전에는 여러 워커가 한 프레임을 처리하는 것이 효율적이었지만, 현재는 단일 워커가 여러 워커를 동원하는 것보다 더 효율적으로 프레임을 처리할 수 있음.
    • 현대의 시스템은 FFmpeg가 처음 만들어졌을 때의 시스템과는 완전히 다른 환경을 가지고 있어, 작업 부하를 어떻게 정의하고 스케줄링하며 분배하고 추적한 후 최종 결과물로 합칠지에 대한 재고가 필요함.
    • FFmpeg 팀이 이러한 도전을 받아들인 것에 대해 칭찬함. FFmpeg는 오픈 소스 인프라의 정점으로, 문명이 구축되는 데 필수적인 요소임.

  • VDD@Dublin 행사의 강연 녹화

    • 강연의 녹화본을 찾고 있었으나, 저자의 사이트나 여기서 쉽게 찾을 수 없음.
    • 업데이트: YouTube에서 발견함!

  • 멀티코어 성능 향상에 대한 고민

    • 현재 인코더들은 동시에 같은 프레임을 처리하기 위해 여러 스레드를 사용함. 프레임을 여러 영역으로 나누고 각 스레드가 특정 영역을 처리하는 방식이 일반적임.
    • 대안으로, 키 프레임 세그먼트를 독립적으로 처리하는 방법을 제안함. 이 방법은 코덱을 일반적이고 효율적인 방식으로 병렬화할 수 있으며, 프레임을 영역으로 나누는 것으로 인한 압축 효율 저하나 스레드 간 통신 오버헤드가 없음.
    • 이 방법의 문제점으로는, 메모리에 N*키 프레임 주기의 프레임을 로드해야 하고, N 프레임을 인코딩하는 데 필요한 추가 메모리 오버헤드가 있음.
    • 그러나 많은 경우에 이러한 문제점들은 큰 문제가 되지 않을 것으로 보임. 대부분의 경우 많은 RAM을 사용하고 고정된 키 프레임 간격으로 출력하는 것에 만족함.
    • 프레임 내 병렬 처리와 키 프레임 세그먼트 병렬 처리를 결합하여 높은 병렬성을 달성하면서도 품질 저하를 최소화할 수 있음.

  • 지속적인 리베이스 작업의 도전

    • 매일 들어오는 변경 사항을 지속적으로 리베이스하는 것은 상당한 도전이었음.
    • 이제 FFmpeg에 통합되었기 때문에 앞으로는 작업이 훨씬 쉬워질 것임.
    • 큰 승리이며, 이는 속도 향상에 크게 기여할 것임.

  • FFmpeg의 가상 디스플레이 버퍼 스트리밍 시작 시간 개선 기대

    • LLMStack 프로젝트에서 FFmpeg를 사용하여 브라우저 비디오를 스트리밍함.
    • 현재는 각 도구를 호출할 때마다 파이프라인을 부팅하는 데 눈에 띄는 지연이 있음.
    • FFmpeg의 개선은 이러한 최적화 작업에 확실히 도움이 될 것임.

  • FFmpeg C API 강의 홍보

    • Udemy에서 FFmpeg C API를 가르치는 강의를 홍보함.

  • FFmpeg 코드베이스에 대한 궁금증

    • FFmpeg 코드베이스에 대해 잘 모르지만, 거대한 커밋 없이 천천히 어떻게 변경을 진행할 수 있을지 궁금함.
    • 발표에 따르면 700개의 커밋이 있었는데, 이것이 별도의 브랜치였는지, 아니면 프로젝트에 서서히 병합되었는지 궁금함.

  • 클라우드 서비스 운영자의 관점

    • Netflix와 같은 클라우드 서비스를 운영하는 경우, 이미 각 기계에서 수천 개의 FFmpeg 프로세스를 실행하고 있으므로, 본질적으로 이미 멀티코어 작업임.

  • VapourSynth의 스레드 필터 처리 경험 공유

    • 거의 10년 동안 VapourSynth에서 스레드 필터 처리를 즐기고 있음.
    • 이번 FFmpeg의 개선도 훌륭하지만, '품질' 비디오 인코딩을 위한 VapourSynth 전처리 + av1an 인코딩 작업 흐름에는 큰 변화가 없을 것임.

  • FFmpeg의 멀티코어 지원에 대한 질문

    • FFmpeg가 모든 포함된 코덱에서 멀티코어를 사용할 수 있게 되었는지 궁금함.
    • 오디오 호스팅 서비스를 위해 FFmpeg를 사용하여 LAME로 MP3를 인코딩하는데, 긴 파일의 인코딩 시간을 개선할 수 있다면 좋을 것임.
답변달기