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 ED32446E4E for ; Wed, 16 Aug 2023 17:37:12 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 182DA68C6E9; Wed, 16 Aug 2023 20:37:10 +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 16A5B68C668 for ; Wed, 16 Aug 2023 20:37:04 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 7AA8460002 for ; Wed, 16 Aug 2023 17:37:03 +0000 (UTC) Date: Wed, 16 Aug 2023 19:37:02 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230816173702.GV7802@pb2> References: MIME-Version: 1.0 In-Reply-To: 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="===============4919003794054279956==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4919003794054279956== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3BodSnToB6Lb8Zxg" Content-Disposition: inline --3BodSnToB6Lb8Zxg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 others) > which appears to decode a file to RGB24, convert to YUV420P and take the > 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->YUV > then it should be good enough for RGB24->YUV too. However it breaks this > fate case - what is an acceptable way to resolve this? update the checksum (if needed), and put the code under appropriate bitexac= t flags checks (there may be remaining issues but hard to say without seeing and being abel to test the code) >=20 > A further question assuming that the above can be resolved - I have also > written aarch64 asm for this (RGB24/BGR24->YUV420P). It costs nothing in > the asm to round the output values to nearest rather than just rounding > down as the C template does and doing so improves the accuracy reported > by tests/swscale - however at that point the asm and the C don't produce > identical results. I assume that the x86 asm for BGR24 conversion does > match the C. What is the best thing to do here? The more differences there are between implementations the more annoying it is but there is a bitexact flag that allows differences thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew .= =2E." --3BodSnToB6Lb8Zxg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZN0JOQAKCRBhHseHBAsP q9fvAJ9aJx+VrPJ1jfpLMiF9p+ZgJPg3UwCfZX9dfW/Fcwogy1O9GBATWOcOYYo= =U+DD -----END PGP SIGNATURE----- --3BodSnToB6Lb8Zxg-- --===============4919003794054279956== 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". --===============4919003794054279956==--