Rasperry Pi xine plugin

  • O.k. Danke. Ich habe gerade eine neue Version hoch geladen. Damit sollte's gefixt sein.


    Ich habe grade noch mal http://xineplug-rpi.ardisoft.de/xineplug_rpi.so heruntergeladen, aber die Farben stimmen noch nicht (keine Veränderung).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich hab jetzt eine Version geupped, die eine log-Ausgabe ausspuckt wenn das OSD eingeblendet wird. ... die hätte ich gern


    Ich nehme an, es ist das:
    Mit TrueColor:


    Mit LUT8:

    Code
    1. [491] [vdr-fe] Keypress: LIRC KEY_MENU
    2. overlay[0] rle scaled ycbcr 1224x922@26,51 extend 1280x1024 hili -1,-1--1,-1 video -1x-1@-1,-1
    3. [491] [lirc] LIRC: 000000000000178d 01 KEY_MENU devinput


    Ist da das Struct anders?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    The post was edited 1 time, last by seahawk1986 ().

  • OSD-Farben fixed


    Kann ich bestätigen :)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)


  • Was willst du mit den Sourcen? Das ist z.Z. nur unaufgeräumter experimenteller Kram der sich laufend ändert. Um auf deine Frage zurück zu kommen: vorerst keine Sourcen


    Sagen wir's so: Im Open Source Umfeld bin ich es gewohnt mit Sourcen arbeiten zu können. Oder auch "Im Linux-Bereich ist das eigentlich so üblich".


    Weiterhin hätte ich dann zumindest in der Theorie die Chance gehabt, einen Versuch zu unternehmen, die Basisfunktion nach Softhddevice zu portieren.


    Ich bin da kein Profi in dem Bereich, aber wenn Xine unter GPL und nicht unter LGPL steht, dann ist mein Verständnis der Lizenz, dass Sourcecode, der auf libxine basiert, sogar ganz automatisch wieder unter GPL steht.

  • Wenn Xine wirklich unter GPL und nicht unter LGPL steht, könnte es sogar sein, dass du laut Lizenz parallel zum Binary den Sourcecode sogar mit anbieten musst.


    Mit so einer kaum verhüllten Drohung begibst du dich auf sehr dünnes Eis. Er könnte als Reaktion erst mal einen Quellenstand freigeben und danach im stillen Kämmerlein weiterentwickeln und weder Source noch Binaries raus rücken, was natürlich schade wäre.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Ich hatte mein Posting nochmal überarbeitet. Du hast zu früh geantwortet ;) Und ein Hinweis darauf, wie die GPL tickt, muss ja wohl erlaubt sein.


    Du hast mich nicht verstanden. Nichts von dem was du gesagt hast ist falsch. Es gibt da so eine Regel die ungefähr so lautet:


    Quote

    Alles was du sagst soll wahr sein, aber sage nicht alles was wahr ist.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Dennoch war meine Intention nicht, eine Drohung auszusprechen, sondern lediglich als Info gedacht. Ich selber habe keinerlei Rechte am Xine-Code, da ich nie beigetragen habe.


    Ich werde den Thread, sofern ich die Aussage von ardi als "Sourcecode gebe ich nicht raus" richtig interpretiert habe, einfach ignorieren und gut ist.


    Warum ich am Code interessiert gewesen wäre, habe ich ja dazugeschrieben. Klar kann man für eine softhddevice-Integration alles nochmal neu machen, aber gerade hier ist doch eigentlich einer der Stärken von Open Source, dass man schonmal getane Arbeit kein zweites Mal tun muss.


    Wenn du also euer Thema hier in Gefahr siehst, dann editiere ich gerne meine Postings. Alleine hätte ich die softhddevice-Geschichte ohnehin nicht hinbekommen und wenn später jemand mit mehr Hintergrundwissen ein Interesse hat, muss der sich halt in die Nesseln setzen. Habe echt keinen Bock später als Sündenbock dazustehen nur weil ich auf die Tatsachen hingewiesen habe.


    Macht aber aus verständlichen Gründen nur dann Sinn, wenn alle ihre Postings editieren.

  • Hallo,
    habe jetzt mal die aktuelle Version getestet und habe folgendes festgestellt.
    - die Qualität des OSD ist jetzt richtig gut, Super. :)
    - beim umschalten von HD <> SD hängt sich vdr-fbfe sporadisch auf. Man hört noch kurz Ton, danach geht nix mehr, kein OSD, kein Video/Audio und umschalten. Abbruch nur mit CTRL + C ..
    - es gibt regelmässig kurze aussetzter im Ton, mal mehr, mal weniger, festgestellt bei HD und SD, ich habe 1080p und aktuell 1080i bei 50Hz eingestellt. (hdmi_mode=20)
    - bei ServusTV HD kommt es immer noch zum Speichzugriffsfehler ...


    Ansonsten vielen Dank für die tollen Fortschritte. :)


    Gruß Uwe

  • Hi ardi,


    freut mich sehr das du dich des xine plugins angenommen hast und es für die Hardwarebeschleunigung des Rpi's verfügbar machst.Ich habe mal deine letzte Version getestet war überrascht wie gut das schon läuft.
    Ich hoffe mal das du dich nicht von den letzten Kommentaren irritierten lässt. Könntest du oder jemand anderes mir sagen wie ich das plugin in die runvdr eintragen muß.Da ist dann ja sowas wie z.B. für das vdr-mcli-plugin:
    -P'mcli --ifname eth0 --sock-path /var/tmp/mcli.sock --mld-reporter-disable --dvb-s2 1' nötig. Mach weiter so :] .


    @ Mreimer und gda


    Das Thema GPL ist ja hier wohl völlig fehl am Platz denn laut Thema gehts hier um das xine Plugin.Mein perönlicher Standpunkt zur Sourcenfreigabe unter GPL ist, das man den Quellcode erst veröffentlichen sollte wenn er
    von Fehlern frei ist und gut dokumentiert ist um es anderen leichter zu machen mit diesen Quellen dann zu arbeiten.Leider wird das viel zuwenig gemacht.
    Ihr seit doch schon lange dabei und wisst doch das unausgegorene Sachen schnell in Patches ertrinken können zB (mcli plugin).


    mfg aus Stendal /SA


    guigra

  • Mein perönlicher Standpunkt zur Sourcenfreigabe unter GPL ist, das man den Quellcode erst veröffentlichen sollte wenn er
    von Fehlern frei ist und gut dokumentiert ist um es anderen leichter zu machen mit diesen Quellen dann zu arbeiten.Leider wird das viel zuwenig gemacht.


    Dein persönlicher Standpunkt tut aber nichts zur Sache und ist auch schlicht falsch. Du solltest dir dringend Paragraph 3 der GPL v2 durchlesen.


    Paragraph 2 regelt, dass ardi Änderungen machen darf
    Paragraph 3 regelt, dass er den geänderten Source wieder freigeben muss


    Genauer:
    Absatz 1 beschreibt, dass der Source zusammen mit der Objektdatei verteilt werden darf
    Absatz 2 beschreibt, dass er schriftlich anbieten muss, dass er mindestens 3 Jahre lang den Source auf Anfrage freigibt.
    Absatz 3 findet hier keine Anwendung.


    Einen dieser beiden Methoden muss er sich raussuchen.

  • Ich hätte auch Interesse am code. Aber nur um mal ein review zu machen und um vielleicht etwas zu helfen.


    Ich denke früher oder später gibt er ihn raus. Also erst mal abwarten.
    Finde es auch Klasse wie es voran geht.

  • Copperhead : Sei doch so gut und bleibe mal cool ;) Die Diskussion bringt nichts und letztlich kann keiner von uns ihn zur Herausgabe zwingen. Das kann, wenn überhaupt, nur jemand aus dem Xine-Team. Nur wer Rechte am Code hat, kann diese auch geltend machen.


    Ich für meinen Teil habe noch Hoffnung, dass ich ardi nur falsch verstanden habe und wenn er den Code dann herausgibt, wenn er soweit ins Reine geschrieben ist, ist ja letztlich auch besser als nichts. Ich wollte ja lediglich wissen wann er meint das er den Sourcecode veröffentlichen kann. Ich habe nie geschrieben, dass ich ihn umgehend, jetzt und sofort haben möchte.

  • Hi vdr_rossi,


    ja, das von Dir oben gepostete Image (client) ist für Dienen Einsatzzweck das richtige.
    Ich hab noch nen Update des lib-xine-rpi Addons online gestellt. Das ist aber nicht im Image enthalten sondern muss per update geholt werden.


    Claus

    MLD 5.4 mit vdr 2.4.1 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.4 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Hi copperhead,


    danke für deine überaus "freundliche" Antwort.Auch wenn es dir nicht passt ich halte die von dir genannten Punkte der GPLv2 für sehr bedenklich da sie eben genau das fördern was ich geschrieben habe, die Herrausgabe von unreifen Programmcode und unvollständige Dokumentation.


    Das solls jetzt aber wirklich zu diesem Thema gewesen sein denn hier gehts ums Plugin und nicht um die GPL.Das hatte ich ja vorhin schon geschrieben!


    Weis jemand zu meiner Frage aus dem letzten Post ne Lösung ich komm nicht drauf :wand .



    mfg aus Stendal/SA



    guigra


  • Warum ich am Code interessiert gewesen wäre, habe ich ja dazugeschrieben. Klar kann man für eine softhddevice-Integration alles nochmal neu machen, aber gerade hier ist doch eigentlich einer der Stärken von Open Source, dass man schonmal getane Arbeit kein zweites Mal tun muss.


    Und warum brauchst du unbedingt die sourcen dieses Projektes? Du könntest ja auch die Sourcen vom Vompclient anschauen.


    mfg Thomas

    VDR:
    Hardware: Thermaltake DH102, Zotac ION ITX-F-E, 2Gig Ram, TechnoTrend
    dual DVB-S2 6400, TechnoTrend Connect CT-3650,


    Software: EasyVDR 1.0

  • Hi vdr_rossi,
    ja, das von Dir oben gepostete Image (client) ist für Dienen Einsatzzweck das richtige.
    Ich hab noch nen Update des lib-xine-rpi Addons online gestellt. Das ist aber nicht im Image enthalten sondern muss per update geholt werden.


    Ja, danke.


    Habe eben die bereits installierte Client Version über das Addon upgedatet.
    Leider keine Verbesserung. Immer noch der gleiche Stand wie ich oben beschrieben habe.


    Bin trotzdem auf dem Pfad der Erleuchtung:
    [Blocked Image: http://i41.tinypic.com/2vt1j4x.jpg]


    Munter bleiben, Rossi