Protocolo de transmissão ao vivo de comunicação e desenvolvimento de áudio e vídeo e streaming de vídeo 丨 RTMP-RTSP

Nos últimos anos, a transmissão ao vivo se tornou um tópico importante na indústria da Internet. Resposta ao vivo, jogos ao vivo, competição ao vivo, transmissão ao vivo em Douyin e educação ao vivo surgiram uma após a outra. A transmissão ao vivo sempre foi uma tecnologia familiar. Na verdade, o aumento da transmissão ao vivo não está apenas relacionado ao desejo das pessoas de falar por si mesmas na nova era, mas também se beneficia da aceleração da largura de banda e do desenvolvimento da tecnologia CDN. Com a maturidade da tecnologia CDN, está se tornando mais fácil para as empresas implantar servidores em nuvem para transmissão ao vivo.

Este artigo serve como uma série de introdução à transmissão ao vivo, principalmente para falar sobre o conteúdo técnico do protocolo de transmissão ao vivo, streaming de vídeo, etc.

1. Protocolo de transmissão ao vivo (com um mapa de rota de aprendizagem anexado ao final do artigo)

A mídia de streaming é dividida em transmissão ao vivo e sob demanda. De um modo geral, a transmissão sob demanda usa o protocolo HTTP, e a transmissão ao vivo usa principalmente RTMP, HLS, HTTP-FLV, etc. Nos últimos anos, o protocolo de transmissão ao vivo também passou por novos desenvolvimentos, como o DASH, mas ainda está em sua infância. A diferença entre a transmissão ao vivo e os protocolos sob demanda está enraizada em suas diferenças de negócios.

Sob demanda, comumente usado para a reprodução de recursos de mídia como dramas de TV e filmes em sites de vídeo como Youku e iQiyi, ou seja, sob demanda é um vídeo gravado, e mil pessoas assistem ao mesmo vídeo, independentemente do dados de mídia obtidos clicando em a qualquer momento Eles são todos iguais, mas as transmissões ao vivo não. As informações que você clica e assiste são diferentes em momentos diferentes.

De um modo geral, a transmissão ao vivo e a on-demand não se misturam, mas, nos últimos anos, algumas pessoas também inovaram e desenvolveram o modo time-shift ao vivo, ou seja, a combinação da on-demand e da transmissão ao vivo. O método é gravar a transmissão ao vivo em um pequeno pedaço de arquivos sob demanda, e então os usuários podem acessar qualquer conteúdo em qualquer local e em qualquer terminal. Por exemplo, você está assistindo a uma transmissão ao vivo de um jogo de futebol e, em seguida, há uma cena maravilhosa. Se quiser assistir novamente imediatamente, você pode arrastar a barra de progresso para voltar e reproduzi-lo. Depois de assistir ao replay, você pode retornar à transmissão ao vivo com um clique.

A distribuição atual de transmissão ao vivo tem principalmente as seguintes características:

1. A maioria dos flv e ts são menores. O principal motivo é que o padrão ts é muito complicado. O documento aberto padrão de Flv tem 11 páginas e o de ts tem 174 páginas. Para transmissões ao vivo gerais, flv pode basicamente atender à demanda, portanto, há menos aplicativos ts. Claro, também podemos contar com o FFmpeg, mas ele encapsulará o que você quer e o que não consegue pensar em mídia de streaming, que não é preciso o suficiente.

2, rtmp e hls coexistem. De um modo geral, o rtmp é usado no lado do PC e o flash é usado para reprodução; o hls é usado como um telefone celular e um tablet.

3. O streaming em tempo real geralmente usa rtmp. Rtmp pode atingir um atraso de 1 a 3 segundos, que é o protocolo de atraso mais baixo em uma transmissão ao vivo, exceto para rtsp. A reprodução direta é suportada no PC e o terminal móvel pode ser decodificado e reproduzido por FFmpeg. Além do rtmp, existem outros protocolos adequados para reprodução de mídia de streaming em tempo real?

Na verdade, http-flv é mais adequado para streaming em tempo real do que rtmp. Ambos têm o mesmo atraso e podem ser transmitidos diretamente no lado do PC. O lado móvel precisa usar o ffmpeg, mas o http-flv tem a vantagem de poder penetrar nas paredes. Mas a maioria dos CDNs não oferece suporte a transmissão ao vivo de http-flv, porque os servidores da Web em geral não oferecem suporte a http-flv, o que é um problema de mídia de fluxo contínuo.

Conhecimento de conteúdo de áudio e vídeo relacionado ao desenvolvimento de materiais de aprendizagem clicando na aquisição de materiais de aprendizagem

2. Servidor Live (com um mapa de rota de aprendizagem anexado ao final do artigo)

A transmissão de dados de streaming media na transmissão ao vivo depende principalmente do servidor. Atualmente, os servidores de mídia de streaming de código aberto incluem RED5, CRTMPD, NGINX-RTMP e SRS.

RED5: O servidor de streaming de código aberto mais antigo baseado em serviços de streaming de flash. É escrito em linguagem Java, usa rtmp como protocolo de transmissão de streaming media e é totalmente compatível com FMS; tem as funções de streaming de arquivos flv e MP3, gravação de fluxos de clientes como arquivos flv em tempo real, compartilhamento de objetos, tempo real reprodução de vídeo e comunicação remota. No entanto, devido à sua tecnologia relativamente atrasada, novas plataformas de transmissão ao vivo foram abandonadas.

CRTMPD: Ele é escrito em linguagem C ++ e oferece suporte a vários protocolos rtmp, protocolos de rede relacionados a IPTV e servidores de streaming de mídia para dispositivos móveis. O uso de soquetes assíncronos de thread único estava no nível de liderança na época, mas quando o NGINX apareceu, ele gradualmente desapareceu da vista do público.

NGINX-RTMP: Baseado no módulo NGINX, um servidor de streaming de mídia escrito em linguagem C também é o servidor de streaming de mídia mais usado no mercado. Com a expansão dos negócios de CDN em 2012, a demanda por serviços de transmissão ao vivo disparou. Como o NGINX-RTMP compartilha um conjunto de servidores para transmissão ao vivo sob demanda e os usuários estão familiarizados e confiam no NGINX; o NGINX-RTMP está gradualmente se tornando um monopólio na indústria.

SRS (Simple Rtmp Sever) é um servidor doméstico de streaming media, que se posiciona como um cluster de servidores ao vivo da Internet em nível operacional, buscando melhor integridade conceitual e a implementação mais simples do código. Segundo o site oficial, sua eficiência é muito alta, podendo chegar a 3 vezes a do NGINX-RTMP, e há uma cópia de documentos em chinês e inglês, mais adequado para o ambiente de desenvolvimento de programadores nacionais.

3. Transmissão ao vivo (com um mapa da rota de aprendizagem anexado ao final do artigo)

O processo geral de transmissão ao vivo é o seguinte

Conforme mostrado na figura acima, na transmissão ao vivo, depois de coletar fontes de dados relevantes de câmeras e microfones, algum processamento de pré-encapsulamento é geralmente necessário, como remoção de ruído, embelezamento, mudança de voz, etc., e então a codificação de áudio e vídeo é realizada e, em seguida, a mídia de streaming apropriada é usada. Após o protocolo ser encapsulado, a taxa de código pode ser adaptada ao site relevante para exibição.

No entanto, os métodos de transmissão ao vivo em diferentes linguagens técnicas também são diferentes:

Se você for um programador iOS ou Android, será mais fácil fazer streaming RTMP.Você pode encontrar diretamente um banco de dados para streaming e fornecer os parâmetros de vídeo e o endereço RTMP final para iniciar um stream RTMP padrão.

Se você for um programador C ++, terá muitos problemas.Você deve pelo menos dominar as três etapas de aquisição, codificação e escrita de fluxo. Claro, essas etapas têm bibliotecas que podem ser chamadas, mas mesmo assim, supondo que você use a biblioteca FFmpeg, leva cerca de 100 linhas para completar o código de ação acima; porque o fluxo de código principal precisa incluir a abertura de equipamentos de áudio e vídeo, criando codecs, definir parâmetros de codificação, inicializar identificador de fluxo de rede, escrever cabeçalho de protocolo, coletar dados ciclicamente, decodificar dados, dados codificados, formatar encapsulamento e escrever fluxo de rede.

Claro, você pode usar diretamente a linha de comando FFmpeg para completar o fluxo de envio com um único comando, mas isso também é limitado a testes ou demonstrações simples, o que não é aplicável em um ambiente de engenharia real, porque este método de comando simples tem muitas funções Não posso suportar isso.

4. Resumo: (Anexe um mapa de rota de aprendizagem no final do artigo)

Resumindo, a dificuldade de fazer uma transmissão ao vivo está principalmente relacionada à função que você deseja alcançar. Se você planeja fazer o teste sozinho, baixe um código de servidor de código aberto, codifique e execute, em seguida, use o FFmpeg para enviar a transmissão com um linha de comando e, em seguida, use o player para reproduzi-lo. Porém, se você deseja comercializar e atender às diversas necessidades dos usuários, como supressão de eco, transmissão ao vivo com microfones e filtros de beleza, a complexidade do problema aumentará exponencialmente.

5. Mapa de rota de aprendizagem de desenvolvimento de áudio e vídeo

Desenvolvimento de áudio e vídeo de materiais de aprendizagem e roteiro de aprendizagem, se necessário, você pode clicar nos materiais de aprendizagem de áudio e vídeo em qun get

Links para materiais de aprendizagem: FFmpeg / WebRTC / RTMP áudio e vídeo streaming de mídia de desenvolvimento-aprendizagem avançada

 

Acho que você gosta

Origin blog.csdn.net/Linuxhus/article/details/115176762
Recomendado
Clasificación