16 jul 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 feed é recusado de cara ou cai no meio da transmissão sem aviso. Isto cobre as três: quem tem permissão para transmitir, a especificação de codificação publicada pela Valve e por que cada ajuste existe, para onde a transmissão realmente vai, e o que esperar de forma realista quando ela estiver no ar.
Nada da codificação abaixo importa se a própria conta não tiver permissão para transmitir, e essa é a etapa que as pessoas pulam porque não tem nada a ver com vídeo. A Steam exige que a conta que transmite seja não limitada - pelo menos $5 de gasto histórico na plataforma - e que tenha a permissão "Broadcast Live" ou esteja inscrita no Store Broadcast Beta. A conta também precisa possuir ou de alguma forma ter acesso ao jogo sendo transmitido, e não pode estar Community Banned. Perca qualquer uma dessas e um feed H.264 High@4.1 perfeitamente em conformidade ainda assim não vai ao ar, e a falha, de fora, parece idêntica a uma codificação ruim - a transmissão simplesmente se recusa a começar, sem nada no log do codificador para culpar. Descarte isso antes de gastar uma noite questionando os seus ajustes de bitrate. É uma verificação de cinco minutos contra um buraco de coelho de codificação de várias horas, e é um seguro barato fazer isso primeiro em vez de por último.
Tudo abaixo vem da própria documentação da Valve em partner.steamgames.com, não de achismo. O codec de vídeo tem que 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 keyframe tem que 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 em relação a esses valores quando ela se conecta, e um campo fora da especificação é o motivo pelo qual uma transmissão que parece bem no seu codificador nunca vai ao ar. Cobrimos os mesmos números com mais contexto em especificações de vídeo e codificação para a Steam.
Codificar dentro da especificação lhe dá um feed em conformidade; você ainda precisa enviá-lo para algum lugar, e essa parte confunde menos as pessoas porque é mais simples que os ajustes de codificação, não porque seja não documentada. O ingest de transmissão da Steam é um endpoint RTMP padrão: rtmp://ingest-rtmp.broadcast.steamcontent.com/app. Você não escolhe uma região - a Steam escolhe o servidor de upload de fato para você com base na localização da conta, do mesmo jeito que também escolhe os servidores de download para instalações de jogos. A chave de transmissão é gerada em steamcommunity.com/broadcast/upload em "Create RTMP Token." Quando você o cria, seleciona o ID de aplicativo base do jogo, não uma entrada de DLC ou demo, já que a transmissão se vincula ao aplicativo base independentemente de qual edição você esteja promovendo.
O OBS é o software que a maioria das pessoas usa para testar isso, mas ele não é especial para a Steam - qualquer codificador capaz de RTMP se conecta da mesma forma, seja o OBS, o vMix, uma unidade de hardware, ou o ffmpeg empurrando direto para a URL acima com a sua chave de transmissão. Em termos do OBS, é o serviço de streaming "Custom", com a URL de ingest no campo Server e a chave no campo Stream Key. A camada RTMP não se importa com o que produziu os bits, só que eles correspondam à especificação da Valve quando chegam.
Uma coisa que vale verificar se a própria conexão não se estabelece, separadamente de qualquer coisa sobre a codificação: o RTMP roda sobre a porta TCP 1935 por padrão. Numa conexão doméstica isso raramente é um problema, mas numa rede de escritório, numa VPN corporativa ou numa VM de nuvem restrita, a saída pela 1935 pode ser bloqueada por um firewall que não tem problema nenhum com tráfego web normal nas portas 80 e 443. Se o codificador não consegue alcançar a URL de ingest de jeito nenhum - não uma transmissão rejeitada, apenas nenhuma conexão - essa é a primeira coisa a descartar antes de presumir que é um problema do lado da Steam.
A maioria dos campos da especificação degrada de forma tolerante se você estiver um pouco fora - um bitrate um pouco acima do teto pode simplesmente ser limitado pelo ingest da Steam. O intervalo de keyframe não funciona assim. A Valve é explícita: se ele não for exatamente 2 segundos, a sua transmissão vai falhar ao iniciar. Sem crédito parcial.
Um intervalo de keyframe 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 comprimento de GOP de 60 quadros; a 60 fps são 120. A maioria dos codificadores usa por padrão outra coisa - muitas vezes 4 ou 5 segundos, ajustada para o tamanho do arquivo em vez da conformidade ao vivo - então esse é o ajuste que as pessoas deixam passar mesmo quando todo o resto está correto. A Valve cita o vMix pelo nome aqui: o padrão dele é Main Profile em Level 3.0, e essa combinação tem que ser alterada antes que uma saída do vMix passe. Encare isso como um aviso de que os padrões do seu próprio codificador provavelmente também não são os padrões da Steam, e verifique-os explicitamente em vez de presumir.
A especificação da Valve pede CBR, não VBR, e o motivo é específico da transmissão ao vivo, não da qualidade de vídeo em geral. O bitrate variável permite que o codificador gaste mais bits em quadros complexos e menos em quadros simples, o que é ótimo para um arquivo que você vai assistir uma vez do começo ao fim. Um servidor de ingest ao vivo tem que fazer buffer com base em uma taxa de dados esperada aproximadamente constante; uma transmissão que oscila de 2000 kbps para 9000 kbps e de volta faz esse buffer ou esvaziar ou transbordar, e qualquer um dos dois aparece como travamento ou queda de conexão. O CBR troca um pouco de qualidade em cenas simples por uma taxa de dados que o lado do ingest consegue planejar, que é exatamente o que uma transmissão 24/7 precisa.
7000 kbps é o teto documentado da Valve, não um alvo. Chegar bem no limite não deixa margem se o seu material de origem der um pico breve acima da taxa que você definiu, o que é comportamento normal de codificador mesmo no modo CBR. Um alvo mais seguro é codificar algumas centenas de kbps abaixo do teto - 6000 kbps é uma escolha razoável, e é o que usamos por padrão pelo mesmo motivo.
Vale a pena saber o que acontece com o feed depois que ele é aceito, principalmente para você não superconstruir para um problema que a Steam já resolve. Assim que uma transmissão passa de cerca de 10 espectadores simultâneos, a Steam habilita a transcodificação automaticamente e gera versões em resolução mais baixa - 720p, 480p e 360p - junto com o seu feed original em 1080p. Isso acontece inteiramente no lado do servidor; você nunca envia mais de uma transmissão e nunca configura uma escada de resoluções por conta própria. O único feed CBR descrito acima é a única codificação pela qual você é responsável. Se você está acostumado a plataformas em que você mesmo empurra várias variantes de bitrate, pode largar esse hábito aqui - um feed limpo em 1080p dentro da especificação acima é o trabalho inteiro, e isso também significa que a qualidade desse único feed importa mais, não menos, já que ele é o mestre do qual tudo o mais é derivado abaixo do limiar de transcodificação.
O HandBrake gera uma saída compatível, mas os campos que importam para o Steam ficam fora dos presets padrão. Defina o container como MP4 e o codec de vídeo como H.264 (x264). Em Framerate, escolha seu alvo - 30 ou 60 - e defina como Constant, não Variable. Para o controle de taxa, use Average Bitrate e defina em 6000 kbps em vez de um modo baseado em qualidade (CRF), já que o CRF produz taxa de bits variável por design.
O profile, o level e o intervalo de keyframe ficam na string de opções x264 da aba Advanced. Defina Profile como High e Level como 4.1 nos seus próprios menus suspensos, depois adicione keyint=60:min-keyint=60 à string de opções para 30 fps, ou keyint=120:min-keyint=120 para 60 fps - esse é o seu intervalo de 2 segundos expresso em quadros. Na aba de áudio, codifique para AAC a 128 kbps.
Se você prefere fazer por script, cada campo acima corresponde a uma flag. Isto codifica conforme a spec a 30 fps com alvo de 6000 kbps e um 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
O par que vale explicar é -b:v, -maxratee -bufsize definidos com os mesmos valores ou valores relacionados - é isso que faz o libx264 de fato se manter no CBR em vez de derivar para o seu comportamento padrão parecido com VBR. -g 60 é o comprimento de GOP para 30 fps (use 120 a 60 fps), e -sc_threshold 0 impede que o codificador insira um keyframe extra em cortes de cena, o que de outra forma quebraria o intervalo fixo de 2 segundos que a Valve exige.
Em vez de confiar que o seu encoder fez o que você pediu, vale ler o arquivo de volta antes de encaminhá-lo ao ingest do Steam. O ffprobe, que vem junto com o ffmpeg, imprime o profile, o level e a taxa de quadros reais que 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 aparece como "Main" em vez de "High", ou o level como 3.1 em vez de 4.1, você vai saber antes que o Steam te avise do jeito difícil. A duração do GOP dá um pouco mais de trabalho para confirmar diretamente, mas uma verificação aproximada é contar os pacotes de vídeo nos primeiros segundos; a 30 fps com intervalo de 2 segundos você deve ver um keyframe a cada 60 quadros, mais ou menos. É um passo pequeno, mas transforma o "a stream foi rejeitada, e agora" em "o level está errado, é só corrigir esse campo" - um ciclo de depuração bem mais curto.
A Valve não publica um número oficial de latência para broadcasts na loja, então trate qualquer coisa que você ler sobre isso - inclusive aqui - como um valor relatado, não uma spec. Com essa ressalva: os usuários costumam relatar latência de cerca de 30 segundos nos broadcasts da loja, contra aproximadamente 15 segundos na Twitch. As próprias notas de atualização da Valve já alegaram latência abaixo de 1 segundo, mas especificamente para broadcasts entre amigos 1 a 1, não para o feed da página da loja, e alguns usuários relatam que essa melhoria nunca apareceu nos broadcasts da loja. Encare o número de ~30 segundos como um valor aproximado, relatado pela comunidade, e não como algo que a Valve garanta por escrito.
Para um vídeo pré-gravado em loop, nada disso importa na prática. A latência só vira um problema quando alguém do outro lado precisa interagir com o que está acontecendo ao vivo - lendo o chat, reagindo em tempo real, cronometrando uma contagem regressiva. Um loop 24/7 de um trailer ou de um vídeo de gameplay não tem nada ao vivo para dessincronizar, então um atraso de 30 segundos é invisível para quem está só assistindo à sua página da loja. É uma restrição real só se você estiver tentando rodar algo interativo pela mesma conexão; veja rodando uma transmissão pré-gravada em loop para o que funciona e o que não funciona bem como loop.
Tudo isso acima existe porque o ingest do Steam é implacável quanto à 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 para 1920x1080 a 30 fps, um intervalo de keyframes de 2 segundos, 6000 kbps CBR e áudio AAC-LC a 128 kbps e 44.1 kHz automaticamente - a mesma spec vista acima, aplicada sem que você toque numa configuração de codec ou numa URL RTMP. Assim que tiver um chave de transmissão do Steam, veja obtendo um chave de transmissão para conectá-lo, e se uma stream se recusar a iniciar, solução de problemas de broadcast cobre as causas mais comuns, tanto de codificação quanto de elegibilidade.
Faça upload de um vídeo, cole seu chave de transmissão do Steam, clique em iniciar. A partir de $0.72/dia.
Comece a transmitir · $0.72/dia