Configurar o Nginx no Ubuntu para transmitir vídeo HLS ao vivo

O HTTP Live Streaming (HLS) é um protocolo de vídeo streaming muito robusto implementado pela Apple Inc. O HLS usa transações HTTP que atravessam firewalls, proxies e podem ser distribuídas através de CDNs com facilidade. Portanto, essa tecnologia é capaz de atingir um público-alvo muito maior do que o RTP ou outros protocolos baseados em UDP. Atualmente, grande parte do vídeo ao vivo on-line é hospedada por sistemas caros que usam HLS, mas geralmente são caros e requerem muitos recursos do servidor. Este tutorial mostra como configurar um Ubuntu 14.04 VULTR VPS muito acessível para realizar eventos de transmissão ao vivo em HLS usando apenas software de código aberto.

O primeiro passo é ler e configurar seu servidor de acordo com o Vultr Doc " Setup Nginx-RTMP no Ubuntu 14.04 ". As instruções nesse documento eram as mais abrangentes para o estágio de configuração, no momento da redação. Eu mencionaria que você pode substituir "nginx-1.7.5" por "nginx-1.9.4" ou qualquer outra versão disponível do Nginx. A outra sugestão é compilar o Nginx com o módulo de status de stub HTTP para permitir a si mesmo a capacidade de monitorar quantos visualizadores de HLS ao vivo você tem posteriormente.

Em vez de compilar com:

./configure --with-http_ssl_module  --add-module=../nginx-rtmp-module-master

Use esta sequência no procedimento descrito no documento de pré-requisito:

./configure --with-http_ssl_module --with-http_stub_status_module --add-module=../nginx-rtmp-module-master

O exemplo neste tutorial criará fluxos "ao vivo" e "móveis" (otimizados) e usará o ffmpeg (instalado no tutorial anterior) para gerar o fluxo HLS otimizado para dispositivos móveis, com taxa de bits ajustada. O exemplo também mostrará como fazer com que o servidor grave suas transmissões ao vivo automaticamente e permita reproduzir as gravações como um serviço de reprodução de vídeo sob demanda (VOD).

Primeiro, crie as estruturas de pastas necessárias para armazenar os manifestos HLS ao vivo e móveis e os fragmentos de vídeo:

sudo mkdir /HLS
sudo mkdir /HLS/live
sudo mkdir /HLS/mobile
sudo mkdir /video_recordings
sudo chmod -R 777 /video_recordings

Provavelmente, é uma boa ideia ativar o firewall, se você ainda não o fez. Nesse caso, você deve permitir o tráfego nas portas usadas pelo Nginx e HLS. Se você deseja executar sem o firewall por enquanto, ignore a seção ufw abaixo.

sudo ufw limit ssh
sudo ufw allow 80
sudo ufw allow 1935
sudo ufw enable

O streaming HLS requer uma configuração Nginx significativamente diferente da configuração RTMP no primeiro artigo. Edite seu nginx.confarquivo para usar o seguinte, substituindo "my-ip" e "my-stream-key" por suas informações. Você pode usar o que quiser para "my-stream-key"; é apenas uma palavra que é única e útil para você. Você pode fazer backup do seu arquivo de configuração original primeiro e colar minhas informações de configuração fornecidas no editor, substituindo tudo o que estava lá:

sudo cp /usr/local/nginx/conf/nginx.conf /usr/local/nginx/conf/nginx.conf.original
sudo nano /usr/local/nginx/conf/nginx.conf

Novo nginx.conf:

worker_processes  1;
error_log  logs/error.log debug;
events {
worker_connections  1024;
}
rtmp {
server {
listen 1935;
allow play all;

#creates our "live" full-resolution HLS videostream from our incoming encoder stream and tells where to put the HLS video manifest and video fragments
application live {
allow play all;
live on;
record all;
record_path /video_recordings;
record_unique on;
hls on;
hls_nested on;
hls_path /HLS/live;
hls_fragment 10s;

#creates the downsampled or "trans-rated" mobile video stream as a 400kbps, 480x360 sized video
exec ffmpeg -i rtmp://192.168.254.178:1935/$app/$name -acodec copy -c:v libx264 -preset veryfast -profile:v baseline -vsync cfr -s 480x360 -b:v 400k maxrate 400k -bufsize 400k -threads 0 -r 30 -f flv rtmp://192.168.254.178:1935/mobile/$;
}

#creates our "mobile" lower-resolution HLS videostream from the ffmpeg-created stream and tells where to put the HLS video manifest and video fragments
application mobile {
allow play all;
live on;
hls on;
hls_nested on;
hls_path /HLS/mobile;
hls_fragment 10s;
}

#allows you to play your recordings of your live streams using a URL like "rtmp://my-ip:1935/vod/filename.flv"
application vod {
play /video_recordings;
}
}
}


http {
include       mime.types;
default_type  application/octet-stream;

server {
listen 80;
server_name 192.168.254.178;

#creates the http-location for our full-resolution (desktop) HLS stream - "http://my-ip/live/my-stream-key/index.m3u8"      
location /live {
types {
application/vnd.apple.mpegurl m3u8;
}
alias /HLS/live;
add_header Cache-Control no-cache;
}

#creates the http-location for our mobile-device HLS stream - "http://my-ip/mobile/my-stream-key/index.m3u8"        
location /mobile {
types {
application/vnd.apple.mpegurl m3u8;
}
alias /HLS/mobile;
add_header Cache-Control no-cache;
}   

#allows us to see how stats on viewers on our Nginx site using a URL like: "http://my-ip/stats"     
location /stats {
stub_status;
}

#allows us to host some webpages which can show our videos: "http://my-ip/my-page.html"     
location / {
root   html;
index  index.html index.htm;
}   
}
}

Pressione Ctrl + X para sair. Diga "sim" para salvar as alterações.

Você pode encontrar instruções e exemplos claros das variáveis ​​possíveis neste nginx.confarquivo se consultar o seu mecanismo de pesquisa favorito por "diretivas nginx-rtmp". Estou usando o nginx-rtmp com HLS há alguns anos, sem usar as diretivas "permitir publicação" e "negar publicação" e vi zero instâncias de pessoas usando / invadindo meus servidores de vídeo. Portanto, não incluí essas diretivas aqui. Leia e adicione essas diretivas, se desejar.

Após alterar o nginx.confarquivo, você deve reiniciar o Nginx para usar a nova configuração:

sudo service nginx restart

Observe atentamente as mensagens de erro do Nginx e resolva os erros que possam ter sido causados ​​por erros de ortografia, propriedade da pasta ou permissões. Se você não tiver mensagens de erro, estará pronto para criar seu fluxo de codificação.

Você deve ter um codificador de vídeo para criar o fluxo. Eu uso o OBS (Open Broadcaster Software) - que é de código aberto e funciona bem para mim. Existem outras soluções para escolher, que estão fora do escopo deste tutorial. Não abordarei tudo sobre a configuração de um codificador de vídeo RTMP. Todos eles requerem aproximadamente as mesmas variáveis ​​de entrada. As principais configurações que você precisará inserir para usar minha nginx.confconfiguração exata e funcionar bem na maioria dos players / navegadores / plataformas são as seguintes:

1. Encoder-x264
2. Taxa de bits variável (não CBR ou taxa de bits constante), qualidade mais alta
3. Taxa de bits máxima-600kbps
4. Codec de áudio-AAC
5. Formato de áudio-44.1khz
6. Taxa de bits de áudio-64kbps
7. URL do FMS - "rtmp: // my-ip: 1935 / live"
8. Chave de fluxo - "minha chave de fluxo"
9. Resolução-640x480
10. FPS (quadros por segundo) -30
11. CFR (taxa de quadros constante) - Sim
12. Intervalo de quadro-chave - 2 segundos (um quadro-chave a cada 2 segundos)
13. x264 Linha de base do perfil de codificação (pode funcionar com main - depende do player usado)
14. CPU x264 atual-muito rápida

Eu recomendo tentar codificadores diferentes e experimentar com eles. Você pode desejar uma ampla relação de aspecto - ou os materiais da sua câmera (ou outra transmissão) podem exigir isso. Nesse caso, certifique-se de alterar essas informações no seu codificador e também a proporção listada na seção exec-ffmpeg do nginx.confarquivo que eu forneci; caso contrário, você receberá alguns feeds de vídeo de aparência pateta.

Depois que seu codificador estiver configurado, você poderá testar tudo. Inicie o codificador com sua webcam ou algum tipo de teste em execução. Você pode ver sua transmissão neste momento com o VLC player usando URLs como:

http://my-ip/live/my-stream-key/index.m3u8
http://my-ip/mobile/my-stream-key/index.m3u8

Estes são para seus fluxos de vídeo principais e para dispositivos móveis, respectivamente. Substitua seu IP e transmita a chave de acordo.

Depois de transmitir com êxito sua primeira verificação de fluxo (via ssh ou ftp), sua transmissão ao vivo foi gravada na /video_recordingspasta do seu Vultr VPS. Você também pode tentar reproduzir este arquivo gravado no VLC com um URL como:

rtmp://my-ip/vod/filename.flv

As estatísticas do Nginx também estão disponíveis (com o Nginx stub_status). Para visualizar estatísticas de visitantes / espectadores, acesse:

http://my-ip/stats

Para visualizar seu vídeo em uma página da web, você precisará de um player incorporável. Existem muitos players incorporáveis ​​disponíveis que reproduzirão o vídeo HLS. Eu uso o JW Player há alguns anos, mas a versão gratuita não reproduz o HLS. O Flowplayer e o Bitdash da Bitmovin (entre outras soluções) são generosos o suficiente para oferecer uma versão não comercial de seus players gratuitamente, que tornará seu fluxo HLS incorporado em uma página da web. Para este artigo, tentei os dois e achei que eles funcionavam muito bem com meu servidor de vídeo baseado em Vultr / Nginx. Mostrarei brevemente como consegui o Flowplayer com minha máquina de teste.

Se você for usar o streaming HLS ao vivo de qualquer maneira regular, contínua ou comercial, recomendamos que você compre uma licença do Flowplayer ou de qualquer outro jogador que você decidir usar. Você receberá um player que possui menos restrições, mais recursos e pode ser marcado com sua organização. Você também receberá suporte - o que pode ser muito importante. Além do Vultr VPS, esse é realmente o único custo associado ao projeto.

Antes de fazer qualquer outra coisa, é importante cuidar do que é chamado de restrições de "domínio cruzado", o que impediria sua capacidade de transmitir para uma página da web / site. Crie um crossdomain.xmlarquivo na sua nginx/htmlpasta e coloque instruções nele para permitir que os dados fluam entre domínios:

sudo nano /usr/local/nginx/html/crossdomain.xml

Primeiro copie (desta página) e depois cole (clique com o botão direito do mouse) no campo nano editor os seguintes dados XML:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*"/>
</cross-domain-policy>

Pressione Ctrl + O para gravar, depois Ctrl + X para salvar o arquivo no disco e sair.

Peguei o HTML5 (versão 6.0.3) do Flowplayer, que me deu vários arquivos e uma pasta quando descompactou. Carreguei todos os arquivos e a pasta em uma subpasta da pasta raiz Nginx / HTML que chamei de "flowplayer". O caminho exato era /usr/local/nginx/html/flowplayer.

Para testar nosso vídeo quando incorporado em uma página da web, crie alguns arquivos HTML na raiz da pasta Nginx / HTML usando nano e preencha-os com o seguinte conteúdo.

Arquivo:

sudo nano /usr/local/nginx/html/hls.html

Código HTML:

<!doctype html>
<head>
<link rel="stylesheet" href="#">
</head>

<body>
640x480 664kbps (live) Desktop Browsers<br>
<div style="width:640px;" class="flowplayer" data-swf="flowplayer/flowplayer.swf" data-ratio="0.75">
<video>
<source type="application/x-mpegurl" src="">
</video>
</div>
<br><br>
480x360 464kbps (mobile) Mobile Browsers <br>
<div style="width:480px;" class="flowplayer" data-swf="flowplayer/flowplayer.swf" data-ratio="0.75">
<video>
<source type="application/x-mpegurl" src="">
</video>
</div>
</body>

Arquivo:

sudo nano /usr/local/nginx/html/hls_progressive.html

Código HTML:

<!doctype html>
<head>
<link rel="stylesheet" href="#">
<style> .flowplayer { width: 640px; } </style>
</head>

<body>
<div class="flowplayer" data-swf="flowplayer/flowplayer.swf" data-ratio="0.75">
<video>
<source type="application/x-mpegurl" src=""> 
<source type="application/x-mpegurl" src="">
</video>
</div>
<br>
</body>

Certifique-se de substituir "my-ip" e "my-stream-key" pelos seus dados.

Você deve substituir o caminho flowplayer/skin/functional.csspelo sinal "#" na folha de estilo href="#". O software tutorial retira o caminho. Você deve preencher um URL na src=""parte - ela está sendo removida pelo software do tutorial, use http://my-ip/live/my-stream-key/index.m3u8e http://my-ip/mobile/my-stream-key/index.m3u8, respectivamente. Você também deve adicionar srctags de script na cabeça para ambos jquery-1.11.2.min.jse para flowplayer.min.js. As tags estão sendo removidas pelo software do tutorial. Você pode descobrir como criar essas tags example htmlvisualizando o arquivo incluído no kit Flowplayer.

Inicie o codificador com sua webcam ou algum tipo de teste em execução. Você pode visualizar sua transmissão em um navegador usando os seguintes URLs:

http://my-ip/hls.html
http://my-ip/hls_progressive.html

A primeira página simplesmente mostra cada um dos seus fluxos - o principal e o da plataforma móvel. Você poderá iniciar os dois e visualizá-los. Você notará que o fluxo da plataforma móvel é menor em tamanho. Essas etapas são apenas para garantir que tudo esteja funcionando.

A segunda página mostra um único fluxo. Mas é configurado de uma maneira que é chamada de "streaming progressivo". O que isso significa é que, quando um espectador reproduz o vídeo, o servidor e o player tentam fornecer ao espectador o fluxo de alta taxa de bits e de alta qualidade, se a conexão dos espectadores puder sustentá-lo. Se a conexão deles é ruim e não é possível sustentá-la, passa a mostrar o fluxo de taxa de bits mais baixa (móvel), que é 200 kbps menor em largura de banda. Se você desejar, poderá criar fluxos progressivos e graduados com o ffmpeg e configurá-los usando o meu exemplo.

Testei essa configuração em um único núcleo, 1GB Vultr VPS e descobri que, com uma única transmissão ao vivo, mais a transmissão móvel classificada que cria com ffmpeg, o uso da CPU era inferior a 35% e consumia apenas 100 MB de meu 1GB de ram. Agora essa é uma configuração muito eficiente.

Se você planeja transmitir vídeo com dimensões muito maiores do que o SD em pixels, talvez descubra que precisa usar um VPS mais poderoso. Fiquei curioso sobre isso e executei meu fluxo principal de até 1280x960 pixels e 2 Mbps - colocando carga adicional nas coisas. Mas o VPS ainda usava apenas 50% da CPU e o uso de memória permanecia em 100 MB. Adicionei uma dúzia de visualizadores / navegadores e isso quase não fez diferença na carga no VPS - apenas a largura de banda usada aumentou. Tenho certeza de que a criação de fluxos adicionais classificados com o ffmpeg continuaria colocando uma carga adicional no sistema.

Eu usei esse tipo de servidor em ambientes de produção com entre 50 e 100 usuários simultâneos e descobri que o uso de recursos aumentou muito pouco com o aumento das conexões dos visualizadores. Experimente com isso. Mas acho que a maioria dos usuários ficaria feliz em usar um VPS de 1 GB de núcleo único. Aproveite o seu novo servidor de streaming HLS!