Beiträge von Flachzange

    So ich melde mich auch mal wieder. War ja zuletzt bei r190 hängengeblieben. Alles danach lief ja bei mir nicht. Jetzt wollte ich heute mal wieder updaten, aber die xine-lib will nicht bauen. Ab r215 erhalte ich beim Bauen folgenden Fehler:


    Warum xine-ui beim starten abstürzt ist mir ein rätsel.

    Also abstürzen tut xine nicht direkt, sondern es hängt beim Start.

    Kannst du mal die Verwendeten Software Versionen posten ?
    ( X + Libs, xine-ui, libva, xf86 intel treibet....) Ich sehe in deiner Signatur das du Suqeeze verwendest. Welche Quellen
    hast Du dort eingebunden ? ( /etc/apt/sources.list ). Vielleicht werde ich am Wochenende eine Squeeze zum testen installieren.

    Zu meiner Schade muss ich bekennen, dass die Signatur nicht aktuell war. Hatte in den letzten Wochen sehr viel gebastelt und geändert. Ich habe es mal aktualisiert


    Zu den Versionen:


    X: 1.9.2.901 (ist relativ alt, kann ich bei Zeiten mal aktualisieren; Die ganzen X packages und libs sind aus dem xorg edgers ppa)
    libva: GIT von dieser Woche
    xf86 intel treiber: GIT von dieser Woche
    mesa: GIT von dieser Woche
    xine-ui: SVN von dieser Woche
    xine-lib-vaapi: r199



    Da fällt mir gerade auf, dass ich parallel noch ein Ubuntu 10.10 minimal mit neuerem Kernel und X installiert habe. Das könnte ich noch mal testen.


    Grüße und Danke für dein Engagement!


    Christoph

    Hi ebsi,


    hatte jetzt noch mal Zeit zum Testen:


    Leider habe ich auch mit der aktuellen Version noch genau die gleichen Probleme: Egal ob ich das softdec aktiviert habe oder nicht, xinestart zeigt nur sporadisch und zufällig mal ein Bild nach dem Start. Es kann passieren, dass ich 5 mal hintereinander ein Bild nach dem Start bekomme und irgendwann geht es dann wieder nicht. Für mich nicht nachvollziehbar. Darüber hinaus raucht xine dann irgendwann auch ab, wenn es mal lief:


    Code
    xiTK received SIGSEGV signal, RIP.


    Ich kann es mir leider nicht erklären.


    Mein xine Aufruf:

    Code
    /usr/bin/xine  -f --post vdr_video --post vdr_audio  --post vdr --verbose=2 "vdr:/tmp/vdr-xine/stream#demux:mpeg_pes"


    Aber auch mit deinem Aufruf ist das Ergebnis identisch.



    Hier noch mal die Ausgabe, von der ich weiter oben mal geschrieben hatte, die auftritt, wenn man xine mit User-Rechten ausführt.


    Bei mir läuft die neue Version auch ohne die beiden Configs nicht. Sehr sporadisch erhalte ich nach dem Xine-Start ein Bild, spätestens nach dem Umschalten bleibt der Bildschirm aber schwarz und Xine hängt. Aufgefallen ist mir noch, dass im xine log etwa steht wie "video_out....no permission to raise nice level". da ich mittlerweile wieder zurück auf r190 kann ich den genauen Wortlaut nicht wiedergeben. Startet man als root bleiben die Ausgaben (sinnigerweise) aus, jedoch ist das oben beschriebene Problem nachwievor vorhanden.


    Vorsichtshalber habe ich noch mal den kompletten Treiber Stack und xine-ui aktualisiert, hilft aber auch nicht.

    Ich habe die Sourcen von VLC gecheckt. Das dort das Deinterlacing geht ist kein wunder. In VLC passiert es in SOFTWARE. VLC verwendet VAAPI nur für die Decodierung, jedoch nicht für die Anzeige. Wenn Ihr vergleiche macht bitte mit mplayer-vaapi durchführen. mplayer-vaapi ist mehr oder weniger die Referenzimplementierung und besser vergleichbar zu Xine. Meldungen über andere Player werde ich einfach ignorieren und nicht komentieren.


    Ich habe mich mit dem Entwickler vom Intel VAAPI Treiber in verbindung gesetzt und ihm die Probleme geschildert. Bin gespannt ob dort was rauskommt.

    Hi Ebsi,


    da habe ich mich wohl falsch ausgedrückt. Es ging mir nicht um den Vergleich mit dem VLC. Dass der das in Software mach ist klar, zumal ich das mit dem VLC unter Windows ausprobiert habe. Ich wollte nur für mich sicherstellen, dass das Deinterlacing in Xine nicht richtig funktioniert, indem ich das gleiche Material mal mit dem VLC und aktiviertem Software-Deinterlacing abspiele und mir den Unterschied anschaue. Meine Frage hier in die Runde sollte dann Aufschluss darüber bringen, ob ich bei mir irgendetwas falsch konfiguriert haben oder es ein generelles Problem ist. Deiner Antwort entnehme ich nun, dass es evtl. doch eher ein generelles Problem ist.


    Grüße
    Christoph

    So ich habe gestern nach längerer Zeit mal wieder ein Update deiner xine-lib gemacht. Das läuft schon wirklich gut und stabil. Auch das Spulen in Aufnahmen (h.264 und MPEG2) funktioniert sehr gut. Lediglich das leidige Thema Deinterlacing; es funktioniert bei mir nachwievor nicht vernünftig (MPEG2). Es spielt keine Rolle, egal ob ich 0, 1 oder 2 einstelle, das Bild sieht immer gleich aus. Hast du eine Ahnung was ich falsch mache oder woran es liegt?


    Ich hab mal zwei Testfiles (MPEG2) hochgeladen:


    Laufschrift auf N24: http://rapidshare.com/files/454607295/00001.ts


    Fussball im WDR: http://rapidshare.com/files/454610824/00001.new.ts



    Edit:
    Um es noch mal zu präzisieren: Das Deinterlacing scheint nicht zu funktionieren. Wenn ich die Aufnahmen beispielsweise im VLC Player öffne, sieht das Bild bei ausgeschaltetem Deinterlacing genauso aus wie xine + vaapi

    Zitat

    Original von ebsi
    Aktiviere das Tiling in der xorg.conf. Das beschleunigt erheblich.


    Code
    Option  "Tiling" "true"


    Mit aktiviertem Tiling sollte dann auch Deinterlace 2 nicht mehr ruckeln.


    Gracias, so läufts mit Bob flüssig. Ist vielleicht kein temporal/spatial aber akzeptabel.


    Zitat

    Original von ebsi
    Wen es intressiert der kann sich die Intel GPU tools installieren.


    http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/


    Mit intel_gpu_top kann man sich die GPU auslastung ansehen.


    cool, so etwas hatte ich schon gesucht, bringt nicht wirklich was, ist aber Interessant :)


    Gibt es eigentlich für deinen vaapi Branch, public git oder svn Zugriff? Bei der vielen Änderungen im Moment. wäre das praktisch.


    Mit dem aktuellen Entwicklungsstand bin ich echt zufrieden und meine Nvidia Karte kann jetzt einpacken.


    Edit: Das mit Bob klappt doch noch nicht so ganz, wie gedacht. Wenn ich einen beliebigen SD-Kanal mal so ca. 5min laufen lassen, ruckelt es irgendwann wieder. Nicht ganz so schlimm wie ohne "tiling", aber doch sehr störend. (r162)

    Zitat

    Original von ebsi
    Update :


    Habe die OSD handling logik überarbeitet, bassierend auf einem neuen VDPAU patch von der xine-devel ML. Unsclaed OSD's sollten nun in vdr-xine und xineliboutput funktionieren. Für vdr-xine muss ein workaround gemacht werden. Anbei das aktuelle Readme mit allen infos für die Konfiguraion.


    Cool, Danke! Das probiere ich heute Abend mal aus.


    Atechsystem
    Was das Deinterlacing angeht, glaube ich schon eine leichte Verbesserung zu sehen, wenn ich "Top Field" wähle, aber die ist minimal. Bei "Bob" ruckelt es noch. Testen kann ich den Deinterlacer nur mit SD-Kanälen.

    Zitat

    Original von Atechsystem
    Das Deinterleacing über die VAAPI Option funktioniert bei mir nicht. Option 2 (Bob) führt lediglich zu einem Auffälligen Ruckeln.


    Das kann ich bestätigen.


    WAs genau meinst du mit OSD wird est spät angezeigt? Bei mir ist es so, dass beim Umschalten das OSD erst in der nativen Streamauflösung angezeigt wird und erst dann in der skalierten Auflösung. Ansonsten konnte ich keine OSD-Verzögerung feststellen.

    Danke Wolfgang. Das hat geholfen!


    ebsi
    Das OSD sieht jetzt top aus. Wenn das mit xineliboutput laufen würde, wäre das die Ideallösung, denn da sind ja schon gute Software-Deinterlacer drin.


    Beim Deinterlacer 2 in vdr-xine ruckelt bei mir das Bild. Die anderen beiden nicht, sind aber auch nicht besonders schön.


    Danke erstmal, so ist vaapi jetzt auch im vdr wirklich nutzbar.

    Zitat

    Original von ebsi
    Man nehme das letze svn r150.
    Verwende vdr-xine.
    Unter den plugin Einstellung für vdr-xine stelle man "OSD Display mode" auf -> X11 overlay und betrachte das OSD.


    Muss ich da etwas spezielles beachten? Wollte es mal testen. Habe das standard vdr-xine 0.9.3 und das xine-ui von wbreu genommen.


    Stelle ich als Videoausgabe "vaapi" ein, so sehe ich wie der Treiber geladen wird, aber xine verabschiedet sich bereits beim Start mit


    Zitat

    xiTK has received SIGSEGV signal, RIP.

    Sehr cool, dass es mit der Entwicklung weiter geht. Danke ebsi!


    Ich habe gerade auch mal die aktuelle xinelib getestet (r148). CPU-Last und Leistungsaufnahme sind phänomenal niedrig. HD und SD läuft bei ersten Tests ordentlich. Lediglich


    Code
    # Priorität für Dekoder ffmpegaudio
    # numeric, default: 0
    engine.decoder_priorities.ffmpegaudio:1


    führt bei mir dazu, dass ich keinen Ton habe... Ideen?


    Hardware OSD ist bei HD und SD transparent und ruckelfrei, skaliert jedoch noch nicht korrekt.

    So, bei mir tut es jetzt auch mit compiz 0.9.2.1 und HUD und das Ganze auch ruckelfrei mit Singel Channel RAM. Das ist auf jeden Fall mal ein richtiger Fortschritt.


    Ich habe aber noch mal ein paar Fragen bzgl. der Compiz-Konfiguration


    1) Wenn ich OpenGL in Compiz nicht aktiviert habe, kann ich keine Fenster verschieben und das transparente HUD funktioniert nicht.


    2) Wenn ich OpenGL in Compiz aktiviert habe, dann habe ich ein transparentes HUD und Fenster lassen sich verschieben, aber ich seltsame Grafikfehler beim Verschieben von Fenstern (nach rechts). Siehe angehängtes Bild.


    Muss man beim Konfigurieren (mit ccsm) irgendetwas spezielles beachten? Gibt da ja nicht gerade wenige Optionen. Wie habt ihr das eingestellt (isbesondere wbreu)?


    Wäre echt cool, wenn ihr mir da Feedback geben könntet. Wenn das hinhaut, widme ich mich anschließend den neuen xine-lib vaapi Versionen.


    P.S. Als decorator habe ich den gtk-window-decorator angegeben.


    Danke und Gruß
    Christoph



    Nachtrag: Also nachdem ich jetzt mal ein paar Tage abends intensiver SD-Fernsehen geschaut habe (Fussball), ist mir aufgefallen, dass das Bild auch mit Compiz 0.9.2.1 nicht flüssig läuft. Das Ruckeln ist aber ein anderes und geht glaube ich eher in die Richtung, die inob beschrieben hat. Interessanterweise läuft die Laufschrift aus meinem HD-Testfile flüssig, was meine Vermutung bestärkt, dass sich das Problem auf SD beschränkt. Ohne compisition läufts sauber und das Bild wirkt viel besser und homogener.

    iNOB


    Hast du bzgl. deiner Ruckler bei langsamen Kameraschwenks mal


    Code
    video.processing.ffmpeg_skip_loop_filter:all


    gesetzt. Das führt bei mir dazu, dass ich


    1) Keine Ruckler mehr habe und
    2) keine Framedrops im log.


    Ob diese Einstellung Nachteile hat weiß ich nicht.


    Die von ebsi vorgeschlagene Kerneloption nohzf=off hat zwar einen ähnlichen Effekt, führt jedoch dazu, dass mein System im IDLE 37% mehr aus der Steckdose zieht (37 statt 27 Watt).


    Obiges gilt für ein System mit einfachem Fenstermanager (derzeit fluxbox) und ohne HUD. Jetzt müsste es nur noch mit composite engine laufen....