Re: [FFmpeg-devel] [PATCH 2/2] lavc/pthread_frame: avoid leaving stale hwaccel state in worker threads
>
>
> av_packet_unref(p->avpkt);
> @@ -655,6 +670,14 @@ void ff_thread_finish_setup(AVCodecContext *avctx) {
> async_lock(p->parent);
> }
>
> +/* save hwaccel state for passing to the next thread;
> + * this is done here so that this worker thread can wipe its own
> hwaccel
> + * state after decoding, without requiring synchronization */
> +av_assert0(!p->parent->stash_hwaccel);
> +p->parent->stash_hwaccel = avctx->hwaccel;
> +p->parent->stash_hwaccel_context = avctx->hwaccel_context;
> +p->parent->stash_hwaccel_priv= avctx->internal->hwaccel_priv_data;
>
Assertion failure when seeking. Step to reproduce:
./ffmpeg -stream_loop -1 -an -hwaccel vaapi -i test.mp4 -f null >/dev/null
Regards
___
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] avcodec/vp8: Disable lf_delta for VP7
On Sun, Sep 11, 2022 at 06:38:39AM +0200, Andreas Rheinhardt wrote:
> Peter Ross:
> > On Sat, Sep 10, 2022 at 03:07:13AM +0200, Andreas Rheinhardt wrote:
> >> It is a VP8-only feature.
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> libavcodec/vp8.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> >> index c00c5c975e..04a2113cc8 100644
> >> --- a/libavcodec/vp8.c
> >> +++ b/libavcodec/vp8.c
> >> @@ -637,7 +637,6 @@ static int vp7_decode_frame_header(VP8Context *s,
> >> const uint8_t *buf, int buf_si
> >> for (i = 0; i < 2; i++)
> >> memcpy(s->prob->mvc[i], vp7_mv_default_prob[i],
> >> sizeof(vp7_mv_default_prob[i]));
> >> -memset(>lf_delta, 0, sizeof(s->lf_delta));
> >> memcpy(s->prob[0].scan, ff_zigzag_scan, sizeof(s->prob[0].scan));
> >> }
> >>
> >> @@ -2171,7 +2170,7 @@ void filter_level_for_mb(VP8Context *s,
> >> VP8Macroblock *mb,
> >> } else
> >> filter_level = s->filter.level;
> >>
> >> -if (s->lf_delta.enabled) {
> >> +if (!is_vp7 && s->lf_delta.enabled) {
> >> filter_level += s->lf_delta.ref[mb->ref_frame];
> >> filter_level += s->lf_delta.mode[mb->mode];
> >> }
> >
> > what's the motivation for patches 01 and 02?
> > are you not just adding another condition (is_vp7) to evaluate at decode
> > time?
> > if its improved readability, then suggest renaming 'lf_delta' to
> > 'lf_delta_vp8'
> >
> > pathces 3-18 look fine to me.
> >
>
> is_vp7 is evaluated at compile-time, because all the functions that use
> is_vp7 in this decoder are marked as av_always_inline.
> If it were otherwise, several of the patches 3-18 would make no sense
> and would just add another runtime check.
ok make sense
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: PGP signature
___
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 v3 2/3] lavf/dashdec: Multithreaded DASH initialization
Gesendet: Montag, 05. September 2022 um 12:45 Uhr
Von: "Andreas Rheinhardt"
An: ffmpeg-devel@ffmpeg.org
Betreff: Re: [FFmpeg-devel] [PATCH v3 2/3] lavf/dashdec: Multithreaded DASH
initialization
Lukas Fellechner:
>>> Moreover, older pthread standards did not allow to use
>>> PTHREAD_MUTEX_INITIALIZER with non-static mutexes, so I don't know
>>> whether we can use that. Also our pthreads-wrapper on top of
>>> OS/2-threads does not provide PTHREAD_COND_INITIALIZER (which is used
>>> nowhere in the codebase).
>>
>> I missed that detail about the initializer macro. Thank you for clearing
>> that up.
>>
>> After looking more into threads implementation in ffmpeg, I wonder if I
>> really need to check any results of init/destroy or other functions.
>> In slicethreads.c, there is zero checking on any of the lock functions.
>> The pthreads-based implementation does internally check the results of all
>> function calls and calls abort() in case of errors ("strict_" wrappers).
>> The Win32 implementation uses SRW locks which cannot even return errors.
>> And the OS2 implementation returns 0 on all calls as well.
>>
>> So right now, I think that I should continue with normal _init() calls
>> (no macros) and drop all error checking, just like slicethread does.
>> Are you fine with that approach?
>
> Zero checking is our old approach; the new approach checks for errors
> and ensures that only mutexes/condition variables that have been
> properly initialized are destroyed. See ff_pthread_init/free in
> libavcodec/pthread.c (you can't use this in libavformat, because these
> functions are local to libavcodec).
>
> - Andreas
I was able to switch to using the slicethread implementation. It has a
very minor delay on init, because it waits for all threads to fully start
up before continueing. But it is only few ms and not worth adding a new
implementation just for that.
I also changed the initialization and release of mutex and conds, with
full return code checking and safe release.
There was one cross-thread issue I needed to address.
A multi hour duration test (connecting in endless loop) did not show
any issues after fixing the avio_opts cross thread access.
Please see the v4 patch for all the changes.
- Lukas
___
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] slicethread: Limit the automatic number of threads to 16
>> 2. Spawning too many threads when "auto" is used in multiple places
>>
>> This can indeed be an efficiency problem, although probably not major.
>> Since usually only one part of the pipeline is active at any time,
>> many of the threads will be sleeping, consuming very little resources.
>
> For 32 bit processes running out of address space, yes, the issue is with
> "auto" being used in many places at once.
>
> But in general, allowing arbitrarily high numbers of auto threads isn't
> beneficial - the optimal cap of threads depends a lot on the content at
> hand.
>
> The system I'm testing on has 160 cores - and it's quite certain that
> doing slice threading with 160 slices doesn't make sense. Maybe the cap of
> 16 is indeed too low - I don't mind raising it to 32 or something like
> that. Ideally, the auto mechanism would factor in the resolution of the
> content.
>
> Just for arguments sake - here's the output from 'time ffmpeg ...' for a
> fairly straightforward transcode (decode, transpose, scale, encode), 1080p
> input 10bit, 720p output 8bit, with explicitly setting the number of
> threads ("ffmpeg -threads N -i input -threads N -filter_threads N
> output").
>
> 12:
> real 0m25.079s
> user 5m22.318s
> sys 0m5.047s
>
> 16:
> real 0m19.967s
> user 6m3.607s
> sys 0m9.112s
>
> 20:
> real 0m20.853s
> user 6m21.841s
> sys 0m28.829s
>
> 24:
> real 0m20.642s
> user 6m28.022s
> sys 1m1.262s
>
> 32:
> real 0m29.785s
> user 6m8.442s
> sys 4m45.290s
>
> 64:
> real 1m0.808s
> user 6m31.065s
> sys 40m44.598s
>
> I'm not testing this with 160 threads for each stage, since 64 already was
> painfully slow - while you suggest that using threads==cores always should
> be preferred, regardless of the number of cores. The optimum here seems to
> be somewhere between 16 and 20.
These are interesting scores. I would not have expected such a dramatic
effect of having too many threads. You are probably right that always using
the core count as auto threads is not such a good idea.
But the encoding part works on 720p, so there each of the 64 threads only
has 11 lines and 14.000 pixels to process, which is really not much.
I do not have a CPU with so many cores, but when doing 4K -> 4K transcode,
I sure see a benefit of using 32 vs 16 cores.
Maybe the best approach would really be to decide auto thread count
on the amount of pixels to process (I would not use line count because
when line count doubles, the pixel count usually goes up by factor 4).
This would probably need some more test data. I will also try to do some
testing on my side.
- Lukas
___
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] slicethread: Limit the automatic number of threads to 16
Gesendet: Dienstag, 06. September 2022 um 23:11 Uhr Von: "Andreas Rheinhardt" An: ffmpeg-devel@ffmpeg.org Betreff: Re: [FFmpeg-devel] [PATCH] slicethread: Limit the automatic number of threads to 16 Lukas Fellechner: >> 1. Running out of address space in 32-bit processes >> >> It probably makes sense to limit auto threads to 16, but it should only >> be done in 32-bit processes. A 64-bit process should never run out of >> address space. We should not cripple high end machines running >> 64-bit applications. >> >> >> Sidenotes about "it does not make sense to have more than 16 slices": >> >> On 8K video, when using 32 threads, each thread will process 256 lines >> or about 1MP (> FullHD!). Sure makes sense to me. But even for sw decoding >> 4K video, having more than 16 threads on a powerful machine makes sense. >> >> Intel's next desktop CPUs will have up to 24 physical cores. The >> proposed change would limit them to use only 16 cores, even on 64-bit. > > This part is completely wrong: You can always set the number of threads > manually. > (Btw: 1. 8K is the horizontal resolution; the vertical resolution of it > is 4360 (when using 16:9), so every thread processes 135 lines which > have as many pixels as 540 lines of FullHD. 2. FullHD has about 2MP.) > > - Andreas You are right. What I ment was: When someone does not explicitly set threads, then only 16 of his 24 cores will be used. I know that it is always possible to manually override the auto value without limits. And indeed I somehow confused the resolutions. Sill each thread would process 1MP of pixel data, which is a lot of data. - Lukas ___ 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".
[FFmpeg-devel] [PATCH v2] configure: try to use -flto=thin or -flto=auto if available
Signed-off-by: Kacper Michajłow --- configure | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 9e51abd0d3..a651fdec5a 100755 --- a/configure +++ b/configure @@ -7173,8 +7173,9 @@ check_optflags -fno-signed-zeros if enabled lto; then test "$cc_type" != "$ld_type" && die "LTO requires same compiler and linker" -check_cflags -flto -check_ldflags -flto $cpuflags +check_cflags -flto=thin || check_cflags -flto=auto || check_cflags -flto +check_ldflags -flto=thin || check_ldflags -flto=auto || check_ldflags -flto +check_ldflags $cpuflags disable inline_asm_direct_symbol_refs fi -- 2.37.3 ___ 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] Bonk, Bonk
On 9/7/22, Paul B Mahol wrote: > Patches attached. > > Could decoder be made faster? > Will apply soon. ___ 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]lavc/x86/simple_idct: Fix linking shared libavcodec with MS link.exe
Am So., 11. Sept. 2022 um 17:29 Uhr schrieb Andreas Rheinhardt : > > Carl Eugen Hoyos: > > From 421041e7cd1bce8952756e60a0dd428f1618d75a Mon Sep 17 00:00:00 2001 > > From: Carl Eugen Hoyos > > Date: Sun, 11 Sep 2022 16:02:09 +0200 > > Subject: [PATCH] lavc/x86/simple_idct: Fix linking shared libavcodec with MS > > link.exe > > > > link.exe hangs on empty simple_idct.o > > > > Fixes ticket #9909. > > --- > > libavcodec/x86/simple_idct.asm | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/x86/simple_idct.asm b/libavcodec/x86/simple_idct.asm > > index dcf0da6df1..982b2f0bbb 100644 > > --- a/libavcodec/x86/simple_idct.asm > > +++ b/libavcodec/x86/simple_idct.asm > > @@ -25,9 +25,9 @@ > > > > %include "libavutil/x86/x86util.asm" > > > > -%if ARCH_X86_32 > > SECTION_RODATA > > > > +%if ARCH_X86_32 > > cextern pb_80 > > > > wm1010: dw 0, 0x, 0, 0x > > Thanks for bisecting this. (I don't have a MSVC setup myself to do it.) > Looking at the patch makes me feel that the very same issue might > happen with simple_idct10.asm when one tries to link a 32bit build. No, that works fine (32bit creates a symbol in the empty object files iiuc). I will not look into another solution, I am happy if you find one. Thank you, Carl Eugen ___ 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".
[FFmpeg-devel] [PATCH] fate/spdif: Add spdif tests
These tests test both the demuxer as well as the muxer wherever possible. It is not always possible due to the fact that the muxer supports more codecs than the demuxer. The spdif demuxer does currently not set the need_parsing flag. If one were to set this to AVSTREAM_PARSE_FULL, the test results would change as follows: - For spdif-aac-remux, the packets are currently padded to 16bits, i.e. if the actual packet size is odd, there is a padding byte. The parser splits this byte away into a one byte packet of its own. Insanely, these one byte packets get the same duration as normal packets, i.e. timing is ruined. - The DCA-remux tests get proper duration/timestamps. - In the spdif-mp2-remux test the demuxer marks the stream as being MP2; the parser sets it to MP3 and this triggers the "Codec change in IEC 61937" codepath; this test therefore returns only two packets with the parser. - For spdif-mp3-remux some bytes end up in different packets: Some input packets of this file have an odd length (417B instead of 418B like all the other packets) and are padded to 418B. Without a parser, all returned packets from the spdif-demuxer are 418B. With a parser, the packets that were originally 417B are 417B again, but the padding byte has not been discarded, but added to the next packet which is now 419B. This fixes "Multiple frames in a packet" warning and avoids an "Invalid data found when processing input" error when decoding. Signed-off-by: Andreas Rheinhardt --- tests/Makefile |1 + tests/fate/spdif.mak | 44 + tests/ref/fate/spdif-aac-remux | 93 ++ tests/ref/fate/spdif-ac3-remux | 63 ++ tests/ref/fate/spdif-dca-core-bswap|1 + tests/ref/fate/spdif-dca-core-remux| 14 + tests/ref/fate/spdif-dca-master|1 + tests/ref/fate/spdif-dca-master-core |1 + tests/ref/fate/spdif-dca-master-core-remux | 1179 tests/ref/fate/spdif-eac3 |1 + tests/ref/fate/spdif-mlp |1 + tests/ref/fate/spdif-mp2-remux | 49 + tests/ref/fate/spdif-mp3-remux | 47 + tests/ref/fate/spdif-truehd|1 + 14 files changed, 1496 insertions(+) create mode 100644 tests/fate/spdif.mak create mode 100644 tests/ref/fate/spdif-aac-remux create mode 100644 tests/ref/fate/spdif-ac3-remux create mode 100644 tests/ref/fate/spdif-dca-core-bswap create mode 100644 tests/ref/fate/spdif-dca-core-remux create mode 100644 tests/ref/fate/spdif-dca-master create mode 100644 tests/ref/fate/spdif-dca-master-core create mode 100644 tests/ref/fate/spdif-dca-master-core-remux create mode 100644 tests/ref/fate/spdif-eac3 create mode 100644 tests/ref/fate/spdif-mlp create mode 100644 tests/ref/fate/spdif-mp2-remux create mode 100644 tests/ref/fate/spdif-mp3-remux create mode 100644 tests/ref/fate/spdif-truehd diff --git a/tests/Makefile b/tests/Makefile index d9c509a415..06494a9cc4 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -231,6 +231,7 @@ include $(SRC_PATH)/tests/fate/real.mak include $(SRC_PATH)/tests/fate/screen.mak include $(SRC_PATH)/tests/fate/segment.mak include $(SRC_PATH)/tests/fate/source.mak +include $(SRC_PATH)/tests/fate/spdif.mak include $(SRC_PATH)/tests/fate/speedhq.mak include $(SRC_PATH)/tests/fate/subtitles.mak include $(SRC_PATH)/tests/fate/truehd.mak diff --git a/tests/fate/spdif.mak b/tests/fate/spdif.mak new file mode 100644 index 00..093b8138e8 --- /dev/null +++ b/tests/fate/spdif.mak @@ -0,0 +1,44 @@ +# This padds the AAC frames to 16 bit words (the actual size is +# still available in the ADTS headers). +FATE_SPDIF_REMUX-$(call ALLYES, AAC_DEMUXER AAC_DECODER) += fate-spdif-aac-remux +fate-spdif-aac-remux: CMD = transcode aac $(TARGET_SAMPLES)/aac/foo.aac spdif "-c copy" "-c copy" + +FATE_SPDIF_REMUX-$(call ALLYES, AC3_DEMUXER AC3_DECODER) += fate-spdif-ac3-remux +fate-spdif-ac3-remux: CMD = transcode ac3 $(TARGET_SAMPLES)/ac3/monsters_inc_5.1_448_small.ac3 spdif "-c copy" "-c copy" + +FATE_SPDIF_REMUX-$(call ALLYES, DTS_DEMUXER DCA_DECODER) += fate-spdif-dca-core-remux +fate-spdif-dca-core-remux: CMD = transcode dts $(TARGET_SAMPLES)/dts/dcadec-suite/core_51_24_48_768_0.dtshd spdif "-c copy" "-c copy" + +FATE_SPDIF-$(call DEMMUX, DTSHD, SPDIF) += fate-spdif-dca-core-bswap +fate-spdif-dca-core-bswap: CMD = md5 -i $(TARGET_SAMPLES)/dts/dcadec-suite/core_51_24_48_768_0.dtshd -c copy -spdif_flags +be -f spdif + +# Only the core will be transferred, extensions are discarded. +FATE_SPDIF_REMUX-$(call ALLYES, DTS_DEMUXER DCA_DECODER) += fate-spdif-dca-master-core-remux +fate-spdif-dca-master-core-remux: CMD = transcode dts $(TARGET_SAMPLES)/dts/master_audio_7.1_24bit.dts spdif "-c copy" "-c copy" + +FATE_SPDIF-$(call DEMMUX, DTS, SPDIF) += fate-spdif-dca-master fate-spdif-dca-master-core +fate-spdif-dca-master: CMD = md5 -i
[FFmpeg-devel] [PATCH] swscale: add missing opaque parameter after f2de911818
Fixes function prototype mismatch, warning Wlto-type-mismatch.
Signed-off-by: Kacper Michajłow
---
libswscale/x86/rgb2rgb_template.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libswscale/x86/rgb2rgb_template.c
b/libswscale/x86/rgb2rgb_template.c
index 4aba25dd51..f6c843e4f2 100644
--- a/libswscale/x86/rgb2rgb_template.c
+++ b/libswscale/x86/rgb2rgb_template.c
@@ -1823,7 +1823,7 @@ void RENAME(ff_nv12ToUV)(uint8_t *dstU, uint8_t *dstV,
const uint8_t *src1,
const uint8_t *src2,
int w,
- uint32_t *unused2);
+ uint32_t *unused2, void *opq);
static void RENAME(deinterleaveBytes)(const uint8_t *src, uint8_t *dst1,
uint8_t *dst2,
int width, int height, int srcStride,
int dst1Stride, int dst2Stride)
@@ -1831,7 +1831,7 @@ static void RENAME(deinterleaveBytes)(const uint8_t *src,
uint8_t *dst1, uint8_t
int h;
for (h = 0; h < height; h++) {
-RENAME(ff_nv12ToUV)(dst1, dst2, NULL, src, NULL, width, NULL);
+RENAME(ff_nv12ToUV)(dst1, dst2, NULL, src, NULL, width, NULL, NULL);
src += srcStride;
dst1 += dst1Stride;
dst2 += dst2Stride;
--
2.37.3
___
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".
[FFmpeg-devel] [PATCH] configure: use -flto=auto if available
Signed-off-by: Kacper Michajłow --- configure | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 9e51abd0d3..bf5a687239 100755 --- a/configure +++ b/configure @@ -7173,8 +7173,9 @@ check_optflags -fno-signed-zeros if enabled lto; then test "$cc_type" != "$ld_type" && die "LTO requires same compiler and linker" -check_cflags -flto -check_ldflags -flto $cpuflags +check_cflags -flto=auto || check_cflags -flto +check_ldflags -flto=auto || check_ldflags -flto +check_ldflags $cpuflags disable inline_asm_direct_symbol_refs fi -- 2.37.3 ___ 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]lavc/x86/simple_idct: Fix linking shared libavcodec with MS link.exe
Carl Eugen Hoyos: > From 421041e7cd1bce8952756e60a0dd428f1618d75a Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Sun, 11 Sep 2022 16:02:09 +0200 > Subject: [PATCH] lavc/x86/simple_idct: Fix linking shared libavcodec with MS > link.exe > > link.exe hangs on empty simple_idct.o > > Fixes ticket #9909. > --- > libavcodec/x86/simple_idct.asm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/x86/simple_idct.asm b/libavcodec/x86/simple_idct.asm > index dcf0da6df1..982b2f0bbb 100644 > --- a/libavcodec/x86/simple_idct.asm > +++ b/libavcodec/x86/simple_idct.asm > @@ -25,9 +25,9 @@ > > %include "libavutil/x86/x86util.asm" > > -%if ARCH_X86_32 > SECTION_RODATA > > +%if ARCH_X86_32 > cextern pb_80 > > wm1010: dw 0, 0x, 0, 0x Thanks for bisecting this. (I don't have a MSVC setup myself to do it.) Looking at the patch makes me feel that the very same issue might happen with simple_idct10.asm when one tries to link a 32bit build. IMO modifying the Makefile to no longer build these files if they are empty would be better. - Andreas ___ 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] avcodec/vp8: Disable lf_delta for VP7
Hi,
On Sun, Sep 11, 2022 at 10:41 AM Ronald S. Bultje
wrote:
> Hi,
>
> On Sun, Sep 11, 2022 at 12:38 AM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Peter Ross:
>> > On Sat, Sep 10, 2022 at 03:07:13AM +0200, Andreas Rheinhardt wrote:
>> >> It is a VP8-only feature.
>> >>
>> >> Signed-off-by: Andreas Rheinhardt
>> >> ---
>> >> libavcodec/vp8.c | 3 +--
>> >> 1 file changed, 1 insertion(+), 2 deletions(-)
>> >>
>> >> diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
>> >> index c00c5c975e..04a2113cc8 100644
>> >> --- a/libavcodec/vp8.c
>> >> +++ b/libavcodec/vp8.c
>> >> @@ -637,7 +637,6 @@ static int vp7_decode_frame_header(VP8Context *s,
>> const uint8_t *buf, int buf_si
>> >> for (i = 0; i < 2; i++)
>> >> memcpy(s->prob->mvc[i], vp7_mv_default_prob[i],
>> >> sizeof(vp7_mv_default_prob[i]));
>> >> -memset(>lf_delta, 0, sizeof(s->lf_delta));
>> >> memcpy(s->prob[0].scan, ff_zigzag_scan,
>> sizeof(s->prob[0].scan));
>> >> }
>> >>
>> >> @@ -2171,7 +2170,7 @@ void filter_level_for_mb(VP8Context *s,
>> VP8Macroblock *mb,
>> >> } else
>> >> filter_level = s->filter.level;
>> >>
>> >> -if (s->lf_delta.enabled) {
>> >> +if (!is_vp7 && s->lf_delta.enabled) {
>> >> filter_level += s->lf_delta.ref[mb->ref_frame];
>> >> filter_level += s->lf_delta.mode[mb->mode];
>> >> }
>> >
>> > what's the motivation for patches 01 and 02?
>> > are you not just adding another condition (is_vp7) to evaluate at
>> decode time?
>> > if its improved readability, then suggest renaming 'lf_delta' to
>> 'lf_delta_vp8'
>> >
>> > pathces 3-18 look fine to me.
>> >
>>
>> is_vp7 is evaluated at compile-time
>>
>
> This should probably be changed to be uppercase then. Lowercase suggests
> it's a variable.
>
It's inline, not macro, apparently.
I don't like the impact on readability here. Part of me wonders whether it
doesn't make more sense to split this file in vp7.c, vp8.c and vp78.c, and
have a proper design of two decoders and separate/shared parent/child
contexts definitions... A classic FFmpeg dilemma, I guess. The problem is
basically that this complicates people who have to debug this code when
issues occur (me) at the benefit of losing some dead code in vp7. I'm not
super-excited about that...
Ronald
___
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] avcodec/vp8: Disable lf_delta for VP7
Hi,
On Sun, Sep 11, 2022 at 12:38 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Peter Ross:
> > On Sat, Sep 10, 2022 at 03:07:13AM +0200, Andreas Rheinhardt wrote:
> >> It is a VP8-only feature.
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> libavcodec/vp8.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> >> index c00c5c975e..04a2113cc8 100644
> >> --- a/libavcodec/vp8.c
> >> +++ b/libavcodec/vp8.c
> >> @@ -637,7 +637,6 @@ static int vp7_decode_frame_header(VP8Context *s,
> const uint8_t *buf, int buf_si
> >> for (i = 0; i < 2; i++)
> >> memcpy(s->prob->mvc[i], vp7_mv_default_prob[i],
> >> sizeof(vp7_mv_default_prob[i]));
> >> -memset(>lf_delta, 0, sizeof(s->lf_delta));
> >> memcpy(s->prob[0].scan, ff_zigzag_scan,
> sizeof(s->prob[0].scan));
> >> }
> >>
> >> @@ -2171,7 +2170,7 @@ void filter_level_for_mb(VP8Context *s,
> VP8Macroblock *mb,
> >> } else
> >> filter_level = s->filter.level;
> >>
> >> -if (s->lf_delta.enabled) {
> >> +if (!is_vp7 && s->lf_delta.enabled) {
> >> filter_level += s->lf_delta.ref[mb->ref_frame];
> >> filter_level += s->lf_delta.mode[mb->mode];
> >> }
> >
> > what's the motivation for patches 01 and 02?
> > are you not just adding another condition (is_vp7) to evaluate at decode
> time?
> > if its improved readability, then suggest renaming 'lf_delta' to
> 'lf_delta_vp8'
> >
> > pathces 3-18 look fine to me.
> >
>
> is_vp7 is evaluated at compile-time
>
This should probably be changed to be uppercase then. Lowercase suggests
it's a variable.
Ronald
___
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".
[FFmpeg-devel] [PATCH 2/5] avcodec/wavpack: Fix overflow in k=31
Untested with "non fuzzed" samples as i have no such file Fixes: shift exponent 32 is too large for 32-bit type 'int' Fixes: 50930/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-6319201949712384 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/wavpack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c index 7aa1f65e17b..b4d19df7ea2 100644 --- a/libavcodec/wavpack.c +++ b/libavcodec/wavpack.c @@ -126,7 +126,7 @@ static av_always_inline unsigned get_tail(GetBitContext *gb, unsigned k) if (k < 1) return 0; p = av_log2(k); -e = (1 << (p + 1)) - k - 1; +e = (1LL << (p + 1)) - k - 1; res = get_bits_long(gb, p); if (res >= e) res = (res << 1) - e + get_bits1(gb); -- 2.17.1 ___ 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]lavc/x86/simple_idct: Fix linking shared libavcodec with MS link.exe
Am So., 11. Sept. 2022 um 16:26 Uhr schrieb James Almer : > > On 9/11/2022 11:17 AM, Carl Eugen Hoyos wrote: > > Hi! > > > > Attached patch fixes ticket #9909 for me, regression since 4618f36a > > > > Please comment, Carl Eugen > > It would help if the patch was attached :p Good point! Carl Eugen 0001-lavc-x86-simple_idct-Fix-linking-shared-libavcodec-w.patch Description: Binary data ___ 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".
[FFmpeg-devel] [PATCH 5/5] tools/target_dec_fuzzer: Adjust threshold for Jpeg2000
Fixes: Timeout
Fixes:
50955/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5148704872464384
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 5b335d3130c..3d4521887a2 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -242,7 +242,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_IFF_ILBM:maxpixels /= 128; break;
case AV_CODEC_ID_INDEO4: maxpixels /= 128; break;
case AV_CODEC_ID_INTERPLAY_ACM: maxsamples /= 16384; break;
-case AV_CODEC_ID_JPEG2000:maxpixels /= 16;break;
+case AV_CODEC_ID_JPEG2000:maxpixels /= 4096; break;
case AV_CODEC_ID_LAGARITH:maxpixels /= 1024; break;
case AV_CODEC_ID_LOCO:maxpixels /= 1024; break;
case AV_CODEC_ID_VORBIS: maxsamples /= 1024; break;
--
2.17.1
___
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".
[FFmpeg-devel] [PATCH 4/5] avcodec/hdrdec: Update w in inner loop of decompress()
Fixes: out of array access
Fixes:
50936/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HDR_fuzzer-5423041009549312
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hdrdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hdrdec.c b/libavcodec/hdrdec.c
index 9b262f2ef2c..7727826e2a5 100644
--- a/libavcodec/hdrdec.c
+++ b/libavcodec/hdrdec.c
@@ -70,8 +70,8 @@ static int decompress(uint8_t *scanline, int w,
GetByteContext *gb, const uint8_
for (int i = run << rshift; i > 0 && w > 0 && scanline >= start +
4; i--) {
memcpy(scanline, scanline - 4, 4);
scanline += 4;
+w -= 4;
}
-w -= run << rshift;
rshift += 8;
if (rshift > 16)
break;
--
2.17.1
___
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".
[FFmpeg-devel] [PATCH 1/5] avformat/mxfdec: Avoid some redundant writing to tables in mxf_compute_ptses_fake_index()
Signed-off-by: Michael Niedermayer
---
libavformat/mxfdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index e63e803aa56..4ceb6cf672f 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1939,10 +1939,10 @@ static int mxf_compute_ptses_fake_index(MXFContext
*mxf, MXFIndexTable *index_ta
if (index_table->nb_ptses <= 0)
return 0;
-if (!(index_table->ptses = av_calloc(index_table->nb_ptses,
sizeof(int64_t))) ||
+if (!(index_table->ptses = av_malloc_array(index_table->nb_ptses,
sizeof(int64_t))) ||
!(index_table->fake_index = av_calloc(index_table->nb_ptses,
sizeof(AVIndexEntry))) ||
!(index_table->offsets= av_calloc(index_table->nb_ptses,
sizeof(int8_t))) ||
-!(flags = av_calloc(index_table->nb_ptses,
sizeof(uint8_t {
+!(flags = av_malloc_array(index_table->nb_ptses,
sizeof(uint8_t {
av_freep(_table->ptses);
av_freep(_table->fake_index);
av_freep(_table->offsets);
--
2.17.1
___
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".
[FFmpeg-devel] [PATCH 3/5] avcodec/wavpack: Check for end of input in wv_unpack_dsd_high()
Fixes: Timeout
Fixes:
50793/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-4980185027444736
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/wavpack.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index b4d19df7ea2..3cb40775506 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -495,6 +495,8 @@ static int wv_unpack_dsd_high(WavpackFrameContext *s,
uint8_t *dst_left, uint8_t
sp[0].fltr0 = 0;
}
+if (DSD_BYTE_READY(high, low) &&
!bytestream2_get_bytes_left(>gbyte))
+return AVERROR_INVALIDDATA;
while (DSD_BYTE_READY(high, low) &&
bytestream2_get_bytes_left(>gbyte)) {
value = (value << 8) | bytestream2_get_byte(>gbyte);
high = (high << 8) | 0xff;
@@ -530,6 +532,8 @@ static int wv_unpack_dsd_high(WavpackFrameContext *s,
uint8_t *dst_left, uint8_t
sp[1].fltr0 = 0;
}
+if (DSD_BYTE_READY(high, low) &&
!bytestream2_get_bytes_left(>gbyte))
+return AVERROR_INVALIDDATA;
while (DSD_BYTE_READY(high, low) &&
bytestream2_get_bytes_left(>gbyte)) {
value = (value << 8) | bytestream2_get_byte(>gbyte);
high = (high << 8) | 0xff;
--
2.17.1
___
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]lavc/x86/simple_idct: Fix linking shared libavcodec with MS link.exe
On 9/11/2022 11:17 AM, Carl Eugen Hoyos wrote: Hi! Attached patch fixes ticket #9909 for me, regression since 4618f36a Please comment, Carl Eugen It would help if the patch was attached :p ___ 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]lavc/x86/simple_idct: Fix linking shared libavcodec with MS link.exe
Am So., 11. Sept. 2022 um 16:17 Uhr schrieb Carl Eugen Hoyos : > > Attached patch fixes ticket #9909 for me, regression since 4618f36a Sorry, it was bfb28b5ce89f3e950214b67ea95b45e3355c2caf Carl Eugen ___ 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".
[FFmpeg-devel] [PATCH]lavc/x86/simple_idct: Fix linking shared libavcodec with MS link.exe
Hi! Attached patch fixes ticket #9909 for me, regression since 4618f36a Please comment, Carl Eugen ___ 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 v2] avformat/riffdec: don't unconditionally overwrite WAVEFORMATEXTENSIBLE layout
On 9/10/2022 10:56 AM, James Almer wrote:
Do it only if the value conflicts with the previous channels value.
Fixes ticket #9912
Signed-off-by: James Almer
---
libavformat/riffdec.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavformat/riffdec.c b/libavformat/riffdec.c
index 3946ecb72f..c1e4a04550 100644
--- a/libavformat/riffdec.c
+++ b/libavformat/riffdec.c
@@ -102,6 +102,8 @@ int ff_get_wav_header(AVFormatContext *s, AVIOContext *pb,
return AVERROR_INVALIDDATA;
}
+av_channel_layout_uninit(>ch_layout);
+
par->codec_type = AVMEDIA_TYPE_AUDIO;
if (!big_endian) {
id = avio_rl16(pb);
@@ -189,9 +191,12 @@ int ff_get_wav_header(AVFormatContext *s, AVIOContext *pb,
if (par->codec_id == AV_CODEC_ID_ADPCM_G726 && par->sample_rate)
par->bits_per_coded_sample = par->bit_rate / par->sample_rate;
-av_channel_layout_uninit(>ch_layout);
-par->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
-par->ch_layout.nb_channels = channels;
+/* ignore WAVEFORMATEXTENSIBLE layout if different from channel count */
+if (channels != par->ch_layout.nb_channels) {
+av_channel_layout_uninit(>ch_layout);
+par->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
+par->ch_layout.nb_channels = channels;
+}
return 0;
}
Will apply
___
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 2/5] avcodec/dstdec: Check for overflow in build_filter()
Rémi Denis-Courmont: > Hi, > > Down-casting to a signed type (here, int16_t) is implementation-defined. And > while normal compilers do the expected thing, with modulo-2^n complement, > sanitizers tend to dislike it. > 1. We expect the implementation-defined behaviour for signed types to match the typical two's complement behaviour, see https://ffmpeg.org/developer.html#C-language-features 2. In this case, there is no real-implementation-defined behaviour: While the value (int16_t)v is implementation defined, whether it coincides with v is not (it does so if and only if the value of v is representable in an int16_t). 3. What sanitizers dislike it? After all, this is an explicit cast, so e.g. UBSan would never report it as suspicious. > AFAIK, the clean solution is via an union whence you assign the uint16_t > member, and then read the int16_t member. Fortunately, GCC and LLVM are able > to optimise that construct back to a single sign-extension. > Type-punning via unions is implementation-defined, too. It will work with two's complement types (as long as the number where all value bits are unset and the sign bit is set is not a trap representation (all exact-width intN_t are of this type)). - Andreas ___ 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 2/5] avcodec/dstdec: Check for overflow in build_filter()
Hi, Down-casting to a signed type (here, int16_t) is implementation-defined. And while normal compilers do the expected thing, with modulo-2^n complement, sanitizers tend to dislike it. AFAIK, the clean solution is via an union whence you assign the uint16_t member, and then read the int16_t member. Fortunately, GCC and LLVM are able to optimise that construct back to a single sign-extension. Br, ___ 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] libavfilter/vf_colorrange_cuda: CUDA-accelerated video filter for MPEG and JPEG color range conversions
Thanks for the detailed review, Timo. Please find fixed patch in attachement. От: ffmpeg-devel от имени Timo Rothenpieler Отправлено: 10 сентября 2022 г. 16:16 Кому: FFmpeg development discussions and patches ; Roman Arzumanyan Копия: Yogender Gupta ; Sven Middelberg ; Hermann Held Тема: Re: [FFmpeg-devel] [PATCH] libavfilter/vf_colorrange_cuda: CUDA-accelerated video filter for MPEG and JPEG color range conversions External email: Use caution opening links or attachments On 10.09.2022 10:16, Roman Arzumanyan wrote: > From 2b15d8a609a12d97b1ba7500c7f8771b336e2fdf Mon Sep 17 00:00:00 2001 > From: Roman Arzumanyan > Date: Sat, 10 Sep 2022 11:05:56 +0300 > Subject: [PATCH] libavfilter/vf_colorrange_cuda CUDA-accelerated color range > conversion filter We could also call this colorspace_cuda, since it does overlap with what the colorspace software filter does, just not nearly to the same degree of feature-completeness. That's fine in my book though, and if someone cares enough, the other features of the colorspace filter can be added over time. > --- > configure | 2 + > libavfilter/Makefile | 3 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_colorrange_cuda.c | 432 ++ > libavfilter/vf_colorrange_cuda.cu | 93 +++ > 5 files changed, 531 insertions(+) > create mode 100644 libavfilter/vf_colorrange_cuda.c > create mode 100644 libavfilter/vf_colorrange_cuda.cu > > diff --git a/configure b/configure > index 9d6457d81b..e5f9738ad1 100755 > --- a/configure > +++ b/configure > @@ -3155,6 +3155,8 @@ transpose_npp_filter_deps="ffnvcodec libnpp" > overlay_cuda_filter_deps="ffnvcodec" > overlay_cuda_filter_deps_any="cuda_nvcc cuda_llvm" > sharpen_npp_filter_deps="ffnvcodec libnpp" > +colorrange_cuda_filter_deps="ffnvcodec" > +colorrange_cuda_filter_deps_any="cuda_nvcc cuda_llvm" Typically should be sorted in by alphapetical ordering. > amf_deps_any="libdl LoadLibrary" > nvenc_deps="ffnvcodec" > diff --git a/libavfilter/Makefile b/libavfilter/Makefile > index 30cc329fb6..784e154d81 100644 > --- a/libavfilter/Makefile > +++ b/libavfilter/Makefile > @@ -230,6 +230,9 @@ OBJS-$(CONFIG_COLORMAP_FILTER) += > vf_colormap.o > OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o > OBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o > colorspacedsp.o > OBJS-$(CONFIG_COLORTEMPERATURE_FILTER) += vf_colortemperature.o > +OBJS-$(CONFIG_COLORRANGE_CUDA_FILTER)+= vf_colorrange_cuda.o \ > +vf_colorrange_cuda.ptx.o \ > +cuda/load_helper.o Same here on alphabetical ordering, should be between colormatrix and colorspace. > OBJS-$(CONFIG_CONVOLUTION_FILTER)+= vf_convolution.o > OBJS-$(CONFIG_CONVOLUTION_OPENCL_FILTER) += vf_convolution_opencl.o > opencl.o \ > opencl/convolution.o > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c > index 5ebacfde27..5e9cbe57ec 100644 > --- a/libavfilter/allfilters.c > +++ b/libavfilter/allfilters.c > @@ -213,6 +213,7 @@ extern const AVFilter ff_vf_colormap; > extern const AVFilter ff_vf_colormatrix; > extern const AVFilter ff_vf_colorspace; > extern const AVFilter ff_vf_colortemperature; > +extern const AVFilter ff_vf_colorrange_cuda; > extern const AVFilter ff_vf_convolution; > extern const AVFilter ff_vf_convolution_opencl; > extern const AVFilter ff_vf_convolve; > diff --git a/libavfilter/vf_colorrange_cuda.c > b/libavfilter/vf_colorrange_cuda.c > new file mode 100644 > index 00..949e7d3bbf > --- /dev/null > +++ b/libavfilter/vf_colorrange_cuda.c > @@ -0,0 +1,432 @@ > +/* > + * Copyright (c) 2022, NVIDIA CORPORATION. All rights reserved. > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
