[FFmpeg-user] Alternative to Dynamic Text

[Marton Balint]

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

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
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>
>