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 BEFAE435AE for ; Fri, 17 Jun 2022 10:59:48 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9F4A268B8B8; Fri, 17 Jun 2022 13:59:45 +0300 (EEST) Received: from smtp-fw-9103.amazon.com (smtp-fw-9103.amazon.com [207.171.188.200]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id DA27768B476 for ; Fri, 17 Jun 2022 13:59:37 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.it; i=@amazon.it; q=dns/txt; s=amazon201209; t=1655463583; x=1686999583; h=from:to:date:message-id:references:in-reply-to: content-id:mime-version:content-transfer-encoding:subject; bh=BeESzPzn6QZXD9ORBRuNDyk8WtAibtLDNZXUIYrkugM=; b=SSFHyRwYXHGga/WgL1DeeeV+vIZg8MUInc/vjp7oU6m5WG2pBdN/eDlZ eeNcGes0QPCzp1/CEp4G3EtQ06YOUTHXL+CnBaZ+88Vn5lp3+41EIfyaW 2P9SlcAtowDpg2meyipVgMEoN9sddUYvwdDfMUlmRbLEwm87tJDmJ0eop U=; X-IronPort-AV: E=Sophos;i="5.92,306,1650931200"; d="scan'208";a="1025350764" Thread-Topic: [FFmpeg-devel] [PATCH] Added support for MB_INFO Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO email-inbound-relay-iad-1e-fc41acad.us-east-1.amazon.com) ([10.25.36.210]) by smtp-border-fw-9103.sea19.amazon.com with ESMTP; 17 Jun 2022 10:59:17 +0000 Received: from EX13D25EUA004.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan3.iad.amazon.com [10.40.163.38]) by email-inbound-relay-iad-1e-fc41acad.us-east-1.amazon.com (Postfix) with ESMTPS id 2D196C026B for ; Fri, 17 Jun 2022 10:59:16 +0000 (UTC) Received: from EX13D25EUA003.ant.amazon.com (10.43.165.117) by EX13D25EUA004.ant.amazon.com (10.43.165.12) with Microsoft SMTP Server (TLS) id 15.0.1497.36; Fri, 17 Jun 2022 10:59:14 +0000 Received: from EX13D25EUA003.ant.amazon.com ([10.43.165.117]) by EX13D25EUA003.ant.amazon.com ([10.43.165.117]) with mapi id 15.00.1497.036; Fri, 17 Jun 2022 10:59:15 +0000 From: "Carotti, Elias" To: "ffmpeg-devel@ffmpeg.org" Thread-Index: AQHYfLJt5ZoAjIylI0i9kT+cl/Xc0K1TUq0AgAAQnoCAAAmcAIAABV6AgAAG4wA= Date: Fri, 17 Jun 2022 10:59:15 +0000 Message-ID: <197e819b43e1c8d203fc035b6fd2ca7f46502ef6.camel@amazon.it> References: <9642852e9da11714c8643833562b6e86133ce1a1.camel@amazon.it> <0215838ca87728a7e2742ab19af7fe1d5c3f9abc.camel@amazon.it> <2d163f70-25e5-27d6-fc6a-a5a8084a03d7@rothenpieler.org> <31d55286-6118-0438-62d8-c04fcb6d183d@rothenpieler.org> In-Reply-To: <31d55286-6118-0438-62d8-c04fcb6d183d@rothenpieler.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.133] Content-ID: <20A4015DA6A2C14F82171DC766C93BBD@amazon.com> MIME-Version: 1.0 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: > > Yes, exactly. It relies on x264 to free it. Not really. It can rely on x264 if you explicitly want that behavior. If you do not set a deallocator, it remains the caller responsibility. > 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? Again, you don't have to pass the ownership, and in fact in my use case I do not pass it since I actually recycle and update the same buffer for subsequent frames. If you do intentionally pass the ownership you need to be aware of what you are doing. As I said, I see a leak only in case of a programming error. Maybe we could explicitly state it in the comment section in mb_info.h: if you set the deallocator you're relinquishing ownership of the buffer. Plus, there's one more flag (b_mb_info_update) in libx264 which allows to pass back information to the caller about which macroblocks among the flagged ones were actually encoded as P_SKIP. I did not add support for that though but in the future somebody may want to. In principle I could've put the buffer into the side information and not just pass a pointer to it but I thought that it would require adding more semantics which would imply a stronger dependency on libx264. Right now, mb_info is a vector of uint8_t flags and the only possible value - to date - is X264_MBINFO_CONSTANT. What if, say, one day libx264 decides the buffer has to be a vector of uint16_t or still uint8_t but the flags are packed? On the other hand, this, AFAIK, is only supported by libx264. Other codecs may want to choose a different semantic for a similar field and the only possibility to make it generic is letting the caller handling the low level details. > 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". NICE SRL, viale Monte Grappa 3/5, 20124 Milano, Italia, Registro delle Imprese di Milano Monza Brianza Lodi REA n. 2096882, Capitale Sociale: 10.329,14 EUR i.v., Cod. Fisc. e P.IVA 01133050052, Societa con Socio Unico _______________________________________________ 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".