Wrong creation_time

[Carl Eugen Hoyos]

​http://ffmpeg.org/pipermail/ffmpeg-user/2016-June/032575.html
Setting creation_time sets an incorrect time in mov since 5f64f3d8cf06631541a4abb1e9a0a4bf4b8e6e0f

$ ffmpeg -f s16le -i /dev/zero -t 1 -acodec copy -metadata "creation_time=2010-03-20 21:34:56" out.mov
ffmpeg version N-80780-gd693392 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      55. 27.100 / 55. 27.100
  libavcodec     57. 48.101 / 57. 48.101
  libavformat    57. 40.101 / 57. 40.101
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 46.102 /  6. 46.102
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
Guessed Channel Layout for Input Stream #0.0 : mono
Input #0, s16le, from '/dev/zero':
  Duration: N/A, bitrate: 705 kb/s
    Stream #0:0: Audio: pcm_s16le, 44100 Hz, 1 channels, s16, 705 kb/s
[mov @ 0x37f7dc0] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Output #0, mov, to 'out.mov':
  Metadata:
    creation_time   : 2010-03-20 21:34:56
    encoder         : Lavf57.40.101
    Stream #0:0: Audio: pcm_s16le (sowt / 0x74776F73), 44100 Hz, mono, 705 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
size=      89kB time=00:00:01.02 bitrate= 711.0kbits/s speed=3.76e+03x
video:0kB audio:88kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.761275%

$ ffmpeg -i out.mov
ffmpeg version N-80780-gd693392 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      55. 27.100 / 55. 27.100
  libavcodec     57. 48.101 / 57. 48.101
  libavformat    57. 40.101 / 57. 40.101
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 46.102 /  6. 46.102
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'out.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 512
    compatible_brands: qt
    creation_time   : 2010-03-20 20:34:56
    encoder         : Lavf57.40.101
  Duration: 00:00:01.02, start: 0.000000, bitrate: 710 kb/s
    Stream #0:0(eng): Audio: pcm_s16le (sowt / 0x74776F73), 44100 Hz, mono, s16, 705 kb/s (default)
    Metadata:
      creation_time   : 2010-03-20 20:34:56
      handler_name    : DataHandler
At least one output file must be specified

Also reproducible with other containers.

[Marton Balint]

When you specify creation time in the CLI, it is interpreted in local timezone, therefore it is recalculated to UTC before saving it in MOV. So after my patch, the correct UTC time is stored in MOV.

Unfortunately when ffmpeg reads creation time metadata from mov, I guess it presents the UTC time, but without specifying it, that it is in UTC. The correct fix would be to fix the mov demuxer (and all demuxers having the same problem) to set the creation_time to an ISO 8601 compatible timestamp.

Which other muxers are affected? I might work on this.

[Carl Eugen Hoyos]

Replying to cus:

When you specify creation time in the CLI, it is interpreted in local timezone, therefore it is recalculated to UTC before saving it in MOV. So after my patch, the correct UTC time is stored in MOV.

Could you explain the usecase?

Which other muxers are affected? I might work on this.

I saw the same issue with mkv iirc.

[Denys Kuzmenko]

Replying to cus:

When you specify creation time in the CLI, it is interpreted in local timezone, therefore it is recalculated to UTC before saving it in MOV. So after my patch, the correct UTC time is stored in MOV.

Unfortunately when ffmpeg reads creation time metadata from mov, I guess it presents the UTC time, but without specifying it, that it is in UTC. The correct fix would be to fix the mov demuxer (and all demuxers having the same problem) to set the creation_time to an ISO 8601 compatible timestamp.

Which other muxers are affected? I might work on this.

Maybe a piece of email from user group could be helpful. I found no connection to local timezone, the time was just one hour less:

So I try to set 21:29, it's reported that 21:29 will be written into
the output file but the actual result is 20:29.
And it doesn't look like it's some timezone problem since I currently
have GMT+2, file date is in GMT+1 (March in Central European Time) but
I also tried GMT+2 dated files (April) and the result was that same.

[Denys Kuzmenko]

Canon and Nikon DSLRs write this field in local time.
Samsung Galaxy S4 - UTC.

When I upload photos and videos from DSLRs to Google Photo they are sorted properly inside album (photos have local time and timezone info, videos have only local time).

[Marton Balint]

Replying to cehoyos:

Replying to cus:

When you specify creation time in the CLI, it is interpreted in local timezone, therefore it is recalculated to UTC before saving it in MOV. So after my patch, the correct UTC time is stored in MOV.

Could you explain the usecase?

What do you mean? MOV (and mkv) stores the creation time as the elapsed time since some reference timestamp. MOV recommands UTC time reference, Matroska explicitly defines it. When you specify -metadata "creation_time=2016-01-01 20:00:00" you obviously mean 20:00 in your local time, and not UTC 20:00, therefore it has to be properly adjusted to UTC time before writing it to the file.

Which other muxers are affected? I might work on this.

I saw the same issue with mkv iirc.

Yes, it has the same problem.

[Marton Balint]

Hmm, it seems there are two problems:
1) the time parser always assumes standard time - therefore the mismatch was always 1 hour
2) The problem I already described, demuxers sets metadata in UTC but they don't signal this

[Marton Balint]

Fixed in 13b90ff2c12749aac58d22da4cb47c24b7a37b04.