Póngase en contacto con nosotros
|
+1 888 882-1880
L-V de 8 a 20 h EST

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

bsp-admin-1 on July 23, 2012

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

bsp-admin-1 on July 13, 2012

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

bsp-admin-1 on February 24, 2012

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

bsp-admin-1 on January 24, 2012

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

bsp-admin-1 on November 1, 2011

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.

UTILIZAR VÍDEOS EN LÍNEA: DIY VS. SOCIAL VS. OVP

bsp-admin-1 on July 13, 2011

Cada vez son más las empresas que descubren el variado potencial de los vídeos en línea: su inmensa popularidad entre los usuarios, su capacidad para evocar emociones, excelentes oportunidades de marketing, importantes impulsos en las ventas de productos e incluso una mejor clasificación en los motores de búsqueda. Sin embargo, muchas pasan por alto los retos y obstáculos asociados al aprovechamiento eficaz de los vídeos.

Incluso con un concepto de vídeo coherente y clips producidos profesionalmente, queda una pregunta crítica: ¿Cómo deben integrarse los vídeos en el sitio web de la empresa? Hay tres opciones principales.

1. SOLUCIONES DE BRICOLAJE

La primera opción es una solución individual. Un empleado (con suerte) cualificado codifica los vídeos, programa un reproductor Flash o configura un reproductor de libre acceso, carga los vídeos en un servidor HTTP y los integra en el sitio web.

Si bien este enfoque puede funcionar para un pequeño número de vídeos con un número limitado de visitas, se convierte rápidamente en poco práctico cuando se manejan más vídeos o un mayor tráfico. Esta solución "hágalo usted mismo" puede resultar desorganizada, propensa a errores, requerir mucho mantenimiento y llevar mucho tiempo.

2. SITIOS SOCIALES DE VÍDEO

La segunda opción consiste en utilizar sitios sociales de vídeo como YouTube. Al subir vídeos a estas plataformas, las empresas reciben códigos de inserción para integrar los vídeos en sus sitios web. Estos sitios ofrecen estadísticas relativamente sólidas sobre el uso del vídeo, y los vídeos se pueden descubrir no sólo en el sitio web de la empresa, sino también a través de la búsqueda de YouTube.

Sin embargo, esta solución presenta importantes inconvenientes. Al subir vídeos a YouTube, las empresas renuncian parcialmente a sus derechos, permitiendo a YouTube comercializar los vídeos, lo que podría dar lugar a que los anuncios de la competencia aparecieran antes que el contenido de la empresa. Además, YouTube mantiene el control sobre la apariencia y las especificaciones técnicas del vídeo, lo que hace que las empresas dependan de las decisiones de la plataforma. En este caso, las empresas ceden el control a YouTube y deben aceptar cualquier cambio o limitación que se les presente.

3. PLATAFORMAS DE VÍDEO EN LÍNEA (OVPS)

Aquí es donde Brightcove entra como la tercera opción y la más profesional. Un OVP combina la personalización de una solución DIY con las capacidades técnicas de un sitio de vídeo social, al tiempo que ofrece seguridad jurídica y control total.

Por supuesto, una OVP requiere una inversión, pero no es diferente de otras herramientas y sistemas profesionales que las empresas utilizan habitualmente. Por un coste relativamente bajo, los clientes acceden a un sistema completo, bien mantenido y en continua mejora.

PRINCIPALES VENTAJAS DE LOS OVPS

  • Entrega fiable: Los vídeos se entregan a través de redes de distribución de contenidos (CDN), lo que garantiza el rendimiento sin sobrecargar los servidores de la empresa.
  • Análisis detallados: Los OVP proporcionan estadísticas detalladas sobre las visualizaciones de los vídeos, lo que permite a las empresas medir la eficacia y obtener información para futuras producciones.
  • Control total: Los vídeos permanecen bajo el control total de la empresa, con la posibilidad de integrar la monetización mediante conexiones a servidores de anuncios o redes publicitarias.
  • Flujos de trabajo optimizados: Los OVP minimizan las tareas técnicas y los riesgos, agilizando los procesos de producción y distribución de vídeo.

Las plataformas de vídeo en línea están diseñadas específicamente para el uso profesional de vídeos. Permiten a las empresas optimizar los flujos de trabajo, reducir los retos técnicos y utilizar los vídeos en Internet de forma eficaz, segura y rentable. Al invertir en una OVP, las empresas pueden liberar todo el potencial de los vídeos en línea manteniendo un control total y garantizando el éxito a largo plazo.

10 CONSEJOS PARA CODIFICAR Y REPRODUCIR VÍDEO DE ALTA CALIDAD

bsp-admin-1 on June 17, 2011

El equipo de comunidad y conocimientos ha analizado las tendencias de búsqueda en nuestro sitio de asistencia, las numerosas consultas a nuestro equipo de atención al cliente y los foros para averiguar qué tipo de temas buscas y sobre qué preguntas. Una de las tendencias que hemos encontrado son las preguntas sobre las mejores prácticas de codificación y consejos para una reproducción de vídeo de alta calidad.

La codificación es un tema muy amplio, pero hemos elaborado una lista de las 10 cosas más importantes que debe tener en cuenta al codificar sus vídeos para cargarlos en Brightcove.

1. Codificación para una amplia compatibilidad de dispositivos

Para garantizar una amplia compatibilidad con los dispositivos, le recomendamos codificar sus vídeos en h.264. La carga de vídeos en h.264 ofrece más posibilidades de personalización de los contenidos de Brightcove y se entrega con mayor calidad y menos ancho de banda que muchas codificaciones alternativas.

H.264 permite una amplia compatibilidad de dispositivos, ya que ofrece las mejores opciones para la entrega de vídeo móvil y es el único formato que se reproducirá en nuestros reproductores inteligentes HTML5. Los reproductores inteligentes entregarán su vídeo en Flash o HTML5, dependiendo de las capacidades del dispositivo del espectador. Esto le permite utilizar un único reproductor de Brightcove que puede entregar vídeo en Flash o HTML5, por lo que no tiene que crear y gestionar reproductores independientes para cada entorno de espectador y sus reproductores existentes pueden cargarse automáticamente en modo Flash o HTML5 sin ningún trabajo personalizado ni JavaScript adicional por su parte.

2. Utilizar streaming multibitrate

Si tienes una audiencia diversa que ve tus vídeos desde cualquier parte del mundo con grandes diferencias en su ancho de banda y conectividad a Internet, utilizar la transmisión multibitrate es imprescindible.

Los usuarios con mayor ancho de banda recibirán automáticamente un vídeo de alta calidad (posiblemente incluso el original). Los espectadores con un ancho de banda inferior no tendrán que esperar largos tiempos de almacenamiento en búfer, sino que podrán ver un vídeo de calidad ligeramente inferior al instante.

Por otro lado, si sus vídeos se visualizan estrictamente, por ejemplo, en una red interna con una conexión a Internet muy potente, puede que le interese subir simplemente un vídeo de alta calidad con una única variante de representación.

3. Conservar el archivo fuente como una variante de representación

Si su archivo de vídeo de origen está en formato h.264, puede optar por conservar su archivo de origen original como variante de representación disponible. Esta opción le permite conservar una versión maestra h.264 que puede tener un nivel de calidad incluso superior al de la variante de representación de mayor calidad de Brightcove.

Además, al seleccionar esta opción, el vídeo fuente h.264 estará disponible inmediatamente, en cuanto finalice la carga, y no tendrá que esperar a que el vídeo se transcodifique para que esté disponible en el módulo multimedia y en sus reproductores.

4. Capturar vídeos a una frecuencia de imagen constante

Para evitar el tartamudeo durante la reproducción, graba vídeo a una velocidad de fotogramas constante de 25-30 fotogramas por segundo, y graba película a una velocidad de fotogramas constante de aproximadamente 24 fotogramas por segundo.

5. Tenga en cuenta el contenido que sube

Los vídeos sobre hechos reales o noticias suelen requerir menos calidad que un vídeo de acción más largo o una atractiva película sobre la naturaleza, que requerirán mucha más calidad.

Si estás produciendo vídeos screencast con muy poca acción, aparte del cambio ocasional de una diapositiva, asegúrate de exportar el vídeo en h.264 con la misma relación de aspecto que tu grabación y utiliza algunas de estas técnicas para configurar tu reproductor.

Codificación de un paso frente a codificación de dos pasos

En general, la transcodificación en dos pasos es mejor que la de un paso. Sin embargo, una codificación de dos pasadas requiere mucho más tiempo. Para los vídeos con mucho movimiento, recomendamos tomarse el tiempo necesario para exportar en dos pasadas. También puede realizar una prueba de comparación para determinar si hay una diferencia notable y mantener un ojo durante las transiciones o áreas de alto movimiento. Si no ves ninguna diferencia notable, quédate con la de una pasada y ahorra algo de tiempo.

6. Cargue el archivo fuente de mejor calidad

Aunque Brightcove puede conservar la calidad de su archivo de origen y crear múltiples niveles diferentes de variantes de representación, no podemos crear variantes de representación de mayor calidad que el archivo de origen que nos proporcione. Disponemos de una lista de recomendaciones de archivos de origen y de ajustes de exportación para ayudarle a crear el archivo de origen de mejor calidad para cargarlo en su cuenta de Brightcove.

7. No ignore la calidad de audio

La mayoría de la gente se centra en conseguir la máxima calidad de imagen posible en sus vídeos e ignora por completo el audio. Sin embargo, los espectadores de tus vídeos son mucho más propensos a abandonar si la calidad del audio se pierde o está entrecortada que si el vídeo tiene una calidad ligeramente inferior.

En la mayoría de los casos, si un usuario no puede oír lo que se dice en un vídeo, no tiene sentido seguir viéndolo. Asegúrate de utilizar un buen micrófono al grabar tus vídeos y ten en cuenta nuestros ajustes de sonido recomendados.

Prácticas recomendadas para la configuración de audio

  • Codec. Seleccione "AAC" cuando codifique vídeo h.264.
  • Frecuencia de muestreo. En caso de duda, elige 44,1 kHz o 48 kHz.
  • Velocidad de bits. Utiliza 128-160 kbps, o 192 kbps+ para contenidos con mucho audio.

8. Desentrelazar vídeos analógicos

Si trabaja con contenido grabado en cinta, le recomendamos que seleccione la casilla Desentrelazar vídeo de origen al exportar para evitar cualquier tipo de efecto de entrelazado en el contenido de Brightcove. Si el contenido se grabó en formato digital y no está entrelazado, no es necesario desentrelazarlo.

9. Modificar los ajustes de transcodificación

Si dispone de una cuenta de edición profesional o empresarial, tiene la opción de modificar los ajustes de transcodificación directamente en Brightcove Studio. De forma predeterminada, dispone de seis variantes de representación en su perfil de transcodificación. Sin embargo, si tiene una base de clientes particularmente diversa que visualiza sus vídeos en diferentes dispositivos y velocidades de conexión, es posible que desee añadir variantes de representación adicionales (hasta 10). La configuración de transcodificación predeterminada de Brightcove proporciona un buen conjunto básico de variantes de representación que debería satisfacer las necesidades de la mayoría de editores y espectadores.

10. Permitir suavizado de vídeo

Los reproductores de Brightcove pueden utilizar el suavizado de vídeo para mejorar la calidad percibida de la reproducción de vídeo. Sin embargo, existe un equilibrio entre la calidad añadida que puede obtener utilizando el suavizado de vídeo y la carga adicional de CPU que el suavizado de vídeo impone al cliente.

Con tasas de bits de vídeo más altas, las ventajas del suavizado de vídeo son menos perceptibles. Los espectadores, especialmente aquellos con ordenadores menos potentes, pueden percibir una calidad de vídeo más entrecortada debido a la caída de fotogramas, lo que puede contrarrestar las ventajas del suavizado de vídeo.

De forma predeterminada, Brightcove utiliza el suavizado de vídeo para vídeos con una tasa de bits inferior a 950 kbps, y no utiliza el suavizado de vídeo para vídeos con una tasa de bits superior o igual a 950 kbps.

Puede anular el comportamiento predeterminado de suavizado de vídeo incluyendo el parámetro opcional videoSmoothing en el código de publicación del reproductor y establecerlo en "true" (siempre se utiliza el suavizado de vídeo) o "false" (nunca se utiliza el suavizado de vídeo).

AJUSTES DE CODIFICACIÓN PARA LA DISTRIBUCIÓN DE VÍDEO DE ALTA DEFINICIÓN DE CALIDAD

bsp-admin-1 on January 20, 2011

Brightcove permite a los editores transmitir contenidos HD a la web. Pero debe asegurarse de codificar correctamente sus archivos de origen para aprovechar nuestras funciones de transmisión de secuencias de alta calidad. Para aquellos de nosotros que pensamos que "4:2:2 pulldown" suena como un idioma extranjero, es útil tener una explicación sencilla de cómo transmitir secuencias de vídeo de alta definición real.

Paso 1: Saber cómo funciona

Brightcove utiliza tecnología de secuencias con múltiples tasas de bits para ofrecer a los espectadores la mejor calidad de vídeo que su velocidad de Internet pueda soportar. Esto significa que creamos hasta seis variantes de representación de su vídeo con distintas resoluciones y velocidades de bits para una amplia variedad de conexiones a Internet, desde las rapidísimas líneas de oficina T3 hasta las conexiones móviles 3G, que a veces son deficientes. Nuestros reproductores de vídeo detectan la velocidad de Internet de los espectadores y les ofrecen la variante de representación adecuada.

Si desea utilizar la configuración predeterminada de Brightcove, simplemente cargue un archivo con la resolución y la tasa de bits más altas que tenga. La configuración predeterminada admite casi todos los códecs y contenedores de vídeo que se utilizan hoy en día, y la calidad máxima será de unos respetables 1280×960 (1280×720 para formatos 16:9) a unos 1,8 Mbps. Dicho esto, si está dispuesto a seguir algunos pasos adicionales, podrá distribuir contenidos de vídeo de alta definición real a través de Brightcove.

Paso 2: Cargar en H.264 y conservar el archivo fuente como una variante de representación

Dado que el proceso de transcodificación de Brightcove limita la reproducción de máxima calidad a 1280×960 a 1,8 Mbps, la clave para exprimir la mejor calidad posible de Brightcove es cargar el vídeo en un formato que podamos entregar a través de nuestros reproductores sin necesidad de transcodificación. Este formato es h.264.

El vídeo H.264 puede reproducirse en PC, dispositivos iOS y dispositivos Android. Dada su amplia compatibilidad entre dispositivos y sistemas operativos, es el formato de vídeo preferido de Brightcove. Como tal, Brightcove ofrece la opción de conservar una fuente H.264 y añadirla a la lista de variantes de representación disponibles del vídeo. El resultado final son las seis variantes de representación predeterminadas de Brightcove, además de su archivo fuente tal y como lo codificó en su máquina.

Paso 3: Codifique su archivo fuente en HD apto para la Web

Las consideraciones clave a la hora de codificar un vídeo para Brightcove son la calidad y la accesibilidad de la reproducción. No hay ninguna razón para incluir una variante de representación de origen de 10 Mbps cuando pocos usuarios finales, si es que hay alguno, tendrán velocidades de Internet suficientes para transmitir vídeo de 10 Mbps. Del mismo modo, un archivo fuente de 2 Mbps será prácticamente indistinguible de la variante de representación de 1,8 Mbps de Brightcove.

Los contenidos de vídeo a 1920×1080 requieren velocidades de bits excepcionalmente altas (a partir de 6-8 Mbps) para mostrarse con claridad, por lo que es mejor utilizar una resolución de 1280×960 o 1280×720 para los vídeos. La mayoría de los espectadores en pantallas de menos de 35″ no notarán la diferencia.

Por último, tienes que decidir la tasa de bits de codificación. Sugerimos una entre 3 y 6 Mbps. A qué lado de ese intervalo te inclines dependerá de si prefieres sacrificar un poco de calidad a cambio de una mayor accesibilidad o viceversa. Recuerda lo siguiente: Si un espectador no dispone de una conexión a Internet lo suficientemente potente para ver su variante de representación fuente, no es el fin del mundo. Brightcove podrá servirles una de las variantes de representación inferiores creadas por nuestro motor de codificación.

CÓMO CODIFICAR VÍDEO PARA MÓVILES

bsp-admin-1 on September 30, 2010

Existen cientos de dispositivos móviles y es prácticamente imposible utilizarlos todos. Pero la buena noticia es que los dispositivos móviles son cada vez mejores.

Los smartphones modernos pueden reproducir vídeo de alta calidad, y su uso va en aumento. Esto no quiere decir que el 3GP se haya acabado o que todo el mundo tenga un smartphone. Pero el uso de smartphones está creciendo y, como es lógico, los usuarios de smartphones son más propensos a ver vídeo en sus teléfonos.

Por eso, si quieres ser compatible con más del 90% de los dispositivos móviles, necesitas al menos dos tipos de vídeo: 3GP + MPEG-4 para los dispositivos menos sofisticados y h.264 + MP4 para los smartphones. En realidad, es una buena noticia. Un vídeo de salida puede cubrir a todos los usuarios de smartphones: iPhone/iPad/iPod, Android y (en su mayoría) Blackberry. También puedes incluir PSP, PS3 y Xbox 360.

Por supuesto, aunque una salida universal para smartphone puede satisfacer a la mayoría de los usuarios, es posible obtener mejores resultados con varias salidas móviles. Por ejemplo, el iPad tiene una resolución nativa de 1024×768, cinco veces superior a los 480×320 de los iPhones anteriores. Así que si codificas tu vídeo a 480×320, estarás desaprovechando las capacidades de casi alta definición del iPad.

Afortunadamente, puedes dirigirte bien a los dispositivos móviles utilizando un puñado de perfiles de codificación estándar. Empiece con el perfil universal para teléfonos inteligentes, que ofrece una amplia compatibilidad. A continuación, añada una versión de perfil avanzado de smartphone para los dispositivos más avanzados y complete su lista de móviles con un perfil heredado para una compatibilidad más amplia (ya sea nuestro perfil heredado de smartphone a continuación o incluso un vídeo 3GP para una compatibilidad aún mayor).

Tenga en cuenta que los siguientes valores predeterminados son el punto de partida para estos perfiles. Zencoder de Brightcove utiliza estos ajustes por defecto, pero puede replicarlos fácilmente en cualquier herramienta de codificación que utilice.

Por defecto

  • Vídeo: h.264, nivel 3.0
  • Audio de perfil básico: AAC, 1-2 canales

1. Perfil universal para teléfonos inteligentes

Este es un buen perfil de partida para una amplia compatibilidad con los smartphones modernos. Funciona con casi todo, aunque no aprovecha las mayores resoluciones y la complejidad de los códecs de los dispositivos más recientes.

Sigue jugando

  • iOS: iPhone, iPad, Apple TV, iPod Touch, iPod Classic, iPod 5.5G
  • Blackberry: Bold 9000, Curve 8910, 8900, 8520, Pearl 9XXX, Storm, Storm 2, Torch, Tour, Bold 9650 + 9700
  • Android: Todos (?)
  • Otros: PSP (3.30+), PS3, Xbox 360, web

No se enciende

  • iPod 5G
  • PSP (pre-3.30)
  • Blackberry Curve 9330, 9300, 8530, 83XX
  • Pearl 8XXX, 88XX

Ajustes

Por defecto, además:

  • Audio_bitrate: 128 (o menos)
  • Audio_sample_rate: 44100 (o menos)
  • Tamaño: 480×320
  • Velocidad máxima de fotogramas: 30
  • Video_bitrate: 1500 (o menos)

1b. Perfil B universal para teléfonos inteligentes: mayor resolución

Este perfil se reproduce mejor en iPhone 4g, iPad, Apple TV, nuevo iPod Touch, Droid, PS3 y Xbox, al aumentar la resolución de vídeo. Sin embargo, los píxeles adicionales se desperdician en los iPhones más antiguos y hacen que el vídeo no se reproduzca en Blackberry y algunos teléfonos Android.

Sigue jugando

Todo lo anterior, menos Blackberry y quizás dispositivos Android más débiles.

Ajustes

Perfil universal para teléfonos inteligentes (arriba), más:

  • Tamaño: 640×480

2. Perfil avanzado de smartphone

Los dispositivos iOS más recientes permiten resoluciones más altas y una mayor complejidad de codificación (lo que significa una mejor compresión). En particular, los usuarios de iPad y Apple TV no deberían tener que ver vídeos de 480×320 en sus hermosas pantallas, por lo que tiene sentido ofrecer una versión de mayor calidad si quieres proporcionar una buena experiencia a estos usuarios.

Sigue jugando

  • iOS: iPhone 4G, iPad, Apple TV*, iPod Touch más reciente
  • Android: Nexus One, Droid, tal vez otros (Nota: Algunos usuarios informan de problemas con vídeo 720p)
  • Otros: PS3, web

No se enciende

  • iOS: iPod 5G/5.5G/Classic, iPhone 3GS y anteriores, iPod Touch PSP antiguo, Apple TV antiguo*.
  • Blackberry: todos
  • Android: otros
  • Otros: PSP, PS3, Xbox 360, web

Ajustes

Por defecto, además:

  • Perfil_H264: principal
  • Nivel_H264: 3.1
  • Audio_bitrate: 160 (o menos)
  • Audio_sample_rate: 48000
  • Tamaño: 1280×720 (máx.) o 960×640 (iPhone 4 nativo)
  • Velocidad máxima de fotogramas: 30
  • Video_bitrate: 5000 (o menos)

*2b. Perfil B de smartphone avanzado: con compatibilidad con el antiguo Apple TV.

Para admitir dispositivos Apple TV más antiguos, utilice el ajuste Perfil avanzado de smartphone, además de una de las siguientes opciones.

Ajustes

Perfil Avanzado de Smartphone (arriba), más uno de los siguientes:

  • Tamaño: 960×540
  • Frecuencia de imagen máxima: 24

3. Perfil de teléfono inteligente heredado

Este perfil se reproduce en el último grupo importante de dispositivos móviles basados en H.264: en particular, iPods antiguos y algunas Blackberries. La contrapartida es un vídeo mucho más pequeño: 320×240, a no más de 768 kbps.

Sigue jugando

Todo lo anterior, además:

  • iPod 5G, PSP (pre 3.30)
  • Blackberry Curve 9330, 9300, 8530, 83XX
  • Pearl 8XXX, 88XX

Ajustes

Por defecto, además:

  • Audio_bitrate: 128 (o menos)
  • Audio_sample_rate: 44100 (o menos)
  • Tamaño: 320×240
  • Velocidad máxima de fotogramas: 30
  • Video_bitrate: 768 (o menos)
  • Nivel_H264: 1.3

4. Perfil 3GP heredado A y B

Por último, uno o dos perfiles 3GP ampliarán la compatibilidad con muchos dispositivos móviles restantes. En particular, puede utilizarlos en la mayoría de los mismos dispositivos compatibles con el perfil de smartphone heredado. Así, si codificas un vídeo 3GP a 320×240, puede que no necesites codificar otro vídeo H.264 a 320×240. Tenga en cuenta que la compatibilidad con vídeo 3GP aún está en fase beta en Zencoder. Por último, tenga en cuenta que estos vídeos tendrán un aspecto terrible, pero ese es el coste de soportar teléfonos 3GP.

Sigue jugando

Es difícil de decir. Hay miles de tipos de dispositivos 3GP, y cada uno es un poco diferente. Considera éstos un punto de partida.

 Perfil APerfil B
Formato3gp3gp
Video_codecmpeg4mpeg4
Talla320×240176×144
Modo_aspectoalmohadillaalmohadilla
Frecuencia de imagen155
De lujoverdaderoverdadero
Velocidad_de_vídeo19252
Bitrate_cap19258
Tamaño_búferN/A16
Audio_bitrate2416
Canales_de_audio11
Velocidad de muestreo de audio1600016000

Resumen

Si quieres crear vídeo para móviles, empieza con el Perfil Universal para Smartphones. Para mejorar la calidad, compleméntalo con vídeo de perfil Smartphone avanzado. Para una mayor compatibilidad, añade uno o dos perfiles Legacy utilizando MP4 o 3GP. Sólo se necesitan de 1 a 3 perfiles para ser compatible con la mayoría de los dispositivos móviles.

Edita

Los dispositivos iPhone/iPod más antiguos piden el perfil "H.264 Baseline Low Complexity". "Baja complejidad" no es un estándar H.264; en realidad sólo significa "sólo 1 fotograma de referencia". El jurado no sabe hasta qué punto los dispositivos Apple realmente aplican esto, pero para una verdadera compatibilidad, probablemente debería utilizar el perfil Baseline y limitar los fotogramas de referencia a 1. Puede hacer esto en Zencoder con la nueva función h264_reference_frames ajuste.

23 de noviembre de 2010: Algunas personas han preguntado por el vídeo de Palm Pre. Las especificaciones publicadas de Palm Pre son muy similares a las de otros smartphones:

  • Resolución nativa de 480×320 (compatible con 640×480)
  • Vídeo H.264, H.263 o MPEG-4
  • Audio MP3 y AAC (junto con algunos otros códecs)

Si estas especificaciones son exactas y completas, entonces los perfiles Universal y Legacy deberían funcionar en Palm Pre.

24 de enero de 2011: Para entregar vídeo 3GP como flujo RTMP es necesario "insinuarlo". Añada "hint": 1 a su solicitud de API para activarlo.

Productos

Servicios

CARACTERÍSTICAS

Soluciones

Recursos

Empresa

2025 Brightcove Inc. Todos los derechos reservados.

Privacidad
Condiciones generales
Linkedin X-twitter Facebook Instagram Rss