encodage par le GPU ?

[turlupin]

Coucou !

Je m'apprête à monter une nouvelle machine du genre... assez costaud et avec gros stockage audio-video sur un RAID 5 (pas loin de 14 To utiles).

L'idée étant de transférer le plus rapidement possible environ 1400 dvd ripés et compressés, autour de 700 CD audio et un peu moins de 300 Laserdiscs qu'il faudra acquérir en analogique et compresser également dans un temps aussi court que possible.

Rien que le rip et l'acquisition représentent beaucoup de temps en manipulations diverses, d'où l'intérêt de mobiliser le GPU pour la phase de compression des fichiers ripés.

Donc ma question est : "est-ce possible avec m4ng et de quelle façon ?"

Je suppose que c'est juste une histoire de codec, quitte à devoir acheter un tel codec comme celui de ETI, par exemple, qui utilise les GPU nVidia pour encoder en h264.

Le problème étant de savoir si on peut demander à m4ng d'utiliser un codec "externe", pas prévu dans le manuel.

Merci donc de répondre assez précisément, histoire de me permettre de savoir s'il y a une solution à mon problème.

Et toujours mes ficelles de caleçon pour ce superbe ensemble logiciel qu'est m4ng.

[pepsilite]

Coucou !

Je m'apprête à monter une nouvelle machine du genre... assez costaud et avec gros stockage audio-video sur un RAID 5 (pas loin de 14 To utiles).

L'idée étant de transférer le plus rapidement possible environ 1400 dvd ripés et compressés, autour de 700 CD audio et un peu moins de 300 Laserdiscs qu'il faudra acquérir en analogique et compresser également dans un temps aussi court que possible.

Rien que le rip et l'acquisition représentent beaucoup de temps en manipulations diverses, d'où l'intérêt de mobiliser le GPU pour la phase de compression des fichiers ripés.

Donc ma question est : "est-ce possible avec m4ng et de quelle façon ?"
Je suppose que c'est juste une histoire de codec, quitte à devoir acheter un tel codec comme celui de ETI, par exemple, qui utilise les GPU nVidia pour encoder en h264.

Le problème étant de savoir si on peut demander à m4ng d'utiliser un codec "externe", pas prévu dans le manuel.

m4ng peut tout ripper et réencoder pour peu que les codecs soient présents, par contre les codecs utilisant le GPU nVidia ne sont pas prévus, n'en ayant pas pour faire le code et tester...

Merci donc de répondre assez précisément, histoire de me permettre de savoir s'il y a une solution à mon problème.

Et toujours mes ficelles de caleçon pour ce superbe ensemble logiciel qu'est m4ng.

[Underground78]

Salut,

Malheureusement ce n'est pas vraiment possible, toutes les solutions actuelles sont propriétaires et pas (ou très difficilement) utilisables par des logiciels tiers ... De plus la qualité de l'encodage est souvent réellement pas top (et ça même face à un encodage basse qualité donc haute vitesse en x264).

Tu prévois quoi comme CPU ? Parce que bon avec un CPU récent quadricoeur tu peux déjà aller très vite en x264.

NB : Je suppose que tu vises le format h264 pour la vidéo, c'est dit nul part mais j'imagine que c'est ça ...

[turlupin]

m4ng peut tout ripper et réencoder pour peu que les codecs soient présents, par contre les codecs utilisant le GPU nVidia ne sont pas prévus, n'en ayant pas pour faire le code et tester...

Oui, je me doute bien que tu n'as ni tout le temps ni tous les moyens techniques et financiers de tout faire (en fait je me demande déjà comment tu fais pour faire ce que tu offres ici, ça doit te prendre un temps dingue ! ), je me demandais juste si des codecs "exotiques" pouvaient être appelés comme des plugins à la façon de ce que font les logiciels Adobe, par exemple.
Ce ne serait donc pas à toi de développer tous ces plugins, le tout se ramenant à savoir si m4ng peut fonctionner sur ce mode.
Sinon il existe des softs qui font le tout mais j'aime bien m4ng depuis que je l'utilise, c'est-à-dire le début puisqu'avant j'utilisais déjà ri4m.
Jusqu'à présent je n'avais pas ce souci d'encodage par le GPU puisque ça se résumait à la partie du chipset chargée de l'affichage (i915)
Avec la machine à venir et l'utilisation prévue, tout gain de temps significatif sur l'une ou l'autre partie du travail sera la très bienvenue, le GPU sera de la partie car, après que tout sera rentré il continuera de bosser en pliant des protéines pour Folding@Home.
Le gain de temps en compression peut être extrêmement important, d'où mon souci de savoir si je pouvais le faire par le biais de m4ng (est-ce que j'ai déjà dit à quel point j'apprécie ce logiciel ? ).
Si ce n'est pas possible, tant pis, j'utiliserai une solution autre

Merci de toutes les façons.

[pepsilite]

m4ng peut tout ripper et réencoder pour peu que les codecs soient présents, par contre les codecs utilisant le GPU nVidia ne sont pas prévus, n'en ayant pas pour faire le code et tester...

Oui, je me doute bien que tu n'as ni tout le temps ni tous les moyens techniques et financiers de tout faire

Ca n'est pas vraiment une question de moyens financiers, je vais regarder du coté de ce fameux ETI dont tu parles, après tout pourquoi pas...


(en fait je me demande déjà comment tu fais pour faire ce que tu offres ici, ça doit te prendre un temps dingue ! )

Ben disons que tout ça est bien rodé et qu'avec la pratique j'arrive à faire beaucoup de choses en très peu de temps. Il est vrai que la v2 m'a bouffé pas mal de ma vie il y a un an, quasiment un mois entier non stop mais maintenant c'est relax...

, je me demandais juste si des codecs "exotiques" pouvaient être appelés comme des plugins à la façon de ce que font les logiciels Adobe, par exemple.
Ce ne serait donc pas à toi de développer tous ces plugins, le tout se ramenant à savoir si m4ng peut fonctionner sur ce mode.

m4ng est une GUI multifonction, si la CLI existe, il pourra piloter (pour peu que je fasse le code, évidemment)

Sinon il existe des softs qui font le tout mais j'aime bien m4ng depuis que je l'utilise, c'est-à-dire le début puisqu'avant j'utilisais déjà ri4m.
Jusqu'à présent je n'avais pas ce souci d'encodage par le GPU puisque ça se résumait à la partie du chipset chargée de l'affichage (i915)
Avec la machine à venir et l'utilisation prévue, tout gain de temps significatif sur l'une ou l'autre partie du travail sera la très bienvenue, le GPU sera de la partie car, après que tout sera rentré il continuera de bosser en pliant des protéines pour Folding@Home.
Le gain de temps en compression peut être extrêmement important, d'où mon souci de savoir si je pouvais le faire par le biais de m4ng (est-ce que j'ai déjà dit à quel point j'apprécie ce logiciel ? ).
Si ce n'est pas possible, tant pis, j'utiliserai une solution autre

J'ai déjà répondu plus et dans mon post avant, dans l'état actuel des choses, m4ng ne peut pas piloter ce pour quoi il n'a pas été prévu. Mais celà dit, si je me souviens bien des tests effectués par certains, le rendu via GPU est extrêmement gourmand en ressources GPU, lequel n'a même plus de souffle pour afficher l'écran de windows, tout ceci pour un résultat final pas très convaincant au niveau qualitatif et rapidité... Un bon PC bien puissant faisant sensiblement la même chose en software. Je demande confirmation mais je crois me rappeler que ça ressemblait à ça.

Merci de toutes les façons.

[pepsilite]

je viens de regarder du coté de ETI, la solution ne semble fonctionner qu'avec du soft Adobe pur, donc aucune solution pour m4ng.
"Adobe", j'ai toujours pensé que c'était de l'...

[pepsilite]

Je viens de tester "Badaboom", il proclamait un encodage "20 fois plus rapide" qu'avec un autre logiciel, ouais ouais... J'ai encodé le même vidéo en 10 minutes avec Badaboom et 12 avec m4ng .... 20 fois plus rapide, c'est flagrant

[Underground78]

Je viens de tester "Badaboom", il proclamait un encodage "20 fois plus rapide" qu'avec un autre logiciel, ouais ouais... J'ai encodé le même vidéo en 10 minutes avec Badaboom et 12 avec m4ng .... 20 fois plus rapide, c'est flagrant

Et niveau qualité ?

[pepsilite]

ben en une seule passe ... tout est dit...

[turlupin]

Merci de ces éclaircissements, Pepsi.

Du coup je suis en train de repenser mes choix sur cette base.

Au début je pensais très naïvement que le GPU n'était rien d'autre qu'une grosse "boîte noire" qui calculait plus vite que le CPU et s'y substituait simplement, sans avoir compris que les spécificités des différentes phases de la compression (particulièrement inter-images) ne bénéficiaient pas toutes de cette facilité.

J'ai vu qu'effectivement ça n'était pas la solution miracle et je réfléchis à mes besoins/désirs en intégrant cet aspect.
Après tout, ça reste au niveau d'un loisir, je ne vais pas en faire tout un plat.

Un i860 un peu "poussé" associé à m4ng devrait déjà assurer un minimum plus satisfaisant que le Pentium M à 2 GHz de mon portable de 2006...

Pour la CG je vais surtout me concentrer sur la qualité de la video en sortie et la performance énergétique et "acoustique", donc fanless.

A une prochaine fois...

[Puppet]

Heu... Ca fait un moment que les construteurs ne communiquent plus la dessus... Et pour cause, les resultats ne sont pas a la hauteur et limite ! ^^ ATI a meme abandonne, faut dire aussi que eux utilisait le GPU mais surtout le CPU !

Oui ca va vite sur GPU, a condition d'avoir une tres bonne carte et surtout... Avec des parametres d'encodages bien precis et limites !

A parametres egaux avec un bon porcesseur, le x264 est aussi voir plus rapide mais une chose est sur, il offre toujours une meilleure qualite !

[Underground78]

M'enfin un jour ça viendra peut-être, un des projets du x264 pour le Google Summer of Code c'est :

GPU motion estimation

While porting x264 entirely to CUDA or OpenCL is an insane task, there are three possible methods that could be used to offload some work to the GPU:

* High-complexity motion search designed to get useful predictors to be used by the main motion search.
* Massively parallelized lookahead motion search, designed to do a lot of the work normally done in the lookahead thread. May also improve B-frame decision and other parts of the lookahead.
* Motion search designed to completely replace x264's main motion search: would require a lot of threading trickery to sync it perfectly with the main encoder threads.

The general algorithm that has been agreed on after a great deal of discussion is the hierarchical search method. If you have a better idea, feel free to propose it, of course. More description of this method is in the Qualification Tasks section.

This project is not recommended unless you have a very significant amount of experience with CUDA or OpenCL.

* Difficulty: Very High
* Amount of work: Medium
* Skill required: Very High

PS : Je peux traduire (grossièrement) si quelqu'un aime vraiment pas l'anglais ...

[Subbat]

Euh... ce n'est pas que je n'aime pas l'anglais... mais je veux bien une traduction, car à part un mot par ci par là, je ne comprends pas grands chose...

[BiGf0oT]

avec reverso sur google ca donne ca :

GPU évaluation de mouvement

En portant x264 entièrement à CUDA ou OpenCL est une tâche folle, il y a trois méthodes possibles qui pourraient être utilisées pour débarquer un peu de travail au GPU :

* La recherche de mouvement de complexité haute conçue pour obtenir des prophètes utiles à être utilisés par la recherche de mouvement principale.
* Massivement parallelized la recherche de mouvement préalable, conçue pour faire beaucoup de travail normalement fait dans le fil préalable. Peut aussi améliorer la décision de B-cadre et d'autres parties de la prévision.
* La recherche de mouvement conçue pour complètement remplacer la recherche de mouvement principale x264's : exigerait la plupart de tromperie de filetage à sync cela parfaitement avec les fils d'encodeur principaux.

L'algorithme général qui a été convenu après beaucoup de discussion est la méthode de recherche hiérarchique. Si vous avez une meilleure idée, n'hésitez pas à le proposer, bien sûr. Plus de description de cette méthode est dans la section de Tâches de Qualification.

On ne recommande pas ce projet à moins que vous n'ayez une quantité(somme) très significative d'expérience avec CUDA

pas top top comme traduc

[Subbat]

... pour obtenir des prophètes utiles...

[BiGf0oT]

[Underground78]

Traduction plus ou moins libre qui vaut ce qu'elle vaut ...

Estimation du mouvement par le GPU

Si porter entièrement le x264 vers CUDA ou OpenCL est une tâche impossible/folle, il existe trois méthodes possibles pour déléguer une partie du travail au GPU [NdT : plutôt que le faire faire par le CPU] :

* Une recherche du mouvement haute-complexité conçu pour obtenir des prédicteurs [NdT : prédisant le mouvement en fait] utiles destinés à être utilisés par l'algorithme principal de recherche du mouvement [NdT : qui reste sur le CPU].
* Une recherche du mouvement par anticipation [NdT : faite en avance par rapport à l'image réellement encodée à un instant T] massivement parallèle [NdT : où plusieurs les calculs sont effectués au même instant] conçue pour effectuer une grande partie du travail normalement effectué par le thread [NdT : le processus léger en français mais bon ...] d'anticipation [NdT : qui travaille en avance par rapport aux autres donc]. Pourrait aussi améliorer le placement des B-Frames et d'autres parties du travail effectué en anticipation.
* Une recherche du mouvement conçue pour remplacer complètement l'algorithme actuel principal de recherche du mouvement du x264 : demanderait de nombreuses astuces de parallélisation pour maintenir sa synchronisation avec les threads d'encodage principaux.

L'algorithme général choisi après de nombreuses discussions est la méthode de recherche hiérarchique. Si vous avez une meilleure idée, n'hésitez pas à la proposer bien sûre. Voir la section "Tâches de qualification" pour plus de détail sur cette méthode.

Ce projet n'est pas recommandé à moins que vous possédiez une expérience significative avec CUDA ou OpenCL.

* Difficulté : Très importante
* Quantité de travail : Moyenne
* Compétences requises : Très importantes

[Subbat]

Merci...