VDPAU und die "Hänger" bei HD. Wie ist der aktuelle Stand?

  • Hallo,


    so habe mich jetzt mal ein wenig mit der Problematik der "Hänger" beschäftigt.
    Untersucht habe ich das Problem mit einem 15 minütigen Ausschnitt einer 1280x720p Aufnahme aus dem ÖR mit dem sich die Hänger einigermassen verlässlich reproduzieren lassen.
    Die Aufnahme wird dabei direkt im xine player abgespielt, ist also unabhängig vom VDR bei der Wiedergabe.
    Die Hänger passieren auf meinen Systemen offenbar immer während die Verarbeitung innerhalb einer VDPAU Library-Funktion abläuft. Dabei verteilen sich diese auf unterschiedliche VDPAU Funktionsaufrufe. Das Problem ist also vermutlich im nvidia Treiber zu suchen womit meine Möglichkeiten der Analyse leider enden.


    Ich habe im Anhang mal einen Patch gegen die aktuelle hg Version der xine-lib-1.2 angehängt mit dem entsprechende Profiling-Funktionen für die VDPAU-Funktionsaufrufe hinzugefügt werden. Weiterhin modifiziert der Patch auch die Anzahl der vdpau display surfaces die in der vdpau display queue verwendet werden um überhaupt auf langsamen Systemen einen vernüftige Wiedergabe hinzubekommen. (Die Verbesserung ist auch schon lange im bekannten vdpau extensions patch von mir enthalten)


    Im xine log werden mit diesem Patch jetzt alle paar Minuten Statistiken über die Zeitdauer diverser VDPAU-Funktionsaufrufe ausgegeben. Treten ungewöhnliche Peaks (z.B. bei den Hängern) auf werden diese zusätzlich ausgegeben.


    Es wäre schön wenn Ihr auch mal mit diesem Patch testet um zu sehen, ob die Probleme auf euren Systemen in ähnlicher weise wie bei mir auftreten. Die xine logs dann bitte in diesem Thread veröffentlichen.


    Meine Testumgebung ist:
    nvidia Treiber 256.35, neuste xine-lib-1.2 (nur mit dem profiling patch versehen) und xine-ui hg version
    Systeme siehe Signatur


    Wer meine Testaufnahme probieren möchte schicke mir bitte eine PM.


    So sieht z.B. ein Hänger im xine log aus:


    Die Funktion vdpau_decoder_render:590 braucht hier zu viel Laufzeit.


    - durchflieger

  • Zitat

    Vielleicht ist es ja noch keinem aufgefallen, aber weitere "ich auch" Meldungen helfen nicht weiter, solange sie nicht auch Lösungsansätze erhalten. Was glaubt ihr denn, was wir mit den Posts machen? Statistiken erstellen? Gerald


    Es trägt nicht zur Lösung bei aber zeigt, dass es noch andere gibt die dieses Problem haben und es sich nicht um einen Einzelfall handelt. Ausserdem kann man meiner Auflistung unten entnehmen, dass es sich nicht um yavdr handelt - was ja evtl. auch helfen kann. Da du mich damit aber heute echt auf dem falschen Fuß erwischt hast werde ich hier nicht mehr zu dem Problem Posten.


    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

  • Zitat

    Original von Atechsystem
    Da du mich damit aber heute echt auf dem falschen Fuß erwischt hast werde ich hier nicht mehr zu dem Problem Posten.


    Schade, dass du dir den Schuh anziehst, da du ja konstruktives zum Thema bei zusteuern hattest. :(.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Hi,


    @all
    Jetzt bitte nicht gleich eingeschnappt sein. Es stimmt schon: Reine "me too" postings bringen uns nicht weiter. Alles, was nähere Details liefert allerdings schon. Im übrigen habe ich diesen Post auch absichtlich nicht im yaVDR-Unterforum eröffnet, da es kein yaVDR-Problem ist, sondern ein allgemeines.


    jrie
    Das war jetzt Quatsch. Hier geht es sowohl um xinelibouput als auch um vdr-xine. Es sind beide betroffen und durchfliegers Patch bezieht sich auf den gemeinsamen "Unterbau" die xine-lib 1.2


    durchflieger
    momentan wird scheinbar an zwei "Fronten" nach dem Fehler gesucht. Ich gebe mal eine Aussage von rnissl frei wieder (was hoffentlich o.k. ist). Evtl. ist das auch interessant für dich:


    In der Datei "/src/video_out/video_out_vdpau.c" hat er seinerzeit auf eine fehlerhafte "libxcb" reagiert, indem er guarded functions eingesetzt hat. Im Code der xine-lib 1.2 erkennbar an: "#define LOCKDISPLAY /*define this if you have a buggy libX11/xcb*/". Die in deinem Patch überwachte Funktion ist eine dieser guarded functions. Zwischenzeitlich haben wir eine libxine gebaut, die darauf verzichtet, da zumindest in Ubuntu Lucid der Fehler in der "libxcb" nicht mehr existiert. Die "Hänger" treten leider immer noch auf, aber der Watchdog bleibt jetzt stumm. Kannst du das bei dir nachvollziehen?


    Wie gesagt, wollt's nur mal weitergeben ;)


    Gruß
    Holger

  • Hallo,


    ich habe folgendes im Einsatz und keine Ruckler mehr:


    Treiber: 256.35


    aktuelle xine-lib und xine-ui aus dem HG resp. mit folgenden patchen:
    - xine-lib-1.2-stream-start-patch-100614.diff
    - xine-lib-1.2-vdpau-extensions-v11-20100612.diff


    ffmpeg-0.6


    aktuelle xineliboutput-cvs.


    Auflösung ist auf 1080p mit 50hz eingestellt.


    Das ganze läuft bei mir auf gen2vdr3.0beta7.


    Viele Grüße
    kaminkehrer

    VDRMB2 (Wohnzimmer) :
    Gehäuse: Activy 330 FP mit TTL Wandler am Serial
    Intel DH61BE ; Geforce GT630 ; 2x2GB ; CineS2 5.6 ; 128GB SSD ; 1TB HDD
    Harmony 650 ; Samsung UE40C6200
    - Gen2VDR 6.0 -


    VDRMB1 (Schlafzimmer) :
    Gehäuse: Activy 330 FP mit TTL Wandler am Serial
    Zotac ionitx G-E ; 240GB SSD ; CineS2 5.4 ; 2x2 GB RAM
    Harmony 650 ; LG 32LG450
    - Gen2VDR 6.0 -


    VDRMB3 (Test) :
    Gehäuse: Activy 300 FP mit TTL Wandler am Serial
    POV 330-1 ; 240GB SSD ; Mystique SaTiX-S2-PCI ; 2x2 GB RAM
    Harmony 300
    - Gen2VDR 6.0 -


    und weitere ...


  • Bei gesetztem LOCKDISPLAY verschärft sich das Problem nur weil jetzt langlaufende VDPAU-Calls durch die weitergehende Serialisierung mehr Threads im Player zum stillstand bringen. Lang laufende VDPAU-Calls treten aber mit oder ohne LOCKDISPLAY auf.


    Für die weitere Analyse wäre es sehr hilfreich, wenn Ihr Tests mit den profiling patch durchführt und die xine logs hier veröffentlicht. Das Profiling zeigt im log genau ob Probleme auftreten, unabhängig davon, ob diese auch wirklich sichtbar werden bzw. vom Tester auch gesehen werden (das Testen ist ja auch viel einfacher weil man gar nicht mehr zuschauen muss).


    Ich denke es läuft letztendlich auf eine Fehlermeldung direkt an den nvidia Support heraus. Dafür brauchen wir aber auch Testvideos mit dem sich das Fehlverhalten reproduzieren lässt. Deshalb am
    besten mit Aufnahmen testen und schauen ob sich die Probleme bei wiederholten abspielen sicher
    reproduzieren lassen.


    Gruss
    durchflieger

  • kaminkehrer
    Dann bist du vermutlich (wie scheinbar viele) nicht von dem beschriebenen Problem betroffen. Fakt ist -wie bereits geschrieben- : Mit dem 256.35 treten die Probleme nach wie vor auf. Der letzte problemlose Treiber ist der 195.30. Alles danach hat dieses Problem.


    durchflieger
    Du hast völlig recht: "Lösen" kann das Problem wohl nur Nvidia und für einen Bugreport, der sich auf eine schon seit einigen Treiberversionen existierende Regression bezieht, brauchen wir wohl jede Menge Stichhaltiges. Was schlägst du vor? Profiling Patch mit oder ohne LOCKDISPLAY?


    Gruß
    Holger

  • Mahlzeit,


    um einen exakten Bugreport abzuliefern solltet ihr diesen Post bei Nvidia beachten.


    Stephan Warren schaut sich das dann in der Regel sehr schnell an.


    Wichtig sind die Nvidia-debug-Ausgaben und das ganze sollte auf einer der betroffenen Maschinen laufen.


    Hier mal die kompletten benötigten Angaben:


    http://www.nvnews.net/vbulletin/showthread.php?t=123819


    PS: Mir gehts wie kaminkehrer, keine Probleme


    Gruß
    Wolfgang

  • Zitat

    Original von HolgerRDer letzte problemlose Treiber ist der 195.30. Alles danach hat dieses Problem.


    Wäre es dann nicht möglich einfach diesen Treiber zu verwenden? In yavdr oder anderen Distris ließe sich der doch sicher einfach einbauen. Oder ist der zu alt für die aktuelle xinelib?

    VDR: Mainboard: MSI B85M-G43; CPU: Pentium G3250 (Haswell); NVIDIA GT630 (GK208 Kepler); SanDisk SSD 64GB SDSSDP-064G-G25 + 500 GB HD; TV: DD Cine CT V6 - Twin Tuner Karte DVB-C (PCI Express Karte); atric USB eco Einschalter

  • Zitat

    Original von avanix


    Wäre es dann nicht möglich einfach diesen Treiber zu verwenden? In yavdr oder anderen Distris ließe sich der doch sicher einfach einbauen. Oder ist der zu alt für die aktuelle xinelib?


    Klar. Immer, wenn ich in Ruhe einen Film schauen möchte, verwende ich den 195.30 ja auch. Aber damit wäre das Problem ja nicht aus der Welt ;)


    Gruß
    Holger


  • Wie schon gesagt zeigen sich die Probleme im Log unabhängig davon ob LOCKDISPLAY benutzt wird oder nicht. Bei Systemen mit alter libxcb muss LOCKDISPLAY auf jeden Fall zugeschaltet sein.


    Nochmals hier der Hinweis das ich zum testen mein Testvideo bereitstellen kann. Schickt mir eine PM.


    Gruss
    durchflieger

  • Zitat

    Original von HolgerR
    kaminkehrer
    Dann bist du vermutlich (wie scheinbar viele) nicht von dem beschriebenen Problem betroffen. Fakt ist -wie bereits geschrieben- : Mit dem 256.35 treten die Probleme nach wie vor auf. Der letzte problemlose Treiber ist der 195.30. Alles danach hat dieses Problem.



    Holger


    Den 195.30 werde ich dann auch mal probieren.

  • weiß einer welcher im aktuellen yavdr 0.1 repo drin ist? Habe auf den HD Sendern auch diese Ruckler, insbesondere auf Sky Sport HD :(

    :vdr1 VDR User #626:fans
    VDR II: YeongYang A106, Fusi D1522, Celeron 2GHz, Frontend per DVB-s FF, 2xDVB-c, ATRIC-IR, YaVDR 0.3a
    VDR III HDTV: Inter-Tech 2008V mit iMonLCD, Atric, ASRock Extreme3 770 AM3, AMD Sempron 140 1x 2.70GHz AM3, 1,5TB WD15EADS, 2TB WD20EARS, 2x4GB DDR3-1600, NVidia GT520 passiv, 3x DVB-c, YaVDR 0.5 @ Samsung PS-50B550

  • Zitat

    Original von durchflieger
    Den 195.30 werde ich dann auch mal probieren.


    Und? Wie sieht's bei dir damit aus?


    Ansonsten:
    yaVDR 0.2 Nutzer finden im "unstable-vdr" Repository jetzt eine libxine inkl. Profiling Patch. Danke dafür hotzenplotz5 (der selber nicht mal von dem Problem betroffen ist). Damit sollte die Hemmschwelle zum munteren gemeinsamen Bughunting ein wenig niedriger sein.


    Gruß
    Holger

  • Das Problem muss definitiv bei xine liegen. Unter xbmc mit HD-Wiedergabe kenne ich diese Probleme nicht.

    :vdr1 VDR User #626:fans
    VDR II: YeongYang A106, Fusi D1522, Celeron 2GHz, Frontend per DVB-s FF, 2xDVB-c, ATRIC-IR, YaVDR 0.3a
    VDR III HDTV: Inter-Tech 2008V mit iMonLCD, Atric, ASRock Extreme3 770 AM3, AMD Sempron 140 1x 2.70GHz AM3, 1,5TB WD15EADS, 2TB WD20EARS, 2x4GB DDR3-1600, NVidia GT520 passiv, 3x DVB-c, YaVDR 0.5 @ Samsung PS-50B550

  • Zitat

    Original von HolgerR
    Ansonsten:
    yaVDR 0.2 Nutzer finden im "unstable-vdr" Repository jetzt eine libxine inkl. Profiling Patch. Danke dafür hotzenplotz5 (der selber nicht mal von dem Problem betroffen ist). Damit sollte die Hemmschwelle zum munteren gemeinsamen Bughunting ein wenig niedriger sein.


    reichts wenn ich mir von da das xinlib hole oder muss ich das komplette repo einbinden und mit apt-gte upgrade druberbuegeln ?


    gruss gerd

    vdr => p8b75-m lx / pentium g2020t / 8 GB Ram / zotac gt 630 / cine S2 V5.5 / 60 gb ocz ssd / 640 gb wd scorpio blue / display noritake 256x64-3900 / chenbro PC71023 gehaeuse / yavdr stable / softhddevice


    spielsystem => p8b75-m le / intel core i3 3220T / ubuntu lts 14.04 / 16 GB ram / zotac gt 630 / cine S2 V6.2 / yavdr stable pakete / softhddevice / pulseaudio+alsa


    spielwiese => Zotac Zbox ID45 / 120 GB mSATA / via Satip => Octopus Net / yavdr stable / softhddevice

Jetzt mitmachen!

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