Montar um servidor de streaming: um upload para qualquer número de espectadores

Quem transmite sem um servidor próprio envia a sua imagem a cada espectador separadamente. Dez espectadores significam dez vezes os mesmos dados, cem espectadores cem vezes. O upload em casa ou no escritório fica assim esgotado depois de poucos espectadores, e a imagem começa a parar, apesar de o computador não ter praticamente nada para fazer.

Um servidor de streaming inverte isto: envia exatamente um stream para o servidor, e é o servidor que abastece todos os espectadores. A sua própria ligação transporta por isso sempre apenas um único upload, seja com dez ou com dez mil pessoas a ver. Este artigo mostra porque é que isto funciona tão bem, como se monta um servidor destes, que atraso custa cada protocolo e quanto tráfego se junta realmente.

O problema: o seu upload é o gargalo

Vídeo é um fluxo permanente. Um stream em 1080p com 60 imagens por segundo precisa, conforme o conteúdo, de 4,5 a 8 Mbit/s; 720p fica entre 3 e 5 Mbit/s. Este bitrate corre por espectador, o tempo todo, sem pausa.

Uma ligação doméstica média na Alemanha consegue entre 10 e 50 Mbit/s de upload, e mesmo muitas ligações de fibra ficam no upload entre 50 e 100 Mbit/s. A conta chega por isso depressa ao fim:

A isto junta-se um segundo problema, muitas vezes esquecido: a sua ligação é partilhada com tudo o resto que se passa em casa ou no escritório. Assim que alguém carrega um ficheiro grande ou arranca um backup, o stream vai abaixo. Um servidor num datacenter não tem este problema, porque aí a ligação está exclusivamente à sua disposição.

O princípio: subir uma vez, entregar muitas vezes

A montagem tem três partes:

• O emissor, ou seja, o OBS, o ffmpeg ou uma caixa de hardware, envia um stream para o servidor. A isto chama-se ingest.
• O servidor recebe esse único stream, converte-o no formato de saída desejado e mantém-no disponível.
• Os espectadores vão buscar o stream ao servidor. A isto chama-se egress, e é a parte que cresce com o número de espectadores.

Decisiva é a assimetria: o caminho de si até ao servidor é percorrido uma vez, o caminho do servidor até aos espectadores mil vezes. Por isso, a sua ligação só precisa do upload de um único stream, enquanto o servidor precisa de uma ligação que acompanhe o público.

Quanto tráfego se junta realmente

A largura de banda é só metade da conta. Mais interessante é o volume, porque é por ele que muitos fornecedores cobram. A fórmula é simples:

Volume em GB = bitrate em Mbit/s × segundos × espectadores ÷ 8000

Alguns exemplos realistas:

Os números da última coluna são a razão por que streaming e faturação por volume combinam mal. Uma única transmissão com muita assistência consegue consumir o volume incluído de um mês inteiro, e cada terabyte seguinte passa a ser cobrado à parte. Num plano com tráfego ilimitado, essa conta desaparece por completo: o preço mensal é fixo, passem 200 GB ou 50 TB pela linha.

Que software lhe convém

Para começar, o nginx com o módulo RTMP é a escolha mais evidente: está disponível em todo o lado, está bem documentado, e mais tarde pode usar o mesmo servidor, sem alterações, como servidor web para a página dos espectadores.

Montar um servidor de streaming com nginx e RTMP

Instalar

No Debian e no Ubuntu, o pacote libnginx-mod-rtmp já traz o módulo, não precisa de compilar nada:

apt update
apt install -y nginx libnginx-mod-rtmp ffmpeg

No AlmaLinux e no Rocky Linux, o módulo vem do repositório EPEL:

dnf install -y epel-release
dnf install -y nginx nginx-mod-rtmp ffmpeg

Configurar

A parte RTMP fica no nginx.conf fora do bloco http, e esse é o erro de principiante mais frequente. Uma versão enxuta e funcional tem este aspeto:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # HLS para os espectadores normais
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # só o próprio endereço pode publicar
            allow publish 203.0.113.10;
            deny publish all;

            # qualquer pessoa pode ver
            allow play all;
        }
    }
}

Os ficheiros HLS são depois entregues pelo servidor web normal. Para isso basta um pequeno bloco na parte http:

server {
    listen 80;
    server_name stream.example.com;

    location /hls {
        types {
            application/vnd.apple.mpegurl m3u8;
            video/mp2t ts;
        }
        root /var/www/stream;
        add_header Cache-Control no-cache;
        add_header Access-Control-Allow-Origin *;
    }
}

Criar o diretório, verificar a configuração, reiniciar:

mkdir -p /var/www/stream/hls
chown -R www-data:www-data /var/www/stream
nginx -t && systemctl reload nginx

Abrir as portas

O RTMP corre na porta 1935, a entrega nas portas 80 e 443. Com nftables ou ufw:

ufw allow from 203.0.113.10 to any port 1935 proto tcp
ufw allow 80/tcp
ufw allow 443/tcp

Repare na primeira linha: a porta de publicação está aberta apenas para o seu próprio endereço. Uma porta RTMP aberta ao mundo é encontrada em poucos dias, porque há gamas inteiras de endereços a serem percorridas automaticamente, e depois é outra pessoa a transmitir pela sua ligação.

Transmitir com o OBS

Nas definições do OBS, em «Transmissão», indique o serviço «Personalizado»:

Em «Saída» define o bitrate. Como referência: 1080p60 com 6000 kbit/s, 1080p30 com 4500 kbit/s, 720p30 com 3000 kbit/s. Ponha o intervalo entre keyframes em 2 segundos, caso contrário surgem segmentos irregulares no HLS e o reprodutor engasga-se nas transições.

Ver o stream

O stream fica depois em https://stream.example.com/hls/kanal1.m3u8 e abre-se com qualquer reprodutor compatível com HLS, no browser por exemplo com hls.js ou Video.js. Para um teste rápido basta o VLC em «Abrir fluxo de rede».

Transmitir para várias plataformas ao mesmo tempo

Esta é a segunda grande vantagem de um servidor próprio. Em vez de rebentar a sua ligação com três uploads em paralelo, envia uma vez para o servidor e é ele que distribui. Para isso acrescenta no bloco application uma linha por destino:

application live {
    live on;
    record off;

    push rtmp://live.plattform-a.example/app/STREAM_KEY;
    push rtmp://live.plattform-b.example/app/STREAM_KEY;
}

O seu upload continua a ser um único stream. A multiplicação fica a cargo do servidor, e aí a largura de banda é exatamente aquilo para que ele existe.

Atraso: que protocolo para quê

O atraso nasce quase todo na entrega, não no envio. É importante compreender isto, porque muita gente procura no lado errado:

Quanto mais baixo o atraso, mais caro fica cada espectador. O HLS é o mais barato, porque consiste em ficheiros simples que qualquer servidor web e qualquer cache consegue entregar. O WebRTC, pelo contrário, mantém uma ligação própria aberta para cada espectador e custa por isso bastante mais capacidade de cálculo. Use o atraso baixo apenas onde realmente precisa dele.

Transcoding: quando vale a pena

Enquanto o servidor apenas reencaminha o stream, quase não precisa de capacidade de cálculo. Um único núcleo moderno serve desta forma várias centenas de espectadores, e o gargalo é apenas a ligação.

Isto muda assim que quer oferecer vários níveis de qualidade, para que também os espectadores com ligação fraca consigam ver. Cada nível adicional tem de ser calculado:

ffmpeg -i rtmp://127.0.0.1/live/kanal1 \
  -c:v libx264 -preset veryfast -b:v 3000k -s 1280x720 -c:a copy -f flv rtmp://127.0.0.1/live/kanal1_720 \
  -c:v libx264 -preset veryfast -b:v 1200k -s 854x480  -c:a copy -f flv rtmp://127.0.0.1/live/kanal1_480

Conte com dois a quatro núcleos por nível. Três níveis ocupam assim permanentemente oito a doze núcleos. Pense por isso bem se precisa deles: para um público que está sobretudo ao computador ou em Wi-Fi, basta muitas vezes um único nível bem escolhido.

Proteger: quem pode transmitir

Um servidor de streaming é visível do exterior e acaba por ser encontrado. Três medidas bastam para o dia a dia:

• Firewall na porta de publicação. Só o seu próprio endereço pode chegar à 1935. Se o seu endereço muda, use em vez disso um acesso VPN ao servidor.
• Verificar a chave de transmissão. Com on_publish, o nginx chama em cada tentativa de publicação um pequeno script que compara a chave com uma lista e recusa quando não coincide.
• Proteção básica contra sobrecarga. Um servidor de streaming é um alvo apetecível, porque uma falha é logo visível. Na KernelHost, cada servidor tem uma proteção contra floods com 3,2 Tbps de capacidade, sem que tenha de configurar nada. Mais sobre isso na página da proteção DDoS.

Escolha do local e vários servidores

O servidor não pertence perto de si, mas perto dos seus espectadores. A sua própria ligação ao servidor é estabelecida uma vez e corre depois estável, mesmo através de meio continente. A ligação aos espectadores, pelo contrário, é a que decide o tempo de carregamento e a taxa de abandono.

Se o seu público está sobretudo na Europa, um local na Alemanha é o acertado. Se se distribui por vários continentes, vale a pena um segundo servidor e uma distribuição por DNS, para que cada espectador caia no mais próximo. A KernelHost oferece para isso locais na Alemanha, na costa oeste dos EUA, na costa leste dos EUA, bem como em Singapura e na Coreia do Sul; encontra uma visão geral em Localizações de servidores.

Se distribui ficheiros em vez de imagem em direto, ou seja, atualizações, imagens ou arquivos de vídeo, a ferramenta certa não é um servidor de streaming, mas uma cache à frente. Como isso funciona está no artigo Montar o seu próprio servidor CDN.

Que servidor serve

Num servidor de streaming conta outra ordem de prioridades do que num servidor web:

1. Ligação e tráfego. É aqui que está o gargalo, sempre. Uma ligação gigabit real sem estrangulamento transporta cerca de 160 espectadores a 6 Mbit/s.
2. Tráfego ilimitado. Os planos por volume são pouco calculáveis para streaming, porque uma única noite bem-sucedida consome o volume do mês.
3. CPU. Secundária, desde que não faça transcoding. Com transcoding passa a ser o segundo gargalo.
4. RAM e disco. O menos crítico. Só quando guarda gravações é que o espaço em disco passa a ser tema.

É exatamente para este caso que os nossos servidores root com tráfego ilimitado estão feitos: ligação real de 2 × 1 Gbit/s por servidor, volume ilimitado sem estrangulamento, um preço mensal fixo independente da quantidade transferida e 3,2 Tbps de proteção contra floods de fábrica. O servidor é disponibilizado em menos de 30 segundos, com acesso root completo, IPv4 e uma rede IPv6 /64. A faturação é em regime PrePaid e cancelável mensalmente, pelo que pode começar com um plano pequeno e crescer quando o seu público crescer.