Je viens de mettre à niveau mon serveur d’un p2200 à un a2000. Avec la version ffmpeg intégrée dans mcebuddy sur l’a2000, j’encode à 5,11x. Avec v6.0, je dépasse le double à 11,9x. Je réitère ma demande de mettre à jour ffmpeg dans mcebuddy.
@techpro2004, en attendant, vous pouvez essayer de copier une version plus récente de FFMPEG dans le dossier du programme de MCEBuddy appelé « ffmpeg ». Vous remplacerez simplement les fichiers ffmpeg.exe et ffprobe.exe de la nouvelle version.
J’utilise la version « essentials » de FFMPEG 6.0 pour Win10x64 depuis Builds - CODEX FFMPEG @ gyan.dev
Si vous compilez la vôtre, vous voudrez inclure vos bibliothèques GPU et tout lier statiquement.
Je préfère utiliser la version officielle de ffmpeg de mcebuddy car elle a été minutieusement vérifiée.
Goose, encore une fois, merci de mettre à jour la version de ffmpeg dans mcebuddy. Et merci de nous informer que vous travaillez dessus.
Merci.
Oie, tu es là ?
Bonjour Goose.
En regardant de plus près Handbrake, il semble qu’ils n’utilisent même pas FFMPEG pour l’encodage matériel AV1. Ils utilisent SVT-AV1 pour cela.
- Ajout des encodeurs vidéo SVT-AV1 (logiciel, v1.4.1) et Intel QSV AV1 (matériel)
Donc peut-être que demander une mise à jour de FFMPEG n’est pas la bonne requête ici. Cela pourrait avoir un rapport avec la raison pour laquelle Goose a dit plus tôt que « c’est compliqué ».
Si vous en avez besoin immédiatement, vous avez une solution : déposez le nouveau FFMPEG de votre choix, même compilé et optimisé spécifiquement pour votre plateforme, OS, CPU et GPU. (Ce que vous n’avez pas partagé, au fait).
Si vous pouvez attendre (comme vous l’avez dit plus tôt) que Goose et les développeurs de MCEBuddy fassent les tests et tests de régression pour toutes les permutations de plateformes, systèmes d’exploitation, CPU et GPU utilisés par tous les utilisateurs de MCEBuddy, alors attendez.
Si vous avez un besoin urgent juste pour vous, vous pouvez toujours demander un prix pour un contrat de développement afin de faire une version personnalisée, rien que pour vous, selon vos spécifications et un calendrier convenu.
pas de besoin urgent, je veux juste savoir qu’ils travaillent dessus.
a aussi dit il y a 5 jours quelle gpu mon serveur utilise et goose sait ce que mon autre système utilise depuis le premier message du fil.
Oie??? Un mot ???
Nous observons des problèmes de stabilité avec le matériel Intel
Je rencontre également des problèmes de stabilité avec la version actuelle de MCEBuddy sur du matériel NVIDIA. Ce n’est pas la version FFmpeg qui en est la cause. Veuillez consulter mon autre fil de discussion. Mon hypothèse (ce n’est qu’une supposition) est que cela est lié au décodeur matériel. Merci de faire des tests avec ceci.
Oie, y a-t-il une mise à jour là-dessus ? Merci.
Juste une note. En examinant le support d’encodage/décodage GPU d’NVIDIA pour l’A2000, il n’y a pas de support GPU pour AV1.
Source : Video Encode and Decode Support Matrix | NVIDIA Developer
Aussi, MCEBuddy utilisant Comskip, utilisera le FFMPEG intégré dans le binaire Comskip. Lorsque MCEBuddy utilise Handbrake pour le transcodage, Handbrake utilisera le FFMPEG intégré dans le binaire CLI Handbrake.
Donc, déposer une version plus récente de FFMPEG n’affecte que le transcodage effectué avec FFMPEG. Selon vos paramètres de flux de travail dans MCEBuddy, plusieurs versions différentes de FFMPEG pourraient être utilisées pendant les différentes étapes de votre flux de travail.
J’ai 2 systèmes, un avec une 4080 pour l’encodage et un autre avec une A2000 pour le service.
Je ne me soucie pas de comskip, juste de l’encodage.
Goose, as-tu testé sans décodage matériel ? Merci
J’ai également remarqué que, bien que mon transcodage soit configuré pour utiliser Handbrake, la partie « Fast Remux » du traitement utilise ffmpeg et ne fait pas appel au décodage matériel. Je ne suis pas certain qu’il existe un moyen d’ajouter des options de ligne de commande personnalisées pour MCEBuddy lors de l’utilisation de ffmpeg ou de comskip. Bien qu’il soit possible de spécifier un chemin personnalisé pour comskip, il ne semble pas y avoir de façon d’inclure des options purement en ligne de commande disponibles dans les versions donateur plus récentes (il n’existe pas d’équivalents dans la configuration --cuvid doit être passé en ligne de commande).
Mon transcodage est configuré dans MCEBuddy pour utiliser HandbrakeCLI, et il utilise bien la nVidia pour transcoder en x.265 (une 2060).
Mike808, mcebuddy utilise le décodage matériel pour l’étape d’encodage sur ffmpeg uniquement. Merci de confirmer qu’Handbrake n’utilise pas cuvid et que cela fonctionne ; ensuite, vous pourriez tester l’encodage ffmpeg avec un large éventail de sources afin de confirmer ma théorie. J’utilise une antenne OTA, donc la réception n’est pas toujours optimale. Je trouve qu’Handbrake est bien plus tolérant qu’ffmpeg. Je suppose qu’il n’y a pas de cuvid. Veuillez le tester comme ceci.
Goose, des nouvelles des tests sans cuvid ?
Je pense que vous avez mal interprété ce que j’ai observé.
MCEBuddy traite les médias en gros en 3 étapes.
L’étape 1 est traitée avec Comskip. Le Comskip fourni avec MCEBuddy est la version donateur, mais quand Comskip parle de HWAssist, cela ne signifie pas le GPU. Cela désigne les fonctionnalités natives du CPU (GPU intégré) des processeurs Intel et des APU AMD avec des codecs média embarqués. Ainsi, Comskip n’utilise pas votre GPU et est limité au CPU.
La dernière version de Comskip possède bien des options de décodage GPU, mais elles ne sont pas actuellement accessibles dans MCEBuddy. J’ai ouvert une demande de fonctionnalité pour ajouter un moyen de passer l’option en ligne de commande « -cuvid » ou « -vdpau ». Encore une fois, Comskip est actuellement toujours limité au CPU, même si vous utilisez un Comskip personnalisé et qu’il s’agit de la toute dernière version donateur.
L’étape 2 est le démultiplexage, où les flux vidéo et audio sont séparés, et utilise le décodage. C’est ici que MCEBuddy semble utiliser FFMPEG (quel que soit le réglage Handbrake pour l’encodage/la conversion), et la version d’FFMPEG, bien qu’elle possède des encodeurs GPU, ne possède pas de décodeurs GPU. Seule la toute nouvelle version d’FFMPEG en dispose, et MCEBuddy n’invoque pas l’option GPU pour le décodage, car il ne sait pas qu’elle existera dans une future version d’FFMPEG, même si vous la placez vous-même.
L’étape 3 est la conversion vidéo où il applique les coupures de pubs (fichier EDL) provenant de Comskip aux flux vidéo et audio séparés (décodage à nouveau) et encode dans le format de sortie combiné avec les pubs supprimées.
À l’étape 3, le décodage des flux semble utiliser le CPU, et la fusion ainsi que le transcodage utilisent bien le GPU. Cela rend l’étape 3 limitée à la fois par le CPU et le GPU. Handbrake utilise son propre FFMPEG lié statiquement, et n’utilise pas le GPU pour décoder, mais utilise les fonctionnalités de lecture et d’encodage intégrées au CPU du GPU intégré sur la puce CPU si disponible, et utilisera le GPU quand activé dans MCEBuddy. Il en va de même si vous avez configuré MCEBuddy pour utiliser FFMPEG au lieu de Handbrake.
Je ne pense pas que la version d’FFMPEG intégrée au CLI Handbrake (la version MCEBuddy, 1.3.3 ?) possède un décodage GPU, et la version la plus récente (1.6.1 ?) ne dispose pas d’options utilisées par MCEBuddy qui n’existent pas pour la version qu’il emploie, même si vous la remplacez. Ainsi, cette partie de la « conversion vidéo » reste limitée au CPU.
En résumé, c’est assez compliqué de savoir quand et si MCEBuddy peut ou va utiliser des versions plus récentes de ces sous-composants, et même si c’était le cas, il y a plusieurs endroits où cela doit être fait séparément dans Comskip, FFMPEG et le CLI Handbrake. Même alors, toutes les options utilisées par Handbrake dépendent entièrement de l’FFMPEG lié statiquement à l’intérieur, et il est distinct de l’FFMPEG autonome invoqué par MCEBuddy.
Oie, qu’est-ce qui se passe ? as-tu essayé sans le décodage matériel. Merci.
Je vous suggère de poursuivre l’échange en message privé avec Goose.
Quand vous publiez sur le forum, c’est pour que la communauté tente d’aider. Ce qui n’est pas utile, c’est d’attaquer quelqu’un qui essaie d’aider ou de comprendre le sujet du message.
Bonne idée, au fait je ne pensais pas que j’attaquais. Je pensais être resté assez tolérant pendant longtemps.
Vous avez dit, et je cite :
« lorsque l’on utilise ffmpeg, mcebuddy ajoute automatiquement les options de décodage GPU »
J’ai constaté que cela ne peut tout simplement pas être vrai. La version de FFMPEG fournie avec MCEBuddy ne peut pas utiliser le GPU pour le décodage, car cette capacité n’existe pas dans cette version de FFMPEG.
J’ai volontairement consacré mon temps à vérifier vos affirmations et j’ai publié mes résultats de test car je m’intéressais aussi aux binaires mis à jour (le sujet de ce fil). J’ai découvert que vos affirmations sur ce que vous pensez que MCEBuddy fait sont contraires à ce que le logiciel fait ou ne fait pas.
J’ai également indiqué où les versions plus récentes du logiciel sont effectivement capables de faire ce que vous demandez à MCEBuddy, mais qu’il ne fait pas et ne peut pas faire dans les versions actuelles.
J’ai aussi souligné pour vous, Goose et les autres développeurs de MCEBuddy, où il pourrait être possible d’ajouter davantage d’accélération GPU. Cependant, tous les GPU ne se valent pas, et le nombre de moteurs d’encodage et de décodage dédiés pourrait être un facteur crucial pour ajuster MCEBuddy afin qu’il serve la plus large base d’utilisateurs. Par exemple, mon 2060 ne possède qu’un seul pipeline d’encodage/décodage et il est parfaitement logique que, pour le transcodage (« conversion vidéo » selon le statut MCEBuddy), le décodage du TS se fasse sur le CPU (avec assistance matérielle du CPU) tandis que l’encodage se produit en parallèle sur le GPU. Sinon, il faudrait le faire en série en deux étapes GPU uniquement, sans bénéficier de parallélisation.
Je suis désolé si la réalité du fonctionnement de MCEBuddy est plus complexe que vous ne le souhaiteriez.
Si vous souhaitez une version personnalisée de MCEBuddy optimisée pour votre matériel et vos cas d’usage, vous devriez peut-être engager une discussion avec MCEBuddy pour financer ce développement personnalisé selon vos spécifications. Même dans ce cas, ce que vous demandez peut ne tout simplement pas exister si la fonctionnalité n’est pas disponible dans les composants open source (FFMPEG et Handbrake) et propriétaires (version donateur de comskip) sur lesquels MCEBuddy repose.
Peut-être que MCEBuddy n’est finalement pas l’outil adapté à vos besoins.