Vous avez un flux vidéo d’enregistrement défectueux
2018-02-11T20:52:13 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000021729d1a240] start time for stream 0 is not set in estimate_timings_from_pts
2018-02-11T20:52:13 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000021729d1a240] Could not find codec parameters for stream 0 (Video: h264 ([27][0][0][0] / 0x001B), none): unspecified size
À cause de cela, ffmpeg s’étouffe et échoue.
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Stream #0:0 → #0:0 (h264 (native) → h264 (libx264))
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Stream #0:1 → #0:1 (ac3 (native) → aac (libfdk_aac))
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Press [q] to stop, [?] for help
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Too many packets buffered for output stream 0:1.
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → [libfdk_aac @ 00000215284102e0] 2 frames left in the queue on closing
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Conversion failed!
J’ai aussi remarqué que vous avez retiré handbrake de votre ordre d’encodeurs afin qu’il n’essaie pas de revenir sur handbrake pour l’encoder :
order=ffmpeg,mencoder
essayez d’ajouter handbrake après ffmpeg
La cause profonde est toutefois un périphérique d’enregistrement défectueux qui crée un fichier vidéo non conforme. Cela peut être dû à un mauvais firmware du périphérique ou à des pilotes défectueux.
Merci d’avoir jeté un œil à tout cela. J’ai tellement modifié les pilotes, profils, etc. depuis que la vidéo a été enregistrée (pour réussir l’encodage matériel) que je ne suis pas sûr de pouvoir résoudre ce mystère.
Ce n’est pas grave car je n’ai rien vu de semblable dans les enregistrements suivants…
Quelques questions :
L’erreur mentionnée dans mon message initial (« Please use -b:a or -b:v, -b is ambiguous ») contient-elle une information utile ou est-ce une fausse piste ?
J’ai supprimé Handbrake car c’était le seul moyen de forcer FFMPEG à faire l’encodage matériel sur NVIDIA. Vu que j’ai une carte NVIDIA avec CUDA et une carte Intel avec QuickSync… l’ordre actuel faisait qu’Handbrake passait par un encodage logiciel.
Je vais donc laisser Handbrake saturer mon CPU pendant un moment pour convertir tout ça…
Aucune conséquence, ffmpeg admet plusieurs styles de saisie ; nous utilisons une ancienne, plus compatible.
Compris, dans la prochaine version nous corrigerons également cela afin qu’il ne réordonne pas les encodeurs si les deux prennent en charge l’encodage matériel.
Il est tout à fait possible que je n’aie pas compris ce que ce patch était censé faire, mais je ne pense pas que cela ait fonctionné. Deux journaux d’exemples sont ci-dessous.
J’ai laissé les profils par défaut intacts lors de l’installation de la bêta 2-12, pensant que l’algorithme finirait par choisir FFMPEG puisque le cas idéal est l’encodage matériel avec mon NVIDIA.
Ce n’était apparemment pas le cas, car les journaux montrent que les deux tâches ont utilisé HandBrake… sans accélération matérielle.
Veuillez me dire si mes hypothèses sur la façon dont cela aurait dû fonctionner étaient incorrectes.
Ce correctif visait à préserver l’ordre sélectionné par l’utilisateur de l’encodeur si plusieurs encodeurs prennent en charge l’encodage matériel. Dans votre cas, à la fois handbrake et ffmpeg prennent en charge les capacités d’encodage matériel, donc il s’est assuré de ne pas réorganiser votre préférence.
Votre profil ressemblait à :
order=handbrake,ffmpeg,mencoder
Vous avez demandé à MCEBuddy d’utiliser handbrake en premier, puis ffmpeg, et c’est exactement ce qu’il a fait.
Je pense que vous vouliez écrire :
order=ffmpeg,handbrake,mencoder
Utiliser d’abord l’encodeur ffmpeg (matériel) et s’il échoue, revenir à handbrake.
Merci Goose. Cela a résolu le problème immédiat. J’ai changé l’ordre et j’ai vérifié que FFMPEG est utilisé pour l’encodage matériel sur ma carte NVIDIA (ce qui n’était pas le cas en 2.4.8).
Cela me conduit à quelques questions/remarques :
Premièrement… je pense avoir mal compris ce qui était fait. Préserver l’ordre me permet de forcer ffmpeg, mais une solution encore plus flexible serait que MCEBuddy conclue par lui-même quelle voie emprunter en fonction de la configuration.
Je suggère qu’il serait idéal que MCEBuddy essaie d’abord toutes les routes d’encodage matériel, puis le logiciel. Le problème original en 2.4.8 était que MCEB tentait l’encodage matériel Handbrake, échouait, puis revenait à Handbrake logiciel. Ce n’était pas idéal pour ma configuration.
C’est peut-être un souhait un peu utopique, mais le cas idéal aurait été d’essayer le matériel Handbrake, d’échouer, puis de passer au matériel ffmpeg. Si cela échouait, on parcourrait à nouveau la liste avec l’encodage logiciel.
Accepteriez-vous également une demande de fonctionnalité concernant le Profile.conf actuel ? Il n’est pas idéal que je doive changer l’ordre de chaque profil utilisant Handbrake pour chaque bêta et version que j’installe.
Une alternative possible serait d’avoir le concept d’un « fichier de profil utilisateur » dans un répertoire Utilisateur (plutôt que dans le répertoire Programme). Ce fichier resterait intact lors des mises à jour et pourrait servir à deux fins :
Des profils utilisateur personnalisés pourraient être créés et maintenus et apparaîtraient dans le menu avec les profils système.
Les valeurs des profils existants pourraient être outrepassées. Cela permettrait aux éléments modifiables (comme les paramètres ffmpeg) d’être mis à jour avec les nouvelles versions tout en conservant les préférences utilisateur comme l’ordre des convertisseurs.
Juste quelques réflexions ; j’ai l’avantage de ne pas avoir la moindre idée de la complexité.
C’est une excellente nouvelle que l’ordre « Hardware first » soit sur la feuille de route.
Concernant la discussion sur le profil personnalisé ci-dessus, je vais soumettre une demande de fonctionnalité car je pense que le profil utilisateur est un fichier « au lieu de » plutôt qu’un « en plus de ». Ma suggestion est que si vous avez 10 profils dans la configuration standard et deux dans le profil utilisateur, MCEbuddy afficherait les 12 et non seulement les deux du profil utilisateur. Je pense que cela serait beaucoup plus utile et flexible…
N’hésitez pas à ouvrir une demande de fonctionnalité, celle-ci est délicate pour une seule raison. Les gens ne renomment parfois pas le profil, donc vous vous retrouvez avec deux profils, un provenant du maître et un autre du personnalisé, nous devrons déterminer lequel prend le dessus.
Je vais ouvrir une demande séparée. Ma position sur le problème de doublon est qu’on préfixe « USER_ » à tout ce qui se trouve dans le fichier utilisateur. Ainsi, « MP4 Normal » dans le fichier de profil officiel restera distinct de « USER MP4 Normal » dans le fichier utilisateur.
