Én upload, seks leverancer
En enkelt stykke kildemateriale skal i dag blive til en 9:16 vertikal reel, et 1:1 kvadratisk klip, en 16:9 landskabsversion, en lydløs variant med undertekster til autoplay, et brandet klip med logo og intro/outro, og en komprimeret version, der indlæses øjeblikkeligt på en svag forbindelse. Samme indhold, seks eller flere former — multipliceret på tværs af hver kampagne og hver skaber, hver dag.
At løse det i stor skala betyder, at video skal transformeres programmatisk, ikke redigeres manuelt. Det er den opgave, FFmpeg udfører i vores pipeline.
Hvorfor FFmpeg, specifikt
FFmpeg er et gratis, open-source command-line værktøj til konvertering, filtrering og kodning af lyd og video. Det har ingen UI — du beskriver præcis, hvad du ønsker som en kommando, og den udfører det. Det er hele værdiforslaget: en kommando kan genereres af kode, parameteriseres per bruger, sættes i kø i en pipeline og køres på en server uden menneskelig involvering. Videoredigering bliver noget, du programmerer, i stedet for noget, du klikker dig igennem.
Tre egenskaber gør det til det rette valg til dette specifikke problem, snarere end blot "et videoværktøj, der virker":
Sammensættelige filtre. FFmpeg's filtergraph lader dig kæde scale → crop → overlay → fade ind i et enkelt gennemløb. Det er vigtigt, fordi det undgår at skrive midlertidige filer ved hvert trin — en naiv pipeline, der re-enkoder mellem hver operation, multiplicerer både renderingstid og storage churn. Kædning holder en multi-trins transformation til én encode.
Stream-level operationer, ikke kun re-enkodninger. For operationer som trimning kan FFmpeg kopiere eksisterende streams i stedet for at dekode og re-enkode dem:
ffmpeg -i input.mp4 -ss 00:00:08 -t 15 -c copy highlight.mp4
-c copy er forskellen mellem en trimning, der er færdig på sekunder, og en, der tager lige så lang tid som en fuld re-enkodning. Vi bruger den, hvor operationen ikke kræver at røre pixel data — trims, format remuxing — og reserverer fuld re-enkodning til trin, der faktisk har brug for det, såsom skalering eller overlay.
Hardware-aware kodning. FFmpeg kan rute gennem GPU encodere (NVENC, QSV, VideoToolbox) i stedet for CPU-only libx264. GPU kodning vinder på rå throughput ved høj volumen; libx264 giver stadig mere forudsigelig, justerbar kvalitet ved en given bitrate. Hvilken man skal bruge er en reel afvejning, ikke en fast standard — vi foretrækker CPU kodning til alt, der er brand-rettet, hvor kvalitetskontrol betyder mest, og reserverer GPU-veje til høj-volumen, lavere-prioritets batches.
Hvordan pipelinen faktisk bruger det
Reframing.
Den mest almindelige anmodning er "få dette til at passe overalt." En horisontal kilde bliver en vertikal reel via scale-and-crop. Direkte cropping er hurtigt, men fjerner en del af billedet — fint til centrerede motiver, dårligt når motivet bevæger sig væk fra midten. I disse tilfælde falder vi tilbage til en sløret, fuld-ramme baggrund bag en korrekt skaleret forgrundskopi, så intet bliver skåret fra:
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
Det er en bevidst beslutning med to veje, ikke et enkelt standardfilter — crop, når det er sikkert, blur-fallback, når det ikke er det.
Branding, undertekster, lyd. Logoer, intros og outros anvendes som parameteriserede overlays og sammenkædninger, så position, størrelse og opacitet ændres per brand uden at røre pipeline-koden. Undertekster brændes direkte ind i frames i stedet for at sendes som et separat undertekstspor — autoplay-muted feeds betyder, at underteksten skal overleve enhver re-enkodning, som destinationsplatformen anvender, og en indbrændt undertekst gør det altid; et undertekstspor gør det nogle gange ikke. Lyden mixes og loudness-normaliseres, så ingen klip er skræmmende højere end det forrige i et scroll-feed.
Levering. Hvert output enkodes med +faststart, som flytter filmetadata til fronten, så afspilning kan begynde, før hele filen er downloadet — et lille flag med en uforholdsmæssig stor effekt på den opfattede indlæsningstid for specifikt kortformatvideo.
Den afvejning, vi stadig arbejder med
Ikke alle beslutninger her er afgjort. GPU vs. CPU kodning er den, vi genbesøger mest: GPU throughput er attraktivt, efterhånden som volumen vokser, men quality-per-bitrate konsistens foretrækker stadig CPU kodning til brand-kritisk output. Lige nu håndteres den opdeling manuelt per jobtype; at gøre det til en automatisk, kvalitetsbevidst routingbeslutning er den næste del af denne pipeline, vi er ved at bygge ud.
Hvorfor dette er vigtigt
Sammensat udløser én upload en pipeline, der omrammer den til vertikale, kvadratiske og landskabsversioner, brander den, brænder undertekster ind, trimmer til det stærkeste klip, mixer og normaliserer lyd og komprimerer den til hurtig levering — uden at en redaktør åbner en tidslinje. Yderligere skalering betyder blot at køre flere FFmpeg workers parallelt, da hvert job er uafhængigt og statsløst.
Reels-trenden ændrede ikke kun, hvordan indhold ser ud — den ændrede, hvor mange former et enkelt stykke indhold skal antage, på en tidslinje, som manuel redigering ikke kan matche. FFmpeg holder trit, fordi det behandler video som programmerbart og sammensætteligt snarere end som noget, der skal klikkes igennem manuelt. Det er den egentlige grund til, at denne pipeline skalerer: ikke at FFmpeg er abstrakt kraftfuld, men at hver beslutning i den — crop vs. blur-fallback, stream-copy vs. re-encode, GPU vs. CPU — træffes bevidst, per tilfælde, i stedet for som standard.
Hvis du bygger en pipeline som denne og ønsker et andet sæt øjne på arkitekturen, kontakt os.
