Mes fichiers sont sur un NAS (Unraid). Je ne fais pas de remux (pas de suppression de publicités nécessaire). Si c’était le cas, mcebuddy créerait un fichier .ts dans mon dossier temp local et travaillerait le fichier depuis ce dossier. Puisque je ne fais pas de remux — mcebuddy travaille directement le fichier depuis Unraid via le réseau, en maintenant constamment une connexion. Malheureusement, Unraid a tendance à ralentir/bloquer le groupe de disques pendant les écritures lourdes ou soutenues (comme lorsque le disque de cache est vidé). Pendant ces ralentissements sur le serveur, tous mes encodages partent en vrille. Au mieux, ils se mettent en pause un moment puis se terminent, ou échouent carrément. Au pire, ils ne signalent aucune erreur (marqués comme terminés) mais produisent un fichier tronqué (la moitié de l’émission, etc.).
Existe-t-il un moyen de copier la source depuis le NAS vers mcebuddytemp avant la conversion, et de faire travailler mcebuddy sur ce fichier ?
MCEBuddy copie TOUS les fichiers vers le dossier temporaire et ne travaille uniquement sur ce dossier temporaire (jamais sur l’original, sauf si vous lui avez demandé de ne pas le faire). Assurez-vous que vous n’avez pas coché ces options dans vos Paramètres d’exportation de la tâche de conversion :
Désolé, « Skip remuxing » est coché, « Skip copying » ne l’est pas.
édition :
J’ai testé « Skip copying original files » coché et décoché : dans les deux cas, la source reste sur le réseau local (aucune copie vers temp) et le fichier converti est créé dans temp. Bref, je ne suis pas sûr que cette option serve à quelque chose.
Essayez de les joindre ici et nous pourrons examiner cela. En supposant que vous ayez décoché les deux options, un avertissement s’affiche si vous essayez de les activer.
Les deux options Skip ne doivent pas être cochées :
Skip Copying Original File for Backup → False Skip Remuxing Original File to TS → True
Vous avez activé l’option Skip remuxing, donc elle ne créera pas de copie locale dans le dossier temp. Par défaut, MCEBuddy remux le fichier original en un fichier TS dans le dossier temp (ou le copie si le fichier original est déjà un TS), puis travaille sur ce dossier temp. Décoché cette option et il ne travaillera plus sur le fichier original après l’avoir remuxé dans le dossier temp.
Je lis peut-être mal le journal, mais mes paramètres n’ont pas les deux cases cochées. « Ignorer le remuxage » est coché, « Ignorer la copie » ne l’est pas.
Skip Copying Original File for Backup → False
Skip Remuxing Original File to TS → True
Je comprends comment fonctionne MCEBuddy lorsque le fichier est remuxé. Le problème est que le remuxage détruit parfois mes fichiers. Ce problème ne se produit pas quand je convertis directement depuis le MKV.
Le but ici, comme le dit le titre du sujet, est de copier le fichier dans le dossier temporaire local quand on NE remuxe PAS… Est-ce possible ?
Le remuxage est une forme de copie, il s’agit simplement de changer le format de conteneur pour quelque chose de plus malléable, sans modifier les propriétés ou le contenu vidéo. C’est redondant de copier si vous faites du remuxage, alors pourquoi vouloir limiter le remuxage ? Laissez simplement le remuxage activé et il créera une copie locale.
Le remux peut gâcher une conversion et n’est qu’une étape inutile si vous ne sautez pas les publicités.
Ça fonctionne bien la plupart du temps, mais il y a des problèmes. Parfois, il définit un mauvais framerate ou colorspace. À un moment, j’ai remarqué que certaines de mes conversions sautaient des images. J’ai regardé les métadonnées : le framerate était genre 29,6 au lieu du 29,97 normal. Ajouter --cfr ou désactiver le remux a réglé le souci, donc pas grave… Je l’avais raté dans mes tests, j’ai lancé un gros batch et dû refaire deux semaines de conversions. J’avais encore la source, donc encore une fois pas grave, mais très agaçant.
Le plus gros souci avec le remux, ce sont les sous-titres. Par défaut, le scodec est ignoré dans le remuxer ; la seule façon d’obtenir des subs est donc de déclencher ccextractor, qui fonctionne bien la plupart du temps, mais a aussi ses défauts. Il n’existe actuellement pas de bonne solution simple pour les sous-titres PGS, de plus en plus fréquents sur les Blu-ray, etc. Les PGS valent mieux les « passer » que les traiter, et le remux ne permet pas de les passer, tandis que ccextractor ne permet pas de les extraire : donc pas de PGS avec remux.
J’ai essayé de réparer ça hier en bidouillant le fichier de config et en changeant la valeur par défaut
CopyRemux0=-i -ss 0 -vcodec copy -acodec copy -map 0:a -map 0:v -f mpegts
en
CopyRemux0=-i -ss 0 -vcodec copy -acodec copy -scodec copy -map 0:a -map 0:v -map 0:s -f mpegts
Ça a un peu aidé, mais visiblement mpegts a ses propres limitations sur les types de subs qu’il accepte : environ 4 fichiers sur 12 n’ont transmis aucun sous-titre. J’ai donc testé
CopyRemux0=-i -ss 0 -vcodec copy -acodec copy -scodec copy -map 0:a -map 0:v -map 0:s -f matroska
Ce fut presque une réussite : sur 12 fichiers tests, 11 ont converti correctement avec tous les bons subs, etc. Le seul qui a échoué a levé une erreur d’espace colorimétrique d’entrée incorrect. Je suis sûr qu’en creusant un peu je trouverai les bons paramètres, mais à force, on se demande… pourquoi ?
Quand on ne saute pas les pubs, le seul vrai avantage du remux, c’est qu’il me fournit un fichier local à traiter. À part ça, il ne sert à rien. Il peut créer des erreurs bizarres (frame rate), il exige une appli tierce pour les subs (ccextractor) et n’accepte pas du tout les PGS. Globalement, je ne vois pas l’intérêt. Ma source est en mkv, ma sortie aussi : inutile de passer par un format intermédiaire (ts). Mon profil Handbrake passe les subs sans souci, ne foire jamais le framerate et ne se prend pas la tête avec le colorspace quand il travaille sur le mkv : alors pourquoi s’embêter ? Je suis sûr que ça a du sens dans plein de cas, mais dans le mien, je préfère copier la source et traiter directement le mkv local temp.
Merci pour votre retour. Il est logique qu’il doive toujours créer une copie locale sauf indication contraire. S’il remuxe, c’est une copie locale ; s’il saute le remuxage, il devrait créer une copie locale sauf si l’option « ignorer la copie » est sélectionnée.
Ce correctif sera présent dans la prochaine version bêta 2.5.2.
