[FFmpeg-devel] [PATCH] checkasm: Increase the tolerance for ac3_sum_square_butterfly_float
Increase the tolerance from 10 ulp to 11 ulp. This fixes occasional
errors for some inputs; the errors could be reproduced on
aarch64/neon builds, with "checkasm --test=ac3dsp 3446175925".
---
tests/checkasm/ac3dsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/checkasm/ac3dsp.c b/tests/checkasm/ac3dsp.c
index 442e965f3b..8c682d03cd 100644
--- a/tests/checkasm/ac3dsp.c
+++ b/tests/checkasm/ac3dsp.c
@@ -181,7 +181,7 @@ static void
check_ac3_sum_square_butterfly_float(AC3DSPContext *c) {
call_ref(v1, lt, rt, ELEMS);
call_new(v2, lt, rt, ELEMS);
-if (!float_near_ulp_array(v1, v2, 10, 4))
+if (!float_near_ulp_array(v1, v2, 11, 4))
fail();
bench_new(v2, lt, rt, ELEMS);
--
2.39.3 (Apple Git-146)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase
On Mon, 11 Mar 2024, Anton Khirnov wrote: I think the point is, that one can't just dismiss that anybody would want to encode mpeg4 video any longer, even if it is obsolete. I also would like to keep being able to do that. That capability is not going away though, and I'm not arguing that it should. Ok, good. The generally dismissive arguments about mpeg4 encoding being obsolete and something that nobody should be doing, could be interpreted in such a way. That said, I haven't followed the discussion closely enough about what to do with the time bases. The only change is that in some rare cases the automatically selected timebase no longer fits into mpeg4 constraints, so the user has to specify either the framerate or the timebase explicitly. Right, I see. Specifically, the commandline used by Michael involves the extremely obscure case of converting subtitles to video (NOT harsubbing, but really 1 sub -> 1 video). Since subtitle encoding API is hardcoded to AV_TIME_BASE_Q, that timebase gets used for encoding, and the mpeg4 encoder rejects it. If it was hardsubbing (i.e. 1 video + 1 sub -> 1 video), the input video timebase should be used, which would probably work. I don't think it's that big of a deal to require users to specify the timebase or framerate explicitly in such a sitation. Inventing new APIs to cover it automagically seems like a waste of time, unless somebody has actual (not potential) uses for this. Right, I would agree with this. (If someone else would volunteer to add said API I would consider accepting it though.) Is this a usecase that currently works, but would be go away by getting rid of codec specific code in the tools, or is it a nice-to-have new extra feature that is being requested? // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate/subtitles: Ignore line endings for sub-scc test
On Tue, 13 Feb 2024, Andreas Rheinhardt wrote: Since 7bf1b9b35769b37684dd2f18a54f01d852a540c8, the test produces ordinary \n, yet this is not what the reference file used for the most time, leading to test failures. Signed-off-by: Andreas Rheinhardt --- tests/fate/subtitles.mak | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak index cea4c810dd..90412e9ac1 100644 --- a/tests/fate/subtitles.mak +++ b/tests/fate/subtitles.mak @@ -114,6 +114,7 @@ fate-sub-charenc: CMD = fmtstdout ass -sub_charenc cp1251 -i $(TARGET_SAMPLES)/s FATE_SUBTITLES-$(call DEMDEC, SCC, CCAPTION) += fate-sub-scc fate-sub-scc: CMD = fmtstdout ass -ss 57 -i $(TARGET_SAMPLES)/sub/witch.scc +fate-sub-scc: CMP = diff FATE_SUBTITLES-$(call DEMMUX, SCC, SCC) += fate-sub-scc-remux fate-sub-scc-remux: CMD = fmtstdout scc -i $(TARGET_SAMPLES)/sub/witch.scc -ss 4:00 -map 0 -c copy -- 2.34.1 Looks ok to me, as a temporary measure until we figure out the best way to upgrade everybody's workdirs without needing interaction. (As an added note to the other thread; even if we could easily patch fate.sh, every current user's workdir is also prone to this issue, and the way of fixing it is kinda non-obvious.) // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfoundation: Fix version checks
On Fri, 15 Dec 2023, Zhao Zhili wrote: On Dec 15, 2023, at 18:11, Martin Storsjö wrote: _VERSION_MAX_ALLOWED indicates what version is available in the SDK, while _VERSION_MIN_REQUIRED is the version we can assume is available, i.e. similar to what is set with e.g. -miphoneos-version-min on the command line. ^ I think we need some utils for version check on Apple’s multiple target OS. It’s hard to get it right and very lengthy to write. Ping Marvin since he is expert on this subject. And can we setup a group of CI for these platforms? That would be good. We do have a mac mini running fate tests; it would probably be good to add test configurations that build for both macOS and iOS, for both whatever the latest version in the installed SDK is, and with an old deployment target (those builds often get broken). (And then, someone would need to check the FATE status as well.) // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/6] lavc/aarch64: new optimization for 8-bit hevc_pel_bi_pixels
On Wed, 22 Nov 2023, Logan.Lyu wrote: I can't reproduce the error you mentioned... I can apply patches to the ffmpeg master branch normally using 'git apply xxx.patch/.eml' or 'git am xxx.patch/.eml'. I guess you have emails that haven't been through the complete delivery chain, while some later party might have rewritten things. By the way, I create these patches by /'git format-patch -s -o "../" --add-header "X-Unsent: 1" --suffix .eml --to ffmpeg-devel@ffmpeg.org -6 --filename-max-length=100' /to generate .eml file. And /'git format-patch -4 --filename-max-length=100' /to generate .patch file as attachment to prevent encoding format problems in email files. These command should be OK, right? That's right for generating the patch files. I guess the problem here isn't about the patch files themselves, but the email delivery of them. Can you try these patches again? If the error still occurs, please tell me how it occurred then I will fixed it. I also tried applying them now with "git am", and I got this: Applying: lavc/aarch64: new optimization for 8-bit hevc_pel_bi_pixels error: corrupt patch at line 194 Patch failed at 0001 lavc/aarch64: new optimization for 8-bit hevc_pel_bi_pixels hint: Use 'git am --show-current-patch=diff' to see the failed patch Thus, same issue here. In earlier iterations, the patches have arrived correctly when you have sent them as attachments, instead of when sending them as plain inline patches with git send-email. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] checkasm: hevc_sao: Fix a regression in hevc_sao_edge
On Thu, 24 Aug 2023, Matthias Dressel wrote: From: Matthias Dressel check_func() might return NULL, in which case the function is not to be benched. Introduced in cc679054c715acda9438e566b8de3a9eba421ac3. Signed-off-by: Matthias Dressel --- tests/checkasm/hevc_sao.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/checkasm/hevc_sao.c b/tests/checkasm/hevc_sao.c index cfee2ddf50..94aa1942e1 100644 --- a/tests/checkasm/hevc_sao.c +++ b/tests/checkasm/hevc_sao.c @@ -134,8 +134,8 @@ static void check_sao_edge(HEVCDSPContext *h, int bit_depth) if (memcmp(dst0 + j*stride, dst1 + j*stride, w*SIZEOF_PIXEL)) fail(); } +bench_new(dst1, src1 + offset, stride, offset_val, eo, block_size, block_size); } -bench_new(dst1, src1 + offset, stride, offset_val, eo, block_size, block_size); } } } -- 2.41.0 LGTM, pushed. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
