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

  • Also muss in TVGuide noch irgendwas anders sein.

    Wenn man keine Taste drückt macht TVGuide nichts. Das einzige was durch das Plugin geht, ist dann ProcessKey() vom VDR jede sec. getriggert. Und das triggert dann jede Min. ein Update des OSD.

    Einen Thread, der dann im Hintergrund werkelt, gibt es auch nicht.

    Das einzige, was bei jedem ProcessKey() Durchlauf gemacht wird, ist ein cPixmap::Lock() am Anfang und ein cPixmap::Unlock() am Ende. Vielleicht reicht das ja schon, um das OSD offen zu halten.

    Ich muss das morgen mal testen, ob das die Ursache dafür ist.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich weis jetzt nicht, ob Du da schon weiter gekommen bist, das hat mich selbst aber auch mal interessiert, warum das OSD bei mir offen bleibt.

    Im Endeffekt ist das ganz einfach, man muss nur "state = osContinue" in ProcessKey() regelmäßig zurückgeben. Solange das passiert, bleibt das OSD auch offen.

    Bisher wurde ja "state=cOsdObject::ProcessKey(Key);" gemacht (brauchst Du das wirklich), und das führte dazu, das "state=osUnknown" zurückgegeben wird, solange keine Taste betätigt wird, was dann zum Schließen des OSD führt.

    Mit folgender kleiner Änderung in webosdpage.cpp:

    Code
    eOSState WebOSDPage::ProcessKey(eKeys Key) {
        eOSState state = osContinue;
    //    state = cOsdObject::ProcessKey(Key);
    
    //    if (state == osUnknown) {
        if (Key != kNone) {
            // special key: kInfo -> Load Application in Browser
            if (Key == kInfo) {
                LOCK_CHANNELS_READ
                const cChannel *currentChannel = Channels->GetByNumber(cDevice::CurrentChannel());

    bleibt bei deaktiviertem "cRemote::TriggerLastActivity();" und ohne Tastendruck das OSD solange offen, wie man mag. Ich hatte es jetzt schon ca. 20 Min offen. Alles Andere funktioniert mit der Änderung genau so, wie bisher.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Im Endeffekt ist das ganz einfach, man muss nur "state = osContinue" in ProcessKey() regelmäßig zurückgeben. Solange das passiert, bleibt das OSD auch offen.

    Genau darauf bin ich auch schon gekommen und das ist die Lösung. Ich habe den Thread und alle Spuren aus dem Plugin entfernt. Heute kam ich auch dazu, die Pause zu testen und auch die bleibt jetzt offen und wird nicht mehr geschlossen.

    Es kann alles so einfach sein, wenn man darauf kommt ;)


    Den Entwicklungsbranch des Browsers habe ich jetzt auch gemerged. Allerdings sollte man Videos der Privaten (S1, P7) nur probieren, wenn man ausgesprochen mutig ist. Im Besten Fall sieht man nur nur eine Endlosschleife von Werbung. Der schlimmste Fall sollte nach einer Änderung im Plugin nicht mehr auftreten - hoffentlich.

    Durch die Nutzung von mutation-summary (Javascript) bekomme ich jetzt nicht mehr alle Kleinigkeiten der DOM-Änderung (Videosize und dergleichen) mit, sondern nur noch eine Zusammenfassung. Das ist viel angenehmer zu handlen. Ich muss jetzt nur noch das video-Tag auch erkennen, das RedButton geschickt einschmuggelt, um dann die URL zu ändern.


    Habe ich eigentlich schon erwähnt, daß ich mit Javascript nicht viel anfangen kann? Ich werde damit einfach nicht warm, egal wie oft ich es versuche.

  • Habe ich eigentlich schon erwähnt, daß ich mit Javascript nicht viel anfangen kann? Ich werde damit einfach nicht warm, egal wie oft ich es versuche.

    Och und ich wollte dich bitten den Kinderschutz bei ARD und ZDF zu eliminieren :) Ich finde das nervig und man sollte das rausnehmen wenn möglich.


    Ausserdem ist mir aufgefallen das nun der VDR beim beenden immer einen segfault macht.

    Code
    Magick: abort due to signMagick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...
  • Der Unterschied ist, dass du die Anzeige vom Browser mit html machen lässt und in meinem Patch das Plugin das macht. Man kann sich den Weg über den Browser eigentlich sparen.

    Ich würde auch den Weg ohne den Browser favorisieren. Ich habe hier unter anderem das Problem, bedingt durch meine Hardware (die OSD-Datenübertragungsrate ist leider begrenzt bei der TT6400), das die Videos ruckeln, wenn das Menü ein- und ausgeblendet wird. Scheinbar werden hierbei die OSD- und Video-Daten nicht unabhängig voneinander übertragen. Ich weis nicht, ob sich da noch mehr entkoppeln lässt, um das zu verbessern.


    rell und ich haben deshalb den Volume-Patch nochmals erheblich vereinfacht, siehe Anhang.

    Zabrimus , vielleicht kannst Du Dich ja damit anfreunden.


    Grüße

    kamel5

  • Scheinbar werden hierbei die OSD- und Video-Daten nicht unabhängig voneinander übertragen. Ich weis nicht, ob sich da noch mehr entkoppeln lässt, um das zu verbessern.

    So wie ich das sehe werden die Video Daten durch den Browser geschleusst. Ich denke das könnte man auch von remotrans direkt an das Plugin senden.

    Damit wäre dann auch das OSD von den Videodaten entkoppelt. Zumindest was dem Browser betrifft.

  • Och und ich wollte dich bitten den Kinderschutz bei ARD und ZDF zu eliminieren :) Ich finde das nervig und man sollte das rausnehmen wenn möglich.

    Was denn für einen Kinderschutz? Hast du da ein Beispiel?

    rell und ich haben deshalb den Volume-Patch nochmals erheblich vereinfacht, siehe Anhang.

    Ich habe den Patch übernommen. Die Lösung über ProcessKey ist ziemlich elegant.

    So wie ich das sehe werden die Video Daten durch den Browser geschleusst. Ich denke das könnte man auch von remotrans direkt an das Plugin senden.

    Damit wäre dann auch das OSD von den Videodaten entkoppelt. Zumindest was dem Browser betrifft.

    Ja. Das könnte man recht einfach machen, aber dann brauche ich im RemoteTranscoder noch einen Heartbeat für den Browser. Aktuell ist es so, daß der Transcoder stoppt, wenn der Browser nicht mehr verfügbar ist, weil gerade das mir am Anfang Ärger machte: Browser stürzt ab oder wird durchgestartet und der Transcoder arbeitet und sendet fröhlich weiter. Auch sind dann Kommandos (stop, pause) an den Transcoder nicht mehr möglich.

    Dasselbe passiert auch, wenn VDR gestoppt wird. Durch die ganze Kaskade werden sowohl der Browser, als auch der Transcoder gestoppt.


    Ich denke, diese Variante würde die aktuelle Funktionalität weitgehend aufrecht erhalten:

    Transcoder sendet TS Daten direkt an VDR und gleichzeitig einen Heartbeat an den Browser.


    Lang-/Mittelfristig könnte ich mir auch vorstellen, den Transcoder as is in das Plugin zu integrieren. Allerdings will ich mir noch die Möglichkeit offen halten, auf einen externen Transcoder (entweder dauerhaft oder nur bei Bedarf) zu wechseln. Der Transcoder besteht im Wesentlichen nur 2 aus wichtigen Klassen: transcodeconfig und ffmpeghandler. Der Rest dient nur zur Kommunikation und zum Starten.

  • Und das vor 22h


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Ausserdem ist mir aufgefallen das nun der VDR beim beenden immer einen segfault macht.

    Bei mir nicht immer, aber doch recht häufig, siehe Anhang. Möglicherweise hat das die gleiche Ursache.


    Grüße

    kamel5

  • Bei mir nicht immer, aber doch recht häufig, siehe Anhang. Möglicherweise hat das die gleiche Ursache.

    Laut BT ist der BrowserClient schon beendet worden oder noch nicht aktiv, während der AIT Scanner etwas senden will. Ich baue eine Sicherheitsabfrage ein.


    Segfaults der Form

    Code
    Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...

    Habe ich im Moment (in meiner Version) sehr häufig. Beim Beenden und wenn ein Video bei S1 abgespielt werden soll. Das Merkwürdige ist, daß mein Plugin Magick überhaupt nicht benutzt, das OSD lasse ich bereits vom Browser skalieren. Ich werde mal einen anderen Skin (als Skindesigner) versuchen.


    Das Ausgabedevice läuft dabei auch noch Amok. Ich weiß nicht, ob der schnelle Wechsel von Streams in verschiedener Auflösung (Werbung und danach das Video) die Ursache ist oder ob der Player noch nicht vollständig da ist. Ich suche gerade eine Möglichkeit herauszufinden, wann das Ausgabedevice und der Player so richtig echt bereit sind um dann den Stream zu senden.

  • Habe ich im Moment (in meiner Version) sehr häufig. Beim Beenden und wenn ein Video bei S1 abgespielt werden soll. Das Merkwürdige ist, daß mein Plugin Magick überhaupt nicht benutzt, das OSD lasse ich bereits vom Browser skalieren. Ich werde mal einen anderen Skin (als Skindesigner) versuchen.

    skindesigner nutzt das nicht, aber z.B. tvguide oder skinnopacity und noch ein paar andere. Und es reicht hier nicht, einen anderen Skin zu nutzen, das betreffende Plugin darf nicht geladen sein.


    Das hat mich auch eine Weile gestört, es hat dann mal hier im Forum jemand (ich weis leider nicht mehr, wer das war) eine Lösung gepostet.


    Wenn man folgendes in den entsprechenden Plugins macht:

    Code
     __attribute__((constructor)) static void init(void) {
    -   Magick::InitializeMagick(NULL);
    +   MagickLib::InitializeMagickEx(NULL, MAGICK_OPT_NO_SIGNAL_HANDER, NULL);
     }

    werden die segfaults nicht mehr von Magick okkupiert.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • War in diesem Thread ;)

  • Ich muss mal wieder Feedback geben :)

    Ich habe gestern abend auf ARD die erste Episode von Arcadia geschaut und alles hat prima geklappt. Dann startete die zweite Episode automatisch und nach 4 Minuten hat sich das ganze dann aufgehängt. Nach gefühlt 60 sekunden wurde dann der VDR mit dem TV Programm wieder aktiv. Da stimmt noch etwas mit dem beenden einen Films nicht. Was dann den nächsten Film offensichtlich stört. Vielleicht sollte man sicherheitshalber beim öffnen noch einen killall ffmpeg einbauen um sicher zu gehen das der alte ffmpeg wirklich beendet ist.

  • Dann startete die zweite Episode automatisch und nach 4 Minuten hat sich das ganze dann aufgehängt.

    In der ARD? Vielleicht ist das dasselbe Problem, daß ich mit Sat1/Pro7 habe.


    Ich weiß einfach nicht mehr weiter. Folgende Situation habe ich bei S1P7:

    Ich will irgendwas schauen und vorher wird Werbung eingeblendet. Die Werbung läuft durch und dann soll die eigentliche Sendung starten. Und dabei gibt es 2 Probleme:

    1. Die Länge der Sendung entspricht im Browser genau der Länge der Werbung davor und nach Ablauf der Zeit wird die Sendung gestoppt und wieder Werbung gestartet.

    2. Der Transcoder schickt zwar Daten, aber im VDR habe ich nur TS-Fehler ohne Ende. Deshalb auch der Verdacht oben mit der ARD.


    Im Moment konzentriere ich mich auf 1. und habe so alles probiert, was ich im Netz gefunden habe:

    Gespielt habe ich mit den Attributen autoplay, preload und mit video.play, video.load, video.pause.

    Im Chrome-Debugger gesehen, daß eigentlich (augenscheinlich) alles funktionieren müsste. Es gibt keine Fehler, das neue transparente Video der Sendung (mit der Richtung Länge) wird auch übers Netz geladen. Den Transcoder habe ich den HTTP Header Cache-Control: no-cache untergeschoben um auch da sicher zu sein. Der Transcoder wurde gesplittet: Statt einem einfachen StreamVideo sind nun 2 Kommandos notwendig: Probe und dann StreamVideo. Das hatte andere positive Auswirkungen, die ich mir nicht erklären kann, aber eine Lösung ist immer noch nicht in Sicht.


    Ich bin rat- und ideenlos. Falls jemand mal schauen will:

    Im Browser in der Datei static-content/js/videoobserver.js befindet sich das ganze Video-Handling.

    Interessant sind dabei die Funktionen checkObjectNode und addVideoNode.


    ich werde jetzt erstmal den 2. Fehler oben untersuchen. FFmpeg wird eigentlich vollständig gestoppt, bevor das neue Video startet und trotzdem gibt es TS-Fehler im Plugin bzw. Ausgabedevice.

  • Schliesst du auch die Pipe auf der Remotrans seite ? Evtl. sind da noch reste drin.

    Hmmm... Gute Idee. Das werde ich prüfen.


    Irgendeine Änderung ist dafür verantwortlich, daß der Transcoder häufiger abstürzt (wenn der Browser abgeschossen wird). Das war vorher nicht so, da muss ich dringend schauen, weil ich den Transcoder bisher einfach gemütlich habe durchlaufen lassen.


    Das Plugin kennt jetzt den Parameter "-s/--savets". Damit werden alle eingehenden TS Packete in das videodir/web gespeichert und können als Aufnahme abgespielt werden. Bei jedem StartVideo und ResetVideo wird eine neue "Aufnahme" angelegt. Zu Debugging-Zwecken bestimmt nützlich.


    Ich hatte jetzt beim Test wieder TS Fehler, aber die die erzeugten "Aufnahmen" werden problemlos abgespielt.

    Aber es gibt noch ein anderes extrem seltsames Verhalten mit softhdcuvid. Ich kann es jetzt gerade - natürlich - nicht nachstellen.

    Werbung in Fullscreen

    Sendung im Fullscreen

    Aber plötzlich wird ist das Video kleiner (rechts und unten ein Rand). Im Rand werden dann Reste der Werbung dargestellt. Allerdings nicht als Standbild, sondern eher als sehr kurze Endlosschleife.

    Dann passiert das wieder und das Video-Fenster ist noch kleiner, aber in dem neuen Rand ist alles grün.

    Ganz merkwürdig und das scheint auch von der Werbung abzuhängen.

    Kann es Probleme mit dem schnellen Wechsel der Auflösung des Videos, der Bitrate oder was auch immer geben?


    Edit:

    Mir ist es wieder gelungen. Das Bild sieht dabei so aus:

    Der untere Rand ist nicht statisch, sondern bewegt sich in einer kleinen Endlosschleife.

  • Ja das liegt bestimmt an der umschaltung der Auflösung. Ich habe intern ca. 12 Buffer und wenn die Auflösung plötzlich kleiner ist dann bleibt in den Frames der "alte" Teil stehen und wird als minischleife mit angezeigt. Da bekomme ich die Änderung der Auflösung wohl nicht mit. Normalerweise findet das ja auch nur bei einem Programmwechel statt. Hier aber wohl mitten im Film. Da muss ich wohl nochmal ins Plugin schauen und aufpassen das ich es mitbekomme wenn sich die Auflösung ändert. Da ich morgen in Urlaub fahre wird es aber wohl noch etwas dauern bis ich dazu komme.

  • Normalerweise findet das ja auch nur bei einem Programmwechel statt. Hier aber wohl mitten im Film. Da muss ich wohl nochmal ins Plugin schauen und aufpassen das ich es mitbekomme wenn sich die Auflösung ändert.

    Ich mache ja keinen Programmwechsel, sondern nur ein Reset nach dem Stoppen des Videos und dem Start des Neuen. Aber gut, daß zumindest dafür eine Erklärung vorhanden ist.

    Die Werbung hat eine kleinere Auflösung, als die Sendung. Beide Auflösungen sind sowieso seltsam klein. Da wird wohl etwas zuviel an Bandbreite/Zeit/Kosten oder was auch immer gespart.


    Ich habe es endlich geschafft, daß das eigentliche Video nach der Sendung die richtige Länge hat. Ich weiß nicht, welche der Änderungen oder welche Kombination dafür verantwortlich ist. Das ist aber auch egal, wenn es funktioniert. Das Problem ist jetzt nur noch, daß das Ausgabedevice nur TS Errors auswirft und das Video nicht darstellt. Mit der Speicherung der eingehenden TS Packete (Parameter -s) kann ich sehen, daß durchaus etwas vernünftiges im VDR ankommt, es wird nur nicht dargestellt.

    Da ich morgen in Urlaub fahre wird es aber wohl noch etwas dauern bis ich dazu komme.

    Dann wünsche ich Dir einen schönen Urlaub :)

  • Mit der Speicherung der eingehenden TS Packete (Parameter -s) kann ich sehen, daß durchaus etwas vernünftiges im VDR ankommt, es wird nur nicht dargestellt.

    Auch das könnte daran liegen das ich den Streamwechsel nicht mitbekomme. Da ist dann evtl. der Dekoder nicht richtig initialisiert. Auch der möchte keine Streamwechel ohne neuen init :)


    PS: Könnte man die Werbung nicht anhand der Auflösung überspringen ?

Jetzt mitmachen!

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