[FFmpeg-devel] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

Submitted by Miroslav Slugeň on Feb. 13, 2017, 9:24 p.m.

Details

Message ID 58A22409.8030809@email.cz
State New
Headers show

Commit Message

Miroslav Slugeň Feb. 13, 2017, 9:24 p.m.
Dne 13.2.2017 v 11:18 Timo Rothenpieler napsal(a):
>>> That's what it looks like for me:
>>> https://bpaste.net/show/890855410dac
>>>
>>> Happens on two independend machines, on both Windows using MSVC and
>>> Linux with gcc.
>>> Both machines are definitely nowehre near out of memory, on either
>>> system or device memory.
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> Can't reproduce it on two my systems with same sample and same command
>> line.
>>
>> First 1000 lines:
>> 375.26: https://bpaste.net/show/bed97b3e0287
>> 378.09: https://bpaste.net/show/912c042036cd
>>
>> Configuration1:
>> Debian Jessie Linux desktop 4.8.0-0.bpo.2-amd64 #1 SMP Debian
>> 4.8.15-2~bpo8+2 (2017-01-17) x86_64 GNU/Linux
>> GeForce GTX 1060, drivers 375.26
>>
>> Configuration2:
>> Debian Jessie Linux pascal 4.7.0-0.bpo.1-amd64 #1 SMP Debian
>> 4.7.8-1~bpo8+1 (2016-10-19) x86_64 GNU/Linux
>> GeForce GTX 1080, drivers 378.09
> That's not built from the right branch.
> Most notably: On the filter-merge branch, the cuvid pfnSequenceCallback
> happens before the "Nvenc initialized successfully", on your log Nvenc
> still gets initialized first.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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.

Comments

Timo Rothenpieler Feb. 13, 2017, 10 p.m.
> 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!
Miroslav Slugeň Feb. 13, 2017, 10:24 p.m.
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.
Hendrik Leppkes Feb. 14, 2017, 5:51 a.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
Miroslav Slugeň Feb. 14, 2017, 8:22 a.m.
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.

Patch hide | download patch | download mbox

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;