Tearing mit xineliboutput opengl ohne Composite

  • Ich habe seit kurzem Tearing wenn ich vdr-sxfe mit der option --opengl starte. Vermutlich seitdem das HUD-Osd ohne aktives Composite genutzt wird, dabei ist es egal ob ich Composite in der xorg.conf aktiviert habe oder nicht.
    Ohne --opengl konnte ich gerade kein Tearing feststellen.


    Läuft das bei euch ohne Tearing? Falls ja was habt ihr gemacht? Wie sieht eure xorg.conf aus? Setzt ihr über export oder nvidia-settings irgendwlche Optionen?


    Edit: Hab was gefunden was mir zwar bei meinem Problem nicht geholfen hat, aber trotzdem sehr interesant ist um eine schlanke xorg.conf zu bekommen und Modelines benutzt welche der TV über EDID meldet: http://forum.xbmc.org/showthread.php?t=70068

  • Hi,


    Wenn ich mich nicht irre, dann bedeutet --OpenGL, dass auch die dekodierung über OpenGL geht. Ich benutze -V vdpau --hud:opengl und kann hierbei kein tearing feststellen. Compoziting verwende ich nicht.


    Gruß Doc_Hollywood

    Current:

    Hardware_: Gigabyte B360M D3H, Silverstone Milo ML03, DD Cine S2 V7A, 256GB Samsung EVO 970, 4GB RAM, ASUS GT1030 passive

    Software_: ArchLinux, VDR4Arch, VDR 2.4.0, softhdcuvid, nordlichtsepg, skinenigmang


  • Die Dekodierung läuft mit --opengl auch über vdpau, Die komplette Ausgabe wird aber in eine Pixmap geschrieben.


    Bei --hud=opengl wird die normale Ausgabe direkt ins Window geschrieben, sobald sich das OSD öffnet wird die Ausgabe in eine Pixmap umgleitet. Das funktioniert, wie du geschrieben hast ohne Tearing. Dabei entsteht aber ein kurzes Schwarzbild auf dem TV. Die Einstellung benutze ich jetzt als Workaround bis ich gefunden habe warum es mit --opengl nicht mehr geht.


    Auch mit einer älteren xineliboutput-Version bekomme ich es nicht mehr ohne Tearing zum laufen.

  • Ich verwende in den letzten Wochen in der Regel softhddevice (wäre das nicht auch was für dich?). Trotzdem verfolge ich die Änderungen bei xineliboutput und xinelib noch nebenbei, auch der aktuelle git-Stand läuft bei mir afaik ohne tearing (HDReady, VGA, 60HZ).


    Code
    export __GL_SYNC_TO_VBLANK=1
    export __GL_SYNC_DISPLAY_DEVICE="CRT-1"


    Code
    DISPLAY=:0.0 /usr/bin/vdr-sxfe --display=:0 "xvdr+tcp://127.0.0.1:37890" --video=vdpau --post="tvtime:method=use_vo_driver;autocrop:soft_start=0" --audio=alsa --fullscreen --reconnect --buffers=500 --hud --opengl --syslog


    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

  • Danke für die Richtigstellung :)


    Was hat es denn für einen Vorteil --opengl zu nutzen?


    Gruß doc_Hollywood

    Current:

    Hardware_: Gigabyte B360M D3H, Silverstone Milo ML03, DD Cine S2 V7A, 256GB Samsung EVO 970, 4GB RAM, ASUS GT1030 passive

    Software_: ArchLinux, VDR4Arch, VDR 2.4.0, softhdcuvid, nordlichtsepg, skinenigmang


  • Danke für die configs, war aber leider keine passende Einstellung bei die geholfen hat :(
    Ich frag mich echt was ich gemacht habe, da auch ein Rollback von xine-lib, xineliboutput, xorg.conf und dem NVidia-Treiber das Problem nicht mehr verschwinden lassen.


    Durch --opengl (wie auch --hud=opengl) ermöglichen ein Truecolor und ruckelfreies OSD mit xineliboutput. Vorteil von --opengl gegenüber --hud=opengl war das kurze schwarze Bild beim öffnen des OSD. Nachteil war bis vor kurzem durch aktiviertes Composite ein gelegendliches Mikroruckeln.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!