Jump to content
Sign in to follow this  
dgdg

Seit einigen Wochen defekte Aufnahmen

Recommended Posts

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

 

Ja klar. Ich möchte ja nicht, dass irgendeine Schnittsoftware unkontrolliert den Inhalt verändert.

 

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.

 

Genau. Eine Störung und der ganze Rest der Aufnahme ist hinüber. Das hat mich seit Dezember mindestens 10 Aufnahmen gekostet (die ich wegschmeissen konnte). Seit ich auf TS-Format umgestellt habe, ist das Problem weg.

 

Aber MPG wäre mir viel lieber, weil ich ganz gerne mit VLC in laufenden Aufnahmen reinschaue. Der TS-Player ist mir mit seinen 2 Fenstern dafür zu unhandlich.

Edited by dgdg

Share this post


Link to post
Griga

Schon der TS ist an der Stelle derbe kaputt. ProjectX:

 

!> PID 0x65 -> packet 31768 @ pos. 5972200 out of sequence (4/14) (shifting..) (~00:00:05.680)

!> PID 0x65 -> packet 31771 @ pos. 5972764 out of sequence (9/7) (shifting..) (~00:00:05.680)

!> PID 0x66 -> packet 31796 @ pos. 5977464 out of sequence (10/1) (shifting..) (~00:00:05.680)

!> packet writing: length index out of bounds, shortened.. (66 / c0 / c0 / 33 -- 5336 / 16 / 6144) @ PTS 04:49:51.631

!> ID 0xC0 (sub 0x0) packet# 34, big PTS difference: this 1565713396, prev. 1565246836

!> dropping GOP# 13 @ orig.PTS 04:49:51.995 (1565279605), errorcode: 24

!> Pics exp/cnt 12/9, inGOP PTS diff. 4800ms, new Timecode 00:00:06.160

!> PTS difference of 475200 (00:00:05.280) to last exported GOP detected

 

In dem TS fehlen etwa 5 Sekunden (!), ähnlich wie in dem letzten Sample. Das ist zufällig der Schwellwert, ab dem die Zeitstempel-Korrektur einsetzt, sowohl im DVBSource als auch bei der MPG-Konvertierung.

 

Zuerst tritt die Diskontinuität der Audio-PTS auf. Diese liegt knapp oberhalb des Schwellwertes. Sie wird deshalb erfasst und korrigiert. Die nachfolgende Diskontinuität der Video-PTS liegt knapp drunter. Abspielbar wird es allein dadurch, dass die Korrektur der Streams im DVBSource miteinander gekoppelt ist. Wenn ich die Korrektur für jeden Stream separat stattfinden lasse, muss ich die Schwelle auf 4 Sekunden senken, damit die Wiedergabe nicht hängenbleibt. DirectShow mag solche Diskontinuitäten überhaupt nicht :)

 

Im TSPlayer sind die Ergebnisse bei der MPG-Konvertierung entsprechend. Damit bleibt weiterhin rätselhaft, warum die MPG-Aufnahme mit dem DVBViewer das Chaos noch vergrößert hat. Vielleicht komme ich ja noch drauf...

 

@dgdg: IMO sind die drastischen Lücken das eigentliche Problem, und die kaputten MPG-Aufnahmen Folgeerscheinungen. Beim Umpacken nach MPG kann man in solchen Fällen machen, was man will: Je nach dem, wie die Würfel fallen, kann es dadurch besser oder schlimmer werden.

 

Nichtsdestotrotz sind solche Samples lehrreich, weil sie zeigen, was alles passieren kann. Eventuell wird es helfen, den Code etwas robuster zu gestalten.

Share this post


Link to post
dgdg
In dem TS fehlen etwa 5 Sekunden (!), ähnlich wie in dem letzten Sample.

 

Das ist natürlich heftig. Ich sollte mich also auf die Suche machen, ob ich hier doch ein -Hardware oder Software-Problem habe. Wenn der Server blockiert ist, dann stockt ja auch die Übertragung zum Client.

 

Ist es denkbar, dass irgendein Task mit hoher Prio im Hintergrung irgendeine Aktion startet und dabei den DVBViewer für 5 Sekunden blockiert?

 

Das würde auch erklären, warum das Problem seit Dezember auftritt. Vielleicht habe ich da irgendeine Software aufgespielt oder aktualisiert.

Share this post


Link to post
Griga

In der MPG-Aufnahme bleiben die PTS ab der fehlerhaften Stelle konstant, d.h. die letzte vor der Stelle wird ständig wiederholt. Dieses Verhalten hatte ich hier anhand theoretischer Überlegungungen prognostiziert, wenn die Korrektur schiefläuft, und zwar deshalb, weil sie für verschiedene Streams gekoppelt ist (es gibt nur einen Korrekturoffset, der für alle Streams gültig ist). Trotzdem kann ich anhand der TS-Aufnahme nicht rekonstruieren, wie das in der Pro passiert ist.

 

Wie auch immer: In der aktuellen Pro Beta wurde die Kopplung der Streams bei der Zeitstempel-Korrektur rausgenommen. D.h. sie findet immer noch statt, aber für alle Streams unabhängig voneinander. Damit sollte die theoretische Ursache vom Tisch sein. Trotzdem bleiben Lücken in Aufnahmen eine kritische Angelegenheit. Es kann nicht garantiert werden, dass MPG-Aufnahmen unter solchen Bedingungen brauchbar sind.

Share this post


Link to post
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

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

Guest
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.

Sign in to follow this  

×
×
  • Create New...