ES2321094T3 - Sistema de asistencia video para la grabacion de video eficiente para la reproduccion en varias pantallas. - Google Patents
Sistema de asistencia video para la grabacion de video eficiente para la reproduccion en varias pantallas. Download PDFInfo
- Publication number
- ES2321094T3 ES2321094T3 ES04022235T ES04022235T ES2321094T3 ES 2321094 T3 ES2321094 T3 ES 2321094T3 ES 04022235 T ES04022235 T ES 04022235T ES 04022235 T ES04022235 T ES 04022235T ES 2321094 T3 ES2321094 T3 ES 2321094T3
- Authority
- ES
- Spain
- Prior art keywords
- data element
- canvas
- data
- assigned
- image
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 claims description 19
- 238000012545 processing Methods 0.000 claims description 15
- 230000008569 process Effects 0.000 claims description 6
- 238000004590 computer program Methods 0.000 claims description 2
- 230000006870 function Effects 0.000 description 22
- 230000000694 effects Effects 0.000 description 13
- 230000009471 action Effects 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 4
- 238000012546 transfer Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000012800 visualization Methods 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 238000012805 post-processing Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
- G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
- G11B27/34—Indicating arrangements
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
- G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
- G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
- G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
- G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N5/00—Details of television systems
- H04N5/222—Studio circuitry; Studio devices; Studio equipment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N5/00—Details of television systems
- H04N5/222—Studio circuitry; Studio devices; Studio equipment
- H04N5/262—Studio circuits, e.g. for mixing, switching-over, change of character of image, other special effects ; Cameras specially adapted for the electronic generation of special effects
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Television Signal Processing For Recording (AREA)
- Management Or Editing Of Information On Record Carriers (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
Abstract
Procedimiento para la creación de una estructura de datos para la grabación, el procesamiento y la reproducción asíncrona de varias corrientes video diferentes en un ordenador, que entran desde diferentes fuentes, - realizándose la reproducción en el interior de ventanas de reproducción Canvas en al menos una pantalla, - y estando representada cada pantalla en una estructura de datos central de ResourceManager por un elemento de datos Displaycontroller, - asignándose a cada pantalla al menos un elemento de datos Canvas, así como exactamente un elemento de datos ShowPackage, que contiene una lista de elementos de datos ShowItem a visualizar en esta pantalla, - teniendo asignado cada elemento de datos ShowItem exactamente una imagen de una corriente video y conteniendo una lista de elementos de datos ShowTarget, que están asignados respectivamente a exactamente un elemento de datos Canvas, que designa la ventana de reproducción Canvas, en la que debe visualizarse esta imagen, - estando asignado a cada elemento de datos Canvas exactamente un elemento de datos StateController, que direcciona este elemento de datos Canvas mediante el elemento de datos ShowTarget e indica qué corrientes video deben visualizarse en la ventana de reproducción Canvas correspondiente, - comprendiendo la actualización de las ventanas de reproducción Canvas en las pantallas con ayuda de las imágenes entrantes las siguientes etapas: para cada elemento de datos StateController y para cada imagen entrante de una corriente video: - consulta del elemento de datos StateController actual para averiguar si la corriente video de la que procede la imagen entrante actual debe visualizarse en la ventana de reproducción Canvas que está asignada al StateController actual, - en caso de deber visualizarse la corriente video en la ventana de reproducción Canvas correspondiente y en caso de que la imagen entrante actual aún no tiene asignado un elemento de datos ShowItem, generación de un nuevo elemento de datos ShowItem, que se asigna a la imagen entrante y - añadidura del elemento de datos ShowItem asignado a la imagen entrante actual a la lista de elementos de datos ShowItem del elemento de datos ShowPackage correspondiente del elemento de datos StateController actual, así como - añadidura del elemento de datos ShowTarget del elemento de datos StateController actual a la lista de elementos de datos ShowTarget del nuevo elemento de datos ShowItem.
Description
Sistema de asistencia video para la grabación de
video eficiente para la reproducción en varias pantallas.
La presente invención se refiere a un
procedimiento para la creación de una estructura de datos para la
grabación, el procesamiento y la reproducción asíncrona de
imágenes. Además, la invención se refiere a un programa de
ordenador para la creación de una estructura de datos de este tipo,
que puede cargarse en una instalación de procesamiento de datos y
que durante su ejecución realiza las etapas del procedimiento, así
como a un sistema de procesamiento de datos, que comprende un
dispositivo para la ejecución de las etapas del procedimiento.
Durante los últimos años, la grabación, el
procesamiento y la reproducción de películas ha cambiado
progresivamente de medios analógicos a medios digitales. El motivo
de este desarrollo estaba también en gran medida en las
posibilidades multimedia que ofrece el medio digital, lo que se
refiere, p.ej. al manejo interactivo de videos digitales, así como
a las posibilidades más flexibles de guardar en memoria.
No obstante, los sistemas digitales deben
cumplir requisitos estrictos ya durante la grabación, el
procesamiento y la reproducción de un video individual, en lo que
se refiere a la potencia de cálculo y los requisitos de control,
sin mencionar los requisitos en el caso de varios videos, es decir,
p.ej. en la reproducción simultánea de varios videos y/o imágenes en
directo diferentes.
Debido a la gran potencia de cálculo y los
requisitos de control necesarios para poder procesar
simultáneamente varias funciones de pantalla diferentes de este
tipo, en el software disponible en el comercio hasta ahora sólo fue
posible distribuir una sola corriente de contenidos video de forma
síncrona entre distintas pantallas. Por lo tanto, sólo se pudo ver
en todos los equipos con pantalla conectados simultáneamente el
mismo contenido video.
En el documento US 2003/0231259A1 está descrita
la posibilidad de guardar varias fuentes de datos en una zona de
memoria y visualizarlos a continuación en tiempo real en un equipo
de salida. El contexto aquí es el campo de la televisión digital y
los datos de imágenes son depositados por un dispositivo hardware en
una memoria común y se emiten según la frecuencia de repetición de
imagen (75 Hz) de forma conjunta en la pantalla. Típicamente las
imágenes no son
superpuestas sino que se incorporan en un layout de ventana con flexibilidad limitada del administrador de ventanas.
superpuestas sino que se incorporan en un layout de ventana con flexibilidad limitada del administrador de ventanas.
El documento US 6.570.581 B1 se mueve en el
contexto del movimiento de actores reales en escenas 3D generadas
por ordenador ("computer generated imagery" - CGI = "imágenes
generadas por ordenador") incl. efectos especiales. Aquí, los
actores deben actuar de tal forma como si vieran realmente las CGI,
aunque por lo general las CGI no se crean hasta después de la
grabación en directo con los actores superponiéndose en la
postproducción. Para evitar procesamientos posteriores que
requieren mucho tiempo y costes, que pueden resultar porque
posteriormente no coinciden las CGI y los movimientos de los
actores, el documento US 6,570,581 B1 da a conocer un sistema con
el que, por un lado, se crean las CGI y que, por otro lado, recibe
la grabación de los actores reales. El sistema mezcla a
continuación las dos señales en una pantalla.
En la clase QMovie (3qt) se dan a conocer
métodos y estructuras de datos para la carga incremental de
animaciones o imágenes. En este caso comienza la película en cuanto
se haya generado un objeto Qmovie; en cuanto se haya reproducido el
último fotograma de la película puede volverse nuevamente al punto
inicial, siempre que ya se haya definido previamente un bucle de
este tipo. No obstante, los objetos QMovie son "explicitly
shared", es decir, para crear películas independientes, los
mismos deben construirse por separado.
La presente invención tiene el objetivo de
crear, a pesar de los problemas existentes en los sistemas digitales
en relación con la potencia de cálculo y los requisitos del
control, una arquitectura de sistema que permita una grabación, un
procesamiento y una reproducción de varias corrientes video
diferentes.
Esto se consigue mediante un procedimiento con
las características de la reivindicación 1. Según la presente
invención se crea una estructura de datos con la que se pueden
visualizar y/o reproducir simultáneamente distintos contenidos
multimedia. Por ejemplo, puede visualizarse en una pantalla táctil
una película guardada en disco duro mientras que en una salida
video puede verse permanentemente la imagen en directo de una de las
cámaras que pueden conectarse. Al mismo tiempo, un sistema client
conectado mediante una red (también de forma inalámbrica mediante
WLAN) podría reproducir otra película ya guardada en memoria. De
esta forma se crea un auténtico entorno multitasking para trabajos
de dirección y cámara en el lugar de rodaje.
La estructura de datos según la invención prevé,
además, que p.ej. puede superponerse la imagen en directo actual a
una película reproducida de un disco, que pueden superponerse
distintas imágenes en directo y que pueden visualizarse
Mix-Takes (tomas mixtas) especiales (superposición
de varias películas guardadas en la memoria del disco), también con
la posibilidad de superponer adicionalmente la imagen en
directo.
Por lo tanto, con la estructura de datos
nuevamente desarrollada se ofrecen por vez primera en el entorno de
las películas dos campos de aplicación valiosos nuevos sin costes
adicionales por el hardware. Por un lado, pueden distribuirse
varios contenidos digitales distintos, como secuencias video
guardadas y/o señales video grabadas en directo, en tiempo real
entre varios terminales con pantalla conectados directamente o
mediante (W)LAN, pudiendo estar provistas estas señales
video previamente de forma adicional de efectos de filtro calculados
(el llamado modo asíncrono); por otro lado, pueden superponerse y
mezclarse en tiempo real varios contenidos digitales diferentes,
como secuencias video guardadas y/o señales video grabadas en
directo (el llamado Mix & Overlay-Modus = modo
de mezcla y superposición), pudiendo procesarse la corriente video
que se genera nuevamente como contenido digital. Hasta ahora no
existe un sistema de asistencia video digital y controlado por
software comparable, en el que sea posible un multitasking de este
tipo ya en el lugar de rodaje, mientras que el cámara controla,
p.ej. la grabación de la cámara A y/o de la cámara B en los
monitores TV-Out conectados con el sistema según la
invención, el asistente de dirección puede encargarse al mismo
tiempo en la pantalla principal (pantalla táctil) de seleccionar
una serie de tomas ya existentes y unirlas para el montaje. Hasta
ahora, estas medidas sólo podían realizarse alternativamente, o
grabación o procesamiento posterior. Gracias a la posibilidad de la
superposición de varios canales, según la presente invención también
es posible por primera vez conseguir con un equipo compacto
directamente en el lugar de rodaje efectos de grabación muy
distintos, que hasta ahora en todo caso podían conseguirse mediante
el procesamiento posterior en el estudio. Estas posibilidades no
pueden conseguirse en el estado actual de la técnica de
microprocesadores y software sin el procedimiento según la
invención para la creación de una estructura de datos.
Conforme a la presente invención está previsto
un procedimiento según la reivindicación 1.
De las reivindicaciones subordinadas resultan
configuraciones especialmente ventajosas.
La fig. 1, muestra un Modelo de Colaboración UML
(UML Collaboration Model) de la arquitectura de sistema
asíncrono.
En una capa de entrada, el sistema de
procesamiento de datos según la invención lee las imágenes que
entran desde una cámara de video mediante tarjetas capturadoras de
video (Video Grabber Cards) o discos duro. Puede estar prevista una
tarjeta capturadora propia para cada cámara cinematográfica que
puede conectarse; además, los discos duros pueden estar
configurados como RAID-0-array. En
la capa de entrada del programa de ordenador según la invención
está previsto para este fin para cada tarjeta capturadora un proceso
de poco peso propio, un llamado thread, aquí denominado GrabThread
y que solicita y recibe los datos de imágenes del controlador de
tarjetas capturadoras. Además, cada GrabThread controla un
writeThread que tiene asignado, que escribe las imágenes durante
una grabación, p.ej. de forma comprimidas en JPEG, en el disco duro.
El motivo de esta división del trabajo de lectura y escritura está
en que el GrabThread no debería perder tiempo por la escritura en
el disco duro mientras lee los datos de imágenes de la tarjeta
capturadora. Para garantizar que los threads trabajan realmente en
paralelo, pueden usarse varias CPU Intel Xeon, que trabajan
adicionalmente en el modo hiperthreading (denominación Intel para
multithreading simultáneo). Para poder reproducir una película así
grabada desde el disco duro, se necesita un objeto que se denomina
aquí DiscPlayer (reproductor de discos) y que trabaja con sólo
lectura en una lista central de las tomas grabadas, teniendo cada
toma nuevamente una lista de todas las imágenes individuales, los
llamados frames (fotogramas). El reproductor de discos tiene un
iterador que indica la toma activa en este momento y un iterador que
indica el fotograma activo en este momento. Estos iteradores son la
forma encapsulada de un puntero orientado al objeto. Puede ir hacia
adelante o hacia atrás, es decir, incrementar o decrementar e
indica correspondientemente el siguiente objeto o el anterior objeto
de la lista a la que puede accederse con ayuda del iterador.
Para poder reproducir al mismo tiempo distintas
películas de discos duros (o también de otros medios de
almacenamiento) independientemente unos de otros, p.ej. en el
sistema principal y en un terminal client, se necesitan varios
objetos reproductores de disco que trabajan todos en una lista de
tomas central. Los cambios en la lista de tomas (borrar, insertar,
etc.) y en distintas tomas (cambios de montaje, cambio de la
velocidad de fotogramas simulada, etc.) se realizan respectivamente
desde un MovieManager que existe sólo una vez, que informa a su vez
a todos los reproductores de disco de los cambios de este tipo.
Además de la reproducción de las imágenes de película guardadas de
esta forma, también debe ser posible la reproducción directamente
mediante las tarjetas capturadoras de las imágenes en directo
entrantes.
La administración central de toda la
reproducción se realiza mediante el llamado ResourceManager. En
primer lugar hay que mencionar que una imagen video representada,
que se visualiza en una pantalla de proyección determinada,
denominada aquí Canvas, puede estar formada por varias capas. Por
esta razón, un Canvas tiene un número variable de capas,
denominadas aquí layers. Cada capa puede tener activados atributos
propios modificadores de la imagen, como reflexión alrededor del
eje X e Y, blanco y negro, inversión, zoom, máscara y otros. Varios
canvas se reúnen en un contenedor, denominado aquí CanvasContainer.
El motivo de prever esta posibilidad es que se necesitan varios
Canvas, p.ej. cuando deben visualizarse al mismo tiempo imágenes en
directo de varias cámaras en un solo medio de salida (p.ej. la
pantalla táctil). El CanvasContainer se encarga de la gestión de
geometría de los distintos Canvas, es decir, del posicionamiento y
del tamaño de los mismos en la pantalla destino.
Dicho de un modo general existe, por lo tanto,
por un lado un conjunto de imágenes que son enviadas por X
reproductores de discos, así como un conjunto de imágenes que
proceden directamente de Y tarjetas capturadoras. Por otro lado,
existen Z subconjuntos "interesantes" de éstos, que deben
visualizarse en las pantallas. Por lo tanto hay que procurar que
para cada pantalla se "compile un paquete" individual, que
suministra la visualización deseada para esta pantalla. Como
interfaz más importante hacia fuera sirve por lo tanto la función
ShowPackage, que suministra un conjunto de imágenes de capas
especificadas para los terminales con pantalla, estando asignado un
ShowPackage individual a cada pantalla. Gracias a la selección
selectiva de distintos subconjuntos para las imágenes suministradas
por ShowPackage a la pantalla correspondiente pueden componerse
antes de la salida propiamente dicha distintas variantes de salida
para distintos terminales con pantalla, p.ej. al mismo tiempo
varias imágenes independientes unas de otras, que se representan una
al lado de la otra y/o distintas superposiciones o efectos para las
distintas pantallas conectadas.
\vskip1.000000\baselineskip
El ResourceManager ya anteriormente mencionado
compila con ayuda de una lista de objetos de estado, los llamados
objetos StateController, los ShowPackages para las pantallas. Cada
StateController está asignado exactamente a un Canvas, que se
direcciona mediante displayID, canvasContainerNr y canvasNr. En el
caso de la reproducción de imágenes de películas guardadas en disco
duro, el ResourceManager controla también los GrabThreads ya
mencionados y recibe las imágenes de éstos y de los reproductores
de disco. Los reproductores de disco se direccionan aquí mediante
el discPlayerID. Aquí hay una restricción, según la cual cada Canvas
sólo puede recibir al mismo tiempo imágenes de un solo reproductor
de disco. Los Mix&Overlay-Takes no se realizan,
por lo tanto, mediante varios reproductores de disco, sino que un
reproductor de disco envía en este caso ya un ShowPackage con varias
imágenes. En el caso de la reproducción de imágenes en directo no
existe esta restricción. La llamada ChannelList representa en este
caso una especie de lista de deseos, en la que figuran los canales
capturadores de los que el Canvas debe recibir y representar
imágenes al mismo tiempo. Una variable de estado, aquí denominada
state, describe finalmente si el Canvas sólo debe recibir las
imágenes del reproductor de disco, sólo imágenes en directo o
imágenes del disco duro e imágenes en directo superpuestas. El
StateController necesita, por consiguiente, los siguientes
parámetros:
parámetros:
StateController
displayID
canvasContainerNr
canvasNr
discPlayerID
channellList
state
\vskip1.000000\baselineskip
Puesto que puede haber varias pantallas, p.ej.
una para el equipo principal y una para cada pantalla client,
también se necesita una estructura de administración para ello. El
llamado DisplayController sirve aquí como representante de una
pantalla en el ResourceManager. Contiene varias listas que son
necesarias para compilar los ShowPackages, así como un puntero que
indica la pantalla propiamente dicha; ésta recibe a continuación
justamente el ShowPackage que está previsto sólo para esta
pantalla.
La estructura de la "capa de transporte",
en la que se realiza la transferencia de las imágenes a las
pantallas, está determinada por el requisito que una imagen para
cada pantalla se copia también sólo una vez en la memoria de
gráficos, puesto que justamente esta operación es la operación
costosa (en tiempo) y en dinero. En la presente invención, este
requisito ha tenido sus consecuencias entre otras cosas en la
separación de imagen y destino de visualización. Con las
explicaciones anteriormente expuestas debería haberse dejado claro
que una imagen que se visualiza en la pantalla ya no es sólo una
imagen sencilla, sino que está formada por varias imágenes, que se
han ampliado con informaciones de direcciones. El caso realizado en
el Harddisk-Recorder (grabador de disco duro)
"PSU" ® comercializado hasta ahora por Vantage Film GmbH, según
el cual una imagen se visualiza en un Canvas determinado, se
convierte por lo tanto en el caso especial de la estructura de
visualización ampliada según la presente inven-
ción.
ción.
Esta estructura de datos de visualización se
denomina al igual que la función ya anteriormente mencionada
ShowPackage y está formada por una lista de llamados ShowItems. La
lista ShowItem es generada por la aplicación y depende de la
configuración de pantalla ajustada por el usuario, que puede ser
cambiada dinámicamente. Cada ShowItem contiene exactamente una
imagen y una lista de posibles destinos de visualización,
denominados aquí ShowTargets. El ShowTarget indica a su vez
detalladamente el destino de visualización. La estructura y la
relación de ShowPackage, ShowItem y ShowTarget se presentan, por lo
tanto, de la siguiente manera:
Cada imagen con el mismo contenido figura sólo
una vez en la lista de ShowItems del ShowPackage. Si debe aparecer
en distintos layers, la lista de ShowTargets, de la que hay una para
cada imagen como se ve en la lista arriba indicada, tiene un número
de entradas correspondientemente alto. Esto es así porque cada copia
de una imagen, p.ej. desde la memoria principal a la memoria de
gráficos de la tarjeta gráfica requiere bastarte tiempo. Gracias a
este estructura se tiene por lo tanto en cuenta el requisito
anteriormente indicado reduciéndose el tiempo para copiar al tiempo
mínimo necesario.
La visualización en la pantalla, que termina el
"recorrido" de las imágenes, se realiza con el lenguaje gráfico
OpenGL, habiéndose realizado adaptaciones de eficiencia adicionales
para el procesador gráfico Nvidia usado en la presente invención.
Una ventaja sustancial del uso de OpenGL está en que la mayor parte
de los efectos de imagen, denominados aquí PictureSettings, son
realizados por el hardware del procesador gráfico, por lo que
requieren claramente menos tiempo de cálculo de la CPU en los
procesadores principales xeon. Las CPUs principales sólo deben
hacer que todas las imágenes que han de ser representadas en
paralelo, han de ser superpuestas o modificadas por efectos, se
encuentren en los pipelines de procesamiento del procesador gráfico.
Al principio de la ventana de cálculo de 40ms (PAL) o 33 ms (NTSC)
se transfieren por lo tanto las imágenes necesarias para la
aplicación de las CPUs principales de la memoria principal a la
memoria de gráficos de la tarjeta gráfica. Con el hardware actual
se necesita por imagen un tiempo de transferencia de 2 ms; cuando
deben superponerse, por ejemplo, cinco imágenes, esto tarda 10 ms.
En los equipos de salida PAL quedan por lo tanto aún 30 ms
disponibles para el cálculo de los efectos y superposiciones y la
salida en los terminales. Las imágenes como p.ej. máscaras
fijamente ajustadas o superposiciones permanecen en la memoria de
gráficos y no deben volver a transferirse nuevamente en cada
ventana de tiempo al procesador gráfico. Con el procedimiento dado a
conocer en la solicitud también pendiente "Procedimiento para
crear una estructura caché para el acceso rápido a objetos
guardados en memoria de forma separada" puede conseguirse,
además, que siempre estén disponibles suficientes imágenes de video
en tomas posiblemente distintas en la memoria principal.
Para el grabador de disco duro "PSU" ®
comercializado hasta ahora por Vantage Film GmbH existen como
efectos ya la reflexión X/Y, el zoom y la máscara, así como la
representación en blanco y negro, que según la presente invención
son calculados ahora todos por el procesador gráfico. La variante de
superposición ya realizada en este grabador de disco duro con una
posición fija se desplaza según la presente invención ahora también
a la CPU gráfica, al igual que el gráfico tipo rampa superpuesta a
una toma reproducida actualmente. Un gráfico tipo rampa representa
el desarrollo de la velocidad de la cámara durante la toma e indica
dinámicamente donde se encuentra la imagen actualmente representada
en la rampa. El gráfico tipo rampa ahora puede estar incluso activo
con un efecto zoom conectado simultáneamente, lo cual no era posible
en el grabador de disco duro disponible hasta la fecha.
Técnicamente es posible activar en cada una de
las capas distintos efectos de imagen o ningún efecto y superponer
varias capas por terminal con pantalla. Gracias al uso de la función
ShowPackage, por ejemplo es posible hacer que el gráfico de rampas
superpuesto a una imagen de color aparezca sólo en el monitor
principal táctil, mientras que en las pantallas adicionales
conectadas mediante salidas de video se emite una imagen de blanco y
negro de la escena sin gráfico tipo rampa. Para los efectos de
pantalla azul/verde necesarios en el campo de los efectos
especiales de estudio, se usa al menos en parte el hardware de
gráficos. Se encarga de la mezcla de partes correspondientes de la
imagen después de haberlas marcado como transparentes o opacas.
A continuación, se seguirá con ayuda de ejemplos
de códigos comentados a título de ejemplo el recorrido de una
imagen desde iniciar la acción "Live-Modus"
(Modo en directo) desde la capa de entrada pasando por la
administración central y la capa de transporte a la capa de
visualización. En los ejemplos de códigos se encuentran
informaciones descriptivas importantes para el proceso o las
distintas funciones respectivamente en los comentarios marcados con
"//".
Al hacer clic en el botón
"Live-A" (GUI) se llama en primer lugar una
función slotLiveA en la clase MainGUI:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Aquí, se desconectó el StateController para el
canal B y se cambió el del canal A modo en directo. Como ya se ha
mencionado anteriormente, cada objeto StateController tiene asignado
exactamente un Canvas y dispone entre otras cosas de atributos y
funciones que indican el destino de visualización exacto, así como
los canales "interesantes", los canales en directo que
eventualmente han de ser superpuestos y el modo en cuestión (en
directo o grabación):
\newpage
En el ejemplo aquí descrito se ha seleccionado
el modo en directo, por lo que ahora se describirá más
detalladamente la función LiveMode ():
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Durante la ejecución de esta función se cambia
al estado en directo, el canal seleccionado se añade a la lista de
intereses (si no figura aún allí) y al ResourceManager se envía el
mensaje startLive (canal), que es recibido por la siguiente
función:
\newpage
El proceso hasta ahora descrito ha servido para
la descripción de lo que pasa directamente en los ajustes
predeterminados en el sistema cuando se aprieta el botón
"Live-A". A continuación, se explicará como las
imágenes llegan del GrabThread mediante la administración central y
la capa de transporte a la pantalla.
La llamada de la función
GrabThread::startShowing () despierta el thread, dado el caso.
Comienza en un bucle sin fin a leer imágenes desde una tarjeta
capturada de fotogramas. A partir de cada imagen leída se genera un
mensaje que termina finalmente en el ResourceManager. Descrito de
una forma fuertemente simplificada, el ResourceManager tiene el
siguiente aspecto, siendo especialmente importante la función
slotDispatch (), puesto que en ella se compilan los paquetes
individuales, es decir, los Show-Packages para la
visualización (véanse al respecto las explicaciones más
adelante).
\vskip1.000000\baselineskip
\newpage
Cada imagen de los GrabThreads se alimenta a la
siguiente función, en la que se convierte en un ShowItem, que ahora
contiene además de la imagen también la lista de los destinos de
visualización, es decir, de los ShowTargets:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Por lo demás, aquí no ocurre mucho en cuanto al
procesamiento. Como ya se ha mencionado varias veces, la compilación
del ShowPackage definitivo no debería iniciarse cada vez cuando
llega una nueva imagen (del grabber) o un nuevo paquete (del
reproductor de disco), porque sino sería excesiva la carga de
cálculo para el procesador gráfico (tarjeta gráfica). Cuando hay,
por ejemplo, dos canales en directo A y B y un reproductor de disco,
llega como promedio cada 40 ms/3=13 ms una nueva imagen. El
promedio de este tiempo es demasiado corto para volver a crear
nuevamente la visualización. En lugar de ello se "compila cada 40
ms un paquete global". Esto se inicia mediante uno de los
GrabThread, que tras cada imagen recibida transmite además de la
imagen propiamente dicha también un "impulso", que inicia la
función central slotDispatch() ya mencionada en la que se compilan
los ShowPackages individuales para la visualización. Esta función
slotDispatch es el "núcleo" propiamente dicho del concepto
según la invención. Por ello, se explicará el funcionamiento de esta
función central aquí en primer lugar a modo de una especie de
seudocódigo:
- \quad
- ¿Hay nuevas imágenes que deben ser visualizadas? No -> salir de la función, bucle que afecta a todos los StateController.
- ¿Debe integrarse el último paquete que se ha recibido del reproductor de disco correspondiente?
- Sí: Añade a todos los Items del ShowPackage asignado el destino (target) del StateController actual (contenedor, Canvas).
- ¿El StateController actual se interesa para alguna imagen en directo (_channelList tiene entradas)?
- Sí: Bucle que afecta a todas las entradas de la lista. Añade imagen o ShowItem del canal correspondiente al paquete definitivo. (Este se encuentra en el DisplayController). La operación de insertar garantiza que esta imagen no está ya incluida. Añade el target a este ShowItem.
- \quad
- Bucle que afecta a todos los DisplayController
- \quad
- Añade todos los DiscPlayer-Packages al paquete global del DisplayController que debe visualizarse en esta pantalla.
\newpage
Ahora, el código real correspondiente de la
función slotDispatch:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Después de haberse "compilado los paquetes"
de esta forma con la función slotDispatch, es decir, después de
haberse compilado los ShowPackages, la función
DisplayController::emitPackage transmite ahora cada paquete acabado
a "su" pantalla. Allí es recibido por la función
slotShowPackage():
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Aquí, el objeto Layer (capa) que se direcciona
mediante el target contiene las coordenadas donde debe ser
dibujado, así como diversas informaciones acerca de la forma como
debe ser dibujado (es decir, determinados efectos, etc.). También
es importante la dirección donde los datos de imágenes se encuentran
exactamente en la memoria de gráficos, que deben aparecer en esta
capa. En la función paintGL () implementada en OpenGL se itera
mediante una lista de objetos Layer. Según las entradas en estos
objetos Layer (posición, tamaño, factor zoom, blanco y negro, etc.)
se proyectan las distintas imágenes como textura en rectángulos y se
dibujan una encima de otra de forma semitransparente, siempre que
existan imágenes a superponer.
Con ello se ha reproducido completamente el
recorrido representado a modo de ejemplo de una imagen desde iniciar
la acción "Live Modus" desde la capa de entrada pasando por la
administración central y la capa de transporte hasta la capa de
visualización.
La interfaz del usuario para el control, desde
la cual también se ha puesto en marcha la acción arriba indicada
"Live Modus", contienen los botones y elementos de
visualización ya conocidos por el grabador de disco duro "PSU"
®. En respuesta a acciones del usuario activa, p.ej. las variables
de algunos statecontroller y envía entre otras señales al
ResourceManager (startLive (canal), ...), al Moviemanager (delete
Take (x)...), al DiscPlayer (play ()...) y al Display (hawk (),
dual-View ()...).
Naturalmente, el sistema arriba descrito puede
ampliarse añadiéndose el uso de clients de red. Para ello deben
registrarse en el lado del servidor en el ResourceManager un número
de statecontroller que corresponde al número de Canvas en los
clients. Un objeto proxy recibe mensajes a través de la red y activa
p.ej. las variables stateController en el servidor. Además, para
cada client debe haber también un reproductor de disco en el
servidor, en caso de desearse una reproducción desacoplada. El
objeto proxy actúa al mismo tiempo como "pantalla virtual". En
el ResourceManager hay un DisplayController propio para cada client,
mediante el cual pueden enviarse los paquetes al client.
Además de la salida de imágenes, el
ResourceManager controla también el sonido, es decir, la grabación
de sonido (2 threads) y la reproducción. Para ello administra los
equipos de sonido (dispositivo de sonido, mezclador). Cada
reproductor de disco necesita también dos threads para la
reproducción del sonido, leyendo un thread los datos de sonido de
un fichero y transfiriendo el otro los datos de sonido a la tarjeta
de sonido para la salida.
Claims (5)
1. Procedimiento para la creación de una
estructura de datos para la grabación, el procesamiento y la
reproducción asíncrona de varias corrientes video diferentes en un
ordenador, que entran desde diferentes fuentes,
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
- \quad
- para cada elemento de datos StateController y para cada imagen entrante de una corriente video:
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
2. Procedimiento según la reivindicación 1,
caracterizado porque se asigna al menos un elemento de datos
Layer, en el que pueden activarse respectivamente atributos
modificadores de la imagen, a cada elemento de datos Canvas y
porque cada elemento de datos ShowTarget está asignado exactamente a
un elemento de datos Canvas y exactamente a un elemento de datos
Layer.
3. Procedimiento según una de las
reivindicaciones anteriores, caracterizado porque además está
previsto un objeto proxy, que recibe mensajes a través de la red y
que fija las variables para los elementos de datos StateController
de los elementos de datos Canvas que están asignados a las pantallas
conectadas mediante clients.
4. Programa de ordenador para la creación de una
estructura de datos para la grabación, el procesamiento y la
reproducción asíncrona de varias corrientes video diferentes, que
puede cargarse en una instalación de procesamiento de datos y que
realiza en el momento de su ejecución las etapas del procedimiento
según una de las reivindicaciones anteriores.
5. Sistema de procesamiento de datos que
comprende dispositivos para la ejecución de las etapas del
procedimiento según una de las reivindicaciones 1 a 3.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP04022235A EP1638101B1 (de) | 2004-09-17 | 2004-09-17 | Video assist System zur effizienten Videoaufzeichnung für die Wiedergabe auf mehreren Displays |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2321094T3 true ES2321094T3 (es) | 2009-06-02 |
Family
ID=34926593
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04022235T Expired - Lifetime ES2321094T3 (es) | 2004-09-17 | 2004-09-17 | Sistema de asistencia video para la grabacion de video eficiente para la reproduccion en varias pantallas. |
Country Status (4)
| Country | Link |
|---|---|
| EP (1) | EP1638101B1 (es) |
| AT (1) | ATE425537T1 (es) |
| DE (1) | DE502004009143D1 (es) |
| ES (1) | ES2321094T3 (es) |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1013084A4 (en) * | 1998-06-12 | 2002-11-06 | Panavision Inc | DISCOUNTED VIDEO SUPPORT RECORDING BOX |
| WO2001024518A1 (en) * | 1999-09-25 | 2001-04-05 | Koninklijke Philips Electronics N.V. | User interface generation |
| US6570581B1 (en) * | 1999-10-25 | 2003-05-27 | Microsoft Corporation | On-location video assistance system with computer generated imagery overlay |
| US6909836B2 (en) * | 2001-02-07 | 2005-06-21 | Autodesk Canada Inc. | Multi-rate real-time players |
| JP4011949B2 (ja) * | 2002-04-01 | 2007-11-21 | キヤノン株式会社 | マルチ画面合成装置及びデジタルテレビ受信装置 |
-
2004
- 2004-09-17 ES ES04022235T patent/ES2321094T3/es not_active Expired - Lifetime
- 2004-09-17 AT AT04022235T patent/ATE425537T1/de not_active IP Right Cessation
- 2004-09-17 DE DE502004009143T patent/DE502004009143D1/de not_active Expired - Lifetime
- 2004-09-17 EP EP04022235A patent/EP1638101B1/de not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| ATE425537T1 (de) | 2009-03-15 |
| EP1638101B1 (de) | 2009-03-11 |
| DE502004009143D1 (de) | 2009-04-23 |
| EP1638101A1 (de) | 2006-03-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2974683T3 (es) | Sistemas y métodos para enjambres multimedia | |
| ES2674897T3 (es) | Método y dispositivo para manejar múltiples flujos de vídeo usando metadatos | |
| US20200145644A1 (en) | Immersive content production system with multiple targets | |
| CN105765990B (zh) | 通过分布式网络分布视频内容的方法、系统及计算机介质 | |
| US10622020B2 (en) | Point of view video processing and curation platform | |
| TW200832370A (en) | Reproducing device and method, information generation device and method, data storage medium, data structure, program storage medium, and program | |
| CN102077138A (zh) | 用于数字电影的动态显示的方法和设备 | |
| US20240096035A1 (en) | Latency reduction for immersive content production systems | |
| US11250886B2 (en) | Point of view video processing and curation platform | |
| ES2321094T3 (es) | Sistema de asistencia video para la grabacion de video eficiente para la reproduccion en varias pantallas. | |
| Lindstrom | Shooting Melanesians: Martin Johnson and Edward Salisbury in the Southwest Pacific | |
| CN116503522A (zh) | 互动画面的渲染方法、装置、设备、存储介质及程序产品 | |
| Motegi et al. | A study on drama content production using 360-degree video | |
| US9715900B2 (en) | Methods, circuits, devices, systems and associated computer executable code for composing composite content | |
| JP3133115B2 (ja) | 見物施設の仮想体験装置 | |
| Gichuki | Cinematographic Elements in Super Sema | |
| Ryan | Variable frame rate display for cinematic presentations | |
| Dsouza | Think in 3D: Food For Thought for Directors, Cinematographers and Stereographers | |
| Curran | The ‘hybrid image practitioner’in Hong Kong; a critical review of technological developments and their impact on simultaneous creation of still and moving images | |
| Preston | The Man in the Backseat: A Reflection on the Projection Design Process of Hookman | |
| Lantz et al. | Large scale immersive theatres | |
| WO2026094726A1 (ja) | 情報処理システム、情報処理方法および情報処理プログラム | |
| Jansen | From the Lab to the OB Truck | |
| Alam | FILM AND TV SCHOOL | |
| Jablonko | Thoughts on the development on visual research in anthropology: some notes on a personal journey |