FFmpeg menggabungkan dukungan streaming ultra-rendah latensi WebRTC (WHIP)

• FFmpeg kini secara resmi menambahkan muxer WHIP (WebRTC-HTTP Ingestion Protocol) dan langsung mendukung streaming ultra-rendah latensi di bawah 1 detik
• Dalam commit ini, penamaan dan struktur muxer WHIP dirombak, sementara pesan kesalahan dan log SSL/DTLS/RTC ditingkatkan
• Parameter protokol utama seperti kurva/profil DTLS, payload RTP, dan ICE STUN diperbarui agar sesuai dengan definisi Chrome, dan magic number diekstrak menjadi makro serta fungsi
• Handshake DTLS dan pemrosesan ICE diintegrasikan dan dioptimalkan ke dalam satu fungsi sehingga performa dan stabilitas meningkat signifikan
• Bug pada transcoding audio dan video (h264_mp4toannexb, timestamp OPUS, pengaturan marker, dll.) telah diperbaiki, sehingga kompatibilitas dengan lingkungan WebRTC standar meningkat
• Dependensi OpenSSL diperjelas, sehingga WHIP hanya dibangun saat dukungan DTLS tersedia
• Hanya dengan FFmpeg, kini lebih mudah membangun lingkungan siaran berbasis WebRTC dan stream real-time, serta memanfaatkan karakteristik ultra-rendah latensi dibanding protokol legacy seperti RTMP

---

avformat/whip: Menambahkan dukungan muxer WHIP FFmpeg

Ringkasan perubahan utama

• Pengenalan resmi muxer berbasis WHIP Version 3, beserta penataan nama internal dan strukturnya
• Konteks log dan pesan error untuk SSL, DTLS, dan RTC menjadi jauh lebih jelas
• Magic number yang di-hardcode diekstrak menjadi makro dan fungsi terpisah untuk meningkatkan kemudahan pemeliharaan
• Daftar kurva DTLS, nama profil SRTP, dan elemen lain disesuaikan dengan standar FFmpeg dan OpenSSL
• Magic number ICE STUN dan tipe payload RTP diperbarui agar sesuai dengan standar browser Chrome
• Berbagai isu pemrosesan media seperti ukuran frame audio, konversi H.264 MP4→AnnexB, dan timestamp OPUS telah diperbaiki
• Logika handshake DTLS dan pemrosesan ICE kini digabung ke satu fungsi sehingga lebih mudah dikelola
• Persyaratan dukungan DTLS berbasis OpenSSL diperjelas, sehingga error build dan kompatibilitas membaik
• Struktur internal TLS/DTLS seperti SRTP, callback BIO, serta inisialisasi kunci/sertifikat CA disatukan
• Total 13 file diubah dan ditambahkan, termasuk file baru whip.c

Latar belakang dan makna

• WHIP adalah protokol standar berbasis HTTP untuk pengiriman stream berbasis WebRTC, dan sangat penting untuk siaran langsung ultra-rendah latensi
• Selama ini, encoding dan pengiriman WebRTC di FFmpeg memerlukan alat terpisah atau relay yang rumit, tetapi dengan merge ini pengiriman WHIP dengan satu perintah FFmpeg kini menjadi mungkin
• Ini menjadi titik balik teknis yang memungkinkan integrasi langsung dengan ekosistem WebRTC modern di berbagai bidang seperti siaran real-time, live commerce, dan konferensi video

[GN⁺]

Komentar Hacker News

• Sangat antusias dengan siaran WebRTC; alasan yang saya rangkum dijelaskan di README Broadcast Box dan PR OBS ini. Sekarang GStreamer, OBS, dan FFmpeg semuanya mendukung WHIP, sehingga kita akhirnya mencapai protokol siaran video serbaguna yang bisa diterapkan di semua platform. Dari pengalaman bertahun-tahun mengerjakan siaran open source + WebRTC, saya merasa pencapaian ini adalah tonggak besar.
  • Dulu saya memainkan game dosbox jarak jauh dari ponsel lewat VNC, dan sekarang saya jadi ingin membuat sendiri webapp input handler lalu menggabungkan teknologi ini + OBS untuk tantangan baru yang bisa menghabiskan waktu tanpa batas.
  • Ada pertanyaan apakah unit streaming mobile akan menambahkan fitur multipath/failover-bonding dengan menghubungkan beberapa modem 5G sekaligus (misalnya memodifikasi SRT agar H.265 dapat dikirim lewat beberapa link).
  • Setelah punya pengalaman memakainya langsung di berbagai platform seperti software siaran populer, mobile, web, embedded, dan lainnya, saya terkesan dengan broadcast-box dan kontribusi pengembangannya.
  • Saya senang melihat library webrtc saya dipakai dengan berguna di berbagai proyek dan memberi pengaruh pada spektrum teknologi yang luas.
• Mengumumkan implementasi WebRTC-HTTP Ingestion Protocol (WHIP) — ini bukan menangani SCTP itu sendiri, melainkan dokumen IETF WHIP IDF yang berperan sebagai gateway melalui HTTP dengan peer yang menggunakan WebRTC (lihat tautan). Saya berharap suatu saat akan beralih ke protokol p2p berbasis QUIC atau WebTransport alih-alih SCTP. Saya tertarik pada Media-over-Quic (MoQ), tetapi membagikan bahwa dukungan browser maupun perkembangannya telah melambat selama beberapa tahun; tautan terkait adalah quic.video dan MoQ IETF introduction
  • Ada pertanyaan tentang bagaimana bagian SCTP ingin dimanfaatkan/diekspos; ini terasa ambigu karena tidak ada penyebutan atau usulan terkait di draft IETF WHIP. Sebagian besar "WHIP Provider" mendukung DataChannel, tetapi belum distandardisasi.
• Ada pertanyaan apakah koneksi langsung antara FFmpeg dan situs web memungkinkan penerimaan stream audio/video secara langsung; detail lebih lanjut bisa dilihat di halaman Phoronix (tautan)
  • Ringkasnya, program yang menggunakan library FFmpeg (terutama libavformat) kini bisa langsung menerima dan memanfaatkan stream WebRTC.
• Ada harapan bahwa perubahan ini akan membuat pembangunan stream self-hosting/CDN streaming jadi jauh lebih mudah, sambil menekankan kemandirian dan kemampuan plug-and-play ffmpeg.
  • Jika digabungkan dengan Simulcast, biaya maupun hambatan masuk diperkirakan akan turun drastis. Salah satu alasan membuat broadcast-box juga untuk menurunkan hambatan masuk self-hosting + WebRTC.
  • Dengan memanfaatkan LLM, bahkan perintah one-liner untuk semua pekerjaan video terkait ffmpeg bisa dihasilkan; pengalaman memakai AI sangat dipuji.
  • Komik xkcd 2347 yang menunjukkan betapa serbagunanya ffmpeg selalu terlintas di pikiran.
• Pengalaman tak terduga melihat grafis Anubis di ffmpeg dan gnu terasa mengesankan.
• Ada kekhawatiran bahwa penambahan fitur WHIP akan membuat mempertahankan ffmpeg di sistem menjadi lebih berisiko; terasa bahwa kerentanan keamanan WebRTC memang menjadi penyebab banyak pelanggaran nyata, dan ada pengalaman selalu menonaktifkannya setelah memasang browser di masa lalu.
  • Ada pertanyaan kerentanan keamanan seperti apa yang dimaksud; disebutkan bahwa implementasi kali ini sangat kecil, dan ada keyakinan kuat bahwa ini memberi hasil terbaik bagi pengguna.
  • Ada pertanyaan apakah tersedia opsi seperti --without-whip agar bisa sepenuhnya dikeluarkan dari build bila tidak diinginkan; itu dianggap akan menjadi yang terbaik.
  • Karena ffmpeg punya riwayat cukup banyak masalah keamanan, saat menangani input pengguna yang terbaik adalah selalu memakai lingkungan terisolasi. Misalnya, gunakan image Docker yang hanya berisi ffmpeg dan dependensinya lalu jalankan baru untuk setiap pekerjaan; atau jika perlu memproses thumbnail maupun dokumen, disarankan menambahkan ClamAV, OpenOffice, ImageMagick, dan sebagainya. Selain itu, server yang menangani file buatan pengguna sebaiknya dijalankan di VLAN yang semaksimal mungkin terpisah, atau jika di AWS maka hanya dioperasikan dalam security group. Ini bukan kritik pada masing-masing proyek, melainkan penekanan pada sulitnya format biner itu sendiri dan pentingnya langkah keamanan proaktif; kasus 4chan juga layak dijadikan referensi. Halaman keamanan ffmpeg ada di sini
• Ada pertanyaan seperti apa aktivitas audit keamanan ffmpeg, sambil berbagi kesan bahwa dari situs resminya penanganannya terlihat agak reaktif.
• Ada pertanyaan apakah sekarang dimungkinkan merekam stream audio dari konferensi video Jitsi dengan ffmpeg.
• Ada yang bertanya apakah ada pengalaman berhasil menerapkan dukungan whip saat build FFmpeg dari source, sambil mengeluhkan sulitnya menemukan opsi ./configure yang benar.
  • Panduan yang diberikan: opsi yang dibutuhkan adalah --enable-muxer=whip dan --enable-openssl.
• Sangat menantikan hari ketika fitur ini diterapkan di Jellyfin.
  • Sebagai tanggapan, ada pertanyaan manfaat fungsional apa yang akan dibawa ini bagi Jellyfin.