[FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When deriving a hwdevice, search for existing device in both directions

James Almer jamrial at gmail.com
Wed Jan 5 05:19:25 EET 2022



On 12/27/2021 12:08 AM, Xiang, Haihao wrote:
> On Thu, 2021-12-23 at 14:01 +0000, Xiang, Haihao wrote:
>> On Fri, 2021-11-26 at 19:29 +0000, Soft Works wrote:
>>>> -----Original Message-----
>>>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Anton
>>>> Khirnov
>>>> Sent: Friday, November 26, 2021 8:12 PM
>>>> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
>>>> Subject: Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When
>>>> deriving
>>>> a
>>>> hwdevice, search for existing device in both directions
>>>>
>>>> Quoting Soft Works (2021-11-26 19:43:58)
>>>>> Maybe I'm missing something, but hw device contexts are refcounted.
>>>>> What happens in hwdevice_ctx_free() is this:
>>>>>
>>>>> av_buffer_unref(&ctx->internal->source_device);
>>>>
>>>> IIUC this only happens after the parent device is freed. My concern is
>>>> the following situation:
>>>> - the caller creates a parent hwdevice
>>>> - the caller derives a child from it, which may acquire some additional
>>>>    resources beyond what the parent holds
>>>> - the caller unrefs all his references to the child, but the child does
>>>>    not get freed because the parent still holds a reference to it
>>>>
>>>> Since av_hwdevice_ctx_create_derived() has a flags parameter, we might
>>>> want to introduce a flag to control this behavior.
>>>
>>> I understand what you mean. I'm just not sure whether a practical case
>>> with such a requirement exists. Should that turn out to be required,
>>> such flag can be added at any time, IMO.
>>
>>
>> I agree we may add such flag later if required. May we merge this patch to fix
>> the annoying derivation limitation if no other concern ?
> 
> Any other comment for this patch version? I'll add the note pointed out by Lynne
> and push this patch if no objection.
> 
> Thanks
> Haihao

Why was this pushed? There were objections.


More information about the ffmpeg-devel mailing list