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

 (git.ffmpeg.org)
3 poin oleh GN⁺ 2025-06-05 | 1 komentar | Bagikan ke WhatsApp
  • WHIP muxer ditambahkan ke avformat/whip, sehingga streaming berbasis WebRTC dengan latensi di bawah 1 detik kini dapat ditangani langsung di dalam FFmpeg
  • Dasar perubahan ini adalah WHIP Version 3, dan selain nama muxer serta implementasinya, konteks log dan pesan kesalahan untuk SSL·DTLS·RTC juga dirapikan
  • Magic number di dalam implementasi diganti menjadi makro dan fungsi, dan penanganan DTLS curve list, profil SRTP, magic number ICE STUN, serta RTP payload type juga diperhalus
  • Pada jalur media, alih-alih ukuran frame tetap, kini digunakan rtc->audio_par->frame_size, dan untuk konversi Annex B pada input MP4/ISOM digunakan h264_mp4toannexb
  • Konfigurasi build diubah agar whip hanya aktif saat DTLS diaktifkan, dan saat ini dukungan dibatasi pada OpenSSL

Penambahan WHIP muxer dan keterkaitan build

Perapian penanganan DTLS·ICE·RTP

  • WHIP muxer dirapikan bersamaan dengan pergantian nama, dan pesan kesalahan serta konteks log SSL·DTLS·RTC juga ditingkatkan
  • Magic number diganti dengan makro, dan sebagian logika dipisahkan menjadi fungsi
    • Level log juga disesuaikan agar lebih jelas
  • Di jalur DTLS, masuk sejumlah perubahan terkait kompatibilitas dan performa
    • DTLS curve list diperbarui
    • Nama profil SRTP untuk FFmpeg dan OpenSSL dirapikan
    • DTLS handshake dan penanganan ICE dioptimalkan untuk meningkatkan performa
    • ARQ dicegah dengan menggunakan satu timeout handshake dan server role
  • Penanganan ICE dirapikan ke arah penyatuan request/response dan DTLS handshake ke dalam satu fungsi
    • Magic number ICE STUN juga diperhalus
  • RTP payload type diperbarui berdasarkan definisi Chrome

Pemrosesan media dan batasan OpenSSL

  • Ukuran frame tetap di sisi audio diubah menjadi penggunaan rtc->audio_par->frame_size
  • Untuk mengonversi input MP4/ISOM ke Annex B, digunakan h264_mp4toannexb
  • Masalah timestamp OPUS dan pengaturan marker setelah penggunaan BSF juga ikut diperbaiki
  • Implementasi TLS dan DTLS digabungkan ke dalam struktur bersama
    • BIO callback, read, write, print_ssl_error, openssl_init_ca_key_cert, dan init_bio_method digunakan bersama
    • Struktur data yang sama digunakan
  • Kesalahan build OpenSSL diperbaiki agar dapat bekerja dengan Pion
  • configure diubah agar whip hanya aktif ketika dtls diaktifkan
    • Saat ini yang didukung adalah OpenSSL

Bacaan terkait

1 komentar

 
GN⁺ 2025-06-05
Opini Hacker News

  • Siaran WebRTC benar-benar membuat saya antusias. Alasannya sudah saya rangkum di README Broadcast Box dan PR OBS
    Sekarang GStreamer, OBS, dan FFmpeg semuanya mendukung WHIP, jadi bisa dibilang kita punya protokol siaran video universal yang dapat dipakai di semua platform seperti mobile, web, embedded, dan perangkat lunak penyiaran
    Saya sudah beberapa tahun mengerjakan open source dan siaran WebRTC, dan menurut saya ini tonggak besar
    [0] https://github.com/Glimesh/broadcast-box?tab=readme-ov-file#...
    [1] https://github.com/obsproject/obs-studio/pull/7926

    • Dari sudut pandang orang yang bekerja di bidang siaran event, perubahan ini bisa membuat OBS menjadi alternatif realistis untuk software profesional seperti vMix. Terutama dukungan P2P dan kemampuan menyiarkan beberapa scene terlihat sangat bernilai
    • Saya penasaran apakah ada pemutar video yang bisa memutar stream WebRTC. Terakhir kali saya cek, VLC dan tool populer lainnya belum mendukungnya

  • Ini bukan bagian SCTP. Yang sebenarnya diimplementasikan adalah WebRTC-HTTP Ingestion Protocol, atau WHIP, yaitu protokol HTTP berlatensi rendah untuk terhubung ke gateway yang berkomunikasi dengan peer melalui protokol berbasis SCTP milik WebRTC
    https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html
    Semoga suatu saat bisa berpindah ke protokol P2P berbasis QUIC atau WebTransport, alih-alih SCTP. QUIC menangani dengan baik hal-hal yang dulu dilakukan SCTP di atas UDP yang sudah ada, tanpa banyak menambah kompleksitas dan perbedaan implementasi
    Salah satu kandidatnya adalah Media-over-QUIC (MoQ), tetapi browser tidak punya P2P QUIC dan progres di sana juga sudah mandek sejak beberapa tahun lalu
    https://quic.video/ https://datatracker.ietf.org/group/moq/about/

    • Saya penasaran bagaimana sebaiknya bagian SCTP diekspos dan digunakan. Draf IETF WHIP tampaknya tidak menyebutkan atau mengusulkan hal itu
      Sebagian besar penyedia WHIP juga mendukung DataChannel, tetapi itu belum distandardisasi

  • Saya penasaran ini artinya apa. Apakah ini berarti sebuah situs web bisa terhubung langsung ke instance FFmpeg dan menerima stream audio atau video?
    Penjelasan dari Phoronix sedikit lebih detail: https://www.phoronix.com/news/FFmpeg-Lands-WHIP-Muxer

    • Sepertinya ini berarti program yang memakai library FFmpeg, khususnya libavformat, akan bisa menerima stream WebRTC

  • Dengan ini, tampaknya akan jauh lebih mudah membuat stream self-hosted atau CDN streaming
    FFmpeg benar-benar software media mandiri dan plug-and-play yang luar biasa, asal tahu cara menggunakannya

    • Benar-benar menarik. Apalagi kalau sampai ada Simulcast, kita bisa membuatnya sangat murah dan mudah untuk orang-orang
      Saya membuat https://github.com/Glimesh/broadcast-box karena ingin membuat self-hosting dan WebRTC jauh lebih mudah
    • LLM benar-benar paham cara memakai FFmpeg. Hampir untuk tugas apa pun yang berkaitan dengan video, kalau ditanya, mereka bisa membuatkan satu baris perintah ffmpeg yang sesuai
    • Memang benar, dan komik ini selalu terlintas di pikiran: https://xkcd.com/2347/

  • Klien XMPP Gajim sudah lama menunggu ini. Fitur panggilan audio/video praktis terbengkalai, dan mereka dengan sabar menunggu agar berkat FFmpeg fitur itu mudah ditambahkan kembali

    • Saya penasaran apakah Gajim dan XMPP masih dipakai. Saya rindu masa ketika aplikasi chat dipakai lewat pidgin seperti dulu
      Sekarang semuanya sudah menjadi taman tertutup atau layanan per aplikasi

  • Senang juga melihat grafis Anubis secara tak terduga. Sejauh ini saya melihatnya di ffmpeg dan gnu, antara lain

    • Saya juga suka, tapi kali ini tidak membiarkan saya masuk

  • Saya berharap ini tidak membuat keberadaan ffmpeg di sistem menjadi lebih berbahaya. Kerentanan keamanan WebRTC menjadi penyebab banyak insiden kompromi, dan itu salah satu fitur pertama yang saya matikan ketika memasang browser

    • Saya penasaran kerentanan keamanan apa yang dimaksud
      Implementasi ini sangat kecil, dan saya 100% yakin bahwa ini memberikan yang terbaik sebisa mungkin kepada pengguna
    • ffmpeg adalah kode berperforma tinggi yang menangani codec dan format biner rumit dalam C, jadi sepertinya tidak perlu hanya mengkhawatirkan WebRTC
    • Saya penasaran apakah bisa dikeluarkan dari build dengan argumen seperti --without-whip kalau tidak diinginkan atau tidak diperlukan. Itu sepertinya ideal
    • ffmpeg juga punya banyak isu keamanan di masa lalu [1], jadi saat menangani input pengguna, praktik terbaiknya memang mengisolasinya dengan baik
      Sebaiknya buat image Docker yang hanya berisi ffmpeg dan dependensinya, lalu jalankan docker run untuk setiap pekerjaan konversi. Kalau juga perlu membuat thumbnail gambar atau dokumen, ClamAV, OpenOffice, dan ImageMagick bisa ikut dimasukkan
      Secara pribadi, saya berpendapat server yang memproses file buatan pengguna, lebih dari sekadar menerima dan menyajikannya, sebaiknya ditempatkan di VLAN terpisah yang dikunci ketat, atau kalau di AWS, di dalam Security Group
      Ini bukan kritik bodoh terhadap proyek-proyek yang disebut. Keamanan itu sulit, terutama ketika menangani format biner yang sudah lama terakumulasi dan kadang direkayasa balik dengan cara yang meragukan. Lebih bijak mengakui ini sebelum terkena seperti 4chan
      [1] https://ffmpeg.org/security.html

  • Bagus sekali. Saya sedang membuat remote control berbasis web, dan kalau dengan ini ffmpeg gdigrab bisa dijadikan stream WebRTC lalu langsung dikonsumsi klien tanpa workaround ExpressJS yang sekarang saya lakukan, saya akan sangat puas

  • Menarik bahwa deteksi bot terus memblokir saya di iOS Safari. Terjadi baik di WiFi kantor maupun data seluler
    Semoga Anubis membiarkan saya lewat

    • Saya penasaran apakah yang muncul halaman "access denied", atau challenge-nya berulang tanpa henti
    • Saya penasaran apakah Anda memakai jaringan dual-stack

  • Anubis tidak membiarkan saya lewat ;(