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.
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".
