Fredouillelafripouille

oups...

Merci pour le lien, Noël, très intéressant. EDIT : à noter que les OS récents (à partir de seven pour windows) reconnaissent automatiquement le type de DD et s'adpatent en excluant d'office les SSD des défragmentations automatiques.

Salut, Concernant la défragmentation, il ne faut jamais la faire sur un SSD. 1) parce que ça ne sert à rien pour un SSD : le but de la défrag est de déplacer les "morceaux de fichiers" sur le (H)DD pour qu'ils soient regroupés sur les plateaux, de cette manière, la tête de lecture n'a plus (ou "a moins") de d'aller-retours à faire pour lire l'intégralité d'un fichier. Donc moins d'usure et lecture plus rapide. Un SSD n'ayant pas de plateaux ni de tête de lecture, cela ne sert à rien pour son cas. 2) une défrag sur un SSD va se résumer à faire des écritures supplémentaires, donc une usure inutile... pour rien. Ce n'est sans doute pas la mort, en termes d'usure, mais vu que c'est vraiment complètement inutile... ++ Fred

ok ça roule. Merci pour le retour.

Heuuuu... J'avoue que je ne travaille qu'en CF, eût égard au matériel que j'utilise, du coup... Il me semblait qu'on pouvait trouver des SD sans le "lock" mais j'ai peut-être dit une connerie, oui

Je ne suis pas sûr de comrpendre ce que tu veux dire, ici. Deux cas, envisagés : tourné en 50p, encodé en 25p en "dropant" (éliminant) une image sur 2. Dans ce cas, tu ne gagnes strictement rien par rapport à un fichier d'origine en 25p. Je dirais même que tu y perds en fluidité car tu ne pourras peut-être pas shooter avec la vitesse d'obturation au 1/50s, en 50p (ça dépend des firmwares), qui est la vitesse te donnant le meilleur rendu des mouvements pour une vidéo en 25p (au final). tourné en 50p et ralenti d'un facteur 2 pour ramener à un 25p "2x plus long" que le rush d'origine. Là, ok (par contre, je ne sais pas si l'idéal est de filmer au 1/100 ou le plus proche possible du 1/50, dans ce cas... Je dirais au 1/100, mais sans garantie). Le problème de l'AVCHD reste évidemment entier : quels que soient les réglages utilisés, si le traveling est trop rapide, ça saccadera de toutes façons à l'affichage à cause du codec...

Il y a qqes années, il me semble que les cartes SD étaient effectivement bcp plus "fragiles" que les cartes CF, qui étaient alors le format de stockage dit "pro". Actuellement, la fiabilité est similaire, je crois, et surtout, le coût bien plus faible. A éviter par contre : les cartes avec des verrous en écriture. En général, c'est le truc qui pète bien avant d'avoir des problèmes avec le reste de la carte. Et si ça pète en position "protection en écriture", ...

oui oui ! Tu as juste oublié de mettre en gras la fin de la phrase ! (la partie la plus importante ou presque !)

En fait, il semblerait bien qu'à moins de tomber sur un SSD défectueux, tu peux bien écrire dessus tranquilloupdt une bonne dizaine d'année avant d'avoir de réels problèmes (j'avais lu un test effectué par une rédac, mais je ne sais plus d'où sortait l'article. Peut-être 01Net... ?). Partant du principe qu'une config est en général renouvellée plus rapidement que ça, ce n'est pas tellement gênant. (évidemment, c'est à tempérer car on parle de stockage : s'il y a bien un truc qui passe d'une config à une autre, ce sont les DD ! Mais la technologie avançant, on finit tjrs par changer de supports à un moment ou un autre). Après, un aspect de ton poste est, je trouve, un peu surprenant : la solution que tu proposes (OS + programmes sur le SSD et les données sur HDD) est en fait la norme, parce que tout mettre sur des SSD rajouterait juste un 0 à la facture du stockage ! En plus, ça force les gens à organiser correctement leurs données (séparation des supports physiques système/données, pour pouvoir réinstaller le système sans perdre les données en cas de crash nécessitant de réinstaller l'OS). @NOEL (salut, au passage) : Un petit hors sujet, sur ce coût : pas de têtes de lectures/écriture dans un SSD ! (mais pas d'erreur dans ce que tu disais à ce sujet, évidemment) Par contre, je ne suis tjrs pas d'accord avec ta façon de parler de "l'OS et les programmes entièrement chargés dans la RAM" ! (même si ce n'est pas faux, à chaque fois que je le lis, j'ai l'impression que des gens vont croire qu'une fois la machine lancée, plus rien n'est écrit sur le disque système). Donc je vais ressortir mon cannaçon en peluche et mon épée en bois, pour voler au secour du débutant en informatique et de l'orphelin de la souris (ne te sens pas visé en particulier, c'est juste que j'ai du temps à occuper, ce soir... ). Les causes d'écritures sur le disque système que je vois, là, tout de suite : (j'en avais pas déjà parlé avant ? ) les "fautes matérielles" = écriture dans le swap plutôt que dans la RAM (et pas besoin que la RAM soit pleine pour que ça arrive). Certes, on peut éviter le problème en faisant un RAM-DISK pour le swap (ça va plus vite, en plus), mais il faut avoir bcp de RAM pour ne pas être pénalisé, et le Go de RAM est tout de même plus cher que le Go de SSD. Ou alors mettre le swap sur un HDD... Mais... Voir plus bas. pour un PC qui ne sert pas qu'au montage, les fichier temporaires sont écrits quelquepart. Pour la navigation internet, ça peut très vite se chiffrer en Go d'écriture par jour, avec les téléchargement youtube et autre. Certes, on peut aussi régler le problème en mettant les fichiers temporaires sur un autre HDD. à chaque fermeture de programme, les données d'historique ou ce genre de choses sont écrites sur le disque (à un endroit ou un autre, selon le logiciel, les fichiers en jeu, les options choisies...) tous les services d'arrière plan aussi, qui se configurent, se reconfigurent, se lancent, s'arrêtent sans rien demander à personne ! (ou presque) sans doute d'autres choses que j'oublie... Au final, et comme j'ai déjà dû le dire, je suis personnellement d'avis que prendre un SSD pour améliorer la réactivité de l'OS et des programmes (oui, on parle à 98% de leur lancement/fermeture l'impact sur l'utilisation des log étant effectivement mineure) et ensuite mettre des goulots d'étranglement partout en collant le swap sur un HDD, en mettant tous les fichiers temporaires sur un HDD, et tout et tout, pour économiser le SSD, c'est complètement contre-productif ! Perso, j'aime quand word ne met pas 10s à s'ouvrir, mais bien 1 ou 2 seulement, quand VP s'ouvre en 10s au lieu de 25 et tout et tout. Si ça use plus vite mon SSD, qu'il s'use. le jour où il me lâchera, ce sera l'occasion de faire une réinstallation au propre. Après, évidemment, tout le monde voit midi à sa porte. Nota : il est par contre évident qu'il faut le plus possible éliminer les éléments qui grossissent de manière démesurée avec le temps du SSD. Genre le dossier "Mes documents" et le bureau : à ne surtout pas laisser sur le SSD (ceux-ci perdant en performance quand l'espace libre devient "à peine un peu faible", genre moins de 40% de l'espace total... ) ++ Fred

Attention, j'ai été utilisateur de VP pdt un moment et, même si on peut réussir à vaguement s'approcher de ce genre de résultats, il n'est en fait pas conçu pour. C'est à dire que l'ergonomie de l'ensemble est trèèèèèèèèèèèèèèèès largement insuffisante pour pouvoir construire des trucs aussi complexes sans s'arracher les cheveux (en vrac, qqes problèmes posés par VP pour ce genre de choses : pas de réel espace 3D (comprendre : acceptable pour ce type de travail) / pas de gestion des trajectoire courbes / pas de gestion de particules / gestion de la résolution-hierarchisation des pistes qui impliquent des calculs intermédiaires des images à la dimension du projet, ce qui empêchent des effets de mouvements ou zooms importants dans une image en combinant le tout avec les mouvements de pistes). En somme, l'option VP est utilisable uniquement pour des trucs très softs. Sinon c'est la crise de nerf assurée (j'en sais qqc...)

Effectivement, NOEL, j'ai toujours appelé "rendu" ce qui est en fait l'encodage. Désolé.

Ce serait oublier que les OS sont tellement énormes, actuellement, qu'il n'y en a plus aucun (actuel) qui tourne en étant intégralement chargé dans la RAM. Cela signifie des lectures/écritures régulières sur le disque système, d'où une réactivité à la faveur du SSD tout de même. Mais il est vrai que pour le fonctionnement d'un logiciel (de manière générale) c'est essentiellement le temps de lancement/fermeture de l'appli qui est impacté par la présence d'un SSD. @MANU : je montais sous vegas pro (système + log : SSD / rushs : caviar black / rendu+projet de montage sur un autre HDD) Petite réflexion personnelle sur les performances de rendu des machines : la course à la meilleure répartition sur différents DD, j'ai abandonné : une fois que les rushs sont séparés du reste, ça n'a quasiment plus d'impact en dehors des temps de rendu. Hors, pour un amateur qui n'a pas à faire ses rendus en même temps qu'il bosse sur un autre montage, les rendus sont fait la nuit. Donc que le temps de rendu soit de 2h avec une répartition HDD/SSD optimisée ou 3h parce que la répartition des DD n'est pas optimale, ça ne change strictement rien. Mais ça revient moins cher, par contre. Donc, pour un amateur, je miserai tout sur l'optimisation des perf lors du travail de montage, plutôt que pour les temps de rendu. NOEL : attention à une chose tout de même : les recommandation pour photoshop n'ont, sur le principe, pas grand chose à voir avec les prérequis nécessaire au montage vidéo : Toshop = traitement d'images fixes = toutes les données chargées dans la RAM. Vidéo = fichiers énormes = les données ne font que transiter par la RAM, mais il y a continuellement à aller faire des lectures sur le disque source. Donc ce paramètre peut introduire un nouveau goulot d'étranglement qui n'existe pas avec photoshop et qui peut ^tre résolu par l'utilisation d'un SSD dédié pour stocker les rushs (mais ça coûte cher, et ça pose d'autres problèmes de gestion de la machine/des rushs par ailleurs)

Petit retour sur le sujet : je m'étais monté un PC spécifiquement pour le montage, il y a qqes temps (amateurs plutôt averti, en montage). système sur SSD et rushs sur DD (caviar black 7200tpm). Le SSD pour le système apporte effectivement un gain important en réactivité de l'ensemble de la machine. Le SSD n'apporte effectivement rien ou presque sur les temps de rendu (après, ça dépend aussi de plein de facteurs : puissance de calcul de la machine ; complexité du montage -> tout dépend où se trouve le goulot d'étranglement) Perso, je ne mettrais pas les rushs sur le SSD du système (pas très cohérent et trop chiant à gérer pour l'archivage). Par contre, il y a un point pour lequel un second SSD avec les rushs utilisés pour le montage aurait été très intéressant : même avec une puissance de calcul suffisante, j'avais (au passé car je ne fais plus de montages depuis qqes temps, déjà) des petits lags au moment des cuts dans la timeline, à cause du temps de latence pour que le DD accède au fichier suivant ou à la bonne partie du fichier en cours. C'était très chiant, parce que c'est justement à ces moments là que j'avais besoin de la lecture en temps réel (j'ai toujours bossé sur des trucs avec une synchro sur le tempo de la musique, pour les cuts). Je n'ai pas pu tester, mais un SSD dédié aux rushs aurait sans doute éliminé ce problème. Par contre, ce n'est plus le même budget, à moins de prendre un SSD pas trop gros et de faire tourner les fichiers (HDD = archivage / SSD = projet en cours uniquement. Mais encore faut-il que le poids total des rushs n'excède pas le volume du SSD, ce qui peut arriver très, très vite...)

Oui, l'hyperfocale est un principe optique, c'est indépendant de la photo ou la vidéo. Tu travailles à f/22 pour maximiser la PdC, ce qui est logique. En travaillant avec l'hyperfocale, tu pourras obtenir la même chose en PdC, mais à f/11 ou f/8, par exemple, et donc sans diffraction. Au final, il te suffira de faire tes tests de netteté avec différentes valeurs du cercle de confusion, et une fois que tu auras trouvé les valeurs qui te conviennent, tu te fais un papier/mémo avec les valeurs d'hyperfocales pour les différentes ouvertures et ça roule tout seul. C'est tout aussi rapide à régler et une fois que c'est fait, il n'y a plus de réglage de MAP à faire quand tu tournes, justement. le follow focus n'est absolument pas adapté à ton utilisation (lourd, encombrant). De toutes façons, avec un glidecam, si en plus tu skie en même temps, tu ne pourras pas te concentrer sur la MAP, donc tu es obligé de travailler avec l'hyperfocale. Bon courage, Fred EDIT : essai classique : MAP à 2m et ouverture à f/11, ça devrait le faire, avec une image normalement "nette" de 1m à l'infini. Faut tester pour vérifier à l'usage, mais ça devrait être pas mal.