VideoActas

• Proveer una página web pública para la visualización de los vídeos de los plenos.
• Certificar la autenticidad de dichos vídeos mediante firma digital, utilizando la plataforma Port@firmas.
• En la página web se mostrará un resumen de la firma y los datos del firmante. A cada vídeo le acompañará una lista de enlaces con los diferentes puntos del orden del día, que situarían al usuario en el momento adecuado en el vídeo (puntos del Orden del Día), junto con el acta de acuerdos correspondiente firmado electrónicamente (en Convoc@).
• Permitir en Convoc@ acceder a vídeos prepublicados junto con el borrador del acta correspondiente, para su visionado por los miembros del órgano de gobierno correspondiente.
• Visualizar los vídeos con capacidad de streaming sin necesidad de precargar el vídeo desde el principio.
• Proveer un sistema de Tótems de grabación con posibilidad de grabación super panorámica, integrado totalmente con el sistema de Videoactas y de forma segura a través de la red Tarsis, permitiendo la incorporación inmediata de los vídeos al sistema de información nada más terminar su grabación.

El procedimiento completo es el siguiente:

1. Partiendo de los vídeos de los plenos entregado en prácticamente cualquier formato estándar (DVD, ficheros MPEG, AVI, MP4, Matroska, etc) se suben a un servidor, a un directorio definido para ello. O bien se envían directamente desde los Tótems de grabación ya debidamente preconfigurados y conectados a la red Tarsis.
2. Un proceso programado se encarga de adaptar (concatenar, convertir, etc.) los vídeos originales a un formato adecuado para reproducción online (streaming), con la mejor calidad posible, y calculará un hash resumen de cada uno de los vídeos convertidos. Este hash se utiliza en la confección del documento a firmar.
3. Con el valor del hash y demás datos técnicos del vídeo (incluyendo marcaje de tiempos) se elabora documento PDF, para firmar electrónicamente en la herramienta Port@firmas.
4. La operatoria consta de:
   • Editor de vídeos existentes: Visualiza los vídeos, y modifica títulos, descripciones y tiempos del orden del día, incluyendo texto de observaciones sobre el vídeo aún no firmados. Esta opción se asigna al personal de la Secretaría General.
   • Prepublicación: Visualiza los vídeos con la información incluida en la opción anterior y “prepublica” para que los miembros del Pleno puedan acceder a visualizar los vídeos prepublicados.
   • Firmado de Vídeo: Visualiza los vídeos y firma del documento pdf generado, con información del hash de vídeo.
   • Publicación: Visualiza los vídeos y podrá “Publicar” los vídeos firmados electrónicamente por todos los firmantes, anexando el acta de acuerdos (acta sin debate) publicado y firmado en Convoc@. Esta opción se asigna al personal de la Secretaría General. Los vídeos publicados podrán enlazarse desde Web, Portal de Transparencia o Sede Electrónica correspondiente.

Se han seleccionado herramientas de software libre, y formatos libres. El uso de dicho software y formatos siempre tendrá la necesidad de ser gratuito, sin obligar a abonar licencias o royalties adicionales.

• Software servidor de streaming: servidor web Apache con módulo de streaming de flowplayer.
• Reproductor de videos: flowplayer, basado HTML5 o en flash embebido en el navegador, de uso gratuito, con licencia GPL.
• Códec vídeo: H.264, por su calidad en la codificación de vídeos, y altamente extendido. Aunque el formato no es libre, no hay cargo en la licencia de H.264 para vídeos gratuitos:
  http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachments/231/n-10-08-26.pdf
• Códec de audio: AAC, formato que no necesita licencias para ser distribuido:
  http://en.wikipedia.org/wiki/Advanced_Audio_Coding#Licensing_and_patents
• Utilidad de conversión: Handbrake. Software libre, basado en ffmpeg (también libre, y muy extendido), con la ventaja de que hace crop y desentralazado/decomb automáticos. Es decir, detecta y elimina los bordes negros, y quita el entralazado con el que pueden estar llegando los video originales. Además, indexa adecuadamente los vídeos para que el servidor de streaming pueda permitir que el usuario se sitúe en cualquier parte durante la reproducción. Dicha herramienta permite, de forma automática, adaptar el formato original del vídeo a un formato digital adecuado para la reproducción con calidad en un servidor de streaming.
• Formato de hash: SHA512. Es el sistema de hash o resumen con salida de mayor tamaño, lo que conlleva una menor probabilidad de colisión hash, y el coste de su cálculo casi no difiere de otros sistemas de hash. Es conveniente sobre todo debido al gran tamaño de los ficheros a los que calcular el hash.
  Referencias sobre el ciclo de vida de los algoritmos de hashing:
  • http://valerieaurora.org/hash.html
  • http://www.larc.usp.br/~pbarreto/hflounge.html
• Formato de firma: Se elabora un fichero PDF con todos los datos (datos del video y hash resumen), y se firma en formato de firma avanzada (XADES, CADES, etc, según se configure en Port@Firmas). Para cada firma de fichero, se elaborará un informe de firma, que consistirá en un nuevo documento PDF que incluye una versión del documento firmado reducido a un 80% del tamaño original y en el que se ha incluido en cada página, en la parte inferior, un pie de firma digital que contiene toda la información del proceso de firma. Existirá la posibilidad de verificar el documento original y sus datos de firma en la aplicación Verifirm@ que forma parte de Port@firmas.

El sistema básico se compone de un servidor de aplicaciones y un servidor multimedia, aunque para entornos con mucha carga de usuarios podrían instalarse varios nodos para repartir la carga.

Ambos componentes pueden coexistir en el mismo servidor, aunque se recomienda dedicar un servidor en exclusiva para cada componente.

Requisitos Software del Servidor de Aplicaciones

• Sistema Operativo: Debido al uso de Java, la aplicación puede funcionar sobre cualquier Sistema Operativo para el que exista Máquina Virtual Java, aunque se recomienda Linux o Solaris. La aplicación ha sido ampliamente probada sobre Suse 10, Ubuntu Server 14.04 y Windows 7.
• Apache Tomcat 6.0, que será el contenedor donde va a desplegarse la aplicación. Ha sido probado ampliamente en la versión 6, pero no se descarta que sean válidas también versiones superiores. Se recomienda que, en la medida de lo posible, el servidor Apache Tomcat sea ejecutado por un usuario del sistema operativo con permisos limitados, y no por el usuario Administrador o root. Para más información en este sentido, nos remitiremos a la documentación oficial. Para entornos con un número elevado de usuarios o simplemente para mejorar la disponibilidad de la aplicación, se pueden instalar varios servidores Tomcat con la aplicación desplegada en cada uno de ellos, y utilizar un balanceador de carga para publicar la aplicación, ya sea hardware o software (ej: HAProxy, Apache con mod_proxy_balancer). En este caso, el balanceador tendría que configurarse con “sticky sessions”.
• JDK 1.6 instalado y configurado correctamente en la máquina servidor que va a alojar la aplicación. La variable JAVA_HOME debe estar definida y apuntando a dicha JDK. O bien debe definirse en el script de inicio del servidor Apache Tomcat (normalmente catalina.sh o catalina.bat).
• Base de Datos Oracle 10g o superior en Linux o Windows , accesible desde el servidor donde se instalará la aplicación. También son posibles otros sistemas operativos donde Oracle soporte su versión 10gR2. La potencia del servidor de base de datos dependerá del volumen de registros se vayan a tratar.

Requisitos Hardware del servidor de Aplicaciones

La aplicación utiliza tecnología Java y, por tanto, no existen restricciones directas sobre la arquitectura hardware a utilizar. Dependerá directamente del número máximo de usuarios concurrentes estimados. Con respecto a la memoria, se recomienda un servidor con un mínimo de 1 Gb de RAM, aunque no más de 2 Gb. Si se tiene una gran carga de usuarios y el servidor se queda sin memoria, es más recomendable usar varios servidores virtuales idénticos con 2 Gb de RAM cada uno, y balancear la carga hacia ellos mediante un balanceador HTTP con sticky sessions. De ésta forma es mucho más sencillo escalar el sistema con respecto a la carga estimada.

Requisitos Software del servidor multimedia

• Sistema Operativo sobre el que pueda instalarse el software requerido.
• Servidor web Apache con módulo de streaming de flowplayer
• Utilidad de conversión HandbrakeCLI
  https://handbrake.fr/

Requisitos Hardware del servidor multimedia

Dependerá directamente del número máximo de usuarios concurrentes estimados. Aunque el servidor web escogido es muy ligero y requiere muy poca memoria para funcionar, disponer al menos de unos 4 Gb de RAM puede beneficiar a la caché de disco (si el Sistema Operativo puede usar caché de disco en memoria) y así mejorar las prestaciones en el streaming de los vídeos con más carga de usuarios concurrentes.

El servidor multimedia debe contar con una buena conexión de red (una interfaz de red Gigabit como mínimo) y no verse afectado por reglas de gestión de tráfico que pueda tener la topología de red en la que se instale (QoS, packet shaping, etc.).

Requisitos Software del Cliente

• Sistema Operativo Windows 7 o superior, Linux (cualquier distribución compatible con los navegadores indicados abajo).
• Navegador web Internet Explorer 11 o superior, Mozilla Firefox 4 o superior o Chrome. Recomendable utilizar las versiones más recientes del navegador escogido.
• Opcionalmente, si el navegador no fuera compatible con HTML 5, se puede utilizar el reproductor Flash con plugin para el navegador.
• Adobe Reader 7 o superior.

Requisitos Hardware del Cliente

Procesador de doble núcleo (Pentium Dual Core, Intel Core i3 o superior) y 512 Mb RAM (Recomendado: 1Gb RAM).