5.2.2   Data Recovery Bei einem Synchronisationsfehler kommt es zu einem meist großen Verlust von aufeinander- folgenden Daten, bedingt durch die Zeitspanne, in der die Resynchronisation durchgeführt wird. Eine Methode zur Wiedergewinnung von zumindest einem Teil der Daten liefert das Reversible Variable Length Coding (RVLC). Dabei wird in dem verlorenen Datenintervall zu- erst vom Anfang solange versucht zu dekodieren, bis auf einen Fehler gestoßen wird. Dasselbe wird vom Ende her wiederholt, so dass nur das Fehlerintervall als Bündelfehler (Burstfehler) übrigbleibt. 5.2.3   Error Concealment Beim Verlust von Videodaten ist es wünschenswert, diese zumindest annähernd dem Original entsprechend wiederzugeben und dem Betrachter zu suggerieren, es sei kein Fehler aufgetre- ten. Hier sollen zwei Strategien angesprochen werden: Kopieren von Daten vorhergehender Frames und das Trennen der Bild und Bewegungsdaten (Data Partitioning). Die erste Stra- tegie macht genau das, was man vermutet. Der fehlerbehaftete Teil wird durch den entspre- chenden Block des vorherigen Bildes ersetzt. Einen anderen Weg verfolgt die zweite Strategie. Durch die Trennung von Bewegungsdaten und Bilddaten kann (bei Verlust der Bilddaten) durch die vorhandene Bewegungsinformation der Ablauf wiedergewonnen werden. Falls auch die Bewegungsinformationen verloren gehen, ist diese Methode natürlich nicht anwendbar. 5.2.4   Weitere Ansätze Die bisher besprochenen Maßnahmen zur Erkennung und Beseitigung von Fehlern arbeiten alle auf Encoder/Decoder-Ebene. Dies ist bedingt durch die Unabhängigkeit vom Transport- medium, siehe auch Abschnitt 3.2.1. Es gibt Problemstellungen, bei denen diese Methoden nicht unbedingt sinnvoll sind. Dazu zählen: •  Synchronisation von MPEG-4 mit Medien anderer Art. •  Bei bereits kodierten MPEG-4 Daten muss sich darauf verlassen werden, dass Fehler- _{^robustheit”}eingebaut“ wurde. Es soll nun noch ein weiterer Ansatz aus [GuWC99] angesprochen werden. Die Protokol- lunabhängigkeit wird aufgegeben und ein bereits spezifiziertes Protokoll zur Übertragung eingesetzt: das  Real-Time Transport Protocol  (RTP). RTP bietet mit Synchronisationsme- chanismen, Unterstützung von Nutzdaten-Typen¹³  sowie dem Real-Time Transport Control Protocol  (RTCP) die Vorraussetzungen für die Versendung von Streaming-Daten aller Art. Es müssen somit nicht die Methoden des DMIF Layers genutzt werden. Um nicht für jede mögliche Stream-Art einen neuen Nutzdaten-Typ definieren zu müssen, soll ein generischer Nutzdaten-Typ entworfen werden, der für jeglichen MPEG-4-Daten-Stream nutzbar ist. Wei- terhin ist die unterschiedliche Priorität von Streams nicht zu vernachlässigen. Da ein Stream mit Kontrollinformationen sicherlich eine höhere Prioritätsstufe bekommt als ein Stream mit reinen Dateninformationen, müssen verschiedene Stufen der Absicherung gegen Fehler vor- genommen werden. Die Realisierung  übernimmt ein statt des DMIFs eingeführter Network Adaption Layer (NAL), siehe Abbildung 7. Dieser NAL nimmt Streaming-Daten in Form von AUs oder PDUs entgegen und fügt zusätzliche Redundanz in Form von Blockcodes oder ähn- lichem hinzu. Um die ihm übergebenen Pakete korrekt einzustufen, muss das von MPEG-4 ¹³Die Art des übermittelten Streams 9