HC MPEG2 Encoder - AviSynth-Probleme

Hm, ich habe jetzt auch mal mit dem Ding herumgespielt, aber über die Hälfte meiner AVS-Scripte bringen den Encoder zum Absturz (passiert mir aber auch mit VirtualDubMOD, nur nicht so oft), während TMPGEnc sie einwandfrei akzeptiert.

In 'nen News-Thread eigentlich nicht viel...
Scheint aber recht ausbaufähig zu sein, wenn auch etwas langsam.

LigH
Danke, gute Idee, das auszulagern.

incredible
Durchaus möglich, dass da was nicht stimmt. Es betrifft aber eben nicht alle AVISynth-Scripte, sondern nur ganz bestimmte. Aber das mit der readavs.dll werde ich zur Sicherheit nochmal checken. Allerdings: Wenn das so sein sollte, wie Du vermutest, dann müsste TMPGEnc in diesen Fällen dann auch abschmieren. Stellt sich die Frage: Wie repariert man's, ohne Windoof neu zu installieren? *grübel*

So, ich habe mal AVISynth von der Platte geputzt und neu instralliert. VirtualDub und MediaPlayer schmieren immer noch ab, wenn eine RGB24-Wandlung vorkommt, aber HCenc frisst jetzt die Scripte, die vorher zum Absturz führten.
Das fällt wohl unter "... Dinge zwischen CPU und Applikation, die kein Mensch versteht..."

Nebenbei habe ich noch festgestellt, dass ich in TMPGEnc eine fehlerhafte Pfadangabe zur ReadAVS.dll hatte.

Ich bin doch der, der sich dem "Fortschritt" bei den Betriebssystemen verweigert. Daher: Win98SE.
Und wie gesagt, nach der Neuinstallation von AVISynth geht's ja jetzt. Ich verstehe zwar nicht warum, denn im Zusammenspiel mit den anderen Programmen hat sich gar nichts geändert, aber das muss ich wohl auch nicht verstehen.

Ich frage mich nur gerade, worüber TMPGEnc in der Vergangenheit die AVS-Files geöffnet hat, wo doch ReadAVS.dll gar nicht vorhanden war? Der DirectShow-Reader hat bei mir eine Priorität von -1, steht also ganz am Ende.

Aber egal, ein kurzes Testencoding hat ergeben, dass die von ReadAVS geöffneten Files bitidentische Ergebnisse bringen.

Nachtrag, da incredible jetzt dazwischen war: Ich hatte sowieso die 2.55 drauf.

Bei dem jetzigen PC steig' ich nicht mehr um, da einiges von meiner Hardware nicht unter XP läuft (der Scanner z.B.). Früher oder später brauche ich eh alles neu, da mach' ich dann reinen Tisch. Ansonsten ginge bei mir nur eine Multibootsystem mit Win98SE UND XP auf dem PC, und den Ärger damit handle ich mir nicht ein.

Das mit den verschobenen Bildern bei HC + 2.56 habe ich im englischen Doom9 gesehen, sah ja schlimm aus.

Nachtrag: Menno, seid Ihr schnell...

LigH
Ah ja, danke. ich wusste nicht, welcher Reader dann genommen wird und hätte auf DirectShow getippt. Aber jetzt, wo Du das geschrieben hast... hätte mir eigentlich auffallen müssen, dass ich seit einiger Zeit keine AVS mehr direkt öffnen konnte, sondern erst "all files" wählen musste. Die eingetragene ReadAVS lag im Verzeichnis von DVD2SVCD - und das habe ich vor einer Weile gelöscht.

Sacht ma... iss dat hier'n Chat oder'n Forum?

incredible
Win98SE und XP professional besitze ich völig legal, Win2k nicht.

LigH
Ich mag diese Art der Bastelleien an PCs nicht sonderlich. Ist wirklich nicht mein Ding sowas.

Doch, doch, die habe ich leider. Ich muss manche Sachen sehr einfach halten und kann manche Dinge nicht gut genug erklären. Und wie ich schon mal erwähnte: Ich kann Englisch ganz gut lesen, aber verstehen, sprechen und schreiben - argh, ohne mein digitales Leitz-Wörterbuch wäre ich vollends aufgeschmissen.

Ich weiß z.B. einfach nicht, wie ich hank genau erklären soll, was ich bei dieser Min.-Bitrate-Sache von ihm will. Und außerdem hatte ich mich da etwas beim CQ-Modus vertan, der bei TMPGEnc ja eben nicht mit einer konstanten Qunatisierung arbeitet, sondern im Gegenteil, der passt ja den Quantisierer dynamisch an. Selbst CQ_VBR, der einem konstaten Quantisierer schon näher kommt, hat noch die Fähigkeit, das zu ändern.

Aber inzwischen habe ich mehrere Tests mit dem HC gemacht und muss sagen, der ist verblüffend gut. Noch kann ich ihn mit TMPGEnc schlagen, aber wenn der sich so weiter entwickelt wie bisher...

Wie wird konstante Qualität berechnet... diese Frage habe ich Hori mal gestellt, als der noch auf Mails antwortete. Aber die Antwort war sehr verworren.
Er hat wohl intern ein Messverfahren, das einen Mittelwert der Frames einer GOP bildet. Danach ändert er dann dynamisch die Quantisierung. Nach welchen Regeln er aber das tut, das hat er nie verraten.
Es funktioniert jedenfalls sehr gut, wenn man den B-Frame-Bug korrigiert, was bei TMPGEnc in CQ oder 2pass CQ dadurch funktioniert, dass man die B-Spoilage auf 0 setzt. TMPGEnc neigt nämich dazu, den I-Frames zu viel und den B-Frames zu wenig Bitrate zuzuordnen - und das ergibt dann oft diese blöde Pumpen innerhalb einer GOP.
Was ich mit Sicherheit sagen kann ist, dass TMPGEnc einen dynamischen und keinen statischen Quantisierer benutzt. Alles weitere, da müsste ich leider raten.
Aber selbst wenn hank keinen dynamischen Quantisierer einbauen kann oder will, sollte es möglich sein, die Quantisierung dann zu ändern, wenn ein vorgegebenes Bitraten-Minimum unterschritten wird. Das ist eigentlich das, was ich gerne hätte.
Ein Padding nutzt ja nichts, weil normale DVD-Authoring-Tools das eh wieder rausschmeißen und es bei elementary Streams - und solche erzeugt HC ja, auch gar nicht möglich ist, ein Padding einzufügen.

Nachtrag: Oh, Mist, ich habe gerade festgestellt, dass ich in meinen AVS-Scripts die Lumarange wieder selbst anpassen muss, wenn ich HC benutze. Der hat all meine Encodings jetzt verhauen. Das AVS lieferte schon 16-235, und HC hat's komprimiert zu 32-219... Also alle Tests nochmal von vorn... argh!