 |
||
| ||
| |||||
| Dernière réponse | |
|---|---|
| Sujet : [DivX 4] - Faire les 2 passes en même temps ... | |
| Bruce | :lol: Ciler... as-tu lus ce que je disais ? :) |
| Aperçu |
|---|
| Vue Rapide de la discussion |
|---|
| Bruce | :lol: Ciler... as-tu lus ce que je disais ? :) |
| BlackSunSoft | 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 |
|
| BlackSunSoft | :love: Ouf il a compris :) |
| Zero Cool | Ah si ça y est, je crois comprendre son propos.
Bonne nuit tout le monde :crazy: ... |
| Zero Cool | Ouaip Bruce, j'avais compris cette idée, c'est juste la dernière réponse de BlackSun que j'ai pas saisie ... |
| Bruce | 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 ! |
| Zero Cool | C'est moi qui comprends plus, là :D |
| BlackSunSoft | En fait les 2 passes plutot, puisque si tu encodais en 1 passe tu aurais finalement la même chose |
| Zero Cool |
|
| BlackSunSoft |
|
| Zero Cool |
|
| BlackSunSoft |
|
| zerong | 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 |
| Zero Cool |
|
| zerong | 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 |
| BlackSunSoft | Hééé les gars :heink: Tiens y a des new smiles encore :ange: 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 :jap: Si vous avez besoin de plus de detail je suis là :) |
| TheNicow | 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. [:thenicow] |
| Zero Cool | 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 :D |
| Bruce | 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. |
| Slyde | 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 ! |
| ssc37 | oups doucle click ;) [edtdd]--Message édité par ssc37--[/edtdd] |
| ssc37 | 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 |
| HAL | tu es sûr qu'au final ça va plus vite ? car chaque flask ira 2 fois moins vite |
| antp | comment est-ce que ça peut être plus rapide ?
il utilise tout le CPU pour chacune des passes quand même... |
| Zero Cool | Petite précision : je parle d'un encodage avec Flask, bien sûr ... |
| Zero Cool | 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 ... |
