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

12

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?

Mateus Felipe Martins Da Costa
la source

Réponses:

20

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 ...

Peter Cordes
la source
9

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é.

Jack
la source
3
Utilisez-le si vous appréciez la vitesse (et la faible utilisation du processeur) par rapport à la qualité par taille de fichier. Dans certains cas d'utilisation, par exemple le streaming sur twitch, c'est ce que vous voulez (en particulier la faible utilisation du processeur). Dans d'autres, par exemple encoder une fois pour créer un fichier qui sera diffusé / regardé plusieurs fois, vous n'allez toujours pas battre -c:v libx264 -preset slower(ce qui n'est pas si lent, comme en temps quasi réel pour 1920x1080p24 sur un Skylake i7-6700k.)
Peter Cordes
L'utilisation ffmpegde -vcodec h264_qsvmon ancien ordinateur portable Intel avec un Intel HD Grpahics 4000 a rendu le rendu beaucoup plus rapide!
Tony
2

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.

user1118321
la source
Oh, oui x264 se parallèle assez bien sur les processeurs multicœurs. J'évolue de façon presque linéaire jusqu'à au moins 8 cœurs, et même au-delà de 32. L'estimation de mouvement peut être effectuée en parallèle, ne laissant que le travail nécessairement en série pour un autre thread, et des astuces similaires.
Peter Cordes
La question n'est pas le parallélisme en général, ce sont les GPU en particulier. Ils sont beaucoup plus restrictifs dans le code que vous pouvez les faire fonctionner que les CPU. Je pense que c'est parce que vous ne pouvez pas avoir de code avec des branches qui vont de différentes manières sur différents blocs de l'image. Je ne comprends pas exactement pourquoi, mais je pense que c'est quelque chose comme ça. Chaque processeur de flux est si simple et avec des moyens si limités de le faire fonctionner indépendamment des autres, que soit vous devez toujours attendre que le plus lent se termine, soit vous êtes limité en termes de branchement, ou les deux.
Peter Cordes
Si vous aviez un cluster d'ordinateurs (CPU avec RAM indépendante qui ne rivalisaient pas pour la bande passante mémoire et le cache CPU), vous diviseriez votre vidéo d'entrée en GOP et enverriez des sections de la vidéo d'entrée encore compressée pour qu'elles soient décodé et compressé sur d'autres machines du cluster. Ainsi, seule la vidéo d'entrée ou de sortie compressée devrait être transférée. Dans un système de cache partagé / RAM multicœur comme même un poste de travail x86 multisocket, plusieurs threads fonctionnent sur les mêmes trames à la fois. (signifie également que vous n'avez pas besoin de nouveau code pour effectuer le contrôle de rat global pour la segmentation des encodages.)
Peter Cordes