Historia del streaming

1.- Streaming Tradicional

2.- Descarga Progresiva

3.- Streaming Adaptativo

Existen protocolos de video adaptivos y no adaptivos

HLS

Fue creado por apple en 2009. Significa HTTP live streaming. Es adaptativo y
funciona en formato H.264. El archivo se fragmenta en pequeñas partes, sirve tanto
para live como para on demand. Durante el streams se puede cambiar de calidad
sin reinicar el stream, por eso se llama adaptativo, ademas se le puede implementar
seguridad.
Orientado a equipos Apple

RTMP

Realiza streaming entre un programa Flash player y un servidor, de archivos de

audio, video y datos en internet. Este protocolo trabaja sobre TCP y usa, por
defecto el puerto 1935. Desarrollado por Macromedia actualmente pertenece a
Adobe. Con el auge del HTML5 tiende a desaparecer.

RTSP/RTP

(Real-Time Streaming Protocol). No es adaptivo lo que quiere decir que desde el

primer momento se envia una calidad y ya no se puede cambiar hasta el reinicio de
la visualización. Los paquetes se transmiten via UDP lo que significa que puede
causar problemas con los firewalls.
MPEG-DASH

(Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP) se espera

sea la solución del futuro logrando aunar las diferentes tecnologías y pudiendo ser
útil para todos los dispositivos. Los tres protocolos presentados anteriormente,
Smooth Streaming, HDS y HLS, permiten la distribución de vídeo por Internet de
forma adaptativa, pero cada uno exige un encapsulamiento diferente. Para tratar de
evitar incompatibilidades entre los distintos protocolos y los dispositivos que utilizan
los usuarios, surge MPEG-DASH (Dynamic Adaptive Streaming over HTTP). La idea
es tratar de converger y simplificar la distribución de vídeo por Internet de forma
adaptativa, reutilizando la tecnología ya existente.

HSS Microsoft smooth streaming

Tambien denominado ISS smooth streaming, forma parte de los servicios ISS
Media Services. Forma parte de la familia de los protocolos adaptivos.

Ofrece la experiencia de video en línea más confiable y de más alta calidad para
contenido en demanda y eventos en vivo. Al utilizar HTTP basado en estándares
para aprovechar los recursos masivos de almacenamiento en caché HTTP existentes,
Smooth Streaming aprovecha la escala de HTTP para proporcionar experiencias de
alta definición completa (hasta 1080p) a los reproductores de medios basados en
Silverlight.

La especificación del protocolo IIS Smooth Transport Transport describe cómo se

distribuye y almacena en caché el contenido de audio / video en vivo y bajo demanda
de Smooth Streaming en una red HTTP. Esta especificación se publica bajo la
Iniciativa de Promesa de la Comunidad, para permitir a terceros que deseen
construir sus propias implementaciones de clientes que interactúen con los Servicios
de Medios de IIS.

Principalmente enfocado a Pc`s, Tv, Xbox y Windows Phone.

HDS

HDS (HTTP Dynamic Streaming) es la solución de Adobe para la transmisión de

vi ́deo por Internet.

HDS presenta una novedad respecto a los dos protocolos anteriores ya que introduce
un nuevo concepto, define una unidad de contenido más pequena ̃ que denomina
fragmento. Un fragmento es una unidad descargable que contiene un intervalo de
vi ́deo o audio (de unos 4 segundos según el estándar [16]). Se identifican por un
número y se pueden agrupar en segmentos. Los números de los fragmentos, al igual
que ocurre en HLS, se van incrementando progresivamente según va avanzando el
contenido del stream.

Protocolo HLS

HLS utiliza vídeo H.264 MPEG-2 TS segmentado y archivos descriptores M3U8 para
difundir el vídeo en directo y a la carta con tasas de bits adaptativas. Un archivo
M3U8 es un índice que permite al cliente saber qué secuencias y segmentos están
disponibles en un momento dado. El dispositivo selecciona automáticamente la
secuencia más adecuada desde el archivo de manifiesto primario teniendo en cuenta
las limitaciones de ancho de banda y de CPU. A continuación, descarga el segmento
y lo añade al búfer de reproducción.

Como su nombre da a entender, HLS transmite datos a través de HTTP, ofreciendo

diversas mejoras sobre los protocolos de transmisión tradicionales.

Beneficios:

 Reducción de los costes de infraestructura

 Posibilidad de almacenamiento en memoria caché en redes CDN y otras
infraestructuras de caché HTTP
 Reducción de las amenazas procedentes de restricciones de proxy y cortafuegos
 Optimización en tiempo real mediante heurística en el equipo cliente (tasa de bits
adaptativa)
 Redundancia integrada
 Implementación sencilla de reproductores HTML5
 Cifrado AES-128 para seguridad de los contenidos
 Subtítulos CEA-608 en la secuencia de transporte
 Vídeo en directo y a la carta
 Las pistas de audio pueden contener una imagen fija, como carátulas de un vídeo
o capturas de pantalla.
 Metadatos de la secuencia, como metadatos cronometrados utilizando el formato
ID3

Consejos para la transmision:

Utilice audio HE-AAC. El audio AAC estándar (llamado a menudo AAC-LC) suena muy
bien con tasas de bits de 96 kbps y superiores, pero con tasas de bits inferiores se
percibe la compresión. Esto es importante para la retransmisión de secuencias HTTP
en directo, ya que la tienda App Store exige secuencias de 64 kbps para la mayoría
de aplicaciones. El perfil HE-AAC ("High Efficiency AAC") está optimizado para tasas
de bits bajas y suena mucho mejor que AAC-LC en el rango de 64 kbps, tan
importante para HLS.

Apple recomienda mantener en todo momento los mismos parámetros de audio para
evitar contratiempos. Si el audio cambia de una secuencia a otra, se pueden producir
saltos y clics audibles provocados por la conmutación entre las tasas de bits de
audio. Si necesita proporcionar diferentes tasas de bits de audio para mejorar la
calidad de determinadas secuencias, mantenga al menos una tasa de muestreo
estándar.

La tasa de fotogramas clave debe ser un intervalo par del tamaño del segmento. Por
ejemplo, si el tamaño del segmento es de 10 segundos, la tasa de fotogramas clave
debe ser de 2 segundos, 2,5 segundos, 3,33 segundos, 5 segundos o 10 segundos.
Algunos codificadores, como Zencoder, colocan automáticamente los fotogramas
clave en los lugares apropiados. Utilice la función force_keyframe_rate de Zencoder
para garantizar una alineación correcta de fotogramas clave entre las sucesivas
secuencias.
Tenga en cuenta los datos de encabezado del formato. El formato MPEG-TS utiliza
una gran cantidad de rellenos innecesarios. Con un muxer TS no optimizado, HLS
puede generar archivos notablemente mayores que sus equivalentes para MP4,
generalmente hasta un 10 o 20 % mayores. Tanto Zencoder como Apple utilizan
muxers TS altamente optimizados que minimizan los datos TS superfluos.

Tasa de bits Datos

solicitada superfluos

HLS optimizado por Zencoder 364 kbps 4,83 %

HLS no optimizado 364 kbps 16,34 %

Considere la posibilidad de limitar los picos de la tasa de bits para asegurar un buen
funcionamiento de la secuencia. Recomendamos establecer una tasa de bits máxima
(bitrate_cap) equivalente a un 150 % de la tasa de bits media dentro de un búfer
de 3 a 5 segundos

El valor de streams debe contener toda la información pertinente. Esto es

especialmente importante al ofrecer varios perfiles H.264 para incluir el valor del
códec correcto. Estos ajustes impiden que los dispositivos más antiguos descarguen
accidentalmente segmentos que no pueden descodificar. Por ejemplo, utilice los
valores “avc1.42E01F, mp4a.40.2” para el perfil Baseline 3.0 y “avc1.42E01F,
mp4a.40.2” para Main 3.1.
Arquitectura de la tecnologia:

Posibles calidades de video:

Sabemos la exigencia de nuestra audiencia, están acostumbrados y esperan

consumir videos en la mejor calidad posible, con el protocolo HLS lo podemos lograr,
y que soporta una compresión de video h.264 o h.265, con esto podremos enviar
una calidad de video desde un tamaño estándar (420p), HD (720p) Full HD (1080p)
¡hasta 4k!
Como funciona:

Primero el archivo de video se debe codificar con compresión de video H.264 y

compresión de Audio AAC. Posteriormente se debe seleccionar MPEG2-TS como
contenedor de video, esto lo hace normalmente un encoder de video.
Una vez codificado el video se realiza un proceso de segmentación. Este proceso
realiza cortes del video cada ciertos segundos, usualmente cada 10 segundos. A
estos fragmentos se les conoce como segmentos o chunks de video.

Dentro del sitio de desarrollo de apple se pueden descargar herramientas para

preparar los segmentos de HLS.

Cuando se decide encriptar la información, se debe ejecutar un algoritmo para

proteger cada uno de los segmentos. Y sólo el player que tenga la llave para
desencriptarlos podrá ver el contenido. Estas llaves pueden ser estáticas o
dinámicas, puede generarse una llave para todos los videos o una llave por video.
Y lo único que hace falta es compartir el URL del archivo índice que es algo como:

http://localhost/videodeprueba/video.m3u8

CASO DE USO “TWITCH”:

El sistema de video es responsable de hacer llegar el video de la emisora a nuestros

televidentes. Esto incluye los siguientes componentes principales:
Ingesta de video: tomamos el video RTMP y luego lo transportamos al sistema de
transcodificación.
Sistema de transcodificación: tomamos el flujo RTMP entrante de la emisora y lo
transcodificamos en múltiples flujos HLS. Esto se implementa a través de una
combinación de C / C ++ y Go.
Distribución y borde: distribuya las transmisiones de HLS a nuestros POP
geográficamente diferentes, de modo que tenga la experiencia de transmisión de
video de la más alta calidad. Una vez más, en su mayoría escrito en Go.
VOD (Video a pedido): tomamos todos nuestros sistemas de video entrantes y los
archivamos para nuestro sistema VOD.