HD-VDR mit Intel HD Graphics - Testbericht zu vaapi

Gelöscht.

Bin jetzt erfolgreich auf den staging Branch gehüpft.
a) fehlte nur ein "git pull" für die libva
b) hatte ich intel-driver 'vergessen'.

Lösche auch die Header Files. /usr/include/va oder /usr/local/include/va

lg

ebsi

Bin jetzt erfolgreich auf den staging Branch gehüpft.

a) fehlte nur ein "git pull" für die libva
b) hatte ich intel-driver 'vergessen'.
c) Natürlich die schon erwähnten "rm -r /usr/local/include" + "rm /usr/lib/libva*"

Trotzdem danke...

Der staging Branch ist echt atemberaubend, wenn ich es richtig gemacht habe, wundert mich die gegenüber vaapi-ext veränderte Qualität nicht so recht.

Feb 27 09:15:17 i3v vdr: postproc: video postprocessor available
Feb 27 09:15:17 i3v vdr: postproc returned 2 filters
Feb 27 09:15:17 i3v vdr: postproc returned 2 interlacers
Feb 27 09:15:17 i3v vdr: postproc filter 0 is noise reduction
Feb 27 09:15:17 i3v vdr: postproc filter 1 is deinterlacer
Feb 27 09:15:17 i3v vdr: postproc deinterlacer 0 is bob
Feb 27 09:15:17 i3v vdr: postproc deinterlacer 1 is weave

Ich habe wie folgt codiert:

// cmsa: Interlacing
	evp = VaapiFindProfile(profiles, profile_n, VAEntrypointVideoProc);
	if (evp == -1) {
    	Warning(_("postproc: unsupported: video postprocessor\n"));
	return; //oops
	} else {
 	   	Warning(_("postproc: video postprocessor available\n"));
	}
	vaQueryVideoProcFilters(decoder->VaDisplay, decoder->VaapiContext[0].context_id,
    	filters, &num_filters);
	Warning(_("postproc returned %d filters\n"), num_filters);


	// vaQueryVideoProcFilterCaps(decoder->VaDisplay, decoder->VaapiContext[0].context_id, VAProcFilterNoiseReduction, &denoise_caps, &num_denoise_caps);
	unsigned int num_deinterlacing_caps = 20;
	VAProcDeinterlacingType deinterlacing_caps[20];
	vaQueryVideoProcFilterCaps(decoder->VaDisplay, decoder->VaapiContext[0].context_id, VAProcFilterDeinterlacing, deinterlacing_caps, &num_deinterlacing_caps);
	Warning(_("postproc returned %d interlacers\n"), num_deinterlacing_caps);


	unsigned int i, j;
	for (i=0; i<num_filters; i++) {
    	switch (filters[i]) {
    	case VAProcFilterNoiseReduction:
        	Warning(_("postproc filter %d is noise reduction\n"), i);
        	break;
    	case VAProcFilterDeinterlacing:
        	Warning(_("postproc filter %d is deinterlacer\n"), i);
        	for (j=0; j<num_deinterlacing_caps; j++) {
            	int t;
            	t = ((VAProcFilterCapDeinterlacing *)&(deinterlacing_caps[j]))->type;
            	switch (t) {
            	case VAProcDeinterlacingNone:
                	Warning(_("postproc deinterlacer %d is none\n"), j);
                	break;
            	case VAProcDeinterlacingBob:
                	Warning(_("postproc deinterlacer %d is bob\n"), j);
                	break;
            	case VAProcDeinterlacingWeave:
                	Warning(_("postproc deinterlacer %d is weave\n"), j);
                	break;
            	case VAProcDeinterlacingMotionAdaptive:
                	Warning(_("postproc deinterlacer %d is motion adaptive\n"), j);
                	break;
            	case VAProcDeinterlacingMotionCompensated:
                	Warning(_("postproc deinterlacer %d is motion compensated\n"), j);
                	break;
            	default:
                	Warning(_("postproc deinterlacer %d is unknown\n"), j);
                	break;
            	}
        	}
        	break;
    	default:
        	Warning(_("postproc filter %d is unknown\n"), i);
        	break;
    	}

Wenn du etwas einfacher herumspielen willst,
anbei mein vaapi Testprogramm, mit #if Teil fliegt vaapi auf die Schnautze mit Staging Branch sagt er wenigstens das er kein Subpicture hat.

gcc -ggdb -o vaapi-killer chaos/vaapi.c `pkg-config --libs libva-x11 libva-glx libva`

Solange man noch keine Advanced Interlacer auswählen kann, lohnt sich das herumspielen noch nicht.

Johns

Als interessierter Laie würde ich gerne etwas zur Theorie der Bildaufbereitung erfahren. Es geht um den in softhddevice erwähnten Known bugs VA-API 1080i does no v-sync, wie wir es auch in diesem Beitrag kurz andiskutiert hatten.

Lässt es sich kurz erläutern, welche algorithmische Mechanik hinter diesem syncing steht?

Ich meine nach einem Blick auf den softhddevice Code, dass der Videostrom am Audiostrom ausgerichtet wird.
Vielleicht, weil man Video unbemerkbarer verzögern und beschleunigen kann?

Wenn diese Beobachtung so richtig ist, verstehe ich nicht, warum man überhaupt eine aktive Aktion dafür vorsehen muss.
Der Beispielcode aus putsurface legt doch nahe, dass man die Surfaces einfach bei Verfügbarkeit übergibt, und sich die Hardware um den Rest kümmert.
Man kann beispielsweise dort einfach mit 20ms framerate übergeben, obwohl mit 16,6ms dargestellt werden muss.

Also Fragen wären:
- Lässt sich dieser sync Vorgang in Software eingängig erklären?
- Synct man nicht grundsätzlich am qualitativ höchstwertigem und schnellstem Datenstrom?
- Wo kommt der Darstellungstakt in softhddevice her, welchen Codeteil im softhddevice sollte man sich genauer ansehen?
- Können frame drops und duplicates in die Hardware verlagert werden? Warum macht man 'manuell' drops und dups?
- Literaturlink?

cmsa:
Gemeint ist das hier: http://de.wikipedia.org/wiki/Tearing

Man muss daher etwa bei der HD3000 meist mit mplayer -vo gl bzw. mplayer -vo vdpau:gl loslegen. Oder man nimmt Compiz, damit wird immer gesynct (auch Flash-YouTube-Filmchen). Aber für gesynctes 1080i brauchts wohl noch was im Treiber? (nicht getestet)

Zitat von cmsa

Als interessierter Laie würde ich gerne etwas zur Theorie der Bildaufbereitung erfahren. Es geht um den in softhddevice erwähnten Known bugs VA-API 1080i does no v-sync, wie wir es auch in diesem Beitrag kurz andiskutiert hatten.

Lässt es sich kurz erläutern, welche algorithmische Mechanik hinter diesem syncing steht?

Passt nicht ganz in diesen Thread, wäre besser einen Eigenen aufzumachen.

Es sind hier zwei Verschieden Syncs.

• v-sync
  Vertical Sync, hier wird die Wiedergabe mit dem Vertical Sync synchronisiert. Siehe link vom rechenknechtler.
• lipsync
  Hier wird der Ton und Bild synchronisert. Damit die Sprache Lippen Synchron ist. http://en.wikipedia.org/wiki/Lipsync

Zurück zu VA-API. Hier sollte vaPutSurface sich um den v-sync kümmern.
Also man ruft einfach vaPutSurface, wenn eine Frame noch angezeigt wird, dann warte diese Funktion bis die Nächste angezeigt wird.
Siehe Beispiel aus libva "putsurface" bzw. "test/putsurface/" für den Source.
Wenn man den Bildschirm mit 50 Hz laufen lässt, dann braucht vaPutSurface im Schnitt 20ms und mit 60 Hz dann 16.6ms.

Mein Problem ist, das dies bei allen Auflösungen bis auf 1080i klappt.
Ich wollte ein Testprogramm schreiben um diesen Bug bei VA-API zumelden, aber leider klappt schon das obige Testprogramm nicht.
Dieses habe ich versucht auf der VA-API Maillingliste zuposten, leider scheint aber dort der Maintainer der Maillingliste zuschlafen, wie auch alle Anderen die zu VA-API gehören.

Johns

Zitat von johns

Zurück zu VA-API. Hier sollte vaPutSurface sich um den v-sync kümmern.
Also man ruft einfach vaPutSurface, wenn eine Frame noch angezeigt wird, dann warte diese Funktion bis die Nächste angezeigt wird.
Siehe Beispiel aus libva "putsurface" bzw. "test/putsurface/" für den Source.
Wenn man den Bildschirm mit 50 Hz laufen lässt, dann braucht vaPutSurface im Schnitt 20ms und mit 60 Hz dann 16.6ms.

Das ist genau mein Punkt.
In putsurface_common.c habe ich gesehen

187: while (1) {
209: 	vaPutSurface();
238: 	sleep(interFrameGap);
367: }

Hier kommt vaPutSurface anscheinend asynchron zurück.
Wo ist der Unterschied, hast Du die Surface bei der Erzeugung als synchron parametrisiert?

Man kann nichts konfigurieren. Leider sind die Anleitungen auch sehr mager.

Der sleep ist unnötig, wenn man syncron zur Bildschirmfrequenz arbeitet.
Aber für z.b. für 25 Hz oder 12.5 Hz kann man ihn verwenden.
Andere < Bildschirmfrequenz gehen auch, aber mit vielen Microrucklern,
weil der Bildwechsel nur alle 20ms (50 Hz) erfolgen kann.

Johns

Ich würde noch schnell branch vaapi-ext bzw. staging holen.
Weil in Kürze gibt es einen Update der die Advanced Deinterlacer für die
normalen Routinen entfernt.
Wie gezeigt gibts aber die Advanced Deinterlacer für die neuen Routinen noch
gar nicht.

Warum man etwas ausbaut was funktioniert, daß verstehen nur Intel Ingenieure.

*sich hier Wutanfall und viele Beleidigungen vorstellen*

Johns

Morgen,

ich denke man möchte so weitere Fragen zu dem Thema (die ja so nicht beantwortet werden) erstmal komplett zu vermeiden. Das wirft uns ja um Jahre zurück wenn da jetzt erstmal garnicht mehr weitergemacht wird. Traurig!

Gruß
Atech

Zitat von johns

Weil in Kürze gibt es einen Update der die Advanced Deinterlacer für die
normalen Routinen entfernt.

Wie kommst du darauf? Meinst du das hier?

Zitat von Gwenole Beauchesne

Avoid advanced deinterlacing kernels as they allocate extra temporary surfaces, which are useless for such simple tasks. i.e. display either field of an interlaced surface.

Wie die bisherige Diskussion verstanden habe, können libva/i965 sowieso nur bob/weave. Was hat sich denn da verschlechtert?
VG
Kurt

Zitat von kh1309

Wie die bisherige Diskussion verstanden habe, können libva/i965 sowieso nur bob/weave. Was hat sich denn da verschlechtert?

Wenn der staging Branch verwendet wird, kann man sehen, wie sich Intel die Programmierung der Videopipeline vorstellt.
Ist ziemlich geil und tut auch schon, allerdings sind die zurückgegebenen Capabilities nur Bob und Weave.

Verwendest Du den ext Branch, kann man m.E. gar nichts einstellen, der Default für Interlaced sieht nicht nach Bob aus, muß also MotionAdaptive oder MotionCompensated sein...

Zitat von kh1309

Wie kommst du darauf? Meinst du das hier?

Wie die bisherige Diskussion verstanden habe, können libva/i965 sowieso nur bob/weave. Was hat sich denn da verschlechtert?

Genau diesen Patch meinte ich.
In den Branch vaapi-ext und staging haben die VAAPI Entwickler neue Deinterlacer eingebaut, die mehr können. Ivy und Sandy Bridge klappt es gut. Mit dem Vorgänger Ironlake nicht so gut.
Im Prinzip ist der Patch schon richtig, wenn man Bob anfordert will man Bob, aber leider fehlt der Rest.

Johns

Da steht doch aber mit keinem Wort: "Wir machen Advanced Deinterlacing" weg.

"Vermeide die Verwendung der Advanced Deinterlacing Kernel (bei Bob), denn sie verbrauchen unnütze zusätzliche Surfaces."

Das stimmt schon. Wenn es aber nur Bob als Deinterlacer gibt (der im Moment mehr als Bob macht) und keinen Anderen, wie will man dann die Advanced Deinterlacer noch verwenden?

Man kann nur Weave oder Bob wählen!

Johns

Im Moment ist absolut nicht klar welchen branch man bei VA-API nehmen. Ein paar fixes in dem branch ein paar in einem anderen. Die Entwicklung sieht dort sehr planlos aus.

Für den ein oder anderen interessant, ich weiß es nicht, aber nachdem ich "Render Standby" bei mir im BIOS fest deaktiviert habe läuft es richtig flüssig mit VAAPI. Mit aktivierten "Render Standby" gab es Ruckler mit allen VAAPI-Kompillierten Programmen (VDR/xine-lib, mplayer, ...).

Der Kernel in git://people.freedesktop.org/~danvet/drm-intel ist auf 3.4.0-rc2+ gesprungen.
Ich verwende den Branch drm-intel-next-queued.
Der intel-driver (branch vaapi-ext) muss neu übersetzt werden.