[osdteletext] 2.2.1 released

  • Sneak Preview auf 2.2.0 ist online zum Testen:


    https://github.com/vdr-project…text/tree/milestone-2.2.0


    Solange keine speziellen Optionen angegeben sind, sollte es sich wie 2.1.x verhalten mit den Unterschied, daß der Hintergrund-Transparenz-Wert nun (endlich) logisch ist, d.h. 0 -> keine Transparenz, 255 -> volle Transparenz und das es Tastenzuordnungen gibt, die nichts bewirken (OSD Preset + Hotkey Level) - und das man (endlich) auch für die letzte Taste im Setup-Menü eine Seitennummer zuweisen kann...


    Wenn allerdings aktiv geschalten mit:


    Code
    1. -k --key-levels=NUM Maximum amount of Hotkey levels selectable and stored
    2. default: 1 (which deactivate this feature)
    3. maximum: 9 levels
    4. -o --osd-presets=NUM Maximum amount of OSD presets selectable and stored
    5. default: 1 (which deactivate this feature)
    6. maximum: 9 presets

    und passender Belegung (Empfehlung: FastRwd: HotkeyLevel-, FastFwd: HotKeyLevel+) kann die OSD-Menüzeile bis zu 9 Ebenen bekommen, die man frei definieren kann...


    Und mit den OSD-Presets, die man dann auch mit Tasten umschalten kann, sollte jeder nun weitere (bis zu 9) umschaltbare Wunscheinstellungen finden (und nicht nur auf "HalfPage" eingeschränkt)...


    Viel Erfolg beim Testen, kann noch etliche Tage dauern, bis der 100% ausgereift ist.


    BTW: hab einen extra Thread dafür aufgemacht, damit's keinen Durcheinander gibt mit dem 2.1.0 Release ([osdteletext] 2.1.0 released)

  • Hallo pbrb,


    vielen Dank für deine Weiterentwicklungen. Ich habe das Problem, dass beim Wählen einer neuen Videotext-Seite die alte Seite als Schatten hinter der neuen Seite stehen bleibt. Ich nutzt softhdcuvid als Frontend.


    Viele Grüße

    Frank

    4x yaVDR 0.7: ASUS P5N7A-VM // 2*TeVii S460 // Atric mit Lirc // 4*1,5TB // 7" TFT

    Im Aufbau: VDR-UHD mit nVidia GT1030 unter Ubuntu 20.04

  • Welche Version von osdteletext hast Du getestet? Ich erinnere mich dunkel, daß da schon mal jemand was gemeldet hat...find nur grad den Post nicht mehr...damals klang es danach, als das "softhdcuvid" ein Problem in der OSD-Implementierung hat.


    Kannst Du mal ein Foto posten (so rechtes oberes Viertel), wie das aussieht. Stell dazu aber vorher mal so 70% Größe ein und Rahmen von 10 Pixel.

  • Das könnte ein Problem von softhdcuvid sein. Das hatte ich aber mal behoben, welche Version nutzt du denn ?

    Ich nutzt Paket-Version 3.3.1 git 20210416

    4x yaVDR 0.7: ASUS P5N7A-VM // 2*TeVii S460 // Atric mit Lirc // 4*1,5TB // 7" TFT

    Im Aufbau: VDR-UHD mit nVidia GT1030 unter Ubuntu 20.04

  • Das könnte ein Problem von softhdcuvid sein. Das hatte ich aber mal behoben, welche Version nutzt du denn ?

    Kannst du sagen, wie? Ich habe mit softhddevice-drm und OpenGL das gleiche Problem.


    Danke Andreas

  • Also in der Version 3.3.1 sollte es gefixt sein. Ich kann es hier nicht reproduzieren. Das Problem war das er beim Overlay nicht immer alles gelöscht hat.

    Ich lösche derzeit immer den Bereich der neu geschrieben wird. Wenn aber das osdteletxt da optimiert dann kann es immer noch fehlerhaft sein.

    Ich werde mal die Version 2.2.0 installieren und testen.

  • So habs nun getestet und es scheint ein Fehler im osdteletext plugin zu sein. Dort wird anscheinend der Bereich beim neuschreiben der Seite nicht gelöscht der nicht geschrieben wird.

    Ausserdem funktioniert das ändern des Backgroundtransparenz nicht immer online. Dazu muss der vdr neu gestartet werden.


    Bei Tranzparenz von 0 sieht man das ganze dann nicht mehr. :-)

  • Hmm, da scheinen sich aber die OSD-Implementierungen recht unterschiedlich zu verhalten...


    es funktioniert alles problemlos mit:

    sowohl Überschreiben der Zeichen als auch Online-Änderung der Hintergrund-Transparenz (z.B. via Config-Menu im 25-Zeilen-Modus)


    Die Zeichen werden alle mit "osd->DrawBitmap" gemalt, ich versteh nicht, wieso (wie beim Bild oben) der alte Text da überhaupt grau werden kann aber noch sichtbar bleibt...ist da irgendein Ausblend-Effekt aktiv, der nicht vollständig durchläuft - oder addiert sich da die Semi-Transparenz vom neuen Bitmap mit dem alten.


    ...dann wäre die Frage, welche OSD-Implementierung denn nach Vorgabe funktioniert bei Drübermalen von Bitmaps mit Alpha-Kanal.


    softhddevice putzt wohl, andere scheinen zu überlagern...


    BTW: beim Ändern der Transparenz (online) wird das ganze OSD neu aufgebaut (Display::SetMode), da sollten eigentlich keine Artefakte auftauchen...sofern das alte OSD auch von der Implementierung vollständig weggeputzt wird...

  • Korrigiert mich, wenn ich mich irre, aber nur eine Vermutung ins Blaue:

    Die OpenGL Implementierungen rendern auf Pixmaps und kombinieren diese dann in ein OSD. Dieser OSD-Buffer wird vor jedem "zusammenrendern" gelöscht.

    odsteletext nutzt http://git.tvdr.de/?p=vdr.git;…06054bad2a2;hb=HEAD#l2109 und rendert über Umwege auf pixmap[0]. Meiner Meinung muss irgendwer diese pixmap löschen, bevor die Zeichen einer neuen Seite darauf gerendert werden.

    Evtl. verhalten sich da OpenGL und Software Implementierungen anders. Funktioniert es denn bei jemandem mit OpenGL, von welchem softhd* auch immer?

    Gruß

    Andreas


  • ...dann wäre die Frage, welche OSD-Implementierung denn nach Vorgabe funktioniert bei Drübermalen von Bitmaps mit Alpha-Kanal.

    Die original Software Implementierung von VDR?

    Wenn du mehrere ->DrawBitmap in ein OSD, sprich auf pixmap[0] machst, ohne das OSD dazwischen zu löschen, sollten sich die Draws mit dem jeweiligen Alpha entsprechend überlagern. Das Foto sieht danach aus. Wird das OSD oder die pixmap irgendwann gelöscht, ausser, wenn osdteletext geschlossen wird?

  • Die original Software Implementierung von VDR?

    Wenn du mehrere ->DrawBitmap in ein OSD, sprich auf pixmap[0] machst, ohne das OSD dazwischen zu löschen, sollten sich die Draws mit dem jeweiligen Alpha entsprechend überlagern. Das Foto sieht danach aus.

    Ok, in dem Fall wäre die von mir benutzte "softhddevice"-Variante nicht gemäß "Standard".

    Wird das OSD oder die pixmap irgendwann gelöscht, ausser, wenn osdteletext geschlossen wird?

    Das OSD wird neu erzeugt bei Größen/Positionsveränderungen und Hintergrundänderung...sonst nicht....ich werd die nächsten Tage mal einen Schalter einbauen, der der bei einem Dirty-Char (das OSD wird tw. nur selektiv aktualisiert) den entsprechenden Bereich löscht...vielleicht reicht das schon.


    War das eigentlich schon immer so oder ist das durch die Optimierungen aufgetreten...wenn ja, ab welcher Version (noch besser: git-commit...)

  • da ich das hier wohl nicht nachstellen kann, brauch ich noch eine Zusatzinfos:


    sind die Message-Boxen (z.B. Kanalwechsel), die so auftauchen können, vom Hintergrund OK und was passiert, wenn die wieder verschwinden...sind da auch noch alte Textfragmente sichtbar oder ist der Bereich, in dem die Message-Box gezeichnet wurde, nach dem Verschwinden anders wie der Rest?

  • sind die Message-Boxen (z.B. Kanalwechsel), die so auftauchen können, vom Hintergrund OK und was passiert, wenn die wieder verschwinden...sind da auch noch alte Textfragmente sichtbar oder ist der Bereich, in dem die Message-Box gezeichnet wurde, nach dem Verschwinden anders wie der Rest?

    Wie kann ich die Message-Boxen denn einblenden? Ich habe es nicht geschafft, außer dem osdteletext was anzeigen zu lassen. Und es ist tatsächlich so, dass jedesmal eine neue Seite mit dem Alpha über alles alte geblendet wird, was dann natürlich im Wirrwarr endet...


    Wenn sich an einer Seite was ändert, wird dann die Seite komplett mit allen Bereichen neu gezeichnet, oder nur die "dreckigen" Bereiche?


    Ich stelle mir das so vor, dass jedesmal, wenn in einen Bereich etwas gezeichnet wird, für diesen Bereich erstmal alles gelöscht wird. Am besten wohl mit ->DrawRectangle in einer Funktion ählich ->CleanDisplay. Falls alles neu gezeichnet wird, würde wohl ein CleanDisplay reichen. Ich meine, so wäre es sauber, da ich nicht glaube, dass eine "Überblendfunktion" im Teletext Sinn macht?!


    Allerdings frage ich mich, warum sich deine Ausgabeplugins da da anders verhalten. Nutzt du das softhddevice mit GL?


    Ohne deinen Code ganz verstanden zu haben, tut es hier und hier möglicherweise auch schon ein

    Code
    1. osd->DrawRectangle(vx + leftFrame, vy + topFrame, w - 1, h - 1, GetColorRGB(ttcTransparent,0));

    EDIT: Wenn das funktionieren sollte, ist es aber sicher nicht die performanteste Lösung :)


    Gruß

    Andreas

  • da ich das hier wohl nicht nachstellen kann, brauch ich noch eine Zusatzinfos:


    sind die Message-Boxen (z.B. Kanalwechsel), die so auftauchen können, vom Hintergrund OK und was passiert, wenn die wieder verschwinden...sind da auch noch alte Textfragmente sichtbar oder ist der Bereich, in dem die Message-Box gezeichnet wurde, nach dem Verschwinden anders wie der Rest?

    Du liegst mit deiner Vermutung richtig. Es bleibt ein heller Hintergrund-Bereich nach dem Verschwinden der Message-Box erhalten.

  • die Zeichen werden normalerweise einzeln geschrieben und nur das notwendigste, das war schon immer so:

    Code
    1. cBitmap charBm(w, h, 24);
    2. charBm.DrawRectangle(0, 0, w, h, bg);
    3. charBm.DrawText(0, ttSetup.txtVoffset, buf, fg, 0, font);
    4. osd->DrawBitmap(vx, vy, charBm);

    das sich die Ausgabeplugins unterschiedlich verhalten, habe ich an den VDR-Maintainer gemeldet und warte auf die Rückmeldung, wie es eigentlich wirklich sein sollte.


    Bei mir läuft: vdr-softhddevice-1.1.0 (https://github.com/ua0lnj/vdr-plugin-softhddevice)

    und das kann übrigens auch "cuvid" (ich habe hier Intel VA-API im Einsatz).


    BTW: auch mit Versionen < 0.9.9 sollte das Verhalten genauso sein, weil an dem Dirty/DirtyAll Mechanismus habe ich nichts geändert meineswissen.

    Man könnte natürlich vor dem DrawBitmap noch ein DrawRectangle direkt auf dem OSD auslösen ("Putzjob") -> entweder als Workaround oder als Dauerzustand....je nach Ergebnis vom VDR-Maintainer...


    Mit dem Meldungsfenster hatte ich übrigens die vom OSDTeletext selbst gemeint, z.B. "Kanalwechsel" (cache oder live), nur mal aktivieren und mit OK wieder schließen, dann wird dieser Bereich neu gezeichnet, und dürfte dann keine "Schatten" mehr haben, der Rest schon.

  • Bei mir läuft: vdr-softhddevice-1.1.0 (https://github.com/ua0lnj/vdr-plugin-softhddevice)

    und das kann übrigens auch "cuvid" (ich habe hier Intel VA-API im Einsatz).

    Mit oder ohne GL Unterstützung?

    https://github.com/ua0lnj/vdr-plugin-softhddevice/blob/vdpau%2Bvaapi%2Bcuvid/Makefile#L23

    https://github.com/ua0lnj/vdr-…aapi%2Bcuvid/Makefile#L45


    Ich würde meine Zeilen eher als Workaround sehen, da kann man schon noch optimieren.


    Lese ich es richtig, dass die Zeichen alle mit DrawPixel gezeichnet werden?

    ^ Sry, nein. Mit DrawText.

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

  • Mit dem Meldungsfenster hatte ich übrigens die vom OSDTeletext selbst gemeint, z.B. "Kanalwechsel" (cache oder live), nur mal aktivieren und mit OK wieder schließen, dann wird dieser Bereich neu gezeichnet, und dürfte dann keine "Schatten" mehr haben, der Rest schon.

    ok, Missverständnis. Im OSDTeletext wird der Bereich neu gezeichnet, es entsteht kein Schatten.

    4x yaVDR 0.7: ASUS P5N7A-VM // 2*TeVii S460 // Atric mit Lirc // 4*1,5TB // 7" TFT

    Im Aufbau: VDR-UHD mit nVidia GT1030 unter Ubuntu 20.04

  • Code
    1. cBitmap charBm(w, h, 24);
    2. charBm.DrawRectangle(0, 0, w, h, bg);
    3. charBm.DrawText(0, ttSetup.txtVoffset, buf, fg, 0, font);
    4. osd->DrawBitmap(vx, vy, charBm);

    das sich die Ausgabeplugins unterschiedlich verhalten, habe ich an den VDR-Maintainer gemeldet und warte auf die Rückmeldung, wie es eigentlich wirklich sein sollte.

    Ich meine, das ist eigentlich klar.

    charBm.DrawRectangle -> http://git.tvdr.de/?p=vdr.git;…defe9a2b43ca;hb=HEAD#l248

    charBm.DrawText -> http://git.tvdr.de/?p=vdr.git;…defe9a2b43ca;hb=HEAD#l242

    osd->DrawBitmap -> http://git.tvdr.de/?p=vdr.git;…defe9a2b43ca;hb=HEAD#l902


    charBm ist ein neues Bitmap mit entsprechendem Hintergrund und das wird dann mit dem alpha Wert wird ins OSD geblendet. charBm ist an sich richtig.

    Wenn der Bereich aber im OSD jetzt bereits belegt ist, wird über die alten Pixel geblendet. Bei schwarzem Hintergrund fällt das nicht auf.