Beiträge von RCf

    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.

    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.

    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.

    Ich kann von einem Mac OS (Intel Core2Duo-basiert) sprechen, auf dem der mplayer läuft. Dort werden zumindest 720p-Videos ordentlich abgespielt. Bei 1080p muss der Rechner allerdings manchmal passen, da mplayer (wie auch VLC) es nicht schaffen, die libavcodec multithreaded zu verwenden. (Ich weiß, dass es geht, weil unter Windows der KMPlayer es hinbekommt, aber das ist vermutlich umgeschriebener Code.)

    Mac OS ist Unix-basiert, also ich würde nicht kategorisch auch Linux davon ausschließen. mplayer wie auch VLC nutzen denselben Decoder (libavcodec) und sollten eigentlich unabhängig vom System überall ähnlich schnell funktionieren. Spezielle DXVA-Features, wie Du sie im anderen Thread beschreibst, werden hier allerdings nicht genutzt. Dazu fallen mir im Moment nur Windowsprogramme ein.

    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.

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

    Code
    ## 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*

    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:


    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.

    Hallo!

    Vor kurzen hatte ich mich schonmal mit einem Problem herumgeschlagen (siehe diesen Beitrag) und dachte da noch, es würde am Dateinamen liegen oder sowas ... eine Neuinstallation vom mplayer-Package hat ja geholfen. Nun hab ich weitere Videos derselben Serie und dasselbe Problem:

    Es sind Matroska-Container mit H.264-Video und zwei Vorbis-Tonspuren. Aber wenn ich diese Dateien öffne, erhalte ich folgende mplayer-Fehlermeldung:

    Code
    Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decodersMPlayer interrupted by signal 11 in module: init_audio_codec- MPlayer crashed by bad usage of CPU/FPU/RAM.  Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and  disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.- MPlayer crashed. This shouldn't happen.

    Spiele ich das Video mit "-nosound" ab, funktioniert es. Wenn ich "-novideo" setze, geht es auch. Und: bei einigen (nicht allen!) Dateien hilft es, den Video-Output auf andere Varianten umzustellen. Manchmal braucht es gl(schnell), manchmal gl2(yuv). Das heißt, es funktioniert mal nur mit dem einen und mal mit dem anderen Renderer. Und manchmal auch gar nicht (nichtmal mit DirectX). Sowas hab ich noch nicht erlebt ... was hat denn der Renderer mit der Tonspur zu tun? Und warum klappt die Verbindung aus Bild und Ton nicht? Das ist übrigens das erste (Matroska-)Video mit Ogg-Spuren, was mir unter die Nase gekommen ist, vielleicht hat diese Kombination noch keiner getestet...? ;)

    Zu meinem System: Windows XP SP2 mit Mulders MPlayer-Package. Das Problem tritt mit mplayer (Konsole) und mit den GUIs auf.

    Nachtrag: die einzelnen Tracks des Containers:

    Code
    [mkv] Track ID 1: video (V_MPEG4/ISO/AVC), -vid 0
    [mkv] Track ID 2: audio (A_VORBIS) "Ogg Ger 2ch", -aid 0, -alang ger
    [mkv] Track ID 3: audio (A_VORBIS) "Ogg Jap 2ch", -aid 1, -alang jpn
    [mkv] Track ID 4: subtitles (S_VOBSUB) "GER IDX", -sid 0, -slang ger
    [mkv] Track ID 5: subtitles (S_TEXT/UTF8) "GER SRT", -sid 1, -slang ger
    [mkv] Will play video track 1.
    Matroska file format detected.
    VIDEO:  [avc1]  704x576  24bpp  25.000 fps    0.0 kbps ( 0.0 kbyte/s)

    Am Dateinamen liegt es wie gesagt nicht. Die Option an sich hat auch keine Auswirkungen darauf gehabt. Ich hab die Datei sogar mal nach C:\ verschoben und 1.mkv genannt. Selbes Problem.

    Aber nun habe ich den neusten MPlayer-Pack installiert (von Ende September) und im Zuge dessen auch mal die Einstellungen löschen lassen. Nun geht alles wieder normal. Das Video lässt sich von überall aus abspielen. Keine Ahnung, was sich da verhakt hat ... Naja egal. Danke für die Mühe. :)

    Hallo!
    Da bin ich doch gerade auf ein sehr merkwürdiges Problem gestoßen, welches die beiden mplayer-GUIs SMPlayer und MPUI betrifft. Folgendes: ich hab hier ein Video, das hab ich in Verzeichnis A gelegt und erstmalig abgespielt. Lief gut. Nun hab ich das Video in ein anderes Verzeicnis verschoben, aber es kann nicht mehr gespielt werden, von keinem der beiden Player. Kriege diese Fehlermeldung:

    Code
    Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
    
    
    
    
    MPlayer interrupted by signal 11 in module: init_audio_codec
    ID_SIGNAL=11
    - MPlayer crashed by bad usage of CPU/FPU/RAM.


    Weitere merkwürdige Fakten:

    • Dieselbe Kommandozeile vom SMPlayer und MPUI funktioniert tadellos, wenn ich den mplayer manuell mit dem Parameterschwanz in der Konsole aufrufe (ohne -slave und -wid natürlich)
    • Egal, wie ich die Datei umbenenne oder irgendwo hin schiebe: sie funktioniert in den GUI-Playern nur in dem Verzeichnis, wo sie zum ersten Mal aufgerufen wurde. Es ist unerheblich, wie sie dort heißt.
    • Das Video hat eine H.264-Videospur und zwei Ogg-Tonspuren. Es ist das erste Mal, dass ich eine solche Kombination (in einem MKV-Container) abspiele. Könnte ggf. etwas damit zu tun haben.
    • Mein System: Windows XP, ich nutze das MPlayerPack von Lord Mulder.


    Weiß jemand, woran das liegt und wie ich das beheben kann? Der vom mplayer beschriebene Fehler im Log ist bestimmt Blödsinn hoch drei, weil es ja geht und nur am Verzeichnis liegt. Vielleicht werden irgendwelche Infos übers Abspielen gespeichert, und der Oggdecoder kommt damit nicht klar, wenn ich die Datei verschiebe? Das wäre natürlich sehr merkwürdig, aber ... naja, ist für mich absolut unverständlich. Wenn's nun an einer Option gelegen hätte (so wie AC3 über S/PDIF, was nur mit Trick17 geht), hätte ich es ja verstanden...

    Kann mir da jemand helfen? Wäre genial. Danke für alles. :)

    Die Aktualisierungsrate dürfte doch weniger vom verwendeten Encoder abhängen, sondern davon, wie oft LameXP die Ausgabe parst. Das Problem mit dem Puffer ist dann aber sehr ärgerlich.

    Zitat

    Und schließlich kannst du dir über das Menu "Erweiterte Optionen" auch in LameXP die Konsolenfenster anzeigen lassen...


    Hach, die besten Sachen entgehen mir wieder... danke für den Tipp! Der reicht schon völlig aus, jetzt hab ich GUI-Komfort und detaillierte Ausgabe. :)

    Hallo!
    Erstmal vielen lieben Dank für dieses tolle Programm. :) Es vereinfacht deutlich den Umgang mit den verschiedenen Audio-Encodern, gerade wenn man einen ganzen Batzen an Dateien kodieren möchte. "Alle unter einem Dach" kann ich nur dazu sagen, sehr gelungen. :)

    Dann hab ich nun eine Frage (wenn's nicht das passende Thema ist, bitte ich um Entschuldigung und ggf. Verschieben des Beitrags). Es geht um die Fortschrittsanzeige beim Kodieren. Die zeigt im Moment an, wieviele Dateien insgesamt schon kodiert wurden. Das ist nützlich bei vielen Dateien, aber sehr unpraktisch, wenn man nur 1 oder 2 Dateien hat, die dafür aber sehr groß sind (halbe Stunde bis hin zu mehreren Stunden). Da fehlt mir nämlich der Überblick, wie weit das Programm schon ist.
    Könnte man da nicht zusätzlich je einen Balken pro Kodierthread einbauen? Das wäre sicherlich etwas schwieriger, weil sich das Programmfenster mit steigender Threadzahl vergrößern müsste ... aber mir wäre das doch lieber, als wenn ich 5 Minuten lang auf "Encoding 0/1" schauen muss. :( Für diese Fälle nehme ich momentan lieber die Lame-Kommandozeile... also die geht auch, doch schön wäre so eine Anzeige in LameXP.

    Oder hier ein Kompromissvorschlag: wenn nur genau eine Datei zu kodieren ist, könnte man den Fortschrittsbalken von "x/y Dateien fertig" zu "x % fertig" umbasteln? Das wäre sehr praktisch.

    Danke für Kommentare, Hinweise und auch (begründete) Ablehnungen.

    Hallo!
    Seit einiger Zeit benutze ich den mplayer als Abspielprogramm und habe dabei gemerkt, dass ich meine Aufnahmen von Eins Festival HD (letztes Ostern) nicht abspielen kann. Die Sendungen wurden in 720@50p ausgestrahlt, mit H.264 kodiert. Ich habe sie als Transport Stream aufgenommen, mit h264tscutter geschnitten und dann nach Matroska verpackt.
    Andere von mir früher benutzte Programme (VLC, DirectShow-basiert mit CoreAVC und ffdshow als Codecs) haben diese Dateien anstandslos abspielen können, aber der mplayer hört nach einigen Sekunden auf und behauptet, die Datei wäre "zuende". Ich kann vor/zurückspulen, bekomme dann aber lustige Fehlermeldungen. Und auch dann ist nach wenigen Sekunden Spielzeit Schluss.

    Warum ich das in dieses Forum poste: die Fehlermeldung lässt darauf schließen, dass bei der Ausstrahlung eine besondere Art von H.264-Kodierung benutzt wurde. Ich kenne mich mit den Feinheiten dieses Codecs nicht aus, deshalb weiß hier vielleicht jemand Rat. Eventuell kann man den Fehler dann ohne Neukodierung beheben. Ein einfaches Neu-Muxen hat nicht geholfen.

    Hier ist die Ausgabe von mplayer, wenn ich bei einer solchen Datei durch die Gegend spule:


    Ich hab den Film gestartet und einmal um 10 Sekunden vorgespult. Dann kamen die "B Picture..." Meldungen. Nach 4 Sekunden Abspielen hat sich der Player dann mit "End of file" verabschiedet. Andere Matroska bzw. AVC-Dateien werden problemlos abgespielt. Das Problem bezieht sich nur auf die Aufnahmen von der DVB-S-Karte (nicht -S2).

    @stax0711:
    Vielen Dank für die Antworten. Gerade bei 1) bin ich ja beruhigt, dass VDubMod meistens nicht verwendet wird, obgleich StaxRip bei der ersten x264-Kodierung auf dessen Vorhandensein besteht.

    Schade, dass der NullMuxer/Encoder jetzt gar nix tut. Gibt es denn eine Alternative, die H.264 ohne Neukodierung schneiden kann (zumindest an IDR-Frames)? Naja, die Frage ist etwas offtopic...

    Hallo!

    Habe mir gerade Staxrip geholt und bin begeistert davon. Alles einstellbar unter einer schönen Oberfläche, gute Hilfestellungen, und man kommt irgendwie schneller zum Ziel, als wenn man alles selber machen muss (ProjektX, AVS-Skript erstellen, MeGUI einstellen, Sound schneiden und muxen etc.). Feine Sache!

    Nun ich hab aber auch zwei Fragen dazu:
    1) Wofür braucht StaxRip den VirtualDubMod, wenn ich ein Video nach AVC kodieren möchte? Ich meine, wozu braucht es das überhaupt, wenn es doch z.B. die DVB-S-Aufnahme mit ProjektX demuxt, mit AviSynth verarbeitet, mit x264 kodiert und mit mkvmerge zusammenfügt? Außerdem ist VDubMod doch längst veraltet und soll für Matroska-Container besser nicht genommen werden (hab ich hier auch irgendwo gelesen).


    2) Wie funktioniert der "x264 pass through" Modus, den ich unter Encoder -> Misc auswählen kann? Ich dachte, es ist endlich mal eine Möglichkeit, AVC-kodierte Dateien ohne Neukodierung zu schneiden, so wie man es bei MPEG2-Videos schon lange kann. Aber es klappt bei mir nicht so ganz. Den entscheidenen Schritt tut er nicht. (Wo kann ich rausfinden, welche Befehle bei einem StaxRip-Job ausgeführt werden?)
    Im Logfile steht dann z.B.

    Code
    "d:\Video\MKVtoolnix\mkvmerge.exe" -o "blubb_new.mkv" --track-name 0:Video --default-duration 0:50.000fps "blubb_new_EncoderOutput.264" --language 0:deu "blubb2_Cutting.ac3"


    Aber die neue Videodatei "blubb_new_EncoderOutput.264" ist nie erzeugt worden. Genau das würde ich aber gerne mal hinbekommen. Einfach ein ganz simpler Schnitt an einer AVC-kodierten Videodatei. Die Originaldatei ist ja als raw h.264 vorhanden. Wieso geht denn das nicht? mkvmerge kann das theoretisch sogar selbst, aber nur in Form von Splitting (und auch nicht framegenau...?).

    Wäre schön, wenn mich da jemand aufklären könnte, wie ich diese Option in StaxRip nutzen kann. Und Frage 1 natürlich auch.

    Danke für Ratschläge und Hinweise. :)