- 09 Nov, 2023 16 commits
-
-
Niklas Haas authored
When using vf_scale to force a specific output color space, also tag this on the AVFrame. (Mirroring existing logic for output range) Move the sanity fix for RGB after the new assignment, to avoid leaking bogus YUV colorspace metadata for RGB spaces.
-
Niklas Haas authored
No need to write a custom string parser when we can just use an integer option with preset values. The various bits of fallback logic are wholly redundant with equivalent logic already inside sws_getCoefficients. Note: I disallowed setting 'out_color_matrix=auto', because this does not do anything meaningful in the current code (just hard-codes AVCOL_SPC_BT470BG fallback).
-
Niklas Haas authored
Alpha planes must always be full range, so complain loudly if fed limited range grayscale input.
-
Niklas Haas authored
Alpha planes are explicitly full range, even for limited range YUVA formats. Mark them as such.
-
Niklas Haas authored
The documentation states that invalid entries default to SWS_CS_DEFAULT. A value of 0 is not a valid SWS_CS_*, yet the code incorrectly hard-codes it to BT.709 coefficients instead of SWS_CS_DEFAULT.
-
Niklas Haas authored
This was a complete hack seemingly designed to work around a different bug, which was fixed in the previous commit. As such, there is no more reason not to do this, as it simply breaks changing color range in sws_setColorspaceDetails for no reason.
-
Niklas Haas authored
More commonly, this fixes the case of sws_setColorspaceDetails after sws_getContext, since the latter implies sws_init_context. The problem here is that sws_init_context sets up the range conversion and fast path tables based on the values of srcRange/dstRange at init time. This may result in locking in a "wrong" path (either using unscaled fast path when range conversion later required, or using scaled slow path when range conversion becomes no longer required). There are two way outs: 1. Always initialize range conversion and unscaled converters, even if they will be unused, and extend the runtime check. 2. Re-do initialization if the values change after sws_setColorspaceDetails. I opted for approach 1 because it was simpler and easier to reason about. Reword the av_log message to make it clear that this special converter is not necessarily used, depending on whether or not there is range conversion or YUV matrix conversion going on.
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Marvin Scholz authored
Adds another test that uses the start_duration and stop_duration options instead of start and stop. Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
Marvin Scholz authored
The check if drawing needs to be initialized and supported formats should be drawable ones was flawed, as pad_stop/pad_start is only populated from stop_duration/start_duration after these checks. To fix that, check the _duration variants as well and for better readability and maintainability break the check out into its own helper. Fixes a regression from 86b252ea Fix #10621 Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
Lynne authored
We calculated offsets as pairs, but addressed them in the shader as single float values, while reading them as ivec2s. Also removes unused code (was provisionally added if cooperative matrices could be used, but that turned out to be impossible).
-
Víctor Manuel Jáquez Leal authored
Rather than the VkFormatFeatureFlagBits enum Signed-off-by:
Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
-
Zhao Zhili authored
VK_KHR_PORTABILITY_ENUMERATION_EXTENSION_NAME is required on macOS, and VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR flag should be set. Signed-off-by:
Zhao Zhili <zhilizhao@tencent.com>
-
- 08 Nov, 2023 10 commits
-
-
Frank Plowman authored
Texinfo 7.0 produces quite different HTML to Texinfo 6.8. Without this change, enumerated option flags (i.e. Possible values of x are...) render as white text on a white background with Texinfo 7.0 and are unreadable. This change removes a style for the selector `.table .table` which causes the background to turn white for these elements. As far as I can tell, it is not actually used anywhere in files generated by Texinfo 6.8. Signed-off-by:
Frank Plowman <post@frankplowman.com>
-
Frank Plowman authored
Resolves trac ticket #10636 (http://trac.ffmpeg.org/ticket/10636). Texinfo 7.0, released in November 2022, changed the names of various functions. Compiling docs with Texinfo 7.0 resulted in warnings and improperly formatted documentation. More old names appear to have been removed in Texinfo 7.1, released October 2023, which causes docs compilation to fail. This commit addresses the issue by adding logic to switch between the old and new function names depending on the Texinfo version. Texinfo 6.8 produces identical documentation before and after the patch. CC https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1938238.html https://bugs.gentoo.org/916104Signed-off-by:
Frank Plowman <post@frankplowman.com>
-
Anton Khirnov authored
By intent, and in practice, the "active contributor" criterion applies to the person authoring the commits, not the one pushing them into the repository.
-
James Almer authored
Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
Mapping to ITU-R BS.2051-3 "Sound System G" and ITU-R BS.1196-8 "Channel Configuration 20". Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
Mapping to ITU-R BS.2051-3 "Sound System F" and ITU-R BS.1196-8 "Channel Configuration 15". Signed-off-by:
James Almer <jamrial@gmail.com>
-
Henrik Gramner authored
When operating on large blocks of data it's common to repeatedly use an instruction on multiple registers. Using the REPX macro makes it easy to quickly write dense code to achieve this without having to explicitly duplicate the same instruction over and over. For example, REPX {paddw x, m4}, m0, m1, m2, m3 REPX {mova [r0+16*x], m5}, 0, 1, 2, 3 will expand to paddw m0, m4 paddw m1, m4 paddw m2, m4 paddw m3, m4 mova [r0+16*0], m5 mova [r0+16*1], m5 mova [r0+16*2], m5 mova [r0+16*3], m5 Commit taken from x264: https://code.videolan.org/videolan/x264/-/commit/6d10612ab0007f8f60dd2399182efd696da3ffe4Signed-off-by:
Frank Plowman <post@frankplowman.com> Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
Zhao Zhili authored
Signed-off-by:
Zhao Zhili <zhilizhao@tencent.com>
-
Peter Ross authored
Partially fixes ticket #798 Reviewed-by:
James Almer <jamrial@gmail.com> Reviewed-by:
Michael Niedermayer <michael@niedermayer.cc> Reviewed-by:
Paul B Mahol <onemda@gmail.com> Signed-off-by:
Peter Ross <pross@xvid.org>
-
- 07 Nov, 2023 1 commit
-
-
Zhao Zhili authored
Signed-off-by:
Zhao Zhili <zhilizhao@tencent.com>
-
- 06 Nov, 2023 3 commits
-
-
Rémi Denis-Courmont authored
This uses a more traditional approach allowing up processing of up to period minus two elements per iteration. This also allows the algorithm to work for all and any vector length. As the T-Head C908 device under test can load 16 elements loop, there is unsurprisingly a little performance drop when the period is minimal and the parallelism is capped at 13 elements: Before: postfilter_15_c: 21222.2 postfilter_15_rvv_f32: 22007.7 postfilter_512_c: 20189.7 postfilter_512_rvv_f32: 22004.2 postfilter_1022_c: 20189.7 postfilter_1022_rvv_f32: 22004.2 After: postfilter_15_c: 20189.5 postfilter_15_rvv_f32: 7057.2 postfilter_512_c: 20189.5 postfilter_512_rvv_f32: 5667.2 postfilter_1022_c: 20192.7 postfilter_1022_rvv_f32: 5667.2
-
Rémi Denis-Courmont authored
As in the aligned case, we can use VLSE64.V, though the way of doing so gets more convoluted, so the performance gains are more modest: get_pixels_unaligned_c: 126.7 get_pixels_unaligned_rvv_i32: 145.5 (before) get_pixels_unaligned_rvv_i64: 62.2 (after) For the reference, those are the aligned benchmarks (unchanged) on the same T-Head C908 hardware: get_pixels_c: 126.7 get_pixels_rvi: 85.7 get_pixels_rvv_i64: 33.2
-
Rémi Denis-Courmont authored
hf_g_filt_c: 1552.5 hf_g_filt_rvv_f32: 679.5
-
- 05 Nov, 2023 5 commits
-
-
Paul B Mahol authored
Makes better results in final output if multiple filters are cascaded at once.
-
Paul B Mahol authored
-
Anton Khirnov authored
Explicitly state what the implications of this are.
-
Anton Khirnov authored
Partially fixes #10617
-
Rob Hall authored
Without this flag, timestamps were embedded into the final binary if CUDA was enabled. Signed-off-by:
Rob Hall <robxnanocode@outlook.com> Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
- 04 Nov, 2023 5 commits
-
-
Paul B Mahol authored
More user-friendly and self-explanatory what certain mode does.
-
Paul B Mahol authored
-
Andreas Rheinhardt authored
Fixes: VUI extension leak Fixes: 63004/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-4928832253329408 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Redundant since ea043cc5 (which made 16x16 no longer use MMX). Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-