- Cloudflare secara resmi memperkenalkan CDN berbasis Media over QUIC(MoQ) yang pertama
- MoQ adalah standar baru untuk transmisi media real-time, dan diharapkan dapat menggantikan WebRTC, HLS/DASH, RTMP/SRT
- Saat ini masih berada pada tahap developer preview, dan dapat diuji melalui endpoint publik Cloudflare dengan berbagai klien dan library
- Fitur percontohan seperti siaran langsung, menonton, dan subtitle berbasis AI tersedia di web dan klien Rust
- Fitur utama seperti autentikasi, dukungan Safari, dan ANNOUNCE masih belum diimplementasikan, dan developer yang tertarik juga bisa menjalankan relay MoQ sendiri
Cloudflare resmi meluncurkan MoQ CDN pertama
Pengenalan
- Cloudflare resmi meluncurkan CDN berbasis standar Media over QUIC(MoQ), yang menandai potensi perubahan besar di bidang transmisi media real-time
- MoQ mendapat perhatian sebagai standar generasi berikutnya yang dapat menggantikan seluruh protokol lama seperti WebRTC, HLS/DASH, RTMP/SRT untuk pengiriman media langsung seperti video dan audio real-time
- Peluncuran kali ini hadir sebagai produk resmi, sehingga pengguna nyata dapat langsung mengujinya di jaringan Anycast global
- Cloudflare menjadi penyedia MoQ CDN pertama, dan teknologi ini diperkirakan akan mendorong inovasi dalam ekosistem transmisi media real-time
Fitur yang tersedia saat ini
- Teknologi ini masih dalam versi preview, sehingga stabilitas layanan dan cakupan fiturnya masih terbatas
- Cloudflare membuka endpoint publik
relay.cloudflare.mediaoverquic.com - Pengujian dapat dilakukan melalui berbagai library dan klien open source berikut
- Dengan demo web dan library tersebut, pengguna dapat menyiarkan dan menonton siaran langsung di dalam browser secara real-time
- Fitur pemrosesan subtitle berbasis AI juga diuji coba
- Di dalam browser, subtitle dapat dibuat dan dikirim menggunakan teknologi seperti [silero-vad], [whisper], [transformers.js], [onnxruntime-web], [WebGPU]
- Selain API berbasis Web Component, tersedia juga dukungan penggunaan lanjutan melalui JavaScript API
- Lingkungan untuk pengguna yang tidak menyukai JavaScript juga disediakan melalui library Rust, termasuk impor MP4, integrasi ffmpeg, serta siaran dan pemutaran berbasis gstreamer
Fitur yang belum diimplementasikan
- Versi yang tersedia saat ini hanya mendukung subset terbatas dari Draft-07
- Fitur utama yang masih belum tersedia
- Autentikasi siaran belum didukung: setiap siaran harus diberi nama yang sulit ditebak secara manual
- ANNOUNCE belum didukung: tidak ada fitur untuk mendeteksi dimulainya atau berakhirnya siaran
- Browser Safari belum didukung: Safari belum kompatibel karena masalah dukungan WebTransport
- Optimasi belum selesai: pengalaman pengguna dan aspek lain akan ditingkatkan secara bertahap
- Jika diperlukan, Anda dapat membangun instance moq-relay sendiri untuk memanfaatkan fitur lanjutan
- Fitur tambahan seperti autentikasi berbasis JWT dan fallback WebSocket untuk Safari/TCP sedang dikembangkan
- Dengan modul terraform, jaringan CDN global juga dapat dibangun
Arti penting MoQ dan Cloudflare
- Pekerjaan standardisasi MoQ telah berlangsung selama lebih dari 3 tahun, dan adopsi global nyata diperkirakan masih akan memerlukan waktu yang cukup lama
- Dengan merilis produk nyata lebih cepat sebelum RFC diadopsi, Cloudflare mengambil keputusan berani untuk menarik umpan balik nyata dari developer dan pengguna
- Teknologi MoQ memiliki potensi untuk menggantikan protokol media lama seperti WebRTC/HLS/RTMP
- Diskusi mengenai draf standar dan isu kode akan terus berlanjut, tetapi pengalaman operasional nyata diperkirakan akan sangat membantu perkembangan standar
- Ke depannya, pemain seperti Google, Akamai, dan Fastly juga perlu menyebarkan kode ke jaringan dan server mereka sendiri untuk memahami kebutuhan nyata di pasar transmisi media berbasis MoQ
Rencana ke depan dan komunitas
- Masih banyak pekerjaan yang harus dilakukan untuk mengimplementasikan ulang WebRTC dan protokol lama dengan API modern berbasis web
- Kinerja dan fitur pada tahap saat ini tidak boleh dijadikan penilaian akhir terhadap keseluruhan MoQ, dan partisipasi aktif dalam pengujian serta pemberian umpan balik sangat dibutuhkan
- Lebih dari 900 orang aktif di komunitas (Discord), dan pertanyaan maupun usulan kolaborasi dapat disampaikan
1 komentar
Komentar Hacker News
Saya mencoba demo di https://moq.dev/publish/ dan rasanya benar-benar mulus. Sangat mengesankan. Dan saya merasa berterima kasih atas teknologi yang hebat ini. Saat melihat demo Big Buck Bunny di https://moq.dev/watch/?name=bbb lewat ponsel, muncul banyak garis hitam horizontal (anehnya, di PC yang memakai Wi-Fi yang sama normal). Saya penasaran apakah ini karena ukuran buffer. Ingin bertanya apakah buffer bisa diperbesar di sisi klien, atau harus lewat pengaturan server. Dan terima kasih karena tidak melupakan South Korea di peta CDN "global"
Saya penasaran apakah ini hanya bekerja di Chrome. Di Firefox Android hanya muncul pesan bahwa browser tidak didukung
Saya tidak begitu tahu soal gejala garis hitam horizontal itu. Rendering dilakukan dengan elemen
<canvas>, diubah ukurannya agar sesuai dengan ukuran video sumber, lalu di-resize lagi dengan CSS agar sesuai ukuran jendelaSaat diputar di OnePlus Ten dengan Chrome, garis hitamnya sering berkedip. Terutama terlihat seperti turun dari bagian atas layar ke kanan bawah, jadi mungkin ini artefak refresh layar (
rolling shutter effect)Karena halaman itu banyak menyebut kode Rust dan WASM, mungkin CPU ponselnya tidak cukup cepat menjalankan WASM. Di Samsung S20 saya sama sekali tidak terlihat garis hitam
Saya mengujinya di mac book air m4 dengan koneksi 600mbps, dan reaksinya terasa seketika serta mengagumkan
Ada bagian "mengapa harus peduli?" di artikel ini, tetapi tidak menjelaskan manfaat Media over QUIC bagi penerbit media atau pengguna akhir — yaitu dua pihak paling penting (mungkin satu-satunya) dalam pertukaran ini. Jadi saya penasaran kenapa saya harus peduli pada teknologi ini
Salah saya. Saya berusaha menghindari pengulangan dengan tulisan blog sebelumnya jadi penjelasannya kurang: https://moq.dev/blog/replacing-webrtc/ dan sebenarnya MoQ terutama menguntungkan para developer. Skalabilitas dan implementasi fitur jadi jauh lebih mudah, jadi manfaatnya lebih bersifat tidak langsung
Latensi end-to-end (glass-to-glass) menjadi jauh lebih baik. Terutama karena protokolnya sekarang bukan lagi model request/response
Halo! Saya developer Cloudflare MoQ, silakan kalau ada pertanyaan. Dan terima kasih atas award-nya, kixelated xD
Ada penjelasan seperti ini: "Tidak ada head-of-line blocking: tidak seperti TCP, stream di QUIC bersifat independen. Jika paket hilang di satu stream (misalnya track audio), track lain (misalnya track video) tidak ikut terblokir. Gejala tersendat yang selalu terjadi di RTMP hilang karena ini". Dengan struktur seperti ini, jika ada packet loss di track audio tetapi track video tetap berjalan tanpa berhenti, bukankah sinkronisasi audio dan video bisa bergeser? Mungkin saya kurang paham karena belum terbiasa dengan teknologinya
Saya punya pertanyaan. Apakah ada rencana konkret untuk memperkecil kesenjangan goodput antara TCP dan QUIC[1]? Di paper yang ditautkan disebutkan bahwa perpindahan dari HTTP/2 (TCP) ke HTTP/3 (QUIC) menunjukkan penurunan bitrate video sampai 9,8%. Tentu MoQ punya struktur stack yang agak berbeda jadi sulit digeneralisasi langsung, tetapi sepertinya masalah serupa bisa saja muncul. (Secara pribadi, beberapa bulan terakhir saya meneliti datapath AF_XDP milik MsQuic sebagai bagian dari tesis master saya. Kesimpulan saya, GSO/GRO adalah alternatif yang lebih baik, dan QUIC jelas butuh lebih banyak hardware offload :p)
[1]: https://arxiv.org/pdf/2310.09423
Ada beberapa hal yang saya penasaran :)
Saya ingin tahu seberapa dekat QUIC dengan tahap benar-benar bisa dipakai di browser (browser dan infrastruktur sama-sama mendukung, level "tinggal jalan")
Dan saya ingin tahu bagaimana QUIC menangani masalah NAT. WebRTC wajib butuh STUN/TURN untuk menembus full cone NAT, dan terutama TURN itu jadi masalah. Karena harus menjalankan banyak infrastruktur
Saya mengerjakan streaming WebRTC di getstream.io. WebRTC memang agak merepotkan saat setup, tetapi setelah tersambung keunggulannya adalah latensi rendah. Saya penasaran setelah koneksi MoQ selesai dibuat, apa kelebihan atau isu yang ada, maksudnya bagaimana rasanya dibanding WebRTC
Saya penasaran apakah load balancing relay berada di luar cakupan MoQ. Sepertinya artikel itu tidak membahas bagian ini
Saya sangat suka proyek ini, kadang juga membaca blog kixelated dan mengikuti di Github.
Pertama-tama saya ingin mengucapkan selamat kepada kixelated dan Cloudflare atas pekerjaan sekeren ini.
Saya penasaran soal live streaming real-time. Biasanya live streaming ditonton ratusan atau ribuan orang secara bersamaan, jadi saya ingin tahu apakah ada rencana atau kemungkinan menggunakan atau mengimplementasikan multicast di MoQ. Di HTTP/1.1 dan HTTP/2 hal itu sulit karena berbasis TCP, tetapi sekarang HTTP/3 memakai UDP jadi terasa seperti ide yang realistis. Saya ingin tahu pendapat Anda. Setahu saya Akamai dan BBC juga sedang meneliti hal ini
Tidak perlu multicast! CDN pada dasarnya sudah seperti implementasi multicast di L7 (lapisan aplikasi). Router atau ISP tidak perlu mengimplementasikannya langsung di L3. Inilah tepatnya yang saya kerjakan selama 5 tahun di Twitch
Secara teori multicast hanya akan mengurangi trafik dari edge CDN ke ISP, tetapi itu hanya relevan untuk siaran raksasa yang terjadi setahun sekali (misalnya Super Bowl), dan tidak berdampak untuk kebanyakan event. Banyak CDN juga sudah memasang edge CDN di dalam ISP untuk menyelesaikan masalah itu, dan untuk event kecil peluang dua penonton berbagi jalur yang sama rendah sehingga manfaatnya kecil
Multicast juga punya masalah lain seperti congestion control dan enkripsi, dan ini lebih sulit lagi karena multicast dalam struktur federasi
Tempat yang paling diuntungkan oleh multicast justru P2P, tetapi di ekosistem CDN raksasa sepertinya sulit diadopsi
WebRTC juga paling cocok dengan multicast dan memakai RTP (yang awalnya dirancang untuk multicast), tetapi pada praktiknya tidak ada minat untuk mendukung multicast
Meski begitu, ada rumor bahwa Google memakai multicast di dalam jaringannya sendiri untuk layanan Meet, jadi siapa tahu
Tautan "just announced" ini sangat bagus bahkan untuk orang yang sama sekali tidak tahu ini apa: https://blog.cloudflare.com/moq/ (saya juga sempat melewatkannya)
"latensi di bawah satu detik pada skala siaran" tetapi tanpa multicast sungguhan
Muncul frasa "bukan sekadar protokol lain, melainkan filosofi desain baru", jadi radar deteksi AI saya langsung aktif
Saya penasaran bagaimana MOQ menangani resolusi fallback dan graceful degradation. Dan di zed juga ada masalah bahwa saat fullscreen, layar tidak terisi penuh
Saya pengguna Firefox, dan kalau Anda pernah mengunjungi situs yang di-host oleh Cloudflare dan memakai HTTP/3, saya ingin membagikan ini sebagai referensi:
https://bugzilla.mozilla.org/show_bug.cgi?id=1979683
Kelihatannya mungkin masalah happy eyeballs? Akan saya teruskan ke orang yang lebih paham
Saya ingin tahu apakah Anda memakai resolver DNS over HTTPS (DoH) di dalam browser. Secara pribadi saya tidak bisa mereproduksi gejala itu. Saya memakai DoH ke 1.1.1.1
Saya merasa baik Chrome maupun Firefox lebih konsisten memakai HTTP/3 saat menggunakan resolver DoH daripada DNS sistem. Saat memakai resolver sistem, sering kali browser tidak bisa mengambil record DNS HTTPS secara konsisten (atau sama sekali tidak),
padahal dukungan server HTTP/3 hanya bisa diumumkan ke browser lewat record DNS HTTPS atau header Alt-Svc yang tersimpan dari HTTP/2/1.1 sebelumnya. Browser juga cenderung menggunakan kembali koneksi yang sudah terbuka, jadi jarang membuat koneksi baru
Header Alt-Svc juga tidak selalu tercache konsisten, terutama di Firefox
Yang makin memperumit situasi, browser (terutama Chrome) akan mematikan dukungan HTTP/3 sepenuhnya jika kegagalan koneksi menumpuk sampai tingkat tertentu. Itu pernah terjadi saat saya memakai Wi-Fi kampus yang sering memblokir trafik UDP secara tidak teratur, dan sesudah itu di rumah pun HTTP/3 tetap tidak aktif. Satu-satunya solusi adalah masuk ke
chrome://flagsdan menyalakan dukungan QUIC secara manual. Walaupun tampilannya secara default "enabled by default", status browser yang sebenarnya bisa berbeda. Firefox juga menyerah pada HTTP/3 dengan cara serupa, tetapi tidak sekeras Chrome dan biasanya tidak terlalu bermasalahJika ingin debug lebih lanjut, cek apakah EncryptedClientHello (ECH) berfungsi di https://tls-ech.dev, karena ini hanya memakai record HTTPS untuk kunci ECH sehingga bagus untuk mengisolasi masalah.
Setelah itu, Anda bisa memakai pengecekan HTTP/3 dari Fastly (https://http3.is) untuk melihat apakah yang dipakai hanya negosiasi Alt-Svc.
Halaman uji Cloudflare (https://cloudflare-quic.com) memakai record DNS HTTPS dan Alt-Svc sekaligus, jadi jika HTTP/3 langsung aktif di sana, berarti parsing record HTTPS berfungsi baik
Akan bagus kalau Anda bisa membagikan hasil pengujiannya. Masalah Firefox ini tidak konsisten pada semua orang karena ada begitu banyak variabel
(Yang ingin saya sampaikan ke pihak Cloudflare, https://cloudflare-quic.com/favicon.ico tampaknya salah konfigurasi. Dan gambar https://web.archive.org/web/20230424015350im_/https://www.cloudflare.com/img//nav/globe-lang-select-dark.svg dimuat dari Wayback Machine sehingga menunda pemuatan halaman; untuk gambar lebih cepat memakai tautan
id_agar tidak di-rewrite. Dulu saya pernah bisa memulihkan situs sementara saat migrasi server gagal dengan bantuan Cloudflare Workers. Atau cukup pakai sumber asli https://www.cloudflare.com/img/nav/globe-lang-select-dark.svg. File itu masih hidup di situs saat ini)Selama beberapa tahun terakhir saya sangat banyak bereksperimen dengan berbagai masalah implementasi dan deployment HTTP/3 yang aneh. Protokolnya hebat. Tetapi memang ada banyak masalah implementasi dan deployment yang aneh dan unik
Saya penasaran apakah ini khusus macOS. Di FF 141 dan 142 di Windows saya tidak bisa mereproduksinya
Keren sekali! Saya kagum dengan upayanya. Awalnya saya membacanya sebagai QUIC CDN dan sempat berpikir "masa iya", tetapi setelah melihat lebih jauh bahwa Media over QUIC adalah konsep yang berbeda, ini jadi cukup menarik
Aplikasi pertama itu menarik. Menurut saya layak diajukan ke Show HN. Saya pernah bekerja di platform video live, dan MoQ cukup menarik sampai membuat saya ingin mengembangkan hal seperti ini lagi
Selama "teknologinya bekerja di balik layar", menurut saya tidak masalah asalkan browser utama mendukungnya (bahkan belum terlihat di caniuse).
Dan jika mesin webview seperti Microsoft Edge WebView2 juga didukung, rasanya bisa langsung dipakai dalam pengembangan.
Tetapi di sisi lain, rasanya baru benar-benar berarti jika pihak seperti OBS atau YouTube mendukungnya
Jadi... MoQ mengambil jalur yang agak berbeda dari satu web API "kotak hitam" besar seperti WebRTC. Dari sudut pandang browser, kuncinya adalah dukungan WebTransport API.
Dengan WebTransport dan MoQT, misalnya, muncul berbagai pendekatan baru seperti memakai WebCodecs sebagai pemutar video. Kalau bersedia menerima sedikit latensi, pemutaran juga bisa dilakukan lewat MSE sambil tetap mendukung DRM
Dan pekerjaan agar bisa publish langsung dari OBS sudah saya lakukan bahkan sebelum masuk Cloudflare, tetapi ini sangat bergantung pada bagaimana detail media diimplementasikan di lapisan "format streaming". Di industri, spesifikasi lapisan ini masih terus berkembang, dan saat ini WARP adalah spesifikasi yang memimpin. Seiring spesifikasi WARP makin mapan, fitur ini bisa saja dibangun langsung ke OBS dan lain-lain. Bahkan sekarang pun video sudah bisa dipublikasikan lewat Norsk(https://norsk.video/) dengan format cadangan berbasis fMP4
Untuk YouTube, memang ada orang-orang di Google yang aktif berkontribusi pada MoQT, tetapi kapan dan bagaimana ini akan diterapkan ke produk YouTube, saya pribadi tidak bisa memastikan
https://caniuse.com/webtransport
https://caniuse.com/webcodecs
Sebenarnya WebCodecs tidak wajib, karena rendering juga bisa dilakukan dengan MSE, tetapi lebih rumit dan latensinya lebih tinggi.
Untuk dukungan Safari, sedang dikerjakan fallback WebSocket dan encoder OPUS berbasis WASM