Beiträge von VdrMize

    Hallo cinfo,


    vielen Dank für Deine rasche Antwort. Generieren und Installieren hat prima geklappt. Nur am Ergebnis hat sich nicht viel getan ... (komisch, daß der dpkg immer noch die 1.5.1 Versionen anzeigt, aber das liegt wahrscheinlich an der Installation per make install ...)



    Hatte gehofft, daß es mit dem neuen Intel Treiber (und der libva) jetzt funktioniert. Leider ist das Verhalten unverändert - im va-api Modus kein Ton und waagrechte Kammartefakte im Bild; im va-api-glx Modus sofortiger Absturz (im i915 Treiber). Aber wahrscheinlich liegt es doch an etwas anderem (evtl. im softhddevice Umfeld, den anderen libva-Komponenten (die immer noch in Version 1.5.1 angezeigt werden), oder woran auch immer ...). Langsam gehen mir die Ideen aus.

    • Hab in dem Thread gelesen, daß manche SSD zu Problemen führen würde ???
    • Liegt es an der Nutzung von VDR 2.x ???
    • Vielleicht mal Euer System frisch auf der Platte aufsetzen.
    • Bei Euch läuft doch auch VDR mit SoftHdDevice, oder?

    Auf jeden Fall vielen Dank für Deine Unterstützung. Wenn jemand noch eine Idee hat - gerne.


    m.f.G.
    Michael

    Hallo Kollegen,


    ich kämpfe seit einiger Zeit mit VDR und dem Intel NUC (i3 Broadwell), und sehe daß Ihr den neuen Treiber bereits übersetzt habt. Könntet Ihr mir dazu bitte eine Hilfestellung geben, wie Ihr den Download angestoßen habt, und wie man den Treiber dann übersetzt? So einfach mit make Makefile ist es ja scheinbar nicht ... (sieht nach Automake aus, oder ist das noch etwas anderes?)???

    • Download: git clone -b master http://anongit.freedesktop.org/git/vaapi/intel-driver.git (nehmt ihr den master branch, oder den v1.6-branch?)
    • Übersetzen: cd intel-Driver, und dann??? Hab mir gerade automake installiert, aber der Aufruf automake bringt zahlreiche Warnungen/Fehler ...
    • Patches: Sind mit dem aktuellen 1.6´er Stand die bisherigen Patches überflüssig, oder habt Ihr weitere Patches reingezogen?
    • VA-API: Muß man mit dem selbst generierten Intel-Treiber weitere Pakete austauschen (VA-API), oder kann man einfach mal den Intel Treiber upgraden, um zu sehen ob seltsame Effekte (Kamm-Artefakte, Abstürze, etc.) behoben sind?

    Beim Generieren bekomme ich folgende Fehlermeldung:


    m.f.G.
    Michael

    Hallo zusammen,


    das mit den Aufrufparametern hat schon so gepaßt. Ich nehme die gleichen wie sie im "Announce VA-API/VPP Support" angegeben werden


    Code
    ~# vdr -P 'softhddevice -a hw:0,3 -d :0.0 -f -v va-api'
    ~# vdr -P 'softhddevice -a hw:0,3 -d :0.0 -f -v va-api-glx'


    Deshalb kurz drei Fragen:


    1.) VA-API läuft mit Streifen (Kammstruktur], VA-API-GLX stürzt ab (im i965_dri.so). Ich befürchte, ich brauche mit meinem Broadwell einen aktuelleren Intel Treiber (als den 1.5.1). Seit gestern/vorgestern gibt es jetzt den 1.6.0pre1 Stand. Hält der gerade bei Euch Einzug (und ich brauche nur noch ein paar Tage zu warten, dann kommt der automatisch), oder lohnt es sich für mich ihn vorab zu holen und zu generieren?


    2.) Wenn rofafor schreibt:


    Please, don't use these buggy v9/v10 patches, but Antti's git repo instead.


    wo finde ich Anttis repo?


    3.) Wenn in die Intel Treiber in letzter Zeit einige Workarounds / Fehlerkorrekturen eingeflossen sind, macht das obige V9/V10 Patches obsolet, oder braucht man die weiter?


    m.f.G.
    Michael

    Vielen Dank an Johns und Rofafor für Eure Antworten ...

    • Ich hab gestern mal den V10 Patch durchgeführt und damit getestet. Im Gegensatz zu meinem bisherigen Stand krieg ich keinen Ton mehr, und nach ca. 10 sec "gutem" Bild bekomme ich dann lauter wagrechte flackernde Steifen - eine Art Kammeffekt (ca. 10-15 Pixel breiter Streifen ist o.k., dann 10-15 Picel Breiter Streifen mit verfälschten Farben, der flackert; dann Streifen o.k; dann wieder Streifen der flackert usw.; die Streifen jeweils nur in Bildteilen; dort wo das OSD ist, ist kein Flackern zu sehen))
    • Ich hab dann mal den V9 Patch genommen, aber gleiches Ergebnis: Kein Ton, nach kurzer Zeit flackerndes Bild.

    Ich muß nach dem Urlaub - bin jetzt für 1 Woche weg - mal mit den Aufrufparametern experimentieren, und ggf. noch mal sehen warum bei dem Video.c der Patch immer um einige Zeilen verrutscht war (nicht daß meine Originalquelle nicht paßt ...)


    Wenn ich natürlich neben den Repos von fnu die von Antti nehmen könnte (zumindest wahrscheinlich für softhdddevice, oder?), falls die wirklich stabiler laufen, das wäre schon gut ...


    so long für today


    m.f.G.
    Michael

    Du benutzt den VA-API Patch für SoftHdDevice? [Announce] VA-API/VPP Patch for vdr-plugin-softhddevice - updated "v9"


    Ist das der "0001-Rudimentary-VA-API-VPP-support-to-softhddevice-v9.patch.txt" in dem angegebenen Thread?


    Ich suche gerade noch nach einer Anleitung, wie ich unter Linux diese Änderung in die Quellen von SoftHdDevice einpflege (hab Änderungen bisher immer händisch übernommen). Falls da jemand einen Tip hat, gerne.


    Mittlerweile lese ich auch von einem V10-Patch - soll ich mit meinem Broadwell NUC bei obigem V9 bleiben?


    m.f.G.
    Michael

    Jetzt weiß ich gar nicht, ob der automatisch mit im fnu repo mit dabei ist. Hatte ich mich einfach darauf verlassen. Ist das an den oben aufgelisteten SW-Ständen zu erkennen? Oder wie kann ich das checken?


    VA-Info zumindest bringt folgende Ausgaben:

    • Einen aktuellen libva-intel-driver/commits/17.vpp.vebox hab ich nicht gebaut ...
    • Und einen libva-intel-driver/tree/18.vpp.avs auch nicht ...
    • Und einen xf86-video-intel driver version 2.99.916 (or later) kann ich auch nicht finden ...

    Ich hab mich drauf verlassen, daß das in einem "xserver-xorg-video-Intel" (2:2.99.917+git1505171930.959598~gd~t) mit aufgegangen ist. Liege ich da richtig?


    m.f.G.
    Michael

    Der Absturz passiert in i965_dri.so (warum ???)


    SWRESAMPLE war bisher schon immer aktiviert, und libswresample0 (Version 7:1.2.6-1~trusty1) ist installiert. Das wurde nur im Log als fehlend angezeigt. Daran liegt es also gar nicht.


    Wie krieg ich die Ursache für den SegFault heraus (error 4 in i965_dri.so)???



    m.f.G.
    Michael

    Der Absturz passiert in i965_dri.so (vielleicht als Folge davon, daß SWRESAMPLE als auch AVRESAMPLE disabled ist ...)


    Fnu hat ja gemeint, ich brauche wahrscheinlich bei ffmpeg den SWRESAMPLE. Mal sehen wie ich SOFTHDDEVICE mit SWRESAMPLE Unterstützung gebaut bekomme ...


    m.f.G.
    Michael

    Die letzten zwei Monate bin ich leider beruflich voll ausgelastet gewesen. Jetzt über das lange Wochenende hab ich etwas Zeit gefunden, an meinem Intel NUC zu schrauben ...

    • Mit dem BIOS-Update auf 0247 (vom 15.04.2015) funktioniert jetzt auch der Parallelbetrieb SSD und Platte (von SSD booten, und da das eigentliche System drauf zu haben, und die Festplatte nur als Ablage für die Video-Files zu nutzen). Hatte schon befürchtet, daß Intel das nicht behebt ... (muß bei Gelegenheit mal die Leistungsaufnahme mit Platte messen)


    • Ich hatte das Gefühl, daß die Nutzung des VDR mit VA-API nach dem BIOS Update (wo auch Grafik BIOS Teile geupdatet wurden) stabiler läuft. Die Abstürze werden seltener. (Allerdings startet Ubuntu die grafische Oberfläche mit einer senkrechten Leiste links am Bildschirm, so daß der VDR beim Start nicht sofort im Vollbild-Modus angezeigt wird. Dementsprechend ist auch das Menü zunächst trapezförmig verzerrt. Erst ein Klick mit der Maus in das VDR Fenster bringt den Vollbild-Modus. Diese Umschaltung Vollbild-/Fenster-Modus ein paar mal gemacht, bleibt der Bildschirm dunkel. In irgendeinem Log-File kommt dann: "Pipe broken ...". Der Ton ist zwar noch da, aber der Rechner hängt total - ein Fall für Reboot aus der Konsole ... (an was kann das liegen?))


    • Jetzt möchte ich - wie Johns empfohlen hat - das VA-API-GLX zum Laufen bekommen. Hab gerade das SOFTHDDEVICE neu übersetzt (war noch ohne GLX gebaut). Im Syslog sehe ich auch eine glx-Version 1.4 die gestartet wird. Jetzt krieg ich einen VDR segfault .... (muß mal kontrollieren, daß ich keine Pakete von fnu mit Paketen von oibaf mische (wie fnu schreibt). Das kontrolliere ich als nächstes.


    Meine aktuellen SW-Stände:


    m.f.G.
    Michael

    Ich war zu voreilig ...


    Was ist wirklich installiert? (libswresample, aber ohne ffmpeg)



    Code
    root@Intel-NUC:# dpkg -l |grep ffmpeg
    ii  chromium-codecs-ffmpeg-extra                          40.0.2214.111-0ubuntu0.14.04.1.1069                 amd64        Extra ffmpeg codecs for the Chromium Browser


    Code
    root@Intel-NUC:# dpkg -l |grep resample
    ii  libswresample-dev                                     7:1.2.6-1~trusty1                                   amd64        Development files for libswresample
    ii  libswresample0:amd64                                  7:1.2.6-1~trusty1                                   amd64        FFmpeg video software resampling library


    Für ffmpeg hätte er zwar den ffmpeg aus fnu´s Repository (als Installationkandidat), aber der ist noch nicht installiert ...


    m.f.G.
    Michael

    Ich sehe nirgends Meldungen mit "video/vaapi" ist ffmpeg auch mit VA-API Support gebaut?


    Ich nutze das ffmpeg aus fnu´s Repository, und gehe davon aus, daß es mit VAAPI Support gebaut ist. Oder muß ich das auch hier streng trennen: mit VA-API und/oder VA-API-GLX Unterstützung gebaut ???
    Die "video/vaapi" Meldungen sind schon drin. Ich hab mal danach gegrept ... (im Log ist sogar ein GPU Hänger dabei ...)



    Ich bau das SoftHdDevice mal mit GLX Support (hatt ich die Tage abgeschaltet, weil es sich unter 14.04.2 nicht übersetzen ließ) und nehm das SWRESAMPLE gleich mit rein ...


    m.f.G.
    Michael

    Hallo Johns,


    Ich starte den VDR per Skript


    Bash
    #!/bin/sh
    #
    
    
    sudo /usr/bin/vdr -v /var/lib/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -P "femon" -P"softhddevice -v va-api"


    Da hätte ich gedacht ist va-api schon aktiv (siehe auch unten die Einträge im Syslog), und ob ich va-api oder va-api-glx nehme, ist bei i3 evtl. beides o.k. (Stimmt das nicht?)



    Was mich hier mehr erschreckt, die ganzen fehlerhaften Pakete (empty Video Packet, invalid PES Video Packet, unten ERROR: TS packet not accepted in Transfer Mode, und softhddevice clear) ... Oder kommt das bei anderen Usern genauso vor, und ist wahrscheinlich nicht die Ursache für den Absturz?


    Na ja der segfault in libvdr-softhddevice.so.2.2.0 ist auf keinen Fall gewünscht :)


    m.f.G.
    Michael

    Naja, bei 720p gibt es kein Bob, ...


    Stimmt. Darum ist das Bild bei HD schön ruhig. Bei SD flattert´s bei BOB wieder (oder immer noch, halt wie auch bei meinem 14.04.02). o.k.


    Chris Wilson has finally fixed the GPU HANG!


    Na ja, davon muß ich mich erst noch überzeugen. Vielleicht ist ja der J1900 Hänger behoben, aber wo anders hängt´s bei mir noch gewaltig ...
    Auch vorhin wieder, sieht aus wie wenn es einen Puffer von schon mal gerenderten Frames gäbe, der irgendwann mal leer läuft (so im Laufe von 1-2 Sekunden läuft Bild und Ton dann auseinander; Ton geht problemlos weiter, Bildschirm ist schwarz). Vorhin konnte ich aber abbrechen, dann


    Auch jetzt - da läuft ARD Standard (nicht HD): Anzeige im OSD SoftHdPlugin (darf man das benutzen, oder kommen damit die Fehler noch schneller?) - Frames verloren (0), verdoppelt (8620), übersprungen (0), Gesamt (79.800)
    10-15% verdoppelte Frames, da stimmt doch was nicht ...


    m.f.G.
    Michael


    p.s. jetzt ist er gerade wieder hart gestorben ...
    Im Syslog finde ich jede Menge Einträge


    So, nach "Nachtschicht" zurück auf Ubuntu 14.04.01. Hochgerüstet auf Kernel 3.19 (ohne Realtime Extensions). Auf Anhieb die aktuellen Pakete von fnu und oibaf gezogen. Stark! (Euch - und allen Mitstreitern - an der Stelle ein großeß Lob, und vielen Dank !!!)


    • Ein wahnsinnig scharfes, detailreiches Bild (bei HD); das Flattern von BOB am oberen Bildrand ist weg; bin ich eigentlich noch bei BOB ??? (hab aber an meinen VDR Startoptionen nix geändert, müßte noch BOB sein); mir kommt es vor, daß ich noch weniger Strom verbrauche (wie soll das gehen: BIOS auf Power-Mode, und nur 13,3 Watt in HD??? Neuer Kernel macht das?)


    • Aber: auch zwei mal Absturz, Bildschirm dunkel, Tastatur - nix geht mehr; nur über die remote Console ging noch Reboot; liegts am Kernel? an der swap Partition auf SSD? muß ich weiter verfolgen ...


    m.f.G.
    Michael

    Entweder oibafs PPA oder meines, beides zusammen führt nur zu Problemen.


    Das heißt, entweder Dein "vpp-vdpau-fnu" oder oibafs "graphics-drivers". Aber das generelle Problem ist doch, daß ich jetzt einen zu neuen XServer Version 1.16 habe, und sich das mit den bisherigen Ständen beißt ... (Richtig? Das krieg ich mit "vpp-vdpau-fnu" PPA entfernen nicht hin)


    Oder: du fragst im oibaf forum ... mal nach, ob er auch demnächst darauf umstellen will, ...


    Das hieße aber, alle die jetzt VAAPI testen, hätten den gleichen Aufwand zu treiben (alten XServer deinstallieren, neuen installieren; wenn demnächst plötzlich XServer 1.16 Pflicht wäre).


    Das macht mich kirre ... - trotzdem vielen Dank. Jetzt weiß ich, woran das liegt ... (das X64-ISO 14.04.01 ist gerade bei 77% download)


    m.f.G.
    Michael

    Bist du mit deinem System auf ubuntu trusty 14.04.2 LTS mit LTS enablement?,


    Code
    apt-cache policy xserver-xorg-core-lts-utopic
    xserver-xorg-core-lts-utopic:
      Installiert:           2:1.16.0-1ubuntu1.2~trusty2
      Installationskandidat: 2:1.16.0-1ubuntu1.2~trusty2
      Versionstabelle:
     *** 2:1.16.0-1ubuntu1.2~trusty2 0
            500 http://de.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
            500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
            100 /var/lib/dpkg/Status


    Du hast Recht, ich bin scheinbar bei xorg Version 1.16 ... Was heißt das nun?


    m.f.G.
    Michael

    Hallo fnu,


    das ist ganz komisch bei mir. Ich hab eine alte xserver-xorg-video-intel-lts-utopic exp1ubuntu4.2~trusty1 am Rechner. Die kommt von


    Code
    xserver-xorg-video-intel-lts-utopic:
      Installiert:           2:2.99.914-1~exp1ubuntu4.2~trusty1
      Installationskandidat: 2:2.99.914-1~exp1ubuntu4.2~trusty1
      Versionstabelle:
     *** 2:2.99.914-1~exp1ubuntu4.2~trusty1 0
            500 http://de.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
            100 /var/lib/dpkg/status


    apt-cache policy xserver-xorg-video-Intel gibt folgendes aus (findet die richtigen Quellen)



    Das Problem kommt dann beim Installieren (warum er hier zurückgehaltene defekte Pakete anmeckert ???):



    Meine Hypothese: "xorg-video-abi-15" gibt´s in Ubuntu 14.04.02 nicht mehr, dafür gibt's jetzt ein "xorg-video-abi-18". Für beide Pakete wird aber ein Ersatz angeboten (macht das resolver???), und das vermute ich führt zu weiteren Problemen



    Da steht jetzt der mit nur bescheidenen Linux-Kenntnissen ausgestattete Anwender voll auf dem Schlauch ... Aber vielleicht ist das ja für einen Spezialisten leicht herauszufinden ... (bin dankbar für jeden Tip)


    m.f.G.
    Michael

    Ich sehe hier gerade, daß ich nicht die aktuellen Treiber drauf habe - auch wenn ich das PPA von oibaf (und gerade auch noch das vpp-vdpau-fnu) in meinen Paketquellen mit drin habe. Klar, daß ich dann noch Effekte sehe, die vielleicht schon behoben sind ...


    Code
    mize@Intel-NUC:~$ dpkg -l xserver-xorg-video-in*
    +++-==============================-====================-====================-==================================================================
    un  xserver-xorg-video-intel       <keine>              <keine>              (keine Beschreibung vorhanden)
    ii  xserver-xorg-video-intel-lts-u 2:2.99.914-1~exp1ubu amd64                X.Org X server -- Intel i8xx, i9xx display driver


    Woran kann das liegen, daß ich die Pakete von oibaf nicht installiert bekomme ??? (dort gibt es ein 2:2.99.917)


    m.f.G.
    Michael

    daher ist es grad gut wenn man etwas mehr Silicon Power hat ...


    Das Gefühl hab ich auch, und so hab ich im BIOS mal die Stromsparoptionen von LowPower (ausgewogen) auf MaxPower gedreht, und hab das Gefühl, daß der Ärger beim Umschalten eines HD Kanal´s geringer geworden ist. Gerade als ich schreiben wollte, hab keinen Hänger mehr gesehen, hat es doch wieder für 2-3 sec. geruckelt, aber es läuft mit etwas mehr Power gefühlt deutlich "smoother" als vorher.


    Das kann bei mir auch daran liegen, daß ich den DVB-C Stick über USB anstecke, und ich nicht weiß ob die Abarbeitung des USB Stack´s parallel zum VDR die zeitlichen Rahmenbedingungen deutlich verschlechtert (zudem weil die Sundtek Treiber noch dazu im User-Space laufen). Eine DVB-Anschaltung über PCI-Express hat da deutlich geringere Latenzen (schätze ich mal).


    Nachdem ich jetzt einmal der Aufforderung nachgekommen bin, einen Error-Log zu verschicken, sind die Abstürze beim Hochfahren weg (ich bin mir jetzt gar nicht mehr sicher, ob das Abstürze waren, oder ob er Trace-Files von Abstürzen gefunden hat, und diese nur verschicken wollte).


    Ich würde mal einen neueren Kernel und Intel Treiber versuchen:


    Ich werde aus den angehängten Links nicht schlau. Da geht es zwar um ähnliche Fehlermeldungen, aber in welchen Kernel ist da eine Behebung eingeflossen? Auf welchen Kernel kann/sollte ich hoch, und welche Kernels sollte ich meiden (in dem J1900 Thread wird ja vor zu neuen Kernels gewarnt, da damit Fehler bekannt sind (wo ich nicht weiß ob die für Broadwell auch gelten, oder ob die Fehler mittlerweile behoben sind, und die Kernels genutzt werden können)


    m.f.G.
    Michael

    Das mit der Installation von Turbostat war scheinbar keine so gute Idee - ich krieg jetzt Abstürze (bei jedem Booten als auch zwischendrin) ...


    Code
    [drm] stuck on render ring
    [drm] GPU HANG: ecode 0:0x85dffffb, in vdr [2403], reason: Ring hung, action: reset
    [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
    [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
    [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
    [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
    [drm] GPU crash dump saved to /sys/class/drm/card0/error
    [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off


    Erkennt einer an den untenstehenden Paketen welche, die potentiell gefährlich sind (ermittelt mit cat /var/log/dpkg.log | grep "status installed")???


    Code
    man-db:amd64 2.6.7.1-1ubuntu1
    linux-tools-common:all 3.13.0-46.77
    libdw1:amd64 0.158-0ubuntu5.2
    libunwind8:amd64 1.1-2.2ubuntu3
    linux-lts-utopic-tools-common:all 3.16.0-31.41~14.04.1
    linux-lts-utopic-tools-3.16.0-31:amd64 3.16.0-31.41~14.04.1
    linux-tools-3.16.0-31-generic:amd64 3.16.0-31.41~14.04.1
    libc-bin:amd64 2.19-0ubuntu6.6


    m.f.G.
    Michael