Gestionando videos en un workflow analógico

Muchas veces la necesidad de hacer cosas choca contra los recursos que dispones. Y si la necesidad de hacer cosas es mucha, a veces, terminamos, o bien atando las cosas con alambre o bien creando cosas que nunca nos hubiéramos imaginado.

Quisiera decirles que de lo que les voy a hablar es lo segundo, pero es una mezcla (en un 30/70 de cada uno respectivamente) que resultó de una necesidad puntual del trabajo.

En una etapa de cambios internos, surgió la necesidad imperiosa de subir fragmentos de video a Youtube. Pero no todo era tan fácil.

El Trasfondo

Subir un video a Youtube no sería algo complejo si la empresa hubiera tenido en ese momento un workflow de trabajo digital, es decir, si los assets de video estuvieran en files controlados por un sistema de gestión central.

Todos los assets de video estaban en tapes. No VHS, sino Betas digitales, de buena calidad, pero casi igual de obsoletos en su uso.

Para poder disponer de videos en digital, se había estado trabajando en digitalizar los fragmentos que se iban a subir. El tema es que no había que subir 5 videos. Tampoco 10, 50 o 100. Estábamos hablando de una cantidad de 1500 y contando, pues el proceso de digitalización, no se detenía.

Gracias trabajo manual que involucraba el proceso, nos habría llevado meses realizar la tarea de upload. Y cabe aclarar que no se limitaba solo a subir el video.

El proceso de digitalización, entregaba un video con un nombre descriptivo que a veces no lo era tanto. A este video había que sumarle, la metadata, el título, una descripción coherente, tags, etc., cosas que Youtube pide al momento de subir un video. Ah, y generar una captura del video que sea atractiva.

Como es fácil de darse cuenta, hacer esto a mano, era, y es, una tarea muy poco práctica. Pero, era el método que se iba a hacer, porque, no había otra forma.

Como la mayoría de las tareas técnicas, esta tarea recayó en mí, la de subir todos estos videos. Disponíamos de una web interna que se utilizaba para controlar que videos se digitalizaban. Y esta Web, fue la que me dio la idea de hacer un sistema para gestionar los videos, su metadata, y poder subirlos a Youtube.

Es así, como, tras presentar mi plan de desarrollo, me embarqué en esta tarea de dos semanas que finalmente fueron tres, en las que tuve lista esta herramienta que aún hoy seguimos utilizando para gestionar videos.

El inicio

Siendo un usuario frecuente  de tecnologías Microsoft, me decidí por realizar este sistema en C#/Winforms, pues, salvo honrosas excepciones, en la empresa se usa Windows en todas las máquinas. Como base de datos, utilizamos SQL Server. Los files se almacenan en una carpeta de red y los nombres de almacenamiento son dados por el sistema automáticamente para evitar problemas de nombres duplicados.

La aplicación, en su primer versión, permitía catalogar videos en varias categorías a la vez, y definir distintos subtipos. Esto permite ubicar videos usando distintos criterios de forma sencilla.

El primer desafío que tuve, fue como mostrar el listado. Los controles de Windows Forms para este fin, no son lo más amigables que existen. Tampoco son los más económicos (recordemos que en este caso contábamos con presupuesto $0). Por esa razón, el área de listado es un WebView y el listado en sí es un HTML.

Al momento de consultar los videos, se genera un HTML que se inyecta en el control. Al hacer click en los links/botones del HTML, se intercepta la llamada y se ejecutan acciones. en este caso la única acción, de momento, es abrir la ventana de información del video.

El resultado, es interesante y dentro de todo original. Como contrapartida, no permite navegar con el teclado, pero bueno, por 0$ no podemos andar quejándonos, ¿no?

La ventana información del video, contiene una variada cantidad de campos como título, descripción, capitulo, etc. Se incluyen además tags, capturas, categorías múltiples y en ciertas categorías la vinculación a otros sistemas para permitir con posterioridad asignar los videos a contenidos web.

Obviamente, se puede pre visualizar el video en esta ventana. En un principio, utilice Mplayer, pero tras varios problemas en el uso, lo cambie por VLC. Si bien el control está embebido en la ventana, se puede abrir en una ventana distinta.

En la reproducción embebida en la pantalla, se puede generar una captura pausando el video y pulsando el botón de generar captura. El método funciona bien, salvo para algunos formatos de video en los que directamente captura el frame que le parece. Como no es una opción muy utilizada aún sigue así, pero no descarto corregirla algún día.

¿Cómo se agregaban / agregan videos al sistema?

Mediante un proceso de Ingesta automática (ok en un principio era manual). De esta forma, los videos digitalizados, se copian en una carpeta de red y el proceso los analiza, genera una captura aleatoria, los almacena con un nombre en forma de GUID y los ingresa en el sistema. El control de videos repetidos se hace por MD5.

Youtube

Una vez que disponíamos del sistema, y teníamos concentrados en un lugar videos y metadata, nos quedaba subir los videos. A Youtube. Más de 1500.

Habré subido 3 o 4 y ya estaba leyendo la especificación de la API de Youtube para ver si se podía automatizar esa tortuosa tarea, cuando de repente, se abrieron las puertas del cielo: Youtube nos invitó a ser Content Partners.

Eso significaba que podríamos subir videos con su metadata, por SFTP. Golazo. En el sistema hicimos una modificación. En la pantalla de Propiedades de Video, agregamos la opción de Publicar en Youtube. Los datos de publicación se almacenaban en otra tabla (Principalmente por si se quería variar un título o descripción de la genérica) y desde dicha tabla se generaba el XML de metadata que interpretaba Youtube.

Una vez hecho esto, empezó el viaje de una semana (o menos) en la que hice el proceso para subir al SFTP. Y digo proceso, porque no requiere que el usuario estuviera frente a la pantalla para que se realice la subida, y tampoco se cancelaria porque el usuario cerrara el programa. Para el operador, la tarea de upload (así como muchos otros procesos que menciono más adelante) se realiza en segundo plano sin saber exactamente cómo sucede. Porque ciertas cosas, es mejor no saber cómo suceden. Para no confundir vió.

Este proceso utiliza WinSCP, que funciona perfecto y permite automatizar las subidas y descargas de contenido. También nos permite ejecutar varios procesos de upload simultáneos, lo que acelera bastante la subida de files.

En paralelo, corre otro proceso que monitoriza los videos subidos y asigna los IDs a los contenidos que están asociados al video.

Con este sistema listo, la aplicación estaba finalizada. O al menos eso creía.

Aló Sony

Al poco tiempo de terminado el proceso de upload a Youtube, se presentó otro desafío. La empresa firmó un acuerdo con Sony para publicar contenidos en su plataforma de contenidos de Video Bravia. Sin entrar en detalles, el sistema es simple, es una especie de XML con información de los videos y los links a los videos en sí.

Teníamos los videos digitalizados por un lado, la metadata por otro, pero teníamos que publicarlos, no en un FTP, sino en una web.

Fue así que primero, intentamos crear videos que sean compatibles. Los Smart TVs son un tanto quisquillosos con los videos que reproducen, aun así, logramos que HandBrake (Si, Open Source, porque recuerden, presupuesto 0$) genere los videos en el formato correcto.

Una vez eso listo, empezó el armado de un nuevo proceso que integraba el handbrake, y otra herramienta (que arme yo también), que sube files a Amazon S3 usando cURL.

El resultado fue excelente y al tener ya los contenidos en una forma fácilmente automatizable, gracias al sistema, logramos una implementación en tiempo record.

Una vez liberado el sistema, notamos que la plataforma no disponía de estadísticas. Obviamente, para vender un proyecto de estos internamente, se necesitan datos (aunque nadie entienda que significan, datos, necesitan datos). De modo que creamos una web que hacia el redirect a los videos y en el XML indicamos los links no a los videos en sí, sino a la web de redirección.

Si bien no sabemos en qué porcentaje se reproducen los videos (es decir, si se reproducen completos,  o donde dejan de verlos etc.), pues no hay forma de saberlo, si podemos saber cantidad de reproducciones, ubicaciones y algunos datos útiles más. Y por el presupuesto asignado a esta feature, estaba más que bien.

Y video en mobile también

Sí, porque si algo funciona bien 2 veces, siempre te van a pedir que funcione 3, o cuatro. O cinco.

Y fue así que, siendo que teníamos contenido,  ¿por qué no alimentar una app Mobile de video con el contenido?

Y fue así como empezó una relación con una empresa del cercano oriente, que desarrollaría la aplicación para ver de automatizar la transferencia de materiales.

Tras varias idas y vueltas con el formato de intercambio (principalmente debido a que las herramientas de código abierto tienen limitaciones) logramos definirlo, pero, el sistema de ellos no permitía automatización alguna.

Logramos que nos permitan subir automáticamente los videos a un bucket de S3, lo que agilizó una mitad del trabajo, pero la otra parte, la carga de metadata, sigue siendo manual.

Aun así, el sistema tiene una pantalla para facilitar al operador la tarea de copiar y pegar la metadata, así como las rutas de las imágenes. Y si, todo no se puede.

Y más Smart TV

La estrategia de Sony de conseguir contenidos exclusivos para su plataforma de Smart TV, tuvo su réplica en otras empresas que hacen Smart TVs. En nuestro caso tuvimos que desarrollar para dos nuevas plataformas, para NetTv de Philips y para una plataforma china que usan unos Smart TVs hechos en Argentina.

Sin entrar en muchos detalles, estas plataformas se basan en HTML, lo que permite mas libertades que la plataforma original de Sony, pero suma más desafíos (que oportunamente comentare).

Para publicar contenidos para esta plataforma,  el sistema incorporó el concepto de plataforma,  para cada plataforma, se definen templates HTML que posteriormente serán completados con los datos correspondientes. Así mismo, cada plataforma, permite tener trascodificación independiente y ajustar los parámetros separadamente, lo que permite utilizar ffmpeg, handbrake u otras herramientas, vía batch files para cada perfil. Por el contrario, si fuera el caso, mas de una plataforma podría compartir el mismo perfil de trascodificación.

El proceso de publicación, primeramente realiza las tareas de trascodificación, luego sube los contenidos a Amazon S3 (vídeos e  imágenes) y posteriormente genera el HTML en base a los templates de cada plataforma. El último paso consiste en enviar el contenido generado a un WebService para su publicación final en las aplicaciones web, desarrolladas por separado.

En el área de publicación, se trabajo para simplificar la interface al máximo para evitar que el operador se confunda, pero, afrontémoslo, hay ciertas cosas que no se pueden simplificar mucho.

Kaltura y el video server que no pudo ser

Y un día surgió la idea ¿y si además de a Youtube, subimos los vídeos a una plataforma propia para embeberlos en nuestro sitio y vendemos las publicidades pre-roll?

Fue así que empecé a buscar que proveedores nos convenían mas. La única contra que tenían (perdón, tienen) es que cobran por sus servicios. Fea la actitud. Mala onda. Y más aun siendo que tenemos presupuesto cero.

Fue así que surgió la idea de Kaltura, un video server de código abierto, del cual hablare en un post aparte. Lo instalamos en un modesto servidor que teníamos y agregamos un exportador de metadata para este sistema en nuestra aplicación.

Si bien las pruebas fueron exitosas,  la empresa decidió romper el chanchito, y se decidió por un servicio pago.

Por esta razón, la implementación de Kaltura quedo a mitad de camino,  pero no descarto que un dia de estos la necesidad la haga resucitar.

Brightcove

Finalmente,  tras muchas idas y vueltas, la empresa se decidió por Brightcove como plataforma de video. En este caso la integración fue sencilla,  en parte gracias a la experiencia previa.

La interface de publicación es muy sencilla y permite seleccionar varios perfiles, los que se aplican al video subido para aplicar logos distintos según el destino.

La plataforma solo admite files .mp4, por lo que el proceso se encarga de convertirlo en caso de ser necesario y luego sube la metadata, imágenes y video al FTP correspondiente.

Cuando el proceso finaliza, se dispara un callback que corre en nuestros servidores, que sirve para la asignación de videos a los contenidos correspondientes, algo similar a lo que hacemos con Youtube.

Marketing

Si analizamos estos procesos por separado no son nada, pero en conjunto, todos estos modulos conforman lo que de momento, llamamos una plataforma unica de publicacion. El nombre que le hemos dado en Content Everywhere, porque en realidad, contamos con la flexibilidad de disponer el contenido en diversas plataformas sin mayores problemas.

Y en realidad, un nombre era necesario para poder valorar dentro de la empresa uns efuerzo que lleva casi 3 años al momento de escribior este artículo.

La experiencia del camino recorrido

Lo que en un principio se pensó como algo temporal, para salir del paso, termino siendo una herramienta casi indispensable,  al menos de momento, en nuestra área y otras, para catalogar material de video y realizar video trascoding.

Y en el camino aprendí muchísimas cosas. Leer varias veces los manuales de Ffmpeg, Handbrake, Mplayer y muchas otras herramientas me ayudo a entender cómo funcionan, a aprender trucos no documentados,  y por sobre todas las cosas a odiar con todo mi corazón a los encargados de documentar algunos proyectos de código abierto :)

En efecto,  aprendí muchísimo desarrollando esta aplicación, mucho más de lo que jamás me hubiese imaginado.

En cuanto al futuro, no sabemos. Parece que finalmente se digitalizará el flujo de trabajo de la empresa,  pero, aun no hay nada implementado, y, siendo que estas cosas tardan meses, calculo que tendremos que seguir usando y agregándole características a esta aplicación un buen rato más.