Desarrollo-de-un-sistema-de-monitoreo-de-senales-de-audio-y-video-para-televisoras

Vista previa del material en texto

DESARROLLO DE UN SISTEMA DE MONITOREO DE SEÑALES 
DE AUDIO Y VIDEO PARA TELEVISORAS 
 
Tesina 
que para obtener el título de 
Ingeniero en Computación 
 
Realizado por SALVADOR BEDREDÍN MEDINA MAZA 
bajo la supervisión de GILBERTO MARRÓN VILLAFÁN 
Ciudad Universitaria 2012 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
FACULTAD DE INGENIERÍA 
 
UNAM – Dirección General de Bibliotecas 
Tesis Digitales 
Restricciones de uso 
 
DERECHOS RESERVADOS © 
PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL 
 
Todo el material contenido en esta tesis esta protegido por la Ley Federal 
del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México). 
El uso de imágenes, fragmentos de videos, y demás material que sea 
objeto de protección de los derechos de autor, será exclusivamente para 
fines educativos e informativos y deberá citar la fuente donde la obtuvo 
mencionando el autor o autores. Cualquier uso distinto como el lucro, 
reproducción, edición o modificación, será perseguido y sancionado por el 
respectivo titular de los Derechos de Autor. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
In Memoriam 
Salvador Medina Manríquez 
Isabel Ramírez Otero 
Abraham Montiel 
 
 
 
 
 
Agradecimientos 
 
Quiero agradecerle a mi mamá por propiciar un ambiente adecuado para mi 
formación personal y profesional. Le debo gran parte de lo que soy hoy en día y este 
trabajo es una respuesta al apoyo incondicional que me ha dado a través de mi vida. 
A ti Julie por hacerme ver lo valioso que soy y demostrarme de lo que soy capaz 
viéndome como una figura a seguir. Semper frateri. 
A ti Chente por apoyarme en la base de mi educación con incontables tardes de 
cultura y tareas a resolver y estribar mi manera de percibir el conocimiento durante la 
inmortalidad del cangrejo. 
A ti Mariana, por aceptar ser mi adorable esposa y apoyar mis ideas en todo 
momento, por estar ahí en esos momentos de desesperanza y nunca dar por vencida la 
idea de titularme para lograr mis anhelos y deseos en el ámbito profesional y académico. 
Te amo. 
También quiero agradecer a mis suegros por apoyarme en los últimos años, 
favoreciendo un ambiente con menos preocupaciones, mediante el cuál pude enfocarme 
a realizar este escrito. 
 
Gracias a la Universidad Nacional Autónoma de México por acobijarme durante mi 
formación como profesionista y otorgarme la oportunidad de vislumbrar un México distinto 
al que conocía anteriormente. Agradezco a la Facultad de Ingeniería por permitirme ser 
parte de esa gran familia académica, tan noble, donde nos inculcan ser mejores cada día 
para así poder formar un México mejor. 
 
Dr. Jesús Savage, muchas gracias por permitirme ser uno de sus pupilos y 
partícipe de sus proyectos. Usted me introdujo en el desarrollo y la investigación de una 
manera formal, en la elaboración de proyectos relevantes y otórgame la oportunidad de 
trabajar en un equipo. Es un gran ejemplo a seguir y este escrito se lo debía desde hace 
muchos años. 
 
También quiero dar las gracias a Fission Software y en especial a Artemio por 
invitarme a ser parte de un equipo de trabajo sin igual. Me han permitido crecer en el 
ámbito profesional confiando en mis habilidades para la elaboración de proyectos tan 
interesantes. Son una gran familia para mí. 
 
Gracias a Abraham Monrroy, Abraham Segura, Carlos Alegría y Francisco 
Rodríguez, por guiarme en la elaboración de este escrito y retroalimentarme con sus 
comentarios durante las revisiones que hicieron. Porque a pesar de los años que tomó 
hacerlo, confiaron en que algún día lo terminaría. También le agradezco a Carlos Velasco 
la revisión final que hicimos de una manera bastante dinámica, como lo solíamos hacer 
durante nuestra educación universitaria. Lo logramos. 
 
Y a ti, porque a pesar de que te encontré tarde, te encontré, para que seas mi 
inspiración a seguir, el pilar en mi mejora como ser humano. Ahí espérame por que en 
algún tiempo y espacio nos volveremos a reunir. 
 
 
 
 
Índice 
 
INTRODUCCIÓN _________________________________________________________ VII 
CAPÍTULO 1 - FISSION SOFTWARE _________________________________________ 9 
ESQUEMA GENERAL DE UNA ESTACIÓN DE TELEVISIÓN ____________________________ 10 
MÓDULOS DE FISSION ____________________________________________________ 11 
FLUJO DE TRABAJO CON FISSION ____________________________________________ 12 
CAPÍTULO 2 - ACTIVIDADES DENTRO DE FISSION SOFTWARE ________________ 13 
CAPÍTULO 3 - FISSION ON-AIR MONITOR ___________________________________ 17 
3.1 REQUERIMIENTOS DEL PRODUCTO ________________________________________ 19 
3.1.1 Primer Bosquejo de la Interfaz ______________________________________ 19 
3.2 DISEÑO DEL PRODUCTO ________________________________________________ 25 
3.2.1 Arquitectura Cliente-Servidor _______________________________________ 25 
3.2.2 Descripción General del Sistema ____________________________________ 26 
3.2.3 Modelo Iterativo Incremental _______________________________________ 28 
3.3 HERRAMIENTAS UTILIZADAS PARA SU PROGRAMACIÓN _________________________ 33 
3.3.1 MFC __________________________________________________________ 33 
3.3.2 DirectShow _____________________________________________________ 33 
3.3.3 Tarjeta Optibase MM400 __________________________________________ 36 
3.3.4 Optibase SDK ___________________________________________________ 38 
3.3.5 Capas de abstracción _____________________________________________ 41 
3.4 ANÁLISIS PREVIO AL DESARROLLO ________________________________________ 42 
3.4.1 Análisis de la Comunicación Interprocesos ____________________________ 42 
3.4.2 Sockets ________________________________________________________ 44 
3.4.3 Búsqueda de Archivos ____________________________________________ 49 
3.5 DESARROLLO ________________________________________________________ 55 
3.5.1 Implementación y Distribución de Versiones ___________________________ 55 
3.5.3 Fission Monitor Server ____________________________________________ 56 
Programación paralela ________________________________________________ 67 
3.5.4. Fission Monitor Upkeeper _________________________________________ 71 
3.5.5 Fission Monitor Client _____________________________________________ 73 
3.6 PRUEBAS AL SISTEMA _________________________________________________ 84 
3.6.1 Fission Monitor Server ____________________________________________ 85 
3.6.2 Fission Monitor Upkeeper__________________________________________ 86 
3.6.3 Fission Monitor Client _____________________________________________ 87 
3.6.4 Fission Monitor Exporter ___________________________________________ 90 
3.7 RESULTADOS DEL PROYECTO ____________________________________________ 93 
CONCLUSIONES ________________________________________________________ 97 
APÉNDICE A____________________________________________________________ 99 
MANEJO DE GRAPHEDIT ___________________________________________________ 99 
Abrir un archivo usando Intelligent Connect ________________________________ 99 
Construcción manual de una gráfica _____________________________________ 100 
APÉNDICE B___________________________________________________________ 103 
FILTRO FUENTE DE UNA GRÁFICA ___________________________________________ 103 
 
 
APÉNDICE C___________________________________________________________ 105 
PROTOCOLO DE COMUNICACIÓN ____________________________________________ 105 
Inicialización de la entrada ____________________________________________ 105 
Manipulación de la captura ____________________________________________ 106 
Configuración del sistema _____________________________________________ 107 
Consultas al sistema _________________________________________________ 110 
APÉNDICE D___________________________________________________________ 117 
CONFIGURACIÓN OPTIBASE PLAYER 400 _____________________________________ 117 
GLOSARIO ____________________________________________________________ 119 
REFERENCIAS_________________________________________________________ 121 
 
 
Índice de Figuras 
 
FIGURA 1.1- ESQUEMA GENERAL SISTEMA FISSION _______________________________________ 12 
FIGURA 3.1 - INTEGRACIÓN FISSION OAM ______________________________________________ 17 
FIGURA 3.2 - FONDO DE PANTALLA ___________________________________________________ 19 
FIGURA 3.3 - DIÁLOGO SELECCIÓN DE CANAL ____________________________________________ 20 
FIGURA 3.4 - DIÁLOGO DE SESIÓN DE CAPTURA __________________________________________ 21 
FIGURA 3.5 - DIÁLOGO DE VISUALIZADOR DE VIDEO _______________________________________ 22 
FIGURA 3.6 - DIÁLOGO DE CONFIGURACIÓN DE ENTRADA ___________________________________ 23 
FIGURA 3.7 - CLIENTE-SERVIDOR ____________________________________________________ 26 
FIGURA 3.8 - DIAGRAMA MODULAR DE FISSION ON-AIR MONITOR _____________________________ 27 
FIGURA 3.9 - INTERACCIÓN DE LOS MÓDULOS ____________________________________________ 28 
FIGURA 3.10 - CICLO ITERATIVO DEL MODELO ITERATIVO INCREMENTAL ________________________ 29 
FIGURA 3.11 - GRÁFICA DE EJEMPLO DE REPRODUCCIÓN DE VIDEO ____________________________ 34 
FIGURA 3.12 - USO DEL FILTER GRAPH MANAGER ________________________________________ 34 
FIGURA 3.13 - TARJETA OPTIBASE MM400 SON SU CABLE __________________________________ 36 
FIGURA 3.14 - USO BÁSICO DEL OPTIBASE SDK__________________________________________ 38 
FIGURA 3.15 - CAPA DE ABSTRACCIÓN EN EL SERVIDOR ____________________________________ 41 
FIGURA 3.16 - CAPA DE ABSTRACCIÓN EN EL CLIENTE _____________________________________ 41 
FIGURA 3.17 - CAPAS MODELO OSI __________________________________________________ 46 
FIGURA 3.18 - ENCAPSULAMIENTO DE DATOS EN EL MODELO OSI _____________________________ 47 
FIGURA 3.19 - ABSTRACCIÓN DE CAPAS PARA SOCKETS TCP Y UDP __________________________ 47 
FIGURA 3.20 - ESTRUCTURAS DE DATOS EN TCP Y UDP ___________________________________ 48 
FIGURA 3.21 - DATAGRAMA TCP _____________________________________________________ 48 
FIGURA 3.22 - DATAGRAMA UDP ____________________________________________________ 49 
FIGURA 3.23 - LISTAS ORDENAMIENTO POR MEZCLA ______________________________________ 52 
FIGURA 3.24 - ORDENAMIENTO POR MEZCLA PASO 1 ______________________________________ 52 
FIGURA 3.25 - ORDENAMIENTO POR MEZCLA PASO 2 ______________________________________ 52 
FIGURA 3.26 - ORDENAMIENTO POR MEZCLA PASO 2 ______________________________________ 53 
FIGURA 3.27 - ORDENAMIENTO POR MEZCLA PASO FINAL ___________________________________ 53 
FIGURA 3.28 - DIAGRAMA DE FLUJO BÚSQUEDA DE ARCHIVO _________________________________ 54 
FIGURA 3.29 - DIAGRAMA FISSION MONITOR SERVER _____________________________________ 57 
FIGURA 3.30 - MÁQUINA DE ESTADOS DE UNA ENTRADA DE A/V ______________________________ 57 
FIGURA 3.31 - MÁQUINA DE ESTADOS INTERNA DE UNA ENTRADA _____________________________ 59 
FIGURA 3.32 - DIAGRAMA DE FLUJO DEL PROCESO DE VERIFICACIÓN ___________________________ 60 
FIGURA 3.33 - PARSER DE RECEPCIÓN DE MENSAJES ______________________________________ 65 
FIGURA 3.34 - ÍCONOS DE ESTADO DE FISSION MONITOR SERVER ____________________________ 69 
FIGURA 3.35 - MENÚ CONTEXTUAL DEL MÓDULO SERVER ___________________________________ 69 
FIGURA 3.36 - DIÁLOGO DE ESTADO DEL MÓDULO SERVER __________________________________ 70 
FIGURA 3.37 - DIAGRAMA DE FLUJO OPERACIÓN UPKEEPER _________________________________ 71 
FIGURA 3.38 - - FLUJO DE DIÁLOGOS DEL MÓDULO CLIENT __________________________________ 73 
FIGURA 3.39 - SESIÓN DE GRABACIÓN FINAL ____________________________________________ 74 
FIGURA 3.40 - VISUALIZADOR DE CAPTURA FINAL _________________________________________ 75 
FIGURA 3.41 - REGISTRO DE CAPTURA EN BLOQUES _______________________________________ 76 
FIGURA 3.42 - DIÁLOGO FINAL DE EXPORTACIÓN _________________________________________ 77 
FIGURA 3.43 - EXPORTACIÓN SEGMENTO EN UN ARCHIVO ___________________________________ 77 
FIGURA 3.44 - EXPORTACIÓN SEGMENTO EN MÚLTIPLES ARCHIVOS ____________________________ 78 
FIGURA 3.45 - EXPORTACIÓN CON ENTRADA SIN REGISTRO__________________________________ 78 
FIGURA 3.46 - EXPORTACIÓN CON SALIDA SIN REGISTRO ___________________________________ 78 
FIGURA 3.47 - EXPORTACIÓN CON UN HUECO____________________________________________ 79 
FIGURA 3.48 - EXPORTACIÓN CON MÚLTIPLES HUECOS _____________________________________ 79 
FIGURA 3.49 - DIÁLOGO DE PROCESO DE EXPORTACIÓN ____________________________________ 81 
FIGURA 3.50 - DIÁLOGO FINAL DE CONFIGURACIÓN ________________________________________ 83 
FIGURA 3.51 - RESULTADO DE LA PRUEBA DE MEMORIA DEL SERVER __________________________ 85 
file:///C:/Documents%20and%20Settings/Zal/My%20Documents/Dropbox/Titulacion/TESINA/Docs/Final/Reporte%20de%20Trabajo%20Profesional%20(3a%20Revisión).docx%23_Toc324956891
file:///C:/Documents%20and%20Settings/Zal/My%20Documents/Dropbox/Titulacion/TESINA/Docs/Final/Reporte%20de%20Trabajo%20Profesional%20(3a%20Revisión).docx%23_Toc324956913
 
FIGURA 3.52 - RESULTADO DE LA PRUEBA DE HANDLES DEL SERVER __________________________ 86 
FIGURA 3.53 - RESULTADO DE LA PRUEBA DE MEMORIA DEL UPKEEPER ________________________ 86 
FIGURA 3.54 - RESULTADO DE LA PRUEBA DE HANDLES DEL UPKEEPER _________________________ 87 
FIGURA 3.55 - RESULTADO DE LA PRUEBA DE MEMORIA DEL CLIENT ___________________________ 87 
FIGURA 3.56 - RESULTADO DE LA PRUEBA DE HANDLES DEL CLIENT ___________________________ 88 
FIGURA 3.57 - RESULTADO DE LA PRUEBA DE MEMORIA DEL RECORD VIEWER ____________________ 88 
FIGURA 3.58 - RESULTADO DE LA PRUEBA DE HANDLES DEL RECORD VIEWER ____________________ 89 
FIGURA 3.59 - REGRESIÓN LINEAL DE LOS HANDLES DEL RECORD VIEWER ______________________ 90 
FIGURA 3.60 - RESULTADO DE LA PRUEBA DE MEMORIA DEL EXPORTER ________________________ 91 
FIGURA 3.61 - RESULTADO DE LA PRUEBA HANDLES DEL EXPORTER ___________________________ 92 
FIGURA A.1 - ABRIR UN ARCHIVO EN GRAPHEDIT POR MENÚS ________________________________ 99 
FIGURA B.1 - GRÁFICA DE REPRODUCCIÓN DE VIDEO _____________________________________ 101 
FIGURA D.1 - CONFIGURACIÓN DEL OPTIBASE PLAYER 400 ________________________________ 117 
 
 
file:///C:/Documents%20and%20Settings/Zal/My%20Documents/Dropbox/Titulacion/TESINA/Docs/Final/Reporte%20de%20Trabajo%20Profesional%20(3a%20Revisión).docx%23_Toc324956941
 
 
Índice de Tablas 
 
TABLA 3.1 - LISTA DE CONTROL DE PROYECTO ___________________________________________ 30 
TABLA 3.2 - CARACTERÍSTICAS TÉCNICAS DE LA TARJETA MM400 ____________________________ 37 
TABLA 3.3 - RESOLUCIONES DE VIDEO SOPORTADAS POR LA TARJETA MM400 ___________________ 38 
TABLA 3.4 - PUERTOS UDP UTILIZADOS ________________________________________________ 61 
TABLA 3.5 - TIPOS DE COMANDO POR PARÁMETRO ________________________________________ 64 
TABLA 3.6 - ERRORES QUE DETECTA EL PARSER _________________________________________ 66 
TABLA 3.7 - RESULTADO PRUEBA DE EXPORTACIÓN _______________________________________ 91 
 
 
 
 
 
 
 
Introducción 
 
El propósito de este reporte es describir mi trabajo, de una manera general, dentro 
de Fission Software de México S.A. de C.V.. La compañía principalmente me contrató con 
el fin de desarrollar un producto dedicado al monitoreo de señales de audio y video 
transmitidos por una televisora. Por lo tanto, trataré de explicar, por este medio, la manera 
en que diseñé y desarrollé un producto de software basado en hardware especializado, 
que se originó en un área de oportunidad dentro de las necesidades de trabajo de una 
estación de televisión. 
 
La implementación de un testigo de señal de retorno, es decir, contar con una 
forma de grabar sin interrupción las señales de audio y video transmitidas por las 
televisoras, para ser revisadas posteriormente por un usuario de manera visual y auditiva. 
 
Esta operación es importante para una televisora, por ejemplo, para obtener una 
forma de comprobar a sus clientes que suscomerciales se han transmitido como se 
estipuló en sus contratos. Asimismo, con esta herramienta pueden corroborar 
inmediatamente si existe algún fallo en la señal que se trasmitió al aire brindando una 
velocidad de respuesta mayor ante el error. Hoy en día, para solucionar este tipo de 
problemas, en diversas estaciones de televisión de México y Sudamérica, todavía utilizan 
DVR's o videocaseteras. 
 
La desventaja de utilizar esos dispositivos es que los tiempos de captura son muy 
limitados, brindando en promedio una semana de grabación. Además estos aparatos se 
activan manualmente por medio de un operador. Otra desventaja que presentan estos 
dispositivos es que requieren de un mantenimiento constante para que funcionen 
correctamente, ya que su uso continuo degenera el equipo con el paso del tiempo. 
 
Para resolver esta problemática, Fission Software buscó desarrollar un sistema 
capaz de grabar señales de audio y video en unidades de almacenamiento masivo y 
escalable, para tener el mayor tiempo de grabación posible. También escrutó que el 
sistema sea lo suficientemente autónomo para poder realizar un mantenimiento periódico 
de las unidades de almacenamiento utilizadas, obteniendo de esta forma el espacio libre 
suficiente para mantener la grabación activa en todo momento, mediante la eliminación de 
los archivos más viejos o que ya no sea necesaria su existencia. 
 
En respuesta a esta necesidad, el producto que implementé se denomina Fission 
On-Air Monitor. Un sistema de monitoreo de señales de televisión basado en el 
levantamiento de requerimientos, realizado en base a las necesidades del mercado. 
 
 
 
 
Capítulo 1 - Fission Software 
 
Fission Software es una corporación, fundada en el año 2000 incorporada al estado de 
Connecticut, E.U.A., dedicada principalmente al desarrollo de soluciones para 
automatización de áreas de Control Maestro (Master Control) de estaciones de televisión. 
 
En el año 2001, abrió una subsidiaria llamada Ground Zero Software de México, 
S.A. de C.V. (GZSM) con el propósito de penetrar en el mercado latinoamericano, 
teniendo un mejor alcance a clientes ubicados dentro Centro y Sudamérica, así como el 
área del Caribe. 
 
En el año 2002, GZSM ganó la licitación para requipar todas las estaciones locales 
de Televisa, así como sus principales estaciones repetidoras de señal en el interior de la 
República Mexicana. Posteriormente, estaciones como Televisa Monterrey, Televisa 
Guadalajara, por mencionar algunas, fueron actualizadas con hardware y software de 
última generación en los años 2003 y 2004. 
 
Al mismo tiempo, en el 2004, se crea Fission Software de México, subsidiaria 
donde comienza la labor de distribuir la solución en América Latina, mientras que el 
producto continúa consolidándose en el mercado doméstico con clientes como: Televisa 
Networks, Sky, Megacable, MVS, entre otras. Lugar donde he laborado desde el 2006 
hasta la fecha. 
 
Para el año 2005, Fission Asia Limited se constituye como mayorista para la región 
de Asia y el Pacífico, obteniendo de esta manera presencia en países como Corea, 
Taiwan, Australia, etc. 
 
Después en el 2006 se abre comercio en Europa mediante compañías 
distribuidoras como Mediateket con base en Noruega, donde el producto comienza a 
tener presencia en Suecia, Noruega y el Reino Unido 
 
La misión de la empresa es proveer soluciones integrales para la automatización 
de canales de T.V. con arquitectura abierta y tecnología de punta a un costo accesible. En 
otras palabras, Fission visto como un producto, es una solución basada en software 
diseñado sobre hardware de última generación. Software que es capaz de proveer una 
operación totalmente automatizada, por medio de un flujo de trabajo adaptable a diversos 
sistemas ya existentes dentro de una estación de transmisión de video por cable o 
televisión abierta. 
 10 
Capítulo 1 
Esquema General de una Estación de Televisión 
Para poder obtener una mejor comprensión de la solución integral que ofrece Fission 
Software, es necesario describir de manera general la forma en la que se manejan la 
mayoría de las estaciones de televisión. Dentro de una estación que maneja canales a 
gran escala existen cuatro departamentos relevantes: 
 
 Departamento de Producción de Contenido 
 Departamento de Ventas 
 Departamento de Programación y Continuidad 
 Control Maestro 
 
El departamento de Producción de Contenido es el encargado de generar el material a 
ser transmitido a la audiencia. Dependiendo del canal y su rubro, el material puede 
consistir de programas educativos, programas de entretenimiento, programas en vivo, etc. 
En esta misma área se encargan de elaborar la promoción interna de los programas que 
transmite la televisora. 
 
El departamento de Ventas es el encargado de vender los espacios comerciales que 
existen dentro y entre los programas a transmitir, ya sea por medio de cortes comerciales, 
menciones dentro de los programas, video superpuesto, entre otras formas de 
comercialización. Una vez que el área de Producción de Contenido y el de Ventas han 
determinado el contenido y comerciales a transmitir, el departamento de Programación y 
Continuidad arma la pauta a ser trasmitida, la cual posteriormente es transferida al área 
de Control Maestro. 
 
En Control Maestro se procesa la pauta que indica lo que se debe transmitir. Por ello, 
en esta área es donde se recaba todo el material audio-visual de diversas fuentes como: 
Producción de Contenido, estudios, clientes externos para obtener su comercialización, 
señales satelitales, etc., para finalmente poder reproducir el video y audio previamente 
planeados y así ser transmitido al teleauditorio. 
 
En el área de Control Maestro es donde reside principalmente la solución que ofrece 
Fission Software a sus clientes. 
 
 
 
11 Fission Software 
Módulos de Fission 
Fission siendo una solución modular, está formado principalmente por 4 módulos 
de software: Feed Capture Module, Capture Module, Management Module e Insertion 
Module. En este escrito para referirse a cada módulo, desarrollado por la compañía, se 
utilizará solamente su nombre, utilizando la palabra módulo de forma implícita, para 
facilitar la lectura. Dichos módulos se describen brevemente a continuación: 
 
Feed Capture Module: Permite al usuario programar y realizar capturas 
de material audiovisual en un horario, periodo y duración predefinida; también 
cuenta con las herramientas para segmentar dicho material en bloques que 
faciliten al usuario su manejo desde una fuente satelital. Por medio de este módulo se 
puede retrasar la transmisión de la señal de entrada por un lapso predefinido para obtener 
repeticiones desfasadas de las señales. También provee herramientas de edición a corte 
para material audiovisual tanto a nivel archivo como lógico. 
 
Capture Module: Facilita al usuario la ingesta de material audiovisual al 
sistema por medio de listas de captura que automatizan el vaciado de las cintas 
desde una videocasetera (VTR). Mediante las herramientas de edición a corte 
que ofrece, permite ligar el material audiovisual recién capturado con las entidades lógicas 
creadas desde otros módulos para ser transmitido posteriormente por el módulo Insertion. 
También provee herramientas para segmentar de manera lógica los programas, de 
acuerdo a los bloques comerciales asignados, para su reproducción al final de la cadena 
del sistema sin tener que modificar el archivo original de captura. 
 
Management Module: Permite al usuario la creación, modificación y 
eliminación de elementos lógicos, que son ligados a la media audiovisual y 
utilizados para realizar pautas de transmisión y reproducción dentro del sistema. 
También permite crear reportes establecidos por el usuario de dichas actividades y la 
comunicación con otros sistemas con el fin de intercambiar pautas y reportes de 
transmisión. Asimismo, permite administrar y dar mantenimiento a los recursos de 
almacenamientocon los que cuenta el sistema instalado, realizando tareas de prevención 
de errores y depuración. 
 
Insertion Module: Su función principal es ejecutar listas de reproducción 
de archivos de audio y/o video previamente establecidas en el sistema por medio 
del módulo Management o un sistema de tráfico externo, así como realizar 
edición y adición de material sobre éstas. También permite agregar efectos de 
superposición, edición y mezcla sobre los elementos de su lista. Además, provee la 
funcionalidad para insertar y ejecutar comandos pautados sobre dispositivos remotos a 
través de protocolos de comunicación como TCP/IP o por puertos del sistema como el 
serial o paralelo, de acuerdo a las necesidades del cliente. El módulo es capaz de 
reproducir el material de hasta cuatro canales simultáneamente en un mismo servidor. 
 
 12 
Capítulo 1 
Flujo de Trabajo con Fission 
Una estación de televisión que utiliza Fission como su sistema de automatización 
dentro del departamento de Control Maestro para la transmisión de su señal de audio y 
video, trabaja descrito en una forma muy general, de la siguiente manera: 
El flujo comienza en el módulo Management, dando de alta la lista de reproducción 
para cierto día. Ésta puede ser creada importando una pauta generada desde un sistema 
de tráfico externo o con la herramienta de creación de pautas incluida en el módulo. 
Después, se ligan los archivos audiovisuales a transmitir con sus contrapartes 
lógicas creadas, en la base de datos, desde el Management, ya sea por un proceso de 
creación manual o por la importación de la lista de reproducción. Los elementos a ligar 
pueden ser: programas, versiones (cortes comerciales y promocionales), y eventos 
secundarios (gráficos, video y audio de superposición). 
Los programas y versiones, por lo general, son capturados por medio del Feed 
Capture o Capture, aunque en ciertas estaciones la media ya ha sido digitalizada desde 
sus departamentos de producción, en este caso, basta con ubicar los archivos dentro del 
almacenamiento de Fission y ligarlos a sus respectivos elementos lógicos. 
El diseño del sistema posee una gran flexibilidad en la administración del 
almacenamiento, ya que permite almacenar el video digitalizado en los discos locales de 
los ordenadores donde se captura el mismo, en el almacenamiento de los ordenadores 
que reproducen dicho material al aire o en sistemas de gran capacidad y disponibilidad 
como lo son una NAS o una SAN para guardar la multimedia empleada en el sistema. 
Una vez que la lista de reproducción se encuentra lista y completa, ésta es 
reproducida en el Insertion que permite realizar en tiempo real modificaciones a la 
programación mediante la inserción de contenido y eventos secundarios de último 
momento. 
Finalmente, una vez transmitido el material, el Insertion crea reportes de 
transmisión dentro de la base de datos de Fission. Estos reportes se cotejan a través del 
Management contra las pautas o listas de reproducción originales de forma automatizada 
para ubicar las diferencias que existen entre lo esperado a transmitir contra lo que se 
transmitió realmente y mantener un control de calidad en la señales de televisión. 
 
1G
B
 Sw
itch
Management
Base de Datos
Fission
Producción de Contenido
Insertion
Capture y FeedCapture
 
Figura 1.1- Esquema general sistema Fission 
 
Capítulo 2 - Actividades dentro de Fission Software 
 
En un inicio cuando ingresé a la compañía en el año 2006, ésta había logrado una 
venta importante con la distribuidora de contenido VISAT, actualmente conocida como 
Televisa Networks. En ese momento mi trabajo consistía en instalar la red física, los 
servidores dentro de su sitio y el software correspondiente a cada servidor de acuerdo al 
producto que había comprado el cliente. En la mayoría de los casos se trata de una red 
con topología de estrella, ya que el almacenamiento se trata de una SAN (Storage-Area 
Network) la cual es un sistema de almacenamiento masivo centralizado y requiere que un 
servidor actúe como MDC (Meta-Data Controller) el cual administra el bloqueo de 
archivos, la asignación de espacio y la autorización de acceso a datos de la SAN. Por lo 
que el trabajo en campo consistía en cablear la red tanto de fibra óptica como de cobre en 
las instalaciones del cliente. Colocar los servidores en su estante, instalarles el sistema 
operativo y el software que les corresponde de acuerdo al diseño de la instalación 
solicitada por el cliente. 
 
En ese momento mi trabajo consistía de diversas tareas como: Instalar la red física, 
colocar los servidores en su sitio, instalarles el software correspondiente y configurarlo de 
acuerdo a la solución que había solicitado el cliente. En la mayoría de los casos la red a 
instalar cuenta con una topología de estrella, debido a que el almacenamiento se trata de 
una SAN (Storage-Area Network) la cual es un sistema de almacenamiento masivo 
centralizado y requiere que un servidor actúe como MDC (Meta-Data Controller) el cual 
está encargado de administrar el bloqueo de archivos, asignar el espacio de escritura y 
autorizar el acceso a datos de la SAN por clientes externos. Por lo tanto primero cableaba 
la red tanto de fibra óptica como de cobre en las instalaciones del cliente. Esta tarea 
consistía en extender los cables por el inmueble del cliente y crear las puntas de conexión 
de los cables, así como configurar los switches de red necesarios. Una vez establecida la 
red se instala el sistema operativo y el software a los ordenadores de acuerdo al diseño 
de la instalación solicitada por el cliente. 
 
Una vez que se cuenta con la red instalada y configurada apropiadamente, el 
trabajo consiste en observar y analizar la estabilidad del sistema dentro del sitio. Como 
parámetros de estabilidad consideraba si existía algún error en el software, registraba en 
que ambiente y situación se ocasionaban por medio de herramientas desarrolladas 
internamente en la compañía. También otro dato a observar era el tráfico de red por 
medio de herramientas como WireShark. Una vez que el equipo se encontraba totalmente 
instalado y listo para ser utilizado, mi trabajo consistía en capacitar al personal de la 
estación que iba a estar a cargo del manejar del software dentro del área de Control 
Maestro. Los cursos impartidos consistían en explicar la manera más adecuada en que 
debían configurar y utilizar el software. Una vez terminados los cursos, mi trabajo se 
basaba en permanecer dentro de la estación como personal de apoyo para aclarar 
cualquier duda sobre el manejo del software a los operadores. 
 
Este tipo de tareas son necesarias dentro de una instalación debido a que el 
producto se trata de un sistema de misión crítica que requiere de su correcto 
funcionamiento en todo momento para que la transmisión de la señal de televisión se 
realice. 
 14 
Capítulo 2 
Ya que me encontraba familiarizado con la forma de trabajo y las necesidades que 
se tienen dentro de una estación de televisión, la compañía me asignó trabajos de 
investigación para sondear las necesidades de los clientes dentro de las estaciones, así 
como averiguar si el cliente se encontraba satisfecho con el software e incrementar la 
calidad del servicio que ofrece la compañía. Se me asignó este tipo de trabajo debido a 
mis conocimientos dentro del área de desarrollo de aplicaciones y consideró que esos 
conocimientos me permitirían escribir reportes más comprensibles al equipo de desarrollo, 
ya que podría utilizar lenguaje técnico más específico con un enfoque a la programación 
del software y así poder cumplir con mayor rapidez las necesidades y exigencias del 
cliente. 
 
Más adelante, y hasta la fecha, se me solicitó programar en sitio controladores 
(drivers) de algunos dispositivos que requieren compatibilidad con Fission. Debido a que 
Fission es un sistema abierto, en casi todas las ocasiones, los clientes desean que el 
sistema sea compatible con equipo con el que ya cuentano compraron 
independientemente al producto que compraron por parte de Fission. En la mayoría de los 
casos, éste equipo de trata de routers o switches de señales de audio y video. Dado que 
la empresa cuenta con un sistema modularizado para controlar dispositivos externos, mi 
trabajo se remitía a implementar los protocolos propietarios de la compañía fabricante de 
cada dispositivo sobre el medio que éste requería, por ejemplo, ya sea sobre una 
conexión RS-232 ó TCP/IP. Por mencionar algunos ejemplos de los protocolos que he 
implementado hasta la fecha se encuentran el Intelligent Interface para el secuenciador 
Channel Box de Chyron, el protocolo Quartz para el ruteador de señal EQX de Evertz, la 
implementación de CSL de VizRT para controlar el secuenciador MultiChannel y el 
protocolo ESAMII para diversos secuenciadores y switches fabricados por Sony 
 
También en diversas ocasiones tenía como trabajo realizar búsquedas de software 
especializado que agilizara o ayudara al cliente para aceptar la adaptación del uso de 
Fission Software dentro la estación. Para ejemplificar un caso, en una ocasión se me 
solicitó un software que agilice el copiado de archivos entre diversos servidor con una 
SAN o NAS. Teniendo en cuenta que esta necesidad era general entre los clientes, 
Fission decidió implementar una solución que se integrara con el sistema, a la cual llamó 
Fission File Transfer. Proyecto en el cual también colaboré en el desarrollo para 
administrar el copiado de archivos dentro de una red de Windows y así limitar la carga de 
la tasa de bits en la transferencia evitando que exista una interferencia en el streaming de 
los archivos de audio y video para su transmisión al aire. 
 
En otro caso, un cliente dentro de una sala de bloqueos, donde la operación 
requiere el remplazar los cortes comerciales por comercialización local ya que la estación 
es una repetidora de señal. Requerían de un cronómetro que los usuarios pudieran lanzar 
y estar atentos a él en todo momento para saber cuanto tiempo les quedaba disponible, 
por lo tanto se les recomendó utilizar XNoteStopwatch ya que este permitía el ser iniciado 
y finalizado por medio de un pulso en el puerto serial RS-232, permitiendo automatizar 
toda la operación desde un servidor central en la sala de bloqueos. 
 
Cuando la compañía determinó que me encontraba los suficientemente 
familiarizado con el ambiente de la televisión, me encomendó la tarea de desarrollar el 
sistema de monitoreo de señales de audio y video para la corroboración de la calidad y un 
 
 
15 Fission Software 
testigo de la señal transmitida. Debido a que en los últimos años me dediqué en gran 
parte de mi tiempo a la elaboración de este software, consideré pertinente ubicar una 
descripción del desarrollo del mismo como el objetivo principal de este escrito el cuál 
explicaré a detalle en el capítulo 3. 
 
Durante el fin de una de las iteraciones del desarrollo del Fission Monitor se me 
invitó a colaborar con el desarrollo del sistema denominado Fission Archive. Éste es un 
sistema de archivo que tiene acceso a diferentes áreas dentro de la estación de televisión 
y provee las herramientas necesarias para crear catálogos con términos consistentes 
entre los usuarios. Los catálogos están compuestos por estructuras de metadatos, valores 
de los datos, reglas de validación y los archivos. De esta forma se le facilita a un usuario 
buscar la información y/o archivos que requieren. Principalmente está basado en un 
sistema de datos ubicados en una base de datos relacionados con archivos dentro de un 
sistema de almacenamiento masivo. En una ocasión un cliente, de acuerdo a sus 
necesidades, requería de un tipo de dato el cuál no estaba contenido en el sistema. El tipo 
de dato se trataba de un árbol de archivos dicha estructura consistía en carpetas las 
cuales a su vez podían contener carpetas y archivos de cualquier tipo. Mi labor fue 
implementar la creación de la estructura de la base de datos, la importación dentro del 
sistema de almacenamiento masivo y la extracción desde el mismo. 
 
Recientemente, al momento de realizar este escrito también se me ha invitado a 
colaborar con el desarrollo de controles personalizables de Windows para poder entregar 
una GUI de última generación que facilité la tarea de inserción de comerciales y la 
administración y captura de multimedia en el área de Control Maestro. Mi última tarea 
consiste en investigar y desarrollar nuevos controles que faciliten el acceso a la 
información contenida en el sistema. Para ello me encuentro actualmente investigando 
acerca de menús contextuales como lo son los circulares. 
 
En resumen, este es un listado de las tareas principales en las que he participado 
dentro de mi trabajo en la compañía Fission Software de México S.A. de C.V. desde mi 
ingreso hasta la fecha. 
 
 
 
Capítulo 3 - Fission On-Air Monitor 
 
Es importante notar que al final del flujo de trabajo que ofrece la compañía como 
solución, existe una necesidad a satisfacer dentro de las estaciones de televisión: la posibilidad 
de poder cotejar de manera auditiva y visual las diferencias que lleguen a existir en la 
transmisión con respecto a la lista de reproducción o contra la pauta inicial. 
La compañía contempló dicha oportunidad de mercado como un módulo a agregar, 
dentro del sistema del área de Control Maestro, desde el cuál se podría ofrecer videoclips que 
contengan lo ocurrido durante la transmisión al aire a los otros departamentos para su revisión 
y análisis. 
 
Afinando el concepto, el módulo que consideró a desarrollar tenía que ubicarse al final 
de la cadena como se muestra en la figura siguiente: 
 
Base de Datos
Fission
Insertion On-Air Monitor
 
Figura 3.1 - Integración Fission OAM 
 
Es importante resaltar que el módulo debe de estar ubicado en el flujo, posterior a la 
señal de retorno de la televisora. De esta forma el producto no depende del resto de los 
módulos de Fission, con lo que es posible instalarlo dentro de una televisora a pesar de que no 
cuente con Fission como sistema de automatización dentro del Control Maestro. 
 
Basándose en esa necesidad, la empresa me encomendó desarrollar un sistema que 
grabe continuamente de manera digital las señales de audio y video transmitidas por una 
estación de televisión. Las grabaciones deben realizarse sin interrupción. La calidad de la señal 
capturada debe ser menor a la transmitida por la estación de televisión para cumplir la función 
de testigo y poder almacenar grandes tiempos de grabación aprovechando la compresión de 
video empleada. 
 
 18 Capítulo 3 
El sistema debe de cumplir con los siguientes requerimientos: 
 Grabación ininterrumpida de la señal de retorno de la estación de televisión 
 Realizar un mantenimiento autónomo a las unidades de almacenamiento que utilice 
para los archivos de grabación 
 Ser capaz de recuperarse automáticamente en caso de error 
 Realizar búsquedas basadas en tiempo, fecha y canal dentro de sus registros de 
captura 
 Realizar exportaciones a un formato de video digital que sea visible en la mayoría de 
los ordenadores sin la necesidad de instalar decodificadores adicionales. 
A su vez, el sistema debe ser compatible con el sistema operativo Windows XP y 
posterior. El hardware especializado a utilizar para realizar la tarea de captura de las señales 
de audio y video es la tarjeta Optibase MM400 la cual se programa por medio de su paquete de 
desarrollo de software (SDK). 
 
 
 
19 Requerimientos 
3.1 Requerimientos del Producto 
 
Los requerimientos del sistema Fission On-Air Monitor se levantaron en base a las 
necesidades de un cliente con una importancia relevante para la compañía. El cliente requería 
un sistema autónomo autosustentable que cumpliera con la función de testigo de sus señales 
de audio y video transmitidas, para ser revisadas en caso de error o ser cotejadas en caso de 
duda con respecto al resultado del flujo de trabajo del áreade Control Maestro. 
El departamento de ventas de Fission Software, junto con su departamento de 
operaciones y desarrollo, realizó un primer acercamiento con el cliente basado en un bosquejo 
de funcionalidad básica de la interfaz del software basada en diálogos y una descripción de los 
eventos que ocurrirían al interactuar con ella. La propuesta, presentada al cliente incluía la 
decisión de desarrollar el sistema basado en el hardware que ofrece Optibase Inc., la tarjeta 
grabadora Optibase MM400, porque ésta cumple con: los estándares de calidad requeridos, un 
SDK sencillo de utilizar que ayuda a la pronta elaboración del sistema y un costo atractivo para 
el cliente. 
 
3.1.1 Primer Bosquejo de la Interfaz 
Fondo de pantalla 
Al iniciar el programa se debe mostrar el diálogo que se muestra en la Figura 3.2. El 
diálogo debe de abarcar en su totalidad la resolución de un monitor de 1280x1024 pixeles. El 
nombre asignado a este diálogo es fondo de pantalla de la aplicación. 
 
RECORD
VIEWER
RECORD
SESSION
EXITSETTINGS
LOGO
FISSION
421 3
 
Figura 3.2 - Fondo de pantalla 
 
El diálogo incluye cuatro botones que cumplen con las siguientes tareas: 
1. Abrir una sesión de captura de una de las entradas del hardware de captura 
2. Abrir una sesión de visualización del registro de captura 
 20 Capítulo 3 
3. Abrir una ventana de configuración del sistema 
4. Cerrar la aplicación. 
 
Descripción de los eventos 
Esta ventana ocupa toda la pantalla para evitar que el usuario pueda realizar otra 
tarea en el servidor mientras esté utilizando el software. Desde esta interfaz se puede iniciar 
una sesión de captura si se presiona el botón “Record Session” (Sesión de Captura), 
posteriormente determina la entrada sobre la cual desea realizar la captura, mediante un 
diálogo intermedio de selección de entrada como el que se muestra en la Figura 3.3. 
 
Como máximo se pueden abrir seis sesiones simultáneas de captura debido a que 
en un servidor se pueden instalar máximo tres tarjetas grabadoras que cuentan con dos 
entradas cada una. 
 
SELECT CHANNEL
OK CANCEL
Channel 1
 
Figura 3.3 - Diálogo selección de canal 
 
Desde el diálogo principal también es posible iniciar una sesión de visualización del 
registro de captura presionando el botón “Record Viewer” (Visualizador de grabación). De la 
misma manera que la sesión de captura, la visualización comienza con la selección del canal 
por medio de un diálogo que muestra el listado de los canales definidos en el sistema. 
 
A cada entrada del sistema le es asignado un nombre de canal el cuál será 
utilizado como identificador único para una sesión de grabación, por lo tanto es importante 
considerar la restricción de no repetir el nombre del canal a través de las diferentes 
entradas dentro del mismo servidor. 
 
El número máximo de visualizadores está delimitado por el hardware que albergue al 
sistema. Debido a que los visualizadores están implementados en su totalidad por medio de 
software, es necesario que se realicen pruebas posteriores al desarrollo para cuantificar la 
cantidad de recursos que ocupa cada instancia del visualizador y así poder determinar la 
cantidad límite de visualizadores simultáneos. 
 
 Finalmente, dando clic sobre el botón “Settings” (Ajustes) debe abrirse un diálogo que 
permita configurar la captura de cada entrada, la manera en la que se despliega el video en la 
entrada física, definir cuáles son las unidades de almacenamiento a utilizar, así como la 
manera en que se les dará mantenimiento. 
 
Todos los diálogos descritos deben de aparecer dentro del fondo de pantalla y en 
ningún momento deberán cubrir el área de botones ubicados en la parte inferior. 
 
 
21 Requerimientos 
Sesión de captura 
RECORD SESSION
CLOSE
RECORDFULL SCREEN STOP
3
1 2
64
5
 
Figura 3.4 - Diálogo de sesión de captura 
 
Los controles del diálogo de sesión de captura deben de cumplir con los eventos 
descritos a continuación: 
 
1. Iniciar la captura de las señales de audiovisuales 
2. Detener la sesión de captura 
3. Mostrar del video de la señal de entrada en un recuadro 
4. Mostrar el de la entrada en toda la pantalla 
5. Reproducir el audio de la captura al seleccionar la sesión 
6. Cerrar la sesión. 
 
Descripción de los eventos 
Al presionar el botón “Start” (Comenzar) debe comenzar a grabar en archivo las señales 
audiovisuales de la entrada correspondiente a la sesión de captura seleccionada. 
Al presionar el botón “Stop” (Detener) se detendrá la sesión de captura en curso. 
En el recuadro ubicado en la parte superior se debe mostrar el video con el que está 
siendo alimentada la entrada correspondiente a una resolución de 320 x 240 pixeles en caso 
de tratarse de una relación 4:3 o en una resolución de 320x180 en el caso de que se desee 
desplegar el video escalado en una relación 16:9 en caso de que la fuente sea anamórfica. 
Cuando este diálogo sea seleccionado por medio de un clic del ratón el audio de 
entrada correspondiente debe ser el único en salir por el dispositivo de salida de audio por 
defecto del sistema. 
En este mismo diálogo se debe de mostrar de manera automática el porcentaje de 
espacio libre en la unidad de almacenamiento donde se capturan los archivos multimedia. La 
cifra debe mostrarse en porcentaje y actualizada cada 10 segundos. 
 22 Capítulo 3 
Finalmente, al presionar el botón “Close” (Cerrar) se cierra la sesión de captura. Si la 
captura se encuentra activa, debe de aparecer un diálogo de aviso al usuario indicando que la 
sesión no puede ser finalizada al menos de que sea detenida la captura. 
Sesión de visualización 
En un diálogo donde se visualiza el material capturado se deben considerar los 
siguientes eventos con relación a los controles indicados en la Figura 3.5. 
 
1. Buscar dentro del registro de archivos el audio y video correspondientes a la fecha y 
hora seleccionados 
2. Reproducir en un recuadro el video correspondiente a la búsqueda realizada y el 
audio a través del dispositivo de salida seleccionado por defecto en el sistema operativo 
3. Llevar a cabo las acciones básicas de un control de reproducción como se muestran 
a través de todo el sistema (Reproducir (Play), pausar (Pause), retroceder un cuadro (Step Back), 
avanzar un cuadro(Step Forward), rebobinar (Rewind), reproducir rápidamente(Fast Forward)). 
4. Exportar el videoclip basado en los tiempos de inicio y fin dentro de los tiempos 
existentes del registro. 
 
RECORD VIEWER
Fecha Búsqueda Hora Búsqueda SEEK
IN
OUT
Fecha Entrada Hora Entrada
Fecha Búsqueda Hora Búsqueda
EXPORT
CERRAR
1
2
3
4
 
Figura 3.5 - Diálogo de visualizador de video 
Descripción de los eventos 
Al presionar el botón “SEEK” (Búsqueda) se realiza una búsqueda dentro del registro 
basado en la fecha y hora ingresados en los controles correspondientes. 
 
La búsqueda puede tener un margen de error de hasta 3 segundos al mostrar el 
resultado, este valor puede ser configurado por el usuario. Cuando la búsqueda tenga éxito, se 
debe mostrar al usuario el video pausado en el cuadro correspondiente a la fecha y tiempo 
solicitados, junto con el nombre del archivo que contiene el video. 
 
 
23 Requerimientos 
Cuando el video se esté reproduciendo, se debe desplegar en todo momento la fecha y 
hora correspondientes al video mostrado en el recuadro de la visualización. 
 
Otro punto a considerar es que al momento de dar doble clic sobre el recuadro donde se 
muestra el video, éste se debe mostrar en toda la pantalla, abarcando toda el área del monitor 
sin perder la proporción de las dimensiones del video. En caso de que el video no recubra en 
su totalidad el área del monitor debido a su relación, se pintará en negro el área desocupada 
por el video. 
 
Los controles de reproducción deben cumplir con su función al dar un solo clic sobre 
ellos. Los botones de [Fast Forward] y [Rewind] tendrán una funcionalidad extra. Ya que al ser 
presionados más de una vez, se iráincrementando la velocidad de la reproducción hacia 
adelante o hacia atrás dependiendo del caso. Las velocidades a soportar son 2X, 4X, 8X, 
32X y 64X, donde X es el número de veces contra la velocidad normal (1X) de reproducción. 
Configuración del sistema 
El diálogo de configuración del sistema debe estar basado en pestañas, donde cada 
pestaña corresponde a cada una de las entradas presentes en el servidor. 
 
Los controles del diálogo mostrado en cada pestaña serán asignados para cada uno de 
los ajustes a configurar en como se muestra en la figura: 
 
 
Input Settings
Channel Name:
Capture Path:
Storage Path:
BRT
CON
SAT
HUE
Enable Audio
Left Gain:
Right Gain:
Sample Rate:
Encoding Format:
VBR
Segment Duration:
1
2
3
4
5
6
Video Resolution: 7
8 9
DB I.P.
DB User
DB Pass
DB Name
10
 
Figura 3.6 - Diálogo de configuración de entrada 
 
 24 Capítulo 3 
1. Nombre del canal asignado a la entrada 
2. Directorio en el cual se realiza la captura (Debe ser un directorio local) 
3. Directorio del almacenamiento donde se guarda la captura (Puede ser un directorio 
local o remoto) 
4. Duración del segmento 
5. Valores de color (HUE), saturación (SAT), brillo (BRT) y contraste (CON) 
6. Tasa de bits (bitrate) de grabación 
7. Resolución de la grabación del video 
8. Muestreo y formato de compresión del audio 
9. Ganancia de audio por canal de audio 
10. Conexión con la base de datos del sistema Fission. 
 
Descripción de los eventos 
Los cambios realizados dentro de los diálogos toman efecto al momento de dar clic 
sobre el botón “Ok”. Una vez que se hayan actualizado las configuraciones de cada entrada el 
diálogo se cierra. Algunos de los cambios pueden tomar efecto durante la manipulación de los 
controles como son todos los valores contenidos en el punto 5, para su visualización 
instantánea. 
En caso de presionar el botón “Cancel” (Cancelar) se cierra el diálogo sin guardar los 
cambios realizados durante la sesión de configuración. 
De acuerdo al manejo de configuraciones del resto de los módulos de Fission, los 
ajustes de la configuración son guardados en el registro de Windows. 
 
 
25 Diseño 
3.2 Diseño del Producto 
 
De acuerdo a los requerimientos levantados por los ingenieros de campo, consideré 
que la mejor metodología para realizar el diseño era la llamada Arriba-Abajo (Top-Down), 
en donde ataqué el problema desde la interfaz gráfica hacia el núcleo del sistema. Por 
esa razón, una vez establecida formalmente la interfaz gráfica con el cliente a través de 
los requerimientos y mediante su abstracción, pude definir las tareas a ejecutar en la 
siguiente lista: 
 
1. Capturar las señales de audio y video en un archivo de cada entrada física 
2. Configurar el sistema 
3. Mostrar al usuario las señales de entrada de la tarjeta 
4. Buscar dentro de los registros de captura 
5. Visualizar el contenido ubicado en los registros de captura 
6. Exportar segmentos del registro de captura 
7. Administrar los archivos ubicados dentro del registro de captura y el espacio libre 
de las unidades de almacenamiento. 
 
Si se analiza con detalle las tareas mencionadas, se puede apreciar que la captura de 
señales A/V debe ser persistente en todo momento, es decir, no puede ser detenida para 
ejecutar cualquiera de las otras tareas, por lo que consideré que el paralelismo dentro del 
sistema es inevitable. 
Otro punto importante que surgió mientras realizaba el análisis previo de las 
herramientas que debía utilizar, es la diferencia de codificaciones en las que se 
encuentran compilados el SDK de Optibase y las aplicaciones desarrolladas en Fission, 
donde el SDK de la tarjeta de captura está compilado en Multi-byte y en Fission se 
compilan en Unicode. 
Los términos, Multi-byte y Unicode, se refieren a la forma en que se codifican las 
cadenas de caractéres al momento de compilar un programa o una biblioteca. La 
codificación Unicode es utilizada para el soporte de más idiomas internacionales con 
caracteres especiales como: el Chino, el Japonés o la escritura Cirílica, mientras que la 
codificación Multi-Byte sólo se limita a la mayoría de las lenguas romances en términos 
generales. 
El hecho de que la herramienta de desarrollo de Optibase y las aplicaciones dentro de 
Fission estén compiladas en diferentes codificaciones impide que dentro de un proyecto, 
se incluyan ambas bibliotecas, lo que me orilló a separar en diferentes programas la capa 
de interfaz gráfica de la capa de manejo de la tarjeta. 
Consecuentemente, la arquitectura Cliente-Servidor me resultó atractiva para la 
implementación del sistema solicitado. 
 
3.2.1 Arquitectura Cliente-Servidor 
La arquitectura Cliente-Servidor abreviada como C/S, es un modelo de diseño para 
sistemas que reparten el procesamiento entre un programa que realiza peticiones, 
denominado Cliente, a otro programa que le da respuesta, llamado Servidor. 
Las ventajas principales de la arquitectura C/S son de tipo organizativo. Una 
ventaja que obtuve al utilizar este esquema de diseño, es que pude separar las 
responsabilidades de cada proceso, clarificando el diseño del sistema. La separación 
 26 Capítulo 3 
entre cliente y servidor es de tipo lógico, es decir, el servidor no se ejecuta 
exclusivamente en una máquina diferente a la que alberga el cliente y tampoco se refiere 
a que el servidor esté forzosamente compuesto por un solo programa. Al contrario, por lo 
general dentro de este modelo, el servidor se descompone en diversos programas que 
pueden ser ejecutados de acuerdo a las necesidades del usuario, aumentando así el 
grado de distribución del sistema y convirtiendo de esta forma la manutención en una 
tarea más sencilla ya que en caso de error podría remplazar únicamente un módulo sin la 
necesidad de detener por completo la parte que actúa como servidor. 
El cliente es el programa que expide una solicitud dentro de la arquitectura C/S, es 
decir, tiene el papel activo dentro de la comunicación y se encarga de solicitar la ejecución 
de los servicios ofrecidos por el servidor. 
 
Monitor Client
Cliente Servidor 
Figura 3.7 - Cliente-Servidor 
 
Una de las ventajas que promete este diseño es la modularidad. Si se cuenta con 
un sistema lo suficientemente modularizado se pueden realizar modificaciones 
sustanciosas, ya sea del lado del cliente o el servidor, sin la necesidad de tener que 
modificar forzosamente la otra parte, en el caso de contar con un protocolo de 
comunicación diseñado convenientemente. A su vez, si se cuenta con un protocolo lo 
suficientemente robusto, facilita que el sistema se comunique con sistemas externos en 
caso de ser necesario. 
 
3.2.2 Descripción General del Sistema 
Considerando la arquitectura elegida y la abstracción de las tareas a implementar, 
resulta claro que la grabación de los archivos es la más importante de todo el desarrollo y 
fue necesario ubicarla en un módulo que funcione como servidor y esté totalmente 
separado del resto de las tareas. Este módulo también es capaz de configurar el sistema 
ya que este se encuentra en contacto directo con el hardware por medio del SDK de 
Optibase. 
Una vez establecido el servidor me resultó lógico que las tareas de búsqueda y 
visualización del registro, estuvieran agrupadas dentro del módulo cliente el cual también 
muestra la interfaz de usuario del sistema. 
La exportación de segmentos de video, o videoclips, del registro de captura, a 
pesar de que lo ubiqué dentro del diseño en el mismo lado del cliente, decidí desarrollarlo 
en un módulo distinto al de la interfaz. Esta decisión fue tomada con la finalidad de poder 
entregar un servicio de exportación, que sea capaz de ser actualizado con mejoras en 
caso de que, en un futuro, algún cliente lo solicite. 
La tarea relacionada al mantenimiento de archivos y almacenamiento masivo debe de 
ejecutarse como un sub-módulo del servidor, porque solamente de esta manera se puede 
estar completamente seguro de que el módulo de mantenimientotiene acceso a las 
unidades de almacenamiento asignados a la captura debido a que ahí se encuentra el 
hardware de captura. Ya que en el supuesto de que lo hubiera colocado en el lado del 
 
 
27 Diseño 
cliente, no tendría el acceso a las unidades de disco si el módulo cliente se ubicara en un 
ordenador remoto. 
Una de las razones importantes que me impulsó a ubicar el proceso de mantenimiento 
en un programa o módulo distinto al que ofrece el servicio de captura fue, que cualquier 
problema crítico, como un error fatal dentro del proceso de mantenimiento, podría llegar a 
interrumpir el proceso de captura, No obstante, ambos módulos comparten su 
configuración ubicada en el registro del sistema operativo. 
 
Considerando el modelo arquitectónico elegido y la asignación de tareas, los nombres 
de los módulos se asignaron de la siguiente forma: 
 Fission Monitor Server (Captura y configuración del sistema por llamadas remotas) 
 Fission Monitor Client (Búsqueda, visualización y exportación) 
 Fission Monitor Upkeeper (Mantenimiento de las unidades de disco) 
 Fission Monitor Exporter (Exportación de videoclips) 
 
Monitor Server
Señal de Entrada
Monitor Upkeeper
Monitor Client
Monitor Exporter
Almacenamiento
Masivo
(NAS/SAN) 
Figura 3.8 - Diagrama modular de Fission On-Air Monitor 
 
Extendiendo la descripción de la funcionalidad de cada módulo, aclaro que el 
módulo Fission Monitor Server es el núcleo del sistema. Su propósito principal es el de 
capturar los archivos multimedia en un dispositivo de almacenamiento local (generalmente 
un disco duro) basado en reglas previamente establecidas por el usuario final. 
Posteriormente, este módulo ejecuta periódicamente el módulo Fission Monitor 
Upkeeper, que está a cargo de la transferencia de archivos multimedia a una unidad de 
almacenamiento a largo plazo y a borrar los archivos dependiendo de su antigüedad en la 
unidad de almacenamiento y el espacio libre en la misma. 
 
El módulo Fission On-Air Client es la interfaz gráfica del sistema que se presenta 
al usuario final. Desde sus controles se puede iniciar y detener una sesión de captura de 
las señales de audio y video. También permite una visualización previa de lo que se está 
capturando en tiempo real. Además, ofrece los controles que permiten configurar la 
captura de cada entrada independientemente de las otras. Igualmente, puede establecer 
las reglas de mantenimiento de las unidades de disco asignadas a la captura y al 
almacenamiento a largo plazo. En este módulo, el usuario puede buscar los archivos 
multimedia relacionados a una fecha, hora y canal en específico y exportar segmentos del 
registro de captura en el formato ASF. Para llegar a esta conclusión, me basé en una 
 28 Capítulo 3 
investigación previa que me indicó que dicho formato puede ser reproducido en cualquier 
servidor que opere bajo Windows en cualquiera de sus versiones XP o posterior. Además, 
este formato permite codificar el video en una calidad lo suficientemente baja con lo cual 
disminuye su tamaño en bytes agilizando su transferencia por cualquier medio electrónico, 
dígase correo electrónico o transferencia FTP. 
 
En la siguiente figura ilustro la interrelación de los módulos que implementé, donde 
solamente interactúan los hexágonos adyacentes: 
 
 
Figura 3.9 - Interacción de los módulos 
 
3.2.3 Modelo Iterativo Incremental 
El departamento de desarrollo de productos, dentro de Fission Software, 
implementó un esquema de trabajo definido empíricamente basado en el progreso y 
necesidades de la empresa durante su crecimiento. La forma en la que los fundadores de 
la compañía se las han ingeniado para cumplir con las soluciones requeridas, por la 
estaciones de televisión, tiene base en el Modelo Iterativo Incremental debido a la 
cantidad de personal y compromisos por entregar a tiempo con diversos clientes. 
Es erróneo pensar en que “iterativo” e “incremental” son sinónimos dentro del 
desarrollo de software. Este error es común debido a que en la práctica ambos conceptos 
van de la mano. Cuando hablamos de un Modelo Iterativo nos referimos a que el 
desarrollo va en ciclos, mejorando la calidad del producto, sin embargo, a éste no se le 
añade funcionalidad. En el caso del Modelo Incremental en cada entrega al cliente, se van 
añadiendo fragmentos de funcionalidad al producto a partir de la primera entrega que se 
denomina la versión esencial o versión base del producto. 
En términos generales el Modelo Iterativo Incremental consiste en desarrollar un 
sistema a través de ciclos repetitivos (iterativo) y con porciones de funcionalidad en cada 
entrega (incremental). De esta forma los desarrolladores de software aprenden las 
necesidades específicas de los usuarios finales y los usuarios pueden tener una idea más 
clara y concreta de sus necesidades, a través del uso del sistema. 
Es decir, en cada iteración existen cambios al diseño, mayor funcionalidad añadida 
al producto y correcciones a posibles errores que pudieran existir en la entrega anterior, 
de tal forma que las versiones van evolucionando hasta que el sistema quede totalmente 
implementado. 
Fission 
Monitor 
Client 
Fission 
Monitor 
Exporter 
Fission 
Monitor 
Server 
Fission 
Monitor 
Upkeeper 
 
 
29 Diseño 
 
Figura 3.10 - Ciclo iterativo del modelo Iterativo Incremental 
 
Este procedimiento consiste básicamente de una fase inicial, una fase iterativa y 
una lista de control de proyecto. En la fase inicial se lleva a cabo un análisis de todo el 
problema, posteriormente un diseño general de todo el sistema, junto con una 
calendarización del desarrollo del producto y terminando en la entrega de una versión 
base del mismo. 
Durante la entrega de la versión base, el usuario está a tiempo de reaccionar y 
verificar que sus requerimientos fueron comprendidos totalmente. En caso de que 
ocurriera lo contrario durante esta etapa, no existen grandes repercusiones ya que se 
puede volver a la etapa de diseño. El rediseño de la aplicación se realiza con la finalidad 
de entregar una nueva versión base que cumpla las expectativas del usuario y a partir de 
la cual se irán entregando versiones mejoradas. Una vez que el usuario comienza a 
utilizar la versión base, el proyecto avanza a la fase iterativa. En ese momento entra en 
juego la lista de control de proyecto. En ella se lleva un registro de todas las tareas que 
deben ser realizadas para guiar la fase iterativa, de lo contrario esta forma de trabajo se 
puede volver muy confusa tanto para los desarrolladores como para el cliente, ya que sin 
una guía el sistema puede llegar a un punto sin fin donde los tiempos de entrega se 
vuelven ambiguos y ninguna de las partes comprende la problemática para la que está 
siendo desarrollado el sistema. 
Por tanto, la Lista de Control de Proyecto debe de incluir las nuevas 
funcionalidades a ser desarrolladas, así como los puntos de rediseño que tuvieron que ser 
tomados para satisfacer las necesidades del cliente. Es importante que sea revisada 
constantemente durante la etapa de análisis en cada iteración. 
 
La fase iterativa incluye el rediseño e implementaciones de nuevas capacidades 
del sistema que fueron añadidas a la Lista de Control de Proyecto como resultado del 
análisis de la versión actual. En una ejecución ideal del modelo, el rediseño e 
implementación en cada iteración debe ser sencillo, directo y modular. El análisis de una 
iteración está basado en la retroalimentación por parte del cliente y el análisis del sistema 
en sitio. Dicho análisis debe estar basado en el uso, eficiencia, estructura, modularidad y 
sobre todo en el alcance de las metas previamente establecidas de la iteración anterior. 
 
 
Planeación y 
Requerimientos 
Análisis, Diseño e 
Implementación 
Pruebas 
Evaluación 
 30 Capítulo 3 
Debilidades del modelo 
Uno de los puntos débiles de este modelo de desarrollo es que el cliente debe 
estar involucrado en todo momento durante el desarrollo delproyecto. El rápido 
crecimiento que ha tenido la compañía Fission Software, en gran parte, se debe a que la 
mayoría de las estaciones de televisión trabajan todos los días del año cubriendo las 24 
horas del día y están dispuestas a ir de la mano con la compañía para poder concretar 
una solución de automatización que les permita mejorar los procesos de producción de 
sus señales de televisión. Desafortunadamente, el costo de ejecución de dicho modelo 
implica para Fission Software mayores gastos de manutención, así como transporte y 
viáticos en horarios extremos para su personal. 
Otro punto débil que se aprecia dentro de este modelo, es que la compañía que 
ofrece la solución requiere de profesionales con habilidades arriba del promedio y que se 
encuentren comprometidos a cumplir con las necesidades del cliente. Para poder cumplir 
con esta labor, Fission Software cuenta con personal capacitado dentro de las áreas de 
desarrollo y operaciones, que cuentan con una comunicación directa para resolver, con la 
mayor velocidad posible, problemas en el software cuando estos suceden en sitio. Para 
llevar una guía adecuada de los avances y metas a alcanzar se establecen planos de ruta 
para cada módulo del sistema que brinda las soluciones esperadas a los clientes. 
Iteraciones del proyecto 
Basado en el Modelo Iterativo Incremental la primera tarea a realizar es un análisis 
de los alcances que debe de tener el proyecto y plasmar las fases del desarrollo en una 
Lista de Control de Proyectos. Esta herramienta, por muy simple que parezca, permite a 
todas las áreas dentro de la empresa el intercomunicarse para generar una idea más 
concreta sobre que punto se encuentra el desarrollo, tener un mejor control sobre los 
tiempos de entrega y fungir como guía para los programadores ayudándoles a obtener 
metas más claras sobre el alcance. A continuación, se muestra una lista ejemplo realizada 
durante la etapa inicial del proyecto en discusión: 
Tabla 3.1 - Lista de control de proyecto 
Fission On-Air Monitor 
Lista de Control de Proyectos 
Fase I-1 
Versión a 
Entregar 1.0.0.0 
Descripci
ón 
Entregar al cliente una versión base que cumpla con la funcionalidad mínima de 
grabar y visualizar la señal que se está grabando 
 
Tareas General: 
1. Implementar Sockets 
2. Diseñar y crear skins de programa cliente 
Módulo Servidor: 
1. Implementar wrapper SDK de Optibase 
2. Implementar protocolo de comunicación 
3. Implementar servidor que interprete correctamente protocolo con cliente 
Módulo Cliente: 
1. Implementar gráfica visualizadora de stream SDP por medio de DirectShow 
2. Implementar Recrod Session 
3. Implementar Settings 
4. Implementar comunicación con el servidor. 
Personal Salvador Medina 
Fecha de 
Entrega 26/08/2006 
 
 
31 Diseño 
Fase I 
Como se puede observar en la tabla, la versión base del producto tiene que ser 
capaz de grabar bajo una configuración establecida por el usuario para aprovechar el 
espacio en disco duro local. Las capturas de las señales de entrada deben de realizarse 
independientemente de acuerdo a las necesidades de cada canal. En esta fase el 
software debe de permitir al usuario visualizar la multimedia contenida dentro de los 
registros de captura. Una vez que se obtiene la versión base que incluye la funcionalidad 
mínima del sistema al concretar la fase I, el proyecto entra en la fase II. 
 
Fase II 
Durante la segunda fase del proyecto, el sistema debe ser capaz de exportar 
segmentos del registro, o videoclips, definidos por el usuario mediante la selección de 
fecha y hora tanto del inicio como del final del clip. Los videoclips deben de ser mostrados 
en un visualizador proporcionado por el programa cliente en la mayoría de los equipos sin 
la necesidad de instalar codecs extra al ordenador. 
 
Fase III 
En una tercera etapa del desarrollo, el sistema debe ser capaz de guardar la 
multimedia capturada en una unidad de almacenamiento masiva, como una NAS 
(Network-Attached Storage) o una SAN (Storage Area Network) y esta funcionalidad debe 
ser opcional para mantener la flexibilidad del sistema. Así mismo, debe de liberar espacio 
en disco mediante la eliminación de archivos en las unidades de almacenamiento 
designadas para la captura y para el almacenamiento a largo plazo. 
 
Los parámetros que tomé en cuenta para realizar esta tarea son el espacio libre en 
la unidad de almacenamiento y la vida útil de los archivos. En caso de que el usuario 
defina un espacio libre mínimo requerido, se deberán borrar los archivos más viejos que 
estén ubicados en la unidad de disco. Si varios canales comparten la misma unidad de 
disco, se borrará el archivo más viejo de todos los canales. En caso de realizar un 
mantenimiento de disco por medio de expiración de archivo, simplemente se tiene que 
verificar en cada uno de los archivos contenidos que su tiempo de vida no sea mayor a la 
establecida por el usuario, el tiempo de vida del archivo está basado en la fecha y hora 
actual contra la fecha y hora de inicio de grabación del archivo. 
 
 32 Capítulo 3 
 
El proceso de mantenimiento puede interpretado por el siguiente pseudocódigo: 
 
1. Obtener listado de cada uno de los directorios de captura y almacenamiento 
2. Ordenar cada uno de los listados obtenidos 
3. Agrupar las listas de acuerdo al disco en que están ubicados 
4. Por cada grupo obtenido 
4.1. Ordenar cronológicamente y mezclar las listas dentro del grupo 
5. Por cada lista obtenida de cada grupo 
5.1. Mientras no exista el espacio libre mínimo en el disco establecido por el usuario 
5.1.1. Borrar el primer archivo de la lista 
5.1.2. Eliminar el primer elemento de la lista 
5.2. Si no existen más archivos en la lista y no hay espacio libre disponible 
5.2.1. Notificar error en el espacio libre correspondiente al disco del grupo 
5.3. Mientras el primer archivo de la lista tenga una vida mayor a la permitida por el 
usuario 
5.3.1. Borrar el primer archivo de la lista 
5.3.2. Eliminar el primer elemento de la lista 
6. FIN 
 
Finalmente, como un comentario extra del diseño actual, un cliente distinto al que 
originó el proyecto solicitó que el sistema permita la visualización y exportación de 
segmentos en un ambiente multiusuario, en otras palabras, requería de un módulo nuevo 
que tenga acceso al registro de captura para buscar y exportar segmentos desde un 
módulo independiente. Gracias a la modularización descrita al inicio del capítulo, este 
programa lo pude implementar mediante la extracción del funcionamiento de la Sesión de 
Captura y reutilizando el módulo de exportación dentro de una nueva aplicación llamada 
Fission Monitor Viewer. 
 
 
33 Herramientas 
3.3 Herramientas Utilizadas para su Programación 
 
En la compañía los programas compatibles con el sistema operativo Windows son 
desarrollados con la herramienta Visual Studio 2005 mediante el lenguaje VC++ utilizando 
las bibliotecas MFC (Microsoft Foundation Classes) que proporciona Microsoft. 
Para desarrollar el sistema también utilicé DirectShow, herramienta proporcionada 
por Microsoft para la manipulación del audio y video. 
Por último, fue imperativo que empleara el SDK que proporciona Optibase con su 
hardware para poder administrar el uso de la tarjeta encargada de capturar las señales de 
audio y video de acuerdo a los requisitos de la aplicación. 
 
3.3.1 MFC 
La biblioteca MFC encapsula algunas funcionalidades de la API de Windows en 
clases para el lenguaje de programación Visual C++, que facilitan el manejo de objetos, 
ventanas y controles de Windows. 
Con esta herramienta se pueden desarrollar programas de una manera más rápida, 
ya que al momento de crear aplicaciones el código generado es mucho más fácil de 
escribir y de leer por todos los macros que éste incluye, teniendo como resultado 
proyectos de fácil mantenimiento. 
VC++ posee un amplio uso de macros. Una macro es una definición o un texto 
breve que puede llegar a remplazar líneas enteras de código creandoconsecuentemente 
un lenguaje breve y conciso. Las macros que MFC provee se utilizan para el manejo de 
los mensajes o excepciones que arroja el sistema o aplicación. También son utilizadas 
para la seriación o creación de instancias de clases dinámicas. Microsoft creo las macros 
con la intención de reducir el uso de memoria evitando la creación de tablas virtuales 
como está estipulado dentro del estándar de C++. También lo creo con la intención de no 
tener que realizar un parseo una y otra vez. 
En el caso particular de este trabajo utilicé la versión 8.0 de esta herramienta que 
está incluida en el programa de desarrollo Visual Studio 2005 SP1. 
 
3.3.2 DirectShow 
DirectShow es una API que proporciona Microsoft para la manipulación de 
archivos multimedia en diferentes versiones del sistema operativo Windows. Ésta fue 
añadida al SDK estándar de desarrollo de aplicaciones de Windows en el año 2007. 
La arquitectura utilizada por DirectShow es del tipo modular, donde cada etapa del 
procesamiento es ejecutada por un objeto denominado filtro. DirectShow provee un 
conjunto de filtros estándar que pueden ser utilizados directamente por los programas, 
aunque esto no limita a los programadores a desarrollar sus propios filtros para aumentar 
la funcionalidad de DirectShow. 
 
Para ilustrar el funcionamiento de DirectShow se muestra en la siguiente figura 
una gráfica sencilla encargada de reproducir un archivo de video con audio embebido: 
 
En la figura que se muestra a continuación se observan componentes en forma 
rectangular, estos representan a los filtros. Cada filtro cuenta con entradas y salidas 
denominadas pines. Un pin de entrada solamente puede ser conectado a un pin de salida 
de otro filtro, generando así un flujo de datos dentro de la gráfica. 
 34 
Capítulo 3 
 
 
Figura 3.11 - Gráfica de ejemplo de reproducción de video 
 
La arquitectura basada en filtros permite al programador reproducir, capturar o 
editar archivos multimedia de algunos formatos comunes como MPEG-1, MP3, WMA, 
WMV, MIDI en contenedores como ASF, AVI y WAV ya que los filtros requeridos están 
incluidos dentro del SDK. 
Sin embargo, para el software en discusión era necesario poder manipular 
archivos codificados en MPEG-4, AAC contenidos en formato MP4, por lo que requería de 
filtros desarrollados por terceros, lo cual implicaba un costo adicional por licenciamiento 
por el uso de la patente y/o tecnología utilizada en el códec. 
Esta herramienta me fue útil ya que me permitió desarrollar un reproductor y un 
editor de video de una manera muy sencilla. 
 
Uso de FilterGraph 
Al momento de programar una aplicación haciendo uso de DirectShow es 
importante tomar en cuenta el objeto Filter Graph Manager, que traducido al español se 
entiende como el Administrador de Gráficas basadas en Filtros, pero en futuras ocasiones 
haré referencia a este componente por su nombre en inglés. 
 
Una de las funciones principales de este componente es establecer un reloj de 
referencia interno para coordinar los cambios de estado dentro de los filtros utilizados en 
la gráfica. Contando con una referencia interna es posible informar a la aplicación sobre 
los eventos ocurridos dentro la gráfica a la aplicación. También provee los métodos e 
interfaces necesarias para construir y manipular las gráficas. Toda aplicación que 
programe utilizando el Filter Graph Manager debo de seguir los siguientes pasos: 
 
 
Aplicación
Filter Graph Manager
Aplicación
Filter Graph Manager
Aplicación
Filter Graph Manager
EventosLlamadas
 
Figura 3.12 - Uso del Filter Graph Manager 
 
 
Raw Audio 0 
Wildfire.wmv 
Raw Video 1 
In0 out0 
 
WMAudio Decoder DMO 
 
In0 out0 
 
WMVideo Decoder DMO 
 
Audio Input pin (rendered) 
 
Default DirectSound Device 
VMR Input 0 
 
Video Renderer 
 
 
35 Herramientas 
1. Crear una instancia del Filter Graph Manager 
2. Crear una gráfica por medio del Filter Graph Manager. Los filtros a utilizar los 
determina la aplicación de acuerdo a sus necesidades. 
3. La aplicación utiliza al Filter Graph Manager como la interfaz para controlar la 
gráfica y flujo de datos que corre a través de los filtros. Durante este proceso la 
aplicación recibe eventos que indican el estado de la gráfica. 
 
Durante el uso del Fiter Graph Manager fue importante que considerara la 
tecnología de Conexión Inteligente (Intelligent Connect). La Conexión Inteligente se refiere 
a los algoritmos que utiliza, internamente este componente, para construir todo o parte de 
la gráfica basándose en la compatibilidad de los filtros instalados en el sistema con los ya 
incluidos en la gráfica, combinando los filtros para intentar resolver la construcción de la 
gráfica. 
 
Codec HELL y sistema de méritos en códecs 
A pesar de que puede ser muy práctico permitir al administrador de gráficas elegir 
los filtros necesarios para completar una gráfica, esto puede llegar a ser un gran 
inconveniente para el usuario. 
Cualquier fabricante de códecs dentro de la industria puede desarrollar sus propios 
filtros compatibles con DirectShow para poder codificar y decodificar diferentes tipos de 
multimedia. 
Los filtros al momento de ser instalados son registrados con ciertos puntos de 
mérito en el registro del sistema operativo. Los puntos de mérito determinan la capacidad 
que tiene el filtro para poder trabajar sobre cierto tipo de multimedia en específico. En una 
instalación limpia dentro de un ordenador, este ambiente es el ideal para que los 
programas trabajen apropiadamente con códecs desarrollados por otras compañías. 
No obstante, en la realidad, esta forma de trabajo trae consigo más errores que 
beneficios, ya que cualquier usuario puede instalar la cantidad de códecs que desee o 
considere necesario para su ambiente de trabajo y, tomando en cuenta, que todos los 
fabricantes al momento de crear el instalador de sus códecs tratarán de asignar el mayor 
número de puntos de mérito a sus filtros, ocasiona que se asignen los puntos de manera 
irregular dentro del ordenador, provocando que la gráfica creada por medio de la 
“Conexión Inteligente” del Filter Graph Manager tome filtros de diferentes fabricantes 
generando una gráfica disfuncional con filtros incompatibles, trastornando la finalidad de 
la Conexión Inteligente. 
 
Para ejemplificar esta situación, se considera que un usuario instala 2 paquetes de 
códecs para decodificar y reproducir los archivos del tipo MPEG-4 versión 2. 
Considerando al primer fabricante como la compañía LEAD y al segundo siendo 3IVX. 
Los códecs de LEAD poseen 5 puntos de mérito para sus demultiplexores y 
decodificadores. En cuanto a los otros codecs, el paquete de instalación de 3IVX asigna 5 
puntos de mérito a sus demultiplexores así como a sus decodificadores de video, sin 
embargo, asigna 3 puntos de mérito a sus decodificadores de audio. 
Basándose en dicho supuesto, al momento de crear una gráfica para reproducir un 
archivo de video con audio embebido codificado en MPEG-4 versión 2 con audio 
codificado en AAC en formato MP4, la Conexión Inteligente del Filter Graph Manager 
daría como resultado una gráfica con filtros de diferentes fabricantes. 
Este resultado en ocasiones podría ser algo positivo, si el decodificador de audio 
de LEAD funciona mejor que el de 3IVX. Sin embargo, en la práctica que he adquirido en 
las diversas instalaciones del producto, en la mayoría de las ocasiones esto resulta en 
 36 
Capítulo 3 
una gráfica disfuncional, donde el audio no esté sincronizado con el video o los 
decodificadores no sean del todo compatibles, construyendo una gráfica que reproduce 
sólo el video sin salida de audio. 
 
Es por ello que se debe de tener mucho cuidado al momento de programar una 
gráfica mediante la Conexión Inteligente del Filter Graph Manager. Para validar si el 
ordenador cuenta con un ambiente apropiado para la reproducción de ciertos archivos 
multimedia, el uso de la herramienta GraphEdit me permitió visualizar