sunxi-vdpau WIP (ehemals interlaced branch)

Quote from WoF

Ich baue das in die handles.c ein, dann kannst du deinen Code aufräumen

OK! Wenn ich morgen von der Knechtschaft komme ist Reinemachen angesagt.

Gruss zille

Habe einen Pull-Request mit meinen Änderungen an der handles.c im queue_deint-Branch gestellt.

WoF: Das ging flott :p Werde das mal ungetestet übernehmen. Ausschauen tuts gut ...
Jetzt noch aufräumen, Queue straffen, handle Zugriffe berichtigen ... Zille macht das schon :p
Danke
Andreas

WoF, wäre es nicht einfacher, die Funktionen handle_get und handle_acquire zusammen zu fassen, d.h. setzen des Mutex und Rückgabe des Handles?
Gruß
Andreas

Ich hab auch mal diverse Locks eingebaut, jetzt sollte erstmal alles wichtige threadsicher sein. Sorry falls jemand jetzt umsonst daran gearbeitet hat, ging alles etwas schnell.

Wozu soll das handle_acquire/release gut sein? Ich weiß, ist vom vaapi-gl backend abgeschrieben, aber ich finde keinen Grund warum man das brauchen sollte. mesa vdpau braucht es auch nicht.

Hallo Jemk,

Vielen Dank! Da werde ich mal saugen und loslegen.

Gruss zille

Hallo Jemk und Johns,

das vsync hab ich jetzt eingebaut und bei einem Film funktioniert es Prima. Wenn das OSD dazu kommt brauchen die surfaces aber 25 bis 30 ms. Da stürzt die libvdpau klanglos ab. vdp_presentation_queue_block_until_surface_idle scheint das surface zum Löschen frei zugeben.

Ich will jetzt ein doppeltes Anzeigen einbauen. Dazu brauche ich eine klare Zuordnung was welches surface ist. Steht in dem zusammengewürfeltem struct irgendwo was drin ( Zeit, Nummer, etc) um ein surface als das eine zu identifizieren?
Das funktioniert leider nicht:

oldvs = nowvs;
	nowvs = os->vs;


	oldtask = task;

Gruß zille

Edit: Der Code liegt da.

Hallo Zille,

kann man deinen Code irgendwo einsehen?

Quote from WoF

Hallo Zille,

kann man deinen Code irgendwo einsehen?

Jo, da isses.

Gruss zille

Quote from Zille

Hallo Jemk und Johns,

das vsync hab ich jetzt eingebaut und bei einem Film funktioniert es Prima. Wenn das OSD dazu kommt brauchen die surfaces aber 25 bis 30 ms. Da stürzt die libvdpau klanglos ab. vdp_presentation_queue_block_until_surface_idle scheint das surface zum Löschen frei zugeben.

Ich will jetzt ein doppeltes Anzeigen einbauen. Dazu brauche ich eine klare Zuordnung was welches surface ist. Steht in dem zusammengewürfeltem struct irgendwo was drin ( Zeit, Nummer, etc) um ein surface als das eine zu identifizieren?

Das OSD wird über VdpOutputSurfaceRenderBitmapSurface oder VdpOutputSurfaceRenderOutputSurface übergeben.
IIRC wird nur bitmap von sunxi unterstützt. Ob dies nun eine eigene Fläche bleibt und ins Video gerendert wird, weiß ich nicht.
Eine Freigabe bei Idle sollte kein Problem sein, da diese OSD Fläche jedesmal für jede Video Fläche zum Treiber hochgeladen wird.

Und das mit dem doppelt verstehe ich nicht. Darum hat sich schon die Anwendung (SoftHdDevice) gekümmert.

OSD + Video -> Ausgabefläche

Die obige Videofläche wird bei Interlace zweimal übergeben. (VdpVideoMixerRender)

"do_presentation_queue_display" arbeitet mit dem Ausgabeflächen diese enthalten Hintergrund, Videobild (auch mehrmals) und OSD (könnte auch mehrmals sein).

Johns

Quote from johns

Und das mit dem doppelt verstehe ich nicht. Darum hat sich schon die Anwendung (SoftHdDevice) gekümmert.

Die Ausgabe passiert mit 20ms pro surface. Die Anlieferung ueber vdp_presentation_queue_display mit OSD Daten dauert aber laenger als 20ms. Das schwankt zwischen 23 bis 30 ms. Da ist die Queue irgendwann mal leer und die lib stuerzt ab. Darum will ich wenn nur 1-2 surfaces in der Queue liegen ein surface doppelt anzeigen um 20 ms rauszuschinden.

Hab grad VdpPresentationQueueStatus
*status gefunden. Damit muesste es glaub ich gehen.

Quote

Das OSD wird über VdpOutputSurfaceRenderBitmapSurface oder VdpOutputSurfaceRenderOutputSurface übergeben.

Wenn ich das richtig sehe wird das OSD ueber vdp_presentation_queue_display als Layer uebergeben und angezeigt. Kann das ueber die obigen Methoden schneller gemacht werden? 20ms sind das Limit!

Gruss zille

Achso, wenn keine neue Fläche zur Verfügung steht, dann einfach nichts machen.
Einfach den Status der Fläche auf "Displayed" lassen.
"first_presentation_time" darf nur beim ersten Anzeigen gesetzt werden.

Die Anwendung kümmert sich dann darum, daß A/V im Sync bleibt.

Auch ältere schwächere NVidia Karten hatten Probleme mit der Peformance mit OSD.
Ich habe schon von der Anwendungsseite optimiert, es wird nur angezeigt, wenn OSD etwas enthält und es wird nur der Bereich angezeigt der auch Informationen enthält.

Für weitere Optimierungen müsste man im VDPAU Treiber messen, wo die Zeit verloren geht.
z.b. wird häufiger der gleiche Inhalt angezeigt, dies könnte man mit etwas CPU Leistung überprüfen, wenn nicht die CPU Leistung bereits das Problem ist.

Johns

Quote from Zille

Das OSD wird mit Hilfe des Mixer Prozessor (G2D) in das Output Surface kopiert. D.h. die blits und fills werden hardwareseitig erledigt. Evtl. liegt da schon die Schwachstelle.
In do_presentation_queue_display wird dann zuerst das VideoSurface (os->vs) auf einen Layer geschrieben (q->target->layer). Danach wird überprüft, ob sich was auf dem Output "RGBA" Surface befindet (os->rgba) und entsprechend dargestellt. Dabei wird der VideoSurface-Layer mit einem weiteren Layer (OSD) überlagert.
d.h. ioctl(q->target->fd, DISP_CMD_LAYER_SET_PARA, args) und ioctl(q->target->fd, DISP_CMD_LAYER_OPEN, args) werden doppelt ausgeführt. 1x für Video Layer, 1x für OSD. Mögliche zweite Schwachstelle.

@zille: Hast du meineGedanken schon mal angesehen?
Und was hat das Warten auf 3 Tasks in der Queue für einen Hintergrund?

Gruß Andreas

Zu lange dauert das Anliefern mit vdp_presentation_queue_display. Da ich momentan nur an einer Stelle messe steckt da der gesamte Kreis drin. Von VDP_STATUS_OK;, Softhddevice, Aufruf vdp_presentation_queue_display, Speicher reservieren in die Queue packen. Vor VDP_STATUS_OK nehme ich die Zeit.

Ab Presentation_thread ist problemlos in 20 ms zu schaffen.

Gruss Zille.

Quote from Zille

Zu lange dauert das Anliefern mit vdp_presentation_queue_display. Da ich momentan nur an einer Stelle messe steckt da der gesamte Kreis drin. Von VDP_STATUS_OK;, Softhddevice, Aufruf vdp_presentation_queue_display, Speicher reservieren in die Queue packen. Vor VDP_STATUS_OK nehme ich die Zeit.

Ab Presentation_thread ist problemlos in 20 ms zu schaffen.

Gruss Zille.

Dann brauchts wohl Zwischenzeiten, um zu sehen, wer der Bremser ist...
Gruß Andreas

Hallo

Quote from rell

Dann brauchts wohl Zwischenzeiten, um zu sehen, wer der Bremser ist...
Gruß Andreas

Das fällt sehr eindeutig aus. Fast 24 ms ausserhalb und lediglich 0,1 ms innerhalb von vdp_presentation_queue_display.

Differenz outside: 23814
Differenz inside: 124

Gruss zille

Hallo Andreas und Zille,
ich habe mir aus euren beiden Forks vsync und dint was zusammengebastelt
Das Deinterlace funktioniert ganz gut wenn man das Display auf 50Hz hat, es gibt nur ein Problem wenn man auf einen Kanal mit einer anderen Auflösung umschaltet ist das Bild verpuzzelt. Wenn man den VDR dann neu startet wird er richtig angezeigt.

Eine funktionierende Implementation ist nicht mehr weit entfernt.

Gruß Joachim

Quote from jodamm

Hallo Andreas und Zille,
ich habe mir aus euren beiden Forks vsync und dint was zusammengebastelt
Das Deinterlace funktioniert ganz gut wenn man das Display auf 50Hz hat, es gibt nur ein Problem wenn man auf einen Kanal mit einer anderen Auflösung umschaltet ist das Bild verpuzzelt. Wenn man den VDR dann neu startet wird er richtig angezeigt.

Eine funktionierende Implementation ist nicht mehr weit entfernt.

Gruß Joachim

... und wie sieht es mit einem grossflächigem OSD aus? Die kleinen nach Kanalwechsel überlebt die Lib hier auch.

Gruss zille

Hallo Zille,
hab deinen fork gestern mal probiert. Nachdem ich ein paar Dinge auskommentiert hatte, kam dann auch ein Bild.
Wir hatten dann am Ende des Tages mit unseren letzten Commits wohl ähnliche Gedanken :p

Zeit für IN und OUT betrug dann bei mir am Ende konstant +/- 40000, also 25Hz ?! Mit mpv, wenn ich mich richtig erinnere. OSD klappte auch. Prinzipiell. Ich denke aber, da muss nachgebessert werden.
Ich habe dann aufgehört und werde heute abend wieder drüber nachdenken...

Gruß Andreas

Hi Andreas,

Quote from rell

Zeit für IN und OUT betrug dann bei mir am Ende konstant +/- 40000, also 25Hz ?! Mit mpv, wenn ich mich richtig erinnere. OSD klappte auch. Prinzipiell.

Was hast Du für eine Bildwiederholrate? Vsync sollte eigentlich 50 Hz, 20 ms pro Bild sein. Jedenfalls hier in Europa. Aber bei 40ms Du hast keine Probleme mit OSD.

Gruss zille.