Alternative to Dynamic Text
Hi, Beside using textfile (reload=1) in drawtext for dynamic text, is there any other method to add dynamic texts onto the video stream?
Am 01.11.2021 um 16:21 schrieb LianCheng Tan:
Hi,
Beside using textfile (reload=1) in drawtext for dynamic text, is there any other method to add dynamic texts onto the video stream?
You could use subtitles. It's described in the wiki: https://trac.ffmpeg.org/wiki/WikiStart There are also some examples for subtitles in my book, see chapters 2.176 and 1.177: http://www.astro-electronic.de/FFmpeg_Book.pdf Michael
Am 01.11.2021 um 19:58 schrieb Michael Koch:
Am 01.11.2021 um 16:21 schrieb LianCheng Tan:
Hi,
Beside using textfile (reload=1) in drawtext for dynamic text, is there any other method to add dynamic texts onto the video stream?
You could use subtitles. It's described in the wiki: https://trac.ffmpeg.org/wiki/WikiStart
There are also some examples for subtitles in my book, see chapters 2.176 and 1.177: http://www.astro-electronic.de/FFmpeg_Book.pdf
sorry for the typo, I did mean 2.176 and 2.177 Michael
Thank you Michael. For subtitles, what if the content of .srt or .ass file is being updated at every second. Will ffmpeg crash because the file is being ‘locked’ by another process that is updating it?
On 2 Nov 2021, at 3:09 AM, Michael Koch <astroelectronic@t-online.de> wrote:
Am 01.11.2021 um 19:58 schrieb Michael Koch:
Am 01.11.2021 um 16:21 schrieb LianCheng Tan: Hi,
Beside using textfile (reload=1) in drawtext for dynamic text, is there any other method to add dynamic texts onto the video stream?
You could use subtitles. It's described in the wiki: https://trac.ffmpeg.org/wiki/WikiStart
There are also some examples for subtitles in my book, see chapters 2.176 and 1.177: http://www.astro-electronic.de/FFmpeg_Book.pdf
sorry for the typo, I did mean 2.176 and 2.177
Michael
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Am 02.11.2021 um 00:09 schrieb LianCheng Tan:
Thank you Michael.
For subtitles, what if the content of .srt or .ass file is being updated at every second. Will ffmpeg crash because the file is being ‘locked’ by another process that is updating it?
I don't know if this works. I thought the texts are known in advance and already written in the file. Michael
For subtitles, what if the content of .srt or .ass file is being updated at every second. Will ffmpeg crash because the file is being ‘locked’ by another process that is updating it?
If you're going to update it every second, how come textfile/reload=1 won't work? I put my textfile in /tmp which is a tmpfs filesystem so that it remains in memory the whole time (fast, no disk access) if you're worried about disk I/O. Cheers, Adam.
Hi Adam, textfile/reload=1 is working. However, the textfile is being updated by another process at every second. This caused ffmpeg to crash after running sometime as the ffmpeg unable to read the textfile when the other process is updating it.
On 3 Nov 2021, at 7:52 AM, Adam Nielsen via ffmpeg-user <ffmpeg-user@ffmpeg.org> wrote:
For subtitles, what if the content of .srt or .ass file is being updated at every second. Will ffmpeg crash because the file is being ‘locked’ by another process that is updating it?
If you're going to update it every second, how come textfile/reload=1 won't work?
I put my textfile in /tmp which is a tmpfs filesystem so that it remains in memory the whole time (fast, no disk access) if you're worried about disk I/O.
Cheers, Adam. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
textfile/reload=1 is working.
However, the textfile is being updated by another process at every second. This caused ffmpeg to crash after running sometime as the ffmpeg unable to read the textfile when the other process is updating it.
In the manpage it says the update has to be atomic, i.e. you should write your update to a different file, then move the new file over the top of the old one. That way ffmpeg will always see either the new content or the old, and nothing in between. Cheers, Adam.
I have tried to do what you have suggested. Somehow, it still cause ffmpeg to crash at the exact moment the file is being renamed. By the way, I am running in Windows environment. Not sure, if in Linux will this issue occurs.
On 3 Nov 2021, at 12:49 PM, Adam Nielsen <a.nielsen@shikadi.net> wrote:
textfile/reload=1 is working.
However, the textfile is being updated by another process at every second. This caused ffmpeg to crash after running sometime as the ffmpeg unable to read the textfile when the other process is updating it.
In the manpage it says the update has to be atomic, i.e. you should write your update to a different file, then move the new file over the top of the old one. That way ffmpeg will always see either the new content or the old, and nothing in between.
Cheers, Adam.
On Wed, Nov 3, 2021 at 12:57 PM LianCheng Tan <tanlccc@gmail.com> wrote:
I have tried to do what you have suggested. Somehow, it still cause ffmpeg to crash at the exact moment the file is being renamed.
By the way, I am running in Windows environment. Not sure, if in Linux will this issue occurs.
Top posting is not allowed here. What is exactly meaning about 'crash' ? Does it simply errors out or it dumps core?
On 3 Nov 2021, at 12:49 PM, Adam Nielsen <a.nielsen@shikadi.net> wrote:
textfile/reload=1 is working.
However, the textfile is being updated by another process at every second. This caused ffmpeg to crash after running sometime as the ffmpeg unable to read the textfile when the other process is updating it.
In the manpage it says the update has to be atomic, i.e. you should write your update to a different file, then move the new file over the top of the old one. That way ffmpeg will always see either the new content or the old, and nothing in between.
Cheers, Adam.
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Sorry, need to give more details. Due to drawtext that load textfile dynamically and when the textfile is inaccessible, the ffmpeg exited.
On 3 Nov 2021, at 9:11 PM, Paul B Mahol <onemda@gmail.com> wrote:
On Wed, Nov 3, 2021 at 12:57 PM LianCheng Tan <tanlccc@gmail.com> wrote:
I have tried to do what you have suggested. Somehow, it still cause ffmpeg to crash at the exact moment the file is being renamed.
By the way, I am running in Windows environment. Not sure, if in Linux will this issue occurs.
Top posting is not allowed here. What is exactly meaning about 'crash' ? Does it simply errors out or it dumps core?
On 3 Nov 2021, at 12:49 PM, Adam Nielsen <a.nielsen@shikadi.net> wrote:
textfile/reload=1 is working.
However, the textfile is being updated by another process at every second. This caused ffmpeg to crash after running sometime as the ffmpeg unable to read the textfile when the other process is updating it.
In the manpage it says the update has to be atomic, i.e. you should write your update to a different file, then move the new file over the top of the old one. That way ffmpeg will always see either the new content or the old, and nothing in between.
Cheers, Adam.
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
I have tried to do what you have suggested. Somehow, it still cause ffmpeg to crash at the exact moment the file is being renamed.
By the way, I am running in Windows environment. Not sure, if in Linux will this issue occurs.
It works fine for me but I'm on Linux. If renaming doesn't work, have you tried copying the new file over the top of the old one? I'm not familiar enough with Windows to know how to atomically overwrite a file. But I searched Google and found this: https://stackoverflow.com/questions/167414/is-an-atomic-file-rename-with-ove... It suggests there is a Windows API function called MoveFileTransacted() that you could use. I'm surprised just opening the file in read-write mode, seeking to the start, then writing your content doesn't work though. You might get a frame here or there with incomplete data but it won't cause ffmpeg to exit with an error. Cheers, Adam.
From: ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] On Behalf Of Adam Nielsen via ffmpeg-user Sent: 03 November 2021 15:10 To: LianCheng Tan Cc: Adam Nielsen; FFmpeg user questions Subject: Re: [FFmpeg-user] Alternative to Dynamic Text
I have tried to do what you have suggested. Somehow, it still cause ffmpeg to crash at the exact moment the file is being renamed.
By the way, I am running in Windows environment. Not sure, if in Linux will this issue occurs.
It works fine for me but I'm on Linux.
If renaming doesn't work, have you tried copying the new file over the top of the old one?
I'm not familiar enough with Windows to know how to atomically overwrite a file. But I searched Google and found this:
https://stackoverflow.com/questions/167414/is-an-atomic-file-rename- with-overwrite-possible-on-windows
It suggests there is a Windows API function called MoveFileTransacted() that you could use.
I'm surprised just opening the file in read-write mode, seeking to the start, then writing your content doesn't work though. You might get a frame here or there with incomplete data but it won't cause ffmpeg to exit with an error.
Possibly the original poster is opening the file with read-write mode also from within ffmpeg. That would be unnecessary, and could also explain "... ffmpeg unable to read the textfile when the other process is updating it."
Cheers, Adam. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Yes, would like to know in ffmpeg, under drawtext, the textfile (reload=1) is using read-write or read-only mode? On Thu, 4 Nov 2021 at 00:50, Francois Visagie <francois.visagie@gmail.com> wrote:
From: ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] On Behalf Of Adam Nielsen via ffmpeg-user Sent: 03 November 2021 15:10 To: LianCheng Tan Cc: Adam Nielsen; FFmpeg user questions Subject: Re: [FFmpeg-user] Alternative to Dynamic Text
I have tried to do what you have suggested. Somehow, it still cause ffmpeg to crash at the exact moment the file is being renamed.
By the way, I am running in Windows environment. Not sure, if in Linux will this issue occurs.
It works fine for me but I'm on Linux.
If renaming doesn't work, have you tried copying the new file over the top of the old one?
I'm not familiar enough with Windows to know how to atomically overwrite a file. But I searched Google and found this:
https://stackoverflow.com/questions/167414/is-an-atomic-file-rename- with-overwrite-possible-on-windows
It suggests there is a Windows API function called MoveFileTransacted() that you could use.
I'm surprised just opening the file in read-write mode, seeking to the start, then writing your content doesn't work though. You might get a frame here or there with incomplete data but it won't cause ffmpeg to exit with an error.
Possibly the original poster is opening the file with read-write mode also from within ffmpeg.
That would be unnecessary, and could also explain "... ffmpeg unable to read the textfile when the other process is updating it."
Cheers, Adam. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-request@ffmpeg.org
with subject "unsubscribe".
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
(I haven't had enough coffee yet and my remembrance of the nuances of mmap are sketchy) On 11/4/2021 5:14 AM, LianCheng wrote:
Yes, would like to know in ffmpeg, under drawtext, the textfile (reload=1) is using read-write or read-only mode?
From a quick read of the source code- libavfilter/vf_drawtext.c uses libavutil/file.c av_file_map(); that opens the file in with O_RDONLY (read only). If mmap exists (in the build of ffmpeg) that is used to map the file with PROT_READ|PROT_WRITE, which IIRC means that the memory map of the file may be back written to. Either way, changing the size of the underlying file would interfere with the memory map of it, and changing the size of a file can upset programs that aren't expecting it. In the end, drawtext in the ffmpeg executable doesn't appear to be the right tool for the job. z!
On Thu, 4 Nov 2021 20:14:16 +0800 LianCheng <tanlccc@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). 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
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
From what I read, the 'move' command under Windows is not atomic. It works by deleting the original file then renaming the new one, so if ffmpeg tries to read it between the delete and the rename, ffmpeg will abort with an error saying it can't find the file. The Win32 API function MoveFileTransacted() appears to be the only way to do it under Windows. I think probably the best solution is to change ffmpeg so that if the textfile parameter cannot read the file, it displays a blank or just uses the previous data. That way it no longer becomes critical to update the file atomically. Cheers, Adam.
On 2021-11-07 03:58 am, Anatoly wrote:
On Thu, 4 Nov 2021 20:14:16 +0800 LianCheng <tanlccc@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. Regards, Gyan
Hi Gyan, Will it be added in the next release of ffmpeg?
On 7 Nov 2021, at 1:08 PM, Gyan Doshi <ffmpeg@gyani.pro> wrote:
On 2021-11-07 03:58 am, Anatoly wrote: On Thu, 4 Nov 2021 20:14:16 +0800 LianCheng <tanlccc@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.
Regards, Gyan _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On 2021-11-07 12:06 pm, LianCheng Tan wrote:
Hi Gyan,
Will it be added in the next release of ffmpeg?
No guarantees but I'll aim for that. Regards, Gyan
On 7 Nov 2021, at 1:08 PM, Gyan Doshi <ffmpeg@gyani.pro> wrote:
On 2021-11-07 03:58 am, Anatoly wrote: On Thu, 4 Nov 2021 20:14:16 +0800 LianCheng <tanlccc@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.
Regards, Gyan _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
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@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. Regards, Marton
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@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
It is good to have some faults tolerance in software instead of exit abruptly :)
On 8 Nov 2021, at 6:44 PM, Gyan Doshi <ffmpeg@gyani.pro> 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@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 _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
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@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@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On 2021-11-09 03:15 am, Marton Balint wrote:
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:
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...
Not on FAT32. And since it's not guaranteed, the filter should accommodate that. Regards, Gyan
Gyan Doshi (12021-11-09):
Not on FAT32. And since it's not guaranteed, the filter should accommodate that.
What are you talking about? The filter does not write the file, it just reads it. It is the responsibility of whoever writes the file to ensure that the writing does not overlap with the reading. Regards, -- Nicolas George
On 2021-11-09 04:31 pm, Nicolas George wrote:
Not on FAT32. And since it's not guaranteed, the filter should accommodate that. What are you talking about? The filter does not write the file, it just reads it. It is the responsibility of whoever writes the file to ensure
Gyan Doshi (12021-11-09): that the writing does not overlap with the reading.
I'm talking about the fact that on FAT32 volumes, atomic replacement is not possible, so the writer/user can't ensure that. Even on NTFS, the user may not be replacing the file via win32 API calls of their choosing. And the filter tolerates no failures; the OP is experiencing premature ffmpeg termination. It shouldn't be that fragile. Regards, Gyan
On 11/9/2021 3:01 AM, Nicolas George wrote:
It is the responsibility of whoever writes the file to ensure that the writing does not overlap with the reading.
Never heard that one, usually it's the reverse unless _both_ have some form of mutex/file-lock implemented. Given than it's not likely that either program expects a need to cooperate with another, the best you can do is make the reader less sensitive to the errors. Later, z!
Anyone know when the file tolerance handling in filter will be fixed?
On 10 Nov 2021, at 12:43 AM, Carl Zwanzig <cpz@tuunq.com> wrote:
On 11/9/2021 3:01 AM, Nicolas George wrote:
It is the responsibility of whoever writes the file to ensure that the writing does not overlap with the reading.
Never heard that one, usually it's the reverse unless _both_ have some form of mutex/file-lock implemented. Given than it's not likely that either program expects a need to cooperate with another, the best you can do is make the reader less sensitive to the errors.
Later,
z! _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
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.
I like this idea. I'm using it on a Raspberry Pi 1 to write the time and camera name in a status bar at the bottom of the video, and the Pi is pegged at 100% CPU usage even using hardware encoding. So anything that lowers the CPU usage is welcome. If you will only reload the file every few frames, I wonder whether you could cache the output image rather than just the text? This way the font rendering would only happen every few frames as well (only when the text actually changes), further lowering CPU usage. If this option to re-use previously rendered text could also apply to placeholders (like text=%{localtime}) that would also help lower the CPU usage. Cheers, Adam.
participants (11)
-
Adam Nielsen -
Anatoly -
Carl Zwanzig -
Francois Visagie -
Gyan Doshi -
LianCheng -
LianCheng Tan
-
Marton Balint -
Michael Koch -
Nicolas George -
Paul B Mahol