Version imprimable du sujet

Écrit par : leon1789 08/07/2007 09:27

Bon voilà, pour faire le test de compressibilité, RIAM lance ce script (c'est un exemple of course !) :

La ligne critique qui permet de gagner du temps est

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 bcp de temps de calcul : faites le test (avec un script comme celui ci-dessus), y a pas photo !


La seconde : prendre 14 images consécutives sur 140, ce n'est peut-être pas une bonne chose, car cela impose au codec de placer au moins une image clé toutes les 14 images (à chaque changement de paquet d'images) dans l'encodage test. Or, le nombre d'images clés est bcp plus faible dans la réalité : il est de l'ordre de 1 sur 100 (et non 1 sur 14...). Donc pour être plus près de la réalité, je propose plutôt Video=SelectRangeEvery(Video, 1500, 150). La mesure est alors plus réaliste je trouve... (même si elle ne représente que 6 secondes par minute)


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 ?

Écrit par : rol 08/07/2007 15:18

Ca a l'air logique effectivement

Merci Leon

Écrit par : leon1789 10/07/2007 22:32

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.

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 ?

Qu'en dîtes vous ?

(gonflées les cheuvilles de Léon !... pas peur d'avoir la honte... )

Écrit par : leon1789 13/07/2007 19:46

(Merci à l'équipe de RIAM de m'avoir proposé d'être "rédacteur" )

Revenons au test de compressibilité...

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 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

Écrit par : marco12 14/07/2007 01:11

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 ^^).

Écrit par : leon1789 14/07/2007 13:07

Je ne te le fais pas dire !!!

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.


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?showtopic=16372&pid=247456&st=0&#entry247456
mais avec un script AVS... comme le fait Riam

Écrit par : marco12 15/07/2007 13:20

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

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). :/

Écrit par : leon1789 15/07/2007 16:26

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 ?


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...


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é )

Donc j'espère que Divx proposera encore et toujours le mode Quantizer (avec quelques améliorations si possibles )

Écrit par : YannBresil 15/07/2007 17:31

quel programme? cela m'intéresse.

Écrit par : leon1789 15/07/2007 17:51

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" 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 ?

Écrit par : YannBresil 15/07/2007 20:46

ça me va. J'ai oOo

Écrit par : leon1789 16/07/2007 00:15

Ok, mais souviens-toi que cette usine à gaz bourrée d'imperfections n'était pour personne d'autre que moi
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 )


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é...

Écrit par : YannBresil 16/07/2007 02:54

cela marche pas, oOo n'aime pas certaines formules.

Écrit par : leon1789 16/07/2007 08:31

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 !

Écrit par : marco12 16/07/2007 15:55

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.

Écrit par : leon1789 16/07/2007 17:44

Merci Encore un petite question
Visiblement le calcul proposé reste une approximation : as-tu une idée de l'ordre de grandeur de l'erreur ? (0%, 5%, 10%, etc.)

Écrit par : marco12 16/07/2007 18:25

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 http://forum.ripp-it.com/redirect.php?url=http%3A%2F%2Fwww.kvcd.net%2Fportal%2Findex.php

Écrit par : leon1789 16/07/2007 18:33

Effectivement, c'est assez précis.




Merci !!

Écrit par : leon1789 16/07/2007 18:46

Je relève le défi ! ...histoire de faire quelque chose

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 )

Écrit par : marco12 16/07/2007 19:12

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...

Écrit par : leon1789 16/07/2007 20:29

La fenêtre de retour (lors de la compilation divx) montre que la valeur quantizer est fixe lorsqu'on encode sans B-frame (profil "sans restriction" par exemple).
Quand on encode avec des B-frame, c'est vrai qu'elle n'est pas fixe : elle prend la valeur N ou N+N/2.

Mais peu importe en fait...

Par exemple, je compte sur une formule du style Bits = k / Quantizer ^ d où k et d sont deux constantes dépendantes du film à encoder et de la configuration d'encodage. Voir http://forum.ripp-it.com/index.php?showtopic=16230&pid=247347&st=0&#entry247347

J'imagine pouvoir déterminer ces deux constantes grâce à 2 ou 3 tests de compressibilité... Et après, faire une estimation de la taille finale (configuration et film fixés) en fonction du quantizer. ...et avec quelle précision ??? 5 ou 6 % peut-être (??) ...donc loin d'un truc réellement utilisable.

Écrit par : marco12 16/07/2007 21:11

je te conseille de post sur le forum divx dans ce cas la , il pourrons te fournir plus de renseignement précis la dessus (voir si la methode quantizer continueras car faire se travail si elle disparait )

Mais je te souhaite bonne chance pour ma part moi je suis convaincu que c'est impossible sans avoir un quantizer de qualité constante , mais comme on dit l'espoir fait vivre

sinon le programme avidemux propose un module de qualité constante pour le xvid avec choix de la taille finale tu devrais peut etre creuser par la bas : ) (voir comment est interprété le mode Q du Xvid car la j'avoue que je n'en sais rien ne l'utilisant jamais )

Écrit par : leon1789 20/08/2007 20:48

Tout dépend de ce qu'on appelle "impossible"...Prévoir le bitrate en fonction du quantizer, c'est possible (car je le fais !) avec une certaine erreur... ou une erreur certaine...

Sur quelques exemples ( http://forum.ripp-it.com/index.php?showtopic=16407&pid=250283&st=0&#entry250283 ), ma formule me donne le résultat à... +/- 6 % ! C'est à la fois peu et bcp...
C'est assez peu si on part du principe que c'est totalement impossible (le monde expérimental est souvent à 5% près),
mais c'est énorme si on veut pouvoir l'utiliser réellement, puisque cela représente plus de 40 Mo pour un CD (de 700 Mo) !

Bref, c'est mi-figue mi-raisin... dommage.