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-boun...@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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
