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.
Thank you for
Am 21.08.24 um 14:39 schrieb Ulf Zibis:
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
when you have a huge collection
Am 21.08.24 um 14:39 schrieb Ulf Zibis:
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, w
Am 21.08.24 um 14:39 schrieb Ulf Zibis:
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 fil
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 thi
On Wed, 21 Aug 2024 at 12:15, Nicolas George wrote:
>
> Oliver Fromme (12024-08-21):
> > I'm sorry this mail is going to be rather long. However, I would
> > like to explain my opinion on this matter in detail.
>
> You are more patient than this issue deserves.
I enjoyed reading Oliver's explana
Am 21.08.24 um 12:48 schrieb Ulf Zibis:
So for 1. it must be additionally:
In case of output file existence 2 additional OS operations are needed
and executed: Write a message to system output stream + read and parse
users answer from system input stream.
As discovered by James Ralston, the
Oliver Fromme (12024-08-21):
> I'm sorry this mail is going to be rather long. However, I would
> like to explain my opinion on this matter in detail.
You are more patient than this issue deserves.
> In fact, I can rather imagine use cases to preserve the *atime*
> (access time) of the input fil
Am 21.08.24 um 10:56 schrieb Reindl Harald:
Am 20.08.24 um 21:33 schrieb Ulf Zibis:
There seems some need to outline and precise my original message.
1. For the security of existing data and in some way for convenience (avoid the
need to create the potentially overwritten data again) FFmpeg
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
Am 21.08.24 um 10:40 schrieb Ulf Zibis:
Am 20.08.24 um 21:59 schrieb Rob Hallam:
It is unlikely at this point you will receive an argument you deem
applicable.
A call to an OS function is not the same as managing filesystem-level
metadata.
If you really want it, it is possible for you to
Am 20.08.24 um 21:33 schrieb Ulf Zibis:
Am 14.08.24 um 17:20 schrieb Ulf Zibis:
Am 12.08.24 um 19:04 schrieb Mark Filipak:
That's a question for your operating system. I can change file times
to whatever I want via the TotalCommander file browser. There are
probably others.
Isn't remo
Am 20.08.24 um 21:59 schrieb Rob Hallam:
It is unlikely at this point you will receive an argument you deem applicable.
A call to an OS function is not the same as managing filesystem-level metadata.
If you really want it, it is possible for you to write and maintain
your own small patch that
> I suspect the reason why ffmpeg implements its current (incorrect)
> behavior is because Windows lacks the Unix/Linux equivalent of O_EXCL.
Consider the CreateFileA function in fileapi.h with the dwCreationDisposition
argument set to CREATE_NEW, which would fail on the existence of the target
On Tue, 20 Aug 2024 at 20:33, Ulf Zibis wrote:
> 4. I'm fine with the result, that FFmpeg developers don't want to provide my
> proposal.
>
> But please *avoid inapplicable arguments*.
It is unlikely at this point you will receive an argument you deem applicable.
A call to an OS functio
Am 14.08.24 um 17:20 schrieb Ulf Zibis:
Am 12.08.24 um 19:04 schrieb Mark Filipak:
That's a question for your operating system. I can change file times to
whatever I want via the TotalCommander file browser. There are probably others.
Isn't removing existing output files samely a question
Am 18.08.24 um 11:38 schrieb Reindl Harald:
Am 18.08.24 um 00:54 schrieb Ulf Zibis:
Am 18.08.24 um 00:26 schrieb Reindl Harald:
Am 17.08.24 um 22:33 schrieb Ulf Zibis:
And WHAT then happens with the original file, when write creates ANOTHER file
???
NOTHING'
Another interesting va
Am 19.08.24 um 17:40 schrieb James Ralston:
On Mon, Aug 19, 2024 at 6:41 AM Reindl Harald wrote:
Am 19.08.24 um 07:56 schrieb James Ralston:
The fact that ffmpeg does it this way [queries for the existence
of the output file itself) is a bug (albeit perhaps one of
convenience, since ffmpeg
On Mon, Aug 19, 2024 at 6:41 AM Reindl Harald wrote:
> Am 19.08.24 um 07:56 schrieb James Ralston:
>
> > The fact that ffmpeg does it this way [queries for the existence
> > of the output file itself) is a bug (albeit perhaps one of
> > convenience, since ffmpeg supports more operating systems th
Am 19.08.24 um 07:56 schrieb James Ralston:
On Sat, Aug 17, 2024 at 3:54 PM Ulf Zibis wrote:
You can spin it however you like. The logic around the ‘-y’ option
requires an extra additional OS call
It shouldn’t.
in this case querying the existence of the file, before it is
overwritten.
On Sat, Aug 17, 2024 at 3:54 PM Ulf Zibis wrote:
> You can spin it however you like. The logic around the ‘-y’ option
> requires an extra additional OS call
It shouldn’t.
> in this case querying the existence of the file, before it is
> overwritten.
The fact that ffmpeg does it this way is a b
Am 18.08.24 um 12:16 schrieb Reindl Harald:
Am 18.08.24 um 12:12 schrieb Ulf Zibis:
Am 18.08.24 um 03:04 schrieb Oliver Fromme:
Would you please stop this? This kind of discussion is not going to
improve FFmpeg. You're just annoying everybody.
You mean the discussion about smartness, dumbn
Am 18.08.24 um 12:12 schrieb Ulf Zibis:
Am 18.08.24 um 03:04 schrieb Oliver Fromme:
Would you please stop this? This kind of discussion is not going to
improve FFmpeg. You're just annoying everybody.
You mean the discussion about smartness, dumbness and nonsense? I agree
with you.
Please
Am 18.08.24 um 03:04 schrieb Oliver Fromme:
Would you please stop this? This kind of discussion is not going to
improve FFmpeg. You're just annoying everybody.
You mean the discussion about smartness, dumbness and nonsense? I agree with
you.
Please address the originator.
Cheers Ulf
which is
identically handeled in both cases
you pretended "But for convenience FFmpeg CLI provides option `-y` for
this task" which is technically nonsense - that's the whole topic - period
so your are talking nosense all the time
-------- Weitergeleitete Nachricht
Betre
ouke wrote "_not_ -y in line". This is the
opposite case.
you pretended "But for convenience FFmpeg CLI provides option `-y` for
this task" which is technically nonsense - that's the whole topic - period
Weitergeleitete Nachricht --------
Betreff: Re: [FFmpeg-us
Am 18.08.24 um 00:46 schrieb Ulf Zibis:
Am 18.08.24 um 00:26 schrieb Reindl Harald:
Am 17.08.24 um 21:53 schrieb Ulf Zibis:
but there is no delete action
You can spin it however you like. The logic around the ‘-y’ option
requires an extra additional OS call, in this case querying the
exi
Ulf Zibis wrote:
> Am 18.08.24 um 00:26 schrieb Reindl Harald:
> > Am 17.08.24 um 22:33 schrieb Ulf Zibis:
> > >
> > > Am 17.08.24 um 22:10 schrieb Bouke / Videotoolshed:
> > > > ..., it will be ‘another’ file with the same name.
> > > And WHAT then happens with the original file, when write
Am 18.08.24 um 00:26 schrieb Reindl Harald:
Am 17.08.24 um 22:33 schrieb Ulf Zibis:
Am 17.08.24 um 22:10 schrieb Bouke / Videotoolshed:
..., it will be ‘another’ file with the same name.
And WHAT then happens with the original file, when write creates ANOTHER file
???
NOTHING
Another i
Am 18.08.24 um 00:30 schrieb Reindl Harald:
Am 17.08.24 um 23:07 schrieb Ulf Zibis:
Am 17.08.24 um 22:10 schrieb Bouke / Videotoolshed:
The user input is parsed as ‘if file exists and not -y in line, abort’
FFmpeg CLI does not abort in that case, it outputs a question to system out
strea
Am 18.08.24 um 00:26 schrieb Reindl Harald:
Am 17.08.24 um 21:53 schrieb Ulf Zibis:
but there is no delete action
You can spin it however you like. The logic around the ‘-y’ option requires an
extra additional OS call, in this case querying the existence of the file,
before it is overwritt
Am 17.08.24 um 23:07 schrieb Ulf Zibis:
Am 17.08.24 um 22:10 schrieb Bouke / Videotoolshed:
The user input is parsed as ‘if file exists and not -y in line, abort’
FFmpeg CLI does not abort in that case, it outputs a question to system
out stream, and then reads the input from system in stre
Am 17.08.24 um 22:33 schrieb Ulf Zibis:
Am 17.08.24 um 22:10 schrieb Bouke / Videotoolshed:
..., it will be ‘another’ file with the same name.
And WHAT then happens with the original file, when write creates ANOTHER
file ???
NOTHING
___
ffmpeg-us
Am 17.08.24 um 21:53 schrieb Ulf Zibis:
but there is no delete action
You can spin it however you like. The logic around the ‘-y’ option
requires an extra additional OS call, in this case querying the
existence of the file, before it is overwritten.
bullshit!
"ffmpeg -y" saves any OS call
Am 17.08.24 um 22:10 schrieb Bouke / Videotoolshed:
The user input is parsed as ‘if file exists and not -y in line, abort’
FFmpeg CLI does not abort in that case, it outputs a question to system out
stream, and then reads the input from system in stream. These are again 2
additional OS calls
> On 17 Aug 2024, at 22:33, Ulf Zibis wrote:
>
>
> Am 17.08.24 um 22:10 schrieb Bouke / Videotoolshed:
>> ..., it will be ‘another’ file with the same name.
> And WHAT then happens with the original file, when write creates ANOTHER file
> ???
Do not misquote me, and do not remove important p
Am 17.08.24 um 22:10 schrieb Bouke / Videotoolshed:
..., it will be ‘another’ file with the same name.
And WHAT then happens with the original file, when write creates ANOTHER file
???
The user input is parsed as ‘if file exists and not -y in line, abort’
Yes, and so we have 3 OS calls extra
>>>
>>> Which is exactly what I mean by "delete".
>>
>> but there is no delete action
> You can spin it however you like. The logic around the ‘-y’ option requires
> an extra additional OS call, in this case querying the existence of the file,
> before it is overwritten.
This is not ’spinnin
Am 16.08.24 um 11:46 schrieb Reindl Harald:
but you are not very smart
That's not a problem for me. It's enough for me to be smarter than you.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To un
Am 16.08.24 um 11:43 schrieb Reindl Harald:
Am 15.08.24 um 23:53 schrieb Ulf Zibis:
Am 15.08.24 um 23:39 schrieb Greg Oliver:
On Thu, Aug 15, 2024 at 12:02 PM Nicolas George wrote:
Ulf Zibis (12024-08-14):
But for convenience FFmpeg CLI provides option `-y` for this task
No, it does not
Am 16.08.24 um 11:43 schrieb Reindl Harald:
Am 15.08.24 um 23:53 schrieb Ulf Zibis:
Am 15.08.24 um 23:39 schrieb Greg Oliver:
On Thu, Aug 15, 2024 at 12:02 PM Nicolas George wrote:
Ulf Zibis (12024-08-14):
But for convenience FFmpeg CLI provides option `-y` for this task
No, it does no
Am 15.08.24 um 23:53 schrieb Ulf Zibis:
Am 15.08.24 um 23:39 schrieb Greg Oliver:
On Thu, Aug 15, 2024 at 12:02 PM Nicolas George wrote:
Ulf Zibis (12024-08-14):
But for convenience FFmpeg CLI provides option `-y` for this task
No, it does not. The -y option only disables a very simple, u
Ulf Zibis (12024-08-15):
> To me, "deleting/overwriting existing files" and "preserving file
> times from input to output" are *both* "OS / file system tasks".
To you is the key word. To somebody who understands how the OS works,
they are nothing alike. And explaining the details is not in topic f
Am 15.08.24 um 23:39 schrieb Greg Oliver:
On Thu, Aug 15, 2024 at 12:02 PM Nicolas George wrote:
Ulf Zibis (12024-08-14):
But for convenience FFmpeg CLI provides option `-y` for this task
No, it does not. The -y option only disables a very simple, unreliable
but convenient safety measure. It
On Thu, Aug 15, 2024 at 12:02 PM Nicolas George wrote:
>
> Ulf Zibis (12024-08-14):
> > But for convenience FFmpeg CLI provides option `-y` for this task
>
> No, it does not. The -y option only disables a very simple, unreliable
> but convenient safety measure. It does not delete anything.
It act
Ulf Zibis (12024-08-14):
> But for convenience FFmpeg CLI provides option `-y` for this task
No, it does not. The -y option only disables a very simple, unreliable
but convenient safety measure. It does not delete anything.
--
Nicolas George
___
ffmp
Am 15.08.24 um 18:17 schrieb Ulf Zibis:
Am 14.08.24 um 21:13 schrieb Greg Oliver:
In other words if the conversion command failed and you had it set to
delete to input file after conversion, with ; it will delete the file
even if the new file was not created, ...
Here it is not about delet
Am 14.08.24 um 21:13 schrieb Greg Oliver:
In other words if the conversion command failed and you had it set to
delete to input file after conversion, with ; it will delete the file
even if the new file was not created, ...
Here it is not about deleting the *input* file, it's about deleting t
On Wed, Aug 14, 2024 at 10:20 AM Ulf Zibis wrote:
>
>
> Am 12.08.24 um 19:04 schrieb Mark Filipak:
> >
> > That's a question for your operating system. I can change file times to
> > whatever I want via the TotalCommander file browser. There are probably
> > others.
>
> Isn't removing existing o
Am 12.08.24 um 19:04 schrieb Mark Filipak:
That's a question for your operating system. I can change file times to
whatever I want via the TotalCommander file browser. There are probably others.
Isn't removing existing output files samely a question for the OS ?
But for convenience FFmpeg
Ulf Zibis via ffmpeg-user wrote:
> is there an option how to preserve the file time from the input file to the
> outputfile?
> My search for "file time" on https://ffmpeg.org/ffmpeg-all.html was
> resultless.
Very simple: First run your FFmpeg command, and then:
touch -r
Of course, that
Am 12.08.24 um 23:05 schrieb Greg Oliver:
On Mon, Aug 12, 2024 at 6:06 AM Ulf Zibis via ffmpeg-user <
ffmpeg-user@ffmpeg.org> wrote:
Hi,
is there an option how to preserve the file time from the input file to
the outputfile?
My search for "file time" on https://ffmpeg.org/ffmpeg-all.html was
On Mon, Aug 12, 2024 at 6:06 AM Ulf Zibis via ffmpeg-user <
ffmpeg-user@ffmpeg.org> wrote:
> Hi,
>
> is there an option how to preserve the file time from the input file to
> the outputfile?
> My search for "file time" on https://ffmpeg.org/ffmpeg-all.html was
> resultless.
>
> -Ulf
>
DATE=$(sta
Am 12.08.24 um 19:37 schrieb Gia Ferrari:
On 8/12/24 3:57 AM, Ulf Zibis via ffmpeg-user wrote:
Hi,
is there an option how to preserve the file time from the input file to the outputfile?
My search for "file time" on https://ffmpeg.org/ffmpeg-all.html was
resultless.
-Ulf
> On 12 Aug 2024, at 19:37, Gia Ferrari wrote:
>
> On 8/12/24 3:57 AM, Ulf Zibis via ffmpeg-user wrote:
>
>> Hi,
>>
>> is there an option how to preserve the file time from the input file to the
>> outputfile?
>> My search for "file time" on https://ffmpeg.org/ffmpeg-all.html was
>> result
On 8/12/24 3:57 AM, Ulf Zibis via ffmpeg-user wrote:
> Hi,
>
> is there an option how to preserve the file time from the input file to the
> outputfile?
> My search for "file time" on https://ffmpeg.org/ffmpeg-all.html was
> resultless.
>
> -Ulf
>
On unix systems, the command "touch
On 12/08/2024 06.57, Ulf Zibis via ffmpeg-user wrote:
Hi,
is there an option how to preserve the file time from the input file to the
outputfile?
My search for "file time" on https://ffmpeg.org/ffmpeg-all.html was resultless.
-Ulf
That's a question for your operating system. I can change fil
57 matches
Mail list logo
