Terminología de "streaming"

Aquí vamos de nuevo

Anteriormente hablé de "transcoding" en Plex, sus ventajas y desventajas. Si te perdiste de leer ese artículo, puedes accederlo aquí.

Ahora voy a hablar un poco de terminología general en cuanto a "streaming" se refiere. Hoy en día es probable que utilices el "streaming" todos los días, y quizás que no te importe la tecnología detrás, pero si te interesa conocer un poco más continúa leyendo.

¿Qué es el "streaming"?

"Streaming" es el término en inglés utilizado para denotar la transmisión constante de contenido multimedia (video, audio o ambos) entregado por un proveedor y recibido por consumidores, donde el contenido puede empezar a ser reproducido sin necesidad de transmitir la totalidad del mismo. El término sólo aplica a medios de telecomunicación a través de redes. La sesión (si así queremos llamarla) que se establece entre el proveedor y el consumidor para hacer el "streaming", se conoce comúnmente como el "stream" (en la representación de la imagen de arriba, cada línea representa un "stream").

Ejemplos de proveedores de "streaming" populares ahora son YouTube, Netflix, Spotify, Facebook, Amazon Prime, Hulu, Pandora, entre otros.

Cliente y servidor

Seguramente has escuchado estos términos muchas veces. Estos conceptos existen en el mundo de la Tecnología de Información (o TI por sus siglas en inglés) desde hace muchos años. En toda interacción digital, por lo general existe un "servidor" que recibe y satisface peticiones de uno o varios "clientes"

Ahora, el término "cliente" y "servidor" se utiliza indistintamente para el "hardware" o para el "software". Por ejemplo, en la imagen de arriba se simboliza la arquitectura cliente-servidor usando "hardware".

Imaginemos que cada uno de esos clientes (pueden ver que son diferentes dispositivos) está haciendo búsquedas en Google, por lo tanto están accediendo a https://www.google.com (o sea al Internet), cada una de las peticiones se redirigen a servidores en Google que regresan los resultados de las búsquedas de regreso a los clientes. Si cambiamos la vista al abstracto mundo del "software", cada uno de esos dispositivos están haciendo las búsquedas en un navegador de Internet (llámese Google Chrome, Safari, Microsoft Internet Explorer, Mozilla Firefox, etc.). Ése navegador de Internet también se le denomina "cliente" o "aplicación cliente". Las peticiones de búsqueda las reciben las computadoras "servidores" en los sitios de Google, las cuales corren programas denominados "servidores web" que se encargan de procesar las peticiones y regresar respuestas a los navegadores web de los clientes.

En el mundo del "streaming", los clientes son los dispositivos que reproducen el contenido multimedia, y los servidores son los dispositivos que tienen el contenido multimedia guardado y que mandan en el "stream" el contenido multimedia en paquetes a los clientes para que comiencen la reproducción lo antes posible.

Los "contenedores" multimedia

Históricamente ha habido muchos tipos de "contenedores" multimedia que han ido evolucionando a través del tiempo, pero su propósito original no ha cambiado. Un "contenedor" es un archivo que, valga la redundancia, contiene uno o más elementos multimedia empaquetados en un solo archivo para facilidad de manejo y distribución.

Puedes ya conocer alguno de los formatos de contenedores multimedia, y mucha gente confunde fácilmente el formato o codec del video con el contenedor. He escuchado gente decir "mi video está en formato AVI" o "está en formato MP4". Eso es incorrecto, la extensión de los archivos te dice el contenedor que está siendo usado, pero el formato o "codec" del video o del audio es punto y aparte.

Como puedes ver en la figura de arriba, se ejemplifica diversos formatos de contenedores y de codecs de video y audio. Un contenedor puede tener "n" cantidad de cada uno de ellos. No todos los contenedores son compatibles con todos los dispositivos, generalmente los contenedores más famosos son los soportados comúnmente.

El famoso "buffering"

Cada vez que ustedes reproducen algún contenido,el servidor intenta protegerse preparando de antemano un "colchón" de datos antes de arrancar el "stream", ya que en internet la velocidad se ve afectada por un sinfín de factores (latencia en la red, ruido en el medio a través del cual los paquetes de datos fluyen, utilización del ancho de banda, y muchos factores más).

Este "colchón" es utilizado entonces para que la transmisión no se detenga en caso que por alguna razón no pueda fluir de manera constante; si el "colchón" es utilizado, éste debe volverse a llenar tan pronto como sea posible para seguir asegurado una transmisión fluida. A ese colchón se le llama "buffer", el hecho de llenar el colchón una vez que se vacía por completo se llama "buffering".

Cuando han visto que la app cliente está "pensando" y muestra un elemento visual que denota una espera, lo que está ocurriendo es "buffering". El uso de un "buffer" es un pilar fundamental en cualquier transmisión de audio o video en tiempo real a través de Internet.

"Buffering" y "transcoding"

Como expliqué en "Transcoding"... lo bueno, lo malo, lo feo, cada operación de "transcoding" demanda grandes cantidades de poder de procesamiento, todo dependiendo de qué está convirtiendo y a qué lo convierte, además de la calidad a la cuál se convierte. 

El procesador tiene que dividir su capacidad de procesamiento entre los diferentes procesos corriendo, entre ellos los de "transcoding"; en algunas ocasiones el "transcoding" para alguno de los "streams" se ralentiza a un grado que no permite que el "buffering" se mantenga al ritmo de la transmisión, la transmisión comienza a utilizar el "buffer" y cuando se lo acaba la transmisión forzosamente debe pausarse.

Quizás tú has experimentado alguna de estas molestas pausas, y la solución más sencilla es detener el "stream" y volverlo a arrancar, lo cual asegura que el "buffer" se vuelva a llenar al 100% y la transmisión continúe como se espera. A veces han tenido que hacer esto no sólo una vez, sino dos o tres, y los entiendo que tan molesto es que  no puedas reproducir algo de manera fluida.

"Buffering" y "bitrate"

El tamaño del "buffer" que se debe llenar en cada transmisión de un "stream" es proporcional a la cantidad de bits utilizados para codificar el video. Los algoritmos de compresión de video utilizan más bits en algunas escenas (con mucho movimiento por ejemplo) y menos bytes en otras (con poco movimiento).

Dada esta variación, se toma un promedio de la cantidad de bits utilizados para codificar el video y se mide en megabits por segundo, o Mbps. Esto es lo que se conoce como "bitrate", que es literalmente la velocidad en la cual una cantidad de bits se transfiere en una cantidad de tiempo. El "bitrate" de un video depende de la resolución del video, y también de la calidad final que se quiere lograr.

Un ejemplo de video con resolución SD (480p), con un bitrate de 1,637 kbps (o 1.59 Mbps):

Otro ejemplo de video con resolución HD (720p), con un bitrate de 3,013 kbps (o 2.94 Mbps):

Un último ejemplo de video con resolución 4K (2160p) con un bitrate de 11,966 kbps (o 11.68 Mbps):

Normalmente el "buffer" a llenar es una constante fija que propone el software que hace el "stream", típicamente un porcentaje del total o una cantidad fija de tiempo (en el caso de Plex, 60 segundos de "buffer"). Aunque pareciera ser una constante, el tamaño del "buffer" depende directamente del "bitrate"; por lo tanto toma más tiempo (o al menos más trabajo de procesamiento) llenar un buffer de un video en 4K que de un video en HD.

Aquí le dejamos

Espero hayas encontrado interesante esta información y que haya sido útil para comprender algunos conceptos utilizados en la tecnología que hay detrás de esa película de Netflix de fin de semana por la noche.

Si te gustaría que hablara de algún tema de tecnología deja un comentario.

¡Saludos!