Sync Byte Error

[siegi2000]

Hallo!
Ich bekomme seit Neuestem öfters sync byte errors (siehe Anhang).
Weiß jemand von euch was die bedeuten und ob die Auswirkungen auf die Bild oder Tonqulität haben.
Leider finde ich keine Sekundenangaben zu den Fehlern und kann somit nicht checken, ob die Videos an den Stellen einen Fehler haben.
Bei anderen Fehlen mache ich das immer so.

lg Siegi

[siegi2000]

Und noch eine Frage: Ist das immer der gleiche Fehler der sich dann über viele Pakete auswirkt oder sind das viele unabhängig Fehler?

[Cypheros]

Also normal ist das nicht. Könnte ein Problem mit dem Datenträger sein. Einfach mal neu formatieren. Falls es eine externe Festplatte ist ohne eigene Stromversorgung, mal versuchen ein Netzteil dran zu hängen. Receiver liefern teilweise nicht genug Strom über USB für die externe Platte.

[Mam]

nun ja, man könnte daraus aber mal die Idee ableiten, das Logfile doch vielleicht etwas kundenfreundlicher zu gestallten, z.B. durch Angabe der "bereinigten Laufzeit" darin.
Es hilft ja niemandem, wenn er da Zeit-/Positionsangaben findet, die als Basis die ungeschnittene Aufnahme haben. Die Fehlstellen sind hinterher nicht wiederzufinden.
Und da ja eh eine "Realtime Clock" beim Durchlauf angezeigt wird, stelle ich es mir nicht allzu kompliziert da, diese auch auszulesen und abzuspeichern 

[Cypheros]

Und da ja eh eine "Realtime Clock" beim Durchlauf angezeigt wird, stelle ich es mir nicht allzu kompliziert da, diese auch auszulesen und abzuspeichern

Ach ja? Was nützt Dir die "Realtime Clock" bei Interleave-Formaten wie TS? Da liegen liegen mehrere Sekunden zwischen Packet-Time und Presentation-Time. Da bei einem kaputten Paket ja nicht festzustellen ist, ob es mal ein Audio-/Video- oder sonstiges Paket war, gibt es keine Möglichkeit exakt festzustellen, wo der Fehler bei der Wiedergabe sichtbar oder hörbar wird.

[Mam]

Ach ja? Was nützt Dir die "Realtime Clock" bei Interleave-Formaten wie TS? Da liegen liegen mehrere Sekunden zwischen Packet-Time und Presentation-Time. Da bei einem kaputten Paket ja nicht festzustellen ist, ob es mal ein Audio-/Video- oder

Ach ja? Ich erinnere mich dunkel an jemanden, der stolz erzählt hat, er würde die entsprechenden Delays ja auslesen. Dann könnte seiner einer auch durch die mystische mathematische Funktion "Subtraktion" einen entprechenden Realtimewert ausrechnen. Entsprechenden Rechenregeln werden üblicherweise im zweiten oder dritten Schuljahr vermittelt...
Schwierig wird es erstmal danach, denn man weis ja nicht wirklich, wieviele Pakete fehlen. Einen "educated guess" könnte die Auswertung der Sequencenumber erlauben.

Es geht ja auch gar nicht so um die genaue Paketposition, eine Näherung auf ein paar Sekunden genau würde ja schon helfen. Nur mit der jetzigen "Skala" kann doch niemand wirklich etwas anfangen (der nicht Pakete runterbeten kann).

Der Mensch fleht doch nur um die Darstellung in einer menschlich nachvollziehbaren Maßeinheit...

[Cypheros]

Nochmal, für die ätere Generation!!!
Es steht nicht fest, zu welchem Stream ein kaputtes Paket gehört und deshalb kann auch das Delay nicht festgestellt werden, denn jeder Stream hat ein anderes Delay.
Videodaten haben eine variable Bitrate, da ist auch nix mit Interpolation.
Bei Audio-Streams taucht automatisch auch ein PES Paket-Size-Error auf, den man dann auch mit Time-Code im Log findet. Videodaten haben leider meist keine PES-Size aber deshalb setze ich mich nicht die nächsten 3 Monate hin und mache ein stochastische Untersuchung der Fehlerverteilungen. Selbst wenn das gelingen würde, was ist bei PCR-Wraps, Programm-Umschaltungen (WDR,NDR,SWR,etc.) und Timer-Sprüngen?

Ein Resync sollte niemals passieren!!! Auch nicht bei Empfangsstörungen!!! Ein TS-Paket bei DVB hat 188 Bytes. In den meisten Fällen, wo ein Resync passiert, tritt der Fehler beim Datentransfer auf.

[Djfe]

@ypheros, Mam
ich glaube Mam hat den Thread nur überflogen und missverstanden, dass es um die TS Sync Error geht, die bei blöden Fehlern mitten im Log ohne Zusammenhang und Timecode auftauchen kann

nun ja, man könnte daraus aber mal die Idee ableiten, das Logfile doch vielleicht etwas kundenfreundlicher zu gestallten, z.B. durch Angabe der "bereinigten Laufzeit" darin.
Es hilft ja niemandem, wenn er da Zeit-/Positionsangaben findet, die als Basis die ungeschnittene Aufnahme haben. Die Fehlstellen sind hinterher nicht wiederzufinden.
Und da ja eh eine "Realtime Clock" beim Durchlauf angezeigt wird, stelle ich es mir nicht allzu kompliziert da, diese auch auszulesen und abzuspeichern 

das hört sich für mich eher so an, als ob er von den normalen Fehlern spricht, die nachher auch in der Übersicht angezeigt werden -> "da würde es helfen wenn der Timecode danach und nicht von vor dem Schnitt angezeigt würde"

oder geht es doch um die Sync Error?
dann würde er meinen, dass du den letzten Timecode (den des letzten Paketes) dahinschreibst, dann weiß man an welcher Stelle man nach den TS Sync errorn in der Datei (in der gefixten) zu suchen hat, also wo Fehler zu sehen sein könnten
den Paketcode des letzten Paketes gibst du ja auch immer mit der Längenangabe unter dem Graphen während des Fixens an

[Djfe]

außerdem: es müsste doch eigentlich möglich sein die Fehlerstelle (zumindestens aus der originalen Datei) auszugeben, oder nicht? schließlich kennt der TSD doch die Stelle an die er zur Wiedergabe mit dem Splitter/Filter springen muss
und wenn der ne Zeitangabe braucht, dann eben die Zeit des letzten gültigen Pakets -2 Sekunden oder so

[Gundolf]

So ähnlich hab ich im Thread "Fehlerstelle in der TS-Datei finden" auch argumentiert. Die Zeitangaben im log sind kaum zu gebrauchen um die fehlerhafte Stelle zu finden/anzuschauen.

[Cypheros]

Sorry Leute, das Log ist hauptsächlich für mich gemacht um Probleme und Fehler zu finden.

Ich versuche das Log zukünftig etwas mehr danach zu trennen, was mich interessiert und das, was den Endanwender interessiert.

[Gundolf]

Super !!!

Wäre klasse wenn du auch, zumindest bei der korrigierten TS-Datei (log), ungefähre Zeitangaben einfügen könntest um den Fehler zu lokalisieren/ anschauen zu können. "Djfe" hat das ja schon erwähnt.

Gruß Gundolf

[Mam]

Super !!!

Wäre klasse wenn du auch, zumindest bei der korrigierten TS-Datei (log), ungefähre Zeitangaben einfügen könntest um den Fehler zu lokalisieren/ anschauen zu können. "Djfe" hat das ja schon erwähnt.

Gruß Gundolf

Du Opferlamm ! 

Willkommen im Jahre 1984... 

Wenn man sein Programmiersprech in hochdeutsch übersetzt heißt das: "ich mach den ganzen Kram raus aus dem Log, dann kann ein doofer Usah mir damit auch nich mea aufn Keks gehen!"

Ist bestimmt nicht das, was Du wolltest, aber applaudir ruhig weiter...

[Gundolf]

Ach was ... 

Man kann es doch dem User überlassen was im Log stehen soll. Oder es wird eine Sektion eingefügt die für Ottonormalverbraucher ausreicht. Das ganze Kauderwelsch kann doch bleiben.

[Djfe]

also sowas wie Verbose, Info, Warning, Error als Aufteilung?

wäre wohl zu viel des guten

gewisse Änderungen wären interessant, aber letztendlich ist das Log auch für erfahrene User interessant
es enthält schließlich nicht nur Infos die nur für Cypheros interessant sind

-> welche Streams sind im Original, welche Fehler sind in der Aufnahme, ggf. wie ist die Dateistruktur, wie viel Filler wurden entfernt, und vor allem: die Quelldatei und wann das Fixen war etc.