Como codificar um vídeo de transmissão com HandBrake ou ffmpeg
16 de jul. de 2026 · 6 min de leitura
A Steam não revisa uma transmissão antes de ela ir ao ar: ela valida a conta, a conexão e a codificação. Erre qualquer uma dessas e o sinal é recusado de cara ou cai no meio da transmissão sem aviso. Este guia cobre as três: quem pode transmitir, a especificação de codificação publicada pela Valve e por que cada configuração existe, para onde a transmissão vai de fato e o que esperar, de forma realista, depois que ela estiver ao vivo.
Esta conta pode mesmo transmitir?
Nenhuma das configurações de codificação abaixo importa se a própria conta não tiver permissão para transmitir, e esta é a etapa que as pessoas pulam porque não tem nada a ver com vídeo. A Steam exige que a conta que transmite não seja limitada (pelo menos $5 em gastos históricos na plataforma) e que tenha a permissão “Broadcast Live” ou esteja inscrita no “Store Broadcast Beta”. A conta também precisa ter o jogo transmitido ou ter acesso a ele de outra forma, e não pode ter Banimento da Comunidade. Se faltar qualquer um desses itens, mesmo um sinal H.264 High@4.1 perfeitamente em conformidade não vai entrar ao vivo, e a falha parece idêntica a uma codificação ruim vista de fora: a transmissão simplesmente se recusa a iniciar, sem nada no log do encoder para culpar. Descarte essa hipótese antes de passar uma noite duvidando das suas configurações de bitrate. É uma checagem de cinco minutos contra um buraco de várias horas mexendo em codificação, e é um seguro barato fazer isso primeiro, não por último.
A especificação da Valve, completa
Tudo abaixo vem da documentação oficial da Valve em partner.steamgames.com, não de achismo. O codec de vídeo precisa ser H.264, Profile High, Level 4.1. A taxa de quadros é 30 ou 60 FPS, a proporção é 16:9 e o intervalo de keyframes precisa ser de 2 segundos. O bitrate máximo é 7000 kbps CBR. O áudio é AAC-LC, limitado a 128 kbps. Nada disso é sugestão: a Valve valida a transmissão com base nesses valores quando ela conecta, e um campo fora do padrão é o motivo de uma transmissão que parece ótima no seu encoder nunca entrar ao vivo. Explicamos os mesmos números com mais contexto em especificações de vídeo e codificação para a Steam.
Conectando à Steam: o lado RTMP
Codificar no padrão gera um sinal em conformidade; você ainda precisa enviá-lo para algum lugar, e esta parte confunde menos as pessoas porque é mais simples do que as configurações de codificação, não porque falte documentação. A ingestão de transmissões da Steam é um endpoint RTMP padrão: rtmp://ingest-rtmp.broadcast.steamcontent.com/app. Você não escolhe a região: a Steam escolhe o servidor de upload real com base na localização da conta, do mesmo jeito que escolhe servidores de download para instalar jogos. A chave de transmissão é gerada em steamcommunity.com/broadcast/upload, em “Create RTMP Token”. Ao criá-la, você seleciona o ID do aplicativo base do jogo, não uma entrada de DLC ou demo, já que a transmissão fica vinculada ao app base, seja qual for a edição que você está promovendo.
O OBS é o software que a maioria das pessoas usa para testar isso, mas ele não tem nada de especial para a Steam: qualquer encoder compatível com RTMP se conecta do mesmo jeito, seja o OBS, o vMix, um equipamento de hardware ou o ffmpeg enviando direto para a URL acima com sua chave de transmissão. Em termos de OBS, é o serviço de streaming “Custom”, com a URL de ingestão no campo Server e a chave no campo Stream Key. A camada RTMP não se importa com o que produziu os dados, só que eles estejam de acordo com a especificação da Valve quando chegarem.
Vale verificar uma coisa se a própria conexão não se estabelecer, independentemente da codificação: o RTMP usa a porta TCP 1935 por padrão. Numa conexão doméstica isso raramente é problema, mas numa rede de escritório, numa VPN corporativa ou numa VM na nuvem com acesso restrito, a saída pela 1935 pode estar bloqueada por um firewall que não tem problema nenhum com o tráfego web normal nas portas 80 e 443. Se o encoder não consegue alcançar a URL de ingestão de jeito nenhum (não uma transmissão recusada, simplesmente nenhuma conexão), essa é a primeira coisa a descartar antes de supor que o problema é do lado da Steam.
A única configuração que falha de vez: intervalo de keyframes
A maioria dos campos da especificação tolera pequenos desvios: um bitrate um pouco acima do teto pode simplesmente ser limitado pela ingestão da Steam. O intervalo de keyframes não funciona assim. A Valve deixa claro que, se ele não for exatamente de 2 segundos, sua transmissão não vai iniciar. Não existe meio-termo.
Um intervalo de keyframes de 2 segundos significa que um quadro completo é codificado a cada 2 segundos, com os quadros intermediários fazendo referência a ele. A 30 fps, isso é um GOP de 60 quadros; a 60 fps, de 120. A maioria dos encoders usa outro padrão (muitas vezes 4 ou 5 segundos, pensado para tamanho de arquivo e não para conformidade ao vivo), então esta é a configuração que as pessoas esquecem mesmo quando todo o resto está certo. A Valve cita o vMix pelo nome aqui: o padrão dele é Main Profile no Level 3.0, e essa combinação precisa ser alterada para que uma saída do vMix passe. Encare isso como um aviso de que os padrões do seu próprio encoder provavelmente também não são os da Steam, e confira-os explicitamente em vez de supor.
Por que bitrate constante, e não variável
A especificação da Valve pede CBR, não VBR, e o motivo é específico de transmissão ao vivo, não de qualidade de vídeo em geral. O bitrate variável deixa o encoder gastar mais bits em quadros complexos e menos nos simples, o que é ótimo para um arquivo que você vai assistir uma vez do começo ao fim. Um servidor de ingestão ao vivo precisa fazer buffer contra uma taxa de dados esperada mais ou menos constante; uma transmissão que oscila de 2000 kbps para 9000 kbps e volta faz esse buffer secar ou transbordar, e as duas coisas aparecem como travadas ou queda de conexão. O CBR troca um pouco de qualidade nas cenas simples por uma taxa de dados com a qual a ingestão consegue contar, que é exatamente o que uma transmissão 24/7 precisa.
7000 kbps é o teto documentado pela Valve, não uma meta. Ficar colado nele não deixa margem se o seu material de origem passar rapidamente da taxa definida, o que é comportamento normal de encoder mesmo em modo CBR. Uma meta mais segura é codificar algumas centenas de kbps abaixo do teto: 6000 kbps é uma escolha razoável, e é o nosso padrão pelo mesmo motivo.
O que a Steam faz com seu sinal depois da ingestão
Vale saber o que acontece com o sinal depois que ele é aceito, principalmente para não exagerar na solução de um problema que a Steam já resolve. Quando uma transmissão passa de cerca de 10 espectadores simultâneos, a Steam ativa a transcodificação automaticamente e gera versões em resolução menor (720p, 480p e 360p) junto com o seu sinal original em 1080p. Isso acontece inteiramente no servidor; você nunca envia mais de uma transmissão e nunca configura uma escada de resoluções. O único sinal CBR descrito acima é a única codificação pela qual você é responsável. Se você está acostumado com plataformas em que você mesmo envia várias versões de bitrate, pode largar esse hábito aqui: um sinal 1080p limpo no padrão acima é todo o trabalho, e isso também significa que a qualidade desse único sinal importa mais, não menos, já que ele é o master do qual todo o resto é derivado, e abaixo do limite de transcodificação é a única coisa que existe.
Codificando no HandBrake
O HandBrake gera uma saída em conformidade, mas os campos que importam para a Steam ficam fora das predefinições padrão dele. Defina o contêiner como MP4 e o codec de vídeo como H.264 (x264). Em Framerate, escolha sua meta (30 ou 60) e defina como Constant, não Variable. No controle de taxa, use Average Bitrate e defina 6000 kbps em vez de um modo baseado em qualidade (CRF), já que o CRF gera bitrate variável por definição.
O profile, o level e o intervalo de keyframes ficam na string de opções x264 da aba Advanced. Defina Profile como High e Level como 4.1 nos menus próprios, depois adicione keyint=60:min-keyint=60 à string de opções para 30 fps, ou keyint=120:min-keyint=120 para 60 fps: é o seu intervalo de 2 segundos expresso em quadros. Na aba de áudio, codifique em AAC a 128 kbps.
O mesmo no ffmpeg
Se preferir usar um script, cada campo acima corresponde a uma flag. Isto codifica no padrão a 30 fps, com meta de 6000 kbps e GOP de 2 segundos:
ffmpeg -i input.mp4 -c:v libx264 -profile:v high -level 4.1 -r 30 -g 60 -keyint_min 60 -sc_threshold 0 -b:v 6000k -maxrate 6000k -bufsize 12000k -c:a aac -b:a 128k -ar 44100 -pix_fmt yuv420p output.mp4
A combinação que vale explicar é -b:v, -maxrate e -bufsize definidos com valores iguais ou relacionados: é isso que faz o libx264 realmente manter o CBR em vez de derivar para o comportamento padrão, parecido com VBR. -g 60 é o tamanho do GOP para 30 fps (use 120 a 60 fps), e -sc_threshold 0 impede o encoder de inserir um keyframe extra nos cortes de cena, o que quebraria o intervalo fixo de 2 segundos que a Valve exige.
Como conferir sua saída antes de enviá-la ao vivo
Em vez de confiar que seu encoder fez o que você pediu, vale ler o arquivo de volta antes de enviá-lo para a ingestão da Steam. O ffprobe, que vem junto com o ffmpeg, mostra o profile, o level e a taxa de quadros que realmente encontra na saída, e não os que você pediu:
ffprobe -v error -select_streams v:0 -show_entries stream=profile,level,r_frame_rate,bit_rate -of default=noprint_wrappers=1 output.mp4
Isso mostra exatamente o que ficou gravado no arquivo: se o profile aparecer como “Main” em vez de “High”, ou o level como 3.1 em vez de 4.1, você vai saber antes que a Steam avise do jeito mais difícil. Confirmar o tamanho do GOP diretamente dá um pouco mais de trabalho, mas uma checagem aproximada é contar os pacotes de vídeo nos primeiros segundos; a 30 fps com intervalo de 2 segundos, você deve ver um keyframe mais ou menos a cada 60 quadros. É um passo pequeno, mas transforma “a transmissão foi recusada, e agora?” em “o level está errado, corrija esse campo”, um ciclo de depuração bem mais curto.
Latência: o que esperar de verdade
A Valve não publica um número oficial de latência para transmissões na loja, então trate qualquer coisa que você ler sobre isso, inclusive aqui, como um valor relatado, não uma especificação. Com essa ressalva: usuários costumam relatar latência de cerca de 30 segundos em transmissões na loja, contra uns 15 segundos na Twitch. As próprias notas de atualização da Valve já falaram em latência abaixo de 1 segundo, mas especificamente para transmissões 1 a 1 entre amigos, não para o sinal da página da loja, e alguns usuários relatam que essa melhoria nunca apareceu nas transmissões da loja. Encare os ~30 segundos como um número aproximado relatado pela comunidade, não como algo que a Valve garante por escrito.
Para um vídeo pré-gravado em loop, nada disso importa na prática. A latência só vira problema quando alguém do outro lado precisa interagir com o que está acontecendo ao vivo: ler o chat, reagir em tempo real, sincronizar uma contagem regressiva. Um loop 24/7 de um trailer ou vídeo de gameplay não tem nada ao vivo para dessincronizar, então um atraso de 30 segundos é invisível para quem só está olhando sua página da loja. É uma limitação real apenas se você tentar rodar algo interativo pela mesma conexão; veja como rodar uma transmissão pré-gravada em loop para saber o que funciona bem em loop e o que não funciona.
Ou dispense o encoder de vez
Tudo isso existe porque a ingestão da Steam é implacável com a codificação, não porque os números sejam difíceis de achar. Com o Loopcast, você envia o arquivo que tiver e nós o transcodificamos automaticamente para 1920x1080 a 30 fps, intervalo de keyframes de 2 segundos, 6000 kbps CBR e áudio AAC-LC a 128 kbps e 44,1 kHz: a mesma especificação descrita acima, aplicada sem você mexer em nenhuma configuração de codec nem em URL RTMP. Quando tiver uma chave de transmissão da Steam, veja como obter sua chave de transmissão da Steam para conectá-la e, se uma transmissão algum dia se recusar a iniciar, solução de problemas de transmissão cobre as causas mais comuns, tanto de codificação quanto de elegibilidade.