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 C7E7D435A8 for ; Fri, 17 Jun 2022 10:34:41 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9ECE768B8B6; Fri, 17 Jun 2022 13:34:39 +0300 (EEST) Received: from btbn.de (btbn.de [136.243.74.85]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id A661E68B8A8 for ; Fri, 17 Jun 2022 13:34:33 +0300 (EEST) Received: from [authenticated] by btbn.de (Postfix) with ESMTPSA id 577F12B0996 for ; Fri, 17 Jun 2022 12:34:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1655462073; bh=ZzTm6sabpCDQY9Am7ZtY4vP8c2kNLkEvfcbcQ7CdLsc=; h=Date:Subject:To:References:From:In-Reply-To; b=WGP0hqWchdI8dvYHySGmrxfu5iBITtAClt1O/eByyXK3ISFcaV62MHkH1iIdJH8A4 wFbgURBCU3R3vBwYQMi3g+kTrZcaxuhdwyJc+ANXJrK+Tk1PMUa8aN71L4FZJHZjmn dxLdUYEzbNqHcZXAOBgNKyK2r93HZRQaou5d2yMSlufa3yVU8SPKQYC3H2N4zdG8Mh LURAC7q4Zmg+h/Y+vpa2FE2//wWJBAM/Z30j4DFkLZjuOhu+eW1apAxuIvCFvA/XN7 cHZVeRO3XyvtWq0nMnQ3eaF8EyYKw/PPFdZUXaNM/59DruHfSBh+kpDMY0puixVs3B 7Srh50I7VgBYg== Message-ID: <31d55286-6118-0438-62d8-c04fcb6d183d@rothenpieler.org> Date: Fri, 17 Jun 2022 12:34:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <9642852e9da11714c8643833562b6e86133ce1a1.camel@amazon.it> <0215838ca87728a7e2742ab19af7fe1d5c3f9abc.camel@amazon.it> <2d163f70-25e5-27d6-fc6a-a5a8084a03d7@rothenpieler.org> From: Timo Rothenpieler In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] Added support for MB_INFO 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 17.06.2022 12:15, Carotti, Elias wrote: > Hi, > thanks for pointing out the printf. That's a left over which I removed. > > I am not clear on the possible leak you are hinting at. > The new side information only passes two pointers to libx264, the first > one being a buffer with the flags and a pointer to a deallocator which > may be NULL. > > If the deallocator is not NULL libx264 we're yielding the deallocation > responsibility to libx264, otherwise the ownership of the buffer and, > as such, the responsibility for the deallocation remains with the > caller. > As such, the only possibility for a leak seems to me due to a > programming error. > Is that what you were asking or am I missing something else? > > Please find attached the updated patch. > > Elias > Yes, exactly. It relies on x264 to free it. What happens if x264 is not involved, but some other encoder, which does not check for that kind of side data? How does the caller know that the data was consumed, and the ownership passed on? The only sane way would be for the caller to hand over the ownership to ffmpeg, which then takes care of making sure it gets freed. _______________________________________________ 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".