FFmpeg, çok iş parçacıklı transcoding pipeline'ını kullanıma sundu

 (ffmpeg.org)
2 puan yazan GN⁺ 2023-11-07 | 1 yorum | WhatsApp'ta paylaş
  • FFmpeg CLI için çok iş parçacıklı transcoding desteğinin, yaklaşık 2 yıllık çalışma ve 700'den fazla hazırlık commit'inin ardından ilk "tam çalışır" haliyle yayımlandığı açıklandı
  • Değişiklik kapsamı büyük olduğundan bazı işlevlerin bozulmuş olma ihtimali sürüyor; bu yüzden gerçek birleştirme öncesinde test ve inceleme temel gündem maddeleri olmaya devam ediyor
  • -fix_sub_duration_heartbeat, decoder ile encoder ve muxer arasındaki senkronizasyon varsayımı nedeniyle asenkron çalışmada belirsiz davranışı önlemekte zorlanıyor
  • İş parçacığı ek yükü genel olarak düşük olsa da, paket başına iş miktarının çok az olduğu görevlerde performans kazanımından çok maliyet daha görünür olabilir
  • Darboğaz tek bir bileşende toplanmıyorsa ve her bileşen zaten kendi içinde çok iş parçacıklı yapıda doygun değilse, çok çekirdekli ortamlarda CPU kullanım oranı ve gerçek işlem süresi önemli ölçüde iyileşebilir

FFmpeg CLI çok iş parçacıklılığı yamasının özeti

  • Yaklaşık 2 yıllık çalışma ve 700'den fazla hazırlık commit'inin ardından, çok iş parçacıklı FFmpeg CLI'nin ilk “fully functional” sürümü bir yama seti olarak yayımlandı
  • Değişikliklerin kapsamı büyük olduğu için henüz fark edilmemiş bozulmalar olabilir; bu nedenle gerçek kullanım senaryolarına dayalı test ve inceleme gerekiyor
  • Genel durumda iş parçacığı ek yükü düşük olsa da, paket başına iş miktarının çok az olduğu iş yüklerinde bu ek yük anlamlı hale gelebilir
  • Transcoding tek bir bileşen tarafından domine edilmiyorsa ve bileşenlerin her biri zaten kendi çok iş parçacıklılığıyla doygun hale gelmemişse, çok çekirdekli sistemlerde CPU kullanımı ve çalışma süresi iyileşebilir

Çalışma kısıtları ve bilinen sorunlar

  • -fix_sub_duration_heartbeat seçeneği mevcut yapıda birbirinden ayrık bileşenler arasında senkronizasyon varsayıyor
    • Hedef akış, encoder ve muxer'dan decoder'a uzanan senkronizasyon
    • Her bileşen asenkron çalıştığında davranış temelden belirsiz hale geliyor
    • Şu anda da davranış öngörülmesi zor olsa da, aynı seçenekle çalıştırıldığında çalıştırmalar arası sonuçlar deterministik
    • 16/24 yamasında bu seçenek devre dışı bırakılıyor ve daha iyi bir çözüm gerekiyor

24 parçalık yama setinin yapısı

  • Yama seti toplam 24 parçadan oluşuyor
    • 01-09/24 hazırlık düzeltmeleri; geri kalan seriden önce gönderilebilir
    • 10-17/24, encoding ve filtering işlemlerini iş parçacıklarına taşıyor ve gerekli hazırlık değişikliklerini yapıyor
      • Bu aşamadaki threading, ana iş parçacığının diğer iş parçacıklarının tamamlanmasını beklediği “sahte” threading olduğundan gerçek paralel yürütme sağlamıyor
      • Geçici ek yük büyük olabilir veya bazı köşe durumları bozulabilir; bu nedenle tüm set hazır olduktan sonra gönderilmesi daha uygun
    • 18/24, en büyük tekil yama olarak transcode scheduler ekliyor, ancak bu aşamada henüz gerçekten çalışmıyor
    • 19-24/24, tek tek bileşenleri scheduler kullanım modeline dönüştürüyor
      • İnceleme kolaylığı için ayrılmış olsalar da nihai gönderimde birleştirilmeleri gerekiyor
  • İlgili materyaller son VDD sunum videosunda ve ffmpeg_threading branch'inde görülebilir

İlgili okumalar

1 yorum

 
GN⁺ 2023-11-07
Hacker News yorumları

  • 4 çekirdekli bir ARM sunucuda yaklaşık 2 kat hızlanmış ve paralelleştirme ek yükü pek görünmüyor
    ffmpeg_threading/ffmpeg 7,771 saniye, mevcut ffmpeg ise 13,841 saniyeydi; CPU kullanımı sırasıyla %218 ve %114'tü

    • Burada kod çözme tarafında donanım hızlandırma kullanılmamış, video çıktısı da kaldırılmış
      NVIDIA kartta hem video kod çözme hem de kodlama için donanım hızlandırma kullanılırsa ne olacağını merak ediyorum: ffmpeg -hwaccel cuda -i $inputFile -codec:a copy -codec:v hevc_nvenc $output
    • Hangi kısmın çok iş parçacıklı hale getirildiğini merak ediyorum. Video sıkıştırma zaten çok iş parçacıklı; video sıkıştırmayı açma tarafını pek bilmiyorum
      Diğer işlemlerin performans maliyeti açısından nispeten küçük olacağını düşündüğüm için, iyileştirme sevindirici olsa da gerçek etkisinin epey sınırlı olmasını bekliyorum

  • Tweet yerine https://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/3165... bağlantısını vermek daha iyi olurdu
    Tweetin özü de zaten bu bağlantı

    • Artık buna sadece post diyebiliriz. 280 karakter sınırı da artık yok; uzun yazılar yalnızca varsayılan olarak katlanmış duruyor

  • Bunu anlamak için VideoLAN Dev Days 2023'te Anton'un yaptığı sunumu izlemek iyi olur: https://www.youtube.com/watch?v=Z4DS3jiZhfo&t=1221

    • Sunum iyiydi; “Future directions” bölümünde bahsedilen dynamic pipelines ve “scripting (Lua?)” ile neyin amaçlandığını merak ediyorum
      Özellik animasyonlarını daha güçlü şekilde ele alan bir yön hayal ettiriyor
    • Videonun 33. dakikası civarında slaytta görünen Extras ile ilgili sorunları gerçekten çok yaşadım
    • Sunumu mutlaka izlemek istiyorum ama ses kalitesi o kadar kötü ki odaklanmak zor. Günümüzde hâlâ nasıl bu kadar fena batırılabildiğini bilmiyorum
    • Anlaşılması zor olan kısmın ne olduğunu bilmiyorum. Video transkoding alanında çok iş parçacıklı ifadesi farklı bir anlamda mı kullanılıyor?

  • Tweet http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/31655... adresine gidiyor, oradan da koda https://git.khirnov.net/libav.git/log/?h=ffmpeg_threading referans veriliyor

    • Tweet, yama setinin resmi kaynağı olan posta listesine bağlıyor. Devamını okumak için “Next in Thread” seçilebilir

  • Bunun otomatik uygulanıp uygulanmadığını, yoksa komut satırı parametrelerini karmaşık biçimde birleştirmek gerekip gerekmediğini merak ediyorum

  • ffmpeg kullanan bir video düzenleme yazılımı var mı merak ediyorum
    Bir ara SVG ile şekiller çizip ffmpeg kullanmayı ya da üstüne bir UI eklemeyi veya yalnızca metin ekleyen bir şey yapmayı düşünmüştüm ama başlamadım
    Avidemux biraz o havada; ffmpeg'in içi de oldukça ham olduğundan GUI'den erişilecek şekilde kullanılmıyor, bu yüzden üzerine kurulu bir editör hantal, garip ve bakımı zor olur gibi
    Komut açıklayıcısı ya da pipeline görüntüleyicisiyle önizleme üreten modüler bir editör gibi bir şey mümkün olabilir
    ffmpeg güçlü ama yalnızca komut satırından kullanılması bazı kullanıcıların önünü kesiyor. Geçmişte rastgele sayıda klip alıp xstack filtresiyle mozaik oluşturan bir Python betiği yazmıştım; kolay değildi

  • Plex için yaptığım küçük transkoding işlerinin hızlanması iyi olurdu
    Ekran kartım donanımsal transkoding desteklemediği için umutluyum

  • Transkoding hızını artırmanın yollarını arıyordum; biri GPU hızlandırma, diğeri iş parçacığı sayısını artırmaktı
    Ancak en uygun iş parçacığı sayısını bulmak zor

    • En iyi değeri bulmak için hiperparametre optimizasyonu kullanılamaz mı? Sherpa veya Scikit-optimize gibi araçlarla iş parçacığı sayısı, girdi türü, CPU türü gibi arama uzayları taranabilir
    • Çoğu işte iş parçacığı sayısını vCPU sayısına eşitlemek yeterli olur. Yani hyper-threading'li çekirdekleri 2 olarak saymak gerekir
      Yine de mümkünse GPU hızlandırma çok daha iyi

  • Büyük ölçekli ffmpeg dağıtımında lisans gereksinimlerinin nasıl olduğunu merak ediyorum. Hangi durumlarda ücret gerekir?

    • “FFmpeg is licensed under the GNU Lesser General Public License (LGPL) version 2.1 or later. However, FFmpeg incorporates several optional parts and optimizations that are covered by the GNU General Public License (GPL) version 2 or later. If those parts get used the GPL applies to all of FFmpeg.”
      http://ffmpeg.org/legal.html
      Yani ücretsiz, ancak bazı modüller kullanılırsa kapalı kaynak kodla karıştırırken sorun çıkabilir
    • Kapalı kaynak yazılım içinde ffmpeg kullanmanın yaygın yolu, kullanılan ffmpeg sürümünü statik olarak derleyip yürütülebilir dosyaya linklemek ya da kapalı kaynak yazılımın onu ayrı bir yürütülebilir dosya olarak çağırmasını sağlamaktır

  • FFmpeg'in geliştiğini görmek güzel. Umarım yakında Dolby AC4 desteğini de görürüz