Beiträge von jojo61

Zitat von MegaV0lt

Ich würde mir eine (zusätzliche) Einstellung wünschen, die Digitalton bevorzugt verwendet, falls vorhanden.

Das gibt es doch schon. Wähle einmal Dolby Digital aus und dann bleibt das über alle Kanäle und Aufzeichnung auch so.

Zitat von beta

Jul 25 22:57:35 CoreELEC kernel: 0: bufmgr_h264_remove_unused_frame, unmark error frame

Jul 25 22:57:35 CoreELEC kernel: 0: bufmgr_h264_remove_unused_frame, unmark error frame

Jul 25 22:57:35 CoreELEC kernel: 0: error 50 B frame, reset dpb buffer

Jul 25 22:57:35 CoreELEC kernel: 0: config_decode_buf fail (-1)

Das sieht mir aber eher nach einem Empfangsproblem aus. Da scheint etwas im Videostream defekt zu sein.

Zitat von Dr. Seltsam

Hast Du vielleicht eine neuere ffmpeg-Version als ich?

Nein ich habe auch die 4.2.7

Zitat von Dr. Seltsam

bedeutet doch, dass ohne Übergabe eines Parameters UseAudioSpdif 0 ist und dann nicht spdif_b sondern spdif genommen wird. Ist das dann bei mir DEV=2?

Erstmal wenn UseAudioSpdif gleich 0 ist dann wird eine 1 ausgegeben und damit Spdif_b genutzt. Ob das dann etwas mit den devices DEV=0 oder DEV=2 zutun hat kann ich nicht sagen. In der config nutze ich DEV=0 und UseAudioSpdif ist bei mir auch 0.

Ich habe mit und ohne Passthrough getestet und beides funktioniert bei mir.

Wenn ich es nur reproduzieren könnte..... Ich muss wohl doch mal schauen ob ich das Passthrough vereinfachen kann.

Ist bei mir alles gleich. Im Moment habe ich da leider auch keine Idee.

Bei mir geht es sogar auf einem X96Max und der hat nur einen 905X3 Prozessor.

Zitat von Dr. Seltsam

Unter welchem Kernel hast Du denn getestet?

Eine Verdopplung der Audio Buffer Size auf 672 oder Deaktivieren von Passthrough ändert übrigens nichts.

Ich teste mit dem 4.9.269 Kernel von Zabrimus unter chroot.

Die Audio Puffer Size ist hier leider nicht wichtig. Wenn das Audio zu spät kommt dann wird das Video immer wieder angehalten weil das Audio ja die Referenz ist. Passthrough wird leider auch durch den ffmpeg decoder geführt (obwohl nicht nötig) und bringt deswegen auch nix. Das könnte ich mal umbauen, war bisher halt nicht nötig und ist noch vom Original von Johns

Ich habe mir den Stream nochmal genauer angeschaut. Das einzige was mir aufgefallen ist, ist das das Video nur einen relativ kurzen Vorlauf von ca. 250ms gegenüber dem Audio hat. Wenn da ffmpeg etwas länger beim Audio decodieren braucht dann klappt es nicht mehr. Ist aber nur ein wilde Vermutung. Nutzt du den 5.1 Audio Stream oder den Stereo Stream und tritt es bei beiden auf ?

Den Kodi Kernel unter Ubuntu zu nutzen ist nicht so einfach. Da musst du dann auch eine eigene ramdisk dazu bauen. Ausserdem braucht der Kernel noch die common_drivers. Da habe ich viel aus Zabrimus VDR*Elec rüber kopiert bevor das lief.

Wie ich schon erwartet habe tritt das Problem hier nicht auf.

Aber evtl. kannst du mal in der Konfig schauen. Setze mal die Audio Puffer size auf 0 und das Audio/Video Delay auch mal auf 0.

Tritt dann das Problem noch auf ? Und tritt es auch beim abspielen einer Aufnahme auf ?

Hast du da ein TV mit 50Hz dran ?

Welche ffmpeg Version nutzt du. Das Audio ist da ja AAC und evtl. kommt da der decoder nicht mit. Da war doch vor kurzem etwas mit AAC und ffmpeg.

Das ist der cefbrowser aus deinem git Den hast du dann vermutlich nicht aktualisiert.

Ich baue den auf dem Zielrechner (Odroid).

Habe heute mal alles upgedated und nun habe ich einen Compilierfehler:

FAILED: cefbrowser.p/v8handler.cpp.o 
c++ -Icefbrowser.p -I. -I.. -I../subprojects/mINI-0.9.14/src -Isubprojects/cef -I../subprojects/cef -Isubprojects/cef/__CMake_build -I../subprojects/cef/__CMake_build -I../subprojects/spdlog-1.12.0/include -Isubprojects/sqlite-amalgamation-3420000 -I../subprojects/sqlite-amalgamation-3420000 -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -O3 -g -O3 -D_GNU_SOURCE -pthread -DPHTTPLIB_ZLIB_SUPPORT -DCPPHTTPLIB_OPENSSL_SUPPORT -MD -MQ cefbrowser.p/v8handler.cpp.o -MF cefbrowser.p/v8handler.cpp.o.d -o cefbrowser.p/v8handler.cpp.o -c ../v8handler.cpp
In file included from ../v8handler.cpp:6:
../browserclient.h:78:10: error: ‘void BrowserClient::OnRenderProcessTerminated(CefRefPtr<CefBrowser>, CefRequestHandler::TerminationStatus, int, const CefString&)’ marked ‘override’, but does not override
   78 |     void OnRenderProcessTerminated(CefRefPtr<CefBrowser> browser, TerminationStatus status, int error_code, const CefString& error_string) override;
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~
ninja: build stopped: subcommand failed.

Zitat von Dr. Seltsam

Oder soll die 1 im Code noch weg?

Mit der 1 habe ich nur ein paar unwichtige Teile für den Performance Test im Code tot gelegt

Deswegen gehört sie nicht ins Makefile.

Und noch eine Verbessung beim Audio playout. Bei einem Wrap des Ringpuffers wurde das Handling verbessert.

Das konnte in der alten Fassung zu Audio underruns führen.

Bei mir kann der ffmpeg den Parameter -mpegts_flags nit nicht. Wird das wirklich gebraucht ?

Ich habe noch einmal etwas am Umschalten geändert (Danke an Dr. Seltsam) und auch die 16:9 bzw. 4:3 Umschaltung verbessert.

An meinem X96 mit angeschlossenem DVB-C Dongle dauert das umschalten bei HD nun ca. 1.8 Sekunden und bei SD sogar nur ca. 1.2 Sekunden. Da ist das aktivieren von Fastswitch eher nicht mehr nötig

Falls es doch noch Probleme mit dem Umschalten gibt dann gebt bitte Feedback.

Ich mache euch einen Aufrufparameter. Das ganze im Switch script zu machen ist ja krampf.

Edit:

So ist im Git. Mit -w use-spdif wird nun das Spdif anstatt Spdif_b genutzt.

Wow was alles an so einer FFMPEG Version hängt. Ich bin derzeit nicht an meiner default Entwicklungsumgebung und komme erst am 3. August wieder nach Hause. Da kann ich gerne FFMPEG 7.0 installieren und die Korrekturen machen. Aber bis dahin müsst ihr euch leider gedulden.

Da ffmpeg 7.0 immer noch als experimental bei debian gelistet wird, werde ich wohl noch etwas warten damit.

Das softhddrm plugin braucht diese Version eh nicht und ich sehe es nicht ein immer dem letzten Schrei nachzulaufen.

Die Version 6.x von ffmpeg tut es auch.

Ja ein Parameter wäre eine Lösung nur ist mir unklar warum es beim Kodi immer mit Spdif_b läuft.

Paulaner Läuft es denn wenn man die Zeile ganz auskommentiert ?

Ich hasse es wenn dauernd die APIs von ffmpeg geändert werden. Ich schaue es mir an und installiere mir mal ffmpeg 7.0.

Nochmal ein update zum Wakeup on Lan.

Im Kernel 5.15 wurde die Schnittstelle zum Secure Prozess geändert. Da fehlen derzeit im Device Tree die dazugehörigen mbox einträge. Sehen kann man das in Log mit den Einträgen "mbox is NULL". Aber auch wenn ich die mboxes im DT nachtrage dann geht es nicht. Das könnte nun daran liegen das die neue Schnittstelle im U-Boot noch nicht vorhanden ist. Es scheint eine U-Boot Version 2015.01 und eine U-Boot Version 2019 zu geben. Leider kann ich die Version 2019 für den Odroid nirgends finden.

Da endet so langsam auch meine Kunst und ich weiss nicht mehr weiter weil es so gar keine Dokumentation von dem ganzen Verfahren gibt. Da hilft dann wohl nur warten bis die Kodi Leute auf das Problem stossen.