[markad] überarbeiteter Decoder

    Quote from jsffm

    Du kannst mal mit -hwaccel cuda oder - probieren

    Danke - aber meinst Du in der Befehlszeile von markad oder in der vdr-transcode.conf?

    Meine vdr-transcode-conf sieht so aus:

    Also cuvid steht da drin. Soll ich cuda stattdessen versuchen?

    Was bedeuten die Zeilen

    Code
    [mpegts @ 0x55f93ce62440] Non-monotonic DTS in output stream 0:3; previous: 383640, current: 383040; changing to 383641. This may result in incorrect timestamps in the output file.

    im Logfile und die vielen "drops" danach, im Fehlerfall?

    Eigentlich sagt die Meldung recht klar, dass da was mit den timestamps nicht stimmt, die Anweisung das zu Verbessern hast Du schon drin. drops=2 heisst, das zwei Frames weggeschmissen wurden, das ist vernachlässigbar.


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

    Hmm, reden wir hier nicht über Fehler - die nach dem markad Prozess - in der Weiterverarbeitung passieren? Wenn ja, was hat das mit diesem Thema zu tun?

    Quote from jsffm

    das zwei Frames weggeschmissen wurden, das ist vernachlässigbar.

    Ja, aber immer wieder. Und das Videobild ist eindeutig "zittrig", wie vor- und rückspringend eben. Aber nur bei Bewegungen zu sehen.

    Quote from vdr_rossi

    Hmm, reden wir hier nicht über Fehler - die nach dem markad Prozess - in der Weiterverarbeitung passieren? Wenn ja, was hat das mit diesem Thema zu tun?

    Es wird beim Markad in Verbindung mit "--smartencode" irgendwas am Signal/an den Timestamps? geändert, welches dann beim transcode Fehler verursacht.

    Ohne "--smartencode" passiert das nicht, transcode läuft dann ohne drops und Zitterbild.

    Quote from vdr_rossi

    Hmm, reden wir hier nicht über Fehler - die nach dem markad Prozess - in der Weiterverarbeitung passieren?

    Das ist meiner Meinung noch nicht klar. Oder irgendwo dazwischen ...

    Ich konnte den Fehler auf Basis der Logs von wmautner und meiner NVIDIA Test Grafikkarte reproduzieren. Die Ruckler treten genau ab der Stelle auf, wo --smartencode vom re-encodieren des Anfangsabschnitts zum Kopieren des Hauptabschnitts wechselt. Habe aber noch eine Ahnung, was da FFmpeg so stört, dass es gar nicht mehr was vernünftiges erzeugen kann.


    Quote from wmautner

    Non-monotonic DTS in output stream 0:3

    Das ist auch ein Audio Stream. Sollte keinen Einfluss auf die Video Ausgabe haben. Das kann aber auch vom originalem Input Stream kommen, ich habe die Meldung bei meinem Test Video nicht. Wobei ich allerdings auch die Audio Streams nicht re-encodiere, ich habe die passenden Encoder nicht drauf.

    Wie auch immer, meine HD-Sender sind fast nur ÖR-Sender ohne Werbepausen innerhalb der Sendungen, und ich selbst merke keine Unterschiede zwischen smartencode oder ohne, also lasse ich das mal wieder weg.

    Wäre nur interessant, ob andere VDR-Benutzer, die ebenfalls H264 transkodieren, solche Effekte sehen.


    Danke!


    Walter

    Quote from wmautner

    und ich selbst merke keine Unterschiede zwischen smartencode oder ohne

    Das ist richtig. Beim Start/Ende Schnitt spielt das praktisch keine Rolle. Ist nur interessant für die Werbe Schnitte.

    Apropos: das markad.log hat sich durch das Debug-Statement so ca. ver20facht. So sehr, daß ich es "part" abschneiden mußte, da 80MB auch nach dem Zippen zu groß sind.

    Nützt das etwas?


    Das "immer wieder" ist regelmäßig, ich meine auch "immer wiederkehrend" :)

    Vermutlich korreliert das auch mit dem Bewegungszittern im Bild. Welches bei dem 10s-Schnipsel hier aber noch kaum zu sehen ist, ich könnte ggf. ein anderes Stück der Audnahme schicken oder die doch wo hochladen.

    Edited once, last by wmautner ().

    Quote from kfb77

    Ich interpretiere das als Summe. Für jeweils ist mir das zu regelmäßig.

    Korrekt


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

    Quote from kfb77

    Das ist auch ein Audio Stream. Sollte keinen Einfluss auf die Video Ausgabe haben. Das kann aber auch vom originalem Input Stream kommen, ich habe die Meldung bei meinem Test Video nicht. Wobei ich allerdings auch die Audio Streams nicht re-encodiere, ich habe die passenden Encoder nicht drauf.

    Die Wiedergabeplugins synchronisieren mit den Audiospuren, da könnten Fehler sich auf das Bild auswirken. Möglicherweise müssen die Audiospuren auch angepasst werden.


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

    Quote from jsffm

    Die Wiedergabeplugins synchronisieren mit den Audiospuren

    Das Zitterbild trifft aber nicht nur auf softhd*, sondern auch auf vlc oder mpv zu. Die notfalls auch ohne Audiospur abspielen :)

    Quote from wmautner

    Apropos: das markad.log hat sich durch das Debug-Statement so ca. ver20facht. So sehr, daß ich es "part" abschneiden mußte, da 80MB auch nach dem Zippen zu groß sind.

    Nützt das etwas?

    Ist mir gar nicht aufgefallen, das was ich sehen wollte, war drin. Also gut abgeschnitten.

    Quote from wmautner

    Welches bei dem 10s-Schnipsel hier aber noch kaum zu sehen ist, ich könnte ggf. ein anderes Stück der Audnahme schicken oder die doch wo hochladen.

    Nicht notwendig, ich kann es ja jetzt mit eigenen Aufnahmen reproduzieren.


    Quote from jsffm

    Möglicherweise müssen die Audiospuren auch angepasst werden.

    Wenn Werbung rausgeschnitten wird, werden die Audio PTS/DTS um den gleichen Offset angepasst, wie die Video Pakete.

    Das Problem tritt aber schon am Anfang der Sendung beim weggeschnitten Timer Vorlauf auf. Da gibt es keinen Schnitt Offset, es wird DTS und PTS beibehalten.

    Es gibt aber wohl einen Offset um den Decodieren Teil passend an den kopierten Teil zu bekommen. Meist nur so 1-2 packet duration groß.

    In meinen Log Files sehe ich da auch keinen Fehler.

    Entweder stimmt da doch was nicht, oder FFmpeg verträgt den Wechsel von meinen Encoding Parameter zu denen von originalen Stream nicht.

    Die Parameter sind gleich geblieben aus dem ursprünglichen full re-encode. Und da nutzt ich z.B. closed GOPs (um besser im Player springen zu könne) und nicht open GOP, wie der originale Stream. Aber bei der direkten Wiederhabe des H.264 hat weder VLC noch Kodi ein Problem damit.

    Also so langsam vermute ich einen Bug im hevc_nvenc encoder:

    Mit der FFmpeg Command Line aus dem Transcode Log bekomme ich die Ruckler:

    Code
     ffmpeg -hide_banner -fflags +igndts+genpts -hwaccel cuvid -hwaccel_output_format cuda -c:v:0 h264_cuvid -i ./Test_HD.ts -map 0:v:0 -map 0:1 -map 0:2 -map 0:3 -map 0:4 -c:v:0 hevc_nvenc -preset medium -profile:v:0 main -rc vbr -cq 36 -g 50 -mpegts_flags system_b -map_chapters -1 -metadata service_name=vdr-transcode_hevc_nvenc ffmeg.ts

    Werfe ich da alles raus, was nach Hardware Decoding/Encoding aussieht, geht es ohne Ruckler mit der gleichen Aufnahme:

    Code
     ffmpeg -hide_banner -fflags +igndts+genpts -c:v:0 h264 -i ./Test_HD.ts -map 0:v:0 -map 0:1 -map 0:2 -map 0:3 -map 0:4 -c:v:0 hevc -preset medium -profile:v:0 main -rc vbr -cq 36 -g 50 -mpegts_flags system_b -map_chapters -1 ffmeg.ts

    jsffm : Hast du noch eine Idee ?

    Ausschliessen möchte ich garnichts, aber ich arbeite ständig mit nvenc und habe damit keine Probleme. Es gibt dort sehr viele Parameter, mit denen man spielen kann.


    ffmpeg -hide_banner -h encoder=hevc_nvenc


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

    Thanks 1

    Die Version 4.2.1 von vdr-plugin-markad ist verfügbar.

    Bei Probleme bitte immer die vollständige markad.log posten.

    Code
    2024-09-29: Version 4.2.1
- reformat man page (thx to shofmann@www.vdr-portal.de)
- ignore VPS start event after recording interruption (thx to pmrb@www.vdr-portal.de for reporting)
- special logo treatment for some french channels (thx to pmrb@www.vdr-portal.de for reporting)
- get recording start time from directory name (thx to MarkusE@www.vdr-portal.de for the tip)
- some minor bug fixes and optimizations, see git
    Like 3 Thanks 2

    Das Thema --smartencode Konviertierung nach H.265 wird noch seltsamer: Ich habe mal die Command Line von wmautner nach VAAPI übersetzt. Mit dem Encoder habe ich ja die Schnittfunktion geschrieben, dem traue ich mehr.

    Code
    ffmpeg -hide_banner -fflags +igndts+genpts -hwaccel vaapi -hwaccel_output_format vaapi -c:v:0 h264 -i /media/Video/VDR/Archiv_5/Test_HD/2023-11-01.18.48.1-4.rec/Test_HD.ts -map 0:v:0 -map 0:1 -map 0:2 -map 0:3 -map 0:4 -c:v:0 hevc_vaapi -profile:v:0 main -g 50 -mpegts_flags system_b -map_chapters -1 -metadata service_name=vdr-transcode_hevc_vaapi /media/Video/VDR/Archiv_5/Test_HD/2023-11-01.18.48.1-4.rec/ffmeg.ts

    Diese Commandline funktioniert mit Quelldatein ohne Re-Encode und mit Full Re-Encode. Kein Abbruch, keine Ruckler.

    Mit einem --smartencode Input File bricht FFmpeg ab:

    Code
    Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scale_0'
[vf#0:0 @ 0x556c2acbe540] Error reinitializing filters!
Failed to inject frame into filter network: Function not implemented
Error while filtering: Function not implemented
[out#0/mpegts @ 0x556c2ad20f00] video:38004kB audio:27528kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 6.032340%
frame= 7384 fps=184 q=-0.0 Lsize=   69485kB time=00:02:27.66 bitrate=3854.9kbits/s speed=3.68x
Conversion failed!

    Und der Timestamp ist genau die Stelle, wo der Wechsel zwischen Re-Encode und copy ist und ab da mit nvenc die Ruckler kommen.

    Ideen, was die Fehlermeldung mir sagen will, wären willkommen. Ich bin im Moment ratlos.

    Edit:

    Ach Mist. Ich sehe gerade an den Zeitstempel der Logs, daß die Zeitzone nicht stimmt :( Vielleicht kommt daher das Problem.

    Also.... Das unten kann man dann wieder vergessen.


    ------- nicht mehr wichtig -------

    Ich habe versucht eine frische Aufnahme durch markad laufen zu lassen. Allerdings habe ich relativ schnell abgebrochen, weil die Fehlermeldungen ziemlich seltsam sind:

    Ist das normal, daß der Recording Start und der Timer Start fast 2 Stunden auseinander liegen?


    Code
    markad: Mon Sep 30 19:03:59 [15475] ERROR: recording start 117:05 min after timer start, recording incomplete, marks will be wrong

    Die Aufnahme habe ich gerade gesichtet und die ist vollständig. Nur eben mit Werbung und ohne Markierungen.

    Quote from Zabrimus

    Vielleicht kommt daher das Problem.

    Sicher:

    recording start from directory name: Sun Sep 29 20:12:00 2024 -> VDR setzt die Zeit für das Aufnahmeverzeichnis von der localtime des Rechners

    timer start at Sun Sep 29 18:14:55 2024 -> die Zeit kommt von EPG Event, da ist die Zeitzone des Rechners egal.

    Du kannst tricksen: Ändere den Namen des Aufnahmeverzeichnis auf die richtige Zeit, dann müsste es gehen.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login