Pourquoi le processeur est-il «meilleur» pour l'encodage que le GPU?

Je lisais cet article et j'ai vu qu'un processeur est meilleur pour la compression vidéo qu'un GPU.

L'article dit seulement que cela se produit parce que le processeur peut gérer des algorithmes plus complexes que le GPU, mais je veux une explication plus technique, j'ai fait des recherches sur Internet mais je n'ai rien trouvé.

Donc, quelqu'un sait expliquer ou lier un site à une explication plus approfondie de cela?

L'article que vous avez lié n'est pas très bon.

Normalement, les codages de débit binaire en un seul passage convertissent votre débit binaire en une valeur RF avec une limite de débit binaire maximale et le prennent à partir de là.

Le contrôle de rat ABR en un seul passage de x264 n'est pas implémenté comme limite CRF +. Il a raison de dire que le 2pass est de loin le meilleur moyen d'atteindre un débit binaire cible.

Et apparemment, il ne se rend pas compte qu'il pourrait démarrer x264 avec threads = 3 ou quelque chose, pour laisser du temps CPU libre pour d'autres tâches. Ou définissez la priorité de x264 sur très faible, de sorte qu'il n'obtienne que du temps CPU qu'aucune autre tâche ne veut.

Il mélange également les threads = 1 avec CUDA, ou quelque chose comme ça. Pas étonnant que vous ayez des questions, car cet article a une TERRIBLE explication. L'article se résume essentiellement à: utiliser x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, ou peut-être utiliser un filtrage de la lumière avec un script AviSynth d'entrée. Il recommande en fait un "placebo". C'est hilarant. Je n'ai jamais vu un fichier piraté encodé avec un placebo. (vous pouvez le dire depuis me=esaou me=tesa, au lieu de me=umhpour tous les presets de bonne qualité, jusqu'à veryslow.

Il ne mentionne pas non plus l'utilisation d'une profondeur de couleur de 10 bits. L'encodage et le décodage sont plus lents, mais même après une conversion vers le bas en 8 bits, vous obtenez un meilleur SSIM 8 bits. Avoir plus de précision pour les vecteurs de mouvement aide apparemment. De plus, ne pas avoir à arrondir à exactement une valeur entière de 8 bits aide. Vous pouvez considérer le 8 bits par composant comme un piratage de vitesse; quantifier dans le domaine fréquentiel puis compresser avec CABAC signifie que les coefficients de profondeur de bits plus élevés n'ont pas besoin de prendre plus de place.

(BTW, h.265 obtient moins d'avantages des encodages 10 bits pour la vidéo 8 bits car il a déjà plus de précision pour les vecteurs de mouvement. S'il y a un avantage à utiliser 10 bits x265 pour les entrées vidéo 8 bits, il est plus petit que avec x 264. Il est donc moins probable que la pénalité de vitesse en vaille la peine.)

Pour répondre à votre vraie question:

edit: doom9 est de nouveau opérationnel, donc je vais ranger le lien. Allez-y pour citer correctement qui a dit quoi.

http://forum.doom9.org/showthread.php?p=1135399#post1135399

Google ne met en cache que la version imprimée stupide qui n'affiche pas correctement la citation. Je ne sais pas trop quelles parties de ces messages sont des citations et lesquelles sont attribuées à la personne elle-même.

Les modèles de branchement très irréguliers (modes de saut) et la manipulation de bits (codage de quantification / entropie) ne conviennent pas aux GPU actuels. IMO la seule très bonne application pour le moment sont les algorithmes ME de recherche complète, en fin de compte bien que la recherche complète accélérée soit toujours lente même si elle est plus rapide que sur le CPU.
- MfA

En fait, pratiquement tout peut être raisonnablement fait sur le GPU, sauf CABAC (ce qui pourrait être fait, il ne pouvait tout simplement pas être mis en parallèle).

x264 CUDA implémentera initialement un algorithme ME fullpel et subpel; plus tard, nous pourrions faire quelque chose comme RDO avec une approximation à peu de frais au lieu de CABAC.

Parce qu'il doit tout faire en virgule flottante simple précision
- MfA

Mauvais, CUDA prend en charge les mathématiques entières.

- Shikari foncé

Dark Shikari est le mainteneur x264 et le développeur de la plupart des fonctionnalités depuis 2007 environ.

AFAIK, ce projet CUDA n'a pas abouti. Il existe une prise en charge de l'utilisation d'OpenCL pour décharger du travail à partir du thread d'anticipation (décision I / P / B rapide, pas un encodage final de haute qualité de la trame).

Ma compréhension est que l'espace de recherche pour le codage vidéo est tellement grand que l'heuristique intelligente pour la terminaison précoce des chemins de recherche sur les processeurs bat les GPU à force brute apportés à la table, au moins pour le codage de haute qualité. C'est seulement par rapport à l' -preset ultrafastendroit où vous pouvez raisonnablement choisir l'encodage HW plutôt que x264, en particulier. si vous avez un processeur lent (comme un ordinateur portable avec double cœur et sans hyperthreading). Sur un processeur rapide (i7 quad core avec hyperthreading), x264 superfastva probablement être aussi rapide et avoir une meilleure apparence (au même débit binaire).

Si vous effectuez un encodage où la distorsion de débit (qualité par taille de fichier) est importante, vous devez utiliser x264 -preset mediumou plus lent. Si vous archivez quelque chose, passer un peu plus de temps CPU maintenant économisera des octets aussi longtemps que vous garderez ce fichier.

note de côté, si vous voyez des messages de rats morts sur un forum vidéo, cela ne sera pas utile. Il s'est trompé sur la plupart des choses dont il parle dans tous les sujets que j'ai jamais vus. Ses messages sont apparus dans quelques discussions que j'ai googlé sur l'encodage GPU x264. Apparemment, il ne comprend pas pourquoi ce n'est pas facile, et a posté plusieurs fois pour dire aux développeurs x264 pourquoi ils sont stupides ...

Mise à jour 2017:

ffmpeg prend en charge le codage vidéo accéléré par GPU N26C h264 et h265 . Vous pouvez effectuer un codage en 1 ou 2 passes à la qualité que vous choisissez, pour hevc_nvenc ou h264_nvenc, ou même avec un GPU d'entrée de gamme, c'est beaucoup plus rapide que le codage non accéléré et le codage accéléré Intel Quick Sync.

Encodage de haute qualité à 2 passes:

ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4

Encodage par défaut en 1 passe:

ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4

Aide et options de NVENC ffmpeg:

ffmpeg -h encoder=nvenc

Utilisez-le, c'est beaucoup plus rapide que l'encodage CPU.

Si vous n'avez pas de GPU, vous pouvez utiliser le codec Intel Quick Sync, h264_qsv, hevc_qsv ou mpeg2_qsv, qui sont également beaucoup plus rapides que l'encodage non accéléré.

Pour élaborer un peu plus sur ce que dit Peter, en général, l'utilisation de plusieurs processeurs aide dans les cas où vous avez plusieurs tâches indépendantes qui doivent toutes être effectuées mais n'ont pas de dépendances les unes des autres, ou une tâche où vous effectuez la même chose mathématiques sur des quantités massives de données.

Si, cependant, vous avez besoin de la sortie du calcul A comme entrée du calcul B et de la sortie du calcul B comme entrée du calcul C, vous ne pouvez pas l'accélérer en ayant un travail de base différent sur chaque tâche ( A, B ou C) parce que l'un ne peut pas commencer avant la fin de l'autre.

Cependant, même dans le cas ci-dessus, vous pourrez peut-être le paralléliser d'une autre manière. Si vous pouvez diviser vos données d'entrée en morceaux, vous pouvez avoir un travail de base pour faire A, puis B, puis C avec un morceau de données, tandis qu'un autre cœur travaille sur faire A, puis B, puis C sur un autre morceau de données .

Il y a aussi d'autres considérations. Vous pourriez peut-être trouver un moyen de paralléliser les calculs, mais simplement lire les données à partir du disque, ou sur le réseau, ou les envoyer au GPU prendra plus de temps que de faire les calculs. Dans ce cas, il n'est pas logique de le paralléliser car le simple fait de mettre les données en mémoire prend plus de temps que le temps que vous économisez en effectuant le calcul en parallèle.

En d'autres termes, c'est autant un art qu'une science.