Criar um servidor de streaming para TV deixou de ser uma atividade restrita às grandes emissoras. Atualmente, pequenas empresas, produtores independentes, igrejas, escolas, canais regionais, plataformas OTT e criadores de conteúdo podem transmitir vídeos e canais ao vivo diretamente para Smart TVs, celulares, computadores e dispositivos como Roku, Fire TV e Android TV.
No entanto, um servidor de streaming profissional não é apenas um computador com alguns vídeos armazenados. Ele precisa receber o sinal, processar áudio e vídeo, gerar diferentes qualidades, criar playlists, entregar os arquivos aos espectadores, controlar acessos e suportar muitos usuários simultâneos.
Em uma estrutura moderna, o servidor também pode ser conectado a aplicativos para:
- Samsung Smart TV;
- LG webOS;
- Roku;
- Android TV;
- Google TV;
- Apple TV;
- navegadores;
- smartphones;
- tablets.
O protocolo mais usado para esse tipo de distribuição é o HLS — HTTP Live Streaming. Ele divide a transmissão em pequenos segmentos e utiliza playlists com extensão .m3u8. O dispositivo pode alternar automaticamente entre diferentes qualidades de vídeo conforme a velocidade da internet do usuário. A Apple mantém a especificação e as recomendações oficiais do HLS, incluindo streaming adaptativo, baixa latência, legendas, áudio alternativo e proteção de conteúdo.
Neste guia, você aprenderá como construir uma estrutura funcional usando:
- servidor Linux;
- Docker;
- SRS;
- FFmpeg;
- NGINX;
- HLS;
- HTTPS;
- DNS;
- CDN;
- aplicativos para Smart TV.
Também veremos segurança, escalabilidade, custos, monitoramento, transmissão linear e os erros mais comuns.
🎯 O que é um servidor de streaming?
Um servidor de streaming é uma infraestrutura responsável por receber, processar e distribuir conteúdo audiovisual pela internet.
Imagine uma emissora transmitindo uma programação ao vivo. O sinal sai de um estúdio, de um computador com OBS Studio, de uma câmera ou de um sistema de automação. Esse sinal é enviado ao servidor por um protocolo de entrada.
O servidor recebe a transmissão e pode:
- converter o vídeo;
- reduzir ou aumentar a resolução;
- gerar diferentes qualidades;
- dividir o conteúdo em segmentos;
- criar a playlist do canal;
- entregar o conteúdo aos espectadores;
- registrar métricas;
- bloquear acessos indevidos;
- gravar o conteúdo;
- encaminhar o vídeo para uma CDN.
O aplicativo instalado na Smart TV não recebe diretamente o sinal da câmera. Ele normalmente recebe uma URL como:
https://stream.seusite.com/live/canal1/master.m3u8Essa URL aponta para uma playlist HLS.
O aplicativo abre a playlist, identifica as qualidades disponíveis e começa a baixar os segmentos de vídeo. Quando a conexão piora, o player pode escolher uma versão mais leve. Quando melhora, ele volta para uma qualidade superior.
Essa capacidade é chamada de streaming adaptativo, ou ABR — Adaptive Bitrate Streaming.
🧩 Como funciona a arquitetura de streaming
Uma estrutura profissional pode ser dividida em sete partes:
Fonte → Ingestão → Codificação → Empacotamento → Servidor de origem → CDN → Aplicativo1. Fonte do conteúdo
A fonte pode ser:
- câmera;
- mesa de corte;
- OBS Studio;
- arquivo MP4;
- playlist de vídeos;
- encoder físico;
- programa de automação de TV;
- sinal via satélite;
- sistema de playout;
- outro servidor.
2. Ingestão
A ingestão é a entrada do sinal no servidor.
Os protocolos mais comuns são:
- RTMP;
- SRT;
- RTSP;
- WHIP;
- MPEG-TS sobre UDP;
- RIST.
O RTMP ainda é amplamente utilizado na contribuição de vídeo porque possui compatibilidade com OBS, FFmpeg e muitos encoders. Para conexões instáveis ou transmissões a longa distância, SRT pode ser mais resistente a perda de pacotes. O SRS suporta ingestão e conversão entre protocolos como RTMP, SRT, HLS, WebRTC e HTTP-FLV.
3. Codificação e transcodificação
A codificação transforma o vídeo bruto em um formato comprimido, como:
- H.264;
- H.265/HEVC;
- AV1.
A transcodificação cria novas versões do vídeo.
Por exemplo:
1080p — 6 Mbps
720p — 3 Mbps
480p — 1,5 Mbps
360p — 800 KbpsQuem está com uma internet rápida recebe 1080p. Quem está em uma rede mais lenta pode receber 480p ou 360p.
4. Empacotamento
Depois de codificado, o vídeo é organizado em um formato de distribuição, como:
- HLS;
- MPEG-DASH;
- CMAF;
- Smooth Streaming.
Para alcançar o maior número possível de televisores, o HLS costuma ser uma escolha inicial segura.
5. Servidor de origem
O servidor de origem mantém:
- playlists
.m3u8; - segmentos
.ts; - segmentos
.m4s; - arquivos de legenda;
- chaves de criptografia;
- gravações;
- imagens;
- metadados.
O servidor de origem não deve necessariamente atender sozinho a todos os espectadores. Em projetos maiores, ele alimenta uma CDN.
6. CDN
A CDN replica ou armazena o conteúdo em servidores distribuídos geograficamente.
Sem uma CDN, todos os usuários solicitam os segmentos diretamente ao seu VPS. Isso pode esgotar rapidamente:
- a banda;
- a CPU;
- a memória;
- as conexões simultâneas;
- os limites da hospedagem.
7. Aplicativo ou player
O player pode estar em:
- site;
- aplicativo móvel;
- Samsung Tizen;
- LG webOS;
- Roku;
- Android TV;
- Fire TV;
- Apple TV.
Cada plataforma possui limitações específicas de codec, tags HLS, DRM, áudio, legenda e resolução. Por isso, um streaming que funciona no navegador pode não funcionar corretamente em todos os modelos de televisão.
🌐 Qual protocolo usar para streaming em TV?
HLS
O HLS é o protocolo mais indicado para começar um projeto de streaming voltado a Smart TVs.
Ele possui:
- ampla compatibilidade;
- distribuição por HTTP e HTTPS;
- suporte a CDN;
- múltiplas qualidades;
- áudio alternativo;
- legendas;
- criptografia;
- transmissão ao vivo;
- vídeo sob demanda;
- janela de DVR;
- baixa latência em versões modernas.
A playlist principal normalmente é chamada de master.m3u8.
Exemplo simplificado:
#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=6000000,RESOLUTION=1920x1080
1080p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=3000000,RESOLUTION=1280x720
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1500000,RESOLUTION=854x480
480p/index.m3u8O aparelho analisa essas opções e escolhe uma delas.
MPEG-DASH
O MPEG-DASH também oferece streaming adaptativo e é bastante utilizado em plataformas profissionais.
Ele usa normalmente um manifesto com extensão:
.mpdPode ser interessante para:
- projetos com Widevine;
- Android;
- navegadores compatíveis;
- ambientes baseados em CMAF;
- operações multi-DRM.
RTMP
O RTMP é mais apropriado para enviar o sinal ao servidor do que para entregá-lo ao usuário final.
Exemplo:
OBS → RTMP → servidorO aplicativo da Smart TV geralmente recebe HLS ou DASH, e não o RTMP diretamente.
SRT
O SRT é útil para transportar o sinal da origem até o servidor, especialmente quando há:
- distância geográfica;
- perda de pacotes;
- internet instável;
- necessidade de criptografia;
- produção remota.
WebRTC
O WebRTC é indicado para transmissões interativas e de latência muito baixa, como:
- videochamadas;
- leilões ao vivo;
- aulas interativas;
- suporte remoto;
- eventos com participação do público.
Para uma programação tradicional de televisão, alguns segundos de atraso podem ser aceitáveis. Nesse caso, HLS costuma ser mais simples e escalável.
O Low-Latency HLS reduz o atraso utilizando segmentos parciais, atualizações incrementais da playlist, bloqueio de recarga e outras extensões. A infraestrutura, o packager e o player precisam suportar essas funções.
🖥️ Requisitos para criar o servidor
Para um projeto inicial, você precisará de:
- servidor VPS ou dedicado;
- sistema operacional Linux;
- endereço IP público;
- domínio ou subdomínio;
- acesso SSH;
- Docker;
- software de streaming;
- FFmpeg;
- certificado HTTPS;
- fonte de vídeo;
- player para testes.
Um exemplo de subdomínio seria:
stream.seusite.comEvite utilizar hospedagem compartilhada convencional para transcodificação de vídeo. A maioria dos planos compartilhados não foi criada para:
- FFmpeg contínuo;
- processamento intensivo;
- alto consumo de banda;
- milhares de conexões;
- portas RTMP;
- serviços em Docker;
- tarefas em segundo plano.
Hospedagem compartilhada pode servir páginas, APIs ou o painel administrativo, mas o streaming normalmente deve ficar em um VPS, servidor dedicado ou serviço especializado.
⚙️ Configuração recomendada de servidor
Não existe uma configuração única. A necessidade depende de:
- quantidade de canais;
- resolução;
- número de qualidades;
- codec;
- quantidade de espectadores;
- necessidade de transcodificação;
- gravação;
- latência desejada.
Projeto de laboratório
Para apenas receber um sinal e gerar HLS sem transcodificar:
2 vCPUs
2 a 4 GB de RAM
40 GB de SSD
porta de 1 Gbps
Ubuntu ServerProjeto pequeno em produção
Para um ou dois canais com alguma transcodificação:
4 a 8 vCPUs
8 a 16 GB de RAM
100 GB ou mais de SSD
porta de 1 Gbps
CDNProjeto com vários canais
Para múltiplos canais e várias qualidades:
CPU com muitos núcleos
32 GB de RAM ou mais
GPU para codificação
armazenamento separado
servidor de origem
servidores de transcodificação
CDN
balanceamento
monitoramentoA transcodificação é geralmente a parte que mais consome processamento. Um fluxo que apenas copia o vídeo original exige muito menos CPU do que um processo que cria quatro resoluções simultâneas.
📊 Como calcular o consumo de banda
O cálculo aproximado é:
Consumo por hora em GB = bitrate em Mbps × 0,45Uma transmissão de 3 Mbps consome aproximadamente:
3 × 0,45 = 1,35 GB por espectador por horaCom 100 espectadores simultâneos durante uma hora:
1,35 × 100 = 135 GBEm termos de velocidade de saída:
100 espectadores × 3 Mbps = 300 MbpsCom mil espectadores:
1.000 × 3 Mbps = 3.000 MbpsIsso representa aproximadamente 3 Gbps de tráfego simultâneo.
Um VPS com porta limitada a 1 Gbps não conseguiria entregar 3 Gbps diretamente. É nesse ponto que a CDN se torna essencial.
🚀 Método 1: criar um servidor com SRS e Docker
O SRS — Simple Realtime Server é um servidor de mídia de código aberto. Ele suporta protocolos como:
- RTMP;
- HLS;
- SRT;
- WebRTC;
- HTTP-FLV;
- MPEG-DASH.
O SRS possui servidor HTTP integrado para testes e operação de origem. A documentação recomenda utilizar NGINX, Caddy ou outra camada HTTP quando for necessária distribuição de borda, proxy ou estrutura mais robusta.
1. Criar o servidor
Contrate um VPS com Ubuntu e anote:
IP público
usuário
senha ou chave SSHAcesse:
ssh root@IP_DO_SERVIDORAtualize o sistema:
apt update && apt upgrade -y2. Instalar Docker
apt install docker.io docker-compose-plugin -yHabilite o Docker na inicialização:
systemctl enable docker
systemctl start dockerVerifique:
docker --version3. Executar o SRS
Exemplo básico:
docker run -d \
--name srs \
--restart unless-stopped \
-p 1935:1935 \
-p 1985:1985 \
-p 8080:8080 \
ossrs/srs:5As portas principais são:
1935 — RTMP
1985 — API
8080 — HLS e HTTPA documentação oficial também apresenta URLs diferentes para aplicações e streams, permitindo publicar vários canais no mesmo servidor.
Verifique se o contêiner está rodando:
docker psConfira os logs:
docker logs -f srs4. Abrir as portas no firewall
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 1935/tcp
ufw allow 8080/tcp
ufw enableNão é recomendável deixar a porta da API administrativa exposta publicamente sem necessidade.
5. Configurar o OBS Studio
No OBS, acesse:
Configurações → TransmissãoSelecione um servidor personalizado.
Servidor:
rtmp://IP_DO_SERVIDOR/liveChave de transmissão:
canal1A URL final de publicação será:
rtmp://IP_DO_SERVIDOR/live/canal1A URL HLS correspondente será:
http://IP_DO_SERVIDOR:8080/live/canal1.m3u86. Testar com VLC
Abra o VLC e selecione:
Mídia → Abrir fluxo de redeCole:
http://IP_DO_SERVIDOR:8080/live/canal1.m3u8Caso o fluxo abra, o servidor básico já está funcionando.
🎬 Publicando um vídeo com FFmpeg
Também é possível simular um canal ao vivo a partir de um arquivo.
Exemplo:
ffmpeg \
-re \
-stream_loop -1 \
-i video.mp4 \
-c:v libx264 \
-preset veryfast \
-b:v 2500k \
-maxrate 2675k \
-bufsize 5000k \
-g 50 \
-keyint_min 50 \
-sc_threshold 0 \
-c:a aac \
-b:a 128k \
-ar 48000 \
-f flv \
rtmp://IP_DO_SERVIDOR/live/canal1Entenda os principais parâmetros:
-reFaz o FFmpeg ler o arquivo em velocidade de reprodução normal.
-stream_loop -1Repete o arquivo indefinidamente.
-c:v libx264Codifica o vídeo em H.264.
-preset veryfastControla a velocidade e o consumo da codificação.
-b:v 2500kDefine o bitrate médio de vídeo.
-c:a aacCodifica o áudio em AAC.
-f flvCria a saída apropriada para RTMP.
O FFmpeg possui muxers responsáveis por organizar fluxos codificados em formatos de saída, incluindo HLS e outros formatos de streaming.
🔐 Configurando domínio e HTTPS
Usar apenas o IP é aceitável para testes, mas uma operação real deve utilizar:
https://stream.seusite.comCrie no DNS um registro do tipo A:
Nome: stream
Tipo: A
Destino: IP_DO_SERVIDORDepois, instale o NGINX:
apt install nginx certbot python3-certbot-nginx -yCrie a configuração:
nano /etc/nginx/sites-available/streamAdicione:
server {
listen 80;
server_name stream.seusite.com;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
add_header Access-Control-Allow-Origin "*" always;
add_header Access-Control-Allow-Methods "GET, HEAD, OPTIONS" always;
add_header Access-Control-Allow-Headers "Range, Origin, Accept, Content-Type" always;
add_header Access-Control-Expose-Headers "Content-Length, Content-Range" always;
}
}Ative:
ln -s /etc/nginx/sites-available/stream /etc/nginx/sites-enabled/stream
nginx -t
systemctl reload nginxGere o certificado:
certbot --nginx -d stream.seusite.comA URL passa a ser:
https://stream.seusite.com/live/canal1.m3u8HTTPS é importante porque muitos aplicativos, navegadores e plataformas aplicam restrições a conteúdos inseguros.
🎚️ Como criar múltiplas qualidades de vídeo
Uma transmissão profissional não deveria depender de apenas uma resolução.
Se você oferecer somente 1080p a 6 Mbps, usuários com conexões fracas sofrerão:
- travamentos;
- buffer;
- quedas;
- demora para iniciar;
- abandono da transmissão.
Uma escada inicial de qualidades pode ser:
| Qualidade | Resolução | Bitrate de vídeo |
|---|---|---|
| Full HD | 1920×1080 | 4,5 a 6 Mbps |
| HD | 1280×720 | 2,5 a 3,5 Mbps |
| SD | 854×480 | 1,2 a 1,8 Mbps |
| Baixa | 640×360 | 600 a 900 Kbps |
Esses números são pontos de partida, não regras universais. Esportes e cenas com movimento exigem mais bitrate do que entrevistas ou imagens estáticas.
Exemplo de FFmpeg com três qualidades
mkdir -p /var/www/hls/canal1/{720p,480p,360p}Depois:
ffmpeg -i rtmp://127.0.0.1/live/canal1 \
-filter_complex "
[0:v]split=3[v720][v480][v360];
[v720]scale=1280:720[v720out];
[v480]scale=854:480[v480out];
[v360]scale=640:360[v360out]
" \
-map "[v720out]" -map 0:a:0 \
-map "[v480out]" -map 0:a:0 \
-map "[v360out]" -map 0:a:0 \
-c:v libx264 \
-preset veryfast \
-sc_threshold 0 \
-g 50 \
-keyint_min 50 \
-b:v:0 3000k -maxrate:v:0 3210k -bufsize:v:0 6000k \
-b:v:1 1500k -maxrate:v:1 1605k -bufsize:v:1 3000k \
-b:v:2 800k -maxrate:v:2 856k -bufsize:v:2 1600k \
-c:a aac \
-b:a:0 128k \
-b:a:1 96k \
-b:a:2 96k \
-ar 48000 \
-f hls \
-hls_time 4 \
-hls_list_size 8 \
-hls_flags delete_segments \
-master_pl_name master.m3u8 \
-var_stream_map "v:0,a:0,name:720p v:1,a:1,name:480p v:2,a:2,name:360p" \
-hls_segment_filename "/var/www/hls/canal1/%v/segment_%06d.ts" \
"/var/www/hls/canal1/%v/index.m3u8"O resultado esperado será:
/var/www/hls/canal1/master.m3u8
/var/www/hls/canal1/720p/index.m3u8
/var/www/hls/canal1/480p/index.m3u8
/var/www/hls/canal1/360p/index.m3u8No NGINX:
server {
listen 80;
server_name stream.seusite.com;
location /hls/ {
root /var/www;
types {
application/vnd.apple.mpegurl m3u8;
video/mp2t ts;
}
add_header Cache-Control "no-cache";
add_header Access-Control-Allow-Origin "*" always;
add_header Access-Control-Allow-Methods "GET, HEAD, OPTIONS" always;
add_header Access-Control-Expose-Headers "Content-Length, Content-Range" always;
}
}A playlist será:
https://stream.seusite.com/hls/canal1/master.m3u8📺 Compatibilidade com Smart TVs
Samsung Tizen
Aplicativos Samsung podem utilizar a API AVPlay para reprodução de mídia. A plataforma suporta mecanismos adaptativos como HLS e MPEG-DASH, identificados por arquivos .m3u8 e .mpd.
Exemplo conceitual:
const url = "https://stream.seusite.com/hls/canal1/master.m3u8";
webapis.avplay.open(url);
webapis.avplay.setDisplayRect(0, 0, 1920, 1080);
webapis.avplay.prepareAsync(
function () {
webapis.avplay.play();
},
function (error) {
console.error("Erro ao preparar vídeo:", error);
}
);É importante verificar a versão do HLS e as tags utilizadas. A documentação da Samsung apresenta uma matriz detalhada de compatibilidade por versão do Tizen. Nem todas as tags modernas estão presentes em televisores antigos.
LG webOS
O webOS oferece reprodução HLS nos dispositivos compatíveis. A própria documentação alerta que algumas tags HLS não são suportadas e que a duração dos segmentos de áudio e vídeo deve ser igual para melhor compatibilidade.
Exemplo com HTML5:
<video
id="player"
controls
autoplay
playsinline
style="width:100%;height:100%;"
>
<source
src="https://stream.seusite.com/hls/canal1/master.m3u8"
type="application/vnd.apple.mpegurl"
>
</video>O fato de funcionar em uma versão atual do webOS não significa que funcionará em todos os televisores antigos. Testes em aparelhos reais continuam indispensáveis.
Roku
O Roku suporta HLS e DASH para streaming adaptativo. A documentação recomenda disponibilizar múltiplos fluxos de qualidade para que o dispositivo ajuste a reprodução às condições da rede.
Exemplo em SceneGraph:
videoContent = CreateObject("roSGNode", "ContentNode")
videoContent.url = "https://stream.seusite.com/hls/canal1/master.m3u8"
videoContent.streamFormat = "hls"
videoContent.title = "Canal ao Vivo"
m.video.content = videoContent
m.video.control = "play"Android TV
No Android TV, o Media3 ExoPlayer possui suporte a HLS, desde que os codecs de áudio e vídeo também sejam compatíveis com o dispositivo.
Exemplo Kotlin:
val player = ExoPlayer.Builder(context).build()
val mediaItem = MediaItem.fromUri(
"https://stream.seusite.com/hls/canal1/master.m3u8"
)
player.setMediaItem(mediaItem)
player.prepare()
player.play()🛡️ Como proteger o servidor
Um servidor aberto pode ser utilizado por terceiros para:
- retransmitir seu conteúdo;
- consumir sua banda;
- descobrir chaves;
- inserir transmissões;
- atacar APIs;
- acessar gravações;
- copiar playlists.
Utilize chaves de transmissão
Em vez de:
rtmp://servidor/live/canal1Utilize uma chave longa e difícil de prever:
rtmp://servidor/live/a8xM3pQ92Kz7L1Ainda melhor é validar a publicação por API ou callback.
Bloqueie portas administrativas
A API do servidor deve ficar:
- protegida por firewall;
- restrita ao localhost;
- atrás de VPN;
- protegida por autenticação.
Use URLs assinadas
Uma URL assinada possui parâmetros temporários:
https://cdn.seusite.com/live/canal1/master.m3u8?token=ABC&expires=123456O servidor ou CDN valida:
- assinatura;
- validade;
- usuário;
- IP, quando apropriado;
- plano de assinatura;
- dispositivo.
Proteja a origem
Quando utilizar CDN, bloqueie o acesso público direto à origem sempre que possível.
A origem deve aceitar solicitações apenas:
- dos IPs da CDN;
- de um proxy autorizado;
- de uma rede privada;
- de conexões autenticadas.
Configure HTTPS
HTTPS protege:
- credenciais;
- tokens;
- playlists;
- chamadas de API;
- dados do usuário.
DRM e criptografia
Existem diferentes níveis de proteção:
AES-128
Criptografa segmentos HLS utilizando uma chave.
É mais simples, mas exige cuidado para que a chave não fique pública.
Widevine
Utilizado em Android, navegadores e alguns televisores.
PlayReady
Comum em ambientes Microsoft e Smart TVs.
FairPlay
Usado em dispositivos Apple.
A documentação do LG webOS apresenta suporte e combinações entre HLS, AES-128, Widevine e PlayReady conforme a versão do sistema.
DRM profissional costuma exigir:
- packager;
- servidor de licenças;
- provedor multi-DRM;
- integração no player;
- autenticação;
- controle de direitos.
🌍 Quando usar uma CDN
Um servidor único pode funcionar para testes e poucos usuários. Conforme a audiência cresce, a CDN passa a ser importante.
Considere CDN quando houver:
- mais de algumas dezenas de espectadores simultâneos;
- usuários em diferentes regiões;
- picos de audiência;
- eventos ao vivo;
- vários canais;
- alto bitrate;
- necessidade de disponibilidade;
- proteção contra ataques;
- cobrança por tráfego previsível.
A arquitetura fica assim:
Encoder
↓
Servidor de ingestão
↓
Transcodificador
↓
Origem HLS
↓
CDN
↓
Smart TVs e aplicativosCache de playlists e segmentos
As playlists ao vivo mudam frequentemente. Por isso, devem ter cache curto ou desabilitado.
Os segmentos podem ter cache maior.
Exemplo conceitual:
master.m3u8 → cache curto
index.m3u8 → cache muito curto
segment.ts → cache maiorUma configuração errada pode fazer o aplicativo receber uma playlist antiga e ficar vários segmentos atrás da transmissão.
⏱️ Como reduzir a latência
A latência é a diferença entre o momento em que algo acontece e o momento em que o usuário vê na tela.
Ela pode surgir em:
- captura;
- encoder;
- envio;
- buffer;
- transcodificação;
- segmentação;
- CDN;
- player.
Para reduzir a latência:
- diminua a duração dos segmentos;
- utilize GOP alinhado;
- reduza buffers;
- use Low-Latency HLS;
- evite transcodificação desnecessária;
- aproxime o servidor da fonte;
- utilize SRT ou WHIP para contribuição;
- configure corretamente o player;
- monitore a CDN;
- teste em aparelhos reais.
Segmentos menores reduzem o atraso, mas aumentam:
- número de requisições;
- processamento;
- sensibilidade a instabilidade;
- complexidade do cache.
O menor valor possível nem sempre é o melhor valor.
Para uma TV linear comum, segmentos de quatro a seis segundos podem ser um ponto inicial. Para baixa latência, a arquitetura precisa ser desenhada especificamente para isso.
🗂️ Como criar uma programação de TV linear
Um servidor de streaming não cria automaticamente a grade da emissora. É necessário um sistema de playout.
O playout organiza:
- programas;
- comerciais;
- vinhetas;
- chamadas;
- horários;
- eventos ao vivo;
- preenchimento;
- identificação do canal.
Uma grade pode ser representada por:
08:00 — Jornal
09:00 — Programa infantil
10:30 — Documentário
12:00 — Notícias
13:00 — Filme
15:00 — Programa de entrevistasO sistema reproduz os arquivos em sequência e envia a saída para o servidor.
Exemplo simples com FFmpeg
Para testes, é possível criar um arquivo de lista:
file 'programa1.mp4'
file 'vinheta.mp4'
file 'programa2.mp4'
file 'comercial.mp4'Salve como:
playlist.txtExecute:
ffmpeg \
-re \
-f concat \
-safe 0 \
-i playlist.txt \
-c:v libx264 \
-preset veryfast \
-b:v 3000k \
-c:a aac \
-b:a 128k \
-f flv \
rtmp://IP_DO_SERVIDOR/live/canal1Esse exemplo é útil para laboratório, mas uma operação profissional precisa lidar com:
- arquivos de formatos diferentes;
- normalização de áudio;
- falha de mídia;
- retomada automática;
- sobreposição de logotipo;
- relógio;
- inserção de eventos ao vivo;
- comerciais;
- relatórios;
- EPG;
- redundância.
📅 EPG: guia eletrônico de programação
O EPG informa ao aplicativo o que está passando.
Exemplo de API:
{
"channel": "canal1",
"now": {
"title": "Jornal da Manhã",
"start": "2026-07-10T08:00:00-03:00",
"end": "2026-07-10T09:00:00-03:00"
},
"next": {
"title": "Programa Entrevista",
"start": "2026-07-10T09:00:00-03:00",
"end": "2026-07-10T10:00:00-03:00"
}
}O aplicativo pode mostrar:
Agora: Jornal da Manhã
A seguir: Programa EntrevistaPara canais FAST ou plataformas com vários canais, o EPG é essencial para:
- grade;
- busca;
- “agora e depois”;
- lembretes;
- continuidade;
- publicidade;
- análise de audiência.
💾 Streaming ao vivo e vídeo sob demanda
Um servidor pode oferecer dois modelos.
Live
O usuário assiste ao conteúdo que está sendo transmitido naquele momento.
Exemplo:
/live/canal1/master.m3u8VOD
O usuário escolhe um vídeo e assiste quando desejar.
Exemplo:
/vod/filme123/master.m3u8Para gerar HLS a partir de um arquivo:
ffmpeg \
-i filme.mp4 \
-c:v libx264 \
-c:a aac \
-hls_time 6 \
-hls_playlist_type vod \
-hls_segment_filename "segment_%05d.ts" \
index.m3u8O parâmetro:
-hls_playlist_type vodgera uma playlist finalizada, apropriada para conteúdo sob demanda.
No VOD, também é recomendável criar:
- múltiplas qualidades;
- miniaturas;
- legendas;
- metadados;
- duração;
- capa;
- classificação;
- categorias;
- controle de acesso.
🔄 Redundância e alta disponibilidade
Uma emissora não pode depender de um único processo.
Uma estrutura mais resistente pode ter:
Encoder principal
Encoder reserva
Servidor de ingestão A
Servidor de ingestão B
Origem principal
Origem reserva
CDN principal
CDN secundáriaO sistema deve detectar:
- ausência de vídeo;
- silêncio;
- tela preta;
- congelamento;
- bitrate zero;
- falha de áudio;
- FFmpeg encerrado;
- disco cheio;
- perda de rede;
- falha no servidor.
Quando houver erro, pode executar:
- reinicialização;
- troca de origem;
- vídeo de emergência;
- alerta;
- failover;
- mudança de CDN.
📈 Monitoramento do streaming
Não basta verificar se a página abre.
Um sistema profissional deve monitorar:
bitrate recebido
bitrate entregue
quadros por segundo
resolução
codec
áudio
latência
buffer
erros HTTP
tempo de inicialização
conexões simultâneas
CPU
RAM
disco
rede
processos FFmpegFFprobe
O FFprobe pode analisar o fluxo:
ffprobe \
-v error \
-show_streams \
-show_format \
https://stream.seusite.com/live/canal1.m3u8O FFprobe coleta informações sobre fluxos multimídia e apresenta os dados em formatos legíveis por pessoas ou sistemas.
Teste de disponibilidade
curl -I https://stream.seusite.com/live/canal1.m3u8Você deve receber algo como:
HTTP/2 200
Content-Type: application/vnd.apple.mpegurlMonitoramento automático
Um script pode verificar a playlist a cada minuto.
Exemplo:
#!/bin/bash
URL="https://stream.seusite.com/live/canal1.m3u8"
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$URL")
if [ "$STATUS" != "200" ]; then
echo "Canal indisponível: HTTP $STATUS"
fiEm produção, envie os alertas para:
- e‑mail;
- aplicativo;
- painel;
- Slack;
- Telegram corporativo;
- sistema de incidentes.
💰 Quanto custa criar um servidor de streaming?
O custo depende mais da audiência e do processamento do que do site.
Os principais componentes são:
| Item | Como afeta o custo |
|---|---|
| VPS | CPU, RAM e transferência |
| Servidor dedicado | maior capacidade |
| GPU | transcodificação |
| Armazenamento | gravações e VOD |
| CDN | tráfego entregue |
| DRM | licenças e integração |
| Monitoramento | métricas e alertas |
| Aplicativos | desenvolvimento e manutenção |
| Playout | automação da programação |
| Suporte | operação técnica |
| Backups | segurança |
| Redundância | disponibilidade |
Um canal com poucos espectadores pode operar em um VPS pequeno.
Um canal com milhares de usuários precisa de:
- CDN;
- múltiplos servidores;
- transcodificação otimizada;
- monitoramento;
- controle de custos;
- redundância.
Antes de contratar, calcule:
bitrate médio
horas assistidas
número de espectadores
quantidade de canais
armazenamento
regiões atendidas❌ Erros mais comuns
1. Usar somente uma qualidade
Uma qualidade única prejudica usuários com internet mais lenta.
Solução: criar uma playlist adaptativa.
2. Hospedar tudo em servidor compartilhado
Hospedagens comuns podem bloquear processos contínuos e alto consumo.
Solução: usar VPS, dedicado ou serviço de mídia.
3. Não utilizar CDN
O servidor pode funcionar no teste e cair quando o público aumenta.
Solução: dimensionar a saída e configurar CDN.
4. Deixar o RTMP aberto
Qualquer pessoa pode tentar publicar um fluxo.
Solução: chave segura, validação e firewall.
5. Ignorar HTTPS
Aplicativos podem bloquear conteúdo inseguro.
Solução: domínio e certificado válido.
6. GOP desalinhado
As qualidades podem trocar de forma incorreta.
Solução: utilizar intervalos de keyframes consistentes.
7. Áudio incompatível
O vídeo aparece, mas não há som.
Solução: usar AAC com parâmetros compatíveis e testar em aparelhos reais.
8. MIME type incorreto
O servidor envia .m3u8 como texto genérico.
Solução: configurar:
application/vnd.apple.mpegurlPara segmentos MPEG-TS:
video/mp2t9. CORS ausente
O aplicativo ou player web não consegue carregar a playlist.
Solução: configurar cabeçalhos CORS de forma consciente.
10. Testar apenas no navegador
Smart TVs possuem players, firmwares e limitações diferentes.
Solução: testar Samsung, LG, Roku e Android TV em dispositivos reais.
✅ Checklist de produção
Antes de publicar, confirme:
[ ] O fluxo funciona por HTTPS
[ ] Existe mais de uma qualidade
[ ] O áudio está em AAC compatível
[ ] O vídeo está em H.264 compatível
[ ] O GOP está alinhado
[ ] Os segmentos têm duração consistente
[ ] O MIME type está correto
[ ] O CORS está configurado
[ ] A origem está protegida
[ ] A chave RTMP não é pública
[ ] A CDN está configurada
[ ] Existem alertas
[ ] O servidor reinicia automaticamente
[ ] Há backup de configurações
[ ] O aplicativo trata erros
[ ] O player tenta reconectar
[ ] Há teste em aparelhos reais
[ ] O conteúdo possui direitos de distribuição❓ Perguntas frequentes
É possível criar um servidor de streaming gratuitamente?
É possível montar o software utilizando soluções gratuitas e de código aberto. Entretanto, servidor, tráfego, domínio, armazenamento, CDN e manutenção possuem custos.
Posso usar meu computador como servidor?
Pode ser usado para testes. Para produção, há riscos:
- queda de energia;
- IP variável;
- internet assimétrica;
- pouca banda de upload;
- falha de hardware;
- ausência de redundância.
Quantos usuários um VPS suporta?
Depende principalmente do bitrate e da velocidade de saída.
Um servidor com saída disponível de 500 Mbps, entregando vídeos de 3 Mbps, teria um limite teórico inferior a:
500 ÷ 3 = 166 espectadoresNa prática, é necessário reservar capacidade para sistema, picos e sobrecarga. O número real será menor.
Preciso de uma CDN?
Para testes, não necessariamente. Para público crescente, eventos e distribuição nacional, é altamente recomendável.
HLS funciona em Samsung?
Sim, o Samsung Tizen possui suporte a HLS, com diferenças entre versões e tags.
HLS funciona em LG?
Sim, mas é necessário respeitar as limitações por versão do webOS, codecs, tags e segmentação.
HLS funciona no Roku?
Sim. O Roku suporta HLS e outros formatos adaptativos.
Qual codec é mais compatível?
Para uma operação inicial com ampla compatibilidade, H.264 para vídeo e AAC para áudio continuam sendo uma combinação segura. Codecs mais modernos podem reduzir o consumo, mas exigem análise dos aparelhos que serão atendidos.
Como criar vários canais?
Utilize chaves ou nomes diferentes:
rtmp://servidor/live/canal1
rtmp://servidor/live/canal2
rtmp://servidor/live/canal3As saídas:
/live/canal1.m3u8
/live/canal2.m3u8
/live/canal3.m3u8O SRS permite diferentes aplicações e nomes de stream dentro da mesma configuração.
Posso monetizar o canal?
Sim, por modelos como:
- publicidade;
- assinatura;
- pay-per-view;
- patrocínio;
- conteúdo gratuito com anúncios;
- canais FAST;
- licenciamento;
- venda de espaço comercial.
A monetização exige direitos sobre o conteúdo transmitido.
🏁 Conclusão
Criar um servidor de streaming para TV envolve muito mais do que instalar um programa. É necessário combinar ingestão, codificação, HLS, segurança, distribuição, aplicativos, monitoramento e escalabilidade.
Para um primeiro projeto, uma arquitetura eficiente pode ser:
OBS ou playout
↓
RTMP ou SRT
↓
SRS
↓
FFmpeg
↓
HLS adaptativo
↓
NGINX e HTTPS
↓
CDN
↓
Samsung, LG, Roku e Android TVO SRS simplifica a ingestão e a conversão de protocolos. O FFmpeg permite controlar codecs, resoluções e bitrates. O NGINX entrega ou encaminha playlists e segmentos. A CDN absorve a audiência. Os aplicativos apresentam o canal ao usuário.
Comece com um laboratório:
- contrate um VPS;
- instale Docker;
- execute o SRS;
- publique pelo OBS;
- teste a playlist HLS;
- configure domínio;
- ative HTTPS;
- crie múltiplas qualidades;
- teste em Smart TVs;
- adicione CDN e segurança.
Depois que essa base estiver estável, você poderá evoluir para:
- vários canais;
- programação 24 horas;
- EPG;
- gravação;
- VOD;
- assinatura;
- anúncios;
- FAST TV;
- aplicativos publicados nas lojas;
- redundância;
- métricas de audiência.
Um projeto de streaming bem planejado pode se transformar em uma verdadeira plataforma de televisão digital, acessível por diferentes aparelhos e pronta para crescer de poucos espectadores para uma operação profissional.
