- Cloudflare hat als Erster offiziell ein CDN auf Basis von Media over QUIC (MoQ) vorgestellt
- MoQ ist ein neuer Standard für die Echtzeit-Medienübertragung und gilt als potenzieller Ersatz für WebRTC, HLS/DASH und RTMP/SRT
- Derzeit befindet sich das Angebot in der Developer Preview und kann über den öffentlichen Endpoint von Cloudflare mit verschiedenen Clients und Bibliotheken getestet werden
- Demofunktionen wie Live-Streaming und Wiedergabe sowie KI-basierte Untertitel stehen im Web und im Rust-Client zur Verfügung
- Wichtige Funktionen wie Authentifizierung, Safari-Unterstützung und ANNOUNCE sind noch nicht implementiert; interessierte Entwickler können auch selbst einen MoQ-Relay betreiben
Cloudflare veröffentlicht offiziell das erste MoQ-CDN
Einführung
- Mit der offiziellen Einführung eines CDN auf Basis des Media-over-QUIC-(MoQ)-Standards kündigt Cloudflare einen großen Wandel bei der Echtzeit-Medienübertragung an
- MoQ gilt als Standard der nächsten Generation, der bei der Übertragung von Live-Mediendaten wie Echtzeitvideo und Audio bestehende Protokolle wie WebRTC, HLS/DASH und RTMP/SRT ersetzen soll
- Der Start erfolgt als offizielles Produkt, das von realen Nutzern direkt im weltweiten Anycast-Netzwerk getestet werden kann
- Cloudflare ist damit der erste Anbieter eines MoQ-CDN; die Technologie dürfte Innovationen im Ökosystem der Echtzeit-Medienübertragung vorantreiben
Derzeit verfügbare Funktionen
- Die Technologie ist aktuell als Preview-Version verfügbar, daher sind Stabilität und Funktionsumfang noch begrenzt
- Cloudflare stellt den öffentlichen Endpoint
relay.cloudflare.mediaoverquic.combereit - Tests sind mit verschiedenen Open-Source-Bibliotheken und Clients möglich, darunter
- Mit Web-Demos und Bibliotheken sind Live-Übertragung und Wiedergabe direkt im Browser möglich
- Eine KI-basierte Untertitelverarbeitung wird testweise angeboten
- Im Browser werden Untertitel mit Technologien wie [silero-vad], [whisper], [transformers.js], [onnxruntime-web] und [WebGPU] erzeugt und übertragen
- Neben einer API im Web-Component-Stil wird auch eine JavaScript-API für fortgeschrittene Nutzung unterstützt
- Über die Rust-Bibliothek gibt es zudem eine Umgebung für Nutzer, die JavaScript nicht bevorzugen, etwa mit MP4-Import, ffmpeg-Integration sowie gstreamer-basierter Übertragung und Wiedergabe
Noch nicht implementierte Funktionen
- Die aktuelle Version unterstützt nur ein begrenztes Subset von Draft-07
- Wichtige noch fehlende Funktionen
- Keine Unterstützung für Stream-Authentifizierung: Für jeden Stream muss man selbst einen schwer zu erratenden Namen festlegen
- Keine Unterstützung für ANNOUNCE: Beginn und Ende eines Streams können nicht erkannt werden
- Keine Unterstützung für den Safari-Browser: Wegen Problemen bei der WebTransport-Unterstützung ist Safari nicht kompatibel
- Optimierung noch unvollständig: Benutzererfahrung und weitere Bereiche sollen schrittweise verbessert werden
- Bei Bedarf kann man selbst eine Instanz von moq-relay aufbauen, um erweiterte Funktionen zu nutzen
- Zusätzliche Funktionen wie JWT-basierte Authentifizierung und WebSocket-Fallback für Safari/TCP sind in Entwicklung
- Mit dem Terraform-Modul lässt sich auch ein globales CDN-Netzwerk aufbauen
Die Bedeutung von MoQ und Cloudflare
- An der Standardisierung von MoQ wird seit mehr als drei Jahren gearbeitet, und bis zu einer weltweiten Verbreitung dürfte noch einige Zeit vergehen
- Indem Cloudflare noch vor der RFC-Verabschiedung ein reales Produkt schnell auf den Markt bringt, trifft das Unternehmen eine mutige Entscheidung, um konkretes Feedback von Entwicklern und Nutzern zu gewinnen
- MoQ hat das Potenzial, bestehende Medienprotokolle wie WebRTC, HLS und RTMP zu ersetzen
- Diskussionen über den Standardentwurf und Code-Issues werden weitergehen, doch praktische Betriebserfahrungen dürften die Weiterentwicklung des Standards stark voranbringen
- Künftig werden wohl auch Google, Akamai und Fastly im MoQ-basierten Markt für Medienübertragung eigenen Code in ihren Netzwerken und Servern ausrollen müssen, um reale Anforderungen zu identifizieren
Weitere Pläne und die Community
- Für die Zukunft bleibt noch viel Arbeit, um WebRTC und bestehende Protokolle mit modernen Web-basierten APIs neu zu implementieren
- Die Gesamtbewertung von MoQ sollte nicht allein auf Basis des aktuellen Leistungs- und Funktionsstands erfolgen; gefragt sind aktive Tests und Feedback
- In der Community (Discord) sind bereits mehr als 900 Mitglieder aktiv; dort sind Fragen und Kooperationsvorschläge möglich
1 Kommentare
Hacker-News-Kommentare
Ich habe die Demo auf https://moq.dev/publish/ ausprobiert, und es fühlt sich wirklich sehr flüssig an. Sehr beeindruckend. Und ich bin dankbar für die großartige Technologie. Wenn ich mir die Big-Buck-Bunny-Demo auf https://moq.dev/watch/?name=bbb auf dem Handy anschaue, treten viele horizontale schwarze Linien auf (merkwürdigerweise ist auf einem PC im selben WLAN alles normal). Ich frage mich, ob das an der Puffergröße liegt. Kann man den Puffer clientseitig vergrößern, oder ist das eine serverseitige Einstellung? Und danke auch dafür, dass South Korea auf der „globalen“ CDN-Karte nicht vergessen wurde
Ich frage mich, ob das nur in Chrome funktioniert. In Firefox auf Android bekomme ich nur die Meldung, dass der Browser nicht unterstützt wird
Zu den horizontalen schwarzen Linien weiß ich nichts Genaues. Es wird in ein
<canvas>-Element gerendert, auf die Größe des Quellvideos skaliert und dann per CSS noch einmal an die Fenstergröße angepasstAuf einem OnePlus Ten mit Chrome flackern die schwarzen Linien häufig. Besonders scheinen sie von oben rechts nach unten links zu wandern; vielleicht ist es ein Refresh-Artefakt auf dem Display (rolling shutter effect)
Da auf der Seite viel von Rust-Code und WASM die Rede ist, könnte es auch sein, dass die CPU des Telefons WASM nicht schnell genug ausführt. Auf meinem Samsung S20 sehe ich überhaupt keine schwarzen Linien
Ich habe es auf einem MacBook Air M4 mit einer 600-Mbps-Verbindung getestet und war von der sofortigen Reaktion begeistert
Es gibt in diesem Artikel einen Abschnitt „Warum sollte mich das interessieren?“, aber dort wird nicht erklärt, welchen Nutzen Media over QUIC für Medienanbieter oder Endnutzer hat — also für die vermutlich einzigen zwei Parteien, die bei diesem Austausch wirklich wichtig sind. Deshalb frage ich mich, warum mich diese Technik interessieren sollte
Mein Fehler. Ich wollte Wiederholungen zu früheren Blogposts vermeiden und habe deshalb zu wenig erklärt: https://moq.dev/blog/replacing-webrtc/ Und tatsächlich ist MoQ vor allem eine Technik, die Entwicklern Vorteile bringt. Skalierung und Feature-Implementierung werden viel einfacher, daher gibt es nur indirekte Vorteile
Die End-to-End-Latenz (glass-to-glass) wird deutlich besser. Vor allem, weil das Protokoll nun nicht mehr nach dem Request/Response-Prinzip arbeitet
Hallo! Ich bin ein Cloudflare-MoQ-Entwickler, Fragen sind willkommen. Und danke für den Award, kixelated xD
Es gab die Erklärung: „Kein Head-of-Line-Blocking: Anders als bei TCP sind die Streams von QUIC unabhängig. Selbst wenn in einem Stream (z. B. Audio-Track) Pakete verloren gehen, werden andere Tracks (z. B. Video-Track) nicht blockiert. Die Aussetzer, die bei RTMP ständig auftreten, verschwinden dadurch.“ Wenn das so aufgebaut ist und es im Audio-Track Paketverlust gibt, während das Video ohne Unterbrechung weiterläuft, könnte dann Audio und Video nicht auseinanderlaufen? Ich kenne mich damit technisch nicht gut genug aus, vielleicht verstehe ich da etwas falsch
Ich habe eine Frage. Gibt es konkrete Pläne, die Goodput-Lücke zwischen TCP und QUIC zu verringern[1]? Im verlinkten Paper heißt es, dass beim Übergang von HTTP/2 (TCP) zu HTTP/3 (QUIC) ein Rückgang der Videobitrate um bis zu 9,8 % beobachtet wurde. Natürlich ist der Stack bei MoQ etwas anders, daher lässt sich das nicht direkt verallgemeinern, aber ein ähnliches Problem scheint möglich. (Ich habe mich in den letzten Monaten im Rahmen meiner Masterarbeit mit dem AF_XDP-Datapath von MsQuic beschäftigt. Mein Fazit war im Grunde, dass GSO/GRO die bessere Alternative sind und QUIC definitiv mehr Hardware-Offload braucht :p)
[1]: https://arxiv.org/pdf/2310.09423
Ich habe ein paar Fragen :)
Wie nah ist QUIC tatsächlich daran, im Browser wirklich nutzbar zu sein (also Browser und Infrastruktur unterstützen es beide, und es „funktioniert einfach“)?
Und wie geht QUIC mit NAT-Problemen um? WebRTC braucht unbedingt STUN/TURN, um Full-Cone-NAT zu durchqueren, und besonders TURN ist problematisch, weil man dafür viel Infrastruktur betreiben muss
Ich arbeite bei getstream.io an WebRTC-Streaming. WebRTC ist beim Setup etwas umständlich, hat aber nach Verbindungsaufbau den Vorteil niedriger Latenz. Mich würde interessieren, welche Vorteile oder Probleme MoQ nach erfolgreichem Verbindungsaufbau hat, also wie es sich im Vergleich zu WebRTC anfühlt
Ich frage mich, ob Load Balancing von Relays außerhalb des MoQ-Scopes liegt. Im Artikel scheint das nicht behandelt zu werden
Ich mag dieses Projekt wirklich sehr, lese gelegentlich auch den kixelated-Blog und folge auf GitHub.
Zunächst einmal Glückwunsch an kixelated und Cloudflare für diese großartige Arbeit.
Mich interessiert Live-Streaming in Echtzeit. Normalerweise schauen dabei Hunderte oder Tausende gleichzeitig zu; mich würde interessieren, ob es Pläne oder Möglichkeiten gibt, in MoQ Multicast zu verwenden oder zu implementieren. Bei HTTP/1.1 und HTTP/2 war das auf TCP-Basis schwierig, aber da HTTP/3 UDP nutzt, scheint das nun eine realistische Idee zu sein. Was denkt ihr darüber? Soweit ich weiß, forschen auch Akamai und die BBC daran
Multicast ist nicht nötig! Ein CDN ist im Grunde bereits eine Implementierung von Multicast auf L7. Router oder ISPs müssen das nicht direkt auf L3 umsetzen. Genau daran habe ich fünf Jahre lang bei Twitch gearbeitet
Theoretisch würde Multicast nur den Traffic vom CDN-Edge zum ISP reduzieren, aber das spielt eigentlich nur bei riesigen Events einmal im Jahr eine Rolle, etwa beim Super Bowl, und bringt für die meisten Veranstaltungen nichts. Viele CDNs haben dieses Problem bereits gelöst, indem sie ihre Edge-Server direkt innerhalb der ISPs betreiben, und bei kleinen Events ist die Wahrscheinlichkeit gering, dass zwei Zuschauer denselben Pfad teilen, sodass kein Vorteil entsteht
Bei Multicast gibt es außerdem andere Probleme wie Congestion Control und Verschlüsselung, und in einer föderierten Struktur ist das noch schwieriger
Am meisten profitieren würde P2P von Multicast, aber im großen CDN-Ökosystem dürfte eine Einführung schwer sein
Auch WebRTC wäre eigentlich sehr gut für Multicast geeignet und nutzt RTP, das ursprünglich dafür konzipiert wurde, aber in der Praxis gibt es kaum Interesse an echter Multicast-Unterstützung
Allerdings gibt es Gerüchte, dass Google innerhalb des eigenen Netzes Multicast für Meet verwendet, also wer weiß
Der „just announced“-Link ist auch für Leute, die überhaupt nicht wissen, worum es geht, sehr gut: https://blog.cloudflare.com/moq/ (ich habe ihn zuerst auch übersehen)
„Sub-Second-Latenz im Broadcast-Maßstab“, aber kein echtes Multicast
Die Formulierung „nicht einfach nur ein weiteres Protokoll, sondern eine neue Designphilosophie“ lässt bei mir den AI-Detektor anspringen
Ich frage mich, wie MOQ Fallback-Auflösung und Graceful Degradation handhabt. Und in zed füllt das Bild auch im Vollbild nicht den ganzen Bildschirm aus
Als Firefox-Nutzer möchte ich das hier teilen, falls jemand eine von Cloudflare gehostete Website mit HTTP/3 besucht:
https://bugzilla.mozilla.org/show_bug.cgi?id=1979683
Sieht nach einem Happy-Eyeballs-Problem aus? Ich werde es an Leute weitergeben, die sich besser damit auskennen
Verwendest du zufällig einen browserinternen DNS-over-HTTPS-(DoH-)Resolver? Ich persönlich konnte das Problem nicht reproduzieren. Ich nutze DoH mit 1.1.1.1
Mir ist aufgefallen, dass Chrome und Firefox HTTP/3 konsistenter nutzen, wenn sie einen DoH-Resolver statt des System-DNS verwenden. Mit dem System-Resolver werden HTTPS-DNS-Records oft nicht konsistent — oder gar nicht — abgefragt,
und Browser können HTTP/3-Serverunterstützung nur nutzen, wenn sie entweder per HTTPS-DNS-Record oder über einen zwischengespeicherten Alt-Svc-Header aus einer früheren HTTP/2/1.1-Verbindung darauf hingewiesen wurden. Außerdem neigen sie dazu, bestehende Verbindungen wiederzuverwenden, statt neue aufzubauen
Auch Alt-Svc-Header werden besonders in Firefox nicht immer konsistent gecacht
Noch komplizierter wird es dadurch, dass Browser (insbesondere Chrome) HTTP/3-Unterstützung komplett abschalten, wenn sich genügend Verbindungsfehler ansammeln. In meinem Uni-WLAN wurden UDP-Pakete oft unregelmäßig blockiert, wodurch das bei mir passiert ist, und danach funktionierte HTTP/3 sogar zu Hause nicht mehr. Die einzige Lösung war, in
chrome://flagsQUIC manuell wieder zu aktivieren. Selbst wenn dort standardmäßig „enabled by default“ steht, kann der tatsächliche Browserzustand anders sein. Firefox gibt HTTP/3 auf ähnliche Weise auf, aber nicht so hartnäckig wie Chrome, daher ist es dort weniger problematischWenn du weiter debuggen willst, prüfe auf https://tls-ech.dev, ob Encrypted Client Hello (ECH) funktioniert; dort werden HTTPS-Records nur für ECH-Keys genutzt, was bei der Eingrenzung hilft.
Danach kannst du mit Fastlys HTTP/3-Check (https://http3.is) prüfen, ob nur Alt-Svc-Negotiation verwendet wird.
Die Cloudflare-Testseite (https://cloudflare-quic.com) nutzt sowohl HTTPS-DNS-Records als auch Alt-Svc. Wenn dort HTTP/3 sofort verwendet wird, werden HTTPS-Records korrekt aufgelöst.
Es wäre interessant, deine Testergebnisse zu hören. Dass das Firefox-Problem nicht bei allen konsistent auftritt, liegt genau an diesen vielen Variablen.
(Und falls das jemand von Cloudflare liest: Bei https://cloudflare-quic.com/favicon.ico scheint etwas falsch konfiguriert zu sein. Außerdem verursacht das Laden des Bildes https://web.archive.org/web/20230424015350im_/https://www.cloudflare.com/img//nav/globe-lang-select-dark.svg über die Wayback Machine Verzögerungen beim Seitenaufbau; für Bilder sollte man „id_“-Links verwenden, damit kein Rewrite erfolgt und es schneller ist. Ich konnte früher mit Cloudflare Workers sogar Websites nach fehlgeschlagenen Servermigrationen provisorisch wiederherstellen. Oder man verwendet einfach direkt das Original https://www.cloudflare.com/img/nav/globe-lang-select-dark.svg, das auf der aktuellen Website weiterhin erreichbar ist.)
Ich habe in den letzten Jahren sehr viel mit den verschiedensten seltsamen Implementierungs- und Deployment-Problemen rund um HTTP/3 experimentiert. Großartiges Protokoll. Aber mit vielen eigenartigen Implementierungs- und Rollout-Problemen
Ich frage mich, ob das nur unter macOS auftritt. Unter Windows mit FF 141 und 142 kann ich es nicht reproduzieren
Wirklich cool! Beeindruckende Arbeit. Zuerst habe ich es als QUIC-CDN gelesen und dachte „niemals“, aber nachdem ich verstanden habe, dass Media over QUIC etwas Eigenständiges ist, finde ich es ziemlich interessant
Die erste App fand ich spannend. Das wäre vielleicht etwas für Show HN. Ich habe schon auf Live-Video-Plattformen gearbeitet, und MoQ ist interessant genug, dass ich Lust hätte, wieder in diese Entwicklung einzusteigen
Wenn „die Technik intern funktioniert“, dann reicht mir Support in den großen Browsern (bei caniuse scheint noch nichts dazu zu stehen).
Und wenn auch WebView-Engines wie Microsoft Edge WebView2 unterstützt werden, könnte man das direkt in der Entwicklung einsetzen.
Andererseits müsste es wohl auch von OBS oder YouTube unterstützt werden, damit es in der Praxis wirklich relevant ist
Also ... MoQ geht etwas weg von einer einzigen großen „Blackbox“-Web-API wie WebRTC. Aus Browsersicht ist Unterstützung für die WebTransport-API entscheidend.
Mit WebTransport und MoQT ergeben sich dann verschiedene neue Möglichkeiten, etwa mit WebCodecs als Videoplayer. Wenn man etwas mehr Latenz akzeptiert, kann man auch mit MSE abspielen und DRM verwenden.
Und ich habe schon vor meiner Zeit bei Cloudflare daran gearbeitet, direktes Publishing aus OBS zu ermöglichen; das hängt stark davon ab, wie man die medienspezifischen Details auf Ebene des „Streaming-Formats“ umsetzt. In der Branche entwickelt sich die Spezifikation auf dieser Ebene noch weiter, aktuell ist WARP die führende Spezifikation. Sobald sich WARP weiter etabliert, könnte diese Funktion auch direkt in OBS und Ähnliches integriert werden. Schon jetzt kann man über Norsk(https://norsk.video/) Video in einem fMP4-basierten Fallback-Format publizieren
Was YouTube betrifft: Bei Google arbeiten Leute aktiv an MoQT mit, aber wann und wie das in YouTube-Produkte einfließt, kann ich nach meiner Einschätzung nicht sagen
https://caniuse.com/webtransport
https://caniuse.com/webcodecs
WebCodecs ist tatsächlich nicht zwingend erforderlich; man kann auch mit MSE rendern, aber das ist komplizierter und hat höhere Latenz.
Für Safari-Support arbeite ich an einem WebSocket-Fallback und einem WASM-basierten OPUS-Encoder