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 4CEBA453CF for ; Fri, 27 Jan 2023 18:41:39 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B034968BE57; Fri, 27 Jan 2023 20:41:36 +0200 (EET) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E2BA568BD9D for ; Fri, 27 Jan 2023 20:41:29 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id 88304E8596 for ; Fri, 27 Jan 2023 19:41:28 +0100 (CET) X-Virus-Scanned: amavisd-new at passwd.hu Received: from iq.passwd.hu ([127.0.0.1]) by localhost (iq.passwd.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TIaDQL0B8dj for ; Fri, 27 Jan 2023 19:41:27 +0100 (CET) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id 2D8CBE8592 for ; Fri, 27 Jan 2023 19:41:27 +0100 (CET) Date: Fri, 27 Jan 2023 19:41:27 +0100 (CET) From: Marton Balint To: FFmpeg development discussions and patches In-Reply-To: <34dbdb79-0784-e5f2-3a2c-7754dc614da3@gmail.com> Message-ID: References: <20230126224649.1887-1-cus@passwd.hu> <167481406537.4503.11256345603659215829@lain.khirnov.net> <167484266801.26119.8016486821936065381@lain.khirnov.net> <34dbdb79-0784-e5f2-3a2c-7754dc614da3@gmail.com> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [BUMP PATCH 1/2] avcodec: change AVCodecContext.frame_number to int64_t 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 Fri, 27 Jan 2023, James Almer wrote: > On 1/27/2023 3:04 PM, Anton Khirnov wrote: >> Quoting Marton Balint (2023-01-27 18:59:39) >>> >>> >>> On Fri, 27 Jan 2023, Anton Khirnov wrote: >>> >>>> I still think we should do a deprecation+replacement like we do for >>>> everything else. >>> >>> You mean you want to introduce a new 64 bit member and deprecate the old >>> 32 bit field? >>> >>> E.g. >>> >>> int64_t frame_num; >>> >>> attribute_deprcated >>> int frame_number >>> >>> And during the transition you want to sync the value between the 64bit >>> and >>> the 32bit ? >> >> yes > > We did make changes like int -> size_t without adding new fields in places > like AVBufferRef. See 14040a1d91. Or AVFormatContext bit_rate sometime before. > It does however probably need an FF_API_ dance, much like in that example. If no new field is added, and no old field is deprecated, then if the type change is done directly before the bump, then the dance is not needed, beacuse you'd just remove the dance at the bump. Regards, Marton _______________________________________________ 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".