"creation_time" metadata incorrect in mov files

[TimNich]

Summary of the bug:
When creating a mov from a mov ffmpeg carries forward the "creation_time" metadata from the original file (if it exists) such that the reported metadata (fprobe) is incorrect for the file that it has just created.

How to reproduce:

% ffmpeg -i in.mov -timecode 09:59:30:06 -an -c:v dvvideo -pix_fmt yuv420p -an -y out.mov
ffmpeg version N-41512-g66531c7-by_Tim Copyright (c) 2000-2012 the FFmpeg developers
  built on Jun 11 2012 12:26:34 with gcc 4.6.2
  configuration: --extra-version=by_Tim --enable-static --disable-shared --enable-gpl --enable-nonfree --enable-version3 --prefix=/mnt/msds-store-0/tim/ffmpeg-tux/usr/local --libdir=/mnt/msds-store-0/tim/ffmpeg-tux/usr/local/lib64 --samples=../fate-suite/ --enable-runtime-cpudetect --extra-cflags='-static -I/mnt/msds-store-0/tim/ffmpeg-tux/usr/local/include' --extra-ldflags='-static -L/mnt/msds-store-0/tim/ffmpeg-tux/usr/local/lib64' --progs-suffix=_Jun-11 --enable-libfaac --enable-libx264 --enable-libfree  libavutil      51. 57.100 / 51. 57.100
  libavcodec     54. 25.100 / 54. 25.100
  libavformat    54.  6.101 / 54.  6.101
  libavdevice    54.  0.100 / 54.  0.100
  libavfilter     2. 78.101 /  2. 78.101
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
Guessed Channel Layout for  Input Stream #0.1 : mono
Guessed Channel Layout for  Input Stream #0.2 : mono                                                                                                                                                                                                                            
Guessed Channel Layout for  Input Stream #0.3 : mono                                                                                                                                                                                                                            
Guessed Channel Layout for  Input Stream #0.4 : mono                                                                                                                                                                                                                            
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/mnt/msds-store-0/Media_hub/bisect/in.mov':                                                                                                                                                                                            
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2012-06-08 06:31:48
  Duration: 00:00:00.40, start: 0.000000, bitrate: 33658 kb/s
    Stream #0:0(eng): Video: dvvideo (dvcp / 0x70637664), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 28800 kb/s, SAR 118:81 DAR 295:162, 25 fps, 25 tbr, 25 tbn, 25 tbc
    Metadata:
      creation_time   : 2012-06-08 06:31:48
      handler_name    : Apple Alias Data Handler
      timecode        : 01:00:00:00
    Stream #0:1(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
    Metadata:
      creation_time   : 2012-06-08 06:31:48
      handler_name    : Apple Alias Data Handler
    Stream #0:2(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
    Metadata:
      creation_time   : 2012-06-08 06:31:48
      handler_name    : Apple Alias Data Handler
    Stream #0:3(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
    Metadata:
      creation_time   : 2012-06-08 06:31:48
      handler_name    : Apple Alias Data Handler
    Stream #0:4(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
    Metadata:
      creation_time   : 2012-06-08 06:31:48
      handler_name    : Apple Alias Data Handler
    Stream #0:5(eng): Data: none (tmcd / 0x64636D74)
    Metadata:
      creation_time   : 2012-06-08 06:31:48
      handler_name    : Apple Alias Data Handler
      timecode        : 01:00:00:00
[buffer @ 0x17f07c0] w:720 h:576 pixfmt:yuv420p tb:1/25 fr:25/1 sar:118/81 sws_param:flags=2
[ffmpeg_buffersink @ 0x17f0aa0] No opaque field provided
Output #0, mov, to 'out.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2012-06-08 06:31:48
    timecode        : 09:59:30:06
    encoder         : Lavf54.6.101
    Stream #0:0(eng): Video: dvvideo (dvcp / 0x70637664), yuv420p, 720x576 [SAR 118:81 DAR 295:162], q=2-31, 200 kb/s, 25 tbn, 25 tbc
    Metadata:
      creation_time   : 2012-06-08 06:31:48
      handler_name    : Apple Alias Data Handler
      timecode        : 01:00:00:00
Stream mapping:
  Stream #0:0 -> #0:0 (dvvideo -> dvvideo)
Press [q] to stop, [?] for help

Notice from the above how the output creation_time is the same as the input times.. "creation_time : 2012-06-08 06:31:48"

[TimNich]

sample QT file made by FCP

[Ulf Zibis]

I have a different opinion to this issue.
I see "creation_time" as the time, when the video was originally recorded. This time should not change on transcoding, so could be preserved. The file creation time is anyway saved from the underlying OS in the file system.
If ffmpeg sees the "creation_time" as time of encoding, why doesn't it set to the current time, but leaves it empty?

Linux tool "mediainfo" distinguishes between "Encoded date" and "Tagged date". Which one is interpreted as "creation_time" by ffmpeg?

As another distinction in JPEG EXIF we find "DateTimeOriginal" and "DateTimeDigitized".

The current behaviour prevents -f ffmatadata to report the global "creation_time", see #8552

[Carl Eugen Hoyos]

The main issue here is that it makes no sense to discuss this problem on trac: The change was undisputed as far as I remember and will not be reverted because of a request here. If you really believe that this fix should be reverted send a patch to the development mailing list: I doubt that it will be accepted but posting on this bug tracker definitely won’t help.

(The blocking fields don’t work as expected.)