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 387E648CE4 for ; Fri, 23 Feb 2024 14:31:38 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A7A5268C720; Fri, 23 Feb 2024 16:31:36 +0200 (EET) Received: from mail1.khirnov.net (quelana.khirnov.net [94.230.150.81]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B6AA668C5E7 for ; Fri, 23 Feb 2024 16:31:29 +0200 (EET) Authentication-Results: mail1.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=fH3WbwF6; dkim-atps=neutral Received: from localhost (mail1.khirnov.net [IPv6:::1]) by mail1.khirnov.net (Postfix) with ESMTP id 44F614D66 for ; Fri, 23 Feb 2024 15:31:28 +0100 (CET) Received: from mail1.khirnov.net ([IPv6:::1]) by localhost (mail1.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id EfN0etpjwCoq for ; Fri, 23 Feb 2024 15:31:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1708698687; bh=nNh+Czk+S3ziEMSA+JJM6s6p4ItXX1Ijc/TNOQTsKI4=; h=From:To:Subject:Date:From; b=fH3WbwF6UjprsomDoeolHhvMN9nhpDpjdip07+E4abPDbBFsRUQm8lF/qAW2VKONy SzpC2EWSpzHel8g/ywAMf3jp4zMBbvvdIGEkUXwyF3xHPCLLBCIMUBgw2E841U1uqq Xd0oVAVffesTJlqXBKKL7a2xmdOnGr/UeG46o2h0jHZtvnlMTcc76OA+FimXeLRhtd JvP3zR79GdKsqzxnIvlJTNAGs7tURnhD1Bee3ZRAk1N180jrfyOL9hJh5xB4mrVgCB vQGOs/eYZAtaQcRVtQdKClKTA9Gbez1A0Zxs32+udQpYH9IBQYaGxs90tp3LjuQoh1 BvtK2kir7fBdA== Received: from libav.khirnov.net (libav.khirnov.net [IPv6:2a00:c500:561:201::7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "libav.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail1.khirnov.net (Postfix) with ESMTPS id 3AB524492 for ; Fri, 23 Feb 2024 15:31:27 +0100 (CET) Received: from libav.khirnov.net (libav.khirnov.net [IPv6:::1]) by libav.khirnov.net (Postfix) with ESMTP id C58D03A032D for ; Fri, 23 Feb 2024 15:31:21 +0100 (CET) From: Anton Khirnov To: ffmpeg-devel@ffmpeg.org Date: Fri, 23 Feb 2024 14:58:22 +0100 Message-ID: <20240223143115.16521-1-anton@khirnov.net> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Subject: [FFmpeg-devel] [PATCH] array AVOptions and side data preference 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: Hi, this patchset implements a solution to the problem of side data precedence for lavc decoding, recently raised by Derek (#10857). The issue was caused by the recent addition of a mechanism for providing global side data (typically from the demuxer) to decoders, which will then propagate it to decoded frames. The problem is that some side data may be present both in global headers and in the coded bytestream, which will result in output frames having both attached, with no way to tell which is which. The solution in this set is as follows: * at most one side data of a given type will ever be attached to a frame * by default, bytestream side data is preferred * a new decoder option is added to allow overriding this default on a per-side-data-type basis; to implement this I am adding array-type AVOptions, which should also be useful elsewhere Some potential points of interest: * I am adding AVOption.array_max_size to allow specifying a maximum array size for array-type options. Since Andreas seemed strongly opposed to increasing sizeof(AVOption), I am placing it in a hole before AVOption.unit (which is the reason 15/38 needs to go in as a part of the major bump). This means that I cannot also add a minimum array size. We might also: * give up on specifying minimum size * drop array size limits entirely (array_max_size is not used as of this set) * make array_max_size 16-bit and add a 16-bit min as well, since I don't expect array sizes to be very large * I am not providing any API for accessing array-type AVOptions other than av_opt_{get,set}() (i.e. converting to/from strings), because it's not strictly necessary for this set and I did not want to delay the bump because of it. But clearly some such API will be needed. Big thanks to Niklas for helping with decoder conversion. Cheers, -- Anton Khirnov _______________________________________________ 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".