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

Quote from kamel5

Also:

softhddevice mit OpenGL --> Anzeige i.O.

softhddevice ohne OpenGL --> Anzeige nicht i.O.

Vielleicht kannst Du damit ja was anfangen.

Quote from rell

Ich glaube, ich bin nah dran. Ich kann es so reproduzieren, dass er hier ein Problem hat:

Okay. Das ist mal eine Ansage. Ich werde das softhddevice neu kompilieren. Was das Device mit dem Softwarerendering und den kleinen Images macht, muss man schauen.

Quote from jsffm

Kann es sein, dass das Plugin nicht in 4k läuft? Nach Umschaltung auf 1920x1080 funktioniert es.

Hmm. Liege ich mit der 4K Auflösung falsch? UltraHD vs. 4K? Welche Auflösung hat denn so ein Fernseher?

3.840 x 2.160 oder 4.096 x 2.160? Ich hätte jetzt den größeren Wert genommen, aber dann geht evt. das Skalieren wieder los. Im Plugin selbst wird die tatsächliche Größe des OSD vom Ausgabedevice erfragt und damit gearbeitet.

Ich kann diese Auflösung aber überhaupt nicht testen.

Quote from rell

Ich glaube, ich bin nah dran. Ich kann es so reproduzieren, dass er hier ein Problem hat:

Beim Schreiben des Buffers in das shared Memory?

Kannst du mal schauen, welche Größe das File /dev/shm/cefbrowser hat. Es müssten 3840 * 2160 * 4 = 33177600 sein. Testest du mit 4K (siehe oben, unsichere Auflösung) oder HD?

Quote from jsffm

Auf meinem vdr3 mit AV-Receiver habe ich bei Phoenix keinen Ton, auf meinem vdr2 mit analogem Ton funktioniert es.

Welchen Audio-Codec verwendet denn Phoenix? Der Transcoder kopiert die nur Streams und transcodiert noch nicht echt. Und die weitere Ausgabe bleibt dem Ausgabedevice überlassen.

Quote from rell

-rw-r--r-- 1 root root 8294400 Jul 31 14:47 cefbrowser

Oh shit. Kannst du mal VDR und Browser stoppen und das File einfach löschen?

Quote from kamel5

Es gibt einen Parameter für die softhddevice.conf:

-w disable-ogl-osd

Das softhddevice sagt nun, daß opengl osd deaktiviert wurde. In der Tagesschau sehe ich auch nur ganz kurz das unvollständige OSD, aber relativ schnell dann wieder das Volle.

Quote from rell

Kracht aber trotzdem. Wo, weiß ich jetzt nicht, da ich die Debugs wieder raus hab.

Wenn es mit -q läuft, dann kann es nur am Handling mit dem shm liegen. Das

sharedMemory.Write((uint8_t *)outbuffer, r.width * r.height * 4);

macht ja nur ein einfaches memcpy. Was kommen denn für Werte für r.width und r.height? Sind die plausibel?

Quote from rell

Damit verabschiedet er sich dann.

Das shm Handling ist nicht perfekt. Kannst du mal den Patch probieren. Falls nicht mehr (aus welchen Gründen auch immer) das shm nicht mehr geöffnet werden kann, gibt es zumindest eine Fehlermeldung.

shm_error.patch.txt

Wenns das auch nicht ist, dann muss es der Aufruf von

vdrRemoteClient->ProcessOsdUpdate(renderWidth, renderHeight, r.x, r.y, r.width, r.height);

sein.

Quote from rell

Jul 31 17:13:59 rockchip2 cefbrowser[4403]: Could not map: Cannot allocate memory

Shit. Dann ist da tatsächlich noch etwas falsch. Ich mag Fehler, die irgendwann auftreten oder nicht oder doch und überhaupt.

Ich werde versuchen das umzubauen. Aber auf jeden Fall Danke für die Mühe und die Analyse.

Quote from kamel5

OK, bei mir fehlt der Rand dann bis zum Ende des ersten Videos. Mhh...

Ich habe das Plugin und den Browser aktualisiert. Für den Fehler von rell brauche ich noch eine Bestätigung, das es funktioniert.

Aber im Plugin sende ich jetzt ein Kommando, daß das OSD vollständig geladen werden soll, nachdem der Player aktiviert wurde. Ich hoffe, es funktioniert endlich.

Quote from rell

Gerne. Ich habe zu danken.

qoi funktioniert ja. Ist das überhaupt so viel langsamer?

Kannst du den Browser und das Plugin aktualisieren und wenn du Zeit hast, mal testen, ob es jetzt klappt.

qoi ist schon ziemlich schnell. Meine Einschätzung ist: Je langsamer der Rechner, umso mehr merkt man den Unterschied zum shared memory.

Quote from kamel5

Wenn ich das interpretieren müsste, würde ich denken, das das Schwarzbild mit folgender fehlerhafter Darstellung mit dem erneuten Setzen der Area size zu tun hat.

1. Muss da die Area size neu gesetzt werden?

2. Wenn ja, könnte nicht danach erst das Kommando, das das OSD vollständig geladen werden soll, erfolgen?

Ich habe das ReloadOSD im Plugin verschoben zu genau der Stelle, die du erwähnst. Es wird die Area gesetzt, die Pixmap gelöscht und danach soll das OSD neu geladen werden.

Quote from rell

Die gute Nachricht: Keine Fehler mehr mit shm bisher.

Puhh. Ein Problem weniger.

Quote from rell

Könnte man vor dem Zeichnen eines neuen OSDs für das Videofenster ein transparentes OSD zeichnen?

Ist das nur bei mir so? OSD an sich sieht vollkommen richtig aus.

Wie ist denn der Ablauf beim Bildaufbau, damit ich kontrollieren kann, ob mein Ausgabedevice alles richtig macht? Ich lasse da z.B. beim Flush nur die dirty rects löschen und zeichnen.

Den Videobereich explizit transparent zu machen, war das Ziel der letzten Umbauaktionen. In Javascript ist das ein Gewurschtel und mein Plan war bzw. ist es, sobald ich das Videofenster bestimmt habe, das OSD bzw. die Bitmap direkt zu manipulieren. Der Browser sendet für das OSD immer nur die Bereiche, die sich tatsächlich verändert haben. Die Bereiche werden dann im Plugin im webosdpage gezeichnet:

    if (!scaleRequired) {
        // scaling is not needed. Draw the image as is.
        cPoint recPoint(x, y);
        const cImage recImage(cSize(width, height), (const tColor *)image);

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

        if (osd != nullptr) {
            osd->Flush();
        }

        return true;
    }

Das Plugin kann man z.B. mit -DDEBUG_SAVE_OSD_IMAGE bauen und alle eingehenden Bilder werden in /tmp als qoi gespeichert. Aber gerade in der Tagesschau werden durch die Laufschriften sehr schnell enorm viele Bilder erzeugt. Und man bräuchte einen qoi-Viewer oder muss die Bilder umwandeln.

Wenn das Live-Bild angezeigt wird, sollte der entsprechende Bereich transparent sein, weil ansonsten das OSD das Video überlagert.

Das Video ist nur ein normaler mpeg-ts Stream. Gibt es Kommandos für das Ausgabedevice das Videofenster festzulegen? Dann könnte man mit einer normalen Aufnahme schauen, ob das Video auch richtig skaliert an der richtigen Position angezeigt wird. Das TV-Bild skalieren können verschiedene Skins (also zumindest der Skindesigner) und das scheint zu funktionieren.

Die eingehenden TS-Pakete werden auch nur an den Player weitergeleitet:

videoPlayer->PlayPacket((uint8_t *) body.c_str(), (int) body.length());
...
int result = PlayTs(buffer, len);

PlayTs ist schon schon im VDR im cPlayer definiert und damit im Ausgabedevice.