HD-VDR mit Intel HD Graphics - Testbericht zu vaapi

Zitat von johns

[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung

Habs mal ins git übernommen. Finde es schade das die Intel Treiber nicht so stabil sind.

Abend,

Habe bei meinen Plugin herausgefunden, das nun das Intel Backend unskaliertes OSD unterstüzt.
In der Anleitung "VA_SUBPICTURE_DESTINATION_IS_SCREEN_COORD" suchen.

Mal als Tipp zum einbauen, damit wäre wieder ein Punkt der an va-api nervt weniger.

Johns

Intel Celeron Single-Core G440 ist auch ne nette CPU fürn vdr.

http://ark.intel.com/products/…-G440-(1M-Cache-1_60-GHz)

lg

ebsi

Zitat von johns

Abend,

Habe bei meinen Plugin herausgefunden, das nun das Intel Backend unskaliertes OSD unterstüzt.
In der Anleitung "VA_SUBPICTURE_DESTINATION_IS_SCREEN_COORD" suchen.

Mal als Tipp zum einbauen, damit wäre wieder ein Punkt der an va-api nervt weniger.

Johns

Alles anzeigen

Leider wird es nicht von allen VAAPI Implemntierungen unterstützt. Somit ist das Interesse dies einzubauen sehr gering.

lg

ebsi

Eigentlich bin ich ja über yaVDR hier gelandet ... wir haben uns ein HP Notebook (dv7-6b04eg) zugelegt und wollten auf eine Partition eine vorgefertigten VDR Distri (yaVDR) installieren. Das DVB Device ist ein Netceiver von RMM.

Nun hab ich leider gelesen, dass yaVDR nich so einfach mit Radeon oder Intel GPUs kann.... was wird einfacher zum Laufen zu bringen sein Intel od. Radeon GPU ?? und gibts ev. doch eine VDR Distri. wo ich als Linux Anfänger mit wenig HAndarbeit zum Ziel komme ?

Hallo g....

du wirst am wahrscheinlich schnellesten zum Ziel kommen wenn du den von ebsi releasten archvdr benutzt und den im Wiki aufgeführten Schritten folgst. Leider ist das ganze keine reine Distribution die du einfach nur Installieren musst. Du wirst dich ein wenig mit archlinux auseinadersetzen müssen. Insgesammt kann ich archlinux mit dem archvdr nur empfehlen. Arch ist eine sehr einfach und simple zu verwaltende Distri.

Wahrscheinlich wirst du mit "intel-vaapi" am einfachsten zum Ziel kommen.

Gruß
Atech

Ich bin's mal wieder Mir ist gestern beim Experimentieren folgende Zeile aufgefallen:

video_out_vaapi Error : vaSetDisplayAttributes(): the requested function is not implemented

xine_play
video_out_vaapi VAAPI Supported Profiles : VAProfileMPEG2Simple VAProfileMPEG2Main VAProfileH264Baseline VAProfileH264Main VAProfileH264High 
ffmpeg_video_dec: Nichtunterstütztes Bildformat, DR1 deaktiviert.
video_out_vaapi vaapi_open: Vendor : Intel i965 driver - 1.0.16.pre1
video_out_vaapi Error : vaSetDisplayAttributes(): the requested function is not implemented
video_out_vaapi vaapi_init : Context width 720 height 576
video_out_vaapi vaapi_init : guarded render : 1
video_out_vaapi vaapi_init : glxrender  : 0
video_out_vaapi vaapi_init : glxrender tfp  : 0
video_out_vaapi vaapi_init : is_bound   : 1
video_out_vaapi vaapi_init : scaling level  : name default value 0x00000000
play_internal ...done

Was genau funktioniert da nicht? Ist nur rein aus Interesse. Es läuft ja alles

Grüße
Christoph

Da versucht er Brightness, .. Saturation zusetzen.

Also ich habe mal vaapi-ext branch getestet funktioniert auch besser mit xine-lib-vaapi.

Edit:

Einen Bug habe ich gefunden:
Mit xineliboutput und autocrop wird nur in X vergrößert, die Y Position und Höhe verändert sich nicht.

Johns

ah ok...danke.

Ich bin derzeit auch mit vaapi-ext unterwegs. Was genau funktioniert deiner Meinung nach besser mit der xine-lib?

Also ich habe es nicht geschafft mit libva-ext, daß die GPU hängen bleibt.
Dann habe ich das Gefühl, daß die Interlaced Sender schärfer und detailierter sind.

Edit: Es ist nicht nur ein Gefühl, die Texteinblendungen bei z.b. Deluxe Music sind mit
master branch blockig und mit vaapi-ext branch fein.

Wobei ich ja mit Sandy Bridge (Core2 2te Generation) teste.

Johns

Intressante info wegen vaapi. Habe mal "libva-ext-vaapi" und "vaapi-ext-intel-driver" als PKGBUILD's für ArchVDR gemacht.

lg

ebsi

Hallo ebsi,

Danke für die Packete, das macht es in Zukunft einfacher. Ich hatte mir recht unpraktische PKGBUILDS zum testen zusammengebaut

Die von dir in deiner Signatur angegeben Prozessoren sind ja schon 3/4 Quartal 2011. Entspricht das dann der Sandybridge (2.) Generation? Bei meinen Zahlreichen Tests mit Clarkdale, auch mit vaapi-ext, habe ich kein Denterlacing hinbekommen. Generell sind aber schon für die Clarkdale GPU genau wie bei Sandybridge "erweiterte Deinterlacer" in den Specs angegeben. Ich habe im Netz schon extrem viel dazu geforscht aber leider nicht herausbekommen warum die Deinterlacer für Clarkdale nicht Aktiv sind. So extrem groß kann der Unterschied doch eigentlich auch nicht sein?

Gruß
Atech

Also ich habe ja auch einen Clarkdale und ich bin mir sicher, dass irgendetwas an Deinterlacing mit vaapi-ext läuft. Ich kann jedenfalls Fußball gucken ohne Augenschmerzen zu bekommen.

Ich werde wohl jetzt im Frühjahr auf Ivy Bridge umsteigen. Ich bin gespannt.

Hallo,

Zitat von johns

Also ich habe es nicht geschafft mit libva-ext, daß die GPU hängen bleibt.

interessante Neuigkeit. Leider habe ich kein Archvdr und werd mir die Pakete am langen Arm herbeischnitzen müssen :(.
Wie einige andere auch habe ich derzeit mit der SandyBridge CPU/GPU bei vaapi (und xine-lib-vaapi, ebsi sei dank!) das Problem, dass sich das System beim Umschalten recht bald aufhängt. Deinterlacing kann ich zwar einstellen, die Resultate sind aber sichtbar schlechter als mit Software Deinterlacing.
Naja, mal schauen. Die Hoffnung stirbt zuletzt..

VG
PS: da hat ein fleißiger Zeitgenosse schon was ins Wiki gestellt.

Hi Flachzange,

hast du irgendwelche besonderen Einstellungen gemacht? Funktioniert das Deinterlacing bei dir auch mit johns softhddevice? Ich weiss langsam nicht mehr wo ich noch suchen soll. Ich hab hier bald sämtliche git versionen von sämtlichen VAAPI Programen und Versionn durch und da passiert garnichts....

Probiere jeden Hinweis

Gruß
Atech

Zugegeben: Ich habe vaapi-ext und deinterlacing bisher nur mit XBMC und xvdr plugin laufen. Das tuts. Jetzt wollte ich gerade mit xine-lib testen. Das war keine gute Idee. Sobald ich mpeg2softdec deaktiviere (habe nur mpeg2 interlaced sender) fliegt mir die xine-lib um die Ohren:

xine: i965_drv_video.c:2072: i965_check_alloc_surface_bo: Zusicherung obj_surface->fourcc == fourcc nicht erfüllt.

Ich bin dann sicherheitshalber noch mal auf den master von libva/intel-driver. Damit läufts (deinterlacing hat mich da jetzt aber nicht interessiert). Wieder zurück auf vaapi-ext und wieder kaputt.

Ich kann da also gerade nicht so viel zu sagen. softhddevice habe ich übrigens noch nicht getestet. Bin klassisch mit xine plugin unterwegs.

Baut bei euch eigentlich die libva vaapi-ext sauber durch? Bei mir scheint irgendetwas am Makefile nicht zu stimmen:

Making all in transcode
make[3]: Betrete Verzeichnis '/usr/local/src/intel/libva/test/transcode'
make[3]: *** Keine Regel, um »all« zu erstellen.  Schluss.
make[3]: Verlasse Verzeichnis '/usr/local/src/intel/libva/test/transcode'
make[2]: *** [all-recursive] Fehler 1

Zitat von Flachzange

Baut bei euch eigentlich die libva vaapi-ext sauber durch? Bei mir scheint irgendetwas am Makefile nicht zu stimmen:

Hatte ich auch.
Ich habe in configure.ac bei test/vainfo/Makefile noch test/transcode/Makefile dazugeschrieben.
Dasselbe noch an zwei Stellen in configure.
Dann wird auch transcode gebaut. Ob du es allerdings brauchst...?

Danke! Brauchen wird man es wohl nicht (läuft ja auch ohne), aber ich war mir auch nicht sicher, ob danach noch etwas anders gebaut werden muss.

Hatte den Fehler grade auch. Das Verzeichnis transcode enthält nur ein Testprogramm. Das braucht man wohl nicht. Habe im Makefile das Verzeichnis gelöscht. Dann baut es sauber fertig.

VDR mit Softhddevice crasht aber leider.

Jan 24 22:47:25 H67 vdr: [softhddev] invalid PES video packet
Jan 24 22:47:25 H67 vdr: [softhddev] invalid PES video packet
Jan 24 22:47:25 H67 vdr: codec: YUV 420 supported
Jan 24 22:47:25 H67 kernel: [ 7942.036722] receiver on dev[12885]: segfault at 0 ip 00007f290edea1c3 sp 00007f28fa261928 error 6 in libavcodec.so.53.54.100[7f290eb59000+68c000]

.
Ist mein Kernel (2.6.38-13-generic) evtl zu alt?
VG
Kurt

das sieht eher nach einem zu alten ffmpeg aus