[FFmpeg-trac] #7562(undetermined:new): using -hwaccel nvdec produces 'No decoder surfaces left' with interlaced input and 3 or more b-frames

[FFmpeg]

#7562: using -hwaccel nvdec produces 'No decoder surfaces left' with interlaced
input and 3 or more b-frames
-------------------------------------+-------------------------------------
             Reporter:  malakudi     |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  git-master   |               Resolution:
             Keywords:  nvdec        |               Blocked By:
  regression                         |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by oviano):

 I've encountered this too under similar circumstances using the C API, but
 also with FFmpeg. In my case I had b frames and rc-lookahead in the
 encoder.

 Since rc-lookahead in NVENC has a maximum of 32, and since that is the
 maximum number of decoder surfaces supported in NVDEC, it would seem
 logically impossible to do a a straight forward NVDEC -> NVENC transcode
 with rc-lookahead of 32.

 This would not be solved by extra_hw_frames because 32 is the limit and
 NVDEC bails out if you try and add more.

 The solution is hinted at by the fact if you include a scale_cuda or
 yadif_cuda then the issue goes away. I believe this is because these
 filters create their own hw_frames_ctx and generate frames from this as
 needed. This means the decoder surface is freed right away and the encoder
 just consumes the filter output frames as many as it likes.

 I haven't tried, but it might be that cuda_scale specifying no change in
 width or height would also solve the problem. It shouldn't do, because if
 width/height is not supposed to change it should just pass the surface
 through but looking at vf_cuda_scale.c there is a passthrough variable
 defined, and set...but not used.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/7562#comment:5>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker