Rendu des vidéos, pixels et texture sur youtube et autres.

jean-thevenet · 09-05-2019 12:53:11

Voilà: j'explique tout ça avec essais, saisies d'écran références.
J'attends vos réactions

http://thevenet.jean.free.fr/texture-et … video.html

jean-thevenet · 09-05-2019 22:14:06

poussé encore les investigations. Détails sur la page

Soit un original 1080p 17Mb/s
A copie 5Mb/s h.265 1080p meilleure à l'écran (de très peu) par rapport à B
B copie 10Mb/s h.264 extrapolée en 1440p (un peu plus de texture de fréquences spatiales élevées)

A et B sont d'une différence qualité quasi indiscernable à l'écran (sur écran 1080p), alors que B fait le double de poids de fichier.

A=upoloadé=>youtube=>a lu-lecteur-youtube-1080p: mauvais (même sur écran 720P)
B=upoloadé=>youtube=>b lu-lecteur-youtube-1080p: meilleur, mais pas aussi bon que c et encore bien en dessous de A ou B
B=upoloadé=>youtube=>c lu -lecteur-youtube-1440p meilleur, et peu en dessous de A ou B

Les saisies d'écran d'une portion d'image pixellisées par du mouvement sont disponibles à http://thevenet.jean.free.fr/texture-et … video.html

Dernière modification par jean-thevenet (09-05-2019 22:18:29)

jean-thevenet · 11-05-2019 00:20:44

Croutons a écrit :

Bonsoir
J'ai regardé les vidéos que j'avais téléchargé faute de connexion suffisante , mais tu je ne peux en tirer aucune conclusion vu que les formats ne sont pas les mêmes
Un super compressé (mkv) avec une profondeur de couleur trop basse et l'autre en meilleur résolution
je reste persuadé que regardé une vidéo qui dépasse la capacité de l'écran n'apporte rien, c'est une question de logique et pour l'instant rien ne m'a prouvé le contraire

pourtant ça se voit, même avec les aperçu qui ne remplissent pas l'écran (textures dans vidéo en mouvement)
台鐵平溪線深澳線菁桐-八斗子路程景

Croutons a écrit :

mediainfo /home/stephane/dwhelper/20190426\ route\ bugey\ conzieu\ ambleon\ extrapolé\ 2k\,\ cette\ fo.webm

General
Complete name : /home/stephane/dwhelper/20190426 route bugey conzieu ambleon extrapolé 2k, cette fo.webm
Format : WebM
Format version : Version 4 / Version 2
File size : 332 MiB
Duration : 5 min 28 s
Overall bit rate : 8 478 kb/s
Writing application : Lavf58.12.100
Writing library : Lavf58.12.100 / Lavf58.12.100

Video
ID : 1
Format : VP9
Codec ID : V_VP9
Duration : 5 min 28 s
Width : 2 560 pixels
Height : 1 440 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 FPS
DURATION : 00:05:28.166000000

LÀ on a du VP9, j'en ai pas vu sur ma vidéo, j'avais du H.264, Mais regardes un peu mieux la différence sur les GRAVILLONS de la route.
https://www.youtube.com/watch?v=P1GWFGJZ8LA
https://www.youtube.com/watch?v=Bz7kH8gzeqI

Croutons a écrit :

mediainfo /home/stephane/dwhelper/20190426\ route\ bugey\ conzieu\ ambleon\ extrapolé\ 2k\,\ cette\ foi.mkv

General
Unique ID : 142492978558679847167708505482595779657 (0x6B332640DAE23C08D9ED68E18825C449)
Complete name : /home/stephane/dwhelper/20190426 route bugey conzieu ambleon extrapolé 2k, cette foi.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 181 MiB
Duration : 5 min 28 s
Overall bit rate mode : Variable
Overall bit rate : 4 615 kb/s
Writing application : Lavf58.12.100
Writing library : Lavf58.12.100 / Lavf58.12.100
ErrorDetectionType : Per level 1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 5 min 28 s
Bit rate : 4 395 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.071
Stream size : 172 MiB (95%)
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
DURATION : 00:05:28.166000000
HANDLER_NAME : ISO Media file produced by Google Inc. Created on: 04/26/2019.

Dernière modification par jean-thevenet (11-05-2019 00:26:59)

jean-thevenet · 11-05-2019 16:33:47

Croutons a écrit :

bonjour
je sais plus trop ou te répondre vu que plusieurs poste en cours
j'ai étudié ton lien
http://thevenet.jean.free.fr/texture-et … video.html
Tu te mélanges complètement tire des conclusions qui ne sont pas vrai
Pour exemple
Avoir une télé 4K sert donc quasiment à rien, sauf pour un autre usage moins répandu regarder des formats qui pèsent des dizaines de Go pour une heure, au lieu d'aller dans une salle de cinéma (on se dit qu'on les téchargera bien un jour avec la fibre ou la 5G, mais c'est multiplier beaucoup les data pour dépasser un optimum qu'on a atteint avec la HD: cette haute définitions est supérieure à celle de l'oeil humain sauf à être trop près de l'écran, écran qui par sa taille ne peut plus servir à autre chose qu'à regarder des films!)

la 4k apporte quelque chose arrivé a une certaine taille d'écran passé 130centimetres de diagnonale
c'est le soucis avec cette nouvelle façon commerciale de nous donner les caractéristiques d'un écran, avant on nous causait pitch la on savait de quoi on parlait seulement c'était pas assez parlant pour le consommateur semble t'il

Il faudrait ne pas dépasser les 1080p pour commencer , le problème de texture ne vient pas de la résolution a coup sur
faire des essaies avec différent taux de compression
avec une compression trop importante l'image ne sera pas belle mais le débit passera sans soucis
avec une taille de fichier trop lourd l'image sera belle mais risquera de dépasser la bande passante (surtout si tu es en adsl), pas de soucis en théorie avec la fibre mais la encore si les serveurs youtube sont saturé cela posera problème , et comme je soupçonne qu'il leurs arrive de saturer le problème reste entier

"la 4k apporte quelque chose arrivé a une certaine taille d'écran passé 130centimetres de diagnonale"
ou si on est assez près pour profiter du pitch à cette échelle, avec cette définition l'écran doit être "grand" du point de vue angulaire (écran petit vu de plus près ou à la loupe, tel les smartphones à écran QHD avec lunette de réalité virtuelle), ou écran grand, vu pas de trop loin: si c'est un écran de cinéma, aller se mettre dans les sièges au premier rang (ce n'est pas d'ailleurs la meilleure place pour appréhender toute l'image, mais la tendance de tourner au grand angle force peu à peu à se mettre plus près pour retrouver la même perspective que dans la réalité, en étant plus immergé)

"avec une compression trop importante l'image ne sera pas belle mais le débit passera sans soucis"

c'est justement à cause de ça que le format 1440p est le minimum acceptable pour regarder sur un écran HD-1080, ils ont trop compressé pour qu'on regarde facilement en streaming. Cela donne de bon résultats pour les vidéos d'émission de plateau, restitue encore très bien les narcissiques à peau lissée et femmes enduites de pâte à peau anti-fissures, qui parlent à l'écran avec un fond peu mobile derrière (moins de surface d'image en modification rapide, moins de données), ça marche encore pour le walking en ville (beaucoup de surfaces unies et de lignes facile à compresser, de redondance), ça commence à moins marcher pour les mecs mal rasés qui bougent (texture de la barbe), ça ne marche plus pour le walking en forêt, les prés d'herbe haute au vent, et les paysages forestiers à forte texture, ce que j'ai tenté de montrer ici avec exemple à l'appui.
Autre exemple: https://www.youtube.com/watch?v=_0Syq3eqUN0 avec pourtant un gimbal, ça marche bien en ville, mais lors de la traversée de la forêt il y a souvent des pixellisations importantes. Le codec employé semble le VP9, qui "accepte" de rendre l'image une partie du temps et qui baisse en qualité d'un coup si débit insuffisant (ça ne vient pas de la connexion, c'est limage qu'est ainsi codé)

"Il faudrait ne pas dépasser les 1080p pour commencer , le problème de texture ne vient pas de la résolution a coup sur
faire des essaies avec différent taux de compression "
Fait: youtube ne rend jamais la qualité au delà de 2.5Mégabits/seconde/mégapixel (3.3 en 60Hz): des qu'on envoie des vidéo de qualité supérieure, il les recompresse à cette limite et on perd entre la copie envoyée et ce qui est rendu disponible. Toutefois la version 1080p semble tout de même meilleure quand l'upload en 1440p a permis de réencoder chez youtube, non pas en h.264, mais en on2 VP9 la version .WEM, en 4.2Mb/s du 1080p, donc il faut envoyer ses upload tiré d'originaux 1080p ou 1440 au moins en 1440 10Mb/s, pour avoir en retour un possible 1080p en 4.3Mb/s dans un codec plus performant que le h.264. Envoyer du h.264 peu compressé (genre du 1080p à 17Mb/s) devient sur youtube un mauvais h.264 à 4.3Mb/s, alors que pour de la fullHD, il faut au moins 10Mb/s pour que ça soit correct, en h.264, ou 5 en h.265.

Le problème de texture provient de la résolution (dans le sens quantité de donnée) par ce qu'ils accordent un débit proportionel à la définition, lequel débit n'est que 30 à 50% du correct pour rendre les textures. 30% si c'est du h.264, 50% si c'est du VP9
C'est pour cela que pour le traduire je parle du débit en Méga-bite/seconde/mégapixels et si pas assez de bites on l'a dans le Q

Alors dire que la définition est supérieur a l'oeil humain est une aberration
Dans le cas "pratique" où l'on se sert d'un écran 4k pour voir un film à une distance "normale" (quand on s'en sert comme une grande télé), à moins que l'écran soit géant ou très près.
La qualité des vidéos de youtube ne permet pas d'être aussi près: l'eau qui bouge, l'herbe, les arbres paraissent trop lissé, les contours sont net, pas les intérieurs des surfaces représentés...
rappel: les saisie écran sur https://debian-facile.org/viewtopic.php … 51#p299851 Le format "1080" de youtube n'est là même pas à la hauteur d'un écran 720p...

quand ça ne bouge pas et que les détails peuvent se dessiner dans les sombres et demi-teintes, là oui, la qualité peut atteindre celle de l'écran.
Le cas de vidéos qui permettent cette qualité sont plutôt "de la photo qui bouge"... (des paysages filmés sans bouger, de loin ou avec un déplacement relatif loin (drone en altitude). Cependant pour ce genre d'image pourtant peu mobiles, on voit encore la différence (en HD la version 2k pixelise moins sur les demi-teintes https://www.youtube.com/watch?v=Xjs6fnpPWy4)

Pour en revenir au tearing peut importe le bureau utilisé, si aucun soucis en visionnage locale , le problème serait + au niveau de la bande passante internet

Non: car ça le fait aussi sur les fichiers en local et quand internet ne suffit pas ça fait des pauses, carrément. Je pouvais lire sans tearing ni saccade des vidéos qui sont 5 à 10 fois plus lourdes que sur internet (débit vidéo de l'ordre de 60Mb/s). À la Réunion (Cilaos), internet permet de lire le 1440p de youtube (20Mb/s), en métropole, il faut attendre le cache rempli pour faire l'essai, ou télécharger (8Mb/s).

Dernière modification par jean-thevenet (14-05-2019 17:50:01)

jean-thevenet · 12-05-2019 18:41:50

J'ai réduit une image typique (le paysage vu d'une voiture), filmé en 1440p pour youtube pour redimensionner l'échelle du crop en équivalence 480p.

Bilan. Pour regarder ce paysage, même sur un écran de 480p, on voit encore la différence: le format FULLHD de youtube, le 1080p, n'est pas à la hauteur du format DVD pour les images de paysage qui bougent.

1440p lu sur un écran 480p

crop-ecran-480p_de_lecture-en-1080p..jpg

1080p lu sur un écran 480p: on voit la différence: l'herbe!!!

c'est étonnamment dégueulasse mais là c'est pas nickel-chrome du tout, c'est chrome seulement.

Si c'était le flou de bougé ou la qualité de la caméra, on ne verrait pas la différence: les défauts grossiers seraient identiques d'une version à l'autre

Dernière modification par jean-thevenet (14-05-2019 17:51:42)

jean-thevenet · 14-05-2019 11:24:37

Mise à jour du dossier.
J'ai découvert une ÉNORME différence de qualité sur un arrêt d'image Chrome, Chromium-youtube (sur l'image décodée, en arrêt sur image): Chrome a un rendu du fullHD qui présente des défauts encore visibles sur un écran 480p (télévision des années huitante)

Comparez
chromium-1080p
chrome-1080p
GROSSE DIFFÉRENCE
L'image se construit par pavage car Chrome ne termine pas le travail (ET ÇA NE CHANGE PAS AVEC L'ACCÉLÉRATION MATÉRIELLE ENFIN FONCTIONNELLE!!!), j'ai mis en noir et blanc les zones sans textures pour vous les montrer, quelques exemple car ce pavage de carrés floue occupe la majeure partie de l'herbe.
Je me suis demandé alors si Chrome ne lisait pas une version streaming différente: la version HD.MP4 et HD.MKV faisaient le même poids, mais ont toutes deux la même qualité une fois téléchargées.

download-1080p.mp4 4.7MB/s
download-1080p.mkv 4.7MB/s
RENDU IDENTIQUE

l'original uploadé était en 1440p ces versions 1080p sont recalculée par youtube en meilleure qualité que si je les avait envoyé directement en 1080p (vérification qui a été faite aussi, même en forçant la qualité du upload)

C'est donc le lecteur intégré de chrome qui ne fonctionne plus car une telle dégradation de qualité n'est pas acceptable (une vidéo HD devrait pas présenter des artefacts sur une version fullHD qu'on voit même sur écran 480p: la télévision ordinaire, celle pour laquelle avait été conçu les DVD).

En examinant la façon dont il rempli l'écran cette dégradation semble être la cause de toutes ces saccades, c'est qu'il rempli l'image par mosaïque dont le pavage fait environ au juger dans les 100 par 100 pixels.
Le bruit dans l'alimentation (appels de courant) dénotent un travail mal fait qui charge le processeur, que chrome confie au CPU au lieu de confier à la carte graphique.
C'est ce mode d'affichage "accéléré" par mosaïque qui pose peut être aussi tous les problèmes de https://debian-facile.org/viewtopic.php?id=24307

J'ai en effet rétrogradé quelques trucs liés à OpenGL et retrouvé un fonctionnement normal des autres lecteurs vidéo, sauf firefox dont le tearing se résoud (assez bien mais avec quelques sauts isolés), en créant le fichier pour faire fonctionner la carte en mode graphique SNA (ce un problème de non-utilisation de l'accélération matérielle qui ne joue pas sur le décodage d'une image qu'on arrête à l'écran).
Car ce qui est curieux en effet, c'est que le "pavage" de Chrome s'arrête net si on appuie sur pause: c'est donc un "travail" qu'il fait en interne, qui n'est pas dans un cache quelconque en attente de calcul dans une librairie et autre. Peut être que c'est un "module" à lui.

Chrome dysfonctionne au delà de son lecteur vidéo, ces défauts d'appels de courant, saccades et déchirement d'images se manifeste aussi lors du défilement des pages de texte.

Dernière modification par jean-thevenet (14-05-2019 19:51:46)

jean-thevenet · 14-05-2019 19:47:09

Reste à vérifier la différence sur ce passage

ici lu avec chromium en 1080p: ça ne suffit pas pour admirer Taiwan en train.
Maintenant que Chrome marche, en 1440p qu'est ce que ça donne?

LA DIFFÉRENCE SE VOIT sans même avoir besoin de charger en plein écran cette image, si le débit était bien géré, on ne devrait théoriquement pas pouvoir voir la différence sur un écran seulement fullHD... on est très loin de la résolution du 1080p surtout avec la première!!! (résolution faible par rapport à la définition d'image)

Les vidéos envoyés en h.264 1440p sont meilleures lues sur chromium depuis youtube, si on les regarde en 1080p qu'avec chrome et firefox

Il se pourrait que les vidéos envoyés en 4K genre et du coup encodés en VP9 soient meilleures sur Chrome que sur chromium, c'est le cas de 4K 台鐵 402次TEMU1000太魯閣號花蓮-台東路程景 (si lues en HD-1080).

Ces problèmes semblent une façon "bizarre" de lire les vidéos en tentant d'économiser des données, et qui défavorise le h.264, sur certaines vidéo qui semblent être en vp9 chrome s'en sort mieux car il réparti le flou dans les bon intervalles de temps, il semble aussi que chrome lit mal le h.264, il fait des gros pixels flous pour moins en charger.
C'est peut être commercial, comme ça ça fait moins chauffer les serveurs à visionner une version dégradée et il nous suggère que le VP9 c'est au top et que le reste c'est de la merde (et on en trouve de la merde sur youtube). Mais là c'est croire à la théorie du complot

Dernière modification par jean-thevenet (14-05-2019 19:54:40)

jean-thevenet · 01-02-2021 15:59:38

J'ai re exploré le sujet: BILAN sur http://thevenet.jean.free.fr/test-bourrage-youtube.html

La différence Chrome, Chromium sur lecture youtube 1080p était du au fait que chromium n'ayant pas le codec vp9 charge la version mp4 alors que chrome charge la version webm, qui en 1920 par 1080 EST MOINS BONNE.

Mis en code pour police à chasse fixe.

débit adapté à l'envoi

, conseillé avec GOP15 B2, l'équivalent qualité avecGOP150 à 300 B3 avec libx264 et libx265

       conseillé|  libx264-|--libx265-| webm-publié| mp4-publié

1080-30fps   8  |  6 -  8  |  3 -  4  |     2.8    |    3.7

1080-60fps  12  |  9 - 12  |  5 -  6  |     4.1    |    5.7

1440-30fps  16  | 12 - 16  |  6 -  8  |     8      |

1440-60fps  24  | 17 - 24  |  9 - 12  |     12     |

2160-30fps  40  | 28 - 32  | 12 - 20  |     18     |

2160-60fps  60  | 42 - 48  | 18 - 30  |     22     |

Réglage selon qualité

vrai 4K choisir CRF 25 maximum

Faux 4K (exemple le 2.7K d'une GoPro converti en 4K), CRF 27 maximum

Dernière modification par jean-thevenet (01-02-2021 16:26:43)

Croutons · 01-02-2021 17:13:35

salut
le réglage de qualité CRF est 23 par défaut avec libx264 , plus le chiffre augmente moins bonne sera la qualité
le techniquement sans perte est au alentour de 17 , 18
les même valeur avec le codec libx265 ne correspondent pas avec libx264(je mettrais le lien vers le wiki)

Dernière modification par Croutons (01-02-2021 17:13:58)

jean-thevenet · 03-02-2021 08:21:56

les même valeur avec le codec libx265 ne correspondent pas avec libx264

En examinant image par image, je constate plutôt que à CRF équivalent ça se vaut: le libx264 donne à qualité (CRF) égale des fichiers un peu plus encombrants, mais si ça bouge beaucoup avec beaucoup de textures, le h.265 devient quasi aussi encombrant pour beaucoup plus de consommation d'encodage et est donc inintéressant pour l'archivage en haute qualité. La différence d'efficacité de compression se creuse si l'image contient des zones inanimés, peu changeantes, qu'il y a des surfaces lisses et qu'on a choisi une compression plus forte que CRF 25.
Le libx265 est plus efficace en forte compression pour gérer des contours et des "à plat" unis en mouvement, mais pas tant pour les textures telles le grain.
Le h.264 est intéressant pour mon usage de CRF 17 à 25 et le Libx265 de CRF 25 à 27 car là ça compresse réellement plus.

Dernière modification par jean-thevenet (03-02-2021 08:24:29)

Croutons · 03-02-2021 08:47:41

l'option CRF est un réglage de qualité ceci joue sur le poid du fichier, il suffit de faire un essai avec CRF40 pour avoir de belle mosaïque
mis je pense pas que cela joue sur le taux de compression
https://trac.ffmpeg.org/wiki/Encode/H.2 … tsandtunes

jean-thevenet · 04-02-2021 18:46:46

C'est clair que ça veut dire Constant Rate Factor, et l'intérêt du CRF est bien là: choisir la qualité d'image voulue et que ça se débrouille, c'est ce que j'ai pensé en voyant que c'était quasi identique pour le même CRF quelque soit le codec, et évidemment, si le codec est plus performant, le même CRF correspond à un débit binaire moindre. Cependant, le h.264 semble plus optimisé pour la haute qualité, alors que le h.265 est surtout intéressant pour les copies fortement compressée.

jean-thevenet · 05-02-2021 06:08:00

Un autre gros problème s'est installé définitivement depuis l'adoption de xrand, c'est la perte des fréquences d'image PAL, aucune réponse si ce problème est résolu avec buster, ça ne doit pas gêner grand monde vu que ça ne se résout pas depuis des années: je n'ai plus que du 60Hz compatible NTSC 30-60fps sur mes écrans, qui depuis 2013, sont toujours les mêmes télévisions justement prévues pour afficher dans les fréquences d'images 48,50 et 60 Hz en standard. Là aussi, rien ne se résous, c'est xrand qui fait la loi et considère ces télés comme des écrans LCD de portable, et xrand ne découvre pas les possibilités de l'écran et interdit les tentatives de forcer avec les mode-line. Cela m'avait valu quelques mois de prise de tête avant abandon.
La perte de fonctionnalité a été progressive, en 2016 par exemple, je pouvais encore trouver une option avec 50fps, mais perdu le 48, mais uniquement en 1280 par 720 avec mon écran 1080, ça suffisait pour le streaming et la télévision, mais déjà ça perdait en compatibilité. Linux, en principe, était "pensé" pour redonner vie au matériel dépassé, et puis avec debian 9 60Hz et c'est tout.

Parallèlement, de plus en plus de youtubeurs s'achètent du matériel de qualité (par exemple une caméra "black magic" à la place d'une GoPro) mais qui est bridé à la norme Pal en Europe, ce qui a rendu le 25 et 50 fps plus fréquent dans les chaines de qualité, un peu comme si on "bridait" d'un coté pour vendre de l'autre: comment en effet accéder à ces médias PAL sans une télé connectée directement, un ordinateur mac ou windows, alors qu'avant étaient accessibles avec un simple ordinateur linux?
Ça ne semble pas gếner les gens de regarder les vidéos saccadé, mais en pratique, l'affichage en PAL sur un ordinateur est rare: on a difficilement le 25fps et encore moins le 24fps, c'est presque toujours en 60Hz compatible 30fps. Dans le passé, c'était justement ce problème qui m'avait orienté sur débian: c'était le seul système qui me permettait d'afficher les fréquences compatibles avec 24, 30 et 60fps quelque soit l'écran.
Je suis plus utilisateur que développeur et beaucoup trop de temps est passé à bloquer sur des trucs pas fini soit dans l'expérimentation d'un truc buggé par ce que trop nouveau, soit un truc buggé par ce qu'abandonné..

Dernière modification par jean-thevenet (05-02-2021 06:15:28)

Debian-facile

#1 09-05-2019 12:53:11

Rendu des vidéos, pixels et texture sur youtube et autres.

#2 09-05-2019 22:14:06

Re : Rendu des vidéos, pixels et texture sur youtube et autres.

#3 11-05-2019 00:20:44

Re : Rendu des vidéos, pixels et texture sur youtube et autres.

#4 11-05-2019 16:33:47

Re : Rendu des vidéos, pixels et texture sur youtube et autres.

#5 12-05-2019 18:41:50

Re : Rendu des vidéos, pixels et texture sur youtube et autres.

#6 14-05-2019 11:24:37

Re : Rendu des vidéos, pixels et texture sur youtube et autres.

#7 14-05-2019 19:47:09

Re : Rendu des vidéos, pixels et texture sur youtube et autres.

#8 01-02-2021 15:59:38

Re : Rendu des vidéos, pixels et texture sur youtube et autres.

#9 01-02-2021 17:13:35

Re : Rendu des vidéos, pixels et texture sur youtube et autres.

#10 03-02-2021 08:21:56

Re : Rendu des vidéos, pixels et texture sur youtube et autres.

#11 03-02-2021 08:47:41

Re : Rendu des vidéos, pixels et texture sur youtube et autres.

#12 04-02-2021 18:46:46

Re : Rendu des vidéos, pixels et texture sur youtube et autres.

#13 05-02-2021 06:08:00

Re : Rendu des vidéos, pixels et texture sur youtube et autres.

Pied de page des forums