Jump to content

Seit einigen Wochen defekte Aufnahmen


dgdg

Recommended Posts

Hallo,

 

seit einigen Wochen (ungefähr seit dem Wechsel auf Version 4 - muss aber nicht damit zusammenhängen) habe ich sporadisch immer mal wieder völlig defekte Aufnahmen. Völlig defekt heisst, dass ProjextX beim Demuxen Tausende von Fehlern meldete und die erzeugten Dateien nur wenige 100MB groß sind. VLC spielt die defekten Aufnahmen auch nicht ab.

 

Komischerweise stehen in der Aufnahme-Logdatei als auch in der EPG-Infodatei meistens nur einige wenige oder sogar überhaupt keine Fehler drin.

 

Da ich davon ausgehe, dass DVBViewer den Datenstrom, so wie er von der SAT-Karte kommt, aufzeichnet, hatte ich die ganze Zeit meine SAT-Anlage und eine der SAT-Karten im Verdacht.

 

Aber gestern abend habe ich zwei Sendungen gleichzeitig vom gleichen Transponder aufgenommen. Die eine ist fehlerfrei, die andere wieder völlig defekt. Kann also eigentlich nicht sein, das es an der Hardware liegen. Die Logdatei zeigt zwar diesmal 53 Fehler, aber deswegen ist doch normalerweise nicht die ganze Aufnahme von vorne bis hinten defekt!?

 

Hat jemand eine Idee, was da los sein könnte? Was kann den DVBViewer oder irgendeine andere beteiligte Komponente so aus dem Tritt bringen?

 

EDIT: Falsche Support.zip entfernt. Siehe weiter unten.

Edited by dgdg
Link to comment
Völlig defekt heisst, dass ProjextX beim Demuxen Tausende von Fehlern meldete und die erzeugten Dateien nur wenige 100MB groß sind. Komischerweise stehen in der Aufnahme-Logdatei als auch in der EPG-Infodatei meistens nur einige wenige oder sogar überhaupt keine Fehler drin.

Würde ich als Hinweis verstehen, dass beim Schreiben auf die Platte bzw. beim Puffern massiv Daten verloren gehen. Das Problem ist bislang bei folgenden Szenarien bekannt:

 

- Hohe CPU-Last während der Aufnahme, der DVBViewer kann seine Recorder-Puffer nicht rechtzeitig wegschreiben, oder Windows seinen Festplatten-Cache.

 

- Der DVBViewer wurde im Taskmanager auf Echtzeit-Priorität gestellt, was Windows ebenfalls daran hindern kann, seinen Festplatten-Cache rechtzeitig wegzuschreiben.

Link to comment
- Hohe CPU-Last während der Aufnahme, der DVBViewer kann seine Recorder-Puffer nicht rechtzeitig wegschreiben, oder Windows seinen Festplatten-Cache.

- Der DVBViewer wurde im Taskmanager auf Echtzeit-Priorität gestellt, was Windows ebenfalls daran hindern kann, seinen Festplatten-Cache rechtzeitig wegzuschreiben.

 

Gegen beide Varianten spricht, dass ja parallel eine zweite Sendung fehlerfrei aufgenommen wurde. Bei einem Engpass beim Wegschreiben sollten doch eigentlich beide Aufnahmen betroffen sein?

 

Ansonten habe ich im DVBViewer die Prio auf "Hoch" eingestellt. Diese Einstellung hat sich aber schon über Jahre bewährt und nie zu Problemen geführt. Oder hat sich mit der 4.0 hier irgendwas verändert? Im Taskmanager habe ich keine Prios verändert.

 

 

Ich habe noch eine Verständnisfrage dazu: Wenn Windows mit dem Wegschreiben der Daten nicht nachkommt, dann müssten doch die Aufnahmedateien deutlich kleiner sein. Das sind sie aber nicht. Sie haben in etwas die Größe, die auf Grund der Datenrate zu erwarten wäre.

 

Ich habe das mal anhand der letzten Aufnahme grob überschlagen: 9120 sec Aufnahmezeit mit einer mittleren Datenrate von 0,452 MB/s ergibt einen Datenmenge von 4122,24 MB. Die Dateigröße beträgt 4118 MB. Kommt also ungefähr hin. Da scheinen nicht viele Daten beim Wegschreiben verloren gegangen zu sein.

 

Oder mache ich da jetzt einen Denkfehler?

Link to comment

Aufschlussreich wäre, welche Fehler ProjectX meldet, welches Aufnahmeformat du verwendest, ob es sich um verschlüsselte Sender handelt... für eine Diagnose fehlen wichtige Details.

 

TS-Pakete sind immer 188 Bytes groß und beginnen mit dem Sync-Byte 0x47. Wenn der Recorder oder Windows ganze Puffer verliert, fehlen typischerweise Datenblöcke, deren Umfang kein Vielfaches von 188 Bytes beträgt, d.h. die TS-Paketstruktur stimmt an der Stelle nicht mehr, was ProjectX entsprechend bemängelt.

 

Die Logdatei zeigt zwar diesmal 53 Fehler, aber deswegen ist doch normalerweise nicht die ganze Aufnahme von vorne bis hinten defekt!?

Dabei werden nur fehlende TS-Pakete erfasst, d.h. der Recorder untersucht laufend den in TS-Paketen enthaltenen Continuity Counter. Sonstwie verfälschte Daten bemerkt er nicht.

Link to comment
hmm? Da hilft uns die support.zip von der 3.9.2.0 vom letzten jahr mai aber wenig... :huh:

 

Sorry, da hab ich wohl beim Hochladen das falsche Verzeichnis erwischt. ;)

 

@Griga

Ich habe auch mal die Log-Datei von ProjectX angehängt. Aufnahmeformat in PS/MPG (nur eine Tonspur). Keine verschlüsselten Sender (habe keine Hardware dafür).

 

Ich versuche mal den Anfang der MPG-Datei zu extrahieren, dann könnte ich sie irgendwo zu Analyse hochladen.

Edited by dgdg
Link to comment

Bei den Zeitstempeln (PTS) geht es drunter und drüber. Diese werden bei MPG auf Basis der PTS im originalen TS vom DVBViewer neu erzeugt. Könnte sich um einen Fehler im Recorder handeln, oder um eine Folgeerscheinung eines fehlerhaften TS. Ohne den TS im Nachhinein schwer zu sagen.

Link to comment
Bei den Zeitstempeln (PTS) geht es drunter und drüber. Diese werden bei MPG auf Basis der PTS im originalen TS vom DVBViewer neu erzeugt. Könnte sich um einen Fehler im Recorder handeln, oder um eine Folgeerscheinung eines fehlerhaften TS. Ohne den TS im Nachhinein schwer zu sagen.

 

Ich könnte auf TS umstellen und schauen, ob das Problem noch auftritt. Das ist aber langwierig, weil der Fehlen nur sporadisch alle 1-2 Wochen auftritt (und das bei 3-4 Aufnahmen pro Tag). Man müsste also im ungünstigsten Fall viele Wochen warten, um einigermaßen sicher zu sein, dass es an der MPG-Erzeugung liegt.

 

EDIT: Ich hab einfach mal umgestellt. Vielleicht haben wir ja "Glück" und es zerbröselt ziemlich schnell auch eine TS-Datei. Dann kann man den Fehler bei MPG-Erzeugung wohl ausschließen.

Edited by dgdg
Link to comment

Hmm, das ist ja interessant. Wenn ich mit dem TSPlayer die Audiospur deines Samples als MP2-Datei extrahiere, hört es sich eindeutig so an, als würde mittendrin auf ein anderes Programm umgeschaltet. Probiere das auch mal. Vielleicht kannst du identifizieren, woher das stammt.

 

Es gibt noch einen anderen Effekt, den ich nicht verstehe. Obwohl die Eigenschaftsseite des DVBSource einen heftigen Sprung bei den Zeitstempeln anzeigt, spricht die Kontrolle der Zeitstempel-Kontinuität nicht an. Das muss ich noch genauer untersuchen...

Link to comment
Hmm, das ist ja interessant. Wenn ich mit dem TSPlayer die Audiospur deines Samples als MP2-Datei extrahiere, hört es sich eindeutig so an, als würde mittendrin auf ein anderes Programm umgeschaltet. Probiere das auch mal. Vielleicht kannst du identifizieren, woher das stammt.

 

Ich bin gerade dabei, die gesamte Tonspur zu extrahiert und habe mir den Anfang der Aufnahme auch nochmal in ProjectX angesehen (ProjectX zeigt in der Vorschau zumindest den Film an, wenn er ihn auch nicht ordentlich demuxt).

 

Ich glaube das mit dem Wechsel des Senders täuscht. Am Anfang der Aufnahme läuft ein Bericht über die Berlinale. Dabei werden immer wieder kurze Filmschnippsel gezeigt. Dadurch entsteht wohl der Eindruck eines Senderwechsels.

 

Das kurze Quitschen im Audiostream bei ersten Fehler lässt schon darauf schließen, dass hier wohl ein Stück fehlt.

 

EDIT: Habe gerade in die MP2-Datei der gesamten Aufnahme reingehört. Bis auf den einen Fehler (nach 9 Sekunden), scheint der Audiostream fehlerfrei zu sein.

Edited by dgdg
Link to comment

Wegen der intakten Audiospur hatte ich den Verdacht, dass vielleicht ProjectX wegen eines einmaligen Fehlers aus dem Tritt kommt und deswegen den Rest der MPG-Datei als fehlerhaft erkennt. Deswegen habe ich mal die ersten 100MB weggeschnitten und versucht den Rest zu demuxen. Bringt aber nichts (gleiche Fehler).

 

Könnte es sein, dass der DVBViewer Recorder wegen dieses einen Fehlers aus dem Tritt gekommen ist und deswegen die Zeitstempel des restlichten Videostreams durcheinander geschmissen hat? Das würde erklären, warum der Audiostream offensichtlich intakt ist.

 

Interessant ist ja auch, das ProjectX in der Schnitt-Vorschau die Aufnahme ohne Murren und vollständig anzeigt. Es sind also wohl alle Videoframes vorhanden. In der Vorschau werden wohl die Zeitstempel nicht verwendet!?

Edited by dgdg
Link to comment
Das kurze Quitschen im Audiostream bei ersten Fehler lässt schon darauf schließen, dass hier wohl ein Stück fehlt.

Mit Sicherheit. Die Kontrolle der Zeitstempel-Kontinuität im DVBSource spricht nicht an, weil die einzelnen Sprünge im Sample zu klein sind. Sie überschreiten nicht den Schwellwert von 5 Sekunden. Wenn ich ihn im Code auf 1 Sekunde setze, sieht es schon anders aus.

 

Wenn der Recorder einen Fehler (= eine Diskontinuität bei den TS-Paketen) registriert, geht daraus nicht hervor, wieviele Pakete fehlen. Es besagt nur, dass welche fehlen. Könnten pro Fehler eine ganze Menge sein. MPG als Format verstärkt i.a. die daraus resultierenden Probleme.

 

Der DVBViewer-Recorder behandelt übrigens bei MPG-Aufnahmen auch Zeitstempel-Diskontinuitäten. Bei einem unbotmäßigen Sprung wiederholt er die letzte PTS und berechnet einen Korrektur-Offset für alle nachfolgenden PTS, weil das zumindest dafür sorgt, dass die Wiedergabe nicht hängenbleibt. Dazu passt die ProjectX-Angabe:

 

191 GOPs mit gleichem PTS-Wert für verschiedene Bilder gefunden!

Hat in diesem Fall aber offenbar nichts genützt, da es auch Serien von kleineren Sprüngen unterhalb des Schwellwertes gibt, die kumulativ die Wiedergabe trotzdem festhängen lassen.

 

Vorläufiges Fazit: Bei der Aufnahme sind offenbar mehrfach größere Datenblöcke verloren gegangen. Wenn es ein Empfangs/Treiber-Problem wäre, müsste eine gleichzeitige Aufnahme vom gleichen Transponder mit dem gleichen Gerät (!) auch gestört sein. Wenn die Kontrolle der Zeitstempel-Kontinuität bei MPG-Aufnahmen zugeschlagen hat, müssen die Lücken schon im TS gewesen sein. Ergibt noch kein klares Bild.

Link to comment
Könnte es sein, dass der DVBViewer Recorder wegen dieses einen Fehlers aus dem Tritt gekommen ist und deswegen die Zeitstempel des restlichten Videostreams durcheinander geschmissen hat? Das würde erklären, warum der Audiostream offensichtlich intakt ist.

Kann man nicht ausschließen. Das würde die Behandlung von Zeitstempel-Diskontinuitäten bei MPG-Aufnahmen betreffen, die eventuell einmalig ausgelöst wurde, und danach lief es dann schief.... der Code sollte auf jeden Fall noch mal überprüft werden.

Link to comment
Vorläufiges Fazit: Bei der Aufnahme sind offenbar mehrfach größere Datenblöcke verloren gegangen. Wenn es ein Empfangs/Treiber-Problem wäre, müsste eine gleichzeitige Aufnahme vom gleichen Transponder mit dem gleichen Gerät (!) auch gestört sein.

 

Von einer Störung durch die SAT-Anlage war ich bisher ausgegangen. Aber da ich nun zwei parallele Aufnahmen vom gleichen Transponder vorliegen haben, von denen nur eine defekt ist, vermute ich das Problem beim DVBViewer.

 

Auf jeden Fall ist das Problem neu. Drei Jahre lief alles fehlerfrei und dann plötzlich alle paar Tage diese Fehler.

 

Am 21.12. habe ich die 4.0 aufgespielt. Am 5.1. ist das Problem zum erstmal aufgetreten (ich kann das genau nachvollziehen, weil ich beim ersten Auftreten sicherheitshalber die Aufnahmeplatte gewechselt habe, weil ich ein Problem beim Wegschreiben vermutete und die Platte vorher schonmal Probleme gemacht hat).

 

Es könnte also gut ein Zusammenhang zwischen 4.0 und dem Fehler bestehen.

Link to comment

Noch ein Hinweis:

 

Die zweite intakte Aufnahme startete später als die defekte und hat daher von der Störung nichts mitbekommen. D.h. die Störung vermute ich schon bei der SAT-Anlage. Nur dass nach so einer Störung der ganze Rest der Aufnahme hinüber ist - das ist neu.

 

Ich hatte auch schon den Fall, dass mehrere parallele Aufnahmen defekt waren. Also wenn so eine Störung über einen Transponder reinkommt, dann erwischt es vermutlich alle gerade laufenden Aufnahmen.

Edited by dgdg
Link to comment
Wegen der intakten Audiospur hatte ich den Verdacht, dass vielleicht ProjectX wegen eines einmaligen Fehlers aus dem Tritt kommt und deswegen den Rest der MPG-Datei als fehlerhaft erkennt. Deswegen habe ich mal die ersten 100MB weggeschnitten und versucht den Rest zu demuxen. Bringt aber nichts (gleiche Fehler).

Lässt sich die Datei mit den weggeschnittenen 100 MB im DVBViewer einwandfrei wiedergeben? Oder kommt es dabei auch zu massiven Störungen?

 

Ich habe versucht, den Effekt zu provozieren. DVB-T-Aufnahme mit dem DVBViewer Pro als MPG. Zeitweise den Antennenstecker abgezogen. Eine Aufname mit mehreren kurzen Unterbrechungen (160 Fehler im Log). Eine mit einer längeren (> 5s), so dass die Kontrolle der Zeitstempel-Kontinuität aktiv wurde.

 

Beide Aufnahmen ließen sich (mit entsprechenden Störungen) abspielen, ohne dass die Wiedergabe in den Streik trat. Die auf der Eigenschaftsseite des DVBSource angezeigten Zeitstempel wiesen bei der ersten Aufnahme die erwarteten (kleineren) Sprünge auf. Bei der zweiten Aufnahme war die Kontinuität in Ordnung, d.h. der DVBViewer hat die längere Unterbrechung erfolgreich ausgebügelt. ProjectX meldete beim Demuxen natürlich Fehler, aber nur einzelne, nicht in endloser Serie. Wie es zu dem Chaos in deinen Aufnahmen kommt, bleibt damit nach wie vor unklar. Im Code habe ich bislang nichts gefunden, dass dies erklären könnte.

Link to comment
Ich habe versucht, den Effekt zu provozieren. DVB-T-Aufnahme mit dem DVBViewer Pro als MPG. Zeitweise den Antennenstecker abgezogen. Eine Aufname mit mehreren kurzen Unterbrechungen (160 Fehler im Log). Eine mit einer längeren (> 5s), so dass die Kontrolle der Zeitstempel-Kontinuität aktiv wurde.

Solche massiven Aussetzer hatte ich ja immer schon mal (Schnee auf der Schüssel etc.). Das hat aber bisher immer nur zu zeitlichen begrenzten Aussetzern geführt.

 

Lässt sich die Datei mit den weggeschnittenen 100 MB im DVBViewer einwandfrei wiedergeben? Oder kommt es dabei auch zu massiven Störungen?

Habe es gerade ausprobiert: Es wird zwar abgespielt, aber ohne Ton und mit starkem Ruckeln.

Edited by dgdg
Link to comment

Hi,

 

auch ich habe Probleme mit der Aufnahme von Sendungen. Bei mir ist das reproduzierbar, immer wenn ich auf Premiere 4 Filme aufnehmen will die um 20:15 beginnen. Die Live-Wiedergabe der Sendung funktioniert, nur die Aufnahmen sind defekt. Kurz bevor der Film beginnt sieht man bei der Live-Wiedergabe ein kurzes stocken, danach läuft sie aber einwandfrei weiter. Die Aufnahme ist dann auch nur bis zum Filmstart in Ordnung.

 

In der Aufnahme Log-Datei ist auch immer ein Fehler kurz vor Filmbeginn eingetragen:

 

PREMIERE 4 16.02.2009

 

D:\Recording\24 (24) - 7_02-16_20-05-00_PREMIERE 4.mpg

 

Device: TechnoTrend BDA/DVB-S Tuner

 

20:05:00 / 00:00:00 (~ 0,0 MB) Start

20:05:03 / 00:00:03 (~ 0,2 MB) PID 767: MPEG2 Video, 16:9, 720x576, 25 fps

20:05:03 / 00:00:03 (~ 0,2 MB) PID 768: MPEG Audio Stereo, 48 khz, 192 kbps

20:05:03 / 00:00:03 (~ 0,2 MB) PID 771: AC3 Audio Stereo Surround, 48 khz, 384 kbps

20:14:29 / 00:09:29 (~ 268,6 MB) PID 769: MPEG Audio Stereo, 48 khz, 192 kbps

20:14:43 / 00:09:43 (~ 272,2 MB) Errors: 4

20:14:56 / 00:09:56 (~ 277,4 MB) PID 771: AC3 Audio 5.1, 48 khz, 384 kbps

20:56:25 / 00:51:25 (~ 1470,6 MB) PID 771: AC3 Audio Stereo Surround, 48 khz, 384 kbps

20:57:34 / 00:52:34 (~ 1493,6 MB) PID 767: MPEG2 Video, 4:3, 720x576, 25 fps

20:58:34 / 00:53:34 (~ 1522,8 MB) PID 767: MPEG2 Video, 16:9, 720x576, 25 fps

21:15:00 / 01:10:00 (~ 1963,8 MB) Stop

 

 

Wenn ich die Aufnahme durch ProjectX jage, dann meldet das Programm einen Haufen Fehler.

 

24__24____7_02_16_20_05_00_PREMIERE_4_log.txt

 

Ich hab das mit der DVBViewer Version 4.0 / DVB Source 3.3.3.0 und der Beta 4.0.1.11 getestet, aber bei beiden das gleiche Problem.

 

Hardware: TechniSat SkyStar HD und AlphaCrypt Classic (3.16) mit Premiere S02 Abbokarte.

 

support.zip

Link to comment

Da gibt es offenbar eine Diskontinuität bei den Zeitstempeln. Ähnliches habe ich schon in einem Sample von Select Kino (Kabel Deutschland, Astra 23° Ost) gesehen. Da werden offenbar Trailer und Filme aneinander geklatscht, ohne auf eine DVB-konforme kontinuierliche Fortschreibung der Zeitstempel zu achten. Und ProjectX reagiert auf sowas äußerst ungehalten (IMO etwas übertrieben). Auch eine Art, unerwünschte "Aufnehmer" zu behindern. Bei Premiere wäre mir das allerdings neu.

 

Ich wundere mich darüber, dass der DVBViewer Pro 4.0 das bei der MPG-Aufnahme nicht automatisch ausgebügelt hat. Soweit ich weiß, wurde die Zeitstempel-Korrektur für das Format in der Version schon implementiert. Wie auch immer, es wird in nächster Zeit eine neue TSPlayer-Version geben, die sowas auch nachträglich hinbiegt, und dann schauen wir mal...

Link to comment
Da werden offenbar Trailer und Filme aneinander geklatscht, ohne auf eine DVB-konforme kontinuierliche Fortschreibung der Zeitstempel zu achten. Und ProjectX reagiert auf sowas äußerst ungehalten (IMO etwas übertrieben). Auch eine Art, unerwünschte "Aufnehmer" zu behindern. Bei Premiere wäre mir das allerdings neu.

 

Falls es sich hier tatsächlich um das gleiche Problem handelt, wie bei mir: Es ist ja nicht nur ProjectX, das damit Problem hat. VLC spielt die Aufnahmen auch nicht ab und TSPlayer nur ruckelnd.

 

Seit ich auf Aufnahmeformat TS umgestellt habe, ist das Problem nicht mehr aufgetreten. Was natürlich auch Zufall sein könnte.

Link to comment

Könnte ein Problem der Zeitstempel-Diskontinuitäten-Behandlung bei MPG sein. Aber bislang fehlt mir ein Ansatz, es genau zu orten, und jegliche Idee, wie es zustande kommen könnte. Ich warte auf eine Gelegenheit, die es reproduzierbar macht...

Link to comment
  • 3 weeks later...

Seit der Umstellung auf Aufnahmeformat *.ts ist das Problem nun seit 3 Wochen nicht mehr aufgetreten zu sein. Scheint also definitiv ein Fehler bei der Aufnahme im mpg-Format zu sein.

 

Schade, dass das nicht wirklich von Interesse zu sein scheint. Damit ist die Einstellung Aufnahmeformat=*.mpg erstmal nicht mehr zu benutzbar und sollte konsequenter weise ganz rausgenommen werden.

Edited by dgdg
Link to comment
Schade, dass das nicht wirklich von Interesse zu sein scheint.

Das ist von Interesse, aber die Ursache mangels ausreichender Hinweise nicht ermittelbar. Insbesondere fehlt die Möglichkeit, es zu reproduzieren, z.B. mit einer TS-Aufnahme, deren Konvertierung nach MPG mit dem TSPlayer 2.1 zu diesem Fehler führt - der TSPlayer verwendet die Recorder-Engine für Konvertierungen, nimmt eine Datei also praktisch noch mal neu auf. Was bisher unternommen wurde:

 

- Analyse deines Samples.

 

- MPG-Testaufnahme mit künstlich herbeigeführten Diskontinuitäten.

 

- Untersuchung des Codes auf eventuelle Schwachstellen.

 

bislang ohne Befund.

 

Damit ist die Einstellung Aufnahmeformat=*.mpg erstmal nicht mehr zu benutzbar und sollte konsequenter weise ganz rausgenommen werden.

Nur wegen dir??? Bislang gibt es keine weiteren entsprechenden Rückmeldungen. Wenn wir jede Funktion, die sich bei irgendeinem Anwender aus irgendeinem Grund als problematisch erweist, sofort rausnehmen würden, wäre der DVBViewer bald funktionslos. Du verallgemeinerst hier deine Erfahrung ohne stichhaltige Belege, dass es sich um ein allgemeines Problem handelt.

Link to comment
Das ist von Interesse, aber die Ursache mangels ausreichender Hinweise nicht ermittelbar. Insbesondere fehlt die Möglichkeit, es zu reproduzieren, z.B. mit einer TS-Aufnahme, deren Konvertierung nach MPG mit dem TSPlayer 2.1 zu diesem Fehler führt

Dazu müsste ich meine Aufnahmen parallel in MPG und TS machen um dann bei einer fehlerhaften MPG-Aufnahme eine TS-Datei für die Analyse zu haben. Da man das Format nicht individuell wählen kann, müsste dafür eine zweite DVBViewer-Instanz parallel laufen. Über den Server müsste das machbar sein.

 

Reicht der Server die Daten 1:1 durch, oder würde das zwischenschalten des Servers den Aufnahmestream verändern und damit den Test verfälschen?

 

Nur wegen dir??? Bislang gibt es keine weiteren entsprechenden Rückmeldungen.

Wenn es irgendeinen Hinweis gäbe was ausgerechnet bei mir falsch läuft. An der Aufnahme ist doch keine Fremdkomponenten beteiliegt. Und wenn TS-Format funktioniert, liegt es ja vermutlich auch nicht an den Treibern.

Link to comment
Dazu müsste ich meine Aufnahmen parallel in MPG und TS machen

Nein. Nur ab und zu eine TS-Aufnahme mit dem TSPlayer nach MPG konvertieren und schauen, ob das Ergebnis verwertbar ist. Damit erhälst du dann gleichzeitig risikofrei das ursprünglich gewünschte Format.

 

Es könnte sich allerdings um einen Fehler handeln, der nur im DVBViewer Pro auftritt, nicht im TSPlayer. Die relevanten Codepassagen habe ich jedoch bereits verglichen. Die verwendeten Recorder-Engines sind weitgehend identisch.

 

Wenn es irgendeinen Hinweis gäbe was ausgerechnet bei mir falsch läuft.

Tja, wer weiß. In deinem Sample waren ja nicht nur die Zeitstempel konfus, sondern es fehlte offensichtlich ein größeres Stück der Aufnahme. Wenn es ein Problem der Recoder-Engine bei MPG ist, tritt es vielleicht nur als Folge eines vorangehenden anderen Fehlers auf. Chaos-Management greift immer nur bis zu einem gewissen Grad von Durcheinander. :blink:

Link to comment

Die Fehler treten nicht nur bei dgdg auf.

 

Bei mir sind einige Aufnahmen im MPG-Format, die auf Premiere 4 um 20:10 starten, defekt. Seit dem ich auf TS-Format umgestellt habe sind die Aufnahmen in Ordnung. Ab und zu ist auch ein Fehler im Log vermerkt aber ich kann die Datei abspielen und auch mit ProjektX weiter verarbeiten, was mit dem Aufnahmen im MPG-Format nicht möglich war.

 

Die Aufnahmen im MPG-Format lassen sich ab der Fehlerstelle nicht wiedergeben, auch der neue TS-Player kann mit den Aufnahmen nix anfangen.

 

Ich hab eine Aufnahme im TS-Format, wie immer mit Fehler kurz vor Filmbeginn, durch den TS-Player gejagt und in das MPG-Format konvertiert. Die Filmdatei lässt sich normal wiedergeben und bleibt auch nicht an der fehlerhaften Stelle stehen.

Link to comment
Ich hab eine Aufnahme im TS-Format, wie immer mit Fehler kurz vor Filmbeginn, durch den TS-Player gejagt und in das MPG-Format konvertiert. Die Filmdatei lässt sich normal wiedergeben

Könnte das Zufall sein? Ich frage wegen

 

Bei mir sind einige Aufnahmen im MPG-Format, die auf Premiere 4 um 20:10 starten, defekt.

...also nicht alle? Ich kann suchen wie ich will: Der Code, mit dem der DVBViewer Pro "on th fly" und der TSPlayer nachträglich TS in MPG umwandeln, ist in allen relevanten Teilen identisch.

 

Es scheint, dass Ungereimtheiten im TS vorausgehen, wenn es bei MPG schiefläuft. Wenn ich ein TS-Sample habe, dessen Konvertierung nach MPG im TSPlayer zu diesem Effekt führt, kriege ich es zu fassen. Ansonsten weiß ich nicht, wo ich ansetzen soll. Wie gesagt scheiterten hier bislang alle Versuche, es zu provozieren.

Link to comment

Nur Aufnahmen von Premiere 4 die um ca. 20:05 starten, in denen dann ein Fehler kurz vor Filmbeginn in der Logdatei steht und die mit MPG-Format aufgenommen sind. Die Aufnahmen kann man dann nur bis zum Fehler wiedergeben.

 

Das sieht dann immer so aus...

 

24__24____1_02_07_20_05_01_PREMIERE_4.log24__24____6_02_09_20_05_00_PREMIERE_4.log24__24____7_02_20_20_10_00_PREMIERE_4.log

 

Ich mache noch ein paar Testaufnahmen im TS- und MPG-Format (parallel), mal sehen ob man den Fehler weiterhin auf Premiere 4 reproduzieren kann.

Link to comment

..möglicherweise ist das durcheinander bei den audiospuren die ursache. Es gibt anscheinend nicht nur einen wechsel im ac3-format sondern auch einen zusätzlichen audiostream (PID 769) ab der fehlerstelle. Genaues liesse sich nur mit einer TS-analyse sagen, aber der DVBViewer merkt versionswechsel in den PSI-tabellen während der aufnahme anscheinend nicht. Interessant wäre eine ts-aufnahme, die den fehler mittendrin hat.

Link to comment
Es gibt anscheinend nicht nur einen wechsel im ac3-format sondern auch einen zusätzlichen audiostream (PID 769) ab der fehlerstelle.

Nicht ab der Stelle, sondern laut Logs immer mehrere Sekunden vor der Stelle mit den Diskontinuitäten.

 

Trotzdem ist das als Ursache in Betracht zu ziehen. Wenn der zusätzliche Audio-Stream erst bei 300 MB einsetzt, hat ihn der TSPlayer garantiert nicht gefunden, also auch nicht mit nach MPG konvertiert, und womöglich deshalb ein abspielbares Ergebnis geliefert. Man müsste mal probeweise die Suchtiefe im TSPlayer so drastisch erhöhen (-> Settings-Tab), dass er den Stream findet.

 

Was sagt eigentlich ProjectX zu der fehlerhaften Stelle in TS-Aufnahmen? Das wäre mal interessant. Es wäre auch gut, wenn ich ein TS-Sample hätte, das eine solche Stelle enthält. Es würde mir ermöglichen, die Abläufe bei der Konvertierung nach MPG im Debugger zu verfolgen.

Link to comment

..naja, das hängt wohl alles zusammen. Disconties gibt es i.d.r. bei formatwechseln (ac3). Die sind zu verschmerzen bzw. sogar nützlich zum finden von schnittpunkten. Den ablauf bei P4 kenne ich nicht, aber es scheint hier -> alter film -> trailer -> neuer film zu sein. Durch den timervorlauf kommt das alles in die aufnahme. bei TS gibt es auch fälle, bei denen sowas zu fehlern führen kann (änderung in der PAT und den SIDs), wenn der DVBViewer pat/pmt anpasst.

Link to comment

Ich werde mal auf Error-Einträge in den Info-Dateien achten und die betroffenen Aufnahmen testweise mit TSPlayer nach MPG konvertieren.

 

Ab dass dieser Fehler auch mit dem TSPlayer auftritt, ist ja auch erstmal nur eine Vermutung. Ich überlege, ob ich wirklich mit zwei Instanzen des DVBViewer parallel im TS und MPG-Format aufnehme.

 

Das müsste doch eine zuverlässige Methode sein, eine Original TS-Datei zu einer dehlerhaften MPG-Datei zu erhalten.

Link to comment
..möglicherweise ist das durcheinander bei den audiospuren die ursache. Es gibt anscheinend nicht nur einen wechsel im ac3-format sondern auch einen zusätzlichen audiostream (PID 769) ab der fehlerstelle.

 

Ich ich bin mir einigemaßen sicher, dass der Fehler hier auch einige Male mitten in einem Film auf einem öffentlichrechtlichen Sender aufgetreten ist. Also gab es da höchstwahrscheinlich weder einen Formatwechsel noch einen zusätzlichen Audiostream. Lediglich irgendeinen kurzen Fehler und anschließend war die MPG-Datei ab dieser Stelle nicht mehr verwendbar.

 

Ich habe es hier gerade so eingerichtet, dass auf einem zweiten Rechner per Streaming alle Aufnahmen zusätzlich parallel im MPG-Format aufgezeichnet werden.

Damit müsste ich in einige Tagen eine Fehlerhafte MPG-Aufnahme mit zugehöriger TS-Datei haben. Hoffen wir, dass der Fehler bald auftritt. ;-)

Link to comment
Ich ich bin mir einigemaßen sicher, dass der Fehler hier auch einige Male mitten in einem Film auf einem öffentlichrechtlichen Sender aufgetreten ist. Also gab es da höchstwahrscheinlich weder einen Formatwechsel noch einen zusätzlichen Audiostream. Lediglich irgendeinen kurzen Fehler und anschließend war die MPG-Datei ab dieser Stelle nicht mehr verwendbar.

 

..da wirst du recht haben. meine analyse bezog sich auf den Premiere4_fall. Dass mehrere, verschiedene dinge in so einem thread durcheinander gehen, scheint unvermeidlich o:)

 

Deine datei (winterschlaefer) ist ganz einfach kaputt. K.a. wie das passiert ist, aber die falschen PTS sind noch das kleinste übel. Es sind wahrscheinlich PES_packets irgendwie verhackstückt worden. In den GOPs (gop 21-28) sind fehler und auch die audio frames haben teilweise eine falsche länge (zu lang). Ohne einen synchronen TS lässt sich über die ursache nur spekulieren..

Link to comment

In einem Gedankenexperiment (mit Papier & Bleistift) konnte ich jetzt einen Fall konstruieren, in dem die automatische Korrektur der Zeitstempel bei MPG-Aufnahmen in die Hose geht.

 

Es passiert, wenn in der Aufnahme z.B die PTS des Videostreams plötzlich 10 Sekunden springt (Zeitstempel-Diskomtinuität), aber die nachfolgende (!) PTS des Audiostreams diesen Sprung (noch) nicht ausführt, sondern vielleicht erst in der übernächsten PTS. Anschließend registriert der Algorithmus nur noch Zeitstempel-Diskontinuitäten, und die "korrigierten" Zeitstempel werden zu endlosen Wiederholungen des letzten vor der Störung empfangenen PTS. Die MPG-Aufnahme ist damit unbrauchbar.

 

Der Algorithmus geht davon aus, dass bei einem plötzlichen Sprung der PTS eines Streams alle nachfolgenden PTS anderer Streams der Aufnahme in ähnlichem Ausmaß springen. Die Annahme war vielleicht etwas zu optimistisch o:) Ob das die Ursache der hier geschilderten Effekte ist, kann ich mangels Material nicht beurteilen... das Experiment zeigt jedoch, dass die angewandte Methode nicht wasserdicht ist. Notfalls muss die Auto-Korrektur wieder raus, obwohl sie sich bei diversen Tests bewährt hat. Allerdings ändere ich nur ungern etwas ohne schlüssigen Beweis, dass es schädliche Auswirkungen hat.

Link to comment
Notfalls muss die Auto-Korrektur wieder raus, obwohl sie sich bei diversen Tests bewährt hat. Allerdings ändere ich nur ungern etwas ohne schlüssigen Beweis, dass es schädliche Auswirkungen hat.

 

Solange das Problem nicht häufiger Auftritt, besteht, wie du selber gesagt hast, noch kein akuter Handlungsbedarf. Warten wir einfach ein paar Tage, ob ich mit meiner Testumgebung hier eine defekte MPG-Datei mit zugehöriger TS-Datei produzieren kann.

Link to comment

GOTCHA!!! :)

 

Es ging dann doch ziemlich schnell. Heute Nacht ist der Fehler im Nachlauf eines Spielfilms auf ARD wieder aufgetreten. Der Film war bereits zu Ende und es lief berits eine Zugfahrt durch Australien. Der Fehler trat wieder mitten in der Sendung auf. Also kein Formatwechsel etc. sondern eine "ganz normale" Diskontinuität. In der TS-Aufnahme ist ein deutlicher Aussetzer zu sehen. Der Fehler ist auch in der LOG-Datei verzeichnet. Der Rest ist dann wieder in Ordnung.

Bei der MPG-Aufnahme sieht man ebenfalls den Aussetzer, aber die MPG-Datei ist danach bis zum Ende der Aufnahme defekt.

 

Ich habe mit einem Filesplitter jeweils einen 20MB-Schnippsel um den Fehler herum herausgeschnitten.

 

Hier die beiden Files:

 

03-28_02-55-00_ARD_Heimlicher Pakt-055-002ts.zip

 

03-28_02-55-00_ARD_Heimlicher Pakt-054-001mpg.zip

 

Ich habe natürlich auch gleich die TS-Aufnahme durch den TS-Player gejagt, aber leider ist das Problem mit dem TS-Player nicht nachvollziehbar. TS-Player meldet zwar 3 Diskontinuitäten, aber die erzeugte MPG-Datei ist in Ordnung (bis auf den Aussetzer). Ich hoffe, die beiden Files helfen trotzdem bei der Analyse des Problems.

 

EDIT: Nochmal zur Testumgebung: Die TS-Aufnahme wurde mit DVBViewer auf dem Server direkt vom Empfangsdevice aufgenommen. Parallel zum DVBViewer läuft auf dem Server der DVBServer. Die MPG-Datei wurde über Netzwerk auf einem zweiten Rechner aufgezeichnet. Ich hoffe mal, dass DVBViewer und DVBServer dabei automatisch das gleiche Device und den gleichen Stream verwendet haben.

Edited by dgdg
Link to comment

..du schneidest wohl mit nem hexeditor ohne rücksicht auf paketgrenzen. Das ist aber nicht weiter schlimm. :)

 

Hier ist die mpegaufnahme deutlich vermuxt. Selbst pj.x kriegt wegen der pts-inkonsistenzen nur einen bruchteil demuxt. Dabei ist im videostream genauso wie im TS nur GOP8 kaputt. Da hat deine empfangsstörung (disconties) anscheinend reingehauen.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...