CONCATENACIÓN DE VÍDEO CON MANIFIESTOS HLS

Este artículo se centra en HTTP Live Streaming (HLS), pero los conceptos básicos son válidos también para otros protocolos de streaming basados en HTTP. Un análisis en profundidad del protocolo HLS queda fuera del alcance de este artículo, pero existe abundante información disponible en Internet, incluido el estándar publicado: HTTP Live Streaming.

Concatenación y la antigua usanza

Contenido es igual a valor, así que, en el mundo del vídeo, una forma de crear más valor es tomar un solo vídeo y mezclarlo con otros para crear una nueva pieza de contenido. Muchas veces esto se hace a través de la concatenación, o la capacidad de unir varios vídeos, lo que representa una forma básica de edición. Si a esto añadimos la creación de clips mediante listas de edición, tenemos dos de las funciones más básicas de un editor no lineal.

Por muy prometedora que parezca la concatenación, también puede suponer una carga tanto para la infraestructura como para las operaciones. Imaginemos un portal de vídeo social. Dependiendo de los dispositivos a los que se dirija, podría haber entre un puñado y varias docenas de formatos de salida por vídeo. Si deciden concatenar varios vídeos para ampliar el valor de su biblioteca, también verán un aumento masivo del coste de almacenamiento y de la complejidad de la gestión de activos. Cada vez que se crea una nueva combinación de vídeos, se genera una serie de activos fijos que es necesario almacenar.

HTTP Live Streaming y el Archivo Manifiesto

La introducción de protocolos de streaming basados en HTTP impulsados por manifiestos ha creado un paradigma totalmente nuevo para crear experiencias de visionado dinámicas. Tradicionalmente, la única opción para ofrecer múltiples combinaciones de clips a partir de un único contenido era la edición, lo que implica la creación de activos fijos. Con tecnologías como HLS -dado que el elemento reproducible ya no es un archivo de vídeo, sino un simple archivo de texto-, editar un vídeo es lo mismo que editar un documento en un procesador de textos.

Para una plataforma de vídeo, hay dos formas de tratar el archivo de manifiesto HLS m3u8. La más sencilla es tratar el archivo m3u8 como un activo discreto y reproducible. En este modelo, el m3u8 se almacena en el servidor de origen junto con los archivos TS segmentados y se entrega a los dispositivos. El resultado es sencillo y rápido de implementar, pero el archivo m3u8 sólo puede modificarse mediante un proceso manual.

En cambio, al tratar el manifiesto como algo que se genera dinámicamente, es posible ofrecer a los espectadores una combinación prácticamente ilimitada de clips. En este modelo, el m3u8 se genera sobre la marcha, por lo que no permanece en el servidor, sino que se crea y se entrega cada vez que se solicita.

Generación dinámica de manifiestos

¿Qué es un archivo de manifiesto? Básicamente, es una combinación de algunos metadatos y enlaces a segmentos de vídeo.

  • Vídeo ejemplar A
  • #EXTM3U
  • #EXT-X-MEDIA-SEQUENCE:0
  • #EXT-X-TARGETDURATION:10
  • #EXTINF:10,
  • Segmento_A_ejemplar-01.ts
  • #EXTINF:10,
  • Segmento_A_ejemplar-02.ts

El m3u8 anterior tiene dos segmentos de vídeo de 10 segundos cada uno, por lo que la duración total del vídeo es de 20 segundos. El vídeo ejemplar A, que, por cierto, es un vídeo realmente genial, dura 20 segundos. Ahora imaginemos que también tenemos

  • Vídeo ejemplar B
  • #EXTM3U
  • #EXT-X-MEDIA-SEQUENCE:0
  • #EXT-X-TARGETDURATION:10
  • #EXTINF:10,
  • Ejemplar_B_segmento-01.ts
  • #EXTINF:10,
  • Segmento_B_ejemplar-02.ts

Y digamos también que sabemos que a un espectador concreto le encantaría ver una combinación de ambos vídeos, con el Vídeo B en primer lugar y el Vídeo A en segundo lugar:

  • Magnífico vídeo
  • #EXTM3U
  • #EXT-X-MEDIA-SEQUENCE:0
  • #EXT-X-TARGETDURATION:10
  • #EXTINF:10,
  • Ejemplar_B_segmento-01.ts
  • #EXTINF:10,
  • Segmento_B_ejemplar-02.ts
  • #EXT-X-DISCONTINUITY
  • #EXTINF:10,
  • Segmento_A_ejemplar-01.ts
  • #EXTINF:10,
  • Segmento_A_ejemplar-02.ts

Ahora, instantáneamente, sin crear ningún activo permanente que deba almacenarse en origen, y sin haber involucrado a un editor para crear un nuevo activo, hemos generado un nuevo vídeo para el usuario que comienza con el Vídeo B seguido del Vídeo A. Por si fuera poco, el vídeo se reproducirá sin problemas como si fuera un único vídeo.

Habrás notado una pequeña adición al m3u8:

EXT-X-DISCONTINUITY

Al colocar esta etiqueta en el m3u8, se indica al reproductor que el siguiente segmento de vídeo tendrá una resolución diferente o un perfil de audio distinto del anterior. Si todos los vídeos están codificados con la misma resolución, códecs y perfiles, esta etiqueta puede omitirse.

Ampliación del nuevo modelo

Para que una plataforma de vídeo sea capaz de ofrecer experiencias de reproducción personalizadas sobre la marcha, es necesario tratar el manifiesto m3u8 no como un activo fijo, sino como algo que debe generarse en cada solicitud. Esto significa que el backend debe conocer la ubicación de cada segmento de vídeo, el número total de segmentos por elemento y la duración de cada segmento.

Hay formas de hacer esto más sencillo. Por ejemplo, nombrando los archivos de forma coherente, sólo es necesario conocer el nombre del archivo base para todos los segmentos, y la iteración de segmentos puede gestionarse mediante programación. Se puede asumir que todos los segmentos, excepto el segmento final, tendrán la misma duración objetivo, por lo que sólo es necesario almacenar la duración del segmento final. Así, para un único archivo de vídeo con muchos segmentos de vídeo, todo lo que hay que almacenar es la ruta base, el nombre de archivo base, el número de segmentos, la duración media de los segmentos y la duración del último segmento.

Si se considera que incluso los títulos de larga duración son una combinación de escenas, o incluso más, si se considera que las escenas son una combinación de planos, se puede desbloquear una increíble cantidad de potencia mediante la generación dinámica de manifiestos. Si se planifica y construye con antelación, la arquitectura de la plataforma de distribución puede lograr una gran flexibilidad sin el consiguiente aumento de los costes operativos o de infraestructura.

CÓMO LA TECNOLOGÍA AVID CREÓ FUNCIONES EDUCATIVAS PERSONALIZADAS

Siempre es interesante explorar cómo los clientes de Brightcove utilizan nuestra tecnología y obtienen beneficios cuantificables de sus implementaciones. Fue especialmente divertido conocer cómo Avid Technology utiliza Brightcove, ya que nuestro mundo está intrínsecamente ligado al suyo. Aunque ayudamos a los clientes a entregar y gestionar contenidos de vídeo en línea, Avid es a menudo la herramienta creativa utilizada en el proceso de desarrollo de vídeo.

Avid, otra empresa con sede en Massachusetts, está especializada en tecnología de producción de vídeo y audio, concretamente en sistemas de edición digital no lineal y servicios de gestión y distribución. Profesionales creativos de Hollywood y Madison Avenue confían en la gama de productos de Avid para satisfacer sus necesidades de narración visual. Desde el lanzamiento de Avid en 1987, sus innovaciones tecnológicas le han valido cientos de premios, entre ellos dos Oscar, un Grammy y 14 Emmy. Sin duda, la empresa tiene "crédito de vídeo".

¿Qué llevó a Avid a Brightcove? Aunque Avid es un experto en el desarrollo de vídeo, buscó asesoramiento externo para las mejores prácticas de distribución de vídeo. Nuestro estudio de caso de cliente analiza la relación entre Avid y Brightcove con más detalle, pero queríamos aprovechar esta entrada para ofrecer una breve sinopsis.

Básicamente, el camino de Avid hacia el vídeo en línea se remonta a la primavera de 2010, cuando la empresa empezó a investigar opciones de retransmisión web en directo, incluido el vídeo. Al final, Avid creó una solución de difusión web basada en Flash que incorporaba chat y vídeo para ofrecer una experiencia interactiva. Con estos conocimientos en la mano, la empresa comenzó a investigar plataformas de vídeo en línea que ofrecieran capacidades de visualización adicionales bajo demanda, y que también ayudaran a la empresa a ampliar su funcionalidad de vídeo educativo en el futuro.

En marzo de 2012, Avid seleccionó a Brightcove como su plataforma de vídeo en línea de referencia. Desde entonces, la empresa ha integrado el vídeo en sus ofertas de ayuda del sitio web, dirigiendo a los usuarios a contenidos de vídeo tutoriales cuando trabajan con el software de Avid y les surge alguna duda. Actualmente, el equipo de Avid está trabajando para migrar sus activos de marketing de contenidos de vídeo a Video Cloud, de modo que puedan organizarse y gestionarse fácilmente, así como optimizarse para dispositivos móviles. En el futuro, Avid planea aprovechar Brightcove para mejorar el SEO basado en vídeo y añadir contenido generado por los usuarios a su sitio web.

PUMA IMPULSA EL COMPROMISO DE SUS CLIENTES CON EL VÍDEO EN LÍNEA

Hemos escrito largo y tendido sobre el papel que desempeña el vídeo online en el ecosistema del marketing de contenidos para ayudar a las marcas a establecer relaciones duraderas con sus clientes. PUMA, una de las marcas de calzado y ropa más conocidas del mundo, es un gran ejemplo de empresa de marketing que entiende el poder del vídeo y cómo ayuda a aumentar el compromiso con los clientes.

PUMA produce y publica una amplia gama de contenidos de vídeo en todo el mundo para apoyar sus productos, pero también para llevar a los clientes a un viaje. Aunque PUMA es conocida por sus productos de vanguardia, su marca realmente cobra vida a través del contexto en el que la empresa sitúa los productos y el estilo de vida que la marca retrata. PUMA ve en el vídeo una oportunidad de participación y una forma de dirigir a los clientes a una experiencia multipantalla con una cadencia específica.

Esta estrategia se puso en práctica en los Juegos Olímpicos de Londres 2012, donde PUMA creó todo un entorno de marca para que sus clientes interactuaran tanto en persona como a distancia a través de contenidos de vídeo en directo, con eventos y contenidos programados en torno al velocista jamaicano Usain Bolt, patrocinado por PUMA, y sus épicas actuaciones en los 100 y 200 metros.

Recientemente nos reunimos con Jay Basnight, responsable de estrategia digital de PUMA, para conocer mejor la estrategia de vídeo de la empresa y el impacto del vídeo en la captación de clientes. Jay habla en detalle de la importancia del vídeo y de cómo PUMA mide el éxito, así como de la forma en que la empresa utiliza la plataforma de vídeo de Brightcove para respaldar sus iniciativas de vídeo en todo el mundo.

USO DE LA API MASIVA DE SALESFORCE Y LOS CÓDIGOS APEX CON BRIGHTCOVE

En Brightcove, utilizamos Salesforce para gestionar la información de nuestros clientes. Nuestros equipos de ventas, gestión de cuentas, asistencia y finanzas también lo utilizan para diversas actividades, como ponerse en contacto con clientes potenciales, realizar el seguimiento de casos de asistencia y generar informes de uso. Es importante para nuestro negocio seguir introduciendo datos de clientes en Salesforce de forma puntual y fiable.

El modelo de datos de nuestros productos admite una relación de muchos a muchos entre usuarios y cuentas. Un objeto de cuenta representa una organización o un departamento dentro de una gran organización, y un objeto de usuario representa a un individuo que trabaja para una o varias organizaciones. En Salesforce, personalizamos el objeto Contacto incorporado para representar a cada usuario de los servicios de Brightcove y definimos un objeto personalizado llamado BCAccount para representar una cuenta (véase figura 1).

Figura 1

Figura 1. Modelo de datos en el Servicio de Brightcove y Salesforce

Hace varios años creamos la función de sincronización de datos utilizando la API SOAP de Salesforce y quartz, y hemos observado algunos problemas con esta implementación. Hay dos dificultades principales:

  • Es demasiado hablador, lo que lo hace lento. Solo se pueden sincronizar 700 objetos a Salesforce por hora.
  • Requiere mucho esfuerzo realizar cualquier cambio en el modelo de datos. Para añadir un nuevo campo a un objeto, nos obliga a exportar un nuevo archivo WSDL de Salesforce y generar clases Java a partir del archivo WSDL.

En vista de estas dificultades, decidimos crear un nuevo sistema de sincronización utilizando la API masiva de Salesforce y código Apex. La nueva implementación consiste en un motor de envío de datos llamado RedLine y un conjunto de clases Apex de Salesforce para procesar datos masivos enviados desde RedLine.

Figura 2

Figura 2. Sincronización de nuevos datos

RedLine se ha creado utilizando Sinatra, un servidor web ruby ligero, como servicio autónomo independiente de los demás servicios de Brightcove. RedLine utiliza el programador rufus para consultar periódicamente las creaciones, actualizaciones y eliminaciones de objetos de Brightcove a través de las API RESTful. A continuación, RedLine transforma la respuesta JSON en CSV y la envía a Salesforce como solicitud masiva. Salesforce tiene un límite de 10.000 objetos por solicitud masiva, que es suficiente para nuestro uso. Dado que las solicitudes masivas se procesan de forma asíncrona en Salesforce, ni los servicios de Brightcove ni RedLine necesitan esperar después de enviar los datos a Salesforce.

Escribimos unas cuantas clases Apex para procesar solicitudes masivas, incluida la adaptación de los objetos de usuario y cuenta a los objetos de Salesforce, y después implementamos las clases Apex en Salesforce y programamos trabajos por lotes Apex para ejecutar estas clases una vez que los datos llegan como solicitud masiva. De este modo, no existe código en los servicios de Brightcove para el modelo de datos de Salesforce y sólo es necesario que el código Apex de Salesforce se ocupe del modelo de datos de Salesforce. Salesforce proporciona un conjunto de herramientas de supervisión tanto para solicitudes masivas como para trabajos por lotes de Apex.

Si se produce algún error durante el procesamiento de una solicitud masiva, podemos verlo fácilmente en la interfaz de usuario Web de Salesforce. También desplegamos una clase Apex que se ejecuta periódicamente para comprobar si una solicitud masiva llega con la frecuencia esperada, y alerta si una solicitud no ha llegado durante un tiempo.

En el nuevo sistema de sincronización, para publicar un cambio de nuevos campos del objeto de usuario o cuenta sólo tenemos que añadir los nuevos campos en el objeto personalizado de Salesforce y, a continuación, exponer los nuevos campos en la respuesta JSON de la API del servicio de Brightcove. No necesitamos cambiar ni reiniciar RedLine para el cambio de formato de objeto, ya que RedLine es lo suficientemente inteligente como para convertir los nuevos campos en JSON como nuevas columnas en CSV en solicitudes masivas.

Se han producido cuatro cambios en los objetos de cuenta y un cambio en los objetos de usuario, y no hemos tenido que cambiar ni una línea de código RedLine para estos cambios. Con el antiguo sistema de sincronización basado en la API SOAP, solíamos tardar entre una y dos semanas en sincronizar un nuevo campo para objetos de usuario o de cuenta.

Después de ejecutar esta nueva aplicación de sincronización en producción durante 8 meses, hemos visto que maneja un par de cambios de datos en ráfaga con elegancia. Recientemente se realizó un cambio por lotes de 900 cuentas durante un despliegue, y todas ellas se sincronizaron con Salesforce en menos de un minuto (la mayor parte del tiempo lo emplearon las clases Apex que se ejecutaban en Salesforce). Antes se tardaba más de una hora en sincronizar la misma cantidad de objetos en el antiguo sistema de sincronización.

USO DE GOOGLE COMPUTE ENGINE PARA LA TRANSCODIFICACIÓN DE VÍDEO

Para los que estamos en el mundo de la computación en la nube, lo más emocionante que salió de Google I/O en 2012 no fueron paracaidistas con gafas Glass ni una nueva tableta. La gran noticia fue que Google entra en el espacio de la infraestructura como servicio en la nube, actualmente dominado por Amazon Web Services (AWS). En concreto, Google ha lanzado un nuevo servicio llamado Google Compute Engine para competir con Amazon EC2.

Esto es emocionante. El mundo necesita otro servicio de máquinas virtuales en la nube sólido, eficaz y bien diseñado. Con el perdón de Rackspace y otros, este ha sido un espacio de un solo jugador durante mucho tiempo: EC2 es de lejos el líder. Es evidente que Google cuenta con la experiencia y la escala necesarias para convertirse en un serio competidor, si se mantiene firme en su empeño.

¿Qué aspecto tiene? Los primeros informes son positivos. Google Compute Engine (GCE) está bien diseñado, bien ejecutado y basado en la infraestructura que Google ha estado utilizando durante años. El rendimiento es bueno, especialmente en cuanto a E/S de disco, tiempos de arranque y consistencia, que históricamente no han sido los puntos fuertes de EC2. Pero, ¿hasta qué punto es adecuado GCE para la transcodificación de vídeo en la nube? Tenemos algunos resultados preliminares, reconociendo que hay que hacer más pruebas. He aquí algunas pruebas básicas de transcodificación de vídeo y transferencia de archivos utilizando el software Zencoder tanto en GCE como en EC2.

Velocidad de transcodificación en bruto

El rendimiento es nuestra máxima prioridad, por lo que Zencoder utiliza los servidores más rápidos que podemos encontrar. En EC2, utilizamos instancias Cluster Compute, que son máquinas rápidas de doble CPU en dos tamaños: 4XL y 8XL. Las comparamos con el tipo de instancia GCE más rápido, que actualmente es un servidor de 8 núcleos con una sola CPU.

ServidorCPU
CME 8 núcleosIntel Xeon (Sandy Bridge - probablemente E5-2670) - 8 núcleos a 2,60 GHz
EC2 cc1.4xlargeDoble Intel Xeon X5570 - 8 núcleos a 2,93 GHz/núcleo
EC2 cc2.8xlargeDoble Intel Xeon E5-2670 - 16 núcleos a 2,60 GHz/núcleo

Estas pruebas se realizaron utilizando un vídeo fuente H.264 con resoluciones de 640×360 y 1280×720, y se codificaron con Zencoder utilizando los mismos ajustes de transcodificación de salida de una sola pasada (perfil H.264 Baseline, AAC, transcodificación de calidad constante de una sola pasada, etc.).

Google Compute Engine frente a Amazon EC2

ServidorResoluciónCodificación simultáneaTiempo (segundos)Coste por mil
EC2 cc1.4xlarge640×360615.87$0.96
EC2 cc2.8xlarge640×36069.93$1.10
CME 8 núcleos640×360621.05$1.13
CME 8 núcleos640×36016.01$1.94
EC2 cc1.4xlarge640×36015.96$2.15
EC2 cc1.4xlarge1280×720648.58$2.92
EC2 cc2.8xlarge640×36014.99$3.33
EC2 cc2.8xlarge1280×720630.74$3.42
CME 8 núcleos1280×720668.15$3.66
EC2 cc1.4xlarge1280×720112.89$4.65
CME 8 núcleos1280×720116.01$5.16
EC2 cc2.8xlarge1280×720110.92$7.28

Con la configuración predeterminada de Zencoder, ambos tipos de instancia EC2 son más rápidos que GCE. Los aspectos económicos están un poco más igualados, y no hay un claro ganador entre las instancias EC2 4XL y GCE. Así pues, GCE es una opción viable para la transcodificación en la que el coste es una prioridad mayor que la velocidad bruta, aunque los clientes de AWS pueden hacer uso de las instancias reservadas y las instancias puntuales para reducir aún más los costes. Observamos que las instancias EC2 de 16 núcleos eran aproximadamente el doble de rápidas que las instancias GCE de 8 núcleos cuando estaban bajo carga con 6 transcodificaciones simultáneas.

Dadas las velocidades de reloj similares, pero con la mitad de núcleos, es lo que cabría esperar. Sin embargo, si Google añade máquinas similares de 16 núcleos, podrían tener velocidades de transcodificación comparables.

Velocidades de transferencia

Cuando se transcodifica vídeo en la nube, la E/S de red es casi tan importante como la CPU. Esto es especialmente cierto para los clientes que trabajan con contenido de alta velocidad de bits (emisoras, estudios y creativos). Entonces, ¿cómo se comparan las velocidades de transferencia de GCE con las de EC2? Para comprobarlo, ejecutamos cuatro conjuntos de pruebas comparativas:

  • De Amazon S3 a Amazon EC2
  • De Amazon S3 a Google Compute Engine
  • Almacenamiento en la nube de Google en Amazon EC2
  • Google Cloud Storage a Google Compute Engine

Para ello, probamos el mismo archivo de vídeo de 1 GB almacenado en Google Cloud Storage (GCS) y en Amazon S3. La transferencia se realizó utilizando 10 conexiones HTTP (Zencoder hace esto por defecto para optimizar la velocidad de transferencia, y puede acelerar drásticamente las transferencias de archivos grandes a través de HTTP).

Velocidades de transferencia de CME frente a EC2

 Velocidad de transferencia (Mbps)Ancho de banda del servidor
De S3 a CME470.961 Gbps
S3 a EC2 c1.xlarge644.291 Gbps
S3 a EC2 cc2.8xlarge1458.3210 Gbps
De GCS a GCE202.601 Gbps
GCS a EC2 c1.xlarge378.281 Gbps
GCS a EC2 cc2.8xlarge641.3410 Gbps

Esto es interesante. Esperábamos que la transferencia de Amazon a Amazon fuera rápida, y lo fue. Pero también esperábamos que la transferencia de Google a Google fuera rápida, y no lo fue. De hecho, parece que GCS es más lento que S3, y la transferencia de GCE es más lenta que EC2, de tal manera que incluso si usted está utilizando Google para el cálculo, puede ser mejor utilizar S3 para el almacenamiento. La transferencia fue 2,3 veces más rápida de S3 a GCE que de GCS a GCE.

Se necesitan más pruebas

Estos resultados son preliminares. Es necesario realizar más pruebas para tener en cuenta más variables.

  • Diferencias entre instancias. Esto es especialmente cierto en el caso de la transferencia de archivos, que puede variar mucho en función de las condiciones de la red y la variabilidad de las instancias.
  • Aplicaciones adicionales. Estas pruebas sólo cubren la transcodificación, que es una prueba limitada a la CPU. Otras aplicaciones están limitadas por el disco, la memoria, etc., y estas pruebas no se refieren a otra cosa que no sea la transcodificación.
  • Escalabilidad. La escalabilidad es extremadamente importante para cualquiera que utilice la nube para la transcodificación de vídeo. Se necesitan más pruebas para ver cómo GCE se compara con EC2 cuando se trata de una escala enorme -decenas de miles de servidores (o más)-. ¿En qué momento tienen los usuarios problemas de capacidad? ¿Problemas de rendimiento? ¿Limitaciones de diseño? ¿Inestabilidad?

Futuro de la infraestructura en nube

Aunque EC2 gana en estas primeras pruebas, estamos entusiasmados con Google Compute Engine. Para ser un competidor serio en la transcodificación de alto rendimiento, Google necesita añadir instancias más grandes con CPU más rápidas. Pero añadir nuevos tipos de instancias es fácil. Nada impide a Google hacerlo. Lo difícil es crear una plataforma en la nube sólida, eficaz, completa y escalable, y parece que Google lo ha conseguido. Si Google se compromete con este producto y con los desarrolladores a largo plazo, el mundo de la virtualización en la nube puede haber conseguido un segundo actor legítimo.

SUBTÍTULOS PARA WEB, MÓVIL Y TELEVISIÓN CONECTADA

Los subtítulos son algo positivo para la accesibilidad y la facilidad de uso, y constituyen otro hito en el camino hacia la madurez del vídeo en Internet. Desgraciadamente, los subtítulos no son una única tecnología o "característica" del vídeo que pueda "activarse". Hay varios formatos, normas y enfoques.

El subtitulado es una especie de lío, como el resto del vídeo digital, y es especialmente difícil para los editores multipantalla. Así que si quieres publicar vídeo hoy para web, móvil y TV conectada, ¿qué tienes que saber sobre el subtitulado?

En este artículo se explican los conceptos básicos: cómo funcionan los subtítulos, qué formatos debes conocer y cómo activar los subtítulos en todas las pantallas.

Cómo funcionan los subtítulos

Lo primero que hay que entender es cómo se entregan, almacenan y leen los subtítulos. Hoy en día existen dos enfoques principales.

  • Incrustado dentro de un vídeo. CEA-608, CEA-708, DVB-T, DVB-S, WST. Estos formatos de subtítulos se escriben directamente en un archivo de vídeo, ya sea como pista de datos o incrustados en el propio flujo de vídeo. La televisión de difusión utiliza este método, al igual que iOS.
  • Almacenado como archivo independiente. DFXP, SAMI, SMPTE-TT, TTML, EBU-TT (XML), WebVTT, SRT (texto), SCC, EBU-STL (binario). Estos formatos transmiten la información de los subtítulos a un reproductor junto con el vídeo, en lugar de incrustarla en el propio vídeo. Este enfoque suele utilizarse en la reproducción de vídeo basada en navegadores.

Diferencias entre subtítulos y subtítulos opcionales

¿Y los subtítulos? ¿Son lo mismo que los subtítulos? Resulta que hay tres diferencias principales.

  • Objetivos. Los subtítulos son una función de accesibilidad que pone el vídeo a disposición de las personas con dificultades auditivas y pueden incluir indicaciones sobre quién está hablando o qué sonidos se están produciendo: por ejemplo, "Llaman a la puerta". Los subtítulos son una función de internacionalización que pone el vídeo a disposición de quienes no entienden la lengua hablada. En otras palabras, utilizarías subtítulos para ver un vídeo en mudo, y utilizarías subtítulos para ver un vídeo en un idioma que no entiendes. Nota: Esta distinción es válida en Norteamérica, pero en gran parte del mundo no se distingue entre subtítulos y subtítulos opcionales.

  • Almacenamiento. Históricamente, los subtítulos se han incrustado en el vídeo y los subtítulos se han almacenado externamente (véase CEA-608 más adelante). Esto tiene sentido desde el punto de vista conceptual, porque los subtítulos siempre deben acompañar al vídeo; la legislación obliga a una accesibilidad del 100% para las personas con problemas de audición. En cambio, los subtítulos sólo se necesitan a veces; un vídeo en alemán emitido en Alemania no necesita subtítulos en alemán, pero ese mismo vídeo emitido en Francia sí.

  • Reproducción. Dado que los subtítulos se transmiten junto con el vídeo y son interpretados/visualizados por un televisor u otro dispositivo de consumo, los espectadores pueden activarlos y desactivarlos ellos mismos en cualquier momento utilizando el propio televisor, pero rara vez disponen de opciones para seleccionar un idioma. En estas situaciones, cuando se añaden subtítulos con fines de traducción, suelen ser subtítulos duros (véase más adelante) y, por tanto, no pueden desactivarse. Sin embargo, al ver un DVD/Blue-Ray/VOD, el dispositivo de reproducción controla si se muestran subtítulos y en qué idioma.

Formatos y normas

Hay docenas de formatos y normas para subtítulos y subtítulos opcionales. Aquí tienes un resumen de los más importantes para el vídeo en Internet.

  • CEA-608. También llamados de línea 21, los subtítulos CEA-608 son la norma NTSC, utilizada por la televisión analógica en Estados Unidos y Canadá. Los subtítulos de la línea 21 se codifican directamente en una zona oculta del flujo de vídeo por los dispositivos de emisión. Si alguna vez ha visto barras y puntos blancos en la parte superior de un programa, eso son subtítulos de la Línea 21.
  • SCC. Este archivo contiene subtítulos en formato Scenarist Closed Caption. Contiene códigos de tiempo SMTPE con los correspondientes datos de subtítulos codificados como representación de datos CEA-608.
  • CEA-708. Se trata de la norma para subtítulos de televisión digital ATSC (DTV) en Estados Unidos y Canadá. Actualmente no existe un formato de archivo estándar para almacenar subtítulos CEA-708 aparte de un flujo de vídeo.
  • TTML. Timed Text Markup Language describe la sincronización de texto y otros medios, como audio o vídeo. Para más información, consulte la Recomendación TTML del W3C.
  • DFXP. Se trata de un perfil de TTML definido por el W3C. Los archivos DFXP contienen TTML que define cuándo y cómo mostrar los datos de los subtítulos. DFXP son las siglas de Distribution Format Exchange Profile (perfil de intercambio de formato de distribución). DFXP y TTML suelen utilizarse como sinónimos.
  • SMPTE-TT. La Society of Motion Picture and Television Engineers - Timed Text es una extensión del perfil DFXP que añade soporte para tres extensiones que se encuentran en otros formatos de subtitulado y elementos informativos pero que no se encuentran en DFXP: #datos, #imagen e #información. SMPTE-TT es también el formato FCC Safe Harbor. Si un productor de contenidos de vídeo proporciona subtítulos en este formato a un distribuidor, habrá cumplido con su obligación de proporcionar subtítulos en un formato accesible. Sin embargo, los productores y distribuidores de contenidos de vídeo son libres de acordar un formato diferente.
  • SAMI. Synchronized Accessible Media Interchange se basa en HTML y fue desarrollado por Microsoft para productos como Microsoft Encarta Encyclopedia y Windows Media Player. SAMI es compatible con varios reproductores de vídeo de sobremesa.
  • EBU-STL. Se trata de un formato binario utilizado por la norma EBU, almacenado en archivos .STL independientes.
  • EBU-TT. Se trata de un formato más reciente apoyado por la UER, basado en TTML. EBU-TT es un subconjunto estricto de TTML, lo que significa que los documentos EBU-TT son documentos TTML válidos, pero algunos documentos TTML no son documentos EBU-TT válidos porque incluyen características no admitidas por EBU-TT.
  • SRT. Se trata de un formato creado por SubRip, una herramienta de código abierto basada en Windows para extraer subtítulos de un vídeo. SRT es ampliamente compatible con los reproductores de vídeo de sobremesa.
  • WebVTT. Se trata de un formato de texto similar a SRT. El Grupo de Trabajo sobre Tecnología de Aplicaciones de Hipertexto en la Web (WHATWG) ha propuesto WebVTT como estándar para los subtítulos de vídeo en HTML5.
  • Subtítulos duros. Por definición, no son subtítulos opcionales. Los subtítulos duros son texto superpuesto codificado en el propio vídeo, por lo que no pueden activarse ni desactivarse, a diferencia de los subtítulos opcionales o los subtítulos suaves. Siempre que sea posible, se prefieren los subtítulos suaves o los subtítulos cerrados, pero los subtítulos duros pueden ser útiles cuando se destinan a un dispositivo o reproductor que no admite subtítulos cerrados.

Subtítulos para todos los dispositivos

¿Qué formatos utilizan qué dispositivos y qué reproductores?

  • HTML5. Los subtítulos aún no son ampliamente compatibles con los navegadores, pero eso cambiará con el tiempo. Hay dos normas que compiten entre sí: TTML, propuesto por el W3C, y WebVTT, propuesto por WHATWG. Por el momento, Chrome admite WebVTT de forma limitada; Safari, Firefox y Opera están trabajando en ello; e Internet Explorer 10 admite tanto WebVTT como TTML. Hasta que los navegadores soporten un formato de forma nativa, un marco de reproducción HTML5 como Video.js puede soportar subtítulos a través de Javascript, analizando un archivo externo (Video.js actualmente soporta subtítulos WebVTT).
  • iOS. Apple adopta un enfoque diferente y utiliza subtítulos CEA-608 mediante una versión modificada de la codificación heredada CEA-708/ATSC. Esto significa que, a diferencia de HTML5, los subtítulos deben añadirse en el momento de la transcodificación. Brightcove Zencoder puede añadir subtítulos a vídeos HTTP Live Streaming para iOS.
  • Android. La compatibilidad con reproductores de vídeo sigue siendo fragmentaria y problemática. La compatibilidad con subtítulos dependerá obviamente de la versión del sistema operativo y del reproductor utilizado.
  • Otros dispositivos móviles. Algunos no admiten subtítulos, por lo que los subtítulos en papel pueden ser la única opción.
  • Roku. Admite subtítulos a través de archivos SRT externos.
  • Otras plataformas de TV conectada. Algunas aún no admiten subtítulos. Pero pronto lo harán. Todos los televisores, consolas, receptores de cable y reproductores de Blu-Ray del mercado quieren transmitir contenidos de Internet y, en el próximo año y medio, los subtítulos serán un requisito. Así que Sony, Samsung, Vizio, Google TV y otros acabarán incluyendo el soporte de subtítulos en sus marcos de desarrollo de aplicaciones. Por desgracia, aún no está claro qué formatos se utilizarán. Lo más probable es que las diferentes plataformas sigan soportando una variedad de formatos incompatibles durante muchos años.

Requisitos para el subtitulado

El panorama de los subtítulos ocultos cambiará y madurará con el tiempo, pero a partir de 2012, estos son los requisitos más comunes para soportar subtítulos ocultos en dispositivos comunes.

  • Un reproductor web con controles para activar y desactivar los subtítulos.
  • Un archivo externo con datos de subtítulos, probablemente utilizando un formato como WebVTT, TTML o SRT. Puede ser necesario más de un archivo (por ejemplo, SRT para Roku y WebVTT para HTML5).
  • Un transcodificador compatible con subtítulos incrustados para HTTP Live Streaming para iPad/iPhone, como Zencoder. Zencoder puede aceptar información de subtítulos en diversos formatos, incluido TTML, por lo que los editores podrían utilizar un único archivo TTML para la reproducción web y como entrada a Zencoder para vídeo iOS.

A partir de ahí, las cosas se complican. Es posible que se necesiten otros formatos de entrada para otros dispositivos, y es probable que se necesiten subtítulos para lograr una compatibilidad del 100% con los dispositivos heredados.

Zencoder y subtítulos de Brightcove

Brightcove Zencoder admite subtítulos para dos formatos: subtítulos de estilo CEA-608 para dispositivos iOS mediante HLS, y archivos MP4 con pistas de subtítulos CEA-608. En cuanto a la entrada, es compatible con SCC, SAMI, DFXP/TTML/SMPTE-TT y pistas de subtítulos CEA-608 en archivos MP4.

Hasta la fecha, hemos optado por centrarnos en los subtítulos incrustados porque estos formatos se añaden a los archivos de vídeo en el momento de la transcodificación. Por tanto, si no admitiéramos subtítulos para iPad o iPhone, nuestros clientes que publicaran en estos dispositivos no podrían utilizar subtítulos. En el futuro, ampliaremos la gama de formatos de subtítulos que aceptamos y es posible que ofrezcamos servicios como la conversión de formatos para archivos de subtítulos externos (por ejemplo, TTML a WebVTT).

Mientras tanto, con un único archivo de subtítulos y el reproductor HTML5 adecuado, los clientes de Brightcove tienen todo lo que necesitan para crear vídeos subtitulados para dispositivos web, móviles y de televisión conectada.

APP CLOUD: INFORME DE LA EXPERIENCIA DE UN DESARROLLADOR WEB

Durante mis 13 años como desarrollador y diseñador web, me he adaptado sin esfuerzo a las nuevas tecnologías: empecé con Java, luego con PHP y más tarde con Ruby. Durante mucho tiempo, estuve inmerso en el "vapor de Flash", explorando las principales bibliotecas de interfaz de usuario como Prototype y jQuery mientras me mantenía al día con los estándares web en rápida evolución.

Sin embargo, como muchos desarrolladores web, me perdí el salto a las aplicaciones móviles. Carecía de experiencia con lenguajes de bajo nivel como C++ u Objective-C y no tenía tiempo para aprenderlos. La idea de crear aplicaciones "pequeñas" en Java -un lenguaje que me parecía voluminoso y extenso- tampoco me atraía.

Exploré varias herramientas de desarrollo multiplataforma, pero siempre se quedaban cortas:

  • Las "fábricas" de aplicaciones que envolvían los canales RSS en plantillas preconstruidas creaban aplicaciones genéricas y poco inspiradas.
  • Los marcos que convertían JavaScript o ActionScript en código nativo requerían complejas cadenas de herramientas para la creación y compilación de aplicaciones.
  • Los frameworks que envolvían las páginas web en shells nativos ofrecían poca infraestructura para desplegar aplicaciones basadas en datos en entornos de producción.

Cuando descubrí App Cloud, un framework para crear aplicaciones móviles nativas utilizando HTML, CSS y JavaScript, era escéptico. ¿Sería diferente de los demás? ¿Cumpliría sus promesas? Después de desarrollar mi primera aplicación, puedo decir con confianza que la respuesta es "¡Sí!". He aquí por qué.

APP CLOUD HABLA EL IDIOMA DE LOS DESARROLLADORES

App Cloud se basa en los conocimientos básicos de los desarrolladores web: HTML para estructurar el contenido, CSS para darle forma y JavaScript para editarlo. No es necesario aprender nuevos lenguajes para crear aplicaciones ricas en contenido. Las tecnologías web siempre han destacado por su sencillez. Compara la complejidad de crear una vista de tabla en iOS con la facilidad de crear una lista HTML básica: ¡no hay competencia!

El SDK de App Cloud también es compatible con casi cualquier biblioteca JavaScript, lo que me permite aplicar trucos que he dominado durante años de desarrollo web.

EN LA VÍA RÁPIDA CON APP CLOUD

A menudo cambio entre BBEdit y vim cuando codifico, ya que siguen siendo mis herramientas más cómodas. App Cloud me permite seguir utilizando estos editores tan familiares. Como se basa en tecnologías web estándar, también puedo depurar y probar mi código con Chrome Developer Tools. A diferencia de los engorrosos sistemas ligados a XCode o Eclipse, App Cloud ofrece flexibilidad y libertad.

ITERACIÓN RÁPIDA CON LA APLICACIÓN DEL TALLER

La aplicación de taller App Cloud para iOS y Android permite realizar pruebas en tiempo real durante el desarrollo. Después de hacer cambios en el código, basta con hacer clic en "Actualizar" para ver inmediatamente las actualizaciones. Para los desarrolladores web acostumbrados a procesos iterativos -codificar, actualizar, repetir- esta función tiene un valor incalculable.

Aunque se pueden hacer muchas pruebas en navegadores de escritorio, no hay nada mejor que ver cómo funciona una aplicación en dispositivos reales. La aplicación del taller lo hace fácil y sin problemas.

APROVECHAR LAS FUNCIONES ESPECÍFICAS DE CADA DISPOSITIVO

App Cloud ofrece una sencilla API JavaScript para acceder a funciones específicas del dispositivo, como la cámara o la fototeca. Por ejemplo, escanear un código QR es tan sencillo como:

bc.device.getQRCode(
function (data) { /* handle success */ },
function (error) { bc.device.alert("Oops! " + error.errorMessage); }
);

COMPILACIÓN SIMPLIFICADA DE APLICACIONES

Compilar aplicaciones con otras herramientas, como los kits para desarrolladores de Android, suele ser como montar muebles de IKEA: tedioso y frustrante. Con App Cloud Studio, las aplicaciones se compilan en la nube con unos pocos clics. En cuestión de minutos, la aplicación está lista para su descarga y despliegue en varias tiendas de aplicaciones, sin necesidad de herramientas especiales.

OPTIMIZACIÓN DE CONTENIDOS: MENOS ES MÁS

En las aplicaciones basadas en contenidos, el propio contenido suele ser el cuello de botella. App Cloud optimiza el rendimiento:

  • Eliminar datos innecesarios, comprimir feeds y almacenar contenidos en caché. Por ejemplo, el feed de mi blog se redujo de 39 KB a 4 KB, un 90% menos.
  • Transcodificación de imágenes para reducir el tamaño del archivo. Una imagen pasó de 125 KB a 425 píxeles de ancho a 8 KB a 200 píxeles de ancho, lo que supone una reducción del 94%.

Estas optimizaciones mejoran significativamente los tiempos de carga, que son fundamentales para la participación del usuario.

FLEXIBILIDAD MÁS ALLÁ DEL DESPLIEGUE

A diferencia de otras herramientas, App Cloud Studio me permite modificar los datos, el diseño y la configuración después de la implementación, sin necesidad de recompilar o redistribuir la aplicación. Esta flexibilidad me permite crear varias aplicaciones a partir de una sola plantilla intercambiando los datos y ajustando la configuración.

COLABORACIÓN SENCILLA

App Cloud facilita el intercambio de aplicaciones con los compañeros. Se pueden compartir capturas de pantalla directamente desde la aplicación del taller, o distribuir plantillas mediante URL o códigos QR, lo que permite una colaboración y unas pruebas eficaces.

GESTIÓN INTEGRAL DE LA NUBE

App Cloud ofrece todo lo que necesito para gestionar y monetizar aplicaciones, desde la distribución de anuncios nativos hasta análisis en tiempo real. Puedo hacer un seguimiento de las instalaciones, el tiempo de uso y otras métricas clave.

Además, App Cloud ofrece mejoras de rendimiento y actualizaciones de funciones gratuitas. Futuras mejoras, como las notificaciones push y las compras in-app, harán que la plataforma sea aún más potente.

App Cloud combina la sencillez del desarrollo web con la funcionalidad de las aplicaciones nativas, lo que la convierte en una herramienta indispensable para los desarrolladores que buscan crear aplicaciones móviles eficientes, escalables y atractivas.

AJUSTES DE CODIFICACIÓN PARA UN VÍDEO PERFECTO PARA IPAD/IPHONE

Cualquier editor de vídeo que se precie ya es compatible con el iPad y el iPhone o tiene que plantearse seriamente la posibilidad de hacerlo. Para algunos grandes editores, la difusión en iPad representa un tercio o más del total de visionados de vídeo.

Sin embargo, codificar para iOS es un poco complicado. Estos dispositivos han pasado por varias generaciones de capacidades técnicas, y los ajustes de vídeo ideales para el iPhone 4 no lo son para el iPhone 3GS o para el iPad.

Afortunadamente, con sólo unos pocos perfiles de codificación, puedes transmitir vídeo de alta calidad a todos los dispositivos iOS, desde el primer iPhone hasta el iPad 2, e incluso prepararte para futuras generaciones de hardware móvil.

Ajustes generales

Como la mayoría de los vídeos actuales, utiliza vídeo h.264 y audio AAC cuando te dirijas a iOS.

On the audio side, consider using HE-AAC at <64kbps, for App Store compliance. HE-AAC sounds reasonably good at these bitrates, even for complex audio.

En cuanto al vídeo, utiliza varios perfiles para cada dispositivo. El iPhone 3GS y los anteriores solo admiten el perfil h.264 Baseline, nivel 3.0 (y algunos admiten una versión más limitada que esa), mientras que los dispositivos más recientes admiten los perfiles Main y High.

Para obtener la mejor experiencia de usuario, HTTP Live Streaming (HLS) es imprescindible. Apple se lo exige a cualquier aplicación de vídeo de la App Store que reproduzca contenidos de más de 10 minutos, y es el único verdadero formato de streaming compatible con iOS. HLS también está siendo adoptado por Android (versión 3+), Roku y otros destinos.

Enfoque general

ResoluciónPerfilBitrate@ 16:9@ 4:3AudioComentarios
1024×768[email protected]2 Mbps1024×5761024×76856kbps HE-AAC 
960×640[email protected]1,5 Mbps960×540854×64056kbps HE-AAC 
640×432[email protected]1Mbps640×360576×43256kbps HE-AAC 
480×320[email protected]600kbps480×272426×32056kbps HE-AAC 
400×288[email protected]400kbps400×224384×28856kbps HE-AAC 
400×288[email protected]200kbps400×224384×28856kbps HE-AACdiezmar la velocidad de fotogramas
N/A (sólo audio)    56kbps HE-AAC 

¿Por qué estas recomendaciones?

  • Son sólo recomendaciones. Las resoluciones y tasas de bits diferentes son perfectamente válidas y, de hecho, pueden ser preferibles en algunas circunstancias. Por ejemplo, un contenido extremadamente complejo puede justificar bitrates más altos.
  • 720p es el mayor tamaño de vídeo reproducible en el iPad 1 y el iPhone 4, y el iPad 2/iPhone 4S reproducen hasta 1080p. Pero como la pantalla nativa sólo tiene 1024 píxeles de ancho, llegar hasta 720p o 1080p no es crítico. A no ser, claro, que quieras reutilizar un vídeo en otro sitio: 720p es una resolución estupenda para la reproducción web a pantalla completa, y 1080p es totalmente apropiada para televisores conectados. Se rumorea que los futuros iPad tendrán cuatro veces la resolución del iPad actual, así que considera añadir 720p para estar preparado para el futuro.
  • El perfil h.264 es importante. Tanto el iPad 1 como el iPhone 4 admiten el perfil Principal. El iPad 2 y el iPhone 4S admiten el perfil Alto, que es ligeramente mejor que el Principal, pero dado el número de dispositivos iPad 1 que hay en el mundo, probablemente sea mejor ceñirse al perfil Principal. Para una orientación realmente óptima de los dispositivos, codifique tanto en Main como en High.
  • Estas seis resoluciones y tasas de bits proporcionan una cobertura razonablemente buena de los distintos anchos de banda. Sin duda podrías hacer más, así que añade o quita resoluciones y perfiles según lo desees.
  • Los usuarios de los antiguos iPhone/iPod Touch dispondrán de tres flujos, incluido un vídeo de 480×320 de calidad razonablemente alta (la resolución de pantalla de estos dispositivos). Los usuarios del iPad y el iPhone 4 podrán hacer uso de las seis secuencias.
  • El escalador de resolución del iPad es bastante bueno, así que los vídeos reescalados se verán bien en general.
  • En la medida de lo posible, estos ajustes permiten dimensiones de resolución divisibles por 16. De este modo, la compresión es más eficaz. El aumento de eficiencia es pequeño, sobre todo a resoluciones altas, pero a resoluciones más bajas empieza a marcar la diferencia.
  • Asegúrate de mantener el audio idéntico en cada vídeo. Si las especificaciones de audio cambian de una versión a otra, el usuario puede oír chasquidos durante la reproducción al cambiar de flujo.

Otros ajustes

  • Ajuste la velocidad en función del tiempo de respuesta deseado. Para estas recomendaciones, vamos a utilizar la velocidad 2, que mejora un poco la compresión con respecto a la línea de base, pero sigue siendo razonablemente rápida.
  • Asegúrese de que cada segmento tiene aproximadamente el mismo tamaño utilizando un pico bitrate\_cap del 150% de la tasa de bits objetivo, pero dentro de un largo buffer\_size (por ejemplo, cinco segundos, o 5 veces el bitrate\_cap).
  • Brightcove elige automáticamente la colocación adecuada de los fotogramas clave cuando usted define el tipo como "segmentado". Si está codificando en MP4 para segmentar por separado en HLS, defina forced\_keyframe\_rate a "0.2" o "0.1" (para intervalos de fotogramas clave de cinco o 10 segundos, respectivamente).
  • Si puede aceptar bitrates ligeramente impredecibles, añadir calidad a la mezcla y cambiar video\_bitrate a max\_video\_bitrate para optimizar el tamaño del archivo. El codificador utilizará el bitrate máximo cuando sea necesario, y utilizará un bitrate menor cuando pueda conseguir la calidad deseada con menos bits.
  • Fije el max\_frame\_rate a 30 y el max\_audio\_sample\_rate a 48000.
  • La primera generación de dispositivos iOS sólo permite un h.264 reference\_frameasí que actívelo en los flujos básicos para obtener la máxima compatibilidad.

Integración de Brightcove Video Cloud y Google Analytics

En este artículo, presentaremos un programa de integración de Google Analytics que le permite medir vídeos utilizando Google Analytics. El programa de integración con Google Analytics puede utilizarse si tiene un contrato con Video Cloud y ya dispone de Google Analytics.