sunxi-vdpau WIP (ehemals interlaced branch)

Hallo WoF,

an der Stelle sehe ich das Problem eigentlich nicht. Die Zusammenarbeit von softhddevice und ffmpeg klappt schon. Das Problem sehe ich im disp Treiber. Ohne Deinterlacer kommt der mit dem Format klar. Nur der Deinterlacer nicht. Dem Deinterlacer müsste man beibringen mit dem Format umgehen zu können.

Ich für meinen Teil werde da nicht weiter forschen. DMA und NAND ansteuerung geht ja auch nicht. Ich hab mir ein Hummingbird bestellt. Der Umgang von Freescale mit der Commutity ist anders als Allwinner das praktiziert. Nur schade das ich das Board nicht zurückschicken kann.

Gruss zille

Hallo zille,

schade dass du nicht mehr an dem Vorhaben weiterarbeitest. Bei dir hat es doch schon zufriedenstellend funktioniert und dann so kurz vor der Zielgeraden aufgeben?

Bei mir geht softhddevice in Vdpau_get_format() in den slow_path und macht dann ohne Hardware-Beschleunigung weiter:

Dec 13 16:42:45 Cubian vdr: audio: 2 channels unsupported
Dec 13 16:42:45 Cubian vdr: video: get hwaccel context, not supported
Dec 13 16:42:45 Cubian vdr: video/vdpau: no valid vdpau pixfmt found

Hallo WoF,

Dec 10 17:23:25 cubie vdr: video: get hwaccel context, not supported

die Zeile steht hier auch im Log. Trotzdem funktioniert HW Decoding und Deinterlacing. Die beiden anderen Zeilen gibt es bei mir nicht. Hast Du NO_MPEG_HW=1 und -a none in deiner Konfiguration?

Gruss zille

Hallo zille,

NO_MPEG_HW habe ich nicht gesetzt und -a steht bei mir auf sunxihdmi. Mit NO_MPEG_HW=1 kommt das "video/vdpau: no valid vdpau pixfmt found" nicht mehr, springt aber dann sofort in den slow_path in video.c:7274.

... da gab es doch das Problem mit signed char. Versuch mal den Patch auf softhddevice.

Gruss zille

Der Patch hat es gebracht! Zusätzlich musste ich noch auf ffmpeg 2.2 downgraden, da ffmpeg 2.5 wahrscheinlich ein Pixelformat bereitstellt, das softhddevice noch nicht unterstützt (PIX_FMT_VDPAU_MPEG2 vs. PIX_FMT_VDPAU).

Im Bild sind sehr starke MPEG-Kompressionsartefakte sichtbar, die im Original nicht enthalten sind. Das sieht schrecklich aus. Siehe Anhang. Ist das bei euch auch so?

Hallo WoF,

ich blicke nicht mehr ganz durch, wie der aktuelle Stand ist. Du benutzt ffmpeg 2.2 mit welcher Version von softhddevice und mit welcher Version von sunxivdpau?
Was geht denn mit deiner Konfiguration? SD-Kanäle hardware-beschleunigt? HD-Kanäle? Alles auch deinterlaced?
Ich frage, weil ich dann auch mal testen will, wenn die grundlegenden Sachen laufen.

Ich benutze ffmpeg in Version 2.2.11, von softhddevice die GIT-Version vom 16.10.2014 und von libvdpau-sunxi diesen Branch von zille. Die Schilderungen von mir bisher, sind von SD-Kanälen. HD reiche ich nach.

Hallo WoF,

gratuliere!

Quote from WoF

Im Bild sind sehr starke MPEG-Kompressionsartefakte sichtbar, die im Original nicht enthalten sind. Das sieht schrecklich aus. Siehe Anhang. Ist das bei euch auch so?

ja sieht bei mir manchmal auch so aus. Der Mpeg2 Decoder braucht wohl noch etwas tuning. Das hängt aber auch vom Fimmaterial ab das angeliefert wird. Einige Filme sehen gut aus. Das kann aber auch eine Überstrahlung sein. Es sieht bald aus wie ein Schatten. Auf dem Bild mit der schwarzen Schrift sieht man das gut.

Gruss zille.

Bei HD (Das Erste & Servus TV Österreich HD) macht er hier ein Segmentation fault. surface_p ist ein NULL-Pointer. Wenn ich das richtig sehe kann das nur passieren wenn er nicht genügend Speicher hat...

Hier rennt es stabil. Kein Absturz. Hab aber auch reichlich Speicher reserviert:

sunxi_cedar.c gepatcht: ve_size=190

Thx zille, mit 190MB funktioniert Servus TV und die MPEG-Blockartefakte sind (wahrscheinlich wegen der Auflösung) geringer als bei SD. Bewegte Kanten fransen immernoch minimal aus. Siehe Bild im Anhang. Das habe ich bei SD auch beobachtet. Bei Farbverläufen sieht es so aus als wenn die Farbtiefe nur geschätzte 16Bit sind.

EDIT: 720p (Das Erste) funktioniert ebenso.

Eventuell sind die bild schärfungsfunktionen von softhddevice da nicht passend eingestellt oder inkompartibel?

Ich glaube softhddevice hat gar keine Schärfungsfunktionen.

Aber was anderes...
Irgendwas mache ich grundlegend falsch. Ich habe versucht die Konfiguration von WoF zu bauen,
kriege aber undefined symbol: vdp_device_create_x11 beim Starten des vdr.
Es sieht so aus, als ob softhddevice vdp_device_create_x11() aufruft, libvdpau-sunxi aber nur
vdp_imp_device_create_X11() bereit stellt.
Ich könnte das ja im source ändern, aber ist das notwendig oder habe ich doch noch irgend eine falsche Version?

Quote from Banknote

Ich glaube softhddevice hat gar keine Schärfungsfunktionen.

Aber was anderes...
Irgendwas mache ich grundlegend falsch. Ich habe versucht die Konfiguration von WoF zu bauen,
kriege aber undefined symbol: vdp_device_create_x11 beim Starten des vdr.
Es sieht so aus, als ob softhddevice vdp_device_create_x11() aufruft, libvdpau-sunxi aber nur
vdp_imp_device_create_X11() bereit stellt.
Ich könnte das ja im source ändern, aber ist das notwendig oder habe ich doch noch irgend eine falsche Version?

Nichts ändern! Da stimmt was mit libvdpau.so nicht. Siehe hier.
Ist die auf deinem System vorhanden?
Gruß
Andreas

Ja, die ist vorhanden.

ls -al /usr/lib/arm-linux-gnueabihf/libvdpau.so gibt:
lrwxrwxrwx 1 root root 25 Nov 9 01:20 /usr/lib/arm-linux-gnueabihf/libvdpau.so -> vdpau/libvdpau_sunxi.so.1

Der Link sieht aber merkürdig aus. Ich würde sagen der zeigt auf das falsche Ziel. Bei mir sieht das so aus:

root@Cubian:~# ls -la /usr/lib/arm-linux-gnueabihf/libvdpau.so*
lrwxrwxrwx 1 root root   17 Aug 16  2012 /usr/lib/arm-linux-gnueabihf/libvdpau.so -> libvdpau.so.1.0.0
lrwxrwxrwx 1 root root   17 Aug 16  2012 /usr/lib/arm-linux-gnueabihf/libvdpau.so.1 -> libvdpau.so.1.0.0
-rw-r--r-- 1 root root 9716 Aug 16  2012 /usr/lib/arm-linux-gnueabihf/libvdpau.so.1.0.0
root@Cubian:~# ls -la /usr/lib/arm-linux-gnueabihf/vdpau/
total 228
drwxr-xr-x  2 root root   4096 Dec 16 15:16 .
drwxr-xr-x 32 root root  40960 Dec 16 15:16 ..
-rwxr-xr-x  1 root root 145313 Dec 16 15:12 libvdpau_sunxi.so.1
lrwxrwxrwx  1 root root 	23 Aug 16  2012 libvdpau_trace.so.1 -> libvdpau_trace.so.1.0.0
-rw-r--r--  1 root root  34220 Aug 16  2012 libvdpau_trace.so.1.0.0

softhddevice hängt nur von libvdpau.so.1 ab. Die libvdpau_sunxi.so.1 wird dann zur Laufzeit nachgeladen.

Ok, vielen Dank an alle.
Mein System war völlig verkorkst (zuviel ausprobiert).
Jetzt gehen auf jeden Fall schon mal die SD-Sender.

Gruß
Horst

Quote from WoF

Thx zille, mit 190MB funktioniert Servus TV und die MPEG-Blockartefakte sind (wahrscheinlich wegen der Auflösung) geringer als bei SD. Bewegte Kanten fransen immernoch minimal aus. Siehe Bild im Anhang. Das habe ich bei SD auch beobachtet. Bei Farbverläufen sieht es so aus als wenn die Farbtiefe nur geschätzte 16Bit sind.

Hast du in den Softhddevice Einstellungen bei den Interlaced Auflösungen den Interlacer auf Temporal umgestellt? Dann sollte es eigentlich weg sein.