I'm sorry this mail is going to be rather long. However, I would
like to explain my opinion on this matter in detail.
I would also like to kindly ask everybody to calm down and refrain
from further ad-hominem attacks, because these are not going to make
things better for anybody.
Ulf Zibis wrote:
> As you see from the arguments of James Ralston, the funcionality around the
> '-y' option is not that simple, as one – especially Harald – might think.
I agree. In fact I think that the logic around the -y option (and its
absence) is not very well implemented in FFmpeg currently. But that's
a different topic; we're certainly not going to fix that here and now.
> Well, in the end, "managing filesystem-level metadata", is also just an "OS
> call".
> Since James' arguments, I now have the impression that the implementation of
> my suggestion might even be easier than the correct handling of the “don't
> overwrite silently” functionality, at least from the OS call side.
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.
FFmpeg already does *lots* of OS calls, either directly or indirectly
(via 3rd-party libraries). Just run a truss(1), ktrace(1), strace(1)
(or whatever your operating system provides to trace system calls)
on the FFmpeg binary to get an impression. So it really doesn't
matter if there are two OS calls more or less.
So, then what are the pros and cons of the proposed wish?
On the pro side, one user (Ulf) obviously has a use case for this
kind of feature. However, so far, nobody else has stepped forward,
explaining that he would need that feature, too.
So, to be fair, this proposal is about a convenience option that
appears to benefit very few people (maybe just one).
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, and
I'm not aware of any program that overrides it -- except for cp(1)
when the -p option is used, but it makes sense that cp(1) provides
such a convenience option because it does not create new content,
and there are often use cases where you need an identical copy of
a file including metadata (note that "cp -p" does not only copy the
mtime, but also other metadata).
On the other hand, FFmpeg *always* creates new content (*).
Therefore, the default behaviour of the OS to assign an updated mtime
to the output files is almost always what is desired. An option to
override that behaviour would only very rarely be useful.
Note that the OS also does other things by default. For example, it
assigns a group to newly created files. The details depend on the
operating system and on the mode bits of the directory: It may be the
group of the directory, or it may be the primary group of the user.
There might be cases where the user wants to override the default
group selection of the operating system -- do you think that FFmpeg
should have an option for this? I don't think so. You can easily
use an OS command to change the group if desired. Exactly the same
holds true for the mtime.
In fact, I can rather imagine use cases to preserve the *atime*
(access time) of the input files, rather than overriding the mtime
of output files. So, in my opinion, an option to reset the atime
when FFmpeg is finished would be more useful (and it would be much
easier to implement). But I wouldn't propose it either, because it
can be trivially done with an OS command, too.
There are two further cons that are important.
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. Therefore it is better to
do that with a separate OS command afterwards ("touch", as has been
mentioned several times).
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).
(My personal opinion: FFmpeg's existing -map* options are already
complicated enough; we don't really need more of that.)
In other words, it requires a certain amount of time and effort from
developers. All of that for a very rare use case that can trivially
be solved by running an OS command afterwards? It is very unlikely
that this is going to happen.
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.
The bottom line is: If *you* know exactly which mtime should be
copied from which input to which output, then it is *MUCH* better
that you do that with an appropriate OS command, instead if trying
to teach FFmpeg a syntax for doing such things in a generic way.
> But it is like it is, there is no vote for my proposal.
That's probably because nobody else sees the need for the proposed
option. Personally I would prefer that the FFmpeg developers spend
their time doing important things, like fixing bugs and implementing
*useful* new features, instead of implementing a feature with unclear
semantics that is rather a convenience option desired by a single
person.
Best regards
-- Oliver
(*) Well, in theory you can use FFmpeg to make a 1:1 copy (-map 0,
same container), but even then details will usually be different --
this can be confirmed by comparing MD5 checksums, for example.
Apart from that, if you really wanted to make an identical copy,
you could just use cp(1) (or your favourite file manager); no need
to fire up FFmpeg.
_______________________________________________
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".
