Bienvenue invité ( Connexion | Inscription )
Réglement intérieur du forum : La loi interdit la récupération "sauvage" des films sur internet, n'est tolérée que la "copie de sauvegarde personnelle". TOUTE mention à une activité "hors la loi" sera sanctionnée directement par une fermeture du sujet voire un avertissement ...
Ripp-it Te@m
08/07/2007 09:27
Message
#1
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Bon voilà, pour faire le test de compressibilité, RIAM lance ce script (c'est un exemple of course !) :
# **** Ripp-it & AVIsynth 2.5x script **** pass 2+ LoadPlugin("C:\PROGRA~1\RIPP-I~1\dlls\undot.dll") LoadPlugin("C:\PROGRA~1\RIPP-I~1\dlls\MPEGDecoder.dll") # Video bitrate : 500000 Source="C:\riam\vobs.lst" Largeur=976 Hauteur=544 ratio =1.794118 vratio =1.794118 Crop_g=136 Crop_d=-120 Crop_h=16 Crop_b=-16 Indice=0.054253 Video=MPEGSource(Source) Video=Undot(Video) Video=BilinearResize(Video, Largeur, Hauteur) Video=Crop(Video, crop_g, crop_h, crop_d, crop_b) Video=Blur (Video, 0.5) LoadPlugin("C:\PROGRA~1\RIPP-I~1\dlls\MSharpen.dll") Video=MSharpen (Video) Video=SelectRangeEvery(Video, 140, 14) Return(Video) La ligne critique qui permet de gagner du temps est Video=SelectRangeEvery(Video, 140, 14) Le test porte sur 14/140 = 0.1 = 10% du film : précisément 0.56 seconde d'encodage pour 5.6 secondes de vidéo. Alors j'ai trois remarques... La première : cette ligne est très mal placée en fin de script ! Elle devrait être écrite juste après Video=MPEGSource(Source), cela gagnerait La seconde : prendre 14 images consécutives sur 140, ce n'est La troisième : en fait, je mettrais Video=SelectRangeEvery(Video, 1500, 150, 675) avec un offset de 675 images : c'est histoire de prendre le paquet de 150 images au milieu des 1500 : c'est légèrement mieux que les prendre au début, car il y a moins "d'effets de bord"... Qu'en pensez-vous ? Ce message a été modifié par leon1789 - 21/08/2007 10:18. |
|
|
08/07/2007 15:18
Message
#2
|
|
Admin Groupe : Admin Messages : 32.192 Inscrit : 12/05/2003 Lieu : DivX ou XviD Membre no 2 |
Ca a l'air logique effectivement (IMG:http://forum.ripp-it.com/style_emoticons/default/cling1.gif)
Merci Leon (IMG:http://forum.ripp-it.com/style_emoticons/default/cling1.gif) |
|
|
10/07/2007 22:32
Message
#3
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Je vous laisse un petit script AVS qui permet d'encoder seulement une partie d'un film (entre 1 et 100% en fait).
Ici, on veut encoder seulement 5% (Pourcent = 5) de la vidéo. Pourcent = 5 Bande = 150 # 150 ou davantage, pour éviter un nombre anormal d'images clés Intervalle = Bande*100.0/Pourcent Intervalle = Intervalle*30 > NBImages ? NBImages/30.0 : Intervalle # pour les videos courtes Intervalle = NBImages / Floor(NBImages/Intervalle) Bande = Round(Intervalle*Pourcent/100.0) Video = SelectRangeEvery(Video, Intervalle, Bande, (Intervalle-Bande)/2) L'encodage se fait de manière équirépartie sur l'ensemble de la vidéo, en limitant les effets de bord (en début et fin de vidéo). En particulier, cela produit des tests de compressibilité plus précis, et un peu plus rapide aussi (ça dépend des réglages du codec). Ca pourrait peut-être remplacer le passable Video=SelectRangeEvery(Video, 14*100/Pourcent, 14) de Riam, non ? (IMG:http://forum.ripp-it.com/style_emoticons/default/cling1.gif) Qu'en dîtes vous ? (gonflées les cheuvilles de Léon !... pas peur d'avoir la honte... (IMG:http://forum.ripp-it.com/style_emoticons/default/wink.gif) ) Ce message a été modifié par leon1789 - 13/07/2007 19:46. |
|
|
13/07/2007 19:46
Message
#4
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
(Merci à l'équipe de RIAM de m'avoir proposé d'être "rédacteur" (IMG:http://forum.ripp-it.com/style_emoticons/default/guix_edoom7.gif) )
Revenons au test de compressibilité... Ca a l'air logique effectivement (IMG:http://forum.ripp-it.com/style_emoticons/default/cling1.gif) Comme des arguments de bon sens ne suffisent pas toujours pour prouver quelque chose, j'ai testé grandeur nature (sur 4 films) les deux manières d'évaluer la compressibilité d'une vidéo. La règle du jeu est simple : on prépare sa configuration préférée pour encoder un film, en choisissant "encodage 1 passe basée sur la qualité" dans le codec DivX (autrement dit on encode à quantizer fixé). On encode et on constate le débit vidéo ainsi obtenu. Pour chaque film, on fait des tests couvrant 5%, 10% et 15% du film, et on compare leurs débits à celui du film encodé totalement... Pour expliquer ce que font les algos, je vais les simuler sur un film à 25 images par seconde : test classique à 5% : encodage de 0.56 seconde du film, saut de 10.64 secondes, encodage de 0.56 seconde du film, saut de 10.64 secondes, etc. test classique à 10% : encodage de 0.56 seconde du film, saut de 5.04 secondes, encodage de 0.56 seconde du film, saut de 5.04 secondes, etc. test classique à 15% : encodage de 0.56 seconde du film, saut de 3.17 secondes, encodage de 0.56 seconde du film, saut de 3.17 secondes, etc. mon test à 5% : saut de 57 secondes puis, encodage de 6 secondes du film, saut de 1 min 54, encodage de 6 secondes du film, saut de 1 min 54, etc. mon test à 10% : saut de 27 secondes puis, encodage de 6 secondes du film, saut de 54 secondes, encodage de 6 secondes du film, saut de 54 secondes, etc. mon test à 15% : saut de 17 secondes puis, encodage de 6 secondes du film, saut de 34 secondes, encodage de 6 secondes du film, saut de 34 secondes, etc. Bref, voici un tableau de quelques exemples : On constate plusieurs choses : 1- La méthode classique Video=SelectRangeEvery(Video, 14*100/Pourcent, 14) (que RIAM et d'autres logiciels utilisent) ne converge pas !!! En effet, malgré une hausse du pourcentage testé, l'erreur est toujours du même ordre... Ca me paraît normal : c'est toujours la faute de ces fameuses images clés anormalement nombreuses dans la réalisation du test classique. 2- L'algorithme que j'ai proposé au-dessus a l'air de converger (les test à 15% est meilleur que celui à 10%), mais ce qui est assez étonnant, c'est que le test à 5% est meilleur que le test à 10% !!! ...Là, je ne comprends pas (IMG:http://forum.ripp-it.com/style_emoticons/default/bbbb.gif) Est-ce dû au hasard de ces 4 films ? Quelqu'un a une idée ? Ma conclusion : mon petit test de compressibilité à 5% à l'air de se défendre (IMG:http://forum.ripp-it.com/style_emoticons/default/wink.gif) Ce message a été modifié par leon1789 - 14/07/2007 13:19. |
|
|
14/07/2007 01:11
Message
#5
|
|
Cascadeur Groupe : Membres Messages : 126 Inscrit : 07/10/2005 Membre no 11.549 |
Comme des arguments de bon sens ne suffisent pas toujours pour prouver quelque chose, j'ai testé grandeur nature (sur 4 films) les deux manières d'évaluer la compressibilité d'une vidéo. La règle du jeu est simple : on prépare sa configuration préférée pour encoder un film, en choisissant "encodage 1 passe basée sur la qualité" dans le codec DivX (autrement dit on encode à quantizer fixé). On encode et on constate le débit vidéo ainsi obtenu. bha déja la y'as un souci ripp-it ne peut pas encodé en mode divx qualité mais en 1 passe tout court (même si on prérègle le codecs avant ripp-it écrase pour mettre 1passe de base car l'option qualité constante n'exister pas encore ^^). |
|
|
14/07/2007 13:07
Message
#6
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
bha déja la y'as un souci ripp-it ne peut pas encodé en mode divx qualité mais en 1 passe tout court Je ne te le fais pas dire !!! (IMG:http://forum.ripp-it.com/style_emoticons/default/aga.gif) Cela étant, je pense que ce sujet sur le test de compressibilité n'est peut-être pas inutile puisque, à l'instar d'autres logiciels avancés, Riam propose un test de compressibilité ! C'est que cela doit intéresser les concepteurs de Riam et des utilisateurs. (même si on prérègle le codecs avant ripp-it écrase pour mettre 1passe de base car l'option qualité constante n'exister pas encore ^^). J'espère qu'un jour Riam pourra réaliser un encodage "1 passe basée sur la qualité"... car je pense que cela contenterait bcp de gens qui ne recherchent pas une optimisation "parfaite" d'un bitrate moyen, ou qui n'ont même pas idée d'un bitrate moyen correct à fournir, mais qui cherchent une méthode "simple et efficace", pas trop gourmande en temps de calcul et en Mo sur disque... En fait, j'utilise VirtualDub (la version Mod est installée dans le répertoire de Riam) un peu comme dans ce petit tuto : http://forum.ripp-it.com/index.php?showtop...mp;#entry247456 mais avec un script AVS... comme le fait Riam (IMG:http://forum.ripp-it.com/style_emoticons/default/cling1.gif) Ce message a été modifié par leon1789 - 16/07/2007 20:31. |
|
|
15/07/2007 13:20
Message
#7
|
|
Cascadeur Groupe : Membres Messages : 126 Inscrit : 07/10/2005 Membre no 11.549 |
bha déja la y'as un souci ripp-it ne peut pas encodé en mode divx qualité mais en 1 passe tout court Je ne te le fais pas dire !!! (IMG:http://forum.ripp-it.com/style_emoticons/default/aga.gif) Cela étant, je pense que ce sujet sur le test de compressibilité n'est peut-être pas inutile puisque, à l'instar d'autres logiciels avancés, Riam propose un test de compressibilité ! C'est que cela doit intéresser les concepteurs de Riam et des utilisateurs. Hum moi je préférerais qu'ils update plutôt la partie son , car bon encodeur lame en 3.95 qui sous échantillonne à 32000 si on choisi 96kbps mp3 c vraiment pas le top (IMG:http://forum.ripp-it.com/style_emoticons/default/icon_mad.gif) Sinon il est vrai que le mode Quantizer est bien pratique mais reste à voir si ce mode va continuer a être suivi par Divx Labs car sa va bien pour faire de l'acquisition direct mais pour l'archivage pas top vu qu'on ne peut savoir la taille finale (contrairement au mode Qualité de CCE pour le mpeg2 qui à un quantizer fixe on peut donc prévoir avec 2.3 essai la taille). :/ |
|
|
15/07/2007 16:26
Message
#8
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Hum moi je préférerais qu'ils update plutôt la partie son , Je suis d'accord avec toi sur ce point ! ...mais l'un n'empêche pas l'autre : ils peuvent modifier les parties son et vidéo, non ? (IMG:http://forum.ripp-it.com/style_emoticons/default/yahoo.gif) car bon encodeur lame en 3.95 qui sous échantillonne à 32000 si on choisi 96kbps mp3 c vraiment pas le top (IMG:http://forum.ripp-it.com/style_emoticons/default/icon_mad.gif) Ben, personnellement, je n'aime pas du tout le MP3 à 48000 Hz en dessous de 100 kbps car il y a un fort "bruit de casserolle" si je peux dire... Sinon il est vrai que le mode Quantizer est bien pratique mais reste à voir si ce mode va continuer a être suivi par Divx Labs car sa va bien pour faire de l'acquisition direct mais pour l'archivage pas top vu qu'on ne peut savoir la taille finale (contrairement au mode Qualité de CCE pour le mpeg2 qui à un quantizer fixe on peut donc prévoir avec 2.3 essai la taille). :/ Personnellement, j'archive (de manière amateur) aussi des films, mais sur des supports bcp plus gros que la taille d'un film : je mets donc plusieurs films par support, en fonction de leurs tailles. Qu'ils pensent 700 Mo, 1400 Mo ou 987 Mo peu m'importe (j'ai un programme qui me dit comment les grouper pour remplir au mieux le support d'archivage). Par ailleurs, il faut bien accepter que c'est un mode rapide pour obtenir une qualité désirée, sans perdre des centaines de Mo pour rien... contrairement à un long encodage multipasse auquel on demande de faire au mieux avec un bitrate imposé et pas forcément ad hoc... (connaitre le bitrate ad hoc, c'est justement l'intérêt du test de compressibilité (IMG:http://forum.ripp-it.com/style_emoticons/default/cling1.gif) ) Donc j'espère que Divx proposera encore et toujours le mode Quantizer (avec quelques améliorations si possibles (IMG:http://forum.ripp-it.com/style_emoticons/default/cling1.gif) ) Ce message a été modifié par leon1789 - 15/07/2007 16:30. |
|
|
15/07/2007 17:31
Message
#9
|
|
Ri(n)oModo Groupe : Super Modérateurs Messages : 7.488 Inscrit : 18/10/2003 Lieu : Manaus, au centre de l'Amazonie Membre no 443 |
Personnellement, j'archive (de manière amateur) aussi des films, mais sur des supports bcp plus gros que la taille d'un film : je mets donc plusieurs films par support, en fonction de leurs tailles. Qu'ils pensent 700 Mo, 1400 Mo ou 987 Mo peu m'importe (j'ai un programme qui me dit comment les grouper pour remplir au mieux le support d'archivage). quel programme? cela m'intéresse. |
|
|
15/07/2007 17:51
Message
#10
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
quel programme? cela m'intéresse. (IMG:http://forum.ripp-it.com/style_emoticons/default/aaaa.gif) (IMG:http://forum.ripp-it.com/style_emoticons/default/an_ouarf.gif) Tu vas être déçu ! J'ai fait ça sans "finacer" avec un tableur... C'est un fichier qui tient compte de la taille d'une dizaine de fichiers (ex : des films) pour remplir au mieux un sac fixé (ex : un DVD). Je peux le mettre sur le forum, mais j'avoue que j'ai fait ça vite fait, et que je ne pensais pas le "commercialiser" (IMG:http://forum.ripp-it.com/style_emoticons/default/cling.gif) Le programme est limité et il n'est pas écrit dans les règles de l'art (pour le coup, c'est plutôt style gros bourrin !!!). L'algo consiste simplement à prendre la meilleure de toutes les possibilités. Tu vois, c'est pas très fute-fute. Ca te va ? ..ou tu es allergique au tableur ? (IMG:http://forum.ripp-it.com/style_emoticons/default/cling1.gif) Ce message a été modifié par leon1789 - 15/07/2007 18:00. |
|
|
15/07/2007 20:46
Message
#11
|
|
Ri(n)oModo Groupe : Super Modérateurs Messages : 7.488 Inscrit : 18/10/2003 Lieu : Manaus, au centre de l'Amazonie Membre no 443 |
ça me va. J'ai oOo
Ce message a été modifié par YannBresil - 15/07/2007 20:49. |
|
|
16/07/2007 00:15
Message
#12
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
ça me va. J'ai oOo Ok, mais souviens-toi que cette usine à gaz bourrée d'imperfections n'était pour personne d'autre que moi (IMG:http://forum.ripp-it.com/style_emoticons/default/cling1.gif) Et j'espère que c'est compatible avec oOo , car j'utilise micro$oft... Une petite démo (pour ceux qui veulent jouer au compte est bon, mais uniquement avec des additions (IMG:http://forum.ripp-it.com/style_emoticons/default/wink.gif) ) J'oublais ! L'utilisateur ne doit que de modifier la taille du support d'archivage (case C3), et les noms et tailles des fichiers (cases E1--N2). Le reste est calculé... Ce message a été modifié par leon1789 - 11/10/2007 19:54. |
|
|
16/07/2007 02:54
Message
#13
|
|
Ri(n)oModo Groupe : Super Modérateurs Messages : 7.488 Inscrit : 18/10/2003 Lieu : Manaus, au centre de l'Amazonie Membre no 443 |
cela marche pas, oOo n'aime pas certaines formules.
|
|
|
16/07/2007 08:31
Message
#14
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Sinon il est vrai que le mode Quantizer est bien pratique mais reste à voir si ce mode va continuer a être suivi par Divx Labs car sa va bien pour faire de l'acquisition direct mais pour l'archivage pas top vu qu'on ne peut savoir la taille finale (contrairement au mode Qualité de CCE pour le mpeg2 qui à un quantizer fixe on peut donc prévoir avec 2.3 essai la taille). :/ Savez-vous comment il font pour prévoir la taille ? Ca m'intéresse : j'ai bien des formules, mais elles sont bcp trop approximatives ! |
|
|
16/07/2007 15:55
Message
#15
|
|
Cascadeur Groupe : Membres Messages : 126 Inscrit : 07/10/2005 Membre no 11.549 |
Sinon il est vrai que le mode Quantizer est bien pratique mais reste à voir si ce mode va continuer a être suivi par Divx Labs car sa va bien pour faire de l'acquisition direct mais pour l'archivage pas top vu qu'on ne peut savoir la taille finale (contrairement au mode Qualité de CCE pour le mpeg2 qui à un quantizer fixe on peut donc prévoir avec 2.3 essai la taille). :/ Savez-vous comment il font pour prévoir la taille ? Ca m'intéresse : j'ai bien des formules, mais elles sont bcp trop approximatives ! pour le divx il est absolument impossible d'avoir un calcul de taille car la qualité est dynamique est non constante comme pour le mpeg2 (j'avais demander sur le forum officiel divx a l'epoque ou le mode Quantizer étais apparu au béta, et apparemment divx network n'a pas approfondi c'est pour cela que je sais pas si ce mode survivra dans le futur) Pour le mpeg2 c'est bcp plus simple , le mode qualité étant constant il suffit d'appliquer une régle dit ping-pong ^^ en gros on encode 5/10min du film voit la place qui prend et applique sa proportionnalité (en gros si 10min de film mette 50mo pour un film de 90min 9x50= 4500mo).(valable pour le mode qualité de tmpgenc et CCE , Quenc ne respecte pas trop le constant, quoique je pense qu'il on due fixé cela avec c dernière version "je n'encode plus en mpeg2". Pour plus d'info tu peux aller sur le forum de kvcd.net il y a une rubrique prédiction dédier mais bon la régle général est celle que je t'es donnée. |
|
|
16/07/2007 17:44
Message
#16
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Pour le mpeg2 c'est bcp plus simple , le mode qualité étant constant il suffit d'appliquer une régle dit ping-pong ^^ en gros on encode 5/10min du film voit la place qui prend et applique sa proportionnalité (en gros si 10min de film mette 50mo pour un film de 90min 9x50= 4500mo). Merci (IMG:http://forum.ripp-it.com/style_emoticons/default/aga.gif) Encore un petite question (IMG:http://forum.ripp-it.com/style_emoticons/default/euh.gif) Visiblement le calcul proposé reste une approximation : as-tu une idée de l'ordre de grandeur de l'erreur ? (0%, 5%, 10%, etc.) Ce message a été modifié par leon1789 - 16/07/2007 17:45. |
|
|
16/07/2007 18:25
Message
#17
|
|
Cascadeur Groupe : Membres Messages : 126 Inscrit : 07/10/2005 Membre no 11.549 |
Pour le mpeg2 c'est bcp plus simple , le mode qualité étant constant il suffit d'appliquer une régle dit ping-pong ^^ en gros on encode 5/10min du film voit la place qui prend et applique sa proportionnalité (en gros si 10min de film mette 50mo pour un film de 90min 9x50= 4500mo). Merci (IMG:http://forum.ripp-it.com/style_emoticons/default/aga.gif) Encore un petite question (IMG:http://forum.ripp-it.com/style_emoticons/default/euh.gif) Visiblement le calcul proposé reste une approximation : as-tu une idée de l'ordre de grandeur de l'erreur ? (0%, 5%, 10%, etc.) je fesais sa pour du vcd (mpeg1) puis svcd (mpeg2) j'avais a peut prêt 5/10mo + ou - quand je calculer sur du 700mo sa reste donc assez précis disons une marge de 1% d'erreur vraiment max (si tu prédit par morceau d'essai de 10min sa affine quand même mieux le calcul) et 2/3% si tu prédit avec des morceau de 5min. Tu as le logiciel crée pas kwag (créateur de la mtrice KVCD) qui automatise ces opérations "Cqmatic" et il est devenu open source depuis peu à voir ici Ce message a été modifié par marco12 - 16/07/2007 18:29. |
|
|
16/07/2007 18:33
Message
#18
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
je fesais sa pour du vcd (mpeg1) puis svcd (mpeg2) j'avais a peut prêt 5/10mo + ou - quand je calculer sur du 700mo sa reste donc assez précis disons une marge de 1% d'erreur vraiment max (si tu prédit par morceau d'essai de 10min sa affine quand même mieux le calcul) et 2/3% si tu prédit avec des morceau de 5min. Effectivement, c'est assez précis. Tu as le logiciel crée pas kwag (créateur de la mtrice KVCD) qui automatise ces opérations "Cqmatic" et il est devenu open source depuis peu à voir ici Merci !! (IMG:http://forum.ripp-it.com/style_emoticons/default/aga.gif) |
|
|
16/07/2007 18:46
Message
#19
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
pour le divx il est absolument impossible d'avoir un calcul de taille car la qualité est dynamique Je relève le défi ! ...histoire de faire quelque chose (IMG:http://forum.ripp-it.com/style_emoticons/default/mrgreen2.gif) Je vais voir si j'arrive, en observant 10 % d'un film, à deviner (malgré le dynamisme) la valeur quantizer ad hoc pour obtenir une taille fixée avec un encodage "1 pass basée sur la qualité". (...avec quelle précision ???! pas en dessous de 3-5 % je pense) J'en reparlerai dans ce topic si j'ai des choses intéressantes... (pas gagnée cette histoire (IMG:http://forum.ripp-it.com/style_emoticons/default/cling1.gif) ) Ce message a été modifié par leon1789 - 16/07/2007 18:53. |
|
|
16/07/2007 19:12
Message
#20
|
|
Cascadeur Groupe : Membres Messages : 126 Inscrit : 07/10/2005 Membre no 11.549 |
pour le divx il est absolument impossible d'avoir un calcul de taille car la qualité est dynamique Je relève le défi ! ...histoire de faire quelque chose (IMG:http://forum.ripp-it.com/style_emoticons/default/mrgreen2.gif) Je vais voir si j'arrive, en observant 10 % d'un film, à deviner (malgré le dynamisme) la valeur quantizer ad hoc pour obtenir une taille fixée avec un encodage "1 pass basée sur la qualité". (...avec quelle précision ???! pas en dessous de 3-5 % je pense) J'en reparlerai dans ce topic si j'ai des choses intéressantes... (pas gagnée cette histoire (IMG:http://forum.ripp-it.com/style_emoticons/default/cling1.gif) ) Je pense que tu perd ton temps vu que le quantizer n'es pas fixe (du moins pour le moment, sa étais confirmer par Divx network sur leur forum) tu peut trouver des calcul juste sur 2/3 film mais qui se revelerons tout faux sur d'autre... |
|
|
Discussions similaires à la discussion "test de compressibilité de RIAM"
Sujets récents
Nous sommes le : 27/04/2024 01:54 |