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 7C4E746C2E for ; Fri, 6 Oct 2023 11:34:14 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 91B8F68CAD4; Fri, 6 Oct 2023 14:34:12 +0300 (EEST) Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id AA4DD68CA01 for ; Fri, 6 Oct 2023 14:34:05 +0300 (EEST) Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-690bd59322dso1688493b3a.3 for ; Fri, 06 Oct 2023 04:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696592043; x=1697196843; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=1mvElcVvUOTir0DWTc+EAp+17LPwc13h8shG45RgXCo=; b=dmCQHdO8L9MhkVKz112/SCdye0bjTGq/xS/IhLNuxSRaJbvpujO+xkK/x2RBuou9WK rQOdbf3MtF/nVpe/2fJHBgNvti+bC9e7JImF4NUsLqkWpbDUyV411YiGLW+z55neP2/U Bi3+JoBBD6X1xi1/87OANLHe+7si9SlzNndT6TBMqPgfiUAT5ObUFjZrNmAGatge/74e RyQ/GnPEHX76x3AAbcexoT+LzGognXbLjGFnVAodUeICbqXi6lsrv2kBwCaZgNMJ4Or+ 9INvaz7FF3OYCew7SKNNk2IW13XL4cgE24HSsnqMKF97CCKMlcQIyjK/9n35kt0TkK7y PVUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696592043; x=1697196843; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1mvElcVvUOTir0DWTc+EAp+17LPwc13h8shG45RgXCo=; b=Cp7Uv6f/Bym5mLOrACMAiYnwVwVdtOyeXfeVxvaS4SE4H3IvWJCO23nfLoLkicL4u9 S/1lHhlABgJaWPTHjq7nwZ6yjqz3aGAtUDjrakNIvHbXTzD9jcnX3eOvSgkYsGDfEPGy M8nPx+mQ/C61PeS1veup874EoHkQd2roYU9k3kTzOM9y2nTc0KRn9bqYxNHZ988FmIWU IDSIPeQnsWGTQH2mw4aO3Zz+hK3Kxi2R3sKM/cksXoaGgpcHSWP0eilq8bNavCUxcqm2 lTX+01/URPcxaNchUx7ofODn0IZc2AlvE+UwlCAyC0PWZRSyFNAapEcRxTHPyX7qMzl4 EknA== X-Gm-Message-State: AOJu0Ywit1JQK4oAPRZm25G501J0ET99+dfDXnhPHut1SgR3P7sIrwSz 34wVO56HB/vA+IN5qJ2GjnrpT9KO3PI= X-Google-Smtp-Source: AGHT+IGLnqhbQAszUSkxTv9pv+G5nuNijKatDL7weR02Qxf08Nx+AlAethf4JGPXS0H3Vql+F3TWiQ== X-Received: by 2002:a05:6a21:3294:b0:16b:8572:5a4a with SMTP id yt20-20020a056a21329400b0016b85725a4amr1783953pzb.61.1696592042824; Fri, 06 Oct 2023 04:34:02 -0700 (PDT) Received: from [192.168.0.16] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id u5-20020aa78385000000b0068c90e1ec84sm1241142pfm.167.2023.10.06.04.34.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Oct 2023 04:34:02 -0700 (PDT) Message-ID: <3089eafc-970f-4fb9-9b03-27d542525433@gmail.com> Date: Fri, 6 Oct 2023 08:34:18 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <20231004122849.56604-1-jamrial@gmail.com> <20231004122849.56604-4-jamrial@gmail.com> Content-Language: en-US From: James Almer Autocrypt: addr=jamrial@gmail.com; keydata= xsBNBFjZtqABCADLW+vdEoZaJZDsIO6geYFTOcn1unsEHefj9zn+3oTHlDFFzO47mzHsSfbK 9JE2xpOJEVnC8FAF5Sayi/pVwV+mtQUV3n5dgVeVBYF9GUQwOGFCpK8X54RRqhkgknbunOEE 0CtgAJgmpFmmmHgq02GvEspx1h/rh4apqwQR6QX4Favb+x9+i9ytVpwVcBX94vo2toyP7h/K BWfadQmb8ltgE1kshfg+SQs/H5bTV5Z1DuEASf02ZL/1qYB/sdTgWPLv9XMUHHsRFmMY8TMx wJSkP+Af3AiYQPJYz1B1D4tt98T/NoiVdin10zATakPjV8hXaobuRmxgakkUASXudydDABEB AAHNH0phbWVzIEFsbWVyIDxqYW1yaWFsQGdtYWlsLmNvbT7CwJIEEwEIADwCGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAFiEEd1EujP2UoWlX5pp6FGMBrXN2WeAFAmJoLUUCGQEACgkQ FGMBrXN2WeAFVQf9GtGhniRs1PzNUOgJktCnv6j4BbLieaIPYPEFXKDHOgjqQE2zVMYXnoXl Jam928ii902a8OY06r9ywn/R8ApD1/3NY/v64O71CY9scz5XyH2au8wIZ6HwFy3/f7sqjdGD uctY8Qs7rjT7NkoC5lmgMu2v2k03dGtM9AAf5AK5gU+H0EUw7vmKKiXzUqt5kvBuf4CEwXvH AQT1SMJ52rIlDWB7FQFyZeUbOAK2IgY/KNedfK6nsgd/eQVnlofPd2XoddE7kP6iys7jJefw DD3g3rZyDTq7in5dyk5glaNpWZpbHGBs+9SCYLnfQ8XvWqPFOD+gj0plamKANgOvavKTxM7A TQRY2bagAQgA69YtILj8kYxmqPr/M8+MXT7wVoOWVW9lvSmPquCELaDy/NIS7D06VC5EuE/6 JlJXZMTn37NLlyWhzwOgXuXw5w2tyoQQBuvqGiXJijuXwXH7HKdzrc6rpYtAqt5w05hzNrFS KrS0izG64VpWrfproy3BsL+8TBm9brLhhNPynVRqVukbbGzlATTzNQGZ14TTi2/dL6DkMQnM qn4jX9UEe4GdGQBP50bUJSSmeiIkyNLWA+znuN2PZEz930ZwNrF9GtDVw7mzcmpCZ7spldE2 tutbpy9D1bIqxyqBrYDSezyzL2adR1qgHyOTMCHg2AYNkrIQHrSyJxKTpZ1/hqOp8wARAQAB wsBfBBgBAgAJBQJY2bagAhsMAAoJEBRjAa1zdlnghekH/0Yb0iYJ74oID2f/Fj+AJKS2ekQF P2xOr8lpGzgp/+yWUvPtqbX0A33anBJdYwxaAC0NataX3tfZ+oJkzXqfmqhIHMPYHdZesJA2 Bk9hU/33mDl5s5U66/z0uelWzwKVHoQ2O6or4+qF3HJFSJLCe9uvWJ3zXf9F342Ftj73sfx+ 3xkw/IXsN1RqbYqDlzpoEQ99SIEfY/8Jjwnd3sIPfqkuyeaYfe6GJDqKawdCEP1oRRlbXEAp TJgYz8r3nPhGv9cdHNDCk44ISbsqVuxIEnLqi4fTPZaGupiQhT+srl268TTAp2TQW7+6Ce/b NPQorMquzS/LZoyALpmsYi/miMc= In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 03/11] avformat/avformat: use the side data from AVStream.codecpar 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 10/6/2023 12:04 AM, Andreas Rheinhardt wrote: > James Almer: >> Deprecate AVStream.side_data and its helpers in favor of the AVStream's >> codecpar.side_data. >> >> This will considerably simplify the propagation of global side data to decoders >> and from encoders. Instead of having to do it inside packets, it will be >> available during init(). >> Global and frame specific side data will therefore be distinct. >> >> Signed-off-by: James Almer >> --- > > ... > >> diff --git a/libavformat/avformat.h b/libavformat/avformat.h >> index a8e245000f..8a3fe137fa 100644 >> --- a/libavformat/avformat.h >> +++ b/libavformat/avformat.h >> @@ -940,6 +940,7 @@ typedef struct AVStream { >> */ >> AVPacket attached_pic; >> >> +#if FF_API_AVSTREAM_SIDE_DATA >> /** >> * An array of side data that applies to the whole stream (i.e. the >> * container does not allow it to change between packets). >> @@ -956,13 +957,20 @@ typedef struct AVStream { >> * >> * Freed by libavformat in avformat_free_context(). >> * >> - * @see av_format_inject_global_side_data() >> + * @deprecated use AVStream's @ref AVCodecParameters.side_data >> + * "codecpar side data". >> */ >> + attribute_deprecated >> AVPacketSideData *side_data; >> /** >> * The number of elements in the AVStream.side_data array. >> + * >> + * @deprecated use AVStream's @ref AVCodecParameters.side_data >> + * "codecpar side data". >> */ >> + attribute_deprecated >> int nb_side_data; >> +#endif >> >> /** >> * Flags indicating events happening on the stream, a combination of >> @@ -1720,11 +1728,18 @@ typedef struct AVFormatContext { >> int (*io_close2)(struct AVFormatContext *s, AVIOContext *pb); >> } AVFormatContext; >> >> +#if FF_API_AVSTREAM_SIDE_DATA >> /** >> * This function will cause global side data to be injected in the next packet >> * of each stream as well as after any subsequent seek. >> + * >> + * @deprecated global side data is always available in every AVStream's >> + * @ref AVCodecParameters.side_data "codecpar side data" array. >> + * @see av_packet_side_data_get() >> */ >> +attribute_deprecated >> void av_format_inject_global_side_data(AVFormatContext *s); >> +#endif > > This is not a "helper" of AVStream.side_data at all. Whereas porting > code to the new API is straightforward for the other deprecated > functions, this one is not. In fact, removing it adds complications for > users, because a user could simply inject global side data via this > function and then only look at packets, the user now has to add special > code to also inspect the global side data. > > One example affected by this is my current patch for the Matroska > demuxer to output the palette as stream side data and not as packet side > data as the other demuxers do. Without > av_format_inject_global_side_data(), this will break every user > searching for palette data only in packet side data and not in stream > side data. In fact, one such user is libavformat itself, because all > muxers (nut and avi and mov (the latter two via rawutils)) only search > for this type of side data in packets. > > As you can see in that patch, it fixes an issue with seeking where the > palette is attached to a packet read during avformat_find_stream_info() > that is discarded afterwards due to a seek. The same issue also exists > in avi, yet the solution is not so simple there because avi has a second > way to export palettes and due to the requirement that global and > packet-specific side data is supposed to be distinct one can't simply > attach the palette extracted from extradata as stream side-data. Which > makes me think that this requirement is not really reasonable. > > - Andreas I can remove the deprecation from this patch. No strong feelings about it, and it can be done later if needed. _______________________________________________ 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".