Je fonctionnais parfaitement avec MCEBuddy et comskip pour supprimer les publicités des émissions d’une demi-heure. Puis j’ai ajouté une émission d’une heure et j’ai commencé à obtenir des échecs pour cette nouvelle émission. MCEBuddy affichait « comskip a échoué » et annulait la conversion.
Si je faisais glisser manuellement le fichier .ts sur comskip.exe, cela fonctionnait parfaitement et se terminait sans erreur.
Il s’est avéré que MCEBuddy tuait le processus comskip après qu’il mettait trop de temps à se terminer. Je l’ai observé manuellement et le processus de détection des publicités SEMBLAIT se figer à 10 secondes de la fin. Pendant ce temps, le journal comskip ne cessait de grossir. MCEBuddy finissait par tuer le processus — je suppose qu’il y a un délai d’attente fixe — et signalait un échec.
Il s’est avéré que le journal pour cette émission particulière était ÉNORME. Le paramètre par défaut de comskip pour « verbose » est 5, et il écrivait une TONNE de données dans le fichier journal. Même si le dossier de travail était sur un SSD avec un processeur XEON rapide, une fois le fichier journal très volumineux, chaque nouvelle ligne prenait très longtemps à s’écrire. Je pense que la routine de journalisation de comskip doit être optimisée.
Bref, j’ai changé verbose à 0 et cela a fonctionné parfaitement et très rapidement. MCEBuddy a cessé de le tuer et la conversion s’est terminée.
Je pense que MCEBuddy devrait soit prolonger le délai d’attente du processus comskip, soit en faire une option de configuration. Mais modifier les paramètres de comskip pour définir verbose=0 a fait l’affaire, même si cela signifie ne plus avoir de journal détaillé de comskip.
