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

  • EDIT:
    durchflieger hat die Sache mittlerweile besser einkreisen können und wir sind jetzt auf die Mithilfe von "Betroffenen" angewiesen. Bitte werft mal einen Blick auf diesen Post


    Hi zusammen,


    ich versuche nach wie vor, die Probleme mit VDPAU und dem "Standbild+Speedup" Problem zumindest so weit einzukreisen, dass man den libxine-Entwicklern was brauchbares zum Forschen liefern kann.


    Wenn man sich so durch die versammelten Foren wühlt, findet man natürlich alles Mögliche. Ich kämpfe mich jetzt schrittweise voran, um die vermeintlichen Lösungsansätze mal zu untersuchen. Ein stets wiederkehrendes Thema ist das berühmte "SCR-tuning". Patches und Erfolgs-, Mißerfolgsmeldungen sind aber jetzt auch schon ein wenig älter.


    An diejenigen, die sich näher mit dem Thema befasst haben:
    Wie ist denn der Stand? Gibt es einen auf das "SCR-Tuning" bezogenen Patch gegen aktuelle Versionen von xineliboutput/libxine der das "Standbild+Speedup Problem"* erfolgreich bekämmpft?


    Gruß
    Holger


    *PS: Ich vermeide absichtlich den Ausdruck "Ruckler", weil sich davon immer Leute mit ganz anderen Problemen angezogen fühlen. Diejenigen mit dem Problem, welches ich meine, wissen schon was mit "Standbild+Speedup" gemeint ist. ;)

  • HolgerR ,


    ich bin mir nicht ganz sicher ob ich wirklich das selbe Problem habe aber bei mir treten bei den HD Sendern des ÖR auch regemäßig kurze Hänger (ca. 1 bis 2 Sek. lang). Diese Probleme bin ich zur Zeit näher am Untersuchen.
    Könnte du dass von dir angesprochene Verhalten mal etwas näher beschreiben. Ich höre nich nicht zu den wirklich "wissenden".


    Gruss
    durchflieger

    Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 2x4TB HD, 2xDVBSKY S952, Ubuntu/V18.04, vdr 2.4.7
    Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V18.04, vdr 2.4.7+softhddevice, KODI 19, LG42LC2R LCD-TV
    Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV

  • Quote

    Original von HolgerR
    ich versuche nach wie vor, die Probleme mit VDPAU und dem "Standbild+Speedup" Problem zumindest so weit einzukreisen.


    Ich hatte genau dasselbe Problem - höchst mühsam.
    Wechsel vom Nvidia Treiber von 195.36.xx zurück zum Nvidia 195.30 hat bei mir geholfen.

    Mein VDR: Software: vdr 1.7.30 vdr-xine, xine-lib-1.2, Ubuntu 10.04, 2.6.35 Hardware: GT 220, TT-PCI S2-1600 + Mystique SaTiX-S2 V2

  • Quote

    Originally posted by sgp01


    Ich hatte genau dasselbe Problem - höchst mühsam.
    Wechsel vom Nvidia Treiber von 195.36.xx zurück zum Nvidia 195.30 hat bei mir geholfen.


    Ich habe mal ein wenig profiling code in der xine-lib eingebaut. Obwohl erst am Anfang meiner Analyse schaut es aber schon ein wenig nach Problemen im nvidia treiber auf da vdpau decoder Aufrufe teilweise bis zu 0,5s für ein frame benötigen. Ich teste mit dem ganz aktuellen Treiber.
    Werde dann auch mal im Verlauf ältere Versionen einbeziehen.


    Gruss
    durchflieger

    Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 2x4TB HD, 2xDVBSKY S952, Ubuntu/V18.04, vdr 2.4.7
    Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V18.04, vdr 2.4.7+softhddevice, KODI 19, LG42LC2R LCD-TV
    Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV

  • Danke euch beiden für den Input. Den 195.30er habe ich in der Tat noch nicht getestet, werde das aber nachholen.


    Hier dann doch noch mal der Versuch einer genaueren Beschreibung des Problems:


    Das Verhalten ist eigentlich nur auf HD Sendern zu beobachten, dort aber auf allen von mir empfangbaren (neben den ÖRs auch SKY HD). Die Abstände scheinen unregelmässig, und teilweise dauert es geraume Zeit (> 30 Minuten) bis zum ersten Auftreten. Manchmal treten sie aber auch schon binnen weniger Minuten nach dem Start auf. Sobald der erste Hänger aufgetreten ist, sind es mindestens 2 oder 3 pro Stunde.


    Die "Hänger" beginnen mit einem kurzen Standbild (1-2 Sekunden) das dann direkt in einen schnellen Bildvorlauf übergeht, der ebenfalls noch mal 1-2 Sekunden läuft. Der Ton läuft währenddessen ganz normal weiter. Es gibt weder vor noch nach einem Hänger Asynchronitäten. Auf der Konsole erfolgt währendessen die berühmt-berüchtigte Ausgabe "verwerfe Bild mit PTS...". Während dieser Phase kommt es auch zu einer erhöhten CPU-Auslastung (bei einem meiner Rechner dreht der CPU-Lüfter dann hörbar schneller). Ich habe das Problem mit einem ION-Board und einem MSI-Mainboard mit C2D. Dort verbaut wahlweise eine 8800 GTS oder eine 8400 GS. Fehler tritt mit beiden Karten auf. Problem besteht mit den aktuellen Versionen von xineliboutput+sxfe und vdr-xine+xine-ui gleichermassen. Unterbau ist die libxine1.2.


    Gruß
    Holger


    Gruß
    Holger

  • HolgerR


    danke für deine Beschreibung.
    Die gleichen Probleme habe ich auch.
    Ich melde mich wieder wenn neue Erkenntnisse vorliegen. Analyse läuft noch.


    Gruss
    durchflieger

    Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 2x4TB HD, 2xDVBSKY S952, Ubuntu/V18.04, vdr 2.4.7
    Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V18.04, vdr 2.4.7+softhddevice, KODI 19, LG42LC2R LCD-TV
    Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV

  • HolgerR


    ich hab's bei mir geregelt bekommen mit


    NVIDIA-Linux-x86_64-256.35-no-compat32.run


    ... das sollte ... so meine ich ... die aktuelleste Version sein.


    Damit konnte ich jetzt unter Kubuntu 10.04-64, yavdr und xbmc keine Ruckler mehr feststellen.


    Gruß


    Miru

    VDR-Server 2.0.6 yavdr-testing-repo - Kubuntu 12.04 LTS/64 - I-Dual-Core 2,2 GHz, 2 GB RAM, SATA 500GB, via NFS 2,9 TB HW-RAID5 an Sol10Sparc mit ZFS, 1x FF-TT 2.3 modded, 1x FF-TT 1.5, 2x TT-1600, via DLAN AVpro/Coax 4x 2x MVP Ver.D3A - VOMP 0.4.0 mit Media, MVP-Dongle 0.4.0
    Arbeitsplatz: 12.04 LTS/64 2.0.6
    yavdr-testing-repo - I-Dual-Core 2,4 GHz, 4 GB RAM, 2x 1TB, 2x TT-1600
    WAF-VDR-Client: openelec-3.2.4/XBMC-12.2-Frodo/ alternativ yavdr 0.5.0a: PulseEight-USB-CEC-Adapter, ZBOX-HD-ID41: 4GB RAM, 64GB SSD, 16GB Patriot-USB-Stick am Samsung UE37D5700 (gehackt) für TimeShift direkt am TV ohne VDR-Zugriff

  • Mit dem Treiber hab ich die Probleme auf meinem ION nach wie vor.

    Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 2x4TB HD, 2xDVBSKY S952, Ubuntu/V18.04, vdr 2.4.7
    Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V18.04, vdr 2.4.7+softhddevice, KODI 19, LG42LC2R LCD-TV
    Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV

  • durchflieger
    Vielen Dank! Hört sich vielleicht blöd an, aber das ausgerechnet *du* auch den Fehler hast, macht mir ein wenig Hoffung ;) Bin sehr gespannt, was du zu Tage förderst.


    Miru
    danke für den Tipp aber mit der 32bit Variante dieses Treibers besteht das Problem noch. 64bit ist leider keiner Option :(


    Gruß
    Holger

  • Wie gesagt, auf meinem Arbeitsplatz-Rechner DualCore 2.1 GHz, 4 GB RAM und 'ner 8400GS (nicht der Server aus der Signatur) läuft's jetzt echt Klasse ... gerade die WM-Spiele.


    EDIT: Sorry, dann kann ich Euch nicht helfen :-(

    VDR-Server 2.0.6 yavdr-testing-repo - Kubuntu 12.04 LTS/64 - I-Dual-Core 2,2 GHz, 2 GB RAM, SATA 500GB, via NFS 2,9 TB HW-RAID5 an Sol10Sparc mit ZFS, 1x FF-TT 2.3 modded, 1x FF-TT 1.5, 2x TT-1600, via DLAN AVpro/Coax 4x 2x MVP Ver.D3A - VOMP 0.4.0 mit Media, MVP-Dongle 0.4.0
    Arbeitsplatz: 12.04 LTS/64 2.0.6
    yavdr-testing-repo - I-Dual-Core 2,4 GHz, 4 GB RAM, 2x 1TB, 2x TT-1600
    WAF-VDR-Client: openelec-3.2.4/XBMC-12.2-Frodo/ alternativ yavdr 0.5.0a: PulseEight-USB-CEC-Adapter, ZBOX-HD-ID41: 4GB RAM, 64GB SSD, 16GB Patriot-USB-Stick am Samsung UE37D5700 (gehackt) für TimeShift direkt am TV ohne VDR-Zugriff

    The post was edited 2 times, last by Miru ().

  • Quote

    Originally posted by HolgerR
    durchflieger
    Vielen Dank! Hört sich vielleicht blöd an, aber das ausgerechnet *du* auch den Fehler hast, macht mir ein wenig Hoffung ;) Bin sehr gespannt, was du zu Tage förderst.


    Das kommt davon wenn man immer die neuste Version (xine-lib-1.2) haben will. :weinen


    Überigens habe ich die Probleme auch wenn ich das .ts File einer Aufnahme direkt mit xine abspiele. Das SCR-Tuning und Kommunikation xine/vdr sind ja dann aussen vor.
    Ist das bei euch genauso?


    Gruss
    durchflieger

    Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 2x4TB HD, 2xDVBSKY S952, Ubuntu/V18.04, vdr 2.4.7
    Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V18.04, vdr 2.4.7+softhddevice, KODI 19, LG42LC2R LCD-TV
    Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV

  • Quote

    Original von durchflieger
    Das kommt davon wenn man immer die neuste Version (xine-lib-1.2) haben will. :weinen


    Ich verschweige jetzt mal meine ganz persönliche Meinung dazu. :unsch Allerdings ist das Festhalten an der mittlerweile betagten libxine1.1 + den notwendigen Patches ja auch keine Lösung.


    Quote

    Überigens habe ich die Probleme auch wenn ich das .ts File einer Aufnahme direkt mit xine abspiele. Das SCR-Tuning und Kommunikation xine/vdr sind ja dann aussen vor.
    Ist das bei euch genauso?


    Danke für den Hinweis! Ich bin bisher nicht zum Testen mit "xine only" gekommen. Ich denke aber mal, dass es bei mir das selbe sein wird. Das war übrigens auch eine der Fragen, die mir rnissl gestern gestellt hatte (er kennt das Problem ebenfalls). Ein weitere Frage von ihm war, ob das ganze mit dem mplayer auch auftritt. Wie gesagt: bisher leider keine Zeit für den Test gefunden.


    Gruß
    Holger


    PS: Hattest du schon mit dem alten 195.30er getestet? Das wäre für mich das nächste auf der Liste.

  • Quote

    Originally posted by HolgerR
    PS: Hattest du schon mit dem alten 195.30er getestet? Das wäre für mich das nächste auf der Liste.


    Bisher noch nicht.
    Gruss
    durchflieger

    Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 2x4TB HD, 2xDVBSKY S952, Ubuntu/V18.04, vdr 2.4.7
    Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V18.04, vdr 2.4.7+softhddevice, KODI 19, LG42LC2R LCD-TV
    Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV

  • Hi,


    ich habe hier jetzt das "Problem", dass ich die Hänger nicht mehr herbeizaubern kann. Einzige Änderung war das Installieren der letzen Lucid-Updates von gestern. Das war nicht sonderlich üppig, einzig die Aktualisierung von "libc6" mit allem drumherum *könnte*(!!) dafür in Frage kommen (siehe UbuntuUpdates). Aber das ganze Thema ist so "voodoo" belastet, das ich mich da mit irgendwelchen Aussagen besser zurück halte. Es kann auch einfach nur Zufall sein.


    Fakt ist aber, dass hier momentan alles glatt und ohne Hänger läuft und weitere Tests meinerseits das Ergebnis im Moment nur verfälschen würden. Ich teste weiter, sobald die Hänger wieder auftreten ;)


    Gruß
    Holger

  • Hi,


    könntest du evtl. ein paar Daten zu deinem System Posten?


    Hardware (AMD oder Intel, welche Graka)


    die Versionen von:
    Kernel
    libc6
    Nvidia-Treiber
    xinelib
    ffmpeg
    alsa
    vdr
    vdr-plugin-xineliboutput & vdr-sxfe


    ...und die aktuelle config_xineliboutput.


    Bei mir muss z.B. vdr-sxfe mit dem Parameter "--buffers" gestartet werden, sonst wird die config_xineliboutput mit dem defaultwert "500" überschrieben. Ist aktuell auf "2500".


    Nimmste als Frontend überhaupt vdr-sxfe oder xine-ui?



    Gruß
    tec

  • Hi tec,


    hmm... das jetzt alles aufzulisten wird kompliziert. Verwendete Software ist yaVDR 0.2, Unterbau daher ein stinknormales Ubuntu Lucid 10.04 (tagesaktuelle Updates). Die "config_xineliboutput" ist auch yaVDR Standard (die Angabe von --buffers ist bei uns nicht nötig und bezieht sich ja eh auf das Pufferverhalten der -nicht betroffenen- SD-Sender). Die betroffenen Systeme sind wie gesagt unterschiedlich und die Probleme gelten für xineliboutput und xine gleichermassen.


    Falls es nicht ganz deutlich geworden sein sollte und bevor das hier in die falsche Richtung geht:
    Es geht mir hier auch nicht um das Lösen meines ganz persönlichen Problems, sondern darum, das neuerdings bestehende verbreitete Problem für die z.T. auch betroffenen yaVDR Nutzer zu lösen. Glücklicherweise konnte ich die "Hänger" bisher an meiner Hardware nachstellen. Ich bin also selbst betroffen, aber das steht für mich nicht im Focus dieses Threads.


    Gruß
    Holger

  • Da ich auch zu den "Leidenden" gehöre, ein paar Anmerkungen zum Fehlerbild, wie es sich bei mir darstellt, verbunden mit der Frage, ob das wirklich alles das selbe Problem beschreibt (was ich vermute), oder eher ein persönliches Spezialproblem (und damit OT) ist.

    Quote

    Original von HolgerR
    Die "Hänger" beginnen mit einem kurzen Standbild (1-2 Sekunden) das dann direkt in einen schnellen Bildvorlauf übergeht, der ebenfalls noch mal 1-2 Sekunden läuft. Der Ton läuft währenddessen ganz normal weiter.


    Bei mir tritt das in verschiedenen Varianten auf, mal genau wie beschrieben, mal zerfällt das Bild irgendwann stellenweise in Pixelhaufen (nicht wie bei einer Störung mit groben Artefakten, sondern in feine Pixelwolken die meist exakt ein bewegtes Objekt darstellen), mal gibt's statt Standbild eine blitzsaubere Superzeitlupe, mal eine weniger saubere Zeitlupe mit Geisterbildern (bewegte Objekte erscheinen doppelt), mal endet das Ganze endgültig mit einem Standbild.
    Bei letzterem Fall hat sich allerdings etwas geändert: in yavdr 0.1.x war vdr danach unbedienbar (restart von nodm und manchmal killall xine nötig), yavdr 0.2 wird (meistens) nur etwas träger in der Bedienung, sodass der Spuk sich durch Kanalwechsel beenden lässt (übrigens nur durch Wechsel auf SD- oder Radiokanäle, bei Wechsel auf anderen HD-Kanal merkt sich die Kiste, dass sie am Spinnen ist und macht auf dem neuen Kanal genauso weiter); gelegentlich hängt auch yavdr 0.2 komplett, befreit sich aber früher oder später selbst durch Neustart (sieht nach watchdog aus, manchmal löst der aber erst nach mehrmaligem Wechsel auf andere Konsolen aus).


    Quote

    Original von HolgerREs gibt weder vor noch nach einem Hänger Asynchronitäten. Auf der Konsole erfolgt währendessen die berühmt-berüchtigte Ausgabe "verwerfe Bild mit PTS...". Während dieser Phase kommt es auch zu einer erhöhten CPU-Auslastung (bei einem meiner Rechner dreht der CPU-Lüfter dann hörbar schneller).


    Bei mir gibt's meist einen Pufferüberlauf:

    Code
    1. vdr: [1145] buffer usage: 70% (tid=1144)
    2. vdr: [1145] buffer usage: 80% (tid=1144)
    3. vdr: [1145] buffer usage: 90% (tid=1144)
    4. vdr: [1145] buffer usage: 100% (tid=1144)


    Eins noch, auch wenn's vielleicht Haarspalterei ist: wenn ich von HD schreibe, meine ich eigentlich DVB-S2 - einsfestivalHD ist nämlich anscheinend nicht betroffen (verhält sich auch bzgl. "Umschalttrick" wie SD).


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

    The post was edited 1 time, last by NullP ().

  • Code
    1. Eins noch, auch wenn's vielleicht Haarspalterei ist: wenn ich von HD schreibe, meine ich eigentlich DVB-S2 - einsfestivalHD ist nämlich anscheinend nicht betroffen (verhält sich auch bzgl. "Umschalttrick" wie SD).


    Hi,


    jetzt wo du das so schreibst fällt mir auch auf, dass dieses Problem bei der Trailerschleife auf Einfestival HD nicht auftaucht. Bei mir verhält es sich genau so wie es hier beschrieben wird. Kurz stockendes Bild und dann wirds wie im Schnellvorlauf nachgeholt. Dieses Problem tritt nur bei 720p auf. Ton läuft normal weiter. Mnachmal hab ich den Eindruck es wird seltener wenn kein Dolby Dgital aktiv ist.


    Gruß
    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

  • Quote

    Original von Atechsystem


    Bei mir verhält es sich genau so wie es hier beschrieben wird. Kurz stockendes Bild und dann wirds wie im Schnellvorlauf nachgeholt. Dieses Problem tritt nur bei 720p auf. Ton läuft normal weiter.


    Ja, hier auch das Gleiche... Experimente hab ich dazu sonst noch keine gemacht... Alles original yavdr 0.2 mit aktuellen Updates


    Gruß,
    Robsta


    Hardware: Antec Fusion Remote Black, Asus P5N7A-VM, E5200, Mystique SaTiX-S2 Dual V2, Stereo-Atmo
    TV: Samsung UE32B6000, BenQ W1070
    Software: yaVDR


  • 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


    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