Codificar un video para transmitir con HandBrake o ffmpeg
16 jul 2026 · 6 min de lectura
Steam no revisa una transmisión antes de emitirla: valida la cuenta, la conexión y la codificación. Si fallas en cualquiera de las tres, la señal se rechaza directamente o se cae a mitad de transmisión sin aviso. Aquí cubrimos las tres: quién puede transmitir, la especificación de codificación publicada por Valve y por qué existe cada ajuste, adónde va realmente la transmisión y qué esperar de forma realista una vez en vivo.
¿Esta cuenta puede siquiera transmitir?
Nada de la codificación que sigue importa si la cuenta no tiene permiso para transmitir, y este es el paso que la gente se salta porque no tiene nada que ver con el video. Steam exige que la cuenta que transmite no sea limitada (al menos $5 gastados históricamente en la plataforma) y que tenga el permiso “Broadcast Live” o esté inscrita en la “Store Broadcast Beta”. La cuenta también tiene que poseer el juego que se transmite o tener acceso a él de otro modo, y no puede tener un bloqueo de comunidad. Si falla cualquiera de estas condiciones, ni una señal H.264 High@4.1 perfectamente válida saldrá en vivo, y desde fuera el fallo es idéntico a una mala codificación: la transmisión simplemente no arranca, sin nada en el log del encoder a lo que culpar. Descártalo antes de pasarte una tarde dudando de tu bitrate. Es una comprobación de cinco minutos frente a un laberinto de codificación de varias horas, y es un seguro barato hacerla primero y no al final.
La especificación de Valve, completa
Todo lo que sigue sale de la propia documentación de Valve en partner.steamgames.com, no de suposiciones. El códec de video tiene que ser H.264, Profile High, Level 4.1. La tasa de fotogramas es de 30 o 60 FPS, la relación de aspecto es 16:9 y el intervalo de fotogramas clave tiene que ser de 2 segundos. El bitrate máximo es de 7000 kbps CBR. El audio es AAC-LC, con un máximo de 128 kbps. Nada de esto es una sugerencia: Valve valida la transmisión con estos valores al conectarse, y un campo fuera de especificación es la razón por la que una transmisión que se ve bien en tu encoder nunca sale en vivo. Cubrimos los mismos números con más contexto en especificaciones de video y codificación para Steam.
Conectar con Steam: la parte RTMP
Codificar según la especificación te da una señal válida; aún tienes que enviarla a algún sitio, y esta parte da menos problemas porque es más sencilla que los ajustes de codificación, no porque no esté documentada. La ingesta de transmisiones de Steam es un endpoint RTMP estándar: rtmp://ingest-rtmp.broadcast.steamcontent.com/app. No eliges tú la región: Steam elige el servidor de subida real según la ubicación de la cuenta, igual que elige los servidores de descarga para instalar juegos. La clave de transmisión se genera en steamcommunity.com/broadcast/upload, en “Create RTMP Token”. Al crearla, seleccionas el ID de la aplicación base del juego, no un DLC ni una demo, ya que la transmisión se asocia a la aplicación base sin importar qué edición estés promocionando.
OBS es el software que la mayoría usa para probar esto, pero no tiene nada especial para Steam: cualquier encoder compatible con RTMP se conecta igual, ya sea OBS, vMix, un equipo hardware o ffmpeg enviando directamente a la URL de arriba con tu clave de transmisión. En términos de OBS, es el servicio de streaming “Custom”, con la URL de ingesta en el campo Server y la clave en el campo Stream Key. A la capa RTMP no le importa qué generó los bits, solo que cumplan la especificación de Valve cuando llegan.
Algo que conviene revisar si la conexión en sí no se establece, aparte de cualquier cosa de la codificación: RTMP usa por defecto el puerto TCP 1935. En una conexión doméstica rara vez es un problema, pero en una red de oficina, una VPN corporativa o una VM en la nube restringida, el puerto 1935 de salida puede estar bloqueado por un firewall que no tiene problema con el tráfico web normal en 80 y 443. Si el encoder no llega a la URL de ingesta en absoluto (no una transmisión rechazada, sino ninguna conexión), es lo primero que hay que descartar antes de suponer que el problema está en Steam.
El ajuste que falla sin remedio: el intervalo de fotogramas clave
La mayoría de los campos de la especificación toleran pequeñas desviaciones: un bitrate algo por encima del techo puede que simplemente lo limite la ingesta de Steam. El intervalo de fotogramas clave no funciona así. Valve deja claro que si no es exactamente de 2 segundos, tu transmisión no arrancará. Sin medias tintas.
Un intervalo de fotogramas clave de 2 segundos significa que se codifica un fotograma completo cada 2 segundos, y los fotogramas intermedios hacen referencia a él. A 30 fps eso es un GOP de 60 fotogramas; a 60 fps, de 120. La mayoría de los encoders usan otro valor por defecto, a menudo 4 o 5 segundos, pensado para el tamaño del archivo y no para cumplir con un directo, así que este es el ajuste que la gente pasa por alto aunque todo lo demás esté bien. Valve menciona vMix por su nombre: su configuración por defecto es Main Profile con Level 3.0, y esa combinación hay que cambiarla para que una salida de vMix sea aceptada. Tómalo como aviso de que los valores por defecto de tu propio encoder probablemente tampoco coinciden con los de Steam, y revísalos explícitamente en lugar de suponerlo.
Por qué bitrate constante y no variable
La especificación de Valve pide CBR, no VBR, y el motivo es propio del streaming en vivo, no de la calidad de video en general. El bitrate variable permite al encoder gastar más bits en los fotogramas complejos y menos en los simples, lo que es ideal para un archivo que verás una vez de principio a fin. Un servidor de ingesta en vivo tiene que gestionar su búfer contra una tasa de datos esperada más o menos constante; una transmisión que oscila de 2000 kbps a 9000 kbps y vuelve hace que ese búfer se vacíe o se desborde, y cualquiera de las dos cosas se nota como tirones o una conexión caída. CBR sacrifica algo de calidad en las escenas simples a cambio de una tasa de datos con la que la ingesta puede contar, que es justo lo que necesita una transmisión 24/7.
7000 kbps es el techo documentado por Valve, no un objetivo. Ir justo al límite no deja margen si tu material supera brevemente la tasa fijada, algo normal en un encoder incluso en modo CBR. Un objetivo más seguro es codificar un par de cientos de kbps por debajo del techo: 6000 kbps es una opción razonable, y es la que usamos por defecto por la misma razón.
Qué hace Steam con tu señal tras la ingesta
Conviene saber qué pasa con la señal una vez aceptada, sobre todo para no sobredimensionar algo que Steam ya resuelve. Cuando una transmisión supera unos 10 espectadores simultáneos, Steam activa automáticamente la transcodificación y genera versiones de menor resolución (720p, 480p y 360p) junto a tu señal original en 1080p. Todo ocurre en el servidor; nunca subes más de una señal ni configuras tú una escalera de resoluciones. La única señal CBR descrita arriba es la única codificación de la que eres responsable. Si vienes de plataformas donde envías tú varias variantes de bitrate, aquí puedes olvidarte de eso: una señal limpia en 1080p con la especificación de arriba es todo el trabajo, y eso también significa que la calidad de esa señal importa más, no menos, porque es el máster del que sale todo lo demás por debajo del umbral de transcodificación.
Codificar en HandBrake
HandBrake te dará una salida válida, pero los campos que importan para Steam quedan fuera de sus presets por defecto. Pon el contenedor en MP4 y el códec de video en H.264 (x264). En Framerate, elige tu objetivo (30 o 60) y ponlo en Constant, no Variable. Para el control de tasa, usa Average Bitrate a 6000 kbps en lugar de un modo basado en calidad (CRF), ya que CRF produce bitrate variable por diseño.
El perfil, el nivel y el intervalo de fotogramas clave están en la cadena de opciones x264 de la pestaña Advanced. Pon Profile en High y Level en 4.1 en sus propios desplegables, y luego añade keyint=60:min-keyint=60 a la cadena de opciones para 30 fps, o keyint=120:min-keyint=120 para 60 fps: es tu intervalo de 2 segundos expresado en fotogramas. En la pestaña de audio, codifica a AAC a 128 kbps.
Lo mismo en ffmpeg
Si prefieres hacerlo con un script, cada campo de arriba corresponde a un flag. Esto codifica según la especificación a 30 fps con un objetivo de 6000 kbps y un 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
La combinación que merece explicación es -b:v, -maxrate y -bufsize con valores iguales o relacionados: eso es lo que hace que libx264 se mantenga de verdad en CBR en lugar de derivar hacia su comportamiento por defecto, parecido a VBR. -g 60 es la longitud del GOP para 30 fps (usa 120 a 60 fps), y -sc_threshold 0 impide que el encoder inserte un fotograma clave extra en los cambios de escena, lo que rompería el intervalo fijo de 2 segundos que exige Valve.
Revisa tu salida antes de enviarla en vivo
En lugar de confiar en que tu encoder hizo lo que le pediste, conviene revisar el archivo antes de enviarlo a la ingesta de Steam. ffprobe, que viene con ffmpeg, muestra el perfil, el nivel y la tasa de fotogramas reales que encuentra en la salida, no los que pediste:
ffprobe -v error -select_streams v:0 -show_entries stream=profile,level,r_frame_rate,bit_rate -of default=noprint_wrappers=1 output.mp4
Eso te muestra exactamente lo que quedó grabado en el archivo: si el perfil dice “Main” en lugar de “High”, o el nivel aparece como 3.1 en lugar de 4.1, lo sabrás antes de que Steam te lo diga por las malas. La longitud del GOP cuesta un poco más de confirmar directamente, pero una comprobación aproximada es contar los paquetes de video de los primeros segundos; a 30 fps con un intervalo de 2 segundos deberías ver un fotograma clave más o menos cada 60 fotogramas. Es un paso pequeño, pero convierte “la transmisión fue rechazada, ¿y ahora qué?” en “el nivel está mal, corrige ese campo”, un ciclo de depuración mucho más corto.
Latencia: qué esperar de verdad
Valve no publica una cifra oficial de latencia para las transmisiones de la tienda, así que toma cualquier dato que leas sobre esto, incluido este, como una cifra reportada, no una especificación. Con esa salvedad: los usuarios suelen reportar una latencia de unos 30 segundos en las transmisiones de la tienda, frente a unos 15 segundos en Twitch. Las notas de parche de Valve han hablado de una latencia de menos de 1 segundo, pero específicamente para transmisiones 1 a 1 entre amigos, no para la señal de la página de la tienda, y algunos usuarios dicen que esa mejora nunca llegó a las transmisiones de la tienda. Toma la cifra de ~30 segundos como un número aproximado reportado por la comunidad, no como algo que Valve respalde por escrito.
Para un video pregrabado en bucle, nada de esto importa en la práctica. La latencia solo es un problema cuando alguien al otro lado necesita interactuar con lo que pasa en vivo: leer el chat, reaccionar en tiempo real, sincronizar una cuenta atrás. Un loop 24/7 de un tráiler o un reel de gameplay no tiene nada en vivo que se pueda desincronizar, así que un retraso de 30 segundos es invisible para quien solo mira tu página de la tienda. Solo es una limitación real si intentas emitir algo interactivo por la misma conexión; consulta cómo emitir un video pregrabado en bucle para ver qué funciona bien en bucle y qué no.
O sáltate el encoder por completo
Todo lo anterior existe porque la ingesta de Steam no perdona en la codificación, no porque los números sean difíciles de encontrar. Con Loopcast subes el archivo que tengas y lo transcodificamos automáticamente a 1920x1080 a 30 fps, con un intervalo de fotogramas clave de 2 segundos, 6000 kbps CBR y audio AAC-LC a 128 kbps y 44.1 kHz: la misma especificación de arriba, aplicada sin que toques un ajuste de códec ni una URL RTMP. Cuando tengas una clave de transmisión de Steam, consulta cómo obtener tu clave de transmisión de Steam para conectarla, y si alguna vez una transmisión se niega a arrancar, solución de problemas de transmisión cubre las causas más comunes, tanto de codificación como de elegibilidad.