CRF vs ICQ

[magnexx]

Hallo zusammen,
bis heute, wenn es darum ging eine Bluray in h265 zu encode, habe ich immer BDRebuilder angeschmissen und CRF16 eingestellt. Ich konnte mich drauf verlassen, dass BDRebuilder mit CRF16 eine sehr gute Qualität bei geringst möglicher Dateigröße liefert. Mit geringster meine ich, dass das Video manchmal eine extrem niedrige Dateigröße hatte und manchmal aber kaum einen Unterschied zum original Video hatte. Die Qualität ist bevorzugt und die resultierende Dateigröße ist halt immer unterschiedlich.

Weil BDRebuilder nur mit CPU oder Nvidea das encode durchführen kann, bin ich jetzt auf StaxRip und VidCoder umgestiegen. Hier kann ich auch mit meiner AMD Grafikkarte oder mit der iGPU von Intel encoden lassen. Allerdings kann ich kein CRF16 mehr einstellen. Als Alternative habe ich ICQ. ICQ soll wie CRF auch eine Bitratenkontrollmethode sein. Beide behalten eine konstante Videoqualität, indem sie die Bitrate automatisch an das was möglich ist (um Dateigröße einzusparen) anpassen. Mehr oder weniger konnte ich mit mehreren Test-Videos herausfinden, dass ein ICQ 16 von der Qualität und Dateigröße einem CRF 16 entspricht.

Allerdings ist es mir jetzt 2 mal schon passiert, dass bei ICQ die Dateigrößer vom encoding größer ist, als die vom original File. Wie geht das? Das beunruhigt mich jetzt. Das heißt ICQ holt nicht die beste Qualität bei geringster Dateigröße raus? Woher soll ich wissen, bei welchen Eingangsmaterial ich welchen ICQ Wert einstellen kann, soll? Bei CRF war das immer so eine sichere Sache.

Wie macht Ihr das?

Grüße

 

[_anonymous0815_]

Meine Empfehlung für den Anfang ist Handbrake, bietet alles und hat eine einsteigerfreundliche GUI. Bei Erfahrung dann Staxrip.

Zu der Frage:

16 CRF ist mMn erst mal völlig overpowered, manche nehmen 20 oder 22RF und sehen damit keinen Unterschied, ich nehme 18RF um auf Nummer sicher zu gehen, was auch schon eigentlich viel zu viel ist.

Einen Modus für gleichbleibende Qualität gibt es auch für GPU-Encoding, ABER: Software-Encoding über die CPU ist in Sachen Qualität unangefochten der Sieger, dafür ist GPU-Encoding deutlich schneller, aber nicht unbedingt kleiner. Falls es Dir also wirklich um Qualität und/oder Größe geht, dann lieber CPU-Encoding nehmen.

 

[Amaoto]

Das heißt ICQ holt nicht die beste Qualität bei geringster Dateigröße raus?

ICQ wahrscheinlich schon, aber AMDs Encoder nicht, d.h. du bekommst zwar anscheinend die kleinste Dateigröße, die für die gewählte Qualität mit VCE möglich ist, das bedeutet aber trotzdem, dass die Datei größer sein muss, als z.B. mit x265 kodiert.

AMD unterstützt angeblich keine B-Frames. Das drückt die Effizienz natürlich auch.
https://codecalamity.com/hardware-encoding-4k-hdr10-videos/

 

[magnexx]

Meine Empfehlung für den Anfang ist Handbrake,

Mit Handbrake habe ich das Problem, dass die Videos zu einem dauer Green-Screen werden, sobald ich in 10bit codiere. Habe dann VidCoder genommen (was übrigens auch mit Handbrake kodiert) und hier funktioniert es. Es gibt auch nicht viele Einstellungsmöglichkeiten und ich finde es von der GUI auch ziemlich selbsterklärend.

16 CRF ist mMn erst mal völlig overpowered, manche nehmen 20 oder 22RF und sehen damit keinen Unterschied, ich nehme 18RF um auf Nummer sicher zu gehen, was auch schon eigentlich viel zu viel ist.

Qualität steht an erster stelle. Ich habe mal ein paar Test durchgeführt und encode Frame zu original Frame verglichen und mit CRF16 habe ich mich erst zufrieden gegeben.

Einen Modus für gleichbleibende Qualität gibt es auch für GPU-Encoding

Das wäre welcher? ICQ?

ABER: Software-Encoding über die CPU ist in Sachen Qualität unangefochten der Sieger, dafür ist GPU-Encoding deutlich schneller, aber nicht unbedingt kleiner.

Mit BDRebuilder habe ich bis zu 24h Stunden für ein encode gebraucht, jetzt sind es mit VidCoder und QSVEnc (Intel) nur noch ca. 50 Minuten. Dafür nehme ich gerne eine größere Dateigröße in Kauf.

ICQ wahrscheinlich schon, aber AMDs Encoder nicht

VCE verwende ich nicht. Mit AMD geht weder CRF, noch ICQ. Ein CQP Wert muss eingestellt werden und in Sachen Qualität/Dateigröße, bin ich mit dem QSV (Intel) und ICQ besser bedient. Problem ist halt nur, dass manchmal die Dateigröße größer wird und dann kann ich mir ein Encode sparen, denn besser als das Original wird es sowieso nicht.

 

[_anonymous0815_]

Das wäre welcher? ICQ?

Vermutlich, kenne nicht jede Abkürzung davon. Aber Intel Quicksync (QSV) und Nvidia NVEnc bieten solche Modis an. Die beiden sollten außerdem keine Probleme mit HDR, bzw. 10 Bit Content haben, ist mir mit Handbrake auch noch nicht untergekommen. Mit gleichbleibender Qualität meine ich aber folgendes:

Du hast über das Video eine durchgängig ähnliche Qualität pro Frame, was die Kompression angeht, d.h. dass die Bitrate variabel bleibt. Dabei sind actionreiche Szenen mit hoher Bitrate versehen. Z.B. 45 MBit/s Peak und ruhige Szenen ohne viel Grain vielleicht nur mit 5 MBit/s Peak. Das betrifft nicht die allgemeine Qualität des Frames.

Bei CPU Encoding hast Du das beste Ergebnis, bei GPU Encoding kann es zu Klötzchenbildung kommen, das liegt an der Hardwarebeschleunigung, das sind dann richtige Schaltungen, die diese Aufgabe energieeffizient übernehmen, dabei treffen sie aber nicht immer die qualitativ hochwertigsten "Entscheidungen" und so kommt es zu Artefakten. Du wirst am CPU Encoding nicht vorbeikommen, wenn Du erst mit RF 16 zufrieden bist. Ich lehne mich mal aus dem Fenster und sage: Der Unterschied zwischen RF 16 und RF 20 ist geringer als der Unterschied von CPU und GPU Encoding auf einer vergleichbaren Stufe. Selbst wenn Du die maximale Qualität bei GPU Encoding auswählst, wird das Bild nicht an das CPU Encoding heran reichen und das Ausgabematerial ist dann womöglich sogar größer! als das Eingangsmaterial.

 

[Angel Of Death]

Allerdings ist es mir jetzt 2 mal schon passiert, dass bei ICQ die Dateigrößer vom encoding größer ist, als die vom original File.

Sicher, dass das nicht am Filmmaterial lag? Bei niedrigem CRF und viel Filmkorn explodiert die Größe auch gern mal. Es gibt einfach nicht "die Einstellung" bzw. den immer selben CRF-Wert, bei dem jedes Video eine super Qualität hat und eine minimale Größe.
Ansonsten gibt es so weit ich weiß bei AMD VCE oder NVENC kein Constant Rate Facor, wenn ICQ für dich keine zufriedenstellenden Ergebnisse liefert, wirst du dich wohl mit CQP begnügen müssen. Ist ja auch Constant Quality und ähnlich wie CRF.

Siehe hier. Zweiter Vergleich
https://slhck.info/video/2017/03/01/rate-control.html

 

[YukoTama]

Moin, ich gebe auch mal meinen Senf dazu ich mache das seit vielen Jahren und habe locker 5k codings hinter mich gebracht.
Eines möchte ich direkt vorweg nehmen, es gibt "DAS eine Setting" nicht. Jede Quelle, jeder Film, jeder Clip ist anders und müsste für das Optimum an Qualität zu Filesize mehrere Selektierungsprozesse mit Samples durchhgehen. Für meine absoluten Favorites läuft es auch genau so..
Des weiteren beschränke ich hier alle meine Aussgenbezüglich Bitrate und Filesize immer auf die REINE VIDEOSPUR, da jeder andere präferenzen mit Ton/Multilanguage usw hat...mir reicht 640kbit DE/ENG...andere wollen Dolby Atmos usw.
Ich nehme das File, trenne es in 30-60 Sekunden Schnipsel, suche mir die Bitreichsten Szenen heraus und lasse diese durch mehrere Settings laufen bis es mir zusagt. Die Ergebnisse sind zum Teil sehr unterschiedlich. Natürlich habe ich auch verallgemeinerte Settings für standard Kram der einfach klein und gut ansehbar gemacht werden soll.
hier erstmal meine Meinung zu einigen Aussagen

Habe dann VidCoder genommen (was übrigens auch mit Handbrake kodiert) und hier funktioniert es.

Handbrake ist nur eine GUI für FFMPEG usw.."Handbrake" selbst codiert gar nix sondern greift wie alle anderen Encoder auf die Vielzahl an verfügbaren zurück. Es ist wichtig den passenden Encoder zu finden und diesen auch zwingend aktuell zu halten da hier immer wieder Updates und Patches für Performance, Hardware und Effizienz rauskommen.

Qualität steht an erster stelle. Ich habe mal ein paar Test durchgeführt und encode Frame zu original Frame verglichen und mit CRF16 habe ich mich erst zufrieden gegeben.

Jeder hat seine eigenen Präferenzen...wenn Qualität an der absolut anangefochtenen ersten Stelle steht sollte man vllt einfach die Bluray als Originalrip stehen lassen Mehr geht einfach nicht. Ich persönlich halte 16 auch für Overkill, meine Präferenz und Sweetspot (mein ganz persönlicher) ist rf20/qp20 usw. Ich streite mich damit schon lange mit anonymus0815 in gepflegter Rivalität. Ich habe unzähliche Stunden mit Frame zu Frame Vergleichen an unterschiedlichsten Displays verbracht, für mich funktioniert es. Wir wissen auch genau worauf wir gucken müssen und haben einen direkten Vergleich, wenn ich Bekannten oder Freunden das Werk präsentiere checken die bis RF24-28 gar nichts...

Einen Modus für gleichbleibende Qualität gibt es auch für GPU-Encoding

Ja den gibt es nahezu überallund überall heißt es ein klein wenig anders...CP Constant Quality usw..ist es bei Staxrip meine ich wird bestimmt manuals oder Foren zu den jeweiligen encodern geben

Mit BDRebuilder habe ich bis zu 24h Stunden für ein encode gebraucht, jetzt sind es mit VidCoder und QSVEnc (Intel) nur noch ca. 50 Minuten. Dafür nehme ich gerne eine größere Dateigröße in Kauf.

Da fehlen jetzt so unzählig viele Faktoren um 24h irgendwie als Gut oder schlecht einordnen zu können...
Mit einem Intel Celeron 265 auf dem Setting Slow für 2h 1080p Material wären 24h eine verdammt gute Zeit Auf einem 13900k auf 60W limitiert wäre es eine brachial mieserable Zeit..hier spielt soviel eine Rolle:
welcher Encoder, welche Hardware, Cliplänge, Update/Versionsnummer, Inputquelle, Filter?, HW Kompatibilität...
Also 24hh für eine Bluray auf 265 in rf20 hat mal 24h auf meinem 12 Jahre alten Laptop gedauert wo 265 gerade frisch raus kam

Aktuell liege ich bei 265/slow/rf20/nofilter/1080p Raw Input-90Min Länge/ bei 22-36FPS das sind 45Min-2h mit einem 13900K auf 125W Limitiert.

Grainfilter usw lassen es exorbitant ansteigen.

VCE verwende ich nicht. Mit AMD geht weder CRF, noch ICQ. Ein CQP Wert muss eingestellt werden und in Sachen Qualität/Dateigröße, bin ich mit dem QSV (Intel) und ICQ besser bedient. Problem ist halt nur, dass manchmal die Dateigröße größer wird und dann kann ich mir ein Encode sparen, denn besser als das Original wird es sowieso nicht.

Intel QS liefert mittlerweile wirklich gut ab, auch hier habe ich vor kurzem mit anonymus0815 eine sehr ausführliche konstruktive Diskussion geführt und wir sind uns nachweislich einig geworden das QS und GPU Encode absolut unentbehrlich sind wenn sehr viel oder sehr schnell encodiert werden muss.
Die Qualität haben wir mit RF18 1080p Quellmaterial antreten lassen, ich kann mal die Bilder hochladen und ihr werdet sehen was ich meine.




Man erkennt glaube ich sofort die Blöckenbildung bei sehr schnellen Bewegungen, gleiches Spiel mit sehr feinen Strukturen oder Sachen wie Nebel und Feuer
(Der Endgegner für jeden Encoder, schummriges Licht, Nebel oder Rauchschwaden oder schäumendes Wasser und Flüsse)

Nicht umsonst wird bei Plattformen oder dem Handy auf GPU Kerne zurückgegriffen da hier einfach eine um den Fakktor 10-20 schnellere Verarbeitung möglich ist für einen im Alltag vernachlässigbaren Qualitätsverlust...fürs Heimkino mit etwas pedantischen Menschen aber ein absolutes Nogo m.M.

Schnell und Top Qualität sind einfach Dinge die beißen sich wie im echten Leben...Billig und schnell ist eben nicht und wer weiß worauf er gucken muss wird, wird den Unterschied sofort erkennen...meine Frau und Freunde eben nicht..wer damit zurechtkommt für den ist es eine absolut denkbare Alternative

Ich lehne mich mal aus dem Fenster und sage: Der Unterschied zwischen RF 16 und RF 20 ist geringer als der Unterschied von CPU und GPU Encoding auf einer vergleichbaren Stufe. Selbst wenn Du die maximale Qualität bei GPU Encoding auswählst, wird das Bild nicht an das CPU Encoding heran reichen und das Ausgabematerial ist dann womöglich sogar größer! als das Eingangsmaterial.

Ich lehne mich genauso weit aus dem Fenster und hatte den Fall Schon einige male mit zb: Alien (1979) wo der Output mit GPU Encoding ohne Grainfilter größer war als der Input...weil es so aggressiver Grain ist, das jeder Frame ein in sich komplett neues Bild ist mit sovielen unterschiedlichen Bildinformationen. Wer Staxrip verwendet und mal auf die Bitrate geachtet hat beim Intro von "HBO" (zb Game of Thrones...dieses weiße Bildrauschen) da schießt die Bitrate einfach komplett hoch bis die Szene vorbei ist. Wie gesagt wenn mir am Quellmaterial etwas liegt oder mir der Output qualitätiv wichtig ist...erstelle ich kurze Samples und jage diese durch bestimmt 10 Settings von rf18-24 um ein bestmögliches Verhältnis für mich zu gewährleisten.

Sicher, dass das nicht am Filmmaterial lag? Bei niedrigem CRF und viel Filmkorn explodiert die Größe auch gern mal. Es gibt einfach nicht "die Einstellung" bzw. den immer selben CRF-Wert, bei dem jedes Video eine super Qualität hat und eine minimale Größe.

Absolut, bei ganz krassen Fällen von Grain kommen bei mir sogar externe Denoiser zum Einsatz..also einige Files durchlaufenn zum Teil mehrere Etappen. Weil mich richtig massiver Grain einfach stört, der mittlerweile sogar zum Teil digital eingefügt wird und furchtbar aussieht, anders als damaliger natürliches Korn.

Ja also soviel dazu, fröhliches coden!

 

[magnexx]

Bei CPU Encoding hast Du das beste Ergebnis, bei GPU Encoding kann es zu Klötzchenbildung kommen,

Davon habe ich schon gehört, konnte aber bei mir aber nichts finden. Auch schnelle Szenen sind absolut mit dem CPU encoding vergleichbar. Das einzige was ich festgestellt habe z. B. Vergleich CPU CRF16 gegen GPU ICQ16, etwas bessere Qualität und geringere Dateigröße auf die CPU Seite. Also aufjedenfall effektiver. Für diese Effizienz aber 25 x mehr Zeit für das Encoding zu investieren, lohnt sich nicht. So extrem waren jetzt die Unterscheide nicht.

Der Unterschied zwischen RF 16 und RF 20 ist geringer als der Unterschied von CPU und GPU Encoding auf einer vergleichbaren Stufe.

Das kann ich echt nicht bestätigen. Ich werde mal ein paar Screenshots von CRF16, CRF20 und ICQ16 anfertigen.

Es gibt einfach nicht "die Einstellung" bzw. den immer selben CRF-Wert, bei dem jedes Video eine super Qualität hat und eine minimale Größe.

Bei CRF hatte ich aber tatsächlich dieses Gefühl. CRF16 hat immer gepasst. Körniger Film wurde halt groß und Filme mit kaum Körnung und vielen digitale Inhalte wurden extrem niedrig - bei gleichbleibender Qualität -. Mit GPU und ICQ scheint es aber wirklich so zu sein. Am besten vorher ein kurzen Ausschnitt - 1min oder so - herausschneiden und mit ICQ herumexperimentieren, bis der richtige Wert für den Film gefunden wurde.

wirst du dich wohl mit CQP begnügen müssen.

Stimmt das kann ich noch ausprobieren. Ich hatte halt mit VCE schlechtere Ergebnisse als mit QSV, daher hatte ich AMD ausgeschlossen. Mit QSV kann ich aber nur ICQ einstellen und kein CQP. Ich versuch es mal erneut bei einem (Problem)-Film, mal gucken wie sich AMD schlägt.

Handbrake ist nur eine GUI für FFMPEG usw.."Handbrake" selbst codiert gar nix sondern greift wie alle anderen Encoder auf die Vielzahl an verfügbaren zurück.

Danke für den Ausführlichen Beitrag.

Damit meint eich, MediaInfo spuckt bei Handbrake unter "Writing application" HandBrake raus. Verwende ich VidCoder, so ist unter Writing application wieder HandBrake hinterlegt. Während ich aber bei Handbrake selber Probleme habe, sobald ich auf 10bit einstelle und VidCoder mit 10bit keine Probleme macht.

Jeder hat seine eigenen Präferenzen...wenn Qualität an der absolut anangefochtenen ersten Stelle steht sollte man vllt einfach die Bluray als Originalrip stehen lassen

Stimmt und soweit war ich schon, aber warum nicht das ganze optimieren? Wie von vielen schon erwähnt ist CRF16 Overkill, ich habe also eine perfekte Qualität - vergleichbar mit dem remux - und spare an Speicherplatz.

Ich nehme das File, trenne es in 30-60 Sekunden Schnipsel, suche mir die Bitreichsten Szenen heraus und lasse diese durch mehrere Settings laufen bis es mir zusagt.

So habe ich es vor langer Zeit gemacht. Bei sehr bitreichen Szenen, viel Bewegung und vor allem mit Nebel, hat für mich CRF16 gute Ergebnisse geliefert. Ohne jeden Film aber jetzt zu analysieren, ist CRF16 zu Standard geworden und ich bin sicher, dass selbst schwierige Szenen gut encodiert werden.

Da fehlen jetzt so unzählig viele Faktoren

Also 24h, mit BD-Rebuilder: Standard-Länge-Film zwischen 1:30 - 2:00h. Starke Körnung, 2160p, MKV, HEVC, No_resize, intact Audio, CRF16 bei Automatic Quality Settings. CPU i3-12100

 

[Bob.Dig]

bei ganz krassen Fällen von Grain kommen bei mir sogar externe Denoiser zum Einsatz..

Inwieweit entfernen die Encoder wie x265 selbst den Grain, wenn ich einen höheren CRF Value wähle? Denn auf Grain kann ich komplett verzichten. Nutze aber aktuell Filter dagegen, die eigentlich zu viel Rechenzeit verlangen.

 

[_anonymous0815_]

Inwieweit entfernen die Encoder wie x265 selbst den Grain, wenn ich einen höheren CRF Value wähle? Denn auf Grain kann ich komplett verzichten. Nutze aber aktuell Filter dagegen, die eigentlich zu viel Rechenzeit verlangen.

Wäre mir nicht bekannt, dass Grain durch normales Encoding gefiltert wird. Eher wieder Artefaktbildung.

@YukoTama und ich verwenden bei viel Grain Topaz Video AI, welche eine Einstellung mit sehr gutem Denoising hat, welche auf der GPU berechnet wird. Dieser Weg hat aber viele Nachteile. Erst mal kostet die Software ordentlich Geld und dann enkodieren wir in zwei Durchgängen. Erst GPU Encoding in Apple Pro Res 422HQ, da kommt bei Filmen eine File mit locker 150-250 GiB raus und das enkodieren wir dann erneut per CPU. Also Zeitersparnis gleich null, viel Zeit und Strom + Geld für Software.

Ansonsten bietet Staxrip mit Temporal Degrain 2 eine reine CPU-Alternative, welche aber nicht auf Multicore läuft und maximal einen Kern nutzt --> Extrem lange Encodingdauer.

 

[Bob.Dig]

Ansonsten bietet Staxrip mit Temporal Degrain 2 eine reine CPU-Alternative, welche aber nicht auf Multicore läuft und maximal einen Kern nutzt --> Extrem lange Encodingdauer.

Sicher? Haste es mal mit VapourSynth statt AviSynth in Stax probiert?

Mir gefällt MCTemporalDenoise recht gut, aber ich hab auch nichts für noise übrig, egal wie sie sich schimpft.

 

[magnexx]

So habe dann mal ein paar Tests gemacht. Intel ist besser als AMD und wie erwartet ist die CPU mit CRF am besten. ICQ16 macht mich nicht mehr zufrieden. ICQ13 passt besser. Problem ist nur, diese Erkenntnis passt nur zu diesem Stück Video und jedes Mal eine Probe machen zu müssen, habe ich keine Lust drauf. Das alles bringt mich immer mehr durcheinander

Testfile / Remux ohne Tonspur, Dauer 47sek.:
File size : 510 MiB
Overall bit rate : 90.6 Mb/s


Encoded, CPU 10bit, QSV decodierung, qualität mittelmäßig, CRF16, 6.55min:
File size : 116 MiB
Overall bit rate : 20.6 Mb/s


Encoded, CPU 10bit, QSV decodierung, qualität mittelmäßig, CRF20, 05.06min:
File size : 58.8 MiB
Overall bit rate : 10.5 Mb/s


Encoded, QSV Intel 10bit, QSV decodierung, max. qualität, ICQ13, 0.30min:
File size : 233 MiB
Overall bit rate : 41.5 Mb/s


Encoded, QSV Intel 10bit, QSV decodierung, max. qualität, ICQ16, 0.29min:
File size : 143 MiB
Overall bit rate : 25.5 Mb/s


Encoded, VCE AMD 10bit, QSV decodierung, max. qualität, CQ25, 0.27min)
File size : 139 MiB
Overall bit rate : 24.8 Mb/s

Und hier die Bilder:

EDIT:
Also wenn man sich die Bilder hier im Forum anguckt, dann bemerkt man nicht viel Unterscheid. Wenn ich sie aber in Vollbild auf meinem 34Zoll Monitor öffne, dann sehe ich viel mehr Unterscheid.

 

[YukoTama]

Also wenn man sich die Bilder hier im Forum anguckt, dann bemerkt man nicht viel Unterscheid. Wenn ich sie aber in Vollbild auf meinem 34Zoll Monitor öffne, dann sehe ich viel mehr Unterscheid.

Ja ich wollte gerade sagen, ich sehe beim schnellen Wechseln der FOrumsbilder nahezu gar nichts an Unterschied. Bis auf die sich leicht veränderne Körnung. Das Sample ist ein gutes Beispiel für Denoiser, hier könnte man nochmal die Filesize halbieren, du kannst ja gerne mal dein Sample zur Verfügung stellen und schauen was andere rausholen Ich würde es probieren wollen.

PS: natürlich nur rein hypothetisch über eine pn oder so...wir wollen ja keine Urheberrechtsgeschützten Inhalte verbreiten...In Minecraft würde man es so machen glaube

 

[_anonymous0815_]

Ich sehe da überraschenderweise auch keinerlei Unterschied, was mich schon ein bisschen wundert, da alles wirklich nahezu gleich wirkt. Aber vielen Dank für die Mühe, finds immer wieder gut, sich mit Gleichgesinnten auszutauschen!

 

[YukoTama]

und du bist um eine ganze Ecke pedantischer als ich was angeht xD

 

[x264.exe]

Nur mal so am Rande. Der Screenshotvergleich ist in der Regel trügerisch und verfälscht die Einschätzung über die Qualität des Encodes, wenn man keine Info darüber hat, um welche Frametyp es sich handelt.
Die Softwareplayer springen bei Nutzung der Seekbar zum nächsten Keyframe, also I-frame. Speichert ihr jetzt den Frame als Bild, vergleicht ihr mit hoher Wahrscheinlichkeit I-frames untereinander.

I-frames sind immer Frames mit der höchsten Qualität in einem Encode. Sinnvoller und aussagekräftiger ist es also B-frames untereinander zu vergleichen. Nun zeigen VLC, MPV oder MPC-HC den jeweiligen Frametyp leider nicht an und man muss sich mit anderer Software behelfen.

Dazu nimmt man am Besten AvsPmod und das FFmpegSource Plugin (ffms2)
Dabei geht man wie folgt vor:

• Installieren von Avisynth+
• Entspacken der Dateien FFMS2.avsi, ffmsindex.exe, ffms2.dll und ffms2.lib aus FFMS2 in den Pluginordner von Avisynth+
• Downloaden von AvsPmod (ist portable)

Nach dem Starten von AvsPmod könnt ihr euch eine neuen Tab generieren und die Videodatei mit folgendem Script (siehe unten) laden. Man kann sich bequem mehrere Tabs erstellen und mittels Mausrad oder den Ziffern auf der Tastatur zwischen den Videos hin- und herspringen und im Reiter Video den Frame auch als Bild speichern.

x264=FFVIDEOSOURCE("Dateipfad_Video.mkv").ffinfo(framenum=true,frametype=true,cfrtime=false,vfrtime=false,version=false,cropping=false,colorrange=false,colorspace=false,sar=false).subtitle("h.264 20 mbps", x=1900, y=0, align=9)

Interleave(x264)
Crop(0,0,-0,-0)

Die Werte für Codec, Subtitle und Crop natürlich entsprechend anpassen.

 

[magnexx]

hier könnte man nochmal die Filesize halbieren,

ja sicherlich, mit CPU und höchste Qualität geht bestimmt noch deutlich was. Aber mit meiner CPU kann ich das vergessen, wenn schon 47sekunden Videolänge mit der Einstellung "mittelmäßig" knapp 7min gedauert hat.

du kannst ja gerne mal dein Sample zur Verfügung stellen

hab leider schon alles gelöscht, bin aber an einer anderen dran. Szene mit Feuer, Nebel und schwaches Licht. Ich schreibe Dir dann...

I-frames sind immer Frames mit der höchsten Qualität in einem Encode. Sinvoller und aussagekräftiger ist es also B-frames untereinander zu vergleichen.

Das bedeutet, wenn z. B. Encode 1 ein besseres i-frame als Encode 2 hat, dass es nicht aussagekräftig ist, weil Encode 2 dennoch ein besseres b-frame als encode 1 haben könnte? Weil wenn nein, dann habe ich vielleicht nicht die tatsächliche encode Qualität mit meinem MPC-HC vor dem Auge, allerdings würde es dann ausreichen, um nur die encodes untereinander zu vergleichen.

Und wenn doch, dann mache ich mal den Versuch.

mit folgendem Script (siehe unten) laden.

Was genau muss im Skript angepasst werden? Klar, Dateipfand und Dateinamen. Aber da steht z. B. h264, was ist wenn es ein h265 ist? Mit h265 ersetzten? Oder am Ende steht was von "20 mbps" bleibt das so?

 

[x264.exe]

Ich wollte damit ausdrücken, dass man zwischen den I-frames oft nur einen minimalen oder sogar keinen Unterschied sieht und die wirkliche Qualitätsminderung erst sichtbar wird, wenn man sich die B-frames anschaut
Weil sich hier gewundert wurde, dass die Shots alle gleich aussähen.

In deinem Fall x264 zu x265 ändern, ich glaube aber selbst das ist nicht unbedingt nötig. Funktioniert auch so. Das andere ist einfach nur eine Beschriftung.

 

[Bob.Dig]

Kannst auch Avidemux nehmen und dann dort die Bilder speichern.

 

[magnexx]

Kannst auch Avidemux nehmen und dann dort die Bilder speichern.

Ich habe Avidemux installiert und die Bilder gespeichert. Speichert es automatisch in B-Frames oder muss ich das irgendwie auswählen / einstellen?

Die Unterschiede der Bilder von MPC-HC (I-Frames) sind größer als die Unterscheide der Bilder von Avidemux (B-Frames ?). Das widerspricht aber der Aussage von x264.exe:

Ich wollte damit ausdrücken, dass man zwischen den I-frames oft nur einen minimalen oder sogar keinen Unterschied sieht und die wirkliche Qualitätsminderung erst sichtbar wird, wenn man sich die B-frames anschaut

Was cool ist, dass Avidemux die Bilder mit den HDR Infos abspeichert und MPC-HC die Infos entfernt hat.

Anbei der neue Versuch inkl. I Frame Bilder und B Frame Bilder... Die dunkleren Bilder (mit HDR Infos nehme ich an) sind von Avidemux. Die Bilder von Avidemux in PNG (müsste glaube ich verlustfreier als JPEG sein)

(1)-023 (Sample) - Länge 58 Sekunden, 505MB
(1)-023 (Encoded) CPU, QSV Decodierung, h265, 10bit, Qualität mittelmäßig, CRF16 - 07.22min, 118MB
(1)-023 (Encoded) Intel QSV, h265, 10bit, max. Qualität, ICQ16 - 00.35min, 120MB
(1)-023 (Encoded) Intel QSV, h265, 10bit, max. Qualität, ICQ13 - 00.35min, 231MB