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

["Xiang, Haihao" <haihao.xiang-at-intel.com@ffmpeg.org>]

On Wed, 2022-01-05 at 00:19 -0300, James Almer wrote:
> 
> 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@ffmpeg.org> On Behalf Of
> > > > > Anton
> > > > > Khirnov
> > > > > Sent: Friday, November 26, 2021 8:12 PM
> > > > > To: FFmpeg development discussions and patches <
> > > > > ffmpeg-devel@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.

I apologize that I missed the new discussion on ML, thought no objection since
my email, so I pushed Softworks' patch as this patch really fixed some issues for me and others. I'll revert it and check the ML more carefully. 

Thanks
Haihao


> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".