Enquanto os primeiros adotantes experimentam nossas novas videoconferências (até 100 pessoas!) Em seus projetos, continuamos a falar sobre coisas interessantes do mundo da transmissão de voz e vídeo com um navegador. Também falaremos sobre videoconferência, mas mais tarde - quando uma massa crítica de usuários acumular e estatísticas interessantes forem coletadas. E agora eu traduzi e adaptei para nós a história do Dr. Alex sobre o local de diferentes protocolos ao transmitir vídeo com baixa latência. A história é essencialmente uma resposta a outro artigo, e o autor, juntamente com a história, aponta os erros e imprecisões que seus colegas no workshop fizeram.
Dados de rede: alarme separadamente, vídeo separadamente
Nos sistemas modernos, se você vê o vídeo em um navegador, o fluxo e o alarme do vídeo provavelmente serão processados por diferentes servidores. Se tudo estiver claro no vídeo, o "servidor de alarme" oferece duas coisas: "descoberta" e "aperto de mão". A primeira, “descoberta”, é a escolha do método de transferência de dados: endereços IP, um servidor intermediário (se necessário). “Handshake” - sobre negociações entre participantes na transmissão de vídeo e som: codecs, resolução, taxa de quadros, qualidade. Curiosamente, no Flash antigo, a sinalização e a transmissão de mídia não eram separadas como no VoxIP ou WebRTC e eram fornecidas por um protocolo: RTMP.
A diferença entre o protocolo de sinalização e o transporte de sinalização
O protocolo de sinalização define o idioma com o qual o navegador e outros participantes da transmissão de vídeo concordarão com a descoberta e o handshake. Pode ser SIP para descoberta em VoIP ou WebRTC, e é com oferta / resposta para handshake. Há muito tempo, o Flash usava
RTMP / AMF . E, se desejado, para o WebRTC, você pode usar não o SIP, mas o JSEP incomum.
O protocolo de transporte de sinalização da mesma pilha, mas mais baixo: é assim que os pacotes do protocolo de sinalização serão fisicamente transmitidos. Tradicionalmente, para Flash + SIP, TCP ou UDP era usado, mas agora no pacote WebRTC + SIP, os WebSockets são cada vez mais encontrados. O protocolo de transporte WebSockets ocupa o nicho TCP em navegadores onde você não pode usar soquetes TCP e UDP "puros".
Uma pilha de sinalização completa agora é descrita popularmente com frases como "SIP na parte superior dos soquetes da Web", "JSEP na parte superior dos soquetes da Web", obsoleto "SIP na parte superior do TCP / UDP" ou a antiga "parte do RTMP".
Programador Anglicism: Media Codec
A maioria dos protocolos de transmissão de vídeo está vinculada a um ou mais codecs. O vídeo recebido da câmera é processado quadro a quadro. E problemas de rede, como largura de banda reduzida, perda de pacotes ou atraso entre eles, são resolvidos pelas configurações de codec para cada quadro. Para aprender sobre problemas de rede com o tempo, usamos mecanismos de protocolo de transporte (RTP / RTCP) e mecanismos de estimativa de largura de banda (REMB, Transport-CC, TIMBR). Um dos problemas fundamentais do vídeo em Flash era que o RTMP também não podia fazer isso, então o vídeo simplesmente parou de ser reproduzido quando a largura de banda do canal caiu.
Outro anglicismo: Protocolo de Streaming de Mídia
Determina como dividir o fluxo de vídeo em pequenos pacotes enviados pela rede pelo protocolo de transporte. Normalmente, o protocolo de streaming ainda fornece mecanismos para lidar com problemas de rede: perda e atraso de pacotes. Buffer de instabilidade, retransmissão (RTC), redundância (RED) e correção de erro de encaminhamento (FEC).
Protocolo de transferência de mídia
Depois que o vídeo recebido da câmera é dividido em pequenos pacotes, eles devem ser transmitidos pela rede. O protocolo de transporte usado para isso é semelhante ao de sinalização, mas como a “carga útil” é completamente diferente, alguns protocolos são melhores que outros. Por exemplo, o TCP fornece acessibilidade de pacotes, mas não agrega valor à pilha, porque mecanismos semelhantes (RTX / RED / FEC) já estão no protocolo de streaming. Mas os atrasos no reenvio para o TCP são uma falha clara que o UDP não possui. Mas existe a prática de bloquear o UDP como um "protocolo para torrents".
A escolha do protocolo e das portas de rede foi decidida anteriormente por "codificação", mas agora usamos protocolos como o ICE no WebRTC, o que nos permite concordar com portas e transporte em cada conexão específica. Num futuro próximo, é possível usar o protocolo QUIC (compatível com o UDP), que é discutido ativamente pela IETF e possui vantagens sobre o TCP e o UDP em velocidade e confiabilidade. Por fim, podemos mencionar protocolos de streaming de mídia como MPEG-DASH e HLS, que usam HTTP como transporte e se beneficiarão da introdução do HTTP / 2.0.
Segurança de transmissão de mídia
Alguns mecanismos protegem os dados durante a transmissão pela rede: o próprio fluxo de mídia ou os pacotes da camada de transporte. O processo inclui a própria transferência de chaves de criptografia, para a qual protocolos separados são usados: SDES em VoIP e DTLS em WebRTC. O último tem uma vantagem, pois além de dados, também protege a transmissão de chaves de criptografia.
O que me incomoda sobre tudo isso
Alguns desenvolvedores, como os autores
deste artigo , colocam os protocolos puramente WebSocket e QUIC no mesmo nível que WebRTC, Flash ou HLS. Para mim, esse agrupamento parece estranho, porque os três últimos protocolos são uma história sobre streaming de mídia. Codificação e pacote ocorrem antes de usar o WebSocket ou QUIC. A implementação WebRTC de referência do Google (libwebrtc / chrome) e o ORTC da Microsoft usam QUIC como o protocolo de transporte.
Igualmente surpreendente é a falta de menção do HTTP / 2.0 como uma otimização para protocolos baseados em HTTP, como HLS e MPEG-DASH. E o CMAF mencionado nada mais é do que um formato de arquivo para HLS e MPEG-DASH, mas não é a substituição deles.
Finalmente, o SRT é apenas um protocolo de transporte. Ele, é claro, adiciona vários chips em comparação com os baseados em arquivos HLS e MPEG-DASH, mas todos esses chips já estão em um nível de pilha diferente e são implementados em RTMP ou WebRTC. O SRT também compartilha a codificação do fluxo de mídia e das estatísticas, o que não permite que o codec mantenha essas informações o mais próximo possível umas das outras. Essa decisão pode afetar adversamente a capacidade de adaptar o vídeo transferido à alteração da largura de banda da rede.
Protocolos baseados em arquivo, como o HLS, codificam vários fluxos e selecionam os necessários para se adaptar à largura do canal. O WebRTC permite adaptar a codificação de cada quadro em tempo real: é muito mais rápido que selecionar outro fluxo no HLS, o que requer a contagem de até 10 segundos dos dados já enviados.