Im Log: "Paket discontinuity" - Hinweis auf mögliche Bildfehler?

[febefe]

Hallo,
habe manchmal in meinen HD-Aufnahmen sichtbare kurze Bildfehler (Pixel, Hänger...) unter 1 Sekunde.
Das Fehlerlog der Aufnahme-Software (DVBViewer) zeigt dabei keine Fehler an.

Im Log vom TSDoctor tauchen manchmal Warnings dieser Art auf:
TS  WARNING: For PID 1842 $01FA60A6: Paket discontinuity 8,1
Könnte dies ein Hinweis auf einen sichtbaren Bildfehler im Stream sein?
Falls ja, kann ich dies überprüfen?: wie kann ich von obiger Meldung auf den genauen Ort im Stream schließen?

Danke.

[Derrick]

Fehlende pakete durch z.b. empfangsstörungen werden als discontinuities erkannt. Die sind auch in den meisten fällen die ursache von bildstörungen. Fehlende pakete lassen sich hinterher nicht mehr reparieren sondern nur durch z.b. wiederholungen flicken, um synchronität zwischen bild und ton zu gewährleisten. Diese stellen werden im log durch einen offset (hier $01FA60A6) dokumentiert. Damit weiss natürlich nicht gleich den genauen zeitpunkt. Der liesse sich aber durch benachbarte zeitspempel bestimmen..

[sts78]

Wie oft synchronisiert sich ein HD-TS-Stream eigentlich neu? Im circa sekundentakt, alle paar Minuten? Weiß das jemand?
Bzgl. des vorliegenden Fehlersyndroms:  Wenn die Discontinuity bei sagen wir bei etwa Position 2min ist, ich aber eh die ersten 5 Minuten mit TSDoctor wegschneide, kann ich dann davon ausgehen, dass hinten von 5min an alles (wieder) synchron ist, weil zwiwschen dem Schluckauf bei 2min und meinem Beginn bei 5min längst wieder (zigmal?) synchronisiert wurde?

[Cypheros]

Hi,

das synchronisieren übernimmt das Wiedergabegerät. Der Transportstream enthält dazu die notwendigen Timerinformationen für jeden einzelnen Stream.
Schwierigkeiten mit fehlenden Paketen können aber auftreten, wenn der Stream in ein anderes Format gebracht werden soll oder Du einen Remuxer benutzst.
Schneidest Du die Problemstelle aber vorher mit dem TS-Doctor ab, ist der resultierende Stream fehlerfrei.

[febefe]

Danke Cypheros.

Funktioniert es denn auch andersherum?:
Wenn ich den Hinweis:
TS  WARNING: For PID 1842 $01FA60A6: Paket discontinuity 8,1
habe, kann ich davon aus schlussfolgern, an welcher Position im Stream sich das Phänomen befindet (an welcher Aufnahme-Zeit)?
Ich weiß ja aufgrund der Angabe noch gar nicht, ob sich das Problem nach 2 Minuten oder vielleicht erst nach 30 Minuten Aufnahme verortet.

[hvda]

Wenn ich den Hinweis:
TS  WARNING: For PID 1842 $01FA60A6: Paket discontinuity 8,1
habe, kann ich davon aus schlussfolgern, an welcher Position im Stream sich das Phänomen befindet (an welcher Aufnahme-Zeit)?
Ich weiß ja aufgrund der Angabe noch gar nicht, ob sich das Problem nach 2 Minuten oder vielleicht erst nach 30 Minuten Aufnahme verortet.

(Sorry to intrude in english)

I use following method to find the (approximate) recording time of packet discontinuity failures in an HD DVBS transport stream (for SD streams, I use ProjectX) :

METHOD A : with program MPEG-2 TS Packet Analyser
(1) Open .ts transport stream file with program MPEG-2 TS Packet Analyser.
(2) In MPEG-2 TS Packet Analyser : do "Check continuity count" (in menu > Tools). MPEG-2 TS Packet Analyser produces a list with all packet discontinuity errors; example : list is something like this :

   ERROR! packet: 12 pid: 82 found: 2 expected: 5
   Complete, 12284400 packets checked
   1 errors found
   
Save the error list somewhere (copy/paste -> Notepad) before you close the window with the list.
(3) In MPEG-2 TS Packet Analyser : browse forward from the begin of the ts file until you find a packet with an Adaptation Field and a PCR (Program Clock Reference); example : something like this showing up in the "interprete" textbox of MPEG-2 TS Packet Analyser:

   Adaptation fields
      Adaptation_field_length: 7
      discontinuity_indicator: False
      random_access_indicator: False
      ES_priority_indicator: False
      PCR_flag: True
      OPCR_flag: False
      splicing_point_flag: False
      transport_private_data_flag: False
      adaptation_field_extension_flag: False
      PCR: 389263169447

Take note of the (decimal) PCR value (example : 389263169447) and convert to a HH:MM:SS.nnn format :
PCR decimal = number of samples of a 27 MHz clock (example : PCR 389263169447 decimal = 04:00:17.154 in format HH:MM:SS.nnn). (I made myself a little toolbox with Visual Studio VB to do these calculations).

Remember this PCR value as "PCR_Begin".

(4) In MPEG-2 TS Packet Analyser : jump (*) to a packet (number) that is present in the list with all packet discontinuity errors (see point 2) (* : = Button "Goto packet number").
(5) Starting from this packet with error, Browse backwards in the stream until you find a packet with an Adaptation Field and a PCR (Program Clock Reference); eventually : use the PID filter while browsing.
Take note of the (decimal) PCR value and convert to a HH:MM:SS.nnn format (see point 3 above). Remember this PCR value as "PCR_Just_Before_Error".
(6) Subtract : PCR_Just_Before_Error - PCR_begin = approximate time "just-before-error" (starting from zero) in the recording when the discontinuity error occured.
(7) Eventually repeat steps 4 to 6, but browse forward instead of backwards to find an approximate time "just-after-error" (starting from zero) in the recording when the discontinuity error occured.
( Eventually repeat steps 4 to 6 for another packet (number) that is present in the list with packet discontinuity errors.

Remarks:

(a) MPEG-2 TS Packet Analyser: Instead of searching for PCR values in the ts stream, you can also look for PTS values; but remember: the conversion of PTS decimal values to a format HH:MM:SS.nnn is different (PTS = number of samples of a 90 KHz clock; example : PTS 1297559834 decimal corresponds to 04:00:17.331 ).

(b) METHOD B : Once you have the list of packet numbers with discontinuity errors, you can also use program MPEG TS Utils to find PCR_Begin, PCR_Just_Before_Error, PCR_Just_After_Error values immediately in format HH:MM:SS.nnn.
Browsing packets in MPEG TS Utils is based on a zero-based packet offset in bytes (in hexa representation) instead of decimal one-based decimal packet number; the maths : 1 DVBS ts packet = 188 bytes -> packet_offset = (packet_number-1)*188
(MPEG TS Utils = limited trial period).

(c) METHOD C : for SD captures : ProjectX shows approx. time in recording of packet discontinuity failures in a user-friendly HH:MM:SS.nnn format.

(d) I think that TS Doctor logs packet discont. failures with a zero-based packet number in hexadecimal format (and not with a hexadecimal byte offset); at least in v.1.0.89, this seems the case.

Conclusion :
Yes you can "davon aus schlussfolgern, an welcher Position im Stream sich das Phänomen befindet (an welcher Aufnahme-Zeit)" but, as you may have noticed, it's not quite user-friendly, and it takes time.
So maybe we could ask Cypheros for a favor : to log approximate values of time (with reference to the beginning of the recording) in HH:MM:SS.nnn format of packet discontinuity failures, like ProjectX does (maybe based on the PCR time table, built during Analysis of a transport stream).

[febefe]

Hey hvda,

thanks a lot for your answer - that was the info I was looking for!

Let's hope that Cypheros can indeed integrate a time log for occurences of packet discontinuity failures.

[Derrick]

Hallo,
habe manchmal in meinen HD-Aufnahmen sichtbare kurze Bildfehler (Pixel, Hänger...) unter 1 Sekunde.
Das Fehlerlog der Aufnahme-Software (DVBViewer) zeigt dabei keine Fehler an.

Wenn es nur darum geht, die fehlerstellen von aufnahmen mit dem dvbviewer zeitlich zu kennzeichnen, müssen im dvbviewer nur die richtigen häkchen gesetzt werden (write extended log). Besser ist es, fehler zu vermeiden

[febefe]

Die erweiterte Log-Funktion in DVBViewer nutze ich bereits (in der Regel werden hierüber nach der Aufnahme keine Fehler angezeigt).

Es geht mir darum, zu überprüfen, ob sich an den von TS-Doctor angezeigten Stellen mit "Paket discontinuites" (sichtbare) Fehler befinden oder nicht.
Kürzlich habe ich festgestellt, dass manche Fehler erst nach der Bearbeitung mit TS-Doctor sichtbar werden bzw. entstehen (siehe meinen anderen, neuen Thread dazu).

[Derrick]

in der Regel werden hierüber nach der Aufnahme keine Fehler angezeigt

also manchmal doch, oder wie? 

[febefe]

@ Derrick:

tut mir leid, aber ich verstehe nicht den Hintergrund deiner Nachfrage...