Header bei TS-Dateien

[Webturtle]

Hallo,

 

gibt es bei TS-Dateien einen festen Header wie bei MPG-Dateien, und wenn ja wie lautet er?

 

Ich habe eine SD-Karte, auf der mit einem Sat-Receiver Aufnahmen gemacht worden sind, der als Format TS verwendet. Diese SD-Karte ist nicht mehr lesbar. Besser gesagt, die Dateistruktur funktioniert nicht mehr. Mit einem Hex-Editor, z.B. Avihex kann man die SD-Karte auf Bit-Ebene noch lesen bzw. exportieren.

 

Ein ähnliches Problem hatte ich schon einmal mit einem USB-Stick, auf dem mit einem DVB-T-Receiver aufgenommen worden ist, der als Aufnahmeformat MPG benutzt hat. Damals hatte ich mir einige neue Aufnahmen auf Bit-Ebene angesehen und einen Header gefunden, der immer gleich war. Damit konnte man dann auf dem defekten Stick feststellen, wo eine Aufnahme anfing, und diese bis zum nächsten Header exportieren. Der eventuelle Müll am Ende ist beim Schneiden weggefallen. Diesmal konnte ich keinen gleichartigen Anfang entdecken.

 

 

Viele Grüße

 

Webturtle

Edited November 21, 2013 by Webturtle

[Derrick]

TS vom DVBViewer beginnt normalerweise mit einer PAT. Einen speziellen header gibt es nicht. Es ist nur eine folge von ts_packets. Bei receivern können proprietäre header vorkommen.

[Webturtle]

Hallo Derrick,

 

vielen Dank für die Info. Kannst Du noch kurz erklären, was man unter PAT bzw. ts_packets versteht?

 

Also die Aufnahmen stammen von einem Sat-Receiver also habe sie wahrscheinlich höchstens einen proprietären Header.

 

 

Viele Grüße

 

Webturtle

 

[playboy]

wenn Du noch zugriff auf den receiver hast, könnte man da eine neue aufnahme machen um an den header zu kommen.

[Derrick]

PAT hat PID 0. Ein ts_paket hat 188byte. Die 1. 4byte sind der header. Es beginnt immer mit dem sync byte 0x47. Kannst du alles einfach im eingebauten hexviewer von transedit betrachten.

[Griga]

PAT-Pakete sind zum Auffinden des Dateianfangs ungeeignet, da sie sich ständig wiederholen (typisch alle 100 ms). Im TS gibt es nichts, was diesem Zweck dienen könnte.

[Derrick]

Es geht ja darum, um ts-aufnahmen vom rest zu unterscheiden. Dazu liesse sich das sync byte gebrauchen. Allerdings hat transedit schwächen beim sync.

[nuts]

Das Thema würde mich auch interessieren.

Wenn man jetzt einen Datenträger mit mehreren Aufnahmen (TS) hat kann man doch nicht mit dem Sync-Byte die Position der einzelnen Aufnahmen trennen oder?

Man fängt vorne (Datenträger) an bis man das Sync-Byte gefunden hat.

Dann hat man den Anfang der ersten Aufnahme. Bis zu welchem Punkt hangelt man sich dann weiter?

[Derrick]

0x47 wird sicher nicht so selten sein. Das reicht also nicht. Erst wenn eine folge von sync bytes im abstand von jeweils 188 byte gefunden wird, hat man einen ts stream. Das dürfte relativ mühselig sein.

[Basic.Master]

In Sachen TS-Dateien wiederherstellen kann ich das kostenlose PhotoRec empfehlen:

Ich wollte nämlich mal von meinem alten (analogen) HDD-DVD-Recorder die Aufnahmen überspielen, der eingebaute Brenner funktionierte aber leider nicht mehr. Die Festplatte hatte ich an den PC angeschlossen, wo auch einige Aufnahmen angezeigt wurden (Dateisystem war an FAT angelehnt; die Dateien TS mit MPEG-2 und AC-3) - sie waren aber nur kurz anspielbar für einige Sekunden. PhotoRec habe ich dann die ganze Platte durchsuchen lassen (ohne Rücksicht aufs Dateisystem) und dabei wurde alles wiederhergestellt, was der Recorder in der Aufnahmenliste am Bildschirm vorher angezeigt hatte.

[Webturtle]

Hallo Basic.Master,

 

vielen Dank für den Tip.

 

Ich werde PhotoRec einmal ausprobieren. Vielleicht klappt es ja. Das Dateisystem ist Fat32. Vielleicht findet dieses Programm ja etwas. Bei MPG-Dateien hatte ich mit der Suche Avihex (Stick als solchen ohne Rücksicht auf das Dateisystem nach dem Header durchsucht) ja Erfolg gehabt, aber bei TS gibt es offensichtlich keinen derartigen "Standard"-Header, nach dem man suchen könnte.

 

 

Viele Grüße

 

Webturtle

 

[Basic.Master]

Wie Derrick erwähnt hat, gibt es halt dieses charakteristische Syncbyte 0x47 und den Abstand von 188 Bytes zwischen zwei Syncbytes bzw. TS-Paketen. Dazu gibt es noch den sogenannten Continuity Counter, der von 0 bis 15 zählt und danach wieder bei 0 anfängt. Ganz so einfach ist das nicht, weil dieser Zähler in bestimmten Fällen gleichbleibt und es außerdem pro Elementarstrom (Video, Tonspur) so einen Zähler gibt. Theoretisch könnte ein Programm diese Zusammenhänge alle nutzen und damit versuchen, die Aufnahme zu rekonstruieren. Wie PhotoRec bei TS da vorgeht, weiß ich allerdings nicht.

[Webturtle]

Hallo Basic.Master,

 

bei TS ist es ja wohl etwas komplizierter als bei MPG. Dort hatte ich eine Byte-Kombination gefunden, die bei jeder Aufnahme am Anfang stand, wie die berühmten Buchstaben am Anfang voni EXE-Dateien (Magische Zeichenfolge MZ wie Mark Zbikowski). Damit läßt sich bei der Suche mit einem Hex-Editor auf einem Datenträger etwas anfangen. Ein einzelnes Syncbyte und ein weiteres in einem bestimmten Abstand sind damit schwer zu finden. Dazu müßte man wohl ein Programm z.B. in C schreiben. Also kann man nur darauf hoffen, daß fertige Programme etwas finden.

 

 

Viele Grüße

 

Webturtle

Edited December 20, 2013 by Webturtle

[erwin]

Hallo Webturtle,

 

 

Dort hatte ich eine Byte-Kombination gefunden, die bei jeder Aufnahme am Anfang stand, wie die berühmten Buchstaben am Anfang voni EXE-Dateien (Magische Zeichenfolge MZ wie Mark Zbikowski). Damit läßt sich bei der Suche mit einem Hex-Editor auf einem Datenträger etwas anfangen.

 

Das Problem ist, dass per DVB KEINE ENDLICHEN DATEIN übertragen werden, sondern ein, potentiell unendlicher, Strom von Daten. Daher auch TS - TransportSTREAM. Ein solcher Stream hat keinen Anfang, ergo auch keinen *Header*. Die Leute schalten ihr TV eben nicht einheitlich um 20:15 ein.

 

 

 

Ein einzelnes Syncbyte und ein weiteres in einem bestimmten Abstand sind damit schwer zu finden.

 

Vergiß diese *SyncBytes*. Der Datenstrom ist in einzelne Packete a 188 Byte strukturiert. Und JEDES, aber auch JEDES Paket, begint mit diesem *SyncByte=0x47". Mit JEDES sind 188-Byte Video gemeint (wenns dumm läuft sind das nicht mal nur Metainformationen), aber auch 188 Byte TABLE-Inhalt, wie z.B. die PAT=Programm-Allocation-Table, PMT-, ect.- Tabellen, die den Inhalt des Streams beschreiben und deshalb periodisch wiederholt werden (müssen - 20:15, du erinnerst dich). Und sogar die NULL-Pakete, die ohne jeglichen inhaltlichen Sinn einfach nur aufgefüllt werden um eine bestimmte Datenrate abzusichern (für Receiver z.B, die sonst Probleme bekämen). beginnen mit 0x47. Also alle 188 Byte - die sagen dir für deinen Zweck GAR NICHTS - und sind so einfach zu finden, einmal *synchronisiert*, kommen die so regelmäßig wie das Finanzamt, alle 188 Byte.

 

Nach diesen *SyncBytes* folgen auf Position 2 (eigentlich sinds 13 Bits) in jedem 188-Paket IDs, PID genannt, die aussagen was das Paket eigentlich enthält: Sind es Null-Pakete, sind es TABLEs, sind es (Mikro-)Teile eines Audio- oder Videoelementarsteams. Diese *Elementarstreams* haben nun irgendwo, da wo eine Sendung inhaltlich begann, VIELLEICHT ein sogenanntes *STARTFLAG*, dem Header folgen können.

 

Also wenn du nun HEISS bist: Das PES-Format, und wie es in den TransportStream eingebettet ist, DAS wäre dann dein Thema. (Das ist dann aber auch wirklich eine interessante Story).

 

erwin

Edited December 26, 2013 by erwin

[Griga]

Vergiß diese *SyncBytes*. (...) Und sogar die NULL-Pakete, die ohne jeglichen inhaltlichen Sinn einfach nur aufgefüllt werden um eine bestimmte Datenrate abzusichern (für Receiver z.B, die sonst Probleme bekämen). beginnen mit 0x47. Also alle 188 Byte - die sagen dir für deinen Zweck GAR NICHTS - und sind so einfach zu finden, einmal *synchronisiert*, kommen die so regelmäßig wie das Finanzamt, alle 188 Byte.

 

Nicht zutreffend. Das regelmäßige Auftreten des Sync-Bytes kann durchaus dazu verwendet werden, TS-Daten auf einer Festplatte zu identifizieren. Falsch ist nur die Annahme, es gäbe einen spezifischen TS-Header, dessen einmaliges Vorhandensein den Beginn einer TS-Datei markiert. Jedes 188-Byte-Paket beginnt mit einem TS-Header - soweit sind die Ausführungen richtig.

 

Null-Pakete dienen vor allem dazu, die konstante Datenrate eines Transponders einzuhalten - also eine senderseitige Notwendigkeit. Mit Receivern hat dies nichts zu tun. Es handelt sich vermutlich um eine Verwechslung mit den bei MPEG2, H.264 und HEVC verwendeten Fülldaten, die dafür sorgen, dass eine bestimmte minimale Video-Datenrate nicht unterschritten wird.

[erwin]

OK, danke für die Präzisierung.

 

erwin

[erwin]

 

jedes 188-Byte-Paket beginnt mit einem TS-Header

 

... mit einem Sync-Byte

 

 

soweit sind die Ausführungen richtig.

 

Oh, nöh!

 

*Nur soweit ...*?

 

Hab ich nur soviel Schrott erzählt?

 

 

 

Null-Pakete dienen vor allem dazu, die konstante Datenrate eines Transponders einzuhalten - also eine senderseitige Notwendigkeit. Mit Receivern hat dies nichts zu tun. Es handelt sich vermutlich um eine Verwechslung mit den bei MPEG2, H.264 und HEVC verwendeten Fülldaten, die dafür sorgen, dass eine bestimmte minimale Video-Datenrate nicht unterschritten wird.

 

Ja, genau. Da ist ein Unterschied.

 

NULL-Pakete im TS mit *eigener PID=0x1FFF* dienen in der Tat *nur* dem Transponder (da sind schließlich mehrere Sender inkludiert).

 

Was der Receiver auswertet, ist ein einzelner PES. Da sind auch noch Fülldaten drin - genau wie Griga anmerkt. Die haben aber keine eigene (0x1FFF-) PID, sondern sind innerhalb des PES-Format kodiert

 

erwin

Edited December 25, 2013 by erwin

[Griga]

jedes 188-Byte-Paket beginnt mit einem TS-Header

 

 

... mit einem Sync-Byte

 

... mit einem 4 Byte großen Header, dessen Syntax und Semantik (jedoch nicht Inhalt!) bei allen TS-Paketen gleich ist

 

Dieser Header umfasst Sync-Byte, PID, continuity_counter und diverse Flags.