Ich teste mit DVB-T, dort funktionieren auch Sender, die über das Internet kommen, also per HbbTV eingeblendet werden.
Ich bin mir jetzt nicht sicher. Funktioniert etwas nicht oder funktioniert es so wie gewünscht?
Ich teste mit DVB-T, dort funktionieren auch Sender, die über das Internet kommen, also per HbbTV eingeblendet werden.
Ich bin mir jetzt nicht sicher. Funktioniert etwas nicht oder funktioniert es so wie gewünscht?
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;
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
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.
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:
rockchip2:~ # 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
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'http://media.tagesschau.de/video/2023/0729/TV-20230729-1736-2500.webxl.h264.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.45.100
Duration: 00:02:04.90, start: 0.000000, bitrate: 2190 kb/s
Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 2056 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
Metadata:
handler_name : VideoHandler
vendor_id : [0][0][0][0]
timecode : 17:27:28:14
Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
Metadata:
handler_name : SoundHandler
vendor_id : [0][0][0][0]
Stream #0:2[0x3](eng): Data: none (tmcd / 0x64636D74)
Metadata:
handler_name : TimeCodeHandler
timecode : 17:27:28:14
^C^C^CReceived > 3 system signals, hard exiting
rockchip2:~ # mc
Display More
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:
root@rockchip2:/tmp$ 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
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'http://media.tagesschau.de/video/2023/0729/TV-20230729-1736-2500.webxl.h264.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.45.100
Duration: 00:02:04.90, start: 0.000000, bitrate: 2190 kb/s
Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 2056 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
Metadata:
handler_name : VideoHandler
vendor_id : [0][0][0][0]
timecode : 17:27:28:14
Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
Metadata:
handler_name : SoundHandler
vendor_id : [0][0][0][0]
Stream #0:2[0x3](eng): Data: none (tmcd / 0x64636D74)
Metadata:
handler_name : TimeCodeHandler
timecode : 17:27:28:14
Output #0, mpegts, to '/tmp/ffmpegts_127.0.0.1_50001':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf60.3.100
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 2056 kb/s, 25 fps, 25 tbr, 90k tbn (default)
Metadata:
handler_name : VideoHandler
vendor_id : [0][0][0][0]
timecode : 17:27:28:14
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
Metadata:
handler_name : SoundHandler
vendor_id : [0][0][0][0]
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 183 fps= 25 q=-1.0 Lsize= 1221kB time=00:00:07.21 bitrate=1387.5kbits/s speed= 1x
video:1028kB audio:114kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 6.984312%
Exiting normally, received signal 2.
root@rockchip2:/tmp$
Display More
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.
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
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.
Jetzt habe ich nochmal ein Log mit "-l 4" vom VK_ENTER bis zum cefbrowser SEGV.
Das letzte Log endet genau mit VK_ENTER. Bis dahin sieht alles gut aus und es gibt keinerlei Auffälligkeiten.
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
} 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.
// 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
und das andere Mal
Keine Ahnung, was das bedeutet...
Hinweis: Ich habe testweise
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:
[2023-07-30 11:22:38.201] [cefbrowser] [debug] [requestresponse.cpp:334] Header by content: application/vnd.hbbtv.xhtml+xml; charset=UTF-8
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:236] RequestResponse::Open: http://itv.ard.de/ardstart/index.html
[2023-07-30 11:22:38.202] [cefbrowser] [debug] [requestresponse.cpp:259] RequestResponse::GetResponseHeaders:
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:264] ResponseHeader: Cache-Control -> max-age=0, no-cache, no-store
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:264] ResponseHeader: Connection -> keep-alive
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:264] ResponseHeader: Content-Length -> 2019
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:264] ResponseHeader: Content-Style-Type -> text/css
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:264] ResponseHeader: Content-Type -> application/vnd.hbbtv.xhtml+xml; charset=UTF-8
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:264] ResponseHeader: Date -> Sun, 30 Jul 2023 09:22:38 GMT
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:264] ResponseHeader: ETag -> d87b55519f348a7519b37cebb23d3c6b
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:264] ResponseHeader: Pragma -> no-cache
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:264] ResponseHeader: Server -> nginx
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:264] ResponseHeader: X-Powered-By -> PHP/8.1.17
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:270] RequestHeader: Accept -> text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:270] RequestHeader: Accept-Language -> de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:270] RequestHeader: Cookie -> ardstart=rbp*1*rangeid*202307*u*21u7rahlgbssq79rq179f8*v*3*ts*16906299
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:270] RequestHeader: Upgrade-Insecure-Requests -> 1
[2023-07-30 11:22:38.202] [cefbrowser] [trace] [requestresponse.cpp:270] RequestHeader: User-Agent -> HbbTV/1.2.1 (+DL+PVR+DRM;Samsung;SmartTV2015;T-HKM6DEUC-1490.3;;) OsrTvViewer;Chrome
[2023-07-30 11:22:38.202] [cefbrowser] [debug] [requestresponse.cpp:243] RequestResponse::Read: 65536, Size 2433, Offset 0
[2023-07-30 11:22:38.202] [cefbrowser] [debug] [requestresponse.cpp:243] RequestResponse::Read: 63103, Size 2433, Offset 2433
[2023-07-30 11:22:38.202] [cefbrowser] [debug] [requestresponse.cpp:309] RequestResponse::OnResourceLoadComplete: 1 -> 2433
[2023-07-30 11:22:38.202] [cefbrowser] [debug] [requestresponse.cpp:301] RequestResponse::Cancel: http://itv.ard.de/ardstart/index.html
[2023-07-30 11:22:38.205] [cefbrowser] [trace] [mainapp.cpp:327] BrowserApp::OnContextCreated
Speicherzugriffsfehler
Display More
Wenn ich alles unter root laufen lasse, funktioniert es ohne Probleme.
Grüße
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.
if (name == "StreamVideo") {
if (!arguments.empty()) {
startVideo = true;
const auto& urlParam = arguments.at(0);
auto url = urlParam.get()->GetStringValue();
if (!transcoderRemoteClient->StreamUrl(url)) { <===== Hier kann man eine fixe URL eintragen
// transcoder not available
ERROR("Unable to send request to transcoder");
return false;
}
if (!videoReset) {
vdrRemoteClient->StartVideo();
}
}
Display More
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.
Kannst du mal versuchsweise den Browser mit "-q" starten um das Shared Memory zu umgehen?
Das hat geholfen.
Browserupdate probiere ich nachher.
Grüße
kamel5
Das hat geholfen.
Okay. Dann liegt es tatsächlich an den Rechten. Verstehen tue ich es nicht.
Bei Anlage verwende ich 0666, das File selbst hat dann aber 0644.
Merkwürdig.
Don’t have an account yet? Register yourself now and be a part of our community!