Je sais pas si le sujet a déjà été abordé, mais je viens d'essayer et a 1ère vue ça marche : qques minutes après avoir lancé la 1ère passe, on balance un autre Flask avec les mêmes settingz mais pour la 2nde passe, et hop, tout est fini en beaucoup moins de temps que normalement !
 
Puisque apparemment Flask peut lire le fichier de log alors qu'il est déjà ouvert en écriture ! Sympa ...

Petite précision : je parle d'un encodage avec Flask, bien sûr ...

comment est-ce que ça peut être plus rapide ?
il utilise tout le CPU pour chacune des passes quand même...

tu es sûr qu'au final ça va plus vite ? car chaque flask ira 2 fois moins vite

moi perso je dis que c'est pas crédible car ton taux d'occupation cpu serra tjs 100% et pas 200%.
Bref cela me semble pas probable

oups doucle click  

[edtdd]--Message édité par ssc37--[/edtdd]

en revanche avec un système SMP en désynchronisant légèrement les deux passes ca marche normalement (en balancant deux instances de Vdub par exemple), avec un CPU reflechissez c'est inutile.
 
On peut faire d'ailleurs plein de choses interessante avec les méthodes de frameserve et les systèmes SMP !

Heu... je suis pas certain que cela soit une méthode si intelligente que ça... Le fichier log n'est pas bloqué par le codec ?
 
Théoriquement ça peut marcher mais vous y gagnez pas grand choses je pense...
 
Surtout qu'avec flask
 
Evidement, en SMP c autre chose.

C'est vrai que le framerate des 2 passes baisse, mais au final j'ai l'impression que ça aura quand même été plus vite que 2 passes enchaînées ...
 
Sinon pour Bruce : nan, le fichier de log est pas bloqué, c'est ça qui est bien

On m'aurait menti ?
 
Perso je pensais que l'interet des 2 passes était que la premiere permettait de reunir des infos sur tout le film pour mieux répartir les données ds la seconde passe. Toujours selon moi, il faut donc avoir fini la premiere passe avant de commencer la deuxieme, sinon, ca perd son interet.
 
 

Hééé les gars    Tiens y a des new smiles encore    
 
Vous avez totalement faux. Dejà le codec aura besoin de connaitre la moyenne de la complexity, la complexity totale, le motion, la texture, le total_bits, et il a besoin du fichier log pour connaitre aussi où mettre des keyframes... La plupart de ces calculs sont fait avant l'encodage.
 
Si vous aviez vu le code source du VBR, certains d'entre vous aurais remarqué, comme c'est souvent le cas en prog, avec votre methode le fichier va ouvrir un fichier LOG dont la fin est proche (lol), et qui ne sera pas fini. Le fichier est donc mis en memoire au debut de l'encodage, et ne beneficieras que des 1ere frames...
 
Bref, votre idée ne marche pas    
Si vous avez besoin de plus de detail je suis là  

euh là j'avoue qu'il y a un truc qui m'échappe.
En effet je croyasi que le principe du 2 pass du divx4 était d'analyser lors de la première passe les différentes scenes afin d'optimiser la qualité de façon homogène sur toute la durée du film. je pensais que le codec analysait les images sur toute la durée du film et gérer donc la qualité de rendu final selon la taille désirée en mo pour le fichier final. Alors je ne comprends aps comment un encodage en quasi simultanée peut être possible !!!,??!!! cela voudrait dire que le codec ne fait aps une interprétation générale à la fin de la première pass pour redistribuer du biterate là où il en faudrait plus et tout en respectant la taille voulue? cela voudrait dire que le codec analyse scene aprés scene le besoin pour avoir la qualité optimale mais alors comment pourrait il prévoir la taille finale ?
 
qui peut m'aider à comprendre le fonctionnement du codec lors de la première passe ?
 
merci

 
Ben là j'ai lancé un Flask pour la 2nde passe quand la 1ère en était à 3%, et la 2nde en est maintenant à 20% ...
 
Donc soit ça marche, c'est-à-dire que le fichier est lu au fur et à mesure, soit t'as raison et je sais pas ce qu'il fait (il boucle sur le début du fichier de log ?).
 
Sinon, ce que je ne sais pas, mais z'avez sûrement la réponse, c'est : dans le fichier de log, est-ce que les infos sur une frame sont définies une fois pour toutes, ou est-ce qu'elles peuvent changer ensuite ? Si elles peuvent changer, ma méthode tombe à l'eau ...

moi je penserais plutot qu'elles peuvent changer sinon quel serait l'intérêt du bi pass !!!??!! c'est al question que je me pose aussi

 
C'est exacte
 

 
C'est ce que j'essaye d'expliquer
 

 
Une fois qu'il aura tout puisé dans le fichier log, il va encoder comme en 1 passe.
 

 
Je ne comprends pas ce que tu essaye de me dire. J'essaye de vous dire que le codec va ouvrir un fichier log qui n'est pas fini, et va se baser dessus, et il va se foutre completement de ce qu'il y aura derriere puisqu'il ne peux pas le savoir.

 
Mouais, ça reste à voir ... je vous dirai ça quand ma 2nde passe sera finie.
 

 
Eh ben le fichier de log c'est un truc avec plein de lignes comme ça :
 
Frame xxx: intra 0, quant 4, texture 35585, motion 1851, total 41541, complexity 444812
 
Chacune est écrite par la 1ère passe, à la lecture d'une frame.
Ce que je me demande, c'est si chaque ligne (les propriétés d'une frame) est écrite une fois pour toute, ou est-ce que la 1ère passe revient dessus pour la changer à un moment donné, en fonction des propriétés d'une autre frame, etc, je sais pas moi ...
 
Si la réponse est oui, ça veut donc dire que tout ce qui est ajouté au fichier de log l'est une fois pour toutes, et qu'on peut balancer la 2nde passe dessus !
 
Tiens, une autre idée pour que ça aille + vite : faire chaque passe sur une bécane différente, en lisant le fichier de log en rézo (mais avec les VOBz en local, quand même, faut pas déconner )

 
La reponse est oui.... Mais grrrrrr. Je me tue a vous dire que le codec a la 2eme passe, juste au debut doit faire des calculs sur la totalité du fichier log, non pas sur une fraction de fichier log, ce qui va fausser tout les calculs dejà dans un 1er point.
 
De plus, il faut savoir qu'en programmation, une fois que tu as ouvert un fichier, il est en memoire, hors ta 1ere passe en cours va tourner dans le vide puisque le codec ne va pas relire le fichier log

 
Ah ok ... ben fallait le dire avant !!
Dans ce cas, forcément, ça nous arrange pas ...
 

 
La 2nde passe, tu veux dire ...

En fait les 2 passes plutot, puisque si tu encodais en 1 passe tu aurais finalement la même chose

C'est moi qui comprends plus, là

En gros si je pige le truc qu'essaye d'expliquer BlackSun :
 
1) dans la 1° passe le codec crée 1 ligne par frame.
2) début de la seconde passe, il charge le log complet en mémoire (donc il lis le fichier .log de A à Z d'un coup et l'oublie ensuite). Fait quelques calculs et lance l'encodage...
 
Bref, si tu lance l'encodage de la 2° passe à 3% de la première, tu vas avoir les info des 3% des frames de ton film... Le reste sera encodé comme si ct une seule passe, le codec ne prévois rien !

Ouaip Bruce, j'avais compris cette idée, c'est juste la dernière réponse de BlackSun que j'ai pas saisie ...

Ah si ça y est, je crois comprendre son propos.
 
Bonne nuit tout le monde ...

Ouf il a compris

 
Raté,
Si tu lance l'encodage de la 2e passe à 3%, il encode tout à partir de ces 3% là. Donc il n'y a pas d'histoire du reste...
Si vous voulez plus de détails sur la question, je vous conseille le source de AVIRevolution et de mpeg2aviAR, c'est du vieux VBR, mais les bases y sont...

Ciler c'est a peu pres ce que je disais et ce que Bruce disait... Enfin bon...
Si on continue on va embrouiller tout le monde

Ciler... as-tu lus ce que je disais ?