Alice é uma desenvolvedora experiente de pilha cheia e é capaz de escrever uma estrutura de projeto SAAS em sua estrutura favorita usando php em uma semana. No front-end, ele prefere Vue.js.
Um telegrama está sendo bloqueado por um cliente que, por todos os meios, precisa desenvolver um site, que será o local de reunião do empregador e do funcionário para a realização de uma entrevista pessoal. Tempo integral - significa contato direto com vídeo, olho no olho, em tempo real, com vídeo e voz.
"Por que não skype?" Você pergunta. Aconteceu que projetos sérios, e toda startup, sem dúvida, se considera como tal, estão tentando oferecer um serviço de comunicação interno por vários motivos, incluindo:
1) Não dê a seus usuários comunicadores de terceiros (skype,
hangouts etc.). Deixe-os em serviço.
2) Monitorar as comunicações: histórico de chamadas, resultados da entrevista.
3) Gravar chamadas (é claro, notificar as duas partes da gravação).
4) Não dependa de políticas e atualizações de serviços de terceiros. Todo mundo conhece essa história: o Skype foi atualizado e começou ...
A tarefa parece simples. O WebRTC é o google sobre o assunto e parece que você pode organizar uma conexão ponto a ponto entre dois navegadores, mas ainda há dúvidas:
1) Onde obter servidores STUN / TURN
2) É possível fazer sem eles
3) Como gravar uma chamada WebRTC ponto a ponto
4) O que acontecerá se você precisar adicionar um terceiro à chamada, por exemplo, um gerente de RH ou outro especialista do empregador.
Acontece que apenas 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 todos esses pontos em branco, são utilizadas soluções de servidor e arquitetura peer-server-peer. O Web Call Server 5.2 WCS adicional é 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 desenvolver JavaScript normal 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, publicar um fluxo em um servidor (transmitir um fluxo 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, você pode 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 para streaming de vídeo. Adicione SDKs para dispositivos móveis à imagem de nível superior. Acontecerá assim:
Fluxos de entrada
O servidor de streaming, que é o WCS, começa com os fluxos de entrada. Para distribuir algo, você precisa. 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 seria útil ao se familiarizar com um servidor de mídia é: para quais protocolos e formatos os últimos aceitam 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, via WebRTC, não apenas um fluxo de um navegador pode entrar, mas também de outro servidor. Exibimos as possíveis fontes de tráfego de entrada na tabela.
Se você passar pelas fontes de tráfego de entrada, poderá adicionar o seguinte:
WebRTC de entrada
O Web SDK permite capturar não apenas a câmera e o microfone, mas também usar os recursos da API do navegador para acessar o compartilhamento de tela. Além disso, você pode capturar um elemento Canvas arbitrário e tudo o que é desenhado para transmissão subsequente é o streaming de tela.
O SDK do Android e o SDK do iOS devido a especificações para dispositivos móveis podem alternar entre as câmeras frontal e traseira do dispositivo em tempo real. Isso permite que você troque a fonte durante a transmissão sem interromper a transmissão.
O fluxo WebRTC de entrada também pode ser obtido de outro servidor WCS por métodos: push, pull e CDN, que serão discutidos um pouco mais tarde.
Rtmp de entrada
O protocolo RTMP é amplamente usado nos streamers OBS favoritos e em outros codificadores: Wirecast, Adobe Media Ensourcer, ffmpeg, etc. Usando um desses codificadores, você pode capturar o fluxo e enviá-lo ao servidor.
Você também pode pegar um fluxo RTMP de outro servidor de mídia ou servidor WCS em
usando métodos push e pull. No caso de envio, o iniciador é o servidor remoto. No caso de pull, passamos para o local para puxar o fluxo do remoto.
RTSP de entrada
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 associada exclusivamente a fluxos de saída e à reprodução do arquivo pelos navegadores. No nosso caso, isso está um pouco errado. O WCS honestamente converte o arquivo mp4 do sistema de arquivos para o host local, como resultado, um fluxo de entrada é criado, como se viesse de uma fonte de terceiros. Além disso, se restringirmos um visualizador a um arquivo mp4, obtemos o VOD clássico, onde o visualizador pega o fluxo e o reproduz desde o início. Se não limitado, 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 (modo de televisão de transmissão pré-gravada).
SIP / RTP de entrada
Para receber tráfego RTP de entrada em uma sessão SIP, é necessário 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, você pode replicar o fluxo recebido para um ou vários visualizadores, mediante solicitação. O visualizador solicita um fluxo do player ou outro dispositivo. Esses fluxos são chamados de saída ou "fluxos de espectadores", porque as sessões desses fluxos são sempre iniciadas no lado do espectador / jogador. O conjunto de tecnologias de reprodução inclui os seguintes protocolos / formatos: WebRTC, RTMP, RTSP, MSE, 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 que, em vez disso,
stream.publish (), stream.play () é chamado para reprodução.
Um jogador também pode ser um servidor WCS de terceiros, que será instruído a captar um fluxo via WebRTC de outro servidor usando o método pull ou a captar um 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. O fato é que, apesar de o Flash ter deixado o navegador, ele deixou o protocolo RTMP, amplamente usado para transmissões de vídeo e a falta de seu suporte nativo nos navegadores, não impede o uso desse protocolo bem-sucedido em outros aplicativos clientes. Sabe-se que o RTMP é amplamente usado em players de RV para aplicativos móveis para 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 fornece dados de áudio e vídeo em 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, uma lista de reprodução HLS é gerada no formato .m3u8, que é fornecido ao player em resposta a uma solicitação HTTP. A lista de reprodução descreve quais segmentos do 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.
Caixa de entrada e caixa de saída
No total, temos 5 de entrada e o mesmo número de tipos de fluxo de saída. Nós listamos
eles na tabela:
I.e. podemos direcionar fluxos para o servidor e conectar-nos a eles e jogar com jogadores adequados para esse assunto. Para reproduzir o fluxo WebRTC, use o Web SDK. Para reproduzir o 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 dizer quais ações podem ser executadas com fluxos.
Manipulação de fluxo de entrada
As correntes de saída nas quais os espectadores se sentam não são particularmente manipuladoras. 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 nos fluxos incluem:
- registro
- remoção de instantâneo
- adicionar stream ao mixer
- transcodificação de fluxo
- adicionar marca d'água
- adicionar filtro FPS
- rotação da imagem em 90, 180, 270 graus
Gravação de fluxo de entrada
Talvez a mais compreensível e freqüentemente encontrada das funções. De fato, os fluxos exigem gravação em muitos casos: webinar, aula de inglês, consulta 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.
Remoção de instantâneo
Uma tarefa igualmente comum é tirar fotos do fluxo atual para exibir ícones no site. Por exemplo, você tem 50 fluxos em um sistema de vigilância por vídeo, cada um com uma fonte de uma câmera IP. 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á de 1500 quadros por segundo e o olho humano simplesmente não aceitará essa frequência. Como solução, você pode configurar fatias automáticas ou capturar instantâneos sob demanda; nesse caso, você pode exibir imagens em um site com uma frequência arbitrária, por exemplo, 1 quadro em 10 segundos. Os instantâneos podem ser removidos do SDK, via API REST ou fatiados automaticamente.
O servidor WCS suporta o seguinte método REST para remover instantâneos:
/stream/snapshot
Adicionando Stream 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 para economizar recursos, no qual os demais são misturados. O mixer é controlado por meio da API REST e possui um modo de operação MCU para criar videoconferência.
Comando REST para adicionar um fluxo ao misturador:
/mixer/startup
Transcodificação de fluxo
Às vezes, é necessário espremer fluxos 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ó especial de Transcoding na CDN. Por exemplo, ao inserir um vídeo de 1280x720, ele 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 companheiros, 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 jogador. Se o seu conteúdo é realmente tão valioso, você pode incorporar uma marca d'água ou logotipo que complicará bastante o uso e a exibição pública. Para adicionar uma marca d'água, basta fazer o upload de uma imagem PNG e ela será inserida no fluxo de vídeo por meio de transcodificação. Portanto, você terá que preparar alguns núcleos de CPU no lado do servidor, caso ainda decida
adicione uma marca d'água ao fluxo. Para não distorcer a marca d'água no servidor por transcodificação, é melhor adicioná-la diretamente ao codificador / serpentina, que
muitas vezes oferecem essa oportunidade.
Adicionando filtro FPS
Em alguns casos, é necessário que o fluxo esteja com um FPS uniforme (quadros por segundo). Isso pode ser útil se retransmitirmos o fluxo para um recurso de terceiros como o Youtube ou o Facebook, ou se o reproduzirmos com um reprodutor HLS sensível. A filtragem novamente requer transcodificação; portanto, calcule a força do seu servidor e prepare-se para a configuração mais 2 núcleos por fluxo, se essa operação estiver planejada.
Gire a imagem 90, 180, 270 graus
Os dispositivos móveis podem alterar a resolução do fluxo publicado, dependendo do ângulo de rotação. Por exemplo, eles começaram a transmitir, segurando o iPhone na horizontal e depois viraram-se de lado. De acordo com a especificação WebRTC, o navegador de streamer do dispositivo móvel e, neste caso, o iOS Safari deve sinalizar uma volta para o servidor. O servidor, por sua vez, deve enviar este evento a todos os assinantes. Caso contrário, teria acontecido
para que a serpentina coloque o telefone de lado, mas veja a câmera ainda na vertical, enquanto os espectadores estão empilhados de lado. Para trabalhar com turnos no lado do SDK, a extensão cvoExtension correspondente está incluída.
Onde está o controle dos fluxos de entrada
Automático - a configuração geralmente é definida no lado do servidor em
configurações.
Relé de fluxo
A retransmissão também é uma opção para manipular fluxos que entram no servidor e consiste em forçar o fluxo a um servidor de terceiros. Um sinônimo de retransmissão é palavras como: replicação, push, injeção.
O relé pode ser implementado usando um dos seguintes protocolos: WebRTC, RTMP, SIP / RTP. A tabela mostra a direção na qual o fluxo pode ser retransmitido.
Retransmissão 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 da API REST usando o método / push. 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
- o método REST usado.
Relé 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 ingestão RTMP: Youtube, streaming no Facebook, etc. Assim, o fluxo WebRTC pode ser retransmitido para RTMP. Com o mesmo sucesso no RTMP, você pode retransmitir qualquer outro fluxo que entre no servidor, por exemplo, RTSP ou VOD.
O fluxo de vídeo é retransmitido para outro servidor RTMP usando chamadas REST
/push/startup
- chamada REST usada.
Relé SIP / RTP
Função raramente usada. Geralmente na empresa. Por exemplo, quando você precisa configurar 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 conteúdo de vídeo: “Assista a este vídeo” ou “Colegas, e agora vamos ver o fluxo com IP- câmeras do canteiro de obras. ” Você precisa entender que a conferência em si existe e é gerenciada neste caso em um servidor VKS externo com suporte a SIP (recentemente testamos a solução do Polycom DMA), basta conectar e retransmitir 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
Um servidor geralmente possui uma quantidade limitada de recursos. Portanto, para grandes transmissões on-line, onde a conta do público-alvo chega a 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, Transcoder. Servidores do tipo origem - receba o tráfego e distribua-o aos nós de borda dos 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. Você pode publicar (alimentar) fluxos de vídeo no servidor usando cinco protocolos: WebRTC, RTMP, RTSP, VOD, SIP / RTP. No servidor, você pode reproduzir fluxos com players usando cinco protocolos: WebRTC, RTMP, RTSP, MSE, HLS. Os fluxos podem ser controlados e executados neles, tais como operações: gravação, corte de instantâneos, mixagem, transcodificação, adição de marca d'água, filtro de FPS, transmissão de vídeo 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 integrados a 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. Equipes desse tipo em
A linha de comando não deve causar confusão:
tar -xvzf wcs5.2.tar.gz
cd wcs5.2
./install.sh
tail -f flashphoner.log
ps aux | grep WebCallServer
top
O Vanilla JavaScript também precisa ser capaz de desenvolver para
Web
// session.createStream({name:'mystream'}).publish(); // session.createStream({name:'mystream'}).play();
A capacidade de trabalhar com o back-end também é útil.
O WCS pode não apenas receber comandos de controle através da API REST, mas também enviar ganchos - notificações sobre os eventos que ocorrem nele.
Por exemplo, ao tentar estabelecer uma conexão a partir de um navegador ou aplicativo móvel, o WCS chamará o gancho / connect e, ao tentar reproduzir um fluxo, chamará o gancho playStream. Portanto, o desenvolvedor precisará permanecer um pouco no backend, capaz de gravar um cliente REST simples e um servidor REST pequeno para processar ganchos.
Exemplo da API REST
/rest-api/stream/find_all
- um exemplo de uma API REST para gerar uma lista de fluxos em um 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 são os três elementos que
o suficiente para desenvolver um serviço de produção na plataforma WCS que funciona
com fluxos de vídeo.
O desenvolvimento de aplicativos móveis requer 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 no seu Centos7 ou Ubuntu 16.x LTS ou Ubuntu 18.x LTS e
etc. guiado por um artigo da documentação .
ou
2) Tire a imagem final no Amazon EC2 .
ou então
3) Tire a imagem do servidor finalizada no DigitalOcean .
E inicie um empolgante desenvolvimento de projeto com recursos de streaming de vídeo.
O artigo de revisão acabou sendo bastante volumoso. Obrigado por isso.
leia paciência.
Tenha um bom streaming!
Referências
WCS 5.2 - servidor de WebRTC
Instalação e lançamento
Instale e execute o WCS
Iniciar uma imagem predefinida no Amazon AWS
DigitalOcean
SDK
Web SDK
Android SDK
iOS SDK
WebRTC CDN
Web Call Server 5.2