Metadatos de video: ¿Para qué se usa el "retraso de video"?

Recientemente, me veo obligado a lidiar con un pequeño problema desagradable con los videos que tienen algunos atributos de metadatos especiales, a saber, "retraso" o "retraso_relativo_al_video".

Existe una solución de software de videoconferencia que produce estos archivos especiales, y cuando nuestro software de procesamiento de video examina estos archivos, obtiene valores de duración más largos que la duración real del contenido, por lo que almacena datos incorrectos en la base de datos, lo que causa más problemas en la fase de posprocesamiento.

Por ejemplo, grabamos un video de 46 segundos de duración, que se detectó como de 104,7 segundos de duración.

Después de inspeccionar el archivo con FFmpeg y Mediainfo, resultó que el archivo original tenía el llamado valor de "retraso" que se puede ver como starttiempo en la salida de FFmpeg:

Input #0, flv, from '/path/to/the/file/converter/master/194/194_video.flv':
  Metadata:
    metadatacreator : Yet Another Metadata Injector for FLV - Version 1.4
    hasKeyframes    : true
    hasVideo        : true
    hasAudio        : true
    hasMetadata     : true
    canSeekToEnd    : false
    datasize        : 12892571
    videosize       : 12198311
    audiosize       : 680584
    lasttimestamp   : 105
    lastkeyframetimestamp: 104
    lastkeyframelocation: 12646873
  Duration: 00:01:44.77, start: 58.033000, bitrate: 984 kb/s
    Stream #0:0: Video: h264 (Constrained Baseline), yuv420p, 1280x720, 30 fps, 30 tbr, 1k tbn
    Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp

...y Delayo Delay_relative_to_videoen los de Mediainfo:

mediainfo --full --output=XML /path/to/the/file/converter/master/194/194_video.flv

<track type="Video">
(...)
<Delay>0</Delay>
<Delay>00:00:00.000</Delay>
<Delay__origin>Container</Delay__origin>
<Delay__origin>Container</Delay__origin>
</track>

<track type="Audio">
(...)
<Delay>58036</Delay>
<Delay>58s 36ms</Delay>
<Delay>58s 36ms</Delay>
<Delay>58s 36ms</Delay>
<Delay>00:00:58.036</Delay>
<Delay__origin>Container</Delay__origin>
<Delay__origin>Container</Delay__origin>
<Delay_relative_to_video>58036</Delay_relative_to_video>
<Delay_relative_to_video>58s 36ms</Delay_relative_to_video>
<Delay_relative_to_video>58s 36ms</Delay_relative_to_video>
<Delay_relative_to_video>58s 36ms</Delay_relative_to_video>
<Delay_relative_to_video>00:00:58.036</Delay_relative_to_video>
</track>

"Sorprendentemente", restando la duración y el retraso me da la duración correcta...

Además, es realmente vergonzoso que algunas bibliotecas de codificadores cuenten estos retrasos en la duración total, ¡pero algunas no lo hacen! ¡Aparentemente no hay forma de distinguir qué valores de longitud son correctos y cuáles se incrementaron en consecuencia!

En pocas palabras, me gustaría saber para qué se utilizan estos metadatos. ¿Cuál es la razón de su existencia y por qué algunos codificadores/software de edición de video inyectan estos metadatos en el archivo?

¡Gracias por sus respuestas de antemano!

Editar:

De acuerdo con la respuesta de Mulvya, ¡ejecutar una copia de flujo simple en el archivo puede restablecer las marcas de tiempo!

Sin embargo, había un archivo .mov en el que no funcionó. Salida de consola relacionada:

ffmpeg -i 22_video.mov -c copy _22_video.mov
ffmpeg version N-79632-g3ce1988-static Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.7 (Debian 4.7.2-5)
  configuration: --prefix=/home/gergo/buildscript/ffmpeg-static-master-customVSQ/target --extra-cflags='-I/home/gergo/buildscript/ffmpeg-static-master-customVSQ/target/include -static' --extra-cflags=--static --extra-ldflags='-L/home/gergo/buildscript/ffmpeg-static-master-customVSQ/target/lib -lm -static' --extra-libs=-ldl --extra-version=static --disable-debug --disable-shared --enable-static --extra-cflags=--static --disable-ffplay --disable-ffserver --disable-doc --enable-gpl --enable-pthreads --enable-postproc --enable-gray --enable-runtime-cpudetect --enable-libfaac --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-bzlib --enable-zlib --enable-nonfree --enable-version3 --enable-libwavpack --enable-libvpx --enable-librtmp
  libavutil      55. 22.101 / 55. 22.101
  libavcodec     57. 38.100 / 57. 38.100
  libavformat    57. 34.103 / 57. 34.103
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 44.100 /  6. 44.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '22_video.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 537199360
    compatible_brands: qt
    creation_time   : 2013-10-29 21:33:33
    com.apple.finalcutstudio.media.uuid: 3B712819-1D1D-4F9B-8593-01656870A04C
    timecode        : 01:00:00:00
  Duration: 00:03:25.00, start: 0.000000, bitrate: 9332 kb/s
    Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080, 9019 kb/s, 25 fps, 25 tbr, 2500 tbn (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Apple Video Media Handler
      encoder         : H.264
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 307 kb/s (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Apple Sound Media Handler
    Stream #0:2(eng): Data: none (tmcd / 0x64636D74) (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Time Code Media Handler
      timecode        : 01:00:00:00
File '_22_video.mov' already exists. Overwrite ? [y/N] y
[mov @ 0x46c6660] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
    Last message repeated 1 times
Output #0, mov, to '_22_video.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 537199360
    compatible_brands: qt
    timecode        : 01:00:00:00
    com.apple.finalcutstudio.media.uuid: 3B712819-1D1D-4F9B-8593-01656870A04C
    encoder         : Lavf57.34.103
    Stream #0:0(eng): Video: h264 (avc1 / 0x31637661), yuv420p, 1920x1080, q=2-31, 9019 kb/s, 0.04 fps, 25 tbr, 10k tbn (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Apple Video Media Handler
      encoder         : H.264
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, 307 kb/s (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Apple Sound Media Handler
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 5125 fps=0.0 q=-1.0 Lsize=  233585kB time=00:03:25.00 bitrate=9333.9kbits/s speed= 547x
video:225709kB audio:7706kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.072599%

Respuestas (1)

Los formatos de transmisión mantienen marcas de tiempo para cada cuadro, ya sea de audio o video, que rigen cuándo el jugador debe presentarlos. Esos grandes tiempos de inicio distintos de cero generalmente ocurren cuando se corta un fragmento de un video más largo y la herramienta utilizada no restablece las marcas de tiempo. Aunque si este FLV se grabó solo, entonces es extraño.

En cualquier caso, ejecutar el siguiente comando debería solucionar el problema.

ffmpeg -i input.flv -c copy output.flv
¡Gracias por la rápida respuesta! Sí, creo que los códigos de tiempo de la transmisión en vivo se mantuvieron cuando se descargó, por lo que ahora tiene sentido. Su malabarismo con la marca de tiempo de ffmpeg resolvió el problema ... funcionó con el ejemplo mencionado anteriormente, sin embargo, lo probé con otro archivo que tenía el mismo problema (retraso de 1 hora). Ese archivo es un producto de algún tipo de software de Apple, en el que el comando no funcionó como se esperaba... Y descubrí otro problema: parece que algunas bibliotecas de codificadores cuentan el retraso para la longitud total, algunas de ellas no t, que es EXTRA confuso...
Muestre la salida completa de la consola del comando ejecutado en el archivo de Apple. Insértelo en la Q.
Aquí tienes. Básicamente respondiste la parte del "por qué", ¡muchas gracias por tu esfuerzo adicional!
¿Qué tiene de malo la salida de Apple? Se ve bien.
Mediainfo todavía dice que el retraso es <Delay>1h 0mn</Delay>. FFmpeg insinúa lo mismo con la timecode : 01:00:00:00parte... Creo que el problema particular con el archivo .mov es tan raro que no debería recibir más atención (básicamente 1 de 1200+ otros archivos).
Eso es un código de tiempo, no una marca de tiempo, y no debería afectar la detección de duración. Puede restablecerlo:ffmpeg -i in.mov -c copy -timecode 00:00:00:00 out.mov
Maldita sea, tienes razón, la salida de mediainfo fue bastante engañosa en el último caso... ¡La -timecodeopción funcionó! ¡Gracias!
Metadatos de video: ¿Para qué se usa el "retraso de video"?
RespuestasAquíPolítica de privacidad1y, 1v