Was ist FFMedia?
Die System-on-Chips der Rockchip RK3588-Serie verfügen über hervorragende Videokodierungs- und -dekodierungsfunktionen, insbesondere eine hervorragende Leistung bei der gleichzeitigen Mehrkanal-Videoverarbeitung. Bei der Entwicklung von Videoverarbeitungsanwendungen stoßen wir jedoch häufig auf Probleme wie allgemeine Frameworks wie Gstreamer und FFMPEG, die die Chipleistung nicht voll ausschöpfen, offizielle Original-APIs, die zu nah an der untersten Schicht liegen, hohe Lernkosten, lange Zyklen und einen hohen Entwicklungsaufwand.
Die Hauptkomponenten jeder Einheit sind wie folgt:
- Eingabeeinheit: Enthält Eingabeeinheiten wie RTSP, RTMP, WHEP, Kamera, Datei usw.
- Verarbeitungseinheit: Umfasst Hardware-Dekodierungs-, Kodierungs-, Bildverarbeitungs- und Inferenzeinheiten sowie andere Verarbeitungseinheiten, die die Hardwarebeschleunigung unterstützen.
- Ausgabeeinheit: Beinhaltet RTSP, RTMP, Whip, DRM-Anzeige, GB28181, Datei und andere Ausgabeeinheiten.
Funktionen und Features
Kernarchitektur
- Modulare Architektur: Das gesamte Framework übernimmt das Producer/Consumer-Modell und jede Einheit wird in die ModuleMedia-Klasse abstrahiert.
- Effiziente Speicherverwaltungstechnologie: Die Dateninteraktion zwischen Einheiten und Hardware wird mithilfe von Zero Copy implementiert.
Medienverarbeitungsfunktionen
- Formatunterstützung: unterstützt das Parsen und Kapseln gängiger Containerformate wie MP4/MKV/FLV/TS und gängiger Protokolle wie RTSP/RTMP/GB28181/WebRTC.
- Transkodierung und Verarbeitung: unterstützt Videotranskodierung, Zuschneiden, Spleißen, Wasserzeichen und andere Verarbeitungen.
- Streaming-Medienverarbeitung: unterstützt das Abrufen von Medienströmen aus Quellen wie Kameras und Netzwerkströmen zur Echtzeitverarbeitung, Weiterleitung und Speicherung.
Leistungsoptimierung
- Geringe Belastung und geringe Latenz: Optimieren Sie die Verarbeitung und Übertragung von Datenströmen umfassend, mit geringerer CPU-Auslastung und höherer Echtzeitleistung im Vergleich zu GStreamer und FFmpeg
- Effizientes Python-Modul: Nahtlose Interoperabilität zwischen C++ und Python wird durch pybind11 erreicht.
- Einheitliche Schnittstelle: Schützen und optimieren Sie komplexe zugrunde liegende Vorgänge, um Benutzern eine effiziente und einheitliche Schnittstelle bereitzustellen.
Plattformkompatibilität
- Anpassung auf Chipebene: unterstützt alle Rockchip-Maschinenmodelle unter der Firefly-Plattform.
- Systemunterstützung: unterstützt verschiedene Systemversionen wie Buildroot/Ubuntu/Debian.
Quellcode herunterladen
Quellcode abrufen:
-
git clone https://github.com/Firefly-rk-linux-utils/ffmedia_release.git
Entwicklungsschnittstelle
Alle Schnittstellen unterstützen C++- und Python-Aufrufe.
C++-Sprachparadigma:
-
auto rtsp_c = make_shared <modulertspclient>("rtsp://xxx"); -
auto ret = rtsp_c->init()
Python-Sprachparadigma:
-
auto rtsp_c = make_shared("rtsp://xxx"); -
auto ret = rtsp_c->init()
Typische Szenarien und Leistungstests
Testumgebung: ITX-3588J ITX-Motherboard
Live-Streaming mit geringer Latenz
Testen Sie die Wiedergabe des H265 1080p@30fps RTSP-Livestreams mit den folgenden Modulen:
- RTSP-Client: Es wird ein selbst implementiertes, leichtes RTSP-Clientmodul verwendet; das Abrufen eines Frames des Streams dauert etwa 0,03 Millisekunden.
- MPP-Dekodierung: Dekodierungsmodul basierend auf der MPP-Implementierung; die Dekodierung eines Frames dauert etwa 1,2 Millisekunden (im Mehrkanalmodus kann es bis zu 0,7 sein).
- DRM-Anzeige: Anzeigemodul basierend auf dem DRM-Framework; das Senden und Anzeigen eines Frames dauert etwa 0,9 Millisekunden.
Die Verzögerung von H265 (p-Frame-Serie ist sequentiell) und 1080P-Liveübertragungen lässt sich berechnen: Die Verzögerung vom Netzwerk bis zur Dekodierung des Datenstroms in den YUV-Rohdatenstrom beträgt etwa 1,3 Millisekunden. Die Bildschirmanzeige wird auch von der Bildwiederholfrequenz beeinflusst. Beispielsweise beträgt das Bildwiederholintervall von 60 Bildern pro Sekunde 16,667 Millisekunden, und die Anzeigeverzögerung lässt sich auf 0,9 bis 16,667 Millisekunden berechnen. Zusammenfassend beträgt die minimale Verzögerung einer 1080P-Liveübertragung etwa 2,4 Millisekunden.
Die Leistungsindikatoren sind in der folgenden Tabelle aufgeführt:
| CPU-Auslastung | Speichernutzung | Frame-Verarbeitungszeit |
| 1,0 % | 72 Millionen | 2,4 ms |
Der einfache Testbefehl lautet wie folgt:
-
./demo rtsp://xxx -d 0
Die Leistungsindikatoren der Testwiedergabe von 32-Kanal H265 1080p@30fps RTSP Echtzeit-Streams sind in der folgenden Tabelle aufgeführt:
| CPU-Auslastung | Speichernutzung |
| 23,5 % | 2,8 GB |
Der einfache Testbefehl lautet wie folgt:
-
./demo rtsp://xxx -d 0 -c 32
Transkodierung und Übertragung von Video-Streaming in Echtzeit
Testen Sie die Transkodierung des H265 1080p@30fps RTSP-Livestreams in einen H264 RTSP-Stream mithilfe der entsprechenden Module:
- RTSP-Client: Leichtgewichtiges RTSP-Clientmodul; das Abrufen eines Frames dauert etwa 0,03 Millisekunden.
- MPP-Dekodierung: Dekodierungsmodul basierend auf der MPP-Implementierung; es dauert etwa 1,2 Millisekunden, um einen Frame zu dekodieren (im Mehrkanalmodus kann es bis zu 0,7 Millisekunden dauern)
- MPP-Kodierung: Kodierungsmodul basierend auf der MPP-Implementierung; die Kodierung eines Frames dauert etwa 4,8 Millisekunden (im Mehrkanalmodus kann die Zeit bis auf 2,5 Millisekunden sinken)
- RTSP-Server: Leichtgewichtiges RTSP-Servermodul; das Übertragen eines Frames dauert etwa 0,1 Millisekunden.
Es lässt sich vorläufig schätzen, dass die theoretische Zeit, die für das Streamen und Transkodieren von Videobildern zum Streamen benötigt wird, etwa 6,3 Millisekunden beträgt.
Die Leistungsindikatoren sind in der folgenden Tabelle aufgeführt:
| CPU-Auslastung | Speichernutzung | Frame-Verarbeitungszeit |
| 1,0 % | 112 Millionen | 6,3 MS |
Der einfache Testbefehl lautet wie folgt:
-
./demo rtsp://xxx -e h264 -p 8554 -
# You can use demo or other software to pull the transcoded rtsp stream: rtsp://ip:8554/live/0
