[osdteletext] Patch für High-Level-OSDs

    Hi Louis


    Zitat von louis

    zwar ein bisschen OT, aber passt hier eigentlich ganz gut: siehst du es auch so, dass die Implementierung der Fonts im VDR nicht ganz optimal für ein High Level OSD ist? Meiner Ansicht nach müsste das Requesten eines Fonts aus einer Anwendung heraus (Skin oder Plugin) besser z.B. über den OsdProvider laufen, damit das High Level Osd das auch mitbekommt. Aktuell geht das ja komplett am High Level Osd vorbei, und der Font muss zweimal erzeugt und im Speicher gehalten werden. Hätte das High Level Osd die Möglichkeit, die Fonts selbst zu verwalten, könnte man das ressourcenschonender implementieren.

    Ich sehe das ähnlich wie du, das OSD sollte die einzige Instanz sein, die sich um Fonts kümmern muss. Ich würde sogar so weit gehen und die Default-Implementation des OSD (also das Lowlevel-OSD) in ein Plugin auszulagern. So könnte man auch die Abhängigkeit von VDR zu Freetype eliminieren.
    Ein grosses Problem mit dem Speicher sehe ich aktuell trotzdem nicht. Schliesslich werden die einzelnen Glyphs ja nur gerendert, wenn sie mittels cFreetypeFont gezeichnet werden, oder jemand die Länge eines Strings über cFont abfragt.


    Zitat von louis

    Wenn man sich hier eh schon Änderungen überlegt, könnte man dieses Thema ggf. auch mal komplett durchdenken...

    Finde ich gut. Ich fände es auch erstrebenswert, bestehende High-Level-Implementationen losgelöst vom Ausgabeplugin für andere verfügbar zu machen. Gerade OpenGL wird ja recht breit unterstützt.


    Gruss
    Thomas

    Moin,

    Zitat von reufer

    Ich sehe das ähnlich wie du, das OSD sollte die einzige Instanz sein, die sich um Fonts kümmern muss. Ich würde sogar so weit gehen und die Default-Implementation des OSD (also das Lowlevel-OSD) in ein Plugin auszulagern. So könnte man auch die Abhängigkeit von VDR zu Freetype eliminieren.


    Jo...das wäre wohl die konsequenteste Lösung. Ein im VDR integrierte Ausgabe gibt es ja auch nicht, da muss man ja auch ein Plugin installieren.

    Zitat von reufer

    Ein grosses Problem mit dem Speicher sehe ich aktuell trotzdem nicht. Schliesslich werden die einzelnen Glyphs ja nur gerendert, wenn sie mittels cFreetypeFont gezeichnet werden, oder jemand die Länge eines Strings über cFont abfragt.


    Klar...ich denke auch nicht, dass das ins Gewicht fällt. Aber es muss ja nicht sein ;)
    Vielleich äußerst sich Klaus mal hierzu, wie er das sieht...

    Zitat von reufer

    Finde ich gut. Ich fände es auch erstrebenswert, bestehende High-Level-Implementationen losgelöst vom Ausgabeplugin für andere verfügbar zu machen. Gerade OpenGL wird ja recht breit unterstützt.


    Man müsste das dann nur so modular aufbauen, dass alle möglichen und sinnvollen Hardwareschnittstellen (OpenGL, OpenGL ES, OpenMax) bei bedarf genutzt werden könnten. rell baut das ganze ja gerade für die Allwinner GPUs auf OpenGL ES um...die Krönung wäre natürlich, wenn es ein allgemeines High Level OSD Plugin gäbe, das mit allen Ausgabeplugins zusammenarbeitet.


    Ciao Louis

    Zitat von louis

    die Krönung wäre natürlich, wenn es ein allgemeines High Level OSD Plugin gäbe, das mit allen Ausgabeplugins zusammenarbeitet.

    Das ginge aber komplett in die falsche Richtung! Es geht ja darum, gemeinsame Implementationen für verschiedene Ausgabeplugins verfügbar zu machen und nicht, alle Implementation miteinander zu "verwursteln". Die OpenVG- und OpenGL-Varianten mögen ähnlich aufgebaut sein, unterscheiden sich aber spätestens bei der eigentlichen Ausgabe grundsätzlich. Sinnvol fände ich, wenn es dann z.B. beim OpenGL-OSD-Plugin verschiedene HW-Layer gäbe, also beispielsweise für X-Server, Framebuffer, etc...


    Im Prinzip wäre ein reines OSD-Plugin schon heute möglich. Jeder kann einen cOsdProvider() instanzieren, der sich um das OSD kümmert - das Ausgabeplugin dürfte diesen einfach nicht überschreiben.


    Gruss
    Thomas

    Zitat von reufer

    Das ginge aber komplett in die falsche Richtung! Es geht ja darum, gemeinsame Implementationen für verschiedene Ausgabeplugins verfügbar zu machen und nicht, alle Implementation miteinander zu "verwursteln". Die OpenVG- und OpenGL-Varianten mögen ähnlich aufgebaut sein, unterscheiden sich aber spätestens bei der eigentlichen Ausgabe grundsätzlich.


    Klar, die Ausgabe ist komplett unterschiedlich. Das "Framework" jedoch (Pixmap handling, Font Handling, Ausgabe über die Command Queue) wäre schon gemeinsam. Könnte man sicherlich so kapseln, dass man das sauber für die verschiedenen Varianten implementieren kann. Klar besteht die Gefahr, dass dann alles verwurschtelt wird, das fängt ja schon bei den Includes an ;)


    Zitat von reufer

    Sinnvol fände ich, wenn es dann z.B. beim OpenGL-OSD-Plugin verschiedene HW-Layer gäbe, also beispielsweise für X-Server, Framebuffer, etc...


    Hm, braucht heutzutage noch jemand Framebuffer?


    Zitat von reufer

    Im Prinzip wäre ein reines OSD-Plugin schon heute möglich. Jeder kann einen cOsdProvider() instanzieren, der sich um das OSD kümmert - das Ausgabeplugin dürfte diesen einfach nicht überschreiben.


    Wohl wahr...müsste nur mal jemand machen ;)


    Ciao Louis

    HI,


    M-Reimer, Copperhead
    Mea culpa fürs verwechseln. War wohl zu spät gestern Abend.


    tomas,
    Danke für den Vergleich. Dann sollte es eigentlich auf dem RPI genauso aussehen.


    crow
    Das sieht ja wirklich übel aus. Die Fonts scheinen viel zu groß zu sein. Welches Ausgabeplugin nutzt Du denn dafür? Ich versuche mal, das bei mir mit den von Dir eingestellten OSD Größen und Fonts nachzustellen. ORF hab ich leider nicht zum Testen.


    louis, Thomas
    Das habe ich auch schon gesehen, dass man die Breite nicht abfragen kann. Das wäre zumindest eine erste, sinnvolle Ergänzung zur cFont API. Die Initialisierungswerte sollte man auch wieder abfragen können. Auch bei den anderen Vorschlägen habt Ihr meine Zustimmung. Das Ausgabedevice weiß ja am Besten, wie es mit Textdarstellung umgeht. Mal sehen, ob bzw. was Klaus dazu sagt.


    Gruß,
    kanadakruemel

    VDR: 2.4.6, Intel NUC8i3BEH + 8GB + 128GB SSD + 1TB
    + CIR + SATIP (Octopus Net)

    kanadakruemel
    rpihddevice auf eine RPi2. Sender war ServusTV HD Ö. (ist ein FTA sender).
    Die werten kommen nicht von setup.conf da drinnen nicht etwas osd teletext spezifisches ist.

    Zitat von louis

    Hm, braucht heutzutage noch jemand Framebuffer?

    Verstehe ich es richtig, z.B. amlhddevice für AmLogic SoC so wie in der Wetek Play? Thomas weiß es bestimmt besser.


    Gruß,
    Lucian

    Zitat von louis

    Das "Framework" jedoch (Pixmap handling, Font Handling, Ausgabe über die Command Queue) wäre schon gemeinsam. Könnte man sicherlich so kapseln, dass man das sauber für die verschiedenen Varianten implementieren kann.

    Einzig die Serialisierung sehe ich als gemeinsame Komponente, der Rest ist eigentlich ganz gut bereits in VDR gelöst.


    Zitat von Zoolook

    Verstehe ich es richtig, z.B. amlhddevice für AmLogic SoC so wie in der Wetek Play? Thomas weiß es bestimmt besser.

    Genau, für die Wetek macht das OpenGL-OSD definitiv Sinn! Aber da gibt es erst andere Baustellen zu lösen...


    Gruss
    Thomas

    @rofaror
    You are right, character conversion has yet to be done correctly. First I would like to get rid of the teletext font dependency an habe a look after crows problem. But character conversion is the very next task.


    best regards,
    kanadakruemel

    VDR: 2.4.6, Intel NUC8i3BEH + 8GB + 128GB SSD + 1TB
    + CIR + SATIP (Octopus Net)

    Hallo,


    anbei eine neue Version des osdteletext-ttf patches. Der teletext.ttf Font wird nun nicht mehr benötigt, die Grafikzeichen werden ähnlich der "alten" Methode erzeugt. Für den Text wird der im Setup des Plugins eingestellte Font benutzt. Standard ist nun der Default Fix Font (definiert in font.c des VDR). Die Character Konvertierung für alle unterstützten Sprachen sollte funktionieren. Bei mir treten mit dieser Version keine Grafikfehler mehr auf, allerdings kann ich leider nicht mit den Hi-Level OSD devices testen.


    crow
    Scheinbar wurde bei Dir der teletext2 font nicht gefunden und daher versucht, den Standardfont immer größer zu skalieren. Das sollte mit dieser Version behoben sein. Falls nicht, bitte im Setup des Plugins nochmal neu einen Font wählen.


    @rofaror
    This version of the osdteletext ttf patch doesn't need the teletext.ttf font anymore. Graphics chars will be rendered using the old method of the plugin.
    Character conversion should work again for all supported language sets. Internally the characters are stored as unicode positions (e.g. 0x00C4 for a german Ä) and converted into UTF8 with the Utf8CharSet function from tools.h.


    Best regards,
    kanadakruemel

    Danke für die Arbeit, sieht von der Textdarstellung her schon gut aus. Bei mir (vdr 2.2.0 mit softhddevice-openglosd) gibt es immer noch das Problem, dass bei Aufruf einer neuen Teletext-Seite die vorherige Seite nicht vollständig gelöscht wird, s. Screenshot.
    Wenn ich das osdteletext Plugin neu starte (d.h. das Plugin schließe und wieder öffne), wird die Seite korrekt angezeigt.


    maz

    Bilder

    Meine VDRs:
    >>>Mac mini 2010 mit 2x Sundtek SkyTV Ultimate III, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>ZOTAC D2550 ITX-WIFI Supreme mit DD Cine S2, Gehäuse OrigenAE M10, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>Raspberry Pi         2 mit Sundtek SkyTV Ultimate IV, raspbian, rpihddevice-Plugin, Logitech Harmony 200<<<

    Einmal editiert, zuletzt von maz ()

    maz: stelle die Transparenz im teletext Plugin Setup auf 0, dann ist der Effekt verschwunden. Das scheint noch irgendwie ein Bug im SHD OpenGL Osd zu sein...obwohl ich mir da aktuell gar keinen Reim drauf machen kann 8o


    Ciao Louis

    Funktioniert leider auch nicht, mit Transparenz = 0 gibt es bei mir Grafikfehler und der Teletext ist gar nicht mehr lesbar.

    Meine VDRs:
    >>>Mac mini 2010 mit 2x Sundtek SkyTV Ultimate III, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>ZOTAC D2550 ITX-WIFI Supreme mit DD Cine S2, Gehäuse OrigenAE M10, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>Raspberry Pi         2 mit Sundtek SkyTV Ultimate IV, raspbian, rpihddevice-Plugin, Logitech Harmony 200<<<

    OK, mit 255 funktioniert es. Die Setup-Parameter können bei mir aus irgendeinem Grund nicht aus dem OSD heraus definiert werden - wenn ich in den settings vom osdteletext Plugin etwas verstelle, dann aus dem Menü gehe und wieder rein, ist noch der alte Wert da. Nur ein Ändern in der setup.conf klappt. Dort finde ich aber z.B. den Parameter für den Teletext-Font nicht.

    Meine VDRs:
    >>>Mac mini 2010 mit 2x Sundtek SkyTV Ultimate III, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>ZOTAC D2550 ITX-WIFI Supreme mit DD Cine S2, Gehäuse OrigenAE M10, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>Raspberry Pi         2 mit Sundtek SkyTV Ultimate IV, raspbian, rpihddevice-Plugin, Logitech Harmony 200<<<

    Schon klar :D geht dennoch nicht, die Änderungen werden nicht übernommen.

    Meine VDRs:
    >>>Mac mini 2010 mit 2x Sundtek SkyTV Ultimate III, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>ZOTAC D2550 ITX-WIFI Supreme mit DD Cine S2, Gehäuse OrigenAE M10, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>Raspberry Pi         2 mit Sundtek SkyTV Ultimate IV, raspbian, rpihddevice-Plugin, Logitech Harmony 200<<<

    Vielen Dank für das neue Patch, leider bei mir hat sich nicht viel geändert.


    VDR 2.3.1 mit vdr-rpihddevice



    Code
    http://abload.de/img/osdteletext02dtk7c.jpg


    OSD-Teletext Einstellungen (nichts im setup.conf)

    Code
    http://abload.de/img/osdteletext03izsnw.jpg


    OSD-Teletext abspeichern über OSD funktioniert hier:

    Code
    Mar 01 23:44:42 vdrrpi vdr[221]: store Courier:Bold 0
Mar 01 23:44:42 vdrrpi vdr[221]: [221] OSD size changed to 1920x1080 @ 1,77778
Mar 01 23:44:42 vdrrpi vdr[221]: [221] saved setup to /var/lib/vdr/setup.conf
Mar 01 23:44:42 vdrrpi vdr[221]: [221] OSD size changed to 1920x1080 @ 1,77778


    Ich habe nur im plugin menu auf OK gedrückt und das wird dann im setup.conf gespeichert

    2 Mal editiert, zuletzt von crow ()

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden