Glück auf zusammen!
Hat vielleicht jemand nen Link zu nem recht aktuellen FFmpeg mit integriertem x265 in 10bit?!
Die ganzen Builds die ich finde sind entweder recht alt (x265 v2.0) oder nur mit 8bit.
Das selbst zu compilieren scheint ne längere Aktion zu werden, zudem ist das überall recht dürftig dokumentiert bzw. sind die Skripts fehlerbehaftet.
Alternativen gibt's auch kaum da Handbrake selbst mit 10bit Plugin intern nur 8bit dithert, kein echtes 10bit ausgibt. StaxRip macht auch nur Schrott und ist von der Performance bei größeren Files selbst von ner SSD echt unterirdisch. XMedia Recode ist leider verbuggt, schmiert immer ab wenn man HEVC main10 in Kombination mit L5.1 High Tier oder unbegrenzt konvertiert.
Für meGUI gilt eigentlich das gleiche wie für StaxRip.
Also "mein" FFmpeg macht eigentlich was es soll, zudem auch im Skript mit Check ob die Datei aus EDIUS bereits fertig ist und Rechner anschließend runterfahren. Hätte nur gerne nen etwas neueres Build.
Hat da jemand vielleicht ne Adresse?!
EDIT: OS ist Win10/64
Zuletzt geändert von Roland Schulz am Mi 01 Nov, 2017 00:52, insgesamt 1-mal geändert.
unter (debian) linux ist es eigentlich ganz normal, dass die systemweite genutzte x265-library 10bit unterstützt. erst für 12bit support sind hier wieder ähnlich umständliche verrenkungen notwendig, wie man sie im falle von x264 noch für den sprung von 8 auf 10bit benötigte.
es würde mich sehr wundern, wenn das nicht auch unter windows ganz ähnlich wäre.
könnte es evtl. sein, dass du irgendwo noch eine alte x265 .dll od. .exe herumliegen hast, die versehentlich genutzt wird?
Langsam, eine 10bit fähige x264/5.exe zu finden ist nicht so schwierig, es geht mir um eine in FFmpeg gelinkte/integrierte Version, die zeigen an besagter Stelle alle nur 8bit an. Wie gesagt, eine ältere 2.0er 10bit fähige Version habe ich (in FFmpeg), hätte aber gerne min. 2.4 oder neuer.
Falls jemand noch ein FFmpeg mit echtem 10bit x265 interessiert (x264 10bit auch möglich) gibt´s hier ne Lösung, die mir freundlicherweise in nem Nachbarforum genannt wurde:
Da findet man erstmal nix weiter als ne Datei mit ner .bat Batchdatei drin.
Die kann einfach aus nem autarken Ordner unter Windows gestartet werden und macht "nichts" am Rechner, läd nen C-Compiler, Python, sämtliche Sourcecodes und was sonst noch alles runter und kompiliert dann eine aktuelle FFmpeg mit x265 und wenn man will auch x264 in 10bit!! In der Batchdatei wird gefragt was alles kompiliert werden soll, der FDKaac Encoder lässt sich zum Beispiel als Option wählen, ebenso Daala, VP9 usw..
Das dauert alles relativ lange (~1h) und das kann mit "falschen" Optionen auch dazu führen, dass die Compilierung am Ende fehlt schlägt (mehrfach passiert).
Ich werde noch mal sehen mit welchen Optionen ich zum Ziel gekommen bin und das dann ggf. posten.
So hat man auf jeden Fall die Möglichkeit echte 10bit Dateien in x264/x265 zu codieren, Handbrake kann das aktuell z.B. auch mit ner 10bit x265 DLL und nem nightly Build nicht, da intern nur 8bit gedithert wird. Sieht man wenn man z.B. nen 10bit Graukeil aus Photoshop rendert und sich das hinterher (gezoomt) auf ner 10bit Ausgabe anschaut.
QuickTime unter HighSierra macht’s leider nur in 10bit was ne mörder Rechenzeit in Anspruch nimmt...
Was macht den Staxrip über die Nvenc und die Qsync Engine?
motiongroup hat geschrieben: ↑Fr 03 Nov, 2017 08:41
QuickTime unter HighSierra macht’s leider nur in 10bit was ne mörder Rechenzeit in Anspruch nimmt...
Was macht den Staxrip über die Nvenc und die Qsync Engine?
...Müll!!
Ich habe bisher noch überhauptkein vernünftiges H.264/265 aus ner NVidia gesehen (habe ne GTX1070). Zu QuickSync kann ich nur soviel sagen, dass mein Skylake kein 10bit x265 kann (10bit HEVC Encode erst ab Kaby-/Gemini-/Coffee Lake), das 8bit H.265 aber auch grottig ist! 10bit H.264 codieren geht ohnehin nicht mit QuickSync/NVenc!
8bit QuickSync ist ganz ok bei hohen Bitraten, x264/265 bringt aber trotzdem bessere Qualität, zumindest bei geringeren Bitraten.
NVidia kann ab ner Pascal 10bit HEVC codieren, kann man meiner Ansicht nach aber auch bei hohen Bitraten völlig vergessen!
Vergessen darf man aber auch nicht dass FFmpeg mit x265/10bit im Preset Medium auf nem 6700K @4,7GHz bei 100Mbps gerade mal ~3fps schafft (abhängig vom Bildinhalt) ;-)!
10bit HEVC Encode erst ab Kaby-/Gemini-/Coffee Lake), das 8bit H.265 aber auch grottig ist!
Wusste ja nicht welches System du hast..
Nun ja so schlecht in Abhängigkeit der Umgebung kann’s nicht sein da die VCA Einheiten Containerweise in Verwendung sind bei den Streaminganbietern laufen aber meist unter Linuxumgebungen...
...spielt keine Rolle in welcher Umgebung das läuft, ist trotzdem Mist was aus ner nVidia an H.264/265 da raus kommt. Es ist schnell, das ist aber auch alles.
Hat auch niemand behauptet dass das Aushängeschild 4K bei Netflix und Co. irgendeinen Qualitätsanspruch erfüllt.
Das Logo steht da - das war's!
Roland Schulz hat geschrieben: ↑Fr 03 Nov, 2017 10:20
Hat auch niemand behauptet dass das Aushängeschild 4K bei Netflix und Co. irgendeinen Qualitätsanspruch erfüllt.
Das Logo steht da - das war's!
Natürlich nicht, schau dir mal die Datenrate an, die da ankommt.
Und ich finde die 60mbit bei meiner Drohne, für 4k schon extrem grenzwertig, Netflix liegt da um Größenordnungen drunter.
Aber Hauptsache es steht 4K drauf.
Roland Schulz hat geschrieben: ↑Fr 03 Nov, 2017 10:20
Hat auch niemand behauptet dass das Aushängeschild 4K bei Netflix und Co. irgendeinen Qualitätsanspruch erfüllt.
Das Logo steht da - das war's!
Natürlich nicht, schau dir mal die Datenrate an, die da ankommt.
Und ich finde die 60mbit bei meiner Drohne, für 4k schon extrem grenzwertig, Netflix liegt da um Größenordnungen drunter.
Aber Hauptsache es steht 4K drauf.
Moin Frank!
Den ganzen Amazon und Netflix 4K Kram kann mag in Bezug auf die Bildqualität meist ziemlich vergessen, da sehen die meisten vernünftigen Blurays besser aus.
Hast auch Recht, die 60Mbps der Phantom 3 Pro waren grenzwertig, das I-Frame Gewackel war zudem auch nicht so dolle. Als das Sony PXW-X70 4K Update kam waren das aber auch erst nur 60Mbps. Die Qualität war aber trotzdem merklich (!!) besser (hatte beide Sachen zur gleichen Zeit).
Die Frage ist immer welcher Encoder da wie arbeitet. Man kann auch mit x264 in Ultrafast Schrott generieren und in Placebo mit der gleichen Datenrate super Sachen ausgeben.
Aus dem nVidia Encoder habe ich trotzdem noch NIX vernünftiges rausgekriegt, aktuell gibt´s auch nix besseres bei nVidia, auch nicht oberhalb der GTX1070.
Bei Intel QuickSync hat man mittlerweile nen ganz gutes Ergebnis erreicht finde ich. Zumindest für ne ordentliche Vorschau taugt das, wenn 100Mbps nicht weh tun kann man das auch fertig verwenden.
Der Coffee Lake wird da wahrscheinlich auch noch mal nen Schritt nach vorne machen, zudem 10bit HEVC in der Wiedergabe beschleunigen. Für mich gibt´s keinen Rechner ohne QuickSync mehr, zumindest nicht in meinem Wirkungsumfeld.
Roland Schulz hat geschrieben: ↑Fr 03 Nov, 2017 11:28
Die Frage ist immer welcher Encoder da wie arbeitet. Man kann auch mit x264 in Ultrafast Schrott generieren und in Placebo mit der gleichen Datenrate super Sachen ausgeben.
ja -- aber selbst noch bei "faster" liefert NVENC, wenn dort entsprechend anspruchsvolles einstellungsprofil gewählt wird, oft objektiv bessere resultate :)
Roland Schulz hat geschrieben: ↑Fr 03 Nov, 2017 15:29
NVENC liefert bessere Ergebnisse ??????
ja -- das ist ohnehin den meisten aktuelleren vergleichen, die an die sache mit ssim/psnr messungen herangehen, zu entnehmen.
x264 u. x265 haben natürlich in der tat ihre vorzüge und sind auch wirklich ausgesprochen optimiert, um in puncto qualität auch noch das letzte herauszuholen, aber dort, wo es eher um realistische anwendungszenarien bzw. qualitäits- und performanceerwartungen geht, fällt der unterschied in der praxis kaum mehr ins gewicht.
da man im ffmpeg aber ohnehin beides zur verfügung hat, kann hat man die wahl ja ohnehin dem persönlichem geschmack überlassen...
Seit zwei Wochen sind wir hier am testen seit in high Sierra hevc implementiert wurde.
Auch der Vergleich zwischen nvenc und x265 unter Win 10 sind dabei eingeflossen.
Ergebnisse wurden unter den Kollegen auf verschiedenen Sichtgeräten inkl Beamern präsentiert. Selbst h264 dabei miteinbezogen und bewertet.
Unter Windows sind wir bei nvenc gelandet und unter OS X bei hevc RF20 fast Decode Single pass superfast - medium
2pass RF<20 brachte im Bewegtbild keine nennenswerten Vorteil im Ergebnis,eventuell beim peeping was aber nicht der Hintergrund war.
Sehr gut auch der QuickTime Encoder der aber erst ab kabylake aufwärts 8bit und 10bit unter QS codieren kann.
Auf CPUs älterer und ohne igpu funktioniert es nur über die Software Codierung auf der CPU in 10bit und das ist extremst langsam.
Zuletzt geändert von motiongroup am Fr 03 Nov, 2017 18:31, insgesamt 1-mal geändert.
Roland Schulz hat geschrieben: ↑Fr 03 Nov, 2017 15:29
NVENC liefert bessere Ergebnisse ??????
ja -- das ist ohnehin den meisten aktuelleren vergleichen, die an die sache mit ssim/psnr messungen herangehen, zu entnehmen.
...bisher dachte ich immer Du hättest Plan ;-)!
Also ich habe selbst Vergleiche gemacht und viel gelesen. Ich habe noch an keiner Stelle feststellen können das nvenc nur annähernd an x264/265 rankommt. Da würde ich bei H.264 maximal QuickSync als halbwegs brauchbar ansehen...
Roland Schulz hat geschrieben: ↑Fr 03 Nov, 2017 18:19
Also ich habe selbst Vergleiche gemacht und viel gelesen. Ich habe noch an keiner Stelle feststellen können das nvenc nur annähernd an x264/265 rankommt. Da würde ich bei H.264 maximal QuickSync als halbwegs brauchbar ansehen...
das sind löeider nur die vorurteile, die dazu immer wieder zu hören sind, trotzdem entsprechen sie leider nicht ganz der wahrheit...
wobei es natürlich eine ziemlich komplizierte sache ist, die sich nicht ganz so einfach entscheiden lässt...
hier jedenfalls ein paar hinweise, die dir evtl. auf die sprünge helfen könnten:
...gemischte Aussagen, die "alte" nVidia Werbung findet natürlich raus dass nvenc besser als x264 ist. Die theoretischen Tests bei OBS finden das ebenfalls raus, die praktische Beurteilung sieht x264 vorne!
Mach mal eigene Tests, ich habe die gemacht und da ist nvenc bzgl. der erriechbaren Qualität das Schlusslicht hinter nem alten Skylake Quicksync und x264 - wobei x264 natürlich deutlich langsamer zu Werke geht.
Für Echtzeitverarbeitung mag nvenc neben QuickSync ne Alternative sein, wenn es "mir" auf Qualität ankommt NICHT!!
Roland Schulz hat geschrieben: ↑Fr 03 Nov, 2017 19:24
Mach mal eigene Tests, ich habe die gemacht und da ist nvenc bzgl. der erriechbaren Qualität das Schlusslicht hinter nem alten Skylake Quicksync und x264 - wobei x264 natürlich deutlich langsamer zu Werke geht.
das problem bei den meisten derartigen praktischen vergleichen liegt darin, dass zwar x264 ganz selbstverständlich mit allen verfügbaren optimierungsoptionen genutzt wird, nvenc dagegen aber meist nur mit recht unzureichenden primitiven einstellungen. da kommt dann natürlich nur genau das raus, was du offenbar sehen willst...
(im dritten der oben genannten links wird das ohnehin recht deutlich hervorgehoben bzw. demonstriert.)
ps: weil du das alter der nvidia-folien kritisiert hast, hier etwas neueres: http://on-demand.gputechconf.com/gtc/20 ... logies.pdf -- in dem fall speziell die seite 48 -- wobei die anderen ffmpeg-workflow spezifischen infos fast noch nützlicher sind...
Ich habe noch mal ein paar Tests gemacht, jeweils HEVC bei 100Mbps in 10bit.
x264/5 lief dabei auf "Medium", nvenc auf "Anschlag", vbr_hq incl. spatial AQ, 2pass (nimmt der Encoder an, ob´s überhaupt funktioniert da streiten sich die Geister) und lookahead (50). Den H.264 nvenc habe ich nicht verglichen da hier keine 10bit möglich sind.
Ohne Frage ist die Geschwindigkeit vom nvenc im Vergleich ABSOLUT BEEINDRUCKEND und ja, die Qualität hat zugelegt, mittlerweile durchaus brauchbar!!
An die Qualität von x264/5 kommt der nvenc meiner Pascal aber dennoch nicht dran. Was auch interessant ist dass nvenc bei einem 25p auf 50p Video zwei identisch aufeinanderfolgende Frames aus dem HQX unterschiedlich abbildet, x264/5 da jeweils die exakt gleiche Abbildung zeigt.
Vergleiche wurden mit "anspruchsvollem Material", 4K, Boote auf rauher Wasseroberfläche bei mehreren, identischen Standbildern in 200% Zoom gemacht.
Aktuell muss ich meine vorherige Aussage aber revidieren das x265 x264 schlägt, da muss irgendwie der Handbrake integrierte x264 Encoder ne Macke gehabt haben - x264 liegt einfach näher am Original, zeigt nach wie vor das beste Ergebnis mit den jeweils aktuellsten Encodern.
Das Problem ist nur dass eine GTX1070/1060 10bit H.264 kaum mehr wiedergeben kann, 10bit HEVC dagegen schon.
Roland Schulz hat geschrieben: ↑Sa 04 Nov, 2017 00:05Was auch interessant ist dass nvenc bei einem 25p auf 50p Video zwei identisch aufeinanderfolgende Frames aus dem HQX unterschiedlich abbildet, x264/5 da jeweils die exakt gleiche Abbildung zeigt.
hast du in beiden fällen all-intra bzw. eine gop length=1 verwendet?
Roland Schulz hat geschrieben: ↑Sa 04 Nov, 2017 00:05
Aktuell muss ich meine vorherige Aussage aber revidieren das x265 x264 schlägt, da muss irgendwie der Handbrake integrierte x264 Encoder ne Macke gehabt haben - x264 liegt einfach näher am Original, zeigt nach wie vor das beste Ergebnis mit den jeweils aktuellsten Encodern.
das hängt immer auch von der vorhandenen ziel- bzw. aufzeichnungsbandbreite ab. wenn es diesbezüglich keine großen einschränkungen gibt, kann man natürlich auch mit älteren und einfacheren mitteln oft recht gute resultate erzielen.
Roland Schulz hat geschrieben: ↑Sa 04 Nov, 2017 00:05
Das Problem ist nur dass eine GTX1070/1060 10bit H.264 kaum mehr wiedergeben kann, 10bit HEVC dagegen schon.
ja -- die 10bit kompatiblität und die unterstützung aller gebräuchlichen farbsubsampling-varianten, sehe ich auch als ganz entscheidendes kriterium.
ich würde darum auch VP9 in die vergleiche einbeziehen, weil es in dieser hinsicht eine recht brauchbare alternative darstellt, die auf allen plattformen [wenn man von ein paar apple browsern absieht] mittlerweile sehr gut unterstützt wird.
Moin mash,
nein, ich habe bei "nur" 100Mbps "natürlich" kein All-Intra gewählt sondern die GOP Länge auf 250 Frames beschränkt. Nichts desto trotz, die x-Encoder stellen fest dass es sich um zwei aufinanderfolgende, identische Bilder handelt.
VP9 kommt für mich nicht in Frage da das im Dunstkreis kaum ein TV direkt decodieren werden kann.
Aber, ich gebe offen zu dass ich doch sehr überrascht bin von dem Ergebnis, welches nvenc aktuell abliefert, wirklich!!
Wenn man mit der Lupe reinguckt gewinnt x264/x265 nach wie vor bei der Qualität, aber das steht in absolut keinem Verhältnis zu dem was nvenc bei der Geschwindigkeit liefert, so ein Müll wie "früher" ist das jetzt nicht mehr, das kann man nicht mehr mit den Maxwell Ergebnissen vergleichen. Immerhin reden wir über einen Boost von ~Faktor 8 auf nem 6770k@4,7GHz!!
Ob man die Details die in Bewegung beeinträchtigt sind überhaupt feststellt bezweifele selbst ich, in stehenden Bildern ist das alles ziemlich irrelevant! Ich sehe auch überhaupt kein i-Frame Geflatter usw. mehr!
Keine Ahnung wie das bei geringen Bitraten ausgehen würde (kein Vergleich gemacht), aber bei den bei mir üblichen, hohen Bitraten sehe "ich" tatsächlich jetzt keine Rechtfertigung für x264/265 mehr!
Sehr gut und Danke mash_gh4, da musste ich einfach nochmal hingucken!!
Bin mal gespannt was Volta ggf. demnächst leisten wird...
Roland Schulz hat geschrieben: ↑Sa 04 Nov, 2017 09:49
nein, ich habe bei "nur" 100Mbps "natürlich" kein All-Intra gewählt sondern die GOP Länge auf 250 Frames beschränkt. Nichts desto trotz, die x-Encoder stellen fest dass es sich um zwei aufeinanderfolgende, identische Bilder handelt.
naja -- ich würde in diesem zusammenhang ja eher die gegebene form des ausgangsmaterials kritisieren.
derartige redundannz durch verdoppelung der einzelbilder wirkt auf mich eher kontraproduktiv bzw. nicht wirklich sinnvoll.
Roland Schulz hat geschrieben: ↑Sa 04 Nov, 2017 09:49
VP9 kommt für mich nicht in Frage da das im Dunstkreis kaum ein TV direkt decodieren werden kann.
schau dir einmal folgende liste an: http://wiki.webmproject.org/hardware/socs
mittlerweile können die meisten smart-TVs vp9 decodieren. und im gegensatz zu h.26x gibt's dafür auch relativ einfach zugängliche hardwarebeschleunigungs referenzimplementationen für typische consumer hardware.
Roland Schulz hat geschrieben: ↑Sa 04 Nov, 2017 09:49
Aber, ich gebe offen zu, dass ich doch sehr überrascht bin von dem Ergebnis, welches nvenc aktuell abliefert, wirklich!!
Wenn man mit der Lupe reinguckt gewinnt x264/x265 nach wie vor bei der Qualität, aber das steht in absolut keinem Verhältnis zu dem was nvenc bei der Geschwindigkeit liefert, so ein Müll wie "früher" ist das jetzt nicht mehr, das kann man nicht mehr mit den Maxwell Ergebnissen vergleichen. Immerhin reden wir über einen Boost von ~Faktor 8 auf nem 6770k@4,7GHz!!
ganz wichtig in diesem zusammenhang ist auch der umstand, dass nvenc vor allem auch ein paralleles komprimieren für unterschiedliche zielbandbreiten in ausgesprochen effizienter weise erlaubt!
dort, wo man derartige codecs nämlich gewöhnlich braucht, für distribution im netz, ist eine derartige auslieferung in form eines ganzen bündels von streams unterschiedlicher qualität bzw. adaptiver auswahl, je nach tatsächlich verfügbarer übertragungsbandbandbreite (HLS/DASH), nämlich die einzig wirklich befriedigende und heute durchwegs übliche herangehensweise.
Zuletzt geändert von mash_gh4 am Sa 04 Nov, 2017 16:58, insgesamt 2-mal geändert.
25p Video in 50p Projekte zu bringen macht Sinn wenn man Zeitraffer einbringen und/oder mit 50p Material mischen will, von daher alles gut.
Ebenso könnte man in Frage stellen warum
man 8bit Material unbedingt in einen 10bit Export bringen will - weil auch das nach dem Graden Sinn macht, das "grobe" 8bit Raster nach Transformation in einem "feinen" 10bit Raster landet, "besser" den neuen transformierten Wert finden und die ursprünglichen Abstufungen nicht noch mehr Quantisierungsfehler erleiden, 8bit immerhin ~8bit bleibt und nicht noch schlechter wird.
Gegen VP9 würde nach der letzten Befürwortung von nvenc o.ä. sprechen, dass das derzeit kaum ein Hardwareencoder macht.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
