Reprise du message précédent :

C'est con, ça.
 

Je suis en train de lire le man d'ogmmerge, mais je ne suis pas sûr que l'on puisse faire ce que je veux (même une bidouille infâme avec l'option -r, je ne suis pas convaincu que ça donne quelque chose. 'faudra que je vois si les ogm tools ont été mis à jour). Cela dit, les fichiers que j'aurais à concaténer sont de la forme NOM_FICHIER-0xx.ogm, donc je peux lire le film avec mplayer avec un mplayer *.ogm.
Tiens, d'ailleurs, on peut peut-être bricoler avec MPlayer justement. Enfin, je suis pas sûr que ce soit très propre au final.

De tout façon ça fait longtemps que je pense que les BF sont une fausse bonne idée et le test de rguyom vont dans le sens que j'imaginais : le quantizer moyen AUGMENTE !!!
Les nombreuses autres options de lavc sont bien plus importantes je pense. Surtout cmp, qpel, trell et aussi peut-être spatial, temporal complexity masking et lumi-masking qui restent à tester.
D'ailleurs j'y crois beaucoup aux technologies de type masking...
Enfin j'ai peut-être tord.
 
vqblur : average the quantizer over the time. Donc avec 0 les quantizer ne subissent pas de moyenne temporelle et à 1 c'est une moyenne sur tous les frames précédentes. Je ne vois pas trop l'interet de cette moyenne ? En tout cas 1, c'est débile puisque ça va lisser la répartition de quantizer et donc selon le type de scène on aura à peu près le même quantizer !!
 
Sinon, niveau fps ?
Et pourquoi tu vises 705 Mo !? Tu les graves comment tes 705Mo après sachant qu'un CD80min c'est 703Mo ?

compilo à la mano.
Jamais eu aucun soucis, je récupère souvent le tarball et ça roule.

 
niveau fps, c'est tres convenable, je n'ai pas la degringolade qu'observe rguyom. Mais je n'ai pas analyse la moyenne. De meme le psnr moyen m'est inconnu : j'ai mis la machine en extinction. Je vais changer le script pour faire ecrire la sortie psnr dans un fichier.
 
Pour les CDs, j'overburne. Kodak Silver/Gold   706Mo sans probleme avec pourtant un vieux graveur (Yamaha 4001t IDE).
 
Je vais essayer de determiner ce qui est responsable de l'apparition des blocs. vqcomp ?

bah, un peu toutes les options ! Et évidemment le bitrate.
Le psnr c'est justement ça : un bloc c'est du bruit donc ça se traduit par la diminuion du rapport signal/bruit.
Tu ne l'as pas dans le fichier de log, le psnr moyen ?
 
vqcomp, c'est pas trop documenté :  

 
Ca doit intervenir dans la courbe de répartition de bitrate. Mais comment ?  

dans la doc, ils recommendent ça aussi :  

 
pour les "non-animated movies".
 
Ca en fait des trucs à tester. Il me plait de plus en plus ce codec, moi qui voulait des trucs à tweaker, je suis servi.  

 
Non, pas trouvé, c'est le psnr frame par frame. Tu crois que si j'envoie la stderr de mencoder vers un fichier c'est bon ?
 
Je suis presque sur qu'il y avait moins de blocs avec tes options par défaut, mais je dois refaire l'encodage pour en avoir le coeur net.
 
Le Pacte des Loups est aussi pas mal : il y a des scènes rapides et plusieurs intéressantes pour ceux qui connaissent : lorsque les loups sont tués et entassés, la fourrure est assez estompée par blurring, juste après c'est pris derrière un grillage ou la pluie du début ou la scène avec la neige : difficile à encoder, et lorsque le héros drague la fille, c'est sur fond de ciel bleu très clair, ça fait des "rings" de compression autour des personnages. Je pense refaire les encodages et regarder le résultat de ces scènes.
En fait, pour les scènes statiques, les codecs se rapprochent de la perfection. C'est surtout les scènes avec du mouvement, des aplats (ciel) et des objets dynamiques et complexes (fumée, neige) qui font la différence.

 
avec "mencoder blablabla > /tmp/log 2>&1", ça doit le faire, mais tu n'auras rien à l'écran. Sauf à utiliser... TEE    
Je vais peut-être essayer ça histoire d'avoir le log même pour les encodages en mode --extinction.
 

bizarre...

Salut!
J'ai un pb depuis quelque temps sur certains films. Lors de l'encodage du son, j'ai des lignes comme celles-ci qui apparaissent:
 
Pos:   3,5s    152f ( 0%) 126fps Trem:   0min   0mb  A-V:-0,013 [0:128]
skip frame!!!
 
Et ainsi de suite... D'où cela peut-il venir?
Merci!

désolé, aucune idée... Je n'encode jamais en mp3.

Dans les paquets Debian pour testing, y a pas transcode. Comment je fas pour l'installer ?

Ben faut compiler...
./configure && make && make install
 

Classique :  
 
http://www.theorie.physik.uni-goet [...] 6.2.tar.gz
tar xvfz transcode-0.6.2.tar.gz
cd transcode-0.6.2
./configure
make
su
make install
 
EDIT : grillaid pour 15sec  

 
http://marillat.free.fr

 
transcode est dans unstable, pas dans testing.

Pour info, au sujet des ogmtools, et plus particulièrement d'ogmcat, dans la version 0.973 des ogmtools : des morceaux de films .OGM codés avec la méthode utilisée pour tuxrip, de manière identique (même options, même résolution, même bitrate audio, etc.) sont concaténés à première vue sans problème par cette version d'ogmcat, malgré les mises en garde sur la fonctionnalité du code.
 
Note : l'intérêt, en tout cas pour moi, de créer un fichier .OGM par fichier .VOB plutôt que de créer un seul .OGM à partir de l'ensemble des .VOB, puis de les concaténer seulement après, c'est que c'est vachement plus simple à paralléliser : j'ai plusieurs machines (pour le moment mon Duron 800, un Athlon XP 1800+ et un Celeron 1,1) à ma disposition pour coder les DVD, et chacune s'occupe individuellement de chaque .VOB (d'abord codage audio, puis une fois que le codage audio est fini, codage vidéo et mixage audio/vidéo). Ça accélère pas mal J'ai pas eu trop l'occasion de tester encore, mais sans compter l'extraction (qui n'est bien évidemment faite que par une machine, sur un répertoire partagé par NFS) ni la concaténation finale (qui doit durer au maximum 7 ou 8 minutes pour un film de 2 H), ça me prend environ 80 ou 90 % de la durée du film, donc, en gros, ça fait un codage dans les 30 fps, partie audio comprise. Ça va me changer des 6 H 30 (pour 2H de vidéo) de juste mon Duron.
 Enfin, disons que je n'ai pas encore testé sur une vidéo longue.

je ne comprends pas trop : 30fps, ton athlon XP suffit pour faire ça...
Sinon, c'est forcément moins efficace que d'encoder tous d'un coup puisque ton réservor de bitrate ne va fonctionner que sur un vob donc sur 20min de film uniquement.

 
Je sais, rien ne l'empèche de mixer les 2, Sarge et Sid ...

Justement, c'est pas mon Athlon, et puis si il met un temps T1 pour coder un film de Tv1 minutes, on peut supposer que pour coder un film de Tv1/2 minutes, il met en gros T1/2 minutes (pour un bitrate, une résolution et des paramètres donnés), c'est à peu près ce que ça donne chez moi. Alors si on lui demande de coder les 2/3 d'un film de Tv1 minutes, il va mettre environ 2/3 de T1 pour coder ça. Et si, pendant ce temps, une autre machine, 2 fois plus lente, peut coder le tiers de film restant, au total, le temps de codage aura été de 2/3 de T1 minutes, donc on aura été plus vite que de laisser une seule machine, aussi rapide soit-elle, faire le traitement. Hormis bien sûr la concaténation finale, mais ce n'est pas ce qui prend le plus temps. Disons que ce qu'on perd lors de la concaténation est largement récupéré par le temps de calcul distribué. Ça, c'est la théorie. En pratique, on ne tombe jamais dans le cas idéal, mais ça n'empêche que l'on gagne quand même pas mal. Il suffit que chaque machine ait un accès NFS aux fichiers, oggenc, transcode, mencoder et ogmmerge, et un accès ssh, et paf, ça marche.
Sinon, à propos des 30 fps, c'était une estimation à la louche, sur une vidéo de 20 minutes. C'est-à-dire qu'entre le début du codage du premier OGG et la fin du mixage du dernier OGM, le temps de calcul est inférieur au temps de la vidéo (environ 1000 secondes pour 1276 secondes de vidéo, j'ai pas fait le calcul, en fait).
 
Je ne comprends pas l'histoire de réservoir de bitrate. Au total, en moyenne, le fichier aura le bitrate vidéo voulu. Ah, oui, peut-être qu'il va essayer de gagner en global sur des zones qui peuvent être codées avec un bitrate faible, pour prendre un bitrate plus élevé après, mais est-ce significatif quant à la qualité finale ? J'ai un doute ...

Ton film est calme les 2/3 et hyper rapide le dernier tiers
 
- Tu l'encodes sur 1 PC : Il code la premier partie sur 60 % de la taille finale et code le dernier tiers sur 40 %. Cad qu'il donne plus de bitrate sur le dernier bout.
- Tu encodes en //, tu donnes en bitrate au prorata de la duree car tu ne peux pas savoir a l'avance. Donc les 2/3 seront encodes avec trop de bitrate et le dernier tier avec pas assez.
 
La bonne methde serait de faire la 1ere passe avec la machine la plus rapide et la deuxieme passe en //
C'est plus lent mais au moins tu ne massacres pas la distribution de bitrate.
 

merci mean, c'est exactement ce à quoi je pensais.

... C'ÉTAIT UN EXEMPLE ... Ça n'est pas aussi simple dans la vraie vie
Dans la vraie vie, ça se passe comme ça : on découpe le DVD en un certain nombre de VOB (leur taille est déjà définie, 128 Mo c'est petit, 1 Go, c'est un peu gros, je raffinerais avec l'expérience. Pour le moment, j'ai fixé la taille des VOB à 128 Mo), entre 40 et 80 (pour des VOB de 128 Mo), et chaque machine en choisit un disponible, et se charge de le coder. Donc, ça serait un comble de tomber pile poil sur les 2/3 qu'il ne faut pas.
 
Cela dit, je ne suis pas très au fait des impératifs de codage, de l'utilité de chaque passe et tout ça. Mais c'est pas grave, ça peut se raffiner. La première passe peut aussi être faite en parallèle, il faudrait juste rajouter une étape intermédiaire pendant laquelle on fait un traitement adéquat sur les fichiers divx2pass$NUM.log de sorte à répartir le bitrate correctement.
Le seul truc, c'est qu'il faudrait que je comprenne à quoi sert le fichier divx2pass.log, et surtout comment mencoder s'en sert.
 
Parce qu'à la limite, de la façon dont je le vois, on a N fichiers divx2pass$NUM.log, dans lesquels chaque image est décrite. Si on reconstitue un fichier général divx2pass.log qui décrit tout le film, est-ce que celui-ci est équivalent au fichier divx2pass.log crée si il est créé en une seule fois ? Si c'est le cas, est-ce que l'on ne pourrait pas associer chaque fichier VOB à une image de début et de fin, et, en prenant en référence le fichier général, ne s'intéresser qu'à la partie correspondant au VOB traité, sachant qu'il a alors quand même accès aux informations des autres ?
 
Des infos là-dessus, quelqu'un ?

Ça tombe mal, ce n'est pas comme ça que ça se passe

je ne suis pas convaincu. Faudrait voir comment fonctionne le mode cluster de transcode...

En ce qui concerne le divx2pass.log ? Bon, je regarde l'option cluster de transcode pour comparer. Ça se trouve où dans le man ? J'ai l'impression que ça n'y est pas (je n'ai peut-être pas cherché ce qu'il fallait). Bon je vais chercher des docs sur le site.

Ptet là : http://www.exit1.org/dvdrip/doc/cluster.cipp
ptet aussi dans les sources de transcode.

Je suis en train de regarder comment fait DVD::RIP pour se servir du mode cluster de transcode. Pas évident à comprendre, parce que je ne comprends pas tous les termes techniques (PSU, etc.), donc je cherche en même temps.

Ah, d'accord, c'est la page de DVD::RIP que j'étais en train de regarder que tu me donnes.

Bon, j'y vais de mon ptit test des nombreuses options lavc.
Méthodologie :  
->Encodage du chapitre 16 du "masque de zorro".
->Durée : 6 min 18 sec
->Format : 2.35
->Résolution : 608x256
->Encodage en une passe à quantizer constant (fixé à 4), afin de comparer les effets des diverses options sur la compressibilité.
->Ligne de commande : "mencoder zorro16.vob -nosound -vop scale=608:256,crop=702:428:10:74 -ovc lavc -lavcopts vcodec=mpeg4:keyint=300:vqscale=4:vme=4:psnr:$OPTIONS"
->Version mencoder : 0.90rc3 (lavc inclu)
->Vérification : taille du fichier obtenu, psnr, fps.
 
Résultats bruts :  
1) Le psnr est quasimant constant : logique a priori puisqu'encodage à quantizer constant (donc qualité constante).
2) Taille obtenue :
 

 
On constate d'emblée que les options de type "masking" ont une influence nulle. Ces options sont plus "psychologiques" (ce qui ne veux pas dire qu'elles ne servent pas...) et ne jouent pas sur la compressibilité de la scène.
 
Interprétation
Afin de comparer les options, j'ai divisé la taille des fichiers par la taille du fichier de référence, c'est à dire celui encodé sans options particulières.
 
 
 
Le grand gagnant est : "qpel" !!! Sans conteste l'option la plus bénéfique. Je confirme le test de rguyom : il ne faut surtout pas utilisé "v4mv" seul. "trell" (même couplé à d'autres options) s'avère étonnament catastrophique (à voir en double passe, néanmoins). Par rapport à l'option par défaut de tuxrip (vhq:v4mv), le gain est remarquable avec l'option "qpel:cmp=2" en plus.
 
Conclusion
Je rajouterais rapidement les infos de vitesse. Ce même test va être réalisé à q=10 pour voir si ça se confirme à très basse qualité.
Enfin, il reste à tester l'influence des b-frames.
 
NB : cmp=2 signifie "precmp=2:cmp=2:subcmp=2"

Je viens de faire toute une série de tests cette fois en double passe et avec un bitrate variable (comme le ferait tuxrip). J'ai noté les fps et psnr et surtout j'ai visionné, et c'est très intéressant. C'est différent de tes tests en constant.
 
J'ai pris le film "Reign of Fire" où la terre a été dévastée par des dragons réveillés dans un chantier de Londres (ne rigolez pas dans le fond siouplait). Ce film est bien car il a beaucoup de flammes et de fumée, de changements brusques, donc parfait pour tester.
 
J'ai encodé une séquence de 40s au début du film, lorsque le gamin découvre la grotte : cette scène commence avec
 
- le gamin s'approchant d'une pierre avec beaucoup d'aspérités (intéressant pour le détail)
 
- puis la caméra fait un plan du gamin sur fond bleu sombre (intéressant pour les aplats)
 
- finalement le gamin se retourne brusquement et voit une flamme au sol (intéressant pour l'encodage d'un objet très mouvant, car c'est là que ça fait des blocs).
 
La ligne de commande est :
mencoder -ss 210 -frames 1000 stream.vob -nosound -vop scale=640:272,crop=716:434:2:72 -ovc lavc -lavcopts vcodec=mpeg4:keyint=300:vme=4: psnr:vpass=1:vbitrate=917:$OPTIONS &&
mencoder -ss 210 -frames 1000 stream.vob -nosound -vop scale=640:272,crop=716:434:2:72 -ovc lavc -lavcopts vcodec=mpeg4:keyint=300:vme=4: psnr:vpass=2:vbitrate=917:$OPTIONS
 
J'encode en variable 917kbps (le bitrate moyen nécessaire pour 1CD de 80 min)
 

 
" signifie vhq:v4mv, je l'utilise toujours
détail : meilleur avec trell qu'avec les deux autres, les détails de la pierre sont mieux visibles
aplats : effets de dégradés mouvants
dynamique : très bonne, pas de blocs visibles
 
 

 
cmp change la façon de calculer la "motion estimation" (en gros, l'image est découpée en blocs et des vecteurs sont tracés représentant la mouvance de ces blocs)
Par défaut (test précédent, *cmp=0)
 
détail : trell donnant le meilleur résultat, j'ai continué avec lui, c'est excellent
aplats : un peu moins mouvants
dynamique : BLOCS visibles !!! Lorsque le gamin se retourne et la flaque s'enflamme, blocs visibles. Note : quand je parle de blocs visibles (dans tous les tests effectués ici, sauf cmp=7), c'est UNIQUEMENT quand il y a quelque chose de très mouvant (la flamme, le gamin qui se retourne). C'est bref, mais bien visible. Ce n'est cependant pas un problème d'image "blockie" qu'on pouvait avoir avec d'anciens codecs.  
 
 

Test intéressant : cela désactive cmp (notez bien : 7 est désactivé, 0 est activé avec l'algo par défaut)
aplats : complètement couverts de blocs ! il n'y a que les parties vraiment très détaillées qui sont précises.
 
Donc cmp comme prévu intervient in fine dans le lissage des aplats.
 

 
cmp=6 est le plus lent des algorithmes
aplats : très bon
dynamiques : blocs visibles, moins qu'avec cmp=2, mais plus qu'avec cmp=0 (défaut)
 

 
En ajoutant 256 au cmp, on tient aussi compte de la chrominance
aplats : mouvants en 256, mais peut-être un poil meilleur que cmp=0 (c'est-à-dire sans option cmp, par défaut), par contre ils sont excellents de stabilité (les meilleurs) en 262
dynamique : très bonne, pas de blocs en cmp=256 (la même qu'avec cmp=0, ce qui est normal), blocs visibles en 262, comme pour cmp=6, donc moins que cmp=2.
 
J'ai fait d'autres tests, comme cmp=3 avec trell, c'est pas beau !
 
Pour résumer:
 
- trell améliore le détail significativement, mais ralentit d'environ 35%
 
- qpel ne semblait pas améliorer grand chose (en variable/2 pass), mais je dois refaire des tests avec cmp et trell. Il bouffe aussi 35%
 
- les cmp : ça dépend. Si les blocs ne vous gènent pas trop, les nouveaux cmp stabilisent grandement les aplats, donc améliorent la qualité des mouvements. Ce qui est logique : c'est un algorithme servant à estimer le mouvement. Plus il est complexe, plus il bouffe de ressource, mais plus les aplats seront stables.
Donc allez-y pour cmp=6 le meilleur pour encoder de nuit (ou 262), et éventuellement, lissez avec un filtre de post-processing (-vop pp) si vous voulez estomper les blocs. Sinon cmp=0 donne pas de blocs (ou quasiment) mais les aplats sont moins stables.
 
EDIT : je suis assez perplexe avec les cmp. Avec le défaut cmp=0, on a pas ces sautes lissé/blocs. Or ceux-ci apparaissent avec les autres algo testés (2, 3, et 6) bien qu'ayant une qualité supérieure. J'ai une théorie : les nouveaux algo sont encore expérimentaux. Il est possible qu'ils n'aient pas le "lissage" de cmp=0 bien qu'ayant une détection du mouvement supérieure, et que donc l'implémentation ne soit pas encore parfaite. Ce serait une bonne chose, car s'ils ne faisaient pas ces blocs, comme cmp=0, alors ils auraient une qualité très supérieure. Mais on peut aussi penser que c'est l'algo le plus simple cmp=0 évite ce problème parce qu'il est simple justement, donc moins précis et plus "lissé". A voir...
 
Maintenant, on regarde un film à 3 mètres au moins du moniteur : les blocs sont moins visibles de loin, par contre les aplats stables et le détail peuvent être plus importants pour certains. D'autres personnes seront gênées par les blocs, même très brefs.
Cela montre qu'il ne faut pas être obnubilé par le psnr mais visionner pour avoir une idée.
 
Lorsque le site sera prêt, je mettrai des photos pour montrer tout ça.
 
A vous de faire les tests et de me dire ce que vous en pensez...

D'après ce que je vois sur le site de DVD::RIP, la deuxième passe, si il y a lieu, n'a pas l'air de se préoccuper des résultats de la première passe des autres processus.
 
En fait, pour le calcul parallèle tel que je l'ai écrit, il faut adopter un compromis entre la rapidité de traitement et la qualité des fichiers finaux.
Ce compromis se décide dans le choix de la taille des fichiers .VOB : plus ils sont gros, moins les problèmes liés à la variation du bitrate se posent, puisque lors de la première sur chaque fichier, on peut considérer qu'il y a des zones lentes et des zones rapides, sur lesquelles sera correctement réparti le bitrate (ça se rapproche du cas du codage avec un seul processus), mais en contrepartie, la vitesse de traitement risque plus d'être pénalisée par la machine la plus lente du système (dans le pire des cas, ce qui n'arrive pas toujours. Il faut décider par expérience), et plus ils sont petits, plus ils sont traités rapidement, mais le bitrate reste uniformément réparti sur chaque morceau de film, pénalisant les scènes actives au profit de scènes plus calmes.
Cela dit, je suis en train de comparer les 2 versions que j'ai faites de Shrek (une par une seule machine, une par calcul parallèle, sur 700 Mo), et peut-être que je ne suis pas doué pour voir le détail pourri qui tue, c'est vrai, mais bon, je ne vois pas de différence (rien qui me saute aux yeux).
Non, le seul problème, pour le moment, c'est la concaténation qui n'est pas tout-à-fait au point, et qui introduit une désynchronisation au cours du film. Mais ça doit pouvoir s'arranger, je suis en train de tester.

 
oui, faut les mêmes options.
Pour l'instant, en 2 passes, je dirais que trell est un plus. Je suis plus réservé avec qpel.
Pour les cmp, je garde le défaut (c'est-à-dire *cmp=0). Je viens de m'apercevoir que si j'ai plus de blocs visibles avec cmp=2, c'est tout simplement que pour les scènes très mouvantes, il a tendance à faire des keyframes supplémentaires. Donc les scènes où j'ai des blocs sont des I frames avec cmp=2, mais des P frames avec cmp=0, et donc l'image est plus lisse.
 
Donc, si vous utilisez tuxrip : vhq:v4mv:trell (ajoutez trell aux options par défaut).

 
Tu veux dire choisir les options d'après le genre de films ? Bof... Je dirais que trell augmente le détail significativement dans tous les cas. Peut-être associé à qpel c'est encore mieux. Mais ne pas utiliser les cmp=2 car les I frames font des blocs (tout du moins avec libavcodec de la RC3).
 

 
Absolument, la taille finale correspondra à la taille ciblée.
 

Tu peux essayer les bframes avec =1 mais attention parfois ça n'en vaut pas la chandelle.
 
 

 
Pour du PAL oui (29.97 pour le NTSC). Pour le nombre de frames :
tcprobe -i /dev/dvd -T titre
 

 
Apres la fin ca fait rien.
 
bits<0.9 c'est un message pour dire que c'est tres degrade, ca n'a pas d'importance.
Pour l'override, je bloque a 20-31 ou 21-31 : c'est encore tres lisible et c'est tres efficace.
 

 
Faut voir la deuxieme passe, c'est peut-etre normal : a la deuxieme passe, il va rajouter des bits aux scenes complexes pour atteindre la taille-cible.

 
C'est tres possible, je n'ai jamais regarde les resultats de mes premieres passes, mais c'est logique : la premiere passe ne peut rien anticiper. Elle calcule la complexite de chaque frame et encode avec un nombre de bits suffisant pour une bonne qualite. C'est seulement a la deuxieme passe que les bits sont redistribues, rajoutes ou enleves selon la complexite des scenes et la taille cible. Ca me parait parfaitement normal.

J'ai essaye : vhq:v4mv:trell:qpel me donne d'excellents resultats... a 15fps par passe (au lieu de 37).

 
oui, en psnr et aussi en image, surtout en detail, avec trell.
Essaie sur des bouts, je trouve l'image plus detaillee.

 
Honnetement, j'ai deja envoye plusieurs problemes, sans reponse. La plupart des reponses sont rarement techniques, c'est surtout "DVD vers SVCD" etc... Contacte les auteurs directement ?