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 8D59345F0A for ; Wed, 16 Aug 2023 16:15:34 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8D2F168C68D; Wed, 16 Aug 2023 19:15:31 +0300 (EEST) Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0C93468C3D0 for ; Wed, 16 Aug 2023 19:15:24 +0300 (EEST) Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-3fea0640d88so26476315e9.2 for ; Wed, 16 Aug 2023 09:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kynesim-co-uk.20221208.gappssmtp.com; s=20221208; t=1692202524; x=1692807324; h=content-transfer-encoding:mime-version:user-agent:message-id:date :subject:to:from:from:to:cc:subject:date:message-id:reply-to; bh=BaqTt1gIoieJ0p1Aszs8wOFMIuWRx0V2GDovvYYNEeI=; b=k64qmrTzZrNO37JXh5kDjiXcDvXJL3fpdbC3eYL0TniXsbtW1ERXafJKEPBfgAfn6e ExS5j2LLXKX0OGKHxHjE6E0Kkd6DRRki+yFCgT3LlaK6qZLTvQrQIvbwpth3UMvMsc/s GAmm2j306qIEFBZVw7G3sAcKg7gayCwNALR7NdgreCgjyEEQc5zmZrAGCV+xcXYyT9qN rSVVTR+yM+NDoPgt+RvzApChnXlpd0ddg0kfKymVNcelhSXw/ZbiMvOXkhevJflOB3tj yPVZNWs+28KzrIztreSUTwUdntpTmuVIH1aK/OrRamCqoe9HY6LXlbfD9GhO5xsTpg4r n8ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692202524; x=1692807324; h=content-transfer-encoding:mime-version:user-agent:message-id:date :subject:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BaqTt1gIoieJ0p1Aszs8wOFMIuWRx0V2GDovvYYNEeI=; b=GnXxMxsLglNnFrS7uGM6jOKrKeTAkPwY/hyGaSRMwFHyeUlApzYdN6ho5RH8z2mPTl FjSTtDNHXdYO6rGVRCsRES5rrwQEbQeCWsCwc3lJ2a5daBgC02zJbZt2OAv8v2Fft4Z+ 3M+p8QxhEyL8mB3iQ8igUtTeLPNbLxxuS1/I8gU1gk7l2LDRNN9WRi7LAW5RxUG9jKIv eI6ya7GnlOG4m/MSHr09lHbR2dsMaQyzgPYVtuKYv6OOJZYIfbXum9qeaiHZ74cdPron B7juH166gBk0af4zbIkGSzohhKHtfzEtEg2lWS/g+s7IUemY3ykPcBpfXP0fdpuEtlRo Zk9g== X-Gm-Message-State: AOJu0Yx59aMXfVzmvx7hjNeuMukcWpkJupIBP96l8225kvBvq1d970Yy 6TMlO6AR6x+ORO047X6UJVbZy+jQ+4vWM9T+eDA= X-Google-Smtp-Source: AGHT+IEtuHY61h4VEP+s+ubOoTnfiDDYKxAzi6S3oX0gr6VLtI5iMKqTVNO4cBtyuegXm15es8jeBg== X-Received: by 2002:adf:ef02:0:b0:30f:b7b4:3e55 with SMTP id e2-20020adfef02000000b0030fb7b43e55mr2147976wro.19.1692202524038; Wed, 16 Aug 2023 09:15:24 -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 z9-20020a5d44c9000000b00319779ee691sm10754394wrr.28.2023.08.16.09.15.23 for (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Wed, 16 Aug 2023 09:15:23 -0700 (PDT) From: John Cox To: ffmpeg-devel@ffmpeg.org Date: Wed, 16 Aug 2023 17:15:23 +0100 Message-ID: User-Agent: ForteAgent/8.00.32.1272 MIME-Version: 1.0 Subject: [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: 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? 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? I've tested by hand with libswscale/test/swscale but fate integration would be obviously better - I'm currently a bit lost in fate, where/how should I do this? Many thanks John Cox _______________________________________________ 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".