- A Cloudflare anunciou oficialmente o primeiro CDN baseado em Media over QUIC (MoQ)
- O MoQ é um novo padrão para transmissão de mídia em tempo real e deve substituir WebRTC, HLS/DASH e RTMP/SRT
- No momento, está em fase de preview para desenvolvedores e pode ser testado com vários clientes e bibliotecas por meio do endpoint público da Cloudflare
- Recursos de demonstração como transmissão e visualização ao vivo, além de legendas com IA, estão disponíveis na web e em clientes Rust
- Ainda faltam autenticação, suporte ao Safari, ANNOUNCE e outros recursos principais; desenvolvedores interessados também podem operar seu próprio relay MoQ
Cloudflare lança oficialmente o primeiro CDN de MoQ
Introdução
- Com o lançamento oficial de um CDN baseado no padrão Media over QUIC (MoQ), a Cloudflare sinaliza uma grande mudança no campo da transmissão de mídia em tempo real
- O MoQ vem ganhando destaque como padrão de próxima geração capaz de substituir os protocolos tradicionais de mídia ao vivo, como WebRTC, HLS/DASH e RTMP/SRT, para transmissão de vídeo, voz e outros dados em tempo real
- Este lançamento chega como um produto oficial, permitindo que usuários reais o testem diretamente na rede Anycast global
- A Cloudflare se tornou a primeira operadora de CDN de MoQ, e a expectativa é que essa tecnologia acelere a inovação no ecossistema de transmissão de mídia em tempo real
Recursos disponíveis atualmente
- A tecnologia está em versão preview, com estabilidade de serviço e escopo funcional ainda limitados
- A Cloudflare disponibilizou o endpoint público
relay.cloudflare.mediaoverquic.com - É possível testar com várias bibliotecas e clientes open source, como:
- Usando a demo web e as bibliotecas, é possível transmitir e assistir a conteúdo ao vivo em tempo real no navegador
- Aplicação experimental de processamento de legendas com IA
- Geração e transmissão de legendas no navegador com tecnologias como [silero-vad], [whisper], [transformers.js], [onnxruntime-web] e [WebGPU]
- Além de uma API no formato Web Component, também há suporte a uso avançado via API JavaScript
- Há também um ambiente voltado para quem prefere evitar JavaScript, com biblioteca em Rust para importação de MP4, integração com ffmpeg e transmissão/visualização com base em gstreamer
Recursos ainda não implementados
- A versão atual oferece suporte apenas a um subconjunto limitado do Draft-07
- Principais recursos ainda indisponíveis:
- Sem autenticação de transmissão: é preciso definir manualmente um nome difícil de adivinhar para cada transmissão
- Sem suporte a ANNOUNCE: não há detecção de início/fim de transmissão
- Sem suporte ao navegador Safari: incompatível com Safari devido a questões de suporte ao WebTransport
- Otimização ainda incompleta: a experiência do usuário e outros aspectos serão melhorados gradualmente
- Se necessário, é possível implantar sua própria instância de moq-relay para usar recursos mais avançados
- Recursos adicionais em desenvolvimento incluem autenticação baseada em JWT e fallback para WebSocket voltado a Safari/TCP
- Também é possível montar uma rede CDN global com o módulo terraform
O significado do MoQ e da Cloudflare
- O trabalho de padronização do MoQ já está em andamento há mais de 3 anos, e sua adoção global real ainda deve levar bastante tempo
- Ao lançar um produto real rapidamente antes da adoção do RFC, a Cloudflare tomou uma decisão ousada para obter feedback prático de desenvolvedores e usuários
- A tecnologia MoQ tem potencial para substituir protocolos de mídia existentes, como WebRTC, HLS e RTMP
- As discussões sobre o rascunho do padrão e os issues de código devem continuar, mas a experiência operacional real tende a contribuir fortemente para a evolução do padrão
- No futuro, empresas como Google, Akamai e Fastly também precisarão implantar código em suas próprias redes e servidores para entender as necessidades práticas do mercado de transmissão de mídia baseada em MoQ
Próximos passos e comunidade
- Ainda há muito trabalho pela frente para reimplementar WebRTC e os protocolos existentes com APIs modernas baseadas na web
- O desempenho e os recursos atuais não devem ser usados para julgar todo o potencial do MoQ; é importante participar ativamente de testes e feedback
- Mais de 900 pessoas já participam da comunidade no Discord, onde é possível fazer perguntas e propor colaborações
1 comentários
Comentários do Hacker News
Testei a demo em https://moq.dev/publish/ e a sensação é realmente muito fluida. Fiquei bem impressionado. E sou grato por uma tecnologia tão boa. Ao ver a demo do Big Buck Bunny em https://moq.dev/watch/?name=bbb no celular, aparece um fenômeno com muitas linhas pretas horizontais (curiosamente, no PC usando o mesmo Wi‑Fi funciona normalmente). Fico me perguntando se isso é por causa do tamanho do buffer. Queria saber se dá para aumentar o buffer no lado do cliente, ou se isso teria que ser uma configuração do servidor. E também agradeço por não terem esquecido a Coreia do Sul no mapa de CDN "global"
Fiquei me perguntando se isso funciona só no Chrome. No Firefox para Android só aparece uma mensagem dizendo que o navegador não é compatível
Não tenho certeza sobre o fenômeno das linhas pretas horizontais. Renderizo com o elemento
<canvas>, redimensiono para o tamanho do vídeo de origem e depois redimensiono de novo com CSS para o tamanho da janelaNo OnePlus Ten, reproduzindo no Chrome, as linhas pretas piscam com frequência. Principalmente num padrão que desce do canto superior da tela para o canto inferior direito, então talvez seja um artefato de atualização de tela (
rolling shutter effect)Como a página menciona bastante código Rust e WASM, talvez o problema seja que a CPU do celular não consegue executar WASM rápido o suficiente. No meu Samsung S20 não vejo nenhuma linha preta
Testei em um mac book air m4 com conexão de 600mbps e a reação foi imediata, fiquei impressionado
O post tem uma seção "por que isso importa?", mas não explica que benefício o Media over QUIC traz para publicadores de mídia ou usuários finais — ou seja, as duas partes mais importantes (e talvez as únicas) dessa troca. Então fico me perguntando por que eu deveria me importar com essa tecnologia
Foi um erro meu. Tentei evitar repetir o conteúdo de posts anteriores do blog e acabei explicando pouco: https://moq.dev/blog/replacing-webrtc/ e, na verdade, o MoQ é uma tecnologia que beneficia principalmente os desenvolvedores. O benefício para os outros é indireto, porque escalabilidade e implementação de funcionalidades ficam bem mais fáceis
A latência de ponta a ponta (glass-to-glass) melhora bastante. Principalmente porque o protocolo agora não é mais baseado em request/response
Olá! Sou desenvolvedor do Cloudflare MoQ, perguntas são bem-vindas. E obrigado pelo prêmio, kixelated xD
Havia uma explicação dizendo: "Sem head-of-line blocking: ao contrário do TCP, os streams do QUIC são independentes. Mesmo que haja perda de pacotes em um stream (por exemplo, a trilha de áudio), outras trilhas (por exemplo, a de vídeo) não ficam bloqueadas. As travadinhas que sempre aconteciam no RTMP desaparecem com isso". Nessa estrutura, se houver perda de pacotes na trilha de áudio e a trilha de vídeo continuar tocando sem parar, isso não poderia dessincronizar áudio e vídeo? Talvez eu esteja entendendo mal por não estar familiarizado com a tecnologia
Tenho uma pergunta. Existe algum plano concreto para reduzir a diferença de goodput entre TCP e QUIC[1]? No artigo vinculado, eles observam uma redução de até 9,8% no bitrate de vídeo ao passar de HTTP/2 (TCP) para HTTP/3 (QUIC). Claro que o MoQ tem uma pilha um pouco diferente, então não dá para generalizar diretamente, mas parece plausível que haja um problema parecido. (Pessoalmente, nos últimos meses investiguei o datapath AF_XDP do MsQuic como parte da minha dissertação de mestrado. No fim, fiquei com a impressão de que GSO/GRO é uma alternativa melhor e que o QUIC realmente precisa de mais offload em hardware :p)
[1]: https://arxiv.org/pdf/2310.09423
Tenho algumas curiosidades :)
Queria saber o quão perto o QUIC está de um estágio realmente utilizável no navegador (suporte tanto no navegador quanto na infraestrutura, nível "simplesmente funciona")
E queria saber como o QUIC lida com o problema de NAT. No WebRTC, STUN/TURN é indispensável para atravessar full cone NAT, e o TURN em especial é um problema, porque exige muita infraestrutura
Trabalho com streaming WebRTC na getstream.io. O WebRTC é meio trabalhoso de configurar, mas, depois que a conexão está estabelecida, a vantagem é a baixa latência. Queria saber que vantagens ou problemas o MoQ tem depois que a conexão já foi concluída, ou seja, como ele se compara ao WebRTC na prática
Queria saber se balanceamento de carga de relay está fora do escopo do MoQ. Parece que o post não trata disso
Gosto demais desse projeto, às vezes leio o blog do kixelated e o sigo no Github.
Antes de tudo, quero parabenizar tanto o kixelated quanto a Cloudflare por esse trabalho incrível.
Tenho curiosidade sobre live streaming em tempo real. Normalmente, streaming ao vivo tem centenas ou milhares de pessoas assistindo ao mesmo tempo; queria saber se existe intenção ou possibilidade de usar ou implementar multicast no MoQ. Em HTTP/1.1 e HTTP/2 isso era difícil por serem baseados em TCP, mas agora que o HTTP/3 usa UDP, me parece uma ideia mais realista. Queria saber o que vocês acham. Sei que a Akamai e a BBC também estão pesquisando isso
Não precisa de multicast! Na prática, uma CDN já é basicamente uma implementação de multicast na camada L7 (aplicação). Não há necessidade de roteadores ou ISPs implementarem isso diretamente na L3. Foi exatamente nisso que trabalhei por 5 anos na Twitch
Em teoria, o multicast só reduziria o tráfego entre a borda da CDN e o ISP, mas isso só faria diferença em transmissões gigantescas que acontecem uma vez por ano (como o Super Bowl); para a maioria dos eventos, não ajuda. Muitas CDNs já resolvem isso colocando a borda da CDN dentro do próprio ISP, e em eventos pequenos é improvável que dois espectadores compartilhem o mesmo caminho, então não há ganho
O multicast também traz outros problemas, como controle de congestionamento e criptografia, e isso fica ainda mais difícil em um multicast federado
Onde o multicast mais ajudaria seria em P2P, mas acho difícil ser adotado no ecossistema gigantesco de CDNs
O WebRTC também combina muito bem com multicast e usa RTP (originalmente projetado para multicast), mas na prática não há interesse em suporte a multicast
Dito isso, ouvi rumores de que o Google usa multicast dentro da própria rede para o Meet, então vai saber
O link "just announced" é ótimo até para quem não faz a menor ideia do que isso é: https://blog.cloudflare.com/moq/ (eu mesmo não tinha percebido de primeira)
"latência abaixo de um segundo em escala de broadcast", mas sem multicast de verdade
A frase "não é apenas mais um protocolo, é uma nova filosofia de design" fez meu radar de detecção de IA apitar
Fico curioso sobre como o MOQ lida com resolução de fallback em caso de falha e degradação gradual de qualidade. E também há um problema no zed em que, mesmo em tela cheia, a tela não fica totalmente preenchida
Sou usuário de Firefox e, caso você visite sites hospedados pela Cloudflare usando HTTP/3, queria compartilhar isso como referência:
https://bugzilla.mozilla.org/show_bug.cgi?id=1979683
Parece que pode ser um problema de happy eyeballs? Vou repassar para quem entende melhor
Queria saber se você está usando um resolvedor de DNS over HTTPS (DoH) dentro do navegador. Pessoalmente, não consigo reproduzir esse comportamento. Estou usando DoH com 1.1.1.1
Percebi que tanto o Chrome quanto o Firefox usam HTTP/3 de forma mais consistente quando usam um resolvedor DoH em vez do DNS do sistema. Quando usam o resolvedor do sistema, muitas vezes não conseguem obter os registros DNS HTTPS de forma consistente (ou simplesmente não conseguem),
e o suporte do servidor a HTTP/3 só funciona se for anunciado ao navegador por meio de registros DNS HTTPS ou por um cabeçalho Alt-Svc em cache de uma conexão anterior HTTP/2/1.1. Há uma tendência de reutilizar conexões já abertas, então nem sempre se cria uma nova conexão
O cabeçalho Alt-Svc também não é armazenado em cache de forma consistente, especialmente no Firefox
O que complica ainda mais é que os navegadores (especialmente o Chrome) desativam totalmente o suporte a HTTP/3 se acumularem um certo número de falhas de conexão. Quando eu usava o Wi‑Fi da universidade, eles bloqueavam muito tráfego UDP (de forma irregular), e depois disso o HTTP/3 não funcionava nem em casa. A única solução é ir em
chrome://flagse ativar manualmente o suporte a QUIC. Mesmo que por padrão apareça como "enabled by default", o estado real do navegador pode ser diferente. O Firefox também desiste do HTTP/3 de forma parecida, mas não é tão teimoso quanto o Chrome e não chega a ser um grande problemaSe quiser depurar mais, vale verificar em https://tls-ech.dev se o EncryptedClientHello (ECH) está funcionando; esse teste usa apenas registros HTTPS para as chaves ECH, então ajuda a isolar o problema.
Depois, com a verificação de HTTP/3 da Fastly (https://http3.is), dá para confirmar se está usando só negociação por Alt-Svc.
A página de teste da Cloudflare (https://cloudflare-quic.com) usa tanto registros DNS HTTPS quanto Alt-Svc, então se o HTTP/3 for estabelecido imediatamente, isso indica que a resolução de registros HTTPS está funcionando bem
Seria bom saber o resultado dos testes. O problema do Firefox não ser consistente entre diferentes pessoas provavelmente vem dessas várias variáveis
(E algo que eu gostaria de avisar para o pessoal da Cloudflare: https://cloudflare-quic.com/favicon.ico parece estar configurado de forma errada. E a imagem https://web.archive.org/web/20230424015350im_/https://www.cloudflare.com/img//nav/globe-lang-select-dark.svg está sendo carregada da Wayback Machine, o que atrasa o carregamento da página; para imagens, é melhor usar links
id_, porque assim não há rewrite e fica mais rápido. No passado eu já consegui restaurar temporariamente sites em falhas de migração de servidor usando isso junto com Cloudflare Workers. Ou então é só usar o original https://www.cloudflare.com/img/nav/globe-lang-select-dark.svg, que ainda existe no site atual)Nos últimos anos fiz muitos experimentos com várias implementações e problemas estranhos de implantação do HTTP/3. É um protocolo excelente. Mas existem muitos problemas estranhos e peculiares de implementação e implantação
Fico me perguntando se isso é limitado ao macOS. No FF 141 e 142 no Windows não consigo reproduzir
Muito legal! Fiquei impressionado com o trabalho. No começo li como QUIC CDN e pensei "não é possível", mas ao pesquisar mais a fundo vi que Media over QUIC é um conceito separado e bem interessante
O primeiro app foi interessante. Acho que valeria enviar para o Show HN. Já trabalhei em uma plataforma de vídeo ao vivo, e o MoQ parece interessante o suficiente para me dar vontade de voltar a desenvolver isso
Se "a tecnologia funciona por baixo dos panos", acho que não importa, desde que haja suporte nos principais navegadores (nem aparece no caniuse).
E se motores de webview como o Microsoft Edge WebView2 também forem compatíveis, parece algo que já dá para aplicar em desenvolvimento imediatamente.
Mas, por outro lado, para realmente fazer diferença, parece que precisaria ser suportado por coisas como OBS ou YouTube
Então... o MoQ está seguindo um caminho um pouco fora da grande API web "caixa-preta" única que é o WebRTC. Do ponto de vista do navegador, o ponto-chave é o suporte à API WebTransport.
Usando MoQT junto com WebTransport, surgem várias novas possibilidades, como usar WebCodecs como player de vídeo. Se você tolerar um pouco mais de latência, também dá para reproduzir com MSE e ainda aplicar DRM
E eu já vinha trabalhando em publicação direta pelo OBS antes mesmo de entrar na Cloudflare, mas isso depende bastante de como os detalhes de mídia são implementados na camada de "formato de streaming". Na indústria, a especificação dessa camada ainda está evoluindo continuamente, e hoje a especificação dominante é o WARP. À medida que o padrão WARP for se consolidando, esse tipo de funcionalidade poderá ser incorporado também em coisas como o OBS. Atualmente já é possível publicar vídeo por meio de um formato provisório baseado em fMP4 usando o Norsk(https://norsk.video/)
No caso do YouTube, o Google tem pessoas contribuindo ativamente para o MoQT, mas eu realmente não saberia dizer quando e de que forma isso pode chegar ao produto YouTube
https://caniuse.com/webtransport
https://caniuse.com/webcodecs
Na prática, WebCodecs não é obrigatório; também dá para renderizar com MSE, mas é mais complicado e a latência é maior.
Estou trabalhando em fallback para WebSocket e em um encoder OPUS baseado em WASM para dar suporte ao Safari