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

100 retransmisiones simultáneas en directo en Inter High

bsp-admin-1 on December 27, 2013

ANUNCIOS MID-ROLL EN RETRANSMISIONES EN DIRECTO

Sports Communications es la empresa que gestiona el medio de comunicación deportivo por internet "SPORTS BULL" (abreviado "Spobu"). Tiene acuerdos de colaboración con más de 60 medios de comunicación y cubre más de 40 deportes. No se trata sólo de deportes con una amplia base de aficionados, como el béisbol y el fútbol, sino que también recoge información detallada sobre deportes que ahora pueden ser menores pero quieren ampliar su base de seguidores, y el número de usuarios aumenta rápidamente. El número de espectadores y visitantes aumenta drásticamente durante los eventos, y el número de usuarios activos diarios (DAU) para el torneo de béisbol de secundaria de verano de 2018 superó los 3 millones. Al igual que el béisbol de instituto, el principal contenido del verano es el encuentro atlético entre institutos. Yusuke Kumagai, director de la empresa, afirma: "El deporte amateur tiene un público objetivo muy amplio. Está profundamente arraigado en la comunidad local, y pueden disfrutarlo personas de todas las edades, desde la generación actual hasta los padres y abuelos de esa generación. De hecho, sólo la mitad de la gente de nuestra empresa tiene el hábito de ver deportes profesionales. Aun así, todo el mundo se siente atraído por los deportes de aficionados. Tienen un encanto misterioso, y puede que sea la experiencia original de muchos japoneses que han tenido actividades de club en su época escolar. Para la empresa, que se dedica a distribuir información sobre todo tipo de deportes, y para los aficionados al Spobu, este torneo para decidir cuál es el mejor equipo de instituto de Japón es un acontecimiento importante.

El deseo de retransmitir la Inter-High en directo llevó a la empresa a decidirse por una plataforma de vídeo. Desde su fundación, la empresa ha difundido varios contenidos de vídeo, y la respuesta de los espectadores ha sido buena. Sin embargo, la carga para los gestores de contenidos era pesada, y resultaba difícil para una empresa incipiente con poco personal dedicarse plenamente al vídeo. Cuando se trata de retransmisiones en directo, la carga aumenta aún más, y es necesario contar con un empleado a tiempo completo. Brightcove Video Cloud era el sistema más adecuado para resolver estos problemas.

El Sr. Taiki Kumagai, Director del Departamento de Desarrollo, recuerda: "Brightcove Video Cloud era la única solución que podía utilizarse para retransmitir de forma estable secuencias en directo con anuncios pre-roll y mid-roll. El hecho de que no se requirieran conocimientos informáticos para la operación también era atractivo, y confiábamos en poder lograr la retransmisión en directo para Inter-High.tv y BIG6.tv (Tokyo Big 6 Baseball League) con nuestro sistema actual".

700 RETRANSMISIONES EN DIRECTO DURANTE EL PERIODO INTERMEDIO

Brightcove se adoptó en 2018. En aquel momento, había unos 10 empleados. Procedieron a realizar pruebas para preparar el Inter-High de verano y celebraron numerosas reuniones con empresas asociadas locales que filmarían realmente los partidos. A continuación, establecieron un proceso para filmar vídeos, importarlos a Brightcove Video Cloud y distribuirlos. Decidimos emitir una cuenta dedicada y hacer que entregaran los vídeos accediendo a la plataforma de vídeo directamente desde el área local, eliminando la necesidad de que cargaran, descargaran y volvieran a cargar los vídeos. De este modo, pudimos entregar los partidos en directo a los espectadores con el mínimo trabajo administrativo.

Pronto entraremos en la era 5G. La necesidad de vídeo no hará sino crecer. Creo que preparar la plataforma y agilizar el proceso de entrega con antelación ha sido muy beneficioso para nuestro negocio.

Yusuke Kumagai

Director, Undo Tsushinsha Co.

La distribución fue a gran escala. Se entregaron a los espectadores más de 100 vídeos al día. También se realizaron retransmisiones en directo simultáneas de varios deportes, con 700 partidos retransmitidos en directo durante el periodo. Al final, se editaron y publicaron como contenidos de vídeo unos 12.000 vídeos de distintas duraciones.

"Ahora que podemos completar todo nuestro trabajo en la plataforma de vídeo, creemos que el total de horas de trabajo necesarias se ha reducido en torno a un 30%. Puedo afirmar con certeza que no habríamos podido alcanzar esta escala de distribución sin Brightcove Video Cloud" (Taiki Kumagai).

CONTENIDOS QUE PUEDAN SER DISFRUTADOS POR "USUARIOS APASIONADOS".

Se dice que en los deportes de aficionados hay muchos "heavy users". Permanecen largos periodos de tiempo y ven los vídeos con detenimiento. También hay muchos usuarios que visitan el sitio repetidamente. Puede que el número de impresiones no sea tan elevado como en el caso de los grandes deportes, pero no cabe duda de que hay usuarios apasionados por el deporte. La empresa intenta ofrecer contenidos que hagan que estos usuarios disfruten aún más del sitio.

Yusuke Kumagai afirma: "Nuestro objetivo es convertirnos en una presencia que 'vea', 'juegue' y 'apoye' los deportes. De momento, nos centramos en 'ver' mediante vídeos, pero también intentamos apoyar la creación de experiencias a través de 'jugar'."

En el futuro, queremos convertirnos en una presencia que apoye. Nuestro objetivo es participar más directamente en el apoyo a la transmisión de mejor información y el asesoramiento sobre métodos de monetización, al tiempo que cultivamos y desarrollamos la audiencia que se interesa por nuestros contenidos. De este modo, podrán transmitir el atractivo de un excelente contenido de vídeo y los ingresos publicitarios que genera a todo tipo de organizaciones deportivas.

"Estamos a punto de entrar en la era 5G. A medida que aumenten las velocidades de comunicación y sea posible intercambiar grandes cantidades de datos a altas velocidades, la demanda de vídeo no hará sino crecer. Creo que preparar la plataforma y agilizar el proceso de distribución con antelación ha sido muy beneficioso para nuestro negocio", afirma.

CREACIÓN DE UNA CADENA DE TRANSCODIFICACIÓN CIFRADA DE EXTREMO A EXTREMO

bsp-admin-1 on November 1, 2013

Para muchos clientes de Zencoder, garantizar la seguridad de sus contenidos durante el proceso de transcodificación es una prioridad absoluta. Ahora que Zencoder admite entradas cifradas, los clientes pueden asegurarse de que sus datos nunca se almacenan en formato plano mientras fluyen por Zencoder. En resumen, Zencoder puede aceptar entradas cifradas, descifrarlas para la transcodificación y, a continuación, volver a cifrar los vídeos de salida antes de escribirlos en una ubicación de almacenamiento. La importancia de este flujo de trabajo radica en que tanto las entradas como las salidas están protegidas. Si un usuario no autorizado pudiera acceder a estos archivos cifrados, no podría verlos sin el par de clave e IV utilizado para cifrarlos. Veamos cómo sería este proceso. Antes de empezar, necesitaremos una entrada encriptada. Para este ejemplo, cifraremos un archivo localmente usando OpenSSL, luego lo subiremos a S3 antes de crear el trabajo de transcodificación.

$ openssl aes-256-cbc -k zencoderisawesome -in trailer_test.mp4 -out trailer_test.mp4.enc -p

En -k es el secreto que queremos utilizar, que en este caso es "zencoderisawesome". La dirección -p indica a OpenSSL que imprima la clave cuando termine, que necesitaremos para descifrar más tarde. Para nosotros, la salida se veía así:

salt=9E7E90A964768A2F
key=DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66
iv =375FDBBB213C062D544FCB5A6ACBA44E

Ahora el archivo está encriptado, por lo que no deberías poder reproducirlo como antes. Ahora tenemos que subir el archivo a S3 o a un servidor FTP en algún lugar para que Zencoder pueda acceder a él. Usaremos la interfaz de carga de S3.S3 SubirEs hora de construir la solicitud. Utilizaremos la función Biblioteca Node.js para enviar la solicitud en estos ejemplos, pero las mismas solicitudes también podrían enviarse utilizando otra herramienta como la aplicación Solicitar constructor. Tendremos que especificar la clave de cifrado y el IV que utilizamos anteriormente para la entrada.

var zencoder = require('zencoder')();
zencoder.Job.create({
  input: "s3://zencoder-demo/trailer_test.mp4.enc",
  decryption_method: "aes-256",
  decryption_key: "DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66",
  decryption_password: "zencoderisawesome"
}, function(err, data) {
  if (err) {
    console.log("Job wasn't created");
    return console.log(err);
  }
  console.log("Woo!");
  console.log(data);
});

Esto sería suficiente para crear una salida h.264 estándar, pero no estaría encriptada de ninguna manera. A veces esto es útil, porque puedes querer tomar un archivo mezzanine encriptado (un archivo de muy alta calidad usado para crear otras salidas de menor calidad) y usarlo para marcas de agua o salidas de menor calidad para distribución. Supongamos que queremos tomar un archivo intermedio y subirlo a tres servicios diferentes. Queremos que una de las salidas sea una versión sin cifrar, de baja calidad y con una marca de agua, y que las otras dos estén cifradas con dos claves diferentes, una con una marca de agua identificativa y la otra sin ella. Antes de que podamos crear esta solicitud, sin embargo, tendremos que generar las dos claves que vamos a utilizar. Usaremos OpenSSL de nuevo para crear estas nuevas claves:

$ openssl enc -aes-256-cbc -k supersecret -P
salt=12B83BBF81DFA5B7
key=48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08
iv =2B3CABAB503198DB32394245F54E2A34

$ openssl enc -aes-256-cbc -k anothersecret -P salt=DE2DE044EA5FEB2A key=3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D iv =169C3DE53C56E74130CDA57BA85F8255

Ahora podemos utilizar estas claves cuando encriptamos las salidas durante el proceso de transcodificación.

zencoder.Job.create({
  input: "s3://zencoder-demo/trailer_test.mp4.enc",
  decryption_method: "aes-256",
  decryption_key: "DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66",
  decryption_password: "zencoderisawesome",
  outputs: [
    {
      url: 's3://some-bucket/decrypted.mp4',
      quality: 3,
      width: 320,
      watermarks: [{
        url: 's3://zencoder-live/test-job-watermark.png'
      }]
    },
    {
      url: 's3://some-other-bucket/encrypted-watermarked.mp4',
      width: 720,
      watermarks: [{
        url: 's3://zencoder-live/test-job-watermark.png'
      }],
      encryption_method: "aes-256",
      encryption_key: '48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08',
      encryption_iv: '2B3CABAB503198DB32394245F54E2A34'
    },
    {
      url: 's3://some-bucket/encrypted-out.mp4',
      width: 720,
      encryption_method: "aes-256",
      encryption_key: '3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D',
      encryption_iv: '169C3DE53C56E74130CDA57BA85F8255'
    }
  ]
}, function(err, data) {
  if (err) {
    console.log("Job wasn't created…");
    return console.log(err);
  }
  console.log("Woo!");
  console.log(data);
});

Omitir la encriptación de una salida y encriptar otras dos por separado puede parecer una locura, pero considera el caso de uso. La salida de baja calidad podría utilizarse como muestra (incluso podrías crear un clip más corto para este fin). Una de las versiones de alta calidad tiene una marca de agua que identifica a la persona a la que se ha subido el vídeo, por lo que podrías proporcionarle la clave para descifrarlo y verlo, y si alguna vez se encuentra el vídeo fuera de su control sabrías de quién era la copia. La tercera copia, sin marca de agua, se volvería a subir a un cubo que controláramos, de modo que pudiéramos utilizarla para distribuirla más tarde. Una vez que tengas uno de estos archivos encriptados localmente, puedes desencriptarlo usando un proceso similar al que usamos para encriptarlo originalmente. Para desencriptar el archivo con marca de agua: $ openssl enc -aes-256-cbc -d -K 48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08 -iv 2B3CABAB503198DB32394245F54E2A34 -in encrypted-watermarked.mp4 -out decrypted-watermarked.mp4 Para desencriptar el archivo sin la marca de agua: $ openssl enc -aes-256-cbc -d -K 3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D -iv 169C3DE53C56E74130CDA57BA85F8255 -in encrypted-out.mp4 -out decrypted-out.mp4 ¡Ya está! Ahora tienes una tubería de codificación encriptada de extremo a extremo. El archivo encriptado usado en estos ejemplos está disponible en esa ubicación y fue realmente encriptado usando estas credenciales, así que siéntete libre de usarlo como archivo de prueba. Sólo una notaNo hay que confundir esto con la gestión de derechos digitales (DRM). Una solución DRM adecuada gestiona aspectos como los derechos de acceso a los contenidos, que pueden ser mucho más granulares, hasta determinados dispositivos y usuarios. Los archivos encriptados sólo pueden verse con la clave de encriptación y la contraseña asociada, pero ése es el único criterio.

LIBRO DE PRÁCTICAS: CÓMO CREAR UNA ESTRATEGIA DE VÍDEO DEPORTIVO

bsp-admin-1 on July 23, 2013

El valor del deporte va más allá de un partido, una liga, un equipo o un jugador. Fundamentalmente, el deporte se compone de momentos. Y la gente no sólo recuerda un momento; recuerda dónde estaba, con quién estaba e incluso qué estaba comiendo. El deporte crece y prospera gracias a las emociones. Ya sea alegría, desesperación o envidia, los deportes evocan toda una gama de emociones en un segundo, una centésima de segundo o al cabo de una década.

Cuando los editores piensan en los deportes en el contexto del vídeo, deben darse cuenta de las oportunidades de atraer a los espectadores y crear una experiencia que combine la espontaneidad de las noticias, el arco dramático de la narrativa cinematográfica y -con el paso de cada partido y cada temporada- un tesoro de datos.

Las 4 S del deporte

Para los editores, las oportunidades de conseguir una mayor participación de la audiencia con el vídeo pueden agruparse en cuatro categorías.

  • Estadísticas y puntuaciones
  • Social y compartir
  • Espontaneidad
  • Historias

Estadísticas y puntuaciones

Las estadísticas y las puntuaciones son la forma en que registramos, medimos, analizamos y hacemos un seguimiento de los deportes. Inevitablemente, alguien o algún equipo recibe la "W" y al menos una persona o equipo recibe la "L", con el empate ocasional para una buena medida.

El vídeo puede contextualizar cualquier tipo de estadística en tiempo real.

Durante un acontecimiento deportivo, aunque es habitual mostrar las "grandes" jugadas, los momentos en los que no se anota un gol son igual de eficaces para comprender el flujo y reflujo de un partido, un equipo o un jugador.

  • Penaltis (o decisiones controvertidas o fallidas)
  • Momentos aparentemente sin importancia (por ejemplo, una vacilación durante un intercambio de relevos, la sustitución de un jugador).
  • Estrategia (por ejemplo, jugadas a balón parado en fútbol o voleibol)
  • Rendimiento (por ejemplo, divisiones de jugadores o cambios en la velocidad de lanzamiento)

Para algunos, el deporte en sí es sólo un vehículo para una pasión aún mayor que abarca no sólo partidos, sino temporadas, trabajos, ciudades y amistades.

Aunque los juegos de fantasía deportiva son más populares con el béisbol y el fútbol, no es raro ver juegos de fantasía para fútbol, baloncesto, carreras de coches, golf y más.

Durante la temporada de deportes de fantasía y durante un partido individual, se puede utilizar el vídeo para aumentar los datos en tiempo real recopilados de partidos recientes o en curso, destacando cualquier tipo de "anotación" de deportes de fantasía, desde touchdowns, goles, strikeouts, grandes ganancias de yardas y mucho más.

Pero los participantes en deportes fantásticos también pasan el tiempo mirando pasivamente un flujo de datos en tiempo real. Los editores pueden ampliar esta experiencia basada en los datos a una experiencia de vídeo leanback agregando, consolidando y serializando los vídeos más destacados en una historia de vídeo sobre su equipo de fantasía y sus jugadores, un "sizzle reel" virtual de estadísticas y resultados.

Aún más atractiva que la sincronización del vídeo con datos recientes o en tiempo real es la posibilidad de utilizar el vídeo para crear un contexto adicional a la hora de buscar estadísticas de equipos y jugadores. Los editores pueden crear experiencias atractivas permitiendo a los consumidores no solo ver las estadísticas, sino investigar a través del vídeo.

Social y Compartir

El deporte suele ser una actividad social en la que se participa, se asiste y se ve.

El vídeo puede desempeñar un papel importante más allá de ver el partido en sí.

Ya sea a través de una red personal (correo electrónico o mensaje de texto) o de una red social (Facebook o Twitter), el deporte vive más allá del momento, lo que aumenta su valor de repetición.

Con las redes sociales, los editores pueden utilizar el vídeo para:

  • Iniciar conversaciones sobre un momento concreto (un gol, un "casi" gol, un hincha exaltado o un entrenador frustrado).
  • Permitir a los espectadores iniciar una conversación sobre un momento concreto, "remezclar" su propia serie de momentos o crear su propio resumen al estilo SportsCenter.
  • Crear nuevas oportunidades de monetización con temas de contenidos patrocinados

Los clubes y ligas deportivos pueden utilizar el vídeo para:

  • Anunciar cambios en un estadio para atraer a los abonados o asistentes (por ejemplo, opciones gastronómicas, vistas desde las gradas y suites, y anticipos de eventos o regalos especiales del día del partido).
  • Aprovechar los contenidos generados por los usuarios para reforzar la base de aficionados y movilizar a ese público para crear un valor de marca duradero, (por ejemplo, los "mejores" ejemplos de pancartas, gritos de ánimo, aficionados "en casa", fiestas en los portones traseros y comida).

Espontaneidad

Los editores deben asegurarse de que todas las experiencias de vídeo, desde el ordenador de sobremesa al móvil, pasando por los televisores conectados, se adapten al deseo del espectador de descubrir contenidos. Los contenidos deportivos tienen la particularidad de ser:

  • Consumido en directo, en diferido y pregrabado
  • Desde la perspectiva de las ligas, los equipos, los jugadores y los aficionados
  • Inextricablemente ligado a los datos

Con todas estas facetas, los editores tienen la oportunidad de optimizar el descubrimiento y la promoción para aumentar la participación y la monetización.

En el modo leanback de consumo de vídeo, los editores deben dejar que el contenido parezca espontáneo. Un espectador puede empezar viendo una repetición de la victoria de Michael Phelps en la medalla de oro por el margen más estrecho: una centésima de segundo. A partir de la noción de "final ajustado" del vídeo, la experiencia de vídeo podría programar automáticamente una lista de reproducción dinámica de contenidos similares: El salto de Christian Laettner contra Kentucky, la victoria de Jimmie Johnson en Talladega en 0,0002 segundos o la remontada de los Blackhawks en el último minuto para ganar la Copa.

Historias

El vídeo puede contar una historia en seis segundos o en seis horas. Para los editores que se centran en contenidos deportivos, cada vídeo cuenta una historia: una historia sobre una liga, un equipo, un jugador, un entrenador o un aficionado. Pero las historias deportivas, como pueden abarcar cualquier número de factores, pueden extenderse más allá del conjunto más tradicional de ligas organizadas.

Armados con una GoPro, podemos ver a un pescador luchar con un Marlin de 950 libras, a escaladores escalar El Capitán, a jugadores practicar geocaching o a exploradores urbanos escabullirse bajo los adoquines de París.

Los editores tienen la oportunidad única de apelar a las emociones del consumidor. Mientras que los contenidos informativos son transitorios y obtienen valor tanto de su inmediatez como de su condición de archivo histórico, un momento deportivo puede verse una y otra vez con el mismo nivel de dramatismo.

El deporte permite a la gente dedicarse a su pasión, como participante o como aficionado, y el vídeo desempeña un papel vital que puede realzar la experiencia con cada victoria, derrota o empate.

CÓMO EL LUXEMBURGER WORT RETRANSMITE EL TOUR DE FRANCIA

bsp-admin-1 on July 9, 2013

Si se compara la población de Luxemburgo con sus exitosos participantes en el Tour de Francia, se comprende inmediatamente por qué el ciclismo se ha convertido en el deporte nacional del pequeño país. Desde la primera "Grand Boucle", que comenzó hace 100 años, 15 grandes del ciclismo luxemburgués han celebrado 70 victorias de etapa en el Tour. Cinco luxemburgueses han ganado ya la carrera ciclista más famosa del mundo y han podido llevarse a casa el maillot amarillo al final de las tres semanas de prueba. No es de extrañar, pues, que el ciclismo sea también uno de los temas más candentes estos días para uno de los diarios más importantes del país, el Luxemburger Wort.

Con su propio equipo de periodistas y fotógrafos in situ, el portal de noticias del Luxemburger Wort, wort.lu, ofrece a sus lectores una cobertura de vídeo actualizada diariamente. Gracias a Brightcove, un pequeño equipo gestiona todo el contenido de vídeo del sitio directamente desde la redacción de wort.lu y ofrece vídeos en línea, pequeños reportajes en vídeo de uno a cinco minutos y otros formatos, como entrevistas en vídeo más largas. Durante todo el Tour, los aficionados al ciclismo pueden mantenerse al día con el teletipo en directo del Tour en wort.lu y acceder cada noche a los resúmenes oficiales en vídeo de los organizadores, la Amaury Sport Organization (ASO), en el sitio web. Y, por supuesto, el periódico, publicado por Verlag Saint-Paul Luxembourg S.A. con una tirada diaria de 85.000 ejemplares, espera que los ciclistas luxemburgueses vuelvan a estar en primera línea de la carrera en este año del aniversario del Tour.

Uno de los factores clave en la decisión del editor de implementar Brightcove en 2012 fue que Luxemburgo tiene una de las tasas de uso de móviles más altas de Europa. En un país en el que los residentes acceden cada vez más a las noticias mientras se desplazan, es esencial una entrega de vídeo fiable y de alta calidad en una amplia gama de plataformas. Con nuestro SDK de Video Cloud, el equipo de desarrollo de wort.lu pudo desarrollar aplicaciones móviles para el sitio web de wort.lu poco después de la implantación de dos semanas. La fluida implementación se basó en nuestra amplia documentación y en la colaboración con nuestro equipo de soporte.

La localización también llamó la atención de los responsables editoriales en DMEXCO 2012 sobre Brightcove porque wort.lu ofrece tanto su cobertura del Tour de Francia como todo su contenido editorial en alemán, francés, inglés y portugués. Esto significa que el equipo editorial puede utilizar Brightcove para automatizar etiquetas u otros textos estándar para sus contenidos de vídeo, como los subtítulos, en varios idiomas.

Para Marc Thill, redactor jefe de Luxemburger Wort, la dirección estratégica de wort.lu en el sector del vídeo está clara: "Nuestros equipos editoriales en línea e impreso están creciendo juntos poco a poco, y para ello necesitábamos una solución como Brightcove que pueda crecer con nuestras futuras necesidades de vídeo, que seguramente aumentarán. En particular, en lo que se refiere a la generación de tráfico para nuestro portal de noticias en Internet wort.lu, la cobertura anual del Tour de Francia es un acontecimiento fijo del año para nuestros lectores, tradicionalmente entusiastas del ciclismo."

La editorial es consciente de que su oferta digital también tiene que demostrar su valía a diario en la creciente competencia por el dominio de Internet más allá de estos grandes acontecimientos deportivos, con el fin de mantener y ampliar la posición de liderazgo de wort.lu en el mercado informativo luxemburgués. Con Brightcove, afirma Marc Thill, la editorial ha cumplido las condiciones técnicas necesarias. Ahora, el equipo de la redacción de wort.lu puede entregar diariamente sus contenidos de vídeo en línea de forma dinámica y fiable a sus diversos grupos de usuarios móviles y en línea sin grandes esfuerzos técnicos. La editorial también puede responder ahora a la creciente demanda de los socios publicitarios de wort.lu de una estrecha colaboración en el sector en línea ofreciendo una nueva gama de opciones de publicidad en vídeo gracias al uso de Brightcove. La función de análisis, importante para el éxito de la monetización en el mercado del vídeo, está incluida en el paquete de Brightcove.

MPEG-DASH: CREACIÓN DE UNA NORMA DE INTEROPERABILIDAD Y ENTREGA DE EXTREMO A EXTREMO

bsp-admin-1 on June 14, 2013

Si trabajas en el sector de los medios de comunicación, habrás oído hablar bastante del término MPEG-DASH. MPEG-DASH no es un códec, un protocolo, un sistema ni un formato. Se trata de una norma de interoperabilidad -esencialmente, de entrega de extremo a extremo- de vídeo a través de HTTP.

Uno de los principales objetivos de MPEG-DASH, y aparentemente el principal beneficio para los editores, es la capacidad de reducir el coste y el esfuerzo de ofrecer experiencias de vídeo premium en directo y pregrabadas utilizando estándares abiertos en la infraestructura existente. Las experiencias de vídeo premium actuales suelen incluir requisitos de publicidad, seguridad (por ejemplo, DRM), reproducción a velocidad de bits adaptable, subtítulos y compatibilidad con varios idiomas. La aplicación de estos requisitos a contenidos en directo y pregrabados en un panorama fragmentado de dispositivos genera complejidad (léase coste) para los flujos de trabajo de codificación, empaquetado, almacenamiento y entrega de los editores.

Con MPEG-DASH, los agentes del sector se esfuerzan por tomar tres protocolos de facto para la distribución de vídeo (HTTP Live Streaming de Apple, HTTP Dynamic Streaming de Adobe y Smooth Streaming de Microsoft) y "evolucionarlos" lógicamente hacia una norma compuesta. Esto tiene sentido. Estos tres protocolos son muy similares en cuanto a lo que intentan conseguir: una entrega eficaz y segura de contenidos para su reproducción a velocidad de bits adaptable a través de una red HTTP. Sin embargo, no son compatibles entre sí.

En la actualidad, la mayoría de los editores se esfuerzan por lograr la ubicuidad de los contenidos, para lo que admiten una amplia gama de dispositivos: ordenadores de sobremesa, móviles, televisores conectados, videoconsolas, etc. Por lo tanto, si los editores quieren ofrecer streaming con tasa de bits adaptable, o bien tienen que admitir varios formatos, protocolos y opciones de protección de contenidos para ampliar la compatibilidad entre dispositivos y plataformas, o bien estandarizar y limitar su huella en dispositivos y plataformas.

Ninguno de los dos resulta atractivo. Todo el mundo funciona de forma ineficaz, desde la creación de contenidos (codificación para múltiples formatos e idiomas, empaquetado para múltiples esquemas de protección de contenidos), almacenamiento duplicado, múltiples protocolos de entrega de contenidos, múltiples reproductores con diferentes capacidades y formatos publicitarios incoherentes.

El objetivo de MPEG-DASH es agilizar el flujo de trabajo de vídeo para que los editores puedan gestionarlo con eficacia y entregarlo en cualquier plataforma y dispositivo.

¿Es MPEG-DASH la panacea?

MPEG-DASH no define los detalles de implementación, sino que deja las siguientes tareas y decisiones a la industria en general.

  • DRM de extremo a extremo
  • Códecs
  • Formatos de archivo y compatibilidad con versiones anteriores
  • Consideraciones sobre cánones y cuestiones relacionadas con la propiedad intelectual actual y futura

Todavía existe la posibilidad de que, si los editores se precipitan en la migración, sus decisiones tecnológicas y de flujo de trabajo vengan dictadas por el apoyo limitado o incoherente de los distintos proveedores del ecosistema y la falta de interoperabilidad entre los proveedores del ecosistema. Los editores tendrían entonces que unir todas las piezas de su pila -entrega de contenidos, publicidad, análisis, codificación, empaquetado DRM y gestión de licencias, y reproducción- para resolver realmente el flujo de trabajo de extremo a extremo.

De hecho, la fragmentación que hemos visto con el "estándar" HTML5 podría ser indicativa de lo que nos encontraremos con MPEG-DASH.

¿Qué gana Apple?

Tampoco está claro por qué Apple promovería MPEG-DASH, dado que ha realizado un enorme esfuerzo en torno a HLS y lo ha elevado a un estándar de facto. Muchos sistemas y empresas se basan en este protocolo y, en mi opinión, será difícil convencer a Apple de que sacrifique la ventaja que tiene con HLS e impulse la estandarización de una alternativa a su oferta.

La historia se repite... ¿o no?

A la hora de evaluar la viabilidad de una nueva norma o proceso, resulta útil considerarlo desde un punto de vista histórico y comparativo.

Pensemos en cómo transportaban las mercancías las empresas. Antes de los años 50, no había una forma fácil y eficaz de hacerlo. Pero a mediados de los 50 se introdujo el concepto de transporte intermodal de mercancías y contenedores. Al permitir el transporte de mercancías por barco, ferrocarril o camión en un formato estándar, nació la cadena de suministro moderna. Acordar la estandarización del proceso fue el primer paso fundamental. MPEG-DASH intenta lograr un "cambio radical" similar, pero como evita los detalles de implementación, existe un riesgo importante de que la fragmentación acabe entrando en la ecuación.
Estos son los problemas que podemos encontrarnos.

  • Si las implementaciones de MPEG-DASH no son compatibles con versiones anteriores, será necesario dar soporte tanto a MPEG-DASH como a HLS. Si HLS (o incluso HDS y Smooth) sigue una senda que hace ineficaz la retrocompatibilidad, los editores se verán obligados a dar cuenta de MPEG-DASH y HLS, y de Smooth Streaming y HDS.
  • Si los reproductores del lado del cliente (ordenadores de sobremesa, móviles, televisores conectados, videoconsolas) no son compatibles con MPEG-DASH, los editores seguirán enfrentándose a la fragmentación de los reproductores. La fragmentación de los reproductores fluye en sentido ascendente, lo que significa que todo el flujo de trabajo de los contenidos -desde la reproducción hasta la entrega, pasando por el empaquetado y la codificación- será una duplicación del flujo de trabajo de MPEG-DASH. Para muchos editores, el coste de la adopción puede no merecer la pena.

La opinión de Brightcove

Nuestros editores ya se enfrentan a la complejidad operativa de soportar múltiples formatos y protocolos de entrega asociados. Seguiremos mejorando nuestras capacidades para reducir la fricción y el esfuerzo necesarios en todos los pasos del flujo de trabajo: ingesta de contenidos de múltiples formatos, transcodificación y empaquetado para múltiples variantes de representación y formatos necesarios para la reproducción multiplataforma y la DRM multiplataforma, y streaming con tasa de bits adaptable para escritorio, web móvil, aplicaciones móviles y televisores conectados.

Aunque apoyamos el concepto de estandarización, aún no estamos en condiciones de renunciar a cualquier otro soporte en favor de un escenario MPEG-DASH de extremo a extremo. Dado que MPEG-DASH no tiene en cuenta toda la amplitud y profundidad del ecosistema de vídeo, una adopción temprana podría conducir a una dependencia o bloqueo de los proveedores, lo que sería perjudicial para nuestros clientes.

En última instancia, esperamos que MPEG-DASH y los proveedores del ecosistema mejoren rápidamente sus capacidades para ofrecer a los editores más flexibilidad en lugar de forzar una implementación propietaria que resulte en una dependencia del proveedor o en una implementación incompleta del estándar. Mientras tanto, nos arremangamos y ponemos los dedos en las palabras clave para trabajar en nuestro papel digital dentro del ecosistema MPEG-DASH.

VIDEO.JS 4.0 MEJORA EL RENDIMIENTO Y LA ESTABILIDAD

bsp-admin-1 on May 9, 2013

Video.js 4.0 se publicó en 2013 y estaba disponible para su descarga en Github y alojado gratuitamente en nuestra CDN. Video.js es un reproductor de vídeo HTML5 de código abierto creado por el equipo de Zencoder, que Brightcove adquirió en 2012.

Video.js revolucionó el mercado de la tecnología de reproducción de vídeo de código abierto y logró una enorme adopción y cuota de mercado en pocos años. El reproductor gratuito Video.js ha sido utilizado por decenas de miles de organizaciones, entre ellas Montblanc, Dolce & Gabbana, Diesel, Illy, Applebee's, Mattel, Kellogg's, Les Echos, US Navy, Aetna, Transamerica, Washington State University y muchas otras.

La versión 4.0 recibió la mayor colaboración de la comunidad de todas las versiones anteriores, lo que habla de la creciente fuerza de la comunidad JavaScript, la creciente popularidad del vídeo HTML5 y un aumento del uso de Video.js. De 2012 a 2013, el número de sitios que utilizan Video.js se ha más que duplicado, y cada mes hay más de 200 millones de visitas solo a la versión alojada en CDN.

Hay muchas novedades en Video.js 4.0.

  • Mejora del rendimiento gracias a una reducción de tamaño del 18% mediante el compilador de cierres de Google en modo avanzado.
  • Mayor estabilidad mediante un conjunto automatizado de pruebas entre navegadores y dispositivos con TravisCI, Bunyip y Browserstack.
  • Nueva interfaz y lista de plugins para ampliar Video.js
  • Nuevo diseño de skin por defecto que utiliza iconos de fuentes para una mayor personalización.
  • Diseño adaptable y compatible con pantallas retina
  • Mayor accesibilidad gracias a un mejor soporte de ARIA
  • Licencia Apache 2.0
  • Conjunto de herramientas de desarrollo 100% JavaScript, incluido Grunt

2013 será un año emocionante para Video.js, con más mejoras de rendimiento, estabilidad multiplataforma y personalización mediante plugins y skins. Los miembros de la comunidad ya han empezado a trabajar en plugins para algunas de las funciones más solicitadas, como listas de reproducción, análisis y publicidad.

7 mejores prácticas de SEO de vídeo que generan tráfico

bsp-admin-1 on April 16, 2013

¿Quieres mejorar el SEO de tus vídeos y atraer más tráfico a tu sitio web? Aquí tienes 7 consejos rápidos que pueden ayudarte.

1. Escriba el título y la descripción de su vídeo para la gente

Google da importancia a "escribir para la gente" y desaprueba el relleno de palabras clave en el título y la descripción del vídeo. Asegúrate de escribir títulos y descripciones que sean atractivos y relevantes para tu audiencia, no que contengan palabras clave.

2. Añada etiquetas si tiene un mapa del sitio de vídeo

Añadir etiquetas a sus vídeos es una excelente forma de organizar el contenido dentro de la plataforma de vídeo en línea de Brightcove, y puede ayudar con el SEO, pero sólo si dispone de un mapa del sitio de vídeo que exponga esas etiquetas a los motores de búsqueda. Si dispone de los recursos de desarrollo necesarios para crear un mapa del sitio de vídeo sencillo, la inversión merece la pena.

3. Utilice Schema Markup

Schema es una colección de etiquetas HTML que los webmasters pueden utilizar para marcar sus páginas de forma reconocida por los principales proveedores de búsqueda. Los motores de búsqueda se basan en estas etiquetas de esquema para mejorar la visualización de sus resultados de búsqueda, lo que facilita a los usuarios encontrar las páginas web adecuadas. Si utiliza el atributo itemscope para identificar su contenido como un vídeo para los motores de búsqueda, aumentará sus resultados SEO. Schema ofrece una explicación sobre cómo utilizar el atributo itemscope e instrucciones generales sobre el uso de etiquetas html para identificar vídeos.

4. Elija imágenes en miniatura de calidad

La calidad editorial de la miniatura prevalece sobre la calidad de la imagen. Dicho de otro modo, elegir miniaturas atractivas para su contenido puede aumentar los clics de los usuarios. Una mayor participación del usuario afectará a sus resultados SEO. También vale la pena señalar que una imagen en miniatura siempre obtendrá mejores resultados de tráfico que un icono de vídeo genérico o un enlace de texto "haga clic aquí para ver el vídeo".

5. Incorpore los principales términos de búsqueda que devuelven resultados de vídeo

Aunque no debes "llenar de palabras clave" el título y las descripciones de tus vídeos, ciertas palabras aumentarán la probabilidad de que los motores de búsqueda los encuentren. Palabras como "vídeo", "mostrar", "cómo", "reseña" y "acerca de" son términos que aumentan la probabilidad de que tu contenido muestre una miniatura de vídeo. No haga nada antinatural, pero si puede incorporar estas palabras en su título o descripción (por ejemplo, "Video tour of Aloft Brooklyn") puede marcar la diferencia.

6. Optimice su sitio web

El SEO de vídeo más impecable no sirve de nada si su sitio web no está optimizado. Siempre es una buena práctica asegurarse de que el SEO de su sitio web está optimizado antes de ajustar la configuración del vídeo.

7. Colocar los vídeos al principio de la página

Si tiene vídeo, colóquelo en la parte superior de la página. Esto permite a los motores de búsqueda entender que se trata de contenido de vídeo. Es increíble los resultados que obtendrá con este pequeño cambio.

MANIFIESTOS DINÁMICOS Y FLEXIBILIDAD DE LAS LISTAS DE REPRODUCCIÓN HLS

bsp-admin-1 on March 28, 2013

Durante años, hubo dos modelos básicos de streaming por Internet: la tecnología propietaria basada en servidor, como RTMP, o la descarga progresiva. El streaming basado en servidor permite la entrega de flujos con múltiples tasas de bits que pueden conmutarse bajo demanda, pero requiere un costoso software de licencia. La descarga progresiva puede hacerse a través de Apache, pero el cambio de velocidad requiere detener la reproducción.

La llegada de protocolos de transmisión basados en HTTP, como HLS y Smooth Streaming, hizo posible la transmisión de secuencias a través de conexiones HTTP estándar utilizando tecnología de servidor básica, como Apache; el cambio de velocidad de bits sin interrupciones se convirtió en algo habitual y la transmisión a través de redes de distribución de contenidos (CDN) era sencilla, ya que básicamente era lo mismo que transmitir cualquier archivo a través de HTTP. El streaming HTTP ha supuesto nada menos que una revolución en la distribución de contenidos multimedia, reduciendo enormemente el coste y la complejidad del streaming de alta calidad.

A la hora de diseñar una plataforma de vídeo hay que tener en cuenta innumerables cosas. Sin embargo, una de las decisiones más importantes y que a menudo se pasa por alto es cómo tratar los archivos de manifiesto basados en HTTP.

Archivos estáticos de manifiesto

En el mundo físico, cuando compras un vídeo, miras el envoltorio, coges la caja, te diriges a la caja, pagas al cajero, te vas a casa y lo introduces en tu reproductor.

La mayoría de las plataformas de vídeo tienen una estructura bastante similar. Fundamentalmente, un grupo de metadatos (la caja) se asocia a un elemento multimedia reproducible (el vídeo). La mayoría de las plataformas de vídeo comienzan con el concepto de una única URL que conecta los metadatos a un único vídeo mp4. A medida que una plataforma de vídeo se hace más compleja, puede haber varias URL conectadas a los metadatos que representen varias velocidades de bits, resoluciones o quizás otros medios asociados al elemento principal, como previsualizaciones o características especiales.

Las cosas se complican cuando se intenta extender el modelo físico a un mundo de streaming en línea que incluye protocolos de streaming basados en HTTP, como HLS. HLS se basa en muchos fragmentos de un archivo de vídeo enlazados por un archivo de texto llamado manifiesto. Cuando se implementa HLS, el método más sencillo es simplemente añadir una URL que enlace al manifiesto, o archivo m3u8. Esto tiene la ventaja de ser extremadamente fácil, encajando básicamente en el modelo existente.

El inconveniente es que HLS no se parece en nada a un elemento multimedia estático. Por ejemplo, un MP4 se parece mucho a una pista de vídeo de un DVD; es un único vídeo con una única resolución y velocidad de bits. El manifiesto HLS consiste, muy probablemente, en múltiples bitrates, resoluciones y miles de piezas fragmentadas de vídeo. HLS tiene la capacidad de hacer mucho más que un MP4, así que ¿por qué tratarlo igual?

Listas de reproducción HLS

Una lista de reproducción HLS incluye algunos metadatos que describen elementos básicos del flujo y un conjunto ordenado de enlaces a fragmentos del vídeo. Al descargar cada fragmento o segmento del vídeo y reproducirlos en secuencia, el usuario puede ver lo que parece ser un único vídeo continuo.

  • EXTM3U
  • #EXT-X-PLAYLIST-TYPE:VOD
  • #EXT-X-TARGETDURATION:10
  • #EXTINF:10,
  • archivo-0001.ts
  • #EXTINF:10,
  • archivo-0002.ts
  • #EXTINF:10,
  • archivo-0003.ts
  • #EXTINF:10,
  • archivo-0003.ts
  • #EXT-X-ENDLIST

Arriba hay una lista de reproducción m3u8 básica. En ella se enlazan cuatro segmentos de vídeo. Para generar estos datos mediante programación, sólo se necesita el nombre de archivo del primer elemento, la duración prevista de los segmentos (en este caso, 10) y el número total de segmentos.

Manifiestos HLS

Un manifiesto HLS es una serie desordenada de enlaces a listas de reproducción. Hay dos razones para tener varias listas de reproducción: para proporcionar varias velocidades de bits y para proporcionar listas de reproducción de copia de seguridad. Esta es una lista de reproducción típica en la que cada .m3u8 es un enlace relativo a otra lista de reproducción HLS.

  • #EXTM3U
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2040000
  • archivo-2040k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1540000
  • archivo-1540k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1040000
  • archivo-1040k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=640000
  • archivo-640k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=440000
  • file-440k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=240000
  • archivo-240k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=64000
  • archivo-64k.m3u8

Las listas de reproducción tienen distintas velocidades de bits y resoluciones para ofrecer una reproducción fluida independientemente de las condiciones de la red. Todo lo que se necesita para generar un manifiesto son las tasas de bits de cada lista de reproducción y sus rutas relativas.

Rellenar los espacios en blanco

Hay muchos otros datos importantes que una plataforma de vídeo en línea debería capturar para cada activo de vídeo codificado: el códec de vídeo, el códec de audio, el contenedor y la tasa de bits total son sólo algunos. Los datos almacenados para un único elemento de vídeo deben ser significativos para el espectador (descripción, clasificación, reparto), significativos para la plataforma (duración, visionados, participación) y significativos para las aplicaciones (formato, resolución, tasa de bits). Con estos datos, el espectador puede decidir qué ver, el sistema puede decidir cómo programar y la aplicación puede decidir cómo reproducir.

Al capturar los datos necesarios para generar programáticamente una lista de reproducción, un manifiesto y la información del códec para cada una de las listas de reproducción, se hace posible disponer de un sistema en el que los manifiestos y las listas de reproducción se generan por solicitud.

Ejemplo - La primera lista de reproducción

La especificación HLS determina que la lista de reproducción que aparezca en primer lugar en el manifiesto será la primera elegida para reproducirse. En el ejemplo de la sección anterior, el primer elemento de la lista era también la pista de mayor calidad. Eso está bien para los usuarios con una conexión a Internet rápida y estable, pero para las personas con conexiones más lentas la reproducción tardará un poco en iniciarse.

Sería mejor determinar si el dispositivo parece tener una buena conexión a Internet y luego personalizar la lista de reproducción en consecuencia. Por suerte, con la generación dinámica de manifiestos, eso es exactamente lo que el sistema está preparado para hacer.

A efectos de este ejercicio, supongamos que se solicita un manifiesto con una matriz ordenada de velocidades de bits. Por ejemplo, la petición [2040,1540,1040,640,440,240,64] devolvería una lista de reproducción idéntica a la de la sección anterior. En iOS, es posible determinar si el usuario está conectado por WiFi o por móvil. Dado que se han capturado datos sobre cada lista de reproducción, incluyendo bitrate, resolución y otros parámetros similares, una aplicación puede decidir de forma inteligente cómo ordenar el manifiesto.

Por ejemplo, se puede determinar que es mejor empezar entre 800-1200kbps si el usuario está en WiFi y entre 200-600kbps si el usuario está en una conexión celular. Si el usuario estuviera en wifi, la aplicación solicitaría un array parecido a: [1040,2040,1540,640,440,240,64]. Si la aplicación sólo detectara una conexión móvil, solicitaría [440,2040,1540,1040,640,240,64].

Ejemplo - El dispositivo heredado

En Android, el soporte de vídeo es una especie de caja negra. Durante años, la documentación oficial de Android sólo admitía el uso de vídeo mp4 h.264 de 640×480 de línea de base, aunque algunos modelos eran capaces de manejar 1080p. En el caso de HLS, el soporte es aún más fragmentado y difícil de entender.

Por suerte, Android está dominado por un puñado de dispositivos estrella. Con los manifiestos dinámicos, la aplicación no solo puede determinar cuál es la mejor lista de reproducción para empezar, sino también excluir las listas de reproducción que se consideren incompatibles.

Dado que nuestros elementos multimedia también capturan datos como la resolución y la información del códec, la asistencia puede dirigirse a dispositivos específicos. Una aplicación podría decidir enviar todas las variantes de representación: [2040,1540,1040,640,440,240,64]. O bien, un dispositivo antiguo que sólo admita hasta 720p podría eliminar la variante de representación más alta: [1540,1040,640,440,240,64]. Además, más allá del mundo de los dispositivos móviles, si la aplicación es un televisor conectado, podría eliminar las variantes de representación de menor calidad: [2040,1540,1040,640].

Dinámico o estático

Elegir un modelo de manifiesto estático está perfectamente bien. Se pierde algo de flexibilidad, pero la simplicidad no tiene nada de malo. Muchos casos de uso, especialmente en el mundo del contenido generado por el usuario, no requieren la cantidad de complejidad que implica la generación dinámica; sin embargo, la generación dinámica de manifiestos abre muchas puertas para aquellos dispuestos a dar el paso.

El modo en que se traten los manifiestos tendrá un impacto significativo en la flexibilidad a largo plazo de una plataforma de vídeo, y es algo que debería discutirse con su compresionista residente.

SUBIR Y CODIFICAR VÍDEO CON FILEPICKER

bsp-admin-1 on March 20, 2013

Cómo subir vídeos es una de las preguntas más frecuentes que nos hacen los nuevos clientes. Para los desarrolladores, la carga de archivos es algo que probablemente han hecho varias veces, pero siempre es un engorro.

Entrar en Filepicker

Filepicker (ahora Filestack) facilita la carga de archivos. Muy fácil. No estás limitado sólo a archivos locales; soportan una amplia gama de fuentes, desde Dropbox y Google hasta incluso grabar un vídeo directamente desde tu webcam. Lo mejor es que puedes hacer todo esto sin salir del front-end.

Antes de hacer nada más, tendrás que registrarte para obtener una cuenta de Filepicker. Una vez que lo haya hecho, cree una nueva aplicación en su panel de control si no existe una. Toma nota de la clave API que ves, la usaremos más adelante. Filepicker es lo suficientemente amable como para proporcionar un cubo S3 para empezar, pero tómese un segundo para configurar un cubo S3 de destino para sus cargas.

Empecemos en la misma página con una plantilla HTML5 básica. Vamos a utilizar jQuery para hacer las cosas simples, así que vamos a incluir que con nuestro boilerplate junto con la biblioteca Filepicker.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>Zencoder Dropzone</title>

    <!-- jQuery Include -->
    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>

    <!-- Filepicker.io Include -->
    <script type="text/javascript" src="//api.filepicker.io/v1/filepicker.js"></script>
</head>

<body>
    <div id="content">
        <h1>Upload all the things!</h1>
    </div>
</body>
</html>

Ahora podemos utilizar la API JavaScript Filepicker para permitir a nuestros usuarios seleccionar un archivo y guardarlo en nuestro cubo S3. También necesitaremos asociar esto con un enlace en el cuerpo para que el usuario tenga algo en lo que hacer clic. Añade esto debajo del Filepicker JavaScript include. Primero vamos a añadir el enlace de carga. Dado que ya tenemos un gran y prominente h1 añadamos el enlace.

<h1><a href="#" id="upload-link">Upload all the things!</a></h1>

Ahora queremos utilizar ese enlace para activar filepicker.pickAndStore al hacer clic. Aquí es donde utilizaremos la clave API que anotó anteriormente. Coloque este fragmento debajo del Filepicker JavaScript incluir en la cabecera de la página.

<script type="text/javascript">
    $(function() {
      filepicker.setKey('The_Key_From_Your_Dashboard');

      $('a').click(function(e) {
        e.preventDefault(); // This keeps the normal link behavior from happening

        filepicker.pickAndStore({},{location: 's3'},function(fpfiles){
            console.log(JSON.stringify(fpfiles));
        });
      });
    });
</script>

Tendrás que utilizar algún tipo de servidor web para servir el HTML o de lo contrario no podrás cargar los archivos JavaScript externos. Puedes usar algo como http-server, pero hay una aplicación básica de Node que servirá archivos estáticos en el repositorio de GitHub.

Elija cualquier archivo (puede que quiera elegir algo relativamente pequeño) y súbalo. En este momento, una carga exitosa sólo registra el archivo fpfiles a la consola, así que después de subir un archivo echa un vistazo a la consola. Si todo ha ido según lo previsto, deberías tener un objeto con información sobre el archivo que acabas de subir.

Acabas de subir un archivo desde tu ordenador con sólo 27 líneas de código en total, incluyendo un simple marcado HTML. Pero subir archivos y dejarlos ahí no es útil, así que hagamos que los usuarios puedan subir vídeos y codificarlos.

Añadir Zencoder

En primer lugar, vamos a modificar nuestro cargador para que sólo acepte archivos de vídeo. Filepicker nos permite restringir por mimetype, así que si usted es como yo puede estar tentado a tratar de {mimetype: 'video/*'}. Esto funcionará bien en Chrome, pero los usuarios de Safari verán un subconjunto mucho más pequeño de archivos que pueden subir. Para vídeo, es mucho más fiable restringir por extensión, así que vamos a tomar esa ruta.

$('a').click(function(e) {
  e.preventDefault(); // This keeps the normal link behavior from happening
  var acceptedExtensions = ['3g2','3gp','3gp2','3gpp','3gpp2','aac','ac3','eac3','ec3','f4a','f4b','f4v','flv','highwinds','m4a','m4b','m4r','m4v','mkv','mov','mp3','mp4','oga','ogg','ogv','ogx','ts','webm','wma','wmv'];
  filepicker.pickAndStore({extensions: acceptedExtensions},{location: 's3'},function(fpfiles){
      console.log(JSON.stringify(fpfiles));
  });
});

Puede restringir este conjunto de archivos aceptados o añadir más, pero he optado por la vía fácil y he utilizado la lista de formatos de salida válidos de la documentación de formatos de Zencoder. Incluye algunos archivos de audio, pero como Zencoder sólo admite codificación de audio, podemos dejarlos ahí. Ahora, si haces clic en el enlace y exploras tus archivos locales, te darás cuenta de que sólo puedes seleccionar archivos con una extensión de la lista. Si intentas arrastrar y soltar un archivo inaceptable, obtendrás un error.

Ahora que sabemos que solo subiremos archivos compatibles con Zencoder, hagamos que una subida correcta envíe el archivo a Zencoder para su codificación. Antes de hacerlo, tendremos que establecer nuestra clave API de Zencoder. Puede incluirla justo debajo de la clave de Filepicker.

filepicker.setKey('The_Key_From_Your_Dashboard');
var zenKey = 'Zencoder_API_Key';

Ahora usaremos la función de jQuery $.ajax para enviar nuestra solicitud de API a Zencoder cuando la carga se haya realizado correctamente.

filepicker.pickAndStore({extensions: acceptedExtensions},{location: 's3'},function(fpfiles){
  // This is the simplest Zencoder API call you can make. This will output an h.264 mp4 with AAC audio and
  // save it to Zencoder's temporary storage on S3.
  var request = {
    "input": fpfiles[0].url
  }
  // Let's use $.ajax instead of $.post so we can specify custom headers.
  $.ajax({
      url: 'https://app.zencoder.com/api/v2/jobs',
      type: 'POST',
      data: JSON.stringify(request),
      headers: { "Zencoder-Api-Key": zenKey },
      dataType: 'json',
      success: function(data) {
        $('body').append('Job created! <a href="https://app.zencoder.com/jobs/'+ data.id +'">View Job</a>')
      },
      error: function(data) {
        console.log(data);
      }
  });
});

Ahora actualiza tu página y sube un vídeo. Si todo ha ido según lo previsto, deberías ver un mensaje de éxito con un enlace a tu trabajo recién creado.

Sólo 47 líneas de código después tendrás una página web que te permitirá subir un vídeo y enviarlo para su codificación.

Notas y advertencias

Es una mala idea poner tu clave API de Zencoder en texto plano dentro de JavaScript. Para repetirlo una vez más: No la utilice en código al que otras personas puedan acceder. Nada impediría que alguien cogiera su clave API y codificara todo el vídeo que quisiera.

Una idea mucho mejor sería utilizar Filepicker como se describe, pero en realidad hacer la llamada a la API Zencoder en su back-end donde su clave de API está a salvo de miradas indiscretas.

Un paso más allá

Arrastrar y soltar es realmente genial, así que queríamos hacer una página completa que utiliza Filepicker's makeDropPane. Los usuarios tienen que introducir su clave API antes de hacer nada y no se almacena en el código, por lo que el demo es seguro ponerlo en línea.

Esta versión valida la clave de la API, incluye un historial de sus trabajos recientes con Zencoder y le permite modificar la plantilla de solicitud. Todos estos ajustes se guardan en el localStorage de su navegador para que no lo pierda todo al actualizar.