Opened 2 years ago

Closed 22 months ago

#5673 closed defect (fixed)

Wrong creation_time

Reported by: cehoyos Owned by:
Priority: important Component: avformat
Version: git-master Keywords: mov regression
Cc: cus Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description (last modified by cehoyos)

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.

Change History (8)

comment:1 follow-ups: Changed 2 years ago by 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.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 2 years ago by cehoyos

  • Cc cus added

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.

comment:3 in reply to: ↑ 1 ; follow-up: Changed 2 years ago by dart

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.

comment:4 Changed 2 years ago by dart

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).

comment:5 in reply to: ↑ 2 Changed 2 years ago by cus

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.

comment:6 in reply to: ↑ 3 Changed 2 years ago by cus

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

comment:7 Changed 22 months ago by cehoyos

  • Description modified (diff)

comment:8 Changed 22 months ago by cus

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.