mplayer: Startverzögerung mit "grünem" Bildschirm

Hallo!

Ich bin's mal wieder mit einem neuen mplayer-Problem ... tut mir ja leid, dass es bei mir immer hakt, aber diesmal weiß ich wirklich nicht, woran es noch liegen könnte. Aber zum Problem: wenn ich ein Video starte (unabhängig ob Konsole oder GUI), wird dieses zwar prompt geöffnet, aber erst nach einigen "Fehlversuchen" abgespielt. In der GUI äußert sich das Problem darin, dass der Ton für ein paar Zehntelsekunden angespielt wird, aber es erscheint kein Bild. Dann ist genauso lange Stille. Dann nochmal anspielen, wieder Pause. Im dritten Versuch startet endlich die Video/Audio-Wiedergabe. Insgesamt also eine zusätzliche Verzögerung von knapp zwei Sekunden, die bis gestern noch nicht da war (später mehr).
Wenn ich das Video von Konsole starte ohne besondere Parameter, erhalte ich keine Warnungen und folgende, für mich normale Ausgabe:

==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
==========================================================================
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
AO: [dsound] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
VDec: vo config request - 640 x 480 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO: [directx] 640x480 => 640x480 Planar YV12

Das Wiedergabefenster öffnet sich und sieht im Modus directx grün gestreift aus, also recht kaputt. Bei Verwendung von OpenGL bleibt das Fenster schwarz. mplayer benötigt dann auch knapp 2 Sekunden, bevor die Video/Audio-Wiedergabe losgeht. Die Startaussetzer (Ton anspielen, Pause, ...) kommen hier auch vor. In jedem Fall blockiert die Kontrolle für diese zwei Sekunden, sowohl von der Konsole wie aus der GUI heraus gestartet.

Jetzt weiß ich leider nicht, wo das Problem liegen könnte. Ich habe verschiedene ältere Versionen ausprobiert (rev27323 bis zur neuesten rev27811), aber alle zeigen die gleiche Problematik. Daran wird's vermutlich nicht liegen. Aber ich hatte bis gestern noch das mplayer-Package vom 29.09. installiert gehabt und ab Mitte Oktober die mplayer.exe mit neueren Revisionen ersetzt. Das hat das Problem nicht hervorgerufen. Gestern hab ich dann das neueste Package installiert (2008-10-27), und seitdem taucht das oben genannte Problem auf.

Ich werde nun nochmal die Installation rückgängig machen und das 09-29-Package installieren. Vielleicht liegt da irgendwo zwischen ein Fehler. Aber wie kann eine Paketsammlung ein Problem hervorrufen, das sämtliche Stand-Alone mplayer-Versionen betrifft? Oder werden Codecs aus dem internen Codec-Verzeichnis verwendet? Sollte eigentlich nicht, die Builds von Sourceforge sind knapp 13MB groß. Ich habe die Sache (wie im Log zu erkennen) mit einem normalen Xvid und MP3-Tonspur getestet. Das Problem tritt auch mit MPEG2, H.264, RealVideo auf (anders gesagt, ich habe keine Ausnahme gefunden).

Nachtrag:
Habe nochmal versucht, die alte Version von Mplayer for Windows zu installieren. Das hat keine Besserung gebracht, weder mit den Standardeinstellungen noch mit dem neuen Binary vom mplayer.

Aber: wenn ich irgendeine Binary vom mplayer (alle Revisionen ab 27323) in ein leeres Verzeichnis stopfe und über die Konsole starte, funktioniert es tadellos! Da ich das vorher nur im Verzeichnis vom Mplayer-Package probiert hatte, schlussfolgere ich mal, dass es irgendwelche Ini-Dateien oder Einstellungen in diesem Verzeichnis gibt, die von mplayer ausgelesen werden und womit es dann zu diesen Startrucklern kommt. Allerdings hatte ich ResetSMPlayer ausgeführt. Wo also können noch Einstellungen gespeichert werden? Irgendwo in der Registry?

LoRd_MuldeR: Wie kann ich von deinem Mplayer for Windows alle Einstellungen restlos entfernen für eine saubere Neuinstallation? Inzwischen sehe ich die Schuld bei mir, ich hab mit den Einstellungen in smplayer herumgespielt. Da
1. es nicht an mplayer selbst liegt (die Stand-Alone funktioniert),
2. mplayer irgendwelche Einstellungen nachlädt,
3. die Re-Installation des alten Mplayer for Windows (2008-09-29) auch nicht hilft,
bleibt mir nur die Option, dass irgendwo in der Registry oder meinem Home-Ordner oder wo auch immer Resteinstellungen bleiben, die den Fehler bewirken. Die hätte ich gerne wieder "auf Null" gestellt.

Also, es liegt schonmal irgendwie am mplayer-Unterordner, wo die Ini-Dateien drin sind. Wenn ich den umbenenne, funktioniert sowohl mplayer (Konsole) wie auch MPUI. Aber nicht der SMPlayer. Dann guck ich mal dessen ini-Datei durch.

Diese Optionen sind standardmäßig in der Datei Mplayer for Windows\mplayer\config drin:

## Fontconfig
fontconfig=yes
font=Arial

Kommentiert man sie aus, funktioniert mplayer aus der Konsole heraus und von MPUI aus. Warum sind die denn standardmäßig aktiviert? Bei mir funktioniert das jedenfalls nicht...

Und warum SMPlayer nicht will, hab ich auch noch nicht ganz heraus. Es hat aber möglicherweise auch etwas mit der Untertitelschrift zu tun, denn wenn ich eine Option wähle, die zu einem Fehler beim mplayer führt (d.h. er sagt, er kann die Schriftart nicht laden), läuft auch die Wiedergabe dort problemlos.

*hmpf*

Nachtrag:
So, der Schuldige ist gefunden! Es waren keine übriggebliebenen Konfigurationen, keine Reste in der Registry. Da hatte ich mich geirrt. Prinzipiell gehen auch die ganzen Untertitel. Das Problem trat auf, wenn ich "-fontconfig" bei mir aktiviere. Nur: warum klappte es, wenn ich mplayer in einem separaten Verzeichnis aufrufe? Weil es dort keinen "Fonts"-Ordner gibt. Dort ist eine Datei "fonts.conf" enthalten, die für diese ganzen Fehler sorgt. Ist diese nicht vorhanden, gibt's auch keinen Ärger mehr.

Meine Fragen sind nun: warum hat es früher funktioniert? (Denn nun führt ja auch die Installation des alten Packages zur "falschen" fonts.conf.) Was ist in der fonts.conf enthalten? Und funktioniert die Sache auf Lord Mulders Rechner mit der fonts.conf?

Noch ein Nachtrag: Wenn ich die Zeilen mit dem Tag "dir" aus der fonts.conf entferne, klappt alles. Ich habe versucht, den richtigen Ordner für die Windows-Schriften anzugeben, aber der wird nicht akzeptiert, ob ich nun / oder \ verwende. Lösche ich die Zeilen, klappt es, und die Schriftarten werden gefunden.
Lord Mulder: wenn das bei Dir mit der fonts.conf klappt, würde ich gerne wissen, warum (falls Du's weißt). Wenn es nicht klappt, entfern doch bitte die genannten Zeilen beim nächsten Release.

Nebenbei: die ganze Suche hat mich jetzt (mit gestern) ca. 3h gekostet. *hmpf*

Du hast recht. Ich habe gestern nicht mehr genau genug getestet. Untertitel gehen zwar wieder, aber nur in einer Standardschriftart (irgendwas mit Serifen). Also fontconfig ist wirkungslos bei mir... So ein Mist, es lief bis vor drei Tagen problemlos, auch mit genau denselben fonts.conf-Dateien (habe sie vorher noch verglichen). Ich komme nicht drauf, was ich geändert haben könnte, aber keines der aktuellen Releases läuft nun damit.

Mir bleibt wohl nichts anderes übrig als ein Bugreport - wobei ich eben nicht an einen Bug glaube, sondern eher daran, dass ich irgendwo im System ein Byte geändert habe... Bei Dir läuft's ja.

Okay, ich glaub ich hab den Grund rausgefunden, warum es "auf einmal" nicht mehr geht. Und zwar hab ich vorgestern mal "Spybot Search & Destroy" durchlaufen lassen. Der hat natürlich auch den Temp-Ordner gelöscht, in dem fontconfig seine Cache-Datei lagert. Wenn ich nun mplayer mit -fontconfig starte, wird eine neue solche Datei angelegt, aber die scheint ja wohl Fehler aufzuweisen.

Ich versuche mal, eine sehr viel ältere Revision zu verwenden, um einen validen fontconfig-Cache zu erzeugen. Vielleicht find ich da etwas.

Oder aber die Datei wird erzeugt und fontconfig findet seine Cachedatei beim späteren Laden nicht. Kann aber eigentlich nicht sein, denn er erzeugt sie doch auch im richtigen Verzeichnis? Ist bei mir [Dokumente-Ordner des Benutzers]\Lokale Einstellungen\Temp\fontconfig\cache, also gemäß Windows-Einstellungen der richtige Temp-Ordner.

Nachtrag: Verdammt! Die Cache-Datei wird jedesmal neu erzeugt. Warum denn bloß?!

Okay, sämtliche Revisionen, die mit fontconfig kompiliert sind, machen dieselben Zicken. Könnte vielleicht an einer Schriftart liegen, die fontconfig nicht passt, wenn er seinen Cache erstellt. Ich hab da schon was in Verdacht.

Yeeeeeehaaaaaaaw
Problem gelöst! Haha! Vielen Dank für den Hinweis auf den Thread in doom9.org. Dein Kommentar zum Temp-Ordner und fontconfig war die richtige Fährte.

Das Problem bestand tatsächlich in einer Schriftart, die fontconfig nicht passte. Ich hab sie aus dem Fonts-Ordner gelöscht, den Cache bereinigt und nochmal gestartet. Nachdem der Cache neu angelegt wurde, funktioniert es nun ohne weitere Verzögerung. Ach wie bin ich froh, dass nun alles wieder geht.

Lord Mulder: Du bist besser als ich im Englischen, vielleicht magst Du die Lösung im Thread auf doom9 posten. Auf jeden Fall hat es mir geholfen, nach "komischen" Schriftarten zu suchen. Bei mir waren es entweder ein paar Bitmap-Schriftarten (RM2000 & Co.) oder die TT-Schriftart "FreeSans". Ich hab (leider) beide gelöscht und erst dann geprüft, ob es geht.

Achso, ich nutze auch XP. Das Cache erstellen dauert wie gesagt nur knapp 2 Sekunden, hab auch nicht so wahnsinnig viele Schriften drin.

Das musst Du fontconfig fragen. Ich kann auf meinen vorigen Beitrag verweisen. Im Font-Ordner findet man .TTF (TrueType/OpenType) und .FON-Schriftarten (Bitmap). Entweder lag's an zwei bestimmten Bitmap-Schriften (stammen vom RPG Maker 2000) oder an "FreeSans", was zwar TrueType war, aber die hatte ich persönlich nicht installiert (war aber auch relativ neu, vom 5. Oktober). Ich hab die einfach mal auf Verdacht gelöscht, weil ich jetzt nicht unbedingt noch eine Sans-Schriftart brauche (die sah auch so nach Linux->Windows portiert aus) ... und siehe da, es geht.

Fontconfig und so geht alles, prima Sache. Ich hatte noch Probleme mit dem gl-Renderer, da wollte Deinterlacing (Yadif) erst nicht. Mit "gl (yuv)" geht es aber.