Softhddevice vaapi support

Es liegt hauptsächlich an Intel. Die Treiber sind der letzte Scheiss.
GPUs die seit Jahren auf dem Markt sind, werden noch nicht zu 100% unterstützt.
Die Treiber sind extrem instabil. Reaktion auf Fehlerberichte gleich Null. usw.

Nach Jahren gibts dann endliche eine API (VPP) die dann die Hardwarefähigkeiten unterstützt,
aber die Videotreiber können auch nicht mehr als die alte Version (Stand vor Weihnachten).

Ich hatte mit der Unterstützung der neuen API angefangen, aber nachdem es nicht weiter ging aufgehört.

Insgesamt fehlen viele Features der VDPAU Ausgabe in der VAAPI Version.

Die entacheidenen Probleme bei Intel sind.

• ruckelfreie Wiedergabe
• 24 Hz für VDR nicht wichtig
• Deinterlacer

Hin und wieder funktionierte VAAPI richtig gut und könnte NVidia gefährlich werden.
Bevor ich mir Sachen wie Raspberry Pi usw. antue, würde ich lieber zu Intel/AMD greifen.

XBMC hatte auch die Schnauze voll und hat nun auf Software Deinterlacer umgestellt.
Damit hatte ich auch schon angefangen, yadif Patch gabs hier im Forum.
Leider brauche ich dafür ein komplett anderes Ausgabekonzept mit mehreren Threads,
was mir zu viel Arbeit ist.

Da die aktuelle VAAPI Ausgabe nicht 100% sauber läuft, unterstütze ich die nicht.
Da keine Besserung der Treibersituation in Sicht ist, plane ich auch nicht weiter daran
zuarbeiten. Ich entferne nun VAAPI nicht aus dem Code und werde auch kleinere
Fehler beheben. Aber es ist weit von dem was ich als Gut empfinde entfernt.

Wenn jemand Lust hat, dies zu übernehmen, werde ich die Patche gerne aufnehmen
und auch helfen.

Als Alternative könntest du dir AMD/VDPAU ansehen.

Johns

Was das deinterlacen angeht haben die OpenELEC-Entwickler wohl jetzt einen gangbaren Weg gefunden. Ich habe mit einem Entwickler gesprochen. Sie lassen die CPU mit yadif das Deinterlacing machen und bekommen ein sehr gutes Bild. Yadif ist ja wohl so zwischen temporal und temporal spatial einzuordnen. Der Entwickler hat selbst ein System mit einem Celeron 1007 im Wohnzimmer. Dieser Celeron ist ja so ziemlich lowest end. Trotzdem hat er "nur" 50% CPU-Last. Weniger wäre sicherlich besser, aber richtig schlimm ist das ja auch nicht.

Wir sind beide sehr neugierig wie sich der DN2820FYK schlagen würde. 130 EUR ist ja ein Schnäppchen. Die CPU hat die doppelte Taktfrequenz, aber der GPU-Takt ist etwas niedriger. Zumindest die CPU-Last würde sich deutlich verringern.

Gerald

Der Celeron 1007 ist eine Billigvariante der Core-I Linie, während der gleichnamige Celeron im NUC DN2820FYK Atomtechnik ist. Die Marketingabteilung hat hier mal wieder ganze Arbeit geleistet. Ich tippe auf eine CPU Leistung auf Tabletniveau. VG Kurt

Ich hatte auch bei OpenELEC schon vermutet, dass das ein umgelabelter ATOM ist. Die Frage ist, wie wichtig für yadif die Features des Core-Is sind und ob die doppelte Takt-Frequenz eventuelle Defizite ausgleichen kann. Wird wohl die Zeit zeigen müssen.

Gerald

Der "Celeron 1007" ist aus der IVY Bridge Familie. Und kann von der Hardware alles was man braucht.
Die Treiber sollen angeblich auch alle Hardwarefeature unterstützen und ist die am Besten von VA-API unterstützte Intel GPU.

Das Problem bei meinen Letzten Tests (vor 1 Jahr) war, daß der Transfer der Daten von der GPU zur CPU fast die Gesamte zur Verfügung stehende Zeit verbrauchte. Beim schnellen überfliegen des XBMC Threads, haben sie das mit SSE4 optimiert, was aber unlogisch ist. Ein Speichertransfer ist schon seit Jahrzehnten optimiert. Ich vermute da ist etwas durcheinander gebracht worden. Ein yadif in SSE4 könnte etwas bringen.

Wer testen will, die aktuelle GIT Version sollte laufen, Software Bob und Software Spatial stehen zur Verfügung.

Johns

Hallo,

da die Hardware vorhanden ist, würde ich gerne softhddevice gerne einmal mit VAAPI (Haswell) testen.
Installiert ist Ubuntu-Server und das yavdr-ppa (stable) ist eingebunden.

Nun bin ich nicht sicher, welche Pakete ich brauche. Angeboten/installiert werden:

apt-cache search video-intel-
xserver-xorg-video-intel-dbg - X.Org X Server -- Intel i8xx- und i9xx-Anzeigetreiber (Debugsymbole)
xserver-xorg-video-intel-lts-quantal - X.Org X server -- Intel i8xx, i9xx display driver
xserver-xorg-video-intel-lts-quantal-dbg - X.Org X server -- Intel i8xx, i9xx display driver (debug symbols)
xserver-xorg-video-intel-lts-raring - X.Org X server -- Intel i8xx, i9xx display driver
xserver-xorg-video-intel-lts-raring-dbg - X.Org X server -- Intel i8xx, i9xx display driver (debug symbols)
xserver-xorg-video-intel-lts-saucy - X.Org X server -- Intel i8xx, i9xx display driver
xserver-xorg-video-intel-lts-saucy-dbg - X.Org X server -- Intel i8xx, i9xx display driver (debug symbols)


apt-cache policy vdr-plugin-softhddevice
vdr-plugin-softhddevice:
  Installiert: 1:0.6.1rc1.git20140114.1359-0yavdr0~precise
  Kandidat:    1:0.6.1rc1.git20140114.1359-0yavdr0~precise
  Versionstabelle:
 *** 1:0.6.1rc1.git20140114.1359-0yavdr0~precise 0
        500 http://ppa.launchpad.net/yavdr/testing-vdr/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

Kann mir jemand einen Tipp geben, welche Version empfehlenswert ist?
Softhddevice muss ich wohl mit vaapi-support selbst bauen, das hab ich schon gesehen.

Gruß,
Hendrik

Moin,

noch ein Hinweis zur Intel NUC Hardware:
Ivy Bridge Celeron 847 -> http://geizhals.at/intel-nuc-b…blkdcp847ske-a902562.html

Munter bleiben, Rossi

Na dann werde ich mal dokumentieren.
Kernel ist 3.12.

aptitude output: http://pastebin.com/raw.php?i=qzM9xwnE

Gruß,
Hendrik

Hallo Martin,

ja, nun.. Bei den Kernel-Paketen darf man ja auch ruhig eine neuere Version installieren und ich gehe mal davon aus, dass mir die Paketverwaltung auch nix anbieten würde, was nicht kompatibel zum Kernel ist?!

Ich hab derweil softhddevice mit vaapi kompiliert. So geht's:

2063  cd ~
 2064  mkdir softhddevice
 2065  cd softhddevice/
 2066  apt-get build-dep vdr-plugin-softhddevice
 2067  apt-get source vdr-plugin-softhddevice
 2071  sed -i s/#VAAPI/VAAPI/ ./vdr-plugin-softhddevice-0.6.1rc1.git20140114.1359/Makefile
 2072  dpkg-buildpackage -us -uc -nc
 2075  cd vdr-plugin-softhddevice-0.6.1rc1.git20140114.1359/
 2076  dpkg-buildpackage -us -uc -nc

Gruß,
Hendrik

Hm...
das wird so noch nix

/usr/bin/vdr -v /srv/vdr/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -P"softhddevice -v va-api"  -P"live --port=8008 --ip=0.0.0.0"
INFO: validating live server ip '0.0.0.0'
libva: VA-API version 0.32.0
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
libva: va_openDriver() returns -1

Da werd ich mal recherchieren müssen.

Gruß,
Hendrik

Hast du auch den Intel VA-API Treiber installiert?

x11-libs/libva-intel-driver

Außerdem sieht mir Version 0.32 falsch aus, aktuell ist libva 1.2.1, wie die sich auf die API Version umrechnet kann ich im Moment nicht prüfen, habe aber 0.33 oder sogar 0,34 in der Errinnerung, muß aber nicht sein.

Johns

Hallo Johns,

ich denke, unter Ubuntu ist das Äquivalent
dpkg -l |grep libva-intel-vaapi-driver
ii libva-intel-vaapi-driver 1.0.15-1ubuntu2 VAAPI driver for Intel G45 & HD Graphics family

Wenn ich mir dies ansehe https://launchpad.net/ubuntu/+source/intel-vaapi-driver dann zeigt sich, dass diese Version von 2012 ist.
Für aktuellere Ubuntu-Versionen gibt es neuere Versionen.

Ich mache mal einen eigenen Thread für dieses Thema auf (hier).

Gruß,
Hendrik

Hallo,

ich versuche mal die OS-Fragen im Nachbar-Thread (s.o.) und die softhddevice-Fragen hier zu posten.
Was hat das hier zu bedeuten?

Jan 22 20:16:12 homeserver vdr: [26371] ERROR: TS packet not accepted in Transfer Mode
Jan 22 20:16:12 homeserver vdr: [26371] [softhddev]Clear:
Jan 22 20:16:12 homeserver vdr: audio: flush out of ring buffers
Jan 22 20:16:12 homeserver vdr: [26371] ERROR: TS packet not accepted in Transfer Mode
Jan 22 20:16:12 homeserver vdr: [26371] [softhddev]Clear:
Jan 22 20:16:12 homeserver vdr: audio: flush out of ring buffers

Gruß,
Hendrik

Ich vermute mal, daß keine Hardwaredekodierung erfolgt und dadurch die Puffer volllaufen.

vdr: [26371] ERROR: TS packet not accepted in Transfer Mode

Kommt wenn das Plugin keine Daten mehr annimmt. Der Clear sollte aber eigentlich diese Puffer löschen, damit der Fehler sich selbst behebt.

Ansonsten hatten die Intel GPU die Angewohnheit sich aufzuhängen.

Such mal nach "video/vaapi: gpu hung" im Log.

Johns

Hallo Johns,

es funktioniert jetzt alles bei mir.
Der X-Server läuft mit 50Hz, softhddevice gibt Bild und Ton auf dem selbst gestarteten x-server (option -x) und die o.g. Fehler im Log sind auch nicht mehr da.

Die CPU-Last ist gering -unter 10%.
Das Bild ist meist sehr gut. Manchmal fallen mir aber folgende Mängel auf:
- Das Bild zittert etwas nach oben und unten ( --> SoftHDDevice - Bild zittert und Bildqualität ist noch nicht optimal ??) Skip-Lines oben/unten und rechts/links habe ich daraufhin auf 2 gestellt, auch wenn mir nicht so passt, dass dann skaliert werden muss, obwohl eigentlich nicht skaliert werden müsste... Trotzdem zittert es. Man sieht das ganz gut bei Einblendungen wie z.B. bei Wer wird Millionär. Da zittert der Rand der Box. Die Bildverbesserer am TV habe ich nach meinm Verständnis auch abgestellt
- Bei Kameraschwenks ruckelt es -ganz selten
-Der Ton wird mit der Zeit asynchron zum Bild

softhddevice.1080i.Scaling = 2
softhddevice.1080i_fake.Scaling = 2
softhddevice.576i.Scaling = 2
softhddevice.720p.Scaling = 2
xineliboutput.OSD.Scaling = 1


softhddevice.1080i.Deinterlace = 0
softhddevice.1080i.SkipChromaDeinterlace = 1
softhddevice.1080i_fake.Deinterlace = 0
softhddevice.1080i_fake.SkipChromaDeinterlace = 1
softhddevice.576i.Deinterlace = 2
softhddevice.576i.SkipChromaDeinterlace = 1
softhddevice.720p.Deinterlace = 1
softhddevice.720p.SkipChromaDeinterlace = 1


softhddevice.1080i.CutLeftRight = 2
softhddevice.1080i.CutTopBottom = 2
softhddevice.1080i_fake.CutLeftRight = 2
softhddevice.1080i_fake.CutTopBottom = 2
softhddevice.576i.CutLeftRight = 1
softhddevice.576i.CutTopBottom = 2
softhddevice.720p.CutLeftRight = 2
softhddevice.720p.CutTopBottom = 2

Sind die Einstellungen so die, die du empfehlen würdest?

Ich hatte eigentlich weniger erwartet, nach dem, was du oben geschrieben hast. Allerdings ist meine Erfahrung auch erst eine Stunde alt.
Danke für deine Arbeit an dem Plugin!

Zitat

XBMC hatte auch die Schnauze voll und hat nun auf Software Deinterlacer umgestellt.
Damit hatte ich auch schon angefangen, yadif Patch gabs hier im Forum.
Leider brauche ich dafür ein komplett anderes Ausgabekonzept mit mehreren Threads,
was mir zu viel Arbeit ist.

Das ist ja laut Gerald auch die Lösung die man unter xbmc verwendet.
Jetzt widersprechen sich die beiden Sätze doch, oder? Ist der Patch nutzbar, oder ist es nur ein Anfang und dir war es dann zu viel Arbeit und du hast es gelassen?

Gruß,
Hendrik

Das zittern bei Bob ist ein Fehler im VA-API Treiber, in alten Versionen ist er noch nicht drin.
In neueren sollte er eigentlich behoben sein.

https://bugs.freedesktop.org/show_bug.cgi?id=54608

Kann aber sein, daß es nur in VPP richtig funktioniert.

Wenn du Microruckler hast, dann nimm "VA-API-GLX" zur Ausgabe, da ein Bug in VA-API in der normalen Ausgabe ist.

YADIF gab es als Assembler Version, die einfach als Ersatz für den Bob Software Deinterlacer verwendet wurde.
Du kannst Software Bob nehmen, dann sollte das Zittern auch weg sein.
Durch den Patch habe ich gemerkt, daß das aktuelle Konzept mit nur einen Ausgabethread, mit Software Deinterlacer nicht so gut ist.

Das Hauptproblem war in VaapiBob die memcpy zwischen vaMapBuffer und vaUnmapBuffer.
Die brauchten schon mehrere ms fast die kompletten 20ms für eine Halbbild.

Edit:
In https://github.com/fritsch/xbm…DVDCodecs/Video/VAAPI.cpp ist die XBMC Lösung.
Die Funktion "m_dllSSE4.copy_frame" soll besser sein als ein memcpy.
Der Source ist in https://github.com/fritsch/xbm…/linux/sse4/CopyFrame.cpp

Johns