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를 인코딩하는데, 긴 파일의 인코딩 시간을 개선할 수 있다면 좋을 것임.