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 C4A0146756 for ; Thu, 17 Aug 2023 17:13:44 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0F780689B46; Thu, 17 Aug 2023 20:13:42 +0300 (EEST) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3C80468C6B2 for ; Thu, 17 Aug 2023 20:13:35 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 8F3E5240003 for ; Thu, 17 Aug 2023 17:13:34 +0000 (UTC) Date: Thu, 17 Aug 2023 19:13:33 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230817171333.GX7802@pb2> References: <20230816173702.GV7802@pb2> <1eqrdidm87gilrdg7k8qc6tovvbbmbu8s2@4ax.com> MIME-Version: 1.0 In-Reply-To: <1eqrdidm87gilrdg7k8qc6tovvbbmbu8s2@4ax.com> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [RFC] swscale RGB24->YUV420P 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="===============8090068327357972872==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============8090068327357972872== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Y8Avk0Nco21EJORf" Content-Disposition: inline --Y8Avk0Nco21EJORf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 17, 2023 at 10:42:13AM +0100, John Cox wrote: > On Wed, 16 Aug 2023 19:37:02 +0200, you wrote: >=20 > >On Wed, Aug 16, 2023 at 05:15:23PM +0100, John Cox wrote: > >> Hi > >>=20 > >> The Pi has a use for a fast RGB24->YUV420P path for encoding camera > >> video. There is an existing BGR24 converter but if I build a RGB24 > >> converter using the same logic (rearrange the conversion matrix and use > >> the same code) I get a fate fail on filter-fps-cfr (and possibly other= s) > >> which appears to decode a file to RGB24, convert to YUV420P and take t= he > >> CRC of that so almost any change to the conversion breaks this > >> (unrelated?) test. > >>=20 > >> My initial assumption was that if the code to conversion in > >> libswscale/rgb2rgb_template:bgr24toyv12_c was good enough for BGR24->Y= UV > >> then it should be good enough for RGB24->YUV too. However it breaks th= is > >> fate case - what is an acceptable way to resolve this? > > > >update the checksum (if needed), and put the code under appropriate bite= xact flags checks > >(there may be remaining issues but hard to say without seeing and being > >abel to test the code) >=20 > Thanks for the prompt answer. The current test invocation goes: >=20 > /home/jc/work/rpi/ffmpeg2/out/x86/ffmpeg -nostdin -nostats > -noauto_conversion_filters -cpuflags all -auto_conversion_filters > -hwaccel none -threads 1 -thread_type frame+slice -i > /home/jc/rpi/conform/fate-suite/qtrle/apple-animation-variable-fps-bug.mov > -r 30 -vsync cfr -pix_fmt yuv420p -bitexact -f framecrc - >=20 > Which appears, at first sight, to already have the required bitexact > flag in it, however it doesn't get passed to the swscale context - in > order for that to happen I need something like: >=20 > /home/jc/work/rpi/ffmpeg2/out/x86/ffmpeg -fflags bitexact -nostdin > -nostats -noauto_conversion_filters -cpuflags all > -auto_conversion_filters -hwaccel none -threads 1 -thread_type > frame+slice -i > /home/jc/rpi/conform/fate-suite/qtrle/apple-animation-variable-fps-bug.mov > -r 30 -vsync cfr -vf scale=3Dsws_flags=3Dbitexact -pix_fmt yuv420p -bitex= act > -f framecrc - >=20 > i.e. adding an explicit "-vf scale=3Dsws_flags=3Dbitexact". Is this the > correct answer or is it a bug that the auto conversion fails to respect > the existing bitexact flag? It would be ideal that the main "-bitexact" gets passed to sws_flags a patch fixing that would be welcome! But one needs to still be able to remove the bitexact flag from sws_flags, only the default should change when -bitexact is specfied and nothing specific is specified for sws= _flags thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle --Y8Avk0Nco21EJORf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZN5VOQAKCRBhHseHBAsP q3CXAKCXk3UEH9pZp5lxTDD07eoDUZzTngCePHylyIT8UUDzcqyRnoNO1ZTtmRI= =e3Bq -----END PGP SIGNATURE----- --Y8Avk0Nco21EJORf-- --===============8090068327357972872== 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". --===============8090068327357972872==--