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 4F3C54637E for ; Mon, 15 May 2023 18:59:56 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D303368BF92; Mon, 15 May 2023 21:59:53 +0300 (EEST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D5872688386 for ; Mon, 15 May 2023 21:59:46 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id D111D60004 for ; Mon, 15 May 2023 18:59:45 +0000 (UTC) Date: Mon, 15 May 2023 20:59:42 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230515185942.GO1391451@pb2> References: <20230507133255.20881-1-anton@khirnov.net> <20230507133255.20881-4-anton@khirnov.net> <20230508141542.GS1391451@pb2> <168362189020.3843.14417317264187506189@lain.khirnov.net> MIME-Version: 1.0 In-Reply-To: <168362189020.3843.14417317264187506189@lain.khirnov.net> Subject: Re: [FFmpeg-devel] [PATCH 04/13] lavf: use AV_CODEC_PROP_FIELDS where appropriate 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: multipart/mixed; boundary="===============6378230148402120099==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6378230148402120099== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nNefFv5r6Ea+vcVx" Content-Disposition: inline --nNefFv5r6Ea+vcVx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 09, 2023 at 10:44:50AM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-05-08 16:15:42) > > On Sun, May 07, 2023 at 03:32:46PM +0200, Anton Khirnov wrote: > > > H.264 and mpeg12 parsers need to be adjusted at the same time to stop > > > using the value of AVCodecContext.ticks_per_frame, because it is not = set > > > correctly unless the codec has been opened. Previously this would res= ult > > > in both the parser and lavf seeing the same incorrect value, which wo= uld > > > cancel out. > > > Updating lavf and not the parsers would result in correct value in la= vf, > > > but the wrong one in parsers, which would break some tests. > > > --- > > > libavcodec/h264_parser.c | 4 ++-- > > > libavcodec/mpegvideo_parser.c | 2 +- > > > libavformat/avformat.c | 9 ++++++--- > > > libavformat/demux.c | 29 +++++++++++++++++++---------- > > > libavformat/internal.h | 3 +++ > > > 5 files changed, 31 insertions(+), 16 deletions(-) > >=20 > > Doesnt this sort of change need a major ABI bump ? > > it sounds like lavc and lavf interdepend here both ways >=20 > No, we do not guarantee bug compatibility. >=20 > Libavformat seeing ticks_per_frame=3D1 for codecs that set it to 2 upon > being opened is a bug. Same for the parser. >=20 > It just so happens that libavformat AND its internal parser instance see > the same incorrect value and this cancels out in cases that are tested > by FATE (it would break if we had more thorough tests for repeating > single fields). This patch seems to change tbr =2E/ffmpeg -i fate-suite//h264/lossless.h264 Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuv420p(progressive), 640= x480, 25 fps, 60 tbr, 1200k tbn vs. Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuv420p(progressive), 640= x480, 25 fps, 120 tbr, 1200k tbn with=20 =2E/ffmpeg -i fate-suite//h264/lossless.h264 -f framecrc - The output uses 1/60 thats odd because if every frame can be represented in 1/60 then tbr is 1/60 or more course OTOH if tbr is finer than 1/60 then not every frame can be represented in 1= /60 maybe iam missing something but the new value seems worse and also not consistent with what ffmpeg actually uses thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. --nNefFv5r6Ea+vcVx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZGKBGgAKCRBhHseHBAsP qxQ/AJ9jGG2r3XmlbDyeZzB6l0iGbmwzTQCdH/OcQ5yLtpz56o94T62DEVG9Jos= =6DDl -----END PGP SIGNATURE----- --nNefFv5r6Ea+vcVx-- --===============6378230148402120099== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============6378230148402120099==--