Vous avez déclaré par le passé ne pas disposer de matériel AMD pour tester, donc je teste de mon côté. J’ai renomplacé les binaires ffmpeg/ffprobe par ceux des nightly de Zeranoe, et créé une copie du profil MKV Normal qui utilise h264_vce comme codec vidéo au lieu de x264.
Ma source est des émissions TV de 30 min provenant de HDHomeRun Prime, qui se convertissent parfaitement en logiciel. Je n’ai modifié aucun autre paramètre de la copie du profil MKV Normal si ce n’est l’encodeur ffmpeg. Tous les autres réglages restent identiques.
Premier résultat flagrant : la vidéo ne se lit pas :
Le fichier est correctement identifié (codec VCE, durée, etc.) dans MediaInfo, mais est corrompu/cassé dans les lecteurs que j’utilise. VLC refuse de lire la vidéo, avec l’avertissement « Cannot get block EOF? ». Plex quitte souvent le fichier immédiatement, puis le lit plus tard mais ne peut pas reprendre. Cela semble lié à un timestamp indiquant la durée du fichier, bien que MediaInfo le détermine sans problème.
Deuxième gros changement : le fichier journal est énorme :
Le journal fait 22 Mo contre les fichiers de moins de 2 Mo habituels en encodage logiciel. J’ai téléversé une copie du journal ici pour inspection. Il semble principalement contenir une multitude d’opérations de crop qui n’ont pas lieu en logiciel.
Bref, je ferai ce que je peux pour aider, mais je suis bloqué. J’aimerais rendre cela compatible avec VLC/Plex et peut-être réduire ces journaux gigantesques ?
Je vous suggère de lire le fichier sur un autre ordinateur avec un lecteur simple comme Windows Media Player afin d’écarter tout problème de codecs de lecture.
Si cela ne fonctionne toujours pas, il s’agit d’un problème ffmpeg ; vous pouvez le signaler là-bas pour que les développeurs l’analysent.
J’essaierais aussi des options plus simples dans le profil et dans MCEBuddy, puis je verrais où cela coince avant de le reporter à ffmpeg.
Cela désactive essentiellement toutes les options avancées, y compris le recadrage, et indique à MCEBuddy de ne modifier aucun paramètre vidéo car ils sont optimisés pour l’encodage matériel.
Si cela fonctionne, vous pouvez réactiver les options une par une pour voir laquelle pose problème (activer le recadrage, puis supprimer l’option d’encodage matériel, puis réintégrer les x264opts, etc.).
Le code que vous m’avez donné a fonctionné, a produit un fichier très rapidement qui pouvait être lu même dans VLC sans problème, et a produit un journal bref (700K).
J’ai donc changé le type de conteneur en VLC. J’ai obtenu un fichier qui pouvait être lu dans Windows Media Player, mais pas dans VLC. Je vais faire plus de tests dans les jours à venir, mais il semble au départ que cette méthode fonctionne mais est plus compatible avec les fichiers MP4 qu’avec les fichiers MKV.
Les deux profils ont généré des vidéos lisibles, mais le second a produit de nombreux avertissements dans VLC concernant la synchronisation audio et des millisecondes de données perdues. La seconde vidéo ne semblait pas décalée pour le spectateur (bien que j’ai parcouru la timeline et ne l’ai pas regardée en entier), mais la première s’est lue avec beaucoup moins d’erreurs dans les logs du lecteur et semble clairement préférable.
J’ai pris le premier profil, augmenté le débit à 1400 et activé AutoDeinterlace (j’enregistre la télé pour la diffuser sur des appareils sans décodeur matériel) afin de l’utiliser quotidiennement pour l’instant. Toutefois, si vous souhaitez d’autres tests, faites-le-moi savoir. J’utilise principalement des épisodes de 15 minutes de Cartoon Network pour tester ; donc, même si je n’utiliserais pas HEVC régulièrement, je n’aurais aucun problème à lancer des tests pour vous. Il serait agréable qu’AMD soit ajouté à la case « Encodage matériel » dans une prochaine bêta plutôt que de devoir créer un profil personnalisé.
Quand j’ai commencé ce fil, j’utilisais un doublon de « MKV Normal » avec le codec changé. C’est ce qui créait les fichiers corrompus avec des erreurs EOF.
Je pense aussi avoir eu des fichiers corrompus en les convertissant avec l’encodage matériel AMD dans un programme séparé (A’s, StaxRip, etc.) puis en laissant MCEBuddy les traiter sans conversion pour comskip/renommer. Ça produisait des erreurs EOF similaires. J’avais brièvement une solution où MCEBuddy traitait chaque fichier deux fois : une première fois pour prendre un .ts non compressé et lancer comskip dessus, puis le déposer dans un dossier surveillé par A’s pour la conversion, puis déplacer/renommer le fichier converti ; mais je voulais tout simplifier dans un seul programme et j’ai abandonné cette approche complexe. Depuis qu’ffmpeg a finalisé la 4.0, j’essaie de le faire fonctionner avec MCEBuddy.
Apparemment, mon problème ici était un souci de profil ? Mais je ne suis pas un utilisateur avancé de la CLI ffmpeg et je ne savais pas comment créer un profil fonctionnel. Remplacer la copie fournie de ffmpeg par la 4.0 était facile, mais je ne sais pas ce que font la plupart des options x264 sur la ligne ffmpeg-video ; même supprimer l’argument d’options x264 ne produisait pas de fichiers stables. Ton profil, lui, fonctionne.
Si vous possédez une carte AMD, essayez la version BÊTA 2.5.1 d’aujourd’hui. Elle prend désormais en charge la détection automatique du matériel NVidia (CUDA/NvEnc), Intel (QuickSync) et AMD (AMF/VCE) et active l’accélération matérielle automatiquement.