HD-VDR mit Intel HD Graphics - Testbericht zu vaapi

Zitat

Originally posted by Atechsystem
Hi ebsi,

danke für das Update.

Meinst du damit das von mir beschriebene Verhalten beim Umschalten? Da wird bei mir das OSD kurz ausgebelendet und anschließend nach dem Umschalten wieder angezeigt. Einen anderes "delay" verhalten ist mir bisher nicht aufgefallen.

Gruß
Atech

Alles anzeigen

Genau das meine ich.

lg

ebsi

Hallo zusammen.

danke ebsi - schade, aber soo schlimm ist das nicht. Störend ist dieses Verhalten nur wenn man auf einen Sender geht, der kein Bild Sendet.

So, jetzt mal wieder ein Statusbericht:

Test mit vdr-xine 0.9.4 mit aktueller xine-lib 1.2 und vaapi patch r157, vdr 1.7.16:

+ OSD Fehlerfrei mit Einpassen HQ (alle anderen optionen - bis auf Overlay führen zum gleichen Ergebnis). Blend clipped hab ich irgendwie nicht.
+ text2skin Skins werden korrekt dargestellt (getestet: PearlHD und Anthra)
+ Bild ist Ordentlich
+ Sehr schnelles Umschalten
- Leider kein Deinterleacing trotz "video.output.vaapi_deinterlace:2" und video.output.vaapi_reinit:1
- Bisher ein Absturtz (wenns nochmal kommt zeig ich hier die Logausgabe) wirkt aber bisher sehr stabil

Soweit...

Gruß
Atech

Und jetzt noch schnell die Fehlermeldung nachgereicht:

Zitat

libva: libva version 0.32.0 libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/dri/i965_drv_video.so libva: va_openDriver() returns 0
vdr: osdflush: n: 2, 20.2, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.1, timeout: 0, result: 0
xiTK received SIGSEGV signal, RIP.
Abgebrochen

Kam beim starten einer Aufnahme.

Gruß
Atech

Zitat

Original von Atechsystem

Kann ich bestätigen. Diesen hatte ich auch schon ein einziges Mal im laufenden Betrieb. Mit der alten xine ui kam er immer direkt beim Start (s.o.).

Update :

Habe die OSD handling logik überarbeitet, bassierend auf einem neuen VDPAU patch von der xine-devel ML. Unsclaed OSD's sollten nun in vdr-xine und xineliboutput funktionieren. Für vdr-xine muss ein workaround gemacht werden. Anbei das aktuelle Readme mit allen infos für die Konfiguraion.

Make sure you have the following in your ~/.xine/config.


General ffmpeg settings :


# Priorität für Dekoder ffmpeg-wmv8
# numeric, default: 0
engine.decoder_priorities.ffmpeg-wmv8:0


# Priorität für Dekoder ffmpeg-wmv9
# numeric, default: 0
engine.decoder_priorities.ffmpeg-wmv9:0


# Priorität für Dekoder ffmpegvideo
# numeric, default: 0
engine.decoder_priorities.ffmpegvideo:1


# Priorität für Dekoder mpeg2
# numeric, default: 0
#engine.decoder_priorities.mpeg2:0


Video out settings :


#vaapi: set deinterlace to 0 ( none ), 1 ( top field ), 2 ( bob ).
# numeric, default: 0
video.output.vaapi_deinterlace:2


# vaapi: reinit vaapi on every format change. When no reinit is used deinterlaced is turned off.
# numeric, default: 1
#video.output.vaapi_reinit:1


# vaapi: VDR osd height workaround.
# numeric, default: 0
#video.output.vaapi_vdr_osd_height:0


# vaapi: VDR osd width workaround.
# numeric, default: 0
#video.output.vaapi_vdr_osd_width:0


It is posible not to use reinit on every format change. The problem is that this does not 
work relayable. On Intel VAAPI the driver crashes. Therefore deinterlacing is disabled
when reinit is set to 0.


Notes on use with VDR. The OSD will have some delay. This is technical and can only be overcome
writting a complete new decoder which use VAAPI direct and not ffmpeg.


For using unsclaed OSD there you can overwrite the OSD size in the config file.


For xineliboutput use the defaults.


For vdr-xine set in VDR the OSD size to 1920x1080 and use the following in ~/.xine/config :


video.output.vaapi_vdr_osd_height:0
video.output.vaapi_vdr_osd_width:0


The workaround is needed, because vdr-xine does not report the real unscaled OSD size.


Call xine like : xine -V vaapi video.mkv

Zitat

Original von ebsi
Update :

Habe die OSD handling logik überarbeitet, bassierend auf einem neuen VDPAU patch von der xine-devel ML. Unsclaed OSD's sollten nun in vdr-xine und xineliboutput funktionieren. Für vdr-xine muss ein workaround gemacht werden. Anbei das aktuelle Readme mit allen infos für die Konfiguraion.

Cool, Danke! Das probiere ich heute Abend mal aus.

Atechsystem
Was das Deinterlacing angeht, glaube ich schon eine leichte Verbesserung zu sehen, wenn ich "Top Field" wähle, aber die ist minimal. Bei "Bob" ruckelt es noch. Testen kann ich den Deinterlacer nur mit SD-Kanälen.

Morgen,

das kann schon sein, dass es irgendwas macht. Aber man sieht die Inlerlacing "streifen" deutlich. Habe auch mit mplayer vaapi getestet und dort bekommt man aktivierten Deinterlacern genau das gleiche Bild.

Gruß
Atech

Zitat

Original von Atechsystem
das kann schon sein, dass es irgendwas macht. Aber man sieht die Inlerlacing "streifen" deutlich. Habe auch mit mplayer vaapi getestet und dort bekommt man aktivierten Deinterlacern genau das gleiche Bild.

Moin,

Wie ich schon mehrmals schrieb, ist es zumindest für das VDPAU Backend falsch.
Der Code in der xine-lib ist der selbe wie im mplayer.

Du solltest mal vlc oder xbmc testen, die verwenden einen anderen Weg.

Johns

Zitat

Originally posted by johns

Moin,

Wie ich schon mehrmals schrieb, ist es zumindest für das VDPAU Backend falsch.
Der Code in der xine-lib ist der selbe wie im mplayer.

Du solltest mal vlc oder xbmc testen, die verwenden einen anderen Weg.

Johns

Alles anzeigen

Soweit ich weis verwenden VLC und XBMC VAAPI nur für die Decodierung aber nicht für die Videoausgabe. Mplayer verwendet VAAPI auch für die Videoausgabe. Ich denke mal das der Code in mplayer richtig ist. Derjenige der den VAAPI support in mplayer macht weis was er tut.

http://www.splitted-desktop.com/~gbeauchesne/

Wenn man die VAAPI Duku liest weis man warum das mit dem Deinterlacer bei VAAPI so implemntiert ist wie es ist.

lg

ebsi

Hi johns,

entgegen meiner Signatur teste ich in diesem Fall nicht mit VDPAU sondern mit INTEL Core I5 und VAAPI. Leider bekomme ich für diese Konfiguration kein Deinterlacing mit der VAAPI in gang. Weder mit xine, mplayer oder XBMC. Man kann zwar in XBMC die Option Deinterlace einschalten aber mehr Möglichkeiten gibt es nicht und es findet im Anschluss auch kein Deinterlacing statt. Bei den anderen beiden Playern gibt es zwar die Optionen 0,1,2 aber diese haben ebenfalls keine Funktion. Bob (2) führt lediglich zum Ruckeln des Bildes (ausserdem wird der Rechner irgendwie Träge obwohl die CPU Last sehr niedrig ist).

Ich habe deine Post keinesfalls ignoriert - finde sehr Interessant was du so alles herausgefunden hast. Mit vlc habe ich noch keine Tests gemacht. Ich meine aber gelesen zu haben, dass der VLC Player das Deinterlacing an einen Software Deinterlacer abgibt. Werde es die Tage mal austesten.

Danke für deine Hilfe

Gruß
Atech

PS: ebsi - du warst wieder schneller Funktioniert das deint denn bei dir? Oder ist das einfach noch ne Baustelle?

Zitat

Original von ebsi

Soweit ich weis verwenden VLC und XBMC VAAPI nur für die Decodierung aber nicht für die Videoausgabe. Mplayer verwendet VAAPI auch für die Videoausgabe. Ich denke mal das der Code in mplayer richtig ist. Derjenige der den VAAPI support in mplayer macht weis was er tut.

http://www.splitted-desktop.com/~gbeauchesne/

Wenn man die VAAPI Duku liest weis man warum das mit dem Deinterlacer bei VAAPI so implemntiert ist wie es ist.

Alles anzeigen

Bei VLC habe ich jetzt im 1.1.7 nichts gefunden, kann mich täuschen oder es war im GIT.
XBMC git verwendet vaCopySurfaceGLX.

Also ich kann nur für das VDPAU Backend sprechen und dessen Code ist nicht besonders gut.

Ich habe nur die Dokumentation im Headerfile gelesen und die Sourcen, gibts noch etwas anderes?

Laut Sourcen vom VDPAU Backend:

Bekommt man Weave, wenn man 1* vaPutSurface immer mit VA_FRAME_PICTURE aufruft.
Bekommt man nur Top-field verdoppelt, wenn man 1* vaPutSurface immer mit VA_TOP_FIELD aufruft.
Bekommt man nur Bottom-field verdoppelt, wenn man 1* vaPutSurface immer mit VA_BOTTOM_FIELD aufruft.
Will man BOB haben, muss man 2 * vaPutSurface mit VA_TOP_FIELD aufrufen und dann
2* vaPutSurface mit VA_BOTTOM_FIELD aufrufen.
Die Advanced Deinterlacer bekommt man, wenn man abwechselnd vaPutSurface mit VA_TOP_FIELD
und VA_BOTTOM_FIELD aufruft. Mit dem original Code halt das Bottom-field verdoppelt.

Guck doch mal in das Intel Backend. ob es da genauso ist.

Johns

Aktiviere das Tiling in der xorg.conf. Das beschleunigt erheblich.

Option  "Tiling" "true"

Mit aktiviertem Tiling sollte dann auch Deinterlace 2 nicht mehr ruckeln.

Zusätzlich bin ich mit libva, libdrm, xf86-video-intel am letzten git stand.
Als kernel verwende ich nun 2.6.38.

Wen es intressiert der kann sich die Intel GPU tools installieren.

http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

Mit intel_gpu_top kann man sich die GPU auslastung ansehen.

lg

Ebsi

Zitat

Originally posted by Flachzange

Cool, Danke! Das probiere ich heute Abend mal aus.

Atechsystem
Was das Deinterlacing angeht, glaube ich schon eine leichte Verbesserung zu sehen, wenn ich "Top Field" wähle, aber die ist minimal. Bei "Bob" ruckelt es noch. Testen kann ich den Deinterlacer nur mit SD-Kanälen.

Zitat

Original von ebsi
Aktiviere das Tiling in der xorg.conf. Das beschleunigt erheblich.

Code

Option  "Tiling" "true"

Mit aktiviertem Tiling sollte dann auch Deinterlace 2 nicht mehr ruckeln.

Gracias, so läufts mit Bob flüssig. Ist vielleicht kein temporal/spatial aber akzeptabel.

Zitat

Original von ebsi
Wen es intressiert der kann sich die Intel GPU tools installieren.

http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

Mit intel_gpu_top kann man sich die GPU auslastung ansehen.

cool, so etwas hatte ich schon gesucht, bringt nicht wirklich was, ist aber Interessant

Gibt es eigentlich für deinen vaapi Branch, public git oder svn Zugriff? Bei der vielen Änderungen im Moment. wäre das praktisch.

Mit dem aktuellen Entwicklungsstand bin ich echt zufrieden und meine Nvidia Karte kann jetzt einpacken.

Edit: Das mit Bob klappt doch noch nicht so ganz, wie gedacht. Wenn ich einen beliebigen SD-Kanal mal so ca. 5min laufen lassen, ruckelt es irgendwann wieder. Nicht ganz so schlimm wie ohne "tiling", aber doch sehr störend. (r162)

Naja, liegen tut das ganze auf Sourceforge im moment :
http://crystalhd.svn.sourcefor…nches/xine-lib-1.2-vaapi/
Ist halt keine aktuelle xine-lib-1.2. Sollte ich mal auf stand bringen. Wenn ich der
Meinung bin das die gröbsten probleme raus sind sollte ich mir gedanken machen
es zum includieren upstream zu schicken.

Zitat

Original von Flachzange

Gracias, so läufts mit Bob flüssig. Ist vielleicht kein temporal/spatial aber akzeptabel.

cool, so etwas hatte ich schon gesucht, bringt nicht wirklich was, ist aber Interessant

Gibt es eigentlich für deinen vaapi Branch, public git oder svn Zugriff? Bei der vielen Änderungen im Moment. wäre das praktisch.

Mit dem aktuellen Entwicklungsstand bin ich echt zufrieden und meine Nvidia Karte kann jetzt einpacken.

Edit: Das mit Bob klappt doch noch nicht so ganz, wie gedacht. Wenn ich einen beliebigen SD-Kanal mal so ca. 5min laufen lassen, ruckelt es irgendwann wieder. Nicht ganz so schlimm wie ohne "tiling", aber doch sehr störend. (r162)

Alles anzeigen

Hat eigentlich noch mal jemand XBMC + VNSI/streamdev und VAAPI getestet? Ich habe mal gerade mit dem git von Lars Op den Kamp getestet, aber mit VNSI bekomme ich bei aktiviertem VAAPI einen segfault. Streamdev läuft einfach so nicht, obwohl es bei mir lokal im Netz gut funktioniert....

Hi,

XBMC und VNSI ist einfach noch eine große Baustelle. In meinen Augen lief die Vorgängerversion wesentlich besser als die jetzige Opdenkamp Variante. Das soll aber überhaupt kein Tadel sein sondern einfach nur eine Feststellung. Ich setz große Hoffnung in XBMC und PVR (VDR). Solange dann halt noch Xine.

Gruß
Atech

vdr-xine vs xineliboutput

Für ein gute "Experience" verwendet vdr-xine. Es hat sich mal wieder herausgestellt das xineliboutput unbrauchbar ist. Xineliboutput verendet intern ein zu agressives Locking, was sich mit xine immer wieder sperrt. Ich hatte schon seinerzeit, an der Arbeit mit xine-plugin-crytslhd, meine Probleme damit. Sollten in xineliboutput Deadlocks auftreten bitte den Entwickler von xineliboutput Steinigen und Mails zuschütten. Ich werde mich auf den Posten zurückziehen, mit xine-ui und vdr-xine funktioniert es. Welche ich als Referenz ansehe. Wenn jemand einen Patch zur lösung des Problemes hat nehme ich ihn gerne an. Tut mir leid das ich keine bessere Nachricht für die xineliboutput anhänger habe.

lg

Ebsi

Hab heute eine sync mit xine-lib-1.2 mercurial gemacht. Ihr müsst den tree neu auschecken.

svn co https://crystalhd.svn.sourcefo…anches/xine-lib-1.2-vaapi

Es gibt auch neue config optionen. Einfach README.vaapi ansehen. Des weiteren funktioniert auch die reine Ausgabeplugin funtionlaität. Will heißen das auch Software decodierte Formate angezeigt werden.

lg

ebsi

So ich habe gestern nach längerer Zeit mal wieder ein Update deiner xine-lib gemacht. Das läuft schon wirklich gut und stabil. Auch das Spulen in Aufnahmen (h.264 und MPEG2) funktioniert sehr gut. Lediglich das leidige Thema Deinterlacing; es funktioniert bei mir nachwievor nicht vernünftig (MPEG2). Es spielt keine Rolle, egal ob ich 0, 1 oder 2 einstelle, das Bild sieht immer gleich aus. Hast du eine Ahnung was ich falsch mache oder woran es liegt?

Ich hab mal zwei Testfiles (MPEG2) hochgeladen:

Laufschrift auf N24: http://rapidshare.com/files/454607295/00001.ts

Fussball im WDR: http://rapidshare.com/files/454610824/00001.new.ts

Edit:
Um es noch mal zu präzisieren: Das Deinterlacing scheint nicht zu funktionieren. Wenn ich die Aufnahmen beispielsweise im VLC Player öffne, sieht das Bild bei ausgeschaltetem Deinterlacing genauso aus wie xine + vaapi

Hi,

Ich habe die Sourcen von VLC gecheckt. Das dort das Deinterlacing geht ist kein wunder. In VLC passiert es in SOFTWARE. VLC verwendet VAAPI nur für die Decodierung, jedoch nicht für die Anzeige. Wenn Ihr vergleiche macht bitte mit mplayer-vaapi durchführen. mplayer-vaapi ist mehr oder weniger die Referenzimplementierung und besser vergleichbar zu Xine. Meldungen über andere Player werde ich einfach ignorieren und nicht komentieren.

Ich habe mich mit dem Entwickler vom Intel VAAPI Treiber in verbindung gesetzt und ihm die Probleme geschildert. Bin gespannt ob dort was rauskommt.

Um die Situation mit MPEG2 und Interlacing zu mildern bin ich daran den einfachen ffmpeg Deinterlacer zu verwenden und das Decoding in Software zu erledigen. Unsere Zielhardware ist schnell genug für diesen Task ohne gleich am vollen Anschlag der CPU zu laufen. Die Anzeige vom OSD ist davon nicht betroffen.

Solltet ihr Interesse haben das ganze auf so einem http://geizhals.at/a609301.html Board ans laufen zu bekommen, würde ich gerne einen Spendenaufruf machen. Wenn jemand bereit ist eine Spende zu tätigen, bitte eine PN und ich sende ihm dann meine PayPal Mail Adresse. Sollte genügend Geld zusammenkommen gebe ich euch bescheid.

lg

ebsi