video first pts = fffe7000
Beim reset mit 0x10000 läuft das Video wieder mit einen PTS von vor dem wrap an und deswegen bleibt es dann wieder stehen.
Beim reset mit 0x1000 läuft es wieder richtig an
video first pts = 3a0e7
nur scheint mir 0x1000 zu klein zu sein weil die normalen PTS Sprünge schon in dem Bereich liegen. Ich frage mich nur was da bei dir anders ist als hier.
Der eigentliche Fehler ist im Kernel weil das Video bei einem negativen PTS Sprung stehen bleibt.
Ein pts wrap wird bereits in ProcessClockBuffer festgestellt (obwohl der Wert mit 0x100000 dort sogar 10x höher als in SendCodecData ist)
Da vergleichst du Äpfel mit Birnen 
Hier schaue ich mir die Differenz zwischen dem audio PTS und dem Video PTS an. Wenn einer davon wraped dann ist die Differenz irgendwo bei 0xffffffxx. Also deutlich über 0x100000. Der Wert hier ist völlig unkritisch.
In SendCodecData schaue ich 0x10000 in die Zukunft des aktuellen Video PTS und wenn dieser Wert wraped dann mache ich vorsichtshalber einen reset um den Buffer der schon im Kernel ansteht zu löschen. Jetzt müsste ich so lange alle video Daten wegwerfen bis ein PTS kommt der tatsächlich gewrapt ist. Nur ist das an der Stelle nicht so einfach weil die PTS da nicht chronlogisch kommen sondern springen weil da die Framereihenfolge noch nicht sortiert ist. Das geschieht erst nach dem dekodieren im Kernel.
Ich frage mich nur was da bei dir anders ist als hier.
Der eigentliche Fehler ist im Kernel weil das Video bei einem negativen PTS Sprung stehen bleibt.
Laufen Deine Maschinen mit vdr unter VDR*Elec?
Oder in CE mit Ubuntu chroot, aber Kernel von Zabrimus?
Oder CE mit Originalkernel und Ubuntu-chroot?
Welcher Kernel läuft laut uname -r?
Ich habe nach sowohl auf dem Odroid als auch der Tanix ein VDR*Elec image wegen der Kernel-Patches von Zabrimus, lasse vdr dort aber in einer Ubuntu chroot laufen. Das VDR*Elec image habe ich vor ein paar Monaten selbst gebaut und dabei den Kernelpatch, der Multidecode deaktiviert wieder rausgenommen - läuft also ohne Multidecode. (Seitdem gab es nie wieder Probleme bei der Rückkehr von Kodi zu vdr.)
Als Kernelversion wird 4.9.269 angezeigt.
Jetzt habe ich nochmal ein frisches VDR*Elec Build vom 15.10.23 ausprobiert, diesmal läuft vdr direkt in der CE Umgebung. Wiederum friert das Bild an genau der gleichen Stelle ein. Angezeigte Kernelversion ist auch 4.9.269. Nun bin ich ratlos.
Jetzt habe ich mal versucht, die ts-Datei der vdr-Aufnahme direkt in Kodi abzuspielen. Die Wiedergabe läuft sauber ohne zu stocken über die Stelle hinweg!
Aufgrund der guten Rückmeldungen hier, habe ich mir auch einen Odroid N2+ zugelegt. Habe dann das System wie im ersten Post und im GIT beschrieben installiert und muss sagen, dass ist bisher das VDR-System, dass am schnellsten aufgesetzt ist und ein 1A Bild liefert (sorry, teste gerade nur HD - will nicht wissen, wie UHD aussieht). Folgendes fällt mir auf:
jojo61 : sehr gute Arbeit, der unscheinbare Odroid macht ein geniales Bild. Könnte meine Client-Konfiguration werden.
MrJoe
Du solltest in den softhdodroid-Plugineinstellungen die standardmäßig leider deaktivierte Option Fast Channel Switch aktivieren.
Ist in den Plugineinstellungen unter Audio evtl passthrough aktiviert? Mal mit und ohne testen. Wenn an, dann auch für die einzelnen Tonformate aktivieren.
Du betreibst das ganze noch direkt unter Ubuntu mit dem Kernel von Hardkernel? Das ist eigentlich nicht mehr die empfohlene Methode. Es gibt im wesentlichen zwei Fraktionen:
VDR*Elec von Zabrimus (vdr direkt unter Coreelec) oder CoreElec als Betriebssystem mit einer Ubuntu-chroot-Umgebung für vdr. Für letzteres gibt es ein Installationsscript von beta68. Ich würde unbedingt beides mal ausprobieren und vergleichen.
Du betreibst das ganze noch direkt unter Ubuntu mit dem Kernel von Hardkernel? Das ist eigentlich nicht mehr die empfohlene Methode. Es gibt im wesentlichen zwei Fraktionen:
VDR*Elec von Zabrimus (vdr direkt unter Coreelec) oder CoreElec als Betriebssystem mit einer Ubuntu-chroot-Umgebung für vdr. Für letzteres gibt es ein Installationsscript von beta68. Ich würde unbedingt beides mal ausprobieren und vergleichen.
Ja, ich bin noch mit dem Standard Ubuntu und Kernel von Hardkernel unterwegs. Beide Hinweise waren hilfreich. Umschaltzeiten sind nun auch bei ca. 1s und Ton gibt es auch. Dank dir schonmal dafür.
Ich hoffe die Frage ist nicht zu doof: was ist der Vorteil der 2 Alternativen ggü. der Ubuntu Basis (ausser vermutlich eine Kodi-Unterstützung)?
Ich hoffe die Frage ist nicht zu doof: was ist der Vorteil der 2 Alternativen ggü. der Ubuntu Basis (ausser vermutlich eine Kodi-Unterstützung)?
Ja, in erster Linie Kodi.
Die CoreElec-Leute haben aber eine Menge Patches zur Optimierung für Videowiedergabe an ihrem Kernel vorgenommen. Niemand anders kennt die internen Geheimnisse der amlogic-Boxen so gut. Wenn es Dir nur um vdr geht, würde ich sagen, warte ab, ob irgendwelche Probleme auftreten. Es ist aber immer gut, einen Vergleich zu haben. Deshalb würde ich die anderen Varianten auch mal probieren. Dafür kannst Du ja eine SD-Karte nehmen.
es friert leider genauso ein.
Brauchst Du von einer bestimmten Code-Stelle eine Logausgabe? Die printf-Aufrufe laufen nicht in journalctl, deshalb müsste ich die durch Debug-Aufrufe ersetzen. Im Moment wird an der Stelle, wo es hängen bleibt, gar nichts geloggt, auch nicht vom Kernel. Ein paar Sekunden nach dem Hänger kommt nur
Okt 19 11:46:45 CoreELECTanixTX3 kernel: asoc-aml-card auge_sound: S/PDIF[1] Playback disablesoll ich den in ProcessClockBuffer mit if 0 deaktivierten Bereich aktivieren, um auch dort den printf bzw. eine Debug-Meldung zu erhalten?
Ich habe Dir mal ein Log angehängt. Die Wiedergabe startet jeweils mit replay /srv/vdr/video.00/2023.10.11-22:00-Wed/2023-10-11.21.58.3-0.rec. Ich finde keinen Logeintrag für einen erkannten wrap.
horchi ja, ich habe die 20.04 von der odroid-Seite mit apt update und apt upgrade aktualisiert - sonst nichts gemacht.
Dr. Seltsam Kodie könnte mittelfristig auch ein Thema sein, somit ein Grund mehr, die @Elec-Distributionen mal auszuprobieren. Gibt es kurzgefasst einen klaren Vor-/Nachteil bei den Varianten?
Ich finde keinen Logeintrag für einen erkannten wrap.
Du hast zu früh gestoppt. Der PTS war schon bei fffdc740 und bei ffffffff ist dann der wrap.
Da kommt nicht mehr. Ich habe die Wiedergabe mehrere Sekunden nachdem das Bild bereits eingefroren war beendet. Das sieht man jetzt im Log:
Okt 19 19:44:22 CoreELECTanixTX3 vdr[4195]: pts PTS 0x01fffdc740 0x00fffd87f8
Okt 19 19:44:26 CoreELECTanixTX3 vdr[4195]: [4431] non blocking file reader thread ended (pid=4195, tid=4431)Neues Log anbei
Don’t have an account yet? Register yourself now and be a part of our community!