Abspielen der letzten 25 Sekunden der Aufnahme: VDR reagiert nicht auf Eingaben, Bild verlangsamt

  • zillerbaer: Seit 2009 ist das Aufnahmeformat "Transport Stream" (TS). Die Umwandlung in PES-Pakete macht VDR lediglich für Devices, die nicht direkt TS selber verarbeiten können oder wollen. Die PES-Pakete sind dabei genau so lang, wie sie vom Sender kommen, und beinhalten nicht unbedingt komplette Frames oder PTS-Daten. Das Zusammenbauen der PES-Pakete zu Frames muss das Ausgabedevice schon selber machen.

  • Das Zusammenbauen der PES-Pakete zu Frames muss das Ausgabedevice schon selber machen.

    Die empfangenen Daten sollte vdr zentral für die Ausgabedevices aufbereiten. Jedes Ausgabeplugin fängt an das Rad neu zu erfinden. Die Ausgabeplugins sollten sich um die Ausgabe auf den unterschiedlichen Hardware Plattformen kümmern und nicht im Bitstream rumkriechen. Kodi ist da ein Vorbild wie die Aufgaben verteilt werden sollten.


    Stimmt meine Aussage das die TS Packete lediglich einen TS-Header vor den PES-Header haben, ansonsten aber die selben Daten beinhalten?

  • VDR schaut sich die Daten nur so weit an, wie es nötig ist, um die Framegrenzen zu ermitteln. Ansonsten schaufelt er nur TS-Paket hin und her.

    Stimmt meine Aussage das die TS Packete lediglich einen TS-Header vor den PES-Header haben, ansonsten aber die selben Daten beinhalten?

    Beim Sender entstehen zunächst PES-Pakete (variabler Größe, gerne auch mal >64KB) , die dann für die Übertragung in TS-Pakete (der konstanten Größe 188 Byte) aufgeteilt werden. Wenn man die TS-Pakete "auspackt" und die Daten aneinanderreiht, erhält man wieder die PES-Pakete.

  • Mit easyVDR 3.5.02-stable/Kernel 4.4.0-96-generic/VDR 2.2.0/softhddevice 0.6.1rc1/Nvidia GT/NVIDIA-Treiber 340.107 existiert das Problem auch (schon). Eingrenzen konnte ich das Problem überhaupt noch nicht. Ich bin mir auch nicht sicher, ob das auf diesem System von Anfang an so war oder ob das Problem evtl. erst durch eine Änderung auf Austrahlungsseite existiert. Allerdings wenn man quasi im Dauerfeuer Stop oder Zurück drückt dauert es auch nicht sooo lange bis VDR aus der Wiedergabe springt.

    MLD 5.5 mit VDR 2.6.4 & Kodi 19.4 - Gigabyte GA-F2A88XM-HD3 - AMD A8-7600 - 4 Gb RAM - Ausgabe via MSI N220GT-MD1GZ mit softhddevice & vdpau - 19.2E & 28.2E Empfang via Linux4Media L4M-Twin S2 ver 6.5 - Terratec Aureon 5.1 Fun TTP8 - Crucial m4 CT064M4SSD2 - Seagate Exos 7E8 in Scythe Quiet Drive SQD-1000 - Medion X10 RF Remote Control 20016398

  • I did a little analysis. The problem does not depend on the output plugin, apparently it is in the vdr. Checked for softhddevice, softhdcuvid and xineliboutput.

    How does the problem reproduce for me.

    Make a recording, a minute or two. When playing this recording, 10-20 seconds before the end, the picture freezes and looks like frame-by-frame playback. If you press stop, the playback ends normally, but if you press rewind, the vdr freezes. If nothing is done to the recording, then the next day it plays perfectly until the end, and this applies to all the recordings that I made and that were sent to me. But if you delete the index and resume files, vdr will create new ones and the problem will repeat. The next day everything will play normally again.

    I didn’t measure what exact period should pass, I just checked the next day.

    Maybe this will help kls find the problem.

  • @lnj: I think you're on to something here.

    As a quick test, please apply this:

    This will prevent VDR from waiting for more index data in case a recording is still active.

    If this solves the problem, I'll see how I can use the ".timer" file for this, which tells exactly whether or not a recording is still active.

  • Die Änderung hilft für das Problem, aber bei einer laufenden Aufzeichnung wird die Länge nicht mehr geändert, damit ist zeitversetztes Sehen nicht, oder nur schwer möglich.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Deswegen darf ich aber doch den Hinweis geben, wie sich das auswirkt ;)8)


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Mit dem Patch "vdr-2.6.1-fix-check-still-recording.diff" funktioniert zwar das Aktualisieren der Aufnahmelänge während einer Aufzeichnung wieder, aber die Aktualisierung bei einem Schnitt (zwischendurch und am Ende) geht damit nicht mehr.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich habe den Patch auf meinem Testsystem und konnte die Beobachtung von kamel5 bestätigen. kls Tut sich da noch was?


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Sieht bislang recht gut aus :tup


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Auch nach intensiverem Test keine Probleme, ich denke, das kann so übernommen werden.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Moin,

    leider hat der Patch einen Nebeneffekt. Fehlt der Aufnahme die Index-Datei (zum Anschauen alter Aufnahmen erzeuge ich ein Verzeichnis und kopiere nur die Ts- und die Info-Datei hinein), wird die Index-Datei beim ersten Abspielen automatisch generiert.


    Mit Patch ist nach der automatischen Index-Datei-Generierung die Aufnahme scheinbar nur 1 bis 2 Minuten lang und die Wiedergabe stoppt nach 1 bis 2 Minuten. Wird die Aufnahme erneut gestartet, stimmt die Länge und alles ist ok (und wird abgespielt).


    So ganz Durchdrungen habe ich die Codeänderung nicht. Zum Nachstellen einfach bei einer Aufnahme die Index-Datei im entsprechenden Videoverzeichnis löschen.


    Vielen Dank für das Angehen dieses Problems. Da es bei uns immer nur sporadisch auftrat, kann ich noch nicht sagen, ob der Patch wirkt. Ich bleibe dran!


    mfg, Michael

    VDR 2.6.6 (oben): Asus M4N68T-M-LE-V2, 2GB RAM, 120GB SSD, 1TB HD, AMD Athlon(tm) II X4 640 @ 3GHz, NVIDIA GT530 (V390.157), FFMPEG 6.1.1, OpenSuse Leap 15.5 (X-Server) Kernel 5.14.21, 2x Budget + 1x Hauppauge WinTV-DualHD, VDPAU (Softhddev.)

    VDR 2.6.6 (unten): Asus P8H77-V LE, 8GB RAM, 120GB SSD, 2TB HD, Intel(R) Celeron(R) G1620 @ 2.70GHz, NVIDIA GT630 (V470.223.02), FFMPEG 6.1.1, OpenSuse Leap 15.1 (X-Server) Kernel 5.6.8, DD Cine V6.1 Dual + Hauppauge WinTV-quadHD, VDPAU (Softhddev.)


Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!