-h264 hevc oder besser -h264HD hevc in /etc/vdr-transcode.conf
ich fürchte, die GT 520 ist zu alt, das schneller zu erledigen.
vdr-transcode - swiss knife for transcoding
-
Danke für die schnelle Antwort!
Ich habe in der conf-Datei die Zeile mit "-h264_HD hevc" einkommentiert.
War "-h264HD hevc" bei dir ein Vertipper oder wäre das wieder ein anderes "Profil"?
Damit wird mir jetzt nämlich eine time von > 2,5h angezeigt.
Kann das Skript (oder ein anderes) die optimalen Settings für meine CPU/GPU Hardware irgendwie selbst ermitteln?
Oder muss ich rumprobieren?Oder ist da einfach insgesamt nicht mehr rauszuholen (bei "erhaltender" Qualität)?
Mir würde eine Einsparung von durchschnittlich 30% Plattenplatz schon ausreichen, wenns schnell(er) rekodiert.
Update: 3:53h und steigend, 4:02h ... ich habs jetzt mit Strg+C abgebrochen. -
Das ist nur der schwache "Celeron" Intel G530 aus der Signatur.
Ich habe leider das ganze Verzeichnis mitsamt dem Log auch gelöscht.
Soll ich nochmal mit hevc anstarten und dir das Log zukommen lassen?
Parallel habe ich gerade wie vorgeschlagen gestartet und da war die "time" zu Anfangs auf 2-3 Minuten und ist jetzt schon bei > 1h und wächst kontinuierlich an.
Ich breche bei ~ 01:40h ab und hänge hier das Log rein.Code: cat logfile
Display MoreStart 2025-11-02 20:05:03 vdr-transcode ffmpeg Version 4.2.7-0ubuntu0.1 script date 2025-11-02 17:14:01 myvdr root x86_64 01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 520] (rev a1) [ 16.331] (II) NVIDIA(0): NVIDIA GPU GeForce GT 520 (GF119) at PCI:1:0:0 (GPU-0) [ 15.700] (II) NVIDIA GLX Module 340.108 Wed Dec 11 14:26:50 PST 2019 ==================================== /etc/vdr-transcode.conf -h264_HD hevc # HD only ==================================== Parameter: -h264 h264 PWD: /srv/vdr/video.00/The_Revenant_-_Der_Rückkehrer/2018-03-04.20.13.1-0.rec insgesamt 10284128 -rw-r--r-- 1 vdr vdr 2097351124 2018-03-04 20:41 00001.ts -rw-r--r-- 1 vdr vdr 2097324992 2018-03-04 21:10 00002.ts -rw-r--r-- 1 vdr vdr 2097516564 2018-03-04 21:39 00003.ts -rw-r--r-- 1 vdr vdr 2097500960 2018-03-04 22:10 00004.ts -rw-r--r-- 1 vdr vdr 2097481972 2018-03-04 22:42 00005.ts -rw-r--r-- 1 vdr vdr 40106040 2018-03-04 22:43 00006.ts -rw-r--r-- 1 vdr vdr 8170 2018-03-04 20:13 3423415_0.jpg -rw-r--r-- 1 root root 79 2025-11-02 18:47 dest -rw-r--r-- 1 vdr vdr 3599464 2018-03-04 22:43 index -rw-r--r-- 1 vdr vdr 2097 2018-03-04 20:13 info -rw-r--r-- 1 vdr vdr 1642 2018-03-04 20:15 info.epg2vdr -rw-r--r-- 1 vdr vdr 1770 2018-03-04 22:46 markad.log -rw-r--r-- 1 vdr vdr 73 2018-03-04 22:46 marks oldsize=10284132 Analyze: Check scantype with ffmpeg scantype=Progressive deinterlace= Stream #0:1[0x781](deu): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 448 kb/s Stream #0:2[0x782](mis): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 448 kb/s ffmpeg -hide_banner -f mpegts -i concat:00001.ts|00002.ts|00003.ts|00004.ts|00005.ts|00006.ts -map 0:v:0 -map 0:1 -map 0:2 -c:v:0 libx264 -preset fast -tune film -profile:v:0 high -crf 27 -g 50 -c:1 copy -c:2 copy -mpegts_flags system_b -map_chapters -1 -mpegts_start_pid 1920 -metadata service_name=vdr-transcode_libx264 ../2018-03-04.20.13.1-1.rec/00001.ts [mpegts @ 0x55f4a712bf40] PES packet size mismatch Last message repeated 1 times Input #0, mpegts, from 'concat:00001.ts|00002.ts|00003.ts|00004.ts|00005.ts|00006.ts': Duration: 02:29:59.92, start: 34280.340244, bitrate: 9357 kb/s Program 132 Stream #0:0[0x780]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc Stream #0:1[0x781](deu): Audio: ac3 ([6][0][0][0] / 0x0006), 48000 Hz, 5.1(side), fltp, 448 kb/s Stream #0:2[0x782](mis): Audio: ac3 ([6][0][0][0] / 0x0006), 48000 Hz, 5.1(side), fltp, 448 kb/s Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) Stream #0:1 -> #0:1 (copy) Stream #0:2 -> #0:2 (copy) Press [q] to stop, [?] for help [libx264 @ 0x55f4a71ad740] using SAR=1/1 [libx264 @ 0x55f4a71ad740] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 [libx264 @ 0x55f4a71ad740] profile High, level 3.2 Output #0, mpegts, to '../2018-03-04.20.13.1-1.rec/00001.ts': Metadata: service_name : vdr-transcode_libx264 encoder : Lavf58.29.100 Stream #0:0: Video: h264 (libx264), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=-1--1, 50 fps, 90k tbn, 50 tbc Metadata: encoder : Lavc58.54.100 libx264 Side data: cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1 Stream #0:1(deu): Audio: ac3 ([6][0][0][0] / 0x0006), 48000 Hz, 5.1(side), fltp, 448 kb/s Stream #0:2(mis): Audio: ac3 ([6][0][0][0] / 0x0006), 48000 Hz, 5.1(side), fltp, 448 kb/s =========================================================== bitrate=2363.7kbits/s speed=0.611x Packet corrupt 0 timestamp discontinuity 0 Missing reference picture 0 Input #0, mpegts, from '../2018-03-04.20.13.1-1.rec/00001.ts': Duration: 00:01:43.92, start: 1.400000, bitrate: 2383 kb/s Program 1 Metadata: service_name : vdr-transcode_libx264 service_provider: FFmpeg Stream #0:0[0x780]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc Stream #0:1[0x781](deu): Audio: ac3 ([6][0][0][0] / 0x0006), 48000 Hz, 5.1(side), fltp, 448 kb/s Stream #0:2[0x782](mis): Audio: ac3 ([6][0][0][0] / 0x0006), 48000 Hz, 5.1(side), fltp, 448 kb/s ======== marks ======== 0:02:35.38 detected logo start (7787)* 2:22:45.11 assuming stop (428260) ======== marks ======== =========================================================== index=3599464 02:29:58.66 index=41048 00:01:42.62 =========================================================== Video: kb/s Audio: 448kb/s Stream #0:0[0x780]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc Stream #0:0: Video: h264 (libx264), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=-1--1, 50 fps, 90k tbn, 50 tbc Stream #0:0[0x780]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc Duration: 02:29:59.92, start: 34280.340244, bitrate: 9357 kb/s Duration: 00:01:43.92, start: 1.400000, bitrate: 2383 kb/s Diff: -889600cs Old 10284132 9,9G New 30340 29,7M 0% Save 10253792 9,8G Duration 00:02:52 End 2025-11-02 20:07:55 -
Hab ich schon befürchtet und es wäre eigentlich eh längst Zeit für was Kleineres (volumens-, nicht leistungstechnisch).
Wie schlagen sich denn solche "kleinen Schachteln" (Arm- & Co) bei derartigen Konvertierungen?
Sind das Meilensprünge ggü. meiner betagten Hardware oder nur ein paar Prozentpunkte?
Nur falls du das zufällig (von deinem Skript her) weißt, sonst ist das arg offtopic. -
Naja, die Aufnahme war schon "HD" und in h264 komprimiert, da hätte nur Konvertierung zu h265/hevc was gebracht. Die wird aber nur nach Konfiguration durchgeführt.
-
Ich bin ein Fan von Geräten mit Arm-Prozessor, mir ist aber keines bekannt, dass von ffmpeg gut unterstützt wird, leider.
Aus genau dem Grund bin ich eigentlich kein großer Fan von den Geräten.
Der ARM-Prozessor ist zwar gut unterstützt, bei der Peripherie hakt es aber oft.Transcoding geht am Besten mit Nvidia oder Intel.
Die Intel-ARC Karten scheinen momentan die schnellsten Video-Transcoder zu haben.
Dabei ist es wohl auch ziemlich unabhängig, welche Karte, da die Encoder extra Einheiten sind.
Es ist inzwischen wohl recht beliebt ein NAS mit so einer Karte nachzurüsten um das Video-Transcoding zu beschleunigen. Ohne Monitor brauchen die Karten idle praktisch keinen Strom (< 1W).
Auch die internen Grafikeinheiten der Prozessoren (zumindest einiger) scheinen mit Quicksync recht respektable Geschwindigkeiten zu erreichen. Da habe ich aber keine Übersicht finden können.Ich hatte mich da letztens etwas eingelesen: Erfahrungen mit Intel ARC Grafikarten? > Linux, Video, VDR
Das Ganze liegt derzeit aber auf Eis. Ich hoffe, dass ich nach Weihnachten etwas Zeit dafür finde...Naja, die Aufnahme war schon "HD" und in h264 komprimiert, da hätte nur Konvertierung zu h265/hevc was gebracht
Bei den vielen Fülldaten bringt ein recodieren in h.264 oft erstaunlich viel.
-
Bei den vielen Fülldaten bringt ein recodieren in h.264 oft erstaunlich viel.
Nun, dafür sollte auch naludump reichen, das benötigt weniger Ressourcen und sollte auch auf ARMs gut laufen.
-
Ich habe gestern VT das erste mal benutzt und war überrascht, wie gut es mit einer 3400ge CPU mit vaapi bei HEVC arbeitete. Es kam auf mindestens 2,8x, Spitzenwerte waren dann 4,5x. Die beste Qualität / Komprimierung habe ich mit -cq24 erzielt. Rund 7,5GB wurden auf ca. 2GB eingestampft. Wichtig, ich habe hier ein Problem beim Streaming im Lan. Der Client benutzt Kodi oder vdr-sxfe, stockt bei den öffentlich rechtlichen und lädt immer den Buffer nach - nicht nutzbar und ein anderes Thema.
Sehr schön, mit der Recodierung auf HEVC mit -cq 24 gab es keine Probleme mehr, ab -cq 20 traten die wieder auf, nur beim Scrollen.
Meine Überlegung, vt nun mit x265 in remux.sh einzubauen. Es schafft hier ja in Echtzeit die Recodierung. Da ich hier frisch angefangen habe, bin ich quasi ein DAU, hat jemand einen Vorschlag für den Parameter Aufruf? Würde mir einiges an Zeit ersparen und die Qualität bei den öffentlich rechtlichen Programmen auf dem Smartphone im Urlaub sehr erhöhen.
-
Falls Du mich gefragt hast, ja, ich habe vaapi verwendet. Sonst hätte es deutlich länger gedauert.
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!