We are currently experiencing a very strange issue when capturing to H.264 using QSV. Over time, the CPU usage increases till it reaches a point where we cannot be real-time anymore and start dropping frames (after 1 to 2 hours of capture).
- We do 4 capture at the same time. The issue also is present with one capture, but it is less significant since the CPU usage is a multiple of the number of captures.
- We convert YUY2 to NV12 then do the encoding to H264.
- We use the de-interlacer
- We are capturing 1080i (25 or 29.97 fps) streams.
- We are using windows 7 and an external GPU. We can reproduce the issue whether the Intel GPU is the main display or not.
We backtracked the driver versions and tested on the HD4000 and HD4600. Here are the results:
- We can reproduce this issue on the HD4600 with the following drivers: 184.108.40.206.3621, 220.127.116.1152 (beta), 18.104.22.168.3907
- We cannot reproduce the issue on the HD4600 with the following drivers: 22.214.171.124.3496
- We cannot reproduce the issue on the HD4000 with the following drivers: 126.96.36.199.3621
I'm attaching some screenshots I took with ProcessExplorer in Windows. The first after 1 minute of capture and another one after several hours... Also I'm attaching the graph of the CPU usage. We can see in these screenshots that 4 threads are increasing their CPU usage over time (I only attached two screenshots, but these 4 threads are responsible of the overall CPU usage increase. They slowly use more and more CPU power).
We'd appreciate some feedback and a fix for this issue as it is a blocker for us. Have you ever seen this, are you aware of it? Is there anything we can do to fix it on our end?
I just noticed I attached screenshots from different captures... It is still valid to prove my point, the only difference is that the thread IDs are not consistent in the first and second screenshot. If it was from the same capture the thread IDs with the call stack VPP_Stat_...would be the same.
I've been able to reproduce the issue using the sample code (Video Encoding Sample 5.0.461.91752) too on the HD4600 with the latest drivers. I modified the sample code to accept YV12 as the input format and feed NV12 buffers to the encoder to make sure VPP is involved. Without VPP involved I wasn't able to reproduce the issue (with NV12 as the input format). I also modified the code to go back to the beginning of the input file when it reaches the end to have a never ending transcoding without needing a very big uncompressed file as the input.
I'm attaching some screenshots taken with ProcessExplorer. In the screenshots we can see the CPU usage increase over time (and it is caused by one thread slowly increasing its CPU usage). At some point it reaches a plateau and then it starts to affect the GPU usage and IO throughput (i.e. the frames are encoded at a a reduced rate).
This looks like a serious issue to me. I'd appreciate some feedback.