Ustedes mencionaron en el pasado que no tienen hardware AMD para probar, así que estoy probando por mi cuenta. Renombré/reemplacé ffmpeg/ffprobe con versiones de la compilación nocturna de Zeranoe, y creé una copia del perfil MKV Normal que usa h264_vce como códec de video en lugar de x264.
Mi fuente son programas de televisión de 30 minutos de HDHomeRun Prime, que se convierten bien en software. No hice ningún otro cambio en la copia del perfil MKV Normal que especificar un codificador diferente para ffmpeg. Todos los demás ajustes siguen siendo los mismos.
El primer y más obvio resultado es que el archivo de video no se reproduce:
El archivo es correctamente identificado (códec VCE, duración, etc.) en MediaInfo, pero está dañado/roto en los reproductores que uso. VLC se niega a reproducir el video, con la advertencia «Cannot get block EOF?». Plex a menudo cierra el archivo inmediatamente, luego lo reproduce más tarde pero no puede reanudarlo. Parece ser algo relacionado con una marca de tiempo que le dice al reproductor la duración del archivo, aunque MediaInfo parece calcularlo bien.
El segundo gran cambio es que el archivo de registro es enorme:
El registro pesa 22 MB en comparación con los archivos habituales de menos de 2 MB generados en codificaciones por software. He subido una copia del registro aquí para inspección. Parece estar compuesto principalmente por muchas operaciones de recorte que no ocurren en software.
En fin, haré lo que pueda para ayudar, pero estoy atascado. ¿Cómo podría hacer que esto sea compatible con VLC/Plex y quizá reducir los registros gigantes?
Sugiero intentar reproducirlo en una computadora diferente con un reproductor básico como Windows Media Player para descartar problemas con tus códecs de reproducción.
Si eso no funciona, es un problema de ffmpeg, puede que quieras reportarlo allí para que los desarrolladores lo analicen.
También intentaría usar opciones más simples en el perfil y mcebuddy y luego ver dónde falla antes de reportarlo a ffmpeg.
Esto básicamente desactiva todas las opciones avanzadas incluyendo el recorte y le dice a MCEBuddy que no ajuste ninguna configuración de video ya que están optimizadas para codificación por hardware.
Si esto funciona, entonces puedes agregar las opciones de vuelta una por una para ver cuálas rompen (como habilitar el recorte, luego quitar la opción de codificación por hardware, luego agregar de vuelta los x264opts etc)
El código que me diste funcionó, produjo un archivo muy rápidamente que se podía reproducir incluso en VLC sin problemas, y generó un registro breve (700K).
Así que cambié el tipo de contenedor a VLC. Obtuve un archivo que se podía reproducir en Windows Media Player, pero no en VLC. Haré más pruebas en los próximos días, pero al parecer este método funciona pero es más compatible con archivos MP4 que con MKV.
Ambos perfiles generaron vídeos que se reproducen, pero el segundo produjo muchos mensajes de advertencia en VLC sobre sincronización de audio y pérdida de milisegundos de datos. El segundo vídeo no parecía estar desincronizado para el espectador (aunque me salté por la línea de tiempo y no lo vi completo), pero el primer vídeo se reprodujo con mucho menos drama en los registros del reproductor y definitivamente parece preferible.
He tomado el primer perfil, aumentado la tasa de bits a 1400 y activado AutoDeinterlace (estoy grabando TV para transmitir en dispositivos sin desentrelazador de hardware) para usarlo como configuración diaria en el futuro inmediato. Sin embargo, si quieren que haga más pruebas, avísenme. Estoy usando episodios de 15 minutos de Cartoon Network para las pruebas principalmente, y aunque no usaría HEVC regularmente, no me importaría hacer algunas pruebas para ustedes. Sería bueno que AMD se añadiera al checkbox de Codificación por Hardware en una futura beta en lugar de tener que crear un perfil personalizado para ello.
Cuando abrí este hilo, estaba usando un duplicado de «MKV Normal» con el códec cambiado. Eso era lo que generaba los archivos corruptos con errores EOF.
Creo que también he tenido archivos corrompidos al convertirlos con codificación por hardware AMD en un programa aparte (A’s, StaxRip, etc.) y luego hacer que MCEBuddy los procese sin tocarlos para comskip/renombrar. Produjo errores EOF similares. Durante un tiempo tuve una solución donde MCEBuddy ejecutaba dos pasos por archivo: primero tomaba un .ts sin comprimir y le hacía comskip, luego lo dejaba en una carpeta vigilada por A’s para convertir, y después movía/renombraba el archivo convertido; pero quería simplificarlo a un solo programa y abandoné ese enfoque complejo. Desde que ffmpeg finalizó la 4.0, he estado intentando que funcione con MCEBuddy.
Al parecer, mi problema aquí era un perfil incorrecto, ¿pero no soy un usuario avanzado de la CLI de ffmpeg y no sabía cómo crear un perfil que funcionara. Cambiar la copia de ffmpeg proporcionada por la 4.0 fue fácil, pero no sé qué hacen muchas de las opciones x264 en la línea ffmpeg-video; aunque eliminara el argumento de opciones x264 de la línea, los archivos no se volvían estables. Tu perfil sí lo consigue.
Si tienes una tarjeta AMD, prueba la versión BETA 2.5.1 de hoy, ahora admite la detección automática de hardware NVidia (CUDA/NvEnc), Intel (QuickSync) y AMD (AMF/VCE) y activa la aceleración por hardware automáticamente.