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 2B1754759F for ; Tue, 12 Sep 2023 16:27:54 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id BAEFD68C9B3; Tue, 12 Sep 2023 19:27:51 +0300 (EEST) Received: from mail-oa1-f44.google.com (mail-oa1-f44.google.com [209.85.160.44]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9BC1F68C8CE for ; Tue, 12 Sep 2023 19:27:45 +0300 (EEST) Received: by mail-oa1-f44.google.com with SMTP id 586e51a60fabf-1d544a4a2f2so3892849fac.3 for ; Tue, 12 Sep 2023 09:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694536063; x=1695140863; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=BXoaXGQKGzIOsf8ogac6WNQNduwCVvgKD0WDda4XA+4=; b=ORmAX127CHH35CdFbRjxkW4OQPjx/CN0fzMU0CSBW8C2AeVvtdKqsCJKWFCMrF+nSd mSPSdBYLxL+4SGQwNCbdT5U+YHUgkGanei9vwZP5JWYlsQt9msFaZSPSznSJ8TdiJXs2 s5G9RrPmFGnfGqjRVKYQL7N7Je4WQ+o/Ut7ZUlbcRwRTcpevthgyBmLaFvDi2JEvthP1 CxXicf8vhCNPVJDF1tqTu9AGDDWPxBXxwYMoz7RNEjA2yc/pkcVs6xTd2iVYWTUk6yYX uxhaAzAxvz8WdF5FDQcsJb/Z3rrRXGEVmhT/QiRhP7G27TX05IgBd872mqUw0tymbWRo zuqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694536063; x=1695140863; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BXoaXGQKGzIOsf8ogac6WNQNduwCVvgKD0WDda4XA+4=; b=vrZzs/b5gr14VCSYyFqtog7CVWH8JqtwJBswh89L+6kvKrMMUGWPX7DreruaLD/NQH hDw+qo54lC+3InBmnbxDGvV45j+YjUEpyAeXdgnBmSRJeFqGNwkHVcLPnnIW4O3rP33P 3oy+lQ7pODZL73rYpAQoPDzDroB4ddih0cvvJ5+SSTsc1McCkAZ76Xi6HArQzkWncM/l tIws937Xk0C+Fu8FCqqe6KFHchIEyKYBs+45v8HfGEZYlYCJPvqY5Z2RidI9JrpHKUAM /KbegFBBlNEgDei1a6i8ru7V43gmi8Fxl2Sc3aYW0d4Ldk90C7grkE4blbuwkbYowAM7 cUwg== X-Gm-Message-State: AOJu0YyhXh4aoaii4/gCfVa+isP1psb008fUBZddqpHNdZ+xERczXUen 28agdzoEtBeoLQfAZJ1hK9gbpeEPH7I= X-Google-Smtp-Source: AGHT+IFHy+diY1X1clbYyGcP4xaAx2S8pX7statu7YI9R09UJwKjBt6tJ4N+q+rIybwXc6oD282OFg== X-Received: by 2002:a05:6870:9706:b0:1bb:4c5f:6db0 with SMTP id n6-20020a056870970600b001bb4c5f6db0mr17252602oaq.36.1694536063164; Tue, 12 Sep 2023 09:27:43 -0700 (PDT) Received: from [192.168.0.10] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id w12-20020a0568080d4c00b003a8657a8954sm4380921oik.5.2023.09.12.09.27.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Sep 2023 09:27:42 -0700 (PDT) Message-ID: Date: Tue, 12 Sep 2023 13:27:40 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20230906174431.45558-1-jamrial@gmail.com> <20230906174431.45558-4-jamrial@gmail.com> From: James Almer In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 03/10] 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 9/11/2023 4:19 PM, 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 1916aa2dc5..f78a027f64 100644 >> --- a/libavformat/avformat.h >> +++ b/libavformat/avformat.h >> @@ -164,6 +164,13 @@ >> * decoding functions avcodec_send_packet() or avcodec_decode_subtitle2() if the >> * caller wishes to decode the data. >> * >> + * There may be no overlap between the stream's @ref AVCodecParameters.side_data >> + * "side data" and @ref AVPacket.side_data "side data" in packets. I.e. a given >> + * side data is either exported by the demuxer in AVCodecParameters, then it never >> + * appears in the packets, or the side data is exported through the packets (always >> + * in the first packet where the value becomes known or changes), then it does not >> + * appear in AVCodecParameters. >> + * > > Is it actually certain that our demuxers currently abide by this? E.g. > in mpegts, stream parameters can change at any time, so why does it set > it at the stream level and not the packet level? Does mpegts change AVStream.codecpar mid demuxing? wouldn't that be an API violation? I assumed that was what AV_PKT_DATA_PARAM_CHANGE and AV_PKT_DATA_NEW_EXTRADATA packet side data were for. > >> * AVPacket.pts, AVPacket.dts and AVPacket.duration timing information will be >> * set if known. They may also be unset (i.e. AV_NOPTS_VALUE for >> * pts/dts, 0 for duration) if the stream does not provide them. The timing >> @@ -209,6 +216,11 @@ >> * AVCodecParameters, rather than using @ref avcodec_parameters_copy() during >> * remuxing: there is no guarantee that the codec context values remain valid >> * for both input and output format contexts. >> + * - There may be no overlap between AVCodecParameters.side_data and side data in >> + * packets. I.e. a given side data is either set by the caller in >> + * AVCodecParameters, then it never appears in the packets, or the side data is >> + * sent through the packets (always in the first packet where the value becomes >> + * known or changes), then it does not appear in AVCodecParameters. > > I have to say, I don't really like this (and of course I am aware that > you are basically copying the doxy of AVPacketSideData here). As you I can remove this part, to be added later if needed. > know, the Matroska muxer needs to add header fields in order to add > certain packet side data to blocks later. In case of seekable output, > one can update the header later, but in case of unseekable output that > is not true. I'd like there to be an easy way for the user to signal the > intention to send packet side data of a specific type later. Maybe a new AVFMT_FLAG_? > >> * - The caller may fill in additional information, such as @ref >> * AVFormatContext.metadata "global" or @ref AVStream.metadata "per-stream" >> * metadata, @ref AVFormatContext.chapters "chapters", @ref >> @@ -937,6 +949,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). >> @@ -953,13 +966,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 >> @@ -1715,11 +1735,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_set_get() >> */ >> +attribute_deprecated >> void av_format_inject_global_side_data(AVFormatContext *s); >> +#endif >> >> /** >> * Returns the method used to set ctx->duration. >> @@ -1844,6 +1871,7 @@ const AVClass *av_stream_get_class(void); >> */ >> AVStream *avformat_new_stream(AVFormatContext *s, const AVCodec *c); >> >> +#if FF_API_AVSTREAM_SIDE_DATA >> /** >> * Wrap an existing array as stream side data. >> * >> @@ -1856,7 +1884,10 @@ AVStream *avformat_new_stream(AVFormatContext *s, const AVCodec *c); >> * >> * @return zero on success, a negative AVERROR code on failure. On failure, >> * the stream is unchanged and the data remains owned by the caller. >> + * @deprecated use av_packet_side_data_set_add() with the stream's >> + * @ref AVCodecParameters.side_data "codecpar side data" >> */ >> +attribute_deprecated >> int av_stream_add_side_data(AVStream *st, enum AVPacketSideDataType type, >> uint8_t *data, size_t size); >> >> @@ -1868,7 +1899,10 @@ int av_stream_add_side_data(AVStream *st, enum AVPacketSideDataType type, >> * @param size side information size >> * >> * @return pointer to fresh allocated data or NULL otherwise >> + * @deprecated use av_packet_side_data_set_new() with the stream's >> + * @ref AVCodecParameters.side_data "codecpar side data" >> */ >> +attribute_deprecated >> uint8_t *av_stream_new_side_data(AVStream *stream, >> enum AVPacketSideDataType type, size_t size); >> /** >> @@ -1880,9 +1914,13 @@ uint8_t *av_stream_new_side_data(AVStream *stream, >> * or to zero if the desired side data is not present. >> * >> * @return pointer to data if present or NULL otherwise >> + * @deprecated use av_packet_side_data_set_get() with the stream's >> + * @ref AVCodecParameters.side_data "codecpar side data" >> */ >> +attribute_deprecated >> uint8_t *av_stream_get_side_data(const AVStream *stream, >> enum AVPacketSideDataType type, size_t *size); >> +#endif >> >> AVProgram *av_new_program(AVFormatContext *s, int id); >> > > > _______________________________________________ > 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". _______________________________________________ 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".