FFmpeg’e WebRTC (WHIP) ultra düşük gecikmeli yayın desteği eklendi
(git.ffmpeg.org)- FFmpeg
avformat/whipiçine WHIP muxer eklendi; böylece WebRTC tabanlı 1 saniyenin altında gecikmeli yayın FFmpeg içinde ele alınabilir hale geldi - Değişiklikler WHIP Version 3 temel alınarak yapıldı; yalnızca muxer adı ve uygulaması değil, SSL·DTLS·RTC günlük bağlamı ve hata mesajları da birlikte düzenlendi
- Uygulama içindeki magic number’lar makrolar ve fonksiyonlarla değiştirildi; DTLS curve list, SRTP profile, ICE STUN magic number ve RTP payload type işleme tarafı da iyileştirildi
- Medya yolunda sabit frame boyutu yerine
rtc->audio_par->frame_sizekullanılıyor ve MP4/ISOM girdisinin Annex B’ye dönüşümünde h264_mp4toannexb kullanılıyor - Derleme ayarı,
whipyalnızca DTLS etkin olduğunda açılacak şekilde değiştirildi; şu an destek yalnızca OpenSSL ile sınırlı
WHIP muxer eklenmesi ve derleme bağlantısı
avformat/whipiçine WHIP muxer eklendi ve 1 saniyenin altında gecikmeli yayını destekliyor- Uygulama WHIP Version 3 temel alınarak geliştirildi
- Yeni uygulama dosyası olarak libavformat/whip.c eklendi
- Dokümantasyon ve derleme yapılandırması da birlikte değiştirildi
DTLS·ICE·RTP işleme düzenlemeleri
- WHIP muxer, ad değişikliğiyle birlikte elden geçirildi; SSL·DTLS·RTC hata mesajları ve günlük bağlamı iyileştirildi
- Magic number’lar makrolarla değiştirildi ve bazı mantık parçaları fonksiyonlara ayrıldı
- Günlük seviyeleri de daha net olacak şekilde ayarlandı
- DTLS tarafında uyumluluk ve performansla ilgili çeşitli değişiklikler yapıldı
- DTLS curve list güncellendi
- FFmpeg ve OpenSSL için SRTP profile adları düzenlendi
- DTLS handshake ve ICE işleme, performans iyileştirmesi için optimize edildi
- ARQ’yu önlemek için tek bir handshake timeout ve server role kullanıldı
- ICE işleme, request/response ile DTLS handshake’i tek bir fonksiyonda birleştirecek şekilde sadeleştirildi
- ICE STUN magic number tarafı iyileştirildi
- RTP payload type, Chrome tanımlarına göre güncellendi
Medya işleme ve OpenSSL kısıtı
- Ses tarafındaki sabit frame boyutu,
rtc->audio_par->frame_sizekullanımına geçirildi - MP4/ISOM girdisini Annex B’ye dönüştürmek için
h264_mp4toannexbkullanıldı - OPUS timestamp sorunu ve BSF kullanımından sonraki marker ayarı birlikte düzeltildi
- TLS ve DTLS uygulamaları ortak bir yapıda birleştirildi
- BIO callback, read, write,
print_ssl_error,openssl_init_ca_key_cert,init_bio_methodortak kullanılıyor - Aynı veri yapısı kullanılıyor
- BIO callback, read, write,
- OpenSSL derleme hatası düzeltilerek Pion ile çalışacak hale getirildi
configure,dtlsetkin olduğundawhipözelliğini açacak şekilde değiştirildi- Şu an desteklenen hedef yalnızca OpenSSL
1 yorum
Hacker News yorumları
WebRTC yayını beni gerçekten heyecanlandırıyor. Nedenlerini Broadcast Box README'sinde ve OBS PR'ında özetledim
Artık GStreamer, OBS ve FFmpeg'in hepsi WHIP desteklediğine göre; mobil, web, gömülü sistemler ve yayın yazılımları dahil tüm platformlarda kullanılabilecek evrensel bir video yayın protokolü ortaya çıkmış oldu
Açık kaynak ve WebRTC yayını tarafında yıllardır çalışıyorum; bunu büyük bir dönüm noktası olarak görüyorum
[0] https://github.com/Glimesh/broadcast-box?tab=readme-ov-file#...
[1] https://github.com/obsproject/obs-studio/pull/7926
SCTP kısmı değil. Aslında yaptığı şey, peer ile WebRTC'nin SCTP tabanlı protokolü üzerinden iletişim kuran bir gateway'e bağlanmak için kullanılan düşük gecikmeli HTTP protokolü olan WebRTC-HTTP Ingestion Protocol'ü, yani WHIP'i uygulamak
https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html
Bir gün SCTP yerine QUIC veya WebTransport tabanlı bir P2P protokolüne geçebilsek güzel olurdu. QUIC, mevcut UDP üzerinde SCTP'nin yaptığı işi iyi hallediyor ve karmaşıklığı ya da uygulama farklılıklarını ciddi biçimde artırmıyor
Adaylardan biri Media-over-QUIC (MoQ), ancak tarayıcılarda P2P QUIC yok ve o taraftaki ilerleme de birkaç yıldır durmuş durumda
https://quic.video/ https://datatracker.ietf.org/group/moq/about/
Çoğu WHIP sağlayıcısı DataChannel'ı da destekliyor, ancak bu henüz standartlaşmış değil
Bunun ne anlama geldiğini merak ediyorum. Bir web sitesinin doğrudan bir FFmpeg instance'ına bağlanıp ses veya video stream'i alabileceği anlamına mı geliyor?
Phoronix tarafındaki açıklama biraz daha ayrıntılı: https://www.phoronix.com/news/FFmpeg-Lands-WHIP-Muxer
Bu, self-hosted stream veya streaming CDN kurmayı çok daha kolay hale getirebilir gibi
FFmpeg, nasıl kullanılacağını bildiğinizde gerçekten şaşırtıcı derecede güçlü, bağımsız ve tak-çalıştır bir medya yazılımı
Self-hosting'i ve WebRTC'yi çok daha kolaylaştırmak istediğim için https://github.com/Glimesh/broadcast-box'ı yaptım
XMPP istemcisi Gajim bunu uzun süredir bekliyordu. Sesli/görüntülü arama özelliği fiilen terk edilmiş durumdaydı; FFmpeg sayesinde tekrar eklemenin kolaylaşmasını sabırla bekliyordu diyebiliriz
Artık hepsi kapalı bahçeler ya da uygulamaya özel servisler oldu
Anubis grafiğini beklenmedik bir yerde görmek güzel oluyor. Şimdiye kadar ffmpeg ve gnu gibi yerlerde gördüm
Umarım bu yüzden sistemde ffmpeg bulundurmak daha riskli hale gelmez. WebRTC güvenlik açıkları birçok ihlalin nedeni ve tarayıcı kurunca ilk kapattığım özelliklerden biri
Bu uygulama çok küçük ve kullanıcılara mümkün olan en iyi şeyi sunduğundan %100 eminim
--without-whipgibi bir argümanla derlemeden çıkarılıp çıkarılamayacağını merak ediyorum. İdeali bu olurduYalnızca ffmpeg ve bağımlılıklarını içeren bir Docker imajı hazırlayıp her dönüştürme işi için
docker runçalıştırmak iyi olur. Görsel veya belge küçük resimleri de üretmek gerekiyorsa ClamAV, OpenOffice ve ImageMagick de eklenebilirŞahsen, kullanıcı tarafından oluşturulan dosyaları sadece alıp sunmanın ötesinde işleyen sunucuların ayrı ve sıkı şekilde kilitlenmiş bir VLAN'da, AWS ise bir Security Group içinde tutulmasının daha iyi olduğunu düşünüyorum
Bu, adı geçen projelere yönelik bilgisizce bir saldırı değil. Güvenlik zordur; özellikle de uzun süre boyunca birikmiş ve bazen şüpheli yöntemlerle tersine mühendislik yapılmış ikili formatlarla uğraşırken daha da zordur. 4chan gibi başınıza gelmeden önce bunu kabul etmek akıllıca
[1] https://ffmpeg.org/security.html
Gerçekten harika. Web tabanlı bir uzaktan kontrol geliştiriyorum; bununla
ffmpeg gdigrab'ı bir WebRTC stream'ine dönüştürüp şu anda yaptığım ExpressJS workaround olmadan istemcinin doğrudan tüketebilmesini sağlayabilirsem çok memnun olurumiOS Safari'de bot tespitine sürekli takılmam ilginç. Hem şirket WiFi'ında hem de hücresel veride böyle
Anubis keşke beni içeri alsa
"access denied"sayfası mı çıkıyor, yoksa challenge sonsuz döngüye mi giriyor merak ediyorumAnubis geçmeme izin vermiyor ;(