Hauppauge Capture - HD PVR2 Problemas ocasionales con la conversión

¿Alguien tiene alguna solución para un problema ocasional en el que, al grabar con Hauppauge Capture como archivo TS y hacer cortes, ocasionalmente la grabación no se convierte? El TS en sí se reproduce bien, pero incluso si intento cortar manualmente con ffmpeg tengo problemas. El problema típico es que obtengo un archivo muy corto, por ejemplo, un programa de televisión que debería durar 40-45 minutos después de los cortes dura 20 minutos, o a veces solo unos segundos y solo muestra la carátula.

Cuando esto sucede, la única solución es volver a grabar. También ocurre ocasionalmente con MP4.

He probado OBS, pero no he tenido éxito en obtener algo que se vea decente. Típicamente hay un desenfoque horizontal extraño y la mayoría de las sugerencias giran en torno a los FPS; el dispositivo hace 60fps, así que probé 60, 30 (alguien dijo que use un múltiplo) y creo que 55, pero todos son prácticamente lo mismo.

Parece que el controlador de tu sintonizador/grabación está creando video corrupto durante un período de señal débil.

Prueba esto:

  1. Cambia el order de tu perfil para usar handbrake primero y luego ffmpeg
  2. En los ajustes expertos de la tarea de conversión habilita Skip remuxing

Esto hará que se omita ffmpeg, que parece tener problemas para procesar video corrupto, y en su lugar permitirá que handbrake intente manejarlo.

Lo intentaré en el próximo fallo. No creo haber guardado ninguno de los archivos fallidos anteriores.
Sé que ya hemos hablado de esto antes, y creo que había probado con HandBrake y también pudo haber fallado, pero habría sido hace unos meses.

The Brothers Celebrating The Allman Brothers Band 50th Anniversary (2024).ts-TestingAV1Conversions-2024-09-06T18-58-04.log (7.2 MB)

Han pasado unas semanas, pero finalmente me encontré con un ejemplo de un problema y he intentado revisar los registros, pero al menos en este caso no creo que el problema sea la conversión, sino el corte. Estoy usando archivos EDL que creo con cortes personalizados y el video resultante parece estar faltando 2 partes. La grabación es de una estación de PBS que está haciendo una recaudación de fondos, así que hay algunos cortes grandes, más grandes que los comerciales típicos. Hubo 5 cortes incluyendo el inicio y el final, así que 4 partes “buenas”, y por lo que puedo ver en el archivo resultante, faltan las últimas 2. El video debería durar alrededor de 1 hora y solo dura unos 38 minutos. ¿Alguna idea?

Veo 5 cortes identificados

2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:0.000 End:61.301 Action:0
2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:1212.502 End:1753.003 Action:0
2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:2920.505 End:3536.006 Action:0
2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:4776.211 End:5307.011 Action:0
2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:5414.414 End:6543.000 Action:0

Luego veo un fallo al intentar cortar el 3er segmento

2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → ¡Conversión fallida!
→ Proceso terminado con código -1094995529
→ Tamaño del archivo de salida de FFMpeg [KB] → 34.00

Después se detiene y no corta los segmentos restantes (no debería hacerlo, así que puede ser un error allí) pero parece que el archivo original puede estar dañado.

2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] Invalid timestamps stream=0, pts=9216112, dts=9216113, size=14338
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] Invalid timestamps stream=0, pts=9492388, dts=9492389, size=38037
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] PES packet size mismatch
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] Packet corrupt (stream = 0, dts = 594041354).
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] PES packet size mismatch
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] Packet corrupt (stream = 0, dts = 594041354).

¿Puedes subir el archivo TS original y tu archivo .EDL para que podamos replicar el problema y ver qué está pasando?

subido bajo jsam01

Gracias por la muestra. Parece que el video original tiene mucha corrupción de marcas de tiempo (probablemente causada por una señal OTA deficiente o un problema con el controlador del sintonizador de TV, que podría solucionarse probando una versión diferente del controlador del sintonizador de TV o mejorando la señal OTA).

Había un error en MCEBuddy que impedía detectar correctamente la corrupción, por lo que terminaba ignorando el video dañado. Hemos corregido eso en la última versión beta 2.6.5. Ahora detectará el video dañado y, si no puede hacer los cortes antes de la conversión, intentará corregir los problemas del video durante la conversión y luego intentará eliminar los comerciales después de la conversión. Cuando esto suceda, el proceso de conversión tardará más, pero debería poder recuperar el video y eliminar los comerciales con éxito.

Prueba la última versión beta y dime cómo te va.

Probé la versión 2.6.5 y parece funcionar; vi que cortó la segunda vez al final. Los cortes no son tan precisos como los del original: al menos, el inicio del vídeo con 2.65 incluyó un poco de lo que intentaba cortar.

Veré si puedo hacer algo con el dispositivo: no es un sintonizador, sino un grabador de vídeo técnicamente para juegos, pero tiene entradas HDMI y componente, así que estoy usando componente desde mi decodificador de cable. Veo que el controlador parece tener un número de versión más alto que el disponible en su sitio web, lo cual es un poco extraño, y el cable USB es bastante largo, así que podría intentar mover la caja y conseguir un cable más corto y nuevo.

Ejecuté el archivo de video que subiste junto con el archivo de cortes EDL a través de MCEBuddy 2.6.5 beta usando el perfil MP4 Unprocessed. Cortó exactamente según el archivo EDL que coincide con el archivo original. No noté ninguna diferencia en los puntos de corte (no más de aproximadamente 1 segundo de sincronización que ocurre porque los cortes siempre están en los límites de GOP, de lo contrario verás desgarro de video).

¿Qué perfil estás usando?