vdr-transcode - swiss knife for transcoding

  • Da bin ich auch drauf gestossen, sind die Untertitel wichtig?


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

  • Code
      Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 50 fps, 50 tbr, 90k tbn
      Stream #0:1(deu): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 96 kb/s (default)
      Stream #0:2(mis): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 96 kb/s
      Stream #0:3(qks): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 96 kb/s
      Stream #0:4(deu): Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz, stereo, fltp, 448 kb/s

    Da kann man bei den Audio-Streams noch einiges rausholen, ich empfehle:

    Code
    -ac3_stereo aac
    -sel 4

    448 kb/s für Stereo ist zuviel!


    Du könntest natürlich auch einfach -sel 1 nehmen, ist Geschmacksache.


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

  • Diesen Eintrag habe ich schon vor 3 Jahren vorne in die Todo-Liste eingefügt:


    # dvb_subtitle -canvas_size ?


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

  • Im Git neue Version, -canvas_size bei Export von dvb_subtitle nach mp4. Bei mkv gab es auch ohne keine Probleme.


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

  • Neue Funktion im Git:


    -h264_HD <codec> # HD only


    Wenn ich z.B. -h264_HD hevc in der Konfiguration eintrage, werden im Gegensatz zu -h264 hevc nur HD Filme nach hevc konvertiert, SD-Filme bleiben in h264, hevc macht hier nicht soviel Sinn. SD-Filme in mpeg2 werden nat. weiterhin nach h264 konvertiert.


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

  • Neue Funktion im Git:


    Code
     --confr            # mark recursiv gt min_br
     -confr <min_br>    # mark recursiv gt min_br
     -min_br <min_br>

    Ich hatte diese Funktion bisher in einem externen Script, habe sie jetzt in vdr-transcode übertragen. Ich nutze sie hauptsächlich bei Serien. Es werden nur Aufzeichnungen markiert, die noch nicht mit meinem Script transkodiert wurden. Wie bei --conf werden Parameter, die dahinter angegeben werden, in vt.conf eingetragen.


    z.B. --confr --selb oder --confr --sel 1


    Für min_br verwende ich meist -min_br 7000


    Desweiteren wird ein Problem bei --out_stat beseitigt, beim Abbruch mit Ctrl-c liefen Prozesse im Hintergrund weiter.


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

    Einmal editiert, zuletzt von jsffm ()

  • Hi,,


    ich habe da eine (oder viele) Verständnisfragen. In einem neuen Container habe ich alles mögliche installiert und habe mit dem Script gespielt. Der Ryzen 5600G kann h264/hevc per vaapi konvertieren. Klappt auch ziemlich gut und schnell.


    Bisher bekomme ich immer den Fehler, daß die index-Datei nicht gefunden wird. Ich nehme an, dazu braucht man auch noch den VDR. Muss der immer laufen oder wird der bei Bedarf gestartet?


    Der Parameter -h264_HD ist perfekt, weil bei Bedarf mpeg2 -> h264 und h264 -> hevc gewandelt wird. Super :)

    Aber die anderen neuen Parameter verstehe ich nicht:

    Code
     --confr            # mark recursiv gt min_br 
     -confr <min_br>    # mark recursiv gt min_br 
     -min_br <min_br>

    Es werden nur Aufzeichnungen markiert, die noch nicht mit meinem Script transkodiert wurden.

    Wenn ich das richtig verstehe, dann wird das Videoverzeichnis durchsucht und in allen neuen Aufnahmen die vt.conf angelegt, oder liege ich da komplett falsch?

    Wie hängt das mit den neuen Parametern zusammen? Was ist denn mit br gemeint?

  • Erst mal zum index, es wird nur das Programm gebraucht, steht es nicht zur Verfügung, wird der index bei erster Wiedergabe generiert.


    br steht für Bitrate, ich makiere nur Dateien, deren Bitrate größer ist, -confr ist eine Kombination von --confr und -min_br


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

  • Für h264 unterstütze ich den AMD direkt, hevc kann ich auch einbinden, brauche nur jemanden zum Testen, da meiner nur h264 unterstützt.


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

  • br steht für Bitrate, ich makiere nur Dateien, deren Bitrate größer ist, -confr ist eine Kombination von --confr und -min_br

    Bitrate. Ja, da hätte ich drauf kommen können :wand Danke.

    Also würde es reichen, wenn ich nur -confr verwende, wobei ich erst einmal mal schauen muss, welche br ( ;) ) die Aufnahmen so üblicherweise haben.

  • Es ist nicht so einfach, wenn man voll in der Materie steckt, eine Beschreibung für Alle zu machen. :)


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

  • Mit vt --inf kannst Du Dir die Bitrate anzeigen lassen.


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

  • Für h264 unterstütze ich den AMD direkt, hevc kann ich auch einbinden, brauche nur jemanden zum Testen, da meiner nur h264 unterstützt.

    Wenn ich mir die CPU-Last so anschaue und auch die Geschwindigkeit, dann gehe ich schon davon aus, das beides per GPU encodiert wird.


    Aktuell sieht es so aus:

    mp2 -> h264: 16-facher Speed bei 110% CPU, Aufnahme (151 min) schrumpft von 6,4 GB auf 1,9 GB.

    h264 -> hevc: 8-fach Speed bei 12% CPU, Aufnahme (71 min) schrumpft von 2,8 GB auf 812 MB.


    Der Aufruf sieht in beiden Fällen so aus:

    vt -h264_HD hevc -hwaccel vaapi

    Bei dem Encoding mit libx264 springt zum Vergleich die CPU-Last auf über 800% und der Speed sinkt leicht. Das Software-Encoding für hevc habe ich gar nicht erst probiert.


    Edit:

    Aufruf hinzugefügt

  • Ich habe nicht bezweifelt, dass vaapi von der Gpu bearbeitet wird. Die Parameter gehören in die Konfiguration /etc/vdr-transcode.conf


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

Jetzt mitmachen!

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