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 C917D43208 for ; Fri, 24 Jun 2022 09:14:48 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 46C5D68B6E1; Fri, 24 Jun 2022 12:14:45 +0300 (EEST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-oln040092075082.outbound.protection.outlook.com [40.92.75.82]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D9D1E68B18B for ; Fri, 24 Jun 2022 12:14:38 +0300 (EEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jRsv5yZXLCkZ615Ftutl69wTcnAkgeLg50UbTKNiJdl27+ahx/aPqhFMZsioh2iF6IvuUyYdbtR7i6QVnel0ONFj2xbdRcoHrOEJVNLXQwpbYOD4mv/5r4qKaYHS+0jSfKH6P2IvKrr9qSgw1D1MzMGKPEgICY1PwSG+0XVvwJYMXe2gu65TZ9R05B4gPpWV2XaitygWb9l9Na8kVE5Zdc7q7ITYsGQ2jm/NuuOAadlWk74wQh8zT3zqiNHO1Yb/gMHDhsdJEjpEJTmWeleFPIxFVlaLJbPcMTNcdcuS5g9Ykl0+O5kiAiqvgp+cfaFDwq8I3UO30SRecS1Gg+cuKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5l8OC0afeE57A6gIdjHvKxoa3ZlZCYGsnAf31lC5DAg=; b=lu0rER28oAHtTcVVkli3MxkQO3T5tE2VhlYJ0tkRxAf7FBA6hn4XxPRzEM83Ky8bsMY+fuhFB0OAKHUDguUDuzCEcCCAejcj7JQlsJpHOyhU0ldp7uq3dOWc0WxqNTwrEYIecsMFU+KBC/DeSgiVG1W9JrI6eCgd3WJjuKERsy2ZLeCOjXA4PZ7NTAPVr4G0+PI5ZH65gDdTtDqE9I1BH0TMPYyzpWaOh7kHdU8Tl/umwREKO7cFrt8C2aZE5Jfqwf+VbiwlDOEEjX7Z+/8O+DxDJeaoMl0PYraWCujKBjNQlIXsJJU7YkoyEXB+pqYR+Dc+i3lE5uRt+tZFRMbdaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5l8OC0afeE57A6gIdjHvKxoa3ZlZCYGsnAf31lC5DAg=; b=VsMHnhst0fFAM1xI5LcT3u619xl0c27W78qXWV8I9f3DvFw9XxPVWAqKugxN0meIRw+ddftq2W87103osppNWOZlKk5f41Z9KqboeYBK6ueSWKEq1uD3kSf5Za9RZqvNfUdkgqIuvE5VBAU1wmu1qxgnEDaODnraRcd08LWv767trcr+Ocnf2z30nQE7fxg1jBnUaMPKOiXn/HxITR7BsfaXv4biWY7ajJ5WzuraRp0XXLEsl5DBDQbT1B9LE7f/XbioUCMhWZmzkKb3sQq1G7qz8UjX87lvxrltzqtnDkaa8BANKwnlCIGRG2HppHXusnbQdnswyg2LVFwLsOnLXA== Received: from DB6PR0101MB2214.eurprd01.prod.exchangelabs.com (2603:10a6:4:42::27) by PA4PR01MB7694.eurprd01.prod.exchangelabs.com (2603:10a6:102:c6::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.15; Fri, 24 Jun 2022 09:14:37 +0000 Received: from DB6PR0101MB2214.eurprd01.prod.exchangelabs.com ([fe80::60b9:9f29:40cc:f01c]) by DB6PR0101MB2214.eurprd01.prod.exchangelabs.com ([fe80::60b9:9f29:40cc:f01c%10]) with mapi id 15.20.5353.022; Fri, 24 Jun 2022 09:14:36 +0000 Message-ID: Date: Fri, 24 Jun 2022 11:14:34 +0200 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <9642852e9da11714c8643833562b6e86133ce1a1.camel@amazon.it> <0215838ca87728a7e2742ab19af7fe1d5c3f9abc.camel@amazon.it> <165556480189.13099.7220862156046633312@lain> <80f0b155c25cfbba992dfb7ca79e1b37b8dfc12e.camel@amazon.it> <165599096835.13099.14253738660427313095@lain> <165599568445.12703.13879461885645668680@lain.khirnov.net> From: Andreas Rheinhardt In-Reply-To: <165599568445.12703.13879461885645668680@lain.khirnov.net> X-TMN: [gW0i01JCL256uWPQqyrA/6FkoNSKl+3z] X-ClientProxiedBy: ZR0P278CA0157.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:41::22) To DB6PR0101MB2214.eurprd01.prod.exchangelabs.com (2603:10a6:4:42::27) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 95f5c025-fde2-46fe-465a-08da55c1f59c X-MS-TrafficTypeDiagnostic: PA4PR01MB7694:EE_ X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3LpRUrYRhEsCADjnnI0kBk57ghlSWg8RS+bkfjL47LsrXjrgNBTBaBsbZ0NNIgZt1Itdwgai+wdv2ilsFFIPEG5hnWovIHB9JtgebDdyEN4jXucQdou7hj8f/c5YtTUastcf+wEx3uKzksP2tksCJjet+G0Gvwm0i3XrYAy80W0IPNG4VnKlXA6pSw9ccsdKN0cfHv8okvsXq/NZuPYzqjta8ONyjXKxrGPlEYQkqpwPFInIR7jfuNHGiHYb4VAmxo/stsEbhbMLC5diAjHzjwDNr4Btp04rYXgw3M29zyWOtNFw4Bw0BxI0ri2tfEHEWneq7Ede/zdVtCMKjjEXHodsRM2c25AHGVerYN6Dp9dAx8t/VpYEKLNNpfrnDjuFJD17piuuoSGFVM7vBHuBF6uKeLhZcg6P/zwhrzjZIIyX8XegwzUpt7c5NMgmNb7t2HALjYQuw+SBneafBUeBV4AVa+H5VCIIaKWo0tA1Wj891hXmUncsNNtdU04v7/5qI1qspbZTpEz5n7kCYFUQ38THLlBv9ZkiCjgZ+/jvTKDAEVTd0Z0APP2w7yGxh/rLN51PztP9g/xB+V2rYnEBmugVpXgKUzxG74dOPpucus3Lbw3gawrUhoOZEJBdAZntJ497gduRx4KyMTU8KMbnug== X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WmlGaXUxV3VJWHE3THI0WHlyQUlZalBMVWh0T1RwclZ0M2JGSTBRRm9oRTBR?= =?utf-8?B?bzZObmtycnZxcHUvVkJWUUhRMDdZS3U1Sm45Q0h1SFNvdWo3SWEzTUp2ME42?= =?utf-8?B?cXN0eGtBbkVraE1XSFJPRlNzZmdrUzFwZWJLVTBqVDU2TlFWZ2NzUkVZa3Ns?= =?utf-8?B?K1VZOXozSzh2SXE4RG54cmppbGQ4bm9hWXRBY2RmU0ZoM25kZlFJbEdNc25l?= =?utf-8?B?aUplOUN0SnRZSm9jZVlKcEdhWmVNZzVmSXZtWVRQc3J6bnRVTWVmNE5uZDdp?= =?utf-8?B?YjBEMFFDaFRGY3VGQjBiUzZlNDdkQUY4RUt2OUlQMmpPRkVYUERoZHdaS3NP?= =?utf-8?B?U2V1UzMwRFR2V3dIMWpTQWxIaS8rdFhjdUc5RjByQnl0QlA1bnJQV3R6N0Ry?= =?utf-8?B?VlpybDN0dm9ycWxIak9nYlI5WG5MSUJ1WW9wc0R0dEdkMVYzOGJBOXloK2hz?= =?utf-8?B?czZrZ21uaTJ2L0pmMTdWbWdPUHBadmc0VUU2cjlqblhJcXFxT29NaWo0REhZ?= =?utf-8?B?Ny90YXlxTjY4SlgrREdUNmV5RGxBamU4RHVQYzZTRzR4MEJzQndSYWQxUFRr?= =?utf-8?B?N1hlZjA3Qm1ydlJNQm80VDM2aXJLNHp2ZkdVT0ZQTXN0N1FRd2FSYkZPRlFU?= =?utf-8?B?cnRQOXZEU1BZRm4relhucDI3YVB1Yjk2K3hoNTFIZ2ZWTGtSM3pYbGtuTm10?= =?utf-8?B?TnFXWUsrSmlNTzJoWmVKQUpvek5zalFsUWVyMnhWNElObkpHMXkwd0U0Q1ZS?= =?utf-8?B?RUQxMkl2Z201VlRaRk0xRDFUbTh3RWw5WHFQTzJlbUdyVG5jdHFFR1plaDZn?= =?utf-8?B?d25uT2JPeFFPUXpocmRZaTVmaTIzYnhTcWNpZTdLeXE4WHZibUM1VVR2aGZz?= =?utf-8?B?aVhKenVXNHdobEp5MUMrdnZBRk8xUkpvM25obWM3bU9GQWlqTW90LytBRG1s?= =?utf-8?B?VHZrT3hLVzJvN21iajd6emFjMjlrSVpvZDRQaUl6RDZxcWxJZjJYVXhOU2g2?= =?utf-8?B?TC9LVVBCZWpNVVF3eHh4dEpDcDFnVE4zMkhlUFQxaU16MGIxbzJoNkd6YVkw?= =?utf-8?B?VUJaWG5XNitqbWNCSjJCa05RaHhQRkV0RjhGOXpTanMyVUtuTWlCZzNHelFw?= =?utf-8?B?RmJjODEzTk92YW1nRFU2VllSNlJLU2ZMZENhT0YyRU0xdDZINTI1dHNwWXcx?= =?utf-8?B?Zm1GMit2QjhUUGMrUnNVODExNU44VklmaHJrT2dKdnkybFhBbXAxVTllMmVD?= =?utf-8?B?dEFkcWF4SkdacERIOFI0NEtpTDh4YVREeUpyYUU0dmFmNnhTS1o5RW4xYXNr?= =?utf-8?B?YkxUNEJnQ0h3QzM4Und6T2dWbUpjV1RERnVNQitpSkVOS1pJRUtkNlV6dFFa?= =?utf-8?B?d2dyaDJVYVBaQ2pvOEZmWmFEQytYRURYN2xUWVYxeDlGYnYraVNsRDJBdXFw?= =?utf-8?B?YVBwV2x0THdrZ3RmM3I5TjNEMFZyNWs2YlNiWitOa2pQK1FJQ3U0dTV5bjBo?= =?utf-8?B?Ulk5c0ZGUkNtSkZCYW4vUmkrL2UzYzdWeGNjQVlkL1NyeUZSYmYyRVNQdlRH?= =?utf-8?B?WTN2bXFPY3RvREk5djVPRUZOTmJaZTdpaitkanF3TUludUVsYldJV21tZlpE?= =?utf-8?B?ckRQbzEraUlVUkxrdzk1dERUYzJGZG9HU3hCczVIa01QOXNCZGhsV09uaXNS?= =?utf-8?B?UFoxMUd5aWtxNUM2QkRRZ0tRdytEbWw4bkpLWVVscitLUFNiMkVHZTlmNXJJ?= =?utf-8?Q?LCzmKlIOs60i3dK+3w=3D?= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 95f5c025-fde2-46fe-465a-08da55c1f59c X-MS-Exchange-CrossTenant-AuthSource: DB6PR0101MB2214.eurprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2022 09:14:36.8273 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR01MB7694 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: Anton Khirnov: > Quoting Andreas Rheinhardt (2022-06-23 16:21:18) >> Anton Khirnov: >>> Quoting Carotti, Elias (2022-06-21 10:48:07) >>>> Hi, >>>> >>>> extending AVVideoEncParams was the first hypothesis I made but it >>>> didn't seem it was the proper place to add the mb_info flags. >>>> >>>> I may be wrong but my impression is that AVVideoEncParams is used to >>>> carry encoding parameters read from the bitstream at the decoder side >>>> while here were going the other direction, i.e., were passing >>>> information from the application to the encoder. >>>> >>>> Secondly, mb_info can't be strictly considered encoding parameters and >>>> it's not present in the bitstream at all. >>>> It's just a way to give hints to the libx264 encoder on which >>>> macroblock we know have not changed since the previous frame and could >>>> be coded as P_SKIPs. Libx264 however, may or may not oblige according >>>> to its logic, and this specific information is not transmitted in the >>>> bitstream nor can be recovered at the decoder. >>> >>> Right, seems I was too hasty in reading your patch. >>> >>> But then I have to wonder whether this really needs a new installed >>> header, with a struct and a destructor, given that it's specific to a >>> single encoder for a single codec that is about 20 years old now. >>> >>> Wouldn't AV_FRAME_DATA_X264_MBINFO that would be just a raw array of >>> uint8_t serve your needs just as fine? You could even get custom buffer >>> management by using AVFrameSideData.buf. >>> >> >> There is one problem though: libx264's free functions don't accept an >> opaque parameter, so one can't easily create a reference for libx264 to >> unref. I don't see a way around duplicating this buffer in the encoder. >> (Or is there a way to know when libx264 is done with using this buffer?) > > An ugly, but workable hack could be > - user allocates the AVBuffer with extra space at the end > - lavc/libx264.c checks that there is extra space AND the buffer is > writable (so the same side data wasn't passed to multiple encoders), > then stores its AVBufferRef* in there > Ugly? Certainly. Workable? Questionable: Depending upon how the user uses the API the frame might not be writable when it reaches the encode callback of our libx264 wrapper even if the user actually supplies writable frames to avcodec_send_frame(). The reason is that if said callback is called in avcodec_send_frame(), both the user's AVFrame as well as the newly created reference to it (which is the frame that the callback receives) will each own a reference to each side data. The callback is called in avcodec_send_frame() if there is currently no buffered packet ready to be forwarded to the user. This is true if the user drains the encoder every time a frame has been sent. And that is how we ordinarily use the API (our examples use this pattern as well as ffmpeg.c). So I guess that this is the common way our API is used by others as well. (I think I once proposed adding a flag to muxers/encoders to select whether an ownership transfer of the packet/frame is intended or not.) - Andreas _______________________________________________ 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".