Transkodieren von über 100 Dateien von H.264 nach H.265

Ich bin dabei, 100+ High Quality Bitrate 720p MKV s mit H.264 (x264) in H.265 (x265 / HEVC) zu transcodieren .

Ich mache das mit der HandBrake -Software unter Linux Debian 9 auf Intel Xeon E3-1225 v3 3,2 GHz 4-Kern .

Es folgen verschiedene Versionen.

Kernel:

4.8.0-1-amd64

Handbremse :

0.10.5 (x86_64)

x265 :

2.1-2
using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

Ich habe diese Einstellungen laut mediainfo angewendet :

Encoding settings: wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=3 / tu-inter-depth=3 / me=3 / subme=4 / merange=57 / rect / amp / max-merge=4 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=240 / min-keyint=24 / scenecut=40 / rc-lookahead=40 / lookahead-slices=0 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=5 / limit-refs=1 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=21.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30

Kurz gesagt, ich habe RF21 mit konstanter Qualität und sehr langsamer Voreinstellung angewendet .

Originale haben alle eine feste Größe von 2 GiB. Die Größen meiner Codierungen sind unterschiedlich (wie lange es gedauert hat, können Sie auch aus der Dateiliste ableiten):

494M Dec  7 07:02 S05E16.mp4
551M Dec  7 00:14 S05E17.mp4
654M Dec  6 16:11 S05E18.mp4
668M Dec  6 08:10 S05E19.mp4

Auf die Originaldateien wurden diese Einstellungen angewendet:

Encoding settings: cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=5670 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

Die Frage ist, ist die CPU-Zeit gut angelegt ? Ich meine, kann ich offensichtliche Optimierungen vornehmen, um die Dinge zu beschleunigen, ohne dass dies zu einer geringeren Qualität und / oder größeren Dateien führt?

EDIT1 :

Zitat aus der offiziellen Quelle :

x265 verfügt über zehn vordefinierte --preset-Optionen, die den Kompromiss zwischen Codierungsgeschwindigkeit (codierte Bilder pro Sekunde) und Komprimierungseffizienz (Qualität pro Bit im Bitstrom) optimieren. Die Standardvoreinstellung ist mittel. Es macht einen ziemlich guten Job, die bestmögliche Qualität zu finden, ohne übermäßige CPU-Zyklen damit zu verbringen, nach dem absolut effizientesten Weg zu suchen, um diese Qualität zu erreichen. Wenn Sie schnellere Voreinstellungen verwenden, nimmt der Encoder Abkürzungen, um die Leistung auf Kosten von Qualität und Komprimierungseffizienz zu verbessern. Wenn Sie langsamere Voreinstellungen verwenden, testet x265 mehr Codierungsoptionen und verwendet mehr Berechnungen, um die beste Qualität bei Ihrer ausgewählten Bitrate zu erzielen (oder im Fall von –crf-Ratensteuerung die niedrigste Bitrate bei der ausgewählten Qualität).

EDIT2 :

Hardwarekonfiguration

Typ: Dedizierter Server von mir. Wird derzeit nur zum Transkodieren von Videos verwendet.

CPU: Intel Xeon E3-1225 v3 3,2 GHz 4-Core

GPU: Keine dedizierte Karte, nur integriert

Arbeitsspeicher: 32 GB ECC 1600 MHz

Festplatten:

  1. SSD; für System verwendet

  2. Festplatten in RAID6; Wird zum Schreiben der Ausgabevideos verwendet

  3. RAMDisk 20 GB; Wird zum Lesen der Quellvideos verwendet

EDIT3 :

In Bezug auf den Kommentar zum Austausch des Speichers habe ich vm.swappiness= 1 gesetzt.

veryslowbraucht viel mehr Zeit für eine geringfügige Verbesserung. Ich würde eine mediumVoreinstellung mit einem niedrigeren CRF vorschlagen.
Denken Sie auch daran, dass die Dateien unabhängig von der Geschwindigkeitseinstellung die gleiche Qualität haben, die Verwendung von veryslow wird nur mehr Zeit damit verbringen, sie (wie Mulvya sagte, geringfügig) kleiner zu machen. Sie können also zwei beliebige priorisieren: Geschwindigkeit, Qualität oder Dateigröße.
Haben Sie versucht, mehr als eine Codierung parallel auszuführen? Bei Multiprozessormaschinen kann dies mitunter zu einer drastischen Verkürzung der Gesamtzeit führen. Nicht sicher, ob Sie mehr als eine Instanz von Handbrake ausführen können, aber mit ffmpeg können Sie es sicherlich. Zwei oder mehr parallele Codierungen bedeuten, dass, während eine die CPU nicht verwendet, z. B. während der Platten-E/A, die andere die freien Zyklen aufsaugt. Solange Sie nicht den gesamten Speicher Ihres Systems verwenden, da es dann mit dem Auslagern auf die Festplatte beginnt und die Dinge viel langsamer werden. Ich würde vorschlagen, die CPU-, Festplatten-E / A- und Speichernutzung während der Codierung zu überwachen, um dies zu sehen.
nein, siehe letzter Satz: (bzw. im Fall von –crf rate control die niedrigste Bitrate bei der gewählten Qualität). IOW Wenn Sie crf verwenden, ist die Qualität konstant, nur die Größe oder Codierungsgeschwindigkeit variiert.
Nun, dann müssen Sie die Größe im Laufe der Zeit priorisieren, da die Qualität konstant ist. Nur BTW, wie lange redest du?
@stib ~ 10 Jahre
Dann solltest du mit h.265 richtig liegen. Wenn Sie über 100 Jahre sprechen, würde ich einen Open-Source-Codec/Container vorschlagen.
Sie können software.intel.com/en-us/intel-media-server-studio/try-buy überprüfen , wenn Sie einen schnelleren Encoder wünschen. Es ist nicht für Endbenutzer wie Handbrake gedacht, wird aber mit Beispielcode geliefert.
Zum OP schneiden Sie die relevante Klausel des von Ihnen fett gedruckten Satzes " um die beste Qualität bei Ihrer ausgewählten Bitrate zu erzielen " aus. Aber da Sie den CRF-Modus verwenden, ist der nächste Teil der eigentlich relevante Teil: " oder im Fall von –crf-Ratensteuerung die niedrigste Bitrate bei der ausgewählten Qualität ". Und bei langsamen Voreinstellungen ist der Unterschied in der Bitrate gering, aber die aufgewendete Zeit ist viel größer.

Antworten (2)

Den ganzen Tag widmete ich mich dem Testen verschiedener Szenarien. Das Folgende gilt für diese spezielle Serie in dieser speziellen Qualität, also sage ich nicht, dass es allgemein gilt . In diesem Fall gilt also:

  • Dateigrößen bei gleichen Einstellungen mit nur mediumund veryslowgeändertem Preset schwanken nur unwesentlich: ~ -10 MiB im Durchschnitt zugunsten von veryslowPreset

  • Die visuelle Qualität ist bei genauem Hinsehen in entweder mediumoder veryslowPreset ziemlich gleich

Eine Sache gelöst. Ich habe die Voreinstellung auf geändert medium.

  • Bei sehr genauer Betrachtung sind die Quellvideos nicht in einer so hohen Qualität, wie ich dachte , das erklärt, warum x265 auf fast 1/4 der Originalgröße komprimiert

Wieder ein Rätsel gelöst.

Vorausgesetzt, ich transkodiere jetzt mit 25 fps, habe ich den RF auf 20 angehoben.

  • RAMDisk bietet in diesem Fall keinen Vorteil, weder für noch mediumvoreingestellt veryslow; Ich landete mit RAID6 als Quelle und SSD als Ausgabelaufwerk

Die Unannehmlichkeit des Verschiebens von Dateien auf RAMDisk wurde behoben.

Um die Frage zu beantworten, wurde die CPU-Zeit überhaupt nicht gut genutzt .

Meiner Erfahrung nach machen die slow-er-Voreinstellungen einen Unterschied, wenn Sie sich bewegende Objekte in der Szene haben. AFAIK, einer der wichtigsten Verbesserungsbereiche in x265 ist die „Vorhersage“ und Wiederverwendung von Informationen über Objekte, die sich in der Szene bewegen.

Je mehr Rechenleistung der Encoder aufwendet, um diese sich bewegenden Objekte zu finden und sie zu codieren, desto bessere Qualität (oder geringere Bitrate) erhalten Sie.

Die Antwort lautet also: Es hängt vom Inhalt Ihrer Clips ab und was Sie mit dem Ergebnis machen wollen. Benötigen Sie eine gute Qualität jedes einzelnen Rahmens? (Überwachungskamera) Dann lohnt es sich mit slowund zu codieren -qb. Ist es nur eine informative Aufnahme? Dann gehen Sie mit mediumund crf 28und -tune film.

Transkodieren von über 100 Dateien von H.264 nach H.265
AntwortenHierDatenschutz-Bestimmungen1y, 0v