Raspberry Pi 5 face au RK3588 : benchmark reproductible d’encodage H.264 en 4K

Voir sur YouTube · Ouvrir le tableau de bord interactif · Dépôt source

Ce projet compare trois méthodes d’encodage vidéo : FFmpeg/libx264 sur Raspberry Pi 5, FFmpeg/libx264 sur Seeed reComputer RK3588 Devkit et GStreamer avec l’encodage matériel Rockchip MPP sur RK3588. Les deux cartes disposent de 16 GB de RAM.

Le dépôt source contient les scripts de reproduction, les données CSV de chaque exécution et un tableau de bord HTML autonome en anglais et en chinois. Il permet d’examiner les compromis entre débit de traitement, utilisation du CPU par le processus et qualité de sortie dans ce test précis.

Résultats mesurés

Les valeurs suivantes proviennent du CSV récapitulatif du dépôt. Chaque méthode d’encodage a été exécutée trois fois avec les mêmes 300 images d’entrée chargées en RAM.

Dans cette configuration, RK3588 MPP a atteint environ 2.38 fois le débit de libx264 sur Pi 5. Les exécutions individuelles de MPP ont duré 10.93, 10.37 et 9.86 secondes : deux sur trois ont dépassé les 10 secondes du clip d’entrée.

Conditions de test

MPP est la méthode propre à Rockchip, utilisée uniquement sur RK3588. La méthode Pi 5 utilise ici l’encodage logiciel.

Reproduire le benchmark

Prérequis

Utilisez un environnement Linux de type Debian/Ubuntu avec git, bash, wget, unzip, sha256sum, ffmpeg, ffprobe et /usr/bin/time. Le script de préparation utilise également des utilitaires standard comme stat, df et cp. FFmpeg doit fournir l’encodeur libx264 et le filtre SSIM.

Pour l’encodage matériel sur RK3588, installez l’environnement GStreamer Rockchip/Seeed approprié avec gst-launch-1.0, l’élément mpph264enc et des pilotes MPP fonctionnels. Le script MPP fourni invoque sudo ; l’image système utilisée pour les mesures nécessitait des privilèges élevés pour accéder à /dev/mpp_service.

L’entrée brute occupe 3,732,480,000 octets (3.48 GiB), avec une copie supplémentaire en RAM. Le projet amont recommande 16 GB de RAM et environ 4 GB libres dans /dev/shm. Prévoyez aussi de l’espace disque pour le ZIP source, le MP4 extrait, l’entrée brute et les sorties encodées.

Préparer une entrée identique sur les deux cartes

Exécutez les commandes depuis une copie distincte du dépôt sur chaque appareil. La révision fixée correspond aux résultats documentés ci-dessus.

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

Le script de préparation télécharge le ZIP source de Blender, extrait le clip, vérifie sa taille en octets et son SHA-256, puis copie l’entrée NV12 vérifiée dans /dev/shm. Le SHA-256 attendu de l’entrée brute est :

d1e3403d6886a5472c7261dfe07a4149b941d1d7bdfa92d46f181dff381f5fd7

Arrêtez-vous si la vérification échoue. L’extraction de la source est une étape de préparation et ne doit pas être comptabilisée dans le temps d’encodage.

Exécuter la méthode d’encodage appropriée

Sur Raspberry Pi 5 :

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

Sur 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

Chaque script d’encodage effectue trois exécutions. Les sorties sont enregistrées dans output/, et les journaux de temps et de qualité dans logs/. Vérifiez le statut de sortie et le nombre d’images produites ; chaque sortie doit contenir 300 images. Le script de qualité indique le SSIM, le débit binaire et le nombre d’images décodées par rapport à l’entrée brute vérifiée.

Évitez l’enregistrement d’écran ou la surveillance simultanée pendant les exécutions chronométrées : ces opérations peuvent modifier les mesures. N’ajoutez pas à Git les vidéos téléchargées ni les fichiers bruts générés.

Explorer le tableau de bord et les données

Téléchargez website/index.html avec la fonction de téléchargement du fichier brut de GitHub, ou ouvrez-le depuis votre copie locale dans un navigateur de bureau. Le tableau de bord fonctionne hors ligne, propose l’anglais et le chinois, et inclut un mode de présentation 16:9. Son animation de course rejoue les temps médians mesurés ; elle n’effectue pas d’encodage en direct.

• README et notes de reproduction
• Résultats originaux de chaque exécution
• Résultats récapitulatifs

Limites et attribution

Ces résultats de trois exécutions portent sur un seul clip d’animation. Ils ne permettent pas de déterminer les performances pour les images de caméras, les charges de vidéosurveillance, la capture vidéo, le décodage HEVC ou AV1, ni la consommation électrique de l’appareil entier. La fréquence du CPU, le refroidissement, le firmware, le noyau et les versions logicielles peuvent influer sur la reproduction. Le SSIM est une mesure de similarité calculée, pas une évaluation visuelle humaine.

La source du test est Big Buck Bunny, Blender Foundation (2008), réédition Sunflower 4K, distribuée sous CC BY 3.0. Le script de préparation télécharge le ZIP original de Blender ; le film n’est pas inclus dans le dépôt du benchmark. Conservez l’attribution du film lors de la création de présentations ou de vidéos dérivées.