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

Quote from Taipan

Bei der ARD-Mediathek in der Tagesschau-Übersicht kann ich die Videos nicht wechseln -

Bei der Tagesschau passiert irgendwas und ich komme nicht dahinter. Die internen Server stellen komplett den Betrieb ein eine Verbindung ist nicht mehr möglich und es hilft nur ein Neustart. Ich vermute irgendwo einen Deadlock, finde den aber im Backtrace nicht.

Quote from jojo61

Ich habe nun eine Lösung gefunden. Wenn ich den cefbrowser nach dem vdr starte dann funktioniert es. Warum auch immer.

Das ist seltsam. Vielleicht hat das etwas mit dem Shared Memory zu tun, den ich nutze um die OSD Bildchen zu übertragen. Kannst du mal den Browser mit "-q" starten, dann wird das shm nicht verwendet, sondern die Bildchen werden über das Netz übertragen. "-q" nutzt das Grafikformat qoi, das recht gut ist und rasend schnell.

Quote from jojo61

Wann nutzt du denn dash2ts zum abspielen von Videos? Bisher sehe ich immer nur den ffmpeg. Ich habe den remotetranscoder mit -a gestartet.

Wenn ein mpeg dash abgespielt werden soll. In der ARD/ZDF Mediathek kann das z.B. mit der blauen Taste erreicht werden. Außer natürlich ein Film soll neu gestartet werden, dann geht das häufig wieder auf mp4. Woanders ist mir das noch nicht untergekommen, kann aber passieren.

Quote from jojo61

was mir noch aufgefallen ist: Wenn ein Stream/Video läuft, dann wird im Sekundentakt ein leeres OSD geschickt. Das ist sicher nicht notwendig

Hmm. Ein leeres OSD? Normalerweise werden Updates nur gesendet, wenn der Browser der Meinung ist, in der Seite hätte sich etwas verändert. Das ist schon seltsam.

Quote from jojo61

Und dann habe ich auch noch einen Segfault:

Man man man. Wie hast du das denn wieder geschafft? Vielleicht hängt das mit deinen (leeren) OSD Updates zusammen. Passiert das häufiger oder war das Zufall?

Insgesamt gesehen denke ich, die Verwendung von Rest und der cpphttplib war ein Fehler. Die Socket-Probleme, die Tagesschau und und und. Gespielt habe ich auch zwischendurch mal mit websockets, nanomq und zeromq, aber auch da hatte ich so meine Probleme. Es wird Zeit für etwas neues und hoffentlich stabileres. Ich hatte erst grpc in Betracht gezogen, aber die Abhängigkeiten und die Build-Zeit sind furchtbar. Mein Favorit ist im Moment Apache Thrift. Die ersten Tests waren vielversprechend.
Dabei ergeben sich auch verschiedene Optimierungspotentiale. Mal schauen.

Quote from jojo61

Mit -q funktioniert es auch wenn ich den cefbrowser vor dem vdr starte. Da hast du wohl wirklich noch ein Problem mit dem shared Memory.

Das werde ich mir anschauen müssen, sobald ich die Umstellung auf Apache Thrift fertig habe.

Die Umstellung scheint sich zu lohnen. Keine Probleme mit den Sockets, die Seiten sind schneller und das Video startet auch schneller. Also insgesamt gesehen viel flüssiger alles. Aber es gibt noch Unschönheiten, die beseitigt werden müssen

Es gibt für alle 3 Projekte (Plugin, Browser, Transcoder) neue Branches "thrift", die in Kombination die neue Funktionalität bereitstellen. Ich kann diese noch nicht in den master mergen, da ich für VDR*ELEC (auch Branch thrift) Abstürze und andere kleine Merkwürdigkeiten erlebe.

Insgesamt gesehen ist es aber auch auf den N2+ ziemlich flüssig und macht Spaß, wenn es die Probleme nicht gäbe, die seltsamerweise auf der Entwicklungsmaschine so gar nicht auftreten.

Also alle Branches sind aktuell nur für furchtlose Tester

Quote from rell

Btw, hast du mal eine force-push auf VDR*ELEC gemacht? Das ist nicht so gut

Ja leider war das nicht gut. Die Nebenwirkungen hatte ich erwähnt, aber ob das rückgängig gemacht werden kann weiß ich nicht und habe mich auch nicht weiter getraut

Mit dem gdb habe ich zumindest einen Hinweis erhalten, wo ich den segfault im Plugin suchen muss:

(gdb) bt full
#0  0xc7e1c802 in ?? ()
No symbol table info available.
#1  0xeedf9a2c in WebOSDPage::scaleAndPaint(unsigned char*, int, int, int, int, int, int) () from /usr/local/lib/vdr/libvdr-web.so.6
No symbol table info available.
#2  0xeeded144 in VdrPluginWebServer::ProcessOsdUpdate(pluginweb::ProcessOsdUpdateType const&) () from /usr/local/lib/vdr/libvdr-web.so.6
No symbol table info available.
#3  0xeee159e4 in pluginweb::VdrPluginWebProcessor::process_ProcessOsdUpdate(int, apache::thrift::protocol::TProtocol*, apache::thrift::protocol::TProtocol*, void*) ()
   from /usr/local/lib/vdr/libvdr-web.so.6
No symbol table info available.

Jetzt gilt es herauszufinden, wo und was da schief gehen kann.

Quote from rell

Hast du mit DEBUG gebaut? Mit "export DEBUG=_vdr-plugin-web" solltest du auch die symbol tables bekommen...

Verdammt. Das habe ich jetzt die ganze Zeit gesucht

jojo61

Hast du den Parameter "-f" für das web-Plugin gesetzt? Sobald ich den setze, bekomme ich gar kein OSD mehr. Aber das ist doch genau das Skalieren im OutputDevice? Ich bin verwirrt.

Quote from rell

Hast du mit DEBUG gebaut? Mit "export DEBUG=_vdr-plugin-web" solltest du auch die symbol tables bekommen...

Hmmm. Muss ich sonst noch etwas machen? Ich habe immer noch keine symbol tables.

Mein Vorgehen:
Build, wobei _vdr-plugin-web das "true" in dev-helper ergänzt wurde. Es werden auch die symbolischen Links auf /storage/... für libvdr-web.so.6 angelegt. Soweit so gut.

Dann der export DEBUG="_vdr-plugin-web" und ein Neubau nur des Plugins. Copy der neuen shared lib nach /storage/... und Neustart von VDR. Die neu eingefügten Ausgaben z.B. kommen, also wird die neue lib verwendet. Allerdings sehe ich im BT immer noch nur den Prozedurnamen ohne wirklich viel mehr Informationen.

Quote from rell

Und das DEBUG sollte dafür sorgen, dass die lib nicht gestrippt wird.

Keine Ahnung, was ich vorher permanent falsch gemacht habe. Ich habe jetzt auch den browser und vdr selbst mit in DEBUG und schwupps... ich bekomme einen schönen Backtrace, der mich aber eher ratlos zurücklässt Und das reproduzierbar (zwar mit Mühen, aber es geht).

#0  0xeea79708 in WebOSDPage::scaleAndPaint (this=0xd2b01868, image=<optimized out>, render_width=<optimized out>, render_height=<optimized out>, x=352, y=36, width=864, height=590)
    at webosdpage.cpp:338
        PixmapMutexLock = {<cMutexLock> = {mutex = 0x1ba4ec <cPixmap::mutex>, locked = true}, <No data fields>}
        recImageSize = {width = 1296, height = 885}
        recImage = {_vptr.cImage = 0x1ad674 <vtable for cImage+8>, size = {width = 1296, height = 885}, data = 0xb90c5008}
        scaled = <optimized out>
        mimage = <incomplete type>
        scaleRequired = <optimized out>
        scalex = 1.5
        scaley = 1.5
        osd_x = <optimized out>
        osd_y = <optimized out>
        osd_width = 1296
        osd_height = 885

Die entsprechende Zeile sieht jetzt bei mir so aus:

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

Ich baue das um und lass immer eine neue Pixmap erzeugen. Vielleicht, wer weiß, ein Mysterium....

Ich denke, es sollte jetzt mit der letzten Version des Plugins passen. In der Tagesschau wird das Video noch nicht zuverlässig skaliert.

Änderungen Browser/Plugin:
Das Shared Memory habe ich ersetzt durch ein weiteres Element im entsprechenden Thrift IDL. Das Shared Memory habe ich nicht zuverlässig hinbekommen, gerade bei verschiedenen Neustarts von VDR und/oder Browser.

Die Pixmap im Plugin wird jetzt nur ein Mutex geschützt.

Mein Testcase sah folgendermaßen aus:
Im Ersten/Tagesschau die Videos so schnell klicken, bis der Daumen weh tut und dann spontan auf die Menu-Taste springen. Ich denke, daß genau zwischen der Abfrage != nullptr und der folgenden Benutzung, die Pixmap gelöscht wurde. Ein extremes Timing also.

jojo61 : Läuft die neue Version bei dir jetzt ohne "-q"?

Der Umbau sollte fertig sein. Ich habe noch den Code etwas aufgeräumt und ein paar Bugs entfernt.
Die Tagesschau im Ersten funktioniert wieder so, wie es sein soll. Und auch der Live dash-Stream von 'Tagesschau 24' in der Tagesschau funktioniert.

Falls keine neuen Probleme auftauchen plane ich den Mega-Merge der ganzen Branches frühestens am Sonntag.

Ich kann natürlich nicht in allen Sendern jede Funktionalität testen. Falls irgendwas (noch) nicht funktioniert, dann brauche ich eine kurze Meldung.