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

  • Auch mit anderem transcoder und ffmpeg klappt es nicht.

    Keine Ahnung, wo ich da ansetzen muss, anscheinend klappt es ja nur bei mir nicht... Falls ich mehr Infos zur Verfügung stellen kann, bitte melden.

    Kannst du mal im ffmpeghandler.cpp ein wenig rumspielen;

    Code
        streamHandler = new TinyProcessLib::Process(callStr, "",
            [](const char *bytes, size_t n) {
                DEBUG("{}", std::string(bytes, n));
            },
    
            [](const char *bytes, size_t n) {
                DEBUG("{}", std::string(bytes, n)); // <== Dies hier
            },
            true
        );

    Die Zeile 131 ist die Ausgabe von stderr, also irgendwas kommt von ffmpeg über stderr rein.

    Also entweder zum Test auskommentieren oder mittels printf ausgeben lassen oder std::cout oder wie auch immer.

    Vielleicht auch mal das 'n' ausgeben lassen. 0, negativ (size_t ist eigentlich unsigned) oder zu groß. Ich kann nur raten.

  • Hmm. Tagesschau habe ich heute gefixt. Mir ist auch aufgefallen, daß das OSD nur teilweise vorhanden ist und dann auch nur die Teile, die sich tatsächlich ändern.

    Diese Änderung hat scheinbar bei mir noch nicht geholfen. Der Effekt ist hier aber der Gleiche wie bei Dir. Wenn ich dann allerdings aus einem Vollbild-Video zurück zur Übersicht gehe, ist das OSD wieder komplett, bis zum nächsten Tastendruck...


    Reicht es eigentlich nach einem "git pull" dann im build Verzeichnis ein "meson compile" und "meson install" zu machen, oder muss man ab "git clone" alles neu machen.


    Ich wollte im Transcoder sowieso einbauen, welche Formate gesendet werden sollen.

    Das wäre toll, ist für mich im Moment aber auch nicht dringlich.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • rell

    Kannst du mal das Kommando direkt auf der Konsole ausführen um zu schauen, was passiert:

    ffmpeg -hide_banner -re -y -ss 0 -i http://media.tagesschau.de/video/2023/0729/TV-20230729-1736-2500.webxl.h264.mp4 -c copy -f mpegts /tmp/ffmpegts_127.0.0.1_50001

    Das ist das, was der Transcoder intern macht.


    Reicht es eigentlich nach einem "git pull" dann im build Verzeichnis ein "meson compile" und "meson install" zu machen, oder muss man ab "git clone" alles neu machen.

    Das reicht völlig aus.

  • Ich bin mir jetzt nicht sicher. Funktioniert etwas nicht oder funktioniert es so wie gewünscht?

    Letzteres.


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

  • Kannst du mal das Kommando direkt auf der Konsole ausführen um zu schauen, was passiert:

    ffmpeg -hide_banner -re -y -ss 0 -i http://media.tagesschau.de/video/2023/0729/TV-20230729-1736-2500.webxl.h264.mp4 -c copy -f mpegts /tmp/ffmpegts_127.0.0.1_50001

    Das ist das, was der Transcoder intern macht.

    Zuerst tut sich gar nichts:

    Dann habe ich gesehen, dass es in /tmp schon eine ffmpegts* gibt. Im mc wird die schwarz angezeigt, also als offene? Datei? Nachdem ich sie dann lösche, sieht es so aus:

    Jetzt muss ich es nochmal live testen, kann aber grad nicht ran. Melde mich nochmal.

  • Jetzt habe ich nochmal ein Log mit "-l 4" vom VK_ENTER bis zum cefbrowser SEGV. Ich glaube nicht, dass es am transcoder liegt, sondern am cefbrowser.

    Vielleicht kannst du was erkennen oder hast sonst einen Tip für mich, wo ich ansetzen kann.

    https://pastebin.com/raw/Kvr069VZ

  • Dann habe ich gesehen, dass es in /tmp schon eine ffmpegts* gibt.

    Die Datei ist ein fifo und wird vom transcoder vor dem Aufruf von ffmpeg angelegt. Der Reader-Thread liest daraus und ffmpeg schreibt da rein. Es kann also schon sein (eigentlich sollte das so sein), daß die Datei vor dem Aufruf von ffmpeg existiert.


    Irgendwas anderes ist noch falsch. Ich habe mir dein Log genauer angeschaut. Es gibt keine Fehlermeldung oder eine Meldung generell, daß das fifo nicht angelegt oder nicht les-/schreibbar ist. Dein Log sagt folgendes

    Code
    Jul 29 18:17:11 rockchip2 remotrans[12007]: [2023-07-29 18:17:11.606] [transcoder] [debug] [ffmpeghandler.cpp:131] frame=   78 fps= 26 q=-1.0 size=     408kB time=00:00:03.04 bitrate=1098.3kbits/s speed=   1x
    Jul 29 18:17:12 rockchip2 remotrans[12007]: HTTP error: Failed to read connection
    Jul 29 18:17:12 rockchip2 remotrans[12007]: [2023-07-29 18:17:12.068] [transcoder] [error] [ffmpeghandler.cpp:37] Unable to connect to browser. Abort transcoding...
    Jul 29 18:17:12 rockchip2 systemd[1]: cef.service: Main process exited, code=killed, status=11/SEGV
    Jul 29 18:17:12 rockchip2 remotrans[12007]: [2023-07-29 18:17:12.078] [transcoder] [debug] [ffmpeghandler.cpp:131] [out#0/mpegts @ 0x1cea60] Error writing trailer: Broken pipe

    Der Transcoder arbeitet, verliert aber die Verbindung zum Browser und der Browser scheint mit einem segfault abgeschmiert zu sein. Und damit geht alles den Bach runter.


    Ich habe eine spezielle Version von cef, die bei einem Fehler sehr viel bessere Ausgaben erzeugt, allerdings habe ich die nur für x86_86 und keine arm/aarch64 Version. Und da ist alleine schon libcef.so schon fast 4 GB groß. Also eher nix zum verteilen.

  • Ich habe das noch nie verwendet und weiß auch noch nicht, wie es funktioniert. Cef Applikationen sollen einen Crash Report schreiben können. Siehe hier.

    Ich werde mal lokal eine crash_reporter.cfg erstellen und falls der Browser crasht (hoffentlich nie) schauen, was da so angelegt wird und was man damit machen kann.

  • Hm, heute fällt mir nichts mehr ein. Schade dass gdb da nicht klappt, aber wenn ich cefbrowser mit Logs aufbohren wollte, was wäre deine Vermutung, wo es hapert? Es muss ja irgendwas mit der Verarbeitung des Videos zu tun haben? Wo wird im Code unterschieden zwischen Vollbild und gescaltem Video?

    Kann man irgendwo dem cefbrowser unterjubeln, dass er das Video nicht skalieren soll?

  • Es muss ja irgendwas mit der Verarbeitung des Videos zu tun haben? Wo wird im Code unterschieden zwischen Vollbild und gescaltem Video?

    Kann man irgendwo dem cefbrowser unterjubeln, dass er das Video nicht skalieren soll?


    Im v8handler.cpp werden die Javascript calls ausgewertet und da gibt es unter anderem die Blöcke

    Code
    }  else if (name == "VideoSize") {
       vdrRemoteClient->VideoSize(x, y, w, h);
    } else if (name == "VideoFullscreen") {
       vdrRemoteClient->VideoFullscreen();

    die jeweils dem VDR mitteilen, ob das Video skaliert werden soll oder ob es Fullscreen ist.

    Wenn du den vdrRemoteClient call auskommentierst, dann bleibt der VDR immer im Fullscreen mode. Aber der Browser skaliert das Video gar nicht, das machen die Ausgabedevices. Der Browser gibt nur die Koordinaten an den VDR.


    Edit:

    Du kannst auch im Browser in der mainapp.cpp einen Trace anschalten, der die Länge der TS Pakete loggt.

    Code
    // called by transcoder
    svr.Post("/ProcessTSPacket", [&vdrRemoteClient, &transcoderRemoteClient](const httplib::Request &req, httplib::Response &res) {
       ...
       // TRACE("ProcessTSPacket, length {}", body.length());
       ...
    }

    Aber das werden dann enorm viele Ausgaben. Aber vielleicht kann man ja was sehen.


    Edit2:

    Ich habe dem http server einen Exception Handler verpasst. Vielleicht gibt es da irgendwelche Informationen.

  • Der Exception Handler macht erstmal nichts. Aber vielleicht liegt es doch irgendwie am Stream. Hier der Vergleich eines Fullscreen Videos, das geht:

    https://pastebin.com/raw/jdh09T8c


    und hier eines, das im Fenster abgespielt wird und nicht funktioniert:

    https://pastebin.com/raw/JyeaF46z

    Die hat z.B. 2 Tonspuren, wenn ich das richtig sehe. Und einmal sehe ich

    Code
    compatible_brands: isomiso2avc1mp41

    und das andere Mal

    Code
    compatible_brands: mp42iso2avc1isom

    Keine Ahnung, was das bedeutet...


    Hinweis: Ich habe testweise

    Code
    }  else if (name == "VideoSize") {
       vdrRemoteClient->VideoFullscreen();

    eingestellt.

  • Wie könnte ich eine fake url von einem funktionieren Video statt des anderen in die Seite einschleusen? Nur um zu sehen, obs am Video liegt oder an der Seite an sich.

  • Für die, die das mal mit der TT6400 testen wollen, der angehängte Patch rüstet die Audiokonvertierung im remotetranscode nach.

    Gut funktioniert damit die ARD-Mediathek.

    Beim Öffnen und Schließen eines Menüs, während ein Video läuft, stottert das Bild und der Ton kurz, das ist wohl systembedingt.


    Für die ZDF-Mediathek reicht das noch nicht, da dafür auch noch das Video konvertiert werden müsste (AVC1).


    Grüße

    kamel5

  • Mal noch eine Frage:

    Mein VDR läuft unter root. cefbrowser und remotrans wollte ich unter einem normalen user laufen lassen. Sollte das funktionieren?

    Wenn ich das mache, bekomme ich einen Speicherzugriffsfehler vom cefbrowser:

    Wenn ich alles unter root laufen lasse, funktioniert es ohne Probleme.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Wie könnte ich eine fake url von einem funktionieren Video statt des anderen in die Seite einschleusen? Nur um zu sehen, obs am Video liegt oder an der Seite an sich.

    Im v8handler.cpp wird das StreamVideo der Seite ausgewertet und die extrahierte URL an den Transcoder gesendet. Die URL an den Transcoder kann man auf einen festen Wert einstellen.


    Ich komme nicht dahinter, was Ursache sein könnte. Wenn es Probleme gibt, hätte ich die im Transcoder oder dem Plugin erwartet, weil der Browser die eingehenden TS-Pakete einfach nur unverändert weiterleitet.

    Überlegt hatte ich auch schon. ob der vdrRemoteClient im v8Handler evt. null ist oder illegal. Aber der wird im Konstruktor neu erzeugt. Und wenn die IP/Port nicht stimmen, dann gibt es einfach keinen Connect.


    Wenn ich alles unter root laufen lasse, funktioniert es ohne Probleme.

    Kannst du mal versuchsweise den Browser mit "-q" starten um das Shared Memory zu umgehen? Es könnte vielleicht an den File Permissions liegen. Plugin/Browser/Transcoder kommunizieren nur über HTTP und das sollte unabhängig vom Users funktionieren. Dies Ausnahme ist das Shared Memory zwischen Browser und Plugin.

  • Ich habe den Browser aktualisiert:

    - mehr Log Entries

    - Versuch das Handling der transparenten Bestandteile (skaliertes Video) zu verbessern bzw. Vorbereitungen getroffen.

    - Sehr viel weniger Resize-Requests an den VDR, damit das Video skaliert wird


    Jetzt gefällt mir die Tagesschau auch wieder und der Videowechsel ist wieder geschmeidig. Es kann aber sein, daß etwas noch nicht so funktioniert wie es soll. Getestet habe ich ARD, ZDF, 3SAT, ARTE und Konsorten.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!