Version imprimable du sujet
Cliquez ici pour voir ce sujet dans son format original
Forum DivX Video Ripp-it After Me Ri4m _ Les codecs, pilotes etc (audio et vidéo) _ XviD version 1.1
Écrit par : stryke 22/12/2004 18:56
En marge de la nouvelle version stable du XviD (voir info donnée par M.ED dans l'actu des logiciels), il y a actuellement une nouvelle branche de développement en test : XviD 1.1
Dans cette version, il y a d'intégré une option qui va réjouir les possesseurs de platine XviD : Le VBV. Pour faire simple le VBV (Video Buffer Verifier) est un limiteur de bitrate. Le VBV veille à ce que le bitrate maximum ne soit jamais dépassé afin de respecter les profils. Pour l'instant les profils "DivX" ne sont pas encore disponibles dans la version XviD 1.1
J'attendais une occasion pour tester cette version, c'est chose faite. J'ai encodé un film avec un bitrate moyen vidéo de 1200Kbps, ce qui allait à coup sur créer des portions avec des pics de bitrate. J'ai donc encodé le film avec la version XviD 1.0.2 et la version 1.1 avec les mêmes paramètres d'encodage.
Ci-dessous une représentation graphique d'une portion qui m'a créée 9 micro-saccades sur ma platine en version XviD 1.0.2. Et en dessous la même portion encodée avec le XviD 1.1
Pour les possesseurs de platine XviD, cette version est vraiment à essayer, enfin à vous de voir....
La version 1.1 est disponible http://www.koepi.org/XviD-1.1.-127-06112004.exe
Pour info le VBV n'a rien de révolutionnaire, ce système est intégré au codec DivX depuis la version 5.0.3
Écrit par : M.ED 22/12/2004 21:34
merci Stryke, je vais de ce pas aller l'essayer 
PS
>Pour l'instant les profils "DivX" ne sont pas encore disponibles dans la version XviD 1.1
dasn profil @ level -> AS@L5, ne correspond pas à celui du DivX
DivX le codec MPEG4 ASP le plus populaire notamment grà¢ce aux profils d'encodages hardwares qui permettent une parfaite compatibilité avec les platines MPEG4 AS@L5 ? 
http://jfl1974.free.fr/HTM/32_Test_Codec_Video.htm
Écrit par : stryke 22/12/2004 23:52
C'est celui qui s'en rapproche le plus effectivement, mais il ne correspond pas tout à fait aux profils DivX notamment sur les valeurs de bitrate maxi.
En théorie devrait donc apparaitre des profils d'appellation "DXN" dans les prochaines versions
Pour tout dire il existe déjà une version du XviD avec ces profils, mais je préfère attendre une version de koepi
Écrit par : dimdes 24/12/2004 06:34
il y a peu..... je ne savais même pas que d'autres que Koepi faisait du xvid...
Écrit par : stryke 24/12/2004 10:08
J'en connais au moins 3 autres. La plus connue étant celle de Nic
Pour info avec cette version je pense que :
- On peut repasser les min quantizer à 1 (surtout pour les I et P frames)
- Si vous êtes en "VHQ mode = 1" alors vous pouvez cocher "VHQ for Bframes" (à condition d'utiliser les B-VOP évidemment)
Au vu de la dernière version (1.0.3) je suis partagé sur l'utilisation du "Trellis"
Écrit par : M.ED 24/12/2004 11:42
J'en connais au moins 3 autres. La plus connue étant celle de Nic
Pour info avec cette version je pense que :
- On peut repasser les min quantizer à 1 (surtout pour les I et P frames) (vu 1.03 ok)
- Si vous êtes en "VHQ mode = 1" alors vous pouvez cocher "VHQ for Bframes" (à condition d'utiliser les B-VOP évidemment) (ok merci je l'avais laissé décocher )
Au vu de la dernière version (1.0.3) je suis partagé sur l'utilisation du "Trellis"
j'utilise toujours le trellis, il ne cesse de l'améliorer
Écrit par : stryke 24/12/2004 11:56
Pour le trellis je fais référence à la dernière version 1.0.3
- {xvidcore} Fixed trellis optimization overflow for quant <= 2.
Je ne pense pas que la v1.1 ait cette maj
Écrit par : M.ED 24/12/2004 13:14
OK
Écrit par : tregor 06/01/2005 14:29
J'ai une platine a base de Mediatek MTK1389FE qui supporte les codec DivX3.11, 4.x, 5.2.x et Xvid d'apres la doc. Question de non initie: si j'utilise ce tout nouveau codec XviD 1.1 faut-il mettre a jour la platine?
Écrit par : stryke 06/01/2005 15:55
Non tu n'as absolument rien à faire sur ta platine, par contre tu dois paramétrer le XviD pour être lisible sur platine.
RIAM fait ça très bien, il suffit, après avoir choisi le codec XviD, de cliquer sur "Options d'encodage" puis de cliquer sur "Appliquer les réglages standards" dans la nouvelle fenêtre.
Voir le tuto de Jack pour plus d'explications : http://forum.ripp-it.com/index.php?showtopic=1721
Écrit par : M.ED 06/01/2005 21:51
Je confirme que les paramètres standards de Ripp-it fonctionnent sur ma platine à puce MTK1389 
Écrit par : tregor 07/01/2005 09:47
Super le tuto de Jack bien qu'il date quand même.
Bref, si j'ai bien compris on clique d'abord sur paramètres par defaut puis on fait les modif de Jack une seule fois à savoir:
- quantization type H.263 (low bitrate) ou MPEG (high bitrate)
- Qpel (high bitrate) si platine a base de Mediatek 1389
- Use Chroma motion
- Min I/P/B frame quantizer : 2
- Overflow treatment: les 3 parametres : 5%
- Low bit rate scene improvement : 10%
- Maximum I frame interval : 250 (PAL), 300 (NTSC)
D'abord ais-je oublié quelque chose ou fait une erreur?
Ensuite, pour ce qui est du XviD 1.1:
- même réglages qu'avant?
- comment activer le VBV?
- Si vous êtes en "VHQ mode = 1" alors vous pouvez cocher "VHQ for Bframes" (à condition d'utiliser les B-VOP évidemment)
Elle est o๠l'option "VHQ for Bframes"?
merci de votre aide
Écrit par : stryke 07/01/2005 11:34
Certes, mais il est toujours correct
Bref, si j'ai bien compris on clique d'abord sur paramètres par defaut puis on fait les modif de Jack une seule fois à savoir:
- quantization type H.263 (low bitrate) ou MPEG (high bitrate)
- Qpel (high bitrate) si platine a base de Mediatek 1389
- Use Chroma motion
- Min I/P/B frame quantizer : 2
- Overflow treatment: les 3 parametres : 5%
- Low bit rate scene improvement : 10%
- Maximum I frame interval : 250 (PAL), 300 (NTSC)
D'abord ais-je oublié quelque chose ou fait une erreur?
Qpel, bien que tu dises que ta platine l'accepte, je ne le cocherai pas car le fichier ne sera plus compatible "DivX". Et toutes les platines se basent sur les profils "DivX".
Low Bitrate et High Bitrate je laisserai à 0%
Avec le VBV on peut revenir à des minis de quantizer I et P à 1 (B à 1 ça ne sert à rien, car de toute façon via le calcul que fait le codec c'est impossible)
Ensuite, pour ce qui est du XviD 1.1:
- même réglages qu'avant?
- comment activer le VBV?
Le VBV est activé par défaut
- Si vous êtes en "VHQ mode = 1" alors vous pouvez cocher "VHQ for Bframes" (à condition d'utiliser les B-VOP évidemment)
Elle est o๠l'option "VHQ for Bframes"?
Dans l'encoder XviD, aller dans le menu "Advanced options..."
merci de votre aide
Écrit par : tregor 07/01/2005 12:50
Dernieres petites questions:
- quand j'installe le nouveau codec xvid 1.1 il remplace et supprime l'ancien?
- faut-il recliquer sur parametres par defaut puis reconfigurer une bonne fois pour toutes les quelques optimization recommendees par jack? ou bien les anciens reglages sont repris?
Écrit par : stryke 07/01/2005 13:53
Il est préférable de faire une désinstallation de l'ancien codec.
Il faut reconfigurer l'encodeur, les anciens paramètres sont perdus
Écrit par : tregor 10/01/2005 10:21
Merci pour tout. Resultat impressionant par rapport au DivXPro! J'ai pu mettre sur un cd un film de 2H20 en 608x... et c'est impeccable alors qu'en DivX c'est meme pas la peine... Encore merci :-)
Écrit par : zombi55 16/01/2005 16:50
Pour les amateurs : http://www.koepi.org/XviD-1.1.0-Beta1-16012005.exe
Écrit par : Jack... 23/01/2005 22:33
salut à tous 
et bien bonne année ! (et oui ça fait longtemps que je ne suis pas venu...)
CéKiKiLaTesté cette nouvelle béta du XviD1.1 "quite stable" 
le VBV fonctionne ? C'est le seul truc qui manquait au XviD pour surpasser son modèle... Koepi y travaillait depuis l'été.
M'en vait tester ça bientôt...
pour info :
First XviD-1.1.0-tree official beta build.
Changelog:
- {core}: Rate-Distortion mode decision for bvops.
- {core}: Two new postprocessing functions, brightness and deringing.
- {core}: VBV support in 2pass mode
- {core}: Overal encoder speedup, especially for b-frames and all vhq modes.
- {core}: Overal speedup of the decoder, merging decoding steps together
in order to save significant memory bandwidth, enabled mmx
qpel support that was misteriously disabled in 1.0.x. All optimizations
could lead to a 25% speedup, and something closer to 12% in average.
- {core}: Fixes to the CBR/ABR rate controller, it should work much better with
bvops now.
- {core}: Fix to the 2pass2 code that could cause doubling the overflow.
- {dshow}: Support for brightness control.
- {vfw}: Many small improvements.
This build is considered quite stable, so please test and report errors you find!
=> http://www.koepi.org/xvid.shtml
@ pluche
...encore et toujours bravo pour le site, et très fort pour la FNAC
Écrit par : pepsilite 23/01/2005 22:53
Tu restes avec nous cette fois ci? ou on te revoit pour le "bonne année 2006"?
Écrit par : Jack... 23/01/2005 22:56
pour le 1er avril ? 
Écrit par : pepsilite 23/01/2005 23:57
Écrit par : rol 24/01/2005 04:44
Tu reviens quand ?
Écrit par : DAN 24/01/2005 09:09
Salut et bonne année jack
Écrit par : Jack... 24/01/2005 10:56
Tu reviens quand ?
maintenant...
tchô
Écrit par : rol 24/01/2005 11:02
Cool
Écrit par : Jack... 24/01/2005 11:57
et encore maintenant
J’ai testé cette 1.1 beta, le VBV fonctionne à merveille, sur 2 extraits où le débit montait vertigineusement et saccadait sur platine. J’ai demandé un débit de fou (7000 k) en AS@L4 (débit limité à 3000k) et le débit est bien resté en deçà de 3000k, ce qui n’aurait jamais été le cas avant…
Bon, le seul truc con, contrairement au DivX, c’est que l’utilisateur ne peut pas fixer le débit maxi de son choix. C’est soit 3000k en AS@L4 soit 8000k en AS@L5. Dommage, ma KiSS-1000 saccade à 4000k en XviD et les platines récentes sous puce Mediatek doivent saccader à 6 ou 7000k…
Je viens de poster une requête en ce sens sur Doom9…
A suivre…
Écrit par : Jack... 24/01/2005 11:58
ah oui... avec la 1.1.0 beta on peut aussi activer le VHQ pour les B-frames... Je serais tenté de cocher ça aussi, pas testé, ça doit ralentir la vitesse d'encodage et améliorer un peu la qualité, dans quelle mesure ?
that is ze question...
... si qq1 a testé ?...
@+
Écrit par : M.ED 24/01/2005 11:59
merci Jack... @bientôt
PS pour les tests c'est donc AS@L4 => puce MTK et VHQ pour les B-frames....
Écrit par : stryke 24/01/2005 12:29
VHQ pour les B-Frames ne ralenti pas l'encodage (pas vu en tout cas). Par contre dans mes différentes lectures j'en suis toujours resté qu'il fallait être en VHQ mode = 1 pour que le VHQ b-Frames soit actif
Écrit par : stryke 24/01/2005 12:32
Bon, le seul truc con, contrairement au DivX, c’est que l’utilisateur ne peut pas fixer le débit maxi de son choix. C’est soit 3000k en AS@L4 soit 8000k en AS@L5. Dommage, ma KiSS-1000 saccade à 4000k en XviD et les platines récentes sous puce Mediatek doivent saccader à 6 ou 7000k…
Je viens de poster une requête en ce sens sur Doom9…
A suivre…
Pour info il me semble que Celtic-Druid a développé une version spécifique pour les puces médiatek (justement pour augmenter la valeur max du bitrate)
Écrit par : Jack... 24/01/2005 12:50
kicéti suilà ? lol
Je vais en rester à AS@L4 pour ma Kiss
sinon, le VHQ actif pour les B-frames, en soi j'imagine que ça ne peut faire que tu bien (VHQ à 1, tu nous a convaincu...)
@MED : ben tu peux rester en AS@L5, j'ai souvent fait des encodages comme ça et c'est rare que le débit monte à 6000k. Je suis passé en AS@L4 pour éviter de m'em... avec les saccades, sans trop de succès jusqu'à l'incorporation du VBV dans cette nlle Beta. Si tu as une Mediatek, restes-en là, et si un jour tu as un film qui saccade qq part, réencode la portion en AS@L4.
PS : tu peux tjrs vérifier les pics de BR, indirectement, en regardant la courbe du poids des images avec XviD Quant Parser ou DivX DRF Analyzer. Je fais comme ça et je repère en un coup d'oeil les passages qui pourraient saccader sur ma KiSS (image clé > 150K ou suite d'images P ou B > 100K sur qq secondes). Il y a des posts à ce sujet qq part dans le forum...
L'idéal serait quand même qu'on puisse délimiter son BR ou que Koepi intercale d'autres levels entre AS@L4 et AS@L5, à 4000k ou 6000k par exemple...
Écrit par : Jack... 24/01/2005 15:08
d'aujourd'hui 15h tout juste...
PS @ Stryke : j'avais lu trop vite ton post et pas vues tes images de comparaison du 1.0;2 et du 1.1.0 avec VBV.
Juste une question : tu as fait le test en AS@L4 ou en AS@L5 pour avoir 3100k de BR ?
Écrit par : stryke 24/01/2005 17:58
PS @ Stryke : j'avais lu trop vite ton post et pas vues tes images de comparaison du 1.0;2 et du 1.1.0 avec VBV.
Juste une question : tu as fait le test en AS@L4 ou en AS@L5 pour avoir 3100k de BR ?
J'ai fait le test avec la version précédente du codec (il n'y avait pas encore les profils DXN). J'étais donc en AS@L5 (Je n'ai pas encore utilisé la dernière version)
Question très con*** : Pourquoi tu préconises dans ton tuto le profil AS@L4 (qui limite le bitrate à 3000kbps) ?
Le profil DXN HT PAL est mieux approprié pour les platines puisque c'est le profil "Home Theater" du DivX (avec un max bitrate de 4000 Kbps)
Tu ne l'as peut être pas vu dans la liste....
Écrit par : Jack... 24/01/2005 18:30
ben non 
et un tuto à revoir, 1.
merci pour le "scoop" 
par contre en DNX HT PAL la matrice est bloquée en H.263 Pas moyen de faire du custom ou du MPEG
Écrit par : vyse 24/01/2005 18:54
j'ai installé le dernier xvid, et j'essaye de réencoder des vidéos en xvid et avi pour diminuer leur taille, mais apparemment il met une taille fantaisite a chaque fois.
les fichiers d'origine font 400mo et je veux les réduire a 350, mais il me pond des fichiers de 450Mo, 400Mo, 399Mo, mais jamais 350, ça peut venir d'où? 
Écrit par : stryke 24/01/2005 19:38
par contre en DNX HT PAL la matrice est bloquée en H.263 Pas moyen de faire du custom ou du MPEG
Exact...C'est pour cette raison que je ne suis pas passé à la dernière version
Écrit par : Jack... 24/01/2005 19:38
heu... du codec ?
1.0.3 ou 1.1.0 beta ?
J'ai pas encore fini mon test sur un film entier avec la 1.1.0 (sans passer par le 1.0.3) pour vérifier le respect de la taille...
Écrit par : stryke 24/01/2005 19:40
les fichiers d'origine font 400mo et je veux les réduire a 350, mais il me pond des fichiers de 450Mo, 400Mo, 399Mo, mais jamais 350, ça peut venir d'où?
Pour le même encodage il te "pond" ces tailles (un delta de 50Mo) ? Tu changes quoi pour avoir ces différences dans les paramètres ?
Écrit par : Jack... 24/01/2005 19:41
par contre en DNX HT PAL la matrice est bloquée en H.263 Pas moyen de faire du custom ou du MPEG
Exact...C'est pour cette raison que je ne suis pas passé à la dernière version
tu peux tjrs rester en AS@L4 ou 5 pour utiliser les matrices alternatives...
Écrit par : vyse 24/01/2005 19:51
ça me le fait avec le xvid 1.0.3 et le 1.1.0
je réencode pas le son, et je change rien, j'ai effectué un batch, avec 4 ou 5 épisodes à encoder, j'ai appliqué un filtre de désetrelacement (j'avais ddes espèces de traits en lecture de divx donc jpense que ça venait de là). Et le soir quand chuis rentré j'ai vu que j'avais une taille différente pour chaque épisode alors qu'à priori j'ai sauvegardé le profil d'encodage et je l'ai utilisé a chaque fois le même.
Je vais réinstaller RIAM et je vais faire de nouveau test jvous tiens au courant
Écrit par : Jack... 24/01/2005 20:36
RiAM n'y est pour rien. Le XviD peut-être. Tu as "reréglé" tes paramètres (mini quant, et tout le toutim)? Réinstalle le 1.0.0 et refait le m^me batch. Tu seras fixé et nous aussi...
PS : avec le 1.0.1 aussi j'avais eu des tailles fantaisistes. D'où retour au 1.0.0...
Écrit par : stryke 24/01/2005 22:40
J'utilise la version XviD-1.1.-127-06112004
J'ai pas encore fini mon test sur un film entier avec la 1.1.0 (sans passer par le 1.0.3) pour vérifier le respect de la taille...
C'est la compressibilité du film qui influe sur le résultat final, il y a un post là-dessus : http://forum.ripp-it.com/index.php?showtopic=3176
Oui, il me faut juste un film où je suis sur d'avoir des pics de bitrate...pour l'instant je n'ai pas
....j'ai effectué un batch, avec 4 ou 5 épisodes à encoder, .....j'ai vu que j'avais une taille différente pour chaque épisode alors qu'à priori j'ai sauvegardé le profil d'encodage et je l'ai utilisé a chaque fois le même.
....
Je comprends mieux tes différences de taille, à vérifier si tu n'as pas des épisodes plus compressible que d'autres
Écrit par : vyse 24/01/2005 22:45
tu veux dire qu'au dela d'une certaine taille, on ne peut plus compresser le film?
pourtant ce sont des épisodes de "24" et ça dure 1h a tout casser donc bon 400Mo c'est quand même pas mal
Écrit par : stryke 24/01/2005 22:54
J'ai relu ton post, tu es en "oversize".
- Comment sont réglés les quantizers mini ?
- Comment sont réglés les overflow ?
- Matrice utilisée ?
Écrit par : stryke 24/01/2005 23:05
U.V venant de ré-ouvrir je peux mettre le lien : http://www.unite-video.com/phpbb/viewtopic.php?t=6097
Perso j'ai zappé le contenu vu que je n'ai pas ce type de puce
Écrit par : Jack... 24/01/2005 23:15
merci pour l'info ... de la réouverture d'UV
par contre mon 1er test avec la 1.1.0 me prépare un bel undersize : 360 Mo prévus à + de 50% d'encodage (le film est très sombre mais quand même)...
et je tourne à 4/5 fps ce qui n'est pas normal du tout (il n'y a que Hybrid Fupp qui puisse ralentir ... et le VHQ activé sur les B-frames). J'étais à 7/8 fps sur la 1ère passe, ce qui est ma vitesse habituelle sur les 2 passes pour du 640*480 avec HFupp
Écrit par : pepsilite 25/01/2005 01:04
Ca fait plaisir de retrouver du "jackien'" pûr sucre seulement compréhensible par Jack et Stryke
C'est rafraichissant ...........
Écrit par : M.ED 25/01/2005 01:15
Le profil DXN HT PAL est mieux approprié pour les platines puisque c'est le profil "Home Theater" du DivX (avec un max bitrate de 4000 Kbps)
c'est pas grave, ça me convient : merci à vous deux...
Écrit par : YannBresil 25/01/2005 02:02
C'est rafraichissant ...........
Tu es mauvaise langue...
Et après ça, le Xvid, c'est simple.
bon où est ma boite d'aspirine, pas compris pourquoi il faut l'adsl pour faire du mpeg dans un xvid, ou bien c'est du Hkl2145412 dans ma tv pal.
Écrit par : Jack... 25/01/2005 02:14
C'est rafraichissant ...........
faut suivre... Tout est à propos dans ce topic...
Écrit par : Jack... 25/01/2005 02:20
et je tourne à 4/5 fps ce qui n'est pas normal du tout (il n'y a que Hybrid Fupp qui puisse ralentir ... et le VHQ activé sur les B-frames). J'étais à 7/8 fps sur la 1ère passe, ce qui est ma vitesse habituelle sur les 2 passes pour du 640*480 avec HFupp
TRADUCTION :
mon premier test avec XviD 1.1.0beta1 va me faire un fichier 2 fois plus petit que demandé, même si le film est sombre et donc très compressible.
En plus il tourne 2x moins vite que la normale. Ne serait-ce pas parce que j'ai coché VHQ sur les images bidirectionnelles ? Ou serait-ce parce que j'ai activé le trellis de combat du quantizer ?
bon je confirme : 350 Mo / 700 demandés à 1 heure de la fin...
Écrit par : stryke 25/01/2005 09:19
Si l'undersize se confirme, fais un test de compressibilité, c'est surprenant les résultats parfois....
Je fais systématiquement ce test maintenant et bon nombre de mes certitudes sont "tombés" avec les résultats de ces tests
Écrit par : Jack... 25/01/2005 12:33
1.1.0beta1 - profil DNX HT PAL + VHQ 1 coché sur B-frames + mini quant à 2 + trellis
12h => 390 Mo @ 500kbps / 700 demandés (à 1000kbps, rapport bit/pixel = 0,13, 77 Mo de son)
L'image est quand même d'excellente qualité => film très compressible à vue ne nez, mais pas tant d'après le test : 0,16 dit le test, soit 80% avec mon rapport bit/pix à 0,13
1.1.0beta1 - profil AS@L5 - matrice MPEG + VHQ1 coché sur B-frame + mini quant à 1 - pas de trellis
10h => 780Mo @ 1150 kbps / tjrs 700 demandés
ah bon, oversize quand même... Image un chouia plus nette, logique...
est-ce le "trellis quantization" qui rallonge d'autant ? (puisque l'encodage avec la matrice MPEG est logiquement plus lent qu'avec la matrice H263 du profil DNX) ?
j'ai bricolé les deux fichiers pour avoir mes 700 Mo et je vais passer à un autre film pour tester la bêta... et revenir au 1.0 si ça cafouille encore...
sinon : la matrice peut être choisie même en DNX : il suffit de passer en AS@..., de choisir la matrice, et de revenir en DNX (du moins ça apparaît comme ça dans la fenêtre grisée).
Écrit par : stryke 25/01/2005 12:44
Pour le trellis c'est surprenant, je ferai un essai d'encodage avec et sans pour voir la différence de temps...
J'ai rien compris aux chiffres concerant le test de compressibilité. Le test tu l'as fait avec quel logiciel ?
Écrit par : rol 25/01/2005 12:47
Ca va les fous de XviD ???
Écrit par : Jack... 25/01/2005 14:09
très bien merci
J'ai rien compris aux chiffres concerant le test de compressibilité. Le test tu l'as fait avec quel logiciel ?
ben avec ripp-it tiens !
0,16 c'est la compressibilité (qui est censée indiquer le rapport bit/pixel idéal, si j'ai bien compris)
80% c'est le rapport entre celle-ci et mon rapport de compression bit/pix (1000kbps pour 640*496 pixels), enfin l'inverse : 0.13/0.16=0.80=80% : soit la qualité obtenue sera de 80% de laqualité maxi "obtenable" ("obtensible" ?)
résultat : fichier de 54Mo sur 5% testé = 1080 Mo si on encodait à plein régime et qualité maxi et quant mini avec le XviD (toujours si j'ai bien compris)
Par contre j'ai fais le test avec le codec réglé en AS@L5 avec matrice MPEG et quant mini à 1, ce qui n'est peut-être pas représentatif...
Écrit par : stryke 25/01/2005 14:34
Le test de compressibilité n'est (pas encore) optimum dans cette version. De mémoire il ne tient pas compte du script avs et la répartition de l'analyse a des mailles trop grandes.
A mon avis perso, tu ne peux pas te fier au résultat (avis perso, j'insiste et qui n'engage que moi, je ré-insiste....)
Voir le lien donné plus haut pour une alternative à RIAM afin de faire un test de compressibilité en XviD
Écrit par : vyse 25/01/2005 17:42
bon j'aurais du lire les tutos avant de parler, j'ai mis les I/V/B frames a 2 et tout de suite, tout rentre dans l'ordre, taille parfaite
Écrit par : stryke 25/01/2005 19:45
Tu es avec quelle version de XviD ?
Écrit par : Jack... 26/01/2005 09:51
1.1.0 probablement puisque le pb de taille non respectée avec les quant à 1 "semble" réglé dans la 1.0.3. Enfin, ça reste à voir...
- On peut repasser les min quantizer à 1 (surtout pour les I et P frames)
- Si vous êtes en "VHQ mode = 1" alors vous pouvez cocher "VHQ for Bframes" (à condition d'utiliser les B-VOP évidemment)
j'aime bien les "pincettes" de Stryke à propos du test de compressibilité...
Bon, je vais tester ARC aussi grace à ton exxxxxcellent tuto
sinon : encodage d'un court expériemental (genre "flicker" et flash stroboscopique où chaque image est à 99% différente de la précédente avec plein de couleurs flashy). BR à 3000 : respecté avec 1.1.0 : aucun pic au-delà de 4000k. Chouette le VBV en XviD. Ça passe comme une lettre à la poste sur KiSS
Écrit par : vyse 26/01/2005 10:17
ouais par contre j'ai remis la vieille 1.0RC4 qui me restait sur mon dur. Je vais réessayer avec la toute dernière beta et je verrais ce que ça donne
Écrit par : CastorTroy 27/01/2005 00:42
Une question, j'avais lu un temps que la matrice mpeg était a proscrire sur une source mpeg (2), risque de reproduire en agravant les défauts d'encodage... Vrai ou pas ?
Le H263 offre moins de blocking et de ringing mais est plus flou que la HVSbest (qui a tout l'opposé en faite).
Le rapport bit/pixel ne veut pas dire grand chose si on ne précise pas le type de film encodé a premiere vu. Ce rapport de tient pas compte du bruit, de la luminosité, du mouvement, quantité de détail...
Sinon, le bVHQ ralentit quand même l'encodage, mais peut-etre (ca reste subjectif) block moins sur les mouvements.
Écrit par : Jack... 29/01/2005 21:44
salut, merci pour l'info sur bVHQ. Si on parlant du rapport bit/pixel tu fais référence à celui donné par le test de compressibilité, à priori il est significatif puisque c'est celui de la vidéo "test" encodée avec le débit maximal nécessaire pour la vidéo, prenant donc en compte mouvement, contrastes etc. Sinon, effectivement, il n'est pas très représentatif (un peu que le seul débit quand même puisqu'il prend en compte la résolution de la vidéo). Pas lu sinon que la matrice MPEG était à proscrire pour encoder une source MPEG2...
Écrit par : Jack... 30/01/2005 20:28
2 nouveaux tests avec le XviD1.1.0b : 702 Mo respectés, comme demandés. Ouf... Ben elle a l'air très bien cette beta...
Écrit par : pepsilite 30/01/2005 20:57
et ben, ça s'arrose, un Xivd qui respecte une taille ........
Écrit par : Jack... 30/01/2005 21:43
mauvaise
enfin, je précise quand même : 707 Mo demandés pour avoir 702. Comme d'hab' avec le XviD 1.0 quoi...
Écrit par : pepsilite 30/01/2005 21:48
quoi mauvaise?
Écrit par : pepsilite 30/01/2005 21:49
Écrit par : cdoris 31/01/2005 11:23
Oui, mais ce n'est pas si catastrophique que cela
Écrit par : Guix 31/01/2005 14:08
Et y'as aucun de vous qui a essayé d'encoder en Xvid via ffdshow ? 
Écrit par : Jack... 31/01/2005 16:26
mauvaise
(langue)depuis que Ripp-it encode en XviD on a toujours demandé 707 Mo pour avoir 702 Mo (avec un son 128k). C'est dans ce sens qu'il respecte la taille...
Écrit par : M.ED 31/01/2005 19:41
oui heu c'est moyen par rapport au xvid habituel
mais je n'ai fait qu'un petit test avec les paramètres par défaut (built-in), peut-être qu'avec des règlages affinés
PS le trellis me fait des misères sur cette version xvid beta
trellis avec 2 undersize
trellis avec 1 oversize
heu sans pour la beta...
PS² je pense plutôt approfondir le ffdshow xvid....
beaucoup plus de règlages marrants...
Écrit par : Jack... 31/01/2005 21:35
beta testée avec trellis... 2 x 702Mo comme attendus donc... Ce n'est peut-être pas (que) le trellis qui est en cause.
Écrit par : stryke 31/01/2005 23:03
Compressibilité peut être ? .....
Au fait : Avec cette version de RIAM si vous avez au résultat du test de compressibilité en XviD -/+ 50% c'est correct (pas eu le temps d'affiner plus).
Avec cette version de RIAM, le script avs impactera le résultat
Ne me demandez pas pour les autres codecs, je ne sais pas....Désolé
Écrit par : M.ED 01/02/2005 07:03
en apparte
dans cette version (3.10 , le divx (5.2.1pro) 1 pass sur 3 encodages de clips de 10 min = 30 min -> précision à 1 mo (merci pepsi)
avec méthode iq proche de 0.18
Écrit par : Jack... 01/02/2005 10:03
J'ai encensé la beta trop vite : nouvel undersize : 520 Mo au lieu de 700, film en partie sombre...
Je vais essayer sans le trellis pour vouère...
Écrit par : stryke 01/02/2005 12:06
Faites des tests de compressibilité....
Écrit par : ricouledingue 01/02/2005 13:12
j'ais fais un test sur un film, le résultat était ridicule, 17%, je l'ais refait en doublant la taille du fichier, j'ais eu 102%, c'est normal comme résultats ?
Écrit par : stryke 01/02/2005 15:56
Oui, le résultat des tests n'est jamais linéaire....ca serait trop simple
EDIT : Ah si, il est linéaire dans le cas d'une modification de resize
Écrit par : pepsilite 01/02/2005 16:40
Je sais que je me répète et je comprends que vous n'ayez pas trop d'alternative, mais franchement, que d'énergie gastpillée avec ce Xvid .... c'est sidérant
Écrit par : stryke 01/02/2005 19:49
J'ai cru au début, comme toi, que c'était une contrainte supplémentaire. Je ne vois plus les choses ainsi, c'est véritablement un outil pour améliorer les encodages. 2 cas réels en ce moment :
1er script
Video = Undot(Video)
Video = Convolution3D(Video, preset="movieHQ")
Video = HybridFupp(Video, 512, 240, preset="medium")
Video = Limiter(Video)
2ème script
Video = Undot(Video)
Video = LanczosResize(Video, 704, 384)
Video = MSharpen(Video)
Video = Limiter(Video)
Jamais au préalable je ne faisais varier mes resizes ainsi (dimensions + filtre), maintenant oui. Pour info le premier script, il s'agissait de faire tenir un film de 2h20 sur 1 CD de 800Mo et pour le second un manga japonais de 1h10 sur un CD de 700Mo.
Je pense avoir optimiser au mieux (les undersizes c'est fini) et je rempli au maxi les CDs en choisissant la qualité maxi que je peux obtenir.
Maintenant ça me demande 1/2h de boulot supplémentaire (+ le temps machine) pour trouver le bon script, mais je n'encode qu'une seule fois....
Les platines de salon nous limitent actuellement. Ceci étant ça bouge énormément en ce moment, de nouvelles platines arrivent avec de nouveaux supports....ça promet de belles releases pour RIAM ça...
Écrit par : M.ED 01/02/2005 21:24
eh je savais bien que le filtre seul ne fairait pas tout
(dimensions + filtre) l'IQ c'est aussi la compressibilité d'où baisse de la résolution...
Je ne me suis jamais penché sur les filtres (bilinear par défaut) vu que ça fausse mes calculs sauf si j'ai du temps -> HybridFupp
Et comme je suis paresseux quand ça marche pas je repasse dès foisau divx : il ne faut pas être plus royaliste que le roi
PS pour ça qu'en dehors de mes essais j'utilise les paramètres par défaut...
Écrit par : pepsilite 01/02/2005 21:53
Tiens au fait, et sans aucun rapport, je cherche un filtre pour rajouter du "bruit" sur une vidéo, un filtre "noise" ou du style. je n'ai trouvé aucun filtre pour faire ça. Si tu as ça sous la main
Écrit par : stryke 02/02/2005 01:14
....
Et que gagnes tu de repasser au DivX ? Certes tu va remplir le CD, oui mais le remplir de quoi ?
Écrit par : stryke 02/02/2005 01:17
Pour rajouter du "bruit" il suffit de prendre un filtre de type "Sharp" non ?
Écrit par : pepsilite 02/02/2005 02:54
non ... si c'était aussi simple, je n'aurais pas demandé .......
Écrit par : stryke 02/02/2005 08:49
je me disais aussi....ben ça va pas être simple, car c'est plutôt l'effet inverse que recherche les utilisateurs.
Écrit par : Jack... 02/02/2005 12:46
quand tu lis sur platine et que nu n'as le choix qu'entre DivX et XviD, que le XviD est tjrs supérieur dans tous les cas de figure, et que la dernière beta permet de limiter les pics de débit, il vaut mieux l'apprivoiser... D'autant que gagner en qualité (quant 1, resize Lanczos, etc.) pour remplir le CD là où le paramétrage basique fait de l'undersize parce que le film est très compressible et que le XviD s'en sort très bien, c'est tjrs bon à prendre. Ce qui est dommage, c'est qu'à chaque fois les betas sont bcp + sensibles aux over/undersizes que les versions stables.
Écrit par : CastorTroy 04/02/2005 13:05
Pour rajouter du bruit, ya toujours au niveau du décodage, XviD, DivX et VP6 propose un "film effect", sinon tu peux essayer sous ffdshow.
A l'encodage : Un plugin de http://compression.ru/video/noise_generation/index_en.html. Un autre pour avisynth 2.5.X (http://www.avisynth.org/warpenterprises/files/addgrain_25_dll_20030618.zip)
Sinon, le rapport Bits/Pixel est indépendant du test de compressibilité. Et pour un meme rapport, autant on peut avoir un film mauvais ou réussi. Par exemple entre Panic Room et Robocop 2. La formule ne prends en compte que la taille de la video [bits] / (pixel d'une frame x nombre de frame de la video). Pas d'autres parametres.
Le taux de compressibilité est plus pertinent. Par contre, quelle est le nombre de frames ? prise au hasard ? Avec le script que l'on a choisi ?
EDIT : Oups, pas vu http://www.unite-video.com/phpbb/viewtopic.php?p=58621&sid=24dbf8ecc5d51f22f8cf0635b2f99683#58621, dernier paragraphe. En fait je voulais dire que seul, ce rapport bits/(pixels*frames) n'est pas un indicateur.
Écrit par : stryke 04/02/2005 13:58
Le taux de compressibilité est plus pertinent. Par contre, quelle est le nombre de frames ? prise au hasard ? Avec le script que l'on a choisi ?
....
RIAM prend 14 frames toutes les X frames. X étant fonction du pourcentage d'encodage de la vidéo (par défaut je crois que c'est 5%)
Donc :
- Test de compressibilité à 5% : Analyse de 14 frames toutes les 280 frames
- Test de compressibilité à 10% : Analyse de 14 frames toutes les 140 frames
Écrit par : pepsilite 04/02/2005 16:40
Ah ben voilà ce qu'il me fallait "addgrain", merci CastorTroy
Écrit par : Jack... 04/02/2005 20:40
suite des tests de la beta 1.1 avec des films sombres et compressibles, et script tout simple
MPEGSource(Source)
Undot(Video)
Crop(Video, 4,12,-2,-10)
HybridFupp ( Video, 688,368, preset="very high")
TextSub(Video, "W:\MD\MailleMouvie.srt")
Tweak(Video, bright=1.000000, cont=1.020000, sat=1.030000 )
Limiter(Video)
q2 avec treillis : 521 Mo
q2 sans treillis : 534 Mo
q1 sans treillis : 782 Mo
dont 92 Mo de son
au final, dans VDM : 3/4 de l'encodage en quant 1 + 1/4 de l'encodage en quant 2 = 702 Mo...
Quand il y a le choix entre over et undersize malgré des scripts Lanczos et sharp, c'est la méthode la moins prise tête que j'ai trouvée pour rentrer 702 Mo sur un CD en conservant au max la qualité et en utilisant le .pass initial pour le second encodage en quant 1 (je ne sais pas si c'est très orthodoxe, mais je n'ai jamais vu de défauts) = 3 passes en tout.
Écrit par : CastorTroy 05/02/2005 09:53
J'ai pas compris
Tu veux dire faire un encodage 2 pass avec des min quant a 1 ? Pourquoi 3 pass ?
Écrit par : Jack... 05/02/2005 14:30
J'ai encore été trop rapide. Alors, au ralenti :
j'encode un film qui a l'air sombre et dont la beta XviD 1.1 pourrait me faire un undersize, donc je fais un script plutôt haute qualité et sharp : Lanczos ou HFupp "very high", resize élevé, pas de dénoiseur,...
(comme je n'ai pas trouvé ARCalculator je ne peux pas faire le test de compressibilité 100% fiable conseillé par Stryke)
encodage en quant 2 (2 passes) : m**** : un undersize ! 
alors, avec VDM, en chargeant le fichier LOG de ripp-it et l'audio déjà créée, je fais une 2nde passe en changeant juste les mini quant du XviD (= à 1), en me servant donc du fichier .pass créé lors de la 1ère passe tout à l'heure [c'est là que je ne sais pas si c'est orthodoxe de faire une 2nde passe en changeant les quant, mais je n'ai jamais vus de défauts...] = 3ème passe.
et là : re-m**** : un oversize !
alors, je prends tout simplement le début de l'AVI encodé en quant1 et je lui colle la fin de l'encodage en quant2. Le plus souvent ça fait 3/4 du film en quant1 et 1/4 en quant 2 (j'ai svt un oversize de 800 Mo et undersize de 400/500 Mo pour 700 demandés). En regardant le poids de la vidéo en bas à droite de la fenêtre de VDM, tu peux facilement couper tes 2 AVi et les recoller pour tomber à 700 Mo.
Dans le cas évoqué + haut j'ai pris presque 600Mo à l'AVI en quant 1 et un peu plus de 100 Mo à l'AVI en quant 2 pour tomber à 719100 Ko = 702 Mo.
Quant tu regardes les 2 AVI, de ttes façons, la différence de qualité est imperceptible, l'image étant à peine à peine à peine plus nette en quant1...
Écrit par : stryke 05/02/2005 17:49
(comme je n'ai pas trouvé ARCalculator je ne peux pas faire le test de compressibilité 100% fiable conseillé par Stryke)
.....
Voilà la version utilisée dans le tuto http://perso.club-internet.fr/mphil/riam/arc/arcalculator100.zip
Écrit par : Jack... 05/02/2005 19:47
merci
Écrit par : M.ED 08/02/2005 18:27
....
Et que gagnes tu de repasser au DivX ? Certes tu va remplir le CD, oui mais le remplir de quoi ?
J'ai effectivement pas précisé : je parle des cas d'oversize
donc de le mettre dans la galette
(pas taper, pas taper....)
PS je teste le ffdshow xvid, c'est bien sympa mais pas beaucoup documenté, tout à fond ça donne de bons résultats mais c'est plus long que xvid façon vp6
sinon le libavcodec (ffdshow) respecte très bien la taille.
Écrit par : stryke 08/02/2005 20:37
PS je teste le ffdshow xvid, c'est bien sympa mais pas beaucoup documenté, tout à fond ça donne de bons résultats mais c'est plus long que xvid façon vp6
sinon le libavcodec (ffdshow) respecte très bien la taille.
Jamais essayé l'encodeur de ffdshow, mais je pense que ce post devrait vous aider : http://www.unite-video.com/phpbb/viewtopic.php?t=5561
Écrit par : pepsilite 08/02/2005 21:37
le xvid ne peut plus être encodé avec les dernières versions de ffdshow ....
Écrit par : M.ED 09/02/2005 07:50
Avec les dernières ffdshow dans ripp-it on pourrait faire du mpeg4 (libavcodec) ?
merci Stryke
quand je ne sais plus faire en xvid je vais me pencher sur ffdshow
qui je le répète, respecte la taille finale
Écrit par : stryke 04/04/2005 23:22
Nouvelle version XviD 1.1 beta 2
http://forum.doom9.org/showthread.php?threadid=92511
Va certainement falloir "l'encadrer" cette version, il ne risque pas d'avoir de mise à jour rapidement derrière celle-ci. Après syskin, c'est au tour d'Edourard GOMEZ de quitter la team XviD
Écrit par : paco67 04/04/2005 23:24
Not Found
The requested URL /showthread.php?threadid=92511&prev=/language_tools was not found on this server.
Apache/2.0.53 (Debian GNU/Linux) PHP/4.3.10-2 Server at forum.doom9.org Port 80
Écrit par : rol 05/04/2005 00:30
http://forum.doom9.org/showthread.php?threadid=92511
Va certainement alloir "l'encadrer" cette version, il ne risque pas d'avoir de mise à jour rapidement derrière celle-ci. Après syskin, c'est au tour d'Edourard GOMEZ de quitter la team XviD
Oula, toutes les boites sont intéressées par ces mecs là, ça craint
Écrit par : stryke 05/04/2005 16:51
The requested URL /showthread.php?threadid=92511&prev=/language_tools was not found on this server.
Apache/2.0.53 (Debian GNU/Linux) PHP/4.3.10-2 Server at forum.doom9.org Port 80
Je n'ai pas réussi sur le site de Koepi, je l'ai donc DL sur le lien direct donné dans le post :
http://www.64k.it/andres/XviD-1.1.0-Beta2-04042005.exe
Écrit par : Cédric@07 05/04/2005 17:08
apparemment le site Koepi est en vrac depuis hier ....
Écrit par : tregor 12/04/2005 09:44
http://www.koepi.org/XviD-1.1.0-Beta2-04042005.exe
Quelqu'un l'a essayé?
Écrit par : Cédric@07 12/04/2005 09:51
non pas encore mais il paraît qu'il n'y a pas trop de changement avec l'autre beta ...
je vais la télécharger et la tester ce soir ...
Écrit par : stryke 12/04/2005 11:47
Cette version fonctionne correctement. Dans l'interface de l'encodeur j'ai vu 2 modifications :
- Suppression de l'option "Closed GOV", cette option avait peu d'utilité (il faut la laisser cochée en permanence)
- Transfert du mode cartoon dans les zones. Ce qui est une très bonne chose dans le cas de film "Hybride", Kill Bill 1 par exemple (film + DA).
Concernant le mode cartoon, je retire tout ce que j'ai pu dire à ce sujet. Il fonctionne très bien avec tout type de DA (hors images de synthèse ?). De plus les derniers bugs ont été corrigés avec cette version....et on gagne 2% de compressibilité en activant l'option.
A tester donc....
Écrit par : Cédric@07 12/04/2005 12:37
il me semblait que cela avait déjà était fait dans la beta 1 ?
Écrit par : stryke 12/04/2005 13:11
possible car la béta 1 je ne l'ai jamais utilisée
Écrit par : Cédric@07 12/04/2005 13:28
Ouufff !!!!
j'avais peur de dire une connerie ....
Écrit par : Archangelus 11/09/2005 23:58
Quelqu'un a essaye la beta 2 de Nic's sortie 2 jours plus tard que celle de Keopi ?
Features of Nic's XviD Codec :
- I, P Frame encoding
- PMVFast and EPZS with diamond and square pattern motion estimation
- inter4v mode
- fullpixell and halfpixel
- precision
- both MPEG4 and H263 quantizations
- custom quant matrices
- Adaptive quantization / Luminance masking.
Changes in Nic's XviD Codec 1.1.0 b2 Build 6.04.2005 :
- Standard CVS Build
- Intel Compiler 8.1 Compiled
Écrit par : Archangelus 21/10/2005 16:16
Sur Doom9, traine ce qui semble etre une sorte de beta3 de la version 1.1 de Xvid !
Il semblerait aussi que la version final ne devrait plus tarder !
-http://forum.doom9.org/showthread.php?t=100147
Écrit par : pepsilite 21/10/2005 20:52
merci pour l'info, on voit que Zombi n'est plus là pour "hanter" Doom9...
Écrit par : Archangelus 21/10/2005 22:32
Plus assez de chaire fraiche ptete !! 
Écrit par : pepsilite 21/10/2005 22:38
il a momentanément changé de continent
Écrit par : MarcParis 07/11/2005 14:29
Avez-vous des nouvelles sur la version xvid 1.1 définitive?
Rien depuis la beta 1.2...
Écrit par : Cédric@07 07/11/2005 14:56
non pas de news depuis la beta 2 ...
Je sais pas s'il y aura encore bcp de version, car il me semblait que koepi avait été embauché par une grosse boîte ... ( syle Nero pour leur H264 ) enfin il me semble ..
Écrit par : MarcParis 07/11/2005 16:33
Je sais pas s'il y aura encore bcp de version, car il me semblait que koepi avait été embauché par une grosse boîte ... ( syle Nero pour leur H264 ) enfin il me semble ..
Mais il y a pas plusieurs équipes xvid?
Écrit par : Cédric@07 07/11/2005 16:37
non pas de news depuis la beta 2 ...
Je sais pas s'il y aura encore bcp de version, car il me semblait que koepi avait été embauché par une grosse boîte ... ( syle Nero pour leur H264 ) enfin il me semble ..
Mais il y a pas plusieurs équipes xvid?
si bien sur ... mais je crois que ce n'est pas le seul à s'être fait débaucher ..
Écrit par : CastorTroy 22/12/2005 11:05
Je crois que la 1.2 en beta se trouve (meilleur treillis) http://www.aziendeassociate.it/cd///xvid.cvs.head.2005.12.10.7z
Xivd passe en multithread sur la m.e. avec http://forum.doom9.org/showthread.php?t=104257
Écrit par : Cédric@07 22/12/2005 11:39
oui mais certaines platines dont les Kiss si je me souviens bien avait des soucis avec cette release donc voila pourquoi on a gardé la version beta 1 sur le pack ..
Écrit par : kalimero 31/12/2005 11:55
La release XviD 1.1.0-final est sortie depuis hier.
Dispo chez Koepi par exemple.
Écrit par : Dirk-Pitt 31/12/2005 12:06
Bon à savoir, merci.
Écrit par : cdoris 02/01/2006 17:00
Je mets à jour l'actu
Écrit par : Archangelus 08/01/2006 15:33
XviD 1.2 ^^'
Écrit par : cdoris 09/01/2006 12:01
Où ça ? 
Écrit par : cdoris 09/01/2006 12:23
Je crois avoir trouvé !
-http://www.aziendeassociate.it/cd/XviD.cvs.head.exe
C'est bien cela ?
Écrit par : Archangelus 09/01/2006 15:43
Le fichier je sais po, par contre ca ete annonce chez Koepi !
Free -Codecs le distribue !
Écrit par : cdoris 09/01/2006 16:27
Free -Codecs le distribue !
OK : le fichier est effectivement disponible chez Koepi.
Écrit par : clem29 05/11/2006 12:28
La version Koepi's XviD Codec 1.1.2 final est sortie elle est disponible depuis le 2novembre sur free-codecs.com
- {core}: Fixed bug when frame-drop (N-VOP) feature is used in combination with packed B-frames
- {core}: Fixed potential crash on AMD64/EMT64 architecture.
- {core}: Fix for visual_object_verid vs. video_object_layer_verid problem.
- {core}: Ensure intervening bytes are preserved in BitstreamInit()
- Techspot : a bunch of copy&paste idiots
- {vfw}: Prevent segfault when encoding application calls compress_end with NULL codec context
- {vfw}: Profile definitions updates.
- Xvid 1.1.2 fixes also a bug with unaligned bitstream buffers still present in Xvid 1.1.1.
Écrit par : rol 05/11/2006 22:46
Merci à toi pour cette info
Elle avait déjà été donnée dans l'actualité des logiciels vidéo sur le forum
Propulsé par Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)