- Cloudflare ने आधिकारिक रूप से पहला Media over QUIC(MoQ)-आधारित CDN पेश किया
- MoQ real-time media transport के लिए एक नया मानक है, जिससे WebRTC, HLS/DASH, RTMP/SRT की जगह लेने की उम्मीद है
- यह फिलहाल developer preview चरण में है, और Cloudflare के public endpoint के जरिए कई clients और libraries के साथ टेस्ट किया जा सकता है
- real-time broadcast publishing और viewing, AI-आधारित subtitles जैसी demo features web और Rust clients में उपलब्ध हैं
- अभी authentication, Safari support, ANNOUNCE जैसी प्रमुख features लागू नहीं हुई हैं, और इच्छुक developers खुद MoQ relay भी चला सकते हैं
Cloudflare ने आधिकारिक रूप से पहला MoQ CDN लॉन्च किया
परिचय
- Cloudflare ने Media over QUIC(MoQ) standard-आधारित CDN आधिकारिक रूप से लॉन्च किया है, जिससे real-time media transport के क्षेत्र में बड़े बदलाव के संकेत मिलते हैं
- MoQ को live video, audio और अन्य live media data transport में मौजूदा WebRTC, HLS/DASH, RTMP/SRT protocols की जगह लेने वाले next-generation standard के रूप में देखा जा रहा है
- यह लॉन्च एक आधिकारिक product के रूप में आया है, और दुनिया भर के Anycast network पर वास्तविक users इसे सीधे टेस्ट कर सकते हैं
- Cloudflare पहला MoQ CDN provider बन गया है, और उम्मीद है कि यह तकनीक real-time media transport ecosystem में innovation को बढ़ावा देगी
अभी उपलब्ध सुविधाएँ
- यह तकनीक फिलहाल preview version में है, इसलिए service stability और feature scope सीमित हैं
- Cloudflare ने
relay.cloudflare.mediaoverquic.comनाम का एक public endpoint खोला है - इसे नीचे दिए गए विभिन्न open source libraries और clients के जरिए टेस्ट किया जा सकता है
- web demo और libraries का इस्तेमाल करके browser के भीतर real-time broadcast publishing और viewing संभव है
- AI-आधारित subtitle processing का demo भी शामिल है
- browser के भीतर [silero-vad], [whisper], [transformers.js], [onnxruntime-web], [WebGPU] जैसी technologies से subtitles generate और transmit किए जाते हैं
- Web Component-style API के साथ-साथ JavaScript API के जरिए advanced usage भी support होता है
- Rust library के जरिए MP4 import, ffmpeg integration, gstreamer-आधारित broadcast publishing और viewing जैसी सुविधाएँ भी उपलब्ध हैं, ताकि JavaScript को पसंद न करने वाले users के लिए भी environment तैयार हो
अभी लागू न हुई सुविधाएँ
- मौजूदा version केवल सीमित Draft-07 subset को support करता है
- अभी उपलब्ध न होने वाली प्रमुख सुविधाएँ
- broadcast authentication का support नहीं: हर broadcast के लिए ऐसा नाम खुद देना होगा जिसका अनुमान लगाना कठिन हो
- ANNOUNCE का support नहीं: broadcast शुरू/बंद होने की detection सुविधा नहीं है
- Safari browser का support नहीं: WebTransport support की समस्या के कारण Safari compatible नहीं है
- optimization अभी अधूरा है: user experience आदि को धीरे-धीरे बेहतर किया जाएगा
- जरूरत होने पर, advanced features के लिए आप खुद moq-relay instance बना सकते हैं
- JWT-आधारित authentication, Safari/TCP के लिए WebSocket fallback जैसी अतिरिक्त सुविधाएँ विकसित की जा रही हैं
- terraform मॉड्यूल से global CDN network भी बनाया जा सकता है
MoQ और Cloudflare का महत्व
- MoQ standardization पर काम 3 साल से अधिक समय से चल रहा है, और इसे वास्तव में वैश्विक स्तर पर अपनाने में अभी काफी समय लग सकता है
- Cloudflare ने RFC अपनाए जाने से पहले ही वास्तविक product तेज़ी से लॉन्च करके developers और users से व्यावहारिक feedback पाने का साहसी फैसला लिया है
- MoQ तकनीक में WebRTC/HLS/RTMP जैसे मौजूदा media protocols की जगह लेने की क्षमता है
- standard draft और code issues पर चर्चा जारी रहेगी, लेकिन वास्तविक operational experience standard के विकास में बड़ा योगदान दे सकता है
- आगे चलकर MoQ-आधारित media transport बाजार में Google, Akamai, Fastly जैसी कंपनियों को भी अपने network और servers पर code deploy करके वास्तविक जरूरतों को समझना पड़ सकता है
आगे की योजना और कम्युनिटी
- आगे WebRTC और मौजूदा protocols को Web-आधारित आधुनिक APIs के रूप में फिर से लागू करने के लिए अभी काफी काम बाकी है
- मौजूदा चरण के performance/features के आधार पर पूरे MoQ का आकलन नहीं करना चाहिए, और सक्रिय रूप से testing और feedback में भागीदारी जरूरी है
- कम्युनिटी (Discord) में 900 से अधिक सदस्य सक्रिय हैं, जहाँ सवाल पूछे जा सकते हैं और सहयोग के प्रस्ताव दिए जा सकते हैं
1 टिप्पणियां
Hacker News की राय
मैंने https://moq.dev/publish/ पर डेमो टेस्ट किया और यह वाकई बहुत स्मूद लगा। काफ़ी प्रभावशाली है। और इतनी शानदार टेक्नोलॉजी के लिए आभार। जब मैंने https://moq.dev/watch/?name=bbb पर Big Buck Bunny डेमो मोबाइल फ़ोन पर देखा, तो बहुत सी क्षैतिज काली रेखाएँ दिखीं (अजीब बात है कि उसी Wi‑Fi पर चल रहे PC में यह ठीक है)। सोच रहा हूँ क्या यह buffer size की वजह से है। क्या client side पर buffer बढ़ाया जा सकता है, या यह server side setting होनी चाहिए? और "global" CDN मैप में South Korea को शामिल करने के लिए भी धन्यवाद
क्या यह सिर्फ Chrome में काम करता है? Android Firefox में तो सिर्फ यह संदेश दिखता है कि browser supported नहीं है
मुझे क्षैतिज काली रेखाओं वाले मुद्दे के बारे में पक्का नहीं पता। यह
<canvas>element में render होता है, source video size के हिसाब से resize किया जाता है, और फिर CSS से window size के हिसाब से दोबारा resize किया जाता हैOnePlus Ten पर Chrome में चलाने पर काली रेखाएँ अक्सर flicker करती हैं। खासकर ऊपर से दाईं नीचे दिशा में जाती हुई दिखती हैं, इसलिए शायद यह screen refresh artifact, यानी rolling shutter effect, भी हो सकता है
पेज पर Rust code और WASM का बहुत ज़िक्र है, इसलिए हो सकता है फ़ोन का CPU WASM को पर्याप्त तेज़ी से execute नहीं कर पा रहा हो। मेरे Samsung S20 में काली रेखाएँ बिल्कुल नहीं दिखतीं
मैंने mac book air m4 और 600mbps connection पर टेस्ट किया, और प्रतिक्रिया तुरंत मिली — काफ़ी चौंकाने वाला था
इस पोस्ट में 'आपको इसकी परवाह क्यों करनी चाहिए?' नाम का section है, लेकिन यह नहीं बताता कि Media over QUIC से media publishers या end users — यानी इस लेनदेन के सबसे अहम (और शायद एकमात्र) दो पक्षों — को क्या फ़ायदा है। इसलिए मैं सोच रहा हूँ कि मुझे इस टेक्नोलॉजी की परवाह क्यों करनी चाहिए
यह मेरी गलती है। पहले के ब्लॉग पोस्ट्स की बात दोहराने से बचते-बचते मैं पर्याप्त समझा नहीं पाया: https://moq.dev/blog/replacing-webrtc/ और सच तो यह है कि MoQ मुख्य रूप से developers के लिए फ़ायदेमंद तकनीक है। scalability और features implement करना बहुत आसान हो जाता है, इसलिए फ़ायदा अधिकतर अप्रत्यक्ष है
end-to-end (glass-to-glass) latency काफ़ी बेहतर हो जाती है। मुख्य कारण यह है कि protocol अब request/response मॉडल पर निर्भर नहीं है
नमस्ते! मैं Cloudflare MoQ developer हूँ, सवालों का स्वागत है। और award देने के लिए धन्यवाद, kixelated xD
वहाँ यह लिखा था: "head-of-line blocking नहीं: TCP के विपरीत, QUIC की streams स्वतंत्र होती हैं। एक stream (जैसे audio track) में packet loss होने पर भी दूसरी track (जैसे video track) नहीं रुकती। RTMP में जो stutter हमेशा होता था, वह इससे खत्म हो जाता है"। अगर संरचना ऐसी है, तो क्या audio track में packet loss होने पर video track बिना रुके चलता रहेगा और audio/video sync बिगड़ सकता है? मैं इस टेक्नोलॉजी से बहुत परिचित नहीं हूँ, इसलिए शायद मेरी समझ अधूरी हो
एक सवाल है। क्या TCP और QUIC के बीच goodput gap कम करने की कोई ठोस योजना है[1]? लिंक किए गए पेपर में कहा गया है कि HTTP/2(TCP) से HTTP/3(QUIC) पर जाने में video bitrate में अधिकतम 9.8% गिरावट देखी गई। बेशक MoQ का stack थोड़ा अलग है, इसलिए इसे सीधे सामान्यीकृत करना मुश्किल है, लेकिन लगता है कि मिलती-जुलती समस्या हो सकती है। (व्यक्तिगत रूप से मैंने पिछले कुछ महीनों में अपनी master's thesis के हिस्से के रूप में MsQuic के AF_XDP datapath को देखा है। निष्कर्षतः मुझे GSO/GRO बेहतर विकल्प लगे, और QUIC को निश्चित रूप से hardware offload की ज़्यादा ज़रूरत है :p)
[1]: https://arxiv.org/pdf/2310.09423
कुछ बातें जाननी हैं :)
QUIC browser में वास्तविक उपयोग के स्तर तक कितना पहुँच चुका है — यानी browser और infrastructure दोनों support करें और वह "बस काम करे"?
और QUIC NAT की समस्या कैसे हल करता है? WebRTC में full cone NAT पार करने के लिए STUN/TURN ज़रूरी होते हैं, खासकर TURN एक समस्या है क्योंकि उसके लिए बहुत infrastructure चलाना पड़ता है
मैं getstream.io पर WebRTC streaming पर काम करता हूँ। WebRTC setup करना थोड़ा झंझट वाला है, लेकिन connection हो जाने के बाद low latency इसकी बड़ी ताकत है। MoQ में connection स्थापित हो जाने के बाद क्या फ़ायदे या समस्याएँ हैं? WebRTC की तुलना में इसका अनुभव कैसा है?
क्या relays का load balancing MoQ के दायरे से बाहर है? पोस्ट में शायद इस हिस्से पर बात नहीं की गई
मुझे यह project बहुत पसंद है, और मैं कभी-कभी kixelated का ब्लॉग भी पढ़ता हूँ और Github पर follow करता हूँ।
सबसे पहले, मैं kixelated और Cloudflare — दोनों को इस शानदार काम के लिए बधाई देना चाहता हूँ।
मुझे real-time live streaming के बारे में जिज्ञासा है। आम तौर पर live streams को सैकड़ों या हज़ारों लोग एक साथ देखते हैं; क्या MoQ में multicast इस्तेमाल करने या implement करने की कोई योजना या संभावना है? HTTP/1.1 और HTTP/2 में TCP-आधारित होने के कारण यह मुश्किल था, लेकिन HTTP/3 में UDP होने से अब यह व्यावहारिक विचार लगता है। इस पर आपकी क्या राय है? मुझे पता है कि Akamai और BBC भी इस पर शोध कर रहे हैं
multicast की ज़रूरत नहीं है! CDN दरअसल L7 पर multicast को implement करने जैसा ही है। routers या ISPs को इसे L3 पर सीधे implement करने की ज़रूरत नहीं है। यही काम मैं Twitch में 5 साल तक करता रहा
सिद्धांततः multicast सिर्फ CDN edge से ISP तक जाने वाले traffic को कम करेगा, लेकिन यह साल में एक बार होने वाले बेहद बड़े broadcasts (जैसे Super Bowl) में ही मायने रखता है; ज़्यादातर events में इससे फ़ायदा नहीं होगा। कई CDNs ने इस समस्या को हल करने के लिए CDN edge पहले से ही ISP के भीतर तैनात कर रखे हैं, और छोटे events में दो viewers का वही path share करने की संभावना कम होती है, इसलिए लाभ भी कम है
multicast के साथ congestion control और encryption जैसी दूसरी समस्याएँ भी हैं, और federated setup में ये और कठिन हो जाती हैं
multicast से सबसे ज़्यादा फ़ायदा P2P को मिल सकता है, लेकिन विशाल CDN ecosystem में इसका अपनाया जाना कठिन लगता है
WebRTC भी multicast के लिए सबसे उपयुक्त है और RTP भी इस्तेमाल करता है (जिसे मूल रूप से multicast के लिए डिज़ाइन किया गया था), लेकिन व्यवहार में multicast support को लेकर कोई खास रुचि नहीं है
हाँ, Google के अपने network के भीतर Meet service में multicast इस्तेमाल होने की अफ़वाह है, तो कौन जाने
"just announced" वाला लिंक उन लोगों के लिए भी बहुत अच्छा है जिन्हें यह बिल्कुल नहीं पता कि यह क्या है: https://blog.cloudflare.com/moq/ (मैंने भी पहली बार में इसे मिस कर दिया था)
"broadcast scale पर sub-second latency" लेकिन असली multicast नहीं
"यह सिर्फ एक और protocol नहीं, बल्कि एक नई design philosophy है" — यह लाइन पढ़कर मेरा AI detection radar सक्रिय हो गया
मैं जानना चाहता हूँ कि MOQ fallback resolution और graceful degradation को कैसे handle करता है। और zed में full screen करने पर भी स्क्रीन पूरी नहीं भरती, यह भी एक समस्या है
अगर आप Firefox user हैं और Cloudflare-hosted, HTTP/3 इस्तेमाल करने वाली साइट पर गए हैं, तो संदर्भ के लिए यह साझा करना चाहता हूँ:
https://bugzilla.mozilla.org/show_bug.cgi?id=1979683
यह happy eyeballs problem लग सकती है? मैं इसे उन लोगों तक पहुँचाने वाला हूँ जो मुझसे ज़्यादा जानते हैं
क्या आप browser के भीतर DNS over HTTPS (DoH) resolver इस्तेमाल कर रहे हैं? व्यक्तिगत रूप से मैं इस समस्या को reproduce नहीं कर पाया। मैं 1.1.1.1 के साथ DoH इस्तेमाल कर रहा हूँ
मैंने महसूस किया है कि Chrome और Firefox दोनों में, system DNS की जगह DoH resolver इस्तेमाल करने पर HTTP/3 का उपयोग अधिक consistent होता है। system resolver इस्तेमाल करने पर कई बार HTTPS DNS records लगातार (या बिल्कुल भी) नहीं मिलते,
और HTTP/3 server support तभी browser को advertise होती है जब या तो HTTPS DNS record मिले, या पहले के HTTP/2/1.1 से cached Alt-Svc header उपलब्ध हो। browser पहले से खुले connection को reuse करना पसंद करते हैं, इसलिए नया connection अक्सर नहीं बनता
Alt-Svc headers भी, खासकर Firefox में, हमेशा consistently cache नहीं होते
स्थिति को और जटिल यह बनाता है कि browsers (खासकर Chrome) अगर एक निश्चित संख्या में connection failures देख लें, तो HTTP/3 support को ही बंद कर देते हैं। मेरे साथ ऐसा university Wi‑Fi पर हुआ था, जहाँ UDP traffic बहुत (और अनियमित रूप से) block होता था; उसके बाद घर पर भी HTTP/3 काम नहीं कर रहा था। इसका समाधान सिर्फ chrome://flags में जाकर QUIC support को manually enable करना था। भले ही वहाँ default रूप में "enabled by default" लिखा हो, browser की वास्तविक internal state अलग हो सकती है। Firefox भी इसी तरह HTTP/3 छोड़ देता है, लेकिन Chrome जितना जिद्दी नहीं होता और यह उतनी बड़ी समस्या नहीं बनती
अगर आप और debugging करना चाहते हैं, तो https://tls-ech.dev पर जाँचें कि EncryptedClientHello(ECH) काम कर रहा है या नहीं; यह सिर्फ ECH keys के लिए HTTPS records इस्तेमाल करता है, इसलिए problem isolation में मदद मिलती है।
इसके बाद Fastly का HTTP/3 check (https://http3.is) यह दिखा सकता है कि क्या सिर्फ Alt-Svc negotiation हो रही है।
Cloudflare test page (https://cloudflare-quic.com) HTTPS DNS records और Alt-Svc दोनों का उपयोग करती है, इसलिए अगर वहाँ HTTP/3 तुरंत connect हो जाए, तो इसका मतलब है कि HTTPS record resolution ठीक चल रही है
अगर आप test results साझा करें तो अच्छा होगा। Firefox की समस्या सभी के लिए एक जैसी न दिखने का कारण यही कई variables हैं
(और Cloudflare वालों के लिए एक नोट: https://cloudflare-quic.com/favicon.ico शायद गलत configure किया गया है। और https://web.archive.org/web/20230424015350im_/https://www.cloudflare.com/img//nav/globe-lang-select-dark.svg इमेज Wayback Machine से लोड होने की वजह से page load में देरी करती है; images के लिए "id_" लिंक इस्तेमाल करने पर rewrite नहीं होता और ज़्यादा तेज़ होता है। पहले मैं Cloudflare Workers के साथ इसका उपयोग server migration failure के दौरान साइट को अस्थायी रूप से बहाल करने के लिए कर चुका हूँ। या बस https://www.cloudflare.com/img/nav/globe-lang-select-dark.svg मूल URL इस्तेमाल कर लें। यह फ़ाइल अभी भी साइट पर मौजूद है)
पिछले कुछ वर्षों में मैंने HTTP/3 के कई अजीब implementation और deployment issues के साथ बहुत प्रयोग किए हैं। यह शानदार protocol है। लेकिन इसमें बहुत से अजीब और विचित्र implementation तथा deployment issues हैं
क्या यह सिर्फ macOS तक सीमित है? Windows पर FF 141, 142 में यह reproduce नहीं होता
बहुत बढ़िया! मेहनत देखकर प्रभावित हूँ। पहले मैंने इसे QUIC CDN समझा और सोचा "असंभव", लेकिन जब Media over QUIC एक अलग concept है यह समझा, तो यह काफ़ी दिलचस्प लगा
पहला app बहुत दिलचस्प लगा। इसे Show HN में submit करना चाहिए। मैंने live video platforms पर काम किया है, और MoQ इतना दिलचस्प लग रहा है कि यह मुझे फिर से इस तरह का development करने के लिए प्रेरित कर सकता है
अगर "तकनीक भीतर से काम करती है", तो मुझे लगता है कि बस major browser support मिलना काफ़ी है (caniuse पर भी जानकारी नहीं दिखती)।
और अगर Microsoft Edge WebView2 जैसे webview engines भी support करें, तो यह तुरंत development में अपनाने लायक लगेगा।
लेकिन दूसरी ओर, जब तक OBS या YouTube जैसी चीज़ें इसे support न करें, तब तक इसका वास्तविक महत्व सीमित रहेगा
तो... MoQ, WebRTC जैसी एक बड़ी "black box" web API से थोड़ा हटकर चल रहा है। browser के नज़रिए से असली मुद्दा WebTransport API support है।
WebTransport के साथ MoQT का उपयोग करने पर, उदाहरण के लिए video player के लिए WebCodecs जैसे कई नए विकल्प खुलते हैं। थोड़ा latency स्वीकार करें तो MSE पर play करते हुए DRM भी लागू किया जा सकता है
और OBS से सीधे publish कराने पर मैं Cloudflare में आने से पहले भी काम कर रहा था, लेकिन यह काफी हद तक इस बात पर निर्भर करता है कि "streaming format" layer में media-specific details को कैसे implement किया जाए। इंडस्ट्री में इस layer की specs अभी भी सक्रिय रूप से विकसित हो रही हैं, और फिलहाल WARP प्रमुख spec है। जैसे-जैसे WARP standard स्थिर होगा, वैसे-वैसे OBS आदि में यह capability built-in आ सकती है। अभी भी Norsk(https://norsk.video/) के माध्यम से fMP4-आधारित fallback format में video publish किया जा सकता है
YouTube की बात करें तो Google के कुछ लोग MoQT में सक्रिय रूप से योगदान दे रहे हैं, लेकिन यह YouTube product में कब और कैसे आएगा, इस पर मैं कोई ठोस अनुमान नहीं लगा सकता
https://caniuse.com/webtransport
https://caniuse.com/webcodecs
वास्तव में WebCodecs अनिवार्य नहीं है; MSE के साथ भी render किया जा सकता है, लेकिन यह ज़्यादा पेचीदा है और latency भी अधिक होती है।
Safari support के लिए WebSocket fallback और WASM-आधारित OPUS encoder पर काम चल रहा है