Seb.26 a écrit:... de ne plus utiliser le timestamp de directshow, et de forcer du 25fps sur la VSync ?
... car là, l'ecart est minime ( la ligne rouge un ou deux pixels au dessu ou en dessous ) mais ça suffit pour rater la VBL je pense ...
Je mesure le temps juste
après que l'image soit affichée, donc un écart de quelque pixels n'est pas génant à mon avis (sachant que cela correspond a une poignée de µs). La fonction "Present" de D3D est appelée juste un peu avant le timecode de presentation, et en interne elle attend le VSync
Difficile de comparer mes courbes avec celles de Haali je ne pense pas que l'on mesure la même chose.
La ligne rouge parfaitement alignée sur la bleue n'est pas significatif car cela veut dire que le décodeur m'envoi des durées farfelue pour les échantillons et donc je ne dessine pas la courbe
Dans la prochaine version je vais faire moi même une estimation du framerate pour ne plus être embêté.
Seb.26 a écrit:ce que je disais, c'est que par exemple si tu prend une vidéo de mire avec un debit ridicule, une resolution pourrie, donc un CPU à 3%, parfois c'est toujours pas parfaitement fluide ... et que c'est dû à directshow, car c'est lui qui decide de "quand" doit être affiché une frame, alors que l'ideal serait d'en afficher une par VBL ( vertical blank : donc une image "physique" )
Normalement Direct3D attend la VBL pour nous (oui je sais faut pas toujours faire comfiance a Microsoft
).
Par contre les saccades peuvent être liées a des timestamp DShow complétement foireux. J'ai un exemple de fichier ou toutes les 3s tu as deux images espacées de 80ms au lieu de 40, et du coup la vidéo saccade a intervalle réguliers!
Avec l'EVR custom j'ai ma maitrîse compléte du séquencement des images, alors peut être que dans ce cas il y aurais un moyen de résoudre le problème...
Si tu veut te lancer dans un comparatif attend un petit peu je vais resortir un nouvelle version dans pas longtemps avec plusieurs bugs génant corrigés.