Du Tearing et de la fluidité (notamment en PAL)

[Cat01]

Au fait, Je propose un retour au sujet du post (référencement des projos)
et un dévelloppement de la théorie plutôt dans le post correspondant dans le forum PCHC... (pour "trier" un peu)


lien : http://www.homecinema-fr.com/forum/viewtopic.php?t=29716324

[MLill]

Bonjour à tous

Le DL500 (et tous les Davis cousins) a deux fréquences de roue 100HZ (PAL et VGA 75HZ) et 120HZ (NTSC et VGA 72HZ).

Je n'ai jamais eu l'impression qu'il perdait des trames et j'ai lu qu'il faisait du "triple buffering". En tous cas je n'ai jamais noté de tearing.
Je n'ai jamais essayé d'élucider si il faisait une conversion 72HZ -> 60HZ -> 120 HZ ou directement 72HZ -> 120HZ (ce qui est bien mieux).

Nette dégradation de la fluidité en passant au menu unique 56HZ du HS10.

Michel

[Emmanuel Piat]

Je pense aussi qu'il ne faut pas confondre tearing et fluidité.

Le tearing s'est quand on commence à dessiner une trame, et qu'en court d'affichage de la trame le buffer qui contient l'image à afficher est remis à jour. Le projo va alors continuer à dessiner la trame avec de nouvelles données ! Si l'ancienne trame et la nouvelle sont bien différente, on voit alors clairement la ligne ou il y a eu chgt de trame. Si votre projo affiche à 60 Hz, cet artefact sera visible pdt 1/60 de sec...

En pratique le double buffering ne permet pas de s'affranchir de ce phénomène génant (il faut au moins 2 buffers ds un projo : un pour recevoir les info vidéo qui sont à une frequence donnée et un autre pour stocker les infos qu'affiche la matrice (après les traitements internes) avec sa propre fréquence).

Seul le triple buffering permet d'être certain que ce phénomène n'apparaitra pas.

Par contre, de mémoire il me semble que le triple buffering ne garanti pas qu'une trame ne sera pas sautée pdt le processus de synchronisation entre la fréquence du lecteur et la fréquence de travail de la matrice. Cette gestion des trames est effectuée ds le buffer intermédiaire... De toute façon, si la fréquence d'affichage n'est pas un multiple exact de la fréquence du player, on peut avoir un pb de fluidité sur les travelling. Par exemple, sur l'exemple qui suit la trame n°5 est shintée...

|..........|..........|..........|..........|..........|..........|..........|
|.............|.............|.............|.............|.............|

A approfondir...

@+
Emmanuel

[HBK]

Le tearing s'est quand on commence à dessiner une trame, et qu'en court d'affichage de la trame le buffer qui contient l'image à afficher est remis à jour. Le projo va alors continuer à dessiner la trame avec de nouvelles données ! Si l'ancienne trame et la nouvelle sont bien différente, on voit alors clairement la ligne ou il y a eu chgt de trame. Si votre projo affiche à 60 Hz, cet artefact sera visible pdt 1/60 de sec...

En pratique le double buffering ne permet pas de s'affranchir de ce phénomène génant (il faut au moins 2 buffers ds un projo : un pour recevoir les info vidéo qui sont à une frequence donnée et un autre pour stocker les infos qu'affiche la matrice (après les traitements internes) avec sa propre fréquence).

Seul le triple buffering permet d'être certain que ce phénomène n'apparaitra pas.

Par contre, de mémoire il me semble que le triple buffering ne garanti pas qu'une trame ne sera pas sautée pdt le processus de synchronisation entre la fréquence du lecteur et la fréquence de travail de la matrice. Cette gestion des trames est effectuée ds le buffer intermédiaire... De toute façon, si la fréquence d'affichage n'est pas un multiple exact de la fréquence du player, on peut avoir un pb de fluidité sur les travelling. Par exemple, sur l'exemple qui suit la trame n°5 est shintée...

Je connais bien le probleme des buffers en rendering video "temps reel", c'est pourquoi je me permets quelques remarques, meme si je sais pertinement que les problèmes de VP n'ont pas grand chose à y voir.

Tout d'abord ta définition du tearing est exacte, mais je pense qu'il est bon de preciser ce que ca fait "visuellement" pour etre sur que ce soit bien compris (le tearing n'a effectivement pas grand chose à voir avec la fluidité).
Pour faire simple, le "tearing" c'est quand le "haut" de l'image ne correspond pas parfaitement au "bas" de l'image, d'ou l'illusion d'une ligne qui découperai l'image en deux (tearing = déchirement en anglais).
Et cet artefact, s'il est présent ne sera effectivement visible que pendant 1/60e de seconde, mais sera présent sur la plupart des images, et on aura donc l'impression de voir la ligne se balader sur l'ecran.

Ensuite tu dis qu'il faut d'une part un buffer pour recevoir en permanence les infos de la source, et un buffer pour l'afficher sur la matrice (balayé avec l'equivalent d'un RAMDAC)
Je veux bien, mais dans ce cas aucun processing video n'est possible, si tu processe sur le buffer "ecran" -> pas cool car tu vas generer pas mal de "flicking", et si tu processe le buffer "source" -> impossible car par définition le buffer source doit toujours rester disponible pour stocker les trames (ou images) en provenance de la source.

Par contre avec du triple buffer, tu as ton buffer "ecran" apres processing, ton buffer "source" toujours dispo, et un buffer de "travail" dans lequel tu peut foutre le souk jusqu'au swap suivant.

Mais dans les deux cas il n'y a pas de tearing si les "SwapBuffers" sont syncrhonisés correctements (sur fin de balayage source). Et c'est là qu'intervient un probleme lié aux DLP ... le "SwapBuffer" est conditionné par la rotation de la roue chromatique, qui est en général fixe, ou avec des reglages possibles figés (cad non-linéaires). Il n'est pas alors possible (lorsque la source n'est pas calée sur un refresh multiple de celui du projo) de syncrhoniser le "Swap" a la fois sur la source, et sur la rotation chromatique, d'ou des echanges de buffers qui se font au "mauvais" moment, et donc un dechirement apparent de l'image.

Pour finir ce qui m'etonne, c'est que les processings video assez complexes qui sont effectués ne necessitent pas plus d'un seul buffer, mais je me trompes peut etre (c'est vrai qu'un scaling ca n'est pas si compliqué).

Bon enfin je fais tout ce raisonnement en live, alors soyez zindulgents, mais c'est mon job de faire basculer des buffers dans des cartes video alors je ne peux pas m'en empecher

[Emmanuel Piat]

Tout cela est très intéressant. Donc si je te suis ts les projo digitaux ont au minimum 3 buffers.

Dans ce cas de figure, j'avoue ne pas encore comprendre exactement pourquoi certaines fréquences engendrent du tearing et d'autre pas sur les dlp (et les lcd ?)

En gros, pourquoi, pour certaines fréquences, le projo remet à jour le buffer dédié à la "matrice" pendant l'affichage d'une trame ???

@+
Emmanuel

[WhyHey]

Je veux bien, mais dans ce cas aucun processing video n'est possible, si tu processe sur le buffer "ecran" -> pas cool car tu vas generer pas mal de "flicking", et si tu processe le buffer "source" -> impossible car par définition le buffer source doit toujours rester disponible pour stocker les trames (ou images) en provenance de la source.

il consiste en quoi le processing en question ?
merci

[WhyHey]

sur les dlp (et les lcd ?)

+1, pourquoi y'a pas ce pb sur les LCD aussi
A moins qu'il existe tout autant
mais en lisant vos posts j'avais l'impression que c'etait un pb purement DLP, comprend pas

Tcha

[FreqResPlot]

Je vais peut être dire une connerie mais la matrice en elle même ne dispose-t-elle pas forcément de son propre frame buffer ? Je veux dire par là que triple buffer = 2 buffers externes + 1 buffer dans la puce lcd/dlp ?

C'est juste une idée comme ça ( ? )...

Pascal

[Emmanuel Piat]

explication sur le triple buffering (pas encore eu le tps de lire) :

http://www.osr.com/ddk/graphics/ddraw_25d3.htm

[FreqResPlot]

sur les dlp (et les lcd ?)

+1, pourquoi y'a pas ce pb sur les LCD aussi
A moins qu'il existe tout autant
mais en lisant vos posts j'avais l'impression que c'etait un pb purement DLP, comprend pas

Tcha

Non non ça touche aussi bien les LCD que les DLP, c'est pourquoi je suppose qu'il se passe la chose suivante en temps normal:

(! pure spéculation attention !)

Je viens de me rappeler d'un détail très important, la matrice n'a pas de buffer propre, elle se sert des autres buffers qui sont en double accès (2 bus qui mènent aux mêmes données), donc il y a bien 2 buffers et pas 3.

Cas du double buffer:

- Le buffer 1 lit l'entrée video et se remplit au fil des lignes
- Pendant ce temps, la matrice affiche le contenu du buffer 2.
- Arrive le vertical blank , on switche les buffers 1 & 2, le 2 se remplit maintenant avec les données vidéo pendant que le 1 sert à l'affichage sur la matrice.

Maintenant le cas du tearing:

Si la matrice est, par construction, incapable de dépasser 60Hz, mais que le buffer 1 se remplit à 75Hz par exemple il est donc rempli avant le vertical refresh, obligeant le swap des buffers sinon l'image suivante est totalement perdue, le switch se passe à n'importe quel moment donc on a un bout de l'ancienne image en haut et la nouvelle en bas. et ainsi de suite.

Bon, c'est encore juste une idée comme ça, mais le cas du triple buffer: (j'imagine toujours je précise ! je peux raconter n'importe quoi je suis pas concepteur de projo )

Buffer 1 2 3:

- Le buffer 1 se remplit avec l'entrée vidéo T
- Le buffer 2 contient l'image numérisée à T -1
- Le buffer 3 affiche l'image T -2

Si tout est synchro, on swap tout le bordel en même temps:

- Le buffer 3 se remplit avec l'entrée video T+1
- Le buffer 1 contient l'image précédente T
- Le buffer 2 affiche l'image T-1

et ainsi de suite

Maintenant si c'est pas synchro, là ça se corse (j'imagine toujours hein, j'en sais rien je re-précise)

- Le buffer 1 se remplit avec l'entrée vidéo T
- Le buffer 2 contient l'image numérisée à T -1
- Le buffer 3 affiche l'image T -2

or le buffer 1 sera remplit avant que le buffer 3 ait fini d'afficher l'image T-2, et bien tant pis on jette le buffer 2 qui devient buffer 1, et le buffer 1 passe en attente de synchro avec la matrice:

- Le buffer 2 se remplit avec l'entrée vidéo T+1
- Le buffer 1 contient l'image numérisée à T
- Le buffer 3 contient l'image T -2

Là interviens le vertical blank de la matrice, le buffer 2 est toujours en train de se remplir:

- Le buffer 2 se remplit avec l'entrée vidéo T+1
- Le buffer 3 est libre (ancienne image numérisée à T-2)
- Le buffer 1 affiche l'image T

Puis le buffer 2 a fini:

- Le buffer 3 se remplit avec l'entrée vidéo T+2
- Le buffer 2 contient l'image T+1
- Le buffer 1 affiche l'image T

etc

Donc si l'entrée est à 75Hz et la matrice à 60Hz on perd une trame complète de temps en temps, mais on a jamais de tearing.

A l'inverse si on est en 50Hz le problème est le même mais à l'envers, au lieu de jetter une image, on l'affiche 2 fois en attendant que le buffer video ait fini de se remplir.

Qu'en dites vous ?

Pascal

[MLill]

Par contre, de mémoire il me semble que le triple buffering ne garanti pas qu'une trame ne sera pas sautée pdt le processus de synchronisation entre la fréquence du lecteur et la fréquence de travail de la matrice

En 75HZ PAL ou 72HZ NTSC la même image du film est répétée 3 fois.
En situation idéale à 100HZ (vitesse de la roue) en PAL chaque image devrait être répétée 4 fois.
A l'oeil cela ne me semble pas le cas et je suppose que certaines sont répétées 3 d'autres 4 et d'autres 5.
D'où un peu plus de temps passé sur certaines images (5 fois) que sur d'autres (3 fois).
Par contre je ne pense pas qu'une image soit sautée ou répétée seulement une ou deux fois.
A étudier : la conception d'une séquence vidéo permettant de mesurer le phénomène.

Michel

[Emmanuel Piat]

Pascal, je pense que tu as bien fait progresser la réflexion. Je vais réfléchir à ça en détail cet AM.

>A étudier : la conception d'une séquence vidéo permettant de mesurer le phénomène.

Pas simple car le phénomène est rapide.

Michel, on pourrait imaginer une barre qui progresse de la gauche vers la droite en 1 sec (donc en 25 étapes en PAL).

Si la vitesse de prog n'est pas constante à l'oeil, c'est que chaque image n'est pas répétée le même nb de fois. Si j'ai le temps, j'encode ça ce WE.

@+
Emmanuel

[HBK]

Tout cela est très intéressant. Donc si je te suis ts les projo digitaux ont au minimum 3 buffers.

Dans ce cas de figure, j'avoue ne pas encore comprendre exactement pourquoi certaines fréquences engendrent du tearing et d'autre pas sur les dlp (et les lcd ?)

En gros, pourquoi, pour certaines fréquences, le projo remet à jour le buffer dédié à la "matrice" pendant l'affichage d'une trame ???

@+
Emmanuel

Je n'ai pas été assez clair apparement.
Sur un DLP tu doit d'une part synchroniser le SwapBuffer sur la rotation de la roue chromatique, et d'autre part sur le balayage video de la source.
Si la roue demande un swap video à 60Hz, et la source a 50Hz : problème ... soit tu bascule alors que la roue n'a pas finie de faire le tour de ses couleurs, et la aie aie les ars-en-ciel géants ... soit tu fait comme tout le monde, tu bascules quand ta roue chromatique a finie de "tourner", et du coup y'a du tearing.
Le seul moyen de l'eliminer c'est de mettre suffisement de buffers pour qu'aucune image ne soit perdue, et que l'on bascule du coup quand il faut, mais a ce moment la il va y avoir un souci de fluidité : exemple d'une roue a 60Hz, et d'un signal a 50Hz, avec 5 buffers supplémentaires tu stockes tout ce que ta balances la source, et pendant ce temps tu peut switcher les images a chaque tour de roue, mais comme il y en a 6, la ou il y a 5 balyages video de la part de la source, tu doit repeter la deniere, d'ou un aspect haché de l'animation (meme si ca reste *assez peu* visible).

J'espere que c'est plus clair comme ca

[HBK]

il consiste en quoi le processing en question ?
merci

Scaling, flitrage spatial (bilinéraire) ou temporel (prog scan), ré-étalonnage des couleurs, mirroring etc ...

[HBK]

sur les dlp (et les lcd ?)

+1, pourquoi y'a pas ce pb sur les LCD aussi
A moins qu'il existe tout autant
mais en lisant vos posts j'avais l'impression que c'etait un pb purement DLP, comprend pas

Tcha

Sur un LCD il n'y a pas de contrainte de "synchro" liée a l'affichage**, seulement la contrainte standard de se syncrhoniser sur la source, ce qui est assez facile

** rotation de la roue chromatique sur un DLP, balayage du faisceau electronique sur un CRT (tube cathodique)

Edit : J'avais marqué LCD au lieu de DLP