-
Stand der
Technik
-
Digitale
Datenströme,
wie z.B. nach dem MPEG2 Standard ISO/IEC 13818-1, sind oft in Pakete
zerstückelt.
Dabei sind bestimmte Informationen, wie z.B. Zeitangaben, nur in
bestimmten Paketen enthalten. Insbesondere definiert der genannte
Standard die Struktur eines Transportdatenstroms (TS). Ein MPEG2-TS
Datenstrom ist ein paketorientierter Strom, der aus aufeinanderfolgenden
Transportpaketen („Transport
Stream Packets",
TSP) besteht. Ein TSP besteht aus einem Kopf („Header") und Transportdaten, die wiederum einen Teil
eines Pakets (PES-Packet) aus einem paketorientierten Elementardatenstrom
(Packetized Elementary Stream, PES) darstellen. Um ein ganzes PES-Packet
zu erhalten, müssen
die einzelnen Teile aus aufeinanderfolgenden zusammengehörigen TSPs
extrahiert und zusammengefügt
werden, ohne dabei die Reihenfolge der TSPs zu verändern. Ein
PES-Packet besteht aus Header-Informationen und einem Datenfeld.
Das Datenfeld kann z.B. ein Teil eines Videodatenstroms oder eines
Audiodatenstroms sein. Um einen solchen Datenstrom nach Informationen
zu durchsuchen (Scannen), muss jedes Paket untersucht werden, was
viel Zeit in Anspruch nimmt. Desweiteren können umfangreiche Auswertungen
nötig sein,
z.B. Fehlerüberprüfung oder Fehlerkorrektur.
-
Erfindung
-
Um
in einem paketorientierten Datenstrom nicht jedes Paket untersuchen
zu müssen,
wird eine Info-Datei (Info-File) erzeugt, welche beim Scannen des
Datenstroms behilflich ist. Dabei werden jeweils die Offsets, d.h.
der Versatz, in Paketen und Bytes, zu markanten Informationen abgelegt.
Der Datenstrom und die Info-Datei werden parallel, d.h. gleichzeitig,
gescannt und anhand der Info-Datei erkennt man, wieviele Pakete bzw.
Bytes im Datenstrom übersprungen
werden können,
um zur nächsten
spezifizierten Position mit der gewünschten Information oder zum
nächsten
markanten Einsprungpunkt zu gelangen. Gleichzeitig können im
Info-File weitere
Informationen zum jeweiligen Datenpaket abgelegt werden, welche
in umfangreicheren Prozeduren aus dem Datenstrom ausgewertet werden
müssen.
Dadurch müssen
diese Prozeduren nur einmal ausgeführt werden. Das kann schon
im Studio sein, oder in einem Aufnahmegerät beim Anwender, während der Aufnahme
oder später
in einer Nachbearbeitung. Dazu reicht es im Prinzip, wenn das Gerät die Info-Datei
aufnehmen und den aufgenommenen Datenstrom nur abspielen kann. Ein
erfindungsgemäßes Info-File
ermöglicht
ein nahezu verzögerungsfreies
Scannen des Datenstroms und damit einen enormen Zeitvorteil bei
der Informationsextrahierung und beim Anspringen einer bestimmten
Position im Datenstrom.
-
Ein
erfindungsgemäßes Info-File
zum Durchsuchen von paketorientierten Datenströmen besteht aus einer Folge
von Info-Blöcken. Jeder
Info-Block wird mit einem zugehörigen
Paket im Datenstrom assoziiert. Er beinhaltet zwei Komponenten:
Erstens den Offset, d.h. nach wie vielen Paketen bzw. Bytes das
nächste
Datenpaket assoziiert mit dem nächsten
Info-Block kommt,
und zweitens zusätzliche
Informationen zum aktuell zugehörigen
Datenpaket, z.B. den jeweiligen Zeitstempel (timestamp).
-
Damit
ein Info-File auch variable Datenraten und unterschiedliche Paketgrößen besser
unterstützen kann,
enthält
ein Info-Block den Versatz oder Offset zum nächsten relevanten Paket sowohl
in Paketen als auch in Bytes. Dabei wäre eine der beiden Angaben
im Prinzip ausreichend.
-
Weiterhin
sind die Offsets relativ, so dass ein erfindungsgemäßes Info-File
Datenströme
beliebiger Größen unterstützen kann.
Im Gegensatz zu absoluten Offsets, die sich auf den Beginn des Stroms
beziehen, besteht dann eine Begrenzung durch die Offsetgröße nur in
dem Abstand zweier Datenpakete, nicht aber in der Dateilänge.
-
Das
Info-File kann insbesondere zum schnellen Vor- und Rückwärtsspulen
in paketorientierten Datenströmen
eingesetzt werden, wo es erhöhte
Flexibilität
ermöglicht.
Durch die Verwendung eines Info-Files erfolgt das Scannen in paketorientierten
Datenströmen
wesentlich schneller, da uninteressante bzw. irrelevante Pakete
im Datenstrom übersprungen
werden können,
insbesondere solche Pakete des Transportdatenstroms, die zu anderen
Elementardatenströmen
gehören
oder keine PES-Packet Header enthalten. Außerdem können die Ergebnisse komplizierter
Berechnungen als Zusatzinformationen im Info-File gespeichert werden,
so dass die Berechnungen nur noch einmal, z.B. beim Erstellen des
Info-Files, durchgeführt
zu werden brauchen. Die Verwendung eines Info-Files wird umso wirkungsvoller,
je mehr Pakete im Datenstrom übersprungen
werden und je schwieriger die Extraktion gewünschter Informationen aus dem
Datenstrom ist.
-
Eine
Vorrichtung zum Vorrichtung zum Vor- oder Zurückspulen innerhalb eines Elementardatenstroms,
der aus Datenpaketen unterschiedlicher Größe besteht, wobei diese Datenpakete
aus anderen Datenpaketen konstanter Größe, z.B. TDPs, eines Transportdatenstroms
extrahiert werden, und wobei ein Dateizeiger eine aktuelle Position
innerhalb des Transportdatenstroms anzeigt, enthält mindestens ein Speichermedium,
aus dem die Position derjenigen TDPs des Transportdatenstroms abgerufen
wird, welche die Anfänge bzw.
Header der Datenpakete des Elementardatenstroms enthalten, weiterhin
eine Vorrichtung, z.B. Prozessor, zur Berechnung der Position eines
anderen TSPs innerhalb des Transportdatenstroms aus der Position des
Dateizeigers und der aus dem Speichermedium abgerufenen Positionsangabe
bzw. Offset des anderen TDPs, und schließlich eine Vorrichtung zum
Setzen des Dateizeigers auf die berechnete Position innerhalb des Transportdatenstroms.
-
Vorteilhafte
Ausführungsformen
der Erfindung werden in den Ansprüchen, der folgenden detaillierten Beschreibung
und den Zeichnungen beschrieben.
-
Zeichnungen
-
Beispielhafte
Ausführungsformen
der Erfindung werden in den im folgenden beschriebenen Zeichnungen
skizziert. Darin zeigen
-
1 den
Aufbau eines MPEG-2 TS Datenstroms;
-
2 den
allgemeinen Aufbau einer Info-Datei;
-
3 eine
Info-Datei für
einen MPEG-2 TS Datenstrom; und
-
4 ein
Struktogramm der ParsePacket() Funktion.
-
Ausführungsbeispiele
-
Die
Erfindung wird am Beispiel eines Parsers für ein MPEG-2 Speicher- und
Wiedergabegerät
(Digital Storage Device, DSD) erläutert, das im folgenden als
DSD-MPEG2-Parser bezeichnet wird.
-
Der
DSD-MPEG2-Parser untersucht einen Strom von MPEG-2 TS Daten, bestehend
aus TSPs, und versucht, aus den darin enthaltenen Teilen von PES-Packets
komplette PES-Packets zusammenzusetzen. Dabei können die TSPs zu verschiedenen
PES-Packets gehören,
die verschiedene Elementardatenströme ergeben. Ein vereinfachter
MPEG-2 Transportdatenstrom MTS und zugehörige Elementardatenströme PES1,PES2
sind in 1 schematisch dargestellt. Der
Transportdatenstrom MTS besteht aus MPEG-2 Transportpaketen TSP,
die jeweils Header und Daten bzw. Payload enthalten. Diese Payload
stellt Teile von PES-Packets dar, die wiederum aus Header und Daten
bzw. Payload bestehen. Die zusammengehörigen PES-Packets PP#1,PP#2
ergeben Elementardatenströme
PES1, PES2, von denen z.B. einer Video- und der andere Rudiodaten
enthalten kann.
-
Der „start_code_prefix" im Header eines
PES-Packets ist 24 bit breit und hat den festen Wert 000001hex. Die nachfolgende „stream_id" gibt an, welchen Typ der mitgeführte Datenstrom („PES_packet_data_byte") hat. Dieser liegt
bei einem Videostrom im Bereich von E0hex bis
EFhex bzw. bei einem Audiostrom im Bereich
von C0hex bis DFhex.
-
Der
Parser untersucht das „payload_unit_start_indicator"-Flag aus dem Header des TSPs auf den Wert
1, und den Datenbereich eines solchen TSPs auf den Wert 00000001hex, entsprechend dem „start_code_prefix" des PES-Packets,
auf 32 bit expandiert. Haben beide Felder die erwarteten Werte,
so erkennt der Parser, dass im aktuellen TSP ein neues PES-Packet beginnt.
-
Ein
PES-Packet kann einen „Presentation
Time Stamp" (PTS)
und einen „Decoding
Time Stamp" (DTS)
mit sich führen.
Der PTS gibt an, zu welchem Zeitpunkt die mitgeführten Daten angezeigt werden
sollen, und der DTS gibt Auskunft über den Decodierungszeitpunkt
der Daten. Das ebenfalls im Header des PES-Packets enthaltene „PTS_DTS_flag" gibt an, ob sich
ein PTS oder DTS im PES-Packet befindet. Der ISO/IEC13818-1 Standard
schreibt einen Abstand von höchstens
0.7s zwischen aufeinanderfolgenden PTS vor. Zum Ermitteln der aktuellen
Position, d.h. des aktuellen Timecodes, kann der PTS ausgewertet
werden.
-
Bei
der Auswertung des PTS ergibt sich das Problem, dass der PTS in
einem Videodatenstrom nicht bei Null beginnen muss, sondern jeden
beliebigen (Start-)Wert annehmen kann. Die einzelnen Bilder (Frames) in
einem Videodatenstrom sind nicht in genau der Reihenfolge codiert,
in der sie angezeigt werden. Der PTS kann somit in begrenztem Maße auch
kleiner werden. Da die Länge
des PTS begrenzt ist, kann dieser aber auch „überlaufen". Weiterhin kann der PTS an einer Schnittstelle
mehrerer hintereinander zusammengesetzter Teil-Videodatenströme um einen
großen
Wert springen. Dieser Sprung des PTS bedeutet jedoch keinen Sprung
des Timecodes des abspielenden Videos. Das Problem, dass der erste
PTS in einem MPEG2-TS Datenstrom von Null abweichen kann, lässt sich
auf folgende Weise lösen:
Eine Variable, deren Wert der Timecode, also die verstrichene Abspielzeit
ist, wird bei einem Reset()-Aufruf auf Null gesetzt. Dieser Variablen
wird kontinuierlich die Differenz zweier aufein anderfolgender PTS
hinzugefügt.
Damit dieser Wert die Einheit Millisekunden hat, wird der Differenzwert
durch 90 geteilt. In dem Fall, dass die Differenz zweier aufeinanderfolgender
PTS größer als
FFFFhex entsprechend 0.7s ist, wird die
Differenz ignoriert. Der Fall tritt ein, wenn die Schnittstelle
zwischen zwei zusammengesetzten Teilströmen erreicht wird. Falls der
Parser auf einen PTS trifft, der ein „Ausreißer" ist, wird die Differenz zwischen diesem
und dem vorigen PTS und zwischen diesem und dem nachfolgenden PTS
ignoriert, da beide Werte vom Betrag größer als 0.7s sind.
-
Die
Differenz zwischen zwei benachbarten PTS wird nur dann in die Berechnung
des Timecodes einbezogen, wenn sie nicht größer als FFFFhex,
entsprechend 0.7s, ist. Diese Berechnung erfordert nur die unteren
16 bit des PTS, der aber 33 bit breit ist. Da jedoch zur Berechnung
nur 16 bit benötigt
werden und der Vergleich zweier PTS auf den Wert FFFFhex mit
32 bit wesentlich einfacher zu realisieren ist, wird das MSB (Most Significant
Bit) des PTS generell ignoriert.
-
Während des
Vor- bzw. Rückspulvorgangs
werden keine Videodaten über
einen IEEE1394-Bus zur Anzeige gesandt, sondern lediglich der Positionszeiger
in der Videodatei verschoben. Die Geschwindigkeit, mit der der Dateizeiger
bewegt wird, ist die Geschwindigkeit, mit der gespult wird. Dazu
wird kontinuierlich der aktuelle Timecode ermittelt, welcher z.B.
auf einem Displaymodul dargestellt werden kann.
-
Um
eine konstante und berechenbare Spulgeschwindigkeit zu ermöglichen,
wird in konstanten Zeitabschnitten der Dateizeiger um die Differenz
eines bestimmten Timecodes verschoben. Dazu müssen die zum gesuchten Timecode
korrespondie renden Datenpakete im Videostrom gefunden werden. Der
prinzipielle Ablauf des Spulvorgangs ist in Tab.1 dargestellt.
-
Tab.1
Prinzipieller Ablauf des Spulvorgangs
-
Mittels
der Differenz des Timecodes (CurrentTimeCode + ΔT) und der anschließenden Wartezeit
der Routine kann man die Spulgeschwindigkeit einstellen. Die Wartezeit
der Schleife kann frei gewählt
werden. Passend zu dieser wird die Differenz des Timecodes ΔT ermittelt,
um eine bestimmte Spulgeschwindigkeit zu realisieren.
-
Die
Spulgeschwindigkeit ist das Intervall des übersprungenen Timecodes in
einer bestimmten Zeit. Dies könnte
z.B. bedeuten: In einer Sekunde sollen 10 Sekunden Film übersprungen
werden. Die Wartezeit sollte nicht zu groß sein, da sonst die Anzeige
des Timecodes während
des Spulens nur in großen
Abständen verfolgt
werden kann. Die Wartezeit darf jedoch auch nicht so klein sein,
dass ΔT
einen wert annimmt, der kleiner als der durchschnittliche Abstand zweier
Timecodes ist. Außerdem
hat die Wartezeit Auswirkungen auf die Lesbarkeit des Displays zur
Zeitanzeige.
-
Da
beim Vor- und Zurückspulen
der Timecode an der aktuellen Position im Videostrom benötigt wird, muss
der Videodatenstrom kontinuierlich geparst werden. Bei einem MPEG2-TS
Datenstrom bedeutet das, dass alle TSPs untersucht werden müssen. Die
PES-Packets müssen
ermittelt und auf das Vorkommen eines PTS untersucht werden. Der
PTS muss anschließend
auf Fehler überprüft und eventuell
korrigiert werden. Dieser Vorgang nimmt jedoch viel Zeit in Anspruch,
sodass nicht beliebig schnell gespult werden kann. Durch die Benutzung
eines erfindungsgemäßen Info-Files,
durch welches unter geringem Aufwand der aktuelle Timecode und das
ihn enthaltende TSP ermittelt werden können, wird das Vor- und Zurückspulen
jedoch wesentlich vereinfacht.
-
Nicht
in jedem PES-Packet muss sich ein PTS befinden. Wenn aber ein PTS
vorhanden ist, muss er sich am Anfang des PES-Packets befinden. Nachdem ein PTS gefunden
wurde, können
daher viele TSPs übersprungen
werden. Beim Parsen des Videodatenstroms ist allerdings im Vorfeld
nicht bekannt, wie viele TSPs übersprungen
werden können.
An dieser Stelle kann die vorteilhafte Wirkung des erfindungsgemäßen Info-Files genutzt werden.
-
Ein
erfindungsgemäßes Info-File
I ist in 2 dargestellt. Es enthält prinzipiell
eine Folge von Offset-Werten OP,OB, die angeben, wie viele elementare
Pakete nicht relevant sind und beim Spulen übersprungen werden können. Außerdem werden
zu jedem Offset Zusatzinformationen AI abgelegt. Zusammen ergeben diese
drei Felder einen Info-Block IB für jedes PES-Packet PP. Die
Werte für „Offset
Packets" OP und „Offset Bytes" OB geben die Anzahl
elementarer Transportdatenpakete (TSPs) TDP und die Anzahl der Bytes
zwischen zwei relevanten TSPs an, also zwischen zwei Paketen PP#11,PP#12 des Transportdatenstroms
MTS, die die Header PPH1,PPH2 von
solchen PES-Packets PP enthalten, die im gleichen Elementardatenstrom
EDS direkt aufeinanderfolgen. Zwischen diesen relevanten TSPs liegen
die TSPs, die zu diesem jeweiligen PES-Packet PP gehören, aber
es können
dort auch TSPs vorkommen, die zu den PES-Packets anderer Elementardatenströme gehören. Ein
Info-Block IB besteht aus zwei Offset-Werten OP,OB und dem Zusatzinformationsfeld
AI. Das Zusatzinformationsfeld („Additional Information") AI bezieht sich
auf das zugehörige
Paket PP#11,PP#12 im
Datenstrom und kann z.B. den Zeitstempel (PTS) dieses Pakets enthalten.
Jedes Info-File bezieht sich nur auf einen Elementardatenstrom,
vorzugsweise den Videodatenstrom, weil sich an ihm das Vor- und
Rückspulen
orientieren soll.
-
Im
Fall eines MPEG2-TS Datenstroms geben die ersten beiden Felder OP,OB
eines Info-Blocks den Abstand zweier aufeinanderfolgender PES-Packets
an und sind jeweils 32 Bit breit. Das „Additional Information" Feld AI enthält in der
beschriebenen Applikation für
jedes Videoformat den fertig berechneten und fehlerkorrigierten
Timecode, ebenfalls 32 Bit breit. Ein Info-Block ist in der beschriebenen
Form bei einem MPEG2-TS Datenstrom demnach 3 × 32 = 96 Bit oder 12 Byte
lang. Es kann aber vorteilhaft sein, im Zusatzinformationsfeld AI
weitere Daten abzulegen, wenn dadurch das Info-File nicht so groß wird,
dass die Spulgeschwindigkeit wieder reduziert wird. Mit Hilfe der
Informationen im Info-File kann die Applikation alle nicht relevanten
TSPs sofort überspringen.
Die Navigation bzw. Synchronisation zwischen dem Info-File I und
dem Elementardatenstrom EDS, z.B. einem MPEG2-gemäßen Videodatenstrom,
erfolgt von PES-Packet zu PES-Packet. Der Timecode kann dabei direkt
aus dem Info-File
gelesen werden und muss somit nicht bei jedem Spulvorgang neu berechnet
werden.
-
Ein
aufgenommener MPEG2-TS Videodatenstrom muss nicht mit einem TSP
beginnen, welches den Anfang eines PES-Packets („PES Start") enthält. Nimmt das DSD z.B. einen
Live-Stream auf, so ist das erste TSP ein beliebiges Paket aus einem
fortlaufenden Transportdatenstrom. Dieser Fall ist in 3 dargestellt. Der
Transportdatenstrom MTS beginnt mit zwei anderen Datenpaketen OTH,
bevor das erste Paket PSP#1 mit einem „PES Start" kommt. Der erste Offset-Wert OP1,OB1
des Info-Files beschreibt die Distanz zwischen dem ersten MTS Paket
PSP#1, das ein „PES
Start" enthält und dem
zweiten MTS Paket PSP#2, das ebenfalls ein „PES Start" beinhaltet. Die ersten TSPs im Transportdatenstrom
MTS enthalten noch kein vollständiges PES-Packet
und bleiben vom Info-File unbeachtet, auch wenn sie zum gleichen
Elementardatenstrom gehören.
Zusätzlich
kann aber auch ein erster Eintrag im Info-File den Abstand des ersten
PES-Packets PSP#1 bzw. die Anzahl der zu überspringenden irrelevanten
TSPs OTH angeben.
-
Wird
die Aufnahme eines Videostroms beendet, dann muss das zuletzt empfangene
TSP nicht das Ende eines PES-Packets enthalten. Deshalb wird an
den letzten Info-Block in einem MPEG2-spezifischen Info-File ein
weiterer Block angehängt,
dessen „Offset
Packets" Wert Null
ist, und anschließend
folgt die Position des letzten TSP, welches ein „PES Start" enthält. Dieses angefangene PES-Packet
muss nicht mehr vollständig
sein und soll bei einer Wiedergabe nicht mehr gesendet werden. An
dem in 3 gezeigten verkürzten Bei spiel beschreibt der
letzte reguläre
Info-Block OP2,OB2,TC2 den Abstand zwischen dem letzten vollständigen PES-Packet,
das mit PSP#2 beginnt, und dem unvollständigen letzten, mit PSP#3 beginnenden PES-Packet.
Der Offset OP2 ist drei, weil das dritte folgende TSP den nächsten,
zum gleichen Elementardatenstrom gehörenden PES-Packet Header PSP#3
enthält.
Der Offset OB2 ist die Summe der Bytes des PES-Packets, das mit
PSP#2 beginnt. Der Timecode TC2 entspricht der Darstellungszeit,
dem PTS dieses PES-Packets. Der letzte Info-Block OP3,OB3,TC3 jedoch enthält eine
Null für
den Offset-Wert
OP3, und danach die Position des letzten „PES Start" Pakets PSP#3. Damit wird das Ende des
aufgezeichneten Elementardatenstroms beschrieben.
-
Ein
Videodatenstrom, der mit Hilfe eines Info-Files gescannt wird, muss
zuerst mit dem Info-File synchronisiert werden. Dabei muss das erste
TSP im Videodatenstrom gesucht werden, das den Anfang eines PES-Parkets,
also ein „PES
Start", enthält.
-
Die
Erzeugung und Auswertung des Info-Files erfolgt im format-spezifischen
DSD-Stream-Parser. Somit besteht die Möglichkeit, für jedes
Videoformat ein speziell angepasstes Info-File mit individuellem
Zusatzinformationsfeld und individueller Bitlänge des Info-Blocks zu erzeugen.
-
Das
Erstellen des Info-Files erfolgt normalerweise beim Empfang der
Videodaten, also während
des Aufnahmevorgangs. Falls zu einem bereits bestehenden Track kein
Info-File existiert, kann beim Start der DSD-Applikation ein solches
erzeugt werden. Somit ist es möglich,
auch Videodateien wiederzugeben, für die bei der Aufnahme kein
erfindungsgemäßes Info-File
erzeugt wurde, z.B. wenn eine Videodatei manuell kopiert wurde.
Das Info-File kann auch zusammen mit den Videodaten übertragen
und empfangen werden.
-
Zur
Implementierung der Schnittstelle werden im DSD-Stream-Parser Modul die
in Tab.2 aufgeführte Funktionen
definiert, mittels derer ein Info-File geöffnet, erzeugt oder geschlossen
werden kann.
-
Tab.2
Funktionen des DSD-Stream-Parsers
-
Tab.2:
Funktionen des DSD-Stream-Parsers
-
Ein
Aufruf von ParsePacket() liest ein Info-File, bzw. ein Aufruf von
ParseStream() liest oder erzeugt ein Info-File, in Abhängigkeit
von einem vorherigen Funktionsaufruf von OpenInfoFile() oder CreateInfoFile().
-
Die
Funktion CheckSync() überprüft, ob der
Videodatenstrom und das Info-File synchron sind. Bei einem MPEG2-TS
Datenstrom wird geprüft,
ob das „payload_unit_start_indicator"-Flag an der aktuellen Position im Videostrom
auf 1 gesetzt ist und der „start_code_prefix" den Wert 000001hex enthält.
Ist dies der Fall, enthält das
TSP an der aktuellen Stelle im Videostrom den Anfang eines PES-Packets.
Da das Info-File
den Abstand zweier TSPs angibt, die jeweils benachbarte „PES Start" enthalten, ist dies
die notwendige Bedingung für
das Scannen des Videodatenstroms mit Hilfe des Info-Files. Die Funktion
gibt in diesem Fall den Wert „true" zurück.
-
Ein
Aufruf von ParsePacket() scannt ein einzelnes TSP eines MPEG2-TS
Datenstroms. Aufeinander folgende Aufrufe von ParsePacket() enthalten
als Eingangsparameter aufeinander folgende TSPs. Der Timecode des
aktuell geparsten Pakets wird aus dem zugehörigen Info-File gelesen. Ein
vorangegangener Aufruf von OpenInfoFile() ist deshalb notwendig. 4 zeigt
den Ablauf der ParsePacket() Routine.
-
Ein
zu parsender Videodatenstrom wird in einzelnen Aufrufen von ParsePacket()
zuerst mit dem Info-File synchronisiert, indem das erste TSP im
Videodatenstrom gesucht wird, das ein „PES Start" enthält. Dazu wird im ersten Schritt
D1 das erste Byte eines TSP Headers, das sync_byte, auf den vorgeschriebenen Wert
47hex untersucht. Die Modulvariable bFirstPESReached
gibt an, ob dieses TSP bereits gefunden wurde. Im zweiten Schritt
D2 von ParsePacket() wird diese Variable untersucht. Wurde das TSP
bisher nicht gefunden, so erfolgt ein Aufruf von CheckSync(). In
Abhängigkeit
des zurückgelieferten
Wertes kann der Wert von bFirstPESReached auf „true" gesetzt werden. Im dritten Schritt
D3 wird mit Hilfe dieser Variable nochmals geprüft, ob ein erstes TSP mit dem
Anfang eines PES-Packets gefunden wurde. Wurde der Videodatenstrom
in einem Aufruf von ParsePacket() mit dem Info-File synchronisiert,
wird aus diesem der Offset zum nächsten TSP
gelesen, das ein relevantes „PES
Start" enthält . Die
Modulvariable u32PacketsToNextPES erhält den Wert des ermittelten
Offsets. Bei jedem Funktionsaufruf wird die Variable dekrementiert.
Das Info-File wird erst dann wieder ausgelesen, wenn die Variable
den Wert Null erreicht hat. Wird aus dem Info-File ein Offset von Null
gelesen D4,D5, d.h. Dateiende erreicht, wird die Position des letzten
TSPs, das ein „PES
Start" enthält, der
Modulvariablen u64ByteCounterAtPESStart übergeben. Der Wert dieser Variablen
wird durch die Funktion GetCurrentEndOfValidStream() zurückgegeben.
Wurde das Dateiende nicht erreicht, wird der zum aktuellen TSP gehörende Timecode
aus dem Info-File gelesen und in der Modulvariablen u32ElapsedTime
abgelegt.
-
Die
Funktion ParseStream() scannt einen aus einem oder mehreren TSPs
bestehenden Teil eines Videodatenstroms. Sie unterstützt sowohl
die Ermittlung des Timecodes aus einem Info-File als auch die Erzeugung
einer solchen Datei. Der angewandte Modus ist abhängig von
einem vorangegangen Aufruf von OpenInfoFile() oder CreateInfoFile().
In einer Schleife wird jeweils ein einzelnes Videodatenpaket aus
dem zu parsenden Videodatenstrom extrahiert. Die Schleife wird so
lange ausgeführt,
bis jedes Paket durchlaufen wurde. Die Modulvariable u32TSPCounter
zählt dabei
die extrahierten Pakete und in u64ByteCounter werden die extrahierten
Bytes gezählt.
Im Fall eines vorangegangenen Aufrufs von OpenInfoFile() wird das
jeweils extrahierte Paket als Eingangsparameter eines Funktionsaufrufs
von ParsePacket() verwendet. Sobald das erste TSP mit einem „PES Start" erreicht wurde,
wird die aktuelle Anzahl Bytes, enthalten in u64ByteCounter, der
Modulvariablen u32CurrentStartOfStreamOffset übergeben.
-
Soll
ein Info-File erzeugt werden, so wird das aktuelle TSP der privaten
Funktion ParseTransportPacket() übergeben.
Diese Funktion stellt fest, ob das TSP relevant für den Elementardatenstrom
ist, extrahiert daraus ein Stück
eines PES-Packets und speichert dieses in einem Buffer. Bei jedem
Funktionsaufruf wird ein weiteres Stück PES-Packet in einem Buffer
abgelegt. Enthält
das TSP den Anfang eines neuen PES-Packets, wird der Zählerstand
der Variable u32TSPCounter in der Modulvariablen u32TSPCounterAtPESStart
sowie der aktuelle Wert von u64ByteCounter in u64ByteCounterAtPESStart
abgelegt, alle bisher gespeicherten Stücke des PES-Packets werden
zusammengefügt
und das gesamte PES-Packet durch die private Funktion ParsePESPacket()
untersucht. Diese ermittelt, falls vorhanden, den zugehörigen PTS
und legt diesen in der Modulvariable u32PTS ab. Außerdem ist
es möglich,
PES-Packets weiter zu untersuchen, z.B. auf enthaltene Video- oder
Audiodatenströme.
Der PTS wird anschließend
in ParseTransportPacket() untersucht, auf Fehler überprüft und korrigiert
sowie der aktuelle Timecode berechnet, welcher in das geöffnete Info-File
geschrieben wird. Die Berechnung des Timecodes erfolgt nach dem
oben beschriebenen Verfahren. Die Distanz zwischen zwei benachbarten
TSPs, die ein „PES
Start" enthalten,
wird anhand der Modulvariablen u32TSPCounter, u32TSPCounterAtPESStart,
u64ByteCounter und u64ByteCounterAtPESStart berechnet.
-
Die
Funktion GetCurrentEndOfValidStream() gibt den aktuellen Wert der
Variablen u64ByteCounterAtPESStart, wie bei ParsePacket() und ParseStream()
beschrieben, zurück.
Damit liefert sie die Position des zuletzt geparsten TSPs, das ein „PES Start" enthält.
-
Die
Funktion GetStartOfStreamOffset() gibt den Wert der in ParseStream()
gefüllten
Variable u32CurrentStartOfstreamOffset zurück. Gibt die Applikation einen
Videostrom wieder, wird die eigentliche Übertragung erst ab dem zurückgelieferten
Wert gestartet. Das verhindert, dass bei Wiedergabebeginn ein unvollständiges PES-Packet übertragen
wird. Da ein Videodatenstrom bei jeder Stelle beginnend aufgenommen werden
kann, muss die aufgenommene Datei nicht mit einem „PES Start" im ersten TSP beginnen.
Die Variable u32CurrentStartOfStreamOffset wird anfangs auf den
Initialwert FFFFFFFFhex gesetzt. Wird dieser
Wert durch die Funktion zurückgeliefert,
bedeutet das, dass in ParseStream() bisher kein „PES Start" gefunden wurde.
-
Die
Suche nach einem bestimmten Timecode im Info File erfolgt in der
SeekTimeCode() Routine des DSD-MPEG2-Parsers. Es wird zwischen Vorwärts- und
Rückwärtssuche
unterschieden (SeekType). Zurückgeliefert
wird die Anzahl Bytes, um die sich der Dateizeiger im Videostrom
bewegen muss, um das entsprechende TSP zu erreichen. Im Rückwärtszweig
der Routine wird ein Timecode im Info-File gesucht, der kleiner oder
gleich dem als Parameter übergebenen
Timecode ist. Dabei läuft
der in Tab.3 dargestellte Algorithmus ab.
-
Tab.3:
Struktogramm der Rückwärtssuche
in SeekTimeCode()
-
Der
Gesamtsprungzähler
in Tab.3 bezeichnet die Anzahl der Bytes, um die der Positionszeiger
im Videostrom bewegt werden muss, um zu dem gewünschten Timecode zu gelangen.
Dieser wird im Info-File gesucht, indem die Offsets von PES-Packet
zu PES-Packet aufsummiert werden.
-
Im
Vorwärtszweig
der Routine wird ein Timecode im Info-File gesucht, der größer oder
gleich dem als Parameter übergebenen
Timecode ist. Tab.4 stellt das Struktogramm der Vorwärtssuche
dar.
-
Tab.4:
Struktogramm der Vorwärtssuche
in SeekTimeCode()
-
Nach
jedem Schleifendurchlauf des in Tab.4 dargestellten Algorithmus
zeigt der Dateizeiger des Info-Files auf den Beginn des nächsten Info-Blocks,
für welchen
die Schritte 5 bis 8 ausgeführt
werden. Beim Erreichen des Dateiendes wird die Schleife verlassen
und der Dateizeiger im Info-File auf „Dateianfang" gesetzt.
-
Im
folgenden wird die Umsetzung der Forward- und Reverse-Kommandos zum Vorwärts- und
Rückwärtsspulen
beschrieben.
-
Das
Vorwärts-
und Rückwärtsspulen
in einem Videodatenstrom erfolgt mit Hilfe des oben beschriebenen
Info-Files. Zu Beginn der Routine wird davon ausgegangen, dass der
Positionszeiger innerhalb des Videostroms auf ein TSP zeigt, das
den Anfang eines PES-Packets („PES
Start") enthält, oder
auf ein TSP, das sich vor diesem befindet. Zur Synchronisation mit
dem Info-File wird der Videostrom solange vorwärts gescannt, bis ein TSP mit
einem „PES
Start" gefunden
wurde. In 3 werden im Datenstrom TS die
Pakete OTH gescannt, bis das erste PES-Packet PSP#1 gefunden wurde,
das ein „PES
Start" enthält. Anschließend wird
mittels einer Schleife in SeekTimeCode() ein Timecode im Info-File
gesucht, welcher einen bestimmten zeitlichen Abstand zum aktuellen
Timecode hat, und die Anzahl zu überspringender
TSPs bzw. Bytes wird durch Aufsummieren ermittelt. Um diese wird
der Dateizeiger im Videostrom versetzt.
-
Die
Synchronisation zwischen dem Videostrom und dem Info-File muss auch bei
einem Kommandowechsel gewährleistet
sein. Dazu wird während
des Wiedergabevorgangs der Timecode ebenfalls aus dem Info-File
statt aus dem Videostrom gelesen. Das hat zwei Gründe: Erstens
muss der Timecode dann nicht aus dem PTS neu berechnet werden, was
schneller geht und sich zugunsten der Performance auswirkt, und
zweitens ist dadurch das Info-File bei einem möglichen Kommandowechsel nach
Vorspulen („Forward") oder Rückspulen
(„Reverse") synchron zum Videostrom.
-
Um
den Videostrom und das Info-File auch bei einem Kommandowechsel
synchron zu halten, hält
der DSD-MPEG2-Parser
folgende Vorgaben ein:
- 1. Zu Beginn der Ausführung eines
Kommandos muss der Positionszeiger im Videostrom auf das TSP zeigen,
welches den Beginn des zur aktuellen Zeigerposition im Info-File
zugehörigen
PES-Packets enthält, oder
auf ein TSP, welches sich vor diesem befindet. Befindet sich der
Zeiger sowohl des Videostroms als auch des Info-Files am Dateianfang,
so ist diese Bedingung per Definition erfüllt.
- 2. Befindet sich nach dem Wiedergabevorgang der Positionszeiger
im Videostrom auf keinem TSP mit einem „PES Start", so zeigt der Dateizeiger des Info-Files
auf den Info-Block, der zum nächsten
TSP mit einem „PES
Start" gehört. Enthält das aktuelle
TSP des Videostroms ein „PES
Start", so zeigt
der Dateizeiger des Info-Files auf den zu diesem TSP zugehörigen Info-Block.
- 3. Nach der Ausführung
eines Forward- oder Reverse-Kommandos zeigt der Positionszeiger
im Videostrom auf ein TSP mit einem „PES Start". Der Dateizeiger des Info-Files zeigt
auf den zu diesem TSP gehörigen Info-Block.
Ausnahme ist der Fall, dass während
der Kommandoausführung
das Dateiende erreicht wird. In diesem Fall werden beide Zeiger
auf den Dateianfang gesetzt.
-
Nach
der Ausführung
eines Kommandos wird sowohl die Videodatei als auch das Info-File
geschlossen. Deshalb werden Modulvariable eingeführt, welche die aktuelle Position
im Videostrom und im Info-File dauerhaft speichern. Das DSD-Working-Thread
Modul legt zu diesem Zweck die Variable u64FilePos an, die nach
jedem Dateizugriff mit der aktuellen Position des Dateizeigers der
Videodatei aktualisiert wird. Der DSD-MPEG2-Parser definiert die
Variable u32InfoFilePosition. In der StartFile() Routine des DSD-Working-Threads wird nach
dem Öffnen
der Videodatei der Dateizeiger auf die Position in u64FilePos gesetzt. Gleiches
geschieht beim Öffnen
des Info-Files mit der entsprechenden DSD-MPEG2-Parser Modulvariablen. Erfolgt
die Wiedergabe eines anderen als des im vorangegangenen Kommando
ausgewählten
Tracks, müssen beide
Modulvariablen auf Null gesetzt werden.
-
In
der praktischen Umsetzung lassen sich typischerweise etwa folgende
Größenverhältnisse
zwischen den Dateien erzielen:
Für eine 65Mbyte große Videodatei
ist das Info-File ca. 81Kbyte groß, entsprechend 0.12%. Für eine andere Videodatei
von 229Mbyte ist das Info-File ca. 146Kbyte groß, entsprechend etwa 0.06%.
-
Der
verwendete Transportdatenstrom (Transport Stream, TS) ist ein paketorientierter
Datenstrom, der vorwiegend für
fehlerbehaftete Kanäle
benutzt wird, meist für Übertragung
oder Speicherung. Die Erfindung ist jedoch unabhängig davon, ob alle oder nur
ein Teil der Pakete des Transportdatenstroms überhaupt relevant sind.
-
Die
verwendeten PES-Packets haben variable-Größe, bis zu 64Kbyte, und können im
Video-Elementardatenstrom ein intracodiertes Bild („I-Frame", ca.40Kbyte) oder
bis zu zwei intercodierte Bilder („B-Frame", "P-Frame") enthalten. Dies
ist auf die je nach Bildinhalt variable Größe der codierten Bilder zurückzuführen. Daher
erlaubt das erfindungsgemäße Verfahren
ein einfaches, schnelles und gezieltes Auffinden einzelner PES-Packets,
und damit einzelner Videobilder.
-
Wichtig
an der Erfindung ist, dass die Informationen zum Auffinden der PES-Packets
separat abgelegt werden, z.B. in einer separaten Datei oder in einem
separaten Speicherbereich. Ein weiterer Vorteil des erfindungsgemäßen Verfahrens
ist, dass zur Lokalisierung einer speziellen Stelle innerhalb eines
Elementardatenstroms der gespeicherte Transportdatenstrom, der die
Pakete mehrerer Elementardatenströme enthalten kann, nicht erst
während
der Lokalisierung nach diesen Elementardatenströmen sortiert werden muss. Beides führt dazu,
dass der Transportdatenstrom unverändert abgespeichert werden
kann, so wie er empfangen wurde.
-
Weiterhin
erlaubt das erfindungsgemäße Verfahren,
jeden von der Bildcodierung her möglichen Einsprungpunkt, d.h.
jeden I-Frame, in der Videodatei anzuspringen, statt z.B. ein festes
Raster möglicher
Einsprungpunkte vorzugeben. Sogar intercodierte Bilder, B-Frames
oder P-Frames, können
angesprungen werden, wenn sie sich am Anfang eines PES-Packets befinden.
Diese Punkte werden beim Anlegen der Info-Datei automatisch lokalisiert.
-
Durch
die Angabe relativer Offsets ist das Verfahren unabhängig von
der Länge
der Gesamtdatei. Nur die maximale Sprungweite ist begrenzt, die
sich aber sicher vorhersagen lässt.
Dabei kann der Offset zum nächsten
relevanten TSP bzw. zum vorherigen relevanten TSP angegeben werden,
je nach Definition der Zuordnung.
-
Das
erfindungsgemäße Verfahren
lässt sich
vorteilhaft in Geräten
einsetzen, die in paketorientierten Datenströmen navigieren müssen, z.B.
Aufnahme- und Wiedergabegeräte
für Video-
und/oder Audiodaten, etwa Personal Video Recorder (PVR) oder ähnliche,
insbesondere zur Implementierung von Vorspul-, Rückspul- oder Wiedergabefunktion.
