Beiträge von ardi


    Danke für die Info. Ich kann das aber gerade nicht testen (vdr ist in Benutzung ;D )
    Ich bleibe dran.


    -Analog Audio: -A alsa (funktioniert bei mir)
    - Umschalten sollte eigentlich gehen
    - Im Server-VDR-Xineliboutbut-Setup im Menü Video muß deinterl. abgeschaltet sein ... noch

    Also, ich hab das so verstanden, dass das Plugin, was ardi für die Xine-Lib schreibt, dafür sorgt, dass Xine die Hardware-Beschleunigung des RPI nutzen kann.


    Genau so ist es. Ein vdr sendet über xineliboutput an den rpi vdr-fbfe empfängt die Daten und gibt sie über xine aus. Mein xine-plugin sorgt dafür, dass dabei die Hardwarebeschleunigung benutzt wird.

    Nur eine Frage zum ablauft.
    Du schreibst jetzt ein xine-lib plugin. Das bedeutet das der VDR dann einfach das unveränderte aktuelle xineliboutput plugin nimmt?
    Wir brauchen dann nur Dein Plugin in ein spezielles Verzeichnis von xine-lib kopieren und vielleicht noch ein paar Parameter mehr mit übergeben?

    Genau das bedeutet es.
    einfach apt-get install xineliboutput-fbfe
    Das ganze libxine-Geschlungze sollte dann automatisch mitkommen. Dann das Plugin nach /usr/lib/xine/plugins/2.2 kopieren und vdr-fbfe mit "-V rpi" starten ... fertig


    Oder muss die ganze xine-lib neu übersetzt werden? (was ich eh tun werde)
    Muss am VDR Plugin dann überhaupt was gemacht werden?
    Dann kann ich es soweit schon mal vorbereiten.

    Die xine-lib muß nicht neu übersetzt werden.


    Warum wird hier eigentlich ständig im selben Atemzug das xine-plugin und das xineliboutput-plugin genannt. Die sind doch gar nicht kompatibel. Kann mich da mal jemand aufklären?


    Gerald

    Ich glaube du hast da was missverstanden. Ich schreibe ein Plugin für die xine-lib (eine Mediaplayer-Library auf die sowohl das vdr-xineliboutput-plugin als auch das vdr-xine-plugin aufsetzen) xine-plugin ist nicht gleich vdr-xine-plugin.


    Mein xine-Plugin sollte sowohl mit dem vdr-xineliboutput-plugin als auch mit dem vdr-xine-plugin funktioniert.
    Auch mit fbxine als stand-alone-media-player kannst'e es nehmen.

    Perfekt!
    Dann wäre das praktisch "nur" ein neuer Player für's xineliboutput-Plugin?

    Nicht ganz. Es ist ein Xine-Plugin. Als Player wird fbxine oder vdr-fbfe (für xineliboutput) verwendet.


    Ich habe bislang nur etwas mit dem Xine-Plugin und Xine gearbeitet, wenn das mitxineliboutput in etwa genauso geht wäre der Raspberry echt ein toller Client.

    Sehe ich auch so.


    Ist das noch aktuell?
    Wenn eine PES-Aufnahme reicht, kann ich dir am WE mal was zusammen schnippeln.
    (Meine Bastelkiste mit aktuellem VDR ist leider derzeit "verbastelt" und mir fehlt derzeit die Zeit die lauffähig zu bekommen.)
    Musst mir nur sagen wo ich es hochladen kann (PN).

    Ja, ist noch aktuell. Danke. Hochladen kannst'e das wo du willst (rapid/ul o.ä.) oder du schickst's mir per Email.
    Es wäre auch schön, wenn du 4:3-Material in Letterbox hast, um die Autocrop-Funktion zu testen.


    So. Jetzt mal was zum Stand der Dinge:

    • Das Plugin läuft schon mal. Zur Zeit aber ohne OSD und ohne Skalierung (immer Vollbild).
    • Angezeigt werden sowohl SD- als auch HD-Kanäle
    • Sorgenkinder sind noch der Sound, HD-Känäle und das OSD

      • Das Abspielen einer simplen MP3 über fbxine verursacht eine Systemlast von 100%
      • Das Ansehen von HD-Kanälen (ohne Sound "-A none") verursacht eine Systemlast von ca.80%
        Bei SD-Kanälen sind es "nur" ca. 40% (mit Sound 100% - aber läuft)
      • Aspect-Ratio- und/oder Auflösungswechsel on-the-fly bisher ungetestet
      • OSD wird noch nicht angezeigt.


    Vermutlich muß ich auch noch die Sound-Decodierung über HW machen.


    Wenn ich es schaffe, dann werde ich am Wochenende schon mal eine erste Test-Version uppen.


    gibts schon was? Prototyp ...

    nee, leider noch nicht - ich habe gerade erst angefangen



    Ich befürchte aber das xine da echt ein starkes Stück Arbeit ist.
    Irgend jemand meinte mal das die OSD Unterstützung von xine nicht mit OpenMax zusammen passen würde.
    Daher dachte ich bin jetzt das softhddevice "leichter" wäre. Wollte mich da auch mal mit befassen, fehlt aber leider die Zeit.

    Doch. OSD geht mit OpenMax und xine.


    Implementieren muss man bei beiden alles.

    Bei "beiden" was?


    Recoursen schonender wärs halt ohne XServer. Wird halt bei Xine nicht gehen.

    Das Plugin wird ohne XServer funktionieren.


    Würde das dann auch wie beim Xine-Plugin übers Netzwerk gehen?
    Also VDR auf zB. einem NAS und die Ausgabe mit OSD auf dem Raspberry?

    Natürlich geht das. Wie bisher mit xineliboutput auch.



    PS: Kopfzerbrechen bereitet mir gerade das ändern der Aspect-Ratio und/oder der Auflösung on-the-fly (z.B. beim Wechsel von Film auf Werbung o.ä.).
    Vielleicht könnte mir jemand eine kleine mpg zusammenschneiden z.B. 720x576 4:3 --> 720x576 16:9 --> 480x576 4:3 jeweils ca. 1 min.

    Warum für Xine? Ich dachte das haben wir hinter uns... Warum nicht softhddevice erweitern?


    3 Gründe für Xine.



    • Ich benutze seit Jahren xineliboutput und bin sehr zufrieden damit.
    • Ich habe mich noch nicht wirklich mit softhddevice beschäftigt.
    • Das Plugin kann mit jedem xine-player benutzt werden. Dadurch haben auch nicht-VDRer einen schlanken Medien-Player ohne gleich mit XBMC zu schmeißen.



    Hallo,


    vorab an Alle, eine Update für SportNG wird's sehr wahrscheinlich nicht mehr geben :(
    Möchte jemand das Projekt übernehmen?


    seit einem Monat hab ich nun einen Raspery Pi.


    Ich habe angefangen ein Xine-Plugin für die Hardwareunterstützten Decodierung von MPEG2 und H264 usw. zu programmieren (für xineliboutput).


    Gibt es dafür eigentlich noch Interesse?


    ----
    Download:


    auf Version 0.0.4 warten ;)


    PS:
    Europa League added

    Zitat

    Original von dreamar
    Hi Leute,


    ich habe eine kleine bitte. Kann mir jemand das Verzeichnis /etc/vdr/sportng
    für das PLugin Sportng zukommen lassen? Es soll auf Zen2mms konvertiert werden und der Entwickler möchte sich die Dateien gerne anschauen, da es unter Gen2vdr ja läuft. Wäre sehr nett von euch. Sage schon mal Danke


    Das Verzeichnis (mit Inhalt) wird komplett vom Plugin selbst angelegt und gefüllt. Es muß also ein Schreibrecht für den VDR in /etc/vdr/ existieren.
    Wenn kein Schreibrecht besteht kann der Path per Command-line-Option angepasst werden (siehe WiKi).

    Hallo,


    da ich nun wieder nach langer Zeit einen VDR in Betrieb habe, kann ich mich auch wieder um SportNG kümmern.


    Ich habe gestern Abend "1. Bundesliga 2010/2011" freigeschaltet und ein paar alte Daten gelöscht.


    Werde in den nächsten Tagen die Datenbank noch etwas bereinigen und ein paar andere Ligen freigeben.


    Eine neue SportNG Version ist ebenfalls in Arbeit.


    mal abgesehen davon das der TLC nicht ohne weiteres beschaffbar ist hast du natürlich recht. Die Flexibilität in punkto Strom erreichst du aber nur wen du die Anzahl der Kanäle kürzt.


    Bei Verwendung von z.B. 350mA HighPower-Leds kannst Du nur noch 7 Kanäle (2 1/3 RGB) nutzen.


    Ich halte es für eine Verschwendung der Fähigkeiten des TLC.


    Da die Vorzüge des TLCs (Dot-Correction, Konstantstrom) nicht genutzt werden und er außerdem schwer beschaffbar ist. Könnte man del TLC z.B. durch einen ATtiny2313 mit SoftPWM ersetzen. der kostet wenig und ist an jeder Ecke zu bekommen.


    PS: nichts für ungut. Ist euer Project. Und eine tolle Leistung. Nur für die Allgemeinheit z.Z. wenig nutzbar. (schwer beschaffbare Teile/Baugruppen)



    ardi


    Nein. Ich meine die LEDs direkt am TLC betreiben (ohne FETs o.ä.).
    Der TLC schaft die 120mA an 16 Ausgängen gleichzeitig.


    Vorteile:

    • der TLC wird nicht kastriert. D.H. die Dot-Correction kann zum weißabgleich genutzt werden.
    • weniger Bauteile (5 an der Zahl)


    Nachteile: 40mA weniger



    ardi

    Zitat

    Original von daniel_k


    Hi ardi,
    Der TLC darf die 120 mA aber nicht auf allen Kanälen gleichzeitig (den Wert habe ich nicht im Kopf, aber der gleiche Hintergrund wie die 2,5A bei den ULNs->Wärme).


    nicht ganz. Beim TLC sind die Ausgänge Stromquellen. Die verbratene Leistung hängt hauptsächlich von der Spannung die der TLC schlucken muß ab.


    So sind 120mA an 16 Ausgaängen durchaus machbar.


    Zitat


    Außerdem wollten wir den Strom über die LED-Vorwiderstände einstellen, weil man sonst ja unterschiedliche Ströme für verschiedene LED-Typen an den TLCs einstellen müßte (Vorwiderstand tauschen).


    Gruß,
    Daniel


    ardi

    Zitat

    Original von randy
    naja, man braucht ja nicht jeden kanel belegen, wenn man mehr strom will ;)


    Ist ein Argument aber ...


    da spar ich doch lieber 5 ICs und packe einen TLC mehr auf ner Platine und hab dann 5 1/3 Kanäle mehr.


    Außerdem muß ich nicht auf die Dot-Correction des TLC verzichten


    ardi


    PS: von den im Wiki vorgestellten LED-Streifen (3 LEDs/Streifen) können nach meinen Berechnungen locker 3 Stück / Kanal dierekt am TLC betrieben werden (das entspricht 15 cm bzw. 9 LEDs / Kanal).
    Die Widerstände könnten auch entfallen (Dot-Correction)

    Hi,


    ich hab mal eine grundsätzliche Frage:


    Warum der Aufwand mit 3x74HC4049 und 2xULN2803 ???


    der ULN bringt zwar 500mA je Kanal durch die 2.5A Begrenzung sind es dann doch nur ca. 160mA.


    Der TLC alleine schaft 120mA das sind gerade mal 40mA weniger??


    nur mal so aus Neugier ... ansonsten tolle Arbeit.


    ardi

    Zitat

    Original von sviper
    Mir ist aufgefallen, dass goom bei der Musikwiedergabe stockt.
    Weiß jemand warum?


    Das hab ich schon seit je her. Bei allen VDRs. Allerdings nur bei Live-Radio. Bei Aufnahmen und mp3's läuft goom ohne stocken.
    Liegt vermutlich daran, daß die Musikdaten nicht gleichmäßge vom SAT kommen.


    Habe mal einen Patch für xineliboutput geschrieben, der bei Radio erst einen Ringbuffer zu ca. 20% volllaufen läßt bevor die Musik abgespielt wurde. Damit war das Stocken weg.


    Leider finde ich den Patch nicht mehr.


    ardi