Je n’ai même pas de théorie pour celui-là. La synchronisation audio de tous les enregistrements est décalée à partir du 11 octobre, selon les fichiers convertis.
J’ai mis à jour TabloRipper vers la version 2.3.4 le 1er novembre 2017.
Tous mes tests d’aujourd’hui utilisent le même fichier : America’s Test Kitchen - s17e11 - Big Easy Favorites - ch4.1.mp4, mais tous les fichiers utilisés avec MCEBuddy sont affectés. Ch4.1 est un enregistrement d’une station PBS qui ne contient aucune publicité.
Le concept initial était de faire couper 60 secondes au début du fichier et 2 minutes à la fin par MCEBuddy. Les coupes de début et fin de fichier ont été supprimées (réglées à 0 et décochées) pour ces tests.
Sur mon Tablo, le fichier passe bien sur une télévision.
J’utilise Tablo Ripper pour récupérer le fichier sur mon PC. Le fichier téléchargé fonctionne correctement.
La conversion MCEBuddy déplace le fichier, et c’est alors que le problème de synchronisation audio apparaît.
Je joins des images de ma configuration et deux fichiers journaux créés en mode Debug.
2017-11-02T13:24:51 MCEBuddy.AppWrapper.FFmpeg → [mp4 @ 00000000003bda20] Flux binaire AAC malformé détecté : utilisez le filtre de flux binaire audio ‘aac_adtstoasc’ pour le corriger (option ‘-bsf:a aac_adtstoasc’ avec ffmpeg)
2017-11-02T13:24:51 MCEBuddy.AppWrapper.FFmpeg → av_interleaved_write_frame(): Opération non permise
Le format de votre fichier a peut-être changé, ce qui déroute ffmpeg.
Nous avons une nouvelle version de ffmpeg qui sort avec la version BETA d’aujourd’hui, qui pourrait mieux gérer ces anomalies audio. Essayez la version BETA 2.4.8 de ce soir.
D’accord, compris, merci de l’avoir signalé. C’est réparé, ça devrait fonctionner maintenant. L’adresse IP AWS avait changé et nous devions resynchroniser les paramètres.
Je viens de mettre deux émissions d’une demi-heure sur le serveur FTP pour tester. L’une est désynchronisée, l’autre est le fichier original téléchargé depuis mon Tablo. C’est une émission de cuisine, il y a donc beaucoup de moments où les animateurs parlent. Ce fichier devrait être bon pour tester le problème de synchronisation audio.
Veuillez les supprimer ainsi que le répertoire lorsque vous avez terminé.
J’ai donc testé votre fichier exemple America's Test Kitchen - s17e11 - Big Easy Favorites - ch4.1 en utilisant la dernière version BETA 2.4.8 de MCEBuddy avec le profil MP4 Normal et Comskip pour la suppression des publicités, et cela a parfaitement fonctionné ! Aucun problème, le son est parfaitement synchronisé du début à la fin.
Essayez la dernière version BETA 2.4.8. Si vous rencontrez un problème, téléchargez la vidéo originale et le fichier journal de conversion.
Oui, je suis d’accord, avec le profil MP4 Normal, l’audio est synchronisé. Le problème vient donc du profil MP4 Unprocessed.
J’apprécie ton enthousiasme, mais America’s Test Kitchen est une émission PBS sans aucune publicité. J’utilise donc le profil MP4 Unprocessed sans suppression de pubs pour gagner du temps sur la conversion de toutes les émissions PBS.
Je viens de télécharger et d’installer la bêta 2.4.8 car la date du répertoire avait changé… il semble que les fichiers dans le zip n’aient pas changé, mais je l’ai installé quand même.
Avec le profil MP4 Unprocessed, en rognant 60 secondes au début et à la fin, il y a un décalage audio très perceptible.
Le profil MP4 Normal prend environ 40 minutes de plus sur une demi-heure d’émission. Sur un Intel I7 avec une tonne de mémoire, c’est un peu comme regarder la peinture sécher.
Oui, je suis d’accord, avec le profil MP4 Normal, l’audio est synchronisé. Le problème vient donc du profil MP4 Unprocessed.
Continue ton excellent travail ! Comment puis-je aider à optimiser le profil MP4 Unprocessed ?
Je vérifierai, aucun problème connu. Il faut comprendre pourquoi ffmpeg bloque s’il n’y a pas de suppression de publicités. Avec la suppression de publicités, il pourrait y avoir toute une série de raisons, mais sans cela, ça devrait être simple.
Je parviens donc à reproduire le problème : quelque chose dans cette vidéo fait planter ffmpeg lors de la copie de la vidéo et de l’audio. J’ai essayé avec d’anciennes versions de ffmpeg au cas où les plus récentes présenteraient un bug, mais c’est pareil. Il semble que la vidéo ne respecte pas le « standard » et cela perturbe ffmpeg. Je vais continuer à expérimenter pour identifier précisément le problème et trouver une solution. Merci pour l’échantillon.
En attendant, vérifie si tu as mis à jour les pilotes de ton tuner TV. Qu’est-ce qui, selon toi, a changé en octobre ?
