Modification de Cadence vidéo sur PC

Aller à : navigation, rechercher

Attention : vous n’êtes pas connecté(e). Votre adresse IP sera visible de tout le monde si vous faites des modifications. Si vous vous connectez ou créez un compte, vos modifications seront attribuées à votre propre nom d’utilisateur(rice) et vous aurez d’autres avantages.

Cette modification va être annulée. Veuillez vérifier les différences ci-dessous, puis publier l’annulation si c’est bien ce que vous voulez faire.
Version actuelle Votre texte
Ligne 1 : Ligne 1 :
 
Si vous utilisez un PC pour lire des vidéos et que vous voulez lire des films/séries dans de bonnes conditions (c'est-à-dire sans ''aucune'' saccade d'aucune sorte), vous devriez lire cette page.
 
Si vous utilisez un PC pour lire des vidéos et que vous voulez lire des films/séries dans de bonnes conditions (c'est-à-dire sans ''aucune'' saccade d'aucune sorte), vous devriez lire cette page.
  
'''NOUVEAU Janvier 2024: [https://github.com/dechamps/videojitter videojitter] peut être utilisé pour mesurer et caractériser les problèmes présentés dans cet article.'''
+
'''Cet article est à jour vis-à-vis de l'état de l'art au : 2018-04-08'''
 
 
'''Cet article est à jour vis-à-vis de l'état de l'art en avril 2018'''
 
  
 
= TL;DR =
 
= TL;DR =
Ligne 33 : Ligne 31 :
 
Par contre, si vous êtes en 60 Hz comme l'immense majorité des gens, alors ce n'est pas si simple, car 60 n'est pas un multiple de 24. Il faudrait répéter chaque frame 2.5 fois, mais ça n'a pas de sens. Au lieu de ça, le comportement décrit ci-dessus va avoir le résultat suivant : la première frame va être répétée 3 fois, puis la frame suivante 2 fois, puis la frame suivante 3 fois, etc. (Ce processus est souvent appelé "[[wikipedia:Three-two_pull_down|3:2 pull down]]", mais ce terme n'est pas tout à fait correct ici car le flux n'est pas entrelacé.) Par exemple, une série de frames 24 FPS "A B C D E" va être convertie en 60 FPS sous la forme "AAA BB CCC DD EEE".
 
Par contre, si vous êtes en 60 Hz comme l'immense majorité des gens, alors ce n'est pas si simple, car 60 n'est pas un multiple de 24. Il faudrait répéter chaque frame 2.5 fois, mais ça n'a pas de sens. Au lieu de ça, le comportement décrit ci-dessus va avoir le résultat suivant : la première frame va être répétée 3 fois, puis la frame suivante 2 fois, puis la frame suivante 3 fois, etc. (Ce processus est souvent appelé "[[wikipedia:Three-two_pull_down|3:2 pull down]]", mais ce terme n'est pas tout à fait correct ici car le flux n'est pas entrelacé.) Par exemple, une série de frames 24 FPS "A B C D E" va être convertie en 60 FPS sous la forme "AAA BB CCC DD EEE".
  
Ce comportement est correct dans la mesure où il permet à la vidéo d'être lue à la bonne vitesse. Mais cette approche présente un gros problème : la vidéo finale une fois convertie ne respecte pas la cadence d'origine. Normalement, dans la vidéo 24 FPS d'origine, chaque frame est affichée pendant ~41 ms. Mais dans la vidéo 60 FPS finale, ce n'est pas le cas : une frame sur deux est affichée pendant ~50 ms, tandis que l'autre est affichée pendant ~33 ms. C'est une dégradation - la vidéo parait saccadée car le rythme de présentation des frames est incorrect. Il s'agit du "[[wikipedia:Telecine#Telecine_judder|Telecine judder]]". La documentation de [https://mpv.io/ mpv] propose [https://github.com/mpv-player/mpv/wiki/Interpolation#32-pulldown une autre présentation] de ce phénomène.
+
Ce comportement est correct dans la mesure où il permet à la vidéo d'être lue à la bonne vitesse. Mais cette approche présente un gros problème : la vidéo finale une fois convertie ne respecte pas la cadence d'origine. Normalement, dans la vidéo 24 FPS d'origine, chaque frame est affichée pendant ~41 ms. Mais dans la vidéo 60 FPS finale, ce n'est pas le cas : une frame sur deux est affichée pendant ~50 ms, tandis que l'autre est affichée pendant ~33 ms. C'est une dégradation - la vidéo parait saccadée car le rythme de présentation des frames est incorrect. Il s'agit du "[[wikipedia:Telecine#Telecine_judder|Telecine judder]]".
  
 
Un objet qui bouge de manière constante à l'écran, par exemple, donnera l'impression de tressauter au lieu de présenter un mouvement constant, doux et fluide. L'effet n'est pas catastrophique parce que la cadence reste plus ou moins régulière (dans le sens où la procession 3:2:3:2, elle, reste constante), mais néanmoins visible dans certaines scènes, en particulier lorsque les objets sont nets et la caméra est en mouvement. Un générique défilant peut également servir d'exemple. Un œil initié qui sait ce qu'il cherche peut remarquer le problème après seulement quelques secondes de lecture, en fonction du contenu.
 
Un objet qui bouge de manière constante à l'écran, par exemple, donnera l'impression de tressauter au lieu de présenter un mouvement constant, doux et fluide. L'effet n'est pas catastrophique parce que la cadence reste plus ou moins régulière (dans le sens où la procession 3:2:3:2, elle, reste constante), mais néanmoins visible dans certaines scènes, en particulier lorsque les objets sont nets et la caméra est en mouvement. Un générique défilant peut également servir d'exemple. Un œil initié qui sait ce qu'il cherche peut remarquer le problème après seulement quelques secondes de lecture, en fonction du contenu.
Ligne 51 : Ligne 49 :
 
Dans un monde parfait, ces horloges seraient parfaitement précises - une fréquence de rafraîchissement « nominale » de 60 Hz a pour effet d'envoyer très précisément 60 images par seconde à l'écran, et une fréquence d’échantillonnage audio « nominale » de 48 kHz a pour effet d'envoyer très précisément 48000 échantillons audio via la sortie (analogique ou numérique). Mais nous ne vivons pas dans un monde parfait, les composants électroniques ont leurs limites, et une horloge censée débiter du 60 Hz pourrait en réalité débiter 59.99 Hz, ou bien 60.01 Hz. Même chose pour l'horloge audio.
 
Dans un monde parfait, ces horloges seraient parfaitement précises - une fréquence de rafraîchissement « nominale » de 60 Hz a pour effet d'envoyer très précisément 60 images par seconde à l'écran, et une fréquence d’échantillonnage audio « nominale » de 48 kHz a pour effet d'envoyer très précisément 48000 échantillons audio via la sortie (analogique ou numérique). Mais nous ne vivons pas dans un monde parfait, les composants électroniques ont leurs limites, et une horloge censée débiter du 60 Hz pourrait en réalité débiter 59.99 Hz, ou bien 60.01 Hz. Même chose pour l'horloge audio.
  
Pour l'horloge vidéo, il y a un problème supplémentaire lié à la configuration. Les paramètres standards ([[wikipedia:Coordinated_Video_Timings|CVT]]) pour du 1080p24 (~23.97'''60''' Hz) nécessitent une ''pixel clock'' de ~74.1759 MHz. Mais en pratique le GPU n'acceptera pas une configuration aussi fine ; la pixel clock n'est ajustable que par paliers de 0.01 MHz. (Sous Linux la situation est meilleure : le [[wikipedia:X.Org_Server|serveur X.Org]] offre des paliers de 0.001 MHz.) Du coup, on se retrouve forcé de régler la pixel clock à 74.1700 MHz (fréquence de rafraîchissement ~23.97'''41''' Hz, une déviation de ~0.007%) ou à 74.1800 MHz (fréquence de rafraîchissement ~23.97'''73''' Hz, une déviation de ~0.005%). L'horloge audio, elle, n'accepte que précisément 48000 Hz et rien d'autre.
+
Pour l'horloge vidéo, il y a un problème supplémentaire lié à la configuration. Les paramètres standards ([[wikipedia:Coordinated_Video_Timings|CVT]]) pour du 1080p24 (~23.97'''60''' Hz) nécessitent une ''pixel clock'' de ~74.1759 MHz. Mais en pratique le GPU n'acceptera pas une configuration aussi fine ; la pixel clock n'est ajustable que par paliers de 0.01 MHz. Du coup, on se retrouve forcé de régler la pixel clock à 74.1700 MHz (fréquence de rafraîchissement ~23.97'''41''' Hz, une déviation de ~0.007%) ou à 74.1800 MHz (fréquence de rafraîchissement ~23.97'''73''' Hz, une déviation de ~0.005%). L'horloge audio, elle, n'accepte que précisément 48000 Hz et rien d'autre.
  
 
Si il n'y avait qu'une seule horloge, comme dans un appareil dédié, une telle déviation ne serait pas un problème. Après tout, il s'agit là de déviations minimes - de l'ordre de 0.01%, soit moins d'une seconde sur un film de 2 heures. La vidéo sera lue trop vite ou trop lentement, mais la différence est imperceptible. À moins que vous ne vérifiez la longueur du film chronomètre en main (et de bons réflexes), vous ne remarquerez rien.
 
Si il n'y avait qu'une seule horloge, comme dans un appareil dédié, une telle déviation ne serait pas un problème. Après tout, il s'agit là de déviations minimes - de l'ordre de 0.01%, soit moins d'une seconde sur un film de 2 heures. La vidéo sera lue trop vite ou trop lentement, mais la différence est imperceptible. À moins que vous ne vérifiez la longueur du film chronomètre en main (et de bons réflexes), vous ne remarquerez rien.
Ligne 158 : Ligne 156 :
 
* [https://github.com/zachsaw/MPDN_Extensions/wiki/Rate-Tuner Rate-Tuner] est une extension pour le lecteur vidéo [http://www.zachsaw.com/mpdn/ MPDN].
 
* [https://github.com/zachsaw/MPDN_Extensions/wiki/Rate-Tuner Rate-Tuner] est une extension pour le lecteur vidéo [http://www.zachsaw.com/mpdn/ MPDN].
 
* [https://mpv.io/ mpv] (et [[wikipedia:Mpv_(media_player)#Interface_and_graphical_front-ends|dérivés]] tels que [https://www.smplayer.info/ SMPlayer]) propose l'[https://mpv.io/manual/master/#options-video-sync option <code>video-sync</code>] qui [https://github.com/mpv-player/mpv/wiki/Display-synchronization#display-sync implémente cette fonctionnalité] (valeur <code>display-resample</code>).
 
* [https://mpv.io/ mpv] (et [[wikipedia:Mpv_(media_player)#Interface_and_graphical_front-ends|dérivés]] tels que [https://www.smplayer.info/ SMPlayer]) propose l'[https://mpv.io/manual/master/#options-video-sync option <code>video-sync</code>] qui [https://github.com/mpv-player/mpv/wiki/Display-synchronization#display-sync implémente cette fonctionnalité] (valeur <code>display-resample</code>).
* [https://potplayer.daum.net/ Potplayer] semble inclure cette fonctionnalité en standard. [https://wiki.mikejung.biz/PotPlayer#Potplayer_Playback_Settings] [https://forum.doom9.org/showthread.php?p=1843214#post1843214]
 
  
 
== Frame blending (Smooth Motion) ==
 
== Frame blending (Smooth Motion) ==
Ligne 164 : Ligne 161 :
 
[[#Telecine_judder_.28saccades_continues_-_24p.4060Hz.2C_.223:2_pull_down.22.29|Souvenez-vous]] du principe de fonctionnement d'un moteur de rendu vidéo : on envoie une frame au GPU au point temporel adéquat, et le GPU se charge ensuite de délivrer cette frame au rafraîchissement suivant. Ce comportement peut donner lieu à des ''frame repeats'' indésirables si la sortie vidéo rafraîchit plus vite que le framerate de la vidéo, à cause du [[#Telecine_judder_.28saccades_continues_-_24p.4060Hz.2C_.223:2_pull_down.22.29|telecine judder]] ou du [[#Horloge_d.C3.A9synchronis.C3.A9e_.28discontinuit.C3.A9s.29|problème des horloges]].
 
[[#Telecine_judder_.28saccades_continues_-_24p.4060Hz.2C_.223:2_pull_down.22.29|Souvenez-vous]] du principe de fonctionnement d'un moteur de rendu vidéo : on envoie une frame au GPU au point temporel adéquat, et le GPU se charge ensuite de délivrer cette frame au rafraîchissement suivant. Ce comportement peut donner lieu à des ''frame repeats'' indésirables si la sortie vidéo rafraîchit plus vite que le framerate de la vidéo, à cause du [[#Telecine_judder_.28saccades_continues_-_24p.4060Hz.2C_.223:2_pull_down.22.29|telecine judder]] ou du [[#Horloge_d.C3.A9synchronis.C3.A9e_.28discontinuit.C3.A9s.29|problème des horloges]].
  
Madshi, l'auteur de l'excellent moteur de rendu vidéo [http://madvr.net/ madVR], a inventé une solution innovante à ce problème, qu'il a baptisé "Smooth Motion" : au lieu de laisser le GPU répéter une frame, on lui envoie une frame supplémentaire qui est une moyenne (mix/blend) de la frame précédente et de la frame suivante. Par exemple, dans le cas du telecine judder, au lieu d'envoyer la cadence "AAA BB CCC DD", on envoie la cadence "AA X BB CC Y DD", où X est une frame artificielle constituée à 50/50 de A et B, et Y est une frame artificielle  constituée à 50/50 de C et D. On remarque que chaque frame est répétée "2.5" fois (le .5 correspondant au blend), au lieu de 2:3:2:3 fois. La documentation de [https://mpv.io/ mpv] propose [https://github.com/mpv-player/mpv/wiki/Interpolation#smoothmotion une autre présentation] de cette solution.
+
Madshi, l'auteur de l'excellent moteur de rendu vidéo [http://madvr.net/ madVR], a inventé une solution innovante à ce problème, qu'il a baptisé "Smooth Motion" : au lieu de laisser le GPU répéter une frame, on lui envoie une frame supplémentaire qui est une moyenne (mix/blend) de la frame précédente et de la frame suivante. Par exemple, dans le cas du telecine judder, au lieu d'envoyer la cadence "AAA BB CCC DD", on envoie la cadence "AA X BB CC Y DD", où X est une frame artificielle constituée à 50/50 de A et B, et Y est une frame artificielle  constituée à 50/50 de C et D. On remarque que chaque frame est répétée "2.5" fois (le .5 correspondant au blend), au lieu de 2:3:2:3 fois.
  
 
Le même procédé est utilisé pour « adoucir » une discontinuité due à l'horloge : au lieu de répéter ou retirer une frame, on peut la fusionner à la place. Cette solution peut donc être utilisée pour résoudre les deux problèmes simultanément. En fait, l'algorithme se contrefout de savoir si un frame repeat ou un frame drop est causé par du 3:2 pulldown ou une discontinuité : dans les deux cas il fusionnera mécaniquement les frames sans chercher à comprendre. Cela en fait une solution très flexible et très générique, tout en étant très simple d'utilisation.
 
Le même procédé est utilisé pour « adoucir » une discontinuité due à l'horloge : au lieu de répéter ou retirer une frame, on peut la fusionner à la place. Cette solution peut donc être utilisée pour résoudre les deux problèmes simultanément. En fait, l'algorithme se contrefout de savoir si un frame repeat ou un frame drop est causé par du 3:2 pulldown ou une discontinuité : dans les deux cas il fusionnera mécaniquement les frames sans chercher à comprendre. Cela en fait une solution très flexible et très générique, tout en étant très simple d'utilisation.
Ligne 186 : Ligne 183 :
 
* L'excellent [http://madvr.net/ madVR] propose l'option "Smooth Motion". madVR nécessite l'utilisation d'un lecteur vidéo compatible DirectShow, tel que [https://mpc-hc.org/ MPC-HC].
 
* L'excellent [http://madvr.net/ madVR] propose l'option "Smooth Motion". madVR nécessite l'utilisation d'un lecteur vidéo compatible DirectShow, tel que [https://mpc-hc.org/ MPC-HC].
 
* Le lecteur vidéo [http://www.zachsaw.com/mpdn/ MPDN] semble proposer une option similaire appellée "Fluid Motion".
 
* Le lecteur vidéo [http://www.zachsaw.com/mpdn/ MPDN] semble proposer une option similaire appellée "Fluid Motion".
* [https://mpv.io/ mpv] (et [[wikipedia:Mpv_(media_player)#Interface_and_graphical_front-ends|dérivés]] tels que [https://www.smplayer.info/ SMPlayer]) propose l'[https://mpv.io/manual/master/#options-interpolation option <code>interpolation</code>] qui implémente cette fonctionnalité. La technique utilisée semble être subtilement différente ([https://github.com/mpv-player/mpv/wiki/Interpolation#convolution-based-interpolation convolution]) comparé à la solution classique ([https://github.com/mpv-player/mpv/wiki/Interpolation#smoothmotion smoothmotion]).
 
  
 
== Ajustement avancé de la fréquence de rafraîchissement (Custom Mode) ==
 
== Ajustement avancé de la fréquence de rafraîchissement (Custom Mode) ==
Ligne 196 : Ligne 192 :
 
La fréquence de rafraîchissement est dérivée directement de la "pixel clock", qui est le signal d'horloge principal de la sortie vidéo. C'est cette pixel clock qui nous limite, car elle n'est ajustable que par paliers de 0.01 MHz. Mais Madshi (oui, encore lui), a trouvé un moyen de « tricher » : en plus de la pixel clock, il est également possible de « jouer » avec d'autres paramètres de la sortie vidéo qui ont également une influence sur la fréquence de rafraîchissement finale. En particulier le "[https://electronics.stackexchange.com/questions/201011/what-is-front-porch-and-back-porch-of-a-video-signal-in-crt-display back porch]" horizontal et vertical, qui sont des paramètres extrêmement techniques (et pas particulièrement utiles en temps normal) et qui ont trait aux intervalles de temps laissés « blancs » entre chaque ligne et chaque frame qui est envoyée à l'écran. En exploitant ces paramètres exotiques, on obtient plus de contrôle sur la fréquence de rafraîchissement finale, à tel point qu'il devient possible de l'ajuster de manière suffisamment fine pour résoudre notre problème. Cette solution est désignée sous le terme "Custom Modes".
 
La fréquence de rafraîchissement est dérivée directement de la "pixel clock", qui est le signal d'horloge principal de la sortie vidéo. C'est cette pixel clock qui nous limite, car elle n'est ajustable que par paliers de 0.01 MHz. Mais Madshi (oui, encore lui), a trouvé un moyen de « tricher » : en plus de la pixel clock, il est également possible de « jouer » avec d'autres paramètres de la sortie vidéo qui ont également une influence sur la fréquence de rafraîchissement finale. En particulier le "[https://electronics.stackexchange.com/questions/201011/what-is-front-porch-and-back-porch-of-a-video-signal-in-crt-display back porch]" horizontal et vertical, qui sont des paramètres extrêmement techniques (et pas particulièrement utiles en temps normal) et qui ont trait aux intervalles de temps laissés « blancs » entre chaque ligne et chaque frame qui est envoyée à l'écran. En exploitant ces paramètres exotiques, on obtient plus de contrôle sur la fréquence de rafraîchissement finale, à tel point qu'il devient possible de l'ajuster de manière suffisamment fine pour résoudre notre problème. Cette solution est désignée sous le terme "Custom Modes".
  
En théorie, personne n'est censé modifier ces paramètres avancés - ils sont codifiés dans le standard VESA "[[wikipedia:Coordinated_Video_Timings|Coordinated Video Timings]]". Pour cette raison, un écran n'appréciera pas forcément de tels ajustements, et il n'y a aucune garantie qu'il acceptera un signal ainsi modifié. Ces problèmes de compatibilité dépendent du matériel utilisé et sont plus ou moins imprévisibles ; il faut faire le test pour vérifier. C'est le principal inconvénient de cette technique.
+
En théorie, personne n'est censé modifier ces paramètres avancés - ils sont codifiés dans le standard VESA "[[wikipedia:Coordinated_Video_Timings|Coordinated Video Timings]]". Pour cette raison, un écran n'appréciera pas forcément de tels ajustements, et il n'y a aucune garantie qu'il acceptera un signal ainsi modifié. Ces problèmes de compatibilité dépendent du matériel utilisé et sont plus ou moins imprévisibles ; il faut faire le test pour vérifier. C'est le principal inconvénient de cette technique.
  
 
Notons que, strictement parlant, cette solution est uniquement capable d'éliminer le [[#Horloge_d.C3.A9synchronis.C3.A9e_.28discontinuit.C3.A9s.29|problème des horloges]] ; elle n'élimine pas le [[#Telecine_judder_.28saccades_continues_-_24p.4060Hz.2C_.223:2_pull_down.22.29|telecine judder]]. Cela dit, il est évidemment possible de faire d'une pierre deux coups et d'éliminer les deux à la fois en ajustant une fréquence de rafraîchissement qui est déjà proche de [[#Utiliser_24_Hz_au_lieu_de_60_Hz|24 Hz]] (ou d'un [[#Utiliser_un_multiple_de_24_Hz_.2848.2F72.2F96.2F120.2F144.29_au_lieu_de_60_Hz|multiple]]) au départ, à supposer que l'écran est compatible avec une telle fréquence.
 
Notons que, strictement parlant, cette solution est uniquement capable d'éliminer le [[#Horloge_d.C3.A9synchronis.C3.A9e_.28discontinuit.C3.A9s.29|problème des horloges]] ; elle n'élimine pas le [[#Telecine_judder_.28saccades_continues_-_24p.4060Hz.2C_.223:2_pull_down.22.29|telecine judder]]. Cela dit, il est évidemment possible de faire d'une pierre deux coups et d'éliminer les deux à la fois en ajustant une fréquence de rafraîchissement qui est déjà proche de [[#Utiliser_24_Hz_au_lieu_de_60_Hz|24 Hz]] (ou d'un [[#Utiliser_un_multiple_de_24_Hz_.2848.2F72.2F96.2F120.2F144.29_au_lieu_de_60_Hz|multiple]]) au départ, à supposer que l'écran est compatible avec une telle fréquence.
  
Rappellons également que contrairement à d'autres solutions comme [[#Ajuster_la_vitesse_audio_.28ReClock.29|ReClock]] ou [[#Frame_blending_.28Smooth_Motion.29|Smooth Motion]], cette approche n'a pas une précision infinie : elle peut réduire fortement la probabilité qu'une discontinuité va apparaître pendant la lecture d'une vidéo, mais elle ne peut pas réduire cette probabilité à zéro.
+
Rappellons également que contrairement à d'autres solutions comme [[#Ajuster_la_vitesse_audio_.28ReClock.29|ReClock]] ou [[#Frame_blending_.28Smooth_Motion.29|Smooth Motion]], cette approche n'a pas une précision infinie : elle peut réduire fortement la probabilité qu'une discontinuité va apparaître pendant la lecture d'une vidéo, mais elle ne peut pas réduire cette probabilité à zéro.
  
 
=== En pratique ===
 
=== En pratique ===
Ligne 206 : Ligne 202 :
 
Contrairement à d'autres solutions décrites dans ce document, il n'est pas possible de faire ces ajustements à la volée au début ou au cours de la lecture vidéo, car les drivers GPU ne sont pas conçus pour changer ces paramètres à la volée de manière transparente.
 
Contrairement à d'autres solutions décrites dans ce document, il n'est pas possible de faire ces ajustements à la volée au début ou au cours de la lecture vidéo, car les drivers GPU ne sont pas conçus pour changer ces paramètres à la volée de manière transparente.
  
Il faut donc configurer ces "custom modes" à l'avance. Fort heureusement, [http://madvr.com/ madVR] propose un « assistant » pour vous aider à les générer ; en particulier, il est capable de mesurer la déviation d'horloge pour vous et de vous aider à trouver le bon mode, tout en vous prévenant de potentiels problèmes de compatibilité. La procédure reste tout de même relativement laborieuse. Pour plus d'informations, référez-vous au [http://madvr.com/crt/CustomResTutorial.html tutoriel de Madshi].
+
Il faut donc configurer ces "custom modes" à l'avance. Fort heureusement, [http://madvr.com/ madVR] propose un « assistant » pour vous aider à les générer ; en particulier, il est capable de mesurer la déviation d'horloge pour vous et de vous aider à trouver le bon mode, tout en vous prévenant de potentiels problèmes de compatibilité. La procédure reste tout de même relativement laborieuse. Pour plus d'informations, référez-vous au [http://madvr.com/crt/CustomResTutorial.html tutoriel de Madshi].
  
Une fois un "custom mode" adéquat généré pour une fréquence donnée (par exemple, 23.976 Hz), il suffit de l'activer avant de lire une vidéo pour profiter d'une lecture sans discontinuités. Bien que l'assistant de création fasse partie de madVR, en théorie un mode généré de cette manière peut être utilisé dans n'importe quelle application, y compris n'importe quel lecteur vidéo. Par exemple, cette solution peut être utilisée pour corriger la sortie d'une application type Netflix. Cela contraste avec d'autres solutions qui nécessitent de la « coopération » de la part du lecteur vidéo pour fonctionner.
+
Une fois un "custom mode" adéquat généré pour une fréquence donnée (par exemple, 23.976 Hz), il suffit de l'activer avant de lire une vidéo pour profiter d'une lecture sans discontinuités. Bien que l'assistant de création fasse partie de madVR, en théorie un mode généré de cette manière peut être utilisé dans n'importe quelle application, y compris n'importe quel lecteur vidéo. Par exemple, cette solution peut être utilisée pour corriger la sortie d'une application type Netflix. Cela contraste avec d'autres solutions qui nécessitent de la « coopération » de la part du lecteur vidéo pour fonctionner.
  
En plus de potentiels problèmes de compatibilité avec les écrans, et la configuration assez laborieuse, il peut également y avoir des problèmes de stabilité : comme ces "custom modes" sont statiques, ils ne s'adaptent pas automatiquement à des changements qui peuvent avoir un impact potentiel sur la vitesse des horloges audio et vidéo, tels qu'un changement de matériel (notamment un changement de sortie son) ou même des écarts de température (!). Cela dit, dans le cas spécifique où l'audio et la vidéo sont au final contrôlés par le même signal d'horloge (par exemple, les deux passent par la même sortie HDMI), la relation entre les deux horloges devrait rester fixe et le "custom mode" ainsi généré devrait en principe être parfaitement stable.
+
En plus de potentiels problèmes de compatibilité avec les écrans, et la configuration assez laborieuse, il peut également y avoir des problèmes de stabilité : comme ces "custom modes" sont statiques, ils ne s'adaptent pas automatiquement à des changements qui peuvent avoir un impact potentiel sur la vitesse des horloges audio et vidéo, tels qu'un changement de matériel (notamment un changement de sortie son) ou même des écarts de température (!). Cela dit, dans le cas spécifique où l'audio et la vidéo sont au final contrôlés par le même signal d'horloge (par exemple, les deux passent par la même sortie HDMI), la relation entre les deux horloges devrait rester fixe et le "custom mode" ainsi généré devrait en principe être parfaitement stable.
  
 
Enfin, les drivers GPU ont tendance à poser des problèmes supplémentaires en raison du cas d'utilisation bizarre et exotique, qui a la fâcheuse tendance à soulever des bugs latents. Par exemple il n'est pas rare de voir des gens se plaindre que les drivers refusent d'appliquer un custom mode sans raison apparente, ou que les modes sont effacés de manière intempestive.
 
Enfin, les drivers GPU ont tendance à poser des problèmes supplémentaires en raison du cas d'utilisation bizarre et exotique, qui a la fâcheuse tendance à soulever des bugs latents. Par exemple il n'est pas rare de voir des gens se plaindre que les drivers refusent d'appliquer un custom mode sans raison apparente, ou que les modes sont effacés de manière intempestive.
 
Sous Linux le support des "custom modes" est meilleur : [[wikipedia:X.Org_Server|X.Org]] les supporte nativement, et la pixel clock est réglable par paliers de 0.001 MHz (contre 0.01 MHz sous Windows). Cela implique cependant de modifier manuellement la configuration du serveur X.
 
  
 
= Recommandations =
 
= Recommandations =
Ligne 466 : Ligne 460 :
 
|style="background-color:#fdd;"|Mauvais
 
|style="background-color:#fdd;"|Mauvais
 
|-
 
|-
!Nécessite un logiciel de lecture spécifique<br />([http://madvr.com/ madVR], [http://www.zachsaw.com/mpdn/ MPDN], [https://mpv.io/ mpv], etc.)
+
!Nécessite un logiciel de lecture spécifique<br />([http://madvr.com/ madVR], [http://www.zachsaw.com/mpdn/ MPDN], etc.)
 
|style="background-color:#dfd;"|Non
 
|style="background-color:#dfd;"|Non
 
|style="background-color:#dfd;"|Non
 
|style="background-color:#dfd;"|Non

Notez bien que toutes les contributions à NoFrag peuvent être modifiées, transformées ou supprimées par d’autres utilisateurs. Si vous ne désirez pas que vos écrits soient modifiés contre votre gré, merci de ne pas les soumettre ici.
Vous nous promettez aussi que vous avez écrit ceci vous-même, ou que vous l’avez copié d’une source provenant du domaine public, ou d’une ressource libre. (voir NoFrag:Copyrights pour plus de détails). N’UTILISEZ PAS DE TRAVAUX SOUS DROIT D’AUTEUR SANS AUTORISATION EXPRESSE !

Annuler Aide pour la modification (s’ouvre dans une nouvelle fenêtre)