Meta'nın FFmpeg Kullanımı: Büyük Ölçekli Medya İşlemenin Sırrı

• Meta, günde on milyarlarca kez FFmpeg çalıştırıyor ve dahili fork sürümü yerine tamamen upstream FFmpeg'e geçmeyi başardı
• Dahili fork ile açık kaynak sürüm arasındaki özellik farkını kapatmak için FFlabs ve VideoLAN ile iş birliği yaparak çoklu hat paralel kodlama ve gerçek zamanlı kalite metrikleri özelliklerini upstream'e kazandırdı
• Günde 1 milyardan fazla video yüklemesini işlerken, DASH oynatımı için çoklu çözünürlük ve codec kodlamasını tek bir FFmpeg komut satırıyla gerçekleştiriyor
• FFmpeg 6.0~8.0 sürümlerinde hayata geçirilen verimli iş parçacığı yapısı, Meta'nın tasarımını temel alıyor ve tüm kullanıcılara daha yüksek kodlama verimliliği sağlıyor
• Kendi tasarımı olan ASIC MSVP (Meta Scalable Video Processor), FFmpeg'in standart donanım API'si üzerinden entegre edilerek yazılım ve donanım pipeline'ları arasında tutarlılık sağlanıyor
• 25 yılı aşkın süredir geliştirilen FFmpeg'e yapılan sürekli yatırım, Meta platformundaki yeni video deneyimlerini ve kararlılığı aynı anda güçlendiriyor

---

FFmpeg'in rolü ve Meta'nın karşılaştığı zorluklar

• FFmpeg, çeşitli ses ve video codec'leri ile container formatlarını destekleyen sektör standardı bir medya işleme aracı olup, karmaşık filtre zincirleri üzerinden medya düzenleme ve dönüştürme yapılmasına olanak tanır
• Meta, ffmpeg (ana CLI) ve ffprobe (medya dosyası özelliklerini sorgulayan yardımcı araç) ikililerini günde on milyarlarca kez çalıştırıyor ve bunun ötesinde, tekil dosya işlemenin dışına çıkan ek gereksinimlere sahip
• Uzun süre dahili bir fork'a dayanarak, o dönemde upstream'de bulunmayan thread tabanlı çoklu hat kodlama ve gerçek zamanlı kalite metriği hesaplama gibi özellikleri kendisi geliştirdi

Dahili fork'un ayrışması ve upstream'e geri dönme ihtiyacı

• Dahili fork, upstream FFmpeg'ten önemli ölçüde ayrıştıkça özellik seti farkı giderek büyüdü
• Aynı zamanda FFmpeg'in yeni sürümleri yeni codec ve dosya formatı desteği ile kararlılık iyileştirmeleri sunduğundan, kullanıcıların yüklediği çeşitli video içeriklerini kesintisiz kabul edebilmek için açık kaynak sürümün en güncel hâlini de desteklemek gerekti
• Dahili değişiklikleri rebase ederken regression önleme giderek zorlaştı; bunun üzerine FFmpeg geliştiricileri, FFlabs ve VideoLAN ile birlikte çalışarak dahili fork'u tamamen bırakıp yalnızca upstream sürümü kullanma yönünde geçiş yapıldı

Verimli çoklu hat transcoding altyapısı kurma (VOD ve canlı yayın)

• Kullanıcı video yüklediğinde, DASH (Dynamic Adaptive Streaming over HTTP) oynatımı için çoklu kodlama setleri üretilir; bunlar çözünürlük, codec, kare hızı ve kalite düzeyi bakımından birbirinden farklıdır
  • Uygulamadaki video oynatıcı, ağ durumu gibi sinyallere göre bu kodlamalar arasında gerçek zamanlı geçiş yapabilir
• En basit yöntem, her hattı ayrı bir FFmpeg komut satırıyla sırayla işlemektir; ancak paralel çalıştırılsa bile her süreç tekrarlı iş yapar (decode işleminin yinelenmesi, süreç başlatma ek yükü) ve bu verimsizdir
• Tek bir FFmpeg komut satırında kareler yalnızca bir kez decode edilip ardından her çıkış kodlayıcısına gönderilirse, tekrarlı decode ortadan kalkar ve süreç başlatma ek yükü azalır
  • Günde 1 milyardan fazla video yüklemesi işlendiği için, süreç başına tasarruf edilen hesaplama genel ölçekte büyük bir verimlilik artışı yaratır
• Meta'nın dahili fork'u ayrıca paralel video kodlama optimizasyonları sunuyordu: mevcut FFmpeg, birden fazla kodlayıcı kullanıldığında bunları kare bazında seri çalıştırırken, tüm kodlayıcı örneklerini paralel çalıştırarak daha yüksek paralellik sağlandı
• FFmpeg geliştiricilerinin (FFlabs ve VideoLAN dahil) katkılarıyla FFmpeg 6.0'dan itibaren daha verimli thread yapısı uygulanmaya başladı ve 8.0 sürümünde tamamlandı
  • Bu yapı doğrudan Meta'nın dahili fork tasarımından etkilendi ve on yıllardır yapılan en karmaşık FFmpeg refactoring'lerinden biri olarak kayda geçti
  • Sonuç olarak tüm FFmpeg kullanıcıları daha verimli kodlamadan yararlanabiliyor

Gerçek zamanlı kalite metrikleri (canlı yayın)

• Görsel kalite metrikleri, medyanın algısal görüntü kalitesini sayısal olarak ifade eder ve sıkıştırma kaynaklı kalite kaybını nicel olarak ölçmek için kullanılır
  • Referans (reference) metrikleri: özgün kodlama ile bozulmuş kodlamayı karşılaştırır
  • Referanssız (no-reference) metrikler: özgün içerik olmadan kalite değerlendirmesi yapar
• FFmpeg, PSNR, SSIM, VMAF gibi kalite metriklerini iki mevcut kodlamayı kullanarak, kodlama tamamlandıktan sonra ayrı bir komut satırında hesaplayabilir; ancak canlı yayında bu hesaplamanın gerçek zamanlı yapılması gerekir
• Her çıkış hattındaki video kodlayıcının arkasına video decoder eklenerek, sıkıştırma sonrası kare bitmap'i elde edilir ve bu, sıkıştırma öncesi kareyle karşılaştırılır; böylece tek bir FFmpeg komut satırında her kodlama hattı için kalite metrikleri gerçek zamanlı üretilir
• FFmpeg 7.0'dan itibaren FFlabs ve VideoLAN geliştiricilerinin katkılarıyla "in-loop" decoding etkinleştirildi ve bu özellik için dahili fork'a olan bağımlılık tamamen kaldırıldı

Upstream katkı kriterleri ve yalnızca dahilde kalan yamalar

• Gerçek zamanlı kalite metrikleri ve verimli thread yapısı gibi özellikler, Meta içindeki ve dışındaki çeşitli FFmpeg tabanlı pipeline'larda verimlilik sağladığı için upstream'e katkı olarak sunuldu
• Buna karşılık, Meta altyapısına son derece özel ve genellenmesi zor yamalar yalnızca dahilde tutuldu
• FFmpeg, NVIDIA NVDEC/NVENC, AMD UVD, Intel QSV gibi donanım hızlandırmalı decode, encode ve filtering işlemlerini standart API ile destekler
• Meta'nın kendi video transcoding ASIC'i olan MSVP (Meta Scalable Video Processor) için de aynı standart API üzerinden destek eklendi ve böylece farklı donanım platformlarında ortak araçlar kullanılabildi
  • MSVP yalnızca Meta'nın dahili altyapısında kullanıldığından, dış FFmpeg geliştiricileri bu donanıma erişip test ve doğrulama yapamaz; bu nedenle ilgili yamalar dahilde tutulur
  • En güncel FFmpeg sürümüne rebase edilirken kapsamlı doğrulama ile sağlamlık ve doğruluk güvence altına alınır

FFmpeg'e sürekli yatırım

• Çoklu hat kodlama ve gerçek zamanlı kalite metrikleri sayesinde tüm VOD ve canlı yayın pipeline'larında dahili fork tamamen terk edildi
• FFmpeg'in standart donanım API'si sayesinde MSVP ASIC ile yazılım tabanlı pipeline'lar asgari sürtünmeyle birlikte desteklenebiliyor
• 25 yılı aşkın süredir aktif biçimde geliştirilen FFmpeg için açık kaynak geliştiricileriyle ortaklık içinde sürekli yatırım planlanıyor; bu da Meta'ya, sektöre ve kullanıcılara fayda sağlıyor

[GN⁺]

Hacker News görüşleri

• Dahili fork giderek eskidikçe, gerekli özellikleri resmi FFmpeg'e entegre etmek için FFmpeg geliştiricileriyle birlikte çalıştık
  Bunun sayesinde dahili sürümü tamamen bırakıp yalnızca upstream sürümle çalışabilir hale geldik
  Bazıları “daha fazla katkı yapamaz mıydınız?” diyor ama açık kaynağın özü, herkesin faydayı paylaşmasıdır

  • Meta'nın topluluğa katkıda bulunduğu inkâr edilemez diye düşünüyorum
    React, React Native ve daha birçok proje sayesinde zaten fayda görüyoruz
  • Ama bu özellikler aşırı büyük şirketlerin ihtiyaçlarından doğduysa, çoğu kullanıcı bunun faydasını hissedemez
    Sonuçta böyle bir yapı yalnızca gücü elinde tutanların lehine gibi geliyor
  • Bunun olumlu bir değişim olduğu açık, ama arka planda bir dönem iç çıkarların öncelediği de vardı
    Yine de Meta'nın açık kaynak ekosistemine çok şey açmış olması sektörde ayırt edici bir unsur olarak işliyor
  • Tüm büyük teknoloji şirketlerinin açık kaynak temeli olmadan var olamayacağını unutmamak gerek
  • Açık kaynak katkısı başlı başına iyi ama blog yazısının tonu hoşuma gitmedi
    “Ancak şimdi upstream'e entegre ettik” tarzı ifade, sanki geçmişteki yetersizliği paketlemeye çalışıyormuş gibi hissettirdi
    Teknik bloga pazarlama dili karıştırmak okur açısından rahatsız edici

• Fabrice Bellard emekli olduğunda yeterince karşılık görmesini umuyorum
  Onun yazılımları sayesinde sayısız şirket para kazandı

• FFmpeg'in yeni sürümünün çeşitli codec ve formatları desteklemesi güzel ama,
  Meta bunu her gün milyarlarca kez çalıştıran bir ölçekteyse, bu iyileştirmelere sürekli katkı verip vermediğini merak ediyorum

  • [silinmiş yorum]

• Günde onlarca milyar kez çalıştırılması gerçekten inanılmaz bir ölçek
  Ben otomatik video birleştirme işlerinde günde yalnızca birkaç bin kez çalıştırdığımda bile overhead hissediyorum
  single-decode multi-output özelliği sayesinde işlem süresi %40 azaldı

  • Bu ölçekte RAM kullanımı da herhalde akıl almaz boyuttadır
    Neyse ki son dönemde bellek fiyatlarının düşmesi sayesinde açık kaynak iyileştirmelerinin maliyet/fayda etkisi daha da arttı

• Encoder instance'larını paralel çalıştırarak paralelliği artırma yaklaşımı mantıklı
  Ama ben zaman ekseni paralelleştirmesi (time-axis parallelization) özelliğini görmek isterim
  Girdi videosunu keyframe'lere göre bölüp paralel encode etmek, kalite kaybı olmadan hızı artırabilir

  • Peki keyframe konumlarını önceden tahmin etmek mümkün mü?
    Genelde encoder bunları verimlilik için dinamik yerleştirdiğinden, önceden bölmek zor olabilir
  • Encoder'ın P/B frame analizi sırasında yaptığı hareket analizini bir kez hesaplayıp birden çok encoding'de yeniden kullanmak mümkün olabilir mi diye merak ediyorum

• Meta ekibinin ffmpeg ve ffprobe'a katkıda bulunmasına teşekkürler
  İleride kod kalitesi, dokümantasyon, topluluk etkinlikleri gibi alanlara mali destek de düşünmelerini isterim

• “Dahili fork giderek eskidi” ifadesiyle çok empati kurdum
  Bu arada FFmpeg 8'de HDR ve SDR renk eşleme kusursuz şekilde işleniyor

  • Eskiden metadata'nın otomatik kopyalanması sorunuyla uğraşıyordum, şimdi çözülmüş olması gerçekten sevindirici
  • Uzun zaman sonra haber almak güzel, gelişim etkileyici

• Almanya'nın Sovereign Tech Fund'unun FFmpeg'e bağış yaptığı haberi ilginç

  • Alman STF yaklaşık 150 bin dolar bağışladı ama Meta'da bir mühendisin 1 yıllık maliyeti bile bunun iki katından fazladır
    Muhtemelen Meta'nın medya encoding'e adanmış bir ekibi vardır ve yıllık 1 milyon doların üzerinde değer üreten katkı yapıyordur
  • Ama FFmpeg'in resmi hesabı, “Meta'nın desteği için minnettarız ama bu sürdürülebilir bir seviye değil” demişti
    ilgili tweet'e bakın
  • Meta'nın gerçekte ne kadar bağış yaptığını merak ediyorum
    Alman STF'nin 2024/2025'te €157,580 destek verdiği söyleniyor
  • Meta milyarlarca dolar kazanırken bir devlet fonundan daha az bağış yapması biraz ironik
  • [silinmiş yorum]

• Neyse ki FFmpeg sunucuları yalnızca hafif içerikleri işlediği için ayakta kalıyor
  Ağır videolar olsaydı aşırı yük altında kalırlardı

• Aynı HN gönderisi 6 gün önce de paylaşılmıştı
  Bu bağlantıyı ekledim diye neden downvote edildiğimi anlamıyorum

  • Benim anladığım kadarıyla, aynı kullanıcı tekrar tekrar göndermediği sürece yeniden paylaşım sorun değil
  • [silinmiş yorum]