[FFmpeg-trac] #8396(undetermined:new): hwdownload always use 0th device (hwaccel_device 0)
FFmpeg
trac at avcodec.org
Mon Nov 25 01:19:13 EET 2019
#8396: hwdownload always use 0th device (hwaccel_device 0)
-------------------------------------+-------------------------------------
Reporter: darn | Owner:
Type: defect | Status: new
Priority: normal | Component:
| undetermined
Version: unspecified | Resolution:
Keywords: nvenc | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by darn):
Replying to [comment:2 oromit]:
> hwdownload copies frames _from_ the device, and thus uses the context of
the frames it gets as input. The outcoming frames are in system RAM and
not tied to any device.
Yes.
hwdownload -- copy from GPU memory to system memory.
hwupload -- copy from system memory to GPU memory.
Is it correct?
> The second CUDA context on the default device (0) you are seeing is
nvenc getting fed non-CUDA frames, which triggers it to create its own
CUDA context to re-uploads the frames on.
> nvenc has its own option (-gpu) controlling on which device it creates
that context.
I tried to use "-gpu 2" setting, the result is the same.
> But really, why even download in the first place, just for nvenc to re-
upload immediately?
As far as I understand my configuration on filter_complex
{{{
-filter_complex
"[0:v]scale_npp=-1:-1:format=yuv420p:interp_algo=lanczos,hwdownload,format=yuv420p[v0]"
}}}
works as follows:
1. Input stream "[0:v]" copying to GPU memory;
2. GPU "scale_npp" input stream to "-1:-1" with
"format=yuv420p:interp_algo=lanczos";
3. GPU "hwdownload" with "format=yuv420p" from GPU memory to system memory
with name [v0].
Is it correct?
--
Ticket URL: <https://trac.ffmpeg.org/ticket/8396#comment:3>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list