From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 6786D42DFD for ; Sat, 9 Jul 2022 00:57:33 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B0D5768BA1A; Sat, 9 Jul 2022 03:57:29 +0300 (EEST) Received: from btbn.de (btbn.de [136.243.74.85]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 53AC568B9E5 for ; Sat, 9 Jul 2022 03:57:23 +0300 (EEST) Received: from [authenticated] by btbn.de (Postfix) with ESMTPSA id F04A93438B9 for ; Sat, 9 Jul 2022 02:57:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1657328243; bh=HBUq8/XYIoMYAS5/njirk2Xy6TAVSHz4aUOcpYjZWkk=; h=Date:Subject:To:References:From:In-Reply-To; b=hw9tTgeoVSW9ZZYhuMNDe9o+drW4LQ1H/xpWXwE2IzYllSf1qvjzsDyfAwNeikCsX sOmb0VKCjbz1J2Ci5IWakgRqa7GC+CXocUMSQ16zIwsMHMCWKX4z+AULtU7l8uGbVt nJzcmR5hrN95zcwFTDnRzB9Z/yjJXV7oHLd8y4CJ6JbqMchc9zMZ95T8TB+S4uOgNA /S36+z7zBjPXutDy8mZxk6RqDZY8dDyUki/SAHgzC7kmP4CaVYcxq5Wwz9HAfpyo5L iG4PN0u8uci0B40ym2EGTiVkcOzCAXlk92nDN/UMWHwkFjPKBs99kDqvqofOj3evoT As27bGLSCVCNg== Message-ID: <28efef30-2b5b-853f-f10e-18ca1c78b873@rothenpieler.org> Date: Sat, 9 Jul 2022 02:57:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220708225404.23748-1-timo@rothenpieler.org> From: Timo Rothenpieler In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c wrapped_avframe and dependent changes X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 09.07.2022 02:28, Soft Works wrote: > > >> -----Original Message----- >> From: ffmpeg-devel On Behalf Of >> Timo Rothenpieler >> Sent: Saturday, July 9, 2022 2:15 AM >> To: ffmpeg-devel@ffmpeg.org >> Subject: Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, >> lavfi.c wrapped_avframe and dependent changes >> >> On 09.07.2022 02:01, Soft Works wrote: >>> I can submit the missing bit of differences as a patch. I thought >>> it was no longer needed. The requirements have also changed over >>> MSDK versions. The 8bit file mapping that I've shown recently >> exists >>> in fact because an earlier MSDK version was requesting such >> texture. >>> >>> Anyway, when something is causing trouble, then it should be fixed >>> in hwcontext_qsv. >> >> Settings those flags correctly isn't at all a bad idea though, and >> not >> fixing any issue I actively experienced. Just an oversight I noticed >> while reading the code. >> >> Fixing the heap overflow is the major issue and can really only be >> done >> in the d3d11 hwcontext. >> Look at the texture_flags array. >> It only ever gets initialized to the size of the initial pool size. >> With a non-fixed-size pool, that grows over time, that obviously is >> an >> issue, and will trash whatever comes after the hwcontext on the heap >> whenever more frames are requested than initially allocated. >> With a initial size of 0, that is... immediately. >> >> >> An entire other issue this does not address at all, but which also >> does >> not cause any memory corruption at least: >> >> QSV can't properly deal with a non-fixed-size pool. >> What happens if more fresh frames are allocated after the qsv hwctx >> has >> been derived? >> From the looks of it, it iterates and maps all the textures only >> once >> at init. > > There's an allocator pattern which filters are using, so when using > non-array textures it might be possible to have bigger pools than > textures allocated. But that's just a "might". > Please give me one or two days to respond with a better and more > comprehensive answer. Right now, I'm deeply drowned into something > else ;-) That issue is entirely unrelated to the ddagrab filter. All it needs is the heap overflow fixed, since it very much does run into that. The other stuff are just follow ups I found while skimming through that code. So if you want more time to look into those, that's no big deal at all from my end. And the fix for the heap overflow is as straight forward as it gets. _______________________________________________ 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".