Optimisation SSD et saccades timeline

Bonjour à tous,

Petit nouveau sur ce forum je viens vers vous pour éclairer ma situation.

Ma config :
Windows
Processeur : intel I7700K. Score : 11900
Carte graphique : Nvidia Geforce GTX 1080 (driver à jour)
SSD 256 go
Disque dur classique HDD: 500 go

Type de fichier vidéo utilisé : provenant du drone mavic 2 zoom
3840 x 2160
30 i/s ou 25 i/s
H264

Logiciel : adobe premiere CC 2020 installé sur le ssd de 256 go.

Voici ma situation :
En bon novice je réalise mon premier montage en plaçant tous mes fichiers (projet, rush, etc..) sur le HDD de 500 go (non ssd) en me disant que l’important c’est que le logiciel soit installé sur le ssd et que le reste n’importe peu. Je me rends alors compte que la manipulation de la timeline est assez saccadée. Je me fais alors la réflexion « c’est normal, tu manipules des fichiers 4K, c’est hyper gourmant et ton ordi commence à prendre de l’age). J’arrive néanmoins à faire mon montage sans trop d’encombres.
Souhaitant corser un peu mes montages (peut être utiliser after effect) et souhaitant avoir une utilisation plus fluide je décide de me renseigner sur le sujet.

Je me retrouve donc sur ce forum où je lis attentivement les posts concernant les optimisations des fichiers et sur les saccades de la timeline. Je lis le fameux post de ogt : "utilisation et optimisation des fichiers et dossier"
Je constate que le problème est récurent.

Les post confirment que ma config n’est pas un avion de chasse mais semble quand même pouvoir jouer (score recommandé pour de la 4k : 12000, mon score : 11900). Je me rend aussi compte qu’il est impératif d’utiliser un ssd pour certains fichiers (rushs, etc..). Il faut également activer le mode Cuda. (Activé d'origine dans mon cas)

Suite à cela je décide de réaliser le petit test suivant :

Réalisation d’un montage avec tous les fichiers (projet, rush, etc..) sur le ssd de 256 go. Même si j’ai bien lu qu’il ne fallait pas mélanger les « torchons des serviettes » et idéalement avoir plusieurs disques physique, je me dis qu’il devrait normalement y avoir une amélioration.

Résultat : aucun changement.

Ma question est la suivante :
Est-ce que j’achète un ssd de 500 go pour remplacer mon disque HDD de 500 go et optimiser ma gestion des fichiers ?
OU
Je laisse tomber et je travaille en mode proxy car ma config sera de toute façon pas assez puissante ?

J’avoue que par fierté personnelle je souhaiterais pouvoir utiliser la pleine puissance de mon pc quitte à acheter un peu de matériel (ssd) mais je suis ouvert à vos précieux conseils.

Par avance, merci à ceux qui prendront le temps de me lire.

Manu

 

Bonjour,

Il faudrait donner une image du Moniteur de Ressources de Windows, pendant la lecture de la timeline, en ayant soin de trier les colonnes importantes en ordre décroissant.
(inspirez vous de l'exemple donné à la fin de mon document).
Normalement avec votre configuration et une bonne répartition des fichiers et dossiers, vous devriez pouvoir avoir une lecture fluide.
(Cuda est bien activé dans les préférences du projet ?).

Olivier

 

Oui Cuda est bien activé (activé d'origine).
J'avais oublié de dire que j'ai 16 go de RAM


J'ai pris une capture d'écran du moniteur de ressource pendant la lecture de mon projet où j'ai mis tous les fichiers (sources, etc..) sur mon HDD (pas idéal du tout).

 

Du coup j'ai fait un second test avec tous les fichiers sur mon SSD.
Voici la capture d'écran. Temps de réponse bien plus faible selon le moniteur des ressources mais la manipulation de la timeline est toujours aussi saccadée.

 

Avec vos sources sur le HDD, un temps d'accès de 30 ms est largement excessif, mais on retombe sur des valeurs raisonnables quand vous les mettez sur le SSD.
Le CPU semble sous-utilisé, ce qui semble indiquer qu'il y a un autre goulot d'étranglement, mais là je ne vois pas quoi.
Avez vous défini un fichier de pagination (pagefile.sys) de taille suffisante ?(au moins égal à la mémoire réelle soit 16 Go) Premiere s'en sert pour faire du virtual I/O.
Le GPU est il utilisé pendant la lecture sur la timeline ? (voir avec GpuZ) : normalement oui, car il y a au moins la mise à l'échelle des fenêtres moniteur.

Remarque : il est connu que les clips des drone DJI sont toujours difficiles à traiter.

Olivier

 

Cette fois-ci j'ai réglé la taille du fichier de pagination à 16go (voir capture d'écran1).
J'ai refait le test sur mon ssd avec gpu-z (voir les autres captures) qui indique un gpu load aux alentours de 4%.
J'ai refait une petite capture du moniteur de ressource pour la route.

La manipulation de la timeline est toujours saccadée.

 

Bon, là je suis un peu à court d'idées.
Essayez de nous mettre un clip à disposition (par ex sur WeTransfer
pour tester sur nos configurations.

Olivier

 

Il est là le souci...

J'imagine que ces clips sont de même nature que sur l' OsmoPocket ….Et ...
ils sont "lourding" niveau codec sur des CPU pas trop puissant
@ Manu : essaye avec celui là pour voir >>> WeTransfer

 

Merci à vous deux de prendre le temps de m'aider.

J'ai essayé avec le clip de bcauchy. C'est pareil, les même saccades.

Voici un lien pour un de mes clips : WeTransfer

Du coup je me suis un peu renseigné sur le codec des drones DJI et avec les lags que ça engendre sur adobe. Effectivement c'est un problème très connu, voici un lien vers un post de forum qui explique bien la raison (nombre d'image entre les "I-frame" énorme, du coup le cpu+ram doivent déduire mathématiquement ce qu'il y a entre) :
Re: 4K Choppy playback - unable to edit - Adobe Support Community - 9020992

Sur le forum il conseille de travailler avec des proxy au format cineform qui est le plus adapté à premiere. J'ai fait le test et c'est vrai que ça fonctionne parfaitement.

Par curiosité j'ai fait un clip en 3840 x 2160 avec mon samsung galaxy s8. Et bien ça lag bien moins sur la timeline de premiere. Bon, c'est pas hyper fluide mais c'est quand même mieux que mon clip de drone.

Le seul truc qui me chiffonne c'est que si les clips de drone DJI sont vraiment compliqués à manipuler, mon processeur aurait dû montré des signes de faiblesse non ? Or, ça n'a pas l'air d'être le cas. On dirait que c'est autre chose qui bloque. Bref, ça doit surement être bien plus compliqué.


Petite question : si je travaille avec des proxy, est-ce que mes sources initiales peuvent être sur mon HDD sans impacter la fluidité de ma timeline ? (les proxy seront eux placé sur le SSD)

 

OK Vu, belle prise de vue ? et t'es vu
Bon, pour moi avec cette configuration, c'est pas du jeux,"presque" tout passe...
mais sur une configuration plus classique (celle de province ) ça rame !

Pas de soucis ​

 

Bon, comme Bertrand, j'ai maintenant une super configuration (CPU au moins 3 fois plus puissant que le 7700K) et ça passe comme une lettre à la poste, totalement fluide (le voyant pertes d'images reste vert).
Utilisation CPU 11%, utilisation GPU 26 %. CC2018 sous W7
Donc on reste dans les brumes (comme sur la vidéo) pour l'explication du problème (probablement difficulté pour décoder les longs Gops,... Heu pas si long que ça M=1 N=29).

Olivier

 

Pour confirmer cette hypothèse, peut être pouvez-vous m'envoyer un clip provenant d'une caméra classique pour que je puisse tester ?

J'ai essayé avec mon téléphone mais je ne suis pas sûr que ce soit vraiment représentatif.

 

Le forum met à disposition toutes sortes de vidéos natives prises avec des appareils différents :
Medias | Le Repaire
Le mieux est de télécharger et tester ces vidéos sur votre configuration, en ayant pris soin de contrôler leurs caractéristiques avec Mediainfo.
Ainsi vous pourrez vous faire une idée plus précise de ce qui passe et ne passe pas fluidement sur votre configuration.

Olivier

 

Un XAVC-S UHD 4:2:0 25p 8 bits (AX700) >>> WeTransfer

 

Merci pour le clip bcauchy.

Je viens de faire le test. C'est vraiment beaucoup plus fluide avec ton clip qu'avec ceux provenant de DJI. Rien à voir !

Cela confirme bien que les clips DJI sont plus demandant en ressource lors des montages.
Mon processeur passe pour des clips UHD "normaux" mais pas pour des clip DJI. J'utiliserai donc des proxy pour ces derniers.