Video stuttering when inserting IDR frames


I took AppEncD3D11 example from Video Coder SDK and integrated it into my app.
I’m using it to constantly capture screen video. However, I need to store only N last seconds of the video. Once encoded frames count gets too big, I erase some amount of old frames (simple FIFO - I store encoded frames in a cicrular buffer).

As far as I understood, to make correct video, later frames should have correct reference frames. So for that I decided to insert IDR frame every second. And it made the job for me - now the video is always successfully decoded.

But now I have other issue: the video started stuttering. I tried using GOP instead of manually inserting IDRs, but I’ve got exactly same issue.

I wrote code, which generated 300 frames from different shades of red (based on frame index), and encoded 30 FPS video from these frames using original AppEncD3D11 example code. It worked fine and I’ve got what is expected (check file without_idr.h264).

But this does not solve my task. So then I encoded 2 additional videos with only next code modifications:

  1. File every_30th_idr.h264 - every 30-th frame is made IDR (through line “picParams.encodePicFlags = NV_ENC_PIC_FLAG_FORCEIDR | NV_ENC_PIC_FLAG_OUTPUT_SPSPPS”). From the video sample you can see, that the frames in video started changing not smoothly.
  2. File every_frame_idr.h264 - every frame is made IDR. In this sample frames change smoothly, but video became a lot faster than it should.

From both samples it feels like there are lost frames in the sequence. However, both samples contain the same amount of frames and generated from the same input.
Could someone please help me understand why simply inserting IDR frames influence correctness of the video, and how can I fix it?

without_idr.h264 -
every_30th_idr.h264 -
every_frame_idr.h264 -

I just checked my own post to be sure the videos are uploaded correctly.
And for some reason they are working fine. Previously I checked them using VLC player. For through Google Drive they are looking absolutelly correct.
Looks like the issue was not in the code, but in the testing…