On Wed, 2018-07-25 at 15:29 +0200, Maxym Dmytrychenko wrote: thanks for the patch. any performance impact you see, depth == 1 and higher ?
our tests shows some drop when async_depth == 1. You indeed can notice some FPS drop on async=~1. This is due to the fact that ffmpeg tried to work on async+1 and it succeeded to some extent. What ffmpeg did was a polling loop on data submission (instead of a sleep on SyncOperation) which means that it gained some time and pushed data more instantly on the appearance of the empty slot. Since the patch removes this instant pushing you see some performance drops which I would actually consider as alignments to the use cases: if user wants synchronous pipeline (async=1) - that's for the reason, like in video conferencing. Well, returning to the performance story. So, there were some gains in async+1 approach. However, there were few important drawbacks on which we need to pay attention: 1. Such polling loop comes with the excessive CPU%. You can notice it if you will consider multiple parallel transcoding, like here: # cat ./run.sh for i in `seq 1 8`; do ffmpeg -y -hwaccel qsv -c:v h264_qsv -i JM_BQTerrace_1920x1080_60_22.h264 \ -c:v h264_qsv -preset medium -profile:v high -level:v 51 -g 50 -bf 3 -async_depth 1 -b:v 16M -minrate 16M -maxrate 16M qsv_$i.264 & done I for example have on 8-cores system (/usr/bin/time -f "%e;%U;%S;%P" ./run.sh): 17.62;10.64;3.22;78% # before the patch 17.87;9.44;2.57;67% # after the patch And the impact will grow with the decrease of the resolution. 2. Another drawback which I am not sure how to measure on ffmpeg is latency impact. Which is that the polling loop on async+1 was not an ultimate polling, instead you had usleep. Thus, you actually impacted latency of the output frames flow since you introduced unpredicatable sleep up to your sleep interval. After the change fluctuations in latency should go away. So, I encourage to embrace this change and understand that there are some changes in performance associated with it which aligns the behavior with the expected usage models. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
