Il existe plusieurs fréquences d'images «standard», mais il y en a tellement qu'il est plus facile de prendre en charge des fréquences d'images arbitraires que de prendre en charge de nombreuses fréquences spécifiques. Cela est particulièrement vrai pour les lecteurs de logiciels, comme VLC.
Il existe de plus en plus de support pour VARIABLE fps. (VFR, fréquence d'images variable). C'est là que l'intervalle entre les images d'une même vidéo n'est pas constant. De nombreux formats de fichiers de conteneurs vidéo (comme Matroska ( .mkv) ou MPEG-4 ( .mp4, étroitement liés à Apple .mov)) ne stockent même pas un numéro FPS, mais plutôt une base de temps (par exemple 1 / 30ème de seconde), puis chaque image a un horodatage comme multiple de cette base de temps. Il se trouve que l'intervalle entre chaque image est un ou un petit nombre entier d'unités de la base de temps dans une vidéo CFR (fréquence d'images constante).
Des séquences de caméras de sécurité avec des images presque dupliquées seraient un cas d'utilisation évident pour le VFR. Encore plus s'il est compressé avec un codec vidéo simpliste qui ne profite pas bien de la redondance temporelle (avec des trames inter (p et b)). (jouez avec ffmpeg -vf mpdecimatepour supprimer des images presque dupées. À utiliser -vsync 2si la sortie vers mp4, car pour une raison quelconque, ce n'est pas la valeur par défaut pour ce muxer, mais c'est pour mkv.)
Un autre cas est celui des smartphones modernes. Par exemple, le Moto G (2e génération) de mon frère enregistre des vidéos VFR. Il réduit la fréquence d'images lorsque le capteur a besoin de plus de lumière. Une partie de la sortie de l'exécution de mediainfo sur un mp4 créé par le logiciel du téléphone, enregistrée à l'intérieur:
Bit rate : 9 999 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Rotation : 90°
Frame rate mode : Variable
Frame rate : 16.587 fps
Minimum frame rate : 14.985 fps
Maximum frame rate : 30.030 fps
La lecture d'un seul flux vidéo VFR n'est pas difficile. Le logiciel prépare simplement la prochaine image à afficher, s'endort jusqu'à ce qu'elle soit affichée, puis se réveille et l'affiche.
Les choses deviennent un peu plus compliquées lorsque l'on tient compte du fait que les humains ne peuvent voir les images vidéo que lorsqu'un moniteur les affiche. Les moniteurs VFR existent, mais sont encore rares. (google pour g-sync freesync).
La modification de l'image affichée pendant sa numérisation sur le moniteur entraîne une déchirure moche de la vidéo (ce qui se produit généralement lorsque vous jouez à un jeu avec vsync désactivé). Cela limite le lecteur à changer l'image affichée à 50 ou 60 Hz. (Les CRT prennent en charge des taux de rafraîchissement arbitraires, dans une plage, mais il est compliqué de préparer des modes avec tous les temps corrects, de sorte que la plupart des gens n'utilisent que quelques taux de rafraîchissement fixes. Et maintenant, les gens ont des écrans LCD qui ne prennent en charge qu'un taux de rafraîchissement fixe de toute façon. Les moniteurs freesync sont de toute façon plus répandus. Je suis vraiment impatient de le faire. :)
Ainsi, avec des fréquences d'images vidéo qui ne sont pas un multiple ou un facteur du taux de rafraîchissement du moniteur, certaines images seront affichées pendant 3 rafraîchissements du moniteur, et d'autres pour 2, par exemple, même si la vidéo est censée être à une vitesse constante de 25 images par seconde. (sur un moniteur à 60 Hz).
Les choses deviennent plus compliquées lorsque vous souhaitez travailler avec plusieurs clips et effectuer un fondu entre eux, ou une image dans l'image, ou divers autres effets. C'est beaucoup plus facile d'écrire un logiciel de montage vidéo si vous pouvez supposer que tous les clips ont une nouvelle image en même temps. (Ils forcent l'alignement des clips à s'aligner sur des images entières).
C'est pourquoi les NLE (comme kdenlive ou pitivi, pour choisir des exemples de logiciels gratuits aléatoires), sont plus susceptibles de vous forcer à un FPS fixe et de supprimer / dupliquer des images de vos clips pour les faire correspondre à cette fréquence d'images. Le CFR que vous choisissez peut être arbitraire, mais il doit généralement être constant pour l'ensemble du "projet".
(Est-ce que des NLE fonctionnent entièrement avec des clips VFR et produisent une sortie VFR dans ce cas?)
Donc, en résumé, une fois que nous avons des moniteurs et des systèmes d'exploitation à synchronisation variable, la seule chose qui nous retient sera le montage vidéo, je suppose. Et la radiodiffusion, car apparemment CFR est aussi un gros problème pour cela?
Au cas où vous vous poseriez la question, les 29.970 (en fait 30000/1001) et 23.976 (en fait 24000/1001, de télécinéma) les taux de trame non entiers ennuyeux sont la faute de la couleur NTSC. recherchez 1.001 . Si seulement ils avaient été prêts à risquer que quelques postes N&B ne soient pas en mesure de gérer une fréquence supplémentaire de 0,1% pour la sous-porteuse audio, le monde aurait été épargné par ce non-sens. (Je pense avoir vu un autre article quelque part qui donnait l'impression que de nombreux ensembles auraient été bien, mais ils n'étaient pas sûrs d'une compatibilité parfaite. Wikipedia donne l'impression qu'aucun ensemble n'aurait géré une sous-porteuse audio 0,1% plus élevée. IDK le faits.)
Les taux de trame ennuyeux sont cependant l'un des moindres péchés de la radiodiffusion. C'est vraiment l'entrelacement qui a été le fléau de la qualité vidéo sur les écrans modernes (tous les pixels allumés en même temps), et cela n'aurait pas changé. Je ne comprends toujours pas pourquoi l'entrelacement a été conservé pour la TVHD. Pourquoi 1080i60 a-t-il été défini au lieu d'utiliser 720p60 pour obtenir la même résolution temporelle pour les sports et autres? C'est similaire à 1920x540p60, mais avec un décalage vertical stupide entre les champs pairs et impairs qui nécessite beaucoup de calculs du côté de la réception pour qu'il ne soit pas horrible.
Éditer:
Pour votre cas d'utilisation, je recommanderais absolument l'archivage au FPS natif. Ne jetez aucune information en supprimant des images. Ne dupez pas les images et agrandissez vos fichiers (ou faites en sorte que votre encodeur h.264 passe plus de temps à remarquer les doublons et à produire une image pleine de saut de macroblocs qui ne prend que 20 octets pour l'ensemble de l'image).
À l'avenir, lorsque nous espérons que tous auront des affichages freesync capables de lire n'importe quel taux d'images, vous voudrez annuler votre pullup à 24 images par seconde pour que votre vidéo soit plus fluide! Ou si le freesync ne fonctionne pas ou que l'affichage qui vient après les LCD est CFR, la conversion de taux est probablement préférable de toute façon au moment de la lecture. Ce n'est pas comme si 24 images par seconde se jouait parfaitement sur un moniteur à 60 Hz. (Je ne remarque pas visuellement le fait que certaines images sont affichées pour 3 * 1 / 60ème tandis que d'autres sont affichées pour 2 * 1 / 60ème, mais c'est vrai).
Si vous rencontrez des problèmes avec Quicktime, alors IDK. Assurez-vous que Handbrake crée des fichiers avec le bon nombre d'images par seconde dans le flux binaire h.264, ainsi que le conteneur. (Oui, les en-têtes h.264 peuvent apparemment stocker une fréquence d'images, distincte de ce que dit le conteneur. Consultez les documents pour mkvmerge --fix-bitstream-timing-information. Et essayez de l'utiliser avec --default-duration 16fpspour créer un fichier mkv. ) Ou peut-être qu'il existe un moyen de le faire avec les outils mp4 en premier lieu. Voir par exemple: /ubuntu/370692/how-to-change-the-framerate-of-a-video-without-reencoding
Je peux garantir que la fréquence d'images arbitraire mp4 est valide, et même la fréquence d'images variable mp4 est valide. Si Quicktime le joue mal, ce pourrait bien être la faute de Quicktime. Ou peut-être la faute de Handbrake pour avoir rendu le fichier incorrect. J'utilise généralement ffmpeg directement, car je suis un ninja en ligne de commande.