WO2015082557A1 - System zum interaktiven aufführen einer darstellung auf einer virtuellen bühne - Google Patents

System zum interaktiven aufführen einer darstellung auf einer virtuellen bühne Download PDF

Info

Publication number
WO2015082557A1
WO2015082557A1 PCT/EP2014/076447 EP2014076447W WO2015082557A1 WO 2015082557 A1 WO2015082557 A1 WO 2015082557A1 EP 2014076447 W EP2014076447 W EP 2014076447W WO 2015082557 A1 WO2015082557 A1 WO 2015082557A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
data
media
client
participants
Prior art date
Application number
PCT/EP2014/076447
Other languages
English (en)
French (fr)
Inventor
Salvatore Vanasco
Laszlo Puskas
Original Assignee
Smjl Gmbh
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Smjl Gmbh filed Critical Smjl Gmbh
Publication of WO2015082557A1 publication Critical patent/WO2015082557A1/de

Links

Classifications

    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09B—EDUCATIONAL OR DEMONSTRATION APPLIANCES; APPLIANCES FOR TEACHING, OR COMMUNICATING WITH, THE BLIND, DEAF OR MUTE; MODELS; PLANETARIA; GLOBES; MAPS; DIAGRAMS
    • G09B5/00—Electrically-operated educational appliances
    • G09B5/06—Electrically-operated educational appliances with both visual and audible presentation of the material to be studied
    • G09B5/065—Combinations of audio and video presentations, e.g. videotapes, videodiscs, television systems

Definitions

  • the invention relates to a system for interactively displaying a representation on a virtual stage.
  • Online collaboration or online playing together several ⁇ rer actors on a common electronic platform is known from prior public use.
  • WO / 67759 Al discloses a system in which different cavities ⁇ Lich separate user and act in their own virtual space as an actor or actors can determine the nature of their representation independent.
  • a system for interactively listing a representation on a virtual stage comprising: a. operator side, a data processing system
  • a media server containing the performance media data
  • an authorization server that communicates to participants, on a schedule, media data including scene images, scheduling and directives
  • iii. a synchronization server that merges media data from the media server and participants synchronized in time
  • a recording server which records synchronized media data from the media server and subscribers and makes available to subscribers as a video stream and / or video file
  • a subscriber-side data processing system comprising: i. Equipment for recording and reproducing video and audio data, ii. a streaming client, which is designed for playback of media data including scene images and directives of the authorization server, iii.
  • a media client which is designed for the transmission of video and audio data to the Synchronisati ⁇ onsserver.
  • a representation for the purposes of the invention is, for example, a play, a role playing game (game, also as part of learning programs at ⁇ ) or suchlike.
  • An interactive performance means that the
  • Participants in the performance can take on it within a pre give ⁇ NEN frame influence, it can be exhaustive or to be limited, for example, that a subscriber triggers the progress of the performance by the conclusion of a particular document or a performance or initiates the performance of a further subscriber O-
  • Participants in the sense of the invention are passive consumers or preferably active contributors to the performance.
  • a virtual stage is a stage on which the contributions of different participants are brought together and inserted into a frame such as a stage set or the like.
  • the presentation or performance on the virtual stage is visible or perceptible for participants or for third parties.
  • the operator makes the system according to the invention available to participants. It contains one called Core
  • server is to be understood in this context as functional and refers to computer units or computer parts that are capable of performing the described functions.
  • the media server contains the media data of a performance. It is the data that is given Disconnect frame, for example, a play and de ⁇ finishing. It concerns the multimedia data of a staging as well as data for its temporal control. These include, for example, stage sets, associated audio, picture and / or video files, stage directions for
  • the media server includes the data that the structure and specific parts of a performance such as in particular for example, the pre-stage design ⁇ ben.
  • the authorization server provides participants with a schedule (a schedule derived from the media server that dictates the structure or design of the performance) of media data including scene images, scheduling, and stage directions.
  • a schedule a schedule derived from the media server that dictates the structure or design of the performance
  • the scene pictures show the participants the background or stage design in front of which they should present their presentation.
  • Sequence control signals specify, for example, the beginning and the intended end of a display.
  • Stage instructions may include instructions for the default content of a presentation requested by the subscriber.
  • the synchronization server merges media data from the media server and participants synchronized in time.
  • Synchronized in time means that the Imaging Logo ⁇ gene of the subscriber, and thus the corresponding media data (game as the stage examples) are inserted so in the predetermined media data of the media server, that a co ⁇ hdter and closed in itself the end of the performance is produced.
  • the synchronization server can according to an advantageous aspect of the invention, in particular the temporal Adjust the performance of the performance (possibly within specified limits) to the representation of the participants and thus ensure that, for example, a new stage or scene image only begins when a participant has actually completed his previous presentation.
  • the recording server records the synchronized media data from the media server and the participants and makes them and / or possibly unrelated third party as Vi deostream (usually incl. Audio) or video file to ⁇ accessible participants.
  • Vi deostream usually incl. Audio
  • video file to ⁇ accessible participants.
  • the invention makes it possible for a plurality of physically remote subscribers to work together on a performance and in doing so on a common virtual
  • Stages are located.
  • a common and coherent performance is ensured, in particular, by the synchronization server, which ensures that the individual contributions to the performance (the media data of the participants) are synchronized in time to the entire performance.
  • the synchronization server allows it to some extent a time-tolerant design to the effect that example ⁇ be maintained with the progress of the performance, until a particular participant has completed its presentation.
  • the inventive system includes a technique called client data processing system with means for recording and reproducing video and audio data (camera, microphone, screen and speaker) and a streaming client, which is designed for playback of Medi ⁇ enish. It is about both Scenes as well as (optional), for example, to directional instructions or other instructions that can help the participant, for example, in the use or the implementation or design of his presentation.
  • client data processing system with means for recording and reproducing video and audio data (camera, microphone, screen and speaker)
  • a streaming client which is designed for playback of Medi ⁇ enish. It is about both Scenes as well as (optional), for example, to directional instructions or other instructions that can help the participant, for example, in the use or the implementation or design of his presentation.
  • Another aspect of the client is a media client, which is designed for real-time transmission of video and audio data to the synchronization server. This media client transmits the presentation of the participant to the Operator Op ⁇ ber workede data processing system, there the synchronization tion server,
  • the operator-side data processing system and the subscriber-side data processing system are interconnected by means of a non real-time capable data connection, preferably via the Internet.
  • subscribers are able to jointly design a performance on a virtual stage without the need for complex real-time data connections between the subscribers and the operator-side data processing system for this purpose.
  • the synchronization server allows its described, to some extent best ⁇ rising time tolerance and that are compensated for example by latency in the Internet transmission delays caused.
  • the authorization server transmits to a client serving data comprising, for example, scene images and directed ⁇ instructions with a lead time, this data is stored on the client ( "precached") maintained.
  • This transmission with a time-forward and the intermediate storage on the client allows existing latencies for example, in a non-real-time Internet environment ⁇ largely offset or completely.
  • the first channel may preferably be designed for the purpose of transmitting commands or requests for requests from the authorization server to the client
  • command or action request is to be understood in the context of the invention and includes both instructions to the client
  • Internal commands or instructions to the client may, for example, be a temporal control of the presentation of pre-stored contents on the screen of the client
  • the described call to action is such time-critical information.
  • action request can be transmitted in real-time or without adversely striking delay, so that his presentation can be seamlessly connected to the end of a vorlau ⁇ fenden presentation.
  • Such an action request can not be precached, as it can not be sent until the previous parts of the performance have been completed.
  • Gestal ⁇ processing with two virtual channels allows such time ⁇ critical to convey some data-intensive information such as the action request mentioned in substantially real time.
  • a connection is permanently maintained between the subscriber-side system (client) and the operator-side system (core).
  • client subscriber-side system
  • core operator-side system
  • co-met web application model can be used for this (http://en.wikipedia.org/wiki/Come_ (programming)). Comet is one
  • this signal arrives at the core, it now transmits the signal for the next action to the next participant on a likewise permanently open connection, which is now its turn. This leads to that already is informed to the actual end of the insert of the previously active participant that he is as Next Tier ⁇ tes "off". To be ready to receive a further signal is now opened another connection between the client and core immediately.
  • the necessary rendering and image composition processes must be carried out for at least the image areas of the participant on the client. This of course increases the performance requirement on the subscriber-side system. Since a broaching ⁇ Lich distributed call situation, there is no reference point to the actual behavior of the other participants, the performance curve is now also visually course, one does not see himself around the time of the above transfer latencies shown delayed. In a virtual performance with a majority of participants, it will not always be possible to reliably provide for the casting of all roles in the performance by participants. In order nevertheless to allow the sequence of the performance even with a shortage of participants, according to the invention avatars can be provided which do not fill roles occupied by participants of the performance. It can be provided according to the invention that the authorization server is able to receive a plurality of client data within a predetermined activation period.
  • the synchronization server is preferably designed for the time-tolerant as- sembling and for the time-tolerant synchronization of the media data from the media server and subscribers. This allows the merging of the mentioned data into a closed performance with seamlessly connected actions or representations.
  • the synchronization server is preferably designed to assemble in response to a participant's behavior.
  • This participant behavior to be analyzed can include, for example, subscriber- initiated triggers (for example, the beginning and end of a presentation or the like) analysis of the audio and / or video signal transmitted by the client and / or word recognition.
  • subscriber- initiated triggers for example, the beginning and end of a presentation or the like
  • the media data preferably includes a schedule, the actors, and scenic components that are provided with electronic attributes.
  • the recording server may be configured to provide the synchronized media data in real-time so that third parties can live-track the virtual performance. It may alternatively or additionally save the virtual performance and make it available to subscribers or third parties as a stored audio and / or video file.
  • sequence control can according to the invention in a compact, machine-readable format such as in
  • JSON Java Script Object Notation
  • XML XML
  • Fig. 2 a-d Schematically the initialization of a
  • Fig. 1 shows schematically a sequence of events in an interactive performance in which an operator-side data processing system (Core) and two participants are involved with the respective clients.
  • Core operator-side data processing system
  • the time axis of the course of the performance runs from left to right.
  • an initialization of the performance takes place at 4, in the course of which the two participants log on to the core.
  • the core at 5 can send an assignment command to the participant 1, so that he can start his first part in the performance.
  • this is done in the described manner via a previously opened and kept open connection between the core and the client 1 example ⁇ by means of the Comet web application model.
  • the part ⁇ contractor 1 plays its predetermined role, as at 6 angedeu ⁇ tet.
  • the participant 2 is at the same time in the waiting ⁇ state.
  • the core receives the data of the role played by the participant 1 via a data transmission channel not shown in the figure (this includes video data and therefore does not necessarily work in real time) and adds it with further data from the media server also not shown in the drawing to a complete scene - Together, as indicated at 8.
  • the client 1 can either constantly recognize this himself (for example by detecting the acoustic end of the roll), or the Subscriber 1 actively sends a signal that his part has ended. This signal over the end of the mission is, as indicated at 7, mediated by the client 1 to the core ⁇ .
  • the core sends a deployment command (indicated at 9) to the
  • Participants 2 which then plays its role in the same way that joins the core with additional media data to ei ⁇ ner scene. After completion of the use of the subscriber 2, the corresponding signal is transmitted at 10 to the core.
  • a variant in which the participant 1 can influence the course of action.
  • the core sends to the subscriber 1 at 11 a question or request for a decision.
  • the participant 1 makes a corresponding decision and transmits it back to the core at 12.
  • the core at 13 makes a selection from two options available for the rest of the performance.
  • a request to display a scene is sent to the participant 1 at 14, in the second variant at 15 a corresponding action request to the participant 2.
  • Fig. 2 shows diagrammatically the processes involved in the initialization ⁇ tion of a performance. Shown schematically here are the processes in the core system with the media server 18, the authorization server 19, the synchronization server 20 and the recording server 21.
  • the authorization server 19 loads a sequence of the intended performance, in the exemplary embodiment this is an XML file. In the figure, this is indicated at 22.
  • the file contains the schedule and the actors as well as scenic elements electro ⁇ nic attributed and structured.
  • the authorization server 19 opens the access for the registration of participants. As indicated at 23, subscriptions are received by subscribers and subscribers are assigned to certain roles in the performance. As soon as either all roles have been filled with participants or a defined login time has elapsed, the logon process is ended and possibly unoccupied roles are filled by avatars (indicated at 24).
  • the authorization server 19 sends a so-called asset description to the synchronization server 20, this asset description containing information about the media data needed for the scheduled times of the performance.
  • the synchronization server 20 uses this asset description from the media server 18 to request corresponding data such as, for example, scene images (indicated at
  • the organization of the data provision also includes a conversion into file formats optimized for fast access, for example images can be decoded and stored in the memory.
  • the synchronization server 20 sends a signal to the recording server 21, as indicated at 29, constituting live streams with participants and subsequently ⁇ HYd sends the publication addresses to the synchronization server 20th
  • the synchronization server 20 establishes the connection to the subscribers' livestreams at 30 and organizes synchronization-optimized access to the data streams.
  • the synchronization server signals the server autorisie- approximately 19 at 31 20, and that all data is provided with the synchronization (rendering) may be started the first scene.
  • the authorization server 19 starts the performance at 32 and creates at 33 the first directorial statement for the first participant.
  • the recording server provides the participants with 34 live streams tailored to their respective participants, which they need to present their respective scene.
  • Fig. 3 shows schematically the processes in the representation of a scene. The interaction between Authorization Server 19 and Synchronization Server 20 is shown.
  • Authorization server 19 sends a commit command at 35 which causes the elements associated with that scene, as well as the scene set up, to be determined and provided at 36 using the XML file of the performance.
  • the scene description thus generated is transmitted to the synchro ⁇ tion server 20 at 37th
  • the synchronization server 20 builds a so-called scene graph from the transmitted description of the scene (reference numeral 38) or changes an existing scene graph accordingly.
  • the scene graph contains the logical description of all audiovisual elements (assets) of a scene, including all the attributes relevant to the presentation. These include visual assets include the position, size and definition of JE element within the scene to be created, for Audi ⁇ oassets includes information on volume and balance.
  • the position of the visual asset in the scene graph describes its image plane within the image to be generated. In ei ⁇ nem scene image, any image planes can be stacked used to produce the desired scene image.
  • the arrangement of the pixels takes place in Koor ⁇ dinatensystem the Zielressmatrize, ie the At ⁇ tribute of assets in the scene graph are image size relative to the total and are applied like this.
  • the image data used include not only information for the colors red, green and blue and transparency values for a Alphaka ⁇ nal. This alpha channel may already be included in the transferred image material or generated by computation during image synthesis.
  • the image data of Mitspie ⁇ ler be treated in this process like the rest of the assets based on their attributes in the scene graph.
  • Discrete audio assets are processed according to their attributes by means of a so-called sequencer and with the audio data the video tracks - if available - merged into a separate audio track.
  • Changes in the scene graph are initiated by the synchronization server.
  • the relevant change can already be pre-chached, but is only carried out by a kon ⁇ cretes signal from the synchronization server.
  • the data to be changed can also be sent by the synchronization server.
  • ge ⁇ maximum flexibility of the scene structure and process design.
  • the image synthesis is thus controlled by a triggered by Synchronisati ⁇ onsserver scene graph change, ie, all belonging to a scene assets and AttributeDescriptor ⁇ bute are drawn picture just after change in the scene graph.
  • Synchronisati ⁇ onsserver scene graph change ie, all belonging to a scene assets and AttributeDescriptor ⁇ bute are drawn picture just after change in the scene graph.
  • unavoidable temporal Va ⁇ rianzen (latencies) result in sending and receiving the video streams of the other players.
  • a trigger represents the word “stop” in the fictitious role 1 at a defined position on the time axis of a piece and is connected to the insertion ei ⁇ ner special request to participant 2, which occupies the role 2.
  • Participants 1 which has occupied role 1, says “Halt”, the system recognizes the keyword, the trigger is triggered and sent to the synchronization server.
  • attendee 1 has said "stop”
  • attendee 2 will not have received that word yet, and it may take several seconds for attendee 2 to see the video image from attendee 1. Were ready to receive the handshake immediately upon receipt of the trigger -.
  • a key aspect of the proposed system is the immersive experi ⁇ tion participating in a virtual scene, for example, to be used for more efficient learning experience or simply talking to serve. So that this experience is not endangered, a low latency between action of the players and the generated scene image is necessary. Due to technical limitations, latencies can not be completely prevented, but they can be hidden using the synchronization process.
  • the rendering client is also used on the subscriber-side system and is executed only for uninvolved viewers on an operator-side system. Both work in the same way, except that the output is different in the sense that the user side displays the scene image without detours on the local screen, while the operator side provides the generated audiovisual data as a video stream. In the latter procedure is still a time delay is added during the playout of the signal, since this must be Transko ⁇ diert ships and on the Internet turn first. In the subscriber-side variant, the local own video image of a fellow player is displayed without perceptible delay in the scene image.
  • Synchronization is needed here in comparison with the multiple image syntheses, since each participant generates his own scene image, but a variance between the own generated image and that of the other participants arises - after all, others receive their own video stream with a time delay. If an event occurs and a trigger is sent, then the optionally optional change of the scene graph must take place temporally synchronously for all rendering clients. For this purpose, the above-mentioned delay is used on the basis of the measured latencies. These measures allow a more homogeneous gaming experience compared to a non-synchronized system.
  • the authorization server 19 waits for the length of a scene defined during the performance of the performance. During this period, the participant or participants can play the corresponding scene.
  • the synchronization server 20 continuously generates the audiovisual files for presentation of the scene.
  • the Au ⁇ torkiesserver waiting for a signal or trigger from each operating participant that he has finished his scene and its role within the scene.
  • the authorization server 19 transmits a corresponding signal to the synchronization server 20 which ends the scene. This signal can announce either a new scene or the end of the performance.
  • the synchronization server 20 receives this signal, the re ⁇ cursive process 39 of the continuous creation of scene images is stopped.
  • Fig. 4 schematically shows the preferably running in Synchronisati ⁇ onsserver 20 process the so-called rendering, in which the scene graph generated from the scene description leads to a playable format audiovisual data exceeded.
  • the process starts at 43 with the Aufforde ⁇ tion for creating a scene image.
  • the scene graph contains various elements which are audio data, image data and video data in the exemplary embodiment. These elements must be joined together to form a scene image.
  • ge ⁇ checks whether the scene graph comprises further elements. If this is the case, branching takes place at 45, depending on the type of element. If it is an audio item, it will continue playing or replaying at 46.
  • An ⁇ other conceivable variants of a filter are, for example, exemptions of image content of a participant in order to fit these exempt images in the overall picture of a scene can. Such exemption filters may include pattern recognition such as face recognition.
  • the generated data of the bitmap is stored in a matrix (reference numeral 50). It is a three-dimensional matrix in which the various bit maps ⁇ applied to the superimposed images of a scene image are stored.
  • the process branches off at 44 to the process shown at 52, in which the three-dimensional matrix with the image data is rendered into a flat single image. This finished scene image is displayed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Educational Administration (AREA)
  • Educational Technology (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Gegenstand der Erfindung ist ein System zum interaktiven Aufführen einer Darstellung auf einer virtuellen Bühne.Betreiberseitig ist ein Datenverarbeitungssystem(Core) vorhanden mit einem Medienserver (18), der die Mediendaten einer Aufführung enthält; einem Autorisierungsserver (19), der Teilnehmern anhand eines Zeitplans Mediendaten umfassend Szenenbilder, Ablaufsteuerungs-und Regieanweisungen übermittelt; einem Synchronisationsserver (20), der Mediendaten von dem Medienserver (18)und von Teilnehmern zeitlich synchronisiert zusammenführt; und einem Aufzeichnungs- server (21), der synchronisierte Mediendaten von dem Medienserver (18)und von Teilnehmern aufzeichnet und Teilnehmern als Videostream und/oder Videodatei zugänglich macht. Teilnehmerseitig ist ein Datenverarbeitungssystem (Client) vorhanden mit Einrichtungen zur Aufzeichnung und Wiedergabe von Video-und Audiodaten; einem Streaming-Client, der zur Wiedergabe von Mediendaten umfassend Szenenbilder und Regieanweisungen des Autorisierungsservers (19) ausgebildet ist; sowie einem Media-Client, der zur Übermittlung von Video-und Audiodaten an den Synchronisationsserver (20)ausgebildet ist.

Description

System zum interaktiven Aufführen einer Darstellung auf einer virtuellen Bühne
Die Erfindung betrifft ein System zum interaktiven Aufführen einer Darstellung auf einer virtuellen Bühne. Die Online-Zusammenarbeit oder das Online-Zusammenspielen mehre¬ rer Akteure auf einer gemeinsamen elektronischen Plattform ist aus offenkundiger Vorbenutzung bekannt. Beispielsweise offenbart WO/67759 AI ein System, in dem verschiedene räum¬ lich getrennte Benutzer in einem eigenen virtuellen Raum als Schauspieler bzw. Akteure handeln und die Art ihrer Darstellung unabhängig bestimmen können.
Es ist Aufgabe der vorliegenden Erfindung, ein System der eingangs genannten Art zu schaffen, das eine virtuelle Auf¬ führung einer Darstellung wie beispielsweise einem Theaterstück mit mehreren räumlich voneinander entfernten Teilnehmern ermöglicht.
Gelöst wird diese Aufgabe durch ein System zum interaktiven Aufführen einer Darstellung auf einer virtuellen Bühne, das aufweist : a. betreiberseitig ein Datenverarbeitungssystem
(Core) mit: i. einem Medienserver, der die Mediendaten einer Aufführung enthält, ii. einem Autorisierungsserver, der Teilnehmern anhand eines Zeitplans Mediendaten umfassend Szenenbilder, Ablaufsteuerungs- und Regieanweisungen übermittelt, iii. einen Synchronisationsserver, der Mediendaten von dem Medienserver und von Teilnehmern zeitlich synchronisiert zusammenführt, iv. einen AufZeichnungsserver, der synchronisierte Mediendaten von dem Medienserver und von Teilnehmern aufzeichnet und Teilnehmern als Videostream und/oder Videodatei zugänglich macht, teilnehmerseitig ein Datenverarbeitungssystem (Client) mit: i. Einrichtungen zur Aufzeichnung und Wiedergabe von Video- und Audiodaten, ii. einem Streaming-Client, der zur Wiedergabe von Mediendaten umfassend Szenenbilder und Regieanweisungen des Autorisierungsservers ausgebildet ist, iii. einem Media-Client, der zur Übermittlung von Video- und Audiodaten an den Synchronisati¬ onsserver ausgebildet ist. Zunächst seien einige im Rahmen der Erfindung verwendete Begriffe erläutert. Eine Darstellung im Sinne der Erfindung ist beispielsweise ein Theaterstück, ein Rollenspiel (bei¬ spielsweise auch im Rahmen von Lernprogrammen) oder der- gleichen. Eine interaktive Aufführung bedeutet, dass die
Teilnehmer der Aufführung darauf innerhalb eines vorgegebe¬ nen Rahmens Einfluss nehmen können, dieser kann umfassend sein oder sich beispielsweise darauf beschränken, dass ein Teilnehmer durch den Abschluss eines bestimmten Beitrags bzw. einer Darbietung den Fortgang der Aufführung triggert bzw. die Darbietung eines weiteren Teilnehmers initiiert o-
Teilnehmer im Sinne der Erfindung sind passive Konsumenten bzw. bevorzugt aktiv Beitragende zu der Aufführung.
Eine virtuelle Bühne ist eine Bühne, auf der die Beiträge verschiedener Teilnehmer zusammengeführt und in einen Rahmen wie beispielsweise ein Bühnenbild oder dergleichen ein- gepasst werden. Die Darstellung bzw. Aufführung auf der virtuellen Bühne ist für Teilnehmer oder für Dritte sichtbar bzw. wahrnehmbar.
Der Betreiber stellt das erfindungsgemäße System Teilneh- mern zur Verfügung. Er enthält ein als Core bezeichnetes
Datenverarbeitungssystem, das vier unten erläuterte Server beinhaltet. Der Begriff Server ist in diesem Kontext funktional zu verstehen und bezeichnet Rechnereinheiten oder Rechnerteile, die die beschriebenen Funktionen auszuführen in der Lage sind.
Der Medienserver enthält die Mediendaten einer Aufführung. Es handelt sich um diejenigen Daten, die den vorgegebenen Rahmen beispielsweise eines Theaterstücks abstecken und de¬ finieren. Es handelt sich dabei um die Multimedia-Daten einer Inszenierung sowie Daten für deren zeitliche Steuerung. Darunter fallen beispielsweise Bühnenbilder, zugehörige Au- dio, Bild- und/oder Videodateien, Regieanweisungen für
Teilnehmer, Einsatzsignale, die einzelnen Teilnehmern anzeigen, wann deren Beitrag bzw. Darstellung zu beginnen hat und dergleichen. Der Medienserver enthält somit diejenigen Daten, die Struktur und bestimmte Teile einer Aufführung wie insbesondere beispielsweise die Bühnengestaltung vorge¬ ben .
Der Autorisierungsserver übermittelt Teilnehmern anhand eines Zeitplans (ein vom Medienserver stammender Zeitplan, der die Struktur bzw. Gestaltung der Aufführung vorgibt) Mediendaten umfassend Szenenbilder, Ablaufsteuerungs- und Regieanweisungen. Die Szenenbilder zeigen den Teilnehmern beispielsweise den Hintergrund oder das Bühnenbild, vor dem sie ihre Darstellung präsentieren sollen. Ablaufsteuerungs- signale geben beispielsweise Beginn und vorgesehenes Ende einer Darstellung vor. Regieanweisungen können Anweisungen zum vorgegebenen Inhalt einer vom Teilnehmer geforderten Darstellung enthalten. Der Synchronisationsserver führt Mediendaten von dem Medienserver und von Teilnehmern zeitlich synchronisiert zusammen. Zeitlich synchronisiert bedeutet, dass die Darstellun¬ gen der Teilnehmer und damit die entsprechenden Mediendaten so in die vorgegebenen Mediendaten des Medienservers (bei- spielsweise das Bühnenbild) eingefügt werden, dass ein ko¬ härenter und in sich geschlossener Ablauf der Aufführung entsteht. Der Synchronisationsserver kann gemäß einem vorteilhaften Aspekt der Erfindung insbesondere den zeitlichen Ablauf der Aufführung (ggf. innerhalb vorgegebener Grenzen) an die Darstellung der Teilnehmer anpassen und somit dafür sorgen, dass beispielsweise ein neues Bühnen- bzw. Szenenbild erst dann beginnt, wenn ein Teilnehmer seine vorherige Darstellung tatsächlich abgeschlossen hat.
Der Aufzeichnungsserver zeichnet die synchronisierten Mediendaten vom Medienserver und den Teilnehmern auf und macht sie Teilnehmern und/oder ggf. unbeteiligten Dritten als Vi- deostream (in der Regel inkl. Audio) oder Videodatei zu¬ gänglich .
Die Erfindung erlaubt es, dass eine Mehrzahl von räumlich entfernten Teilnehmern gemeinsam an einer Aufführung mit- wirken und sich dabei auf einer gemeinsamen virtuellen
Bühne befinden. Eine gemeinsame und kohärente Aufführung wird insbesondere durch den Synchronisationsserver gewährleistet, der dafür sorgt, dass die einzelnen Beiträge zu der Aufführung (die Mediendaten der Teilnehmer) zeitlich synchronisiert in die gesamte Aufführung eingepasst werden. Der Synchronisationsserver erlaubt dabei in gewissem Umfang eine zeittolerante Gestaltung dahingehend, dass beispiels¬ weise mit dem Fortgang der Aufführung gewartet wird, bis ein bestimmter Teilnehmer seine Darstellung abgeschlossen hat.
Teilnehmerseitig enthält das erfindungsgemäße System ein als Client bezeichnetes Datenverarbeitungssystem mit Einrichtungen zur Aufzeichnung und Wiedergabe von Video- und Audiodaten (Kamera, Mikrofon, Bildschirm und Lautsprecher) sowie einem Streaming-Client, der zur Wiedergabe von Medi¬ endaten ausgebildet ist. Es handelt sich dabei sowohl um Szenenbilder als auch (fakultativ) beispielsweise um Regieanweisungen oder andere Instruktionen, die den Teilnehmer beispielsweise beim Einsatz oder der Durchführung oder Gestaltung seiner Darstellung Hilfestellung leisten können. Ein weiterer Aspekt des Client ist ein Media-Client, der zur EchtZeitübermittlung von Video- und Audiodaten an den Synchronisationsserver ausgebildet ist. Dieser Media-Client übermittelt die Darstellung des Teilnehmers an das betrei¬ berseitige Datenverarbeitungssystem, dort den Synchronisa- tionsserver, der die verschiedenen Darstellungen der verschiedenen Teilnehmer dann zu einer Aufführung zusammenfügt .
Gemäß einem besonders vorteilhaften Aspekt der Erfindung sind das betreiberseitige Datenverarbeitungssystem und das teilnehmerseitige Datenverarbeitungssystem mittels einer nicht echtzeitfähigen Datenverbindung, vorzugsweise über das Internet, miteinander verbunden. Gemäß diesem besonders vorteilhaften Aspekt der Erfindung ist es Teilnehmern möglich, auf einer virtuellen Bühne gemeinsam eine Aufführung zu gestalten, ohne dass zu diesem Zweck zwischen den Teilnehmern und dem betreiberseitigen Datenverarbeitungssystem aufwendige echtzeitfähige Daten- Verbindungen bestehen müssen. Der Synchronisationsserver erlaubt durch seine beschriebene, in gewissem Umfang beste¬ hende Zeittoleranz auch, dass beispielsweise durch Latenzen bei der Internetübertragung verursachte Verzögerungen ausgeglichen werden.
Gemäß einem weiteren besonders vorteilhaften Aspekt der Erfindung überträgt der Autorisierungsserver einem Client Me- diendaten umfassend beispielsweise Szenenbilder und Regie¬ anweisungen mit einem zeitlichen Vorlauf, diese Daten werden auf dem Client gespeichert („precached" ) vorgehalten. Diese Übermittlung mit zeitlichem Vorlauf und die Zwischen- speicherung auf dem Client erlaubt es, vorhandene Latenzen beispielsweise in einer nicht echtzeitfähigen Internetumge¬ bung weitgehend bzw. vollständig auszugleichen.
Gemäß einer weiteren Ausführungsform der Erfindung sind Core und Client über zwei virtuelle Kanäle miteinander ver¬ bunden, von denen der erste Kanal zur Übermittlung zeitkritischer Information und der zweite Kanal zur weniger zeitkritischen Datenübertragung ausgebildet ist. Der erste Kanal kann erfindungsgemäß bevorzugt zur Übermittlung von Be- fehlen oder Handlungsaufforderungen („request") vom Autori- sierungsserver an den Client ausgebildet sein. Der Begriff Befehl oder Handlungsaufforderung ist im Rahmen der Erfindung weit zu verstehen und umfasst sowohl Anweisungen an den Client als auch konkrete Handlungsaufforderungen an den agierenden Teilnehmer. Interne Befehle oder Anweisungen an den Client können beispielsweise eine zeitliche Steuerung der Darstellung von vorgespeicherten (precached) Inhalten auf dem Bildschirm des Client sein. Gemäß diesem Aspekt der Erfindung können über den ersten Kanal insbesondere wenig datenintensive, aber dafür zeitkritische Daten übertragen werden. Die geschilderte Handlungsaufforderung („request") ist beispielsweise eine solche zeitkritische Information. Kommt es beispielsweise durch Verzögerungen in den Darstel¬ lungen der Teilnehmer oder Latenzen bei der Datenübertra- gung zu einer zeitlichen Verzögerung im Ablauf der Aufführung, muss einem nachfolgenden Teilnehmer sein Signal zum Einsatz (Handlungsaufforderung) in Echtzeit oder ohne nachteilig auffallende Verzögerung übermittelt werden können, damit seine Darstellung nahtlos an das Ende einer vorlau¬ fenden Darstellung anschließen kann. Eine solche Handlungsaufforderung kann nicht precached werden, da sie erst dann abgeschickt werden kann, wenn die vorlaufenden Teile der Aufführung abgeschlossen sind. Die erfindungsgemäße Gestal¬ tung mit zwei virtuellen Kanälen erlaubt es, solche zeit¬ kritischen, wenig datenintensiven Informationen wie beispielsweise die genannten Handlungsaufforderungen im Wesentlichen in Echtzeit zu übermitteln.
Bevorzugt wird zwischen dem teilnehmerseitigen System (Client) und dem betreiberseitigen System (Core) permanent eine Verbindung vorgehalten. Beispielsweise kann hierfür das Co- met-Webapplikationsmodell verwendet werden (http://en.wi- kipedia . org/wiki/Comet_ (programming) ) . Comet ist ein
Webapplikationsverfahren, bei dem ein Webserver Daten zu einem Web-Browser pusht, ohne dass der Browser diese Daten explizit angefordert hat. Im Detail wird hierfür die Eigen¬ heit des HTTP-Protokolls genutzt, Verbindungsanfragen bis zu einer gewissen Zeit aufrecht zu erhalten, bis sie auto¬ matisch geschlossen werden. Üblicherweise wird bei einer Anfrage erst die Verbindung aufgebaut und danach direkt die Daten versendet. Somit muss die für den Verbindungsaufbau benötigte Zeit stets mit einkalkuliert werden. Erfindungs- gemäß wird der Verbindungsaufbau zu einem Zeitpunkt ausge¬ führt (beziehungsweise erneuert nach Ablauf der Verbin¬ dungszeit) , an dem keine Daten zu senden sind. Das Senden eines Signals für das Ende der Darstellung eines Teilnehmers schließt diese offene Verbindung augenblicklich.
Trifft dieses Signal beim Core ein, sendet dieser nun auf einer ebenfalls permanent offenen Verbindung das Signal für den nächsten Handlungseinsatz an den nächsten Teilnehmer, der nun an der Reihe ist. Das führt dazu, dass dieser schon zum tatsächlichen Ende des Einsatzes des zuvor agierenden Teilnehmers darüber informiert wird, dass er nun als nächs¬ tes „dran" ist. Um für ein weiteres Signal empfangsbereit zu sein, wird nun sofort eine andere Verbindung zwischen Client und Core geöffnet. Durch dieses ständige Offenhalten einer Verbindung können zeitkritische Signale (Trigger, re- quests) , die das Ende einer Darstellung signalisieren oder Handlungsaufforderungen für Teilnehmer sind, quasi in Echtzeit übermittelt werden. Erfindungsgemäß wird diese Form der Datenübertragung bevorzugt eingesetzt, sofern der Einsatz nicht ausgeschlossen ist, wie zum Beispiel bei der Videoübertragung selbst. In der Praxis führt das zu deutlich kürzeren menschlichen Reaktionszeiten, auch wenn die eigentliche Videoübertragung nicht beschleunigt wird. Außen- stehende Zuschauer empfinden die Aufführung durch die Beschleunigung ebenfalls natürlicher. Eine weitere Maßnahme zur Unterbindung wahrnehmbarer Zeitverzögerungen auf Seite der Teilnehmer wird durch die getrennte Behandlung der eingehenden Videodaten der anderen Teilnehmer und den eigenen bereitgestellten Videodaten ergriffen. Während die Daten anderer Teilnehmer über das Netzwerk übertragen werden, erfolgt die Einblendung des vom Teilnehmer selbst erzeugten Videobildes direkt im Client. Die nötigen Rendering- und Bildkompositionsprozesse müssen dafür zumindest für die Bildbereiche des Teilnehmers auf dem Client durchgeführt werden. Hierdurch erhöht sich natürlich die Leistungsanforderung an das teilnehmerseitige System. Da bei einer räum¬ lich verteilten Gesprächssituation kein Referenzpunkt zum tatsächlichen Verhalten der anderen Teilnehmer besteht, ist der Aufführungsverlauf nun auch visuell natürlich, man sieht sich selbst nicht um die Zeit der oben genannten Übertragungslatenzen verzögert dargestellt. Bei einer virtuellen Aufführung mit einer Mehrzahl von Teilnehmern wird es nicht immer möglich sein, verlässlich für die Besetzung aller Rollen in der Aufführung durch Teilnehmer zu sorgen. Um dennoch den Ablauf der Aufführung auch mit einer Unterzahl von Teilnehmern zu ermöglichen, können erfindungsgemäß Avatare vorgesehen sein, die nicht durch Teilnehmer besetzte Rollen der Aufführung ausfüllen. Es kann erfindungsgemäß vorgesehen sein, dass der Autori- sierungsserver innerhalb eines vorgegebenen Aktivierungs- Zeitraums zur Entgegennahme einer Mehrzahl von Client-
Ready-Signalen ausgebildet ist. Innerhalb dieses Aktivie¬ rungszeitraums können sich Teilnehmer für die verschiedenen Rollen der Aufführung anmelden. Nach Ablauf des Aktivierungszeitraums werden noch offene Rollen der Darstellung durch Avatare besetzt, so dass die Aufführung dann mit ei¬ ner vollständigen Rollenbesetzung beginnen kann. Der Synchronisationsserver ist bevorzugt zum zeittoleranten As- sembling und zur zeittoleranten Synchronisation der Mediendaten von dem Medienserver und von Teilnehmern ausgebildet. Dies erlaubt das Zusammenführen der genannten Daten zu einer geschlossenen Aufführung mit nahtlos aneinander schließenden Handlungen bzw. Darstellungen.
Der Synchronisationsserver ist dabei bevorzugt beim Assemb- ling zur Reaktion auf ein Teilnehmerverhalten ausgebildet. Dieses zu analysierende Teilnehmerverhalten kann beispiels¬ weise teilnehmerinitiierte Trigger (beispielsweise Beginn und Ende einer Darstellung oder dergleichen) Analyse des vom Client übermittelten Audio- und/oder Videosignals und/oder Worterkennung umfassen. Beispielsweise kann dann auch auf bestimmte erkannte Stichworte hin ein Zusammenfüh¬ ren mit anderen Mediendaten beginnen bzw. andere Mediendaten einsetzen. Die Mediendaten enthalten bevorzugt einen Ablaufplan, die handelnden Personen und szenische Bestandteile, die mit elektronischen Attributen versehen sind.
Der Aufzeichnungsserver kann zum Zugänglichmachen der synchronisierten Mediendaten in Echtzeit ausgebildet sein, so dass Dritte die virtuelle Aufführung live verfolgen können. Er kann alternativ oder zusätzlich die virtuelle Aufführung speichern und für Teilnehmer oder Dritte als gespeicherte Audio- und/oder Videodatei zugänglich machen.
Die Ablaufsteuerung kann erfindungsgemäß in einem kompakten, maschinenlesbaren Format wie beispielsweise im
JSON(Java Script Object Notation) -Format oder XML-Format programmiert sein.
Ein Ausführungsbeispiel der Erfindung wird nachfolgend an¬ hand der Zeichnungen beschrieben. Es handelt sich um Ab- laufschemen eines erfindungsgemäßen Systems, das der Übersichtlichkeit halber lediglich zwei Teilnehmer aufweist. In der Zeichnung zeigen:
Fig. 1 a-c: Schematisch den Ablauf einer interakti- ven Aufführung unter Verwendung eines erfindungsgemäßen Systems;
Fig. 2 a-d: Schematisch die Initialisierung einer
Aufführung;
Fig. 3 a und b: Schematisch die Vorgänge bei der Darstellung einer Szene; Fig. 4: Schematisch das Rendering von Audio- und
Videodaten .
Fig. 1 zeigt schematisch eine Abfolge von Ereignissen bei einer interaktiven Aufführung, an der ein betreiberseitiges Datenverarbeitungssystem (Core) und zwei Teilnehmer mit den jeweiligen Clients beteiligt sind. In der Figur verläuft die Zeitachse des Verlaufs der Aufführung von links nach rechts .
Zunächst erfolgt bei 4 eine Initialisierung der Aufführung, in deren Verlauf sich die beiden Teilnehmer am Core anmelden. Sobald die Anmeldung der Teilnehmer erfolgt ist, kann der Core bei 5 einen Einsatzbefehl an den Teilnehmer 1 sen- den, so dass dieser seinen ersten Part in der Aufführung beginnen kann. Um die Übermittlung dieses zeitkritischen Einsatzbefehls in Echtzeit oder wenigstens ohne maßgebliche Verzögerung zu ermöglichen, erfolgt dies in der geschilderten Weise über eine zuvor geöffnete und offen gehaltene Verbindung zwischen dem Core und dem Client 1 beispiels¬ weise mittels des Comet-Webapplikationsmodells. Der Teil¬ nehmer 1 spielt seine vorgegebene Rolle, wie bei 6 angedeu¬ tet. Der Teilnehmer 2 befindet sich gleichzeitig im Warte¬ zustand. Der Core empfängt die Daten der vom Teilnehmer 1 gespielten Rolle über einen in der Figur nicht dargestellten Datenübertragungskanal (dieser umfasst Videodaten und arbeitet daher nicht notwendigerweise in Echtzeit) und fügt sie mit weiteren Daten vom in der Zeichnung ebenfalls nicht dargestellten Medienserver zu einer vollständigen Szene zu- sammen, wie bei 8 angedeutet. Sobald der Teilnehmer 1 den entsprechenden Part seiner Rolle beendet hat, kann dies der Client 1 entweder selbst ständig erkennen (beispielsweise durch Erkennung des akustischen Endes der Rolle) , oder der Teilnehmer 1 übermittelt aktiv ein Signal, dass sein Part beendet ist. Dieses Signal über das Ende des Einsatzes wird, wie bei 7 angedeutet, vom Client 1 an den Core über¬ mittelt. Nach Beendigung der Szene des Teilnehmers 1 sendet der Core einen Einsatzbefehl (angedeutet bei 9) an den
Teilnehmer 2, der daraufhin in gleicher Art und Weise seine Rolle spielt, die der Core mit weiteren Mediendaten zu ei¬ ner Szene zusammenfügt. Nach Beendigung des Einsatzes des Teilnehmers 2 wird das entsprechende Signal bei 10 an den Core übermittelt.
Im weiteren zeitlichen Ablauf dieser Figur wird eine Variante gezeigt, bei der der Teilnehmer 1 den Handlungsablauf beeinflussen kann. Zu diesem Zweck sendet der Core an den Teilnehmer 1 bei 11 eine Frage bzw. Aufforderung zu einer Entscheidung. Der Teilnehmer 1 trifft eine entsprechende Entscheidung und übermittelt diese bei 12 zurück an den Core. Abhängig von dieser Entscheidung trifft der Core bei 13 eine Auswahl aus zwei zur Verfügung stehenden Optionen für den weiteren Verlauf der Aufführung. In der ersten Variante wird bei 14 eine Aufforderung zur Darstellung einer Szene an den Teilnehmer 1 gesendet, in der zweiten Variante bei 15 eine entsprechende Handlungsaufforderung an den Teilnehmer 2.
Bei Abschluss einer Aufführung sendet der Core bei 17 ein entsprechendes Abschlusssignal an die Teilnehmer 1 und 2, die Aufführung ist daraufhin beendet. Die Aufführung kann im Rahmen der Erfindung live Dritten zur Verfügung gestellt werden, sie kann alternativ oder zusätzlich gespeichert und von den Teilnehmern oder Dritten zeitverzögert betrachtet werden . Fig. 2 zeigt schematisch die Vorgänge bei der Initialisie¬ rung einer Aufführung. Schematisch dargestellt sind hier die Abläufe im Core-System mit dem Medienserver 18, dem Autorisierungsserver 19, dem Synchronisationsserver 20 und dem AufZeichnungsserver 21.
Zu Beginn einer Aufführung lädt der Autorisierungsserver 19 einen Ablauf der vorgesehenen Aufführung, im Ausführungsbeispiel ist dies eine XML-Datei. In der Figur ist dies bei 22 angedeutet. Die Datei enthält den Ablaufplan und die handelnden Personen sowie szenische Bestandteile elektro¬ nisch attributiert und strukturiert.
Im ersten Schritt eröffnet der Autorisierungsserver 19 den Zugang für die Anmeldung von Teilnehmern. Wie bei 23 angedeutet werden Anmeldungen von Teilnehmern entgegengenommen und die Teilnehmer werden bestimmten Rollen in der Aufführung zugeordnet. Sobald entweder alle Rollen mit Teilnehmern besetzt sind oder aber ein festgelegter Anmeldezeit- räum verstrichen ist, wird der Anmeldevorgang beendet und gegebenenfalls nicht besetzte Rollen werden durch Avatare besetzt (angedeutet bei 24).
Bei 25 sendet der Autorisierungsserver 19 eine so genannte Assetbeschreibung an den Synchronisationsserver 20, diese Assetbeschreibung enthält Informationen über die Mediendaten, die für die vorgesehenen Zeiten der Aufführung benötigt werden. Der Synchronisationsserver 20 fordert anhand dieser Assetbeschreibung vom Medienserver 18 entsprechende Daten wie beispielsweise Szenenbilder an (angedeutet bei
26), empfängt diese aus dem Datenspeicher des Medienservers 18, wie bei 27 angedeutet und organisiert die Datenvorhal¬ tung (siehe Bezugsziffer 28). Zur Datenvorhaltung gehört auch die Übermittlung beispielsweise von Mediendaten umfassend Szenenbilder, Ablaufsteuerungs- und Regieanweisungen an die Clients der Teilnehmer, die gegebenenfalls auf dem entsprechenden Client precached vorgehalten werden können, und entsprechend dem Ablauf der Aufführung zum Einsatz kommen können, ohne dass größere Datenmengen mit diesen Mediendaten in Echtzeit übermittelt werden müssen. Die Details der Organisation dieser Datenvorhaltung sind in der Figur nicht dargestellt.
Zu der Organisation der Datenvorhaltung gehört auch eine Umwandlung in für den schnellen Zugriff optimierte Dateiformate, beispielsweise können Bilder decodiert und im Speicher abgelegt werden.
Anschließend sendet der Synchronisationsserver 20 ein Signal an den AufZeichnungsserver 21, der, wie bei 29 angedeutet, Livestreams mit den Teilnehmern aufbaut und anschlie¬ ßend deren Publikationsadressen an den Synchronisationsser- ver 20 sendet. Der Synchronisationsserver 20 baut bei 30 die Verbindung zu den Livestreams der Teilnehmer auf und organisiert einen für die Synchronisation optimierten Zugriff auf die Datenströme. Sobald die Datenvorhaltung orga¬ nisiert und Verbindungen zu den Livestreams aufgebaut sind, signalisiert der Synchronisationsserver 20 dem Autorisie- rungsserver 19 bei 31, dass alle Daten bereitgestellt sind und mit der Synchronisation (Rendering) der ersten Szene begonnen werden kann. Der Autorisierungsserver 19 startet bei 32 die Aufführung und erstellt bei 33 die erste Regie- anweisung für den ersten Teilnehmer. Der Aufzeichnungsser- ver stellt den Teilnehmern bei 34 auf dem jeweiligen Teilnehmer zugeschnittene Livestreams zur Verfügung, die sie für die Darstellung ihrer jeweiligen Szene benötigen. Fig. 3 zeigt schematisch die Vorgänge bei der Darstellung einer Szene. Dargestellt werden das Zusammenwirken von Au- torisierungsserver 19 und Synchronisationsserver 20.
Der Autorisierungsserver 19 sendet bei 35 einen Einsatzbefehl, der bewirkt, dass bei 36 anhand der XML-Datei der Aufführung die zu dieser Szene gehörenden Elemente sowie der Szenenaufbau ermittelt und bereitgestellt werden. Die so erstellte Szenenbeschreibung wird bei 37 an den Synchro¬ nisationsserver 20 übermittelt. Der Synchronisationsserver 20 baut aus der übermittelten Beschreibung der Szene einen so genannten Szenengraph auf (Bezugsziffer 38) bzw. verändert einen bereits vorhandenen Szenengraph entsprechend.
Der Szenengraph beinhaltet die logische Beschreibung aller audiovisuellen Elemente (Assets) einer Szene inklusive al¬ ler darstellungsrelevanten Attribute. Hierzu zählen für visuelle Assets u.a. die Positions-, und Größendefinition je- des Elementes innerhalb der zu erzeugenden Szene, für Audi¬ oassets u.a. Informationen über Lautstärke und Balance. Die Position des visuellen Assets im Szenengraphen beschreibt seine Bildebene innerhalb des zu erzeugenden Bildes. In ei¬ nem Szenenbild können beliebige Bildebenen übereinander verwendet werden um das gewünschte Szenenbild zu erzeugen.
Aus diesem Szenengraph wird bei 39 mittels rekursivem
Durchlauf über alle enthaltenen audiovisuellen Elemente ein Szenenbild erzeugt. Dieser Vorgang wird kontinuierlich bis zu 60-mal pro Sekunde wiederholt, um aus diesen Szenenbil¬ dern eine fortlaufende Szene einschließlich der zugehörigen Audiodatei sichtbar und hörbar zu machen. Die aus dem Szenengraph resultierende Darstellung der Einzelbilder der Szene wird durch Bildsynthese erzeugt. Von jedem zur Anwendung kommenden Asset wird pro Bildgenerie- rung ein Einzelbild dekodiert und der Synthese bereitge- stellt. Die Synthese findet durch den Renderingclient statt. Hierfür werden die dekodierten und optional manipu¬ lierten Bilddaten der Assets entsprechend ihrer Attribute im Szenengraph in die Bildmatrize des zu erstellenden Szenenbildes eingefügt. Zur Feststellung der tatsächlich zur Anwendung kommenden Bilddaten (Pixel) wird mittels einer Verdeckungsberechnung eine Abtastung nach Ebenenüberlagerung durchgeführt. Die Anordnung der Pixel findet im Koor¬ dinatensystem der Zielbildmatrize statt, d.h. dass die At¬ tribute der Assets im Szenengraphen relativ zur Gesamt- bildgröße stehen und so angewendet werden. Die verwendeten Bilddaten beinhalten neben den Informationen für die Farben Rot, Grün und Blau auch Transparenzwerte für einen Alphaka¬ nal. Dieser Alphakanal kann bereits in dem übertragenen Bildmaterial enthalten sein oder durch Berechnung während der Bildsynthese erzeugt werden. Die Bilddaten der Mitspie¬ ler werden in diesem Prozess genau wie die übrigen Assets anhand ihrer Attribute im Szenengraphen behandelt.
Mit der Ebenenzuordnung jedes Assets und den Transparenz- werten werden mittels Alpablending aus einzelnen Assets vollständig neue Szenenbilder zusammengesetzt. Die Abbil¬ der der Mitspieler sind dadurch ähnlich einer automatisierten Fotomontage in ein Szenenbild einer neuen virtuellen Umgebung integriert.
Diskrete Audioassets werden gemäß ihrer Attribute mittels eines sog. Sequenzers verarbeitet und mit den Audiodaten der Videospuren - sofern vorhanden - in einer gesonderten Audiospur zusammengeführt.
Veränderungen im Szenengraphen werden durch den Synchroni- sationsserver eingeleitet. Die maßgebliche Veränderung kann bereits pre-chached sein, wird jedoch erst durch ein kon¬ kretes Signal vom Synchronisationsserver durchgeführt. Alternativ können auch die zu verändernden Daten vom Synchronisationsserver übersendet werden. Somit ist eine maximale Flexibilität des Szenenaufbaus und der Ablaufgestaltung ge¬ geben .
Die Bildsynthese wird somit durch eine vom Synchronisati¬ onsserver ausgelöste Szenengraphveränderung gesteuert, d.h. sämtliche zu einer Szene gehörenden Assets und Attri¬ bute werden nach Veränderung des Szenengraphen bildgenau gezeichnet. Jedoch ergeben sich unvermeidbare zeitliche Va¬ rianzen (Latenzen) bei Versendung und Empfang der Video- streams der Mitspieler. Hier kommen die üblichen Arbeits- schritte und Verzögerungen der digitalen audiovisuellen
Kommunikation zum Tragen. Diese Daten müssen zunächst auf dem teilnehmerseitigen System aufgezeichnet und transkodiert werden, um anschließend über das Internet transpor¬ tiert werden zu können. Einflussfaktor ist in diesem Fall bereits die naturgemäß unterschiedliche Rechenleistung der teilnehmerseitigen Systeme. Des Weiteren ist der Transport über das Internet mit zeitlichen Verlusten behaftet, die je nach beim Teilnehmer vorherrschender infrastruktureller Situation stark variieren kann. Das für die Bildsynthese im Renderingclient eintreffende Signal muss dekodiert werden und weiteren optionalen Berechnungen zugeführt werden. Die Bereitstellung des fertigen Einzelbildes zur Bildsynthese des Szenenbildes, in dem die ausgeführte Handlung erfolgen soll, ist somit zeitlich verzögert gegenüber dem tatsächlichen Zeitpunkt der Ausführung des Mitspielers.
Da das System den Spielablauf dynamisch anhand von Triggern - wie z.B. durch Spracherkennung gefundene Schlüsselwörter - steuern kann, ist es nötig, dass das auf den Trigger fol¬ gende Verhalten für alle Teilnehmer konsistent ist.
Hierzu zwei Beispiel: Ein Trigger stellt das Wort „Halt" in der fiktiven Rolle 1 an einer definierten Stelle auf der Zeitachse eines Stückes dar und ist mit der Einblendung ei¬ ner speziellen Aufforderung an Teilnehmer 2, der die Rolle 2 belegt, verbunden. Teilnehmer 1, der die Rolle 1 belegt hat, sagt „Halt", das System erkennt das Schlüsselwort, der Trigger wird ausgelöst und an den Synchronisationsserver gesendet. Während der Teilnehmer 1 „Halt" gesagt hat, wird jedoch ein Teilnehmer 2 dieses Wort noch nicht empfangen haben. Es können unter Umständen mehrere Sekunden vergehen, bis Teilnehmer 2 das Videobild von Teilnehmer 1 sieht. Wäre sofort nach Erhalt des Triggers die Aussendung der Hand- lungsanweisung für Teilnehmer 2 erfolgt, würde diese für ihn zusammenhangslos erscheinen. Stattdessen ermittelt der Synchronisationserver die Latenzen zwischen den Teilnehmern und verzögert die Anweisung für alle Teilnehmer bis die Vi¬ deodaten von Teilnehmer 1 bei Teilnehmer 2 eingetroffen sind. Um ein für alle Teilnehmer wie auch Zuschauer einheitliches Seherlebnis zu erreichen, müssen die Zeitpunkte, an denen das Trigger-auslösende Ereignis beim Teilnehmer stattfindet, mit der zeitliche verzögerten Bildsynthese synchronisiert werden. Damit die Anweisung selbst nicht den Latenzen im Internet unterliegt, wird für diesen Anwen¬ dungsfall ein offener Kanal zwischen einem Client und dem Synchronisationserver gehalten, der für jene zeitkritische Informationen dient. Mit dieser Methode ist es auch möglich Teilnehmer 2 schon vorab einen optionalen Hinweis zu übermitteln, das es einen Trigger gab. Somit sind verschiedene Möglichkeiten geschaf¬ fen, den Spielverlauf für die Mitspieler vorteilhaft zu steuern und für jeden Betrachter einheitlich darzustellen, ohne dass diese durch die Latenzen der Videodatenübertra¬ gung eingeschränkt werden.
Der Mensch ist in der Lage bereits zeitliche Verzögerungen von wenigen Millisekunden wahrzunehmen. Ein wesentlicher Aspekt des vorgestellten Systems ist die immersive Erfah¬ rung einer Teilnahme in einer virtuellen Szene, die z.B. zur effizienteren Lernerfahrung genutzt werden soll, oder schlicht der Unterhaltung dienen soll. Damit diese Erfah- rung nicht gefährdet ist, ist eine niedrige Latenz zwischen Handlung der Mitspieler und dem erzeugten Szenenbild nötig. Durch technische Einschränkungen lassen sich Latenzen nicht völlig verhindern, jedoch lassen sich diese mittels des Synchronisationsverfahren verstecken .
Vorzugweise kommt der Renderingclient auch auf dem teilneh- merseitigen System zum Einsatz und wird nur für unbeteiligte Zuschauer auf einem betreiberseitigen System ausgeführt. Beide arbeiten nach der gleichen Funktionsweise, le- diglich die Ausgabe ist in dem Sinne unterschiedlich, dass das Teilnehmerseitige das Szenenbild ohne Umwege auf dem lokalen Bildschirm zur Anzeige bringt, während das Betrei- berseitige die erzeugten audiovisuellen Daten als Video- stream zur Verfügung stellt. Im letzteren Verfahren kommt noch eine zeitliche Verzögerung während der Ausspielung des Signals hinzu, da dieses Bild zunächst wiederum transko¬ diert und über das Internet versendet werden muss. In der teilnehmerseitigen Variante wird das lokale eigene Videobild eines Mitspielers ohne wahrnehmbare Verzögerung im Szenenbild dargestellt. Synchronisation ist hier gegenüber den mehrfach stattfindenden Bildsynthesen nötig, da jeder Teilnehmer so sein eigenes Szenenbild erzeugt, jedoch eine Varianz zwischen dem eigenen erzeugten Bild und dem der anderen Teilnehmer entsteht - schließlich erhalten andere den eigenen Videostream mit zeitlicher Verzögerung. Erfolgt nun ein Ereignis und ein Trigger wird versendet, so muss die daraufhin optionale Veränderung des Szenengraphen für alle Renderingclients zeitlich synchron stattfinden. Hierfür kommt die o.g. Verzögerung anhand der gemessenen Latenzen zur Anwendung. Durch diese Maßnahmen ist ein homogeneres Spielerlebnis im Vergleich zu einem System ohne Synchronisation ermöglicht.
Der Autorisierungsserver 19 wartet die im Ablauf der Aufführung definierte Länge einer Szene ab. In diesem Zeitraum können der oder die Teilnehmer die entsprechende Szene spielen. Der Synchronisationsserver 20 erzeugt daraus kontinuierlich die audiovisuellen Dateien zur Darstellung der Szene. Innerhalb des vorgegebenen Zeitraums wartet der Au¬ torisierungsserver auf ein Signal bzw. Trigger vom jeweils agierenden Teilnehmer, dass er seine Szene bzw. seine Rolle innerhalb der Szene beendet hat. Wird dieses Signal bei 40 empfangen, übermittelt der Autorisierungsserver 19 dem Synchronisationsserver 20 ein entsprechendes Signal, das die Szene beendet. Dieses Signal kann entweder eine neue Szene oder das Ende der Aufführung ankündigen. Sobald der Synchronisationsserver 20 dieses Signal erhält, wird der re¬ kursive Vorgang 39 des fortlaufenden Erstellens von Szenenbildern gestoppt. Lässt sich ein Teilnehmer mit seiner Rolle bzw. Darstellung zu viel Zeit und beendet diese nicht in einem vorgegebenen Zeitraum zuzüglich gegebenenfalls eines Toleranzzeitraums, wird bei 41 zwangsläufig ein Signal über das Ende der Szene ausgelöst und dem Synchronisations- Server 20 übermittelt. Der Fortgang der Aufführung innerhalb des vorgegebenen Zeitrahmens und einer gewissen Tole¬ ranz wird somit sichergestellt. Sobald eine Szene abge¬ schlossen ist, wartet der Synchronisationsserver 20 bei 42 auf die Übermittlung der Beschreibung der nächsten Szene.
Fig. 4 zeigt schematisch den vorzugsweise im Synchronisati¬ onsserver 20 ablaufenden Vorgang des so genannten Renderns, bei dem die aus der Szenenbeschreibung erzeugten Szenengraphen in ein abspielbares audiovisuelles Datenformat über- führt werden. Der Vorgang startet bei 43 mit der Aufforde¬ rung zur Erstellung eines Szenenbilds. In diesem Beispiel enthält der Szenengraph verschiedene Elemente, die im Aus¬ führungsbeispiel Audiodaten, Bilddaten und Videodaten sind. Diese Elemente müssen zu einem Szenenbild zusammengefügt werden. Bei der Erstellung dieses Szenenbilds wird der Sze¬ nengraph iterativ solange durchlaufen, bis alle zugehörigen Elemente abgearbeitet worden sind. Bei 44 wird zunächst ge¬ prüft, ob der Szenengraph weitere Elemente aufweist. Ist dies der Fall, wird bei 45 je nach Typ des Elements ver- zweigt. Handelt es sich um ein Audioelement, wird es bei 46 weiter oder neu abgespielt. Es kann sich hierbei um einen komplexen Vorgang handeln, da verschiedene Audiodaten mittels eines so genannten Sequenzers gemischt bzw. vereint werden können. Gegebenenfalls können bei 47 Filter auf die Audiodaten angewendet werden, die beispielsweise einen Hal¬ leffekt oder einen sonstigen Effekt, der zu der Szene passt, hervorrufen können. Handelt es sich bei dem Elementtyp um ein statisches Bild (Image), werden die zugehörigen Bilddaten decodiert und in Form einer Bitmap bereitgestellt. Dies ist bei 48 angedeu¬ tet. Gegebenenfalls können darauf (Bezugsziffer 49) Filter wie beispielsweise Farbveränderungen angewendet werden. An¬ dere denkbare Varianten eines Filters sind beispielsweise Freistellungen von Bildinhalten eines Teilnehmers, um diese freigestellten Bilder in das Gesamtbild einer Szene einpassen zu können. Solche Filter zur Freistellung können Mus- tererkennung wie beispielsweise Gesichtserkennung beinhalten. Die erzeugten Daten der Bitmap werden in einer Matrix gespeichert (Bezugsziffer 50) . Es handelt sich um eine dreidimensionale Matrix, in der die unterschiedlichen Bit¬ maps der übereinander zu legenden Bilder eines Szenenbildes gespeichert werden.
Handelt es sich bei dem Elementtyp um Videodaten, wird bei 51 der nächste Videoframe ermittelt und anschließend wie ein statisches Bild behandelt. Wenn alle Elemente eines Szenengraphs bearbeitet wurden, wird bei 44 verzweigt zu dem bei 52 dargestellten Vorgang, bei dem die dreidimensionale Matrix mit den Bilddaten in ein flaches Einzelbild ge- rendert wird. Dieses fertige Szenenbild wird zur Anzeige gebracht .

Claims

Patentansprüche
System zum interaktiven Aufführen einer Darstellung auf einer virtuellen Bühne, das aufweist: a . betreiberseitig ein Datenverarbeitungssystem
(Core) mit: i. einem Medienserver (18), der die Mediendaten einer Aufführung enthält, ii. einem Autorisierungsserver (19), der
Teilnehmern anhand eines Zeitplans Medi¬ endaten umfassend Szenenbilder, Ablauf- steuerungs- und Regieanweisungen übermit¬ telt, iii. einen Synchronisationsserver (20), der
Mediendaten von dem Medienserver (18) und von Teilnehmern zeitlich synchronisiert zusammenführt, iv. einen AufZeichnungsserver (21), der synchronisierte Mediendaten von dem Medienserver (18) und von Teilnehmern aufzeichnet und Teilnehmern als Videostream und/oder Videodatei zugänglich macht, b . teilnehmerseitig ein Datenverarbeitungssystem
(Client) mit: i. Einrichtungen zur Aufzeichnung und Wiedergabe von Video- und Audiodaten, einem Streaming-Client, der zur Wiedergabe von Mediendaten umfassend Szenenbil der und Regieanweisungen des Autorisie- rungsservers (19) ausgebildet ist, einem Media-Client, der zur Übermittlung von Video- und Audiodaten an den Synchro nisationsserver (20) ausgebildet ist.
System nach Anspruch 1, dadurch gekennzeichnet, dass das betreiberseitige Datenverarbeitungssystem und das teilnehmerseitige Datenverarbeitungssystem mittels ei¬ ner nicht echtzeitfähigen Datenverbindung, vorzugsweise über das Internet, miteinander verbunden sind.
System nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Autorisierungsserver (19) einem Client Medien daten umfassend Szenenbilder und Regieanweisungen mit einem zeitlichen Vorlauf übermittelt und das diese Da¬ ten auf dem Client precached vorgehalten werden.
System nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass Core und Client über zwei virtuelle Kanäle miteinander verbunden sind, von denen der erste Kanal zur Übermittlung zeitkritischer Informationen und der zweite Kanal zur weniger zeitkritischen Datenübertragung ausgebildet ist.
5. System nach Anspruch 4, dadurch gekennzeichnet, dass der erste Kanal zur Übermittlung von Befehlen und/oder Handlungsaufforderungen (Requests) vom Autorisierungs- server (19) an den Client ausgebildet ist.
System nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass der Autorisierungsserver (19) inner halb eines vorgegebenen Aktivierungszeitraums zur Ent¬ gegennahme einer Mehrzahl von Client Ready Signalen ausgebildet ist und nach Ablauf des Aktivierungszeit¬ raums noch offene Rollen der Darstellung durch Avatare besetzt .
System nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass der Synchronisationsserver (20) zum zeittoleranten Assembling und Synchronisation der Medi endaten von dem Medienserver (18) und von Teilnehmern ausgebildet ist.
System nach Anspruch 7, dadurch gekennzeichnet, dass der Synchronisationsserver (20) beim Assembling zur aktion auf ein Teilnehmerverhalten ausgebildet ist.
System nach Anspruch 8, dadurch gekennzeichnet, dass die Analyse des Teilnehmerverhaltens teilnehmeriniti¬ ierte Trigger, Analyse des vom Client übermittelten Au dio- und/oder Videosignals und/oder Worterkennung um- fasst .
10. System nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die Mediendaten einen Ablaufplan, die handelnden Personen und szenische Bestandteile mit elektronischen Attributen versehen enthalten.
11. System nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass der Aufzeichnungsserver (21) zum Zugänglichmachen der synchronisierten Mediendaten in Echtzeit ausgebildet ist.
12. System nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass die Ablaufsteuerung im JSON-Format programmiert ist.
PCT/EP2014/076447 2013-12-03 2014-12-03 System zum interaktiven aufführen einer darstellung auf einer virtuellen bühne WO2015082557A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102013224785.0 2013-12-03
DE102013224785.0A DE102013224785A1 (de) 2013-12-03 2013-12-03 System zum interaktiven Aufführen einer Darstellung auf einer virtuellen Bühne

Publications (1)

Publication Number Publication Date
WO2015082557A1 true WO2015082557A1 (de) 2015-06-11

Family

ID=52023474

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2014/076447 WO2015082557A1 (de) 2013-12-03 2014-12-03 System zum interaktiven aufführen einer darstellung auf einer virtuellen bühne

Country Status (2)

Country Link
DE (1) DE102013224785A1 (de)
WO (1) WO2015082557A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11321892B2 (en) 2020-05-21 2022-05-03 Scott REILLY Interactive virtual reality broadcast systems and methods

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001067759A2 (en) 2000-03-08 2001-09-13 Eyematic Interfaces, Inc. Communication system and method including rich media tools
CA2357291A1 (en) * 2001-09-13 2003-03-13 Zoran Konjevic System and method for real-time interactive musical instruction and performance

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6409599B1 (en) * 1999-07-19 2002-06-25 Ham On Rye Technologies, Inc. Interactive virtual reality performance theater entertainment system
US20080092047A1 (en) * 2006-10-12 2008-04-17 Rideo, Inc. Interactive multimedia system and method for audio dubbing of video
US20090280897A1 (en) * 2008-01-14 2009-11-12 Simon Fitzmaurice Method and Apparatus for Producing Interactive Video Content
JP5767108B2 (ja) * 2008-07-08 2015-08-19 シーンプレイ インコーポレイテッド 媒体生成システム及び方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001067759A2 (en) 2000-03-08 2001-09-13 Eyematic Interfaces, Inc. Communication system and method including rich media tools
CA2357291A1 (en) * 2001-09-13 2003-03-13 Zoran Konjevic System and method for real-time interactive musical instruction and performance

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11321892B2 (en) 2020-05-21 2022-05-03 Scott REILLY Interactive virtual reality broadcast systems and methods

Also Published As

Publication number Publication date
DE102013224785A1 (de) 2015-06-03

Similar Documents

Publication Publication Date Title
DE60123851T2 (de) Fernsehplauderzimmer
DE10084867B4 (de) Verfahren und Vorrichtung um es einem Videokonferenzteilnehmer zu ermöglichen den zugehörigen Nutzern in der Kamera fokussiert zu erscheinen
DE60222890T2 (de) Verfahren und Vorrichtungen zur Implementerung von hochinteraktiven Unterhaltungsdiensten unter Verwendung der Medienströmungstechnologie, das die Bereitstellung auf Abstand von Virtuelle Realitätdiensten ermöglicht
US20170282075A1 (en) Methods, system and nodes for handling media streams relating to an online game
CN109327741A (zh) 游戏直播方法、装置和系统
DE112015002650B4 (de) Systeme und Verfahren zur prädiktiven Auslieferung von Inhalten mit hohen Bitraten zur Wiedergabe
DE112017005879T5 (de) Informationsverarbeitungsvorrichtung, informationsverarbeitungsverfahren und programm
EP2930926A1 (de) Verfahren, Softwareprodukt und Vorrichtung zur Steuerung einer Konferenz
DE102018007493A1 (de) Verfügbares Tonumstellen für Clientvorrichtungen auf einer Onlinekonferenz
DE102012214902A1 (de) Verfahren und System zur Live-Video-Beratung
EP3204946A1 (de) Vorrichtung zum erzeugen eines videoausgangsdatenstroms, videoquelle, videosystem und verfahren zum erzeugen eines videoausgangsdatenstroms bzw. eines videoquellendatenstroms
WO2015082557A1 (de) System zum interaktiven aufführen einer darstellung auf einer virtuellen bühne
WO2018184735A1 (de) Konzept zur virtuellen teilnahme an live-ereignissen
EP3926442A1 (de) Videokonferenzverfahren und videokonferenzsystem
CN108053487A (zh) 一种基于虚拟技术的真人参与娱乐方法和系统
EP1168829A2 (de) Verfahren zur Durchführung von Livesendungen mit Bildeinspielung
DE102022119070B3 (de) Medienwiedergabevorrichtung, Verfahren zum Betreiben einer Medienwiedergabevorrichtung und Fahrzeug
DE102017204789A1 (de) Computergestützte Erweiterung der Realitätswahrnehmung für industrielle Anwendungen
DE102023005306A1 (de) Verfahren und Fahrzeug zum Teilnehmen an Gesprächsrunden
DE102013102992A1 (de) Szenenaufbausystem und - verfahren durch Szenenausschnitte sowie deren Aufzeichnungsmedien
DE112016004480T5 (de) Synchronisierung des Renderns von Medien in heterogenen Netzwerkumgebungen
DE102021129730A1 (de) Computernetzwerksystem
WO2023134834A1 (de) Kontrollverfahren für eine kontrolle einer virtuellen podiumsdiskussion über eine kommunikationsverbindung zwischen einer vielzahl von kommunikationsteilnehmern
DE102022119188A1 (de) Informationsverarbeitungssystem und informationsverarbeitungsverfahren
EP3038319B1 (de) Kommunikationssystem für eine interaktive avatar-kommunikation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14811798

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14811798

Country of ref document: EP

Kind code of ref document: A1