He eliminado la versión beta anterior e instalado la última, pero mcebuddy sigue cortando los primeros 10 segundos de cada archivo que convierto.
He intentado activar “cut start” y configurarlo en 1 segundo, pero no hace ninguna diferencia; sigo perdiendo 10 segundos al inicio de cada vídeo.
Además, tengo el eliminador de anuncios en “none” y la detección y optimización de calidad de vídeo desactivadas, pero el registro está lleno de entradas de comskip y ffmpeg donde el archivo se remuxea y escanea, por lo que parece que mcebuddy ignora que estas opciones están desactivadas.
He adjuntado los registros y espero que alguien pueda echarles un vistazo…
Estoy usando mcebuddy para automatizar mis antiguos métodos de handbrake, así que solo quiero una codificación CC21 directa con un ancho máximo de 1280.
Tus registros muestran la duración correcta hasta justo antes de que HandBrake comience a codificar, y luego al final muestra 10 segundos menos. La línea de comandos parece estar bien. He notado que estás usando codificación por hardware (NVIDIA).
Mi única conjetura podría ser que el controlador gráfico está descartando los primeros 10 segundos debido a corrupción o no puede manejarlos.
Intenta desactivar la codificación por hardware y observa si el codificador por software tiene el mismo problema. También podrías intentar eliminar --start-at duration:0 de la línea handbrake-video en tu perfil, lo cual podría estar interferiendo con tu conversión debido a corrupción de marcas de tiempo.
Tienes razón, lo siento. Está utilizando el codificador de software x265. Veo esto en tus registros:
2018-10-24T06:49:35 MCEBuddy.AppWrapper.Handbrake → [06:49:35] sync: first pts audio 0x100 is 0
2018-10-24T06:49:35 MCEBuddy.AppWrapper.Handbrake → [06:49:35] sync: first pts video is 430
Posiblemente el vídeo esté corrompido. Algunas cosas que puedes probar:
Eliminar el --start-at duration:0 de la línea handbrake-video en tu perfil
Usar ffmpeg en lugar de handbrake (cambiar el orden en tu perfil)
Descargar la última versión nocturna de handbrake y reemplazarla en tu carpeta de handbrake (podría ser un problema en handbrake con el codificador x265 que no puede manejar la secuencia de vídeo)
Los vídeos no están corruptos, ya que mcebuddy hace esto en todos los vídeos. Estoy usando la misma versión de Handbrake que en mcebuddy y ésta no salta los primeros 10 segundos; preferiría seguir con Handbrake, pero estoy dispuesto a probar ffmpeg. Primero eliminaré ese parámetro y te informaré
Sugería que las marcas de tiempo en los fotogramas iniciales del video podrían estar corruptas, por lo que Handbrake se salta los primeros 10 segundos.
Handbrake y ffmpeg utilizan bibliotecas similares (de hecho, la próxima versión de Handbrake usará la misma biblioteca que ffmpeg). Puedes ajustar la configuración del perfil y los filtros que se utilizan para ffmpeg si estás familiarizado con ffmpeg.
También puedes jugar con el control deslizante de calidad en la Tarea de Conversión, intenta aumentarlo y eso también debería ayudar.
Puedes descargar la versión nocturna de la CLI de HandBrake desde su sitio web y reemplazar la que viene con MCEBuddy para ver si eso soluciona el problema.
He reemplazado la CLI con la última versión nocturna (HandBrakeCLI-20181023173755-177c1e3-master-win-x86_64)
¿Sigue cortando los primeros 10 segundos de cada vídeo?
He creado un archivo de prueba corto que se codifica completamente con la aplicación independiente de HandBrake y he adjuntado mi perfil y registros para este vídeo corto, ¿alguna otra idea?
Las marcas de tiempo del video original están corruptas al principio. Según tus registros, incluso Comskip está teniendo problemas con las marcas de tiempo al inicio de la grabación.
2018-10-26T15:22:06 MCEBuddy.AppWrapper.CCExtractor → Found large gap(684) in PTS! Trying to recover …
2018-10-26T15:22:06 MCEBuddy.AppWrapper.CCExtractor → 3% | 00:00
2018-10-26T15:22:06 MCEBuddy.AppWrapper.CCExtractor → Found large gap(691) in PTS! Trying to recover …
2018-10-26T15:22:06 MCEBuddy.AppWrapper.CCExtractor → Found large gap(689) in PTS! Trying to recover …
2018-10-26T15:22:06 MCEBuddy.AppWrapper.CCExtractor → Found large gap(686) in PTS! Trying to recover …
Quizás deberías revisar tu fuente de grabación (si es un sintonizador, podría ser un problema con el firmware o el controlador, o podría ser un problema con la transmisión misma).
Handbrake no puede compensar los errores de marca de tiempo, así que los está omitiendo; parece que ffmpeg puede recuperarlos, así que si no puedes solucionar la fuente, tu mejor opción es usar ffmpeg.
He probado con una copia de Blu-ray, copia de DVD, grabación de TV y archivo descargado, y siempre se eliminan los primeros 10 segundos (exactamente 10 segundos). Si codifico todos esos mismos archivos en HandBrake (Windows 10), se codifican perfectamente. No puedo ver cómo todos esos archivos de diferentes fuentes pueden tener la misma corrupción durante los mismos 10 segundos.
Sea cual sea el programa que estás usando para crear tu archivo MKV (parece un ripper web o algún codificador web) está teniendo problemas al crear las marcas de tiempo. Esto es lo que puedo ver de tu archivo MKV
matroska,webm
MCEBuddy remuxea el MKV a TS para facilitar el procesamiento, ya que no todos los programas subyacentes soportan otros formatos. Es posible que HandBrake esté teniendo problemas leyendo el archivo TS en lugar del archivo MKV.
Si quieres evitar el remuxeo de MKV a TS como archivo intermedio, puedes marcar la opción Skip remuxing en tu página Conversion task → Expert settings:
Ahora el MKV original se pasará a HandBrake; aunque puede funcionar, no resuelve la causa raíz del problema.
He probado a saltarme el remuxing de archivos y ¡ha resuelto todos mis problemas! ya no se cortan los primeros 10 segundos y ¡también empieza a codificar de inmediato sin procesamiento! ¡Muchas gracias!
No estoy usando ningún programa en particular para crear los archivos de codificación, por eso no entiendo el problema.
Así que una gran variedad de software alimentando a mcebuddy; no veo cómo todos los vídeos pueden tener la misma corrupción o problema que hace que se corten los primeros 10 segundos cuando todos esos mismos archivos de vídeo se codifican perfectamente en HandBrake (Windows 10) y también he probado Staxrip para codificar a X265 sin problemas… algo está pasando en mcebuddy, ¡pero no lo encuentro!
Gracias por toda tu ayuda hasta ahora, ¡estoy seguro de que alguien mucho más listo que yo encontrará este problema!
¡Al menos al saltarme el remuxing del archivo, se conservan los 10 segundos!
Me pregunto si alguna vez encontraste una solución a este problema. He eliminado todas las menciones de -ss en mcebuddy.conf y creado mi propio perfil en profiles.conf con --start-at duration completamente eliminado.
No estoy haciendo ninguna eliminación de comerciales, pero MCE sigue eliminando 3 segundos del principio de TODOS los videos, sin importar la fuente.
Cuando codifico estos mismos archivos con otra aplicación (que usa handbrake), no elimina los primeros 3 segundos.
