Original von "Gerti67":

Liebe "CCE Geplagte",

da sich die Probleme hier anscheinend häufen, und ich etwas Zeit hatte, hier mal sämtliche Tips und Tricks, die man mal ausprobieren sollte, wenn sich der CCE im "Multipass" Modus aufhängt.

Eins vorweg, ich bin mir fast zu 100% sicher, dass das CCE Problem ein Hardware Problem ist - will sagen, die Hardware läuft nicht 100% stabil. Ok, einige werden jetzt aufschreien und sagen, ich habe noch nie Probleme mit meinem Rechner gehabt, weder mit Photoshop, Corel oder Office und auch nicht bei irgendwelchen Spielen.

Das mag ja alles sein, aber kein Spiel und erst recht nicht ein "normales" Office oder Grafik Programm fordert den PC so stark wie ein Frameserving von Avisynth an den CCE, vor allem das gesamte Speicher-Interface arbeitet dabei am absoluten Limit. Und erst in diesem Bereich offenbaren einige Mainboards zusammen mit den verwendeten Speicherbausteinen und den Einstellungen des BIOS Instabilitäten, die sonst nicht auftreten.

Auf der anderen Seite trägt wohl auch die etwas "hakelige" Programmierung des CCE ihren Teil dazu bei, insbesondere die wohl etwas intoleranten Speicherzugriffsroutinen. Mag vielleicht auch daran liegen, das der CCE zu 100% in hoch optimiertem Assembler geschrieben ist. Denn oft funktioniert der TMPGEnc auf den betroffenen Systemen dann problemlos - aber auch nicht immer. Wenn beide Programme nicht funktionieren und hängen bleiben, dann hat man wirklich ein grösseres Hardware Problem.

All die kleinen Tips und Tricks, die noch folgen werden, beseitigen nicht alle die Ursache des Hardware Problems, sie können jedoch dabei helfen, diese abzumildern, sodass der CCE dann relativ problemlos seinen Dienst verrichtet - aber eben auch nicht immer.

Tips, die versuchen die Ursache, also die Hardware Instabilität zu bekämpfen, und damit sollte man auch beginnen, weil sie das problem direkt angreifen:

1.) Prozessor und Speicher _NICHT_ übertakten!

Das ist eines der Hauptprobleme, wenn der CCE nicht korrekt funktioniert, Wagemutige können ja selbst mal testen, ab welchem Grad der Übertaktung der CCE anfängt mit CRC Fehlern um sich zu schmeissen, obwohl er vorher korrekt funktioniert hat und auch andere Programme bei dieser Übertaktung noch tadellos laufen. (Bei meinem 1200 MHz Duron auf einem EPOX 8KTA2 mit KT133 und einem 256 MB PC133 Infinion CL2 ist bei 1272 MHz definitv diese Grenze erreicht. Bleibe ich darunter habe ich auch keine CRC Fehler. Noch höher bin ich nicht gegangen, aber ich mache jede Wette, dass dann die ersten CCE "Hänger" auftreten werden.)

2.) Speicher Timings im BIOS heruntersetzten.

Gerade neuere Boards mit DDR-RAM Interface sind da anfälliger, vor allem, wenn man auch noch die gepufferte Variante dieser Module einsetzt. Das verzögert einige Speicherzugriffe, und es ist zwingend nötig im BIOS die Timings herunterzusetzten, noch besser aber ist, solche Module auf keinen Fall einzusetzen. Auch mehr als ein Modul kann Probleme verursachen, wenn die Speicher Timings zu schnell eingestellt sind und auf ein Modul optimiert sind, oder wenn zwei unterschiedliche Module eingesetzt werden. Also: Timings heruntersetzen, dabei notfalls auf manuelle Einstellung umschalten, weil die Automatik schon mal versagen kann. Oder alternativ nur mal mit einem Modul versuchen.

3.) Aktuelles BIOS des Mainboard Herstellers verwenden.

Das ergibt sich oft aus dem vorangegangen, weil die Hersteller oft mit neuen BIOS Versionen kleine Instabilitäten beseitigen, die sich oft erst später gezeigt haben. Man braucht sich da nur mal die "Readme" Dateien zu den BIOS Updates durchzulesen.


4.) Auf gute Stromversorgung und Kühlung achten.

Gerade unter der extremen Belastung des Video-Encodings mit Avisynth und CCE zieht der Prozessor mächtig Strom. Dabei wird er sehr, sehr heiss, 4-5 Stunden Quake sind da nichts dagegen. Also, wenn das Netzteil etwas wackelig ist und diese hohe Belastung auf Dauer nicht aushält, kann es auch zu den berüchtigten CCE "Hängern" kommen, wobei sich ein instabiles Netzteil aber häufiger durch spontane Re-Boots bemerkbar macht. Durch die enorme Stromaufnahme und die damit verbundene Wärmeabgabe des Prozessors ist unbedingt auf gute Kühlung zu achten. Wem der Prozessor unter "normalem" Betrieb schon so um die 60°C warm wird (gemessen vom BIOS), der kann davon ausgehen, dass dieser Wert um ca. 10-15°C ansteigt beim Kodieren - und dann kommt der Prozessor schon in die gefährliche Zone, weil die Kerntemperatur in der Regel noch um einiges höher liegt (um ca. 20°C).

5.) Die aktuellsten Chipsatz Treiber installieren.

Gerade bei Mainboards mit VIA Chipsatz, ist es meisst absolut notwendig, die aktuellsten 4-in-1 Treiber zu installieren, damit das System stabil läuft.

6.) Einige Stabilitätstests durchführen.

Zwei Test haben sich dabei als sinvoll erwiesen, da sie ähnlich hohe Last auf das CPU/Speicher-Interface erzeugen, wie Avisynth/CCE. Zum einen der "Prime95 Torture Test" ( http://www.mersenne.org/freesoft.htm ) und zum anderen der "Memtest86" ( http://www.memtest86.com ). Laufen beide Test für mehrere Stunden ohne irgendwelche Fehler durch, dann scheint das System stabil zu laufen. Wenn nicht, hat man immer noch irgendwo ein Problem im System. Vor allem den "Prime95 Torture Test" sollte man ruhig mal ca. 10 Stunden laufen lassen, besser noch länger. Aber unbedingt auf gute Kühlung achten, der Prozessor wird dabei verdammt heiss!


Hat man diese Punkte abgearbeitet und die Probleme sind immer noch nicht behoben, kann man versuchen dem CCE zu etwas mehr Stabilität zu verhelfen, indem man ihn mit einigen Einstellungen "zwingt" etwas toleranter zu werden oder ihn mit etwas verdaulicherem Matrial zu füttern:

7.) Die Zeile "ResampleAudio(44100)" zum Avisynth Script hinzufügen (bei DVD2SVCD unter "Frameserver").

Obwohl bei Verwendung von DVD2SVCD der CCE keine Audio Daten kodiert, kann dieser Befehl helfen, weil dann Avisynth einen Video-Stream an den CCE liefert, der aussieht, als ob ein Audio-Stream mit 44.1 kHz enthalten ist. Da der CCE zur Audio-Bearbeitung SSE Befehle benutzt, führt dies auf älteren Durons/Athlons zu Abstürzen, und dadurch, das Avisynth dem CCE einen 44.1 kHz Stream "vorgaukelt" oder so ähnlich, denkt der CCE halt, das mit dem Audio-Stream alles in Ordnung ist, und dieser nicht konvertiert werden muss - also versucht er auch nicht irgendwelche SSE Befehle zu benutzen obwohl er den Audio-Stream eh nur durchreichen soll und nichts damit machen soll. Auf Prozessoren, die SSE unterstützen, sollte die Zeile nicht nötig sein, jedoch schaden tut sie auch nicht.

8.) Den "Anti Noise Filter" des CCE ausschalten (bei DVD2SVCD unter "Encoder").

Dadurch verhält sich der CCE etwas stabiler, gerade beim Kodieren von Szenen, in denen das Bild fast komplett schwarz erscheint (etwa im Abspann, z.Bsp. Shrek ist bekannt dafür) jedoch in Wirklichkeit einige kleine "Pixel" vorhanden sind, die eben nicht schwarz sondern sehr, sehr dunkel grau sind, und der CCE die dann versucht herauszufiltern und dabei ins Straucheln kommt.

9.) Ausreichend Abstand zwischen "Max" und "Max. avg" Bitrate einhalten (bei DVD2SVCD unter "Bitrate").

Der CCE ist auch etwas anfällig, wenn zwischen der "Max" und der "Max. avg" Bitrate nicht mindestens 120 besser noch 150 kbit/s Differenz liegen, wobei "Max. avg" natürlich kleiner als "Max" sein muss.

10.) "Luminance Offset (Brightness)" erhöhen (bei DVD2SVCD unter "DVD2AVI").

Das bewirkt eine Anpassung des gesamten Films, der dadurch etwas heller wird, dadurch werden natürlich wieder die berüchtigten dunklen Szenen etwas aufgehellt, was anscheinend dem CCE hilft, über diese Stellen besser hinwegzukommen.

11.) Den CRC Patch für den CCE anwenden.

Dadurch wird der CCE veranlasst, bei einem "Multipass" Durchlauf einen eventuell auftretenden CRC (Checksum) Fehler zu ignorieren. Das muss nicht unbedingt bedeuten, dass tatsächlich ein Bit-Fehler zwischen zwei Durchläufen vorhanden ist, einige vermuten die Ursache dafür auch bei Avisynth, das (leicht) falsche Daten an den CCE liefert. Im allgemeinen ist der Fehler sowieso zu vernachlässigen, weil das MPEG2 Format ziemlich fehlertolerant ist, und sich kleine Fehler wenn überhaupt nur durch kurze "Macroblocks" bemerkbar machen. Wie schon oben beschrieben, deutet dieser Fehler jedoch auf eventuell vorhandene Speicher-Timing Probleme hin. (Den Patch gibt's bei Doom9 im DVD2SVCD Basic Forum in der "DVD2SVCD Official Q&A" - Q27)
Edit arlsair: Gertie verzeih mir, ich füge hier mal einen direkten Link ein: CRC Patch (15KB)

12.) Die "MPEG2DEC2.DLL" statt der "MPEG2DEC.DLL" mit Avisynth benutzen (bei DVD2SVCD unter "Frameserver").

Diese DLL ist dafür zuständig den Video-Stream aus den VOBs zu dekodieren und Avisynth reicht dann diese dekodierten Video-Daten als "Pseudo" AVI an den CCE weiter. Die "MPEG2DEC2.DLL" ist eine Weiterentwicklung, die von Tom Barry auf den Pentium 4 optimiert wurde, sie läuft aber auch problemlos auf allen anderen CPUs, dann kommen die Optimierungen jedoch nicht (so sehr) zum Tragen. Bei dieser DLL hat Tom auch die Video-Stream-Puffer erhöht und die DLL neben einigen kleinen Bugfixes somit auch um einiges stabiler gemacht, sodass die Puffer wohl einige problematische Speicherzugriffe besser ausgleichen.

13.) Die "Intra DC precision" auf "8" oder "Auto" stellen (bei DVD2SVCD unter "Encoder").

Diese Einstellung zwingt den CCE, die Rechengenauigkeit bei der Kodierung etwas herunterzustellen, dadurch soll in manchen Fällen auch Probleme mit CRC Fehlern oder auch CCE "Hängern" behoben werden. Qualitativ bringt das keine Nachteile, weil die optimale Einstellung dieses Wertes eigentlich vom Quellmaterial abhängig ist und bei etwas "verrauschtem" oder auch sehr detailreichem Material z.Bsp. bei einem Wert von "10" manchmal eben auch diese "Rauschen" als Bewegung interpretiert wird, obwohl gar keine vorhanden ist, oder bei Bewegungen zu viele Details berücksichtigt werden. Dadurch wird dann unnötig Bitrate verschwendet und man wäre mit der Einstellung "8" viel besser aufgehoben. Umgekehrt gibt es aber auch Fälle, bei denen "10" ein besseres Ergebnis abliefert, z.Bsp. bei ruhigen Szenen mit vielen Details. Also kann man den CCE das eigentlich auch selbst entscheiden lassen und die Einstellung auf "Auto" stellen.

14.) Den VirtualDub AVI "Proxy" Mode abschalten, falls aktiviert.

Wer mit VirtualDub, den AVI "Proxy" Mode File Handler installiert hat, sollte diesen wieder deaktivieren, weil dies zu Problemen mit dem CCE führen kann. Standardmässig ist er bei der Installation von VirtualDub jedoch nicht aktiviert, also ist es nur nötig, wenn man ihn eingeschaltet hat. Genaueres in der Readme im "VirtualDub\aviproxy" verzeichnis.

15.) AVIs mit ungenauer Framerate oder fehlerhafte AVIs.

Manche AVIs kommen mit einer Framerate daher, die vom CCE nicht unterstützt wird. Zwar versucht DVD2SCVD dieses Problem mit dem "AssumeFPS()" Kommando im Avisynth Script zu umgehen, jedoch funktioniert das manchmal nicht korrekt. Eine Lösung gibt es in dem Fall wohl nicht, es sei denn man kann die AVIs nochmal neu kodieren. Bei aus dem Internet heruntergeladenen AVIs kann es auch mal zu den berüchtigten AVI Freezes kommen, da hilft dann manchmal ein Tool das diese Freezes vorher beseitigen kann (z. Bsp. AviDefreezer gibts bei Doom9), damit der CCE das AVI anschliessend fehlerfrei kodieren kann.

16.) Die Option "Safe mode (frameserving)" verwenden (bei DVD2SVCD unter "Encoder").

Sollten alle oben beschriebenen Tips nicht helfen, kann man versuchen den CCE im "Safe mode" über VFAPI mit einem kompatibleren AVI zu füttern. In diesem Modus finden alle Transformationen im RGB Farbraum statt, wobei sich jedoch ein Geschwindigkeitsverlust von ca. 30% ergibt. Dieser Modus bekommt dem CCE jedoch anscheinend besser, wodurch eventuelle "Hänger" behoben werden können. Auch lassen sich so die Versionen 2.62 und 2.64 zusammen mit DVD2SVCD benutzen, die ja bekanntlich keine Avisynth Dateien direkt benutzen können, was ausser der einfacheren verwendung von anderen Matrizen jedoch keine qualitativen Vorteile bringt, da diese Versionen hauptsächlich Bugfixes für die Audio Kodierung auf Athlon Rechnern sind, die bei DVD2SVCD sowieso nicht mit dem CCE gemacht werden. Die demnächst erscheinende Version 2.66 soll laut Insider-Berichten jedoch wieder direkt Avisynth Dateien unterstützen - sollte dann auch mit DVD2SVCD funktionieren. Eine andere Möglichkeit, ist das Shareware Programm "Link2" von Edwin van Eggelen, das ein AVI erzeugt, das von den Versionen 2.62 und 2.64 unterstützt wird, und welches man unter "Safe mode (frameserving)" auswählen kann. Dieses Programm ist fast genauso schnell wie Avisynth, womit der Geschwindigkeitsverlust von 30% nicht vorhanden ist. Allerdings ist es Shareware und muss bezahlt und registriert werden, sonst kann es nur 30 Frames mit voller Geschwindigkeit kodieren.

17.) Nur "CBR" oder "One pass VBR" benutzen (bei DVD2SVCD unter "Encoder").

Ok, ist zwar nicht der Weisheit letzter Schluss, funktioniert aber in den Fällen, in denen ein "Multipass" nicht funktioniert, weil nur ein Kodier-Durchgang stattfindet und der CCE in diesem Modus etwas stabiler agiert. Der Nachteil ist, dass die Zielgrösse und somit die Anzahl der CDs nicht korrekt vorherbestimmbar ist ("One pass VBR") oder bei geringeren Bitraten (< 2300 kbit/s) ein "CBR" nicht unbedingt mehr so gut wie eine Multi-Pass Kodierung aussiht bei manchen Szenen.

18.) Als letzten Ausweg TMPGEnc benutzen.

Ist vielleicht nicht die beste Lösung, aber so schlecht ist der TMPGEnc gar nicht. Im Gegenteil, er wird immer besser und bei VCDs und DV und "Interlaced" Material ist er dem CCE eigentlich schon jetzt überlegen. Ok, das Kodieren dauert länger als beim CCE, dafür unterstützt er aber Dual CPU Boards auch besser und ist darauf dann fast gleichschnell.


Hoffe, das bringt etwas Licht ins Dunkel der CCE Abstürze und Problemchen.

So, dass war's mit all den zusammengetragenen Infos zum CCE Problem (hauptsächlich aus dem englischen Doom9 Forum und einigen anderen Quellen). Vielleicht kann einer der Moderatoren ja ein "Sticky" draus machen - oder was auch immer.

Gruss,
Gerti