sunxi-vdpau WIP (ehemals interlaced branch)

Quote from Zille

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.

Tja, da liegt das Problem Ich weiß nicht mehr ob mit VDR oder MPV und wenn mit mpv, ob mit dem bunny oder einer VDR-Aufnahme
Ich tauch da heute abend nochmal ein ... Also erstmal nicht drauf einschießen.
Vielleicht kann da ja auch Joachim seinen Code irgendwo einstellen, aus ein paar Forks werden wir doch was Vernünftiges zusammenbauen können.

Leider crasht mein WIP/queue branch gleich... da bedarf es noch der Fehlersuche. Das ist so eine Sache, wenn man alles auf einmal aus dem Kopf schreibt und zwischendrin nie testet Ich würde mir für den upstream branch wünschen, dass man auf die Abhängigkeit von glib verzichten kann.

Gruß Andreas

Und wenn sich jemand mit Motion Adaptiv Filter - Deinterlacing auskennt, kann man auch versuchen, das zum Laufen zu bringen.
Der Display Engine müssen zwei Parameter mitgegeben werden, von denen ich nicht (genau) weiß, was sie bedeuten und wo man die herbekommt:
"Current frame block flag buffer address" (Speicheradresse des Ausschnitts, der für die Bewegungserkennung vom MAF Algorithmus verwendet wird?)
"block flag line-stride" (Abstand/ Größe zwischen den Kacheln?)
Vielleicht kann hier jemand aufklären, was es damit auf sich hat, dann könnte man sich auf die Suche begeben. Eine Vermutung wäre, dass die VPU das zur Verfügung stellt bzw. festlegt. Die Registeradressen sind wohl bekannt, allerdings nicht, wie sie belegt sind.

Bob hingegen würde funktionieren (wenn eingebaut :p)

Gruß Andreas

Entweder wir machen hier im Thread mit Grundlagen weiter oder wir machen für die Probleme einen neuen Thread auf.
https://www.vdr-portal.de/board17-develo…0-c-c-scripten/
Die glib ist einfach zuentfernen. Liste mit Mutex oder einen Ringbuffer. Kann man auch erst machen wenn alles läuft.

Motion Adaptiv Filter

Im Prinzip braucht man 2 Bilder, das aktuelle Bild und das zukünftige Bild, daraus wird ein Bild berechnet was dazwischen liegt.
Dies wird durch eine Bewegungsanalyse erreicht.
"Current frame block flag buffer address" klingt mir mehr nach einen Puffer für diese Bewegungsanalyse.
Gibts einen Link zur Docu?
"line-stride" ist der Abstand der Zeilen im Speicher. Bei 1920 wird gerne z.b. mit 2048 gearbeitet.
Kommt auf die Hardware an ob die mit Bytes oder nur anderen Größen häufig 16 Bytes arbeiten kann.
Man müsste diesen Speicher für die VPU im VPU Speicher reservieren.

Johns

Quote from johns

Entweder wir machen hier im Thread mit Grundlagen weiter oder wir machen für die Probleme einen neuen Thread auf.
https://www.vdr-portal.de/board17-develo…0-c-c-scripten/
Die glib ist einfach zuentfernen. Liste mit Mutex oder einen Ringbuffer. Kann man auch erst machen wenn alles läuft.

Hab ich hier mal angefangen, das Testprogramm funktioniert zumindest :p

Quote

Motion Adaptiv Filter

Im Prinzip braucht man 2 Bilder, das aktuelle Bild und das zukünftige Bild, daraus wird ein Bild berechnet was dazwischen liegt.
Dies wird durch eine Bewegungsanalyse erreicht.
"Current frame block flag buffer address" klingt mir mehr nach einen Puffer für diese Bewegungsanalyse.
Gibts einen Link zur Docu?
"line-stride" ist der Abstand der Zeilen im Speicher. Bei 1920 wird gerne z.b. mit 2048 gearbeitet.
Kommt auf die Hardware an ob die mit Bytes oder nur anderen Größen häufig 16 Bytes arbeiten kann.
Man müsste diesen Speicher für die VPU im VPU Speicher reservieren.

Johns

Display More

Die entsprechende Stelle im Quellcode, dann hier, weiter hier und hier. Resultiert letztendlich beim Setzen von Registerwerten 0x00bc und 0x00c0, die im User Manual (Seite 480, 504, 505) "beschrieben" sind.

Da wir von Allwinner bzgl. der Dokumentation von der VPU nichts haben, sind wir auf die Ergebnisse des RE-Engineering angewiesen. Dort werden bis dato lediglich die Register 0x30-0x4c ausgewiesen, die mit MAF zu tun haben. Nicht was sie wo enthalten.

Solange sich keiner zur fehlenden Übersicht beschwert, würde ich das alles hier halten. Alle Interessierten bleiben eh am Ball, denke ich

Gruß Andreas

Ich habe meine Änderungen auf Zilles Fork angewendet und einen eigenen Fork damit erstellt : https://github.com/jodamm/libvdpau-sunxi

Ich habe das OSD bisher nur auf meinem Monitor mit 1280*1024 getestet. Wenn das OSD offen ist, gibt es viele missed frames aber Ton und Bild bleiben in Sync.

Jetzt habe ich auch die Umschaltung auf eine andere Auflösung im Griff. Für mich schon ganz brauchbar, mal sehen wie stabil das läuft.

Edit: Leider klappt das beim Umschalten doch nicht immer, scheint an fehlerhaften frames zu liegen.
Edit 2: Habe scheinbar die Ursache gefunden os->vs->width war nicht immer gleich mit os->video_src_rect.x1 daher frage ich jetzt letzteres ab.

Hallo Jodamm,

Quote from jodamm

Ich habe das OSD bisher nur auf meinem Monitor mit 1280*1024 getestet. Wenn das OSD offen ist, gibt es viele missed frames aber Ton und Bild bleiben in Sync.

das Problem sitzt meist vor dem Monitor! Ich habe das Gentoo ebuild Script genommen um softhddevice zu installieren. In dem ist BITMAP nicht eingeschaltet!

Hier meine ersten Schritte zu deinterlacing.

Gruss zille

Quote from rell

Die entsprechende Stelle im Quellcode, dann hier, weiter hier und hier.

die Übergabe ans Kernel passiert m.E. weiter oben und steckt im DISP_CMD_VIDEO_* drin. Was ich noch nicht begriffen habe ist warum softhddevice video.interlace = 1 nicht setzt. Das Feature Temporal wird erkannt.

Dec  4 21:54:03 cubie vdr: video/vdpau: feature deinterlace temporal supported

Und wie top_field_first benutzt wird. Steckt da die Info des ersten fields drin oder muss das mit dem field wechseln?

Gruss zille

Quote from Zille

die Übergabe ans Kernel passiert m.E. weiter oben und steckt im DISP_CMD_VIDEO_* drin. Was ich noch nicht begriffen habe ist warum softhddevice video.interlace = 1 nicht setzt und wie top_field_first benutzt wird. Steckt da die Info des ersten fields drin oder muss das mit dem field wechseln?

Gruss zille

Genauer gesagt hier und zwar über die parameter .flag_addr und .flag_stride des video Objektes. Dazu muss auch .maf_valid gesetzt sein.
Aus dem Userspace wird das ganze wie du richtig gesagt hast über DISP_CMD_VIDEO_START und DISP_CMD_VIDEO_SET_FB veranlasst, die die entsprechenden Funktionen triggern und Variablen setzen.

video.interlace wird m.E. hier gesteuert. Frag mich nicht, wie das funktioniert, damit habe ich mich noch nicht befasst.
video.top_field_first: Hier geschehen interessante Dinge damit :p
Wenn current_picture_structure von softhddevice richtig gem. VDPAU übergeben wird, ist es 0, wenn das top field zuerst kommt. Demnach sollte das hier auch korrekt sein - wenn man sich auf den Variablennamen verlassen darf, und ohne verstanden zu haben, was der Display Code daraus macht :p

Mich würde interessieren, ob die Geschichte mit DISP_CMD_VIDEO und dem Setzen der video.addr auch funktioniert, wenn Deinterlacing nicht aktiviert ist. D.h. man könnte generell auf fb.addr und das anschließende DISP_CMD_LAYER_SET_PARA verzichten.

Der korrekte Ablauf für Deinterlacing wäre m.E.:
DISP_CMD_LAYER_SET_PARA
DISP_CMD_LAYER_OPEN
DISP_CMD_VIDEO_START
while {
DISP_CMD_VIDEO_SET_FB
}

Die Frage ist, ob das auch funktioniert, wenn diese Abfrage entfällt, dh. DISP_CMD_VIDEO_START generell beim ersten Durchlauf aufgerufen wird - immer, wenn ein Video an den FB geschickt wird.

Hoffe, die Zusammenfassung war richtig

Gruß Andreas

Hallo,

ich habe gestern ein wenig getestet. Dabei sind mir noch ein paar Dinge aufgefallen.

Jodamms branch funktioniert mit Softhdevice nur, wenn man den X-server beendet und dem Plugin den Parameter -x mitgibt. Beim Beenden von VDR läuft dann das syslog mit disp-Meldungen voll.

Zilles vsync-branch hat dieses Problem nicht und funktioniert auch mit gestarteten Display-Manager. Die Ruckler sind durch vsync deutlich weniger geworden, treten aber immer noch je nach Sender vereinzelt auf. Kann man da noch was machen, z. B. queue größer?

Ansonsten vielen Dank an alle. Das sieht schon richtig gut aus!

LG
beta

Quote from Zille

die Übergabe ans Kernel passiert m.E. weiter oben und steckt im DISP_CMD_VIDEO_* drin. Was ich noch nicht begriffen habe ist warum softhddevice video.interlace = 1 nicht setzt.

Ist mir auch aufgefallen. Die Werte Interlace und Top-Field-First erzeugt ffmpeg/libav ob ffmpeg/libav diese aus dem Stream oder MPEG/H264 ausliest oder einfach rät oder ignoriert, habe ich nicht nach vollzogen. Oder auch eine andere Bedeutung haben?

Ich habe einfach 720p als nicht interlaced angenommen.

Johns

Quote from beta

Die Ruckler sind durch vsync deutlich weniger geworden, treten aber immer noch je nach Sender vereinzelt auf. Kann man da noch was machen, z. B. queue größer?

Ja, den native DMA Treiber für das Kernel 3.4 portieren oder die Grafiktreiber für den Mainline Kernel entwickeln. Das Ruckeln tritt immer dann auf wenn softhddevice versucht AV synchron zu halten. Wenn ich das richtig interpretiere dauert es zu lange bis die Audio Daten geschrieben werden. das gössere Zappeln beginnt beim öffnen eines OSD. Dann braucht das Videosignal länger als die 20ms zwischen den Vsync Punkten. Eine grössere Queue bringt nix da Audio und Video synchron bleiben müssen. Da hilft nur schneller verarbeiten.

Gruss zille

Quote from beta

Jodamms branch funktioniert mit Softhdevice nur, wenn man den X-server beendet und dem Plugin den Parameter -x mitgibt. Beim Beenden von VDR läuft dann das syslog mit disp-Meldungen voll.

Die Ruckler sind durch vsync deutlich weniger geworden, treten aber
immer noch je nach Sender vereinzelt auf. Kann man da noch was machen,
z. B. queue größer?

Das kann gut sein, ich starte das Plugin mit -x Parameter. Aber die disp Meldungen bekomme ich nur wenn VDR abstürzt, wenn er normal beendet wird ist alles Ok.
Läuft dein Display auch mit 50Hz oder vielleicht doch mit 60Hz?

Hallo Jodamm,

mein Display läuft mit 50 Hz.

LG
beta

Deinterlacing für HW accelerated ist online. Leider geht ffmpeg aufbereitetes Material nicht weil das im Mode DISP_MOD_NON_MB_PLANAR kommt. Der Kerneltreiber verlangt aber DISP_MOD_MB_UV_COMBINED.

Softhddevice schickt es im YCBCR_FORMAT_YV12. Die HW Engine benutzt INTERNAL_YCBCR_FORMAT. Keine Ahnung worin sich die Formate unterscheiden und ob man die irgendwie konvertieren kann.

Gruss zille

Hallo zille,

irgendwas mache ich falsch, 576i Material spielt der VDR nicht gedeinterlaced ab. Braucht man einen bestimmen Patchlevel/Branch vom sunxi Kernel? Beim Starten von VDR sagt er, dass Temporal unterstützt wird (ist auch in softhddevice aktiviert):

Dec 11 15:17:26 Cubian vdr: video/vdpau: VDPAU API version: 1
Dec 11 15:17:26 Cubian vdr: video/vdpau: VDPAU information: sunxi VDPAU Driver
Dec 11 15:17:26 Cubian vdr: video/vdpau: high quality scaling unsupported
Dec 11 15:17:26 Cubian vdr: video/vdpau: feature deinterlace temporal supported

Ich kann leider den Code vom Gesamtsystem VDR, softhddevice, libvdpau, sunxi-Kernel noch nicht ganz überblicken. Wo kann ich am besten anfangen zu debuggen?

Gruß WoF

Hallo WoF,

lässt Du das in HW decodieren oder hast Du NO_HWMPEG gesetzt? Wenn top_field_first wechselt schaltet vdpau den Deinterlacer ein. Das Kernel akzeptiert aber nur Material welches in HW decodiert wurde. Siehe Beitrag oben.

Gruss zille.

Quote from WoF

Ich kann leider den Code vom Gesamtsystem VDR, softhddevice, libvdpau, sunxi-Kernel noch nicht ganz überblicken. Wo kann ich am besten anfangen zu debuggen?

Ich hatte bei mir auch 2 Tage gesucht bis ich endlich den Grund gefunden hatte warum es bei mir nicht ging. Bei mir hat softhddevice nicht die ffmpeg Bibliothek verwendet die ich kompiliert habe, sondern es war noch eine libav installiert die hatte aber keine vdpau Unterstützung.
Wie ist denn die CPU Last wenn du einen SD Kanal anschaust? VDR hat bei mir jetzt so ca.20% vorher mit der libav über 50% gehabt.

Gruß Joachim

Quote from WoF

Ich kann leider den Code vom Gesamtsystem VDR, softhddevice, libvdpau, sunxi-Kernel noch nicht ganz überblicken. Wo kann ich am besten anfangen zu debuggen?
Gruß WoF

Ich tat mich am leichtesten mit libvdpau und dem sunxi-Kernel (sobald man mal weiß, wo die Suche da beginnt). Softhddevice geht, obwohl die video.c doch riesig ist :p Und an VDR an sich habe ich mich noch nicht gewagt...
Andere Frage: Heißt es der oder das Kernel?

Gruß Andreas

Nach einigen Debugging-Sessions und dem Beseitigen des FFmpeg/libav-Versions-Chaos, habe ich herausgefunden, dass das Pixelformat nicht stimmt. FFmpeg liefert AV_PIX_FMT_XVMC_MPEG2_IDCT, softhddevice erwartet aber PIX_FMT_VDPAU_MPEG2. Nun habe ich gelesen, dass XvMC eine Erweiterung für X11 ist, die ebenfalls die MPEG-Dekodierung in der GPU ermöglicht. Wie kann ich ihm sagen dass er VDPAU und nicht XvMC zur Dekodierung nutzen soll?