[Tuto] Encodage Premiere en X264 x265, Nvidia ou AMD, VBR, CQP, AC3, MKV etc

Merci pour ton aide et...bonne nuit

 

Pourquoi quand je met exactement le même clip sur la time line de Da vinci Resolve ça passe nickel; alors que c'est saccadé sous première et inutilisable sous Vegas?

 

Je compte faire monter mon nouveau PC avec ce GPU:
MSI NVIDIA GeForce GTX 1660 Super Ventus XS OC Carte Graphique 6 Go GDDR6

Pourrait-il y avoir des raisons pour que CC et Voukoder la prenne mal en compte...Bernard tu me donnes des frayeurs parfois
J'ai regardé toutes les specs ça me parait pas trop mal.

Heu je fais pas du REC2020

Pour répondre à ta question Bernard c'est je pense que résolve utilise mieux ton CPU et ton GPU
Pas beaucoup d'autres explications

 

Bernard

Je n'ai pas de rush natif osmo pocket
Tu pourrais mettre 30s 1mn en téléchargement pour que je teste ?
oui j'ai vu un lien de téléchargement

 

C'était juste pour rappeler que les codecs de diffusion sont conçus dès le départ pour une lecture séquentielle (dans l'ordre, du début à la fin), c'est cette contrainte propre aux diffuseurs qui permet d'obtenir des taux de compression aussi énormes. Quand on travaille au Jog/Shuttle, ces clips sont une plaie, ça ne suit pas la cadence en lecture aléatoire dans les deux sens, même avec une RTX2080 (il y a aussi beaucoup d'accès disques avec ces fichiers).

Ces codecs sont très complexes. Pour optimiser certains usages on peut modifier des paramètres qui vont les rendre plus difficiles ou impossibles à interpréter selon l'implémentation du décodeur. C'est un peu le même problème que la fragmentation de l'écosystème Android, il y a moult versions et variantes dans la nature, et elles ne sont pas toutes compatibles entre elles, alors qu'elles se nomment toutes "Android". Il n'y a pas 1 compresseur et 1 décompresseur que tout le monde utilise quand on parle de H264 et H265, il y a de multiples implémentations et variantes, ce qui engendre tous les problèmes rencontrés. Un décodeur qui se veut exhaustif doit évoluer constamment pour tenir compte de plein de cas particuliers qui se présentent au fur et à mesure. C'est très différent des codecs intermédiaires qui eux sont parfaitement normés et très simples à implémenter car ils ne comprennent aucun paramètre sur lequel on peut agir. Un clip ProRes HQ se lira sur tous les logiciels qui supportent le ProRes HQ car le ProRes HQ reste du ProRes HQ, il n'y a pas de variantes possibles en fonction de l'appareil ou du logiciel qui les a générés.

PP ne savait pas lire les clips 10 bits issus du GH5 à sa sortie. Resolve non plus d'ailleurs. Pourtant c'était des clips compressés en "H264", et le 10 bits faisait partie des specs du codec (mais comme c'était très peu utilisé, le supporter était facultatif). Il a fallu attendre qu'ils modifient leur décodeur pour les supporter. C'est régulièrement le cas avec les appareils qui sortent et qui utilisent ces codecs à leur façon.

 

Post 603 sur ce même topic

 

Testé le 50p UHD de l'Osmo de Bernard sur ma config 2011
sans effet ça passe
Si je met le même à la sute avec un Fondue enchainée je vois pas la fondue et après ça saccade
Même si je mets pas de fondu arrivé au second rush (qui est le même car je n'ai que celui la) ça saccade si j'appuie sur espace pour arréter et rependre la lecture de la TL ça repasse en vert et c'est plus saccadé
Avec effet lumétrie ça saccade bien sûr !!
On verra ça bientôt avec 3900X et MSI gtx 1660 super ventus xs oc
CM MSI mpg x570 gaming plus
Je pense que j'aurais une config pour voir venir !

 

J'avais trouvé Bernard je l'ai écrit voir mon CR

 

Dis nous si c'est mieux avec ta nouvelle config pour moi c'est exactement pareil

 

Dans Davinci Resolve, les I/O sont CPU mais les traitements (le reste) sont GPU. (d'où l'importance du GPU)

MediaInfo

Code:

Débit                                    : 100,0 Mb/s
Sous-échantillonnage de la chrominance   : 4:2:0
Profondeur des couleurs                  : 8 bits

C'est très léger et du 8 bits.

 

Dommage que l'encodeur H265 très rapide de Résolve me donne un résultat aussi déplorable (artefacts incroyables) sinon je l'aurais adopté

 

Décodage et encodage 10 bits par le GPU ne sont accessibles qu'avec la version Studio.

 

Je sais...

 

Je viens de faire le test sous Resolve 16.1.2, et chez moi, bizarrement c'est l'inverse :
Le clips sans effet est parfaitement lu sous Premiere,
il saccade beaucoup sous Resolve, avec une utilisation très faible du CPU (< 8 %) et du GPU (6 %).
J'y perd mon latin !

Olivier

 

Je viens de faire un essai sous résolve...ma CV est occupée entre 20 et 60% et le CPU a 40% lecture sur le clip sans effet sans saccades...