[FFmpeg-user] Alternative to Dynamic Text

[Gyan Doshi]

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 <tanlccc at gmail.com> 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