[AddVideoFormat.sh] Frameinfos in alte Aufnahmen einfügen

  • Wegen der neuen Funktion von VDR 2.6.5 die Videoinformationen anzuzeigen, habe ich ein Skript gebastelt, dass die Fehlenden Informationen wie Breite, Höhe und Aspect nach trägt.

    Leider kann man mit ffprobe nicht herausfinden, ob interlaced oder progressive vorliegt.


    Im Skript trage ich daher erst mal '-' ein. Gefällt mir aber nicht besonders. Welche Möglichkeiten gäbe es noch?

    Falls jemand mal in das Skript schauen will:

    VDR_config/local/sbin/AddVideoFormat.sh at main · MegaV0lt/VDR_config
    _config. Contribute to MegaV0lt/VDR_config development by creating an account on GitHub.
    github.com


    Es wird ein Backup der info erstellt. Wenn Backup vorhanden, wird die Aufnahme übersprungen

    Die erstellten Backups können wieder hergestellt werden

  • dass die Fehlenden Informationen wie Breite, Höhe und Aspect nach trägt.

    Wo willst du das eintragen ?


    Leider kann man mit ffprobe nicht herausfinden

    ffprobe ist ungefähr so zuverlässig, wie der Wetterbericht: Manchmal stimmt es.


    ob interlaced oder progressive vorliegt.

    Es gibt Sender, die laufend dazwischen wechseln. Was ist das dann ?

  • Wo willst du das eintragen ?

    Eingetragen wird es in die 'info' im Aufnahmeverzeichnis. Siehe oben.

    Code
    F 50 1280 720 - 16:9


    ffprobe ist ungefähr so zuverlässig, wie der Wetterbericht: Manchmal stimmt es.

    Was wäre zuverlässiger als ffprobe?

    Es gibt Sender, die laufend dazwischen wechseln. Was ist das dann ?

    Und wie macht der VDR das?

  • Eingetragen wird es in die 'info' im Aufnahmeverzeichnis.

    In markad gab es sowas auch mal, habe ich aber entfernt. Ich finde, es ist nicht zulässig, Schnittstellen Dateien anderer Programme zu verändern, auch wenn man der Meinung ist, sie sind unvollständig oder falsch.

    Was wäre zuverlässiger als ffprobe?

    Das Problem von ffprobe (und vermutlich aller anderer Tolls dafür auch) ist, dass nur ein (kleiner) Teil des Files, per default meist der Anfang, gelesen wird. Damit kann alles falsch sein, was sich ändert (z.B. audio format, audio channels, aspect ratio, interlaced vs progressive). Frame Rate und Auflösung habe ich bis jetzt noch nicht gesehen, dass sie sich bei einer Aufnahme ändert, müsste somit funktionieren.

    Und wie macht der VDR das?

    interlaced, Beispiel von ProSieben:

    F 25 720 576 i 16:9

    2 Mal editiert, zuletzt von kfb77 ()

  • In markad gab es sowas auch mal, habe ich aber entfernt. Ich finde, es ist nicht zulässig, Schnittstellen Dateien anderer Programme zu verändern, auch wenn man der Meinung ist, sie sind unvollständig oder falsch.

    Da ist was dran. Vielleicht kann man ja im VDR so eine Funktion zum scannen der Videos einbauen?

    So in der Art vdr --add_frame_params

  • mediainfo ist evtl zuverlässiger.


    In meinem vdr-transcode ist beides drin.


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

  • Das Problem von ffprobe (und vermutlich aller anderer Tolls dafür auch) ist, dass nur ein (kleiner) Teil des Files, per default meist der Anfang, gelesen wird.

    Das macht vdr doch auch nicht anders. Am Anfang wird die Stream Auflösung ermittelt, und dann in die info Datei geschrieben. Steht dann auch im Syslog.


    Also, falls jemand einen Sender kennt, der solche Daten regelmäßig ändert: Macht doch mal eine Aufnahme und schaut, was vdr daraus macht

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Hab mein Skript mal auf die 900+ Videos losgelassen. Klappt ganz gut. Im Skin werden nun schön die sd/hd/uhd Logos angezeigt um im Text der Beschreibung passt es auch. das fehlende i/p stört mich nicht weiter

  • Erstmal vielen Dank für das Script.

    Hier https://stackoverflow.com/ques…rlace-detection-in-ffmpeg gibt es Hinweise, wie mit

    Code
    ffmpeg -filter:v idet -frames:v 360 -an -f rawvideo -y /dev/null -i 00001.ts

    interlaced/progressive herausgefunden werden kann.

    Funktioniert bei mir aber nur manchmal korrekt. z.B.:


    BBC HD:

    Zitat

    F 25 1920 1080 i 16:9

    Stream #0:0[0x1388]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc

    [Parsed_idet_0 @ 0x55a3cebf50] Repeated Fields: Neither: 361 Top: 0 Bottom: 0

    [Parsed_idet_0 @ 0x55a3cebf50] Single frame detection: TFF: 352 BFF: 0 Progressive: 9 Undetermined: 0

    [Parsed_idet_0 @ 0x55a3cebf50] Multi frame detection: TFF: 361 BFF: 0 Progressive: 0 Undetermined: 0

    -> korrekt, ist interlaced.



    arte HD

    Code
    F 50 1280 720 p 16:9
    Stream #0:0[0x13f7]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc
    [Parsed_idet_0 @ 0x559857cf30] Repeated Fields: Neither:   360 Top:     0 Bottom:     0
    [Parsed_idet_0 @ 0x559857cf30] Single frame detection: TFF:     0 BFF:     0 Progressive:   253 Undetermined:   107
    [Parsed_idet_0 @ 0x559857cf30] Multi frame detection: TFF:     0 BFF:     0 Progressive:   359 Undetermined:     1

    -> korrekt, ist progressive.



    kabel eins

    Zitat

    F 25 720 576 i 16:9

    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x576 [SAR 64:45 DAR 16:9], q=2-31, 124416 kb/s, 25 fps, 25 tbn, 25 tbc

    [Parsed_idet_0 @ 0x55a0863760] Repeated Fields: Neither: 361 Top: 0 Bottom: 0

    [Parsed_idet_0 @ 0x55a0863760] Single frame detection: TFF: 0 BFF: 0 Progressive: 361 Undetermined: 0

    [Parsed_idet_0 @ 0x55a0863760] Multi frame detection: TFF: 0 BFF: 0 Progressive: 361 Undetermined: 0

    Ist interlaced, ffmpeg hat aber keine interlaced frames gefunden (TFF). Hier habe ich mal testweise ffmpeg mit -frames:v 5000 aufgerufen, und es kommt:

    Zitat

    [Parsed_idet_0 @ 0x5592f81760] Repeated Fields: Neither: 5000 Top: 0 Bottom: 1

    [Parsed_idet_0 @ 0x5592f81760] Single frame detection: TFF: 67 BFF: 3 Progressive: 4478 Undetermined: 453

    [Parsed_idet_0 @ 0x5592f81760] Multi frame detection: TFF: 71 BFF: 0 Progressive: 4930 Undetermined: 0

    Sieht jetzt besser aus, es gibt TFF frames -> interlaced.

    Ist aber eher was für geduldige.



    FireFly , wie macht das denn VDR?


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Hab das Skript erweitert um eine Backup-Funktion. Die info wird nur geändert, wenn es keine info.bak gibt. Mit -f wird die .bak zurück kopiert und neu verarbeitet.


    Das i/p schenke ich mir, da es ja nur im Infotext der Aufnahmen erscheint.


  • FireFly , wie macht das denn VDR?

    Der VDR parsed bei MPEG2 den Sequence Header und die Sequence Extension, bei H.264 und H.265 das Sequence Parameter Set.


    Das i/p schenke ich mir, da es ja nur im Infotext der Aufnahmen erscheint.

    Das habe ich implementiert, muss das Skript aber jetzt an Deine Änderungen anpassen ;) Wobei da noch die Frage ist, wie man mit Fällen wie Kabel eins umgeht - 576p gibts IMHO nicht im Standard

  • muss das Skript aber jetzt an Deine Änderungen anpassen

    Mein Skript trägt für i/p ein '-' ein. In meinem Skin zeige ich das '-' nicht an. Habe gesehen, dass z.B. bei Aspect vom VDR auch ein - eingetragen wird, wenn nichts erkannt wurde.


    Hast Du einen sinnvolleren Vorschlag?

  • Ich glaube die Paramterausgabe hat eine feste Reihenfolge.

    nk=1 hab ich doch drin.

    Die Bildwiederholfrequenz übernehme ich aus der info Datei und wird daher nicht geändert.

  • Ja, ich meinte nk=0

    Die Bildwiederholfrequenz übernehme ich aus der info Datei und wird daher nicht geändert.

    Ah, aber erst in der neuen Version ;)

    Aber die Berechnung von $fps kann man sich doch dann eigentlich sparen, denn wenn es nicht gesetzt ist, wird f_insert_framedata doch nie aufgerufen, oder?

    Wenn ich nachher Zeit habe, mache ich daran weiter

  • Das stimmt. Kommt daher, dass ich das nachher eingebaut habe. Und die fps hat keine Dezimalstelle, weil ich nicht weiß, ob der VDR das verträgt. Kann man raus nehmen. Außerdem hab ich inzwischen auch eine Restore Funktion eingebaut, die die .bak wieder zurück kopiert.

    Bin dann erst mal unterwegs…

  • Hier mal mein erster Wurf:

    Die wichtigsten Änderungen:

    • scanType hinzugefügt (sofern ffprobe den findet, bei 1080p und 2160p bei meinen Testaufnahmen z.B. nicht)
    • kein root nötig, dafür wird geprüft ob Schreibrechte auf die Info-Datei vorhanden sind. Kopien haben den gleichen Owner
    • Startverzeichnis kann als Parameter übergeben werden, default (ohne Parameter) ist weiterhin /video
    • PES-Aufnahmen werden explizit geprüft und übersprungen
    • Einrückungen der Ausgaben zu einer Aufnahme der besseren Übersichtlichkeit wegen

    Das -read_intervalls habe ich übernommen, das stimmt aber nicht mit dem Kommentar darüber überein, oder?

  • Hevc ist immer Progressiv.


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

  • Vielen Dank für die Überarbeitung. Werde das so übernehmen.


    Ja der Kommentar ist nur als Beispiel zu sehen...

  • Habe mal getopts mit eingebaut

    Code
    darkwing@MCP-Notebook ~/Schreibtisch $ sudo bash AddVideoFormat.sh -h
    AddVideoFormat.sh Usage:
        AddVideoFormat.sh -f  Force processing of already processed 'info'. Reuse of original 'info'!
        AddVideoFormat.sh -r  Restore backed up 'info' files
        AddVideoFormat.sh -v VIDEO_DIR  Path to VDR's video directory (default: /video)


Jetzt mitmachen!

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