El formato OGV se reproduce correctamente en mi computadora, pero la transcodificación elimina fotogramas (¿duplicados?)

Hice un conjunto de screencasts usando recordmydesktop en ubuntu 12.10. La salida es un archivo ogv. Cuando veo el archivo ogv usando el reproductor de películas predeterminado (tótem), se ve bien: el audio y el video están sincronizados. Cuando se transcodifica (por mí o por YouTube), el audio y el video no están sincronizados. Parece que me salto una o dos diapositivas mientras narro.

Actualizar

Sospecho que el problema se caracteriza más correctamente por la eliminación de fotogramas duplicados durante la transcodificación. La conversión de video donde se mueve el mouse parece funcionar normalmente bien. Pero cuando solo estoy hablando durante una diapositiva, esos cuadros duplicados desaparecen.

Vi esto, pero no es exactamente mi situación (intentar pasar de ogv -> cualquier cosa) https://superuser.com/questions/436187/ffmpeg-convert-video-w-dropped-frames-out-of-sync

¡Los archivos AVI parecen traducirse correctamente! Supongo que esto será una gran pista para alguien. Todavía me gustaría rastrear el problema subyacente. Estoy probando la conversión de mis videos anteriores a AVI, pero esto toma un tiempo ya que tengo que verificar cada transición.

Ejemplos

Este es el archivo OGV original de gtk-recordmydesktop: http://dl.dropbox.com/u/64693533/sync_test/sync_test1.ogv

El video comienza con una diapositiva de 10 s, luego avanza a 3 diapositivas más de 5 s cada una. Cada vez que avanzo diapositivas toco el micrófono también (10s, 15s, 20s, 25s).

Aquí hay algunas conversiones que se realizaron (cada una muestra sus propios problemas de tiempo de video):

http://dl.dropbox.com/u/64693533/sync_test/sync_test1.mp4

  • esta muestra la primera diapositiva en el primer cuadro, pero avanza rápidamente más allá
  • esto se hizo usando el stock ffmpeg

http://dl.dropbox.com/u/64693533/sync_test/sync_test1.ffmpeg-static.mp4

  • este está bastante cerca - por alguna razón a los 13s decide avanzar aunque
  • esto se hizo usando la compilación estática de ffmpeg de hace unos días

Aquí está en youtube: puede ver que alrededor de los 13 s avanza temprano (desde la diapositiva 1 -> diapositiva 2):

Aquí hay una prueba de que el archivo OGV funciona correctamente:

traducción ffmpeg

Al usar ffmpeg o avconv, parece que obtengo resultados similares a los de YouTube (las transiciones parecen ocurrir temprano pero no necesariamente al mismo tiempo).

Aquí está el comando que uso (con una compilación estática reciente de ffmpeg) y la salida:

$ ~/ffmpeg/ffmpeg -i JSP.ogv JSP.mp4
ffmpeg versión N-50025-gb8bb661 Copyright (c) 2000-2013 los desarrolladores de FFmpeg
  construido el 17 de febrero de 2013 05:23:03 con gcc 4.6 (Debian 4.6.3-1)
  configuración: --prefix=/root/ffmpeg-static/64bit --extra-cflags='-I/root/ffmpeg-static/64bit/include -static' --extra-ldflags='-L/root/ffmpeg- static/64bit/lib -static' --extra-libs='-lxml2 -lexpat -lfreetype' --enable-static --disable-shared --disable-ffserver --disable-doc --enable-bzlib --enable -zlib --enable-postproc --enable-runtime-cpudetect --enable-libx264 --enable-gpl --enable-libtheora --enable-libvorbis --enable-libmp3lame --enable-gray --enable-libass - -habilitar-libfreetype --habilitar-libopenjpeg --habilitar-libspeex --habilitar-libvo-aacenc --habilitar-libvo-amrwbenc --habilitar-versión3 --habilitar-libvpx
  libavutil 52. 17.101 / 52. 17.101
  libavcodec 54. 91.103 / 54. 91.103
  formato libav 54. 63.100 / 54. 63.100
  dispositivo libav 54. 3.103 / 54. 3.103
  filtro libav 3. 38.100 / 3. 38.100
  libswscale 2. 2.100 / 2. 2.100
  libswresample 0. 17.102 / 0. 17.102
  libpostproc 52. 2.100 / 52. 2.100
[ogg @ 0x34d4640] No se implementan múltiples fisbone para la misma transmisión. Actualice su versión de FFmpeg a la más reciente de Git. Si el problema persiste, significa que su archivo tiene una función que no se ha implementado.
[ogg @ 0x34d4640] Falló el análisis del encabezado para la secuencia 0
[ogg @ 0x34d4640] Archivo roto, fotograma clave no marcado correctamente.
Entrada #0, ogg, de 'JSP.ogv':
  Duración: 00:12:49.67, inicio: 0.000000, tasa de bits: 224 kb/s
    Secuencia #0:0: Datos: ninguno
    Transmisión #0:1: Video: theora, yuv420p, 1600x880 [SAR 1:1 DAR 20:11], 15 fps, 15 tbr, 15 tbn, 15 tbc
    Metadatos:
      GRABAR EN MI ESCRITORIO: 0.3.8.1
    Transmisión #0:2: Audio: vorbis, 22050 Hz, mono, fltp, 89 kb/s
[libx264 @ 0x369c5e0] usando SAR=1/1
[libx264 @ 0x369c5e0] usando capacidades de CPU: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
[libx264 @ 0x369c5e0] perfil Alto, nivel 4.0
[libx264 @ 0x369c5e0] 264 - core 129 r2230 1cffe9f - Códec H.264/MPEG-4 AVC - Copyleft 2003-2012 - http://www.videolan.org/x264.html - opciones: cabac=1 ref=3 deblock =1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip= 1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 diezmar=1 entrelazado=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 pesop=2 keyint=250 keyint_min=15 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Salida #0, mp4, a 'JSP.mp4':
  Metadatos:
    codificador: Lavf54.63.100
    Secuencia #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 1600x880 [SAR 1:1 DAR 20:11], q=-1--1, 15360 tbn , 15 por confirmar
    Metadatos:
      GRABAR EN MI ESCRITORIO: 0.3.8.1
    Transmisión #0:1: Audio: aac ([64][0][0][0] / 0x0040), 22050 Hz, mono, s16, 128 kb/s
Mapeo de flujo:
  Flujo #0:1 -> #0:0 (teora -> libx264)
  Corriente #0:2 -> #0:1 (vorbis -> libvo_aacenc)
Presione [q] para detener, [?] para obtener ayuda
[ogg @ 0x34d4640] Archivo roto, fotograma no clave no marcado correctamente.
    Último mensaje repetido 2 veces
Archivo roto, sin fotograma clave no marcado correctamente. = 00: 00: 08.37 tasa de bits = 28.7 kbits / s dup = 66 drop = 0    
Archivo roto, fotograma clave no marcado correctamente.time=00:00:51.01 bitrate=125.3kbits/s dup=675 drop=0    
Archivo roto, fotograma clave no marcado correctamente.time=00:00:55.05 bitrate=140.2kbits/s dup=782 drop=0    
Archivo roto, fotograma clave no marcado correctamente.time=00:00:59.60 bitrate=140.5kbits/s dup=836 drop=0    
[ogg @ 0x34d4640] Archivo roto, fotograma clave no marcado correctamente.
Archivo roto, fotograma clave no marcado correctamente.time=00:01:08.00 bitrate=143.0kbits/s dup=900 drop=0    
Archivo roto, fotograma clave no marcado correctamente.time=00:01:11.86 bitrate=141.6kbits/s dup=910 drop=0

...repetido muchas veces...

Archivo roto, fotograma clave no marcado correctamente.time=00:12:47.62 bitrate=153.0kbits/s dup=9087 drop=0    
frame=11521 fps= 87 q=-1.0 Lsize= 14849kB time=00:12:49.48 bitrate= 158.1kbits/s dup=9087 drop=0    
video:2401kB audio:12024kB subtítulo:0 encabezados globales:0kB sobrecarga de muxing 2.938094%
[libx264 @ 0x369c5e0] marco I: 49 Promedio QP: 16.05 tamaño: 29658
[libx264 @ 0x369c5e0] marco P: 2912 QP promedio: 9.88 tamaño: 114
[libx264 @ 0x369c5e0] marco B: 8560 Promedio QP: 12.76 tamaño: 78
[libx264 @ 0x369c5e0] fotogramas B consecutivos: 0,9 % 0,1 % 0,2 % 98,9 %
[libx264 @ 0x369c5e0] MB I I16..4: 90,8 % 0,4 % 8,8 %
[libx264 @ 0x369c5e0] mb P I16..4: 0,0 % 0,0 % 0,0 % P16..4: 0,0 % 0,0 % 0,0 % 0,0 % 0,0 % omitir: 99,9 %
[libx264 @ 0x369c5e0] mb B I16..4: 0,0 % 0,0 % 0,0 % B16..8: 0,3 % 0,0 % 0,0 % directo: 0,0 % omitir: 99,7 % L0: 65,3 % L1: 34,6 % BI: 0,1 %
[libx264 @ 0x369c5e0] Transformación 8x8 intra: 0,5 % inter: 15,8 %
[libx264 @ 0x369c5e0] codificado y, uvDC, uvAC intra: 6,4 % 0,1 % 0,1 % inter: 0,0 % 0,0 % 0,0 %
[libx264 @ 0x369c5e0] i16 v, h, dc, p: 94 % 4 % 2 % 0 %
[libx264 @ 0x369c5e0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 22% 44% 1% 2% 2% 3% 1% 6%
[libx264 @ 0x369c5e0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 35% 17% 19% 4% 5% 5% 5% 5% 5%
[libx264 @ 0x369c5e0] i8c cc, h, v, p: 100 % 0 % 0 % 0 %
[libx264 @ 0x369c5e0] Marcos P ponderados: Y: 0,0 % UV: 0,0 %
[libx264 @ 0x369c5e0] ref P L0: 82,5 % 1,4 % 11,9 % 4,3 %
[libx264 @ 0x369c5e0] referencia B L0: 47,2 % 52,4 % 0,4 %
[libx264 @ 0x369c5e0] referencia B L1: 99,2 % 0,8 %
[libx264 @ 0x369c5e0] kb/s: 25,60

El video aún avanza temprano pero en diferentes momentos. Parece que gtk-recordmydesktop está generando un "archivo roto". Lo que es molesto es que el OGV funciona, por lo que parece que debería poder hacer que esto funcione con un conjunto de opciones.

Descubrí que puedo renderizar el video en kdenlive y parece estar funcionando allí. Todavía me gustaría saber qué está pasando. kdenlive hace un trabajo mucho mejor, pero aún así avanza temprano a veces.

Muestre su comando ffmpeg y la salida de la consola completa resultante.
Buena idea @LordNeckbeard. Agregué el comando y la salida. Veo un error/advertencia: max_analyze_duration alcanzado.
¿Sigue ocurriendo el problema si usa una compilación estática reciente de ffmpeg ? Esto descartará cualquier posible error que pueda encontrar y que ya se haya solucionado con una versión más nueva de ffmpeg. No hace falta instalar ni nada. Simplemente descargue, extraiga el archivo y luego ejecute el ffmpegbinario incluido.
¿Puede proporcionar un archivo de entrada de muestra con el que se pueda reproducir el problema?
Buena idea, prepararé uno pequeño y lo publicaré más tarde esta noche.
¿Sería aceptable una respuesta como 'usar un programa de grabación de pantalla diferente'? Parece que GTK-recordmydesktop está creando archivos rotos.
@evilsoup: lamentablemente no, ya he creado varias grabaciones antes de darme cuenta del problema. Además, puedo ver el OGV muy bien en Linux, por lo que parece que no está totalmente corrupto. Dicho esto, intentaré rastrear por qué está creando "archivos rotos".
A menos que me esté perdiendo algo, es probable que sea un error o la falta de compatibilidad con la función ogg en ffmpeg y/o un error en recordmydesktop (para el que ffmpeg no ha hecho un caso especial). Un informe de error puede ser la mejor opción aquí. Asegúrese de usar la última versión de ffmpeg que pueda, muestre su comando ffmpeg y complete la salida de la consola, proporcione sync_test1.ogve intente mostrar el problema usando solo codificadores nativos (no lib*como libx264) si es posible.
Gracias por la sugerencia, @LordNeckbeard. Enviaré un informe de error y veré adónde va. ¿Alguna idea de por qué AVI parece estar funcionando?

Respuestas (4)

¿Por qué convertir a OGV cuando su carga final será en youtube? Puede que me equivoque, pero puede convertir a códec de video x264 con AAC Audio incluso en Linux y cargarlo en youtube considerando que es lo que prefieren cargar de todos modos. ¿Ha intentado hacer un h264 y subirlo a YouTube en lugar del archivo OGV y ver si ese era el problema? Porque apostaría a que si eso lo resuelve, entonces sabrá que fue un problema con el OGV que se subió a YouTube, y si no lo resuelve, podría ser un problema de velocidad de fotogramas con la interpretación de YouTube o algo similar.

Ha habido muchos problemas con los archivos OGV subidos a YouTube en el pasado. No puedo imaginar que esté 100% arreglado incluso en este punto.

http://support.google.com/youtube/bin/answer.py?hl=es&answer=1722171

EDITAR: también noté que su metraje original está a 15 fps... esta podría ser la fuente del problema

EDICIÓN 2: Parecía haber leído mal un poco la pregunta... siendo que estás comenzando con un archivo de video que es OGV, y vi que vas a MP4... esto cambia un poco las cosas... .pero supongo que tiene algo que ver con el audio de 15 fps y 22050 Hz... Sé que la frecuencia de muestreo no tiene nada que ver con la sincronización del audio, pero por experiencia cuando se usan frecuencias de fotogramas y frecuencias de muestreo de audio no estándar, He tendido a ver la deriva... hacer que estos se sincronicen puede ser bastante difícil y no poder editarlos después de la grabación inicial con un editor de video barato...

Si bien el software ha mejorado con respecto al audio a la deriva, sigue siendo un problema común cuando se usan velocidades de fotogramas y frecuencias de muestreo poco comunes, ya que los puntos de sincronización de fotogramas clave no son estándar y podrían estar redondeando fotogramas clave, etc.

Verá donde dice "Archivo roto, fotograma clave no marcado correctamente". a eso se refiere...

mi consejo para usted sería que lo acerque lo más posible, lo lleve a un editor de video y deslice y corte el audio para que coincida con la forma en que lo desea. Desafortunadamente, a veces así es como se arregla...

Los transcodificadores basados ​​en software no siempre funcionan como deberían... por eso una configuración protools y/o una configuración ávida vendría con hardware para garantizar aún más las capacidades de sincronización y velocidades de cuadro constantes, etc...

Otra cosa que podría intentar es convertir el metraje a una velocidad de fotogramas estándar e intentar volver a mezclar el audio... ya que estoy bastante seguro de que el vídeo se está desviando... probablemente disminuyendo ligeramente la velocidad y luego acelerando hacia el final o viceversa.

EDITAR: Pude sincronizar el video con el original usando este comando ffmpeg... es posible que necesite la cláusula de tarifa, que es lo que sospechaba

ffmpeg -i sync_test1.ogv -strict experimental -pix_fmt yuv420p -r 15 -vcodec h264 -acodec aac sync_test1.mp4

El archivo original es video Theora y audio Vorbis en contenedor ogv. Amir T no está volviendo a codificar en este formato, que yo sepa, pero cuando intenta volver a codificar el original con ffmpeg o YouTube, se manifiesta el problema de sincronización.
El formato de entrada es ogv, que es lo que genera gtk-recordmydesktop. Estoy tratando de llegar a algo que no sea ogv (flv, etc.).
Lea mi respuesta actualizada... Creo que es un problema de FPS
Agregué un archivo fuente de ejemplo. El problema de sincronización es muy notable. Me parece que se elidieron un montón de marcos para varios formatos.
Prueba esto... ver nueva respuesta
Agregar -r 15es lo mismo que omitirlo porque ffmpeg heredará la velocidad de fotogramas de entrada de forma predeterminada, y los archivos de salida resultantes, con o sin ellos, -r 15son exactamente iguales con ffmpeg de git head (versión N-50285-gad89952). Si funciona para usted usando una versión anterior de ffmpeg, esto podría ser una regresión y debe informarse al rastreador de errores de FFmpeg .
@ChrisJamesChampeau, gracias por la sugerencia. Probé el comando que enumeró usando la compilación estática de ffmpeg. Obtuve la diapositiva 2 a los 12 y 3 a los 17: dl.dropbox.com/u/64693533/sync_test/sync_test1.cjc.mp4
Bueno, el FFmpeg que estoy usando es una versión MAC en comparación con su versión de Linus, no estoy seguro, pero supongo que debe haber un error con su FFMPEG. ¿Has probado a quitarlo y volver a instalar la última versión?
Sí, probé dos versiones, la predeterminada de ubuntu de apt-get y la compilación estática.
Estoy con @LordNeckbeard, debe informar esto como un error a FFMPEG

Luché con un problema similar en Ubuntu 12.04.3 LTS. Solucioné el problema usando la compilación ffmpeg estática que está disponible en http://johnvansickle.com/ffmpeg/

También probé una compilación estática y funcionó un poco mejor. Quizás el error se haya solucionado, en cuyo caso podría ser útil agregar el número de versión de la compilación estática a su respuesta.

Parece que este error todavía está en recordmydesktop, o al menos obtuve exactamente los mismos síntomas aquí con la versión de Debian testing ( 0.3.8.1+svn602-1.1).

Logré transcodificar este video casi correctamente, de la siguiente manera:

  1. Usa VLC.
  2. Pídale que transcodifique al "perfil" de WebM.
  3. Pídale que muestre el video a medida que se transcodifica.

El resultado aún tiene la sincronización correcta (¡sí!), pero aún tiene un problema: el video resultante anuncia que dura más de 4 horas, mientras que mi video solo dura 25 minutos. Por lo tanto, Peertube lo enumera como un video de 4 horas, aunque una vez que comienza a reproducirlo, se muestra la duración correcta de 25 minutos, por lo que el problema no es demasiado grave.

El punto 3 es importante, pero el punto 2 también lo es: tal vez otros perfiles también funcionen, pero al menos el perfil H264 me dio un video inutilizable (ya sea con mala sincronización ffmpego peor).

Intente simplemente cambiar el contenedor a avi en lugar de transcodificar, lo que parece funcionar mejor para youtube:

ffmpeg -i JSP.ogv -vcodec copy -acodec copy JSP.avi
Intenté esto, y la carga simplemente nunca termina de procesarse, igual que si cargara OGV. Dado que esta respuesta es anterior a que YouTube acepte OGV, debe ser ese cambio. Es molesto que ffmpeg todavía tenga este problema de conversión cuatro años después.
Mi ffpmeg es: 3.2.14-1~deb9u1 (apt-get install)
Probé todas las variaciones anteriores, con compilaciones estáticas (git-20191029), y aunque mejora un poco, el audio y el video no están sincronizados. Si intenta uno necesita un valor grande de --max_muxing_queue_size. Usé 40960.
El formato OGV se reproduce correctamente en mi computadora, pero la transcodificación elimina fotogramas (¿duplicados?)
RespuestasAquíPolítica de privacidad1y, 0v