DE10312030A1

DE10312030A1 - Verfahren zur Übertragung von Multimedia-Objekten und digitaler Empfänger für Multimedia-Objekte

Info

Publication number: DE10312030A1
Application number: DE10312030A
Authority: DE
Inventors: Hartwig Koch
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2003-03-18
Filing date: 2003-03-18
Publication date: 2004-09-30
Also published as: GB2399726A; GB2399726B; GB0406149D0

Abstract

Ein Verfahren zur Übertragung von Multimedia-Objekten (MOT-Objekte), digital kodiert im Multimedia-Objekt-Transfer(MOT)-Protokoll, wobei MOT-Objekte jeweils ein Kopfdatenteil mit Informationen über das zugeordnete MOT-Objekt und einen Rumpfdatenteil haben, und wobei im Datenstrom zur Übertragung einer Gruppe von MOT-Objekten ein MOT-Verzeichnis mit Informationen über die MOT-Objekte der Gruppe übertragen wird, hat den Schritt des Übertragens von Veränderungen des MOT-Verzeichnisses oder von dem MOT-Verzeichnis registrierten MOT-Objekten als Änderungsindex im Datenstrom.

Description

Die Erfindung betrifft ein Verfahren zur Übertragung von Multimedia-Objekten digital kodiert im Multimedia-Objekt-Tranfer (MOT)-Protokoll, wobei MOT-Objekte jeweils einen Kopfdatenteil mit Informationen über das zugeordnete MOT-Objekt und einen Rumpfdatenteil haben, und wobei für eine Gruppe von MOT-Objekten ein MOT-Verzeichnis mit Informationen über alle MOT-Objekte der Gruppe vorgesehen ist.
Die Erfindung betrifft weiterhin einen digitalen Empfänger für Multimedia-Objekte (MOT-Objekte) mit einer Rekonstruktionseinheit zur Dekodierung von Multimedia-Objekt-Daten (MOD), die im MOT-Protokoll übertragen werden, wobei MOT-Objekte jeweils einen Kopfdatenteil mit Informationen über das zugeordnete MOT-Objekt und einen Rumpfdatenteil haben, und wobei für eine Gruppe MOT-Objekte ein MOT-Verzeichnis mit Informationen über alle MOT-Objekte der Gruppe vorgesehen ist.
Mit dem europäischen ETSI-Standard EN 300 401 "Radio Broadcasting Systems: Digital Audio Broadcasting (DAB) to mobil, portable and fixed Receivers" ist ein Verfahren zur breitbandigen Übertragung digitaler Audiodaten festgelegt. zusammen mit den Audiodaten können auch Multimediadaten im Transportdatenstrom mit übertragen werden. Hierzu ist der europäische ETSI-Standard EN 301 234 "Digital Audio Broadcasting (DAB), Multimedia-Objekt-Transfer (MOT)-Protokol" definiert. Die Mulitmedia-Objekt-Daten, nachfolgend MOD-Objekte genannt, können beliebige Formate und Formen haben, wie Texte, Bilder, Videos etc.. Auch im Digital Radio Mondiale (DRM) wird das MOT-Protokoll benutzt.
Die Multimedia-Objekt-Daten werden hierbei in den sogenannten Program Associated Data (PAD) oder im sogenannten Packet-Mode eines DAB-Datenstroms übertragen. to einem DAB-Empfänger ist folglich eine MOT-Dekoder genannte Rekonstruktionseinheit am Ausgang des PAD-Dekoders und/oder Packet-Mode-Dekoders optional vorgesehen.
Das Multimedia-Objekt-Transfer (MOT)-Protokoll sieht vor, dass MOT-Objekte aus einem Kopfdatenteil mit Kopfkernteil von 7 Byte und Kopf-Erweiterungsteil und einem Rumpfdatenteil bestehen. Der Kopfdatenteil enthält Informationen über die Größe und den Inhalt des MOT-Objektes, so dass der Empfänger bestimmen kann, ob ausreichende Ressourcen zur Dekodierung und Präsentation des MOT-Objektes vorhanden sind. Der Kopferweiterungsteil enthält Informationen zur Unterstützung der Handhabung des MOT-Objekts, wie zum Beispiel Speicheranweisungen. Der Rumpfdatenteil beinhaltet die eigentlichen Daten des zu übertragenden Multimedia-Objektes.
Zur Übertragung eines MOT-Objektes wird dieses mindestens in ein separates Kopfsegment und ein separates Rumpfsegment aufgeteilt. Jedes Segment wird wiederum in mindestens eine Datengruppe segmentiert. Die Datengruppen werden dann unabhängig voneinander in den Transportdatenstrom eingebunden und einmalig oder wiederholt ausgesendet. Das Aussenden der Datengruppen kann beispielsweise zyklisch erfolgen, in dem zum Beispiel die Datengruppen eines MOT- Objektes zunächst nacheinander ausgestrahlt werden. Diese Header-Mode genannte Prozedur wird dann mehrfach wiederholt. Es ist auch denkbar, dass zunächst eine Datengruppe mehrfach ausgestrahlt wird und anschließend die folgende Datengruppe des MOT-Objektes wiederum mehrfach ausgestrahlt wird, solange bis sämtliche Datengruppen des MOT-Objektes übertragen sind. Bei der zyklischen Versendung der MOT-Objekte ist es nicht möglich, einen kompletten Überblick über alle MOT-Objekte im Empfänger zu haben, da die Informationen unabhängig und zeitlich gestreckt versendet werden.
Bei einer Übertragung von Gruppen von MOT-Objekten kann der Kopfdatenteil aller MOT-Objekte auch in einem MOT-Verzeichnis beschrieben werden. Die Kopfdatenteile der MOT-Objekte werden dann normalerweise nicht mehr einzeln gesendet. Man Spricht dann von einem Datenkarussell oder Directory-Mode. Dieses MOT-Verzeichnis beinhaltet neben lnformationen über das gesamte MOT-Verzeichnis, wie beispielsweise die Verzeichnisgröße, die Anzahl der im Datenkarussell enthaltenden Objekte, die Wiederholperiode des Datenkarussells, alle Kopfdateninformationen der MOT-Objekte, die im Datenkarussell als Gruppe zusammengefasst sind, und deren Transportidentifikationsnummer (Transport-Id).
Das MOT-Verzeichnis wird wie ein Objekt segmentiert und in Datengruppen übertragen. Zusätzlich wird das MOT-Verzeichnis entsprechend signalisiert, um es von den MOT-Rumpfdaten zu unterscheiden_ Das Problem hierbei ist die erforderliche relativ große Größe für das MOT-Verzeichnis durch die gesammelten Kopfdaten aller MOT-Objekte. Falls des MOT-Verzeichnis möglichst selten übertragen wird, um die benötigte Bandbreite zu reduzieren, führt dies jedoch zu einer relativ großen Verzögerung der Erkennung von Änderungen von MOT-Objekten.
Aufgabe der Erfindung ist es daher, ein verbessertes Verfahren zur Übertragung von Multimedia-Objekten zu schaffen.
Die Aufgabe wird mit dem gattungsgemäßen Verfahren erfindungsgemäß gelöst durch Übertragen von Veränderungen des MOT-Verzeichnisses oder von im MOT-Verzeichnis registrierten MOT-Objekten als Änderungsindex im Datenstrom.
Es wird somit vorgeschlagen, einen zusätzlichen Änderungsindex vorzusehen, der Veränderungen des MOT-Verzeichnisses oder Veränderungen von dem MOT-Verzeichnis registrierten MOT-Objekten kennzeichnet.
Dieser Änderungsindex kann dann zum Update der Kopfdatenteile der MOT-Objekte oder des aktuellen MOT-Verzeichnisses unabhängig von dem geänderten MOT-Verzeichnis, zusammen mit einem MOT-Verzeichnis, mit Kopfdateninformationen oder Rumpfdateninformationen von MOT-Objekten oder unabhängig davon übertragen werden, vorzugsweise erfolgt die Übertragung des Änderungsindex unabhängig von dem MOT-Verzeichnis, so dass Änderungen möglichst schnell an die Empfänger weitergeleitet werden.
Dies ist besonders dann vorteilhaft, wenn die Gruppe von MOT-Objekten beispielsweise in einem Detenkarussell wiederholt übertragen wird.
Vorzugsweise wird ein Änderungsindex gebildet und übertragen, wenn mindestens der Kopfdatenteil und/oder der Rumpfdatenteil eines MOT-Objektes bezogen auf ein entsprechendes früheres MOT-Objekt verändert ist.
Das Verfahren hat vorzugsweise die Schritte:

– Zuordnen von Versionsnummern zu dem MOT-Verzeichnis,
– Zuordnen von Slotnummern zu den Kopfdateninformationen für die MOT-Objekte in dem MOT-Verzeichnis, wobei die Slotnummern eine Sortierfolge der MOT-Objekte festlegen,
– Ändern der Versionsnummer des aktuellen MOT-Verzeichnisses, wenn eine Änderung des MOT-Verzeichnisses und/oder eines MOT-Objektes festgestellt wurde, und
– Aufnehmen eines Änderungsindex, wobei eine Änderung bezogen auf die Slotnummer des jeweils geänderten MOT-Objektes in dem Änderungsindex vermerkt wird.

Das Ordnen der in dem MOT-Verzeichnis vermerkten MOT-Objekte mit Hilfe von Slotnummern hat den Vorteil, dass Änderungen bezogen auf die Slotnummern in dem Änderungsindex eingetragen werden können, so dass durch Auswertung des Änderungsindex auf die Slotnummern der geänderten MOT-Objekte zurückgeschlossen werden kann. Mit Hilfe der Versionsnummern können zudem geänderte Versionen von MOT-Verzeichnissen, insbesondere geänderte Änderungsindizes im Empfänger erkannt werden.
Der Änderungsindex ist vorzugsweise eine Bitfolge mit jeweils einem Bit pro MOT-Objekt zur Kennzeichnung einer Anderung. Die Bits der MOT-Objekte in der Bitfolge sind dabei besonders vorteilhaft in der Reihenfolge der Slotnummern geordnet, so dass aus den einzelnen Bits sofort das zugeordnete MOT-Objekt geschlossen werden kann. Bei spielsweise wird für nicht geänderte MOT-Objekte das Bit "1" und für geänderte MOT-Objekte das Bit "0" gesetzt und diese Bits in der Reihenfolge der Slotnummern hintereinander geordnet. Der Änderungsindex ergibt somit einen einfachen binären Wert, der mit sehr geringem Datenaufwand übertragen werden kann.
Nichtgesetzte Bits in der Bitfolge können dann im Empfänger mit festgelegten Werten, insbesondere mit dem Wert für nichtgeänderte MOT-Objekte, aufgefüllt werden.
Weiterhin ist es vorteilhaft, Zusatzinformationen über die geänderten MOT-Objekte zusammen mit dem Änderungsindex zu übertragen. Dies können beispielsweise MOT-Parameter-Transport-Identifikationen (Transport-Id), Inhaltsnamen (content name) etc, sein.
Besonders vorteilhaft ist es, wenn die Differenz zwischen dem aktuellen MOT-Verzeichnis und dem geänderten MOT-Verzeichnis gebildet und der entsprechende Differenzwert als Änderungsindex übertragen wird. In einem Empfänger kann dann aus dem abgespeicherten aktuellen MOT-Verzeichnis und dem Differenzwert das geänderte MOT-Verzeichnis berechnet werden.
Die Aufgabe wird weiterhin mit einem digitalen Empfänger für Multimedia-Objekte (MOT-Objekte) mit einer Rekonstruktionseinheit zur Dekodierung von Multimedia-Objekt-Daten (MOD), die im MOT-Protokoll nach dem oben beschriebenen Verfahren übertragen werden, gelöst, indem erfindungsgemäß die Rekonstruktionseinheit zum Empfangen von Änderungsindizes und Erkennen und Aktualisieren von MOT-Verzeichnissen anhand der Änderungsindizes ausgebildet ist.
Die Erfindung wird nachfolgend anhand der beigefügten Zeichnungen näher erläutert. Es zeigen:
1 – Blockdiagramm eines DAB-Empfängers mit MOT-Dekoder
2 – schematische Darstellung der Aufteilung von Multimedia-Objekt-Daten in ein MOT-Objekt, in Datensegmente und in Datengruppen;
3 – Bitstruktur des MOT-Verzeichnisses gemäß Standard;
4 – schematischc Darstellung eines Datenkarussells mit MOT-Verzeichnis, MOT-Objekten, Versionsnummer und Änderungsindex.
Die 1 lässt ein Blockdiagramm eines Digital-Audio-Brodcast-Empfängers entsprechend der Definition des DAB-Standards EN 300 401 erkennen. Der DAB-Empfänger hat ein Hochfrequenzteil 1 mit einer nachfolgenden Signalverarbeitungseinheit 2 zur Signaldekodierung mit einer Fast-Fourier-Transformation FFT, mit einem Demultiplex-Verfahren und mit einer Kanaldekodierung. Der Audio-Datenstrom wird in einem Audiodekoder 3 dekodiert und mit Lautsprechern 4 wiedergegeben.
Weiterhin ist ein PAD-Dekoder 5 zur Dekodierung der Programm-Associated-Data PAD sowie ein Packet-Dekoder o zur Paketdekodierung vorgesehen. An dem Ausgang des PAD-Dekoders 5 sowie des Packet-Mode-Decoders sind dann Datensegmente gemäß der Definition des DAB-Standards verfügbar, die in einen Multimedia-Objekt-Transfer-Dekoder 7 geleitet werden. Mindestens dieser sogenannte MOT-Dekoder 7 ist mit einem Datenspeicher 8 gekoppelt, um die Daten der übertragenen Multimedia-Objekte abzuspeichern. Die Multimedia-Objekt-Daten MOD sowie möglicherweise Zusatzinformationen werden über eine weitere Datenverarbeitungseinheit 9 oder geeignete Software zur Wiedergabe bereitgestellt.
Die Multimedia-Objekt-Daten MOD werden gemäß dem Multimedia-Transfer-Protokoll segmentiert übertragen. Dies ist schematisch in der 2 dargestellt. Die Multimedia-Objekt-Daten MOD werden im Rumpfdatenteil eines MOT-Objektes in Rumpf-Datensegmente aufgeteilt. Ein MOT-Objekt hat ferner ein Kopfdatenkernteil sowie gegebenenfalls ein Kopfdatenerweiterungsteil gemäß der Definition des DAB-MOT-Standards EN 301 234. Der Kopfdatenteil wird wiederum in Datensegmente K-SEG aufgeteilt, die jeweils einen Segmentkopf SK sowie ein Segmentdatenteil SD haben. In dem Segmentkopf ist unter anderem die Segmentgröße verzeichnet.
Auch die Rumpfdatensegmente R-SEG werden in entsprechenden Datensegmenten mit Segmentkopf SK und Segmentdatenteil SD übertragen.
Die Datensegmente SEG werden in Datensegmente mit einem Datengruppenkopf DGH (Data-Group-Header) einem sogenannten Session-Header SH, einem Datengruppen-Datenfeld DG (Data-Group-Data-Field) sowie optional einer sogenannten MSC-Data-Group CRC übertragen. Der Datengruppenkopf DGH beinhaltet den Typ der Datensegmente SEG. So bezeichnet die Zahl 3 ein Kopfdatenteil sowie die Zahlen 4 und 5 ein Rumpfdatenteil.
Weiterhin ist in dem Session-Header SH eine Transportkennung (Transport-Id) vorhanden, die das zugehörige MOT-Objekt bezeichnet.
Die Datensegmente SEG sind somit in Bezug auf das MOT-Objekt identifizierbar.
Die einzelnen Datensegmente bzw. Datengruppen werden zeitlich unabhängig voneinander in den Transportstrom eingebunden und gegebenenfalls mehrfach hintereinander zyklisch übertragen.
Für eine solche wiederholte Übertragung einer Gruppe von MOT-Objekten wird optional ein MOT-Verzeichnis übertragen und in längeren Zeitabständen hintereinander in einem sogenannten MOT-Datenkarussell aktualisiert. Dann werden die Kopfdaten im MOT-Verzeichnis und normalerweise nicht mehr in eigenen Datengruppen übertragen. Ein Objekt kann in dem Verzeichnis gesucht und über den Content Name des gewünschten Objektes identifiziert werden. Gemäß der herkömmlichen Definition des MOT-Standards EN 301 234 erfolgt die Versionskontrolle der Objekte innerhalb des MOT-Datenkarussells durch Vergleich der Transport-Id und der Versionsnummer. Bei einer Änderung der MOT-Verzeichnis-Transport-Id wird üblicherweise erkannt, dass der Inhalt des Datenkarussells und damit ein MOT-Objekt geändert wurde.
Die 3 lässt die derzeit definierte Struktur des MOT-Verzeichnisses erkennen. In einem 2-Bit großen Feld RFU kann zukünftig die Strukturversion angegeben werden. In einem nachfolgendem 30-Bit großen Feld wird die gesamte Größe des MOT-Verzeichnisses angegeben (Directory-Size). Anschließend folgen auf 16 Bits die Anzahl der in dem MOT-Verzeichnis enthaltenen Anzahl von MOT-Objekten (Number of Objects). Es folgt auf 24 Bit die Datenkarussellperiode als maximale Zeit, die das Datenkarussell zur Vervollständigung eines Zyklusses benötigt. Zwei weitere Felder RFU und RFA sind für zukünftige Zwecke reserviert. Es folgt die Angabe der Segmentgröße (Segment-Size) in einem Feld von 13 Bits. Die Segmentgröße gibt die Anzahl von Bits an, die zur Segmentierung der MOT-Objekte innerhalb des MOT-Datenkarussells genutzt werden. Ein weiteres i 16-Bit großes Feld ist für die Verzeichniserweiterungslänge (Directory Extension Length) vorgesehen, um die gesamte Anzahl der nachfolgenden Verzeichnis-Erweiterungs-Bits anzugeben. Es folgt die Verzeichniserweiterung mit einer Liste von Parametern, die zur Beschreibung des gesamten Datenkarussells benötigt werden. Die Struktur dieser Parameter entspricht der Definition der MOT-Header-Extension-Parameter und sieht einen Parameter-Längen-Indikator PLI, eine Parameterkennung (Paremeter-Id), ein Erweiterungsflag (EXT), einen Datenfeld-Längenindikator (Date-Field-Lengts-lndicator) sowie ein Datenfeld (Data-Field) vor.
Es folgen eine Anzahl von Verzeichniseinträgen, wobei für jedes MOT-Objekt ein Verzeichniseintrag (Directory-Entry n) vorgesehen ist. Jeder Verzeichniseintrag enthält eine Transportkennung (Transport-Id) zur Identifizierung des MOT-Objektes, zu dem der folgende MOT-Kopfdatenteil (MOT-Header) gehört. Der folgende MOT-Header enthält den Kopfdatenteil und gegebenenfalls den Kopfdatenerweiterungsteil des Objektes. Die Codestruktur des MOT-Headers entspricht exakt MOT-Headern in den Datengruppen.
Der Kopfdatenteil enthält die Rumpfdatengröße (Body-Size), die Kopfdatengröße (Header-Size), die Inhaltsart (Content-Type), d.h. die Kategorie der Rumpfdateninhalts, sowie einen Inhaltsuntertyp (Content-Sub-Type).
Auch im Header-Mode existiert ein Verzeichnis, das allerdings lokal im Empfänger und Sender aus den einzelnen Kopfdatenteilen als Liste aufgebaut wird. Im Weiteren wird diese Liste auch als MOT-Verzeichnis bezeichnet.
Darüber hinaus wird nun vorgeschlagen, einen Änderungsindex für ein solches MOT-Verzeichnis zu erzeugen und im Datenstrom zu übertragen. Dieser Änderungsindex wird vorzugsweise mit einem eigenen Kopfdatenteil als sehr kleiner und damit schnell empfangbarer Header übertragen, so dass Voränderungen des MOT-Verzeichnisses durch diesen Änderungsindex schneller signalisiert werden können.
Um die Änderungen einem bestimmten MOT-Objekt zuordnen zu können werden die einzelnen Kopfdatenteile der MOT-Objekte im MOT-Verzeichnis in virtuelle Slots einsortiert. Diese werden durch einen zusätzlichen Parameter im Kopfdatenteil (MOT-Slot-Nr) festgelegt. Alle MOT-Objekte haben eine eigene Slotnummer, wobei doppelte Slotnummern nicht zugelassen sind. Nur bei einer Änderung eines MOT-Objektes darf dessen Slotnummer geändert werden.
Mit jeder Änderung eines MOT-Objekts wird die im MOT-Verzeichnis vorgesehene Versionsnummer inkrementiert. Dann wird ein Differenzwert für jede alte Versionsnummer des MOT-Verzeichnisses berechnet. Dieser Wart kann ein Bitwert sein, wobei jedem nicht geänderten Objekt eine "1" und jedem geänderte Objekt eine "0" zugeordnet wird. Eine Änderung tritt bei einem anderen Inhalt des MOT-Objektes, dem sogenannten Rumpfdatenteil (Body) ein. Es ist auch möglich eine Änderung schon bei neuen Objektparametern im Kopfdatenteil eines MOT-Objekts aber gleichem Inhalt im Rumpfdatenteil zu signalisieren.
Die Übertragung von MOT-Objekten in einem MOT-Datenkarussell 10 mit MOT-Verzeichnis 11 wird anhand eines in der 4 skizziertem Beispiels aus Sicht des Serviceproviders beschrieben.
Dabei werden die MOT-Objekte mit "A", "B", "C", "D", "E", "F" und "G" bezeichnet. Die Versionsnummern der MOT-Verzeichnisse 11 werden als laufende Nummer 1 bis N festgelegt und als Eintrag im je weiligen MOT-Verzeichnis 11 übertragen. Ein Datum mit Uhrzeit als Versionsnummer ist auch denkbar.
In der Versionsnummer 1 des MOT-Verzeichnisses 11 sind zunächst die MOT-Objekte A, B, C und D vorgesehen, die im MOT-Datenkarussell 10 zeitlich hintereinander wiederholt übertragen werden. Es ist auch denkbar, dass zunächst das MOT-Objekt "A" mehrfach hintereinander, dann das MOT-Objekt "B" mehrfach hintereinander, dann das MOT-Objekt "C" mehrfach hintereinander und schließlich das MOT-Objekt "D" mehrfach hintereinander gesendet wird, wobei auch diese Abfolge mehrfach wiederholt werden kann.
Die Aktualisierung der MOT-Verzeichnisse 11 erfolgt mit MOT-Parametern 12 als sogenannte MOT-Verzeichnis-Aktualisierungen, die als MOT-Parameter im Datenstrom an einen Empfänger 13 übertragen werden.
10:00 Uhr Beginn des Services:
Zu Beginn des Services um 10 Uhr hat das MOT-Verzeichnis 10 die Versionsnummer 1. Als Änderungsindex zur aktuellen Version des MOT-Verzeichnisses 10 ist für jedes MOT-Objekt in der Reihenfolge der Slotnummern der MOT-Objekte eine binäre "1" eingetragen. Das bedeutet, dass die MOT-Objekte unverändert sind.
11:00 Uhr:
Um 11 Uhr wird ein MOT-Verzeichnis 11 mit der Versionsnummer 2 übertragen, wobei nunmehr die MOT-Objekte A, E, C, und D übertragen werden. Das MOT-Objekt "B" wurde somit durch das MOT-Objekt "E" getauscht. Der Änderungsindex in der aktuellen Versionsnummer 2 des MOT-Verzeichnisses 11 sieht für die MOT-Objekte den Eintrag "1" vor, d.h. im Vergleich zur aktuellen Version liegt keine Änderung vor.
Für das vorhergehende MOT-Verzeichnis 11 mit der Versionsnummer 1 ist im Änderungsindex an der zweiten Stelle für das MOT-Objekt "B" an der Slotnummer/Slotposition 2 ein Eintrag "0" vorgesehen. Aus der Bitfolge des Änderungsindex ist somit erkennbar, dass das zweite MOT-Objekt "B" geändert wurde.
Um 12 Uhr wird ein neues MOT-Verzeichnis 11 mit der Versionsnummer 3 übertragen, in dem die MOT-Objekte A, E, F, D vorgesehen sind. Der Änderungsindex zu dieser aktuellen Versionsnummer 3 des MOT-Verzeichnisses 11 sieht wiederum die Einträge "1" für sämtliche MOT-Objekte vor, da diese bewogen auf die aktuelle Versionsnummer 3 des MOT-Verzeichnisses 11 unverändert sind.
12:00 Uhr;
Das vorhergehende MOT-Verzeichnis 11 mit der Versionsnummer 2 beinhaltet nunmehr einen auf die aktuelle Versionsnummer 3 bezogenen Änderungsindex, bei dem für die dritte Slotnummer eine binäre "0" eingetragen ist, Das dritte MOT-Objekt "C" wurde nämlich in dem neuen MOT-Verzeichnis 11 mit der Versionsnummer 3 in das MOT-Objekt "F" geändert. Sämtliche anderen MOT-Objekte sind gleich geblieben, so dass im Änderungsindex hierfür eine "1" eingetragen ist.
Für das MOT-Verzeichnis 11 mit der Versionsnummer 1 wird der Änderungsindex, der auf die aktuelle Versionsnummer 3 des MOT-Verzeichnisses 11 bezogen ist, folglich dahingehend geändert, dass für die zweite Slotnummer und dritte Slotnummer eine Änderung durch den binären Eintrag "4" eingetragen wird. Die erste und vierte Slotnummer des Änderungsindex bleibt hingegen unverändert.
Um 13 Uhr wird ein weiteres MOT-Verzeichnis 11 mit der Versionsnummer 4 übertragen. Hierbei wird das dritte MOT-Objekt "F" in das MOT-Objekt "G" getauscht, so dass in dem Änderungsindex an der dritten Position eine Änderung in den vorhergehenden Versionen des MOT-Verzeichnisses 11 vermerkt wird.
13:00 Uhr:
Zusammen mit der jeweiligen Versionsnummer wird der Änderungsindex nun in einem entsprechend signalisierten Kopf vorzugsweise mit den Inhalten "Content Type: MOT-Transport, Content Sub Type: Directory Update" übertragen.
Die MOT-Parameter im Kopfdatenteil sind wie folgt:
In dem Header werden nur die vorherigen Versionen des MOT-Verzeichnisses 11 gesendet. Als Optionen können Versionsnummern ausgelassen werden, falls es keinen Unterschied zum vorherigen Änderungsindex gibt, beispielsweise zwischen 12 und 11 Uhr zu 13 Uhr. In diesem Fall wird die ältere Versionsnummer geschickt und der Empfänger nimmt automatisch die nächst erreichbare vorherige Version des MOT-Verzeichnisses 11.
Desweiteren ist der Änderungsindex der aktuellen Version immer „1", also redundant. Dieses Index muß also auch nicht gesendet werden.
Die gesendeten optimierten MOT-Parameter 12 für die MOT-Verzeichnis-Änderungen um 13 Uhr sind beispielsweise wie folgt:
Falls auf Empfängerseite die jeweilige lokale Version des MOT-Verzeichnisses 11 nicht verfügbar ist und auch keine ältere Version, kann entweder eine Komplettänderung des MOT-Verzeichnisses 11 angenommen oder darauf geschlossen werden, dass auf das komplette MOT-Verzeichnis 11 gewartet werden muss.
Eine Möglichkeit der Komprimierung bei der Datenübertragung besteht nun darin, für nicht übertragene Slotnummern der jeweiligen Version einen Standard-Wert anzunehmen. Zum Beispiel können alle fehlenden Nummern als unverändert festgelegt werden. Dies gilt allerdings nur für die Slotnummern am Ende des MOT-Verzeichnisses 11. Da die eigene Länge des MOT-Verzeichnisses 11 bekannt ist, können die fehlenden Werte des Änderungsindex einfach im Empfänger aufgefüllt werden.
Beispiel mit Komprimierung um 13:00 Uhr (Figur 4d):
Desweiteren kann ein Änderungsindex auch aus identischen Teilen oder Stücken neuerer Indexe zusammengesetzt werden.
Ein Empfänger 13 wird diesen Header 12 sehr viel schneller empfangen können, als das gesamte aktuelle MOT-Verzeichnis 11. So kann im Empfänger 13 aus den Informationen im Header 12 die Version des lokalen MOT-Verzeichnisses 11 herausgesucht und alle geänderten MOT-Objekte sofort aus der inzwischen veralteten, aber im Empfänger einzig verfügbaren MOT-Verzeichnisliste 11 gelöscht werden. Alte MOT-Objekte müssen auf diese Weise dem Benutzer nicht angeboten werden.
Weiterhin besteht die Möglichkeit, detailliertere Informationen zu den geänderten MOT-Objekten mit den Differenzwerten zusammen zu senden. So können zum Beispiel die MOT-Parameter Transport-Id, Content-Name etc. in dem MOT-Directory Update gesendet werden.
Es kann auch ein kompletter Differenzwert des aktuellen MOT-Verzeichnisses 11 erzeugt werden, in dem der binäre Wett des aktuellen MOT-Verzeichnisses 11 von dem binären Wert des vorhergehenden MOT-Verzeichnisses 11 subtrahiert wird. Dieser Differenzwert wird nun als Änderungsindex übertragen. Im Empfänger kann nun aus dem Differenzwert und dem im Empfänger vorhandenen alten MOT- Verzeichnis 11 das aktuelle MOT-Verzeichnis 11 mit allen Einträgen durch Aufsummieren des Differenzwertes berechnet werden.
Das Update des MOT-Verzeichnisses 11 kann getrennt mit dem MOT-Verzeichnis 11 oder auch zusammen damit gesendet werden. Es kann entweder mit dem MOT-Verzeichnis 11 und den MOT-Objekten, mit den MOT-Headern und den MOT-Objekten, oder mit dem MOT-Verzeichnis 11, den MOT-Headern und den MOT-Objekten gesendet werden.
Allerdings können neue MOT-Objekte erst nach dem Empfang des neuen MOT-Verzeichnisses 11 präsentiert werden, da erst dann alle Parameter bekannt sind. Es ist allerdings anzunehmen, dass die Dekodierung dieser neuen Objekte sowieso länger dauert, als der Empfang des neuen MOT-Verzeichnisses 11.
Zusätzlich können die geänderten Kopfdatenteile der geänderten MOT-Objekte auch vor einem MOT-Objekt gesendet und somit der Header-Mode benutzt werden, so dass nicht bis zum vollständigen Empfang des MOT-Verzeichnisses 11 gewartet werden muss.
Als Erweiterung kann auch ganz auf die Übertragung des MOT-Verzeichnisses 11 verzichtet werden. Die MOT-Objekt Kopfdaten weiden dann einzeln im Header-Mode übertragen. Der Änderungsindex dient dabei als verbindende Klammer über alle Objekte.
Mit dem vorgeschlagenen MOT-Verzeichnis-Update kann das MOT-Verzeichnis 11 sehr viel seltener als bisher gesendet werden, so dass der benötigte Overhead erheblich verringert wird. Zusätzlich sind Änderungen im Datenkarussell 10 schneller beim Empfänger verfügbar.

Claims

Verfahren zur Übertragung von Multimedia-Objekten (MOT-Objekte) digital kodiert im Multimedia-Objekt-Transfer (MOT)-Protokoll, wobei MOT-Objekte jeweils einen Kopfdatenteil mit Informationen über das zugeordnete MOT-Objekt und einem Rumpfdatenteil haben, und wobei für eine Gruppe von MOT-Objekten ein MOT-Verzeichnis (11) mit Informationen über alte MOT-Objekte der Gruppe vorgesehen ist, gekennzeichnet durch Übertragen von Veränderungen des MOT-Verzeichnisses (11) oder von im MOT-Verzeichnis registrierten MOT-Objekten als Änderungsindex im Datenstrom.
Verfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch Bilden und Übertragen eines Änderungsindex, wenn mindestens der Kopfdatenteil und/oder der Rumpfdatenteil eine MOT-Objektes bezogen auf ein entsprechendes früheres MOT-Objekt verändert ist.
Vorfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch – Zuordnen von Versionsnummern zu dem Verzeichnis, insbesondere dem MOT-Verzeichnis (11), – Zuordnen von Slotnummern zu den Kopfdateninformationen für die MOT-Objekte in dem MOT-Verzeichnis (11), wobei die Slotnummern eine Sortierfolge der MOT-Objekte festlegen, – Ändern der Versionsnummer des aktuellen MOT-Verzeichnisses (11), wenn eine Änderung des MOT-Verzeichnisses (11) und/oder eines MOT-Objektes festgestellt wurde, und – Aufnehmen eines Änderungsindex, wobei eine Änderung bezogen auf die Slotnummer des jeweils geänderten MOT-Objektes in dem Änderungsindex vorgemerkt wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Änderungsindex eine Bitfolge mit jeweils einem Bit pro MOT-Objekt zur Kennzeichnung einer Änderung ist.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Einträge des Änderungsindex für die MOT-Objekte in der Reihenfolge der Slotnummern geordnet sind.
Verfahren nach einem vorhergehenden Ansprüche, gekennzeichnet durch Auffüllen von nicht gesetzten Bits in der Bitfolge des Änderungsindex mit festgelegten Werten und/oder Auffüllen von nicht gesetzten Bits aus Bestandteilen jüngerer Änderungsindizes.
Verfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch Vergleichen des Änderungsindex einer nachfolgenden Version eines MOT-Verzeichnisses (11) mit der vorhergehenden Version und Auslassen der nachfolgenden Version bei dem Senden von MOT-Verzeichnissen (11), wenn der Änderungsindex gleich ist.
Verfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch Übertragen von Zusatzinformationen über die geänderten MOT-Objekte zusammen mit dem Änderungsindex.
Verfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch Bilden der Differenz zwischen dem aktuellen MOT-Verzeichnis (11) und dem geänderten MOT-Verzeichnis (11) und Übertragen des Differenzwertes als Änderungsindex, wobei in einem Empfängor aus dem abgespeicherten aktuellen MOT-Verzeichnis (11) und dem Differenzwert das geänderte MOT-Verzeichnis (11) berechenbar ist.
Digitaler Empfänger für Multimedia-Objekte (MOT-Objekte) mit einer Rekonstruktionseinheit zur Dekodierung von Multimedia-Objekt-Daten (MOD) die im MOT-Protokoll nach dem Verfahren mach einem der vorhergehenden Ansprüche übertragen werden, wobei MOT-Objekte jeweils einen Kopfdatenteil mit Informationen über das zugeordnete MOT-Objekt und einen Rumpfdatenteil haben, und wobei für eine Gruppe von MOT-Objekten ein MOT-Verzeichnis (11) mit (Informationen über alle MOT-Objekte der Gruppe vorgesehen ist, dadurch gekennzeichnet, dass die Rekonstruktionseinheit zum Empfangen von Änderungsindizes und Erkennen und Aktualisieren von MOT-Verzeichnissen (11) anhand der Änderungsindizes ausgebildet ist.