Ich bearbeite eine Reihe von Frames aus einem RTSP-Stream mit ffmpeg. Am Ende arbeite ich viel an diesen Frames, was bedeutet, dass ich nicht immer in Echtzeit ziehe. Wenn der Puffer voll wird, hängt der Prozess. Ich frage mich, ob eine der folgenden Lösungen machbar ist / behebt das Problem, und wenn ja, wie würde ich es implementieren mit den ffmpeg-Bibliotheken:
1) Gibt es eine Möglichkeit, den Puffer zu löschen, wenn ich jemals einen Punkt erreiche, an dem er hängt? (Ich kann feststellen, wenn es hängt, ich weiß einfach nicht, was ich tun soll).
2) Gibt es eine Möglichkeit, dass der Puffer die alten Daten überschreibt und immer nur die neuesten Daten liest? Es ist mir egal, wenn ich Frames verliere.
3) Ich habe bereits festgestellt, dass ich den Puffer mit: av_dict_set(&avd, "buffer_size", "655360", 0); sehr groß machen kann. Dies könnte eine Lösung sein, aber ich weiß nicht, wie groß / klein es sein muss, weil ich nicht weiß, wie lange der Stream für Video posten wird?
4) Ist das nur ein Fehler, den ich mit den ffmpeg-Leuten besprechen muss?
5) Etwas anderes habe ich nicht berücksichtigt?
%Vor%Ich habe den Code hinzugefügt, der das Programm zum Hängen bringt.
Sie könnten versuchen, Multithreading auszuprobieren. Jeder Frame wird von einem separaten Thread verarbeitet (verwenden Sie einen Threadpool).
Wenn Sie eine sequenzielle Bearbeitungsreihenfolge benötigen, müssen Sie eine Struktur (Warteschlange?) verwenden, um die Reihenfolge in ungeordneten Bearbeitungszeiten zu erhöhen.
Puffergröße ist eine Socket-Option, und unter der Haube ffmpeg kann auf ihrem Socket recv Anruf blockieren, wenn der Puffer voll ist. Nach dem Betrachten des ffmpeg-Codes scheint es, dass sie eine FIFO-Größenoption für einen Ringpuffer in reinen UDP-Streams haben, aber dies ist für RTP-Streams deaktiviert.
Um sicherzustellen, dass der Puffer niemals voll wird, würde ich alle pkt recv- und frame decode-Operationen in einem Thread ausführen und sie in meinen eigenen thread-sicheren Ringpuffer einspeisen. Ein Raspi sollte in der Lage sein, mit der Decodierung Schritt zu halten, aber wenn nicht, würde ich mich mit hardwaregestützter Decodierung befassen. Der Punkt ist, stellen Sie sicher, dass Ihr Demuxing und Decoding Echtzeitgeschwindigkeit beibehalten. Sie können die gesamte Größenänderung, Verarbeitung und das Schreiben von Frames in anderen Threads durchführen und die Größe des Ringpuffers entsprechend anpassen, um den Überlauf zu behandeln.
Es scheint, dass Sie versuchen, rohe Frames in Echtzeit zu schreiben, also ein Wort der Warnung: Offensichtlich spielen fps und frame size eine Rolle in der Geschwindigkeit von allem, aber ich vermute, dass Sie viele ausgelassene Frames sehen werden.
>