slashCAM Forum

Die Meldung ist falsch positiv... was der Bauer (Windows) nicht kennt usw...

Der Entwickler kommt aus Deutschland.

Vom Entwickler:

"Windows zeigt Warnungen da der Installer und das eigentliche Plugin nicht digital signiert sind. Ein solches "EV Codesigning Certificate" kostet mehrere hundert Euro, hält max. 3 Jahre und muss dann immer wieder neu gekauft werden. Das kann ich mir für ein kostenloses Plugin nicht leisten."

Das ergibt Sinn, Danke Dir! :-)

TomStg hat geschrieben: ↑Di 01 Feb, 2022 21:40

cantsin hat geschrieben: ↑Di 01 Feb, 2022 21:29 Falls Du diesen Weg gehen willst, würde ich ProRes (auf MacOS) oder DNxHR (Windows/Linux) exportieren und dann die exportierte Datei mit Handbrake als h264/h265 encodieren.

Dieser Intermediate-Umweg macht nun wirklich keinen Sinn, kostet nur Zeit und erzeugt eine völlig überflüssige zusätzliche verlustbehaftete Rendergeneration.

Da wäre ich mir nicht so sicher - hier das Ergebnis eines Vergleichstest mit frischgedrehtem Material, den ich gerade mal veranstaltet habe:

(anklicken für Ansicht in Originalgröße)

Das Bild links wurde direkt aus Resolve als h265 bei 9000 MBit/s (Nvenc) exportiert, das Bild rechts erst als DNxHR HQX exportiert und dann mit ffmpeg [=der engine von Handbrake] mit dem x264-Codec zu 9000 MBit/s-h264 umcodiert.

Wohlgemerkt, die linke Hälfte ist das eigentlich modernere, effizientere und bei niedrigeren Bitraten bessere h265, die rechte Hälfte das ältere (aber zu mehr Abspielhardware kompatible) h264, beide bei gleicher Bitrate. Hier könnte man höchstens noch argumentieren, dass der Nvidia/Resolve-h265-Codec für eine u.U. willkommene Weichzeichnung/Gesichtsretusche sorgt...

Das Quellmaterial ist übrigens schnödes Long-GOP-4K-Video aus einer Panasonic S1H mit dem ebenfalls schnöden 24-105mm/f4-Zoom. Also keine Highend-Sachen wie Raw aus einer Cinekamera mit Zeiss Supreme Primes....


- Natürlich sind die diversen x264/x265-Third Party-Plugin-Hacks für Resolve ein Mittel, um das beste beider Ansätzen zu kombinieren, bzw. sich den Zwischenschritt über DNxHR oder ProRes zu sparen. Ich nutze allerdings die Linux-Version von Resolve, für die es AFAIK noch keine entsprechenden Lösungen gibt.

Die Qualität von NVEnc ist für live oder Previews akzeptabel, für Mastering aber selbst bei hohen Bitraten kritisch, egal wie man die Einstellungen tweakt... Grain wird nicht sauber wiedergegeben und in sehr dunklen Bereichen gibt es Posterisationseffekte. Und ich rede hier von 4k mit 50 Mbit mit dem NVEnc der 20xx Generation.

Ja. für ne schnelle Vorschau geh ich auch schon mal über Resolve raus, aber wenn es ernst wird, immer erst ein unkomprimiertes Master (brauch ich ja sowieso) und von da aus über Handbrake.

Resolve Studio 17 vs. Handbreak:

Ich rendere MP4/h624/h265 mittlerweile wieder alles direkt von Resolve Studio 17 aus der Timeline raus, mit 2K und mit 4K (aktuelle Version) ganz ohne Handbreak.

Ich hab das wirklich bis zum geht nicht mehr, erst kürzlich im Januar mit beiden Tools wirklich, ausführlich getestet und mit zig verschiedenen Bitraten und Einstellungen, die Ergebnisse wirklich, auf zwei schönen LG/Samsung HD Screens, direkt nebeneinander, immer wieder miteinander, verglichen.

Das Material aus der Kamera war 4K BBaw mit Q1 und 4K BRaw 8:1, 12Bit (Film)
Timeline eingestellt auf 4K, heraus rendern nur mit Full HD.
Beziehungsweise für die Handbremse auf zuerst 4K DnXHR..

Single Pass, Multipass, Auto, manuell, niedrige Bitrate, mittlere Bitrate, hohe Bitrate, mit mp4, QuickTime, H624, h265.
Alles quer durchs Band mit den beiden Programmen.

Mein (persönliches) Fazit:
Die Qualität der Ergebnisse sind, für meine Augen mittlerweile mit (Resolve Studio 17) eher ein wenig besser, ganz bestimmt nicht schlechter, als mit Handbreak.
In gar keiner Hinsicht.
Glaubt es mir oder glaubt es mir nicht…;)

Weitere Vorteile von Resolve:
Das Rendern geht mit Resolve zumal gefühlt etwas schneller und die zusätzliche mit etwas Verlust behaftete Umwandlung zuerst in ProRes/DnXHR für die Handbremse entfällt so ganz.
Ich nutze Handbreak somit gar nicht mehr, weil für mich sehe ich dafür mittlerweile überhaupt keinen Grund.
Für mich stimmt es was da BMD mit Resolve direkt auf den Speicher Stick so zaubert…

Ich bin mir ganz sicher BMD hat diesbezüglich bei der Studio Version 17 sehr stark aufgeholt. Bei der Version 16 und 15 war das Ergebnis nicht so gut und der Mac ist mir früher beim rendern auch öfters abgestürzt.
Heute gar nicht mehr.

Wie sehen die erfahrenen Profi Augen das ?;)
Würde ich interessieren.
Gruss Boris

Falls das Delivery-Modul eines aktuellen NLE mit H264/265 - also den gängigsten und meist verbreiteten Distributionscodecs - eine so heftig schlechtere Ausgabequalität erzeugt als eine Ausgabe mit einem verlustbehafteten Intermediate-Codec plus zusätzlicher Rendergeneration durch Handbrake-Freeware, wäre so ein NLE praktisch unbrauchbar. Das trifft zumindest für die Resolve-Studio-Version unter MacOS nicht zu.

Ist die Qualität mit einem zusätzlichen Intermediate-Codec plus Handbrake tatsächlich besser, kann es sich nur um einen Fehler im individuellen Workflow handeln oder das NLE wäre auf der Stelle zu ersetzen. Aber auch in diesem Fall ist ein verlustbehafteter Intermediate-Codec keine Option. Eine Ausgabe mit einem verlustlosen Codec oder unkompromiert ist aus Qualitätsgründen klar sinnvoller.

Nun gut wenn jetzt jemand natürlich ein verlustloses Master braucht um später was auch immer damit zu machen, wird Handbreak sicher sinnvoll sein müssen.
Keine Ahnung ?
Ich weiss auch nicht was dann diesbezüglich in Resolve Studio überhaupt damit geht und was nicht.

Da oben beim kleinen Erfahrungsbericht, hab ich mich nur auf meine ganz eigenen Erfahrungen bezogen…
Gruss Boris

TomStg hat geschrieben: ↑Mi 02 Feb, 2022 09:05 Falls das Delivery-Modul eines aktuellen NLE mit H264/265 - also den gängigsten und meist verbreiteten Distributionscodecs - eine so heftig schlechtere Ausgabequalität erzeugt als eine Ausgabe mit einem verlustbehafteten Intermediate-Codec plus zusätzlicher Rendergeneration durch Handbrake-Freeware, wäre so ein NLE praktisch unbrauchbar. Das trifft zumindest für die Resolve-Studio-Version unter MacOS nicht zu.

Ist die Qualität mit einem zusätzlichen Intermediate-Codec plus Handbrake tatsächlich besser, kann es sich nur um einen Fehler im individuellen Workflow handeln oder das NLE wäre auf der Stelle zu ersetzen. Aber auch in diesem Fall ist ein verlustbehafteter Intermediate-Codec keine Option. Eine Ausgabe mit einem verlustlosen Codec oder unkompromiert ist aus Qualitätsgründen klar sinnvoller.

Für PC ist das schon lange nicht mehr die Realität, siehe Voukoder, mit Mac kenne ich mich nicht aus. Dann müssten Resolve und Premiere in MAC/PC andere Codecs verbaut haben, weiß nicht.

TomStg hat geschrieben: ↑Mi 02 Feb, 2022 09:05 Falls das Delivery-Modul eines aktuellen NLE mit H264/265 ...

Daß x264 bessere Qualität und geringere Datenraten hat als 264, ist jetzt aber auch nix neues.
Allerdings stellt sich die Frage dank Voukoder auch nicht mehr.

Da ich immer ein unkomprimiertes Master raus rechnen muß, hab ich davon aber auch nicht wirklich was :D

Frank, welches Format verwendest Du für Dein Master?

Unkomprimiertes AVI

Avi!
Avi kenn ich nur von damals aus der Schmuddel oder Raubkopie Ecke, ist das was vernünftiges?

cantsin hat geschrieben: ↑Di 01 Feb, 2022 21:29

Video Rookie hat geschrieben: ↑Di 01 Feb, 2022 19:40 Ich habe UHD Material 25p als Canon XF-AVC Format (.MXF Container). Wenn ich dieses Ausgangsmaterial fertig bearbeitet habe und ich Handbrake zwecks h264 Codierung nutzen möchte - in welchem Format empfehlt Ihr den Export aus Resolve?

Falls Du diesen Weg gehen willst, würde ich ProRes (auf MacOS) oder DNxHR (Windows/Linux) exportieren und dann die exportierte Datei mit Handbrake als h264/h265 encodieren.

Bezüglich klusters Empfehlung, direkt aus Resolve h265 zu rendern (was dann i.d.R. über den Hardware-Encoder der Grafikkarte läuft), würde ich einfach mal Vergleichstests machen.

also ich habe das schon öfter vergleichen und hab mich immer wieder doch für Handbrake entschieden. Die Files sind kleiner und dennoch bessere Qualität.

klusterdegenerierung hat geschrieben: ↑Mi 02 Feb, 2022 10:30 Avi!
Avi kenn ich nur von damals aus der Schmuddel oder Raubkopie Ecke, ist das was vernünftiges?

LOL :D

https://de.wikipedia.org/wiki/Audio_Video_Interleave

TomStg hat geschrieben: ↑Mi 02 Feb, 2022 09:05 Falls das Delivery-Modul eines aktuellen NLE mit H264/265 - also den gängigsten und meist verbreiteten Distributionscodecs - eine so heftig schlechtere Ausgabequalität erzeugt als eine Ausgabe mit einem verlustbehafteten Intermediate-Codec plus zusätzlicher Rendergeneration durch Handbrake-Freeware, wäre so ein NLE praktisch unbrauchbar.

Das hat nichts mit dem NLE zu tun, sondern ist die Qualität von Nvidias Hardware-Encoder (Nvenc). D.h. auf jedem NLE, bei dem Du via Nvenc/mit Nvidia Hardware-Beschleunigung nach h264 oder h265 rausrenderst, kriegst Du diese Bildqualität.

Das trifft zumindest für die Resolve-Studio-Version unter MacOS nicht zu.

Weil unter MacOS keine Nvidia-Karten und damit auch nicht Nvenc gebraucht werden.

Ist die Qualität mit einem zusätzlichen Intermediate-Codec plus Handbrake tatsächlich besser, kann es sich nur um einen Fehler im individuellen Workflow handeln oder das NLE wäre auf der Stelle zu ersetzen.

Du glaubst doch nicht ernsthaft, dass man bei 9Mbit/s-h264 irgendeinen Unterschied sieht (bzw. sich auch nur ein relevanter Pixel dadurch verändert), wenn das Master unkomprimiertes Video ist oder mit einem niedrig komprimierten Codec wie ProRes oder DNxHR rausgerendert wurde...

Da stellst Du ja höhere Qualitätsansprüche als Hollywood-Postproduktionshäuser.

Ja und dann macht man den 4K unkomprimierten Master Max und anschliessend landet es mit 10Mbit und 720p in der Mediathek. :-)

Es wäre übrigens interessant, mal einen Performance- und Bildqualitäts-Shootout der Hardware-h264/h265-Encoder von Nvidia (Nvenc), AMD (VCE), Intel (QuickSync) und Apple (M1-interner Encoder) zu machen: Wie schnell rendern sie jeweils auf grob vergleichbarer Hardware, und wie gut ist die Bildqualität ihres Outputs bei verschiedenen Bitraten?

Auch Nvenc hat, trotz seiner Qualitätsabstriche, ja durchaus seinen Platz, wenn man z.B. ein Blog-/Nachrichten-Video sehr schnell rausrendern, uploaden oder jemandem mitgeben will. Dann wählt man eben eine höhere Bitrate, um die Qualitätseinbußen zu kompensieren.

Auch bei meinem weiter oben geposteten Beispiel wäre ja die Frage, ob man die Qualitätsunterschiede zwischen Nvenc und Handbrake/ffmpeg/x264/x265 überhaupt noch sieht, nachdem das Video z.B. auf YouTube hochgeladen wurde. Bei anderen Social Media-Plattformen wie Facebook, Instagram und Twitter und deren mieser Videobildqualität wird es da garantiert keinen sichtbaren Unterschied geben, insofern spricht bei denen sowie nichts gegen Nvenc (und kann man sich den erhöhten Renderaufwand mit x264/x265 sparen)...

Unterm Strich heißt das, das Nvidia so schnelle ist, weil er das Bild nicht in so einer guten Quali bzw guten Kompression rausschickt?
Und das heißt auch, das dann selbst der h264 nicht Nvidia eine bessere Quali liefer und man nichtmal viel von der 10Bit Option hat?

klusterdegenerierung hat geschrieben: ↑Mi 02 Feb, 2022 15:32 Unterm Strich heißt das, das Nvidia so schnelle ist, weil er das Bild nicht in so einer guten Quali bzw guten Kompression rausschickt?
Und das heißt auch, das dann selbst der h264 nicht Nvidia eine bessere Quali liefer und man nichtmal viel von der 10Bit Option hat?

Ja, leider - Prinzip "quick and dirty". Ich werd' gleich noch mal einen Versuch machen mit dem Nvidia-Encoder in höchster Qualitätseinstellung und 10bit.


EDIT - Voilà:
(2x anklicken für 1:1-Ansicht)

Mich hat Handbrake und dieses Theater mit den Profilen die nicht komplett so gespeichert werden können wie man möchte ziemlich angenervt.
Ständig diese abstellen von Audio 5.1 etc. als wenn das blöde Teil sich das nicht einfür allemal merken kann. ;-)

klusterdegenerierung hat geschrieben: ↑Mi 02 Feb, 2022 15:54 Mich hat Handbrake und dieses Theater mit den Profilen die nicht komplett so gespeichert werden können wie man möchte ziemlich angenervt.
Ständig diese abstellen von Audio 5.1 etc. als wenn das blöde Teil sich das nicht einfür allemal merken kann. ;-)

Kommandozeile und ffmpeg lernen, dann kannst Du die ganze Chose skripten und Dir sehr leicht verschiedene Presets bauen...

cantsin hat geschrieben: ↑Mi 02 Feb, 2022 15:34 EDIT - Voilà:

Hui, da hat man ja schon die Beautyretusche mit drin, easy! ;-)))

cantsin hat geschrieben: ↑Mi 02 Feb, 2022 15:56 ffmpeg lernen

Das ist für mich ungefähr wie mal eben Alu Schweißen lernen. ;-))

Hat sich denn jetzt irgendwas in Resolve durch diese Voukoder geändert, hast Du das mal gegengecheckt, bzw was haben wir jetzt davon?

klusterdegenerierung hat geschrieben: ↑Mi 02 Feb, 2022 16:02 Hat sich denn jetzt irgendwas in Resolve durch diese Voukoder geändert, hast Du das mal gegengecheckt, bzw was haben wir jetzt davon?

Dann kannst Du in der Tat direkt in x264/x265 rausrendern, als mit denselben Codecs (und in derselben Qualität) wie Handbrake, aber deutlich langsamer [da nicht GPU-beschleunigt].

cantsin hat geschrieben: ↑Mi 02 Feb, 2022 16:08

klusterdegenerierung hat geschrieben: ↑Mi 02 Feb, 2022 16:02 Hat sich denn jetzt irgendwas in Resolve durch diese Voukoder geändert, hast Du das mal gegengecheckt, bzw was haben wir jetzt davon?

Dann kannst Du in der Tat direkt in x264/x265 rausrendern, als mit denselben Codecs (und in derselben Qualität) wie Handbrake, aber deutlich langsamer [da nicht GPU-beschleunigt].

Also ich gehe dann jetzt genauso wie vorher auf mp4 Container und dann auf h264, oder auf h264 Nvidia, oder ganz anders?
Was muß ich dann für Werte anvisieren wenn ich was davon haben will?

Das heißt das ich dadurch jetzt sozusagen Handbrake in Resolve habe?

Mit dem Voukoder kann man auch NVEnc nutzen. Dort mit mehr Einstellmöglichkeiten. x264 bzw. x265 ist doch auch in Handbrake nicht über die GPU beschleunigt?

Hatte ich mir auch gedacht denn das hat immer ne Ewigkeit gerendert.

MK hat geschrieben: ↑Mi 02 Feb, 2022 16:21 Mit dem Voukoder kann man auch NVEnc nutzen. Dort mit mehr Einstellmöglichkeiten. x264 bzw. x265 ist doch auch in Handbrake nicht über die GPU beschleunigt?

Ja, das meinte ich.

Es ist völlig egal, ob man x264/x265 via Vokouder, Handbrake, ffmpeg, Shutter Encoder oder welches Interface auch immer verwendet. Das Encodieren läuft bei x264 und x265 immer ausschließlich über die CPU und ist rechenaufwändiger, daher [bei hohen Qualitäts-Settings] deutlich langsamer, aber eben auch im Resultat qualitativ besser als Nvenc und andere Hardware-Codecs.

Das verstehe ich nur bedingt, denn all die zusätzlichen features die man nun damit bekommen hat, befinden sich doch lediglich unter dem schlechteren Nvidia Codec, bei den anderen hat sich doch überhaupt nix geändert, was soll denn dann jetzt gleich sein wie bei Handbrake, sorry?

klusterdegenerierung hat geschrieben: ↑Mi 02 Feb, 2022 16:49 Das verstehe ich nur bedingt, denn all die zusätzlichen features die man nun damit bekommen hat, befinden sich doch lediglich unter dem schlechteren Nvidia Codec, bei den anderen hat sich doch überhaupt nix geändert, was soll denn dann jetzt gleich sein wie bei Handbrake, sorry?

Noch mal langsam:

h264 und h265 sind keine Codecs, sondern standardisierte Videoformate. Beide Videoformate haben ziemlich ausufernde Features. Wie wir wissen, werden nicht alle dieser Features auf allen Abspielgeräten unterstützt (z.B. 10bit h264 oder generell h264 "High" Profile i.d.R. nicht von einfachen Medienspielern). Das ist die Decoderseite.

Auf der Encoderseite sieht es ähnlich aus: Es gibt simplere und komplexere Encoder, die jeweils bestimmte Untermengen der Features von h264 und h265 unterstützen.

x264 und x265 sind zwei (sehr verbreitete) Open Source-Codecs für h264- bzw. h265-kompatibeles Video, die die Featuresets dieser beiden Formate weitgehend abdecken und auf Bildqualität getrimmt sind. Sie laufen, auch aus Kompatibilitätsgründen, ausschließlich auf der CPU und machen keinen Gebrauch von GPU-Beschleunigung. Programme wie ffmpeg, Handbrake, ShutterEncoder, Voukoder verwenden diese beiden Codecs und agieren letztlich nur als Interfaces dafür. Es ist also weitgehend egal, ob man h264-Video mit Handbrake oder Voukoder encodiert - in beiden Fällen arbeitet unter der Haube x264. Der Unterschied liegt allein darin, welche der ausufernden Features von x264 Handbrake, Voukoder oder andere Programme über ihre Benutzerinterface zugänglich machen, bzw. welche Presets sie für x264 verwenden.

Daneben gibt es noch alle möglichen anderen Encoder für h264 und h265, von anderen Softwareherstellern wie z.B. Main Concept. (Der Main Concept-h264-Encoder wird AFAIK in Adobe Premiere verwendet, und zwar immer dann, wenn man in Premiere h264-Video exportiert.)

Neben diesen reinen Software-Encodern gibt es noch die Hardwareencoder von Nvidia, AMD, Intel und Apple, die als feste Chipfunktion direkt ins Silizium der GPUs eingebaut sind. Wenn Resolve also per Nvenc h264 exportiert, schickt es einen unkomprimierten Videostrom an die Grafikkarte, die dann mit ihrer Chiphardware h264 erzeugt und an den Computer zurückschickt.

Diese Hardware-Codecs sind vor allem auf Schnelligkeit optimiert und unterstützen nur eine kleine Untermenge der möglichen Features des h264- und h265-Formats. Sie sind auch qualitativ nur so gut, wie sie im Chip implementiert bzw. fest eingegossen sind. D.h. es gibt (im Gegensatz zu den Software-Encodern) keine Möglichkeit, sie über neue Versionen bzw. Softwareupdates zu verbessern. [Genauso funktionieren übrigens auch die h264/h265-Encoder der meisten digitalen Kameras.]

Also für Resolve 17 muss ich meine Aussage auf jeden Fall dahingehend revidieren, dass das h264-Encoding sowohl mit Nvenc wie auch nativ direkt aus Resolve qualitativ keine Nachteile hat. Habe ich gerade nochmal getestet.
Damit sage ich nichts über die Effizienz, also dem Verhältnis von Qualität zu Datenrate, ich habe nur auf die Qualität geschaut.

D.h. für den Upload auf eine Plattform, die sowieso nochmal encodet, muß man den Weg über ein Intermediate eigentlich nicht gehen.

Mein persönlicher Workflow sieht so aus, dass ich mir angewöhnt habe, Previews mit 3,5 Mbits für 1080p25 zu versenden.
Ich denke, an diese Effizienz von x264 kommt h264 nicht ran.

dienstag_01 hat geschrieben: ↑Mi 02 Feb, 2022 18:10 ... das h264-Encoding sowohl mit Nvenc wie auch nativ direkt aus Resolve qualitativ keine Nachteile hat. Habe ich gerade nochmal getestet.
Damit sage ich nichts über die Effizienz, also dem Verhältnis von Qualität zu Datenrate, ich habe nur auf die Qualität geschaut.
...
Mein persönlicher Workflow sieht so aus, dass ich mir angewöhnt habe, Previews mit 3,5 Mbits für 1080p25 zu versenden.
Ich denke, an diese Effizienz von x264 kommt h264 nicht ran.

hä?
x264 generiert h264.

Mit Avidemux geht encoding wahlweise via x264 als auch mit NVidia-Encoder.

Mein EIndruck dazu ist, ist dass X264 bei gleicher Datenrate bessere Bildqualität generieren kann,
bzw umgekehrt benötigt der NVidia-Encoder für gleiche Bildqualität höhere Datenrate.

Wenn's für den Empfänger machbar ist solltest Du bei x264 mit VBR encoden,
da das BW-budget stark von Komplexität und Varianz abhängt.
dto für x265 (was nur ein superset von 264 ist)
Da kann 3.5 Mbps manchmal zu knapp sein.

Leider fehlt mir noch ein gutes Tool, das 2 Videostreams messtechnisch vergleicht und Differenzen darstellen kann.

Was nutzt ihr dafür?