Uma solicitação típica de suporte técnico do Voximplant: "Por que uma vídeo chamada entre dois Chrome parece melhor do que uma vídeo chamada entre o MS Edge e um aplicativo iOS nativo?" Os colegas geralmente respondem de forma neutra - "porque os codecs". Mas nós, as pessoas de TI, somos curiosos. Mesmo que eu não esteja desenvolvendo um novo Skype para Web, ler “o que o navegador pode” e como eles dividem um vídeo em vários fluxos de qualidade diferente enriquece a imagem do mundo e fornece um novo tópico para discussão na sala de fumantes. Artigo publicado com sucesso de amplamente conhecido em círculos estreitos,
Dr. Alex (com a melhor explicação do termo "mecanismo de mídia" de tudo o que eu vi), um pouco da nossa experiência, algumas noites no "Dial" - e uma tradução adaptada para Habr está esperando por você!
Codecs e largura do canal
Ao falar sobre codecs de vídeo, na maioria das vezes eles discutem o equilíbrio de qualidade e largura do canal usado. E eles gostam de ignorar os problemas de carga do processador e como transmitir vídeo tecnicamente. Bastante razoável se estivermos discutindo a codificação de um vídeo já gravado.
Afinal, se você tiver um vídeo finalizado, não há muita diferença, ele comprimirá alguns minutos, algumas horas ou até alguns dias. Quaisquer custos de processador e memória serão justificados, porque este é um investimento único e você poderá distribuir o vídeo para milhões de usuários. Os melhores codecs de vídeo compactam o vídeo em várias passagens:
- Passe nº 1: o vídeo é dividido em partes com recursos comuns: a ação ocorre no mesmo plano de fundo, cena rápida ou lenta e similares.
- Passo 2: Colete estatísticas para codificação e informações sobre como os quadros mudam ao longo do tempo (para obter essas informações, você precisa de vários quadros).
- Passo 3: Cada parte é codificada com suas próprias configurações de codec e usando as informações obtidas na segunda etapa.
Streaming é uma questão completamente diferente. Ninguém vai esperar até o final de um podcast, transmitir ou mostrar antes de começar a codificar o vídeo. Codifique e envie imediatamente. Viva e peça que o atraso mínimo se torne mais importante.
Ao usar mídia física, DVD ou Blu-ray, o tamanho do vídeo é fixo e o codec é confrontado com a tarefa de garantir a máxima qualidade para um determinado tamanho. Se o vídeo for distribuído pela rede, a tarefa do codec é preparar esses arquivos para obter a máxima qualidade com uma largura de canal fixa ou a largura mínima de canal com uma qualidade fixa, se você precisar reduzir o preço. Nesse caso, os atrasos na rede podem ser ignorados e armazenados em buffer no lado do cliente por quantos segundos de vídeo forem necessários. Mas para o streaming, não há necessidade específica de corrigir tamanho ou qualidade, o codec tem uma tarefa diferente: reduzir atrasos a qualquer custo.
Por fim, os fabricantes de codecs mantiveram em mente apenas um caso de uso: no computador do usuário, um e apenas um vídeo é reproduzido. Além disso, quase sempre pode ser decodificado pelas forças de um chip de vídeo. Depois, havia plataformas móveis. E, em seguida, o WebRTC, para garantir a latência mínima da qual os desenvolvedores realmente desejam usar os servidores da Unidade de Encaminhamento Seletivo.
O uso de codecs para videochamadas é tão diferente do uso tradicional na reprodução de vídeos que a comparação dos codecs "de frente" se torna inútil. Quando o VP8 e o H.264 foram comparados no início do WebRTC, uma das discussões mais quentes foi sobre configurações de codec: tornando-as "realistas" com redes não confiáveis ou "ideais" para obter a máxima qualidade de vídeo. Os defensores da “comparação limpa de codecs” argumentaram com toda a seriedade que os codecs deveriam ser comparados sem considerar a perda de pacotes, instabilidade e outros problemas de rede.
E os codecs agora?
- H.264 e VP8 são aproximadamente os mesmos em termos de proporção de qualidade de vídeo e largura de canal usada;
- O H.265 e o VP9 também se correspondem aproximadamente, mostrando em média 30% melhores resultados em comparação com os codecs da geração anterior devido a um aumento na carga do processador em 20%;
- o novo codec AV1, uma mistura explosiva de VP10, daala e thor, é melhor que os codecs da geração anterior, tanto quanto os melhores que seus antecessores.
E agora uma surpresa: todo mundo não se importa com essas diferenças quando se trata de chamadas de vídeo e videoconferência. O mais importante é como o codec é reproduzido em uma equipe com o restante da infraestrutura. Os desenvolvedores estão preocupados com o que chamamos de novo termo
mecanismo de mídia : como um navegador ou aplicativo móvel captura vídeo, codifica / decodifica, divide-o em pacotes RTP e lida com problemas de rede (lembre-se do vídeo do nosso
harast anterior ?
Artigo, para que a mídia fosse comparada lá engine - nota do tradutor). Se o codificador não puder trabalhar com uma diminuição acentuada na largura do canal ou manter de maneira estável 20 quadros por segundo, se o decodificador não puder funcionar com a perda de um pacote de rede, que diferença faz o quão bem o codec comprime o vídeo? É fácil ver por que o Google patrocina
a pesquisa de Stanford sobre a melhor interação entre codec e rede. Este é o futuro das comunicações por vídeo.
Codecs e mecanismo de mídia: tudo é complicado
As chamadas de vídeo e a videoconferência têm
quase as mesmas tarefas que a mídia convencional. Somente as prioridades são
completamente diferentes:
- São necessários 30 quadros por segundo (velocidade do codec).
- Precisa de 30 quadros por segundo com interatividade (atraso mínimo).
Também temos a Internet entre os participantes, cuja qualidade só podemos adivinhar. Geralmente é pior. Portanto:
- Você precisa experimentar pequenas alterações na largura do canal quando outro visitante chegar ao coworking.
- Você precisa, pelo menos de alguma forma, experimentar fortes mudanças na largura do canal quando esse visitante começar a baixar torrents.
- Você precisa se preocupar com o jitter (atrasos aleatórios entre pacotes recebidos, devido aos quais eles não podem apenas atrasar, mas chegar na ordem errada em que foram enviados).
- Precisa se preocupar com a perda de pacotes.
3.1 Principais tarefas do mecanismo de mídia
O que significa "precisa de 30 quadros por segundo"? Isso significa que o mecanismo de mídia possui 33 milissegundos para capturar vídeo da câmera, som do microfone, compactá-lo com um codec, dividi-lo em pacotes RTP, proteger os dados transmitidos (SRTP = RTP + AES) e enviar pela rede (UDP ou TCP , na grande maioria dos casos, UDP). Tudo isso está no lado de envio. E no lado receptor - repita na ordem inversa. Como a codificação geralmente é mais difícil do que a decodificação, o lado de envio tem mais dificuldade.
No lado técnico, a meta "30 quadros por segundo" é alcançável com atrasos. E quanto maior o atraso, mais fácil é atingir o objetivo: se você codificar no lado do envio não vários quadros ao mesmo tempo, mas vários ao mesmo tempo, poderá economizar significativamente na largura do canal (os codecs compactam melhor vários quadros analisando as alterações entre todos eles, e não apenas entre atual e anterior). Ao mesmo tempo, o atraso entre o recebimento do fluxo de vídeo da câmera e o envio pela rede aumenta proporcionalmente ao número de quadros em buffer, mais a compactação se torna mais lenta devido a cálculos adicionais. Muitos sites usam esse truque, declarando o tempo de resposta entre o envio e o recebimento de pacotes de rede entre os participantes nas vídeo chamadas. O atraso na codificação e decodificação, eles são silenciosos.
Para fazer com que as chamadas de vídeo pareçam comunicação pessoal, os criadores dos serviços de comunicação recusam todas as configurações e perfis de codec que podem criar atrasos. Acontece uma degradação dos codecs modernos na compactação quadro a quadro. A princípio, tal situação provocou rejeição e críticas dos desenvolvedores de codec. Mas os tempos mudaram e agora os codecs modernos, além das predefinições tradicionais "tamanho mínimo" e "qualidade máxima", adicionaram um conjunto de configurações "tempo real". E, ao mesmo tempo, o “compartilhamento de tela” também é para chamadas de vídeo (ele tem suas próprias especificidades - resolução grande, imagem ligeiramente alterada, necessidade de compactação sem perdas, caso contrário, o texto flutuará).
3.2 Mecanismo de mídia e redes públicas
Pequenas alterações na largura do canal
Anteriormente, os codecs não podiam alterar a taxa de bits: no início da compactação, tomavam a taxa de bits de destino como uma configuração e emitiam um número fixo de megabytes de vídeo por minuto. Naquela época, as videochamadas e as videoconferências eram muitas redes locais e largura de banda redundante. E em caso de problemas, o nome do administrador foi chamado, que corrigiu a reserva da largura do canal em tsiska.
A primeira mudança evolutiva foi a tecnologia da "taxa de bits adaptável". O codec possui muitas configurações que afetam a taxa de bits: resolução de vídeo, uma ligeira diminuição nos quadros de 30 a 25 quadros por segundo, quantização do sinal de vídeo. O último desta lista é o “engrossamento” da transição entre cores, cujas pequenas alterações dificilmente são visíveis ao olho humano. Mais frequentemente, o principal "ajuste" da taxa de bits adaptativa era a quantização precisa. E o mecanismo de mídia disse ao codec sobre a largura do canal.
Grandes mudanças na largura do canal
O mecanismo de taxa de bits adaptável ajuda o mecanismo de mídia a continuar transmitindo vídeo com pequenas alterações na largura do canal. Mas se o seu colega começou a baixar torrents e o canal disponível caiu duas ou três vezes, a taxa de bits adaptável não ajudará. Diminuir a resolução e a taxa de quadros ajudará. O último é preferível, já que nossos olhos são menos sensíveis ao número de quadros por segundo do que à resolução do vídeo. Normalmente, o codec começa a pular um ou dois quadros, reduzindo a taxa de quadros de 30 para 15 ou mesmo para 10.
Detalhe importante: o mecanismo de mídia pulará os quadros no lado de envio. Se tivermos uma videoconferência para vários participantes ou transmissão e o remetente não tiver um problema de rede, um "link fraco" piorará a qualidade do vídeo para todos os participantes. Nesta situação, um monte de simulcast ajuda (o lado que envia imediatamente envia vários fluxos de vídeo de qualidade diferente) e SFU (Selective Forwarding Unit, o servidor oferece a cada participante uma videoconferência ou transmite um fluxo da qualidade desejada). Alguns codecs têm a capacidade de criar vários fluxos de simulcast, SVCs que se complementam: clientes com o canal mais fraco recebem um fluxo de qualidade mínima, clientes com um canal melhor recebem o mesmo fluxo mais a primeira "atualização", clientes com um canal ainda melhor já dois fluxos de "atualização" e assim por diante. Esse método permite que você não transfira os mesmos dados para vários fluxos e economiza cerca de 20% do tráfego em comparação com a codificação de vários fluxos de vídeo completos. Também simplifica a operação do servidor - não há necessidade de alternar fluxos, é suficiente para não transferir pacotes com uma "atualização" para os clientes. No entanto, qualquer codec pode ser usado para transmissão simultânea, é um recurso do mecanismo de mídia e da organização de pacotes RTP, não um codec.
Perda de instabilidade e pacote
As perdas são as mais difíceis de lidar. O jitter é um pouco mais simples - basta fazer um buffer no lado receptor para coletar pacotes atrasados e confusos. Um buffer não muito grande; caso contrário, você pode interromper o tempo real e se tornar um vídeo do YouTube com buffer.
A perda de pacotes geralmente é combatida com reencaminhamento (RTX). Se o remetente tiver uma boa comunicação com o SFU, o servidor poderá solicitar um pacote perdido, recuperá-lo e ainda atender 33 milissegundos. Se a conexão de rede não é confiável (mais de 0,01% de perda de pacotes), precisamos de algoritmos complexos de trabalho com perdas, como o
FEC .
A melhor solução até agora é usar codecs SVC. Nesse caso, para receber pelo menos alguns vídeos, são necessários apenas pacotes de "referência" com um fluxo de qualidade mínima, esses pacotes são menos, portanto, é mais fácil reenviá-los, isso é suficiente para "sobreviver" mesmo com uma rede muito ruim (perda de pacotes superior a 1%). Se o Simulcast + SFU permitir que você lide com subsidência de canal, o Simulcast com a ajuda do codec SVC + SFU resolve os problemas de largura e perda de pacotes do canal.
Quais navegadores agora suportam
O Firefox e o Safari usam o Media Engine do Google e atualizam a libwebrtc periodicamente. Eles fazem isso com muito menos frequência do que o Chrome, cuja nova versão é lançada a cada 6 semanas. De tempos em tempos, eles começam a ficar para trás, mas depois são sincronizados novamente. Com exceção do suporte ao codec VP8 no Safari. Nem pergunte.
Antes do kat, uma tabela com uma comparação completa de quem suporta o quê, mas, em geral, tudo é bastante simples. O Edge geralmente é ignorado por todos. A escolha é entre oferecer suporte à versão móvel do Safari e boa qualidade de vídeo. O iOS Safari suporta apenas o codec de vídeo H.264, enquanto o libwebrtc permite apenas a transmissão simultânea com codecs VP8 (fluxos diferentes com taxas de quadros diferentes) e VP9 (suporte SVC). Mas você pode ler e usar a libwebrtc no iOS criando um aplicativo nativo. Então, com o simulcast, tudo ficará bem e os usuários receberão a mais alta qualidade de vídeo possível com uma conexão instável à Internet. Alguns exemplos:
- Highfive - um aplicativo de desktop em Electron (Chromium) com simulcast H.264 (libwebrtc) e codecs de som da Dolby;
- Attlasian - Uma solução interessante do cliente no React Native e na libwebrtc para simulcast;
- Symphony - Electron para desktop, React Native para dispositivos móveis e simulcast são suportados ali e ali + recursos de segurança adicionais compatíveis com o que os bancos desejam;
- Tokbox - VP8 com simulcast no SDK móvel, use a versão corrigida do libvpx no libwebrtc.
O futuro
Já está claro que não haverá VP8 e VP9 no Safari (ao contrário do Edge, que o VP8 suporta).
Embora a Apple tenha apoiado a inclusão do H.265 no WebRTC, notícias recentes e vários sinais indiretos apontam para o AV1 como a “próxima grande novidade”. Ao contrário do restante do artigo, esta é minha opinião pessoal. As especificações para transmissão de dados AV1 já estão prontas, mas o trabalho ainda está em andamento no codec. Agora, a implementação de referência do codificador mostra tristes 0,3 quadros por segundo. Isso não é um problema ao reproduzir conteúdo pré-compactado, mas ainda não é aplicável ao Realtime Communications. Enquanto isso, você pode
tentar reproduzir vídeos AV1 no Firefox, embora isso não esteja relacionado ao RTC. Implementação da equipe bitmovin, que desenvolveu o MPEG-DASH e recebeu 30 milhões de investimentos na criação da infraestrutura de próxima geração para trabalhar com vídeo.