Am 21.08.24 um 12:45 schrieb Oliver Fromme:
I'm sorry this mail is going to be rather long. However, I would like to explain my opinion on this matter in detail.
Hollala, thanks for your effort. German accuracy? ;-)
Well, I'm not sure who brought up the "OS call" argument -- and why. I think that point is rather irrelevant, or at least very weak.
Much thanks for that understanding !!!
And what are the cons? Keep in mind that the meaning of the "mtime" time stamp (in POSIX terms) is the last modification time of the file contents. When a new file (with new contents) is created, it is obvious that the mtime should be set to the creation time of the file. This is what the operating system does by default, and it is what users expect,
Agreed, so it should never be the default behaviour. In case of mtime is "manipulated", one can substitutionally refer the "creation time" (on Linux a kind of hidden and not available on very old kernels). * On the other hand, Linux NTFS, FAT and exFAT drivers mostly associate Windows "creation time" with Linux ctime.
and I'm not aware of any program that overrides it
I've seen this plenty of times. The one, which instantly comes in memory is IrfanView. There it's my standard setting. From there I was inspired for my proposal. I also remember some MP3-tag editors, which provide that.
An option to override that behaviour would only very rarely be useful.
To me it's very useful. Imagine you have huge collection of pictures and videos. If I do some compression later, preserving the mtime allows me to simply use the file manager for listing the files in their right order. Also e.g. image viewers normally refer the mtime for the order in a "slide show". For image compression I can conveniently use IrfanView for that requirement. But for videos I have to use FFMPEG, where I painfully miss that option.
... do you think that FFmpeg should have an option for this?
Not really. (It could be named '--preserve-file-metadata' ;-) ) So I change my proposal to name the option '--preserve-mtime', it's anyway shorter.
First, note that every single write access to output files refreshes their mtime. That means that the setting of the mtime would be the very last thing that FFmpeg had to do before it exits, after closing the output files. But what if FFmpeg terminates unexpectedly, e.g. because of a critical error or because of an OS signal? In that case, the mtime would not be set as desired.
The same problem occurs with other options, e.g. '-movflags +faststart'. I think that culprit is acceptable.
Second, implementing the proposed option correctly is actually very non-trivial, especially considering that there can be multiple input files and multiple output files, and there needs to be some syntax and built-in logic for mapping mtime from input files to output files (not to mention that all of that needs to be documented, too).
Agreed, that this is the only non-trivial part. But the logic behind already exists, see my comment: https://trac.ffmpeg.org/ticket/11139#comment:3
(My personal opinion: FFmpeg's existing -map* options are already complicated enough; we don't really need more of that.)
Right. But one can reuse them, and I believe, that most of the complicated side paths with '-map*' are not needed here.
By the way, there are a lot more complications. For example, there are input streams that consist of multiple files. Think about the concat demuxer. How to handle that? Another typical case are VOBSUB subtitles that consist of two files (*.sub and *.idx). What if they have different mtimes -- which one should be taken? What if an input is a network stream -- should FFmpeg try to parse the "Last- Modified" header? What if there is no such header? What if an input file is a pipe, a FIFO or standard input? Even if you can answer these questions for yourself, others might think differently about such cases. And these are just some cases from the top of my head; you'll probably find many more when you read through the manual page.
if the user idiotically maps the '--preserve-mtime' option to such streams, just ignore the option or throw an error message. Regards, -Ulf _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
