nvenc memory management model undocumented

Greetings,

I want to integrate nvenc in my software, using input frames allocated on the device with CUDA.

I’m running Linux so I’m using the synchronous mode.

As far as I can tell, there is no documention on when it’s safe to free the input frames. The only thing I found is

“The NvEncodeAPI interface will need to keep a copy of the input buffers for re-ordering and it allocates following internal buffers (NvI1, NvI2…). These internal buffers are managed by NvEncodeAPI and the client is not responsible for the allocating or freeing the memory of the internal buffers.”

That doesn’t tell me when those copies are done!

So: when I call NvEncEncodePicture(), is it safe to free the input frame immediately? If not, when is it safe?

It looks like nvidia isn’t interested in answering questions about their hardware. I post the results of my experiments for anyone else who has the same question.

For input frames allocated using system memory: it looks OK to free the input frame immediately or reuse it for the next buffer. This was tested with 3 B frames, so there is reordering going on under the hood.

For input frames allocated with CUDA on the device: it looks OK to unmap/unregister the input frame immediately after encoding, regardless of what the doc says about waiting for a successful NvEncLockBitstream().

Other issues:

  • nvcc generates warnings for nvEncodeAPI.h.
  • Valgrind complains about conditional jumps on uninitialized memory, caused by the nvenc lib.
  • 10-25% of the API is deprecated without being marked as such. Don’t trust the doc/comments. See what NvHWEncoder.cpp actually does.
  • Don’t count on the HQ preset to actually be HQ. You need to set frameIntervalP to get B frames.
1 Like