FFmpeg, WebRTC (WHIP) ultra düşük gecikmeli yayın desteğini birleştirdi

• FFmpeg'e WHIP (WebRTC-HTTP Ingestion Protocol) muxer resmen eklendi ve 1 saniyenin altında ultra düşük gecikmeli yayın doğrudan desteklenmeye başlandı
• Bu commit ile WHIP muxer'ın adlandırması ve yapısı yeniden düzenlendi, SSL/DTLS/RTC hata mesajları ve loglar iyileştirildi
• DTLS eğrileri/profilleri, RTP payload, ICE STUN vb. temel protokol parametreleri Chrome tanımlarına uyacak şekilde güncellendi ve magic number değerleri makrolara ve fonksiyonlara ayrıştırıldı
• DTLS handshake ve ICE işleme tek bir fonksiyonda birleştirilip optimize edilerek performans ve kararlılık önemli ölçüde artırıldı
• Ses ve video transcoding ile ilgili hatalar (h264_mp4toannexb, OPUS timestamp, marker ayarları vb.) giderildi ve standart WebRTC ortamlarıyla uyumluluk artırıldı
• OpenSSL bağımlılığı netleştirildi; WHIP artık yalnızca DTLS desteği etkin olduğunda derleniyor
• Yalnızca FFmpeg ile WebRTC tabanlı yayın ve gerçek zamanlı akış ortamı kurmak kolaylaşıyor; böylece mevcut RTMP gibi legacy protokollere kıyasla ultra düşük gecikme avantajından yararlanılabiliyor

---

avformat/whip: FFmpeg WHIP muxer desteği eklendi

Başlıca değişikliklerin özeti

• WHIP Version 3 tabanlı muxer resmen kullanıma alındı, iç isimlendirme ve yapı düzenlendi
• SSL, DTLS ve RTC için log bağlamı ve hata mesajları daha da net hale getirildi
• Hardcoded magic number değerleri makrolara ve ayrı fonksiyonlara çıkarılarak bakım kolaylığı artırıldı
• DTLS eğri listesi, SRTP profil adları gibi alanlar FFmpeg ve OpenSSL standartlarına uyacak şekilde düzeltildi
• ICE STUN magic number, RTP payload type değerleri Chrome tarayıcı standardıyla uyumlu olacak şekilde güncellendi
• Ses kare boyutu, H.264 MP4→AnnexB dönüşümü, OPUS timestamp gibi medya işleme sorunları çözüldü
• DTLS handshake ve ICE işleme mantığı tek bir fonksiyonda birleştirildi, böylece yönetimi kolaylaştı
• OpenSSL tabanlı DTLS desteği koşulları netleştirilerek build hataları ve uyumluluk iyileştirildi
• SRTP, BIO callback, CA anahtarı/sertifika başlatma gibi TLS/DTLS iç yapıları birleştirildi
• whip.c dosyasının eklenmesi dahil toplam 13 dosyada değişiklik yapıldı ve yeni dosyalar eklendi

Arka plan ve anlamı

• WHIP, WebRTC tabanlı akış gönderimi için HTTP tabanlı standart bir protokoldür ve ultra düşük gecikmeli canlı yayın için kritik öneme sahiptir
• Bugüne kadar FFmpeg'de WebRTC kodlama ve gönderimi için ayrı araçlar veya karmaşık aracılık yapıları gerekiyordu; bu birleşmeyle birlikte tek bir FFmpeg komutuyla WHIP yayını mümkün hale geliyor
• Gerçek zamanlı yayın, canlı ticaret, görüntülü toplantı gibi pek çok alanda güncel WebRTC ekosistemiyle doğrudan entegrasyon sağlayan teknik bir dönüm noktası niteliğinde

[GN⁺]

Hacker News görüşleri

• WebRTC yayıncılığı konusunda inanılmaz heyecanlıyım; bunun nedenlerini Broadcast Box README ve OBS PR bağlantısında derledim. Artık GStreamer, OBS ve FFmpeg’in hepsi WHIP destekliyor; böylece tüm platformlara uygulanabilecek genel amaçlı bir video yayın protokolüne ulaşılmış oldu. Yıllardır açık kaynak + WebRTC yayıncılığı üzerinde çalışmış biri olarak bunun büyük bir dönüm noktası olduğunu düşünüyorum.
  • Eskiden uzaktaki dosbox oyunlarını telefondan VNC ile oynuyordum; şimdi ise kendi input handler web uygulamamı yapıp bu teknoloji + OBS kombinasyonuyla sonsuz zaman harcayacağım yeni bir uğraşa başlama isteği duyuyorum.
  • Mobil yayın birimlerinde birden fazla 5G modemi bağlayıp multipath/failover-bonding özelliği (örneğin SRT’yi değiştirerek H.265’i birden çok bağlantı üzerinden göndermek gibi) ekleme planı olup olmadığı soruluyor.
  • Popüler yayın yazılımları, mobil, web, gömülü sistemler gibi farklı platformlarda doğrudan kullanım deneyimi yaşadıktan sonra broadcast-box ve buna yapılan geliştirme katkıları karşısında hayranlık duyduğunu söylüyor.
  • Kendi webrtc kütüphanesinin çeşitli projelerde faydalı şekilde kullanıldığını ve geniş bir teknoloji yelpazesinde etkili olduğunu görmekten memnuniyet duyduğunu ifade ediyor.
• WebRTC-HTTP Ingestion Protocol (WHIP) uygulamasını duyuruyor — burada doğrudan SCTP’nin kendisi ele alınmıyor; bunun yerine WebRTC kullanan peer’lerle HTTP üzerinden ağ geçidi görevi gören bir WHIP var. WHIP IETF belgesine (bağlantı) bakılabilir. Bir gün SCTP yerine QUIC ya da WebTransport tabanlı bir p2p protokolüne geçilmesini umduğunu söylüyor. Media-over-Quic(MoQ) ile ilgilendiğini, ancak tarayıcı desteğinin ve gelişiminin yıllardır yavaşladığını paylaşıyor. İlgili bağlantılar: quic.video ve MoQ IETF introduction
  • SCTP kısmını tam olarak nasıl kullanmak ya da görünür kılmak istediğini soran bir yorum var; WHIP IETF taslağında bununla ilgili bir ifade ya da öneri olmadığı için konu belirsiz görünüyor. Çoğu "WHIP Provider" DataChannel destekliyor, ancak bu standartlaştırılmış değil.
• FFmpeg ile web sitesinin doğrudan bağlanıp anında ses/video akışı almasının mümkün olup olmadığı soruluyor; daha fazla ayrıntı Phoronix sayfasında (bağlantı) bulunabilir.
  • FFmpeg kütüphanelerini, özellikle de libavformat’ı kullanan programların WebRTC akışlarını doğrudan alıp kullanabileceğine dair özet bir açıklama yapılıyor.
• Bu değişiklikle birlikte kendi kendine barındırılan akışlar / streaming CDN kurmanın çok daha kolaylaşacağı umuluyor; ffmpeg’in bağımsızlığı ve tak-çalıştır niteliği vurgulanıyor.
  • Simulcast ile birleşince maliyetlerin ve giriş engellerinin çarpıcı biçimde düşeceği öngörülüyor; broadcast-box’ın oluşturulma sebeplerinden birinin de self-hosting + WebRTC için giriş engelini azaltmak olduğu belirtiliyor.
  • LLM kullanımı sayesinde ffmpeg ile ilgili her türlü video işinde one-liner komutlar bile üretilebildiği, yapay zeka kullanım deneyiminin çok etkileyici olduğu söyleniyor.
  • ffmpeg’in ne kadar çok yönlü olduğunu gösteren xkcd 2347 karikatürü her zaman akla geliyor.
• Anubis grafiğini ffmpeg ve gnu gibi yerlerde beklenmedik şekilde görmüş olmanın ilginç bir deneyim olduğu söyleniyor.
• WHIP özelliğinin eklenmesiyle sistemde ffmpeg bulundurmanın daha riskli hâle gelip gelmeyeceğine dair endişe dile getiriliyor; WebRTC güvenlik açıklarının pratikte pek çok ihlalin nedeni olduğu hissedildiği ve geçmişte tarayıcı kurulunca her zaman devre dışı bırakıldığı anlatılıyor.
  • Hangi güvenlik açıklarının kastedildiği soruluyor; bu uygulamanın çok küçük olduğu ve kullanıcılara en iyi sonucu sunduğuna dair güçlü bir güven dile getiriliyor.
  • İstenmiyorsa --without-whip gibi bir seçenekle derlemeden tamamen çıkarılmasının mümkün olup olmadığı soruluyor; bunun ideal olacağı görüşü paylaşılıyor.
  • ffmpeg’in geçmişte çok sayıda güvenlik sorunu yaşadığı için kullanıcı girdisi işlerken her zaman izole ortam kullanmanın en iyisi olduğu belirtiliyor. Örneğin yalnızca ffmpeg ve bağımlılıklarını içeren bir Docker imajını her iş için yeniden başlatmak, ya da thumbnail veya belge işleme gerekiyorsa ClamAV, OpenOffice, ImageMagick gibi araçlar eklemek öneriliyor. Ayrıca kullanıcı üretimli dosyaları işleyen sunucuların mümkün olduğunca ayrı bir VLAN’da, ya da AWS kullanılıyorsa yalnızca güvenlik grubu içinde çalıştırılması tavsiye ediliyor. Bunun belirli projelere yönelik bir eleştiri olmadığı, ikili dosya formatlarının doğası gereği zorlu olduğu ve proaktif güvenlik önlemlerinin önemli olduğu vurgulanıyor. 4chan örneğine de bakılabilir. ffmpeg güvenlik sayfası burada.
• ffmpeg’in güvenlik denetimi çalışmalarının nasıl olduğu soruluyor; resmî siteden bunun biraz olay sonrası tepki veren bir yaklaşım gibi göründüğü hissi paylaşılıyor.
• Artık ffmpeg ile Jitsi sesli/görüntülü konferansının ses akışının kaydedilip kaydedilemeyeceği soruluyor.
• FFmpeg kaynak derlemesinde whip desteğini başarıyla etkinleştiren olup olmadığı soruluyor; doğru ./configure seçeneklerini bulmanın zor olduğundan yakınılıyor.
  • Gerekli seçeneklerin --enable-muxer=whip ve --enable-openssl olduğu belirtiliyor.
• Bunun Jellyfin’e ne zaman geleceğini sabırsızlıkla beklediğini söyleyenler var.
  • Buna karşılık bunun Jellyfin’e işlevsel olarak ne sağlayacağını soran bir yorum da var.