30 ou 60 fps pour une vidéo de démo
60 fps ne rend pas toujours plus fluide. La vraie différence se joue sur le mouvement du curseur et le bitrate — pas sur le chiffre affiché dans la console.
TL;DR
- **60 fps ne gagne que dans les démos à mouvement rapide** (un curseur qui traverse l’écran, du drag-and-drop). Sur une UI statique, 30 fps est indiscernable.
- HEVC à 60 fps **double à peu près la taille du fichier** sans doubler la fluidité perçue — la loi de Weber s’applique.
- La règle de Sgrin : 30 fps par défaut, 60 seulement en cas de vrai mouvement du curseur — décidé à l’export.
La métrique qui compte n’est pas le nombre de frames par seconde mais le mouvement perçu : à quelle vitesse le contenu se déplace entre deux frames. Une capture d’une fenêtre statique à 60 fps est identique à 30 fps parce que rien ne se déplace entre les frames.
L’œil ne compte pas les frames — il détecte la discontinuité du déplacement. C’est pourquoi un curseur qui traverse un écran de 1440px en 0,3 s paraît saccadé à 30 fps et fluide à 60 : chaque frame couvre 80px contre 40px, et le seuil où l’œil cesse d’intégrer le mouvement se situe vers 60px.
Le frame rate ne décrit pas ta vidéo. Il décrit à quelle vitesse ce que tu as enregistré bougeait.
Quand 30 fps suffit
Si ta démo est une visite de panneaux statiques avec un curseur qui avance posément, 30 fps suffit. Les panneaux ne changent pas entre les frames, et le déplacement du curseur reste sous le seuil de perception. Tu obtiens un fichier deux fois plus léger sans perte visible.
Cela couvre la plupart des walkthroughs produit, des visites de réglages et des explainers de feature — l’essentiel de ce que publient les founders indie et les petites équipes.
Quand 60 fps justifie son poids
60 fps paie quand il y a du vrai mouvement : drag-and-drop, scroll rapide, transitions animées de l’UI, ou un curseur qui traverse l’écran vite. Là, le déplacement par frame dépasse le seuil et 30 fps commence à paraître par à-coups.
L’arbitrage, c’est la taille du fichier. HEVC à 60 fps double presque les octets sans doubler la fluidité perçue — un cas d’école de la loi de Weber, où la différence à peine perceptible croît avec la base, pas par paliers absolus.
| Dimension | 30 fps | 60 fps |
|---|---|---|
| Mouvement fluide du curseur | Jusqu’à ~40px/frame | Jusqu’à ~80px/frame |
| Taille du fichier (HEVC, 30 s) | ~6 Mo | ~11 Mo |
| Compatibilité web | Universelle | HEVC restrictif |
Décider en trois étapes
- Regarde le mouvement dominant. Panneaux statiques avec un curseur lent → 30 fps. Drag, scroll rapide ou animation UI → envisage 60.
- Pèse le coût du fichier. HEVC à 60 fps double à peu près la taille sans doubler la fluidité perçue. Si tu le sers sur une landing page, le poids peut pénaliser ton LCP plus que la fluidité n’aide.
- Vérifie la destination. HEVC à 60 fps dans Safari sans le bon container rend un écran noir. Pour une diffusion web universelle, H.264 à 30 fps reste la valeur sûre.
Ce que Sgrin en fait
Sgrin ne te fait pas choisir à la main. Il lit le mouvement de la capture et applique la règle ci-dessus à l’export.
› En profondeur — le calcul du seuil
Questions fréquentes
60 fps est-il toujours meilleur pour une capture d’écran ?
Non. Pour une UI statique avec un curseur lent, 30 fps reste identique et divise la taille du fichier par deux. 60 fps n’aide que quand quelque chose bouge vite entre deux frames.
HEVC à 60 fps fonctionne-t-il partout ?
Pas vraiment. HEVC est restrictif sur le web — Safari exige le bon container, et certaines plateformes refusent de le lire. H.264 à 30 fps reste la valeur sûre pour une lecture universelle.
Comment Sgrin choisit-il le frame rate ?
Il mesure la vélocité de pointe du pointeur pendant la capture. Si le curseur dépasse environ 60px par frame à 30 fps, l’export passe à 60. Sinon, il reste à 30 pour garder un fichier léger.
Enregistre une démo. Laisse Sgrin la réaliser.
Essai gratuit 14 jours · Sans carte