This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

[BUG] 1920x1012 10bit YUV444 file wird in AviSynth falsch verarbeitet
#31
Kleinvieh macht auch Mist, 10x 2,1% sind auch schon 20%. (Sorry, da kam der Schwabe durch Big Grin )

Werd mal schauen, ob sich das mit nem anderen x264 preset evtl. noch etwas erhöht. Leider lasten die schnelleren immer meine CPU nicht konsequent bei 100% aus, und damit kann dann theoretisch ein Mehraufwand von avs2yuv/avisynth durch die CPU, die noch "etwas Luft hat" vermutlich teilweise kompensiert werden.
Reply
#32
Gerade mal geschaut, dass ConvertToYUV444 passiert, weil Hybrid bei 4:4:4 intern fläschlicherweise von YV16 anstat YUV24 ausgegangen ist. (Typo,.. Angel sollte aber nichts machen)

Das > 8bit als 16bit angenommen wird, kann ich anpassen.

Cu Selur
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
Reply
#33
(15.05.2022, 19:42)Selur Wrote: Das > 8bit als 16bit angenommen wird, kann ich anpassen.

Du meinst 10 bit als 16 bit, oder bist noch auf einen weiteren bug gestoßen?
Reply
#34
Nein, wenn eine Quelle mit mehr als 10bit erkannt wird, wird bei LibAVSource immer 16bit angefragt in Hybrid.
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
Reply
#35
hab das ">" übersehen Blush
Reply
#36
Nebenbei: DGDecNV gibt bei >8bit immer 16bit aus.
-> könntest mal testen ob das bei libav auch ist wenn Hardware decoding verwendet wird.

Cu Selur
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
Reply
#37
Bei der Verwendung von ffmpeg liese sich für den Fall einer Formatänderung (z.B. von YUV444P16 zu YUV420P10) theoretisch converbits(10) und ConvertToYUV420() auch noch einsparen, indem z.B. nur der interne Aufruf -pix_fmt yuv420p10le verwendet wird.
Scheint genau andersrum zu sein, als du das in der letzten PM geschrieben hast, die ffmpeg-interne Routine ist etwas schneller, als wenn avisynth verwendet wird. Allerdings lag da der Gewinn nur bei knapp 1%.
Wenn durch diese Anpassung aber größeres Code Chaos durch verursacht wird... Wollt's nur nochmal erwähnen, wenn du dich gerade in diese code section reindenkst.
Reply
#38
Quote:, die ffmpeg-interne Routine ist etwas schneller, als wenn avisynth verwendet wird.
Ne, dafür hat da FFMpeg zu oft Probleme gemacht, als das ich mich da blind auf FFMpeg verlasse.
Deine Messgenauigkeit ist nicht so hoch als das ich da drüber nachdenke.
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
Reply
#39
(15.05.2022, 20:01)Selur Wrote: Nebenbei: DGDecNV gibt bei >8bit immer 16bit aus.
-> könntest mal testen ob das bei libav auch ist wenn Hardware decoding verwendet wird.

Cu Selur


Ich würd's gerne und hätte es auch bereits' gemacht, aber es mangelt wie gesagt an Nvidia-Hardware Sad
Reply
#40
Naja, teste ich die Tage mal.
Mach mich jetzt auch gleich ins Bett, muss morgen um 4 Uhr raus.

Cu Selur
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)