VEGAS et la gestion de la RAM

[FONT=&quot]Gérer la RAM avec VEGAS[/FONT]
Récapitulation des divers réglages indiqués ça et là.
Ce qui est souligné est à cliquer ou écrire

Rappel : Trois sortes de mémoire.
1- D'abord la mémoire ultra rapide mais très chère qui trouve sa place directement dans le processeur et qui participe aux calculs : très peu de L1 (calculs de niveau 1), beaucoup plus de L2 (niveau 2) et de plus en plus de "grosse quantité" de L3. L'idéal serait évidemment que toute la mémoire y soit regroupée.
2- Ensuite celle dont il s'agit ici et qu'on nomme RAM (Random Access Memory), constituée de barrettes encliquées dans leurs emplacements réservés, généralement de deux à quatre. Cette mémoire est un lien rapide mais provisoire entre le processeur (1) et les lieux de stockage (3).
3- Enfin donc celle qui sert de stockage, la moins rapide des trois mais nécessairement la plus volumineuse. A la base constituée par les disques durs à plateaux (HDD), qui s'améliorent toutefois avec toujours plus de densité. L'évolution va vers les SSD plus rapides qui ne comportent aucune pièce en mouvement. Enfin les diverses sortes de Cartes Mémoires employées par les appareils périphériques. A mettre aussi dans ce groupe l'ensemble des cassettes à bande et les disques amovibles (CD, DVD et BD).

• [FONT=&quot]Préférences Internes[/FONT]

[FONT=&quot]Gestion de la RAM [/FONT][FONT=&quot]
Voir la capture d'écran sur :http://www.repaire.net/forums/sony-...ue-memoire-insuffisante-2.html/post1969968882

1 et 2 : Barre d’outils de Vegas Pro / Options / appuyer sur la touche MAJ (ou SHIFT, majuscule provisoire du clavier : 1ère de l'avant dernière rangée) + Préférences (bas de la liste des Options).[/FONT]
[FONT=&quot]3 : Apparition (en supplément) de l'onglet Interne pour TOUS les réglages possibles du logiciel.[/FONT]
[FONT=&quot]4 : La liste étant très longue, en bas de la fenêtre taper par exemple Memory.[/FONT]
[FONT=&quot]5 : Apparition des seuls items portant ce terme.[/FONT]
[FONT=&quot]6 : Choisir et cliquer sur le nombre ou le mot à changer : ici FALSE (faux) à changer, éventuellement pour TRUE (vrai) en comparant aux valeurs par défaut (colonne Default)[/FONT]
[FONT=&quot]7 : confirmer le choix : OK.[/FONT]

[FONT=&quot]Se passer de la Prévisualisation pendant l’encodage ? [/FONT]
http://www.cameravideo.net/forum/91671-post2.html

• [FONT=&quot]RAM allouée dans Options / Préférences / Vidéo[/FONT]

[FONT=&quot]Dans Vegas quelle que soit la quantité de RAM sur la machine, ne pas trop mettre de RAM dynamique.[/FONT]
[FONT=&quot]Vegas 32bit & OS 32 bit[/FONT][FONT=&quot] : 100 Mo[/FONT]
[FONT=&quot]Vegas 32bit & OS 64 bit[/FONT][FONT=&quot] : 100 à 500 Mo (plutôt 250)[/FONT]
[FONT=&quot]Vegas 64bit & OS 64 bit[/FONT][FONT=&quot] : Si 4Go de RAM, plutôt 1Go, voire moins (ça dépend aussi du montage, s'il est très gourmand ou pas en ressources).[/FONT] [FONT=&quot] 2Go si on dispose au moins de 6Go en barrettes. [/FONT]

• [FONT=&quot]RAM pour la prévisualisation[/FONT]

Exceptionnellement, dans des cas compliqués rien de plus commode qu'un rendu préalable d'une zone prédéfinie (boucle). Mais avec la RAM.
[FONT=&quot] * Pour créer un pré-rendu : [/FONT][FONT=&quot] Maj + M ou clic droit / [/FONT][FONT=&quot]Prérendre la vidéo de manière sélective[/FONT]
[FONT=&quot]Le pré-rendu mémoire est très pratique (et très rapide) si on veut juste vérifier une transition ou un bout d'effet en temps réel. Mais il est automatiquement détruit à la moindre modification dans la zone de boucle (point clé, effet, enveloppes, etc...)[/FONT] et il faudra le refaire.

[FONT=&quot]- [/FONT][FONT=&quot]Sélectionner la zone[/FONT][FONT=&quot] du projet pour laquelle on désire une prévisualisation. Si aucune durée n'est sélectionnée, tout le projet sera utilisé. [/FONT]
[FONT=&quot]- Dans le menu Outils / Prérendre la vidéo de manière sélective. [/FONT]
[FONT=&quot]La boîte de dialogue Prérendre la vidéo s'affiche.[/FONT]
[FONT=&quot]- [/FONT][FONT=&quot]Sélectionner un modèle[/FONT][FONT=&quot] dans la liste déroulante Modèle pour indiquer les paramètres à employer pour le rendu du fichier, ou cliquer sur le bouton Personnaliser pour créer un nouveau modèle.[/FONT]
[FONT=&quot]- Si nécessaire activer la case à cocher Étirer la vidéo à la taille de l'image de sortie (sans bandes noires) lorsqu’on effectue un rendu dans un format dont les proportions sont légèrement différentes de celles qui sont paramétrées dans le projet. Ceci empêche l'apparition de bandes noires en haut, en bas ou sur les côtés de la sortie. Cliquer sur le bouton OK. [/FONT]
[FONT=&quot]- Le processus de rendu commence et une boîte de progression s'affiche. À la fin du traitement, une barre s'affiche en haut de la barre temporelle pour indiquer chaque section rendue.[/FONT]
[FONT=&quot]- Les sections pré rendues ne comportent pas plus de 300 images (environ 40 Mo), 10 à 12 sec.[/FONT]

• [FONT=&quot]RAM suffisante pour remplacer le Fichier d’échanges[/FONT]

[FONT=&quot]Certains programmes ne se contentent pas de la mémoire système et font donc appel à la mémoire virtuelle (portion du DD, évidemment plus lent que la RAM). Si dans les bons cas de figure on gagne à contourner les temps d’accès assez longs des disques durs, dans les cas contraires, il faudra faire avec. A moins de viser un plus haut niveau RAM, ce qui permet aussi de gagner en performances bien que les écarts ne soient pas conséquents.[/FONT]
[FONT=&quot]En calculant les ressources mémoires nécessaires aux programmes avec une quantité de RAM de 8, 12 et 16 Go, on pourrait penser qu’il est possible de désactiver le fichier d’échange lorsque l’on a au moins 8 Go. C’est peut être une mauvaise idée : L’absence de fichier d’échange peut provoquer des erreurs système ou encore saturer la RAM de données corrompues.[/FONT]

[FONT=&quot]Quelle est la bonne quantité de RAM ?
[/FONT][FONT=&quot]La baisse du prix de la mémoire pousse à recommander[/FONT][FONT=&quot] un minimum de 8 Go de RAM. [/FONT]
[FONT=&quot]Du côté d’une configuration triple canal on peut considérer 6 Go comme un minimum. [/FONT]

[FONT=&quot]Peut-on se passer du fichier d'échange en vue d' accélérer ?
[/FONT][FONT=&quot]Mieux vaut s’abstenir de supprimer le fichier d’échange lorsque l’on possède moins de 12 Go de RAM, a fortiori sans avoir testé tous les programmes installées au préalable : le gain de performance obtenu ne vaut pas le risque de perdre des données.[/FONT]
[FONT=&quot]http://www.presence-pc.com/tests/RAM-quantite-23328/7/[/FONT]

Même si on a pléthore de mémoire RAM, il faut toujours avoir un fichier de pagination, car certains logiciels ont tendance à utiliser toute la mémoire disponible (ceux de montages vidéo par exemple, mais aussi les bases de données), il faut donc que Windows puisse swapper les autres applications quelque part.
Une valeur recommandée est 4GB, ce qui correspond au maximum pour une application 32 bits (ce qui est la majorité des applications classiques). A mettre de préférence sur un disque pas très actif, surtout pas sur le SSD. La présence du fichier d'échange (mémoire virtuelle/swap disk) est déconseillée sur les SSD parce que les opérations d'écriture/effacement diminuent leur durée de vie.
http://www.repaire.net/forums/pc-and-video/235262-ordinateur-ram-ecc-vs-non.html/post1970033957

[FONT=&quot]Utilité d'une grande quantité de RAM ?
[/FONT][FONT=&quot]Le passage à 12 Go ou 16 Go n’a de sens qu’en cas de contrainte d’ allocation de 4 Go (ou plus) à un RAM-disque (pour y placer les fichiers .temp) dans le but d’accélérer le traitement des fichiers temporaires. Ceci vaut avantageusement pour la compression de fichiers tels que l’ encodage vidéo ou encore le traitement d’images approfondi. [/FONT]

 

Merci pour ces infos et pour le récapitulatif. Très utile.

Curieux, chez moi avec Vegas Pro 10.0c, les touches SHIFT + B ne donnent rien !?!
Avec V9 c'est OK !

Un détail :
dans RAM allouée dans Outils / Préférences / Vidéo
remplacer Outils par Options.

 

1. Ben oui.
Tout honteux. Corrigé Options à la place d'Outils.
L’œil du Maitre !


2. Pour la prévisualisation en effet, sur VP10 Maj + M seul (corrigé aussi) ouvre la fenêtre multichoix Prérendre la vidéo sans précision sur le "stockage" du mini pré-rendu:
Effectuer le rendu de la zone de boucle uniquement
Comme un rendu normal avec Enregistrer en tant que.
Sans oublier l'onglet de personnalisation jusqu'en HD 1050p

 

VP 10 est décevant encore sur ce coup : pas de SHIFT B !?! Comme pour l'enregistrement à partir de carte mémoire Compact Flash !?!

Je crois que je vais râler en haut lieu !

Heureusement il nous reste le 0 du pavé numérique pour prévisualiser autour du curseur en cours de montage... mais sans calcul RAM... qui semble véritablement poser pb à Sony.

Je conserve précieusement VP9, aussi pour le rendu intelligent Mpeg2, qui lui aussi a disparu sur VP10 !

Le Tsunami n'arrangera rien ! C'est triste !

 

Salut topsub, quel plaisir !!!

Pas de souci ici avec le rendu en RAM (10b). Par contre pour le reste...

Je suis impatient d'avoir ton retour après le "je vais râler en haut lieu".

 

Bonjour,
Merci pour ce poste tres informatif.
Pour info, sur mon Vegas pro 10.0c, j'ai bien le rendu intelligent en mpeg2 (fichier issu de sony Z7) et shift+B fonctionne normalement.

 

Les voies de Sony sont impénétrables ! A moins que ce ne soient celles de Crosoft ?

On va placer ce post dans les discussions incontournables.

 

J'ai Vegas en Anglais, c'est peut-etre pour ca que ca fonctionne. Il me semble avoir lu qu'il y avait un probleme dans DVDA (fichier psd) qui etait seulement sur la version Francaise.

 

Agdi, merci pour cette synthèse.

Ca fait tellement longtemps que je lis des inexactitudes voir des grosses bétises sur des sites de neuneus gamerz que je profite de l'occasion pour rappeler quelques faits.Ce qui suit est volontairement simplifié à l'extrème mais les grandes lignes sont là. Ingés système et technophiles érudits, inutile de sauter au plafond...

Les bases de la gestion mémoire sur un système à temps partagé proposent un méchanisme permettant aux programmes d'utiliser la mémoire comme une ressource délivrée par le système d'exploitation. Contrairement à du code spécifique de bas niveau exécuté en contexte noyau, un programme utilisateur n'a pas à faire de distinction entre zone d'échange disque (swap) et mémoire vive (RAM). En fait, il n'en sait rien...

Processus, stricto sensu c'est l'image mémoire d'un programme chargé par le système et en cours d'exécution. En simplifiant à l'extrème un processus est découpé en 3 parties principales appelées sections:

1. le texte (.text) qui n'est autre que le code machine directement exécuté par le processeur. Code issu d'un compilateur puis lié statiquement ou dynamiquement (.dll sous winbeurk) à des libraires de fonctions spécifiques ou utilitaires et bien répandues.
2. les données (.data) qui regroupe grosso modo toutes les données volatiles du programme (variables, structures de données, etc) ainsi que les constantes.
3. la pile (.bss) qui est la zone qui sert de stockage temporaire durant les appels à des fonctions ou des services système. C'est là dedans que le code du programme met l'adresse du code à exécuter lors du retour de la fonction (directement interprété par le processeur) et les paramètres fournis à la fonction appelée.

On remarquera que d'un point de vue processeur, ces trois sections ont des propriétés intrinsèques: lecture et exécution pour .text, lecture écriture pour .data et .bss. Ces propriétés n'ont pas toujours été bornées, c'est comme ca que pas mal de programmes malicieux ont exploité des sections de code accessible en écriture (virus polymorphes et adaptatifs), idem pour .bss et .data considérés exécutables (les fameux buffer overflow et stack overflow).

De ces trois sections d'un processus, deux peuvent être modifiées. Comme le code est censé être invariant, pour plusieurs instances du même programme, la section .text va être partagée par plusieurs processus alors qu'il en est tout autre pour .bss. On économise donc de la mémoire vive en évitant de charger inutilement la section .text d'un programme et des librairies qu'il utilise et ce même si on l'a lancé 10 fois. Pour .data. c'est un peu plus subtil. Le postulat de départ dit qu'il faut économiser la mémoire, mais si on partage cette section entre plusieurs instances du même programme c'est le cafouillage assuré à la moindre modification du contenu. La méthode dite copy-on-write apporte une réponse: tant qu'un processus ne modifie pas le moindre bit de la section .data on garde le contexte d'exécution tel quel et à la première écriture la section est dupliquée puis le contexte d'exécution du processus mis à jour afin de permettre cette modification sans perturber les copains. Ceci est une description très approximative mais ca suffira pour le propos.

Thread, un processus léger. Le principe du thread c'est de partager .text et .data. Les processus légers ont pour avantages de limiter la consommation mémoire, de partager le même espace d'adressage que leur papa et ainsi minimiser le coût du passage d'un processus actif à un autre puisque au niveau système et processeur, le changement de contexte est réduit au minimum: seulement la section .bss et zou ! On minimise aussi l'occupation mémoire pour les données. Forcément, pour éviter les gags (pas de copy-on-write), cela demande une programmation rigoureuse en termes de synchronisation et d'accès aux données (sémaphores, exclusion mutuelle, queues). La dénomination thread est utilisée de manière totalement abusive et carrément erronée quand elle est confondue avec les cores des processeurs Intel. En informatique, on crée des threads depuis près de 20 ans sur des machines monoprocesseur dotées d'une seule unité d'exécution sans aucun problème et à l'époque une Alpha à 100MHz ou un Sparc enterrait, et de très loin, le pentium dernier cri gonflé à bloc. Le standard POSIX (p-threads) a été finalement publié en 1995 mais tournait déjà de facon plus ou moins expérimentale sur bien des systèmes.

Mémoire virtuelle, encore une dénomination fourre-tout et bien trop souvent employée à tord pour désigner le swap. Ca fait des décennies que les systèmes d'exploitation gèrent l'unité d'allocation de mémoire en pages, les pages sont des adresses virtuelles qui décrivent une zone de mémoire caractérisée par une adresse physique et une taille. Cette taille est constante et fixée par l'OS.
Pour économiser la RAM, un système à temps partagé gère les pages mémoire entre RAM et swap: un processus en état bloqué (attente utilisateur, E/S, etc...) n'a pas besoin d'accéder à ses données qui seront placés en zone de swap si un autre a besoin d'accéder à des pages de son espace mémoire qui auraient été déchargées sur le swap ou nouvellement allouées.
Sans entrer dans les détails, c'est le processeur qui signale au noyau qu'un processus tente d'accéder à une page mémoire qui est déchargée. On appelle cela un défaut de page (pagefault). C'est à ce moment là que le système va procéder à une élection selon le processus actif et les processus bloqués pour satisfaire tout le monde sans oublier de mettre à jour les tables utilisées par le processeur. Des pages mémoire de processus en état bloqué donneront de la place en RAM en étant stockées temporairement dans la zone de swap. Forcément, plus on a de RAM et moins on a de chances d'avoir des défauts de page en cours d'exécution et donc d'aller-retours entre le swap et la RAM. In fine, vu du processus, c'est toute la mémoire qui est virtuelle: l'espace d'adressage peut être supérieur à la quantité physiquement disponible et l'adresse d'une page n'est pas une adresse directe en RAM. La correspondance entre adresse mémoire virtuelle (page) et adresse réelle est gérée conjointement par le processeur (GDT/LDT chez Intel) et le système d'exploitation.

De ce qui précède, il découle qu'une adresse de mémoire (page) peut correspondre à un bloc sur disque ou une zone de mémoire physique à un instant t mais pas nécessairement le même à t+dt: copy-on-write ou défaut de page. Ceci est vrai pour toutes les sections et permet, entre autres, les migrations de processus entre différents processeurs sur une machine SMP voire une réincarnation de processus sur une autre machine en cas d'architecture répartie.

Supprimer le swap en supposant qu'on a assez de RAM pour s'en passer est une façon de prendre un ticket pour foncer droit dans un mur. Si, pour ne serait-ce que l'accès à un octet, un défaut de page est signalé, le noyau va tenter l'échange et si il n'a pas été codé en prévision d'une telle situation c'est le plantage assuré.

Ces principes sont vieux, universellement répandus sur les machines à architecture Von Neumann et les méchanismes processeur les rendant vraiment possibles chez Intel datent du 80386 même si les prémices étaient déjà là avec le 80186 et le 80286 il y a presque 30 ans.

Revenons à Vegas...
​

La "RAM" réservée pour l'exécution de Vegas n'échappe pas à ces règles. N'ayant pas les sources du logiciel je ne peux faire que comme les autres: des observations sur son comportement. La portion réservée pour la prévisualisation semble être immuable tant qu'on ne modifie pas ses propriétés ce qui est logique. Mais elle a un effet de bord sur les petites configurations et tout particulièrement en mode x86 (32 bits). Prendre beaucoup de mémoire pour la prévisu c'est s'offrir la possibilité de pré-rendus RAM plus longs au détriment de tout le reste: codecs, effets, plugins, tampons d'E/S fichier et interface utilisateur avec à la clé le risque d'avoir une application qui finit par se geler ou planter car la gestion de pool mémoire dans Vegas n'est pas 100% clean et encore moins idiot proof. Heureusement, toute modification de cette valeur ne nécessite pas de relancer Vegas ce qui permet d'adapter cette réservation en fonction du besoin. Par exemple, le host OFX qui permet l'utilisation de plugins temporels (time flow, etc) utilise cette portion de mémoire. Si elle est trop petite le plugin risque de ne pas pouvoir traiter correctement par manque d'images ou fonctionner dans un mode tellement dégradé et lent que ca en devient insupportable. Dans la même veine, les codecs aux algorithmes de prédicition sophistiqués comme H.264 seront reconnaissants d'avoir suffisamment de mémoire pour faire leur boulot ce qui implique un minimum réservé pour la prévisu...

Les threads de rendu, on serait tenté d'en mettre un maximum mais le constat est mitigé: en demander 16 sur un core duo ne rendra pas service bien au contraire. Il y a un certain consensus pour un thread par coeur au maximum. Théoriquement, augmenter ce facteur devrait améliorer les choses mais les constatations ont la tête dure. De là à dire que le noyau de winbeurk qui n'a jamais réellement brillé de ce côté là (performances dégradées si contention) est l'unique fautif serait une affirmation discutable sans vraie mesure de laboratoire ou examen du code: sur la même machine la différence de performance de la prévisu entre VP9 et VP10 est indiscutable. Le mieux est de procéder à des tests selon une méthodologie intellectuellement honnête.

De nos jours, la solution immédiate est évidente: Sandy Bridge, X6, 12G (voire plus) et 64 bits qui offriront un max de confort sans oublier de peaufiner les paramètres de son système et des applications pour en tirer la quintessence. Malheureusement, le 32 bits, il faut parfois y retourner à cause de plugins qui n'existent pas en 64 ou encore certains bugs de la version x64 de Vegas:

• Gérer judicieusement la quantité de mémoire réservée pour la prévisu.
• Faire attention avec le nombre de threads de rendu.
• Créer une zone de swap énorme pour éviter le plantage de rendu au bout de 15 heures: sur mon vieux 9400 de secours qui tourne avec 7/x64 et 4Go de RAM j'ai 12Go de swap qui m'ont permis d'encoder 50 minutes de TL FullHD avec moultes corrections de couleur en 11 jours. Sans une telle zone d'échange il n'y serait jamais arrivé...

Avec une telle zone de swap, après une bonne session d'édition sur une TL chargée, lors de l'arrêt de Vegas, le dur va se mettre à mouliner comme un fou en rendant Windows quasiment inutilisable pendant quelques minutes. C'est normal, il faut que le noyau gère tous les défauts de page de l'Explorer et des machins autour qui tout d'un coup sortent de l'état bloqué tandis que le noyau détruit logiquement toutes les pages allouées pour Vegas. Inutile de s'inquiéter, ce n'est pas un virus qui formatte...

Pour ceux qui se sentent à l'aise avec tout ca il y a une dernière astuce qui est très bénéfique: modifier un flag dans l'entête PE/COFF de Vegas et certaines de ses DLL afin de dire au système que l'espace d'adressage du processus x86 ne doit pas être limité à 2Go. Ainsi, Vegas disposera d'un maximum de 3Go sur un système x64 doté d'au moins 4Go de RAM. Cela revient à faire exactement la même chose que si SCS procédait à une édition de liens en utilisant l'option /LARGEADDRESSAWARE (je me demande encore pourquoi ils ne le font pas). 1Go de plus ce n'est pas énorme mais ca peut faire toute la différence.

Les outils pour faire ca: CFF explorer ou alors le SDK windows.


Quelques liens:

POSIX threads explained
OPERATING SYSTEMS: Intel’s View of Memory Management
OPERATING SYSTEMS: virtual memory
How to determine the appropriate page file size for 64-bit versions of Windows
Sony Creative Software - Forums - Vegas Pro - Some interesting memory observations and avchd...

Et pour ceusses à qui "pinoche tri-state" dit quelque chose, transformer une machine en baudruche à mémoire n'est pas la solution ultime: What every programmer should know about memory

 

Mazette !

Et dire qu'on vivait tranquillement à côté ...

 

Ca faisait longtemps que ca me grattait ces choses là...

Désolé, le coup est parti tout seul... oups

 

En me relisant...

C'est vraiment ambigu et peut induire en erreur. Une application x86 n'aura jamais plus de 3G et configurer une zone de swap conséquente n'y changera rien. Par contre ca peut aider: si plusieurs applications gourmandes sont actives, qu'une seule vorace tourne ou encore permettre à un programme x64 gourmand de finir sa tâche sur une machine sous-dimensionnée. Le long rendu a été fait en x64, ca plantait autrement.

Cependant les limites existent: demander à l'OS de swapper 1Go pour passer d'un processus à un autre est illusoire sur une architecture conventionnelle.

 

Preview RAM.
Des essais dans cette discussion sur le site de SCS.
Sony Creative Software - Forums - Vegas Pro - Video Messages

Conclusions : Lors des rendus (avant ça a parait inutile) prévoir des RAM Prévisualisations (visualisations à la limite de l'inutilité) assez basses, voire très basses. Tout va alors pour le travail du rendu. Logique.
- Options/préférences/vidéo/première ligne : mettre au minimum
- Dès que le rendu est terminé remettre la valeur antérieure.


A la base de bonnes installations et des vidéos en HD. Mais des rendus formats timbre-Poste pour envoyer sur Internet. Ce qui pour moi fausse les résultats, car des rendus en full HD ça change tout de même la donne pour qui veut vérifier en continu.

Tests à faire.

 

Quand j'aurais remonté une solution de montage digne de ce nom.

Au sujet des threads, j'ai récemment remarqué dans les options cachées que le max configuré par SCS est de 4 pour le binaire x86 et 16 pour x64. Là aussi, selon les codecs ou le mode de la prévisu il doit il y avoir des observations intéressantes à faire.

 

chez moi impossible de faire cette manip'
"6 : Choisir et cliquer sur le nombre ou le mot à changer : ici FALSE (faux) à changer, éventuellement pour TRUE (vrai) en comparant aux valeurs par défaut (colonne Default)"
je fais "appliquer" mais ça revient en FALSE.