A etapa seguinte foi uma das mais frustrantes de toda a jornada: configurar o MediaMTX corretamente. Mesmo sendo uma ferramenta poderosa, a documentação limitada e a extrema sensibilidade a erros de configuração tornaram essa fase um verdadeiro teste de paciência.
🧱 O início com o MediaMTX
O MediaMTX (anteriormente rtsp-simple-server) era perfeito para o que eu precisava: receber RTMP, gerar HLS, e ainda oferecer suporte a SRT. Baixei a versão estável, instalei e... nada funcionava direito.
A única referência oficial era um arquivo gigantesco de configuração em YAML no repositório do GitHub. Sem muitos comentários ou explicações, era um território difícil de navegar.
⚠️ O terror do YAML
Cometi inúmeros erros por causa de:
Espaços mal posicionados (YAML é extremamente sensível)
Estruturas mal interpretadas (ex: tentar usar hls: como objeto ao invés de enable: yes)
Tipos errados (booleanos confundidos com strings)
Resultado: o serviço falhava silenciosamente ou emitia erros vagos nos logs.
Com o tempo, aprendi a consultar constantemente os logs com:
tail -f /var/log/mediamtx/mediamtx.log
E corrigir a configuração. Um exemplo funcional mínimo:
rtmp:
enable: yes
hls:
enable: yes
segmentCount: 7
segmentDuration: 2s
partDuration: 0
🧪 O mistério do LL-HLS
Mesmo após tudo parecer configurado corretamente, notei um comportamento estranho: o player apresentava travamentos e alto uso de CPU. Depois de horas investigando, descobri que o modo LL-HLS (Low-Latency HLS) vinha ativado por padrão no MediaMTX.
Esse modo não se adequava à minha infraestrutura e gerava gargalos sérios.
A solução foi explícita:
hls:
variant: mpegts
Forçar o modo clássico de segmentação (mpegts) fez o LL-HLS sumir!
"HLS listener opened on :8888"
sem erros, foi um alívio indescritível.
No próximo post, explico como configurei o FFPlayout para transmitir os vídeos e como usei Nginx como proxy reverso — incluindo as dores (e soluções) com CORS e HTTPS.
Top comments (0)