True Color OSD -Entwicklung

    Nur mal so als Zwischenstandsmeldung: Ich arbeite im Moment daran, das OSD "True-Color"-fähig zu machen, weil das ja anscheinend auch so eine irrsinnig wichtige Funktion ist, ohne die VDR unbrauchbar ist ;)
    Dabei müssen natürlich alle bisherigen Skins unverändert weiter funktionieren, und das Ganze muß von den Schnittstellen her so gestaltet sein, daß ein konkretes Ausgabedevice Dinge wie Pixmaps rendern oder Texte zeichnen vollständig selber machen kann, oder aber die Default-Implementierung das alles "zu Fuß" im Speicher macht. Das ist eine ganze Menge Arbeit, daher bin ich in den letzten Wochen leider zu nichts anderem gekommen.


    Ich habe bereits einige der Patches aufgenommen bzw. deren Funktionalität (teilweise) eingebaut (CMDSUBMENU, SOURCECAPS, PLUGINPARAM, DOLBYINREC, ANALOGTV, ATSC und DELTIMESHIFTREC) und werde auch weiterhin daran arbeiten. Was ich halt einfach nicht mache ist, "Monster-Patches" einfach so drüberzubügeln. Viele Patches leiden halt unter "Featureitis", wogegen ich lieber einfache Lösungen habe.


    Wenn jemand die Patches in einem Repository verwalten möchte, so habe ich da natürlich nichts dagegen. Solange die Basis der original VDR ist und es nicht plötzlich "VDR-NG" oder sowas heißt, habe ich damit kein Problem.


    Klaus

    Zitat

    Original von kls
    Nur mal so als Zwischenstandsmeldung: Ich arbeite im Moment daran, das OSD "True-Color"-fähig zu machen, weil das ja anscheinend auch so eine irrsinnig wichtige Funktion ist, ohne die VDR unbrauchbar ist ;)


    :lachen1 :lachen1 :lachen1


    Um den Thread mal aufzulockern ... :hat2


    Gruß
    Frank

    HowTo: APT pinning

    hotzenplotz5


    Das war zustimmendes ROFL, weil manche hier wirklich so tun, als ob VDR ohne ein True-Color-OSD der der letzte Scheiß wäre ...


    Ich finde es gut wie es ist und hoffe aber das man das mit der S2-6400 wirklich nutzen kann, finde aber es gäbe wichtigeres z.B. eine Cutter-Queue ohne Patch und das Schneiden könnte mit etwas niedrigerer Prio (Nice) laufen.


    Gruß
    Frank

    HowTo: APT pinning

    2 Mal editiert, zuletzt von fnu ()

    Zitat

    Original von hotzenplotz5
    dafür gibt es immerhin noch keinen patch :P


    Doch den gibt es.... Siehe Reel-Threads


    Zitat

    Original von fnu
    finde aber es gäbe wichtigeres z.B. eine Cutter-Queue ohne Patch und das Schneiden könnte mit etwas niedrigerer Prio (Nice) laufen.


    Das sollten beides einfache Sachen sein. Schonmal deinen Wunsch Klaus geschrieben.

    Zitat

    Originally posted by fnu
    Ich finde es gut wie es ist und hoffe aber das man das mit der S2-6400 wirklich nutzen kann, ...


    Ja, kann man ;) Das ist meine Testplattform für die Entwicklung. Das Interface ist aber allgemein genug, daß man es auch für jedes andere Device implementieren können sollte.


    Klaus

    Zitat

    Original von Copperhead
    Das sollten beides einfache Sachen sein. Schonmal deinen Wunsch Klaus geschrieben.


    Habe ich in der Tat, müsste das genaue Datum nachschauen, war aber irgendwann Feb/Mar/Apr 2010 ...


    Zitat

    Original von kls
    Das Interface ist aber allgemein genug, daß man es auch für jedes andere Device implementieren können sollte.


    Für die Software-Ausgaben mache ich mir da wenig Sorgen, das ist bestimmt irgendwie lösbar. Was aber kommen wird, ist die Frage zu alten Devices (FF, DXR3 etc.) die bestimmt noch weiterverwendet werden wollen ... ;)


    Gruß
    Frank

    HowTo: APT pinning

    Zitat

    Originally posted by fnu


    Für die Software-Ausgaben mache ich mir da wenig Sorgen, das ist bestimmt irgendwie lösbar. Was aber kommen wird, ist die Frage zu alten Devices (FF, DXR3 etc.) die bestimmt noch weiterverwendet werden wollen ... ;)


    Ganz einfach: die benutzen weiterhin die bisherige Schnittstelle.


    Aus der Sicht einer Skin ändert sich zunächst gar nichts. Zum Beispiel läuft die ST-TNG Skin ohne jegliche Änderung mit dem neuen True-Color OSD. Erst wenn die Skin eine Area der Form { x1, y1, x2, y2, 32 } anfordert schaltet das OSD auf True-Color-Betrieb um. Selbst dann funktioniert alles wie gehabt. Die Skin "zeichnet" wie gewohnt direkt in das OSD. Es gibt dann halt lediglich keine "Bitmaps" mehr, sonder das ganze OSD ist eine "Pixmap". Die einzige Funktion, die dann nicht mehr so arbeitet wie bisher ist GetBitmap(). Es wird dann eine Dummy-Bitmap zurückgeliefert, damit Skins, die die Palette vorbelegen wollen, nicht ins Leere greifen.


    Im True-Color-Modus kann eine Skin aber nicht nur in die Hintergrund-Pixmap zeichnen, sondern auch weitere, "davor" liegende Pixmaps anlegen, die dann mittels Alpha-Blending der Hintergrund-Pixmap überlagert werden.


    Klaus

    Zitat

    Original von kls
    ...


    Im True-Color-Modus kann eine Skin aber nicht nur in die Hintergrund-Pixmap zeichnen, sondern auch weitere, "davor" liegende Pixmaps anlegen, die dann mittels Alpha-Blending der Hintergrund-Pixmap überlagert werden.


    Klaus


    Super ! Das ist ja spitze.


    Würd es auch eine möglichkeit geben zb. jpgs ohne vorherige konvertierung anzeigen zulassen ?

    Zitat

    Original von kls
    Aus der Sicht einer Skin ändert sich zunächst gar nichts. Zum Beispiel läuft die ST-TNG Skin ohne jegliche Änderung mit dem neuen True-Color OSD. Erst wenn die Skin eine Area der Form { x1, y1, x2, y2, 32 } anfordert schaltet das OSD auf True-Color-Betrieb um. Selbst dann funktioniert alles wie gehabt. Die Skin "zeichnet" wie gewohnt direkt in das OSD. Es gibt dann halt lediglich keine "Bitmaps" mehr, sonder das ganze OSD ist eine "Pixmap". Die einzige Funktion, die dann nicht mehr so arbeitet wie bisher ist GetBitmap(). Es wird dann eine Dummy-Bitmap zurückgeliefert, damit Skins, die die Palette vorbelegen wollen, nicht ins Leere greifen.


    Im True-Color-Modus kann eine Skin aber nicht nur in die Hintergrund-Pixmap zeichnen, sondern auch weitere, "davor" liegende Pixmaps anlegen, die dann mittels Alpha-Blending der Hintergrund-Pixmap überlagert werden.


    Hallo Klaus,
    wenn Du eh grade am OSD bist hätte ich eine Bitte: einige Skins nutzen ja schon Scrolling um längere Zeilen darstellen zu können.
    Könntest Du eine Funktion in die Bitmap/Pixmap-Klasse einbauen, die Teile einer Bitmap kopiert?
    Bisher wird das Scrolling so gelöst, dass eine Bitmap mit dem kompletten Text erstellt wird und dann in einer zweidimensionalen Schleife mit cBitmap::Color() / cOsd:: DrawPixel() jeder Punkt der gerade sichtbaren Bereiches ins OSD kopiert wird. Ich denke, das kann man eleganter und vor allem performanter innerhalb der Klasse lösen.


    Grüße
    FireFly

    Zitat

    Originally posted by FireFly
    wenn Du eh grade am OSD bist hätte ich eine Bitte: einige Skins nutzen ja schon Scrolling um längere Zeilen darstellen zu können.
    Könntest Du eine Funktion in die Bitmap/Pixmap-Klasse einbauen, die Teile einer Bitmap kopiert?
    Bisher wird das Scrolling so gelöst, dass eine Bitmap mit dem kompletten Text erstellt wird und dann in einer zweidimensionalen Schleife mit cBitmap::Color() / cOsd:: DrawPixel() jeder Punkt der gerade sichtbaren Bereiches ins OSD kopiert wird. Ich denke, das kann man eleganter und vor allem performanter innerhalb der Klasse lösen.


    Das wird durch einfaches Verschieben des Referenzpunktes möglich sein.
    Eine Pixmap hat zwei Rechtecke: eines, das den Ausschnitt auf dem OSD definiert, in dem diese Pixmap sichtbar sein soll ("view port") und eines, das die tatsächlichen Pixeldaten bestimmt ("draw port"). Der "draw port" kann gößer sein als der "view port" und es ist dann nur der Teil des draw ports sichtbar, den der view port "freigibt". Verschiebt man nun den Referenzpunkt des draw ports, dann "scrollt" der Text innerhalb des view ports.


    Wenn man im draw port z.B. eine Folge von Einzelbildern ablegt, die alle im gleichen Abstand neben- oder untereienander liegen, und verschiebt den Referenzpunkt alle 50ms, so kann man eine animierte Pixmap darstellen ;)


    Klaus

    Hi,
    nun auch wenn noch nichts neues geschrieben wurde, so möchte ich nochmal meine Hoffnung ausdrücken, dass es mit der TrueColor OSD Erweiterung endlich einmal mit der Hardwarebeschleunigten Ausgabe und dem OSD flüssig funktionieren wird.


    Denn bisher muß die CPU beim OSD einfach zu viel Arbeit übernehmen, was auf den ATOM Systemen und anderen leistungsschwachen Lösungen zu den bekannten Bildstörungen führt, sobald das FullHD OSD genutzt wird und der Theme etwas aufwendiger ist.


    Ich denke abgesehen von den zusätzlichen neuen Möglichkeiten die sich ergeben können, ist dies der vornehmlich größte Nutzen (für mich).


    Ich freue mich schon darauf, wenn es spruchreif wird.


    Gruß
    Torsten

    Proxmox VE, Tyan Xeon Server, OMV, MLD-Server 5.1
    MLD 5.1 64bit: Asus AT5iont-t, ION2, 4GB Ram, SSHD 2,5" 1Tb, HEX TFX 300W 82+, Cine S2 V6.2 , 38W max.
    Yavdr 0.5:     Zotac D2550ITXS-A-E mit GT610 OB, TT S2-4100 PCI-e ,Joujye NU-0568I-B
    Yavdr 0.5:     Sandy Bridge G840, Tests und Energieverbrauch , CoHaus CIR, Cine S2 V6.2
    MLD 5.1 Beebox N3150    , DVBSky S960 und 1Tb WD Blue

    Na dann fang schon mal an.
    Was hat das eine nun mit dem anderen zu tun.
    Das haette ja auch schon jemand mit dem "alten" OSD machen koennen aber ich kenne
    da nichts was erschienen ist. ;)
    Ich wuerde mir diesbezueglich doch recht wenig Hoffnung machen.

    Vorsicht OT ;)


    Zitat

    Original von Torsten73
    Denn bisher muß die CPU beim OSD einfach zu viel Arbeit übernehmen, was auf den ATOM Systemen und anderen leistungsschwachen Lösungen zu den bekannten Bildstörungen führt, sobald das FullHD OSD genutzt wird und der Theme etwas aufwendiger ist.


    Das Problem erlebe ich auch gerade. Hast du ein paar Thread Links zur Hand, wo das diskutiert wird ?


    LG


    Joachim

    Mein VDR: Digitainer II Gehäuse, Asus M85M-US2H, AMD Sempron 140, 2 GB RAM, 1 TB WD Festplatte, Satelco Easywatch / Terratec Cinergy DVB-C, IR- Fernbedienung mit Atric-Einschalter, yavdr-0.5.0a

    @all


    Ja, das könnte OT werden, aber Morone hat da absolut recht, das eine hat mit dem anderen gar nichts zu tun!


    Das Ausgabegerät muß die Darstellung des OSDs, True-Color oder nicht, übernehmen. Also entweder eine DXR3, SD-FF, eHD, FF-HD, softdevice, xine-ui oder eben vdr-sxfe. Die HW Lösungen haben dafür entsprechende "Einrichtungen", die das unabhängig von der CPU übernehmen.


    Bei den Softausgaben übernimmt das eben die Software, die nun mal prinzipbedingt auf der CPU läuft. Nehmen wir mal softdevice mangels Weiterentwicklung aus, ist bei xine* nur die Video-Ausgabe beschleunigt. Mir wäre keine OSD Schnittstelle in VDPAU oder auch VAAPI bekannt.


    Evtl. läßt die Beschleunigung des OSD mit Hilfe von VDPAU/VAAPI/XVBA realisieren, aber das muß in xine-ui oder xineliboutput passieren und ist kein Problem vom VDR und damit von "kls". So, feel free to provide a proper solution ... ;D


    Und wenn Euch das Thema so arg ist, würde ich empfehlen eben mehr CPU Leistung an den Start zu bringen ... mit einem Single-Core Sempron 140 habe ich da kein Problem mit Anthra FullHD & Liquid-Logos ... ;)


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

    Ich denke mal das es zwei Gründe gibt warum wir noch nichts neues gehört haben.


    a) Klaus hat keine Zeit
    b) das Thema ist komplexer als wir es uns vorgestellt haben.


    Da es sich um ein Developer Release handeln wird, muss auch nicht der erste Schuss in Stein gehauen werden. Ich glaube aber wenn es Klaus seinen Ansprüchen genügt, dann kann man damit schon mal sehr gut arbeiten.



    Wenn ich das Thema mit dem OSD Rucklern bei schwachen PC's richtig erstanden habe, dann muss die CPU für jedes Pixel om OSD eine Umrechnung von X-Farben auf TrueColor machen. Wenn dieser Schritt weg fällt, wird erhofft das sich das OSD weniger auf die CPU Auslastung auswirkt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden