MX2014012515A - Arquitectura y sistema para distribucion de video en grupo. - Google Patents

Abstract

Un método para gestionar la distribución de vídeo incluye recibir una pluralidad de trenes de datos de vídeo a partir de una pluralidad de dispositivos de fuente de datos de vídeo asociados con un grupo. Cada tren de datos de vídeo incluye una pluralidad de tramas de vídeo y una pluralidad de campos de metadatos. Los trenes de datos de vídeo se analizan sintácticamente para extraer las tramas de vídeo e información que comprende la pluralidad de campos de metadatos. Se genera un tren de metadatos de grupo común que incluye información de metadatos a partir de la pluralidad de campos de metadatos. El tren de metadatos de grupo común se comunica a unos dispositivos de equipo de usuario (UED) accionados por unos usuarios que pueden tener interés en trenes de vídeo. Tras la recepción de una demanda de un primer tren de vídeo de usuario sobre la base de la información contenida en el tren de metadatos de grupo común, un primer tren de vídeo de usuario se genera y se comunica a un UED.

Description

ARQUITECTURA Y SISTEMA PARA DISTRIBUCIÓN DE VIDEO EN GRUPO ANTECEDENTES DE LA INVENCIÓN Declaración del campo de la técnica Las disposiciones de la invención se refieren a sistemas de comunicación de seguridad pública y, de manera más particular, a la distribución de video en los entornos de comunicación basados en grupos.

Descripción de la técnica relacionada En los sistemas por voz de seguridad pública, es común que los usuarios se dividan en grupos de hablantes. Dentro de cada grupo un único hablante "tiene el turno de palabra", y otros miembros del grupo oyen al hablante más o menos de manera simultánea. Estos sistemas funcionan bien para las comunicaciones por voz, pero no se ha realizado un progreso similar en relación con la determinación de unos sistemas y métodos óptimos para distribuir contenido de video.

Se sabe que los seres humanos procesan la información de habla de formas que son drásticamente diferentes en comparación con las formas en las cuales estos procesan la información visual. Coloquialmente, se podría observar que las personas están habituadas a escuchar a un orador cada vez. En reuniones de comité formales, un presidente o mediador arbitra entre peticiones que compiten por el turno de palabra, e impone una comunicación secuencial. Cada miembro del comité oye la misma cosa. A diferencia de las percepciones humanas del habla, la percepción visual es de alta velocidad y episódica. De hecho, el "punto de fijación" del ojo se mueve un promedio de tres veces por segundo, un periodo durante el cual por lo general solo se producen dos fonemas en el habla humana. Por ejemplo, la capacidad de desplazar con rapidez el enfoque visual ha conducido a unos sistemas de vigilancia en los que una única persona supervisa múltiples imágenes de forma continua.

Mientras que el habla se percibe del mejor modo de forma secuencial, un estimulo visual (es decir, video) puede comprenderse de manera simultánea. Asi mismo, existen diferencias fundamentales en las formas en las que los miembros del mismo grupo experimentan un estimulo visual frente a uno auditivo, y en la forma en la que los individuos procesan estímulos simultáneos. Por lo tanto, a pesar de que los paradigmas de comunicación por voz de grupo con arbitraje con un control del turno de palabra secuencial son dominantes en las comunicaciones críticas (en especial, los sistemas por voz de seguridad pública) , los métodos óptimos para la distribución de información de vídeo en grupo son menos evidentes. Además, a pesar de que en la técnica se conocen muchos sistemas y métodos de realización de videoconferencias , ninguno de estos sistemas convencionales satisface las necesidades y requisitos de los usuarios en un contexto de comunicación de grupo.

SUMARIO DE LA INVENCIÓN Las realizaciones de la invención se refieren a métodos para gestionar la distribución de medios de vídeo en un entorno de grupo. Los métodos incluyen recibir en un servidor de grupo una pluralidad de trenes de datos de video, cada uno generado de manera respectiva en una pluralidad de dispositivos de fuente de datos de vídeo asociados con un grupo. Cada tren de datos de vídeo incluye una pluralidad de tramas de vídeo y una pluralidad de campos de metadatos. Un procesador de ordenador en el servidor de grupo analiza sintácticamente los trenes de datos de vídeo para extraer las tramas de vídeo y una información que comprende la pluralidad de campos de metadatos. El servidor de grupo genera un tren de metadatos de grupo común que incluye, de manera selectiva, información de metadatos a partir de cada uno de la pluralidad de campos de metadatos. El tren de metadatos de grupo común se comunica a unos dispositivos de equipo de usuario (UED) accionados por unos usuarios que pueden tener interés en trenes de vídeo que se proporcionan a partir de los dispositivos de fuente de datos de vídeo. El soporte lógico en el UED supervisa los metadatos de grupo, y sobre la base de criterios específicos de la misión, determina si el usuario humano debería supervisar el tren de vídeo. Si el soporte lógico determina que el usuario debería supervisar el tren de vídeo, el servidor de grupo recibirá a partir de por lo menos uno de los UED, una demanda de un primer tren de vídeo de usuario. La demanda del primer tren de usuario se basa en la información contenida en el tren de metadatos de grupo común. En respuesta a la demanda, el servidor de grupo genera el primer tren de vídeo de usuario que comprende la pluralidad de tramas de vídeo incluidas en uno de los trenes de datos de vídeo. A continuación, el primer tren de vídeo de usuario se comunica al UED a partir del cual se recibió la demanda. El método también puede incluir recibir a partir de por lo menos uno de los UED, una demanda condicional para un primer tren de vídeo de usuario y comunicar el primer tren de vídeo de usuario al UED sobre la base de tal demanda condicional. La demanda condicional puede especificar una determinada acción de procesamiento que va a realizarse por el procesador de ordenador antes de la comunicación del tren de vídeo de usuario a dicho UED. Los métodos anteriores también pueden implementarse como un sistema de ordenador para gestionar la distribución de medios de vídeo en un entorno de grupo.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Se describirán realizaciones con referencia a las siguientes figuras de dibujo, en las que números similares representan artículos similares en la totalidad de las figuras, y en las que: La figura 1 es un diagrama conceptual que es útil para comprender cómo pueden distribuirse trenes de video en un entorno de grupo.

La figura 2 es un diagrama de flujo que es útil para comprender las operaciones de una función de grupo que se ejecuta en un servidor de video de grupo.

La figura 3 es un diagrama conceptual que es útil para comprender cómo pueden distribuirse trenes de video a partir de múltiples grupos a los usuarios en un escenario de patrulla de policía.

La figura 4 es un diagrama de flujo que es útil para comprender las operaciones del equipo de usuario en un sistema de distribución de vídeo en grupo.

La figura 5 es un diagrama de arquitectura de ordenador que es útil para comprender una implementación de un sistema de distribución de vídeo en grupo.

La figura 6 es un diagrama de bloques que es útil para comprender la arquitectura de un dispositivo de equipo de usuario a modo de ejemplo.

La figura 7 es un diagrama de bloques que es útil para comprender la arquitectura de un servidor de grupo a modo de ej emplo .

DESCRIPCIÓN DETALLADA La invención se describe con referencia a las figuras adjuntas. Las figuras no están dibujadas a escala y las mismas . se proporcionan meramente para ilustrar la presente invención. Varios aspectos de la invención se describen en lo sucesivo con referencia a aplicaciones a modo de ejemplo para ilustración. Deberla comprenderse que se exponen numerosos detalles específicos, relaciones y métodos para proporcionar una plena comprensión de la invención. Un experto en la materia relevante, no obstante, reconocerán inmediatamente que la invención puede ponerse en práctica sin uno o más de los detalles específicos o con otros métodos. En otros casos, no se muestran con detalle unas estructuras o funcionamiento bien conocidos para evitar complicar la invención. La invención no está limitada por la ordenación ilustrada de actos o sucesos, debido a que algunos actos pueden tener lugar en diferentes órdenes y / o concurrentemente con otros actos o sucesos. Además, no todos los actos o sucesos ilustrados se requieren para implementar una metodología de acuerdo con la invención.

La presente invención se refiere a un sistema y método para la distribución de vídeo en escenarios en los que los usuarios se dividen en grupos para los fines de comunicar y llevar a cabo una misión particular. Es común que los usuarios se dividan en grupos con el fin de facilitar determinados tipos de sistemas de comunicación por voz. Por ejemplo, en un entorno de sistema de radio con concentración de enlaces, una pluralidad de usuarios que comprenden un determinado grupo pueden asignarse a un "grupo de hablantes" que usa dos o más frecuencias para facilitar las comunicaciones entre el grupo. En tales sistemas, la expresión grupo de hablantes a menudo se usa para hacer referencia a un canal de radio virtual que los miembros de un grupo usarán para comunicarse uno con otro. Los grupos de hablantes se conocen bien en la técnica y por lo tanto no se describirán con detalle en el presente caso.

Los miembros de un grupo, tal como un grupo de hablantes, tendrán en general una estructura de mando y de control común, si bien a menudo cada uno está enfocado en actividades diferentes o incidentes específicos diferentes en cualquier instante particular. Por consiguiente, la distribución de vídeo en un entorno de este tipo está dispuesta de manera ventajosa de tal modo que los trenes de vídeo se comunican de manera selectiva cuando y donde estos serán de interés para los usuarios. Haciendo referencia a continuación a la figura 1, se ilustra un modelo para la distribución de vídeo en grupo que facilita de manera ventajosa cada uno de estos objetivos. El modelo comporta una pluralidad de dispositivos de equipo de usuario (UED) ??ß?, IO62. Solo dos UED se muestran en la figura 1 para los fines de descripción de la invención; pero debería comprenderse que la invención no está limitada a este respecto. Cada uno de los UED puede configurarse para incluir una pantalla de visualización en la que los usuarios pueden ver los trenes de vídeo que se han comunicado a cada dispositivo. En algunas realizaciones, los UED también pueden configurarse para facilitar las comunicaciones por voz, incluyendo las comunicaciones por voz dentro de un grupo de hablantes tal como podrían facilitarse por un entorno de comunicaciones de radio con concentración de enlaces.

Una pluralidad de trenes de vídeo si, s2 y s3 se generan de manera respectiva por una pluralidad de fuentes de vídeo 104i, 10 2, 1043. Cada uno de los trenes de vídeo está compuesto por unas tramas de vídeo 108 y una pluralidad de campos o elementos que contienen unos metadatos 110. En el ejemplo que se muestra, los metadatos incluyen una información de fuente (Src) que especifica un nombre o identificación para la fuente de las tramas de vídeo 108, un tiempo en el que se capturaron las tramas de vídeo 108, y una información de ubicación (Loe) que especifica una ubicación de la fuente cuando se capturaron las tramas de vídeo. Los metadatos que se muestran en la figura 1 son de naturaleza meramente ejemplar y no se pretende que limiten los tipos de metadatos que pueden incluirse con los trenes de vídeo si, s2 y S3. En su lugar, pueden incluirse muchos tipos diferentes de metadatos en los trenes de datos de vídeo, y las ventajas de tales tipos diferentes de metadatos se harán evidentes a medida que avance el análisis. Tal como se usa en el presente documento, los metadatos pueden incluir cualquier tipo de elemento o campo (que no sean tramas de video) que contenga información acerca de la trama de video, o las condiciones bajo las cuales se crearon. Los metadatos también pueden incluir datos en relación con actividades, acciones, o condiciones que tienen lugar de forma simultánea a la captura de tramas de video asociadas, con independencia de si tal información directamente se refiere a las tramas de video.

Cada uno de los trenes de datos de video se comunica de las fuentes 104i, 1042, 1043 a una función de grupo Gl. La función de grupo puede implementarse en soporte físico, soporte lógico, o una combinación de soporte físico y soporte lógico. Por ejemplo, la función de grupo puede ser una aplicación de soporte lógico que se ejecuta en un servidor de grupo tal como se describe en las figuras 5 y 6. Haciendo referencia a continuación a la figura 2, se proporciona un diagrama de flujo en el que el funcionamiento de la función de grupo Gl se describe con más detalle. El proceso comienza en 202 y continúa en 204, en la que la función de grupo recibe uno o más de los trenes de datos de vídeo si, s2, s3 a partir de las fuentes de datos de vídeo. A continuación de lo anterior, la función de grupo analiza sintácticamente cada uno de los trenes de datos de vídeo recibidos para extraer los metadatos asociados con cada tren individual.

En la etapa 208, la función de grupo identifica por lo menos un grupo al que se ha atribuido o asignado una fuente de datos de video 104i, 1042, 1043. En una realización preferida, los grupos están previamente definidos de tal modo que la función de grupo tiene acceso a una tabla o base de datos que identifica qué fuentes de datos de video están asociadas con un grupo particular. Por ejemplo, las fuentes de datos de video 104i, 1042, 1043 pueden identificarse como pertenecientes a un grupo común. Como alternativa, las diversas fuentes de datos de video pueden atribuirse a más de un grupo. Asi mismo, es posible que una fuente individual se atribuya o se asigne a más de un grupo. Por ejemplo, la fuente 104i podría estar asociada con un primer grupo, la fuente 1042 podría estar asociada con un segundo grupo, y la fuente 1043 podría estar asociada con ambos grupos. Si existe un grupo al que se han atribuido una o más de las fuentes de datos de vídeo, la función de grupo genera en la etapa 210 un tren de metadatos de grupo para ese grupo. Como alternativa, la pertenencia de una fuente en un grupo particular puede gestionarse de manera dinámica por la fuente, o por otra entidad. Por ejemplo, si una fuente está asociada con un agente de policía particular, la fuente podría cambiar los grupos síncronos con el agente de policía cambiando los grupos de hablantes (es decir, la pertenencia al grupo sigue la estructura de mando y de control) .

Si se está recibiendo activamente más de un tren de datos de vídeo por la función de grupo, entonces opcionalmente la etapa 210 puede incluir de manera selectiva conmutar una pluralidad de campos de trenes individuales de los metadatos 110 a partir de los trenes apropiados (si, s2, s3) en un tren de metadatos de grupo común para un grupo particular. En el ejemplo que se muestra en la figura 1, se supone que las fuentes de datos de video 104i, 10 2, 1043 están asociadas con un grupo común. Por consiguiente, los metadatos de tren individuales para los trenes si, s2, y s3 pueden conmutarse en un tren de metadatos de grupo común (metadatos de gl) .

Tal como se usa en el presente documento, la expresión "conmutado" en general se refiere a la idea de que los metadatos asociados con cada tren de datos individual se combinan en un tren de datos común. Para el presente fin puede usarse un único tren de datos, tal como se muestra, a pesar de que la invención no está limitada a este respecto y también son posibles múltiples trenes de datos. Si los metadatos de tren individuales se combinan en un tren de datos común, estos pueden combinarse o conmutarse de acuerdo con un cierto patrón previamente definido. Este concepto se ilustra en la figura 1, que muestra un tren de metadatos de grupo (metadatos de gl) que incluye, como alternativa, grupos de metadatos en relación con si, s2, y s3. Aún asi, debería comprenderse que la invención no está limitada a este respecto y también son posibles otros esquemas de conmutación en los que los metadatos a partir de cada tren de datos de video se combinan o se conmutan de formas diferentes dentro de un tren de metadatos de grupo común. Asi mismo, tales metadatos de grupo común pueden comunicarse a través de uno o más canales físicos o lógicos. En última instancia, todo lo que se requiere es que los metadatos analizados sintácticamente a partir de las fuentes de datos de vídeo seleccionadas se recopilen y a continuación se comuniquen a una pluralidad de UED tal como se describe en lo sucesivo en el presente documento. En la figura 1, un tren de metadatos de grupo (metadatos de gl) 105 a modo de ejemplo incluye la totalidad de los diversos tipos de metadatos a partir de cada uno de los trenes de datos de vídeo individuales, pero debería comprenderse que la invención no está limitada a este respecto. En su lugar, el tren de metadatos de grupo puede incluir, en algunas realizaciones, solo tipos seleccionados de los metadatos 110. Además, si las limitaciones de ancho de banda son una preocupación, uno o más de los campos de los metadatos 110 pueden omitirse de manera periódica de los metadatos de grupo común para reducir el volumen de datos global. Como alternativa, pueden incluirse determinados tipos de metadatos en los metadatos de grupo solo cuando se detecta un cambio en tales metadatos por la función de grupo Gl.

El tren de metadatos de grupo (metadatos de gl) 105 puede estar compuesto en exclusiva por la pluralidad de campos de los metadatos 110, debido a que tales campos están incluidos dentro de los trenes de datos de video si, s2 o s3. No obstante, la invención no está limitada a este respecto. En algunas realizaciones, la función de grupo Gl puede realizar un procesamiento adicional sobre la base del contenido de los metadatos 110 para generar unos metadatos secundarios que también pueden incluirse dentro del tren de metadatos de grupo. Por ejemplo, la función de grupo Gl podría procesar unos metadatos de ubicación (Loe) para calcular una velocidad de un vehículo en el que se encuentra una fuente 104i, 1042, 1043. A continuación, la información de velocidad del vehículo podría incluirse dentro del tren de metadatos de grupo como unos metadatos secundarios asociados con uno particular de los trenes de datos de vídeo individuales si, s2, y s3. De forma similar, los metadatos de grupo común en general no incluirán las tramas de vídeo 108, pero opcionalmente pueden incluir unos datos de imágenes en miniatura 112 en los que puede pensarse como un tipo de metadatos secundarios. Los datos de imágenes en miniatura 112 pueden comprender una única imagen (fija) de una escena contenida en el tren de vídeo y se proporciona en lugar del vídeo de transmisión por secuencias. Una ventaja de un enfoque de este tipo es que tales los datos de imágenes en miniatura 112 requerirían significativamente menos ancho de banda en comparación con un vídeo de transmisión por secuencias completo.

Los datos de imágenes en miniatura también pueden ser especialmente útiles en situaciones en las que un usuario de UED tiene interés en algún aspecto de un tren de video, pero encuentra ventajoso el uso de unas funciones de procesamiento automatizado para proporcionar asistencia en la supervisión de tal tren de video. En un escenario de este tipo, las funciones de procesamiento automatizado se realizan preferiblemente en un servidor en el que está implementada la función de grupo Gl. Es ventajoso realizar tal procesamiento automatizado del tren de video en Gl (en lugar de en el UED) debido a que los recursos de procesamiento fijos en general tienen más potencia de procesamiento en comparación con un UED. Además, puede ser preferible no cargar el enlace de comunicación entre Gl y el UED con un tren de video para los fines de facilitar tal procesamiento automatizado en el UED. En un escenario de este tipo, un usuario puede seleccionar o marcar, de manera ventajosa, porciones de la imagen en miniatura, y a continuación dar lugar a que el UED indique o envié un mensaje a la función de grupo Gl que indica que determinado procesamiento va a realizarse en Gl para esa porción del tren de video.

Un ejemplo de una situación que requeriría tal procesamiento por la función de grupo sería una en la que un usuario de un UED está interesado en observar un tren de vídeo solo si tiene lugar un determinado suceso (por ejemplo, se detecta movimiento o una persona pasa a través de una puerta) . El usuario podría usar un dispositivo apuntador (por ejemplo, un panel táctil) del UED para seleccionar o marcar una porción de la imagen en miniatura. El usuario podría marcar la totalidad de la imagen o seleccionar alguna parte menor de la imagen (por ejemplo, el usuario marca el área de puerta de la miniatura) . A continuación, el usuario podría dar lugar a que el UED enviara un mensaje a Gl de que el tren de vídeo que se corresponde con la miniatura va a comunicarse al UED solo cuando hay movimiento en el área seleccionada. Por ejemplo, el mensaje podría identificar la imagen en miniatura particular, la porción seleccionada o marcada por el usuario, y el procesamiento y / o acción solicitado que va a realizarse cuando se detecta movimiento. A continuación, la función de grupo Gl realizaría el procesamiento del tren de vídeo que se recibe a partir de la fuente para determinar cuando se detecta movimiento en la porción seleccionada de la imagen de vídeo. La detección de movimiento (por ejemplo, una persona que entra o que sale a través de una puerta) por la función de grupo podría usarse a continuación para desencadenar alguna acción (por ejemplo, comunicar el tren de vídeo correspondiente al usuario) . Por supuesto, la invención no está limitada a este respecto y también podrían desencadenarse otras acciones como resultado de tal procesamiento de imágenes de vídeo. Por ejemplo, la imagen también podría potenciarse de algún modo por Gl, o Gl podría dar lugar a que el tren de vídeo se reprodujera en orden cronológico inverso para proporcionar una función de rebobinado .

Las características anteriores se han descrito en un contexto que comporta utilizar una imagen en miniatura, pero los expertos en la materia apreciarán que una imagen en miniatura no se requiere necesariamente para todas las realizaciones tal como se describe en el presente documento. Por ejemplo, una imagen en miniatura no se requiere si un tren de vídeo va a reproducirse del revés, o la totalidad de la escena representada por un tren de vídeo va a procesarse por la función de grupo sin tener en cuenta selección de usuario alguna de una porción seleccionada de la misma.

En la etapa 212, el tren de metadatos de grupo para por lo menos un grupo se comunica a una pluralidad de UED que están asociados con ese grupo. Por ejemplo, la figura 1 muestra que el tren de metadatos de grupo (metadatos de gl) se comunica a los UED 106i, 1062. El tren de metadatos de grupo puede comunicarse de forma continua o periódica, dependiendo de la implementación específica seleccionada.

En la etapa 214 se realiza una determinación con respecto a por lo menos un UED al que debería comunicarse un tren de vídeo. Esta determinación puede hacerse en la función de grupo, en el UED o ambos. En algunas realizaciones, la función de grupo Gl evaluará uno o más campos o elementos de los metadatos 110 para identificar un UED al que deberla proporcionarse un tren de video si, s2, s3. Como alternativa, o además de lo anterior, los UED supervisarán el tren de metadatos de grupo para identificar cuando un tren de datos de video particular si, s2 o s3 puede ser de interés para un usuario particular. Cuando existen una o más condiciones para indicar que un tren de datos de video particular puede ser de interés para un usuario de un UED particular, puede comunicarse desde el UED a la función de grupo Gl un mensaje que indica que está seleccionado un tren de datos de video particular. El tren de video es uno que se selecciona de manera especifica por o para un usuario de un UED particular. Por consiguiente, a veces se hace referencia a este tren de video en el presente documento como un tren de video de usuario. En la etapa 214, la función de grupo recibe el mensaje que comprende una selección de usuario de una fuente de datos de video o un tren de datos de video de usuario. En uno u otro escenario, la función de grupo responde en la etapa 216 mediante la generación de un tren de video de usuario apropiado y la comunicación del mismo al UED. Por ejemplo, el tren de video de usuario que se comunica puede estar compuesto por unas vTramas (vFrames) 108 que se han analizado sintácticamente a partir de un tren de datos de video seleccionado. En la etapa 218, la función de grupo realiza una comprobación para determinar si se ha indicado al proceso que termine. De ser asi (218: Si), entonces el proceso finaliza en la etapa 220. Como alternativa, si el proceso no se ha terminado (218: No) entonces el proceso vuelve a la etapa 204.

Con el fin de apreciar más completamente las ventajas de los métodos anteriores, una realización a modo de ejemplo se describe con referencia a la figura 3. En este ejemplo, se supone que un grupo de patrullas de policía tiene un supervisor, un distribuidor, y un número de unidades de patrulla 304i, 3042, 3043. Los coches patrulla de policía convencionales pueden incluir una cámara de vídeo enfocada hacia delante que registra en un dispositivo de almacenamiento de medios montado en circuito de enlace. La cámara de vídeo enfocada hacia delante genera un tren de vídeo que puede transmitirse a través de una red de banda ancha. Para los fines de este ejemplo, se supondrá que estas cámaras de vídeo enfocadas hacia delante son fuentes de vídeo para el grupo de patrulla, y que estas fuentes de vídeo generan los trenes de vídeo s31, s32 y s33. Estos trenes de vídeo pueden comunicarse a una función de grupo Gp. Además, se supone un grupo de "cámaras de tráfico" que está enviando de manera continua vídeo a partir de las cámaras de tráfico a una función de grupo (Gt) . Las funciones de grupo Gp y Gt generan trenes de metadatos de grupo de una forma similar a lo que se ha descrito en lo que antecede con respecto a la función de grupo Gl.

Normalmente, no se transmite video alguno a partir de las unidades de patrulla 304i, 3042, 3043 a menos que tengan lugar determinadas condiciones previamente determinadas (por ejemplo, un control de tráfico, o una persecución de alta velocidad) . Cuando no se está transmitiendo video alguno a partir de las unidades de patrulla, el tren de metadatos de grupo (metadatos de gp) está esencialmente en reposo. Supóngase que un control de tráfico se inicia de tal modo que una unidad de patrulla (por ejemplo, la unidad de patrulla 304i) comienza a transmitir un tren de video (s31) a la función de grupo Gp. En respuesta, la función de grupo Gp comienza a enviar un tren de metadatos de grupo (metadatos de gp) a cada uno de los UED asociados con el grupo. El tren de metadatos de grupo incluye metadatos a partir del tren de video s31 (y cualesquiera otros trenes de video que se encuentren activos). En este ejemplo, los UED que están asociados con el grupo incluyen la consola 310 de un distribuidor, el ordenador 312 de un supervisor de patrulla, y un UED de unidad de patrulla 314. Los metadatos se analizan en la función de grupo Gp y / o en los UED 310, 312, 314. En el UED, el análisis puede comprender una evaluación por el usuario de determinada información que se comunica en los metadatos. Como alternativa, la evaluación puede ser un algoritmo programado o conjunto de reglas que procesa de manera automática los metadatos de grupo para determinar su relevancia para un usuario particular. Sobre la base de tal análisis una demanda o solicitud puede realizarse para un tren de video particular.

De acuerdo con una realización preferida, el tren de metadatos de grupo contiene uno o más tipos de metadatos que son útiles para determinar si un tren de video particular será de interés para diversos miembros del grupo. Los tipos particulares de elemento de metadatos incluidos para el presente fin dependerán de la aplicación especifica. Por consiguiente, la invención no está limitada a este respecto. Por ejemplo, en el ejemplo de la patrulla de policía en la figura 3, los metadatos pueden incluir uno o más de una identificación de vehículo, un tiempo asociado con la adquisición de tramas de vídeo asociadas, ubicación del vehículo, velocidad del vehículo, el estado de las luces de emergencia / la sirena en el vehículo (es decir, si las luces de emergencia / la sirena están apagadas / encendidas) , la presencia / ausencia de un agente de patrulla en un vehículo, el estatus de PTT de un micrófono que se usa para una comunicación por voz, el estatus de despliegue de airbag, y así sucesivamente.

Si los metadatos se analizan en el UED, entonces estos pueden procesarse y la información representada por tales metadatos puede visualizarse en una pantalla del UED. En algunas realizaciones, el usuario puede evaluar esta información para determinar su interés en un tren de video asociado con tales metadatos. En otras realizaciones, el UED puede programarse para visualizar de manera automática un tren de video cuando uno o más de los elementos de metadatos satisfacen determinadas condiciones. Las condiciones seleccionadas para desencadenar la visualización de un tren de video pueden ser diferentes para diferentes usuarios. Por consiguiente, los UED que están asignados a diversos usuarios pueden programarse para visualizar un tren de video bajo condiciones diferentes. Pueden proporcionarse diversas reglas o algoritmos para desencadenar la visualización de un tren de datos de video. En algunas realizaciones, pueden proporcionarse unos perfiles de usuario selecciónateles en cada UED para permitir que cada usuario especifique su papel en un grupo. En tales realizaciones, el perfil de usuario puede definir un conjunto de reglas o condiciones bajo las cuales va a visualizarse un tren de video al usuario, sobre la base de los metadatos recibidos.

Haciendo referencia una vez más a la figura 3, supóngase que los metadatos para un tren de video particular s31 indican que el tren de video será de interés para el distribuidor del grupo. Tales condiciones podrían tener lugar, por ejemplo, cuando los metadatos indican que un vehículo patrulla particular está implicado en un control de tráfico. Sobre la base de tales metadatos, la función de grupo Gp puede determinar que el tren de video s31 deberla comunicarse al distribuidor UED 310. Por consiguiente, la función de grupo Gp generará un tren de video de usuario que se corresponde con las tramas de video que se reciben a partir del vehículo de patrulla 304i. El tren de vídeo de usuario se comunica de manera automática a la consola 310 del distribuidor debido a que se sabe que un distribuidor tiene interés en observar las condiciones en el control de tráfico. Cuando el tren de vídeo de usuario se recibe en la consola 310 del distribuidor, puede alertarse al distribuidor de su disponibilidad, o el tren de vídeo puede visualizarse de manera automática para el distribuidor. Concurrentemente con estas acciones, la función de grupo comunicará un tren de metadatos de grupo (metadatos de gp) a cada uno de los UED (310, 312, 314) en el grupo. El tren de metadatos de grupo incluirá metadatos de tren individuales a partir del tren s31 Cuando tales metadatos de tren de grupo se reciben en el UED 312 del supervisor, puede usarse para alertar a ese supervisor la aparición del control de tráfico. En este ejemplo, se supone que el supervisor no está interesado en observar un control de tráfico de rutina, y por lo tanto el tren de vídeo s31 no se solicita de forma manual por el supervisor de patrulla. Así mismo, debido a que los supervisores de patrulla no están interesados en general en observar controles de tráfico de rutina, el algoritmo de procesamiento de metadatos en su UED 312 no realiza una solicitud automática de que el tren de video s31 se comunique al UED del supervisor.

Supóngase que el control de tráfico de rutina realiza una transición a una situación que comporta una persecución del vehículo de un sospechoso. Bajo esas circunstancias, el supervisor de patrulla puede tener súbitamente interés en observar el tren de vídeo asociado con tal suceso. El supervisor de patrulla puede tener conocimiento de la existencia de la persecución como resultado de la supervisión de las comunicaciones por voz que implican al grupo. Como alternativa, uno o más campos o elementos de los metadatos 110 asociados con el tren de datos de vídeo s31 pueden sugerir que una persecución se encuentra en curso. Por ejemplo, los metadatos 110 que indican que el vehículo de patrulla está viajando a alta velocidad y con las luces de emergencia activadas puede servir como una indicación de que se encuentra en curso una persecución. El UED puede procesar los metadatos para determinar que existe una condición que es probable que sea de interés para el supervisor de patrulla. Por consiguiente, el UED 312 del supervisor puede programarse para solicitar de manera automática que el tren de vídeo s31 se le comunique. Como alternativa, la información de metadatos que indica que una persecución en curso puede visualizarse al supervisor de patrulla, dando lugar a que el supervisor de patrulla solicite el tren de video s31 asociado. En uno u otro caso, una solicitud (Demanda (s31) ) se comunica a la función de grupo Gp para el tren de video asociado. Tras la recepción de tal solicitud, la función de grupo Gp comunica tramas de video asociadas con el tren de video s31 al UED 312 como un tren de video de usuario.

Uno o más miembros de un grupo también pueden recibir por lo menos un segundo tren de metadatos de grupo de una segunda función de grupo. Por ejemplo, en el ejemplo que se muestra en la figura 3, el UED 312 de un supervisor de grupo puede recibir un segundo tren de metadatos de grupo (metadatos de gt) a partir de la función de grupo Gt . En este ejemplo, la función de grupo Gt procesa los trenes de video ti, t2 y t3 que se reciben a partir de un grupo de cámaras de tráfico 306i, 3062, 3O63. La función de grupo Gt genera unos metadatos de grupo (metadatos de gt) de una forma similar a la función de grupo Gp. En el presente escenario, los metadatos a partir de las cámaras de tráfico incluyen su ubicación, y unas imágenes en miniatura tal como se ha descrito previamente. Una aplicación de' soporte lógico que se ejecuta en el UED 312 del supervisor puede supervisar los metadatos a partir de Gp, reconocer el escenario de persecución que se ha descrito en lo que antecede sobre la base de tales metadatos, y visualizar el tren de video de coche patrulla s31 tal como se ha descrito previamente. De acuerdo con una realización adicional de la invención, la ejecución de aplicación de soporte lógico en el UED 312 puede usar los metadatos de ubicación asociados con el tren de datos de video s31 para determinar los trenes de video de cámaras de tráfico que son relevantes para la persecución. Sobre la base de tal determinación, el UED 312 puede solicitar de manera automática (Demanda (tn) ) uno o más trenes de video de cámaras de tráfico tn apropiados a partir de la función de grupo Gt . Tras la recepción de tal tren de video en el UED 312, el tren o trenes de video pueden visualizarse de manera automática en el UED 312, junto con el tren de video a partir del coche patrulla en persecución. De forma similar, es probable que las condiciones de tráfico generales a una distancia moderada con respecto a la persecución puedan ser relevantes para el dictamen del supervisor. Podría concebirse que en estas circunstancias, podrían ser adecuadas unas "instantáneas" periódicas en lugar de un vídeo de transmisión por secuencias. Por consiguiente, las imágenes en miniatura incluidas en el tren de metadatos de grupo podrían visualizarse en el UED 312 en lugar de un vídeo de transmisión por secuencias para determinadas cámaras de tráfico. Debido a que tales imágenes en miniatura son imágenes instantáneas o fijas, estas tendrían un requisito de ancho de banda significativamente más bajo que el video de transmisión por secuencias completo.

Pasando a continuación a la figura 4, hay un diagrama de flujo que es útil para comprender el funcionamiento de uno o más UED. El proceso puede comenzar en la etapa 402 y continúa hasta la etapa 404. En la etapa 404 un UED recibe uno o más trenes de metadatos de grupo común a partir de una o más funciones de grupo. En la etapa 406 uno o más tipos de información contenidos en el tren de metadatos de grupo común se procesan y se visualizan opcionalmente para un usuario en una interfaz gráfica de usuario. Tal información puede incluir una presentación directa de la información de metadatos (por ejemplo, ubicación de vehículo patrulla visualizada en la pantalla) o notificaciones de información de estatus de vehículo que se derivan de metadatos (por ejemplo, el estatus es patrullando, control de tráfico en curso, o vehículo de patrulla en persecución) . En la etapa 410 el UED puede determinar (sobre la base de los metadatos recibidos) si algún tren de vídeo particular es de interés para un usuario. Tal como se ha descrito previamente, esta determinación puede realizarse sobre la base de la aplicación de una o más reglas previamente programadas que especifican las condiciones bajo las cuales unos trenes de vídeo particulares son de interés para un usuario. Por consiguiente, el UED analiza sintácticamente el tren de metadatos de grupo y analiza los metadatos para cada tren para identificar uno o más trenes de interés.

Si por lo menos un video es de interés para un usuario particular (410: Si) entonces el proceso continúa hasta la etapa 412 en la que el uno o más trenes de video se solicitan a partir de una o más de las funciones de grupo (por ejemplo, Gp, Gt) . A continuación de lo anterior, el proceso continúa hasta la etapa 413 en la que se realiza una determinación en lo que respecta a si debería complementarse el tren de vídeo de interés con trenes adicionales de trenes de vídeo relacionados que pueden ser relevantes para el usuario. Una determinación en la etapa 413 dependerá de una diversidad de factores que pueden variar de acuerdo con una implementación particular. Por ejemplo, estos factores pueden incluir la identidad de la fuente del tren de vídeo seleccionada, y la razón o las razones por las cuales se consideró que ese tren de vídeo particular era de interés para un usuario, y si los trenes de vídeo adicionales proporcionarán una información relevante en relación con un tren de vídeo seleccionado. Por ejemplo, considérese el caso en el que la fuente de vídeo es una cámara montada en la parte delantera de un vehículo patrulla, y el tren de vídeo se selecciona para su visualización debido a que los metadatos sugieren una persecución que implica a ese vehículo de patrulla. En un escenario de este tipo, uno o más trenes de vídeo de cámaras de tráfico pueden relevantes para el usuario. A la inversa, considérese el caso en el que los metadatos para un tren de video indican que la fuente de vídeo es una cámara de vídeo montada en la parte delantera de un vehículo patrulla, pero el tren de vídeo se selecciona debido a que los metadatos indican que un control de tráfico se encuentra en curso. En un escenario de este tipo, el beneficio de la visualización de trenes de vídeo a partir de las cámaras de tráfico en el área puede ser mínimo. Por consiguiente, en el presente caso podría realizarse una determinación de que un tren de vídeo complementario no es necesario o deseable.

Si se realiza una determinación de que sería ventajoso complementar un tren de vídeo seleccionado con uno o más trenes de vídeo adicionales, entonces el proceso prosigue hasta la etapa 414. En esta etapa, se realiza una determinación en lo que respecta a si hay trenes de vídeo relacionados disponibles que son relevantes para el tren de vídeo que se ha seleccionado. Esta etapa también puede comportar la evaluación de los metadatos asociados con un tren particular para identificar trenes de vídeo relevantes. Por ejemplo, considérese de nuevo el escenario de persecución que se ha descrito en lo que antecede. Podría accederse a los metadatos de ubicación a partir del tren de vídeo que se proporciona por el vehículo de patrulla para determinar una ubicación aproximada del vehículo de patrulla. A continuación, podría realizarse una determinación en la etapa 414 en lo que respecta a si había alguna cámara de tráfico ubicada dentro de una cierta distancia previamente determinada de la ubicación actual del vehículo de patrulla. Por supuesto, la invención no está limitada a este respecto y otras realizaciones también son posibles. Si están disponibles trenes de vídeo relevantes, estos se solicitan en la etapa 416. En la etapa 418, puede realizarse un procesamiento adicional para visualizar los trenes de vídeo solicitados. En la etapa 420, se realiza una determinación en lo que respecta a si debería terminarse el proceso 400. De ser así, el proceso termina en la etapa 422. De lo contrario, el proceso continúa en la etapa 404.

Haciendo referencia a continuación a la figura 5, se ilustra una arquitectura de ordenador que es útil para comprender los métodos y sistemas que se describen en el presente documento para la distribución en grupo de los trenes de vídeo. La arquitectura de ordenador puede incluir una pluralidad de UED. Por ejemplo, una pluralidad de UED portátiles 502, 514 se encuentran en comunicación con una infraestructura de red 510 usando una interfaz inalámbrica 504 y un servidor de punto de acceso 506. Como alternativa, o además de los UED 502, 514, una pluralidad de UED 516 pueden comunicarse con la infraestructura de red directamente por medio de conexiones cableadas. Una pluralidad de cámaras de vídeo 503, 518 puede servir como fuentes para los trenes de video. Las cámaras de vídeo comunican trenes de datos de vídeo con los servidores de vídeo 508, 509. Los datos pueden comunicarse mediante una infraestructura cableada o inalámbrica. En algunas realizaciones, la interfaz inalámbrica 504 y / o la infraestructura de red 510 pueden usarse para el presente fin, pero la invención no está limitada a este respecto. Por ejemplo, en algunas realizaciones puede ser preferible que los trenes de vídeo se comuniquen a los servidores 508, 509 por una interfaz aérea e infraestructura de red independiente.

Las cámaras de vídeo 503, 518 comunican trenes de datos de vídeo (incluyendo metadatos) a un servidor de vídeo de grupo 508, 509 respectivo. Cada servidor de vídeo está programado con un conjunto de instrucciones para realizar actividades asociadas con una función de grupo (por ejemplo, Gl, Gp, Gt) tal como se describe en el presente documento. Como alternativa, un único servidor puede programarse para realizar actividades para facilitar actividades asociadas con una pluralidad de dichas funciones de grupo. Por consiguiente, los servidores de vídeo 508, 509 analizan sintácticamente los trenes de datos de vídeo y generan trenes de metadatos de grupo común tal como se ha descrito previamente. A continuación, los trenes de metadatos de grupo común se comunican a uno o más de los UED 502, 514, 516 por medio de la infraestructura de red 510 y / o la interfaz inalámbrica 504. Se generan solicitudes o demandas de trenes de video en los UED sobre la base de un análisis humano o de máquina del tren de metadatos de grupo común. Tales solicitudes se envían a los servidores de vídeo 508 y / o 509 usando la interfaz inalámbrica 504 y / o la infraestructura de red 510. En respuesta a tales solicitudes, los trenes de vídeo se comunican a UED a partir de los servidores de vídeo. En algunas realizaciones, los servidores de vídeo 508, 509 también pueden analizar los metadatos contenidos en los trenes de vídeo recibidos para determinar si un tren de vídeo debería enviarse a un UED particular.

La presente invención puede adoptar la forma de un producto de programa informático en un medio de almacenamiento utilizable por ordenador (por ejemplo, un disco duro o un CD-ROM) . El medio de almacenamiento legible por ordenador puede tener un código de programa utilizable por ordenador incorporado en el medio. La expresión producto de programa informático, tal como se usa en el presente documento, se refiere a un dispositivo que está compuesto por la totalidad de las características que permiten la implementación de los métodos que se describen en el presente documento. Programa informático, aplicación de soporte lógico, rutina de soporte lógico informático, y / u otras variantes de estas expresiones, en el presente contexto, quieren decir cualquier expresión, en cualquier lenguaje, código o notación, de un conjunto de instrucciones previstas para dar lugar a que un sistema que tiene una capacidad de procesamiento de información realice una función particular o bien directamente o bien después de una u otra, o ambas, de lo siguiente: a) conversión a otro lenguaje, código o notación; o b) reproducción en una forma material diferente.

Los métodos que se describen en el presente documento pueden realizarse en diversos tipos de dispositivos y sistemas de ordenador, incluyendo un ordenador de servidor, un ordenador de usuario de cliente, un ordenador personal (PC), un ordenador tipo tableta, un ordenador portátil, un ordenador de sobremesa, o cualquier otro dispositivo capaz de ejecutar un conjunto de instrucciones (secuencial o de otro modo) que especifica acciones que van a adoptarse por ese dispositivo. Además, a pesar de que algunas de las etapas comportan un único ordenador, deberá entenderse que la expresión "sistema de ordenador" incluye también cualquier colección de dispositivos de cálculo que ejecutan, de manera individual o conjunta, un conjunto (o múltiples conjuntos) de instrucciones para realizar cualesquiera una o más de las metodologías que se analizan en el presente documento.

Haciendo referencia a continuación a la figura 6, se proporciona un UED 600 a modo de ejemplo que es útil para comprender la invención. El UED 600 incluye un procesador 612 (tal como una unidad de procesamiento central (CPU) , una unidad de procesamiento de gráficos (GPU, o ambos), una unidad de disco 606, una memoria principal 620 y una memoria estática 618, que se comunican uno con otro por medio de un bus 622. El UED 600 puede incluir además una unidad de visualización 602, tal como un visualizador de video (por ejemplo, un visualizador de cristal liquido o LCD) , un panel plano, un visualizador de estado sólido, o un tubo de rayos catódicos (CRT) ) . El UED 600 puede incluir un dispositivo de entrada de usuario 604 (por ejemplo, un teclado) , un dispositivo de control de cursor 614 (por ejemplo, un ratón) y un dispositivo de interfaz de red 616. El dispositivo de interfaz de red 716 proporciona unas comunicaciones de red con respecto a la infraestructura de red 504, 510. En el caso de los UED 502 que se comunican de manera inalámbrica, el dispositivo de interfaz de red 616 puede incluir un transceptor inalámbrico (que no se muestra) según sea necesario para comunicarse con la interfaz inalámbrica 504.

La unidad de disco 606 incluye un medio de almacenamiento legible por ordenador 610 en el que se almacena uno o más conjuntos de instrucciones 608 (por ejemplo, código de soporte lógico) configurados para implementar una o más de las metodologías, procedimientos o funciones que se describen en el presente documento. Las instrucciones 608 también pueden residir, completamente o por lo menos parcialmente, dentro de la memoria principal 620, la memoria estática 618, y / o dentro del procesador 612 durante la ejecución de las mismas por el sistema de ordenador. La memoria principal 620 y el procesador 612 también pueden constituir medios legibles por máquina.

Haciendo referencia a continuación a la figura 7, un servidor de video 700 a modo de ejemplo incluye un procesador 712 (tal como una unidad de procesamiento central (CPU) , una unidad de procesamiento de gráficos (GPU, o ambos), una unidad de disco 706, una memoria principal 720 y una memoria estática 718, que se comunican uno con otro por medio de a bus 722. El servidor de video 700 puede incluir además una unidad de visualización 702, tal como un visualizador de video (por ejemplo, un visualizador de cristal liquido o LCD) , un panel plano, un visualizador de estado sólido, o un tubo de rayos catódicos (CRT) ) . El video 700 puede incluir un dispositivo de entrada de usuario 704 (por ejemplo, un teclado) , un dispositivo de control de cursor 714 (por ejemplo, un ratón) y un dispositivo de interfaz de red 716. El dispositivo de interfaz de red 716 proporciona unas comunicaciones de red con respecto a la infraestructura de red 510.

La unidad de disco 706 incluye un medio de almacenamiento legible por ordenador 710 en el que se almacena uno o más conjuntos de instrucciones 708 (por ejemplo, código de soporte lógico) configurados para implementar una o más de las metodologías, procedimientos o funciones que se describen en el presente documento. Las instrucciones 708 también pueden residir, completamente o por lo menos parcialmente, dentro de la memoria principal 720, la memoria estática 718, y / o dentro del procesador 712 durante la ejecución de las mismas por el sistema de ordenador. La memoria principal 720 y el procesador 712 también pueden constituir medios de almacenamiento legibles por máquina.

Las arquitecturas que se ilustran en las figuras 6 y 7 se proporcionan como ejemplos. No obstante, la invención no está limitada a este respecto y puede usarse cualquier otra arquitectura de sistema de ordenador adecuada también sin limitación. Implementaciones de soporte físico dedicado incluyendo, pero sin limitarse a, circuitos integrados específicos de una aplicación, matrices de lógica programable, y otros dispositivos de soporte físico pueden construirse de forma similar para implementar los métodos que se describen en el presente documento. Las aplicaciones que pueden incluir los aparatos y sistemas de diversas realizaciones incluyen, en términos generales, una diversidad de sistemas electrónicos y de ordenador. Algunas realizaciones pueden implementar funciones en dos o más dispositivos o módulos de soporte físico interconectados específicos con unas señales de control y de datos relacionadas que se comunican entre y a través de los módulos, o como porciones de un circuito integrado especifico de una aplicación. Por lo tanto, el sistema a modo de ejemplo puede aplicarse a implementaciones de soporte lógico, de soporte lógico inalterable y de soporte físico.

De acuerdo con diversas realizaciones de la presente invención, los métodos que se describen en el presente documento se almacenan como programas de soporte lógico en un medio de almacenamiento legible por ordenador y se configuran para ejecutarse en un procesador de ordenador. Además, las implementaciones de soporte lógico pueden incluir, pero no están limitadas a, procesamiento distribuido, procesamiento distribuido de componentes / objetos, procesamiento en paralelo, procesamiento de máquina virtual, que también pueden construirse para implementar los métodos que se describen en el presente documento, conectado con un entorno de red se comunica a través de la red usando las instrucciones 608. Tal como se usa en el presente documento, la expresión "medio de almacenamiento legible por ordenador" debería interpretarse como que incluye un único medio o múltiples medios (por ejemplo, base de datos centralizada o distribuida, y / o las memorias intermedias de alta velocidad y servidores asociados) que almacenan el uno o más conjuntos de instrucciones. La expresión "medio de almacenamiento legible por ordenador" también deberá interpretarse como que incluye cualquier medio que sea capaz de almacenar, codificar o portar un conjunto de instrucciones para su ejecución por la máquina y que hace que la máquina realice cualesquiera una o más de las metodologías de la presente divulgación.

La expresión "medio legible por ordenador" deberá interpretarse por consiguiente como que incluye, pero sin limitarse a, memorias de estado sólido tal como una tarjeta de memoria u otro paquete que aloja una o más memorias de solo lectura (no volátiles) , memorias de acceso aleatorio, u otras memorias regrabables (volátiles) ; medios magneto-ópticos u ópticos tal como un disco o una cinta. Por consiguiente, se considera que la divulgación incluye cualesquiera uno o más de un medio legible por ordenador como se enumera en el presente documento y que incluye equivalentes reconocidos y medios que los sucedan, en los que se almacenan las implementaciones de soporte lógico en el presente documento.

A pesar de que la invención se ha ilustrado y descrito con respecto a una o más implementaciones, a otros expertos en la materia se les ocurrirán modificaciones y alteraciones equivalentes tras la lectura y comprensión de la presente memoria descriptiva y los dibujos adjuntos. Además, a pesar de que una característica particular de la invención puede haberse divulgado con respecto a solo una de varias implementaciones, tal característica puede combinarse con otras una o más características de las otras implementaciones según pueda ser deseable y ventajoso para cualquier aplicación dada o particular. Por lo tanto, la amplitud y el alcance de la presente invención no deberían estar limitados por ninguna de las realizaciones que se han descrito en lo que antecede. En su lugar, el alcance de la invención debería definirse de acuerdo con las siguientes reivindicaciones y sus equivalentes.

Se hace constar que con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.

Claims (10)

REIVINDICACIONES

1. Un método para gestionar la distribución de medios de video en un entorno de grupo, que comprende: recibir en un servidor de grupo una pluralidad de trenes de datos de video que se generan de manera respectiva en una pluralidad de dispositivos de fuente de datos de video asociados con un grupo, incluyendo cada uno de dichos trenes de datos de video una pluralidad de tramas de video y una pluralidad de campos de metadatos; accionar un procesador de ordenador en dicho servidor de grupo para analizar sintácticamente dichos trenes de datos de video para extraer dichas tramas de video e información que comprende dicha pluralidad de campos de metadatos; generar un tren de metadatos de grupo común que incluye, de manera selectiva, información de metadatos a partir de cada uno de dicha pluralidad de campos de metadatos; comunicar dicho tren de metadatos de grupo común a una pluralidad de dispositivos de equipo de usuario (UED) que comprenden dicho grupo; recibir a partir de por lo menos uno de dichos UED, una demanda de un primer tren de vídeo de usuario sobre la base de dicho tren de metadatos de grupo común; en respuesta a dicha demanda, generar un primer tren de vídeo de usuario que comprende dicha pluralidad de tramas de vídeo incluidas en uno de dichos trenes de datos de vídeo, y comunicar dicho primer tren de vídeo de usuario a dicho UED a partir del cual se recibió dicha demanda.

2. El método de acuerdo con la reivindicación 1, que además comprende generar dicha demanda en uno o más de dicha pluralidad de UED sobre la base de una evaluación en dicho UED de dicho tren de metadatos de grupo para determinar si las tramas de vídeo asociadas con una o más de dichas fuentes de datos de vídeo son de interés para un usuario.

3. El método de acuerdo con la reivindicación 2, en el que dicha evaluación incluye generar unos metadatos secundarios que comprenden una información no especificada directamente por dichos metadatos contenidos en dichos trenes de datos de vídeo.

4. El método de acuerdo con la reivindicación 2, que además comprende determinar sobre la base de dicho tren de metadatos de grupo si es deseable complementar dicho primer tren de vídeo de usuario con por lo menos un segundo tren de vídeo de usuario.

5. El método de acuerdo con la reivindicación 4, que además comprende identificar sobre la base de dicho tren de metadatos de grupo, uno o más segundos trenes de vídeo de usuario relevantes para dicho primer tren de vídeo de usuario

6. El método de acuerdo con la reivindicación 1, que además comprende usar dicho procesador de ordenador en dicho servidor para evaluar dicha pluralidad de campos de metadatos contenidos en cada uno de dicha pluralidad de trenes de datos de video para determinar si dicha pluralidad de tramas de video asociadas con por lo menos una de dichas fuentes de datos de video deberla comunicarse de manera automática a uno de dichos UED.

7. El método de acuerdo con la reivindicación 1, que además comprende generar unos metadatos secundarios que comprenden una información no especificada directamente por dichos metadatos que se generan en dicha pluralidad de dispositivos de fuente de datos de video.

8. Un método para gestionar la distribución de medios de video en un entorno de grupo, que comprende: recibir en un servidor de grupo una pluralidad de trenes de datos de video que se generan de manera respectiva en una pluralidad de dispositivos de fuente de datos de video asociados con un grupo, incluyendo cada uno de dichos trenes de datos de video una pluralidad de tramas de video y una pluralidad de campos de metadatos; accionar un procesador de ordenador en dicho servidor de grupo para analizar sintácticamente dichos trenes de datos de video para extraer dichas tramas de video e información que comprende dicha pluralidad de campos de metadatos; generar un tren de metadatos de grupo común que incluye, de manera selectiva, información de metadatos a partir de cada uno de dicha pluralidad de campos de metadatos; comunicar dicho tren de metadatos de grupo común a una pluralidad de dispositivos de equipo de usuario (UED) que comprenden dicho grupo; recibir a partir de por lo menos uno de dichos UED, una demanda condicional para un primer tren de vídeo de usuario sobre la base de dicho tren de metadatos de grupo común; en respuesta a dicha demanda, generar un primer tren de vídeo de usuario que comprende dicha pluralidad de tramas de vídeo incluidas en uno de dichos trenes de datos de vídeo, y comunicar dicho primer tren de vídeo de usuario a dicho UED a partir del cual se recibió dicha demanda.

9. El método de acuerdo con la reivindicación 8, en el que dicha demanda condicionad especifica por lo menos una acción de procesamiento que va a realizarse por dicho procesador de ordenador antes de dicha comunicación de dicho primer tren de vídeo de usuario a dicho UED.

10. El método de acuerdo con la reivindicación 8, que además comprende generar dicha demanda en uno o más de dicha pluralidad de UED sobre la base de una evaluación en dicho UED de dicho tren de metadatos de grupo para determinar si las tramas de vídeo asociadas con una o más de dichas fuentes de datos de vídeo son de interés para un usuario.