오늘날의 Reels 트렌드에 FFmpeg가 비디오 영역에서 제공하는 유연성

한 번의 업로드, 여섯 가지 결과물

오늘날 단일 원본 푸티지는 9:16 수직형 릴스, 1:1 정사각형 컷, 16:9 가로형 버전, 자동 재생을 위한 음소거 및 자막 버전, 로고와 인트로/아웃트로가 포함된 브랜드 컷, 그리고 연결이 약한 환경에서도 즉시 로드되는 압축 버전으로 변환되어야 합니다. 동일한 콘텐츠가 매일 모든 캠페인과 모든 크리에이터에게 여섯 가지 이상의 형태로 제공됩니다.

이를 대규모로 해결하려면 비디오를 수동으로 편집하는 것이 아니라 프로그래밍 방식으로 변환해야 합니다. 이것이 우리 파이프라인에서 FFmpeg가 수행하는 역할입니다.

왜 FFmpeg인가

FFmpeg는 오디오 및 비디오를 변환, 필터링 및 인코딩하는 무료 오픈 소스 커맨드라인 도구입니다. UI가 없으며, 원하는 것을 명령어로 정확히 설명하면 FFmpeg가 이를 실행합니다. 이것이 바로 핵심 가치 제안입니다. 즉, 명령은 코드로 생성될 수 있고, 사용자별로 매개변수화될 수 있으며, 파이프라인에 대기열에 추가되어 사람의 개입 없이 서버에서 실행될 수 있습니다. 비디오 편집은 클릭을 통해 수행하는 것이 아니라 프로그래밍하는 것이 됩니다.

단순히 "작동하는 비디오 도구"가 아니라 이 특정 문제에 FFmpeg가 적합한 세 가지 특성이 있습니다.

결합 가능한 필터. FFmpeg의 필터그래프를 사용하면 스케일 → 크롭 → 오버레이 → 페이드를 단일 패스로 연결할 수 있습니다. 이는 각 단계에서 중간 파일을 작성하는 것을 피하기 때문에 중요합니다. 모든 작업 사이에 재인코딩하는 단순한 파이프라인은 렌더링 시간과 스토리지 소모를 증가시킵니다. 체이닝은 다단계 변환을 단일 인코딩으로 유지합니다.

재인코딩뿐 아니라 스트림 레벨 작업. 트리밍과 같은 작업의 경우, FFmpeg는 기존 스트림을 디코딩하고 재인코딩하는 대신 복사할 수 있습니다.

ffmpeg -i input.mp4 -ss 00:00:08 -t 15 -c copy highlight.mp4

-c copy는 몇 초 만에 완료되는 트리밍과 전체 재인코딩만큼 시간이 걸리는 트리밍의 차이입니다. 우리는 픽셀 데이터를 건드릴 필요가 없는 작업(트리밍, 형식 리먹싱)에는 이를 사용하며, 스케일링이나 오버레이와 같이 실제로 필요한 단계에만 전체 재인코딩을 남겨둡니다.

하드웨어 인식 인코딩. FFmpeg는 CPU 전용 libx264 대신 GPU 인코더(NVENC, QSV, VideoToolbox)를 통해 라우팅할 수 있습니다. GPU 인코딩은 대량 처리 시 원시 처리량에서 우위를 점하며, libx264는 주어진 비트레이트에서 더 예측 가능하고 조절 가능한 품질을 제공합니다. 어떤 것을 사용할지는 결정된 기본값이 아닌 실제적인 절충점입니다. 우리는 품질 관리가 가장 중요한 브랜드 관련 작업에는 CPU 인코딩을 선호하고, 대량의 낮은 우선순위 배치 작업에는 GPU 경로를 남겨둡니다.

파이프라인이 FFmpeg를 실제로 사용하는 방법

리프레이밍. 

가장 일반적인 요청은 "모든 곳에 맞게 만들어달라"는 것입니다. 가로 원본은 스케일 및 크롭을 통해 세로 릴스로 변환됩니다. 단순한 크롭은 빠르지만 프레임의 일부를 버리게 됩니다. 중앙에 있는 피사체에는 괜찮지만, 피사체가 중앙에서 벗어날 때는 좋지 않습니다. 이러한 경우, 우리는 올바르게 스케일된 전경 복사본 뒤에 흐릿한 전체 프레임 배경을 사용하여 아무것도 잘려나가지 않도록 합니다.

ffmpeg -i input.mp4 -filter_complex \
  "[0:v]scale=1080:1920,boxblur=20:5[bg]; \
   [0:v]scale=1080:-2[fg]; \
   [bg][fg]overlay=(W-w)/2:(H-h)/2" \
  -c:a copy output_blurred.mp4

이는 단일 기본 필터가 아닌 의도적인 두 갈래 결정입니다. 안전할 때는 크롭을 사용하고, 그렇지 않을 때는 블러 폴백을 사용합니다.

브랜딩, 자막, 오디오. 로고, 인트로, 아웃트로는 매개변수화된 오버레이 및 연결로 적용되므로, 파이프라인 코드를 건드리지 않고도 브랜드별로 위치, 크기, 불투명도를 변경할 수 있습니다. 자막은 별도의 자막 트랙으로 제공되는 대신 프레임에 직접 삽입됩니다. 자동 재생 음소거 피드는 자막이 대상 플랫폼이 적용하는 재인코딩을 견뎌야 함을 의미하며, 삽입된 자막은 항상 그렇지만 자막 트랙은 그렇지 않을 때가 있습니다. 오디오는 믹싱되고 음량 정규화되어 스크롤 피드에서 이전 클립보다 갑자기 소리가 커지는 클립이 없도록 합니다.

배포. 모든 출력은 +faststart로 인코딩됩니다. 이는 파일 메타데이터를 앞으로 이동시켜 파일 전체를 다운로드하기 전에 재생을 시작할 수 있게 합니다. 이는 특히 짧은 형식의 비디오에서 인지되는 로드 시간에 큰 영향을 미치는 작은 플래그입니다.

여전히 고민 중인 절충점

여기서 모든 결정이 확정된 것은 아닙니다. GPU vs. CPU 인코딩은 우리가 가장 많이 재검토하는 부분입니다. 볼륨이 증가함에 따라 GPU 처리량은 매력적이지만, 비트레이트당 품질 일관성은 브랜드에 중요한 출력의 경우 여전히 CPU 인코딩에 유리합니다. 현재 이 분할은 작업 유형별로 수동으로 처리되고 있습니다. 이를 자동적이고 품질 인식 라우팅 결정으로 만드는 것이 우리가 구축하고 있는 이 파이프라인의 다음 단계입니다.

이것이 중요한 이유

종합적으로, 한 번의 업로드는 수직, 정사각형, 가로형 변형으로 재구성하고, 브랜딩하며, 자막을 삽입하고, 가장 강력한 컷으로 다듬고, 오디오를 믹싱 및 정규화하고, 빠른 배포를 위해 압축하는 파이프라인을 트리거합니다. 이 모든 과정에서 편집자는 타임라인을 열 필요가 없습니다. 각 작업은 독립적이고 상태 비저장이므로, 더 확장한다는 것은 단순히 더 많은 FFmpeg 워커를 병렬로 실행하는 것을 의미합니다.

릴스 트렌드는 콘텐츠의 모습을 바꾸었을 뿐만 아니라, 수동 편집으로는 따라잡을 수 없는 타임라인에서 단일 콘텐츠가 취해야 할 형태의 수를 바꾸었습니다. FFmpeg는 비디오를 수동으로 클릭해야 하는 것이 아니라 프로그래밍 가능하고 구성 가능한 것으로 취급하기 때문에 이러한 변화에 보조를 맞출 수 있습니다. 이것이 이 파이프라인이 확장되는 실제 이유입니다. 즉, FFmpeg가 추상적으로 강력해서가 아니라, 그 안에 있는 모든 결정(크롭 vs. 블러 폴백, 스트림 복사 vs. 재인코딩, GPU vs. CPU)이 기본값으로 처리되는 대신 사례별로 의도적으로 이루어지기 때문입니다.

이와 같은 파이프라인을 구축 중이고 아키텍처에 대한 다른 관점을 원하신다면, 저희에게 문의하십시오.