Raspberry Pi 5 und RK3588: Reproduzierbarer Benchmark für 4K-H.264-Encoding

Auf YouTube ansehen · Interaktives Dashboard öffnen · Quellcode-Repository

Dieses Projekt vergleicht drei Wege zur Videocodierung: FFmpeg/libx264 auf Raspberry Pi 5, FFmpeg/libx264 auf dem Seeed reComputer RK3588 Devkit und GStreamer mit Rockchip-MPP-Hardware-Encoding auf RK3588. Beide Boards verfügen über 16 GB RAM.

Das Quellcode-Repository enthält Skripte zur Reproduktion, CSV-Daten für jeden Durchlauf und ein eigenständiges HTML-Dashboard auf Englisch und Chinesisch. Damit lassen sich die Abwägungen zwischen Durchsatz, CPU-Auslastung des Prozesses und Ausgabequalität in diesem konkreten Test untersuchen.

Messergebnisse

Die folgenden Werte stammen aus der Zusammenfassungs-CSV des Repositorys. Jeder Codierungsweg wurde dreimal mit derselben, in den RAM geladenen Eingabe aus 300 Frames ausgeführt.

In dieser Konfiguration erreichte RK3588 MPP etwa den 2.38-fachen Durchsatz von libx264 auf dem Pi 5. Die einzelnen MPP-Durchläufe dauerten 10.93, 10.37 und 9.86 Sekunden: Zwei von drei überschritten die Dauer des Eingabeclips von 10 Sekunden.

Testbedingungen

MPP ist der Rockchip-spezifische Codierungsweg und wird nur auf RK3588 verwendet. Auf dem Pi 5 kommt hier Software-Encoding zum Einsatz.

Benchmark reproduzieren

Voraussetzungen

Verwenden Sie eine Debian/Ubuntu-ähnliche Linux-Umgebung mit git, bash, wget, unzip, sha256sum, ffmpeg, ffprobe und /usr/bin/time. Das Vorbereitungsskript verwendet außerdem Standardwerkzeuge wie stat, df und cp. FFmpeg muss den libx264-Encoder und den SSIM-Filter bereitstellen.

Installieren Sie für das Hardware-Encoding auf RK3588 die passende Rockchip/Seeed-GStreamer-Umgebung mit gst-launch-1.0, dem Element mpph264enc und funktionsfähigen MPP-Treibern. Das mitgelieferte MPP-Skript ruft sudo auf; im getesteten Systemabbild waren erhöhte Rechte für den Zugriff auf /dev/mpp_service erforderlich.

Die Roheingabe belegt 3,732,480,000 Bytes (3.48 GiB); eine weitere Kopie liegt im RAM. Das ursprüngliche Projekt empfiehlt 16 GB RAM und etwa 4 GB freien Speicher in /dev/shm. Planen Sie zusätzlich Speicherplatz für das Quell-ZIP, die extrahierte MP4-Datei, die Roheingabe und die codierten Ausgaben ein.

Identische Eingabe auf beiden Boards vorbereiten

Führen Sie die Befehle auf jedem Gerät aus einer eigenen ausgecheckten Repository-Kopie aus. Die festgelegte Revision entspricht den oben dokumentierten Ergebnissen.

git clone https://github.com/Seeed-Projects/raspberrypi-rockchip_benchmark_lab.git
cd raspberrypi-rockchip_benchmark_lab
git checkout b7758d37bdc2b20b1cdf85acc25a94c349d9fc13
bash scripts/00_prepare_input.sh

Das Vorbereitungsskript lädt das Blender-Quell-ZIP herunter, extrahiert den Clip, prüft die Byteanzahl und SHA-256 und kopiert die verifizierte NV12-Eingabe nach /dev/shm. Der erwartete SHA-256-Wert der Roheingabe lautet:

d1e3403d6886a5472c7261dfe07a4149b941d1d7bdfa92d46f181dff381f5fd7

Brechen Sie ab, wenn die Überprüfung fehlschlägt. Das Extrahieren der Quelle gehört zur Vorbereitung und darf nicht als Codierungszeit gezählt werden.

Passenden Codierungsweg ausführen

Auf Raspberry Pi 5:

bash scripts/01_cpu_encode.sh pi5
bash scripts/03_measure_quality.sh output/cpu_pi5_run2.mp4

Auf RK3588:

bash scripts/01_cpu_encode.sh rk3588
bash scripts/02_rk3588_mpp.sh
bash scripts/03_measure_quality.sh output/cpu_rk3588_run2.mp4
bash scripts/03_measure_quality.sh output/mpp_rk3588_run2.mp4

Jedes Codierungsskript führt drei Durchläufe aus. Die Ausgaben werden unter output/ gespeichert, Zeit- und Qualitätsprotokolle unter logs/. Prüfen Sie den Exit-Status und die Frameanzahl der Ausgaben; jede Ausgabe sollte 300 Frames enthalten. Das Qualitätsskript meldet SSIM, Bitrate und die Anzahl decodierter Frames im Vergleich zur verifizierten Roheingabe.

Vermeiden Sie Bildschirmaufnahmen oder gleichzeitiges Monitoring während der Zeitmessung, da diese die Messwerte verändern können. Nehmen Sie heruntergeladenes Filmmaterial und erzeugte Rohdateien nicht in Git auf.

Dashboard und Daten erkunden

Laden Sie website/index.html über die Raw-Datei-Downloadfunktion von GitHub herunter oder öffnen Sie die Datei aus Ihrer lokalen Repository-Kopie in einem Desktop-Browser. Das Dashboard funktioniert offline, lässt sich zwischen Englisch und Chinesisch umschalten und enthält einen 16:9-Präsentationsmodus. Die Rennanimation spielt die gemessenen medianen Laufzeiten nach; sie führt keine Live-Codierung aus.

• README und Hinweise zur Reproduktion
• Ursprüngliche Ergebnisse der einzelnen Durchläufe
• Zusammengefasste Ergebnisse

Einschränkungen und Quellenangabe

Diese Ergebnisse aus drei Durchläufen beziehen sich auf einen einzigen Animationsclip. Sie belegen keine Leistung für Kameraaufnahmen, Überwachungsaufgaben, Videoaufnahme, HEVC-Decodierung oder AV1 und keine Leistungsaufnahme des Gesamtgeräts. CPU-Takt, Kühlung, Firmware, Kernel und Softwareversionen können die Reproduktion beeinflussen. SSIM ist eine berechnete Ähnlichkeitsmetrik und keine menschliche visuelle Bewertung.

Die Testquelle ist Big Buck Bunny, Blender Foundation (2008), Sunflower-4K-Neuveröffentlichung, verbreitet unter CC BY 3.0. Das Vorbereitungsskript lädt das ursprüngliche Blender-ZIP herunter; der Film ist nicht im Benchmark-Repository enthalten. Behalten Sie die Quellenangabe des Films bei, wenn Sie daraus Präsentationen oder Videos erstellen.