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 D1BCA40D3D for ; Thu, 17 Aug 2023 09:42:25 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B1D8368C74A; Thu, 17 Aug 2023 12:42:22 +0300 (EEST) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id DD13068C5FB for ; Thu, 17 Aug 2023 12:42:15 +0300 (EEST) Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-3fe8a1591c8so59395235e9.3 for ; Thu, 17 Aug 2023 02:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kynesim-co-uk.20221208.gappssmtp.com; s=20221208; t=1692265334; x=1692870134; h=content-transfer-encoding:mime-version:user-agent:in-reply-to :references:message-id:date:subject:to:from:from:to:cc:subject:date :message-id:reply-to; bh=uZ7uAyzdnd57rFpafH0G3p8/cimFWX6i92++yaA3SkQ=; b=THxFQ8XDiKRJnuU0afy+MM5RKyDBxzeBdx7ANKn/S8eaEJasd9AE5zQOCUhUuhIJyl z4gI1Cc82ZRGNX995epVEFanyGhV682m1SsSUVac7GJePfbmNS0V/RVq7Hre0WQfiqQX Ly6VpVDg/2kKgtusmLxBRYLmYEQpQvZOJRzv+NdeDK41/z2B55fH7GZKFi0rVtu7ZDps ilKx3pgY/THagyv1ysWESftF87tKkxMLUnl5ZW8iM6LX5P6aSimnsfFp5juLQMKEyWC1 uFnIocu+B7gg18HZsMcDdZs5fH/dkqTsm7en9CmOmu2a3NFXZxGWwZekTXkKEepiphf/ 4ZAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692265334; x=1692870134; h=content-transfer-encoding:mime-version:user-agent:in-reply-to :references:message-id:date:subject:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=uZ7uAyzdnd57rFpafH0G3p8/cimFWX6i92++yaA3SkQ=; b=HKjeFJ4C/tO/5Ae2yanEUqeAeGJhzTqdE4O5e06P/wJ1pIUSGF53HVb768WhaxW8/S 0OSvb4JaFzJxtZ31Mc7mgMSZsk0km1TOyyWJkA6xyMigJ9mE0ZJsvBwJZ2DXiBw6fB+F vB5em582qoA/LiAfqpYO2xgCS2kgWEX2y5YZKTi1LdpyXtW1qejrSBzNie48xUbIf13V 2ohXbhCWylywAV2+oB5hElrjcupzIto7UuEx5W/LAVEgNZgm1bF+ibwWHCzu6d6yugUR m0gN5h0V1hDwMtAz6T+QmLQ81qhLC6e33ujZ1HKaSPEN+Dvs05VNJ9SEf1uBopxFmUPr 57Yw== X-Gm-Message-State: AOJu0YwsPh6GqzDgZxxYd0PPe08hoJSnJMnSPztIn6Xf3MV01aLqzJff t/PQWNxT5rQeCRA+lhotCS6nrZbxEqRPfUn++04= X-Google-Smtp-Source: AGHT+IGZWSr7S182r9DiSw73/AW4Sl/b8MGTozL+K47wwtdbvDtLkgIXFIthdQ3m+XRdjbv08XyH4g== X-Received: by 2002:a05:600c:3792:b0:3fe:1deb:86 with SMTP id o18-20020a05600c379200b003fe1deb0086mr3600904wmr.28.1692265334259; Thu, 17 Aug 2023 02:42:14 -0700 (PDT) Received: from CTHALPA.outer.uphall.net (cpc1-cmbg20-2-0-cust759.5-4.cable.virginm.net. [86.21.218.248]) by smtp.gmail.com with ESMTPSA id f25-20020a7bcd19000000b003fe2f3a89d4sm2383582wmj.7.2023.08.17.02.42.13 for (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 17 Aug 2023 02:42:13 -0700 (PDT) From: John Cox To: FFmpeg development discussions and patches Date: Thu, 17 Aug 2023 10:42:13 +0100 Message-ID: <1eqrdidm87gilrdg7k8qc6tovvbbmbu8s2@4ax.com> References: <20230816173702.GV7802@pb2> In-Reply-To: <20230816173702.GV7802@pb2> User-Agent: ForteAgent/8.00.32.1272 MIME-Version: 1.0 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Wed, 16 Aug 2023 19:37:02 +0200, you wrote: >On Wed, Aug 16, 2023 at 05:15:23PM +0100, John Cox wrote: >> Hi >> >> 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. >> >> 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 bitexact flags checks >(there may be remaining issues but hard to say without seeing and being >abel to test the code) Thanks for the prompt answer. The current test invocation goes: /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 - 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: /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=sws_flags=bitexact -pix_fmt yuv420p -bitexact -f framecrc - i.e. adding an explicit "-vf scale=sws_flags=bitexact". Is this the correct answer or is it a bug that the auto conversion fails to respect the existing bitexact flag? >> 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 Thanks John Cox >thx > >[...] _______________________________________________ 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".