Velocidad de subida para streaming: lo que no revela una descarga rápida

La comparación resulta especialmente útil en los intervalos de descarga más altos. El 1 de octubre de 2026, casi una cuarta parte de los pares incluidos con descargas de 100 a menos de 300 Mbps tuvo una subida inferior a 14,128 Mbps. Una semana después, la proporción fue algo menor: el 23,4%. Incluso en el intervalo que empieza en 300 Mbps, las proporciones fueron del 9,6% y el 8,8%, respectivamente.

Cada porcentaje tiene un denominador distinto según el intervalo y la fecha. La tabla muestra los cuatro intervalos para situar los resultados más rápidos en contexto. Son velocidades de descarga medidas, no las anunciadas en una tarifa de internet.

En ambos días, las subidas inferiores a 14,128 Mbps fueron menos frecuentes en cada intervalo de descarga sucesivamente más alto. Esa relación es útil, pero los casos que siguen apareciendo explican por qué comprobar solo la descarga deja parte del trabajo pendiente. Estar en un intervalo de descarga más rápido no significaba que todas las subidas emparejadas superaran el bitrate elegido.

Para la empresa que prepara su demo, el siguiente paso útil es conservar los dos números de la prueba. Si la subida es mucho menor que la descarga, conviene probar la emisión con el equipo real antes de decidir si cambiar de formato o pagar por otra conexión.

La referencia elegida importa. La guía de codificación de YouTube recomienda 14 Mbps de vídeo H.264 para 1080p a 30 fotogramas por segundo, más 128 Kbps de audio estéreo. La suma es 14,128 Mbps. Esa misma guía indica un mínimo de vídeo H.264 más bajo, de 5 Mbps, para esa resolución y frecuencia de imagen.^[2]

Una recomendación de bitrate de vídeo y audio codificados no es una velocidad mínima de internet. Nuestra medición es otra cosa: una transferencia breve a un servidor de M-Lab. Su tasa se calcula a partir de bytes TCP y tiempo transcurrido en el servidor, no de una emisión sostenida a YouTube.^[3][6][7]

Por tanto, la tabla compara dos magnitudes; no es una prueba de aprobado o suspenso. Un resultado inferior a la referencia es un motivo para revisar la configuración prevista. No demuestra que una emisión concreta vaya a fallar. Superarla tampoco certifica que el evento saldrá bien. Siguen importando la ruta hasta el servicio de streaming, los cambios durante el evento, el resto del tráfico y el dispositivo que ejecuta el codificador.

Esta distinción también protege el presupuesto. Un equipo que interprete 14,128 Mbps como un requisito universal de compra podría gastar antes de comprobar sus ajustes y su funcionamiento real. Otro que interprete superar esa referencia como una garantía podría saltarse el ensayo. Ninguna de las dos conclusiones se desprende de estas mediciones.

La secuencia más útil es elegir los ajustes de imagen, movimiento y sonido, anotar su bitrate y probar la emisión real. Este análisis no propone un multiplicador fijo de ancho de banda ni recomienda contratar una conexión superior.

Comprobamos si el hallazgo dependía de una única configuración de referencia. Fijamos previamente otras dos comparaciones, de 10,128 y 17,128 Mbps, a partir de otros ajustes de codificación recomendados en la misma tabla de YouTube.^[2] Los resultados completos están en el análisis descargable.

En el intervalo de descarga de 100 a menos de 300 Mbps, la referencia más baja dio proporciones del 18,9% el 1 de octubre y del 18,1% el 8 de octubre. Con la referencia más alta, fueron del 28,0% y el 26,8%. Los denominadores siguieron siendo 212.675 y 194.290 pares. En el intervalo de 300 Mbps o más, las proporciones correspondientes fueron del 7,9% al 11,0% el 1 de octubre y del 7,1% al 10,2% el 8 de octubre, con 237.588 y 221.617 pares. La configuración cambia la comparación, por lo que no existe un único porcentaje para «streaming».

También repetimos el cálculo excluyendo cualquier par cuyo resumen de subida o descarga tuviera valor cero. Algunas vías de procesamiento de la fuente pueden devolver cero cuando faltan las mediciones finales; por eso, un cero en el resumen no demuestra automáticamente que una transferencia no enviara nada.^[6] En el intervalo de 100 a menos de 300 Mbps, el resultado pasó a 51.313 de 212.136 pares (24,2%) el 1 de octubre y a 45.047 de 193.832 (23,2%) el 8 de octubre. En el de 300 Mbps o más, pasó a 22.122 de 236.909 (9,3%) y a 18.764 de 220.928 (8,5%), respectivamente. Eliminar los ceros cambió cada porcentaje de los cuatro intervalos principales en menos de 0,3 puntos porcentuales en ambos días. La diferencia relevante para la preparación se mantuvo.

Hubo un cambio mayor dentro de un grupo de software del servidor. Para la versión v0.25.2, en el intervalo de 300 Mbps o más, la proporción de subidas inferiores a 14,128 Mbps bajó de 4.803 de 26.338 pares (18,24%) el 1 de octubre a 1.418 de 21.217 (6,68%) el 8 de octubre. Esta diferencia merece aparecer junto al resultado principal. Explica por qué un porcentaje de este análisis no debería convertirse en una regla universal de planificación.

Eso no demuestra que el software causara el cambio. La combinación de redes, dispositivos, rutas y clientes de medición puede variar entre días. Un mismo cliente puede aparecer varias veces, incluso en ambas fechas. Publicamos todos los desgloses por tramo horario, biblioteca del cliente y versión del servidor para que se pueda examinar esa variación sin depender únicamente de una cifra global.^[1]

Empieza por mantener visible el resultado de subida. Anota dónde y cuándo se hizo la prueba, qué dispositivo y conexión se usaron y qué más estaba ocurriendo en la red. Así será más fácil interpretar el resultado después. También evitarás tratar una lectura de un lugar como prueba de lo que ocurrirá en otro.

Después, ensaya la parte de la demo que más exige al montaje real. En una explicación de producto, puede ser compartir pantalla mientras hablas y alternar entre la cámara y el producto. En una demostración física, puede incluir movimiento y primeros planos detallados. Usa el codificador, la cuenta, la plataforma y la conexión previstos para que el ensayo responda a la pregunta del evento. YouTube también aconseja probar con audio y movimiento representativos y vigilar el estado de la emisión.^[2]

Pon nombre a cada escena representativa en las notas del ensayo: apertura con cámara, demostración en primer plano, recorrido con pantalla compartida, preguntas del público. Anota cuándo empieza cada una y qué detalles debería poder ver u oír quien observa. Si aparece un problema, registra la escena, la hora y el síntoma visible o audible para que quien presenta y quien observa puedan comparar sus notas.

Separa las observaciones de las explicaciones. «La imagen se entrecortó al compartir pantalla» es una observación que merece anotarse. «Lo causó nuestro proveedor de internet» es un diagnóstico que necesita más pruebas. Una medición breve de M-Lab no identifica la causa de un problema visto en otra ruta hasta el servicio de streaming.

Si el ensayo revela un problema, cambia una parte del montaje y vuelve a probar. Repite la misma escena y anota qué ajuste cambiaste, qué condiciones se mantuvieron y qué vio cada observador. Registra también las diferencias inevitables, como otro dispositivo que se conecte a la red. Una segunda prueba mejor aporta información útil sobre ese intento; no aísla una causa si también cambiaron otras condiciones. Si cambias de formato, prueba el nuevo en lugar de apoyarte en el resultado anterior.

Por último, decide qué debería recibir el público si se interrumpe la demo en directo. Un vídeo preparado o una explicación escrita pueden mantener la información disponible mientras el equipo atiende la interrupción. Encarga a alguien que tenga ese material accesible durante el evento. Nuestra plantilla de guion de vídeo puede ayudarte a preparar la demostración, y nuestro estudio sobre marketing para desarrolladores y documentación aborda una cuestión relacionada: qué material útil colocar junto a un vídeo.

Imagina una empresa ficticia de software de cinco personas que prepara una demostración en directo para empezar a usar el producto. Sus lecturas supuestas son de 180 Mbps de descarga y 11 Mbps de subida. Estas cifras ilustran la ficha; no corresponden a una empresa observada en los datos de M-Lab.

El equipo quiere usar vídeo H.264 a 1080p y 30 fotogramas por segundo, con audio estéreo. Su lectura de subida queda por debajo de la referencia recomendada de 14,128 Mbps utilizada en este estudio. Anota esa lectura junto a los ajustes previstos del codificador para compararla con lo que observe durante la demostración.

El equipo programa un ensayo con el mismo portátil, conexión, codificador y secuencia de presentación previstos para el evento. Una persona presenta, otra comprueba lo que ve el público y una tercera anota la información sobre el estado de la emisión que ofrece la plataforma y cualquier interrupción visible o audible. Incluyen el tramo de pantalla compartida en el que los clientes necesitan leer detalles pequeños de la interfaz.

Antes de probar, acuerdan cómo responderán si el ensayo no resulta satisfactorio: elegir otra configuración, volver a probarla y preparar un vídeo corto y pasos por escrito por si necesitan otro formato de entrega. No damos por hecho que el ensayo salga bien ni que mejore el rendimiento. El ejemplo termina con un plan concreto para obtener la información que falta.

Empieza por el evento. Copia la ficha completa en tus notas sin necesidad de registrarte y guárdala junto al guion. Identifica al público, el lugar, la fecha y la hora previstas, quién presenta y quién comprobará la vista del público. Señala el momento que los espectadores necesitan ver u oír con mayor claridad.

Describe el montaje previsto. Anota la plataforma de streaming, el dispositivo, el codificador y la conexión; después, la resolución, los fotogramas por segundo, el códec de vídeo y los bitrates configurados de vídeo y audio. Registra otras actividades previstas en el dispositivo o la red para que las notas describan las condiciones del ensayo.

Conserva la prueba de velocidad por separado. Anota su fecha, hora, lugar y herramienta, además de las lecturas de descarga y subida con sus unidades. Indica en qué se diferencia esa prueba del montaje previsto para emitir. Sin contexto, a un compañero le resultará más difícil interpretar la lectura más adelante.

Documenta el ensayo. Describe la secuencia probada, incluido el movimiento, el sonido y la pantalla compartida. Reúne las observaciones de la vista del público y las del estado de la emisión en la plataforma. Si cambiaste un ajuste, anota qué ocurrió en la siguiente prueba. Completa estos campos después de probar; deja señaladas las comprobaciones pendientes y asigna una persona a cada una.

Decide cómo se hará la presentación. Anota el formato y los ajustes elegidos después del ensayo, junto con los motivos. Identifica el material alternativo preparado por si se interrumpe la demo y quién comunicará un cambio al público. Después del evento, mantén disponible la explicación útil. Una plantilla de descripción de YouTube puede ayudarte a organizar el vídeo y los enlaces complementarios para los clientes que no pudieron asistir.

Usamos la vista pública de unión NDT7 de M-Lab para registros geolocalizados en Estados Unidos del 1 y el 8 de octubre de 2026. Cada par incluido tenía exactamente un registro de subida y uno de descarga con el mismo token de autorización y la misma identidad de servidor. Sus inicios debían estar separados por un máximo de 60 segundos y caer dentro del día UTC elegido. Otras comprobaciones cubrieron los tiempos, los identificadores de conexión y las versiones de la fuente.^[1][3]

Tras estas comprobaciones y la exclusión de tasas no válidas, el análisis conservó 745.186 pares el 1 de octubre y 698.882 el 8 de octubre. Los registros sin pareja de subida o descarga se excluyeron; nunca se completaron con un cero. Cada porcentaje de la tabla divide el número de pares con subida inferior a la referencia entre los pares conservados en el intervalo de descarga de esa fecha.

Estudios anteriores ya han emparejado observaciones de subida y descarga de M-Lab y examinado su contexto.^[4] Nuestra aportación es esta comparación fechada y reproducible para una cuestión práctica de preparación de emisiones. Describe las mediciones seleccionadas, no la prevalencia de subidas lentas entre empresas o creadores de Estados Unidos.

La descarga sin registro contiene el protocolo fijado, las consultas exactas, las notas de las fuentes, los recuentos completos de selección y las 264 celdas de resultados previstas para cada día.^[8] Incluyen desgloses que se solapan, no 264 estudios independientes. El script sin conexión reproduce los cálculos agregados; volver a ejecutar las consultas sobre la fuente es otro paso. Para la próxima demo, la acción práctica es más sencilla: conserva la lectura de subida, ensaya la presentación real y decide cómo hacerla a partir de lo que observe el equipo.