Offiziell VDPAU mit AMD Grafikkarten

  • Ubuntu 12.04 LTS + LTS Trusty Enablement Stack ist erledigt. Um den Mainline-Kernel würde ich - wenn möglich - gern einen Bogen machen.


    Der 3.13.0er Kernel den du jetzt benutzt ist suboptimal, siehe Radeon OSS with vdpau (howto) - History im XBMC Forum:

    Zitat

    2014/02/24: Updated to kernel 3.13.5 this adds two important fixes for HD 7xxx and Kabini

    Und wie man dort nachlesen kann gab's danach noch weitere Fixes mit Kernel 3.15, sowie auch problematische Änderungen die erst mit Kernel 3.15.3 wieder herausgenommen wurden. Deshalb hab ich auch genau den genommen, siehe Link in meinem letzten Posting.


    blablubb@VDR-HD-Emmering:~$ sudo apt-get install xserver-xorg-video-radeon xserver-xorg-video-ati

    Damit versuchst du die Installation der Radeon Pakete für den Standard xserver von Ubuntu 12.04 OHNE die Benutzung eines der HWE Stacks. Das ist nicht das was du brauchst und das kann auch nicht funktionieren wenn du den Trusty Stack bereits installiert hast. Was du brauchst sind die Pakete xserver-xorg-video-radeon-lts-trusty und xserver-xorg-core-lts-trusty passend zum LTS Trusty Stack, und die hast du laut aptitude ja auch bereits drauf. Und soweit ich das anhand deinem xorg Log beurteilen kann wird auch das radeon Kernel-Modul zumindest mal geladen. Hast du die notwendigen radeon bzw. Kabini Firmware Dateien drauf? Die befinden sich im Paket linux-firmware-nonfree, und wenn noch was fehlen sollte siehe Link oben.


    Meine xorg.conf hab ich komplett neu erstellen lassen, so wie unter http://askubuntu.com/questions…g-conf-file/281685#281685 beschrieben. Ich hab lediglich kontrolliert ob in der Section "Device" der radeon Driver benutzt wird sowie den folgenden Abschnitt ergänzt um wegen dem bekannten Tearing-Problem das Compositing abzuschalten:

    Code
    Section "Extensions"
            Option "Composite" "0"
    EndSection


    Ob die Versionen im yaVDR Stable Repository ausreichen kann ich nicht genau sagen. Ich denke aber schon da man damit afaik ja SoftHDDevice mit VDPAU auf Nvidia-Basis auch problemlos nutzen kann. Voraussetzung ist auf jeden Fall dass du auch das Paket mesa-vdpau-drivers-lts-trusty installiert hast.

  • Also probiert hatte ich jetzt mal den 3.15.6er Mainline-Kernel. Pakete gezogen und mit dpkg -i installiert (PPA geht oder gibts da nicht?). Die Pakete xserver-xorg-video-radeon-lts-trusty und xserver-xorg-core-lts-trusty passend zum LTS Trusty Stack sind installiert, mesa-vdpau-drivers-lts-trusty ebenfalls.


    xorg.conf habe ich wie beschrieben erstellt und die eine Sektion ergänzt.


    Mit dem Konglomerat kam kein Bild. Da ich auch per ssh nicht mehr auf den VDR drauf komme, wird es wohl Probleme mit der Hardware (Ethernet-Onboard) im Zusammenhang mit dem Kernel geben. Ich werde mal schauen, dass ich auch testweise mal den 3.15.3er Mainline-Kernel installiert bekomme.


    Ist halt noch der wackelige Punkt mit SoftHDDevice aus dem yaVDR Stable- oder doch besser Testing-Repo. Ich weiss auch nicht, ob man sonst noch irgendetwas umbiegen müsste. Da gabs bei yaVDR doch diese /var/lib/yavdrdb.hdf in der die ganzen Einstellungen aus dem Webfrontend reingespeichert werden.


    Mal schauen, wie es weitergeht...

  • Mit dem Konglomerat kam kein Bild. Da ich auch per ssh nicht mehr auf den VDR drauf komme, wird es wohl Probleme mit der Hardware (Ethernet-Onboard) im Zusammenhang mit dem Kernel geben. Ich werde mal schauen, dass ich auch testweise mal den 3.15.3er Mainline-Kernel installiert bekomme.


    'Kein Bild' heißt kein TV-Bild vom VDR? Oder lief der xserver auch schon nicht?


    Zu dem Netzwerkproblem: Abgesehen davon, dass bei dem LTS Trusty Stack Firmware-Dateien für das r8169 Modul fehlen (diese hatte ich mir aus dem Debian Wheezy Paket firmware-realtek geholt), scheint da ab Kernel 3.13 irgendwas mit dem r8169 Modul für die Realtek NICs nicht mehr zu passen. Ich hatte nach dem Upgrade auf den Trusty Stack auf 2 verschiedenen Systemen ebenfalls Probleme damit. Bei der Realtek RTL8111DL auf dem MSI 785GM-E65 von meinem Produktiv-VDR half es das r8169 Paket zu Blacklisten und stattdessen das r8168-dkms Paket zu nutzen. Da dies aber momentan gegen Kernel 3.15 nicht mehr baut, war das für die Realtek RTL8111G auf dem MSI AM1I von meinem Kabini System aber keine Lösung. Nachdem ich bei dem System im syslog Fehler vom dnsmasq entdeckt hatte, konnte ich die Probleme dort vorerst damit gelösen dass ich dnsmasq im NetworkManager einfach deaktiviert hab. Nachträglich hab ich dann gesehen dass das hier z.B. auch geholfen hatte.


    Ist halt noch der wackelige Punkt mit SoftHDDevice aus dem yaVDR Stable- oder doch besser Testing-Repo.


    Daran sollte es dann jetzt auch nicht mehr scheitern :)
    Updates für yaVDR 0.5 stable: VDR 2.0.6, XBMC Gotham, Lirc usw.

  • Sodele,


    ...Du hast es in Deinem gestrigen Posting schon erwähnt, das yaVDR-Team hat mir mit den Updates in die Karten gespielt.


    Was soll ich sagen? Es kommt ein Bild und auch der Ton passt. :strike1


    ABER:


    Das Bild passt nur bei HD-Sendern und auch der Wiedergabe von HD-Aufnahmen. Bei SD-Sendern und der Wiedergabe von SD-Aufnahmen schaut die Schrift unleserlich aus und das Bild läuft abgehackt (sieht aus als ob es nur alle paar Sekunden aktualisiert wird). Ich meine, ich hätte hier in dem Thread irgendwann schon einmal etwas von Problemen mit MPEG1/2 gelesen. Könnte es das sein? An welcher Stellschraube müsste ich da noch drehen?


    Das SD-Problem besteht btw bei Verwendung des 3.13er-Kernels als auch beim 3.15.6er. Letzterer verursacht halt noch zusätzlich das Nichtfunktionieren des Netzwerkes mit dem Realtek-Chipsatz (hattest Du auch mit angerissen das Thema)...da würde ich mich aber erst drum kümmern wollen, wenn das SD-Bild auch rund läuft.


    Auf jeden Fall nochmals vielen Dank für Deine Unterstützung bis hierhin...vielleicht bekomm ich den Rest ja auch noch irgendwie hin?

  • Lass doch einfach mal qvdpautest lafuen und vergleiche die Werte mit denen aus dem xbmc forum.
    Es gibt ein paar Möglichkeiten warum es stottert.


    Lass mal zeitgleich glxgears lafuen, wenn es dann besser ist, hast du Probleme mit den Powerstates.

  • qvdpautest ohne glxgears:


    qvdpautest mit zeitgleich laufendem glxgears:


    Schaut irgendwie nicht danach aus, als würden sich die Werte groß voneinander unterscheiden? Welches Profil ist da nicht unterstützt? Könnte es daran klemmen?

  • Also ich finde die Werte sind sehr niedrig,


    zum Vergleich die Werte meines Athlon 5350



    Such doch mal nach Werten eines A4-5000 im xbmc forum und Vergleich die.

  • Hi,


    ich habe hier zum Test eine zbox nano aq01 mit amd kabini unter trusty und yavdr-unstable
    laufen, mit oibaf ppa und mainline ubuntu 3.16-rc7 kernel, ffmpeg 2.3 aus dem samrog131 ppa
    und softhddevice aus dem vdr-developers git, via vdpau,..


    softhddevice jeweils neu kompiliert ( mit trusty libva geht swresample nicht, daher ffmpeg)


    mit qvdpautest sind die Werte etwas besser als im XBMC Forum, aber die SD content Probleme sind
    auch bei mir weiterhin manifest, HD content läuft mit temporal aber wirklich gut,


    hier nur mal meine qvdpautest Werte mit 1920x1080@50p zum Vergleich:



    da muss noch ein anderer Effekt reinspielen,..


    viele Grüsse pbg4

    vdr1:Produktivsystem: Zotac Box mit Atom 525/ION 2.Generation yaVDR 0.6.1 und satip plugin, mit digibit r1/minsatip
    vdr2:Zotac CI-320 vdr für ARD radio transponder und VDR Aufnahmen server yaVDR 0.6.1,.. und weiterer minisatip-server + Hauppauge WinTV-Quad HD,
    vdr3: testsystem: Shuttle NC02U mit Skylake und Softhddevice VAAPI/HEVC für DVB-T2, Ubuntu Zesty, VDR von Hand auf Basis yaVDR,..
    vdr4: testsystem: Acer Laptop ES11-132 mit Braswell und Softhddevice VAAPI/HEVC für DVB-T2, Ubuntu Zesty, VDR von Hand auf Basis yaVDR,..

  • Kann gut sein das es an Ubuntu liegt.


    Ich habe es aus Opensuse laufen, mit mesa aus dem aktuellen Entwicklerzweig.
    Es läuft schon seit mehreren Monaten stabil, egal ob SD oder HD.


    Könnt ihr mal xbmc testen ?
    Ist da SD auch schlecht ?

  • Kann gut sein das es an Ubuntu liegt.


    Ich denke auch der Fehler liegt an irgendeinem Paket in Ubuntu.


    Ich habe die Installation testweiße mit Arch auf einem AMD Fusion am laufen und dort keine Fehler mit dem SD Bild.
    Zwar nicht im Dauerbetrieb weil dann doch die NVIDIA die bessere Bildausgabe hat, aber Probleme, abgesehen vom GRAB, habe ich keine.


    Gruß

  • Hi,


    das ist ja mal ein Hinweis, bei opensuse ist die mesa-devel derzeit bei 10.2.3 wenn ich das
    richtig gesehen habe, oder?? im oibaf ppa forum sind auch einige user unterwegs die seit
    dem Wechsel auf Mesa 10.3-git im oibaf ppa Stabilitätsprobleme hatten und wieder zurück
    auf mesa 10.2 wollen,


    auf der zbox nano aq01 habe ich im Augenblick folgenden SW Stand laufen:



    über environment Variablen kann ich auch zwischen Gallium mit llvm3.5, ohne llvm und reinem Software rendering umschalten,
    aber keine Änderung bei SD Content festgestellt,


    schade eigentlich, denn mit HD Content und sound über HDMI läuft die kleine box mit yavdr-unstable super ( XBMC muss ich noch testen)
    mit nur 11-12 W Stromverbrauch, im radeon wiki in der HW-Tabelle ist auch ein Eintrag, das der Kabini für einige features llvm 3.5 benötigt,
    das gibt es auch nur mit mesa 10.3 git, für 10.2 braucht man einen backport des llvm 3.5 patch, ... hmm,..


    viele Grüsse pbg4

    vdr1:Produktivsystem: Zotac Box mit Atom 525/ION 2.Generation yaVDR 0.6.1 und satip plugin, mit digibit r1/minsatip
    vdr2:Zotac CI-320 vdr für ARD radio transponder und VDR Aufnahmen server yaVDR 0.6.1,.. und weiterer minisatip-server + Hauppauge WinTV-Quad HD,
    vdr3: testsystem: Shuttle NC02U mit Skylake und Softhddevice VAAPI/HEVC für DVB-T2, Ubuntu Zesty, VDR von Hand auf Basis yaVDR,..
    vdr4: testsystem: Acer Laptop ES11-132 mit Braswell und Softhddevice VAAPI/HEVC für DVB-T2, Ubuntu Zesty, VDR von Hand auf Basis yaVDR,..

    Einmal editiert, zuletzt von pbg4 ()

  • So und ich kann auch nochmal nachlegen.


    System bei mir - wie erwähnt - ein aufgebohrtes yaVDR 0.5 mit den stable-repos und das Ganze auf das trusty-HWE-Zeug mit 3.13er Kernel hochgezogen.


    XBMC mit XVDR:


    Live-TV funktioniert hier problemlos sowohl mit SD als auch HD!


    Woran klemmt es dann jetzt? Fehlt da evtl. beim SoftHDDevice-Plugin irgendein Patch? Oder muss ich für SD noch an irgendeiner Konfigurationsschraube drehen?


    SoftHDDevice-Version:

    Code
    sudo apt-cache policy vdr-plugin-softhddevice 
    vdr-plugin-softhddevice:
      Installiert: 1:0.6.1rc1.git20140218-0yavdr4~precise
      Kandidat:    1:0.6.1rc1.git20140218-0yavdr4~precise
      Versionstabelle:
     *** 1:0.6.1rc1.git20140218-0yavdr4~precise 0
            500 http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu/ precise/main amd64 Packages
            100 /var/lib/dpkg/status


    Syslog nach dem Umschalten auf einen SD-Kanal:

  • Hi


    Eventuell hat dies ja auch etwas mit ffmpeg zu tun.
    Du benutzt aktuell ja eine Version von softhddevice mit GIT Stand 18.02.2014.


    Nach kurzer Recherge im Forum LINK schreibt attuska ja auch von Problemen bei SD Sender nach wechsel von ffmpeg auf eine Version höher als 2.2.


    Der Fix ist im GIT von softhddevice. GIT


    Ev. das Plugin auf neuesten Stand aktualisieren...


    Gruß

  • Ich würd auch auf ffmpeg tippen. Denn was mir aufgefallen ist: Boss666 nutzt mit yaVDR 0.5 ffmpeg. Ich nutze unter meinem Ubuntu + yaVDR PPA hingegen libav. Und bei mir läuft SD Material aber ja ohne Probleme, obwohl wir ansonsten seit der Aktualisierung des yaVDR Stable Repos ja quasi auf die gleiche Art unterwegs sind...

  • Hi,


    Boss666


    das mit dem umschwenken von ffmpeg auf libav geht ganz einfach beim kompilieren
    vom softhddevice mit make LIBSWRESAMPLE=1 oder 0, oder du lässt es die pkg-config Automatik
    im Makefile machen, nachdem libraries wie etwa libavcodec-ffmpeg-dev durch das jeweilige libav
    Äquivalent ersetzt wurden, das betrifft nur 4 -5 libs (aus dem Kopf, log files kann ich heute abend posten),
    man kann da problemlos hin - und hergehen,


    das Kompilieren unter trusty war OK, es gab aber zur Laufzeit dann Ärger unter trusty mit libav und softhddevice,
    deswegen musste ich bei softhddevice unter trusty bei ffmpeg bleiben, unter precise habe ich das nie probiert,


    viele Grüsse pbg4

    vdr1:Produktivsystem: Zotac Box mit Atom 525/ION 2.Generation yaVDR 0.6.1 und satip plugin, mit digibit r1/minsatip
    vdr2:Zotac CI-320 vdr für ARD radio transponder und VDR Aufnahmen server yaVDR 0.6.1,.. und weiterer minisatip-server + Hauppauge WinTV-Quad HD,
    vdr3: testsystem: Shuttle NC02U mit Skylake und Softhddevice VAAPI/HEVC für DVB-T2, Ubuntu Zesty, VDR von Hand auf Basis yaVDR,..
    vdr4: testsystem: Acer Laptop ES11-132 mit Braswell und Softhddevice VAAPI/HEVC für DVB-T2, Ubuntu Zesty, VDR von Hand auf Basis yaVDR,..

  • Hmm, komisch... Ich nutze ja libav weil Ubuntu 12.04 standardmäßig damit daher kommt. Allerdings ohne dass ich das SoftHDDevice extra dafür selbst gebaut hätte bzw. hätte müssen. Ich hab das ganz normale yaVDR Paket aus dem Testing PPA drauf. Wenn yaVDR 0.5 aber doch ffmpeg nutzt (oder etwa nicht?!?), müsste doch das SoftHDDevice demnach auch für ffmpeg gebaut sein. Aber wieso funktioniert bei mir libav dann trotzdem ?(


    Ich war sowieso gerade letztens erst hier im Forum auf das Thema libav/ffmpeg bei SoftHDDevice gestoßen und frage mich die ganze Zeit schon was denn für SoftHDDevice die bessere Lösung ist und warum? Soweit ich das jetzt sehe braucht's für ffmpeg unter Precise sowieso schon mal eine externe Paketquelle. Und für ffmpeg >= 2.2 brauchst's dann auch noch ein neueres SoftHDDevice als das aus yaVDR Stable bzw. Testing mit entsprechendem Fix. Lohnt sich der Aufwand überhaupt?

  • Unter yaVDR 0.5 wird softhddevice gegen libav gebaut. Unter trusty baue ich es gegen ffmpeg 2.x (aktuell wird das Paket gegen ffmpeg 2.2 gebaut), weil die neuere libav-Version Tonprobleme macht.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

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