I just checked the CPU frequency with lscpu and indeed when running my code with the additional sleep, the clock stays at 800 MHz whereas without sleeps it bursts up to 4.7 GHz. I disabled the clock stepdown and now the code runs with constant runtime regardless of an additional sleep.
So, you guys were perfectly right!! Thanks a lot for the hint. This saved me from dumping this project as a dead end. My actual application does not use a sleep of course, but instead captures multiple streams within different threads which wait on a condition variable. But the problem and solution are the same. Best Regards, Lukas On 3/6/19 2:59 PM, Omar Álvarez wrote:
It is probably related to how turbo boost works. You need to tune your OS for CPU latency (governor performance on Debian/Ubuntu), it has to do with the delay changing between low power states and performance states. When you sleep continuously, you cannot reach peak CPU clock speed. When you don't use the sleep, you are using peak clock speed all the time. Cheers, Omar. El sáb., 1 jun. 2019 a las 19:33, Paul Sanderson (<[email protected] <mailto:[email protected]>>) escribió: I think Carl’s point is interesting. It could be something funky with sleep which if I remember right is a Linux/ Debian based call. Maybe try a different method of making your program hang and see if the problem persists. All my best, Paul Sent from the top a castle using a moderately sized European swallow On 1 Jun 2019, at 16:17, Lukas Bommes <[email protected] <mailto:[email protected]>> wrote:I'm just buffled because OpenCV uses the same code (in fact I copied the retrieveFrame funtion from the videoio module 1:1) and it does not show this weird behaviour. There, the runtime of sws_scale is constant regardless of the calling frequency and retrieving one frame takes always around 1.3 ms. However, my OpenCV build (version 4.1) uses FFMPEG 3.4.6, not 4.1. So, I'm gonna try building my code with FFMPEG 3.4.6 and see if the problem persists. Alternatively, I add a function to the OpenCV videoio module which retrieves frame + motion vectors. However, altering the OpenCV API brings a lot of other challenges. But maybe someone else has noticed a similar issue with sws_scale in FFMPEG 4.1 before. Lukas On 1 Jun 2019 7:04 pm, Carl Eugen Hoyos <[email protected] <mailto:[email protected]>> wrote: Am Do., 30. Mai 2019 um 11:59 Uhr schrieb lukas <[email protected] <mailto:[email protected]>>: > I wrote a program which extracts motion vectors from a video stream and > encountered the problem that the runtime of sws_scale changes depending > on whether I put a sleep command in the main loop of the caller. Shouldn't you ask this your CPU provider? Carl Eugen _______________________________________________ Libav-user mailing list [email protected] <mailto:[email protected]> https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email [email protected] <mailto:[email protected]> with subject "unsubscribe". _______________________________________________ Libav-user mailing list [email protected] <mailto:[email protected]> https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email [email protected] <mailto:[email protected]> with subject "unsubscribe"._______________________________________________ Libav-user mailing list [email protected] <mailto:[email protected]> https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email [email protected] <mailto:[email protected]> with subject "unsubscribe". _______________________________________________ Libav-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
_______________________________________________ Libav-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
