Ich habe die Streams untersucht und keine Pakete gefunden die da nicht hingehören. Mein Vermutung hat sich nicht bestätigt.
Gruss
zille
Posts by zillerbaer
-
-
- Welches Problem vermutet ihr und wie könnte ich es eingrenzen ?
Mir sind auch ungewöhnliche Sprünge z.b bei ntv aufgefallen. Siehe da. Allerdings nur im Bereich von Millisekunden. Kannst Du mir Aufnahmen mit dem Problem zukommen lassen?
-
Es gibt keinen Crash! VDR wird abgebrochen und kontrolliert beendet. Die Audio PTS ist die führende Clock. Darauf wird das Video synchronisiert. Das zu ändern muss ich erst mal durch denken.
-
Das auf die maximale Anzahl von Kanälen runtergemixt wird die die HW bereit stellt. Das wird aktuell schon so gemacht. Nur wenn der Treiber eine falsche Anzahl Kanäle zurück gibt geht das schief.
-
Das Hauptproblem ist der unsaubere HDMI Treiber. Bei der Abfrage mit wie vielen Kanälen er umgehen kann, behauptet der Treiber das er 6 Kanäle kann (HWChannels 6). Erst bei der Konfiguration streikt der. Bei sauber programmierten Audiotreibern wird automatisch auf die maximale Anzahl der Kanäle gemixt. Vielleicht machst Du mal ein Bugreport bei Raspi-Kernel?
Edit: Der Schalter AudioDownmix soll demnächst entfernt werden.
-
Jul 11 17:55:28 raspberrypi vdr: audio/alsa: set params error: Das Argument ist ungültig#012AlsaSetup: Channels 6 SampleRate 48000#012 HWChannels 6 HWSampleRate 48000 SampleFormat S16_LE
Die Konfiguration der Audioausgabe geht schief. Kann Dein HDMI Gerät 6 Kanäle wiedergeben?
-
Im Abstand einiger Stunden kommt im Audio MP2 PES Stream ein MPEG Packet Daten mit denen ich nix anfangen kann. Das schlimme (Bug) ist das softhddevice dann das vorhergehende MPEG Packet und das mir unbekannte Packet verwirft. Hier mal der Beginn eines Beispiels:
Erwartet wird aber ein MPEG Packet:
Weiss wer was das Packet beinhaltet? Kann das ignoriert werden?
Gruss
zille
-
Das geht schon seit geraumter Zeit nicht mehr.
Unter Gentoo, ohne systemd, funktioniert das.
-
Jetzt noch ein Problem mit der "Pause".
Das sollte mit dem heutigen Commit behoben sein.
Gruss zille
-
Im git gibt es eine neue Version in der das Problem behoben sein sollte. Auch das Umschalten geht jetzt flotter.
-
Da gibt es einen Bug in der Umrechnung der PTS. FFmpeg benutzt einen PTS in Abhänigkeit zur timebase. MMAL in microseconds (glaub ich). Da muss ich erst mal in die header kriechen. Da brauch ich ein bissel Zeit für. Das passiert auch bei normaler Wiedergabe wenn der Deinterlacer benutzt wird. Das das noch niemanden aufgefallen ist!
-
In Handauflegen und Ferndiagnose bin ich nicht gut. Aber es sieht nach fehlerhaften Aufnahmen aus. Nach dem PTS wird Audio und Video synchronisiert und der scheint nicht zu passen. Du kannst mir ja nochmal ein Schnipsel zukommen lassen.
Gruss zille
Edit: Wenn Du AV_SYNC_DEBUG im Makefile einschaltest siehst Du auf der Konsole wie synchronisiert wird.
-
In dem Fall wird kein PlayMode 0 von vdr geschickt. Im git gibt es eine neue Version in der das Problem behoben ist.
-
Ich denke, wenn CodecVideoOpen ein avcodec_alloc_context3 macht und decoder->VideoCtx noch zugewiesen ist, landet der alte AVCodecContext von decoder->VideoCtx doch im Niemandsland, oder kann der Fall nicht eintreten?
Das kann nicht passieren weil alle Threads mit StreamFreezed blockiert sind.
-
Schau mal in CodecVideoClose() da wird avcodec_free_context() gemacht. Wenn der Buffer freigegeben wird, muss er vorher nicht zurück gesetzt werden. Nur wenn das struct als leeres struct wieder benutzt werden soll.
Wofür braucht man das atomic_inc(&MyVideoStream->PacketsFilled);?
Damit wird die Queue um eins erhöht. Ist eigentlich nicht notwendig, aber da das erste Packet der Queue genutzt wird, ist es sauberer.
Gruss zille
-
Manchmal bleibt nach dem Springen das Bild an der angesprungenen Stelle stehen, und nur der Ton geht weiter.
Da hilft nur nach einem Sprung warten bis AV synchronisiert sind und dann den nächsten Sprung machen. Ist nervig, aber da hab ich schon lang dran gesessen und jetzt fasse ich das nicht mehr an.
Warum von hinten aufgerollt? Verstehe ich nicht.
Vergleiche doch mal die Lösungen.
-
ich habe eine Vermutung. Teste mal bitte das git.
-
-
Du kriegst aber auch alles kaputt!
Hier muss gdb ran. Dazu wird ein core file gebraucht. Mit:wird das freigeschaltet. Beim nächsten segfault wird ein core file geschrieben. Entweder schickst mir das zu oder:
Die Ausgabe von "bt full" brauche ich.
-
Wir müssen davon ausgehen, dass Alsa fehlerhaft ist.
Nö, Alsa lässt eine grosse Bandbreite zu was die Treiber können müssen. Die Alsa HW-Treiber sind problematisch.
"pcm state: XRUN" ist das Problem. Im git ist eine xrun recovery function hinzugefügt. Die Meldungen kommen im Log. Wenn mal Zeit ist muss ich unbedingt das Error handling in Ordnung bringen.
