DE102014012355A1

DE102014012355A1 - Verfahren zur Steuerung einer Multimedia-Anwendung, Softwareprodukt und Vorrichtung

Info

Publication number: DE102014012355A1
Application number: DE102014012355.3A
Authority: DE
Inventors: Jürgen Totzke; Karl Klug; Viktor Ransmayr
Original assignee: Unify GmbH and Co KG
Current assignee: Unify Patente GmbH and Co KG
Priority date: 2014-08-25
Filing date: 2014-08-25
Publication date: 2016-02-25
Also published as: WO2016037677A1; EP3186971A1; US10581946B2; CN106576185A; US20170272488A1

Abstract

Ein erster Gesichtspunkt der vorliegenden Erfindung betrifft ein Verfahren zur Steuerung einer Multimedia-Anwendung auf einem insbesondere mobilen Endgerät, wobei multimediale Daten von einer entfernten Quelle empfangen werden und zur Darstellung auf einer Anzeige des Endgeräts verarbeitet werden, mit den Schritten: a) Erkennen eines Betriebszustands wenigstens einer die Darstellung der Daten der multimedialen Anwendung betreffenden Servicekomponente des Endgeräts; b) Erzeugen einer den Betriebszustand der wenigstens einen Servicekomponente kennzeichnenden Zustandsinformation; c) Erzeugen einer Nachricht, umfassend: die Zustandsinformation, und/oder eine die Zustandsinformation kennzeichnende Information, welche die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten kennzeichnet, und/oder eine Anweisung an die entfernte Quelle bezüglich der Adaption der Daten und/oder Übertragung der Daten an das Endgerät, um die Daten und/oder die Übertragung der Daten an die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten anzupassen; d) Übertragen der Nachricht an die entfernte Quelle; e) Empfangen der multimedialen Daten; und f) Verarbeiten der multimedialen Daten zur Darstellung auf der Anzeige des Endgeräts. Die Erfindung betrifft auch ein Verfahren zur Anpassung und Übertragung von multimedialen Daten, ein Softwareprodukt und eine Vorrichtung.

Description

Die Erfindung betrifft Verfahren zur Steuerung einer Multimedia-Anwendung, ein Verfahren zur Anpassung und Übertragung von multimedialen Daten, ein diesbezügliches Softwareprodukt und eine diesbezügliche Vorrichtung.
Multi-mediale Kollaboration, (geschäftliche) Soziale Netzwerke, Online-Spiele und dergleichen nutzen zunehmend mehrere Kommunikations- und Datenkanäle gleichzeitig. Eine dazugehörige, neu entstehende Technologie ist WebRTC (RTC steht für Real Time Communication, also Echtzeitkommunikation). Solange genügend Bandbreite, z. B. über Festnetz, zur Verfügung steht, ist dies auch problemlos möglich. Im mobilen Internet oder WLAN (Wireless LAN) kann die Bandbreite durch das geteilte Medium und Empfangsstörungen jedoch begrenzt sein oder schwanken. Zudem haben die eingesetzten mobilen Geräte oft nur eine begrenzte Darstellungsfläche (kleines Display), die die gleichzeitig angebotenen Kommunikations- und Datenkanäle nicht mit sinnvoller Auflösung darstellen kann.
Derzeit stehen die Ressourcenverwaltung und Dienstgütebetrachtungen für derartig gebündelte multi-mediale Kommunikationsformen erst am Anfang und es gibt für das oben beschriebene Problem noch keine technische Lösung. Daher muss eine schlechte Nutzererfahrung und eine Vergeudung von Netzressourcen, deren übermittelte Inhalte gar nicht sinnvoll nutzbar sind oder genutzt werden, meist hingenommen werden.
Von Betriebssystemen wie iOS von Apple oder Android ist bekannt, dass Applikationen im Hintergrund gestoppt werden, wenn das System an Grenzen stößt. Dies ist aber eine rigorose Notlösung, die zu unerwünschtem Verhalten des Geräts führen kann.
Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren, ein Softwareprodukt und eine Vorrichtung anzugeben, die in der Lage sind, die vorstehenden Nachteile im Stand der Technik wenigstens teilweise zu überwinden. Insbesondere besteht eine Aufgabe der vorliegenden Erfindung darin, ein Verfahren, ein Softwareprodukt und eine Vorrichtung anzugeben, die in der Lage sind, verfügbare Netzbandbreiten ohne Beeinträchtigung der Nutzererfahrung optimiert zu nutzen.
Die Aufgabe wird erfindungsgemäß wenigstens in Teilaspekten durch die Merkmale der unabhängigen Ansprüche, welche Verfahren zur Steuerung einer Multimedia-Anwendung, ein Verfahren zur Anpassung und Übertragung von multimedialen Daten, ein diesbezügliches Softwareprodukt und eine diesbezügliche Vorrichtung betreffen, gelöst. Vorteilhafte Ausführungsformen und Weiterentwicklungen der Erfindung sind in den Unteransprüchen angegeben.
Ein erster Gesichtspunkt der vorliegenden Erfindung betrifft ein Verfahren zur Steuerung einer Multimedia-Anwendung auf einem insbesondere mobilen Endgerät, wobei multimediale Daten von einer entfernten Quelle empfangen werden und zur Darstellung auf einer Anzeige des Endgeräts verarbeitet werden, mit den Schritten:

a) Erkennen eines Betriebszustands wenigstens einer die Darstellung der Daten der multimedialen Anwendung betreffenden Servicekomponente des Endgeräts;
b) Erzeugen einer den Betriebszustand der wenigstens einen Servicekomponente kennzeichnenden Zustandsinformation;
c) Erzeugen einer Nachricht, umfassend: – die Zustandsinformation, und/oder – eine die Zustandsinformation kennzeichnende Information, welche die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten kennzeichnet, und/oder – eine Anweisung an die entfernte Quelle bezüglich der Adaption der Daten und/oder Übertragung der Daten an das Endgerät, um die Daten und/oder die Übertragung der Daten an die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten anzupassen;
d) Übertragen der Nachricht an die entfernte Quelle;
e) Empfangen der multimedialen Daten; und
f) Verarbeiten der multimedialen Daten zur Darstellung auf der Anzeige des Endgeräts.

Die vorliegende Erfindung geht davon aus, dass eine Multimedia-Anwendung zwei Seiten, nämlich eine Quellenseite bzw. Quellendomäne, von der aus Multimedia-Inhalte für die Anwendung bereitgestellt (und übermittelt) werden, und eine Senkenseite bzw. Senkendomäne, an der die Multimedia-Inhalte weiterverwendet werden, umfasst. Im Wesentlichen kann das Endgerät die Senke sein und kann beispielsweise ein Server (Download-Server, Spieleserver, Konferenzserver) die Quelle sein. Es können aber auch Vermittlungsstellen sowohl als (Zwischen-)Senke und (Zwischen-)Quelle vorgesehen sein. Das Verfahren des vorliegenden Gesichtspunkts betrifft die Senkenseite, insbesondere die Seite des Endgeräts. Mit dem erfindungsgemäßen Verfahren dieses Gesichtspunkts wird die Senderseite (die entfernte Quelle) in die Lage versetzt, die Erzeugung, Aufbereitung und Übertragung der Daten auf der Grundlage des Zustands der Servicekomponente anzupassen. Dadurch können wiederum Ressourcen auf der Seite des Endgeräts (aber auch der Quelle) optimal ausgenutzt werden. Das Endgerät kann vorzugsweise mobil sein, es sind aber auch stationäre Anwendungen denkbar. Mobil heißt insbesondere, dass das Endgerät mittels Mobilfunkverfahren kommunizieren kann. Beispiele für mobile Endgeräte sind beispielsweise Smartphone, Tablet, Laptop. Ein stationäres Endgerät wie etwa ein PC oder dergleichen bedeutet, dass die Übertragung bzw. der Empfang aller oder von Teilen der Daten zusätzlich oder alternativ über ein stationäres Netz erfolgen kann. Die multimedialen Daten können zur Darstellung auf jeder Anzeige des Endgeräts verarbeitet werden, die mit dem Endgerät verbunden und/oder in dem Endgerät fest eingebaut ist. Der erkannte Betriebszustand kann beispielsweise die bloße Tatsache der Aktivierung oder Deaktivierung der Komponente sein, kann aber auch Details wie etwa einen Batterieladestand, angeschlossene bzw. aktive Displays oder dergleichen umfassen. Servicekomponenten können beispielsweise, aber nicht nur, solche zur Audiowiedergabe, Videowiedergabe, Screen-Sharing, Joint Editing, Gaming etc. in Hardware und/oder Software sein. Die Servicekomponente kann auf dem Endgerät fest eingebaut und/oder installiert sein. Erfindungsgemäß kann die Nachricht die Zustandsinformation und/oder eine die Zustandsinformation kennzeichnende Information, welche die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten kennzeichnet, umfassen. Unter einer Datendichte kann im Sinne der Erfindung insbesondere eine Datenrate verstanden werden. Eine Datenrate kann insbesondere als eine Datenmenge je Zeiteinheit definiert sein. Wenn die Nachricht die Zustandsinformation enthält, wird die Verarbeitungsintelligenz und Entscheidungskompetenz auf der Seite der Datenquelle unterstellt und ausgenutzt, was Ressourcen auf der Endgeräteseite einsparen kann. Die Übertragung der Nachricht kann beispielsweise über RTC, insbesondere über einen Mobilfunkstandard, an die entfernte Quelle übertragen bzw. empfangen werden. Wenn die Nachricht die Anweisung enthält, wird die Verarbeitungsintelligenz und Entscheidungskompetenz auf der Seite des Endgeräts vorausgesetzt, was das Endgerät unabhängiger machen kann. Wenn die Nachricht, die die Zustandsinformation kennzeichnende Information, welche die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten kennzeichnet, aufweist, wird eine Verarbeitungsintelligenz wenigstens in hohem Anteil auf der Seite des Endgeräts vorausgesetzt, um die maximal verarbeitbare Datendichte zu ermitteln, während die Entscheidung über die zu treffenden Maßnahmen, um die Datenbereitstellung und -übertragung an die maximal verarbeitbare Datendichte anzupassen, auf der Seite der Quelle getroffen wird.
Bei diesem Erfindungsgesichtspunkt wird mit anderen Worten auch die entfernte Quelle aufgrund des erkannten Betriebszustands veranlasst, die Daten (höchstens) mit der durch das Endgerät maximal verarbeitbaren Datendichte zu übertragen. D. h., das Endgerät empfängt die Daten (höchstens) mit der durch das Endgerät maximal verarbeitbaren Datendichte.
Eine Weiterbildung des Verfahren dieses Erfindungsgesichtspunkts kann vorsehen, dass der Betriebszustand durch eine erste Anwendungsprogrammierschnittstelle (API, insbesondere Device-API) erfasst wird und die Zustandsinformation durch eine zweite Anwendungsprogrammierschnittstelle (API, insbesondere Control-API) verarbeitet wird, wobei die Anwendung, welcher die zweite Anwendungsprogrammierschnittstelle zugeordnet ist, vorzugsweise in einem WebRTC-fähigen Web-Browser des Endgeräts implementiert ist, und wobei vorzugsweise die zweite Anwendungsprogrammierschnittstelle die Nachricht erzeugt oder einen insbesondere RTC-fähigen Server veranlasst, die Nachricht zu erzeugen. Als Server kann insbesondere ein RTC-fähiger Kommunikationsserver eingesetzt werden. Ferner kann das Verfahren so ausgestaltet sein, dass die Nachricht an eine entfernte Anwendungsprogrammierschnittstelle (API, insbesondere Control-API) der entfernten Quelle adressiert wird.
Eine bevorzugte Ausführungsform des Verfahren dieses Erfindungsgesichtspunkts kann vorsehen, dass die Darstellung der Daten nach einem Entwurfsmuster (MVC) mit einem die Daten enthaltenden Modell (M), einer View (V) als Präsentationsschicht zur Darstellung der Daten und einem Controller (C) als Steuerungsschicht zur Verwaltung der Präsentationsschicht implementiert wird, wobei die Zustandsinformation durch den Controller (C) erzeugt wird, wobei vorzugsweise der Betriebszustand in dem Modell (M) implementiert wird. Im Sinne des gemäß der vorliegenden Erfindung genutzten MVC-Entwurfsmusters ist eine View eine Präsentationsschicht, die auch für die Entgegennahme von Benutzerinteraktionen zuständig ist. Sie kennt sowohl ihre Steuerung als auch das Modell, dessen Daten sie präsentiert, ist aber nicht für die Weiterverarbeitung der vom Benutzer übergebenen Daten zuständig. Die Präsentation kann über Änderungen von Daten im Modell mithilfe des Entwurfsmusters „Beobachter” unterrichtet werden und daraufhin die aktualisierten Daten abrufen. Ferner ist ein Controller im Sinne des gemäß der vorliegenden Erfindung genutzten MVC-Entwurfsmusters eine Steuerung, die eine oder mehrere Präsentationen verwaltet, und die auch gegebenenfalls von ihnen Benutzeraktionen entgegennimmt, diese auswertet und entsprechend agiert. Jede Präsentation kann eine eigene Steuerung aufweisen. Die Steuerung kann auch dafür sorgen, dass Benutzeraktionen wirksam werden, z. B. durch Änderung der Präsentation (z. B. Verschieben des Fensters) oder durch Weiterleiten an das Modell (z. B. Übernahme von Eingabedaten oder Auslösen von Verarbeitungen). Die Steuerung kann auch Mechanismen enthalten, um die Benutzerinteraktionen der Präsentation einzuschränken. Die Steuerung kann in manchen Implementierungen ebenfalls zu einem „Beobachter” des Modells werden, um bei Änderungen der Daten die View direkt zu manipulieren. Die vorstehenden Erläuterungen zum MVC-Entwurfsmuster folgen dem Wikipedia-Eintrag ”Model_View_Controller”, der für das weitere Verständnis in Bezug genommen wird. Da erfindungsgemäß die Zustandsinformation durch den Controller (C) erzeugt wird, kann das bestehende MVC-Muster ausgenutzt werden, wobei die Steuerungsschicht eine Erweiterung erfährt.
Eine Weiterbildung des Verfahren dieser Ausführungsform kann vorsehen, dass die zweite Anwendungsprogrammierschnittstelle in dem Entwurfsmuster als zusätzliche View für die von ihr gesteuerten Servicekomponenten registriert wird, wobei vorzugsweise der Betriebszustand über die erste Anwendungs-Steuerschnittstelle dem Modell zugeführt wird.
Eine Weiterbildung des Verfahrens dieses Erfindungsgesichtspunkts kann vorsehen, dass die Anweisung bezüglich der Adaption der Daten und/oder Übertragung der Daten an das Endgerät wenigstens eine der nachstehenden Maßnahmen betrifft:

– Abschalten oder Suspendieren oder Wiederaufnehmen oder Einschalten eines Datenstroms;
– Verringern oder Erhöhen einer Datendichte eines Datenstroms;
– Ändern des Übertragungswegs zum Senden des Datenstroms;
– Senden eines Ersatzmediums anstelle des Datenstroms oder eines Teils des Datenstroms.

Ein zweiter Gesichtspunkt der vorliegenden Erfindung betrifft ein Verfahren zur Steuerung einer Adaption und Übertragung von multimedialen Daten an eine entfernte Senke, insbesondere an ein vorzugsweise mobiles Endgerät, mit den Schritten:

A) Empfangen und Dekodieren einer Nachricht von der entfernten Senke;
B) Auswerten der Nachricht, um einen Betriebszustand wenigstens einer die Darstellung der Daten der multimedialen Anwendung betreffenden Servicekomponente auf der Seite der entfernten Senke oder eine durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten in der entfernten Senke zu erkennen;
C) Ändern der Adaption und/oder Übertragung der multimedialen Daten, durch Auswerten des erkannten Betriebszustands oder der maximal verarbeitbaren Datendichte zur Darstellung der multimedialen Daten, durch wenigstens eine der nachstehenden Maßnahmen: – Abschalten oder Suspendieren oder Wiederaufnehmen oder Einschalten eines Datenstroms der multimedialen Daten; – Verringern oder Erhöhen einer Datendichte des Datenstroms; – Ändern des Übertragungswegs zum Senden des Datenstroms; – Senden eines Ersatzmediums anstelle des Datenstroms oder eines Teils des Datenstroms, um die an die entfernte Senke zu übermittelnde Datendichte an die maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten in der entfernten Senke anzupassen.

Dieser Erfindungsgesichtspunkt betrifft die Sender- bzw. Quellenseite und geht von der Voraussetzung aus, dass die Entscheidungsintelligenz auf der Senderseite liegt. Das Verfahren dieses Erfindungsgesichtspunkts wird also insbesondere durch die entfernte Quelle im Sinne des ersten Erfindungsgesichtspunkts durchgeführt. Eine entfernte Senke kann im Sinne dieses zweiten Erfindungsgesichtspunkts ein Endgerät, insbesondere das Endgerät des ersten Erfindungsgesichtspunkts, oder eine Zwischenstation (z. B. Router, TK-Anlage, Server) sein. Vorzugsweise ist vorgesehen, dass die Nachricht über RTC, insbesondere über einen Mobilfunkstandard, an die entfernte Quelle übertragen bzw. empfangen wird.
Alternativ kann anstelle der Schritte B und C in dem Verfahren dieses Erfindungsgesichtspunkts eine in der Nachricht enthaltene Anweisung erkannt und kann gemäß dem Inhalt der Anweisung

– eine Suspendierung einer Übertragung der multimedialen Daten unter Aufrechterhaltung des Übertragungskanals, oder
– eine Verringerung einer Datendichte der multimedialen Daten, oder
– eine Maskierung eines Datenstroms der multimedialen Daten durch ein Ersatzmedium, oder
– eine Wiederaufnahme einer zuvor suspendierten Übertragung oder Wiederherstellen einer zuvor verringerten Datendichte der multimedialen Daten, oder
– eine Wiederherstellung eines zuvor maskierten Datenstroms der multimedialen Daten

Eine Weiterbildung des Verfahrens dieses Erfindungsgesichtspunkts kann vorsehen, dass die Nachricht durch eine Anwendungsprogrammierschnittstelle (API, insbesondere Control-API) empfangen wird, wobei eine Anwendung, welcher die Anwendungsprogrammierschnittstelle zugeordnet ist, vorzugsweise in einem WebRTC-fähigen Web-Browser implementiert ist. Vorzugsweise kann zusätzlich vorgesehen sein, dass die multimedialen Daten über eine von der Anwendungsprogrammierschnittstelle zum Empfang der Nachricht verschiedene Schnittstelle, insbesondere eine Media Engine zur Codierung oder Decodierung von Mediendatenströmen des Web-Browsers, übertragen werden.
Ein dritter Gesichtspunkt der vorliegenden Erfindung betrifft ein Verfahren zur Steuerung einer Multimedia-Anwendung auf einem insbesondere mobilen Endgerät, wobei multimediale Daten der Multimedia-Anwendung von einer Quellendomäne an eine Senkendomäne übertragen werden, durch die Senkendomäne empfangen und zur Darstellung auf einer Anzeige des Endgerät verarbeitet werden, wobei die multimedialen Daten in Abhängigkeit von einem Betriebszustand wenigstens einer die Darstellung der Daten der multimedialen Anwendung betreffenden Servicekomponente des Endgeräts adaptiert und/oder übertragen werden, wobei das Verfahren vorzugsweise die Verfahrensschritte des vorstehend beschriebenen Verfahrens gemäß dem ersten Erfindungsgesichtspunkt und/oder des vorstehend beschriebenen Verfahrens gemäß dem zweiten Erfindungsgesichtspunkt aufweist. Mit anderen Worten, dieser Erfindungsgesichtspunkt betrifft ein System, welches die Quellen- und die Senkenseite umfasst. Bei diesem Erfindungsgesichtspunkt kann auch sichergestellt werden, dass die Daten von der Quelle zur Senke (höchstens) mit der durch das Endgerät (Senke) maximal verarbeitbaren Datendichte übertragen werden.
Ein vierter Gesichtspunkt der vorliegenden Erfindung betrifft ein Softwareprodukt, das auf einem durch einen Computer lesbaren Medium gespeichert ist und das vorzugsweise direkt in den internen Speicher eines Computer geladen werden kann und das Programmcodes eines Computerprogramms, das einen Computer zur Durchführung der Verfahrensschritte wenigstens eines der vorstehend beschriebenen Verfahren gemäß dem ersten, zweiten oder dritten Erfindungsgesichtspunkts befähigt, wenn das Computerprogramm auf dem Computer ausgeführt wird, aufweist.
Ein fünfter Gesichtspunkt der vorliegenden Erfindung betrifft ein Vorrichtung zur Ausführung wenigstens eines der vorstehend beschriebenen Verfahren gemäß dem ersten, zweiten oder dritten Erfindungsgesichtspunkts, wobei die Vorrichtung vorzugsweise ein insbesondere mobiles Endgerät, und/oder einen Server, insbesondere Gaming-Server oder Konferenzserver, und/oder eine Konferenzeinheit umfasst, und wobei die Vorrichtung insbesondere durch Implementierung des Softwareprodukts gemäß dem vierten Erfindungsgesichtspunkts zur Ausführung des Verfahrens befähigt ist.
Die Erfindung kann auch durch ein Computerprogramm, umfassend Programmbefehle, die einen Computer dazu veranlassen, die Verfahrensschritte wenigstens eines der vorstehend beschriebenen Verfahren gemäß dem ersten, zweiten oder dritten Erfindungsgesichtspunkts auszuführen, wenn das Computerprogramm auf den Computer geladen oder von diesem ausgeführt wird, und/oder ein digitales Speichermedium mit elektrisch lesbaren Steuersignalen, welche mit einem programmierbaren Computer arbeiten können, um Kommunikationsvorgänge zu verwalten, wobei die Steuersignale ausgelegt und angepasst sind, den Computer zu veranlassen, die Verfahrensschritte wenigstens eines der vorstehend beschriebenen Verfahren gemäß dem ersten, zweiten oder dritten Erfindungsgesichtspunkts auszuführen, verkörpert sein.
Weitere Merkmale, Aufgaben, Vorteile und Einzelheiten der vorliegenden Erfindung werden aus der nachstehenden Beschreibung konkreter Ausführungsbeispiele und ihrer zeichnerischen Darstellung in den beigefügten Figuren noch deutlicher werden. Es versteht sich, dass Merkmale, Aufgaben, Vorteile und Einzelheiten einzelner Ausführungsbeispiele auf andere Ausführungsbeispiele übertragbar sind und auch im Zusammenhang mit den anderen Ausführungsbeispielen als offenbart gelten sollen, soweit dies nicht aus technischen oder naturgesetzlichen Gründen offensichtlich abwegig ist. In diesem Sinne können Merkmale verschiedener Ausführungsbeispiele grundsätzlich stets miteinander kombiniert werden, und die Kombination kann ebenfalls als Ausführungsbeispiel der Erfindung verstanden werden.
Im Folgenden wird die Erfindung anhand bevorzugter Ausführungsbeispiele und mit Hilfe von Figuren näher beschrieben. Dabei ist bzw. sind
1 eine schematische Darstellung einer generischen Referenzarchitektur mit Quellen- und Senkendomäne gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
2A eine schematische Darstellung einer möglichen Integration in eine quellenseitige Implementierung einer WebRTC Applikation des Ausführungsbeispiels;
2B eine schematische Darstellung einer möglichen Integration in eine senkenseitige Implementierung einer WebRTC Applikation des Ausführungsbeispiels;
3 ein Ablaufdiagramm eines Prozesses gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
Die Figuren sind rein schematisch und nicht notwendigerweise maßstabsgetreu. Die zeichnerischen Darstellungen und Beschreibungen hiervon sind zur beispielhaften Veranschaulichung des Prinzips der Erfindung gedacht und sollen diese in keiner Weise einschränken. Begriffe und Konzepte, die der Fachmann aus dem Stand der Technik verstehen und anwenden kann, werden nachstehend nicht im Einzelnen erläutert, um den Erfindungsgegenstand nicht zu verwässern.
In 1 ist eine generische Referenzarchitektur mit Quellen- und Senkendomäne als ein Ausführungsbeispiel einer Vorrichtung gemäß der vorliegenden Erfindung dargestellt.
Eine Ursprungs- bzw. Quellendomäne (Domain 1) 100 weist eine Medienquelle (Client Media Source) 110, einen HTTP/Web-Server 120, einen Echtzeit-Kollaborations- bzw. -Kommunikationsserver (Real-Time Collaboration Server) 130, einen Session Border Controller (SBC) 140 und einen STUN&TURN-Server 150 (STUN/TURN: Session Traversal Utilities for NAT (Network Address Translation)/Traversal Using Relays around NAT) auf. Die Medienquelle 110 wird wesentlich durch ein Gerät (Device) 111 implementiert. Das Gerät 111 weist einen Web-Browser 112, in dem eine WebRTC-fähige Anwendung (WebRTC App) 113 mit einem MVC-(Model-View-Controller)-Entwurfsmuster 114 implementiert ist, auf. Die Anwendung 113 ist über eine Verbindung 121 mit einem geeigneten Protokoll wie etwa HTML 5/JS mit dem HTTP/Web-Server 120 verbunden und steht über eine Geräte-Anwendungsprogrammierschnittstelle (Device API) 115 mit Peripheriegeräten des Geräts 111 in Verbindung. Ferner steht eine Steuerungs-Anwendungsprogrammierschnittstelle (Control API) 116 der Anwendung 113 über eine Verbindung 131 mit einem proprietären Protokoll wie etwa ”RESTful over Websockets” (REST: Representational State Transfer) mit dem Kommunikationsserver 130 in Verbindung. Der Web Browser 112 weist ferner eine Medienschnittstelle 117 auf, die mit dem STUN&TURN-Server 150 in Verbindung steht. Im Sinne der vorliegenden Anmeldung schließt der Begriff der Kollaboration die Kommunikation ein, ist aber nicht darauf beschränkt.
Eine Ziel- bzw. Senkendomäne (Domain 2) 200 ist in Bezug auf die die vorliegende Erfindung betreffende Merkmale im Wesentlichen wie die Quellendomäne 200 aufgebaut. Namentlich weist die Zieldomäne 200 eine Mediensenke (Client Media Sink) 210, einen HTTP/Web-Server 220, einen Echtzeit-Kommunikationsserver (Real-Time Collaboration Server) 230, einen Session Border Controller 240 und einen STUN&TURN-Server 250 auf. Die Mediensenke 210 wird wesentlich durch ein Gerät (Device) 211 implementiert. Das Gerät 211 weist einen Web-Browser 212, in dem eine WebRTC-fähige Anwendung (WebRTC App) 213 mit einem MVC-(Model-View-Controller)-Entwurfsmuster 214 implementiert ist, auf. Die Anwendung 213 ist über eine Verbindung 221 mit einem geeigneten Protokoll mit dem HTTP/Web-Server 220 verbunden und steht über eine Geräte-Anwendungsprogrammierschnittstelle (Device API) 215 mit Peripheriegeräten des Geräts 211 in Verbindung. Ferner ist eine Steuerungs-Anwendungsprogrammierschnittstelle (Control API) 216 der Anwendung 213 über eine Verbindung 231 mit dem Kommunikationsserver 230 verbunden. Der Web Browser 212 weist ferner eine Medienschnittstelle 217 auf, die mit dem STUN&TURN-Server 250 in Verbindung steht. Die verwendeten Protokolle können den in der Quellendomäne 100 verwendeten Protokollen entsprechen.
Die Kollaborationsserver 130, 230 dienen im Zusammenhang mit der vorliegenden Erfindung in erster Linie als Kommunikationsserver, können aber auch weitere Kollaborationsfunktionen verwirklichen.
Die Quellendomäne 100 und die Zieldomäne 200 sind über mehrere Datenverbindungen miteinander verbunden. Zum einen sind die Kommunikationsserver 130, 230 der Quellendomäne 100 und der Zieldomäne 200 durch eine Datenverbindung 400 miteinander verbunden, wobei die Session Border Controller 140, 240 der Quellendomäne 100 und der Zieldomäne 200 jeweils als Schnittstelle nach außen fungieren. Die Datenverbindung 400 nutzt beispielsweise Session Protocol SIP-T oder XMPP mit SDP Offer/Answer zur Anbindung weiterer Domänen (Federation) anbieten. Weiters sind die STUN&TURN-Server 150, 250 der Quellendomäne 100 und der Zieldomäne 200 zur Realisierung einer RTP-Verbindung 500 zwischen den Medienschnittstellen 117, 217 der Quellendomäne 100 und der Zieldomäne 200 miteinander verbunden und sind die Medienschnittstellen 117, 217 der Quellendomäne 100 und der Zieldomäne 200 über eine SCTP-(Stream Control Transmission Protocol)-Verbindung 700 auch direkt miteinander verbunden.
Im vorliegenden Ausführungsbeispiel entspricht die Zieldomäne 200 bzw. deren Geräteebene 211 einem (mobilen) Endgerät. Die Quellendomäne 100 bzw. deren Geräteebene 111 kann beispielsweise ein Medienserver sein. Es ist zu verstehen, dass in der generischen Architektur von 1 einzelne Elemente der jeweiligen Domäne 100, 200 in dem jeweiligen physikalischen Gerät 111, 211 oder außerhalb angeordnet sein können.
2A und 2B verdeutlichen den Aufbau der WebRTC-Browser 112, 214 der Quellendomäne 100 bzw. der Zieldomäne 200 in weiteren Einzelheiten. Dabei ist 2A eine schematische Darstellung einer möglichen Integration in eine quellenseitige Implementierung der WebRTC-Applikation 113 dieses Ausführungsbeispiels, und 2B ist eine schematische Darstellung einer möglichen Integration in eine senkenseitige Implementierung der WebRTC-Applikation 213 dieses Ausführungsbeispiels. 2A und 2B können als Einzelheiten von 1 verstanden werden.
Gemäß der Darstellung in 2A weist die Medienschnittstelle 117 des Web-Browsers 112 der Quellendomäne 100 eine WebRTC-fähige Anwendungsprogrammierschnittstelle (WebRTC API) 117a und eine Medienmaschine (Media Engine) 117b auf. Die Media Engine 117b auf der Seite der Quellendomäne 100 kann als Encoder für gesendete Mediendatenströme arbeiten. Eine Kamera-Mikrofon-Einheit (Camera/Microphone) 160 ist mit der Geräte-Anwendungsprogrammierschnittstelle 115 verbunden.
Gleichermaßen weist gemäß der Darstellung in 2B weist die Medienschnittstelle 217 des Web-Browsers 212 der Zieldomäne 200 eine WebRTC-fähige Anwendungsprogrammierschnittstelle (WebRTC API) 217a und eine Medienmaschine (Media Engine) 217b auf. Die Media Engine 217b auf der Seite der Zieldomäne 200 kann als Decoder für empfangene Mediendatenströme arbeiten. Eine Kamera-Mikrofon-Einheit (Camera/Microphone) 260, eine Mensch-Maschine-Schnittstelle (Human Interaction Device) 270 zur Erfassung von Interaktionen eines Bedieners 900 sowie andere Hardware-Sensoren 280 sind mit der Geräte-Anwendungsprogrammierschnittstelle 215 verbunden.
In 2B ist auch das erweiterte MVC-Entwurfsmuster 214 der Web-RTC-Anwendung 213 der Senkendomäne 200 und seine Implementierung schematisch dargestellt. Das MVC-Entwurfsmuster 214 weist ein Modell (Model) ”M”, eine Ansicht (View) ”V” und eine Steuerung (Controller) ”C” auf, wie bereits oben näher erläutert. Das Modell ”M” erhält Eingabedaten von der Device API 215 und der WebRTC Media Engine 217b. Die View ”V” steuert die Anzeige einer Ansicht auf einer Bild-Ton-Wiedergabeeinheit (Screen Speaker) 290. Der Controller ”C” erhält ebenfalls Eingabedaten von der Device API 215 und liefert Ausgabedaten für die Control API 216. Die Control API 216 ist ferner mit der WebRTC API 217a und der Device API 215 verbunden.
Wie in 2A und 2B gezeigt, sind die RTP-Verbindung 500 und die SCTP-Verbindung 700 zwischen der Medienschnittstelle 117 des WebRTC-Browsers 112 der Quellendomäne 100 und der Medienschnittstelle 217 des WebRTC-Browsers 212 der Zieldomäne 200 errichtet. Dabei läuft die unidirektionale RTP-Verbindung 500, wie in 1 gezeigt, auf Quellen- und Senkenseite jeweils über einen STUN&TURN-Server 150, 250, während die bidirektionale SCTP-Verbindung 700 direkt zwischen den Medienschnittstellen 117, 217 verläuft. Die STUN&TURN-Server 150, 250 können in Ausführungsvarianten weggelassen werden oder auf STUN- oder TURN-Funktion beschränkt sein. Die RTP-Verbindung 500 und die SCTP-Verbindung 700 können wahlweise genutzt werden, und es kann in Ausführungsvarianten nur eine von diesen vorhanden sein.
Die Funktionsweise der in 1, 2A und 2B dargestellten Gerätetechnik wird nachstehend auch anhand des Ablaufschemas von 3 als ein Ausführungsbeispiel eines Verfahrens gemäß der vorliegenden Erfindung beschrieben.
Eine spezifische WebRTC Applikation 213 auf dem (mobilen) Endgerät 210 wird durch Auswahl einer entsprechenden URL in einem HTML5/JavaScript(JS)-fähigen Browser 212 gestartet, und vom Applikations-Server (HTTP/Web-Server) 220 wird dann die eigentliche Applikationslogik über JS in den Browser 212 geladen. Daraufhin wird zunächst eine Websocket-Verbindung 231 zum jeweiligen RTC-Server 130, 230 aufgebaut und das proprietäre Protokoll – meist als RESTful gestaltetes Protokoll – gestartet. Bei einer beispielhaften Videotelefonie-mit-Screen-Sharing-Anwendung werden lokal die Geräte-Empfangsressourcen für den Zugriff auf Mikrofon, Kamera, und Graphikkarte über das Device API:getUserMedia gestartet. Über das proprietäre und das Session-Protokoll (das optional über einen oder mehrere Session Border Controller geführt wird) werden die Adressen des entfernten Gerätes 110, mit dem kommuniziert werden soll, übermittelt. Die beteiligten Geräte, die Medien als Quelle übermitteln, d. h., im dargestellten Ausführungsbeispiel das Gerät 111 der Quellendomäne 100, bauen mittels des Web-RTC API 117 die jeweils uni-direktionalen RTP Verbindungen 500 zur Übermittlung von Sprache, Video und Screen-Sharing beispielhaft als gestreamtes Video in Vorwärtsrichtung auf. Wie erwähnt, kann für bestimmte andere Medien die bi-direktionale SCTP-Verbindung 700 aufgebaut werden. Im vorliegenden Ausführungsbeispiel werden in den Verbindungsaufbau jeweilige STUN&TURN-Server 150, 250 in den RTP-Kanal 500 involviert. Die vom Gerät der Quellendomäne empfangenen Medien Sprache, Bewegtbild der Kamera und des Bildschirms werden entsprechend dem im Session-Protokoll ausgehandelten Kodierungsverfahren durch die quellenseitige Media Engine 117b codiert und über die jeweils eine RTP-Verbindung 500 (hier ebenfalls wieder über die STUN&TURN-Server 150, 250) übermittelt. Das empfangende Gerät, d. h., die senkenseitige Media Engine 217b, decodiert die Medienströme und präsentiert diese über die Applikationslogik auf den entsprechenden lokalen Geräte-Ausgaberessourcen, hier Lautsprecher und Bildschirm als Bild-Ton-Wiedergabeeinheit 290, entsprechend der aktuell vom Benutzer gewählten Darstellung.
Die Applikationslogik implementiert die Ansicht typischerweise als Model-View-Controller(MVC)-Entwurfsmuster. Dabei erhält der MVC-Controller ”C” oder das MVC-Model ”M” das Wissen über die aktuelle Ansicht ”V”. Bei der Nutzung der beispielhaften Anwendung – beispielhaft auf einem Smartphone – kann nicht sinnvoll auf der Bildschirmfläche die Videodarstellung und der gesharte Bildschirm gleichzeitig mit geeigneter Auflösung dargestellt werden. Der Benutzer wird deshalb durch Interaktion (Human Interaction Device 270) beispielsweise in eine Ansicht Desktop-Sharing wechseln. Dies wird vom MVC 214 erfasst und festgestellt, dass das Kamera-Bewegtbild nicht mehr angezeigt wird. Daraufhin wird das lokale, erfindungsgemäß erweiterte Control-API 216 informiert, welches beispielsweise über eine Callback-Funktion eine erfindungsgemäße RemoteMedia(Suspend) Meldung 219 für diese Videoverbindung an den lokalen (Sink) WebRTC-Server 230 übermittelt. Dieser leitet diese Information über das gewählte und erfindungsgemäß erweiterte Session Protokoll 400 zum entfernten (Source) WebRTC-Server 130 weiter. Der entfernte WebRTC-Server 130 wiederum leitet diese Meldung zum Control-API 116 seines lokal verbundenen Browsers 112 weiter. Die Applikationslogik der lokalen WebRTC-App 113 schaltet daraufhin über das lokale DeviceAPI 111 mittels einer getUserMedia-Anweisung 119 den Medienstrom von der Kamera 160 ab, erhält aber die zugehörige RTP-Verbindung 500 aufrecht. Ggf. generiert der zugehörige Encoder (quellenseitige Media Engine 117b) ein Ersatzmedium, beispielsweise ein Standbild, mit deutlich reduziertem Bandbreitenbedarf. Wechselt der Benutzer am Empfangsgerät 210 nun kurzfristig in die Videotelefonie-Ansicht, um die Mimik des Gesprächspartners zu einem kritischen Aspekt in der gesharten Präsentation zu sehen, wird dies über den MVC 214 erfasst und daraufhin über das erfindungsgemäß erweiterte lokale Control-API 216 über eine Callback-Funktion angeregt, eine erfindungsgemäße RemoteMedia(Resume)-Meldung 219 für diese Videoverbindung an den lokalen (Sink) WebRTC-Server 230 zu übermittelt. Dieser leitet diese Information 219 über das gewählte und erfindungsgemäß erweiterte Session Protokoll 400 zum entfernten (Source) WebRTC-Server 130 weiter. Der entfernte WebRTC-Server 130 wiederum leitet diese Meldung zum Control-API 116 seines lokal verbundenen Browsers 112 weiter. Die Applikationslogik der lokalen WebRTC-App 113 schaltet daraufhin über das lokale DeviceAPI 115 mittels getUserMedia 119 den Medienstrom von der Kamera 190 wieder ein. Der Encoder liefert daraufhin den gewöhnten Medienstrom. Nach einer Karenzzeit, wenn der Benutzer in der Screen-Sharing-Ansicht verbleibt, kann auf analogem Verfahren das als Bewegtbild übermittelte Screen-Sharing suspendiert werden, und so weiter.
Beim Abmelden oder Verlassen der WebRTC-Anwendung 213 werden die verwendeten Ressourcen und die RTP(SCTP)-Verbindungen unabhängig von Suspendierungsstatus freigegeben bzw. abgebaut.
Wie erwähnt, zeigt 2B eine mögliche Integration in eine Client-seitige Implementierung einer WebRTC Applikation 213 durch die erfindungsgemäße Erweiterung des MVC 214. Das erfindungsgemäße Control-API 216 wird vom Controller ”V” getriggert, wenn die View ”V” sich so verändert hat, dass eine veränderte Nutzung der Medienströme vorliegt, die über das WebRTC-API 217a etabliert wurden. Alternativ zur View ”V” kann der Controller ”C” auch Signale aus dem Geräteumfeld propagieren wie Display ausgeschaltet, niedriger Batteriezustand, etc. Das Control-API 216 übermittelt dies zum WebRTC-Server 230, der wiederum dies an den entfernten WebRTC-Server 130 weiterleitet (nicht dargestellt). Optional können die empfangenen Medienströme noch lokal abgeschaltet werden, die Bestandteil des Models ”M” sind. Entfernt werden vom Control-API 130 dann die zu sendenden Medienströme abgeschaltet oder ressourcenschonend modifiziert. Das lokale Device-API 216 detektiert dies, und falls nicht bereits lokal explizit verarbeitet, wird das lokale Model ”M” entsprechend aktualisiert.
Prinzipiell könnte eine ähnliche Wirkung auch durch SDP:Offer/Answer abgebildet werden. Dies erfordert allerdings einen erheblicher höheren Signalisierungsaufwand, insbesondere zum Aufbau der RTP-Verbindungen und das Allokieren und De-allokieren der damit verbundenen Geräteressourcen. Das erfindungsgemäße Verfahren erlaubt demgegenüber eine erhöhte Agilität bei der Benutzerinteraktion und damit eine verbesserte Benutzererfahrung.
Wie oben beschrieben, wird durch die RemoteMedia{suspend|resume}-Meldung 219 eine Anweisung an die entfernte Quelle 100 bezüglich der Adaption der Daten und/oder Übertragung der Daten an das Endgerät 200, um die Daten und/oder die Übertragung der Daten an die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten anzupassen, verwirklicht. Dies setzt voraus, dass die Anwendungslogik und damit die zur Durchführung des erfindungsgemäßen Verfahrens erforderliche Entscheidungsintelligenz und -kompentenz auf der Seite des Endgeräts (Senkendomäne) 200 liegt.
In einer Abwandlung des vorstehend beschriebenen Ausführungsbeispiels kann die Anwendungslogik auch wenigstens teilweise auf der Seite der Quelle 100 angeordnet sein. So kann anstelle der RemoteMedia{suspend|resume}-Meldung 219 auch eine Nachricht erzeugt werden, welche die Zustandsinformation selbst enthält, und die Vorgaben zur Anpassung der Daten und/oder der Übertragung der Daten an die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten können durch die WebRTC-Anwendung 113 der Quelle 100 ermittelt und dann – via getUserMedia – umgesetzt werden.
In einer weiteren Abwandlung kann die erzeugte Nachricht eine die Zustandsinformation kennzeichnende Information, welche die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten kennzeichnet, aufweisen.
Wird nach dem Stand der Technik eine multi-mediale Anwendung, beispielsweise eine Kollaborationssitzung, gestartet, werden die zugehörigen Kommunikationskomponenten ebenfalls gleichzeitig gestartet. Dazu werden Verbindungen für Audio-/Video-Komponenten, Application-Sharing Komponenten und ggf. weitere Kommunikationskanäle bi-direktional aufgebaut. Sobald diese aufgebaut sind, beginnen die Datenquellen mit der Codierung der Daten- und Kommunikationsströme unabhängig davon, ob diese von der Datensenke verarbeitet und deren Decodierung dargestellt wird. Werden diese nun aber nicht dargestellt, werden unnötig Netzbandbreiten genutzt und zusätzlich am sendenden und empfangenen Gerät unnötig Energie verbraucht, was bei mobilen Endgeräten die Batterielaufzeiten verkürzt. Typischerweise ist auf einem Smartphone oder Tablet-PC mit kleinerer Bildschirmdiagonale nicht gleichzeitig eine Videokonferenz und ein entfernter Bildschirm mit vernünftiger Auflösung darstellbar.
Gemäß der vorliegenden Erfindung wird die Übermittlungssteuerung über ein (mobiles) Datennetz von multi-medialen Servicekomponenten durch Rückkopplung von Benutzeransichten und -interaktionen am (mobilen) Zielgerät (Senkendomäne 200) zum Ursprungsgerät (Quellendomäne 100) verbessert. Dadurch werden sowohl Bandbreiten im Datennetz und Energie in den beteiligten End- und Übermittlungsgeräten gespart und bei mobilen Endgeräten damit die Batterielaufzeiten verlängert.
Wenn die Endgeräte über Konferenzsysteme verbunden sind, werden die Konferenzsysteme erfindungsgemäß im Sinne der Quellendomäne 100 verwendet und implementieren eine adäquate Funktionalität in proprietärer Weise.
Die erfindungsgemäß erweiterten Verbindungsprotokolle und Nutzverbindungen der Servicekomponenten können auch über Netzübergangs- oder Proxyeinrichtungen wie die STUN/TURN Server 150, 250 geführt werden. Das erfindungsgemäß erweiterte Session Protokoll kann optional über einen SBC 140, 240 geführt werden.
Darstellungen auf Geräten werden oft mit dem Entwurfsmuster Model-View-Controller (MVC) implementiert. Dabei steuert die View über den Controller, welche Daten gemäß Nutzerinteraktion aus dem Model dargestellt werden, und umgekehrt kann bei Änderung vom Controller beobachteter Daten die View aktualisiert werden. Das MVC-Implementierungsmuster kann sowohl für Web-Applikationen, native Clients, und Gadgets verwendet werden. Der Controller hat damit das Wissen, welcher Ausschnitt des Models tatsächlich aktuell verwendet wird. Für multi-mediale Anwendungen wie beispielsweise WebRTC beinhaltet das Model u. a. die Servicekomponenten wie Audio, Video, Screen-sharing, Joint Editing, und Gaming. Das Model hat erfindungsgemäß das Wissen, welche Komponenten aus Sicht der View aktiv sind und benötigt werden. Der Controller verfügt außerdem über die Übersicht, welche Servicekomponenten aktiv sind und kann damit erfindungsgemäß sinnvolle Kombinationen bereitstellen.
Ist zum Beispiel eine Screen-sharing Applikation aktiv und die Videokonferenzkomponente – da nicht darstellbar – inaktiv, kann der Controller die Abschaltung der Videoverbindung bei gleichwohl fortdauernder Nutzung der Audioverbindung veranlassen. Das erfindungsgemäß erweiterte Model mit Wissen über aktive und inaktive Servicekomponenten kann erfindungsgemäß für die jeweilige Servicekomponente beispielsweise über ein erfindungsgemäß erweitertes Control-API 216 der WebRTC App 213 im Client 210 informieren, welches wiederum die erfindungsgemäße call-back Funktion „RemoteMedia{suspend|resume}” 219 im Senke-Echtzeitkommunikationsserver (WebRTC-Server) 230 auslöst. Dazu könnte sich das Control-API 216 beispielsweise als zusätzliche „View” für die von ihr gesteuerten Servicekomponenten registrieren. Der Senken-WebRTC-Server 230 kann erfindungsgemäß zum Quellen-WebRTC-Server 130 über ein geeignetes implizit oder explizit erweitertes Verbindungsprotokoll 400 signalisieren, welches die Funktion „RemoteMedia{suspend|resume}” 219 adäquat abbildet, die Verwendung einzelner Servicekomponenten rückkoppeln. Der Quellen-WebRTC Server 130 kann dann wiederum über sein lokales Control-API 116 die korrespondierende Datenquelle 110 ansteuern (z. B. über das Device API:getUserMedia 119), die Übermittlung von Daten einzustellen, zu suspendieren, fortzusetzten bzw. wieder aufzunehmen, die Datendichte zu verringern oder zu erhöhen, den Datenstrom durch ein Ersatzmedium zu maskieren oder eine Maskierung wieder durch den ursprünglichen Datenstrom zu ersetzen, etc. D. h., gegebenenfalls wird das Medium in geringerer Güte oder ein Ersatzmedium bereitgestellt, um mögliche Verbindungsabbrüche wegen Inaktivität zu vermeiden. Dabei hat eine erfindungsgemäße explizite Erweiterung der verwendeten Protokolle den Vorteil, dass betroffene Komponenten nur suspendiert bzw. schnell wieder reaktiviert werden können, ohne die Verbindung (beispielsweise heute wie geplant über SDP:Offer/Answer) erneut einrichten zu müssen, und somit die damit verbundene Latenzzeit reduziert werden kann.
Der erfindungsgemäße Controller ”C” z. B. des MVC 214 verfügt über die Übersicht, welche Servicekomponenten aktiv sind und kann damit erfindungsgemäß sinnvolle Kombinationen bereitstellen. Durch eine ergänzende Anbindung an Hard- und/oder Soft-Sensoren (260, 270, 280) im Endgerät oder Monitoring-Verbindungen zur Infrastruktur können Informationen über die tatsächlich verfügbare Bandbreiten und Dienstgüte bereitgestellt werden. Der Controller ”C” kann damit sinnvolle Kombinationen von Servicekomponenten weiter optimieren, indem beispielsweise die Videokomponente abgeschaltet oder beispielsweise ein (letztes) Standbild der View ”V” übermittelt wird, das zuvor in regelmäßigen Abständen im Model ”M” zusätzlich erzeugt und gespeichert wurde, und nur die Audiokomponente verwendet wird.
Die Komponenten des erfindungsgemäß erweiterten client-seitigen MVC 214 können auch mit Ausnahme vom Controller ”C” über einen Backend-Server, beispielsweise über den http/WebServer 220, verteilt werden.
Wie beschrieben, kann die Applicationslogik client-seitig im Browser durch das JavaScript download realisiert werden. Alternativ stellt diese der Applikationsserver bereit und interagiert mit der client-seitigen Implementierung des MVCs.
Die unter Bezug auf die dargestellten Ausführungsformen beschriebenen Merkmale der Erfindung, z. B. die erfindungsgemäße Erweiterung des MVC-Modells 214 auf der Seite der senkenseitigen WebRTC-App 213, können auch bei anderen Ausführungsformen und/oder Abwandlungen der Erfindung, beispielsweise zusätzlich oder alternativ zu einer Erweiterung des MVC-Modells 114 auf der Seite der quellenseitigen WebRTC-App 113 zur beispielsweise quellenseitigen Ermittlung der senkenseitig maximal verarbeitbaren Datendichte, vorhanden sein, außer wenn es anders angegeben ist oder sich aus technischen Gründen von selbst verbietet.

Claims

Verfahren zur Steuerung einer Multimedia-Anwendung (213) auf einem insbesondere mobilen Endgerät (200), wobei multimediale Daten von einer entfernten Quelle (100) empfangen werden und zur Darstellung auf einer Anzeige (290) des Endgeräts (200) verarbeitet werden, mit den Schritten: a) Erkennen eines Betriebszustands wenigstens einer die Darstellung der Daten der multimedialen Anwendung (213) betreffenden Servicekomponente des Endgeräts (200); b) Erzeugen einer den Betriebszustand der wenigstens einen Servicekomponente kennzeichnenden Zustandsinformation; c) Erzeugen einer Nachricht, umfassend: – die Zustandsinformation, und/oder – eine die Zustandsinformation kennzeichnende Information, welche die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten kennzeichnet, und/oder – eine Anweisung an die entfernte Quelle bezüglich der Adaption der Daten und/oder Übertragung der Daten an das Endgerät, um die Daten und/oder die Übertragung der Daten an die durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten anzupassen; d) Übertragen der Nachricht an die entfernte Quelle (100); e) Empfangen der multimedialen Daten; und f) Verarbeiten der multimedialen Daten zur Darstellung auf der Anzeige (290) des Endgeräts.
Verfahren gemäß Anspruch 1, dadurch gekennzeichnet, dass der Betriebszustand durch eine erste Anwendungsprogrammierschnittstelle (API, insbesondere Device-API) erfasst wird und die Zustandsinformation durch eine zweite Anwendungsprogrammierschnittstelle (API, insbesondere Control-API) verarbeitet wird, wobei die Anwendung, welcher die zweite Anwendungsprogrammierschnittstelle zugeordnet ist, vorzugsweise in einem WebRTC-fähigen Web-Browser des Endgeräts implementiert ist, und wobei vorzugsweise die zweite Anwendungsprogrammierschnittstelle die Nachricht erzeugt oder einen insbesondere RTC-fähigen Server veranlasst, die Nachricht zu erzeugen.
Verfahren gemäß Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Darstellung der Daten nach einem Entwurfsmuster (MVC) mit einem die Daten enthaltenden Modell (M), einer View (V) als Präsentationsschicht zur Darstellung der Daten und einem Controller (C) als Steuerungsschicht zur Verwaltung der Präsentationsschicht implementiert wird, wobei die Zustandsinformation durch den Controller (C) erzeugt wird, wobei vorzugsweise der Betriebszustand in dem Modell (M) implementiert wird.
Verfahren gemäß Anspruch 3, soweit auf Anspruch 2 rückbezogen, dadurch gekennzeichnet, dass die zweite Anwendungsprogrammierschnittstelle in dem Entwurfsmuster als zusätzliche View für die von ihr gesteuerten Servicekomponenten registriert wird, wobei vorzugsweise der Betriebszustand über die erste Anwendungs-Steuerschnittstelle dem Modell zugeführt wird.
Verfahren gemäß einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Nachricht eine Anweisung an die entfernte Quelle bezüglich der Adaption der Daten und/oder Übertragung der Daten an das Endgerät umfasst, wobei die Anweisung wenigstens eine der nachstehenden Maßnahmen betrifft: – Abschalten oder Suspendieren oder Wiederaufnehmen oder Einschalten eines Datenstroms; – Verringern oder Erhöhen einer Datendichte eines Datenstroms; – Ändern des Übertragungswegs zum Senden des Datenstroms; – Senden eines Ersatzmediums anstelle des Datenstroms oder eines Teils des Datenstroms.
Verfahren zur Steuerung einer Adaption und Übertragung von multimedialen Daten an eine entfernte Senke, insbesondere an ein vorzugsweise mobiles Endgerät, mit den Schritten: A) Empfangen und Dekodieren einer Nachricht von der entfernten Senke; B) Auswerten der Nachricht, um einen Betriebszustand wenigstens einer die Darstellung der Daten der multimedialen Anwendung betreffenden Servicekomponente auf der Seite der entfernten Senke oder eine durch den Betriebszustand der Servicekomponente vorgegebene maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten in der entfernten Senke zu erkennen; C) Ändern der Adaption und/oder Übertragung der multimedialen Daten, durch Auswerten des erkannten Betriebszustands oder der maximal verarbeitbaren Datendichte zur Darstellung der multimedialen Daten, durch wenigstens eine der nachstehenden Maßnahmen: – Abschalten oder Suspendieren oder Wiederaufnehmen oder Einschalten eines Datenstroms der multimedialen Daten; – Verringern oder Erhöhen einer Datendichte des Datenstroms; – Ändern des Übertragungswegs zum Senden des Datenstroms; – Senden eines Ersatzmediums anstelle des Datenstroms oder eines Teils des Datenstroms, um die an die entfernte Senke zu übermittelnde Datendichte an die maximal verarbeitbare Datendichte zur Darstellung der multimedialen Daten in der entfernten Senke anzupassen.
Verfahren gemäß Anspruch 6, dadurch gekennzeichnet, dass die Nachricht durch eine Anwendungsprogrammierschnittstelle (API, insbesondere Control-API) empfangen wird, wobei eine Anwendung, welcher die Anwendungsprogrammierschnittstelle zugeordnet ist, vorzugsweise in einem WebRTC-fähigen Web-Browser implementiert ist.
Verfahren zur Steuerung einer Multimedia-Anwendung auf einem insbesondere mobilen Endgerät, wobei multimediale Daten der Multimedia-Anwendung von einer Quellendomäne an eine Senkendomäne übertragen werden, durch die Senkendomäne empfangen und zur Darstellung auf einer Anzeige des Endgerät verarbeitet werden, wobei die multimedialen Daten in Abhängigkeit von einem Betriebszustand wenigstens einer die Darstellung der Daten der multimedialen Anwendung betreffenden Servicekomponente des Endgeräts adaptiert und/oder übertragen werden, wobei das Verfahren vorzugsweise die Verfahrensschritte eines Verfahrens gemäß einem der Ansprüche 1 bis 5 und/oder eines Verfahrens gemäß Anspruch 6 oder 7 aufweist.
Softwareprodukt, das auf einem durch einen Computer lesbaren Medium gespeichert ist und das vorzugsweise direkt in den internen Speicher eines Computer geladen werden kann und das Programmcodes eines Computerprogramms, das einen Computer zur Durchführung der Verfahrensschritte eines Verfahrens nach einem der vorstehenden Ansprüche befähigt, wenn das Computerprogramm auf dem Computer ausgeführt wird, aufweist.
Vorrichtung zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 8, wobei die Vorrichtung vorzugsweise ein insbesondere mobiles Endgerät, und/oder einen Server, insbesondere Gaming-Server oder Konferenzserver, und/oder eine Konferenzeinheit umfasst, und wobei die Vorrichtung insbesondere durch Implementierung von Programmcodes eines Computerprogramms eines Softwareprodukts nach Anspruch 9 zur Ausführung des Verfahrens befähigt ist.