| Message ID | 58A22409.8030809@email.cz |
|---|---|
| State | New |
| Headers | show |
> It is problem in NVENC. > > You create first frame before initialization of NVENC in CUVID, so this > first frame is not accesible to NVENC until > dl_fn->cuda_dl->cuCtxPushCurrent(ctx->cu_context) is called in NVENC. > > This trivial patch should fix your problem. > > M. Very interesting. I don't think this patch is the proper fix though. There never should be an active cuda context when returning from a function, at least that's the premise under which I wrote all cuda related functions so far. This must mean that before, cuvid or something else must somehow have leaked a bound cuda context to nvenc. So that might need fixing as well. Thank you very much for finding this!
Dne 13.2.2017 v 23:00 Timo Rothenpieler napsal(a): >> It is problem in NVENC. >> >> You create first frame before initialization of NVENC in CUVID, so this >> first frame is not accesible to NVENC until >> dl_fn->cuda_dl->cuCtxPushCurrent(ctx->cu_context) is called in NVENC. >> >> This trivial patch should fix your problem. >> >> M. > Very interesting. I don't think this patch is the proper fix though. > There never should be an active cuda context when returning from a > function, at least that's the premise under which I wrote all cuda > related functions so far. > > This must mean that before, cuvid or something else must somehow have > leaked a bound cuda context to nvenc. So that might need fixing as well. > > Thank you very much for finding this! > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Try to look at: http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#module Maybe someone from nvidia will be able to explain it more M.
On Mon, Feb 13, 2017 at 11:00 PM, Timo Rothenpieler <timo@rothenpieler.org> wrote: >> It is problem in NVENC. >> >> You create first frame before initialization of NVENC in CUVID, so this >> first frame is not accesible to NVENC until >> dl_fn->cuda_dl->cuCtxPushCurrent(ctx->cu_context) is called in NVENC. >> >> This trivial patch should fix your problem. >> >> M. > > Very interesting. I don't think this patch is the proper fix though. > There never should be an active cuda context when returning from a > function, at least that's the premise under which I wrote all cuda > related functions so far. > > This must mean that before, cuvid or something else must somehow have > leaked a bound cuda context to nvenc. So that might need fixing as well. > Indeed having an implicit context active would be rather fragile, so best would be to revisit both cuvid and nvenc and make sure contexts are explicitly pushed and poped wherever needed - but I assume thats what you have planned to do now already. ;) This reminds me of this patch from Libav which landed a couple weeks ago: https://git.libav.org/?p=libav.git;a=commitdiff;h=fb59f87ce72035b940c3f5045884098b9324e1b2 Its hardly complete and only handling it in one place, but its probably fixing a similar issue. - Hendrik
Dne 14.2.2017 v 06:51 Hendrik Leppkes napsal(a): > On Mon, Feb 13, 2017 at 11:00 PM, Timo Rothenpieler > <timo@rothenpieler.org> wrote: >>> It is problem in NVENC. >>> >>> You create first frame before initialization of NVENC in CUVID, so this >>> first frame is not accesible to NVENC until >>> dl_fn->cuda_dl->cuCtxPushCurrent(ctx->cu_context) is called in NVENC. >>> >>> This trivial patch should fix your problem. >>> >>> M. >> Very interesting. I don't think this patch is the proper fix though. >> There never should be an active cuda context when returning from a >> function, at least that's the premise under which I wrote all cuda >> related functions so far. >> >> This must mean that before, cuvid or something else must somehow have >> leaked a bound cuda context to nvenc. So that might need fixing as well. >> > Indeed having an implicit context active would be rather fragile, so > best would be to revisit both cuvid and nvenc and make sure contexts > are explicitly pushed and poped wherever needed - but I assume thats > what you have planned to do now already. ;) > > This reminds me of this patch from Libav which landed a couple weeks ago: > https://git.libav.org/?p=libav.git;a=commitdiff;h=fb59f87ce72035b940c3f5045884098b9324e1b2 > > Its hardly complete and only handling it in one place, but its > probably fixing a similar issue. > > - Hendrik > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Nice catch, this patch in libav should fix it also, i think it should be backported as soon as possible. M.
diff -Nurp a/libavcodec/nvenc.c b/libavcodec/nvenc.c --- a/libavcodec/nvenc.c 2017-02-13 22:22:37.627309692 +0100 +++ b/libavcodec/nvenc.c 2017-02-13 22:16:09.000000000 +0100 @@ -426,6 +426,8 @@ static av_cold int nvenc_setup_device(AV av_log(avctx, AV_LOG_FATAL, "Provided device doesn't support required NVENC features\n"); return ret; } + + dl_fn->cuda_dl->cuCtxPushCurrent(ctx->cu_context); } else { int i, nb_devices = 0;