Ja, aber nicht pauschal.
Unpolemische Frage: Wieso soll man noch so etwas kaufen, wenn es kostenlose Open Source-Lösungen wie Handbrake [mit extrem benutzerfreundlichen Interface] und Shutter Encoder [dem Schweizer Taschenmesser] gibt, die zudem mit x264 und x265 unter der Haube sowie Unterstützung für NVenc/QuickSync & Co. wahlweise die qualitativ besten und die schnellsten h264/h265-Codecs anbieten?Skeptiker hat geschrieben: ↑Mo 13 Nov, 2023 11:59 Je nachdem, wie professionell das Ganze sein soll, könntest Du auch einen der China-Multikonverter ausprobieren, die teils einen "Superspeed"-Modus bieten oder einfach GPU-Support. Nach ProRes & Co willst Du ja nicht wandeln, und H.264 und H.265 können die alle.
Im Prinzip kann XMedia Recode das Gleiche auch kostenlos, während die kommerziellen Converter fürs breite Publikum so um die 50 EUR/USD kosten.
Berechtigte Frage. Ich habe die kostenlosen auch alle installiert (sofern am Mac verfügbar). Wie geschrieben, die kommerziellen bieten teils ein paar nützliche Extras und vielleicht (das wäre einen Test wert) höhere Geschwindigkeit. Bliebe die Frage nach der Encoding-Qualität im Vergleich.
Jott hat geschrieben: ↑Mo 13 Nov, 2023 14:41 Verstehe die Diskussion nicht. Wenn das interessiert, dann nimmt man sich einen 1-Minuten-Schnipsel (mit viel Details und Bewegung, um auch ein Auge auf die Qualität werfen zu können) und macht damit ein Wettrennen auf der vorhandenen Hardware.
Ist doch schnell erledigt?
Du meinst, x264/265 ist genauso schnell wie GPU?
Ultrafast / Superfast / Veryfast... je nach CPU natürlich, Qualität schenkt sich dann aber auch nichts mehr, egal ob x26x oder GPU :(dienstag_01 hat geschrieben: ↑Mo 13 Nov, 2023 17:19 Du meinst, x264/265 ist genauso schnell wie GPU?
Ich hab das noch nie nachgemessen, fand aber x264 schon immer ganz schön flott. Gleich schnell hätte ich jetzt aber nicht vermutet. Nehme allerdings auch keines der fasten Presets (in Hybrid).MK hat geschrieben: ↑Mo 13 Nov, 2023 17:28Ultrafast / Superfast / Veryfast... je nach CPU natürlich, Qualität schenkt sich dann aber auch nichts mehr, egal ob x26x oder GPU :(dienstag_01 hat geschrieben: ↑Mo 13 Nov, 2023 17:19 Du meinst, x264/265 ist genauso schnell wie GPU?
Die Geschwindigkeit nimmt mit den langsameren Presets immer mehr ab. Medium ist für Previews über die CPU gerade zeitlich noch so im Rahmen.dienstag_01 hat geschrieben: ↑Mo 13 Nov, 2023 17:38 Ich hab das noch nie nachgemessen, fand aber x264 schon immer ganz schön flott. Gleich schnell hätte ich jetzt aber nicht vermutet. Nehme allerdings auch keines der fasten Presets (in Hybrid).
Ich habe gerade extra nachgeschaut, ich nehme immer None. Und lege die Bitrate fest.MK hat geschrieben: ↑Mo 13 Nov, 2023 17:44Die Geschwindigkeit nimmt mit den langsameren Presets immer mehr ab. Medium ist für Previews über die CPU gerade zeitlich noch so im Rahmen.dienstag_01 hat geschrieben: ↑Mo 13 Nov, 2023 17:38 Ich hab das noch nie nachgemessen, fand aber x264 schon immer ganz schön flott. Gleich schnell hätte ich jetzt aber nicht vermutet. Nehme allerdings auch keines der fasten Presets (in Hybrid).
Die Bitrate ist unabhängig vom Qualitäts-Preset. Das ist ein typischer Stolperstein bei x264 und x265.dienstag_01 hat geschrieben: ↑Mo 13 Nov, 2023 17:47Ich habe gerade extra nachgeschaut, ich nehme immer None. Und lege die Bitrate fest.
Hier heißt *Preset NONE* und *Configuration Default* im ergebnis *Preset veryfast*.cantsin hat geschrieben: ↑Mo 13 Nov, 2023 18:16Die Bitrate ist unabhängig vom Qualitäts-Preset. Das ist ein typischer Stolperstein bei x264 und x265.dienstag_01 hat geschrieben: ↑Mo 13 Nov, 2023 17:47
Ich habe gerade extra nachgeschaut, ich nehme immer None. Und lege die Bitrate fest.
D.h., wenn Du z.B. als Bitrate 24 MBit/s einstellst und kein Qualitäts-Preset wählst, wird mit mittlerem Rechenaufwand und (innerhalb dieser Bitrate) mittlerer Encodingqualität encodiert. Wenn Du hingegen das Preset auf "veryslow" oder "Placebo" stellst, wird zwar immer noch mit 24 Mbit/s encodiert, aber mit maximalem Rechenaufwand/maximaler Optimierung und entsprechend langsamer Encodierungszeit, so dass die erzielbare Bildqualität mit dieser Bitrate deutlich höher bzw. maximal ausgereizt wird.
Umgekehrt kannst auf die Schnell-Presets gehen und kriegst dann innerhalb 24 Mbit/s ungefähr die Qualität, die Du auch mit NVENC & Co. bei 24 Mbit/s kriegen würdest.
MKs Argument ist wohl, dass dieses CPU-Schnell-Encoding mittlerweile so zügig geht, dass NVENC & Co. sich eigentlich nicht mehr lohnen (es sei denn, meine Zufügung, man will die CPU-Last auf dem System niedrig halten).
veryfast = beinahe schlechtest mögliche Encoding-Qualität (nur "ultrafast" ist noch schlechter), als Trade-Off für maximale Encoding-Geschwindigkeit.dienstag_01 hat geschrieben: ↑Mo 13 Nov, 2023 18:58 Hier heißt NONE und *Configuration Default* Preset veryfast.
Und damit gebe ich meine HD-Previews mit 3500 raus ;)cantsin hat geschrieben: ↑Mo 13 Nov, 2023 19:00veryfast = beinahe schlechtest mögliche Encoding-Qualität (nur "ultrafast" ist noch schlechter), als Trade-Off für maximale Encoding-Geschwindigkeit.dienstag_01 hat geschrieben: ↑Mo 13 Nov, 2023 18:58 Hier heißt NONE und *Configuration Default* Preset veryfast.
Bei Hybrid ist das nicht so. Ich habe auch extra in meine vorherige Konfiguration geschaut (anderes Betriebssystem, habe nach meiner schon vor Jahren erstellten eigenen Configuration gesucht, nicht mehr gefunden), auch da ist es veryfast.
Dann übergibt es Hybrid als abweichenden Parameter an x264 oder die haben sich eine eigene Version kompiliert.dienstag_01 hat geschrieben: ↑Mo 13 Nov, 2023 22:47 Bei Hybrid ist das nicht so. Ich habe auch extra in meine vorherige Konfiguration geschaut (anderes Betriebssystem, habe nach meiner schon vor Jahren erstellten eigenen Configuration gesucht, nicht mehr gefunden), auch da ist es veryfast.
Danke, das mache ich mal. Hast du Erfahrung, ob man die Stable oder die Beta nutzen sollte?MK hat geschrieben: ↑Mo 13 Nov, 2023 22:54Dann übergibt es Hybrid als abweichenden Parameter an x264 oder die haben sich eine eigene Version kompiliert.dienstag_01 hat geschrieben: ↑Mo 13 Nov, 2023 22:47 Bei Hybrid ist das nicht so. Ich habe auch extra in meine vorherige Konfiguration geschaut (anderes Betriebssystem, habe nach meiner schon vor Jahren erstellten eigenen Configuration gesucht, nicht mehr gefunden), auch da ist es veryfast.
Wer Zeit und Muße hat kann sich mit FFMetrics die Kodierungsqualiät verschiedener Einstellungen gegen das Original vergleichen.
Ja, toll ;)cantsin hat geschrieben: ↑Mo 13 Nov, 2023 23:50 Hier mal der Unterschied zwischen einem x264-Encoding mit Preset "veryfast" versus "Placebo", bei identischer Bitrate und ansonsten identischen Encoderparametern in ffmpeg.
Das Original ist ein mit der Ursa 4.6K gedrehtes Blackmagic Raw-Demovideo mit sehr viel Bewegung von Kamera und Motiv, in einer DCI 2K-Timeline mit rausgenommener SloMo sowie 200% ins Bild reingecroppt, um den Codec maximal zu stressen. Den Clip habe ich als unkomprimiertes Quicktime rausgerendert.
Der 36. Frame des unkomprimierten Videos sieht dann so aus:
00036-uncompressed.jpg
(Konnte hier leider nur JPEG in 100%-JPEG-Qualität hochladen, weil der PNG-Screengrab mit 11MB zu groß fürs Forum ist.)
Encoding mit x264, 2-Pass 6500 Kbit/s, Preset "Placebo" [=langsam, rechenintensiv, bestmögliche Encoding-Qualität]:
new-00036-placebo.png
Encoding mit x264, 2-Pass 6500 Kbit/s, Preset "Veryslow" [=schnell, zweitschlechtestmögliche Encoding-Qualität]:
new-00036-veryfast.png
Am besten die beiden letzten Bilder 'runterladen und hintereinander betrachten, um die Unterschiede zu sehen. Hier mal zwei 1:1-Crops zum Direktvergleich:
new-00036-placebo-crop.png
"placebo"
new-00036-veryfast-crop.png
"veryfast"
Naja, sieh mal genau hin...:dienstag_01 hat geschrieben: ↑Di 14 Nov, 2023 00:01 Aber im Ernst, das ist in meinen Augen vollkommen uninteressant (es sei denn, man streamt es auf einen riesigen Screen), spielt im Bewegtbild keine Rolle.
Mein Kriterium sind immer Blockartefakte im Schwarzen, wenn die auftreten, gebe ich alles, die zu verhindern/zu minimieren.
Ja, aber das ist mir zu akademisch/allgemein. Letztendlich entscheidet man für konkretes Material. Das es Unterschiede gibt, ist ja nun nicht überraschend.cantsin hat geschrieben: ↑Di 14 Nov, 2023 00:07Naja, sieh mal genau hin...:dienstag_01 hat geschrieben: ↑Di 14 Nov, 2023 00:01 Aber im Ernst, das ist in meinen Augen vollkommen uninteressant (es sei denn, man streamt es auf einen riesigen Screen), spielt im Bewegtbild keine Rolle.
Mein Kriterium sind immer Blockartefakte im Schwarzen, wenn die auftreten, gebe ich alles, die zu verhindern/zu minimieren.
new-00036-placebo-crop.png
placebo
new-00036-veryfast-crop.png
veryfast
Die Frage ist halt, was Dein Zielmedium ist.dienstag_01 hat geschrieben: ↑Di 14 Nov, 2023 00:11 Ja, aber das ist mir zu akademisch/allgemein. Letztendlich entscheidet man für konkretes Material. Das es Unterschiede gibt, ist ja nun nicht überraschend.
Genauso kann ich aber auch die Bitrate erhöhen, und habe eine bessere Qualität.cantsin hat geschrieben: ↑Di 14 Nov, 2023 00:14Die Frage ist halt, was Dein Zielmedium ist.dienstag_01 hat geschrieben: ↑Di 14 Nov, 2023 00:11 Ja, aber das ist mir zu akademisch/allgemein. Letztendlich entscheidet man für konkretes Material. Das es Unterschiede gibt, ist ja nun nicht überraschend.
Wenn Dein Zielmedium z.B. Auslieferung der mp4-Datei auf einem USB-Stick bzw. Du die Abspieldatei rausrenderst, erzielst Du mit dem langsameren Encoder-Preset doch eine deutlich höhere Qualität.
Oder (anders betrachtet), wenn die Bandbreite knapp ist, kannst Du mit dem langsamen Preset die Bitrate senken, ohne Bildqualität zu verlieren.
Was aber nicht immer geht - entweder weil Du z.B. bei Streaming innerhalb der möglichen Bandbreite für flüssiges Playback bleiben musst, oder wenn Du für Hardware-Medienspieler (wie z.B. SmartTVs) die zulässige bzw. sicher unterstützte Bitrate nicht überschreiten solltest.dienstag_01 hat geschrieben: ↑Di 14 Nov, 2023 00:20 Genauso kann ich aber auch die Bitrate erhöhen, und habe eine bessere Qualität.