web (HbbTV, VDR*ELEC), Milestone 1 erreicht

Zitat von kamel5

Wenn ich bei meiner TT6400 die OSD-Größe im Ausgabedevice (dvbhddevice) entsprechend fest einstelle, z.B. auf 1024x576, dann skaliert der skindesigner entsprechend

Um so besser.

Was ich aber gesehen habe ist das die Images nicht scaliert werden. D.h. die Icons bleiben unverändert und passen dann nicht immer

in die vorgesehenen Plätze. Wenn ich skindesigner mit einem 3940x2160 OSD laufen lasse dann passt das nicht so recht.

Letztlich ist es nur wichtig das die Oberflächen plugins wissen wie gross das OSD ist. Und der Ansatz von oben würde ihnen das kaputt machen wenn das web plugin das OSD verändert und nicht mehr zurück setzt.

Zitat von jojo61

Was ich aber gesehen habe ist das die Images nicht scaliert werden. D.h. die Icons bleiben unverändert und passen dann nicht immer

in die vorgesehenen Plätze. Wenn ich skindesigner mit einem 3940x2160 OSD laufen lasse dann passt das nicht so recht.

Normalerweise sollten die Icons auch alle skaliert werden, das sind alles *.svg Dateien.

Möglicherweise gibt es da im skindesigner noch irgendwo eine Obergrenze, ich muss mir das mal ansehen.

Ich kann das aber leider nicht selber testen, da ich noch keine 4K Ausgabe habe.

Grüße

kamel5

Ich würde trotzdem sagen, dass ein DrawImageScaled() die sauberere Lösung wäre, falls kls da mitgeht. Ich poste später mal einen Patch, dann könnte man es mal testen...

Ungetestet: https://github.com/rellla/VDRS…e252443610c12acbc2ce7a61f

Und die scaleAndPaint könnte etwa so aussehen:

diff --git a/webosdpage.cpp b/webosdpage.cpp
index b565265..41fdd1b 100644
--- a/webosdpage.cpp
+++ b/webosdpage.cpp
@@ -256,40 +256,15 @@ bool WebOSDPage::scaleAndPaint(uint8_t* image, int width, int height, AVPixelFor
         return false;
     }

-    // create image buffer for scaled image
-    cSize recImageSize(disp_width, disp_height);
     cPoint recPoint(0, 0);
-    const cImage recImage(recImageSize);
-    auto *scaled  = (uint8_t*)(recImage.Data());
+    const cImage recImage(cSize(pixmap->ViewPort().Width(), pixmap->ViewPort().Height()), (const tColor *)image);

-    if (scaled == nullptr) {
-        esyslog("[vdrweb] Out of memory reading OSD image");
-        return true;
-    }
-
-    // scale image
-    if (swsCtx != nullptr) {
-        swsCtx = sws_getCachedContext(swsCtx,
-                                      width, height, srcFormat,
-                                      disp_width, disp_height, destFormat,
-                                      SWS_BILINEAR, nullptr, nullptr, nullptr);
-    }
-
-    if (swsCtx == nullptr) {
-        swsCtx = sws_getContext(width, height, srcFormat,
-                                disp_width, disp_height, destFormat,
-                                SWS_BILINEAR, nullptr, nullptr, nullptr);
-    }
-
-    uint8_t *inData[1] = { image };
-    int inLinesize[1] = {4 * width};
-    int outLinesize[1] = {4 * disp_width};
-
-    sws_scale(swsCtx, inData, inLinesize, 0, height, &scaled, outLinesize);
+    double scaleX = (double)pixmap->ViewPort().Width() / (double)width;
+    double scaleY = (double)pixmap->ViewPort().Height() / (double)height;

     if (pixmap != nullptr) {
         LOCK_PIXMAPS;
-        pixmap->DrawImage(recPoint, recImage);
+        pixmap->DrawImageScaled(recPoint, recImage, scaleX, scaleY);
     } else {
         esyslog("[vdrweb] Pixmap is null. OSD not available");
     }
--

... auch ungetestet.

Zitat von rell

Ich würde trotzdem sagen, dass ein DrawImageScaled() die sauberere Lösung wäre, falls kls da mitgeht. Ich poste später mal einen Patch, dann könnte man es mal testen...

Das schöne am SVG ist ja gerade das man es verlustfrei in alle Auflösungen skalieren kann. Wenn du auf "Pixel Ebene" skalierst gibst du den Vorteil von immer scharfen Kanten wieder auf.

Da hast du natürlich recht, aber mit SVGs haben wir es doch bei einem cImage bzw. hier im speziellen mit den Daten die der cefbrowser aktuell liefert doch gar nicht zu tun, oder?

OpenGL behandelt cImage praktisch als Texture und mit DrawImageScaled könnte man dem Draw einfach noch ein Zielrechteck mitgeben. Das gibt es ja so noch nicht.

Das openglosd.c für softhdodroid ist fast gleich. Ich mache dir morgen einen Patch dafür. Dann kannst du es testen.

Hier nun der Patch für das softhdodroid plugin. Danke an rell für die Vorarbeit.

Natürlich brauchst du dann auch noch den patch für den vdr von rell

Ich hoffe, das funktioniert auch so

Zabrimus Bei vdr-plugin-web müsstest du nochmal schauen, ob das mit dem (tColor *) cast auf das uint_8 image so richtig ist, da bin ich zu wenig C Profi.

Und das x/y-Scaling fehlt natürlich auch noch.

Gruß

Andreas

warum sollte es Probleme mit anderen Plugins geben? Die Funktion DrawImageScaled ist neu und sollte niemand stören der sie nicht nutzt.

DrawImage ist ja unverändert noch da.

Zitat von Zabrimus

Ja. aber die ist pure virtual und wenn die nicht implementiert wird, dann schlägt die Kompilierung fehl oder sehe ich da was falsch

Da bin ich überfragt

Aber ich hätte ein paar Patches für dich, die du dir ansehen kannst -> https://github.com/rellla/VDRSternELEC/commits/WIP/cef

Ich bin auf ein paar Probleme gestossen:

- das addon Verzeichnis liegt in ${DEVICE} nicht in ${PROJECT} (zumindest bei LE)

- locale wird nicht gebaut, weil es in der addon.list nicht steht. Das automatische Bauen habe ich raus...

- ich baue cefbrowser als .zip Datei und lasse es beim update kopieren. Das vdrsternelecupdate schlägt fehl, wenn Dateien schon vorhanden sind.

- addons werden bisher nicht geupdated

- mc aus den system-tools meckert die fehlende libssh2.so an. Keine Ahnung warum das jetzt so ist. Evtl. nur bei mir. Ansonsten wäre das ein bug in LE

- der cefbrowser ist als Paket nun dabei. Dabei werden die binaries in root/cef/cef-*.tar.bz2 abgelegt und müssen manuell einmalig auf den client kopiert werden. Der Browser an sich wird beim update kopiert

- die WIP/DO_NOT_MERGE Sachen betreffen ein paar Dinge bzgl. scaling und damit das Entwickeln einfacher ist

- der graphicsmagick patch z.B. verhindert, dass abgebrochen wird, bevor ein coredump erstellt wird. Ansonsten fängt das der signal handler von graphicsmagick nämlich vorher ab

Vielleicht kannst du die ersten Sachen mal testen und gebrauchen. Ich werde dann auch mal wieder vdr-plugin-web versuchen...

Gruß

Andreas

Zitat von Zabrimus

Und es funktioniert Das OSD hat noch Fehlfarben aufgrund des falschen Pixelformats (bgra, rgba), aber das ist lösbar.

Welches Format liefert der Browser?

Zabrimus: Meinst du, die VDR*ELEC Boxen würden den Transcoder packen?

So, konnte es jetzt auch testen. Das sieht schon richtig gut aus. Flott, weniger bis kaum Abstürze (cefbrowser hats mal geschleudert...).

Was mich ein bißchen aufgehalten hat, war, dass das OSD völlig zerwürfelt dargestellt wurde und ich habe dann auch herausgefunden, warum...

Hast du was dagegen, als OSD Level nicht das Subtitle Level zu wählen? softhddevice-drm-gles (und evtl. auch andere) behandeln das etwas eigen. Z.B. werden hier teilweise X und Y ignoriert und das passt dann nicht mehr. Wenn ich da einen anderen Level wähle funktioniert alles wunderbar. Ich muss mal in VDR-Code schauen, wie das mit den Untertiteln generell gedacht ist.

Mit den Farben habe ich übrigens kein Problem.

Bei ZDF sehe ich noch kein Video, sondern höre es nur, aber das wird schon Jetzt ist es auch viel besser zu testen, da sich kaum eine Komponente verabschiedet...

Gruß

Andreas