nav-Datei - Fehlerhafte Aufnahmen erkennen

[Homer]

Ist es möglich, durch die Analyse der originalen nav-Datei (und ggf. auch der inf-Datei) eine fehlerhafte Aufnahme zu erkennen? Ich vermute, dass es auf den jeweiligen Fall ankommt. Ich denke zunächst an die folgenden Fehler:

1. Klötzchenbildung
2. Senderausfall von ca. 2 Minuten mitten in der Aufnahme
3. vorzeitiges Aufnahmeende wegen voller Festplatte
4. vorzeitiges Aufnahmeende wegen Einfrierens
5. vorzeitiges Aufnahmeende wegen eines Reboots

Welche Infos sind in der nav enthalten? Wo finde ich eine Beschreibung der Struktur, um selbst ein Programm schreiben zu können?

Viele Grüße
Homer

[FireBird]

3 bis 5 lassen sich relativ leicht überprüfen. Die Aufnahmen enthalten einen PCR (Program Clock Reference). Das ist ein Zähler, der vom Studiotakt getaktet wird und aus der Differenz des letzten und des ersten PCR lässt sich die genaue Laufzeit der Aufnahmen berechnen. Vielleicht vom Ende der Datei etwas Abstand lassen, für den Fall dass dort Datenmüll liegt.

Die .nav enthält Pointer auf Picture-Start und andere Strukturen in der .rec. Aus dieser direkt wird man keine Rückschlüsse ziehen können. Da ich aber gerade im Ausland bin, habe ich keinen direkten Zugriff auf die nav-Details.

[Homer]

[quote="FireBird"]3 bis 5 lassen sich relativ leicht überprüfen. Die Aufnahmen enthalten einen PCR (Program Clock Reference). Das ist ein Zähler, der vom Studiotakt getaktet wird und aus der Differenz des letzten und des ersten PCR lässt sich die genaue Laufzeit der Aufnahmen berechnen. Vielleicht vom Ende der Datei etwas Abstand lassen, für den Fall dass dort Datenmüll liegt.[/quote]Das bedeutet ein Lesen der rec nur am Anfang und am Ende. Das wäre machbar.
[quote="FireBird"]Die .nav enthält Pointer auf Picture-Start und andere Strukturen in der .rec. Aus dieser direkt wird man keine Rückschlüsse ziehen können. Da ich aber gerade im Ausland bin, habe ich keinen direkten Zugriff auf die nav-Details.[/quote]Die Klötzchenbildung geht immer einher mit Sprüngen durch eine zu kleine nav. Die fehlenden Pointer müsste man erkennen können, da die Ziele der vorhandenen Pointer in diesem Fall springen, d. h. Lücken aufweisen.

Im Fall 2, der vergangene Nacht auftrat, ist eine solche Lücke nicht vorhanden. Wenn die Pointer keinen (senderseitigen) Zähler haben (laufende Nr. oder Zeit), könnte man auch erst durch Zugriff auf die rec diesen Fehler durch einen Laufzeitunterschied (Ende minus Anfang > Aufnahmedauer in inf) erkennen. Und um dann die Stelle zu finden (Vorlauf, Werbung, Nachlauf oder Film) müsste man die rec sequentiell lesen.

Dann warte ich auf die nav-Details. Zuvor will ich noch das TopfAutoRename für die falsch benannten nav-Dateien fertig schreiben.

Viele Grüße
Homer

[chris86]

Die nav-Struktur kann ich dir schicken.
Was du da vorhast, wird aber so wohl nicht funktionieren. Der PCR läuft auch bei Unterbrechungen weiter, so dass Anfang und Ende in jedem Fall korrekt sind. Außer es fehlt das Ende der Aufnahme - das lässt sich durch Vergleich der PCR-Differenz von Anfang und Ende der rec gut ermitteln.
Störungen zwischendurch können durch große Zeitsprünge innerhalb der nav ermittelt werden. Aber wenn du es richtig machen willst, musst du eigentlich die gesamte rec scannen, und den fortlaufenden Paket-Counter überprüfen.

[Homer]

[quote="chris86"]Die nav-Struktur kann ich dir schicken.[/quote]Ja bitte.
[quote="chris86"]Was du da vorhast, wird aber so wohl nicht funktionieren. Der PCR läuft auch bei Unterbrechungen weiter, so dass Anfang und Ende in jedem Fall korrekt sind.[/quote]Im Fall 2 merkt der Topf das und schreibt eine kürzere Laufzeit in die inf (Istdauer). Die Solldauer ist gleich Ende minus Anfang und in diesem Fall größer als die Istdauer.
[quote="chris86"]Aber wenn du es richtig machen willst, musst du eigentlich die gesamte rec scannen, und den fortlaufenden Paket-Counter überprüfen.[/quote]Das möchte ich nur dann machen, wenn ich schon sicher weiß, dass der Fehler 2 aufgetreten ist, nur noch nicht wo (Film oder nicht Film).

Viele Grüße
Homer

[jkIT]

[quote="Homer"]Das bedeutet ein Lesen der rec nur am Anfang und am Ende. Das wäre machbar.[/quote]
Was man auch probieren könnte, wäre eine Prüfung über die Größe der nav-Datei.
1 Frame, also 40ms, verbraucht bei SD-NAVs 32 Byte und bei HD-NAVs 64 Byte.
Eine signifikante Abweichung zur erwarteten Aufnahmelänge wäre evtl. ein Indiz.

[chris86]

Die nav-Strukturen (für SD und HD sind sie unterschiedlich):

Code: Alles auswählen

typedef struct
{
  dword                 SHOffset:24; // = (FrameType shl 24) or SHOffset
  dword                 FrameType:8;
  byte                  MPEGType;
  byte                  FrameIndex;
  word                  iFrameSeqOffset;
//  byte                  Zero1;
 [b] dword                 PHOffsetHigh;
  dword                 PHOffset;[/b]

  dword                 PTS2;
  dword                 NextPH;
[b]  dword                 Timems;[/b]
  dword                 Zero5;
} tnavSD;

typedef struct
{
  dword                 SEIPPS:24;
  dword                 FrameType:8;
  byte                  MPEGType;
  byte                  FrameIndex;
  word                  PPSLen;
//  byte                  Zero1;
[b]  dword                 SEIOffsetHigh;
  dword                 SEIOffsetLow;[/b]
  dword                 SEIPTS;
  dword                 NextAUD;
[b]  dword                 Timems;[/b]
  dword                 Zero2;

  dword                 SEISPS;
  dword                 SPSLen;
  dword                 IFrame;
  dword                 Zero4;

  dword                 Zero5;
  dword                 Zero6;
  dword                 Zero7;
  dword                 Zero8;
} tnavHD; 

Die fett gedruckten Werte könnten für dich nützlich sein... dort einfach auf ungewöhnlich große Sprünge testen.