Aprenda todas as etapas para criar um servidor de streaming para Smart TV

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.m3u8

Essa 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 → Aplicativo

1. 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 Kbps

Quem 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.m3u8

O 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:

.mpd

Pode 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 → servidor

O 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.com

Evite 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 Server

Projeto 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
CDN

Projeto 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
monitoramento

A 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,45

Uma transmissão de 3 Mbps consome aproximadamente:

3 × 0,45 = 1,35 GB por espectador por hora

Com 100 espectadores simultâneos durante uma hora:

1,35 × 100 = 135 GB

Em termos de velocidade de saída:

100 espectadores × 3 Mbps = 300 Mbps

Com mil espectadores:

1.000 × 3 Mbps = 3.000 Mbps

Isso 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 SSH

Acesse:

ssh root@IP_DO_SERVIDOR

Atualize o sistema:

apt update && apt upgrade -y

2. Instalar Docker

apt install docker.io docker-compose-plugin -y

Habilite o Docker na inicialização:

systemctl enable docker
systemctl start docker

Verifique:

docker --version

3. 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:5

As portas principais são:

1935 — RTMP
1985 — API
8080 — HLS e HTTP

A 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 ps

Confira os logs:

docker logs -f srs

4. 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 enable

Não é recomendável deixar a porta da API administrativa exposta publicamente sem necessidade.

5. Configurar o OBS Studio

No OBS, acesse:

Configurações → Transmissão

Selecione um servidor personalizado.

Servidor:

rtmp://IP_DO_SERVIDOR/live

Chave de transmissão:

canal1

A URL final de publicação será:

rtmp://IP_DO_SERVIDOR/live/canal1

A URL HLS correspondente será:

http://IP_DO_SERVIDOR:8080/live/canal1.m3u8

6. Testar com VLC

Abra o VLC e selecione:

Mídia → Abrir fluxo de rede

Cole:

http://IP_DO_SERVIDOR:8080/live/canal1.m3u8

Caso 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/canal1

Entenda os principais parâmetros:

-re

Faz o FFmpeg ler o arquivo em velocidade de reprodução normal.

-stream_loop -1

Repete o arquivo indefinidamente.

-c:v libx264

Codifica o vídeo em H.264.

-preset veryfast

Controla a velocidade e o consumo da codificação.

-b:v 2500k

Define o bitrate médio de vídeo.

-c:a aac

Codifica o áudio em AAC.

-f flv

Cria 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.com

Crie no DNS um registro do tipo A:

Nome: stream
Tipo: A
Destino: IP_DO_SERVIDOR

Depois, instale o NGINX:

apt install nginx certbot python3-certbot-nginx -y

Crie a configuração:

nano /etc/nginx/sites-available/stream

Adicione:

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 nginx

Gere o certificado:

certbot --nginx -d stream.seusite.com

A URL passa a ser:

https://stream.seusite.com/live/canal1.m3u8

HTTPS é 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.m3u8

No 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/canal1

Utilize uma chave longa e difícil de prever:

rtmp://servidor/live/a8xM3pQ92Kz7L1

Ainda 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=123456

O 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 aplicativos

Cache 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 maior

Uma 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 entrevistas

O 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.txt

Execute:

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/canal1

Esse 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 Entrevista

Para 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.m3u8

VOD

O usuário escolhe um vídeo e assiste quando desejar.

Exemplo:

/vod/filme123/master.m3u8

Para 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.m3u8

O parâmetro:

-hls_playlist_type vod

gera 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ária

O 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 FFmpeg

FFprobe

O FFprobe pode analisar o fluxo:

ffprobe \
  -v error \
  -show_streams \
  -show_format \
  https://stream.seusite.com/live/canal1.m3u8

O 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.m3u8

Você deve receber algo como:

HTTP/2 200
Content-Type: application/vnd.apple.mpegurl

Monitoramento 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"
fi

Em 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.mpegurl

Para segmentos MPEG-TS:

video/mp2t

9. 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 espectadores

Na 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/canal3

As saídas:

/live/canal1.m3u8
/live/canal2.m3u8
/live/canal3.m3u8

O 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 TV

O 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.