- Cloudflare, ilk Media over QUIC(MoQ) tabanlı CDN çözümünü resmen duyurdu
- MoQ, gerçek zamanlı medya aktarımı için yeni bir standart olarak, WebRTC, HLS/DASH, RTMP/SRT'nin yerini alması bekleniyor
- Şu anda geliştirici önizlemesi aşamasında ve Cloudflare'ın herkese açık uç noktası üzerinden çeşitli istemci ve kütüphanelerle test edilebiliyor
- Gerçek zamanlı yayın yapma ve izleme, yapay zeka tabanlı altyazılar gibi deneysel özellikler web ve Rust istemcilerinde sunuluyor
- Henüz kimlik doğrulama, Safari desteği, ANNOUNCE gibi temel özellikler uygulanmış değil; ilgilenen geliştiriciler isterlerse kendi MoQ relay'lerini de çalıştırabiliyor
Cloudflare, ilk MoQ CDN'ini resmen duyurdu
Giriş
- Cloudflare'ın Media over QUIC(MoQ) standardına dayalı CDN çözümünü resmen kullanıma sunması, gerçek zamanlı medya aktarımı alanında büyük bir değişimin habercisi
- MoQ, canlı video, ses ve benzeri canlı medya verilerinin aktarımında mevcut WebRTC, HLS/DASH, RTMP/SRT protokollerinin tamamının yerini alabilecek yeni nesil bir standart olarak öne çıkıyor
- Bu duyuru, resmi bir ürün olarak yapıldı ve dünyanın dört bir yanındaki Anycast ağı üzerinde gerçek kullanıcılar tarafından doğrudan test edilebiliyor
- Cloudflare böylece ilk MoQ CDN sağlayıcısı oldu ve bu teknolojinin gerçek zamanlı medya aktarımı ekosisteminde yeniliği hızlandırması bekleniyor
Hâlihazırda sunulan özellikler
- Bu teknoloji önizleme sürümü olarak sunuluyor; hizmet kararlılığı ve özellik kapsamı sınırlı
- Cloudflare,
relay.cloudflare.mediaoverquic.comadlı herkese açık bir uç nokta açtı - Aşağıdaki çeşitli açık kaynak kütüphane ve istemcilerle test edilebiliyor
- Web demo ve kütüphaneler kullanılarak tarayıcı içinde gerçek zamanlı yayın yapma ve izleme mümkün
- Yapay zeka tabanlı altyazı işleme özelliği deneme amaçlı sunuluyor
- Tarayıcı içinde [silero-vad], [whisper], [transformers.js], [onnxruntime-web], [WebGPU] gibi teknolojilerle altyazı oluşturma ve iletme
- Web Component tarzı API'nin yanı sıra, JavaScript API üzerinden daha gelişmiş kullanım da destekleniyor
- Rust kütüphanesi üzerinden MP4 içe aktarma, ffmpeg entegrasyonu, gstreamer tabanlı yayın yapma ve izleme gibi olanaklar da JavaScript tercih etmeyenler için hazırlanmış durumda
Henüz uygulanmamış özellikler
- Mevcut sürüm yalnızca sınırlı bir Draft-07 alt kümesini destekliyor
- Henüz sunulmayan başlıca özellikler
- Yayın kimlik doğrulaması yok: Her yayın için tahmin edilmesi zor adların elle verilmesi gerekiyor
- ANNOUNCE desteği yok: Yayının başlama/bitişini algılama özelliği bulunmuyor
- Safari tarayıcı desteği yok: WebTransport desteğiyle ilgili sorunlar nedeniyle Safari ile uyumlu değil
- Optimizasyon tamamlanmadı: Kullanıcı deneyimi gibi alanlarda kademeli iyileştirmeler planlanıyor
- Gerekirse gelişmiş özelliklerden yararlanmak için doğrudan moq-relay instance'ı kurulabiliyor
- JWT tabanlı kimlik doğrulama, Safari/TCP için WebSocket fallback gibi ek özellikler geliştiriliyor
- terraform modülü ile küresel bir CDN ağı da kurulabiliyor
MoQ ve Cloudflare'ın anlamı
- MoQ standardizasyon çalışmaları 3 yıldan uzun süredir devam ediyor ve dünya çapında gerçek benimsenmenin zaman alması bekleniyor
- Cloudflare, RFC kabulünden önce gerçek bir ürünü hızla kullanıma sunarak, geliştiriciler ve kullanıcılar tarafında somut geri bildirim toplamayı hedefleyen cesur bir adım attı
- MoQ teknolojisi, WebRTC/HLS/RTMP gibi mevcut medya protokollerinin yerini alma potansiyeline sahip
- Standart taslağı ve kod sorunlarına ilişkin tartışmalar sürecek olsa da, gerçek işletim deneyiminin standardın gelişimine büyük katkı sağlaması bekleniyor
- İleride MoQ tabanlı medya aktarımı pazarında Google, Akamai, Fastly gibi şirketlerin de kendi ağ ve sunucularına kod dağıtarak pratik ihtiyaçları tespit etmesi gerekecek
Gelecek planları ve topluluk
- Bundan sonra WebRTC ve mevcut protokollerin web tabanlı modern API'lerle yeniden uygulanması için yapılacak çok iş var
- Mevcut aşamadaki performans ve özelliklere bakarak MoQ'nun tamamı hakkında hüküm verilmemeli; aktif test ve geri bildirim katılımı gerekiyor
- Toplulukta (Discord) 900'den fazla kişi aktif ve soru sormak ya da iş birliği önermek mümkün
1 yorum
Hacker News görüşleri
https://moq.dev/publish/ adresindeki demoyu denedim ve gerçekten çok akıcı hissettiriyor. Oldukça etkileyici. Ayrıca bu harika teknoloji için teşekkürler. https://moq.dev/watch/?name=bbb adresindeki Big Buck Bunny demosunu cep telefonumda izlerken çok sayıda yatay siyah çizgi oluşuyor (garip şekilde aynı Wi‑Fi’yi kullanan PC’de sorun yok). Bunun tampon boyutundan kaynaklanıp kaynaklanmadığını merak ediyorum. İstemci tarafında tamponu büyütmek mümkün mü, yoksa bu sunucu tarafında ayarlanması gereken bir şey mi? Ayrıca "global" CDN haritasında South Korea’yı atlamadığınız için teşekkürler
Bunun yalnızca Chrome’da mı çalıştığını merak ediyorum. Android Firefox’ta sadece desteklenmeyen tarayıcı mesajı görünüyor
Yatay siyah çizgi olayından emin değilim.
<canvas>öğesiyle render edip kaynak videonun boyutuna göre yeniden boyutlandırıyoruz, sonra CSS ile pencere boyutuna göre tekrar yeniden boyutlandırıyoruzOnePlus Ten’de Chrome ile oynatınca siyah çizgiler sık sık titreşiyor. Özellikle ekranın üst kısmından sağ alta doğru iniyor gibi ve belki de ekran yenileme artefaktı (
rolling shutter effect) olabilirSayfada Rust kodu ve WASM’den çok söz edildiği için, belki de telefonun CPU’su WASM’i yeterince hızlı çalıştıramadığı için oluyordur. Benim Samsung S20’de hiç siyah çizgi görünmüyor
mac book air m4 ve 600mbps bağlantıyla test ettim; tepkiselliği anlıktı ve şaşırtıcıydı
Bu yazıda 'neden önemsemeliyim?' diye bir bölüm var ama Media over QUIC’in medya yayıncılarına ya da son kullanıcılara — yani bu alışverişte en önemli (muhtemelen tek) iki tarafa — ne kazandırdığını açıklamıyor. O yüzden neden bu teknolojiyle ilgilenmem gerektiğini merak ediyorum
Benim hatam. Önceki blog yazılarıyla tekrar etmemeye çalışırken yeterince açıklayamamışım: https://moq.dev/blog/replacing-webrtc/ ve aslında MoQ daha çok geliştiricilere fayda sağlayan bir teknoloji. Ölçeklenebilirlik ve özellik geliştirme çok daha kolay olduğu için son kullanıcılara faydası daha dolaylı
Uçtan uca (camdan cama) gecikme belirgin biçimde daha iyi oluyor. Bunun ana nedeni artık protokolün request/response tabanlı olmaması
Merhaba! Cloudflare MoQ geliştiricisiyim, sorularınızı beklerim. Ve ödül için teşekkürler, kixelated xD
"Head-of-line blocking yok: TCP’nin aksine QUIC akışları bağımsızdır. Bir akışta (ör. ses parçası) paket kaybı olsa bile diğer parçalar (ör. video parçası) bloke olmaz. RTMP’de sürekli yaşanan takılmalar bu sayede ortadan kalkar" denmişti; bu yapıda ses parçasında paket kaybı olduğunda video durmadan oynamaya devam ederse ses ve görüntü senkronu bozulmaz mı diye merak ediyorum. Bu teknolojilere çok hakim olmadığım için yanlış anlamış olabilirim
Bir sorum var. TCP ile QUIC arasındaki goodput farkını azaltmak için somut planlar var mı merak ediyorum[1]. Bağlantılı makalede HTTP/2 (TCP)’den HTTP/3 (QUIC)’e geçildiğinde video bitrate’inde %9.8’e kadar düşüş görüldüğü söyleniyor. Elbette MoQ’nun yığın yapısı biraz farklı, dolayısıyla bunu doğrudan genellemek zor ama benzer bir sorun olabilir gibi geliyor. (Bu arada son birkaç aydır yüksek lisans tezim kapsamında MsQuic’in AF_XDP datapath’ini inceliyorum. Benim vardığım sonuç, GSO/GRO’nun daha iyi bir alternatif olduğu ve QUIC’in kesinlikle daha fazla donanım offload’una ihtiyaç duyduğu yönünde :p)
[1]: https://arxiv.org/pdf/2310.09423
Birkaç şeyi merak ediyorum :)
QUIC’in tarayıcılarda gerçekten kullanılabilir olma seviyesine — yani hem tarayıcı hem altyapı desteğiyle "direkt çalışıyor" noktasına — ne kadar yaklaştığını merak ediyorum
Ayrıca QUIC’in NAT sorununu nasıl ele aldığını merak ediyorum. WebRTC’de özellikle TURN maliyetli olduğu için STUN/TURN şart oluyor; çok fazla altyapı işletmek gerekiyor
getstream.io’da WebRTC yayıncılığı üzerinde çalışıyorum. WebRTC’nin kurulumu biraz uğraştırıcı ama bağlantı kurulduktan sonra düşük gecikme büyük bir avantaj. MoQ’nun da bağlantı kurulduktan sonra ne gibi artıları ya da sorunları olduğunu, yani WebRTC’ye kıyasla nasıl hissettirdiğini merak ediyorum
Rölelerin load balancing’inin MoQ kapsamı dışında mı kaldığını merak ediyorum. Yazıda bu kısım ele alınmamış gibi görünüyor
Bu projeyi gerçekten çok seviyorum; arada bir kixelated’in blogunu da okuyorum ve Github’da takip ediyorum.
Öncelikle bu kadar güzel bir iş çıkardıkları için hem kixelated’i hem de Cloudflare’i tebrik etmek istiyorum.
Gerçek zamanlı canlı yayın konusunda merak ettiğim şey şu: genelde canlı yayınları aynı anda yüzlerce, binlerce kişi izliyor; MoQ’da multicast kullanmak ya da uygulamak gibi bir düşünce veya olasılık var mı? HTTP/1.1 ve HTTP/2’de TCP tabanlı olduğu için bu zorlayıcıydı ama HTTP/3 UDP kullandığından artık daha gerçekçi bir fikir gibi geliyor. Bu konuda ne düşünüyorsunuz? Akamai ve BBC’nin de bunu araştırdığını biliyorum
Multicast’e gerek yok! CDN aslında pratikte L7’de yapılmış bir multicast gibi çalışıyor. Bunu yönlendiricilerin ya da ISP’lerin L3’te doğrudan uygulamasına gerek yok. Twitch’te 5 yıl boyunca yaptığım iş tam olarak buydu
Teorik olarak multicast yalnızca CDN edge’den ISP’ye giden trafiği azaltır ama bu da yılda bir kez olan dev yayınlarda (ör. Super Bowl) anlamlıdır; etkinliklerin büyük çoğunluğunda bir fayda sağlamaz. Birçok CDN zaten bu sorunu çözmek için CDN edge’lerini ISP’lerin içine yerleştirdi, küçük etkinliklerde ise iki izleyicinin aynı yolu paylaşma olasılığı düşük olduğu için kazanç olmuyor
Multicast’in congestion control ve şifreleme gibi başka sorunları da var; özellikle federatif yapıda multicast daha da zor
Multicast’in en çok fayda sağlayacağı yer P2P olurdu ama devasa CDN ekosisteminde benimsenmesi zor görünüyor
WebRTC de multicast’e en uygun seçeneklerden biri ve RTP kullanıyor (zaten başlangıçta multicast için tasarlanmıştı) ama buna rağmen multicast desteğine ilgi pek yok
Yine de Google’ın kendi ağı içinde Meet için multicast kullandığına dair söylentiler var, dolayısıyla belli olmaz
"just announced" bağlantısı, bunun ne olduğunu hiç bilmeyen biri için bile çok iyi: https://blog.cloudflare.com/moq/ (ben de ilk başta kaçırdım)
"Yayın ölçeğinde sub-second latency" ama gerçek multicast yok
"sadece başka bir protokol değil, yeni bir tasarım felsefesi" ifadesi görünce AI algılama radarım öttü
MOQ’un failback çözünürlüğü ve graceful degradation konularını nasıl ele aldığını merak ediyorum. Ayrıca zed’de tam ekran yapsam da görüntü ekranı tamamen doldurmuyor
Firefox kullanıyorsanız ve Cloudflare tarafından barındırılan, HTTP/3 kullanan siteleri ziyaret ediyorsanız paylaşmak istedim:
https://bugzilla.mozilla.org/show_bug.cgi?id=1979683
Bu bir happy eyeballs sorunu olabilir gibi görünüyor? Konuyu daha iyi bilenlere ileteceğim
Tarayıcı içi DNS over HTTPS (DoH) çözücüsü kullanıp kullanmadığını merak ediyorum. Ben şahsen bu sorunu yeniden üretemedim. 1.1.1.1 ile DoH kullanıyorum
Hem Chrome’da hem Firefox’ta, sistem DNS’i yerine DoH çözücüsü kullanıldığında HTTP/3 kullanımının daha tutarlı olduğunu fark ettim. Sistem çözücüsü kullanıldığında HTTPS DNS kayıtları çoğu zaman tutarlı şekilde (hatta bazen hiç) alınamıyor,
HTTP/3 sunucu desteğinin çalışması için tarayıcıya ya HTTPS DNS kaydıyla ya da önceki HTTP/2/1.1 bağlantılarından önbelleğe alınmış Alt-Svc başlığıyla ilan edilmesi gerekiyor. Tarayıcılar da mevcut bağlantıları yeniden kullanmaya eğilimli olduğu için yeni bağlantı açmakta isteksiz oluyor
Alt-Svc başlıkları da özellikle Firefox’ta tutarlı şekilde önbelleğe alınmıyor
Durumu daha da karmaşıklaştıran şey, tarayıcıların (özellikle Chrome’un) yeterince bağlantı hatası birikince HTTP/3 desteğini tamamen kapatması. Üniversite Wi‑Fi’sını kullanırken UDP trafiği yoğun şekilde (ve düzensiz biçimde) engellendiği için bunu yaşamıştım; sonrasında evde de HTTP/3 çalışmıyordu. Çözüm, chrome://flags üzerinden QUIC desteğini elle yeniden açmaktı. Arayüzde varsayılan olarak "enabled by default" görünse bile tarayıcının gerçek çalışma durumu farklı olabiliyor. Firefox da benzer şekilde bazen HTTP/3’ten vazgeçiyor ama Chrome kadar inatçı değil ve genelde büyük sorun çıkarmıyor
Daha fazla hata ayıklamak isterseniz EncryptedClientHello (ECH) çalışıyor mu diye https://tls-ech.dev üzerinden kontrol edebilirsiniz; bu sadece ECH anahtarları için HTTPS kaydı kullandığından sorunu izole etmeye yardımcı olur.
Sonra Fastly’nin HTTP/3 testiyle (https://http3.is) yalnızca Alt-Svc pazarlığı mı kullanılıyor diye bakabilirsiniz.
Cloudflare test sayfası (https://cloudflare-quic.com) hem HTTPS DNS kayıtlarını hem Alt-Svc’yi kullandığı için burada HTTP/3 hemen devreye giriyorsa HTTPS kayıt çözümlemesi düzgün çalışıyor demektir
Test sonuçlarını paylaşırsanız sevinirim. Firefox’taki sorunun herkeste tutarlı olmamasının nedeni bu kadar çok değişken olması
(Cloudflare tarafına da iletmek isterim: https://cloudflare-quic.com/favicon.ico sanki yanlış yapılandırılmış. Ayrıca https://web.archive.org/web/20230424015350im_/https://www.cloudflare.com/img//nav/globe-lang-select-dark.svg görselinin Wayback Machine’den yüklenmesi sayfa yüklemesini geciktiriyor; görseller için "id_" bağlantıları kullanılırsa rewrite yapılmadığı için daha hızlı oluyor. Eskiden bunu Cloudflare Workers ile birleştirip sunucu geçişi başarısız olduğunda siteyi geçici olarak ayağa kaldırmak için kullanabiliyordum. Ya da doğrudan https://www.cloudflare.com/img/nav/globe-lang-select-dark.svg orijinal dosyası kullanılabilir. Dosya şu an da yayında)
Son birkaç yıldır HTTP/3’ün çeşitli tuhaf uygulama ve dağıtım sorunlarıyla çok fazla deney yaptım. Harika bir protokol ama garip uygulama ve dağıtım sorunları da çok
Bunun macOS’a özgü olup olmadığını merak ediyorum. Windows’ta FF 141 ve 142’de yeniden üretemedim
Gerçekten çok havalı! Emeğe hayran kaldım. İlk başta bunu QUIC CDN diye okuyup "yok artık" dedim ama Media over QUIC’in ayrı bir kavram olduğunu daha detaylı öğrenince oldukça ilginç geldi
İlk uygulama ilgimi çekti. Show HN’e gönderilse güzel olur diye düşünüyorum. Canlı video platformlarında çalışmışlığım var ve MoQ, yeniden böyle bir geliştirme yapmak isteyeceğim kadar ilginç görünüyor
"Teknoloji içeride çalıştığı sürece" büyük tarayıcı desteği varsa benim için sorun değil (caniuse’da da pek bilgi görünmüyor).
Ayrıca Microsoft Edge WebView2 gibi webview motorları da destekliyorsa bunu doğrudan geliştirmede kullanabilirim diye düşünüyorum.
Ama öte yandan OBS ya da YouTube gibi tarafların da bunu desteklemesi gerekiyor ki gerçekten anlamlı olsun
Evet... MoQ, WebRTC gibi tek parça büyük bir "kara kutu" web API’sinden biraz uzaklaşıyor. Tarayıcı açısından kritik olan şey WebTransport API desteği.
WebTransport ile birlikte MoQT kullandığınızda örneğin video oynatıcı tarafında WebCodecs gibi yeni seçenekler açılıyor. Biraz daha fazla gecikmeyi kabul ederseniz MSE ile oynatıp DRM de uygulayabilirsiniz
OBS’den doğrudan publish edebilme üzerinde Cloudflare’e gelmeden önce de çalışıyordum; ama bu, medya ile ilgili ayrıntıların "streaming format" katmanında nasıl ele alındığına oldukça bağlı. Sektörde bu katmanın spesifikasyonu hâlâ gelişiyor ve şu anda öncü spesifikasyon WARP. WARP yerleştikçe bu özellik OBS gibi araçlara da doğrudan girebilir. Şu anda bile Norsk(https://norsk.video/) üzerinden fMP4 tabanlı bir yedek formatla video publish etmek mümkün
YouTube tarafında ise Google’ın MoQT’ye aktif katkı veren insanları var ama bunun YouTube ürünlerine ne zaman ve nasıl yansıyacağı konusunda benim net bir öngörüm yok
https://caniuse.com/webtransport
https://caniuse.com/webcodecs
Aslında WebCodecs şart değil; MSE ile de render edilebilir ama bu daha zahmetli ve gecikmesi daha yüksek olur.
Safari desteği için WebSocket fallback ve WASM tabanlı OPUS encoder üzerinde çalışıyorum