On Wed, Nov 20, 2019 at 12:48 PM Timo Rothenpieler
wrote:
>
> On 20/11/2019 11:29, Oleg Dobkin wrote:
> > On Tue, 2019-11-19 at 23:58 +0100, Timo Rothenpieler wrote:
> >> Only thing I'm still wondering is if it would make sense to use the
> >> primary context by
On Tue, 2019-11-19 at 23:58 +0100, Timo Rothenpieler wrote:
> Only thing I'm still wondering is if it would make sense to use the
> primary context by default.
> I can't think of any obvious downsides, other than weakened
> isolation,
> which really shouldn't be a huge concern.
> And there appare
Any more comments?
On Mon, 2019-11-18 at 15:39 +0200, Oleg Dobkin wrote:
> Updated
>
> On Mon, 2019-11-18 at 13:51 +0100, Timo Rothenpieler wrote:
>
> On 18/11/2019 12:25, Oleg Dobkin wrote:
>
> FFmpeg supports multiple tracks of the Video Codec SDK, to support
> ol
Updated
On Mon, 2019-11-18 at 13:51 +0100, Timo Rothenpieler wrote:
> On 18/11/2019 12:25, Oleg Dobkin wrote:
>
> FFmpeg supports multiple tracks of the Video Codec SDK, to support
> older
> drivers and legacy GPUs that way.
> Since the version number only tracks the Video SD
device context. Currently, the context is not accessible from
FFmpeg API, so, technically, the memory created by the hardware decoder
(the video frame) can't be safely read.
Signed-off-by: Oleg Dobkin
---
configure | 8
libavutil/hwcontext_cuda.c
ck that needs to be
performed, regardless of the supported Video SDK versions, isn't it?
On Mon, 2019-11-18 at 12:09 +0100, Timo Rothenpieler wrote:
> On 18/11/2019 11:51, Oleg Dobkin wrote:
>
> I've changed enum into a flag and moved it into
> AVCUDADeviceContextInter
On Sun, 2019-11-17 at 23:31 +0100, Timo Rothenpieler wrote:
> On 17.11.2019 15:58, Oleg Dobkin wrote:
>
> Add AVCUDADeviceContextFlags to control the creation of CUDA device
> context for the hardware CUDA decoder.
>
> The current values are 0 (default behavior) - new context
On Mon, 2019-11-18 at 12:51 +0200, Oleg Dobkin wrote:
> I've changed enum into a flag and moved it into
> AVCUDADeviceContextInternal.
>
>
> Can't one just call cuCtxGetDevice on the context to get the device?
>
> Not sure the cuCtxGetDevice can be used
t the top-level check, but I'm not sure
this is the correct way.
On Sun, 2019-11-17 at 23:31 +0100, Timo Rothenpieler wrote:
> On 17.11.2019 15:58, Oleg Dobkin wrote:
>
> Add AVCUDADeviceContextFlags to control the creation of CUDA device
> context for the hardware CUDA deco
device context. Currently, the context is not accessible from
FFmpeg API, so, technically, the memory created by the hardware decoder
(the video frame) can't be safely read.
Signed-off-by: Oleg Dobkin
---
libavutil/hwcontext_cuda.c | 22 +-
liba
These functions can be used to create HW cuda device using primary
contexts - which is the preferred approach.
Signed-off-by: Oleg Dobkin
---
ffnvcodec.pc.in| 2 +-
include/ffnvcodec/dynlink_cuda.h | 2 ++
include/ffnvcodec/dynlink_loader.h | 4
3 files changed, 7
device context. Currently, the context is not accessible from
FFmpeg API, so, technically, the memory created by the hardware decoder
(the video frame) can't be safely read.
Signed-off-by: Oleg Dobkin
---
libavutil/hwcontext_cuda.c | 20 +++-
libavutil/hwcontext_cuda.h
These functions can be used to create HW cuda device using primary
contexts - which is the preferred approach.
---
include/ffnvcodec/dynlink_cuda.h | 2 ++
include/ffnvcodec/dynlink_loader.h | 4
2 files changed, 6 insertions(+)
diff --git a/include/ffnvcodec/dynlink_cuda.h b/include/ffnvc
13 matches
Mail list logo
