Conversión fallida

Desafortunadamente, no tengo tanta suerte, pero no estoy seguro de que sea por el motivo de los subtítulos.

Adjunto el registro. No estoy cualificado para tomar esta decisión, pero creo que tuvo problemas con lo siguiente:

2018-02-11T21:47:17 MCEBuddy.AppWrapper.FFmpeg → Please use -b:a or -b:v, -b is ambiguous

Aquí está el registro detallado:
NFL Football (2002) - 2018-02-04 - Philadelphia Eagles vs. New England Patriots.ts-Profile Test-2018-02-11T18-19-59.9641097-05-00.log.zip (4.3 MB)

¿Alguna idea?

gracias
BrianGGG

Completamente sin relación con los subtítulos.

Tienes un flujo de video grabado defectuoso

2018-02-11T20:52:13 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000021729d1a240] start time for stream 0 is not set in estimate_timings_from_pts
2018-02-11T20:52:13 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000021729d1a240] Could not find codec parameters for stream 0 (Video: h264 ([27][0][0][0] / 0x001B), none): unspecified size

Por esto ffmpeg se ahoga y falla.

2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Stream #0:0#0:0 (h264 (native) → h264 (libx264))
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Stream #0:1#0:1 (ac3 (native) → aac (libfdk_aac))
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Press [q] to stop, [?] for help
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Too many packets buffered for output stream 0:1.
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → [libfdk_aac @ 00000215284102e0] 2 frames left in the queue on closing
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Conversion failed!

También noté que has eliminado handbrake de tu orden de codificadores para que no intente recurrir a handbrake para codificarlo:

order=ffmpeg,mencoder

prueba añadiendo handbrake después de ffmpeg

La causa raíz, sin embargo, es un dispositivo de grabación defectuoso que está creando un archivo de video no conforme. Podría deberse a un firmware del dispositivo malo o controladores defectuosos.

Gracias por revisar esto. He hecho tantos cambios en controladores, perfiles, etc. desde que se grabó el video (para lograr la codificación por hardware) que no estoy seguro de poder resolver este misterio.

Lo cual está bien porque no he visto nada parecido en grabaciones posteriores…

Algunas preguntas aquí:

  1. ¿Hay algo útil sobre el error que mencioné en mi publicación original (“Please use -b:a or -b:v, -b is ambiguous”) o es una pista falsa?

  2. Desinstalé Handbrake porque era la única forma de asegurar que FFMPEG hiciera codificación por hardware en NVIDIA. Como tengo una tarjeta NVIDIA con CUDA y una tarjeta Intel con QuickSync… el orden actual estaba causando una codificación por software desde Handbrake.

Supongo que dejaré que Handbrake use al máximo mi CPU por un tiempo para convertir esto…

gracias
BrianGGG

Sin consecuencias, ffmpeg tiene varios tipos de estilos de entrada, estamos usando uno más antiguo y compatible

Entendido, en la próxima versión también corregiremos esto para que no reordene los codificadores si ambos soportan codificación por hardware

Listo, lo arreglé en la compilación beta 2.4.9 de hoy. Pruébalo.

Es muy posible que no haya entendido lo que haría este parche, pero no creo que haya tenido éxito. A continuación hay dos registros de ejemplo.

Dejé los perfiles predeterminados intactos cuando instalé la beta del 12-2, pensando que el algoritmo eventualmente elegiría FFMPEG, ya que el caso ideal es la codificación por hardware con mi NVIDIA.

Aparentemente no fue así, ya que los registros muestran que ambos trabajos usaron HandBrake… sin aceleración por hardware.

Por favor, házmelo saber si mis suposiciones sobre cómo debería haber funcionado eran incorrectas.

log.zip (230.2 KB)

gracias
BrianGGG

Este parche fue para preservar el orden seleccionado por el usuario del codificador si más de uno admite la codificación por hardware. En tu caso, tanto handbrake como ffmpeg admiten capacidades de codificación por hardware, por lo que se aseguró de no reordenar tu preferencia.

Tu perfil se veía así:

order=handbrake,ffmpeg,mencoder

Le pediste a MCEBuddy que usara handbrake primero y luego ffmpeg, y eso es exactamente lo que hizo.

Creo que lo que querías escribir era:

order=ffmpeg,handbrake,mencoder

Usar el codificador ffmpeg (hardware) primero y si falla, volver a handbrake.

Gracias, Goose. Esto resolvió el problema inmediato. Cambié el orden y he verificado que FFMPEG está siendo utilizado para la codificación por hardware en mi tarjeta NVIDIA (lo cual no ocurría en la 2.4.8).

Esto me lleva a algunas preguntas/comentarios:

Primero… creo que malinterpreté lo que se estaba haciendo. Preservar el orden me permite forzar ffmpeg, pero una solución aún más flexible sería que MCEBuddy llegara a una conclusión sobre qué camino tomar basándose en la configuración.

Sugiero que sería ideal si MCEBuddy intentara primero todas las rutas de codificación por hardware, seguidas por el software. El problema original en la 2.4.8 fue que MCEB intentó la codificación por hardware de Handbrake, falló, y luego retrocedió a Handbrake por software. Esto no era ideal para mi configuración.

Posiblemente una aspiración utópica, pero el caso ideal habr sido intentar la codificación por hardware de handbrake, fallar, luego retroceder a ffmpeg por hardware. Si eso fallaba, entonces pasar por la lista nuevamente con codificación por software.

También, ¿aceptarían una solicitud de función en el Profile.Conf actual? No es ideal que tenga que cambiar el orden de cada perfil que usa handbrake para cada beta y versión que instalo.

Una posible alternativa aquí sería tener el concepto de un “archivo de Perfil de Usuario” en un directorio de Usuario (en lugar del directorio de Programa). Este archivo permanecería intacto durante las actualizaciones, y podría servir para dos propósitos:

  1. Se podrían crear y mantener Perfiles de Usuario personalizados y se mostrarían en el menú junto con los perfiles del sistema.

  2. Se podrían sobrescribir valores en perfiles existentes. Esto permitiría que los elementos cambiables (como parámetros en ffmpeg) se actualicen con nuevas versiones mientras se mantienen las preferencias del usuario como el orden del conversor.

Solo algunas ideas, tengo la ventaja de no tener concepto de complejidad.

Saludos,
BrianGGG

Sí, eso está en nuestra lista de próximas tareas; es un poco más complejo, así que tomará algo de tiempo resolverlo.

Ya está disponible: Ajustes del Sistema

image

Gracias por las respuestas.

Es genial saber que la priorización de “Hardware primero” está en la hoja de ruta.

Con respecto a la discusión anterior sobre el Perfil personalizado, voy a enviar una solicitud de función porque creo que el perfil de usuario es un archivo “en lugar de” y no “además de”. Mi sugerencia es que si tienes 10 perfiles en la configuración estándar de Perfil y dos en el perfil de usuario, entonces MCEbuddy mostraría los 12, no solo los dos del perfil de usuario. Creo que eso sería mucho más valioso y flexible…

Gracias
BrianGGG

Abre una solicitud de función, esta es complicada por una sola razón. A veces la gente no cambia el nombre del perfil, así que ahora tienes dos perfiles, uno del maestro y otro del personalizado, tendremos que averiguar cuál tiene prioridad.

Abriré una solicitud separada. Mi opinión sobre el problema duplicado es que se agrega un prefijo “USER_” a cualquier cosa en el archivo de usuario. De esa manera, “MP4 Normal” en el archivo de perfil oficial será diferente de “USER MP4 Normal” en el archivo de usuario.