MPEG-4-Video Standard Seite 65 von 103 Technische Informatik 10.10.2003 Je   nach   Index-Wert   beschreibt   SDL   einen   unterschiedlichen   FlexMux-Mode.   Mit Werten von 0 bis 237 wird der Simple-Mode beschrieben (Abb.31), der für SL-Pakete (Sync  Layer)  variabler  Länge  gedacht  ist.  Jeder  FlexMux-Kanal  kennzeichnet  hierbei einen SL-Strom. Der Overhead beträgt nur 2 Bytes.   index-Werte zwischen 240 und 255 kennzeichnen den MuxCode-Mode, der es erlaubt SL-Pakete  verschiedenster  Ströme  zu  einem  einzigen  FlexMux-Paket  (hinterlegt  in Slots)   mit   einem   Overhead   von   3   Bytes,   zu   verknüpfen.   Dieser   Modus   wird hauptsächlich  bei  Sprach-Kodierungen  mit  sehr  niedrigen  Bitraten  eingesetzt.  Die MuxCodeTableEntry  zum  MuxCode-Table  (mit  bis  zu  16  Einträgen  für  MuxCode- Layouts)  signalisiert  die  Länge  der  einzelnen  SL-Pakete  innerhalb  eines  TransMux- Pakets.   index-Werte mit 238 und 239 stehen für spezielle Kanäle. index=239 markiert einen FlexMux-Kanal,  der  zum  Einlagern  von  Füll-Bytes,  für  den  Erhalt  konstanter  Bitraten, genutzt wird. FlexMux-Kanal 238 widmet sich dem Timing der Zustellung von FlexMux- Strömen. Seine Pakete tragen zwei Elemente, die FlexMux Clock Reference (FCR) und die  gegenwärtige  Bitrate  des  Stroms,  wobei  die  FCR  annähernd  die  selbe  Semantik verwendet  wie  die  Object  Clock  Reference  (OCR)  in  einem  SL-Strom.  Über  eine regelmäßige  Eingabe  von  FCR-Werten,  in  Verbindung  mit  der  Bitrate,  lässt  sich  das Timing  des  FlexMux-Stroms  schließlich  festlegen.  Kontrolliert  wird  das  Zustellungs- Timing  hauptsächlich  in  Applikationsszenarien,  in  denen  geringe  Verzögerungen  und eine präzise Bufferkontrolle erwünscht ist. Hierfür setzt sich auch das System Decoder Model  (SDM  –  4.3.3)  ein,  wo  jeder  FlexMux-Kanal  ein  FlexMux-Buffer  zugewiesen bekommt  und  dessen  Füllung  von  der  maximalen  Bitrate  des  entsprechenden  ES abhängt (wird im ES-Descriptor fest-gelegt). Letztlich ist es aber Aufgabe der MPEG-4- Anwendung den FlexMux-Buffer vor dem Überlauf zu schützen. 5.2 MP4 Dateiformat Frühere  MPEG-Versionen  haben  kein  eigenes  explizites  Dateiformat.  MPEG-1-  und MPEG-2-Inhalte  werden  typischerweise  über  Container  (z.B.  AVI)  transportiert,  deren Datenströme bereits fertig für die Zustellung sind. Sie beinhalten absolute Zeit-Stempel und sind oft für eine bestimmte Transportart ausgelegt, was den Random Access,  das Bearbeiten        und    das    Wiederverwenden    von    Strömen    ohne    Decodierung    und Demultiplexing   oft   schwierig   gestaltet.   Deshalb   wurde   das   neue   MP4-Format   so entwickelt,  dass  es  MPEG-4-Ströme  in  einer  flexiblen  und  erweiterbaren  Form  für  den Austausch,  das  Management,  die  Bearbeitung  und  die  Präsentation  des  Mediums archiviert.  Dabei  können  die  Daten  lokal  zum  System  gespeichert  sein  oder  über  ein Netzwerk   oder   andere   Übertragungsmechanismen   bezogen   werden.   MP4   ist   zwar unabhängig  von  jedem  Zustellungs-Protokoll,  bietet  aber  eine  breite  Unterstützung  für jede Art von Datenübermittlung. QuickTime® von Apple kam all diesen Anforderungen am  nächsten,  weshalb  man es,  nach  einer Phase der  Festlegung  von  Anforderungen, als Grundlage für das neue MP4-Format wählte.   Das ungewöhnlichste an diesem neuen Format ist die Trennung von Mediendaten (z.B. Videodaten)  von  dessen  Metadaten,  also  Informationen  über  die  Daten,  wie  Timing- Informationen,   Bitraten   oder   dessen   Herkunft.   Diese   werden   in   separaten   Tables hinterlegt  und  erleichtern  so  das  Handling  der  einzelnen  Ströme. Erleichtert  wird  auch deren Bearbeitung, indem auf ein relatives Zeitmanagement (vgl. 4.3) gesetzt wird. Das bedeutet  Zeitstempel  müssen  nicht  erneuert  werden,  wenn  ein  Frame  neu  eingefügt oder gelöscht wurde. Wenn Daten gestreamt werden, geben spezielle Instruktionen, die in   der   Datei   gespeichert   sein   können,   protokollspezifische   Anweisungen   über   die