HD-VDR mit Intel HD Graphics - Testbericht zu vaapi

  • Hi nochmal,


    naja, ich vermute nicht, dass es an der ffmpeg-Einbindung liegt. Du hast irgendwo im setup des xineliboutput einen config-Punkt nicht gesetzt oder eben falsch.


    Aber trotzdem habe ich dir auf der bekannten vaapi-Seite mal ein bisschen die jeweiligen Flags dokumentiert.


    Link:


    Zudem die setup.conf-Parameter und die config-xineliboutput.


    Sag mal du hast aber schon dualchannel-Ram drinnen?


    externes oder internes ffmpeg ist wurscht....


    Schau auch mal nach ob die compiz-Plugins deaktiviert sind, nicht dass da ein Plugin dazwischenfunkt (--replace, wäre gut).


    Viel Spaß beim stöbern in den configs.


    So siehts bei mir aus, beim Umschalten:



    und danach ist Ruhe im Log!


    Gruß
    Wolfgang

  • Quote

    Original von Flachzange
    Ich bin mal gespannt. ob Frank es unter Natty hinbekommt.


    Kurzer Zwischenstand, Kiste rennt mit Natty, sehr cool, schon 2.6.38 im Repo, blöd, das fglrx Kernel-Modul läßt sich nicht mit dem Kernel bauen. Muß erstmal auf Lösungssuche gehen.


    Wolfgang, keine Angst ich möchte Deinen Thread nicht entern ... ;)


    Gruß
    Frank

    HowTo: APT pinning

  • Nabend zusammen,


    kurz zu meinem oben geposteten Script.. funzt nicht wie erwartet, also doch alles selber zusammentragen und bauen.. dann weiss man wenigstens, was man hat.


    xserver 1.9.3 läuft nun mit allem drum und dran, ausser libva 1.0.8 und libxine 1.2.
    Die letzten beiden wollte ich gerade bauen, aber der Link
    http://crystalhd.svn.sourcefor…nches/xine-lib-1.2-vaapi/
    scheint tot zu sein.


    Weiss da jemand was genaueres ? Meine Suche auf Sourceforge war nicht von Erfolg gekrönt.


    fnu
    Kurze Frage. Wenn du natty verwendest, woher beziehst du dann den VDR ? Aus den sourcen und selber patchen und bauen ? Oder bedienst du dich anderweitiger Repos ?


    Danke & Gruss
    Hoschi

  • Quote

    Original von wbreu
    Aber trotzdem habe ich dir auf der bekannten vaapi-Seite mal ein bisschen die jeweiligen Flags dokumentiert.


    Zudem die setup.conf-Parameter und die config-xineliboutput.


    Ich danke dir! Ich habe die mal mit meinen Settings verglichen. Die kritische Stelle scheint zu sein:


    Code
    1. # enable vblank sync
    2. # bool, default: 1
    3. video.device.xv_sync_to_vblank:0


    1) Wert 0 bei deaktiviertem Compiz/xcompmgr führt zu horizontalen Bildfehlern. Genau, dann wenn ich sonst die frame drops hätte.


    2) Wert 1 bei deaktiviertem Compiz führt zu den frame drops von vorher


    3) Werte 1/0 bei aktiviertem Compiz/xcompmgr führen zu ruckeln aber keine dauerhaften frame drops wie bisher Edit: Das Ruckeln ist übrigens ein anderes. Es ist gleichmäßiger, aber Kopfschmerzen macht es trotzdem :-) Im Prinzip ist das in etwa so wie bei meinen letzten Versuchen unter Ubuntu.


    Quote

    Original von wbreu
    Sag mal du hast aber schon dualchannel-Ram drinnen?


    Nein, ich habe nur ein Modul. Ist das tatsächlich relevant? Ich habe hier noch RAM,kann es also testen, aber das wäre schon ein Ding....


    Quote

    Original von wbreu
    Schau auch mal nach ob die compiz-Plugins deaktiviert sind, nicht dass da ein Plugin dazwischenfunkt (--replace, wäre gut).


    Compiz schlägt mir das replace vor....xcompmgr sagt nichts

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

    The post was edited 4 times, last by Flachzange ().

  • Quote

    Original von hoschi78
    xserver 1.9.3 läuft nun mit allem drum und dran, ausser libva 1.0.8 und libxine 1.2.
    Die letzten beiden wollte ich gerade bauen, aber der Link
    http://crystalhd.svn.sourcefor…nches/xine-lib-1.2-vaapi/
    scheint tot zu sein.


    Ist mir auch schon aufgefallen. Ich habe es mal auf rapidshare hochgeladen:


    http://rapidshare.com/files/445188506/xinelibvaapi.tar.gz

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

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

  • Quote

    Originally posted by Flachzange
    Ich habe es mal auf rapidshare hochgeladen:


    Prompter Service, vielen Dank :)



    Ich renn hier grad dennoch in ein Problem. Da meine Kompilier-Reihenfolge nicht der von wbreu entspricht, diese aber doch essentiell wichtig wäre. Nun wollte ich jetzt einfach nochmal "richtig rum" bauen.


    libx264 --> ffmpeg --> xinelib-1.2-vaapi --> xine-ui


    Als nächstes wäre das xineliboutput-Plugin dran.
    Hier kann ich mich nicht an die Kompilierdoku halten, da ich den VDR nie aus den Sourcen baue, sondern e-Tobi-Pakete verwende.


    Gut, mittels dpkg-source vdr-plugin-xineliboutput bekomme ich vdr-plugin-xineliboutput-1.0.6+cvs20110105.1949... recht aktuell.
    Nun sollte ein dpkg-buildpackage -us -uc für mich den Rest erledigen und ich sollte deb-Pakete haben.
    Der Befehl zickt aber rum. da libxine-dev als Abhängigkeit drin ist, welches nicht per aptitude installiert ist.
    Wird libxine-dev nicht mit xinelib-1.2-vaapi gebaut ? Wenn nein, kann ich libxine-dev aus dem Repo installieren ohne in irgendwelche Probleme zu geraten ? wbreu meinte letztens was von "bloss nicht mischen".


    Wenn die libxine-dev von nichts Abhängig ist, was ich in den Schritten vorher gebaut habe, dann müsste ich das Paket einfach installieren können. Sollten Abhängigkeiten zu den vorherigen Sachen vorhanden sein, dann sollte ich ansich auch libxine-dev per dpkg-source holen und neu bauen können. Sehe ich das richtig oder hab ich da nen Denkfehler drin ?


    Danke & Gruss
    Hoschi

  • Quote

    Original von hoschi78
    fnu
    Kurze Frage. Wenn du natty verwendest, woher beziehst du dann den VDR ? Aus den sourcen und selber patchen und bauen ? Oder bedienst du dich anderweitiger Repos ?


    Schau 'mer mal, will jetzt erstmal Xorg & ATI etc. zum laufen bringen. Das Problem mit 2.6.38, ist mit einem aktuellen fglrx-Treiber gelöst. Läuft aber immer noch nicht, Xorg stört sich an dem L4M Display im Gerät und crasht (segfault evdev_drv.so) aktuell noch ... ist schon so lange her das ich mal das Display konfiguriert hatte ...


    Regards
    fnu

    HowTo: APT pinning

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

  • Hoschi


    Wenn tobi source packages im repository hat, kannste dir doch eigentlich mit


    apt-get source vdr


    (bzw auch für xineliboutput)


    die sourcen zum vdr holen und die xineliboutput dann gegen deine xine-lib und den vdr von tobi bauen.

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

  • Den VDR selbst aus den Sourcen von Tobi zu bauen wollte ich eigentlich nicht, bzw. erschliesst sich mir grad nicht, warum ich das tun sollte.
    Mir ging es jetzt ansich nur um "vdr-plugin-xineliboutput", welches ich mit dpkg-source geholt hab.
    Wenn ich da ein dpkg-buildpackage mache, dann bricht das mit der Fehlermeldung ab, dass libxine-dev nicht installiert ist.
    Die Frage hierbei wäre nun, ob ich einfach die libxine-dev aus dem Repo installieren kann, oder ob sich das mit anderem "xine-Gedöns" beisst, bzw. ob von dem zuvor gebauten auch irgendwas in die libxine-dev einfliesst, so dass ein rebuild notwendig ist.


    Gruss Hoschi


    Edit:
    Ein apt-get build-dep vdr-plugin-xineliboutput möchte libxine-dev und libxine1-bin installieren. Würde also eher sinnbefreit sein, da ich ja die libxine-1.2-vaapi nutzen will. Ratlosigkeit macht sichbreit :D

  • Ja weil du das package mit dpkg-buildpackage bauen möchtest. Meine Idee war folgende (jedenfalls glaube ich das vor ein paar Jahren mal so gemacht zu haben):


    Du holst dir die vdr und xineliboutput sourcen aus dem Repository. Das wird dann irgendwo in /usr/source oder so abgelegt


    Den vdr brauchst du vermutlich selbst nicht bauen, aber der muss halt da sein, damit du xineliboutput *per Hand* bauen möchtest. Dann solltest du mit "make plugins" und "make install-plugins" das xineliboutput bauen und installieren können. Da das dann am dpkg vorbeiläuft hast du auch nicht die Paketabhängigkeit auf lib-xine.


    Ist nur eine Idee, aber vielleicht haben die anderen ja noch eine bessere.

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

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

  • Nabend hoschi78,


    nimm doch den Source aus dem xineliboutput-git vom vdr-developper, dann hast du das Problem nicht.


    Für alle die mal mit einer aktuellen xine-lib-1.2 inkl. vaapi-ffmpeg-Patch von ebsi testen wollen, habe ich die Sourcen bei mir auf die Homepage zum Download bereitgestellt. Zu finden ist das Paket hier:


    Link:


    Das Paket habe ich heute nachmittag frisch zusammengestellt und läuft bereits auf meinem Test-VDR im Wohnzimmer.


    Viel Spaß beim Testen damit!


    Gruß
    Wolfgang

  • Sodele.. eine Kompilierorgie weiter gugg ich nun wie n Schwein ins Uhrwerk.. nur dass es hier n bissi dunkler is :D


    Hab den kompletten Krams nochmal von vorn gebaut.. cairo wollte noch pixman haben.. lief alles sauber durch soweit.


    Die vdr sourcen hab ich von e-tobi mittels dpkg-source und xineliboutput hab ich von vdr-developer geholt und vdr/plugins/src gepackt.
    Anschliessend mit make plugins clean, make plugins gebaut und die libs auch entsprechend kopiert.


    Wenn ich nun vdr-sxfe allein oder den kompletten Aufruf mit allen Optionen

    Code
    1. /usr/local/bin/vdr-sxfe --video=xv --display=:0 -f --hud --audio=alsa:hw:0,3 --buffers=1000 --post="autocrop:use_avards_analysis=1,overscan_compensate=30" "xvdr+udp://127.0.0.1:37890" --reconnect --verbose > /var/log/vdr-sxfe.log &


    ausführe, brichts ab. Siehe angehängtes logfile.


    Hier fallen mir 2 Sachen auf.


    1) vdr-sxfe 1.0.90-cvs (build with xine-lib 1.1.90, using xine-lib 1.1.90)
    Das erschliesst sich mir nun nicht wirklich, da ich der Meinung bin, dass ich libxine-1.2 gebaut und installiert hab. ldconfig hab ich nicht vergessen.


    2) xine: Inputplugin gefunden: VDR (Video Disk Recorder) input plugin
    xine: Plugin kann MRL [xvdr+udp://127.0.0.1:37890#nocache] nicht öffnen
    xine: Kann kein Plugin für MRL [xvdr+udp://127.0.0.1:37890#nocache] finden


    Öhm.. ja !
    Ich sehe zwar, was da steht, kanns aber nicht wirklich deuten.
    Was fehlt denn ? Wenn ich den vdr starte, dann taucht xineliboutput mit in der Liste der Plugins auf.


    Any ideas ?





    wbreu
    Da das ganze nicht so gefruchtet hab, wollt ich auch mal deine sourcen nehmen und bauen, aber deine xineliboutput ind xine-ui bauen bei mir nicht. Ich bekomm hier




    Danke & Gruss
    Hoschi

  • Quote

    Original von hoschi78
    Öhm.. ja !
    Ich sehe zwar, was da steht, kanns aber nicht wirklich deuten.
    Was fehlt denn ? Wenn ich den vdr starte, dann taucht xineliboutput mit in der Liste der Plugins auf.


    Dann sind die libs am falschen Ort oder irgendetwas anderes fehlt noch. Ich nehme jetzt an, dass dein vdr automatisch nach Plugins sucht?!Was sagt denn syslog beim start des vdr? Vielleicht fehlt noch die allowed-hosts.conf oder so...



    Bei mir baut die xine-lib von Wolfgang, bringt jedoch keine Änderung (hatte ich aber auch nicht erwartet)

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

  • Moin zusammen,


    Flachzange ,


    sehe ich das richtig dass du sowohl compiz als auch den xcompmgr laufen hast?


    Dann würde ich sagen schmeiss mal einen runter, ansonsten beide und teste mal ohne --hud ob das Ruckeln imm er noch da ist.


    Wie sieht es denn aus mit zwei Ram-Modulen?, bei den Nvidia's ist das wichtig wegen Ram-Performance, der Ram wird auch von der GPU genutzt.



    hoschi78 ,


    - die xine-lib 1.1.90 ist die Entwicklerversion, die unter xine-lib-1.2 ausgerollt wird.


    - wenn der VDR/xine nach dem compile nicht die notwenidgen Plugins findet ist beim make install in die falschen Verzeichnisse installiert worden, oder es stimmen die Rechte auf die Dateien nicht. xineliboutput verlangt noch ein make install im ...xineliboutput-Verzeichnis bei den neueren Versionen.


    - Warum die xine-lib-1.2 bei dir nicht baut, hmm, welche gcc-Version läuft da?
    Die Meldung habe ich so noch nicht gesehen, hat auch nix mit der vaapi zu tun, sondern sieht so aus, dass vorher was schief geht.


    Gruß
    Wolfgang

  • Moin


    Quote

    Original von wbreu
    Flachzange ,


    sehe ich das richtig dass du sowohl compiz als auch den xcompmgr laufen hast?


    Nein, ich habe nur mal mit beiden getestet, weil compiz anfangs irgendwelche Zicken gemacht hat Das tuts aber jetzt sauber


    Quote

    Original von wbreu
    Dann würde ich sagen schmeiss mal einen runter, ansonsten beide und teste mal ohne --hud ob das Ruckeln imm er noch da ist.


    Stimmt, das hatte ich noch nicht getestet. Ich habe es gerade noch mal ausprobiert und es spielt keine Rolle, ob --hud oder nicht...gleichmäßiges ruckeln ohne drop frames im log. Was mich zudem stutzig macht sind die Bildfehler bei deaktiviertem vsync (compiz aus).


    Quote

    Original von wbreu
    Wie sieht es denn aus mit zwei Ram-Modulen?, bei den Nvidia's ist das wichtig wegen Ram-Performance, der Ram wird auch von der GPU genutzt.


    Nvidia?!? :-) Ich bekomme den Ram erst morgen, kann dazu also morgen Abend noch mal etwas sagen. Mich irritiert halt nachwievor, dass es im mplayer bzw auch xbmc sauber läuft.



    Jetzt sehe ich gerade in fett rot folgende Ausgabe (Auszug) auf der vdr-sxfe Konsole:



    Ist das auch normal?


    Gruß
    Christoph



    Nachtrag:


    Um ein paar Faktoren auzuschließen, habe ich mal meine G210 eingebaut und mein paralleles Ubuntu 10.10 gestartet. Habe dann deine neue xine-lib genommen und genau den gleichen vdr + xineliboutput wie bei den vaapi Tests. Das läuft alles glatt auch keine dieser seltsamen "h264" Ausgaben. Das ist Setup ist natürlich nicht 100%ig vergleichbar.


    Nachtrag 2: Ich bin da gerade über einen Beitrag von dir gestolpert, der genau das gleiche beschreibt :-)

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

    The post was edited 3 times, last by Flachzange ().

  • Mahlzeit,


    naja das kurze Log das du da zeigst, ist nicht sehr Aussagekräftig, aber soweit ich das sehe, wird da versucht zu ermitteln, was er als Decoder nehmen soll, das ist normal beim Umschalten, da er ja kurz keinen Stream bekommt.


    Hier mal ein Umschaltvorgang von Das Erste HD auf ZDF HD:



    Wenn der libva-Eintrag kommt, dann nimmt er die vaapi incl. Ausgabe darüber, für mpeg2 = SD, nimmt er ja nach wie vor xv als Ausgabemethode.


    Das Nvidia-Beispiel ist genau das was bei dir auch vorkommen kann => nur ein Modul, die Speicherbandbreite sinkt enorm und damit auch die Videoausgabeperformance.


    Wohin wird denn bei dir gesynct, hast du was konfiguriert? z.B. den DFP-0 vorgegeben. Ansonsten fällt mir nix mehr ein. Auch wenn es bei anderen Anwendungen läuft, was hilft es, wenn es unter xineliboutput nicht geht bei dir.
    Die Anwendungen sind zu verschieden, um sie zu vergleichen.


    Gruß
    Wolfgang

  • Okay, das war in der Tat ein Schnellschuss..Ich habe die Ausgaben auch nur beim Umschalten....ich warte jetzt erst mal ab bis ich den Speicher habe, dann melde ich mich noch mal.

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

  • Flachzange


    wenn man mal RICHTIG im logfile nachschaut, dann würde man auch sehen, dass sich nach laden des xineliboutput plugins bzw. beim initialisieren eben selbiges mit einen segfault beendet hat, was den VDR zum Dauerneustart veranlasst hat.... nuja, war spät gestern, aber Fehler zumindest mittlerweile erkannt. Nur mitm beheben wars bisher noch nix.



    wbreu


    Ich versteh die Aussage nicht ganz, bzw. könnte 2 Aussagen deuten.
    Heisst das nun, dass meine Version eine ältere ist und somit beim Bauen gegen alte libs gebaut wurde, sprich hier schon was schief gelaufen ist oder sollte das bedeuten, dass dass die libxine1.1.90 nur inoffiziell 1.2 genannt wird und somit hier erstmal alles in Ordnung ist ?



    Was das kompilieren vom xineliboutput-Plugin angeht, bin ich wie folgt vorgegangen, da die e-Tobi Sourcen vom vdr-plugin-xineliboutput als Abhängigkeit die libxine-dev haben, welche zumindest aus dem Repo als Paket nicht installiert wurde.


    Angelehnt an deine Kompilierdoku....


    cd /usr/local/src
    apt-get source vdr (von e-Tobi geholt)
    ln -s vdr-1.7.16 VDR
    cd VDR
    make clean-plugins
    make plugins
    cd /usr/local/src/VDR/PLUGINS/src/xineliboutput
    make install
    cd /usr/local/src/VDR/PLUGINS/lib
    strip *.*


    Dann die libs nach /etc/vdr/plugins.
    Die libs liegen bei mir alle in /usr/local/lib und/oder /usr/lib/vdr/plugins, also hab ich sie dorthin kopiert.


    Mit diesen libs renn ich in einen segfault.



    Ich werd sie wohl nochmal neu bauen und intensiv schauen, ob Fehler zu sehen sind.


    Wenn dir noch irgendwas "dummes" auffällt, dann bin ich für jeden Tip dankbar.



    Achja.. was ich "anders" mache ist ein make -j4 statt make, damits n bissi schneller geht.
    gcc ist version 4.4.5



    Gruss hoschi

  • Mach doch mal ein make && make install auf den vdr. Vermutlich liegt es daran, dass die packages von tobi anders gebaut sind, aber wenn du Pech hast laufen anschließend die anderen Plugins nicht mehr. Ein Versuch wäre es aber wert....

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2


  • Schau mal hier rein:


    http://hg.debian.org/hg/xine-l…e/a4776884f759/version.sh


    Alles klar?


    Gruß
    Wolfgang