J’ai supprimé la version bêta précédente et installé la dernière bêta, mais mcebuddy coupe toujours les 10 premières secondes de chaque fichier que je convertis.
J’ai essayé d’activer « cut start » et de le régler à 1 seconde, mais cela ne change rien : je perds toujours 10 secondes au début de chaque vidéo.
De plus, j’ai défini le retrait de publicités sur « none » et la détection/optimisation de la qualité vidéo sur « désactivé », mais le journal est rempli d’entrées comskip et ffmpeg où le fichier est remuxé et analysé, comme si mcebuddy ignorait ces options désactivées.
J’ai joint les journaux et j’espère que quelqu’un pourra jeter un œil…
J’utilise mcebuddy pour automatiser mes anciennes méthodes handbrake ; je souhaite simplement un encodage direct CC21 avec une largeur maximale de 1280.
Vos journaux indiquent la durée correcte jusqu’à ce que handbrake commence l’encodage, puis à la fin il manque 10 secondes. La ligne de commande semble correcte. J’ai remarqué que vous utilisez l’encodage matériel (NVidia).
Ma seule hypothèse est que le pilote graphique supprime les 10 premières secondes à cause d’une corruption ou parce qu’il ne peut pas les gérer.
Essayez de désactiver l’encodage matériel et voyez si l’encodeur logiciel a le même problème. Vous pouvez également essayer de supprimer --start-at duration:0 de la ligne handbrake-video de votre profil, ce qui pourrait perturber la conversion en raison d’une corruption des timestamps.
Je n’utilise pas l’encodage matériel (qualité terrible), veuillez voir l’écran de configuration ci-joint.
Je vais donc essayer de supprimer le paramètre que vous avez mentionné
Avez-vous une idée de pourquoi mes vidéos sont également analysées ? J’ai désactivé tout cela, mais chaque fichier passe par un remuxage lent / rapide, etc…
Vous avez raison, désolé pour cela. Il utilise l’encodeur logiciel x265. Je vois ceci dans vos journaux :
2018-10-24T06:49:35 MCEBuddy.AppWrapper.Handbrake → [06:49:35] sync: first pts audio 0x100 is 0
2018-10-24T06:49:35 MCEBuddy.AppWrapper.Handbrake → [06:49:35] sync: first pts video is 430
La vidéo est peut-être corrompue. Quelques choses que vous pouvez essayer :
Supprimer le --start-at duration:0 de la ligne handbrake-video dans votre profil
Utiliser ffmpeg au lieu de handbrake (changer l’ordre dans votre profil)
Télécharger la dernière version nightly de handbrake et la remplacer dans votre dossier handbrake (cela pourrait être un problème dans handbrake avec l’encodeur x265 ne pouvant pas gérer le flux vidéo)
Les vidéos ne sont pas corrompues car mcebuddy fait cela sur toutes les vidéos, j’utilise la même version de Handbrake que dans mcebuddy et cela ne saute pas les 10 premières secondes, je préférerais rester avec Handbrake mais je suis prêt à essayer ffmpeg mais d’abord je vais supprimer ce paramètre et je vous ferai un retour
passer à ffmpeg a résolu le problème… la qualité ne semble pas aussi bonne qu’avec HandBrake ? c’est peut-être moi ? j’ai le même CC21 qu’avec HandBrake
Je suggérais que les horodatages sur les images vidéo initiales peuvent être corrompus, c’est pourquoi Handbrake saute les 10 premières secondes.
Handbrake et ffmpeg utilisent des bibliothèques similaires (en fait, la prochaine version de Handbrake utilisera la même bibliothèque que ffmpeg). Vous pouvez modifier les paramètres de profil et les filtres utilisés pour ffmpeg si vous connaissez bien ffmpeg.
Vous pouvez également jouer avec le curseur de qualité dans la tâche de conversion, essayez de l’augmenter et cela devrait également aider.
Vous pouvez télécharger la version nocturne CLI de HandBrake depuis leur site Web et remplacer celle fournie avec MCEBuddy pour voir si cela résout le problème.
J’ai remplacé le CLI par la dernière version nightly (HandBrakeCLI-20181023173755-177c1e3-master-win-x86_64)
Le début de chaque vidéo est-il encore tronqué de 10 s ?
J’ai créé un court fichier de test qui s’encode intégralement avec l’application autonome HandBrake et j’ai joint mon profil et les journaux pour cette courte vidéo ; d’autres idées ?
Les timestamps de la vidéo source sont corrompus au début. En regardant vos logs, même Comskip a des problèmes avec les timestamps au début de l’enregistrement.
2018-10-26T15:22:06 MCEBuddy.AppWrapper.CCExtractor → Found large gap(684) in PTS! Trying to recover …
2018-10-26T15:22:06 MCEBuddy.AppWrapper.CCExtractor → 3% | 00:00
2018-10-26T15:22:06 MCEBuddy.AppWrapper.CCExtractor → Found large gap(691) in PTS! Trying to recover …
2018-10-26T15:22:06 MCEBuddy.AppWrapper.CCExtractor → Found large gap(689) in PTS! Trying to recover …
2018-10-26T15:22:06 MCEBuddy.AppWrapper.CCExtractor → Found large gap(686) in PTS! Trying to recover …
Vous devriez vérifier votre source d’enregistrement (s’il s’agit d’un tuner, cela pourrait être un problème de firmware ou de pilote, ou alors un problème de transmission).
Handbrake ne peut pas compenser les erreurs de timestamp, donc il les ignore ; il semble que ffmpeg soit capable de les récupérer. Si vous ne pouvez pas corriger la source, votre meilleure option est d’utiliser ffmpeg.
J’ai testé avec un rip Blu-ray, un rip DVD, un enregistrement TV et un fichier téléchargé, et à chaque fois les 10 premières secondes (exactement 10 secondes) sont supprimées. Si j’encode tous ces mêmes fichiers avec HandBrake (Windows 10), ils s’encodent parfaitement. Je ne vois pas comment tous ces fichiers provenant de sources différentes peuvent avoir la même corruption pendant les mêmes 10 secondes ?
Quel que soit le programme utilisé pour créer votre fichier MKV (on dirait un rippeur web ou un encodeur web), il rencontre un problème lors de la création des timestamps. C’est ce que je peux voir à partir de votre fichier MKV
matroska,webm
MCEBuddy remux le MKV en TS pour faciliter le traitement, car tous les programmes sous-jacents ne prennent pas en charge d’autres formats. Il est possible que Handbrake ait des difficultés à lire le fichier TS par rapport au fichier MKV.
Si vous souhaitez éviter le remuxage de MKV à TS comme fichier intermédiaire, vous pouvez cocher l’option Skip remuxing dans votre page Conversion task → Expert settings :
Maintenant, le MKV original sera transmis à Handbrake. Même si cela peut fonctionner, cela ne résout pas la cause principale du problème.
J’ai essayé de sauter le remuxage des fichiers, ce qui a résolu tous mes problèmes ! plus de coupure des 10 premières secondes et le codage démarre immédiatement sans traitement ! Merci beaucoup !!
Je n’utilise aucun programme particulier pour créer les fichiers à encoder, c’est pourquoi je ne comprends pas le problème.
Les sources incluent
MKVToolnix pour les rips Blu-ray
Plex PVR pour les enregistrements TV
Téléchargement de Big Buck Bunny depuis http://bbb3d.renderfarming.net/download.html
DVDDecrypter pour les rips DVD
Donc une grande variété de logiciels alimentant mcebuddy ; je ne vois pas comment toutes les vidéos pourraient avoir la même corruption ou le même problème causant la coupure des 10 premières secondes, alors que les mêmes fichiers vidéo s’encodent parfaitement dans HandBrake (Windows 10) et j’ai maintenant testé StaxRip pour encoder en X265 sans problème non plus… il se passe quelque chose dans mcebuddy mais je ne le trouve pas !
Merci pour toute ton aide jusqu’à présent, je suis sûr que quelqu’un de bien plus malin que moi trouvera ce problème !
Au moins, en sautant le remuxage du fichier, les 10 secondes sont conservées !
Je me demande si vous avez trouvé une solution à ce problème. J’ai supprimé toutes les mentions -ss dans mcebuddy.conf et créé mon propre profil dans profiles.conf avec --start-at duration complètement supprimé.
Je ne fais aucune suppression de publicités, pourtant MCE retire toujours 3 secondes du début de TOUTES les vidéos, peu importe la source.
Quand j’encode ces mêmes fichiers avec une autre application (qui utilise handbrake), elle ne supprime pas les 3 premières secondes.
