Alice é uma desenvolvedora experiente de pilha cheia, capaz de escrever uma estrutura de projeto SAAS em sua estrutura favorita usando php em uma semana. Quanto ao frontend, ela prefere Vue.js.
Um cliente entra em contato com você pelo Telegram, solicitando que você desenvolva um site que será o local de reunião para o empregador e o funcionário realizarem uma entrevista pessoal. Pessoalmente, pessoalmente, um contato de vídeo direto em tempo real com vídeo e voz. “Por que não usar o Skype?” Alguns podem perguntar. Acontece que projetos sérios - e cada startup, sem dúvida, se considera um projeto sério - estão tentando oferecer um serviço de comunicação interno por vários motivos, incluindo:
1) Eles não desejam emprestar seus usuários a comunicadores de terceiros (Skype, Hangouts etc.) e desejam mantê-los no serviço.
2) O desejo de monitorar suas comunicações, como histórico de chamadas e resultados de entrevistas.
3) Gravar chamadas (naturalmente, notificando ambas as partes sobre a gravação).
4) Eles não querem depender de políticas e atualizações de serviços de terceiros. Todo mundo conhece essa história: o Skype foi atualizado e tudo se transforma em fumaça ...
Parece uma tarefa fácil. O WebRTC aparece ao pesquisar sobre o tópico e parece que você pode organizar uma conexão ponto a ponto entre dois navegadores, mas ainda há algumas perguntas:
1) Onde obter servidores STUN / TURN?
2) Podemos ficar sem eles?
3) Como gravar uma chamada WebRTC ponto a ponto?
4) O que acontecerá se precisarmos adicionar um terceiro à chamada, por exemplo, um gerente de RH ou outro especialista do empregador?
Acontece que o WebRTC e o ponto a ponto não são suficientes e não está claro o que fazer com tudo isso para iniciar as funções de vídeo necessárias do serviço.
Conteúdo do artigo
Servidor e API
Para fechar essas lacunas, são utilizadas soluções de servidor e arquitetura peer-server-peer. O Web Call Server 5.2 (doravante - WCS) é uma das soluções de servidor; é uma plataforma de desenvolvimento que permite adicionar essas funções de vídeo ao projeto e não se preocupar com a estabilidade da conexão STUN / TURN e da conexão ponto a ponto.
No nível mais alto, o WCS é uma parte da API + do servidor JavaScript. A API é usada para desenvolvimento usando JavaScript regular no lado do navegador e o servidor processa o tráfego de vídeo, atuando como um Proxy com Estado para o tráfego de mídia.
Além da API JavaScript, há também o Android SDK e o iOS SDK, necessários para desenvolver aplicativos móveis nativos para iOS e Android, respectivamente.
Por exemplo, a publicação de um fluxo no servidor (streaming de uma webcam para o servidor) se parece com o seguinte:
SDK da Web
session.createStream({name:”stream123”}).publish();
Android SDK
publishStream = session.createStream(streamOptions) publishStream.publish();
SDK para iOS
FPWCSApi2Stream *stream = [session createStream:options error:&error]; if(![stream publish:&error]) { //published without errors }
Como resultado, podemos implementar não apenas um aplicativo da Web, mas também ups de pleno direito para o Google Play e a App Store com suporte a streaming de vídeo. Se adicionarmos o SDK móvel à imagem de nível superior, obteremos o seguinte:
Fluxos de entrada
O servidor de streaming, que é o WCS, começa com os fluxos de entrada. Para distribuir algo, precisamos tê-lo. Para distribuir fluxos de vídeo para os visualizadores, é necessário que eles entrem no servidor, passem pela RAM e saiam pela placa de rede. Portanto, a primeira pergunta que precisamos fazer ao nos familiarizarmos com o servidor de mídia é quais protocolos e formatos o último usa para aceitar fluxos. No caso do WCS, estas são as seguintes tecnologias: WebRTC, RTMP, RTSP, VOD, SIP / RTP.
Cada um dos protocolos pode ser usado por diversos clientes. Por exemplo, não apenas o fluxo do navegador pode entrar via WebRTC, mas também de outro servidor. Na tabela abaixo, existem as possíveis fontes de tráfego de entrada.
Se analisarmos as fontes de tráfego de entrada, podemos adicionar o seguinte:
WebRTC de entrada
O Web SDK permite não apenas capturar a câmera e o microfone, mas também usar os recursos da API do navegador para acessar a tela por meio do compartilhamento de tela. Além disso, podemos capturar um elemento Canvas arbitrário, e tudo o que é desenhado para transmissão subsequente é o streaming de tela:
Devido às especificidades do celular, o Android SDK e o iOS SDK podem alternar entre as câmeras frontal e traseira do dispositivo em movimento. Isso nos permite alternar a fonte durante a transmissão sem precisar interromper a transmissão.
O fluxo WebRTC de entrada também pode ser obtido de outro servidor WCS usando os métodos push, pull e CDN, que serão discutidos posteriormente.
Rtmp recebido
O protocolo RTMP é amplamente usado no OBS favorito dos streamers, bem como em outros codificadores: Wirecast, Adobe Media Encoder, ffmpeg, etc. Usando um desses codificadores, podemos capturar o fluxo e enviá-lo ao servidor.
Também podemos pegar um fluxo RTMP de outro servidor de mídia ou servidor WCS usando os métodos push e pull. No caso de envio, o iniciador é o servidor remoto. No caso de pull, recorremos ao servidor local para extrair o fluxo do remoto.
Rtsp recebido
As fontes de tráfego RTSP são geralmente câmeras IP ou servidores de mídia de terceiros que suportam o protocolo RTSP. Apesar do fato de que, ao iniciar uma conexão RTSP, o iniciador é o WCS, o tráfego de áudio e vídeo na direção da câmera IP se move em direção ao servidor WCS. Portanto, consideramos o fluxo da câmera recebido.
Vod recebido
À primeira vista, pode parecer que a função VOD (Video On Demand) esteja exclusivamente associada a fluxos de saída e à reprodução de arquivos pelos navegadores. Mas no nosso caso, isso não é inteiramente verdade. O WCS transmite um arquivo mp4 do sistema de arquivos para o host local; como resultado, um fluxo de entrada é criado, como se fosse de uma fonte de terceiros. Além disso, se restringirmos um visualizador a um arquivo mp4, obtemos o VOD clássico, onde o visualizador obtém o fluxo e o reproduz desde o início. Se não restringirmos um visualizador a um arquivo mp4, obtemos o VOD LIVE - uma variação do VOD, na qual os espectadores podem reproduzir o mesmo arquivo que um fluxo, conectando-se ao ponto de reprodução no qual todos os outros estão atualmente localizados (pré- modo de transmissão de televisão gravada).
SIP / RTP de entrada
Para receber o tráfego RTP de entrada em uma sessão SIP, precisamos configurar uma chamada com um gateway SIP de terceiros. Se a conexão for estabelecida com sucesso, o tráfego de áudio e / ou vídeo passará do gateway SIP, que será envolvido no fluxo de entrada no lado do WCS.
Fluxos de saída
Depois de receber o fluxo no servidor, podemos replicar o fluxo recebido para um ou vários espectadores, mediante solicitação. O visualizador solicita um fluxo do player ou outro dispositivo. Esses fluxos são chamados de fluxos de saída ou de "visualizador", porque as sessões desses fluxos são sempre iniciadas no lado do visualizador / reprodutor. O conjunto de tecnologias de reprodução inclui os seguintes protocolos / formatos: WebRTC, RTMP, RTSP, MSE e HLS.
WebRTC de saída
Nesse caso, o Web SDK, o Android SDK e o iOS SDK atuam como a API do player. Um exemplo de reprodução de fluxo WebRTC é semelhante a este:
SDK da Web
session.createStream({name:”stream123”}).play();
Android SDK
playStream = session.createStream(streamOptions); playStream.play();
SDK para iOS
FPWCSApi2Stream *stream = [session createStream:options error:nil]; if(![stream play:&error]) { //published without errors }
Isso é muito semelhante à API de publicação, com a única diferença: em vez de stream.publish (), stream.play () é chamado para reprodução.
Um servidor WCS de terceiros pode ser o reprodutor, que será instruído a captar o fluxo via WebRTC de outro servidor usando o método pull ou captar o fluxo dentro da CDN.
Rtmp de saída
Aqui haverá principalmente players de RTMP - o conhecido Flash Player e aplicativos de desktop e móveis que usam o protocolo RTMP, recebem e reproduzem um fluxo RTMP. Apesar do fato de o Flash ter deixado o navegador, ele manteve o protocolo RTMP, amplamente usado para transmissões de vídeo, e a falta de suporte nativo nos navegadores não impede o uso desse protocolo com êxito em outros aplicativos clientes. Sabe-se que o RTMP é amplamente usado em players de RV para aplicativos móveis no Android e iOS.
Rtsp de saída
O servidor WCS pode atuar como um servidor RTSP e distribuir o fluxo recebido via RTSP como uma câmera IP comum. Nesse caso, o aparelho deve estabelecer uma conexão RTSP com o servidor e pegar o fluxo para reprodução, como se fosse uma câmera IP.
Mse de saída
Nesse caso, o player solicita um fluxo do servidor usando o protocolo Websocket. O servidor distribui dados de áudio e vídeo por soquetes da web. Os dados chegam ao navegador e são convertidos em partes que o navegador pode reproduzir, graças à extensão MSE nativa suportada imediatamente. O player finalmente trabalha com base no elemento de vídeo HTML5.
Hls de saída
Aqui, o WCS atua como um servidor HLS ou servidor Web que suporta HLS (HTTP Live Streaming). Depois que o fluxo recebido aparece no servidor, é gerada uma lista de reprodução .m3u8 HLS, que é fornecida ao player em resposta a uma solicitação HTTP. A lista de reprodução descreve quais segmentos de vídeo o player deve baixar e exibir. O player baixa segmentos de vídeo e o reproduz na página do navegador, no dispositivo móvel, na área de trabalho, no decodificador da Apple TV e onde quer que o suporte a HLS seja reivindicado.
Entrada e saída
No total, temos 5 tipos de fluxo de entrada e saída. Eles estão listados na tabela:
Ou seja, podemos enviar os fluxos para o servidor, conectar-se a eles e reproduzi-los com jogadores adequados. Para reproduzir um fluxo WebRTC, use o Web SDK. Para reproduzir um fluxo WebRTC como HLS, use um player HLS etc. Um fluxo pode ser reproduzido por muitos espectadores. As transmissões de um para muitos funcionam.
Agora, vamos descrever quais ações podem ser executadas com fluxos.
Manipulação de fluxo de entrada
Fluxos de saída com espectadores não são facilmente manipulados. De fato, se o visualizador estabeleceu uma sessão com o servidor e já está recebendo algum tipo de fluxo, não há como fazer alterações nela sem interromper a sessão. Por esse motivo, todas as manipulações e alterações ocorrem nos fluxos de entrada, no ponto em que sua replicação ainda não ocorreu. O fluxo que sofreu alterações é distribuído a todos os visualizadores conectados.
As operações de fluxo incluem:
- gravação
- tirar uma foto
- adicionando um fluxo ao mixer
- transcodificação de fluxo
- adicionando uma marca d'água
- adicionando um filtro FPS
- rotação da imagem em 90, 180, 270 graus
Gravação de fluxo de entrada
Talvez a função mais compreensível e frequentemente encontrada. De fato, em muitos casos, os fluxos exigem gravação: seminários on-line, aulas de inglês, consultas etc.
A gravação pode ser iniciada com o Web SDK ou a API REST com uma solicitação especial:
/stream/startRecording {}
O resultado é salvo no sistema de arquivos como um arquivo mp4.
Tirando um instantâneo
Uma tarefa igualmente comum é tirar fotos do fluxo atual para exibir ícones no site. Por exemplo, temos 50 fluxos em um sistema de vigilância por vídeo, cada um com uma câmera IP como fonte. A exibição de todos os 50 threads em uma página não é apenas problemática para os recursos do navegador, mas também é inútil. No caso de 30 FPS, o FPS total da imagem alterada será 1500 e o olho humano simplesmente não aceitará essa frequência de exibição. Como solução, podemos configurar o fatiamento automático ou a captura de instantâneos sob demanda; nesse caso, imagens com uma frequência arbitrária podem ser exibidas no site, por exemplo, 1 quadro em 10 segundos. Os instantâneos podem ser removidos do SDK por meio da API REST ou fatiados automaticamente.
O servidor WCS apoia o método REST para receber instantâneos:
/stream/snapshot
Adicionando um fluxo ao mixer
Uma imagem de duas ou mais fontes pode ser combinada em uma para exibição para os espectadores finais. Este procedimento é chamado de mistura. Exemplos básicos: 1) Vigilância por vídeo de várias câmeras na tela em uma imagem. 2) Videoconferência, em que cada usuário recebe um fluxo, no qual os demais são misturados, para economizar recursos. O mixer é controlado por meio da API REST e possui um modo de operação MCU para criar videoconferências.
Comando REST para adicionar um fluxo ao misturador:
/mixer/startup
Transcodificação de fluxo
Às vezes, os fluxos precisam ser compactados para se adaptar a determinados grupos de dispositivos clientes por resolução e taxa de bits. Para isso, a transcodificação é usada. A transcodificação pode ser ativada no lado do SDK da Web, por meio da API REST ou automaticamente por meio de um nó de transcodificação especial na CDN. Por exemplo, um vídeo de 1280x720 pode ser transcodificado para 640x360 para distribuição aos clientes de uma região geográfica com uma largura de banda tradicionalmente baixa. Onde estão seus satélites, Elon Musk?
Método REST usado:
/transcoder/startup
Adicionando uma marca d'água
Sabe-se que qualquer conteúdo pode ser roubado e transformado em WebRip, independentemente da proteção do player. Se o seu conteúdo for valioso, você poderá incorporar uma marca d'água ou um logotipo que dificultarão muito o uso posterior e a exibição pública. Para adicionar uma marca d'água, basta fazer o upload de uma imagem PNG, que será inserida no fluxo de vídeo por transcodificação. Portanto, você precisará preparar alguns núcleos da CPU no lado do servidor, caso ainda decida adicionar uma marca d'água ao fluxo. Para não criar a marca d'água no servidor por transcodificação, é melhor adicioná-la diretamente no codificador / serpentina, que geralmente oferece essa oportunidade.
Adicionando um filtro FPS
Em alguns casos, é necessário que o fluxo tenha um FPS uniforme (quadros por segundo). Isso pode ser útil se transmitirmos novamente o fluxo para um recurso de terceiros como o Youtube ou o Facebook ou o reproduzirmos com um player HLS sensível. A filtragem também requer transcodificação, portanto, avalie adequadamente a potência do seu servidor e prepare 2 núcleos por fluxo, se essa operação estiver planejada.
Rotação da imagem em 90, 180, 270 graus
Os dispositivos móveis podem alterar a resolução do fluxo publicado, dependendo do ângulo de rotação. Por exemplo, você começou a transmitir, segurando o iPhone horizontalmente e depois o girou. De acordo com a especificação WebRTC, o navegador de streamer do dispositivo móvel (neste caso, o iOS Safari) deve sinalizar a rotação para o servidor. Por sua vez, o servidor deve enviar este evento a todos os assinantes. Caso contrário, seria assim - a serpentina colocou o telefone de lado, mas ainda vê a câmera na vertical, enquanto os espectadores veem uma imagem girada. Para trabalhar com rotações no lado do SDK, a extensão cvoExtension correspondente está incluída.
Gerenciamento de fluxos de entrada
Automático - a configuração geralmente é definida no lado do servidor nas configurações.
Retransmissão de fluxo
A retransmissão também é uma opção para manipular fluxos que entram no servidor; consiste em forçar o fluxo para um servidor de terceiros. Retransmitir é sinônimo de palavras como republicar, empurrar, injetar.
A retransmissão pode ser implementada usando um dos seguintes protocolos: WebRTC, RTMP, SIP / RTP. A tabela mostra a direção na qual o fluxo pode ser retransmitido.
Retransmissão do WebRTC
Um fluxo pode ser retransmitido para outro servidor WCS se, por algum motivo, for necessário disponibilizar o fluxo em outro servidor. A retransmissão é feita através do método via / push da API REST. Após o recebimento de uma solicitação REST, o WCS se conecta ao servidor especificado e publica um fluxo servidor-servidor. Depois disso, o fluxo fica disponível para reprodução em outra máquina.
/pull/push
- usou o método REST
Retransmissão RTMP
Como na retransmissão do WebRTC, a retransmissão RTMP para outro servidor também é possível. A diferença estará apenas no protocolo do relé. A retransmissão RTMP também é realizada via / push e permite transferir o fluxo para servidores RTMP de terceiros e para serviços que suportam o RTMP Ingest: Youtube, streaming no Facebook, etc. Assim, o fluxo WebRTC pode ser retransmitido para RTMP. Também podemos retransmitir qualquer outro fluxo que entra no servidor, por exemplo, RTSP ou VOD, para RTMP.
O fluxo de vídeo é retransmitido para outro servidor RTMP usando chamadas REST.
/push/startup
- chamada REST usada
Retransmissão SIP / RTP
É raramente usada função. Na maioria das vezes, é usado na empresa. Por exemplo, quando precisamos estabelecer uma chamada SIP com um servidor de conferência SIP externo e redirecionar o fluxo de áudio ou vídeo para esta chamada, para que o público da conferência veja algum tipo de conteúdo de vídeo: “Assista a este vídeo” ou “Colegas , agora vamos assistir a um fluxo de câmera IP do canteiro de obras ”. Precisamos ter em mente que, neste caso, a própria conferência existe e é gerenciada em um servidor VKS externo com suporte a SIP (recentemente testamos a solução do Polycom DMA), enquanto apenas conectamos e retransmitimos o fluxo existente para este servidor. A função API REST é chamada / injetar e serve apenas para este caso.
Comando da API REST:
/call/inject_stream/startup
Conectando servidores a uma rede de processamento de conteúdo CDN
Normalmente, um servidor possui uma quantidade limitada de recursos. Portanto, para grandes transmissões on-line em que o público conta por milhares e dezenas de milhares, é necessário dimensionar. Vários servidores WCS podem ser combinados em uma rede de entrega de conteúdo CDN. Internamente, a CDN trabalha com o WebRTC para manter baixa latência durante o streaming.
O servidor pode ser configurado em uma das seguintes funções: Origem, Borda ou Transcoder. Os servidores do tipo de origem recebem tráfego e o distribuem para os servidores de Borda, responsáveis pela entrega do fluxo aos visualizadores. Se for necessário preparar um fluxo em várias resoluções, os nós do transcodificador serão incluídos no esquema, que assumem a missão de consumir recursos dos fluxos de transcodificação.
Resumir
O WCS 5.2 é um servidor para desenvolvimento de aplicativos com suporte de áudio e vídeo em tempo real para navegadores e dispositivos móveis. São fornecidas quatro APIs para desenvolvimento: Web SDK, iOS SDK, Android SDK, API REST. Podemos publicar (alimentar) fluxos de vídeo no servidor usando cinco protocolos: WebRTC, RTMP, RTSP, VOD, SIP / RTP. No servidor, podemos reproduzir fluxos com jogadores usando cinco protocolos: WebRTC, RTMP, RTSP, MSE, HLS. Os fluxos podem ser controlados e submetidos a operações como gravação, corte de instantâneos, mixagem, transcodificação, adição de marca d'água, filtro de FPS e transmissão de vídeos em dispositivos móveis. Os fluxos podem ser retransmitidos para outros servidores via protocolos WebRTC e RTMP, bem como redirecionados para conferências SIP. Os servidores podem ser combinados em uma rede de entrega de conteúdo e redimensionados para processar um número arbitrário de fluxos de vídeo.
O que Alice deve saber para trabalhar com o servidor
O desenvolvedor precisa poder usar o Linux. Os seguintes comandos na linha de comando não devem causar confusão:
tar -xvzf wcs5.2.tar.gz
cd wcs5.2
./install.sh
tail -f flashphoner.log
ps aux | grep WebCallServer
top
Também é necessário conhecer o Vanilla JavaScript quando se trata de desenvolvimento da Web.
//publishing the stream session.createStream({name:'mystream'}).publish(); //playing the stream session.createStream({name:'mystream'}).play();
A capacidade de trabalhar com o back-end também pode ser útil.
O WCS pode não apenas receber comandos de controle através da API REST, mas também enviar ganchos - ou seja, notificações sobre eventos que ocorrem nele. Por exemplo, ao tentar estabelecer uma conexão a partir de um navegador ou aplicativo móvel, o WCS acionará o gancho / connect e, ao tentar reproduzir um fluxo, acionará o gancho playStream. Portanto, o desenvolvedor precisará se concentrar um pouco no backend, capaz de criar um cliente REST simples e um servidor REST pequeno para processar ganchos.
Exemplo da API REST
/rest-api/stream/find_all
- exemplo de API REST para listar fluxos no servidor
Exemplo de gancho REST
https://myback-end.com/hook/connect
- Gancho REST / processamento de conexão no lado de back-end.
Linux, JavaScript, Cliente / Servidor REST - três elementos suficientes para desenvolver um serviço de produção na plataforma WCS, trabalhando com fluxos de vídeo.
O desenvolvimento de aplicativos móveis exigirá conhecimento de Java e Objective-C para Android e iOS, respectivamente.
Instalação e lançamento
Hoje existem três maneiras de lançar rapidamente o WCS:
1) Instale o Ubuntu 16.x LTS ou Ubuntu 18.x LTS etc. no seu Centos7. ou ser guiado pelo artigo da documentação .
ou
2) Obtenha imagens prontas no Amazon EC2 .
ou
3) Obtenha uma imagem pronta para o servidor no Digital Ocean .
E inicie um empolgante desenvolvimento de projeto com recursos de streaming de vídeo.
O artigo de revisão acabou sendo bastante grande. Obrigado pela paciência de lê-lo.
Tenha um bom streaming!
Ligações
WCS 5.2 - servidor de WebRTC
Instalação e lançamento
Instalação e lançamento do WCS
Iniciar imagem pronta no Amazon EC2
Iniciar imagem pronta para servidor no DigitalOcean
SDK
SDK da Web da documentação
Documentação Android SDK
Documentação iOS SDK
Estojos
Fluxos de entrada
Fluxos de saída
Gerenciamento de fluxos
Retransmissão de fluxo
CDN para streaming WebRTC de baixa latência
Documentação
Documentação Web Call Server 5.2