blog.bressure.net

Carnet professionnel d'un informaticien

Application, Paramétrage

Rendu en grappe avec Cinelerra

admin

Cinelerra est une application de montage vidéo bien connue du monde du libre et que j’utilise depuis très longtemps. Le temps de rendu ont tendance à s’allonger au fil des années avec des algorithmes de compression de plus en plus performants mais gourmands en ressources comme le h265 ou HEVC. Il m’est arrivé plusieurs fois au bout d’une heure de rendu constater un défaut et devoir repasser une heure à refaire le rendu. L’utilisation de plusieurs machine de rendu est une fonctionnalité que vais mettre en œuvre pour la première fois afin de gagner en temps.

Espace partagé

Les PC de rendu doivent accéder aux données que sont le projet, les fichiers sources (vidéo, audio, image) et les sorties (fichier de rendu final, fichier et optionnellement fichiers de rendu temporaire en tâche de fond): sur un même espace. Plus précisément ces données doivent être accessible depuis le même espace de nommage quel que soit le nœud de rendu. Un montage NFS par exemple.

Ainsi sur le PC d’édition, je travaille dans /home/thierry/cinelerra. Ce répertoire devra également exister sur les autres nœuds. Donc sur le PC de rendu distant, ce répertoire sera un montage NFS vers le répertoire local du PC d’édition.

Pour la mise en œuvre après avoir installer les paquets NFS adéquats:

Processus cinelerra

Sur chacun des PC de rendu il faut lancer cinelerra en démon via l’option -d suivi du numéro de port d’écoute. Le processus de rendu peut être décomposé en 2 partie: la génération du montage (effets de transition, ajout des sous-titre etc) et la génération du fichier final avec son encodage (video et son). L’encodage (avconv ou ffmpeg) pur peuvent tirer partie des capacités multh-thread du CPU mais al documentation de cinelerra propose de répartir le tâches sur autant de cœurs disponibles.

Je vais utiliser les 2 PC: celui d’édition qui possède 4 coeurs physique soit 8 cpu logique (avec Hyper-Thread) et le PC de rendu qui possède 8 coeurs physiques soit 16 cpu logiques Hyper-Thread. Je vais donc lancer 8 processus cinelerra sur le PC d’édition et 16 sur le PC de rendu, en utilisant un commande du type

cin -d 12000

Afin d’automatser cette manipulation je me suis fait un script pour démarrer et stopper les démons cinelerra depuis ma machine d’édition.

!/bin/bash
#
manage cin backgroud render
#
if [ $# -ne 1 ]; then
echo "il faut un argument soit 'stop' soit 'start'"
exit 1
fi
command=$1
RENDER_CLIENT=perso.bressure.net
case "${command}" in
"start")
echo "start render"
# start renderer on remote host
echo " on remote"
ssh thierry@${RENDER_CLIENT} sudo mount 192.168.0.42:/home/thierry/cinelerra /home/thierry/cinelerra
for i in seq 10200 10215
do
ssh thierry@${RENDER_CLIENT} "cin -d $i > /dev/null 2>&1"
done
# start renderer on local host
echo " on local"
for i in seq 12000 12007
do
cin -d $i > /dev/null 2>&1
done
;;
"stop")
echo "stop render"
# stop renderer on remote host
echo " on remote"
PIDS=ssh thierry@${RENDER_CLIENT} ps -ef | grep "cin -d" | grep -v "grep" | awk '{print $2}'
for un_render_pid in $PIDS
do
echo "killing $un_render_pid"
ssh thierry@${RENDER_CLIENT} kill $un_render_pid
done
ssh thierry@${RENDER_CLIENT} sudo umount /home/thierry/cinelerra
# stop renderer on local host
echo " on local"
PIDS=ps -ef | grep "cin -d" | grep -v "grep" | awk '{print $2}'
for un_render_pid in $PIDS
do
echo "killing $un_render_pid"
kill $un_render_pid
done
;;
*)
echo "commande non reconnue" >&2
exit 2
;;
esac

Station d’édition

En suivant la documentation on ajoute les instances cinelerra démons. Dans mon cas 16 sur le PC distant et 8 sur le PC local. Il faut aller dans le menu Configiration > Préférence puis dans l’onglet Performances

Sur la même page on peut avantageusement renseigner chemin de rendu temporaire en tâche de fond avec une valeur sur l’espace partagé. Ainsi les processus cinelerra de rendu vont être sollicités pour le rendu en tâche de fond. Cela va rendre l’expérience d’édition plus confortable en ayant en direct un prévisualisation du rendu final.

Test

J’ai pris un petit projet de 1min20 avec des transitions et des titres. La longueur du projet doit beaucoup jouer sur le gain car le temps d’accès par NFS est un surcoût d’autant plus que mon réseau domestique est limité. En effet des fichiers sources en format peu compressés ou de longues durées peut amener à partager en NFS plusieurs dizaines ou centaines de mega-octet. Je verrai à l’usage.

Pou ce qui est de mon test, un rendu témoins en local sur la station d’édition avec un paramétrage à 8 cpu (4 cœurs,  2 thread par cœur) prend 2min10. Un rendu en grappe avec un total de 24 cpu (12 cœurs, 2 thread par cœur) prend 35 sec.


Comme je l’indiquait la phase de compression pur doit utiliser la présences de cœurs multiples donc il se peut bien qu’en utilisant moins de démon pour laisser plus de cœurs disponibles lors de l’encodage on améliore les performances. Cependant la méthode brute que j’ai appliquée en utilisant un démon par cpu logique me donne déjà satisfaction : fois 3 en nombre de cœurs et division par 4 du temps de rendu !

Tags:

Comments

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Back to top