[Black-Luster]

Okay.. dummerweise hab ich die Prozesspriorität auf "Höher als Normal" gestellt, wodurch ich mich danach nicht mehr via RDP Anmelden konnte, wegen der hohen Systemauslatung...
Nunja, als er "fertig" war, konnte ich mich anmelden. Aber irgendwie, wie erwartet: Mit nem Crash.
Das altbekannte (JIT-Debugger). Als ich es im Task Manager verfolgt habe, war es bei wie bereits gesagt, ~350 MB. Kurioserweise teigtre mir aber der Process Explorer mehr als 1GB beanspruchten Speicher an. Okay, PE zeigt den RAM Verbrauch von haus aus nicht an - deswegen musste ich es manuell aktivieren. Dadurch kann es sein, das sich das Falsche Feld ausgesucht habe.

[Black-Luster]

Welche werte musst du da genau wissen?

[Black-Luster]

Hier einfach mal ein Screenshot, damit du siehst, was bis jetzt Sache ist.

[Black-Luster]

Nein..! Es läuft noch.
Sollte nur mal quasi als zwischen-Bilanz dienen. ^^
Btw, dieses "Free" unten in der Tabelle: Meint man den freien Speicher, den das Programm noch für sich beanspruchen kann?

Dieser Beitrag wurde von Black-Luster bearbeitet: 22. Februar 2010 - 16:52

[Black-Luster]

Also.. wie es scheint, scheint es ein Speicherproblem zu sein.
Zwar ist die Anwendung diesmal nicht abgestürzt - allerding liegt es daran, da ich diesmal mit Konstanter Bitarte - statt wie bisher mit Variabler Bitrate. Durch die Variable Bitrate muss dieser mehr berechen, wodurch der RAM voll läuft und die Anwendung crasht.
Als das Video mit Konstanter Bitrate fertig Konvertiert wurde, blieben inetwa ~800-900 MB frei.
Ich werds demnächst nochmal mit Variabler Bitrate testen, um 100%ig zu sehen, ob es wirklich deswegen ist.

[DK2000]

Aber irgendwie scheint das wohl auch ein Bug zu sein. Habe da mal auch ein wenig mit dem Encoder gespielt und irgendwie kommt der über Pass 1 bei mkv Dateien nicht hinaus. Er zählt die verbleibende Zeit auf 0 runter und dann irgendwie wieder ganz langsam hoch. Irgendwie glaube ich nicht, dass das so gedacht ist. Bei anderen Dateien zählt er Pass 1 auf 0, dann Pass 2 auf 0 und er ist fertig. Als Profil hatte ich H.264 Zune HD (AV Dock Playback) verwendet. Er ist zwar nicht abgestürzt, aber weiter ist er auch nicht gekommen.

Auf den Speicherverbrauch hatte ich da nicht so geachtet, weil ich das unter Windows 7 x64 getestet hatte.

Mal das Codec Pack (Shark007) anders konfigurieren. Vermute eigentlich, dass das mehr am mkv Splitter/Decoder liegt.

Dieser Beitrag wurde von DK2000 bearbeitet: 27. Februar 2010 - 01:01

[Black-Luster]

Hm... auf meinem Client PC mit dem Encoder und Windows 7 x64, als auch dem Shark007 Codec Pack hatte ich bisher keine Probleme.
Auf dem Server hab ich das Combined Community Codec Pack installiert. Ich müsste mal die MKV Splitter/Decoder beider Packs vergleichen...

[DK2000]

Habe das Codec Pack jetzt mal upgedatet, aber viel gebracht hat es nicht. Da hatte ich mich zu früh gefreut.

Mit den alten Einstellungen ist er zwar nicht über Pass 1 hinausgekommen, aber dafür war der Speicherverbrauch niedrig (~700MB). Das hatte ich mir da noch einmal angeschaut. Mit den neuen Codecs und den anderen Einstellungen hängt er jetzt in Pass 1 bei gut 2 Minuten Restzeit und der Speicherverbrauch hat sich fast verdoppelt (~1200MB). Ich werde ihn mal weiter laufen lassen und mal schauen, was passiert. Auf jeden Fall läuft die Restzeit jetzt wieder ganz langsam hoch.

Aber scheint da einen direkten Zusammenhang zwischen Encoder 3 und den MKV Codecs zu geben. Je nach Einstellung des Codec Packs verhält sich der Encoder 3 anders. Irgendwie habe ich da noch nicht die richtigen Einstellungen gefunden oder es hängt mit meiner mkv Datei zusammen.

Dieser Beitrag wurde von DK2000 bearbeitet: 27. Februar 2010 - 16:09