Beiträge von rell

    Hi,


    ich habe den Orange Pi plus. Wie so oft bei Allwinner, hardwareseitig wohl gut, Software fehlt. Basis ist H3, also nicht mit den Sachen für A10/A10 nutzbar.
    Derzeit laufen nur die "fertigen" Images von der Homepage. Ich habe das Debian Server Image drauf, um "irgendwann" ein bißchen beim Kernel mainlining zu helfen. Da gibt es derzeit ein paar patches für rudimentäre Unterstützung im Kernel und in U-Boot. Leider fehlt es an Personal und wohl wie so oft die Zeit dafür ...
    VDR Server mit einem fertigen Image wird wohl funktionieren, als Client mit Video-Decoding analog zu den A10/A20 Geräten derzeit keine Chance. Ich habe nichts mitbekommen, dass sich jemand mit einem OpenSource Treiber ala libvdpau-sunxi noch mit den binary libs (falls vorhanden) auseinander gesetzt hat.
    Also warten oder selbst Hand anlegen.
    Ansonsten sympathisches Teil finde ich, vor allem wegen HEVC.


    Gruß
    Andreas

    Alleine, dass WETEK offiziell Kodi und OpenELEC unterstützen, macht die Firma schon unterstützungswürdig.


    Mag erstmal nichts heißen. Vidon.me stand da auch mal, weil Geld geflossen ist. Bis zu dem Zeitpunkt, als die XBMC'ler mitbekommen haben, dass sich Vidon.me wohl die GPL auch noch nicht so genau durchgelesen hat ...
    Bitte aber nicht falsch verstehen, ich möchte natürlich nichts unterstellen. Potenzial hat die Box imho, wenn man die Softwareseite lösen kann.


    Gruß Andreas

    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

    Code
    #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

    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

    Zur Frage 1:
    Bei mir siehts so aus:

    Code
    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,


    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

    Naja, dieses Howto nutzt die Version von Zille. Da funktioniert CSC nicht bzw. nicht richtig.
    Für den o.g. Branch ist seit diesem Commit CSC eingebaut. Wenn man will, dass Helligkeit, Kontrast etc. korrekt funktioniert, benötigt man einen Kernel ohne diesen Bug.
    Außerdem halt den letzten Stand inkl. diesem Commit, weil da noch ein paar Sachen korrigiert wurden.


    Gruß Andreas

    Hallo,
    dev_fix ist bei mir schon irgendwo im Nirwana ...
    Da ich ziemlich ohne Rücksicht auf Verluste die Branches merge und rebase, ist das mit den dev_ und WIP/... ein bißchen durcheinander und auch nicht unbedingt für die Öffentlichkeit gedacht ;)
    Ich weiß also gar nicht mehr, was im dev_fix so drin war ;) Das "Gute" sollte aber in den dev gewandert sein. Den möchte ich auch nach Möglichkeit so halten und nicht mehr rebasen, bis was in Mainline ist. Der sollte funktionieren.


    Empfehlen würde ich dir allerdings den aktuellen Stand. Das ist gerade WIP/rebased ;) Wie der Name schon sagt, tut sich da evtl. aber auch immer mal wieder was.
    Ziel ist es, den in upstream zu mergen. Vorher müssten aber noch ein paar Sachen korrigiert werden...


    Die Farben sollten bei beiden stimmen, vorausgesetzt, du hast den CSC Kernelpatch angewandt...


    Gruß Andreas

    Und wie läufts bei dir generell? z.B. mit lcars? Hast du "missed frames" bzw. "dropping frame" Meldungen?
    Ich hatte letztens speziell z.B. bei ARD SD ca. 3% verlorengegangene frames, und das waren schon mal ~0 meine ich ...
    Nicht dass ich da in der Zwischenzeit etwas an libvdpau vermurkst habe ...


    Gruß Andreas


    Kernel anpassen, darum habe ich mich bis jetzt gedrückt...


    Da kommst du leider nicht drum herum, wenn du willst, dass CSC bzw. die Einstellungen aus softhddevice funktionieren. Der Kernel hat hier leider einen Bug ....
    Und skinopacity schaue ich mir jetzt dann mal an ... Wie gesagt, damals hat VDR gleich seinen Dienst quittiert, dann habe ich da nicht weiter geschaut.


    Gruß Andreas

    Ich auch nicht ;) Ich würde meinen dev Brach nehmen. Ausser du bist experimentierfreudig ...
    Sollte ganz gut funktionieren. Skindesigner geht damit auch. Prinzipiell ;)
    Und wenn du deinen Kernel selber machst, dann vergiss den csc patch nicht...


    Gruß Andreas


    Allwinner hat seit kurzem den Sourcecode für CedarX unter die LGPL gestellt.


    Stimmt nicht ganz. Allwinner hat Teile des Codes "vermeintlich" neu geschrieben und das unter die LGPL gestellt. Und zwar werden die Codecs nun als "plugin" eingebunden. MPEG1/2/4 und H264 sind im Source vorhanden, sowie die Engine an sich. (Userspace Treiber). Mit dem Kernel Treiber hat das nichts zu tun, der ist open source.
    Was ich auf den ersten Blick so sehe, ist allerdings nicht die ganze Funktionalität, die die Hardware hergibt und womöglich in den alten binary blobs umgesetzt war, vorhanden. Register dokumentation ist lückenhaft. Und das wäre eigentlich das interessante. Der Encoder und die restlichen Codecs (z.B. VP8, VP6, MS-MPEG) müssen weiterhin als binary eingebunden werden. Das alles mag wohl ein Schritt nach vorne sein, löst aber nicht die Probleme von Allwinner, SÄMTLICHEN Source Code zu veröffentlichen, der in den alten binaries war welche die GPL verletzen.

    Zitat


    a) nicht mehr auf den sunxi-kernel angewiesen ist, sondern auch auf dem Mainline Kernel VDR mit VDPAU laufen lassen kann?


    Nein. Im mainline Kernel fehlt ein Modul für die Video Engine (Ein OS-Treiber ist angefangen und ein "Gerüst" war kurz online - bis die Situation mit Allwinner und der GPL nicht klar ist, wird hier allerdings nichts veröffentlicht). Außerdem fehlt der display Treiber (Da gibts wohl auch schon was im stillen Kämmerchen, Fertigstellung scheitert allerdings hauptsächlich an der Motivation, für einen GPL Violator den Code zu liefern). Den Mixer Prozessor, den libvdpau-sunxi für 2D Beschleunigung nutzt, könnte man wohl softwareseitig umschiffen - oder "einfach" selber schreiben.

    Zitat


    b) alle Allwinner SoC mit CedarX Unterstützung prinzipiell für VDR geeignet sind?


    Prinzipiell ja, wobei sich die API bzw. die Register der Video Engine in den Generationen - in welchem Umfang auch immer - unterscheiden. Unabhängig davon, dass das Ganze ja auch am Display Treiber hängt ... Und dessen API unterscheidet sich wohl auch, wenn man den SDK Releases von Allwinner trauen kann.

    Zitat


    c) auf welchen Allwinner SoC ist VDR mit VDPPAU jetzt praktisch möglich?


    A10 und A20

    Zitat


    d) welchen Einfluss hat die Freigabe des Sourcecodes auf die Portierung des VDR auf Allwinner SoC?


    Wenn wir von Portierung von VDR auf Allwinner SoC sprechen, gibts nur zwei Sachen zu beachten. libvdpau-sunxi und den Kernel mit Display Treiber und VE Treiber. Der Kernel muss display und video engine können und die libvdpau-sunxi muss diese beiden Treiber bzw. die Register mit der (jeweils SoC-versionsabhängigen) richtigen API ansprechen. Der Rest ist einfach nur ein linux auf arm und VDR.
    Die Veröffentlichung bringt der Entwicklung erstmal wenig, da das, was veröffentlicht wurde, zum größten Teil eh schon bekannt war und in libvdpau-sunxi enthalten ist. Anständige Registerdoku wäre besser als immer wieder diese Code drops... Aber Allwinner checkts nicht.
    Bevor irgendwelche weitern SoC Versionen noch unterstützt werden, muss erst der komplette Mainline Support her (inkl. Display + VE). Aber dafür muss Allwinner erst die GPL Geschichte klären. Mal sehen, ob der Beitritt zur Linux Foundation kürzlich da irgendwas bringt. Ich bezweifle das.


    Hi !
    das der Pro M1 genaus funktioniert weiss ich... ich hab nur gefragt ob einer mit dem M2 was macht bzw. machen will.... denn ich koennet mittesten.. hab einen ergattert.. :D


    Ich habe nur reagiert, weil du "Pro M2" geschrieben hast. Und den gibts nicht. Ansonsten viel Spaß damit, ich würde versuchen ihn zu tauschen ;) Z.B. gegen einen H3, der liegt hier seit einer Woche rum und wartet darauf erkundet zu werden...


    Hoffe, etwas zur Aufklärung beigetragen zu haben.


    Gruß Andreas