Nota: publiqué la misma pregunta en stackoverflow poco tiempo antes, cuando todavía no he encontrado esta comunidad. Vuelvo a publicar esto ya que la pregunta es más adecuada para esta comunidad.

1. Lo que probé

Tengo algunos archivos .MTS (formato AVCHD) grabados con mi cámara AVCHD . Su especificación es como se muestra a continuación:

$ ffprobe 140612_Canon-00000.MTS 
ffprobe version 2.2.1 Copyright (c) 2007-2014 the FFmpeg developers
(snip)
Input #0, mpegts, from '140612_Canon-00000.MTS':
  Duration: 00:48:58.40, start: 0.800300, bitrate: 5563 kb/s
  Program 1 
    Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), 
      yuv420p, 1440x1080 [SAR 4:3 DAR 16:9], 
      29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 
      stereo, fltp, 256 kb/s

Presta atención a la parte de framerate / timebase: 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc

Ahora me gustaría convertir este archivo a archivo .mp4, sin volver a codificar la transmisión de video H264 , por otro lado, con la transcodificación de su transmisión de audio a AAC . Así que probé el siguiente comando:

ffmpeg -i 140612_Canon-00000.MTS -t 60 -y -vcodec copy -acodec libfaac -ab 128k 140612_Canon-00001.MTS.mp4

2. Resultado

y la especificación del archivo de salida es como se muestra a continuación:

$ ffprobe 140612_Canon-00000.MTS.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '140612_Canon-00000.MTS.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf55.33.100

  Duration: 00:01:00.04, start: 0.021333, bitrate: 4590 kb/s

    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 
        1440x1080 [SAR 4:3 DAR 16:9], 4448 kb/s, 
        59.94 fps, 59.94 tbr, 90k tbn, 59.94 tbc (default)
    Metadata:
      handler_name    : VideoHandler

    Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 
        48000 Hz, stereo, fltp, 128 kb/s (default)
    Metadata:
      handler_name    : SoundHandler

Mire la parte de framerate / timebase: 59.94 fps, 59.94 tbr, 90k tbn, 59.94 tbc . Aunque ffmpeg acaba de copiar la transmisión de video, la velocidad de fotogramas y la base de tiempo se ha cambiado a dos veces .

Entonces, cuando abro y reproduzco el archivo de salida con QuickTime Player o VLC Player, el audio no tiene ningún problema, sin embargo, la transmisión de video no se reproduce correctamente. El video se reproduce con su marco hacia adelante y hacia atrás temblando repetidamente.

3. Pregunta

1. ¿Cómo puedo convertir el archivo .MTS (AVCHD) a .mp4 mediante ffmpeg sin volver a codificar correctamente la transmisión de video H264 ?
2. ¿Cómo puedo mantener los valores de framerate / timebase originales (fps / tbr / tbn / tbc) cuando convierto el contenedor con ffmpegsu -vcodec copyinterruptor?
3. ¿Cómo puedo establecer los valores de framerate / timebase (fps / tbr / tbn / tbc) mediante las opciones de línea de comando de ffmpeg sin volver a codificar una secuencia de video.

¿Algunas ideas?

4. Agregar -r 29.97opción

El profesor Sparkles me dio un consejo para agregar -r 29.97. Intenté eso:

ffmpeg -i 140612_Canon-00001.MTS -t 60 -r 29.97 -y -vcodec copy -acodec libfaac -ab 128k 140612_Canon-00001.MTS.mp4

Sin embargo, el archivo de salida todavía tiene una tasa de fotogramas / base de tiempo incorrecta:

Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 
1440x1080 [SAR 4:3 DAR 16:9], 4448 kb/s, 
59.94 fps, 59.94 tbr, 11988 tbn, 59.94 tbc (default)

5. Remux usando MP4Box

Intenté demux y remux usando MP4Box, de acuerdo con los consejos del profesor Sparkles.

brew install mp4box

ffmpeg -i 140612_Canon-00000.MTS -t 60 -y \
  -vcodec copy -an 140612_Canon-00000.MTS.h264

ffmpeg -i 140612_Canon-00000.MTS -t 60 -y \
  -vn -acodec libfaac -ab 128k 140612_Canon-00000.MTS.aac

mp4box -add 140612_Canon-00000.MTS.h264:fps=29.97 \
  -add 140612_Canon-00000.MTS.aac \
  -new 140612_Canon-00000.MTS.mp4

y la salida fue:

$ ffprobe 140612_Canon-00000.MTS.mp4

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '140612_Canon-00000.MTS.mp4':
(snip)
  Duration: 00:02:00.22, start: 0.000000, bitrate: 2293 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), 
          yuv420p, 1440x1080 [SAR 4:3 DAR 16:9], 2228 kb/s, 
          29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default)
    Metadata:
      creation_time   : 2014-07-14 00:38:23
      handler_name    : 140612_Canon-00000.MTS.h264:fps=29.97
       - Imported with GPAC 0.5.0-rev4065

    Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, 
          stereo, fltp, 125 kb/s (default)

Parece un poco un paso adelante. Mire la parte de framerate / timebase: 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc . Esos coinciden con la secuencia original, exceptotbn (valor de base de tiempo del contenedor).

Sin embargo, cuando reproduzco el archivo de salida con Quicktime Player o VLC, el video se reproduce a media velocidad .

Aunque el archivo original tiene 90k tbn(90000 tics por segundo) y el nuevo archivo de salida de MP4Box tiene 30k tbnsolo un tercio del valor original, el archivo de salida se reproduce a la mitad de velocidad.

No sé por qué. Pero creo que el resto es cómo puedo ajustar el tbnvalor.

5-b. Informe de MediaInfo sobre el archivo de salida

También probé la herramienta MediaInfo en el archivo de salida generado por 5. Remux usando MP4Box . La salida está aquí: https://gist.github.com/kaorukobo/c5ab9eaa413dff6cd26a

6. Probar avconv

Volodya informó que avconvfuncionó bien. También preparé un pequeño archivo de película de muestra (Canon-00006.MTS) grabado con la misma cámara. Ok, intentemos:

brew install avconv
avconv -i Canon-00006.MTS -c:a copy -c:v copy -y Canon-00006.MTS.mp4
ffprobe Canon-00006.MTS.mp4

La información de ffprobe del archivo de salida está aquí: https://gist.github.com/kaorukobo/5b53244ade2632ff1211 y su información de velocidad de fotogramas / base de tiempo es la siguiente: 59.94 fps, 59.94 tbr, 90k tbn, 59.94 tbc

El archivo de salida se reprodujo bien con VLC Player como informó Volodya. Sin embargo, al abrirlo con Quicktime Player X, el video se reprodujo a la velocidad normal pero con su marco hacia atrás temblando repetidamente.

7. ¿Por qué funciona la aplicación "Free AVCHD to MOV"?

Como mencioné en mi comentario anterior , la función "reenviar a MOV" de la aplicación Free AVCHD to MOV funcionó bien, aunque no hace MP4 sino MOV.

El software llama internamente a su propio programa ffmpeg (o avconv), y vi qué opciones se le pasan. Es como se muestra a continuación:

/Applications/Free AVCHD to Mov.app/Contents/Resources/bin/com.geranium-soft.convert \
  -i /path/to/140710_Canon-00003.MTS \
  -map 0:0 -map 0:1 -c:a libfaac -vol 256 -b:a 128k -c:v copy \
  -sn -movflags faststart -threads 0 -pix_fmt yuv420p -y \
  /path/to/140710_Canon-00003.mov

Traté de pasar las mismas opciones (Extracto. Establecí el tipo de contenedor de salida en MOV y eliminé incluso el -t 60interruptor) al programa ffmpeg y la conversión. Pero el resultado fue el mismo que se informó hasta ahora .

De todos modos, esa gran aplicación resolvió mi problema en "¿Cómo puedo convertir el archivo .MTS (AVCHD) a .mp4 sin volver a codificar la transmisión de video H264?", Excepto en "a .mp4" y "por ffmpeg". Pero todavía estoy interesado en por qué esa aplicación funciona bien, pero ffmpeg no.

Al ver que en el texto de su pregunta ha comenzado a discutir otras utilidades, asumiré que no está interesado en seguir con ffmpeg, sino más bien en hacer el trabajo.

En mi experiencia con libav y MTS, no he tenido problemas con la velocidad de fotogramas, los archivos se remezclaron perfectamente.

Acabo de intentar lo siguiente con uno de mis archivos:

avconv -i 00174.MTS -c:a copy -c:v copy 00174.mp4

El archivo MP4 resultante se reprodujo correctamente con VLC.

Mi archivo es MTS progresivo, no tengo ningún entrelazado, pero si es necesario, puedo verificarlo más.

Informe sobre la prueba de archivo

El iniciador del tema fue capaz de proporcionar un archivo, que se remueve de MTS a MP4 y no se reproduce en la máquina de esa persona con QuickTime Player (versión desconocida). Sin embargo, sí jugó con el jugador VLC de ese individuo.

No tengo una computadora Mac OS, pero la he probado con Ubuntu. Lo he jugado en Ubuntu en VLC (2.0.8) y GNOME Videos (solía llamarse Totem) (3.8.2); Ambos juegan perfectamente.

Luego le pregunté a un amigo mío, que está en una Mac para jugarlo. Está en Mavericks (10.9.4), y jugó bien con QuickTime Player 10.3 (727.4).

En este momento parece ser un problema con el reproductor en particular o un problema con los ajustes de configuración en la computadora. Y probablemente sea mejor intentar actualizar a la versión más reciente de QTP, posiblemente eliminando primero la versión actual y borrando por completo la configuración anterior.

Otra posibilidad

Cuando tuve una máquina vieja, tuve algunos archivos de alta tasa de bits que se reproducen incorrectamente en algunos reproductores, y era específico del contenedor. Por ejemplo, VLC se negaría a reproducir el archivo MTS, mostraría un cuadro y luego mostraría el siguiente solo en un segundo y medio. Los videos de GNOME lo jugaron bien. Pero cuando lo remux a MKV, ambos jugadores lo jugaron razonablemente bien. Esto quizás sea una cuestión de algo similar. Un jugador puede leer un contenedor particular (MP4 en este caso) de una manera que requiera suficiente tiempo de CPU, para que comience a ahogarse. El efecto de sacudida se puede atribuir a cualquier subproceso que requiera el acabado de la CPU y al jugador que descarta todos los fotogramas que se estaban quedando atrás muy rápidamente, después de eso el subproceso malo vuelve a activarse y el ciclo continúa.

En esta posibilidad, la mejor opción es intentar actualizar el software. Con los procesadores multinúcleo actuales, sería difícil probar la necesidad de actualizar el hardware sin obtenerlo realmente, pero tal vez sea posible observar la carga de la CPU durante el uso de QuickTime Player y compararlo con VLC. Si ve 100% para cualquier núcleo con QTP, eso puede ser indicativo de esto.

Según este error ffmpeg

Los paquetes H.264 entrelazados se dividen y causan STTS MP4

Cuando se remux un mpeg-ts que contiene H.264 entrelazado en mp4, ambos campos de cada cuadro de video se dividen en paquetes separados. Software como Mediainfo utiliza el STTS para determinar la velocidad de fotogramas. Se mostrará como 50 fps en lugar de 25 fps

El desajuste de la velocidad de fotogramas que se informa aquí parece ser el resultado de ffmpeg muxing entrelazado flujos MP4 de acuerdo con la especificación, según lo cual, cada campo se separa en un paquete. Y por lo tanto

"El software que utiliza el recuento de muestras en el archivo MP4 para determinar la velocidad de cuadros es simplemente incorrecto". Comentario 7

Esto no se parcheará ya que la combinación de pares de campos en una unidad de acceso viola la especificación MPEG-4 y, por lo tanto, también los codificadores que hacen lo mismo.

Tenga en cuenta que la salida de multiplexado, tales como la de abajo, juega muy bien para mí en Potplayer y VLC.

    ffmpeg version N-76741-g8eadabf Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 5.2.0 (GCC)

Input #0, mpegts, from '00007.MTS':
  Duration: 00:00:07.01, start: 1.033367, bitrate: 15935 kb/s
  Program 1 
    Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 448 kb/s
    Stream #0:2[0x1200]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090), 1920x1080
[mp4 @ 054cf020] Codec for stream 0 does not use global headers but container format requires global headers
Output #0, mp4, to '00007.MTS.mp4':
  Metadata:
    encoder         : Lavf57.16.100
    Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 29.97 fps, 29.97 tbr, 90k tbn, 90k tbc
    Stream #0:1: Audio: aac ([64][0][0][0] / 0x0040), 48000 Hz, 5.1(side), fltp, 128 kb/s
    Metadata:
      encoder         : Lavc57.15.100 aac
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (ac3 (native) -> aac (native))
Press [q] to stop, [?] for help
[mp4 @ 054cf020] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[mp4 @ 054cf020] pts has no value
    Last message repeated 209 times
frame=  420 fps=0.0 q=-1.0 Lsize=   12478kB time=00:00:07.01 bitrate=14564.2kbits/s    
video:12458kB audio:6kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.111239%
[aac @ 052fd480] Qavg: 64863.176

Es posible que desee intentar aplicar la velocidad de fotogramas original utilizando -r 29.97. FFmpeg probablemente está tratando de ajustar la velocidad de fotogramas por alguna razón. Su sintaxis es correcta y no debería producir ese error.

En cuanto a su tercera pregunta. Simplemente no es posible. Puede omitir fotogramas cuando use códecs que codifican fotogramas individualmente, pero ese no es el caso con h264, pero incluso con dicho códec aún modifica la transmisión de video de alguna manera. Lo mismo ocurre con el aumento de la velocidad de cuadros, debe agregar cuadros calculados o duplicar algunos cuadros.

Editar: con respecto a la información adicional del comentario a continuación. Si necesita cambiar los datos escritos en el encabezado del formato sin escribir un archivo completamente nuevo, probablemente quiera hacerlo en un editor hexadecimal. FFmpeg solo tiene la opción de alterar los metadatos que no incluyen los datos del flujo. Cómo y dónde realizar sus cambios en el archivo depende del formato del contenedor.

Otra opción sería demoler el contenedor y remux la transmisión de video y audio a un nuevo contenedor con sus opciones especificadas. La cantidad que puede volver a especificar depende del formato del contenedor. La herramienta MP4Box puede ser de ayuda con eso, en este caso, puede especificar una velocidad de fotogramas al mezclar transmisiones de video en bruto en un nuevo mp4 usando la siguiente sintaxis:

MP4Box -add input.h264:fps=29.97 -new output.mp4

Sé que esta es una vieja pregunta, pero simplemente apareció nuevamente en el feed, así que es nueva para mí. (-:

Una cosa que no veo mencionada es el orden de campo. Este es un archivo entrelazado, por lo que es una consideración. El OP menciona que los cuadros "tiemblan de un lado a otro", que siempre es un indicador de orden de campo incorrecto. Si el video está bien, excepto por el 'temblor', intente agregar lo que sea que ffmpeg necesite para forzar el "campo superior primero", luego lo contrario si todavía está mal. No estoy lo suficientemente familiarizado con los detalles de ffmpeg para dar las banderas exactas para eso.