HEVC Videokonvertierer gesucht, der auch Metadaten transferiert

[autoshot]

Hallo zusammen!
Um Speicherplatz zu sparen komprimiere ich seit ca. einem Jahr alle Videos, die ich mit meinem iPhone aufnehme, um ca. 75% (HEVC @ ~50000kbps -> HEVC @ 12000kbps). Bisher habe ich hierfür immer Handbrake genutzt und nach der Umwandlung händisch die Metadaten der neuen Videodateien (Aufnahmedatum, -Zeit und -Ort) angeglichen. Da das allerdings eine Heidenarbeit ist bin ich gerade auf der Suche nach einem Videokonverter, der die im Ausgangsmaterial enthaltenen Metadaten beim Encodieren auf die neuen Videos überträgt. Habt ihr da einen (bezahlbaren) Tipp?
lg autoshot

 

[ghecko]

MKVtoolnix. Damit könnte man das neu encodierte Video in die alte Datei reinmuxen und damit den alten Stream ersetzen. So bleiben die Metadaten erhalten. Sind zwar dann 2 Schritte, aber immer noch schneller als alles von Hand neu eintragen.

 

[NameHere]

Das kann man mit ffmpeg auch mit einer Batch machen
Beispiel

for %%a in ("*.*") do ffmpeg -i "%%a" -c:v libx265 -crf 22 -c:a aac -b:a 320k "newfiles\%%~na.mp4"
pause

Bei mir bleiben die Metadaten

Du brauchst dafür nur die ffmpeg.exe (32 od. 64 bit) aus dem Paket

 

[autoshot]

Danke für die Antworten!

@ghecko
Sehe ich das richtig, dass MKVtoolnix nur MKV-Dateien produzieren kann? Das wäre ungünstig, da sich Apple Photos nur mit .MOV, .M4V und .MP4 versteht.

@NameHere
Aus Qualitätsgründen konvertiere ich die Videodateien nicht via RF-Faktor, sondern über Avg Bitrate + 2-Pass Encoding + noch ein paar andere Einstellungen. Sieht dann so aus:

Geht das so auch über die Kommandozeile?

 

[NameHere]

Sollte gehen. Gibt ja tausende Variablen die man in die Batch packen und den eigenen Bedürfnissen anpassen kann
Edit:
Habs irgendwann mal von hier genommen

https://forum.videohelp.com/threads/356314-How-to-batch-convert-multiplex-any-files-with-ffmpeg

Es gibt im Netz bestimmt hilfreiches wie du deine Batch anpassen kannst.

P.S. Und ja, die 64bit Version funktioniert

 

[Yuuri]

Aus Qualitätsgründen konvertiere ich die Videodateien nicht via RF-Faktor, sondern über Avg Bitrate + 2-Pass Encoding + noch ein paar andere Einstellungen.

Aus Qualitätsgründen solltest du gerade deshalb über den CRF gehen. 2-Pass nutzt man, wenn man eine gewisse Zielgröße im Blick hat, ergo nicht über x MB hinaus gehen kann.

 

[NameHere]

Hier noch ein kurzer Guide (auch CRF erklärt)
https://slhck.info/video/2017/02/24/crf-guide.html

Lies dir auch mal die Kommentare durch

 

[autoshot]

@Yuuri
Mein Ziel ist es, die Videos möglichst ohne Qualitätsverlust möglichst stark zu komprimieren. Soweit ich weiß liefert 2-Pass da die besseren Resultate, deswegen mache ich das so oder unterliege ich da einem Irrtum?

@NameHere
Danke für den Link aber puh, die ffmpeg-Befehle sind echt eine Wissenschaft für sich. Da Handbrake ebenfalls ffmpeg nutzt frage ich mich gerade, ob es irgendeine Möglichkeit gibt, die von Handbrake auf Basis meiner Einstellungen generierte Kommandozeileneingabe zu extrahieren, sodass man sie nur noch ein bisschen erweitern muss. Geht das?

 

[NameHere]

War mal so freundlich

https://we.tl/t-fCQphRPlf2 (We Transfer)
Entpacken und probieren. Zieh (Kopiere) einfach deine Datei in den Ordner und starte ein von den beiden .bat Dateien.
Ich ziehe meist mehrere Dateien rein und lass die über Nacht konvertieren

 

[[JiM]]

Ja da unterliegst du einem Irrtum - 2-Pass ist nur dann sinnvoll wenn du eine bestimmte Größe erreichen willst. Also einen fixen Platz maximal ausnutzen willst. Bei CRF gibst du halt eine bestimmte Qualität vor die dann nie unterschritten wird, die Dateigröße variiert dann je nach Quelle aber ist keine Limitierung. Es geht schneller und sieht besser aus.

 

[autoshot]

Vielen Dank für das Skript @NameHere! Habs gerade getestet und es funktioniert auch so weit. Leider kann ich die so konvertierten Videos allerdings nicht in Apple Photos importieren und die Metadaten werden auch nicht übernommen

 

[Yuuri]

Mein Ziel ist es, die Videos möglichst ohne Qualitätsverlust möglichst stark zu komprimieren. Soweit ich weiß liefert 2-Pass da die besseren Resultate, deswegen mache ich das so oder unterliege ich da einem Irrtum?

2-Pass und N-Pass
Sinn und Zweck eines 2-Pass-Encodings ist es, eine vorher festgelegte Dateigröße exakt zu treffen und dabei die subjektiv empfundene Videoqualität im Verlauf des Films möglichst konstant zu halten. 2-Pass war nie und ist nicht die Methode, um das wolkige Ideal von »maximaler Qualität« zu erfüllen.
Dass sich die Legende von der maximalen Qualität durch 2-Pass hartnäckig hält, hat seine Wurzeln in der Anfangszeit des Videoencodings. CDs und später DVDs waren damals das einzige erschwingliche Medium, um eine Filmsammlung zu speichern. Und auch CD-/DVD-Rohlinge waren nicht so billig, dass man sie halb leer lassen wollte. Deswegen war es vollkommen natürlich, einen Film z.B. auf exakt zwei CDs zu strecken; oder exakt drei Filme auf eine DVD zu packen. In so einer Situation ist 2-Pass die einzig vernünftige Encodingmethode.
Heutzutage, wo mehrere hundert HD-Encodings auf die für billiges Geld geschossene 4-TB-Platte passen, ist es dagegen vollkommen egal, wie groß ein einzelner Film ist. Das bringt uns zum 1-Pass-Encoding.

1-Pass, konstante Qualität
Konstante Qualität ist das Gegenstück zur konstanten Dateigröße des 2-Pass-Verfahrens. Heute ist es das Standardverfahren. Wir definieren vor dem Encoding ein Qualitätsniveau, das vom Encoder eingehalten wird, ohne auf die Größe zu achten. Deswegen wissen wir vorher nicht, wie groß der Film werden wird. Mit Qualität ist hier die visuelle Qualität gemeint, die wir beim Anschauen wahrnehmen. Für den Encoder heißt das, dass er je nach Eigenschaften der Szene unterschiedlich stark komprimieren darf.
Nur die neueren Encoder wie x264 oder x265 unterstützen einen echten Qualitätsmodus. Er heißt dort CRF (Constant Rate Factor). Wer noch auf Xvid oder DivX angewiesen ist, muss das Quantizer-Verfahren als Annäherung verwenden.

 

[NameHere]

Bei WIN10 wird auch kein Vorschaubild genneriert. Mich hat es bisher nicht gestört.

Schade

 

[autoshot]

Danke für die Klarstellung @Yuuri!