Re: [FFmpeg-devel] [PATCH] avformat/mov: remove hack breaking creation time parsing

["Bernd Dürrer" <Bernd.Duerrer@gmx.de>]

On Tue Apr 11 2023, Marton Balint wrote:

> Maybe you can check if the DLNA server reads that. Or if it only reads the
> year information, then com.apple.quicktime.year might be even better.

I have checked the DLNA Guidelines and Part 1-1, clause 10.1.3.12.3, Table 13, recommends to provide the dc:date metadata property for
video items. I have MP4 files where the date metadata was set, but not to a complete date, but only the year part. This appears to be
the reason why my DLNA server has used the creation_time metadata instead. After setting the date tag to a complete date YYYY-MM-DD HH:MM:SS,
it is recognised by the DLNA server and provided to the DLNA clients, and there is no problem to set the date tag to dates before 1970 with
ffmpeg. So my use case to set the creation_time tag to dates before 1970 is now obsolete.

Nevertheless, I looked into ffmpeg why the command

ffmpeg -i input.mp4 -map_metadata 0 -metadata creation_time="1965-01-01 12:00:00" -codec copy output.mp4

results in creation_time written as 2036-01-01T23:59:59.000000Z to the output file. The reason is at the end of function av_parse_time
in libavutil/parseutils.c where mktime is called to convert the dt structure. As mktime cannot represent calendar times before 1970,
it returns -1. However, as the result is not checked, the return value of -1 is used for all subsequent processing and results in the wrong
date written to the file. In my humble opinion, at least a warning should be raised that the date value provided as parameter on the command
line is out of range.

Thanks for your support and kind regards,

Bernd
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".