HD-VDR mit Intel HD Graphics - Testbericht zu vaapi

Welche Mailingliste muß man da verfolgen, es war wohl weder LibVA, noch Intel-GFX?

Hi,

die Intel-gfx Liste. Blick da aber noch nicht durch wo man anschließend die Mails einsehen kann. Die Mail wurde mir jedenfalls von der Mailinglist zugestellt.

Atech

Ich bin am Suchen ob ich den Bug einfach reproduzieren kann.

In meinem Plugin tritt er nur auf, wenn man auf ein paar besondere Sender schaltet. Alle anderen funktionieren.
Die Sender sind im Moment "Nick/CC" und "Sixx", nachdem auf einen solchen geschaltet war, spinnen auch 1080i Sender.

Das "GPU hung" kommt bei dem ersten vaPutSurface was danach aufgerufen wird auf.

Mit "hwdecode-demos" kann ich es leider nicht repoduzieren.

Johns

Sooo,

gut Ding will Weile haben. Ich habe eine Antwort von Haihao Xiang bekommen. Er sagt, dass es eigentlich funltionieren sollte und er sich dem "Clarkdale" Problem wenn er ein wenig Zeit hat annehmen will.

johns: Falls du Ergebnisse hast werde ich SIe dann reporten. Es besteht Hoffnung

Gruß
Atech

ebsi

ich wollte gerade deine xine-lib gegen ein aktuelles ffmpeg(git von heute) bauen und bekomme einen unerwarteten Fehler:

CC     xineplug_decode_ff_la-ff_video_decoder.lo
ff_video_decoder.c:135:3: error: unknown type name 'AVPaletteControl'
ff_video_decoder.c: In function 'get_buffer':
ff_video_decoder.c:183:13: error: 'AVFrame' has no member named 'age'
ff_video_decoder.c:286:11: error: 'AVFrame' has no member named 'age'
ff_video_decoder.c: In function 'ff_handle_special_buffer':
ff_video_decoder.c:1194:5: error: unknown type name 'AVPaletteControl'
ff_video_decoder.c:1197:18: error: 'AVCodecContext' has no member named 'palctrl'
ff_video_decoder.c:1198:24: error: 'AVPaletteControl' undeclared (first use in this function)
ff_video_decoder.c:1198:24: note: each undeclared identifier is reported only once for each function it appears in
ff_video_decoder.c:1198:42: error: expected expression before ')' token
ff_video_decoder.c:1202:22: error: request for member 'palette' in something not a structure or union
ff_video_decoder.c:1207:20: error: request for member 'palette_changed' in something not a structure or union
ff_video_decoder.c: In function 'ff_video_open_plugin':
ff_video_decoder.c:2023:16: error: 'AVCodecContext' has no member named 'palctrl'

Hast du eine Idee, was da los ist?

Nabend,

gestern habe ich mal xine@vdr-plugin-xine via vaapi am lebenden Objekt sprich HD TV getestet. Wie erwartet ist auch hier Bild gut und gibt keinen Grund zur Klage. Gilt aber - wie gesagt - nur für CPUs der Sandy Brigde Generation.

Was bleibt, ist die Zitterpartie beim Umschalten. Sobald umgeschaltet wird, kann es zu Hängern kommen. Es passiert zwar nicht immer, aber doch sehr oft. Im Log ist der Hänger gut zu sehen. Witzigerweise ist der Hänger sofort zu weg, wenn die Maus angeschubst oder die Tastatur (nicht die FB!) betätigt wird. Anscheinend sorgt das Event dafür, Xine irgendwelche Stati auswertet oder was aus libva ruft, das das Warten aufhebt.

'13:52:49: ffmpeg_video_dec: direct rendering enabled'
 '13:52:49: ffmpeg_video_dec: force AVDISCARD_DEFAULT for VAAPI'
 '13:52:49: ffmpeg_video_dec: VAAPI Enabled in config.'
 '13:52:49: ffmpeg_video_dec: vaapi_mpeg_softdec 0'
 '13:52:49: ffmpeg_video_dec: vaapi_mpeg_softdec_deinterlace 0'
 '13:52:49: load_plugins: plugin ffmpegvideo will be used for video streamtype 00.'
 '13:52:49: video_out_vaapi VAAPI Profile VAProfileMPEG2Main supported by your hardware'
 '13:52:49: video_out_vaapi VAAPI Supported Profiles : '
 '13:53:05: input_vdr: flush buffers (vb: 0, ab: 0, vf: 0, af: 0) done.'
 '13:53:05: vdr_video: osd: (0, 0)-(720, 576)@1.33333'
 '13:53:05: vdr_video: osd: (0, 0)-(720, 576)@1.33333'
 '13:53:05: video_out_vaapi Error : vaSetDisplayAttributes(): the requested function is not implemented'
 '13:53:05: video_out_vaapi vaapi_init : Context width 720 height 576'

Hat jemand denselben Effekt mit xine schon mal beobachtet?

VG
Kurt

Solchen Effekt hatte ich ganz am Anfang, Maus rühren beim Umschalten half.
Habe leider keine Maus am Testrechner, kann es nicht testen.

intel_iommu=igfx_off oder intel_iommu=off der Kernel Kommandozeile anfügen, verbessert bei mir das Umschalten.

Johns

Zitat von Flachzange

ebsi

ich wollte gerade deine xine-lib gegen ein aktuelles ffmpeg(git von heute) bauen und bekomme einen unerwarteten Fehler:

Code

CC     xineplug_decode_ff_la-ff_video_decoder.lo
ff_video_decoder.c:135:3: error: unknown type name 'AVPaletteControl'
ff_video_decoder.c: In function 'get_buffer':
ff_video_decoder.c:183:13: error: 'AVFrame' has no member named 'age'
ff_video_decoder.c:286:11: error: 'AVFrame' has no member named 'age'
ff_video_decoder.c: In function 'ff_handle_special_buffer':
ff_video_decoder.c:1194:5: error: unknown type name 'AVPaletteControl'
ff_video_decoder.c:1197:18: error: 'AVCodecContext' has no member named 'palctrl'
ff_video_decoder.c:1198:24: error: 'AVPaletteControl' undeclared (first use in this function)
ff_video_decoder.c:1198:24: note: each undeclared identifier is reported only once for each function it appears in
ff_video_decoder.c:1198:42: error: expected expression before ')' token
ff_video_decoder.c:1202:22: error: request for member 'palette' in something not a structure or union
ff_video_decoder.c:1207:20: error: request for member 'palette_changed' in something not a structure or union
ff_video_decoder.c: In function 'ff_video_open_plugin':
ff_video_decoder.c:2023:16: error: 'AVCodecContext' has no member named 'palctrl'

Alles anzeigen

Hast du eine Idee, was da los ist?

Alles anzeigen

Da haben die ffmpeg Entwickler aufgeräumt. Das war schon länger als deprecated markiert.

So Leute, ich gebe ja nicht auf....ihr kennt ja mein Problem:

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

Ich habe gerade mal rumgspielt und geschaut, was so in fourcc und obj_surface->fourcc steht:

obj_surface->fourcc = 842094158 = NV12
fourcc == 808596553 = I420

Deswegen failed die assertion und ich habe meine exception. Da ich ja von diesem ganzen Grafik- und Videozeugs keine Ahnung habe, dachte ich mir, ich setze einfach NV12 falls I420 drin steht und schaue was passiert. Und siehe da, ich kriege eine Bild mit VAAPI und funktionierendem Deinterlacing! Klar, der Farbraum passt nicht und das Bild ist farblich nicht sehr sehenswert, aber es geht mal prinzipiell.

Ich bin mir ziemlich sicher, dass Deinterlacing auf meinem Clarkdale so läuft. Meine Settings:

video.driver:vaapi
video.output.vaapi_deinterlace:2
video.processing.ffmpeg_enable_vaapi:1
video.processing.vaapi_mpeg_softdec:0
video.processing.vaapi_mpeg_softdec_deinterlace:0
engine.decoder_priorities.ffmpegvideo:1

- CPU-Auslastung bei MEPG2 SD: 10%
- Keine Ruckler mehr beim Starten
- Bei manchen Kanälen Hänger beim Umschalten
- Laufschrift bei N24 sehr sauber
- Zur sonstigen Bildqualität kann ich keine Aussage machen

Das einzige was mir jetzt noch jemand sagen kann ist, dass es nur funktioniert, weil der Farbraum falsch ist. Die Frage ist jetzt nur, warum passen die fourcc codes der Farbräume nicht? Ich würde ja gerne selbst suchen, aber da fehlt mir einfach das Hintergrundwissen. Liefert der xf68 Intel Treiber hier falsche Werte, weil ich einen Clarkdale habe?

Edit: Habe gerade gesehen, dass i965_check_alloc_surface_bo immer mit fourcc=NV12 aufgerufen wird. Im normalen Treiber aus dem master branch holt er sich fourcc über image.fourcc, was auch irgendwie sinnvoller aussieht. Ich werde das heute Abend mal testen, mein Router hat mich leider gerade ausgesperrt

Zitat von ebsi

Da haben die ffmpeg Entwickler aufgeräumt. Das war schon länger als deprecated markiert.

Hab einen workaroud in den vaapi-testing tree gepusht.

Zitat von ebsi

Hab einen workaroud in den vaapi-testing tree gepusht.

Klasse! Das ging ja schnell. Gerade getestet und läuft. Dank dir!

Zitat von johns

intel_iommu=igfx_off oder intel_iommu=off der Kernel Kommandozeile anfügen, verbessert bei mir das Umschalten.

Hat nichts gebracht. Hängt weiterhin.
Dennoch danke für den Tip. Ein Versuchs war's wert. Vielleicht haue ich mal einen aktuelle Kernel drauf. Obwohl ich nicht wirklich glaube, dass es daran hängt.
VG
Kurt

Morgen,

Zitat von Flachzange

So Leute, ich gebe ja nicht auf....ihr kennt ja mein Problem:

Das Lob ich mir.

Zitat von Flachzange

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

Konnte ich leider noch nicht nachvollziehen.

Zitat von Flachzange

Ich habe gerade mal rumgspielt und geschaut, was so in fourcc und obj_surface->fourcc steht

Zitat von Flachzange

obj_surface->fourcc = 842094158 = NV12
fourcc == 808596553 = I420

Zitat von Flachzange

Deswegen failed die assertion und ich habe meine exception. Da ich ja von diesem ganzen Grafik- und Videozeugs keine Ahnung habe, dachte ich mir, ich setze einfach NV12 falls I420 drin steht und schaue was passiert. Und siehe da, ich kriege eine Bild mit VAAPI und funktionierendem Deinterlacing! Klar, der Farbraum passt nicht und das Bild ist farblich nicht sehr sehenswert, aber es geht mal prinzipiell.

Zitat von Flachzange

Ich bin mir ziemlich sicher, dass Deinterlacing auf meinem Clarkdale so läuft. Meine Settings:

Zitat von Flachzange

Das einzige was mir jetzt noch jemand sagen kann ist, dass es nur funktioniert, weil der Farbraum falsch ist. Die Frage ist jetzt nur, warum passen die fourcc codes der Farbräume nicht? Ich würde ja gerne selbst suchen, aber da fehlt mir einfach das Hintergrundwissen. Liefert der xf68 Intel Treiber hier falsche Werte, weil ich einen Clarkdale habe?

Zitat von Flachzange

Edit: Habe gerade gesehen, dass i965_check_alloc_surface_bo immer mit fourcc=NV12 aufgerufen wird. Im normalen Treiber aus dem master branch holt er sich fourcc über image.fourcc, was auch irgendwie sinnvoller aussieht. Ich werde das heute Abend mal testen, mein Router hat mich leider gerade ausgesperrt

Hast du mittlerweile nochmal getestet? Wenn wir das ein wenig Sinnvoll zusammenfassen kann sende ich es an die libva Liste.

Was sagen denn die Experten?

Gruß
Atech

Edit: Könnte das hier dazu passen? http://lists.freedesktop.org/a…011-September/000603.html

@Atech
Okay. Geht nicht. Habe jetzt mal einfach ein I420 surface übergeben und damit geht Deinterlacing definitiv nicht, also genauso wie bei dir. Jetzt stimmen zwar die Farben, aber das hilft ja nicht. Der Clarkdale kann es wohl einfach nicht

Edit: Wenn ich mir das so anschaue, glaube ich fast, dass vaapi-ext nur für Sandy und Ivy gedacht ist. Mich wundert jedoch, warum es bei dir funktioniert. Wenn du Lust hast, kannst du meinen Fehler ja mal auf der Mailingliste posten.

Ich habe einen Bug in ffmpeg gefunden, der wahrscheinlich die Ursache für die GPU hung sind.
Es könnte auch sein, daß es noch einen weiteren in libav auslöst.

ffmpeg erzeugt und mapped VA-API Buffers mehrmals und gibt die erst sehr spät frei. Dies passiert bei kaputten Frames.

Leider gibt es nun grüne Artefakte beim Umschalten bei Nick/CC und SIXX, ...

Johns

Zitat von johns

Ich habe einen Bug in ffmpeg gefunden, der wahrscheinlich die Ursache für die GPU hung sind.
Es könnte auch sein, daß es noch einen weiteren in libav auslöst.

ffmpeg erzeugt und mapped VA-API Buffers mehrmals und gibt die erst sehr spät frei. Dies passiert bei kaputten Frames.

Leider gibt es nun grüne Artefakte beim Umschalten bei Nick/CC und SIXX, ...

Johns

Alles anzeigen

Hast Du den patch an ffmpeg / libva gemeldet ? Gwenole ist glaub ich der richtige den man ansprechen sollte.

lg

ebsi

Nein noch nicht, ich wollte erstmal hören was andere dazu sagen.
Und zufrieden bin ich auch noch nicht. Da es beim Umschalten erstmal grünen Pixelbrei gibt.
(Also Bild mit grünen Artefakte von fehlenden Macroblocks)

Und mit 1080i Sendern gibts auch noch Probleme. Die waren schon mal weg. Wenn ich den
Software Decoder von ffmpeg nehme, dann klappen alle Sender.

Ist schon verzwickt das Ganze.
Johns

Hi Johns,

werde heute Abend mal testen

@ Flachzange:

Zitat

@Atech
Okay. Geht nicht. Habe jetzt mal einfach ein I420 surface übergeben und damit geht Deinterlacing definitiv nicht, also genauso wie bei dir. Jetzt stimmen zwar die Farben, aber das hilft ja nicht. Der Clarkdale kann es wohl einfach nicht

Edit: Wenn ich mir das so anschaue, glaube ich fast, dass vaapi-ext nur für Sandy und Ivy gedacht ist. Mich wundert jedoch, warum es bei dir funktioniert. Wenn du Lust hast, kannst du meinen Fehler ja mal auf der Mailingliste posten.

Kannst du bitte nochmal Erklären wie du zu einem interlaced Bild mit falschen Farben gekommmen bist. Ich weiss noch nicht geneau wie ich das in eine Mail packen soll. Warum bei dir mit dem ext branch ein Fehler erscheint und bei mir nicht kann ich nicht nachvollziehen. Der ext branch enthält nach meiner Auffassung einige Erweiterungen für Sandy- und Ivybridge und einige Bugfixes die unter anderem auf der Mailingliste Diskutiert wurden.

Gruß
Atech

Darüber habe ich mich auch gewundert.

Die Intel Shader (Deinterlace...) arbeiten nur mit NV12 Flächen. NV12 verwendet Intel für H264 dekodieren Bei Mpeg2 verwendet Intel I420 Flächen.
Diese müssen für das Postprocessing nach NV12 umgewandelt werden.

Für meinen vorherigen Patch, habe ich eine einfachere noch ungetestete Lösung:

diff --git a/libavcodec/vaapi_mpeg2.c b/libavcodec/vaapi_mpeg2.c
index 030f76b..5596e99 100644
--- a/libavcodec/vaapi_mpeg2.c
+++ b/libavcodec/vaapi_mpeg2.c
@@ -46,6 +46,11 @@ static int vaapi_mpeg2_start_frame(AVCodecContext *avctx, av_unused const uint8_
 
     av_dlog(avctx, "vaapi_mpeg2_start_frame()\n");
 
+    /* push out any old data; unmap and release buffers */
+    if (vactx->pic_param_buf_id) {
+        ff_vaapi_common_end_frame(s);
+    }
+
     vactx->slice_param_size = sizeof(VASliceParameterBufferMPEG2);
 
     /* Fill in VAPictureParameterBufferMPEG2 */

Johns

@Atech

Habe mich gerade mal selber zur intel-gfx Liste angemeldet und kann es dann später auch selbst erklären. Wirst du dann ja mitbekommen. Danke trotzdem