drawtext reload=N > 1?
I am overlaying real-time weather on streaming video: https://www.youtube.com/channel/UCIVY11504PcY2sy2qpRhiMg/live I have a script reading from openweather.org every 10 minutes and writing to weather.txt*, and then drawtext reads weather.txt and applies it via: ./ffmpeg -thread_queue_size 2048 -hwaccel videotoolbox -i 'rtsp://anonymous:password1@192.168.1.13:554' -hwaccel videotoolbox -i 'rtsp://anonymous:password1@192.168.1.45:554' -vcodec h264_videotoolbox -b:v 5000k -acodec copy -t 2:00:00 -filter_complex "hstack=inputs=2,fps=20[stacked];[stacked]drawtext='fontfile=/System/Library/Fonts/Helvetica.ttc: textfile=/tmp/weather.txt: fontcolor=white: fontsize=48: x=(w-text_w)*0.01: y=(h-text_h)*0.01:reload=600'" -f flv "rtmp://a.rtmp.youtube.com/live2/<my-youtube-streaming-key>” It’s working, but it seems very inefficient to read weather.txt every 1 frame when it gets updated only every 12,000 frames. According to the documentation, reload is a Boolean to read every frame or not, and attempting reload=2 or reload=600 results in: [drawtext @ 0x7fa696010600] Unable to parse option value "2" as boolean Would it be worthy feature request to allow drawtext to accept integer values N > 1, and then reload the text file every Nth frame? It seems like a win for CPU and I/O loading, with the benefit of being fully backward compatible with existing scripts that read in every 1 frame (e.g. reload=1). Or are there downsides to this that I’m not seeing? * and yes, I’m writing to weather.tmp and cping to weather.txt to prevent a file I/O collision.
Would it be worthy feature request to allow drawtext to accept integer values N > 1, and then reload the text file every Nth frame? It seems like a win for CPU and I/O loading, with the benefit of being fully backward compatible with existing scripts that read in every 1 frame (e.g. reload=1).
Or are there downsides to this that I’m not seeing?
I thought about something similar as I'm also overlaying infrequently changed data (temperature) onto video. However I ended up putting the file on a tmpfs partition so there's no actual disk IO, the whole thing sits in memory anyway. Have you tried benchmarking to see how much benefit you'd get from this optimisation? You could check CPU usage and I/O load with reload=1 and again with reload=0 and see what the difference is. Let us know what you find, as I haven't actually tried this myself so it would be interesting to know what the impact is of reading the file on every frame.
* and yes, I’m writing to weather.tmp and cping to weather.txt to prevent a file I/O collision.
Do you mean "mv" instead of "cp"? I don't think "cp" is atomic but "mv" is. Using "cp" won't break anything but you might get a frame here or there with incomplete data. Cheers, Adam.
On Feb 27, 2022, at 10:49 PM, Adam Nielsen via ffmpeg-user <ffmpeg-user@ffmpeg.org> wrote:
Would it be worthy feature request to allow drawtext to accept integer values N > 1, and then reload the text file every Nth frame? It seems like a win for CPU and I/O loading, with the benefit of being fully backward compatible with existing scripts that read in every 1 frame (e.g. reload=1).
Or are there downsides to this that I’m not seeing?
I thought about something similar as I'm also overlaying infrequently changed data (temperature) onto video.
However I ended up putting the file on a tmpfs partition so there's no actual disk IO, the whole thing sits in memory anyway.
Have you tried benchmarking to see how much benefit you'd get from this optimisation? You could check CPU usage and I/O load with reload=1 and again with reload=0 and see what the difference is. Let us know what you find, as I haven't actually tried this myself so it would be interesting to know what the impact is of reading the file on every frame.
* and yes, I’m writing to weather.tmp and cping to weather.txt to prevent a file I/O collision.
Do you mean "mv" instead of "cp"? I don't think "cp" is atomic but "mv" is. Using "cp" won't break anything but you might get a frame here or there with incomplete data.
Thanks for the tip about mv vs cp. I originally had mv, per the documentation, but then I changed it to cp during troubleshooting because I couldn’t figure out why my temp file kept disappearing, LOL. I’ve changed it back to mv. Regarding I/O load, I know it’s probably negligible, but it just offends my sensibilities to read something 11,999 times for no reason. And if this feature gets implemented (thank you, Gyan!!!) then I won’t have to worry about where I put the tmp file.
Have you tried benchmarking to see how much benefit you'd get from this optimisation? You could check CPU usage and I/O load with reload=1 and again with reload=0 and see what the difference is.
Regarding I/O load, I know it’s probably negligible, but it just offends my sensibilities to read something 11,999 times for no reason. And if this feature gets implemented (thank you, Gyan!!!) then I won’t have to worry about where I put the tmp file.
That's probably the best reason for something like this where it's "just better" even if there is no tangible benefit :) However what bothers me more than a little I/O is all the CPU calculations required to load and parse the font file, interpret the arcs and lines in the font, calculate the shape of each character, draw it all in and antialias the lines to give smooth characters, and do all *that* repeatedly on every single frame even if the text hasn't changed. I guess in some ways if efficiency is what you're after, it would be better to render the whole thing to a raw image file as needed, and then just copy those pixels across as-is on every frame. It's actually something I have been meaning to look in to, because I wouldn't mind being able to overlay an icon or two onto the video as well as just text. Cheers, Adam.
On 2022-02-28 10:37 am, Steven Kan wrote:
I am overlaying real-time weather on streaming video:
https://www.youtube.com/channel/UCIVY11504PcY2sy2qpRhiMg/live
I have a script reading from openweather.org every 10 minutes and writing to weather.txt*, and then drawtext reads weather.txt and applies it via:
./ffmpeg -thread_queue_size 2048 -hwaccel videotoolbox -i 'rtsp://anonymous:password1@192.168.1.13:554' -hwaccel videotoolbox -i 'rtsp://anonymous:password1@192.168.1.45:554' -vcodec h264_videotoolbox -b:v 5000k -acodec copy -t 2:00:00 -filter_complex "hstack=inputs=2,fps=20[stacked];[stacked]drawtext='fontfile=/System/Library/Fonts/Helvetica.ttc: textfile=/tmp/weather.txt: fontcolor=white: fontsize=48: x=(w-text_w)*0.01: y=(h-text_h)*0.01:reload=600'" -f flv "rtmp://a.rtmp.youtube.com/live2/<my-youtube-streaming-key>”
It’s working, but it seems very inefficient to read weather.txt every 1 frame when it gets updated only every 12,000 frames.
According to the documentation, reload is a Boolean to read every frame or not, and attempting reload=2 or reload=600 results in:
[drawtext @ 0x7fa696010600] Unable to parse option value "2" as boolean
Would it be worthy feature request to allow drawtext to accept integer values N > 1, and then reload the text file every Nth frame? It seems like a win for CPU and I/O loading, with the benefit of being fully backward compatible with existing scripts that read in every 1 frame (e.g. reload=1).
This has come up before. I'll patch it to make it an interval. Regards, Gyan
Gyan Doshi (12022-02-28):
This has come up before. I'll patch it to make it an interval.
I do not think it is worth your effort: the cost of loading the file is negligible compared to the rest of the operations. Regards, -- Nicolas George
On 2/28/2022 2:12 AM, Nicolas George wrote:
I do not think it is worth your effort: the cost of loading the file is negligible compared to the rest of the operations.
Maybe yes, maybe no; depends on the system and OS. It's still unnecessary file system overhead that could be avoided. z!
On 2022-02-28 12:28 pm, Gyan Doshi wrote:
On 2022-02-28 10:37 am, Steven Kan wrote:
I am overlaying real-time weather on streaming video:
https://www.youtube.com/channel/UCIVY11504PcY2sy2qpRhiMg/live
I have a script reading from openweather.org every 10 minutes and writing to weather.txt*, and then drawtext reads weather.txt and applies it via:
./ffmpeg -thread_queue_size 2048 -hwaccel videotoolbox -i 'rtsp://anonymous:password1@192.168.1.13:554' -hwaccel videotoolbox -i 'rtsp://anonymous:password1@192.168.1.45:554' -vcodec h264_videotoolbox -b:v 5000k -acodec copy -t 2:00:00 -filter_complex "hstack=inputs=2,fps=20[stacked];[stacked]drawtext='fontfile=/System/Library/Fonts/Helvetica.ttc: textfile=/tmp/weather.txt: fontcolor=white: fontsize=48: x=(w-text_w)*0.01: y=(h-text_h)*0.01:reload=600'" -f flv "rtmp://a.rtmp.youtube.com/live2/<my-youtube-streaming-key>”
It’s working, but it seems very inefficient to read weather.txt every 1 frame when it gets updated only every 12,000 frames.
According to the documentation, reload is a Boolean to read every frame or not, and attempting reload=2 or reload=600 results in:
[drawtext @ 0x7fa696010600] Unable to parse option value "2" as boolean
Would it be worthy feature request to allow drawtext to accept integer values N > 1, and then reload the text file every Nth frame? It seems like a win for CPU and I/O loading, with the benefit of being fully backward compatible with existing scripts that read in every 1 frame (e.g. reload=1).
This has come up before. I'll patch it to make it an interval.
Patched in git master. Regards, Gyan
On Mar 1, 2022, at 11:29 PM, Gyan Doshi <ffmpeg@gyani.pro> wrote:
On 2022-02-28 12:28 pm, Gyan Doshi wrote:
On 2022-02-28 10:37 am, Steven Kan wrote:
I am overlaying real-time weather on streaming video:
https://www.youtube.com/channel/UCIVY11504PcY2sy2qpRhiMg/live
I have a script reading from openweather.org every 10 minutes and writing to weather.txt*, and then drawtext reads weather.txt and applies it via:
./ffmpeg -thread_queue_size 2048 -hwaccel videotoolbox -i 'rtsp://anonymous:password1@192.168.1.13:554' -hwaccel videotoolbox -i 'rtsp://anonymous:password1@192.168.1.45:554' -vcodec h264_videotoolbox -b:v 5000k -acodec copy -t 2:00:00 -filter_complex "hstack=inputs=2,fps=20[stacked];[stacked]drawtext='fontfile=/System/Library/Fonts/Helvetica.ttc: textfile=/tmp/weather.txt: fontcolor=white: fontsize=48: x=(w-text_w)*0.01: y=(h-text_h)*0.01:reload=600'" -f flv "rtmp://a.rtmp.youtube.com/live2/<my-youtube-streaming-key>”
It’s working, but it seems very inefficient to read weather.txt every 1 frame when it gets updated only every 12,000 frames.
According to the documentation, reload is a Boolean to read every frame or not, and attempting reload=2 or reload=600 results in:
[drawtext @ 0x7fa696010600] Unable to parse option value "2" as boolean
Would it be worthy feature request to allow drawtext to accept integer values N > 1, and then reload the text file every Nth frame? It seems like a win for CPU and I/O loading, with the benefit of being fully backward compatible with existing scripts that read in every 1 frame (e.g. reload=1).
This has come up before. I'll patch it to make it an interval.
Patched in git master.
Wow! That was a very elegant, efficient patch! One line of code, other than the modified variable declaration: if (s->reload) { if (s->reload && !(inlink->frame_count_out % s->reload)) {
participants (5)
-
Adam Nielsen -
Carl Zwanzig -
Gyan Doshi -
Nicolas George -
Steven Kan