Hui, da hat sich ja was angesammelt; keine Mail gekriegt, dass was Neues kam; hatte beim Ändern der Benachrichtigungsoptionen nicht auf Absenden geklickt *grummel*.
Das machst du, indem du weder --tff noch --bff verwendest. Weglassen, dann arbeitet x264 progressiv.
Hm, dann verstehe ich den Output von x264 nicht:
[2021-08-27][20:45:26] "C:\Program Files (x86)\Simple x264 Launcher\toolset\x64\x264_x64.exe" --output-depth 8 --crf 18.0 --preset veryfast --tune film --nr 1000 --vf crop:0,0,6,4/resize:720,576,1:1 --output C:\Users\Public\Videos\x264\Hatari.mkv --index C:\Users\Siegbert\AppData\Local\Temp\~026a09c4f17660e09837.ffindex C:\Users\Public\Videos\Todo\Hatari\Hatari.mkv
[2021-08-27][20:45:26]
[2021-08-27][20:45:27] ffms [info]: 720x576i 64:45 @ 25/1 fps (vfr)
[2021-08-27][20:45:27] crop [info]: cropping to 714x572
[2021-08-27][20:45:27] resize [error]: swscale is not compatible with interlaced vertical resizing
Kein Paramter --tff, d.h. codieren als progressive, aber unten die Meldung "swscale is not compatible with interlaced vertical resizing". Bug in x264? Hier kommt übrigens auch das ffms her, das ich oben zitierte. Scheint als Library in x264 einkompiliert zu sein, um die Metadaten zu extrahieren.
Es gibt kein zweites Bild, das man wegwerfen müsste. Bei progressivem Video ist ein Vollbild zu einem Zeitpunkt aufgenommen worden; bei Interlaced sind zwei Halbbilder zu verschiedenen Zeitpunkten aufgenommen worden, wurden dann zu einem Vollbild vereint.
Was ich sehe ist, dass beim Anschauen von Einzelbildern der gerippten Datei mit MPC jedes 2. Bild identisch zum Vorgänger ist. Gaukelt mir hier MPC zwei identische Standbilder vor, die in Wahrheit aus 2 interlaced-Halbbildern zusammengesetzt sind?
Was ist denn beim Encodieren der DVD passiert, wenn der aus progressivem Filmmaterial interlaced MPEG-2 macht? Ist das danach wirklich interlactes Material, das bei meinem Rückweg deinterlaced werden muss? Oder ist das Flag nur da, um dem Standard zu entsprechen, die Bildinhalte sind aber noch progressive mit 2 identischen Bildern?
Gibt's eine bessere Methode sich das Material zur Analyse anzusehen als Einzelbilder in MPC?
DAR = Display Aspect Ratio = Breite : Höhe
SAR = Sample Aspect Ratio = entzerrte Breite (wie es dargestellt werden soll) : encodierte Breite (wie es gespeichert wurde)
andere AR-Abkürzungen: kommt drauf an, was die in dem Zusammenhang bedeuten sollen...
Ok, so weit Einigkeit.
Zum Skalieren kann man AviSynth oder VapourSynth verwenden, die haben jeweils eine breite Auswahl unterschiedlicher Methoden. Ich nehme an, dass ffmpeg das auch alleine kann, kenne aber den Parametersatz nicht auswendig. Aber ffms(2) ist was anderes, ich kenne das als Quell-Plugin für AviSynth/VapourSynth, nicht als eigenständiges Programm.
Die Doku von Vapoursynth empfiehlt Bicubic, wenn man es nicht besser weiß. Ist das die Methode, die auch der TV in Hardware anwenden würde?
Wo es bei mir fehlt, sind die Colorspace-Möglichkeiten, die dort zur Auswahl stehen. Oder ist das beim Ausgangsmaterial Film dann immer derselbe, den man nehmen sollte?
Dort ist auch nichts erwähnt, ob die Ausgangsgröße irgendein Vielfaches von 2-8 sein muss. Also volle Freiheit beim Croppen auf krumme Werte? Sollte die Endgröße sich an bestimmte Beschränkungen halten?
Anstatt die variablen Ränder abzuschneiden, könnte man sie auch mit einem scharfen schwarzen Rahmen überdecken. Dann bleibt zumindest das Seitenverhältnis des Gesamtbildes gleich.
Hm, ja das könnte tatsächlich der einfachere Weg sein, die schwarzen Ränder kosten ja kaum Platz. Sollten die Schwarzen Ränder Vielfaches von irgendwas sein, damit die Grenze zum eigentlichen farbigen Bild nicht innerhalb eines Blockes liegt?
Für Videobearbeitung sollten mindestens
immer 3 SSDs oder HDDs im System vorhanden sein. Den Simple x264 Launcher
kannst du auf C: belassen, aber unbedingt für die Streams, einen Ordner auf ein
anderes LW erstellen.
Werd ich bei meinem neuen Rechner so machen, auf der alten Kiste war die CPU der Flaschenhals.
Hatari.txt:
Das Preset: veryfast, würde ich auf „slow“ setzen. Das
Tuning Film ist eigentlich für 35mm Film gedacht.
Aber wir haben ja Streams, ich glaube nicht, dass sich hierdurch Vorteile ergeben.
Aber wenn man z. Bsp. Zeichentrickfilme encodiert, dann kann man unter Tuning „Animation“ verwenden.
Angeblich sollen mit dieser Tuningeigenschaft, die Bilder flüssiger wirken.
"slow" werde ich mit dem neuen Rechner dann auch ausprobieren, bisher war "veryfast" für mich ein guter Kompromiss aus Größe und Encodierzeit.
Ob man Tuning "Film" noch verwenden sollte, wenn das Material schon durch diverse Vorbehandlung durch ist und nicht mehr der Scan direkt vom Film ist eine gute Frage.
Kann dazu jemand was sagen?
Animationsfilme habe ich keine auf DVD.
Cropping:
Mein Tipp, nicht croppen, dann wird dir auch vermutlich der
Fehler nicht mehr angezeigt. Auch interlace stimmt vermutlich wieder.
Muss ich heute abend mal ausprobieren, sitze gerade nicht am Rechner für Filme.
Wenn du progressiv willst, dann musst du deinterlacen, wie
du schon richtig schreibst mit QTGMC.
CUDA immer abschalten, das ist mehr für
Spiele geeignet. 32 GB- oder 64 GB-RAM sind da sinnvoller.
Ob das Material wirklich interlaced ist, habe ich oben schon LigH gefragt. CUDA hat mein Rechner bisher nicht.
Kurze Frage:
Wenn du in den 70er- oder 80er Jahren Bilder mit einem
Röhrenfernseher angeschaut hast, hast du dich damals über Interlacsestreifen
und Banding aufgeregt. Damals wussten wir noch gar nicht, dass es so etwas
überhaupt gibt.
Studio-Material war ja auch interlaced aufgenommen, also kein Problem. Gibt's Banding auch im reinen Analogbereich? Ich kann mich nur an Cross-Color/-Luminance-Probleme erinnern, die aber deutlich. 
Bei Filmen kann ich mich an keine Artefakte erinnern, obwohl progressives Material als interlaced gesendet wurde. Keine Ahnung wie die das gemacht haben in der Analogwelt.
Wer braucht MPEG-2:
Eine DVD VOB-Datei ist MPEG-2. x264 im MKV-Container in
deinem Fall, wird nochmals in VOB zu MPEG-2 umgewandelt.
Ist mir soweit klar. Was Pato gemeint hatte ist wohl, dass man MPEG2 als Archivformat auf Platte heute nicht mehr braucht. Deswegen scheint er auch neu zu encodieren.
/OT
"Ok wird doch Zeit auf neue Hardware zu wechseln. Auch x265 ist rein CPU-basiert ohne dass die GPU eine Rolle spielt, korrekt?"
es kommt darauf an.
- für pc gilt ein zweigleisiger weg:
. die CPU ist für videoerstellung für qualität (außerhalb) der üblichen video profile
. dekodieren bekommt diese meist auch problemlos hin
. die GPU ist bei den vordefinierten profilen effizienter und entlastet die CPU für andere aufgaben
. auch beim erstellen von videos (z.b.) streaming sind diese auch nicht mehr so schlecht
. für youtube & streaming bieten GPUs vorteile
. fürs videoarchiv sollte man vielleicht die CPU bemühen. (qualität vs. größe)
--> aufrüstung in betracht ziehen
Alles anzeigen
Da reden wir glaube ich ein bisschen aneinander vorbei. Ich meinte mit x265 nicht den Standard H.265, sondern das Programm zum Encodieren. Soweit ich weiß, benutzt das keine HW-Beschleunigung. Du führst ja unten fürs Videoarchiv auch die CPU an. Da war meine Frage, ob es inzwischen qualitativ gleichwertige Encoder gibt, die GPUs benutzen und deswegen nochmal deutlich schneller sind als x265 bei vergleichbarer Qualität des Endmaterials.
Dass vergleichsweise schwachbrüstige Mobil- und Embedded-Geräte HW-Beschleunigung zum Decodieren brauchen ist klar.
Noch an Pro Jo: Bei Hatari würde ich mir die Bluray tatsächlich überlegen. Bei den meisten anderen Filmen, die auf DVD warten, würde sich die Neuanschaffung wohl nicht lohnen. Wäre auch ganz schön teuer, sind einige Schachteln voll ...
