Beiträge von udobroemme

    Grundsätzlich wäre ich auch für ein Plugin aus 'einem Guss' und zwar aus verschiedenen Gründen:
    - Bei einer Client-Server-Lösung musste ich mich bisher immer mit dem Problem rumschlagen, dass evtl. der Socket noch nicht so weit war, wenn das Frontend starten wollte. Aus diesem Grund habe ich mittlerweile beim Xineliboutput-Plugin die Frontendlib mit eingebunden und sie hat bisher noch kein einziges Mal den VDR mitgerissen, weil sie abgestürzt wäre.
    - Als Medienplayer habe ich lieber die einfache und funktionale VDR-Oberfläche als viel grafischen Schnickschnack, den beispielsweise XBMC bietet. Deswegen nutze ich selbst mit Xineliboutput das Mplayer-Plugin, weil es so einfach zu bedienen ist und äußerst stabil läuft. Das neue Libva-Plugin sollte dann noch alle benötigten Slave-Kommandos implementiert haben, das fehlt mir momentan bei Xineliboutput.


    Andererseits bietet die Implementierung von Libva in die Xine-Lib viele kurzfristige Vorteile:
    - Wie man an Thomas' Bemühungen erkennen kann, sicher am schnellsten greifbare Ergebnisse, weil nicht an vielen Stellen das Rad neu erfunden werden muss.
    - Thema Deinterlacer: Da ja abzusehen ist, dass hardwaremäßig in die XVBA-Lib so schnell nichts implementiert wird, muss man halt, auch wenn es CPU-Zeit kostet, auf Softwaredeinterlacer ausweichen. Was nützt es, wenn nichts anderes Vernünftiges möglich ist? Auf jeden Fall bietet Xine über die TVTime-Deinterlacer für jeden Geschmack bzw. jeden CPU-Dampf passende Alternativen. Und wer mit der effektiv halbierten vertikalen Auflösung leben kann-will-muss, nutzt halt den BOB-Deinterlacer von XVBA.
    - Für alle, die eine eine Client-Server-Lösung wollen, gibt es Lösungen und man kann auch alles mit einem Plugin ohne extra Player-Frontend installieren.


    Allerdings hat die Xine-Lösung natürlich weiterhin die kritisierten Nachteile des schwer administrierbaren Kolosses, dessen Lib an vielen Stellen noch eine einzige Baustelle ist. Aber für die ersten Gehversuche begrüße ich sehr, dass erst einmal etwas Vorhandenes genutzt wird und hoffe, dass Thomas recht bald Zeit findet, an seiner Lösung weiter zu arbeiten :D


    Evtl. merkst Du es sehr schnell, weil das System nicht bootet. Ich hatte den Fall mit einem MSI-AM2-Board und einem AthlonII-Prozessor. Um das Bios-Update installiert zu bekommen, habe ich mir bei eBay für ein paar Euro einen AM2-Pozessor geschossen. Danach lief das Board einwandfrei mit der neuen CPU.

    Maybe you have patched 1.7.14 with yaepghd-Patch and didn't patch 1.7.13. The code with "SetVideoWindow' is only used with yaepghd-Patch. Look into the code of xineliboutput.
    I think

    Code
    SetVideoWindow

    is a typo. As far as I read the code it should be

    Code
    CmdVideoWindow

    Ich habe das Problem auch ab und zu. Momentan bekomme ich es nur gelöst, indem ich den Alsa-Daemon stoppe, die Datei /etc/asound.state lösche und dann den Alsa-Daemon wieder starte. Ggf muss im Alsa-Mixer der Digitalausgang danach noch unmuted werden.
    Was der Auslöser dafür ist, dass die Stereoausgabe nicht mehr funktioniert, habe ich allerdings auch noch nicht herausgefunden.

    Bei mir ging die Umstellung von FF-DVB auf VDPAU ratzfatz und ohne Probleme in weniger als zwei Stunden. Derzeit nutze ich noch VGA2SCART mit meiner Röhre, aber ich denke, dass der Aufwand, das Ganze mit einem HDMI-Ausgang zum Rennen zu bringen auch nicht viel höher sein kann. Derzeit habe ich nur noch ein Problemchen, nämlich dass der Alsasound manchmal stumm bleibt und ich deshalb dann die asound.state löschen und Alsa und VDR wieder neu starten muss.
    Die RGB-Bildqualität von VDPAU ist gegenüber der der FF-Karte schon mal um Meilen besser. Und soweit ich das mit meiner 82cm-Röhre beurteilen kann, funktioniert der Nvidia-Deinterlacer sehr gut (z.B. kein Ruckeln bei Laufschriften u. keine Intelaced-Artefakte).
    Wenn hier argumentiert wird, dass die VDR-Inatallation mit einer FF-Karte gegenüber anderen Lösungen sooo viel einfacher ist, stimmt das vielleicht für den aktuellen Zeitpunkt. Wenn ich mich aber fünf 5-8 Jahre zurück erinnere, gab es damals aber auch arge Probleme mit den FF-Karten (kein AC3-Sound über SP/Dif, ruckelndes Bild, stotternder und asynchroner Ton), obwohl diese sogar schon seit einigen Jahren lauffähige Linux-Treiber hatten. Erst als sich UFO die Treiber und die Firmware zur Brust nahm, verbesserte sich hier die Situation.
    Lange Rede, im Umfang arg begrenzter Sinn: Auch eine neue FF-Karte muss nicht unbedingt bedeuten, dass das Aufsetzen und Betreiben eines VDR-Systems mit ihr grundsätzlich einfacher und reibungsloser funktioniert als beisplielsweise mit VDPAU-Hardware.

    Vielen Dank. Jetzt läuft unter vdr-1.7.10 endlich wieder alles so wie unter vdr-1.6.x


    [edit]
    Übrigens muss für ein aktuelles ffmpeg in decoder.c in Zeile 85 und 92 die Variable

    Code
    PIX_FMT_RGBA32

    in

    Code
    PIX_FMT_RGB32

    umgewandelt werden.

    Grundsätzlich ist es begrüßenswert, dass die Videobeschleunigungsfunktionen meiner HD4850 nicht mehr brachliegen. Allerdings hat die Sache mehrere Haken.
    1. Man muss für xvba den Drecks-fglrx-Treiber nutzen. Bisher habe ich es nicht geschafft, diesen stabil ans Rennen zu bekommen. Bei jedem zweiten X-Start hängt sich der X-Server auf.
    2. Es gibt bisher keine Xine-Patches. Somit ist xvba bisher nur sehr eingeschränkt überhaupt nutzbar.
    3. Die Bildqualität bei den Videobeschleunigungsfunktionen des fglrx-Treibers kann alles anderes als überzeugen. So hat man u.A. mit Tearing-Artefakten zu kämpfen.


    Das alles sind für mich Gründe, auf Gallium3D, bzw. auf dessen State-Tracker, der die Beschleunigerfunktionen der 3D-Enigne nutzen wird, zu warten. Bis dahin bastele ich halt noch mit vdpau herum...