Le « Temps Réel » me manque

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 :

1 - lecture du Clip
1ière étape : lire le clip depuis de Disque pour le stocker en RAM Clic ➧ Grand

La vitesse du disque de stockage du clip est déterminante pour cette étape.

2 - décompression du Clip
2ième étape : Décompression du Clip. Clic ➧ Grand

La vitesse et le nombre de processeurs est déterminante pour cette étape.

3ième étape : l’étalonnage du Clip. Clic ➧ Grand

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.

Ca ne marche pas : 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’apporte le logiciel Resolve pour les limitations de chaque étape :

  1. Une suite d’image DPX ou un RAW trop lourd à lire ➧ Faire un Optimized Media ou mieux un Render Cache Source Clip (en Apple ProRes 4444XQ / DnxHR 444). Ils seront « plus légers »!
  2. Un RAW ou un H264/265 trop complexe à décompresser ➧ Faire un Optimized Media ou un Render Cache Source Clip en Apple ProRes 4444XQ / 422 HQ. Ils seront « plus simple à décompresser » mais plus lourd à lire (étape 1)
  3. Les effets sont trop complexe à calculer ➧ Passer le « Proxy Mode » en « Half Résolution » ou réduire manuellement la résolution du Projet
  4. 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é sur un Clip. 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.

4ième étape : Compression au format/Codec de sortie. Clic ➧ Grand

La vitesse et le nombre de processeurs est une fois de plus déterminante pour cette étape.

5ième étape : Ecriture des fichiers sur le disque d’export

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 :

  1. 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.
  2. Un (RAID 0°) SSD dédié à l’export pour ne faire qu’écrire dessus.
 

Laisser un commentaire

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