Option to preserve filetime of input

[Ulf Zibis]

Summary of the bug:
For convenience please add an option to preserve the filetime of the input file to the output file.
Example:

% ffmpeg -i input --preserve-filetime output  ## Alternative: --keep-filetime

Workaround:

% DATE=$(stat -c %Y input) && ffmpeg -i input output && touch -d @${DATE} filename

[inof]

A better solution is this (after running FFmpeg):

touch -r <input> <output>

That should work on any POSIX-compliant system, including Linux and BSD. If you need to do that often, you can write a small script to do it for you.

I don't think FFmpeg should mess with such things itself.

Keep in mind that there can be an arbitrary number of input files (not just one), and there can be an arbitrary number of output files as well. What time stamp should be mapped from which input file to which output file? It's not that easy; a simple command line option won't suffice. And what if the output is a symlink? Should the time stamp of the target be changed, or the time stamp of the symlink itself, or both? What about the access time stamp, should it be preserved, too? Also, if FFmpeg started supporting that, then why not also preserve the files' permission flags? Or the group ownership? Or ...? It's a can of worms.

[elenril]

I agree with inof, this is out of scope for ffmpeg CLI.

[Ulf Zibis]

Replying to inof:

A better solution is this (after running FFmpeg):

touch -r <input> <output>

You could also argue, that
rm <output> && ffmpeg ...
is better than
ffmpeg -y ....
Its's the same scope of actions.

Keep in mind that there can be an arbitrary number of input files (not just one), and there can be an arbitrary number of output files as well. What time stamp should be mapped from which input file to which output file?

Use the same rules as for mapping files, streams and channels. If not otherwise specified, always refer the first input. Optionally allow specification like for all other mappings. Output is automatically specified by the position in the command. E.g., if --codec is placed after the first output file, it is only valid for the following output.

It's not that easy; a simple command line option won't suffice.

Agreed, slicely more complex than for option -y

And what if the output is a symlink?

Same question appears for option -y and your "better solution" !

What about the access time stamp, should it be preserved, too?

Same question appears for your "better solution" !

Also, if FFmpeg started supporting that, then why not also preserve the files' permission flags? Or the group ownership? Or ...? It's a can of worms.

Still same questions appear for your "better solution" !

[inof]

Replying to Ulf Zibis:

Replying to inof:

A better solution is this (after running FFmpeg):

touch -r <input> <output>

You could also argue, that
rm <output> && ffmpeg ...
is better than
ffmpeg -y ....

You probably mean:
rm -f <output>; ffmpeg ...
That wouldn't be better because it opens a potential security hole (a race condition).

Apart from that, the -y option cannot really be compared with the option proposed in this ticked, because it serves a very different purpose and has very different implications. (By the way, note that the -y option does not cause FFmpeg to remove the file beforehand, i.e. it is not the same as calling rm. The -y option only disables the check for the existence of the file.)

Actually, the behaviour of FFmpeg regarding the presence or non-presence of the -y option is not very good. It needs to be redesigned, taking advantage of the O_EXCL flag to the open() function, but that's beyond the scope of this ticket.

[MasterQuestionable]

͏    `rm <output> && ffmpeg ...` vs. `ffmpeg -y ...`
͏    `rm -f <output>; ffmpeg ...`

͏    Note:
͏    `rm -f` may regardless return success.
͏    "&&" means when success (or evaluated true, at times). [1]
͏    And "&" means asynchronous execution. [2]

[ [1]
͏    E.g.
͏    `1 && 2` runs 2 only after success of 1.
͏    (no run if failure) ]
[ [2]
͏    `1& 2&` may mean to execute them in regardless order: potentially parallel.
͏    `1; 2;` is blocking: 2 must be planned after finishing 1. ]

[MasterQuestionable]

͏    I think it's sensible.
͏    Any problem it may rise having the implementation?

͏    "--preserve-filetime", "--keep-filetime"
<^>    Why not "-p"?
͏    Parallel with ͏"-y".

[MasterQuestionable]

͏    Implementation note:
͏    A file may have 3 associated times:
͏    |1| Modification
͏    |2| Access
͏    |3| Inode Change

͏    E.g. ​https://dev.to/masterinquestion/comment/2hgbe

[Ulf Zibis]

Meanwhile I think, the option should only preserve the mtime, to make it simple. So then it could be named:
--preserve-mtime or --keep-mtime or additionally -p or -k, if yet available.

A future enhancement for all file meta data could be:
--preserve-meta or --keep-meta or additionally -P or -K, if yet available.

[Cigaes]

It has been explained on the users mailing-list that an output file can be created from multiple input files. This option would therefore need a complex logic to decide *which* input file should give its timestamp to the output file, and that complex logic would need to be documented to the users.

And that is just not worth it when the same logic can be simply expressed outside from ffmpeg.

[MasterQuestionable]

͏    Overdone may undermine the future...
͏    Extreme invert. Excess amok.

͏    To determine the availability:
͏    ffmpeg -v debug -hide_banner -p
͏    ; etc.

͏    And "all file meta data"..? What do you intend?
͏    .
͏    And I'm against use of metadata overall:
͏    ​https://trac.ffmpeg.org/ticket/8338#comment:20
͏    ​https://github.com/exiftool/exiftool/issues/252#issuecomment-2067281770

͏    ----

͏    Pardon I scarcely read mail lists for the usefulness and accessibility reason:
͏    ​https://trac.ffmpeg.org/ticket/11055#comment:151
͏    .
͏    Regardless for reference:
͏    ​https://www.mail-archive.com/search?l=ffmpeg-user@ffmpeg.org&q=subject:%22How+to+preserve+file+time%22&o=oldest&f=1

͏    I sense it anyhow.
͏    However it might be even worthy to just implement a shortcut version:
͏    That mere blindly assumes that of the 1st "-i".

͏    Or mere simply:
͏    Use whichever it's placed before "-i": last occurrence takes precedence.
͏    Assume 1st "-i" if one placed after "-i" (as output option).

͏    Any rejection?

͏    ----

͏    Caveat that the input maybe atypical sources rather than typical file:
͏    ​https://trac.ffmpeg.org/ticket/11159#comment:14
͏    ​https://trac.ffmpeg.org/ticket/10989
͏    .
͏    In which case there'd be no sensible filetime.

͏    A warning message:
͏    “W/ No input applicable for "-p" (Preserve filetime as input). Ignoring.”
͏    See also: ​https://trac.ffmpeg.org/ticket/11071

͏    When "-p" used as output option:
͏    The whole input list should be enumerated to find the 1st sensible one.
͏    (rather than failing on 1st unsensible)

[MasterQuestionable]

͏    I scarcely rely on filesystem time.
͏    If it did matter, I tend to have it as part of filename:
͏    E.g.
͏    "20240830_Big Talk.txt"
͏    "colorspace_yuv444p10le-yuv444p.20190416.webp"
͏    "NotoSansMono-Light.20240509_095652.8e0ceff8f08d62cc6af00031a9383a897565bd05.ttf"

͏    Or outright written in-file (for Plain Text).

[MasterQuestionable]

͏    I may help with the implementation however.

[elenril]

MasterQuestionable, please stop arbitrarily reopening bugs closed by developers.
I maintain the ffmpeg CLI and it is my decision in that capacity that this feature is out of scope and would be too complex to implement properly.
If you really want to escalate the issue further, you can present an additional argument here, or take it to TC, but so far I've seen no compelling reason to add it.

[MasterQuestionable]

͏    Present a compelling reason to reject its implementation, please?
͏    My implementation hint presented before should be proper enough, to handle all possible cases properly.
͏    If the proposer would like to implement it: why not?

[elenril]

The reasons were already stated by people above:

• ffmpeg CLI is an M-to-N transcoder, there is in general no canonical way to tell which is THE input file for a given output file;
• Which timestamp of the three standard ones is to be preserved? Do we add a new option for each one? What about permissions, ACLs, xattrs, etc.? This is a giant can of worms.
• The same functionality can be easily implemented with standard unix commandline tools.

  ͏ If the proposer would like to implement it: why not?
  

Because ffmpeg CLI already has way too many options, which makes it extremely hard to understand both for users and developers. Each new option has to be maintained for a very long time, and its interactions with other options have to be considered, making future development harder. New options should only be added if there is a strong reason for them to exist and I see no such reason here.

[MasterQuestionable]

͏    Please take a bit more careful review on the aforementioned logic.
͏    "in general no canonical way, to tell which is the input file for a given output file."
<^>    How is the output file possibly be properly generated this way..? Out of mere air?

͏    |1| [
͏    "-p" as input: Use whichever "-i" it binds, for all output in the same input-output group.
͏    E.g. `-i "1" ... "out1" ... -i "2" ... "out2"`
͏    ; "1" and "out1", "2" and "out2": are considered the same group. ]
͏    |2| [
͏    "-p" as output: Guess the most sensible one.
͏    Try simple mapping if in-out can be 1-1 mapped.
͏    Else, use aforementioned logic. (assume 1st "-i" sensible) ]

͏    Modification time alone should suffice. All together also shouldn't matter.
͏    However the real interesting thing is probably not this functionality itself, but beyond:
͏    Analyzing the whole structure of FFmpeg, by the opportunity.
͏    .
͏    And my aim is on the "concat", "-map" related things:
͏    ​https://trac.ffmpeg.org/ticket/11146#comment:22


͏    Not really because too many options, but not properly arranged.
͏    Length itself is usually not the accessibility killer.
͏    Bad hierarchy is.

͏    As for permissions, ACL (Access Control Lists), "xattr" whatsoever: even dedicated archive format may not handle them...
͏    ​https://unix.stackexchange.com/questions/600282/preserve-file-permissions-and-symlinks-in-archive-with-7-zip#639108
͏    ​https://www.google.com/search?hl=en&gl=ca&num=10&q=7zz|7z+permissions
͏    ​https://en.wikipedia.org/wiki/Talk:7z#file_permissions


͏    I wonder 1 question, does such writing:
͏    ffmpeg -y -v debug -hide_banner -nostdin -nostats "Out.mkv" -f lavfi -i "testsrc2=1920x1080:10:d=1"
͏    ; really make sense?
͏    Is there significant actual usage of such?

[MasterQuestionable]

͏    "what if the output is a symlink?"
<^>    I believe FFmpeg could only handle alike in 2 possible ways:
͏    |1| Either outright overwrite the link, or
͏    |2| Trace the link and act on target.

͏    Either way, just no essentially different as handling ordinary file.