[FFmpeg-devel] modification time in libavformat (.MOV files)

[Ayke van Laethem]

Hi,

I have been working on a patch to fix a bug I discovered in the saving
of .MOV files. In short, the creation time of individual streams isn't
copied as it says they will be (it is copied from the output .MOV file
instead, which is null if -map_metadata isn't used), and modification
time is set to the creation time.

This SuperUser post is in part about this issue:
http://superuser.com/questions/510578/when-spliting-mp4s-with-ffmpeg-how-do-i-include-metadata
I can add a way to reproduce the issue if needed. I will certainly do
that before (or while) submitting the patch.

The patch I wrote seems to work correctly, but fate fails. I assume
this is because the metadata is changed so the output file has a
different hash than what fate expects. Updating the hash so it
includes the correct creation_time should be easy, but the
modification time will be different each time.
So here is the question. Should the modification time be set at all? I
think it would be the more 'correct' way to go, but it makes testing
harder. If modification time will be set, how should testing be done?

Relevant parts of the specification:
https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html
(see 'Movie Header Atoms' and 'Track Header Atoms').
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=61988
(see 'Movie Header Box' and 'Track Header Box')

Re-reading the specification I am not sure whether copying the
creation time for tracks should even happen, but this is what ffmpeg
says it will do and it is also what I would expect to happen. For
example, Shotwell relies on this metadata to determine when a video
was taken.

I have no prior experience with the internals of ffmpeg at all, and
only use ffmpeg occasionally (I just happened to notice something was
odd with creation_time while cutting some personal videos).

— Ayke