[FFmpeg-devel] [PATCH] NVENC Surface Allocation Reduction

Philip Langdale philipl at overt.org
Tue May 9 05:59:33 EEST 2017


On Thu, 27 Apr 2017 01:12:55 +0200
Timo Rothenpieler <timo at rothenpieler.org> wrote:

> > This seems to be a regression introduced when filtergraph
> > initialization related changes were passed. The below commit and
> > its follow up seems to have caused the issue. I am looking to fix
> > this. Please let us know if you have any suggestions in mind.
> > Thanks
> > https://github.com/FFmpeg/FFmpeg/commit/af1761f7b5b1b72197dc40934953b775c2d951cc  
> 
> Yes, this initially started happening with that.
> What it does for nvenc/cuvid is basically that it swapped around
> their order of initialization. Now cuvid is initialized first, and
> nvenc is not fired up until cuvid returns the first frame.
> Before, nvenc was initialized first.
> 
> Initially, this completely broke cuvid->nvenc, but that was fixed
> with:
> https://github.com/FFmpeg/FFmpeg/commit/be74ba648cf4063c9805ebe95ee83fd7299f7fd5
> Kinda making me wonder why/how it ever worked in the first place.
> 
> Now only that weird max_b_frames > 0 behavior is left, but only when 
> doing direct hwaccel transcoding from cuvid to nvenc.
> Dropping -hwaccel cuvid, so sending frames back and forth through
> system memory, fixes it.
> 
> Using -vf hwupload_cuda works just fine with bframes as well, so it 
> can't really be an issue with the PIXFMT_CUDA frame handling code in 
> nvenc, as that would blow up then as well.

To continue on this point, with the release of the new video sdk 8.0,
you guys (nvidia) have an example command line that uses "-bf 2" and it
does not work for me or Timo.

Specifically the following:

ffmpeg -y -vsync 0 -hwaccel cuvid -c:v h264_cuvid -i input.mp4 -c:a \
copy -c:v h264_nvenc -preset slow -profile high -b:v 5M -bufsize 5M \
-maxrate 10M -qmin 0 -g 250 -bf 2 -temporal-aq 1 -rc-lookahead 20 \
-i_qfactor 0.75 -b_qfactor 1.1 output.mp4

This returns an error until b-frames are set to zero.

If this works for you internally, we'd love to understand why, and if
it doesn't, then you have the repro case you need :-) Perhaps it's
fixed in some newer driver version you're working with which isn't
public yet.

--phil


More information about the ffmpeg-devel mailing list