[FFmpeg-devel] [PATCH] avutil/hwcontext_cuda: check that the SDK defines cuCtxGetCurrent()

Timo Rothenpieler timo at rothenpieler.org
Fri Oct 6 16:47:45 EEST 2023


On 06/10/2023 15:31, Hendrik Leppkes wrote:
> On Fri, Oct 6, 2023 at 3:07 PM Timo Rothenpieler <timo at rothenpieler.org> wrote:
>>
>> On 06/10/2023 14:29, Hendrik Leppkes wrote:
>>> On Sun, Oct 1, 2023 at 1:39 PM Timo Rothenpieler <timo at rothenpieler.org> wrote:
>>>>
>>>> On 01.10.2023 04:06, James Almer wrote:
>>>>> Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2
>>>>
>>>> It's expected behaviour to break compilation with random inter-release
>>>> versions of ffnvcodec.
>>>> It's only reliable exactly on release versions.
>>>>
>>>
>>> But isn't the point that there is no release version of ffnvcodec that
>>> I can use to build this?
>>> And that it has no check to limit building it, and will always fail
>>> with release versions?
>>
>> I don't understand what you mean.
>> Right now, it only works with nv-codec-headers master.
>> I will make a new release there very soon.
> 
> You say that its expected to break with inter-release versions of
> ffnvcodec, but this is the opposite, it breaks with the release
> version and works with git versions. So I'm not sure I understand what
> you are saying.

No, with any old release version, configure correctly refuses to use them.
It's only broken with master versions after the last release, up to the 
patch that added the function.

> Requiring a non-released version of a dependency was obviously a
> gigantic oversight with the original patch, and as a result master is
> currently broken for any reasonable setup avoiding those
> "inter-release versions".

master temporarily requiring a development-version of the headers wasn't 
an oversight, that was the intended outcome of the update, and was done 
exactly in that fashion many times before.
I'm quite confused why this specific instance suddenly causes so much upset.


More information about the ffmpeg-devel mailing list