En regardant la version de FFMPEG dans MCEBuddy, il est indiqué « N-95085-g525de95679 », ce qui ne révèle pas grand-chose sur les dates/versions de FFMPEG. Il est mentionné qu’elle a été compilée avec gcc 20190918, mais on ne sait pas si c’est la date du compilateur GCC utilisé pour compiler cette version de FFMPEG ou la date à laquelle FFMPEG a été extrait du dépôt git et compilé.
Je vois que Gyan Doshi publie des builds hebdomadaires qui incluent bien les encodeurs/décodeurs NVENC et NVDEC.
Voir ici : Builds - CODEX FFMPEG @ gyan.dev
Handbrake semble être en version 1.3.3 avec nVenc version 12.0.
La version actuelle est 1.5.1. Je ne sais pas si Handbrake inclut le décodeur NVDEC ou seulement l’encodeur NVENC.
Ma question est : pouvons-nous remplacer les fichiers .exe de FFMPEG et HandbrakeCLI par des versions plus récentes en simple drop-in ?
Si ce n’est pas possible, quand peut-on s’attendre à ce que ces utilitaires critiques soient mis à jour aux versions actuelles dans MCEBuddy ?
Est-il possible d’exploiter les décodeurs GPU pour comskip ?
Nous testons les versions plus récentes des différents outils. Nous devons vérifier la stabilité et les performances (ainsi que la compatibilité). Souvent, les versions plus récentes comportent des bogues ou parfois des performances inférieures ; par exemple, nous avons différentes versions de HandBrake pour les conversions Intel QSV et pour les conversions NVEnc. Chaque cycle de test prend des semaines de tests 24h/24 et 7j/7 sur de nombreuses machines et des centaines de milliers de fichiers avant d’être certifié pour une utilisation générale avec MCEBuddy.
Mais pour un usage personnel, allez-y absolument, remplacez simplement le fichier, testez-le et n’hésitez pas à partager vos commentaires.
La mise à jour de FFMPEG est également quelque chose que j’attends avec impatience.
Je n’utilise plus MCEBuddy pour réencoder mes enregistrements car il ne gère pas l’audio AC-4 utilisé dans l’ATSC 3.0. Au lieu de cela, je me contente de copier et renommer les fichiers, puis je laisse Emby les transcoder car Emby dispose d’un FFMPEG mis à jour qui le prend en charge. Mais j’aimerais vraiment pouvoir réutiliser MCEBuddy, car il me offre beaucoup plus d’options de configuration et de contrôle.
Les versions officielles de FFmpeg ne prennent pas encore en charge l’AC-4. C’est toujours en développement, mais si vous disposez des versions de développement préliminaires, vous pouvez toujours les utiliser avec MCEBuddy.
Les builds Emby sont basés sur un arbre FFMPEG 5.
Dans les journaux de transcodage, je vois :
*01:56:01.333 ffmpeg version 5.1-emby_2022_10_11 Copyright (c) 2000-2022 the FFmpeg developers and softworkz for Emby LLC*
*01:56:01.334 built with gcc 10.3.0 (Rev5, Built by MSYS2 project)*
J’ai essayé de les remplacer par les builds MCEBuddy, mais ensuite les tâches ne s’exécutaient plus. Ça remonte à un moment, mais si je me souviens bien, la ligne de commande que MCEBuddy passait à FFMPEG ne faisait pas le travail.
J’ai installé Handbrake-CLI v1.5.1 et, pour l’instant, tout fonctionne bien. Aucun problème. Win10x64 22H2 (19045.2364), i5-4430, RTX-2060.
Il semble que les ventilateurs du GPU tournent à un régime inférieur à leur maximum. L’utilisation du GPU est d’environ 60-70%, peut-être un peu moins ? L’utilisation du CPU reste autour de 95% pendant l’encodage.
Je n’ai pas traité le même fichier avec les deux versions, mais la même émission sur la même chaîne, traitée précédemment avec MCE Buddy et Handbrake 1.3.1, semble avoir une chroma plus faible que celle traitée avec 1.5.1 quand je les ai lues côte à côte et synchronisées pour voir les différences entre les deux versions de Handbrake.
Je ne sais pas si le temps de traitement est plus lent ou plus rapide entre les versions de Handbrake. Je transcode en H.265 et AC3 dans un conteneur MKV.
Mise à jour de mes tests de mises à jour directes (limités, 1 point de données, Intel i5-Haswell, RTX2060) :
Handbrake CLI 1.6.1 - OK, depuis 1.3.3. N’ai pas touché CLI-qsv (1.0.7), bien que 1.6.1 prétende prendre en charge, donc la version qsv n’est plus nécessaire ?
MKVMerge et MKVExtract 74.0.0 - OK, depuis 17.0.0 (télécharger la version portable et extraire les utilitaires individuels)
AVIdemux 2.8.1 - OK, depuis 2.7.1 (l’application a été restructurée, j’ai juste gardé le répertoire plugins)
FFMPEG 6.0 stable est sorti ! J’ai utilisé les builds de gyan.dev.
Détails : FFmpeg
Comskip - 0.80.003. La version actuelle des donateurs est 0.82.012.
Je ne sais pas s’il utilise le ffmpeg externe ou s’il a sa version intégrée.
Espérons qu’il utilisera celui fourni par MCEBuddy.
Juste une note sur la sortie de HandBrake 1.7 publiée sur GitHub. À noter, l’intégration d’FFmpeg v6.1 et le support d’AV1, y compris NVENC. La version officielle devrait arriver dans les prochains jours, elle est déjà disponible dans les versions nightly.
Notable dans ce qui précède, l’inclusion de NVENC SV1 (encodage matériel nVidia vers SV1).
Ceci est désormais présent dans les versions nocturnes de Handbrake, et Handbrake 1.7.0 devrait sortir très prochainement.
Cependant, l’encodage GPU NVENC SV1 n’est disponible que sur les nouvelles cartes Ada (série RTX40).
On ne sait pas si nVidia rétrogradera l’encodeur vers les séries RTX10 (Pascal), RTX20 (Turing) ou RTX30 (Ampere). Je n’ai pas de carte RTX40, donc je ne vois pas l’option.
Si j’obtiens une carte RTX40, ce sera le point de basculement pour que je passe de x265.
L’équivalent audio de codec ouvert à SV1 est Opus. Malheureusement, il y a peu de support (jusqu’à présent) dans les appareils pour ce codec, et un fort ancrage médiatique et un support pour des codecs sous brevets comme AAC, AC3, E-AC3 et Dolby 5.1.
Donc pour l’instant, mon futur encodage multimédia ressemble à SV1 et AAC.