Jump to content

Fredouillelafripouille

Membres
  • Content Count

    671
  • Joined

  • Last visited

A propos de Fredouillelafripouille

  • Rank
    Membre Albert Einstein

Contact Methods

  • URL de votre site (si existant)
    http://www.escalade-alsace.com

Profile Information

  • Lieu
    67
  • Intérêts, passions
    Grimpegrimpegrimpe...

Recent Profile Visitors

4074 profile views
  1. 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.
  2. 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 in
  3. 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
  4. 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 (p
  5. 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", ...
  6. oui oui ! Tu as juste oublié de mettre en gras la fin de la phrase ! (la partie la plus importante ou presque !)
  7. 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
  8. 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 imp
  9. Effectivement, NOEL, j'ai toujours appelé "rendu" ce qui est en fait l'encodage. Désolé.
  10. 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é
  11. 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
  12. 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
×
×
  • Create New...

Important Information

j'accepte les cookies de ce site