DIFUSIÓN DE VÍDEO EN LA WEB

Anuncio
CODIFICACIÓN Y TRANSMISIÓN DE VÍDEO:
DESDE LA CÁMARA A LA WEB, TV Y CINE
ALBACETE, 7 y 8 de JULIO de 2014
Antonio
Leal
DIFUSIÓN
DE VÍDEO EN
LA WEB
QUÉ ES el STREAMING
Transferencia de datos multimedia a través de una red de datos, que se procesa como un flujo
regular y continuo, en paralelo mientras se descarga
VENTAJA
No es necesario
esperar la descarga del
vídeo para comenzar a
visualizarlo
LA IDEA ES “REPLICAR” UNA EMISIÓN TÍPICA DE TELEVISIÓN
• Reproducción “inmediata”
• Utilización de buffer
• Retransmisión en directo
PROBLEMAS del STREAMING
TELEVISIÓN
TVE1 ES LA MISMA
PARA TODOS
SISTEMA OPERATIVO
NAVEGADOR
REPRODUCTOR
CODECS
ANCHO DE BANDA
USUARIO
Tal cantidad de variables hacen que no resulte trivial conseguir un streaming que funcione “para todos”
ADQUISICIÓN
CODIFICACIÓN
ENTREGA
De la señal en directo o del
contenido previamente
grabado
Uno o varios formatos y
calidades
Descarga total, progresiva,
streaming “real”
FASES DEL
STREAMING
DIAGRAMA BÁSICO DE LAS TRES GRANDES FASES EN EL PROCESO DE STREAMING
QUÉ ES un CODEC
Compresor/descompresor
Especificación software o hardware que codifica flujo o señal (pérdidas)
• H264
ASIMÉTRICO
• VP8
Descompresión mucho
más rápida que
compresión
• THEORA
• MP3
• ACC
• VORBIS
¿ CUÁL DEBEREMOS UTILIZAR ?
QUÉ ES un CONTENEDOR
Puede contener múltiples tipos de codecs (audio, vídeo) así como subtítulos, música, animación…
Identifica, combina y sincroniza los distintos elementos
CRÍTICO AL
REPRODUCIR
Fuente de problemas
• MOV
• AVI
• OGG
• MP4
• FLV
¿ CUÁL DEBEREMOS UTILIZAR ?
QUÉ ES un FORMATO DE VÍDEO
Combinación de un contenedor y de un conjunto específico de codecs
Ejemplo
Vídeo codificado en
H.264 encapsulado en
MP4 y con audio AAC
Contenedor MP4
Codec H.264
720x480, 25 fps, campo superior primero
2-Pasasadas VBR, 3 MB tasa datos
ACC audio
Estéreo, 16 bits por muestra, 48 khz frecuencia
muestreo, 128 kbps tasa de datos
LA COSA SE COMPLICA…
HERRAMIENTAS DE CODIFICACIÓN (ESCRITORIO)
MEDIA ENCODER
COMPRESSOR
HANDBRAKE
(ADOBE)
(APPLE)
(OPEN SOURCE Y GRATUITO)
HERRAMIENTAS DE CODIFICACIÓN (ON LINE)
FAMILIARIZÁNDONOS CON LA COMPRESIÓN
CONTROLES HABITUALES
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
TAMAÑO
MÁS NO ES SIEMPRE
MEJOR
-
Reducir tamaño de fotograma
-
Nunca superar tamaño original
-
Número de píxeles = múltiplo del ancho por el alto (640x480 cuadruplica 320x240)
-
En general a más píxeles más carga de procesamiento para codificar ( a veces no, logo pequeño sobre
cuadro color sólido en H.264 se comprime igual que mismo logo sobre fondo más grande)
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
TAMAÑO
MÁS NO ES SIEMPRE
MEJOR
-
Por cómo funciona compresión  tamaño siempre divisible por 16 (pero no alterarlo, salvo crop)
-
Cuidado con la relación de aspecto
-
Si la fuente tiene píxeles con relación de aspecto <> 1 el tamaño del destino ha de traducirse a lo que
sería si fuesen cuadrados
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
RELACION
DE ASPECTO
RELACIÓN ANCHURA Y ALTURA
-
Pixel Aspect Ratio (PAR)
-
Storage Aspect Ratio (SAR)
-
Display Aspect Ratio (DAR)
-
PAR x SAR = DAR
ESTÁNDAR = 4:3
PANORÁMICA = 16:9
VGA 640 x 480
HD 1280 x 720
PAL 720 x 576
HDV 1440 X 1080
FULL HD 1920 x 1080
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
RELACION
DE ASPECTO
RELACIÓN ANCHURA Y ALTURA
ESTÁNDAR = 4:3
PANORÁMICA = 16:9
VGA 640 x 480
HD 1280 x 720
PAL 720 x 576
HDV 1440 X 1080
FULL HD 1920 x 1080
Por ejemplo, para una imagen de 640x480, el SAR sería 640/480 = 4:3. Si queremos
visualizar en una pantalla 4:3, el DAR sería 4:3, luego necesitaríamos PAR 1:1, píxeles
cuadrados
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
FPS
CONSERVAR
LA ORIGINAL
-
PAL 24 fps, NTSC 29,97 fps, tutoriales 6 fps
-
Más fps  Más suavidad de movimiento (concierto) pero – calidad/tasa de bits
-
Menos fps  Menos carga, luego más “espacio”, luego mejor calidad (peor movimiento)
-
Cifras pares (sincronización)
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
PERFIL
CONJUNTO DE
CARACTERÍSTICAS QUE PUEDE
USAR EL CODIFICADOR PARA
LIMITAR SU COMPLEJIDAD
-
Eficiencia vs rendimiento
-
Depende de aplicación final del vídeo
-
Más complejidad  Más calidad/tasa de bits pero más recursos (problemas compatibilidad)
-
Línea de Base  vídeos “ligeros” (videoconferencia, móviles)  - compresión y – consumo CPU
-
Principal  vídeos de calidad media (web)  + eficiente + consumo de CPU
-
Alta  en principio Blue Ray (ahora tb web)  la mejor calidad / tasa de bits > consumo CPU
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
NIVEL
RESTRICCIONES PARA UN
PERFIL DETERMINADO
-
Maxima resolución, bit rate y tamaño de cuadro a utilizar
-
Para limitar los requisitos de rendimiento, ancho de banda y memoria
-
A más nivel, más calidad, más problemas con dispositivos
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
TASA DE BITS
Nº bits /unidad tiempo
-
VBR  comprimir eficientemente para misma tasa de bit
-
Problema: picos frecuentes
-
Originalmente descarga progresiva (ahora también streaming)
-
CBR  necesidad de flujo predecible y constante (fichero mayor pero más suavidad)
-
Problema: no conseguiremos la mayor eficiencia posible
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
Nº PASADAS
NO SIEMPRE AYUDA
-
+ pasadas  + tiempo codificación, pero mejor relación calidad / tasa de bits
-
2 pasadas != doble calidad
-
Sólo nos queda experimentar
-
¿ Merece la pena el aumento en el tiempo de codificación ?
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
DISTANCIA KEY
FRAMES
DEPENDE de
MOVIMIENTO y FPS
-
Fotogramas completos o sin referencias a otros
-
Más key frames  Menos pérdida pero también más dificultad para “navegar” por el vídeo
-
Habitualmente entre 1 y 3 segundos  entre 25 y 75 fps
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
ORDEN DE
CAMPOS
“RELIQUIA” DEL PASADO
-
TV tradicional, haz electrones
-
No utilizar ninguna conf. si no entrelazada
-
Si la fuente contiene campos (entrelazada), desentrelazar antes de codificar
FAMILIARIZÁNDONOS CON LA COMPRESIÓN
CONTROLES HABITUALES (AUDIO)
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
MONO o STEREO
DEPENDE, COMO SIEMPRE
-
Verdadero estéreo  dos canales independientes
-
Ante restricciones de tasa de bits, estéreo sólo si es imprescindible
-
No es lo mismo un vídeo musical que una conferencia
-
Si la fuente es mono no codificaremos como estéreo
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
BITS POR
MUESTRA
CUANTOS MÁS, MEJOR
-
Onda de sonido varía cada momento
-
Cuantos más bits por muestra, más se parecerá el flujo de audio a la onda original
-
No es lo mismo un vídeo musical que una conferencia
-
Audio de 16 bits alta calidad
-
Considerar formas de reducir tasa de bits antes que bits por muestra
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
FRECUENCIA DE
MUESTREO
+ FRECUENCIA, +FIDELIDAD
-
44.1 kHz suele ser suficiente
-
Sólo voz  con 22.05 nos valdría
-
Por debajo de eso se degrada demasiado (pérdida de sonidos sutiles, como respiración)
-
+ 48 kHz sólo alta fidelidad (a más frecuencia, mayor detalle)
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
TASA DE BITS
+ FRECUENCIA, +FIDELIDAD
-
Menor consumo que el vídeo
-
Tasas de bits bajas consiguen calidad razonable
-
Pista música estéreo  bastaría con entre 96 y 128 kbps (pérdida mínima)
-
Pista mono  bastaría con entre 56 y 80 kbps (menos aún para voz sólo  24 kbps)
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
REFERENCIAS
VARIAS para TODO
Tamaño
Tasa de bits
Tamaño archivo
320x240 px
400 kbps
3 MB / minuto
480x270 px
700 kbps
5 MB / minuto
1024x576 px
1500 kbps
11 MB / minuto
1280x720 px
2500 kbps
19 MB / minuto
1920x1080 px
4000 kbps
30 MB / minuto
MEDIDA DE KUSH
Tasa de bits en kbps = (número px por seg x factor de movimiento x 0.07) / 1000
Donde número px = ancho x alto x fps y factor movimiento es 1, 2 o 4 (mayor a más movimiento)
Dividiendo entre 1000000 tendríamos Mbps
Podríamos usar 75% para tasa mínima y 150% para tasa máxima en caso de VBR
FAMILIRIARIZÁNDONOS con la COMPRESIÓN
PRESETS
AMIGOS para SIEMPRE
-
Combinaciones predefinidas de configuraciones de codificación para un formato dado
-
Nos pueden facilitar mucho las cosas
-
Podemos ajustar después a nuestro gusto (incluyendo contenedor)
QUÉ ES
HTML
Nuevas etiquetas
<header>, <nav>, <footer>, <section>, <article>…
Nuevos elementos
Enlace tel para llamar directamente a un tlf.
Elementos de formulario como search, email, url
Nuevas funcionalidades
Gracias a la API Javascript, como
geolocalización, drag and drop, datos en local
PERMITE INSERTAR AUDIO
Y VÍDEO DIRECTAMENTE SIN
NECESIDAD DE PLUGINS NI
DEL USO DE FLASH
HTML5: EL ELEMENTO <video>
TAN SENCILLO COMO
<video src=”mivideo.ext” controls> </video>
EN TEORÍA…
COMPROBÉMOSLO
Vídeo webm en Chrome
Vídeo webm en IE
LA TRISTE REALIDAD
NO EXISTE
UN FORMATO ESTÁNDAR
QUE FUNCIONE EN TODOS
LOS NAVEGADORES HTML5
NO PARECE QUE ESTO
VAYA A CAMBIAR A CORTO
PLAZO
TENDREMOS QUE
CODIFICAR NUESTRO VÍDEO
MÁS DE UNA VEZ
! Y ESTO SÓLO PENSANDO EN
NAVEGADORES COMPATIBLES CON
HTML5 !
FORMATOS más COMUNES
OGG  codificador de video Theora y audio Vorbis *
MP4  codificador de video H.264 y audio AAC.
WEBM  codificador de video VP8 y audio Vorbis **
* HANDBRAKE
** FIREFOG, MIRO MEDIA CONVERTER, SORENSON
FORMATOS más COMUNES
OGG  libre y abierto, desarrollado por fundación Xiph.org
MP4  codificadores bajo patente *
WEBM  libre y abierto, desarrollado por Google
* EL USO DE CODECS PARA MP4 EN APLICACIONES IMPLICA PAGO DE LICENCIAS (ALGUNAS RESTRICCIONES
ANULADAS PARA APLICACIONES GRATUITAS)
SOPORTE de FORMATOS en NAVEGADORES
IE
OGG (Theora y
Vorbis)
MP4 (H.264 y AAC)
WebM (VP8 Y
Vorbis)
Firefox Safari Chrome Opera Iphone Android
3.5+
9.0+
9.0+ **
4.0+
*
5.0+
3.0+
5.0+
*
6.0+
10.5+
3.0+
10.6+
* SAFARI REPRODUCE TODO LO QUE REPRODUZCA QUICKTIME ( INCLUYE DE FORMA NATIVA H.264/ACC/MP4 ).
HABRÍA QUE INSTALAR PLUGINS PARA THEORA Y WEBM
** IE SÓLO SOPORTARÁ WEBM SI EL USUARIO TIENE INSTALADO CÓDEC VP8
2.0+
2.3+
HTML5 <video>: BUSCANDO LA COMPATIBILIAD
<video controls>
<source src = “vid.mp4">
<source src= “vid.webm">
<source src= “vid.ogg">
</video>
PROPORCIONAREMOS VARIOS FORMATOS PARA UN MISMO VÍDEO
HTML5 <video>: MÚLTIPLES FUENTES
<video controls>
<source src = “vid.mp4" type= "video/mp4”>
<source src= “vid.webm" type= "video/webm”>
<source src= “vid.ogg" type= "video/ogg">
</video>
ATRIBUTO TYPE NO ES OBLIGATORIO, PERO PUEDE AYUDARNOS
HTML5 <video>: MÚLTIPLES FUENTES
<video controls>
<source src = “vid.mp4" type= "video/mp4; codecs =avc1.42E01E,mp4a.40.2“>
<source src= “vid.webm" type= "video/webm; codecs = vp8,vorbis“>
<source src= “vid.ogg" type= "video/ogg; codecs = theora,vorbis">
</video>
Si el atributo type no está especificado, habrá que acceder al servidor para ver si es fuente puede ser manejada; si no
puede ser mostrado, se comprueba el siguiente source , si ninguno de los elementos source especificados pueden ser
usados, un evento de error es enviado al elemento video. Si el atributo type está especificado, es comparado con los
tipos que el navegador puede reproducir, y si no es reconocido, no se hace la consulta al servidor; en su lugar, el
siguiente source se comprueba
HTML5 <video>: MÚLTIPLES FUENTES
<video controls>
<source src = “vid.mp4" type = "video/mp4; codecs =avc1.42E01E,mp4a.40.2“>
<source src= “vid.webm" type= "video/webm; codecs = vp8,vorbis“>
<source src= “vid.ogg" type= "video/ogg; codecs = theora,vorbis">
</video>
¿ SIEMPRE TENDREMOS QUE OFRECER NUESTRO VÍDEO
CON TRES FORMATOS DIFERENTES?
BUENO, AL MENOS PRESCINDIREMOS DE PLUGINS
NO NECESITAMOS
UTILIZAR FLASH
¡¡ FALSO !!
NAVEGADORES PRE HTML5
INCOMPATIBILIDAD FORMATO DE VÍDEO
HTML5 <video>: FLASH FALLBACK
<video controls>
<source 1> <source 2> <source 3>
<object type="application/x-shockwave-flash" data="player.swf" width="854" height="504"> <param
name="allowfullscreen" value="true"> <param name="allowscriptaccess" value="always"> <param
name="flashvars" value="file=video.mp4"> <!--[if IE]><param name="movie"
value="player.swf"><![endif]--> <img src="video.jpg" width="854" height="480" alt="Video"> Su
navegador no puede reproducir éste vídeo<a href="video.mp4"> Descárguelo</a>.</p> </object>
</video>
¿ webm ?
USANDO VÍDEO en HTML5
Atributos
currentSrc
currentTime
width
height
duration
ended
seeking
seeking
volume
poster
autoplay
buffer
preload
autobuffer
Métodos
play
pause
load
canPlayType
POR SUPUESTO, HAY MUCHA MÁS TELA QUE CORTAR…
Eventos
play
pause
progress
error
timeupdate
ended
abort
empty
emptied
waiting
loadedmetadata
QUÉ FORMATO UTILIZAR
MP4
H.264, ACC
-
Mayor compatibilidad y calidad
-
Como segunda opción una buena elección sería webm (VP8 y VORBIS)
-
Flash fallback (pre HTML 5)
QUÉ ES STREAMING ADAPTATIVO
En lugar de simplemente ofrecer distintas tasas de bits para un vídeo, los formatos de streaming adaptativo permiten el cambio
dinámico de tasa de bits, en función de del ancho de banda disponible, así como del estado de la CPU
HTTP LIVE STREAMING
(HLS)
HTTP DYNAMIC STREAMING
(HDS)
SILERLIGHT SMOOTH
STREAMING (MMS)
MPEG DYNAMIC ADAPTATIVE
STREAMING (DASH)
STREAMING ADAPTATIVO
HTTP LIVE STREAMING
STREAMING ADAPTATIVO
AL CODIFICAR EN HLS SE CREAN MÚLTIPLES ARCHIVOS PARA DIFERENTES ANCHOS DE BANDA Y RESOLUCIONES
(MPG2_TS CODEC). EL MAPEADO PARA EL CLIENTE SE REALIZA MEDIANTE EL ARCHIVO ÍNDICE .M3U8 EN TIEMPO REAL
STREAMING ADAPTATIVO
AL CODIFICAR EN HLS SE CREAN MÚLTIPLES ARCHIVOS PARA DIFERENTES ANCHOS DE BANDA Y RESOLUCIONES
(MPG2_TS CODEC). EL MAPEADO PARA EL CLIENTE SE REALIZA MEDIANTE EL ARCHIVO ÍNDICE .M3U8 EN TIEMPO REAL
STREAMING ADAPTATIVO
EJEMPLO DE FUNCIONAMIENTO
STREAMING ADAPTATIVO
¿ TAN SENCILLO COMO ?
<video src=” https://url.com/archivo.m3u8” controls> </video>
POR SUPUESTO QUE NO…¿QUÉ ESPERÁBAIS?
CODIFICACIÓN mediante IIS SMOOTH STREAMING
ARCHIVOS MP4
FRAGMENTACIÓN EN
ARCHIVOS MÁS PEQUEÑOS
(CACHÉ)
Servidor (.ism) – mapeado de niveles de calidad y bit rates a los archivos .ismv y .isma (para acceder al
archivo adecuado para crear el siguiente fragmento con el bit rate adecuado, antes de responder al
cliente
CODIFICACIÓN mediante IIS SMOOTH STREAMING
ARCHIVOS MP4
FRAGMENTACIÓN EN
ARCHIVOS MÁS PEQUEÑOS
(CACHÉ)
Cliente (.ismc) – toda la información que el cliente silverlight necesita para acceder a los distintos streams
así como metadatos (niveles de calidad, bit rates disponibles, etc). Para sincronizarse
CODIFICACIÓN mediante IIS SMOOTH STREAMING
Con IIS Media Services 4, podemos configurar IIS
Smooth Streaming para “transformar” los fragmentos
MP4 en segmentos MPEG-2 y generar el archivo de
manifiesto de Apple HTTP Live Streaming (.m3u8)
SOLUCIÓN ADOPTADA EN LA UCLM  IIS MEDIA SERVICES 4
CODIFICACIÓN mediante IIS SMOOTH STREAMING
Así codificamos “sólo una vez”, siendo el servidor el que
convierte Los fragmentos de MP4 que contienen H.264
(AVC) y AAC en u archivo .ts (MPEG2) por stream,
fragmentando el archivo bajo demanda cuando un
dispositivo Apple lo requiere
SOLUCIÓN ADOPTADA EN LA UCLM  IIS MEDIA SERVICES 4
CODIFICACIÓN mediante IIS SMOOTH STREAMING
COMPATIBILIDAD
APPLE SILVERLIGHT
SOLUCIÓN ADOPTADA EN LA UCLM  IIS MEDIA SERVICES 4
CODIFICACIÓN mediante IIS SMOOTH STREAMING
COMPATIBILIDAD
APPLE SILVERLIGHT
SOLUCIÓN ADOPTADA EN LA UCLM  PROCESO BÁSICO
CODIFICACIÓN mediante IIS SMOOTH STREAMING
COMPATIBILIDAD
APPLE SILVERLIGHT
SOLUCIÓN ADOPTADA EN LA UCLM  PROCESO BÁSICO
CODIFICACIÓN mediante IIS SMOOTH STREAMING
COMPATIBILIDAD
APPLE SILVERLIGHT
SOLUCIÓN ADOPTADA EN LA UCLM  PROCESO BÁSICO
CODIFICACIÓN mediante IIS SMOOTH STREAMING
COMPATIBILIDAD
APPLE SILVERLIGHT
PUNTO
PUBLICACIÓN
DIRECCIÓN/NOMBRE.ISML
SOLUCIÓN ADOPTADA EN LA UCLM  PROCESO BÁSICO
CODIFICACIÓN mediante IIS SMOOTH STREAMING
COMPATIBILIDAD
APPLE SILVERLIGHT
SOLUCIÓN ADOPTADA EN LA UCLM  PROCESO BÁSICO
CODIFICACIÓN mediante IIS SMOOTH STREAMING
COMPATIBILIDAD
APPLE SILVERLIGHT
<video width="640"
height="480“
src=“archivo.isml/manifest(format=m3u8-aapl).m3u8"
poster=“imagen.png"
autoplay="true"
controls="true" >Live</video>
SOLUCIÓN ADOPTADA EN LA UCLM  PROCESO BÁSICO
CODIFICACIÓN mediante IIS SMOOTH STREAMING
<object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%">
<param name="source" value="SmoothStreamingPlayer.xap"/>
…
<param name="InitParams"
value="selectedcaptionstream=textstream_eng,mediaurl=http://url/archivo.isml/manifest" />
…
</object>
SOLUCIÓN ADOPTADA EN LA UCLM  PROCESO BÁSICO
Antonio
Leal
¡¡ MUCHAS GRACIAS
POR AGUANTARME !!
DIFUSIÓN
DE VÍDEO EN
LA WEB
Descargar