On Mon, 8 Nov 2021, Gyan Doshi wrote:
On 2021-11-07 02:56 pm, Marton Balint wrote:
On Sun, 7 Nov 2021, Gyan Doshi wrote:
On 2021-11-07 03:58 am, Anatoly wrote:
On Thu, 4 Nov 2021 20:14:16 +0800
LianCheng <[email protected]> wrote:
Yes, would like to know in ffmpeg, under drawtext, the textfile
(reload=1) is using read-write or read-only mode?
I think "procmon.exe" from Microsoft
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
can help you to find the answer (and maybe somehow "debug" the
situation).
FFmpeg opens the file with O_RDONLY mode.
Btw, I think following approach may help (or may not, I have no windows
system by hand to test it myself). Let's say I want to atomically
replace file a.txt with file b.txt
mklink /h wrk.txt a.txt
open wrk.txt with ffmpeg
update b.txt as needed
mklink /h next.txt b.txt
move /y next.txt wrk.txt
now update a.txt as needed or may delete a, b and create new b.
hardlink again and move again
and so on in loop
This can work until it doesn't. The filter doesn't tolerate any load
failures.
I'll see if I can add a short sleep and retry. If it still fails, we
continue with the old text.
I am not a fan of this to be honest. There is a proper way to do atomic
renames even in windows, see the referenced stackoverflow articles, so it
should just work.
The comments at SO by Craig Barkhouse ('NTFS developer at Microsoft') says
that "ReplaceFile is most definitely NOT atomic." and that, forMoveFileEx,
atomicity is not guaranteed, depending on the underlying fs ops the call
leads to. So, I think some fault tolerance on our part is called for.
But later on he also says that MoveFileEx with MOVEFILE_REPLACE_EXISTING
flag is atomic 99.999999% of the time with the only exception of the
target file being huge...
Regards,
Marton
Instead of a sleep and retry, we can simply continue with existing text and
try again on next frame. We can also extend the semantics of the option (in a
backward-compatible way) to specify the frame interval at which the file is
reloaded.
Regards,
Gyan
_______________________________________________
ffmpeg-user mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".