auf welche weise hast du die qualität überprüft?Bruno Peter hat geschrieben:Hat schon jetzt jemand überprüft ob aus der "Delivery" heraus gleichwertige h.264 - Videoqualität wie im Falle Handbrake exportiert werden kann?
ok. -- dann vergessen wir das am besten schnell wieder...
Warum?
Natürlich ist das libx264.mash_gh4 hat geschrieben: ↑Do 25 Feb, 2021 19:30
es ist zwar nicht gesagt, dass man nicht auch mir anderen codecs tatsächlich die selbe qualität wie mit libx264 erreichen kann, oder BMD endlich eine lizenz für diese freie lösung erworben hat,
weil man so etwas mit den dafür gebräuchlichen metriken beurteilt.
so einfach geht das nicht!Frank Glencairn hat geschrieben: ↑Do 25 Feb, 2021 20:05Natürlich ist das libx264.mash_gh4 hat geschrieben: ↑Do 25 Feb, 2021 19:30
es ist zwar nicht gesagt, dass man nicht auch mir anderen codecs tatsächlich die selbe qualität wie mit libx264 erreichen kann, oder BMD endlich eine lizenz für diese freie lösung erworben hat,
BM stellt sowieso nur die Schnittstelle zur Verfügung, das x264 plugin ist von einem Forenmitglied, wie auch das DPP AS-11 Plugin. MainConcept bastelt gerade an eigenen Implementationen (HEVC 8K z.B.)
Wir wissen hier alle wie das geht.
Kann man sicher machen, wenn man irgendwas verkaufen will,
selbst zwischen den codecs der selben art, gibt es leider in der praxis ganz gewaltige qualitäts- bzw. effizienzunterschiede!
wie gesagt, wenn man das ein bisserl genauer untersucht, kommt man da zu etwas anderen erkenntnissen -- wobei die durchaus nützlich sind, um tartsächlich die verfügbaren bandbreiten sinnvoll auszunutzen bzw. möglichst hochwertige bilder im netz zugänglich zu machen.
Aber wenn das File die max. Dateigröße die es haben darf nicht überschreitet und im direkten Vergleich im NLE kein Unterschied zu sehen ist, welche Relevanz hat das dann? Vielleicht sprechen wir einfach von verschiedenen Anwendungsgebieten, aber die einzigen h264 Files die ich anliefere landen meistens auf Plattformen, auf denen sie sowieso nochmal komprimiert werden. Und meistens sind die Specs auch vorgegeben.mash_gh4 hat geschrieben: ↑Do 25 Feb, 2021 21:15selbst zwischen den codecs der selben art, gibt es leider in der praxis ganz gewaltige qualitäts- bzw. effizienzunterschiede!
ich hab leider gerade keine aktuelleren vergleiche bei der hand, weil mittlerweile h.264 keine so große rolle mehr spielt, und deshalb fast nur mehr h.265, AV1 u.ä. getestet wird.
wie gesagt, wenn man das ein bisserl genauer untersucht, kommt man da zu etwas anderen erkenntnissen -- wobei die durchaus nützlich sind, um tartsächlich die verfügbaren bandbreiten sinnvoll auszunutzen bzw. möglichst hochwertige bilder im netz zugänglich zu machen.
die heute üblichen anspruchsvolleren video-qualitätsmetriken (bspw. VMAF) orientieren sich natürlich an genau dieser visuellen wahrnehmung in größeren versuchsgruppen -- liefern also u.a. ganz klare aussagen darüber, wann entprechende kompressionsartefakte bzw. qualitätsminderung auf unterschiedlichen wiedergabegeräten tatsächlich für gewöhnlich wahrgenommen wird.Frank Glencairn hat geschrieben: ↑Do 25 Feb, 2021 21:07 Aber für gewöhnlich schaut man so einen Film mit den Augen an, und nicht mit einem Messprogramm.
Wenn die Augen keinen Unterschied sehen können,
dann ist das Ziel zu 100% erreicht,
Huh? Geht doch größtenteils um die Distribution und nicht um die Nutzung. Wenn ich eine nichtfreie Version von ffmpeg kompiliere, dann darf ich die nicht weitergeben, verwenden aber definitiv.
ja -- die einschränkungen beziehen sich tatsächlich nur auf die weitergabe.
Der Export läuft auf meinem Rechner wirklich wahnsinnig schnell.Frank Glencairn hat geschrieben: ↑Do 25 Feb, 2021 18:39 Ja, vor allem erstaunlich schnell (bei mittelprächtigen EInstellungen) - bis zu 40 FPS auf einem recht alten Hobel.
Stellt sich raus: nur unter Linux, bei "EN-US-Intl"-Tastaturen, die doppelte Anführungszeichen, Umlaute und sonstige Buchstaben mit Akzenten auf zwei hintereinander gedrückte Tasten legen. Auch wenn das auf OS-Ebene eingestellt ist, hat Resolve da einen Bug bzw. eine Unzulänglichkeit. Man kann mit Copy-Paste aus anderen Programmen helfen, aber dann landet der eingefügt Inhalt (wie gesagt) doppelt im Resolve-Titel...
Hab den Test jetzt mal spaßeshalber gemacht, mit relativ anspruchsvollem Testmaterial (Action-Aufnahmen mit viel Bewegung, Low Light mit Bildrauschen und Regen, aus Braw-Referenzdateien aus der Pocket 6K und 4K von Blackmagics Website).
Renderzeiten subjektiv gleich, ob die GPU angesprochen wurde, habe ich nicht geprüft. (Der Standard-x264-Codec ist nicht GPU-beschleunigt.)
mit derartigen visuellen gegenüberstellungen kann man natürlich stunden verbringen, trotzdem halte ich es für wesentlich vernünftiger, solche vergleiche bzw. beurteilungen mit geeigneteren mitteln anzustellen...
mir kommen immer wieder einzelne tests unter, wo intel quicksync oder die nvidia encoder zumindest in den schnellen verarbeitungsmodi besser abschneiden als libx264. mittlerweile dürften also auch diese anderen implemenationen fast alle details übernommen haben, die ursprünglich den qualitativen vorsprung von x264 ausgemacht haben.cantsin hat geschrieben: ↑Do 25 Feb, 2021 23:52 Tatsächlich sind die Ergebnisse des direkten h264-Exports aus Resolve und des Umwegs Resolve -> DNxHR 10bit -> Handbrake x264 optisch praktisch nicht unterscheidbar. Habe bei Handbrake das schnellste Encoding-Preset gewählt sowie eine Qualitätsstufe, bei der am Ende die gleiche Dateigröße wie beim Resolve-Direktexport (160MB bei 5.15 Sek. in UltraHD) resultierte.
nein -- bisher haben wir alle einfach nur über das default h.264 encoding im resolve jenseits aller plugins und modifikationen geredet.Frank Glencairn hat geschrieben: ↑Fr 26 Feb, 2021 06:50 Ich glaube wir reden hier über verschiedene Dinge.
eh -- klar!Frank Glencairn hat geschrieben: ↑Fr 26 Feb, 2021 06:50 1. h264 Export, wahlweise auf der CPU oder GPU gerechnet (wenn man ne Nvidia Karte hat) - das ging ja schon lange vor der 17.
das klammern wir vielleicht besser aus der diskusion aus, weil deratige erweiterung, die sich auf GNU lizenz geschützte software stützen, in unfreier software nicht genützt werden dürfen. damit verhält es sich also nicht wesentlich anders, als wenn ich hier leuten erklären würde, dass sie dumm sind, wenn sie creative cloud abos bezahlen, wo man doch auf irgendwelchen servern im darknet immer hacks findet, um die entsprechenen schutzmechanismen zu umgehen.Frank Glencairn hat geschrieben: ↑Fr 26 Feb, 2021 06:50 2. x264 Export über die neue Schnittstelle mit entsprechendem Plugin.
ja. handbracke ist nur eine grafische oberfläche für das ffmpeg. und dieses erlaubt die nutzung ganz vieler verschiedener codecs. libx264 ist nur einer darunter. daneben stehen aber auch einige andere für das selbe format zur verfügung -- tlw. hardware bschleunigt, tlw. nicht.Frank Glencairn hat geschrieben: ↑Fr 26 Feb, 2021 06:50 Und dann gibt's noch Handbrake, wo man auch zwischen CPU/GPU wählen kann, mit unterschiedlichen Ergebnissen.
wie gesagt -- dass evtl. letzt eine brauchbare qualität herauskommt, würde mich weiter nicht verwundern. in dem punkt waren die bisherigen leistungen von resolve ja auch nicht wirklich schwer zu überbieten.Frank Glencairn hat geschrieben: ↑Fr 26 Feb, 2021 06:50 Nach allem was ich bisher probiert hatte, entspricht der CPU Handbrake Export, dem Export aus Resolve über das x264 Plugin, und der GPU Export von Handbrake (Nvidia), emtspricht dem GPU Export in Resolve - was beides eigentlich auch so zu erwarten war, da ja die selben Librarys und die selbe Hardware zum Einsatz kommen - nur das UI ist ein anderes.
kannst du im prozessbaum ('pstree' od.ä.) erkennen, ob sie das ganze tatsächlich in einem losgelösten subprozess realisiert haben -- was u.u. die mangelhafte performance erklären könnte --, oder ob man sich dort einfach über die GPL, die ganz klar eine nutzung von GNU software in form von dynamisch ladbarer modulen in unfreier software untersagt, hinweg setzt?
Bei mir läuft der Gnome-Desktop, weshalb alle laufenden GUI-Anwendung in den meisten Tools monolithisch als "GUI Thread" angezeigt werden. Einen separaten x264-Prozess sehe ich nicht.mash_gh4 hat geschrieben: ↑Fr 26 Feb, 2021 11:41kannst du im prozessbaum ('pstree' od.ä.) erkennen, ob sie das ganze tatsächlich in einem losgelösten subprozess realisiert haben -- was u.u. die mangelhafte performance erklären könnte --, oder ob man sich dort einfach über die GPL, die ganz klar eine nutzung von GNU software in form von dynamisch ladbarer modulen in unfreier software untersagt, hinweg setzt?
Verwende das schon seit Jahr und Tag, funktioniert tadellos.freezer hat geschrieben: ↑Fr 26 Feb, 2021 12:36 Weiß nicht, ob das wer kennt:
https://www.danieltufvesson.com/makeresolvedeb
hmm -- gnome sollte daran eigentlich nichts ändern.
natürlich kann man diese problematik auch einfach ignorieren.