Pour les personnes qui n’ont connu que ça, ca va leur paraitre bête. Le temps réel est la capacité du couple Logiciel/Station de travail à effectuer et montrer, en lecture de manière « instantanée », le travail demandé. Quoique vous fassiez dans votre logiciel favoris, la lecture est fluide. Ce n’est pas toujours le cas. Regardons pourquoi et les options proposées pour contourner les problèmes.
Cet article est le pendant avec Resolve de celui que j’avais écrit sur Final Cut Pro X .
Composants informatiques
Je prends l’exemple de l’étalonnage d’un plan dans Resolve :
La vitesse du disque de stockage du clip est déterminante pour cette étape.
La vitesse et le nombre de processeurs est déterminante pour cette étape.
La puissance du/des GPUs est déterminante pour cette étape.
Temps Réel pour un projet à 25 ips : les 3 étapes doivent êtres suffisamment rapide pour êtres effectuées les unes à la suite des autres en moins 1/25ième de seconde !!
Il suffit donc qu’un des 3 composants soit surmené (goulet d’étranglement) pour perdre le temps réel.
Pas de lecture fluide – pas de temps réel : Que faire ?
Comment contourner ces limitations : la réponse la plus simple est de changer le composant limité par un plus puissant. Pour le disque c’est facile (tour RAID ou SSD), pour le GPU et les CPU un peu moins, car potentiellement soudés sur la carte-mère. Mais le but de cet article est de voir les solutions qu’apportent le logiciel Resolve pour les limitations de chaque étape :
- Une suite d’image DPX ou un RAW trop lourd à lire
- Faire un Proxy Media (Resolve 17 et +) en Apple ProRes 4444XQ / DnxHR 444 (ou moins lourd)
- Faire Optimized Media ou mieux un Render Cache Source Clip en Apple ProRes 4444XQ / DnxHR 444
Ils seront « plus légers »!
- Un RAW ou un H264/265/H266 trop complexe à décompresser
- Faire un Proxy Media (Resolve 17 et +) en Apple ProRes 4444XQ / DnxHR 444
- Faire Optimized Media ou mieux un Render Cache Source Clip en Apple ProRes 4444XQ / DnxHR 444
Ils seront « plus simple à décompresser » mais plus lourd à lire (étape 1)
- Les effets sont trop complexes à calculer ➧
- Passer le Menu Lecture ➧ Timeline Proxy Mode ➧ Half/Quarter Résolution
- réduire manuellement la résolution de calcul de la Timeline/Projet
Historiquement, si on perd le temps réel, on fait un Render Cache de Séquence, c’est à dire un fichier facile à lire de tout le travail demandé « sous » la tête de lecture. C’est imparable (ça marche tout le temps), mais c’est long et absolument pas souple (Chaque changement nécessite un nouveau rendu ..long)
L’export : encore plus complexe
Le temps réel n’est malheureusement pas le plus complexe pour la station de montage/étalonnage, mais c’est l’export (ou le rendu)!! En effet, il y a deux étapes supplémentaires qui viennent s’ajouter à cette chaine.
La vitesse et le nombre de processeurs est une fois de plus déterminante pour cette étape.
La vitesse du disque d’export est déterminante pour cette étape.
Remarque : de plus la fréquence d’export peut être supérieure à celle du projet. La chaine de composant « tourne » à plein régime !!!
Ca marche moins bien que le temps réel : Que faire ?
Pour limiter l’impact de ces 2 nouvelles étapes dans la performance de la machine, il suffit d’avoir un peu de bon sens :
- Exporter une suite d’image DPX permet de ne pas solliciter les CPUs à l’export ➧ les fichiers sont alors lourd à écrire. Sinon choisir un Codec Intra plutôt que GOP.
- Un (RAID 0) SSD dédié à l’export pour ne faire qu’écrire dessus.