wurst10 hat geschrieben: 03.10.2021 09:37:24
Anfang der 2000er
Nette Geschichte aus dem Krieg. Hintergrund war dass in den 90ern alle Codecs auf 1x-DVD-Laufwerkem Player mit Puffern im kiB-Bereich und ähnliches optimiert waren. Hast du eine Bewegung bekommen und die Bitrate gieng liefen deren Puffer leer und der Codec drehte Qualität runter damit der Film nicht ruckelte. Viele Codecs haben das Verhalten auch in die ersten paar Jahre des 21. Jahrhunders geretten obwohl die Puffer deutlich größer wurden.
2pass hat das Problem entschärft indem es vor Bewegungen aktiv die Bitrate runter gedereht hat damit die Puffer maximal voll sind und der Codec etwas länger bei guter Qualität durchhält.
Die Variante wie man das heute löst ist: Dreh die Qualität nicht runter sondern mach die Datei etwas größer, wenn der Film mehr sich mehr bewegt! Die Platte ist schnell genug. Im x264 -crf (constatn rate factor) im nvenc -rc constqp (constant Quantization Parameter.) Das ist am Ende ein Wert durch den du Teilst damit deine Zahlen kleiner werden und besser komprimieren. – Und weil beim Teilen auf ganze Zahlen gerundet wird, geht die Qualität kaputt.) Es gibt seit 20 Jahren keinen Grund mehr nachträglich an dem Faktor zu fummeln.
Nochmal so eine Kuriosität aus der Zeit:
Inverse Telecine
Ohne NTSC material kann ich kein Inverse Telecine machen. Bei 25Hz gibts kein 2:3 Pulldown und schon gar keine 1‰ verlangsamung. PAL kennt allenfalls noch 2:2 pulldown das quasi kostenlos zu deinterlacen ist. Ich weiß nicht, was du machen willst. Ich kann nen Yadif drüber laufen lassen aber das wird stark am Material hängen, wann der merkt, dass er eigentlich nichts machen muss. Nettes Benchmark für die Intelligenz der Software. Und da gewinnt dein CPU-Filter sogar vermutlich einiges. Ich weigere mich aber Benchmarks mit absichtlich fehlerhafter Parameter anzugeben. Das soll ein Benchmark und keine suche nach "Bugs" sein.
mit gleichen Parametern: […] LapSharp
Wenn ich gleiche Parameter anhänge wird der auf meiner 7Jahre alten-Bulldozer CPU encoden. Da ist absehbar, was raus kommt. Ich kann nur
equivalente Parameter nutzen. h.264 und h.265 ist kein Problem. Genau so wenig 2pass h.264 und lustigerweise hat jemand für NVIDIA sogar yadif implementiert. Aber LapSharp findet ich nicht mal mit google was das genau ist. convolution gibt es auf der GPU. Min unsharp kann man eventell was ähnliches bauen.
Deswegen hatte ich ja gemeint lass mal zum vergleichen weg und SSIMs gepostet, damit man sehen kann, ob er schlechtere Ergebnisse liefert.
Aber wie gesagt: Es steht außer zweifel, dass du mit der CPU minimal bessere Ergebnisse erzielen
kannst. Aber wer sich immer noch DVDs antut hat offensichtlich absolut kein Interesse an maximaler Qualität und dein 3min Encoding ist sicher auch bei weitem kein guter versuch das Maximum raus zu holen. Deswegen habe ich gemeint: Damit vergleichbare Qualität bekommst du mit der GPU viel schneller.
Wahrscheinlich wird die GPU das schneller rechnen, aber ganz sicher nicht um den Faktor 20 schneller.
Wenn man ne wirklch neue nimmt gehe ich jede Wette ein. (Wie gesagt, wenn man nicht mit Gewalt irgend welche 90er Jahre obskuritäten haben will, die aus gutem Grund gestorben sind.) Aber die sind dann eben auch deutlich teurer. Ich guck mal, ob ich irgend wo ne aktuellere Low-End GPU zum Testen her bekomme.[/quote]