Pourquoi le processeur est “ meilleur ” pour le codage que le GPU?

Larticle que vous avez lié nest pas très bon.

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

x264 « s one-pass ABR ratecontrol nest pas implémenté en tant que limite CRF +. Il a raison que 2pass est de loin le meilleur moyen datteindre un débit cible, cependant.

Et apparemment, il ne se rend pas compte quil pourrait démarrer x264 avec threads = 3 ou quelque chose comme ça, pour laissez du temps processeur libre pour dautres tâches. Ou définissez la priorité de x264 sur très faible, de sorte quil nobtienne que du temps CPU quaucune autre tâche ne souhaite.

Il mélange également threads = 1 avec lutilisation de CUDA, ou quelque chose du genre. Pas étonnant que vous ayez des questions, car larticle a une explication TERRIBLE. Larticle entier 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 dentrée AviSynth. Il recommande en fait  » placebo « . Cest hilarant. Je « nai jamais vu de fichier piraté encodé avec un placebo. (Vous pouvez le dire à partir de me=esa ou me=tesa, au lieu de me=umh pour tous les préréglages de bonne qualité, jusquà veryslow.

Il ne mentionne pas non plus lutilisation dune profondeur de couleur de 10 bits. encoder et décoder, mais même après une conversion descendante en 8 bits, vous obtenez un meilleur SSIM 8 bits. Avoir plus de précision pour les vecteurs de mouvement est apparemment utile. De plus, ne pas avoir à arrondir exactement à une valeur 8 bits entière aide. Vous pouvez penser à 8 -bit par composant comme un speed-hack; quantifier dans le domaine fréquentiel puis compresser cela avec CABAC signifie que des coefficients de profondeur de bits plus élevés ne doivent pas prendre plus despace.

(BTW, h. 265 tire moins profit des encodages 10 bits pour la vidéo 8 bits car il a déjà plus de précision pour les vecteurs de mouvement. Sil ya un avantage à utiliser 10 bits x265 pour les entrées vidéo 8 bits, il est plus petit quavec x264. Il est donc moins probable que la pénalité de vitesse Jen vaux la peine.)

Pour répondre à votre question:

edit: doom9 est de nouveau en place, je vais donc ranger le lien. Accédez-y pour savoir 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 ne montre pas correctement les citations. Je ne sais pas exactement quelles parties de ces messages sont des guillemets et lesquelles sont attribuées à la personne elle-même.

Les schémas de branchement très irréguliers (modes de saut) et la manipulation de bits (quantification / codage dentropie) ne conviennent pas aux GPU actuels. IMO le seul les algorithmes ME de recherche complète sont une très bonne application pour le moment, bien que la recherche complète accélérée soit encore lente même si elle est plus rapide que sur le processeur.
– MfA

En fait, fondamentalement, tout peut être raisonnablement fait sur le GPU sauf CABAC (ce qui pourrait être fait, cela ne pouvait tout simplement pas être parallélisé).

x264 CUDA implémentera un fullpel et lalgorithme de sous-pixel ME au départ; plus tard, nous pourrions faire quelque chose comme RDO avec un coût en bit ximation au lieu de CABAC.

Parce quil doit tout faire en virgule flottante simple précision
– MfA

Faux, CUDA prend en charge le calcul des nombres entiers.

– Dark Shikari

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

AFAIK, ce projet CUDA na pas abouti. Il existe un support pour utiliser OpenCL pour décharger certains travaux du thread de recherche (décision rapide I / P / B, pas un encodage final de haute qualité de la trame).

Daprès ce que je comprends , lespace de recherche pour le codage vidéo est tellement grand que lheuristique intelligente pour la terminaison précoce des chemins de recherche sur les processeurs bat les GPU de force brute apporter à la table, au moins pour un encodage de haute qualité. Cest seulement comparé à -preset ultrafast où vous pourriez raisonnablement choisir le codage matériel plutôt que x264, surtout si vous avez un processeur lent (comme un ordinateur portable avec double cœur et sans hyperthreading). Le processeur (quad core i7 avec hyperthreading), x264 superfast sera probablement aussi rapide et sera meilleur (au même débit).

Si vous « effectuez un encodage où la distorsion de taux (qualité par taille de fichier) compte du tout, vous devez utiliser x264 -preset medium ou plus lentement. Si vous » archiver quelque chose, dépenser un peu plus de temps CPU maintenant économisera des octets tant que vous « gardez ce fichier autour de vous.

note latérale, si jamais vous voyez des messages de deadrats sur un forum vidéo, cest » ne sera pas utile. Il sest trompé sur la plupart des sujets dont il parle dans tous les fils que jai jamais vus. Ses messages sont apparus dans quelques fils que jai recherchés sur le codage GPU x264. Apparemment, il ne comprend pas pourquoi ce nest pas facile, et a posté plusieurs fois pour dire aux développeurs x264 pourquoi ils « sont idiots …

Mise à jour 2017:

ffmpeg prend en charge lencodage vidéo accéléré par GPU NVENC h264 et h265 . Vous pouvez effectuer un encodage en 1 ou 2 passages avec la qualité de votre choix, pour hevc_nvenc ou h264_nvenc, ou même avec un GPU dentrée de gamme, cest beaucoup plus rapide que lencodage non accéléré et lencodage accéléré Intel Quick Sync.

Encodage de haute qualité en 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 NVENC ffmpeg:

ffmpeg -h encoder=nvenc 

Utilisez-le, cest beaucoup plus rapide que lencodage CPU.

Si vous ne possédez 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é.

Commentaires

• Utilisez-le si vous accordez une valeur à la vitesse (et à une faible utilisation du processeur) par rapport à la qualité par taille de fichier. Dans certains cas dutilisation, par exemple le streaming vers twitch, que ‘ est ce que vous voulez (en particulier la faible utilisation du processeur). Dans dautres, par exemple encoder une fois pour créer un fichier qui sera diffusé / regardé plusieurs fois, vous nêtes toujours pas va battre -c:v libx264 -preset slower (ce qui nest pas si lent, comme en temps quasi réel pour 1920x1080p24 sur un Skylake i7-6700k.)
• Lutilisation de ffmpeg avec -vcodec h264_qsv sur mon ancien ordinateur portable Intel avec un Intel HD Grpahics 4000 a rendu le rendu beaucoup plus rapide!

Pour développer un peu plus ce que dit Peter, en général lutilisation de plusieurs processeurs aide dans les cas où vous avez plusieurs tâches indépendantes qui doivent être effectuées mais n’ont pas de dépendances les unes sur les autres, ou une tâche où vous «exécutez les mêmes calculs sur des quantités massives de données.

Si, cependant, vous avez besoin de la sortie du calcul A en tant quentrée du calcul B, et la sortie du calcul B en tant quentrée du calcul C, alors vous pouvez « t laccélérer en ayant un travail de base différent sur chaque tâche (A, B ou C) car on ne peut » t commencer jusquà ce que lautre se termine.

Cependant, même dans le cas ci-dessus, vous pourrez peut-être o parallélisez-le dune autre manière. Si vous pouvez diviser vos données dentrée en morceaux, vous pouvez avoir un travail de base sur A, puis B, puis C avec un morceau de données, tandis quun autre noyau travaille sur A, puis B, puis C sur un autre morceau de données .

Il y a aussi dautres considérations. Vous pourriez peut-être trouver un moyen de paralléliser les calculs, mais la simple lecture des données à partir du disque, ou via le réseau, ou leur envoi au GPU prendra plus de temps que les calculs. Dans ce cas, cela na pas de sens 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 gagnez en faisant le calcul en parallèle.

En dautres termes, cest autant un art quune science.

Commentaires

• Oh, oui x264 est assez bien parallélisé sur les processeurs multicœurs. Je mets à léchelle presque linéairement jusquà au moins 8 cœurs, et décemment même au-delà de 32. Lestimation 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.
• La question nest pas ‘ t parallélisme en général, il ‘ s GPU en particulier. Ils ‘ sont beaucoup plus restrictifs dans le code que vous pouvez les faire exécuter que les processeurs. Je pense que ‘ est parce que vous pouvez ‘ t avoir du code avec des branches qui vont de différentes manières sur différents blocs de limage. Je ne ‘ pas comprendre exactement pourquoi, mais je pense que ‘ 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é dans le branchement du tout, ou les deux.
• Si vous aviez un cluster dordinateurs (processeurs avec RAM indépendante qui ne se sont ‘ qui se font concurrence pour la bande passante mémoire et le cache du processeur), vous ‘ d diviser votre vidéo dentrée en GOP et envoyer des sections de la vidéo dentrée encore compressée à décoder et compresser sur dautres machines du cluster.Ainsi, seule la vidéo dentrée ou de sortie compressée devrait être transférée. Un système multicœur de cache partagé / RAM comme même une station de travail x86 multisocket, vous avez plusieurs threads qui fonctionnent sur les mêmes trames à la fois. (signifie également que vous navez ‘ pas besoin dun nouveau code pour effectuer un contrôle global du taux de segmentation des codes.)