A baixa latência é uma aspiração universal na mídia. Quando uma empresa como a Wowza produz o gráfico perfeito para explicar as tecnologias de streaming de baixa latência, você precisa tirar o chapéu para eles e usar o gráfico, com atribuição e algumas pequenas modificações. Apresento o referido gráfico como Figura 1; vamos discutir na ordem designada pelos números destacados que eu adicionei.
1. Aplicativos para baixa latência
GUIA DO PRODUTO
Melhores câmeras PTZ para streaming ao vivo
Apenas para ter certeza de que estamos todos na mesma página, a latência no contexto da transmissão ao vivo significa o atraso de vidro a vidro. O primeiro vidro é a câmera do evento ao vivo real, o segundo é a tela que você está assistindo. Latência é o atraso entre o momento em que aparece na câmera e em seu telefone. Contribuindo para a latência estão fatores como o tempo de codificação (no evento), o tempo de transporte para a nuvem, o tempo de transcodificação na nuvem (para criar a escada de codificação), o tempo de entrega e, criticamente, quantos segundos seu jogador armazena antes de começar a jogar.
A camada superior mostra os aplicativos típicos e seus requisitos de latência. Aplicativos populares ausentes devido à latência baixa e latência quase em tempo real são sites de jogos de azar e leilões.
Antes de mergulhar em nossa discussão sobre tecnologia, entenda que quanto menor a latência de sua transmissão ao vivo, menos resiliente será a transmissão a interrupções de largura de banda. Por exemplo, usando as configurações padrão, um fluxo HLS será reproduzido por mais de 15 segundos de largura de banda interrompida e, se for restaurado nesse ponto, o visualizador pode nunca saber que houve um problema. Em contraste, um stream de baixa latência irá parar de tocar quase imediatamente após uma interrupção. Portanto, o benefício do tempo de inicialização de baixa latência sempre precisa ser balanceado com o negativo das interrupções na reprodução. Se você não precisa absolutamente de baixa latência, pode não valer a pena sacrificar a resiliência para obtê-la.
Dito isso, é útil dividir a latência em três categorias, como segue.
PRO NEWSLETTERÁudio + Vídeo + TI. Nossos editores são especialistas em integração de áudio / vídeo e TI. Receba insights diários, notícias e networking profissional. Assine o Pro AV hoje.
- Bom ter - Mais rápido é sempre melhor, mas se você estiver transmitindo ao vivo uma reunião do Conselho de Educação ou um jogo de futebol do colégio, pode decidir que a robustez da transmissão é mais importante do que a baixa latência, especialmente se muitos espectadores estiverem assistindo em conexões de baixa taxa de bits.
- Vantagem competitiva - Em alguns casos, a baixa latência fornece uma vantagem competitiva, ou a latência lenta significa uma desvantagem competitiva. Você notará no gráfico que a latência típica para TV a cabo é de cerca de cinco segundos. Se o seu serviço de streaming está competindo com o cabo, você precisa estar nessa faixa, com a latência mais baixa fornecendo uma vantagem competitiva modesta.
- Comunicações em tempo real - Se você for um site de jogos de azar ou leilão, ou se seu aplicativo exigir comunicações em tempo real, é absolutamente necessário fornecer baixa latência.
- Guia de comparação de streaming ao vivo
- Como prever o sucesso do codec
Agora que conhecemos as categorias, vamos ver a maneira mais eficiente de fornecer o nível necessário de baixa latência.
2/3 É bom ter baixa latência
O número 2 mostra que o Apple HLS e o MPEG-DASH implantados usando suas configurações padrão resultam em cerca de 30 segundos de latência. Os números são simples; se você usar tamanhos de segmento de dez segundos e exigir que três segmentos estejam no buffer do player antes do início da reprodução, você terá trinta segundos. Na verdade, a Apple mudou seus requisitos de dez segundos para seis segundos há alguns anos, e a maioria dos produtores de DASH usa segmentos de 4-6 segundos, então o número padrão é realmente mais próximo de 20 segundos.
Ainda assim, o número 3, HLS Tuned e DASH Tuned, mostra latência de cerca de 6 a 8 segundos. Em essência, o ajuste significa mudar de segmentos de 10 segundos para segmentos de 2 segundos que, aplicando a mesma matemática, fornecem os 6-8 segundos de latência. Portanto, quando é bom ter latência, você pode cortar a latência drasticamente, sem tempo ou custo de desenvolvimento, ou aumentar significativamente o risco de entrega.
4. Vantagem competitiva - Tecnologias HTTP de baixa latência
Quando a baixa latência é necessária como uma vantagem competitiva, apenas cortar o tamanho dos segmentos não resolverá; você terá que implementar uma verdadeira tecnologia de baixa latência. Aqui, existem duas classes; Tecnologias HTTP como HLS de baixa latência e CMAF de baixa latência para DASH e soluções baseadas em outras tecnologias, como WebSockets e WebRTC.
Para a maioria dos produtores com aplicativos desta classe, as tecnologias HTTP de baixa latência oferecem a melhor combinação de acessibilidade, compatibilidade com versões anteriores, flexibilidade e conjunto de recursos. Portanto, abordarei HLS de baixa latência e CMAF de baixa latência para DASH nesta seção, e outras tecnologias na próxima.
Todos os sistemas de baixa latência baseados em HLS / DASH / CMAF funcionam da mesma maneira básica, conforme mostrado na Figura 2. Ou seja, em vez de esperar até que um segmento completo seja codificado, o que normalmente leva entre 6 a 10 segundos (parte superior da Figura 2) , o codificador cria blocos muito mais curtos que são transferidos para o CDN assim que são concluídos (parte inferior da Figura 2).
Por exemplo, se seu codificador estava produzindo segmentos de seis segundos, você teria pelo menos seis segundos de latência; o triplo disso se os três segmentos normais precisassem ser recebidos pelo visualizador antes do início da reprodução. No entanto, se seu codificador enviar pedaços a cada 200 milissegundos e o player tiver sido configurado para iniciar a reprodução imediatamente, a latência deve ser muito, muito menor. Um dos principais benefícios desse esquema é a compatibilidade com versões anteriores; uma vez que os segmentos ainda estão sendo criados, os jogadores não compatíveis com o esquema de baixa latência ainda devem ser capazes de reproduzir os segmentos, embora com latência mais longa. Esses segmentos também estão disponíveis instantaneamente para apresentações VOD da transmissão ao vivo.
Além dessas vantagens, as tecnologias HTTP de baixa latência suportam a maioria dos recursos de seus irmãos de latência normal, incluindo criptografia, inserção de publicidade e legendagem, que não são universalmente compatíveis com tecnologias WebRTC e baseadas em WebSockets. Você provavelmente pode implementar sua tecnologia de baixa latência selecionada usando seu player existente e infraestrutura de entrega, minimizando o desenvolvimento e outros custos de tecnologia.
Escolhendo uma tecnologia HTTP de baixa latência
Existem dois padrões principais para HTTP Adaptive Streaming, HLS e DASH, além de um formato de contêiner unificador, CMAF. Assim que a Apple anunciou sua solução HLS de baixa latência, ela imediatamente substituiu vários esforços básicos e se tornou a tecnologia preferida para fornecer baixa latência para HLS. Embora a especificação ainda seja relativamente nova, ela já é suportada por fornecedores de tecnologia como Wowza e WMSPanel com seu produto Nimble Streamer.
Existe um padrão DVB para DASH de baixa latência e o DASH Industry Forum aprovou vários modos de baixa latência para DASH a serem incluídos em suas próximas diretrizes de interoperabilidade. De acordo com todas essas especificações, os desenvolvedores de codificadores e reprodutores e redes de distribuição de conteúdo têm trabalhado por vários anos para garantir a interoperabilidade, de forma que todos os aplicativos de baixa latência DASH / CMAF possam começar a funcionar.
Como exemplo, Harmonic e Akamai juntas demonstraram CMAF de baixa latência já em NAB e IBC 2017, mostrando entrega OTT ao vivo com uma latência inferior a cinco segundos. Desde então, a Harmonic integrou a funcionalidade DASH de baixa latência em seus produtos baseados em dispositivo (Packager XOS e Electra XOS) e soluções SaaS (VOS Cluster e VOS260). Muitos outros fornecedores de codificadores e reprodutores fizeram o mesmo.
Quer você escolha implementar HLS de baixa latência ou baixa latência para DASH, ou ambos, a transição de sua arquitetura de entrega de HLS e / ou DASH existente deve ser relativamente simples e econômica.
5. Comunicações em tempo real
WebRTC é normalmente o mecanismo para um pacote integrado que inclui o codificador, o player e a infraestrutura de entrega. Exemplos de soluções de streaming de grande escala baseadas em WebRTC incluem Real Time da Phenix, Limelight Realtime Streaming e Millicast da CoSMo Software e Influxis (Figura 3). Você também pode acessar a tecnologia WebRTC em ferramentas como o Wowza Streaming Engine, o software CoSMO e o Red 5 Pro Server. Os tempos de latência para tecnologias nesta classe variam de 0,5 segundos para 71% dos fluxos (Phenix), menos de 500 milissegundos (Red5 Pro), a menos de um segundo (Limelight). Se você precisar de latência inferior a dois segundos, WebRTC é uma opção que você precisa considerar.
Se você precisa de comunicações em tempo real, provavelmente precisará implementar uma solução baseada em WebRTC ou Websockets. O WebRTC foi formulado para comunicações de navegador a navegador e é compatível com todos os principais navegadores de desktop, no Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 e BlackBerry 10, portanto, deve ser executado sem downloads em qualquer uma dessas plataformas. Como o nome sugere, WebRTC é um protocolo para entrega de streams ao vivo para cada visualizador, seja ponto a ponto ou servidor a ponto.
WebSockets é um protocolo em tempo real que cria e mantém uma conexão persistente entre um servidor e cliente que qualquer uma das partes pode usar para transmitir dados. Essa conexão pode ser usada para oferecer suporte a entrega de vídeo e outras comunicações, portanto, é conveniente se seu aplicativo precisar de interatividade. Como as implementações WebRTC, os serviços que usam WebSockets são normalmente oferecidos como um serviço que inclui player e CDN, e você pode usar qualquer codificador que possa transportar fluxos para o servidor via RTMP ou WebRTC. Os exemplos incluem a nuvem nanoStream da Nanocosmos e a nuvem de streaming de Wowza com latência ultrabaixa. Wowza afirma latência de menos de 3 segundos para sua solução, enquanto Nanocosmos afirma cerca de um segundo, vidro com vidro.
Outras tecnologias de baixa latência
Há uma quarta categoria de produtos mais conhecida como “outros”, que usa tecnologias diferentes para fornecer baixa latência. Esta categoria inclui o Protocolo de Streaming de Alta Eficiência (HESP) da THEO Technologies, um protocolo de streaming adaptável HTTP proprietário que, de acordo com a THEO, oferece latência abaixo de 100 milissegundos enquanto reduz a largura de banda em cerca de 10% em comparação com outras tecnologias de baixa latência. O HESP usa codificadores e CDNs padrão, mas requer suporte personalizado no empacotador e player (Figura 4). Você pode ler mais sobre o HESP em white paper disponível para download, aqui.
Aqui está uma lista de perguntas que você deve considerar ao decidir qual tecnologia de baixa latência implementar e como fazê-lo.
Construir ou comprar?
Se você mesmo implementar a tecnologia, certifique-se de responder a todas as perguntas listadas abaixo antes de escolher uma tecnologia. Se você estiver escolhendo um provedor de serviços, use-os para comparar os diferentes provedores de serviços.
Você está escolhendo um padrão ou um parceiro?
Descrevemos as diferentes tecnologias para alcançar baixa latência acima, mas as implementações variam de provedor de serviço para provedor de serviço. Portanto, nem todas as implementações de LL HLS incorporarão a entrega de ABR, pelo menos não no início. A maioria dos aplicativos tradicionais do tipo broadcast provavelmente migrará para padrões baseados em HTTP, como HLS / DASH / CMAF de baixa latência, enquanto os aplicativos que exigem latência ultrabaixa, como apostas e leilões, gravitarão em direção a outras tecnologias. Em ambos os casos, ao escolher um provedor de serviços, é mais importante determinar se ele pode atender às suas metas tecnológicas e de negócios do que qual tecnologia eles realmente implementam.
Pode ser escalonado e a que custo?
Uma das vantagens das tecnologias baseadas em HTTP é que elas são escalonadas com preços padrão usando a maioria dos CDNs. Em contraste, a maioria das tecnologias baseadas em WebRTC e WebSocket requerem uma infraestrutura de entrega dedicada implementada pelo provedor de serviços. Por esse motivo, os serviços não baseados em HTTP podem ser mais caros para entregar do que HLS / DASH / CMAF. Ao comparar os provedores de serviços, verifique o custo total do evento, incluindo entrada, transcodificação, largura de banda, criação de arquivo VOD, configurações únicas ou por evento e assim por diante.
Problemas relacionados à implementação?
Faça as seguintes perguntas relacionadas à implementação e ao uso da tecnologia.
- Qual é a latência alcançável em uma escala relevante para o tamanho do seu público e distribuição geográfica?
- Existem limitações de qualidade - algumas tecnologias podem ser limitadas a certas resoluções máximas ou perfis H.264.
- Os pacotes passarão por um firewall? Os sistemas baseados em HTTP usam protocolos HTTP, que são amigáveis ao firewall. Outros usam UDP, que pode não passar pelos firewalls automaticamente. Se for UDP, há algum backchannels para entregar aos visualizadores bloqueados?
- Quais plataformas são suportadas? Presumivelmente, computadores e dispositivos móveis, mas e quanto aos STBs, dongles, dispositivos OTT e TVs inteligentes?
- O sistema pode ser dimensionado para atender ao número de visualizadores-alvo? A infraestrutura do CDN é privada e, em caso afirmativo, ela pode atender a todos os visualizadores relevantes em todos os mercados relevantes? Quais são os custos previstos de escalonamento?
- Você pode usar seu próprio player ou precisa usar o player do sistema? Se for seu, quais mudanças são necessárias e quanto isso custará?
- O que é necessário para reprodução móvel? Os streams serão reproduzidos em um navegador ou é necessário um aplicativo? Se houver um aplicativo necessário (ou desejável), os SDKs estão disponíveis?
- Quais codificadores o sistema pode usar? A maioria deve usar qualquer codificador que possa suportar conexões RTMP no transcodificador de nuvem, mas verifique se outros protocolos são necessários.
- O conteúdo pode ser reutilizado para VOD ou será necessária a recodificação? Não é um grande negócio, pois custa cerca de US $ 20 / hora de vídeo para transcodificar para uma escada de codificação razoável, mas caro para transmissões frequentes.
- Quais são as opções de redundância e quais são os custos? Para transmissões de missão crítica, você vai querer saber como duplicar o fluxo de trabalho de codificação / transmissão caso algum componente do sistema caia durante o evento. Essa redundância é suportada e qual é o custo?
Quais recursos estão disponíveis e em que escala?
Haverá uma grande variedade de ofertas de recursos de diferentes fornecedores, que podem ou não incluir:
- Streaming ABR - quantas transmissões e há alguma taxa de bits relevante ou limitações de resolução?
- E sobre os recursos do DVR? Os telespectadores podem parar e reiniciar a reprodução sem perder nenhum conteúdo.
- Sincronização de vídeo - O sistema pode sincronizar todos os visualizadores no mesmo ponto do stream? Os streams podem flutuar sobre locais e dispositivos e, sem esse recurso, os usuários em algumas conexões podem ter uma vantagem para leilões ou jogos de azar.
- Qual proteção de conteúdo está disponível? Se você é um produtor de conteúdo premium, pode precisar de um DRM verdadeiro. Outros podem sobreviver com autenticação ou outras técnicas semelhantes.
- As legendas estão disponíveis? As legendas são legalmente exigidas para algumas transmissões, mas geralmente benéficas para todos.
- E quanto à inserção de publicidade ou outro esquema de monetização? O provedor de tecnologia / serviço oferece suporte para isso?
Em geral, se você é uma loja de streaming que busca atingir ou superar os tempos de transmissão na faixa de 5 a 6 segundos, uma tecnologia HTTP baseada em padrões é provavelmente sua melhor aposta, já que estará mais perto de oferecer suporte ao mesmo conjunto de recursos que você ' estamos usando atualmente, como proteção de conteúdo, legendas e monetização. Se você tiver um aplicativo que requer uma latência muito menor, provavelmente precisará de uma solução baseada em WebRTC ou Websockets, ou uma tecnologia HTTP proprietária. Em ambos os casos, fazer as perguntas listadas acima deve ajudá-lo a identificar a tecnologia e / ou o provedor de serviços que melhor atende às suas necessidades.