sunxi-vdpau WIP (ehemals interlaced branch)

Hallo zusammen,

es gibt einen neuen Anlauf, die libvdpau-sunxi Sache weiterzutreiben.
Wer möchte, kann den aktuellen Stand hier ausprobieren.
Damit sollte z.B. das Zappelbild beim Kanalwechsel auch verschwunden sein. Ein paar Fixes sind mit drin, weitgehend deckt sich der Stand mit den Vorgängerversionen.
Es hat aber ein kompletter Rebase auf Basis des vermutlich neuen libvdpau-sunxi/master von jemk stattgefunden, und gleichzeitig habe ich versucht etwas aufzuräumen...

Bitte vorher die Readme lesen, es wurde die Abhängigkeit von libcsptr eingeführt, das nun vorher gebaut werden muss. Es werden nun nämlich smart pointers für die Referenzen verwendet.
Es wäre toll, wenn das einige ausprobieren könnten und Rückmeldung geben, da ich bei mir hier immer noch ca. 2% missed frames habe und der Sache auf den Grund gehen möchte... Evtl. liegt das gar nicht an libvdpau-sunxi...

Viel Spaß
Andreas

Zitat von Moorviper

igor hat auch das image angepasst und es sind nun die patche von rell enthalten

Wo waren die Images nochmal zu finden?
Edit: ok, hier .... http://www.igorpecovnik.com

Wohl wieder was eingeschlichen .... Dieses Rebasen macht mich wahnsinnig
Ich kann mir das erst heute abend ansehen, aber vielleicht löst der Patch das Problem ja schon ...

Gruß Andreas

Denke nicht. Da ist noch irgendwo ein Fehler. Das liegt wohl an libvdpau-sunxi. War ich wieder zu vorschnell, sorry
Gruß Andreas

So, hier läuft der letzte upstream_staging branch jetzt mit vdr.
Jetzt kommen die missed frames dran. Hat die noch jemand?

Gruß
Andreas

Hallo Andreas,

ich habe eine Frage zum Kompilieren. Wir haben verstanden, das wir nun libcsptr mit aktivieren müssen, das habe wir nun auch auf unserer Develmaschine eingebaut. Nun zu meiner Frage.

In dem Makefile vom libvdpau-sunxi ist die Abfrage auf die "LIBS = -lrt -lm -lX11 -lpthread -lcsptr", aber wo ist denn die library "csptr". Erzeugt wird doch nur die "/usr/local/lib/libcsptr.so"?

h264.c: In function ‘ref_pic_list_modification’:
h264.c:263:19: warning: unused variable ‘long_term_pic_num’ [-Wunused-variable]
      unsigned int long_term_pic_num = get_ue(c->regs);
                   ^
h264.c:281:19: warning: unused variable ‘abs_diff_pic_num_minus1’ [-Wunused-variable]
      unsigned int abs_diff_pic_num_minus1 = get_ue(c->regs);
                   ^
h264.c:285:19: warning: unused variable ‘long_term_pic_num’ [-Wunused-variable]
      unsigned int long_term_pic_num = get_ue(c->regs);
                   ^
/usr/bin/ld: cannot find -lcsptr
collect2: error: ld returned 1 exit status
Makefile:27: recipe for target 'libvdpau_sunxi.so.1' failed
make[2]: *** [libvdpau_sunxi.so.1] Error 1
Makefile:20: recipe for target 'src/libvdpau-sunxi' failed
make[1]: *** [src/libvdpau-sunxi] Error 2

und dann weiter die Frage, kann man die Library nur auf einem BananaPi übersetzen? (Wir haben unsere ARM-Entwicklungsumgebung auf einem RPI2 aktiv)

Hintergrund: Wenn ich mit "ldd libcsptr.so" die Überprüfung mache, so sind hier unterschiedliche Ausgaben..
auf dem RPI2 (Debian Jessie, gcc version 4.9.2 (Debian 4.9.2-10, Linux Kernel 3.8.11) sieht so aus:

ldd libcsptr.so 
	/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0x76fad000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76e4c000)
	/lib/ld-linux-armhf.so.3 (0x76fcc000)

auf einem BananaPi (Debian Jessie, gcc version 4.9.2 (Debian 4.9.2-10, Linux Kernel 4.1.1) sieht es so aus:

ldd libcsptr.so 
	linux-vdso.so.1 (0xbed8f000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6ea7000)
	/lib/ld-linux-armhf.so.3 (0x7f603000)

Habe das Problem verständlich beschrieben?

Gruß,

Pit

Zur Frage 1:
Bei mir siehts so aus:

root@Cubieboard2:/# find / -name *csptr*
/usr/local/share/man/man3/csptr.3
/usr/local/include/csptr
/usr/local/lib/libcsptr.so
/usr/local/lib/libcsptr.so.0.0.0
/usr/local/lib/libcsptr.so.0
/usr/local/lib/libcsptr.a
/usr/local/lib/libcsptr.la

Frage 2:
Da sind die Experten gefragt, aber wenns mit libvdpau-sunxi klappt, dann sollte es mit libcsptr doch auch gehen?

[EDIT]Frage zurück: Übersetzt ihr nur mit Kernel 4.1.1, oder ist das auch der Kernel, der in MLD für sunxi drin ist? Denke nicht ...[/EDIT]
Gruß Andreas

Hallo zusammen,

an alle, die heute den neuen Stand schon gezogen haben, bitte nochmal machen
Da wir uns ja in WIP befinden, habe ich mir erlaubt, die Fehler über ein rebase auszumerzen und gleichzeitig den Stand nach linux-sunxi/libvdpau-sunxi zu pushen. Der experimentelle Branch ist der staging. Der entspricht auch meinem staging.
Bitte aber den "offiziellen" benutzen, da dieser hoffentlich kein Rebase mehr erfährt. Bei meinem kann ich für nichts garantieren.

Viel Spaß beim testen und wie gesagt, mich würden die missed frame Meldungen interessieren.

Danke und Gruß
Andreas

Hallo Andreas,

Danke für die Aktualisierung. Wir konnten unsere Umgebung auch fertig bekommen. Nun steht dieser Stand auf der MLD 5.0 zur Verfügung. Ich denke/hoffe das auch Aussagen zu deiner Rückfrage mit dem Framedrops kommen...

gruss,

Pit

Habe es gerade mit der Aktuellen MLD 5.0 BPi am laufen zum Test und nach ersten eindrücken sind die Umschaltzeiten besser geworden und auch dir grünen Streifen und das ruckeln nach dem Umschalten weg. Verlorene Frames bestehen auch so wie Pit schon geschrieben hat

mafe68: Danke fürs probieren. Freut mich, dass es nicht nur bei mir läuft. Könntest du beizeiten mal ein Log von libvdpau mit

#define DEBUG
#define DEBUG_LEVEL LINFO // oder LDBG, aber das ist extrem gesprächig 
#define DEBUG_TIME
#define DEBUG_LEVEL_TIME LPQ2 // oder LDEC, da wären die Zeiten mit drin, wie lange der Decoder braucht

posten? Da wären die Timestamps drin und vielleicht helfen die ja bei der Suche weiter. Ich meine, dass die missed frames bei ARD(z.B. Fußball) deutlich mehr sind, als bei ZDF (SD)...

Moorviper: Bitte ebenfalls das Log von vdpau mitgeben, irgendwas passt noch nicht, wenn kein Bild kommt. Geht MPV?

Danke und Gruß
Andreas

Morgen Andreas!

Werde dir die Log hier Posten wenn ich den Bpi wieder dran habe da zur Zeit ein Test läuft wegen Harten Abschalten (Einfach Strom weg nehmen im laufen Betrieb Rpi) wo es anscheinend immer wieder Probleme bei unserer MLD geben soll das sie nicht mehr startet.