viernes, 26 de agosto de 2016

SUS 17 mini

Hemos decidido saltearnos la versión 16 de S.U.S. ya que el año no se presentó muy próspero.

Así que pensamos en un desarrollo doble para el 2017: El SUS 17 mini y el SUS 17 pro.

Estamos en pleno desarrollo del SUS 17 mini que contará con una novedad que llamamos streamdb. Se trata del almacenamiento de los videos en un formato TS unificado a los criterios de la configuración del usuario.
Se podra seleccionar fragmentos de 1 segundo de duración mínima de cada video, concatenarlos con otros y generar un solo stream. A su vez, a l hora de almacenar el streamdb podrá manejar múltiples unidades de discos. En el momento de almacenar define en que disco guardarlo evitando que se llenen.
El sistema genera un stream multicast con video H264 y audio mp2. El video soporta hasta el FullHD (1920x1080) y el audio se emite en estereo a 192kb.

En desarrollo.
El sistema se controlará desde una API web, una consola Linux y/o su propio sitio web.
Se podrá emitir videos previamente almacenados y el sistema mantendrá un sistema para relleno en caso de no haber videos en el spooler.
Cuenta con un motor gráfico de doble spool: uno para aplicaciones y otros para gráficos del usuario.

Otras funcionalidades se encuentran en desarrollo.

Hemos venido reescribiendo el código desde nuestro primer SAS. Ganando en experiencia en éste terreno en donde hay pocas alternativas para los Cable Operadores y emisores de video profesional.

Muy pronto!

martes, 9 de agosto de 2016

Scripts controlados

Queremos compartir un nuevo script que nos está resultando muy util en nuestros sistemas. Es una evolución de KRUN (Krab RUN) siempre apuntando a la simplicidad y efectividad.
El nuevo código requiere que el programador cargue una variable con un ID que no vaya a repetir. Que no se encuentre en tiempo de ejecución en otros programas y que sea mnemotécnicamente identificable por el programador.

El concepto es muy simple, se lanza el script y al ingreso comprueba si existe su propia ID dentro de los programas en ejecución, en caso de no existir asume que no fue ejecutado  y se ejecuta mediante un exec y finaliza el script. La diferencia es que el lanzado por exec tendrá la ID como parte de los parametros de ejecución. De ésta manera en la segunda instancia si existirá una copia ejecutándose y no se lanzará nuevamente.

#!/bin/bash
# #########################################################
# Script programado por Carlos Giurleo - V0.2
# Uso de dominio publico
#
# ID unica para este script basado en el nombre sin ruta
unid="`basename $0 | base64`"
#
# Control de duplicado
if [ "`ps aux | grep ${unid} | grep -v grep`" = "" ]; then
        echo ${unid} > /tmp/${unid}.unid
        exec $0 $@ ${unid}
        exit
fi
# Control de instancia
if [ "`echo $@ | grep ${unid}`" = "" ]; then
        exit
fi
 # #########################################################
#
#
# MAIN

while true; do
        echo Funciona
        sleep 1
done


Si el script se vuelve a cargar estando en ejecución, no se validará porque ya existirá una copia y continua al segundo control. El mismo verifica que en la linea de comandos exista la ID. Esta trampa está para evitar el siguiente escenario:
Un script se ejecuta desde un cron. Se carga, hace su primer recarga y ya se está ejecutando con el ID entre sus comandos. Si el cron lo vuelve a ejecutar, la primer trampa no lo dentendria ya que SI existe una copia en ejecución. Para evitar que se ejecute nuevamente la segunda trampa detectará que no es una ejecución válida ya que no tiene el ID entre los parámetros.

Obviamente desde el # MAIN hacia el final irá el código que necesite. El loop fue colocado como demo.

Código cedido a dominio público.