Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: "Xiang, Haihao" <haihao.xiang@intel.com>
To: "ffmpeg-devel@ffmpeg.org" <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
Date: Thu, 23 Dec 2021 14:01:30 +0000
Message-ID: <50841f8a73c902d3fca896b1eda923d082b27383.camel@intel.com> (raw)
In-Reply-To: <DM8P223MB0365E3DFD61F63B305FC079BBA639@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>

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 ? 

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".

       reply	other threads:[~2021-12-23 14:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1637807570.git.softworkz@hotmail.com>
     [not found] ` <163785839519.25323.16303122737288435026@lain.red.khirnov.net>
     [not found]   ` <163794332023.25323.7446601680884381987@lain.red.khirnov.net>
     [not found]     ` <163795393240.7822.9483345286843818669@lain.red.khirnov.net>
     [not found]       ` <DM8P223MB0365E3DFD61F63B305FC079BBA639@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
2021-12-23 14:01         ` Xiang, Haihao [this message]
2021-12-27  3:08           ` Xiang, Haihao
2022-01-05  3:19             ` James Almer
2022-01-05  3:38               ` Xiang, Haihao
2022-01-09 18:39                 ` Mark Thompson
2022-01-09 21:15                   ` Soft Works
2022-01-09 23:12                     ` Mark Thompson
2022-01-09 23:36                       ` Soft Works
2022-01-10  0:56                         ` Mark Thompson
2022-01-10  1:40                           ` Soft Works
2022-01-10  6:47                             ` Xiang, Haihao
2022-01-10 21:16                               ` Mark Thompson
2022-01-11  7:01                                 ` Xiang, Haihao
2022-01-10 20:56                             ` Mark Thompson
2022-01-12  5:15                               ` Soft Works
     [not found] ` <DM8P223MB036578CDD5AEA447DD2DE424BA629@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
2021-12-29 23:04   ` Mark Thompson
2021-12-30  0:29     ` Soft Works
2021-12-30 11:21       ` Mark Thompson
2021-12-30 19:20         ` Soft Works

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50841f8a73c902d3fca896b1eda923d082b27383.camel@intel.com \
    --to=haihao.xiang@intel.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git