Re: [FFmpeg-devel] [PATCH v1] avcodec/av1dec: Add tile list OBU to decompose list

[Andreas Rheinhardt]

Wang, Fei W:
> On Thu, 2023-12-21 at 20:14 +0100, Andreas Rheinhardt wrote:
>> Wang, Fei W:
>>> On Wed, 2023-12-20 at 17:11 +0100, Andreas Rheinhardt wrote:
 fei.w.wang-at-intel@ffmpeg.org:
> From: Fei Wang 
>
> Show the unsupported message and return unsupported for clips
> contain
> tile list OBU since it hasn't been implemented. Otherwise,
> decoding
> maybe successful but result is incorrect.
>
> Signed-off-by: Fei Wang 
> ---
>  libavcodec/av1dec.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> index 4dcde234c6..629e37c3f8 100644
> --- a/libavcodec/av1dec.c
> +++ b/libavcodec/av1dec.c
> @@ -805,6 +805,7 @@ static const CodedBitstreamUnitType
> decompose_unit_types[] = {
>  AV1_OBU_SEQUENCE_HEADER,
>  AV1_OBU_TEMPORAL_DELIMITER,
>  AV1_OBU_TILE_GROUP,
> +AV1_OBU_TILE_LIST,

 What do you need this for? Decomposing it would only change
 whether
 CodedBitstreamUnit.content is available, but you are only reading
 CodedBitstreamUnit.type.
>>>
>>> To show the unsupported error and let user know that there are tile
>>> list OBUs in bitstream that decoder can't handle them. Otherwise,
>>> like
>>> my commit mentioned, tile list obu bitsteam may be decoded
>>> 'successful'
>>> according to log.
>>>
>>
>> As I said: You do not need CodedBitstreamUnit.content for the error
>> message.
> 
> No, obu will be filtered if it is not listed in decompose, decoder
> can't receive its type neither.
> 

Did you test this? If so, this would be a violation of the documentation
of decompose_unit_types: "Types not in this list will be available in
bitstream form only." My reading of the code of
cbs_read_fragment_content() in cbs.c is that it does what it is supposed
to do.

If you were right, it would also mean that the current case for
AV1_OBU_TILE_LIST and AV1_OBU_PADDING is redundant (and that the default
case will be used instead).

- 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] lavc: remove the QOA decoder

[Anton Khirnov]

Hi Paul,
Quoting Paul B Mahol (2023-12-21 21:05:18)
> Say what serious feature you contributed ? - Nothing.

this is a personal attach. Personal attacks are not allowed on this
mailing list. Please refrain from them in the future.

-- 
Anton Khirnov
(CC member)
___
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: Generalize crash handling

[Rémi Denis-Courmont]

Le 21 décembre 2023 22:16:09 GMT+02:00, "Rémi Denis-Courmont"  
a écrit :
>Le tiistaina 19. joulukuuta 2023, 14.02.00 EET Martin Storsjö a écrit :
>> This replaces the riscv specific handling from
>> 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is
>> reverted, together with 286d6742218ba0235c32876b50bf593cb1986353)
>> with a different implementation of the same (plus a bit more), based
>> on the corresponding feature in dav1d's checkasm, supporting both Unix
>> and Windows.
>> 
>> See in particular dav1d commits
>> 0b6ee30eab2400e4f85b735ad29a68a842c34e21 and
>> 0421f787ea592fd2cc74c887f20b8dc31393788b, authored by
>> Henrik Gramner.
>> 
>> The overall approach is the same; set up a signal handler,
>> store the state with setjmp/sigsetjmp, jump out of the crashing
>> function with longjmp/siglongjmp.
>> 
>> The main difference is in what happens when the signal handler
>> is invoked. In the previous implementation, it would resume from
>> right before calling the crashing function, and then skip that call
>> based on the setjmp return value.
>> 
>> In the imported implementation from dav1d, we return to right before
>> the check_func() call, which will skip testing the current function
>> (as the pointer is the same as it was before).
>> 
>> Other differences are:
>> - Support for other signal handling mechanisms (Windows
>>   AddVectoredExceptionHandler)
>> - Using RtlCaptureContext/RtlRestoreContext instead of setjmp/longjmp
>>   on Windows with SEH (which adds the design limitation that it doesn't
>>   return a value like setjmp does)
>> - Only catching signals once per function - if more than one
>>   signal is delivered before signal handling is reenabled, any
>>   signal is handled as it would without our handler
>> - Not using an arch specific signal handler written in assembly
>> ---
>>  tests/checkasm/checkasm.c   | 100 ++--
>>  tests/checkasm/checkasm.h   |  79 ++---
>>  tests/checkasm/riscv/checkasm.S |  12 
>>  3 files changed, 140 insertions(+), 51 deletions(-)
>> 
>> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
>> index 6318d9296b..668034c67f 100644
>> --- a/tests/checkasm/checkasm.c
>> +++ b/tests/checkasm/checkasm.c
>> @@ -23,8 +23,10 @@
>>  #include "config.h"
>>  #include "config_components.h"
>> 
>> -#ifndef _GNU_SOURCE
>> -# define _GNU_SOURCE // for syscall (performance monitoring API),
>> strsignal() +#if CONFIG_LINUX_PERF
>> +# ifndef _GNU_SOURCE
>> +#  define _GNU_SOURCE // for syscall (performance monitoring API)
>> +# endif
>>  #endif
>> 
>>  #include 
>> @@ -326,6 +328,7 @@ static struct {
>>  const char *cpu_flag_name;
>>  const char *test_name;
>>  int verbose;
>> +int catch_signals;
>
>AFAICT, this needs to be volatile sigatomic_t
>
>>  } state;
>> 
>>  /* PRNG state */
>> @@ -627,6 +630,64 @@ static CheckasmFunc *get_func(CheckasmFunc **root,
>> const char *name) return f;
>>  }
>> 
>> +checkasm_context checkasm_context_buf;
>> +
>> +/* Crash handling: attempt to catch crashes and handle them
>> + * gracefully instead of just aborting abruptly. */
>> +#ifdef _WIN32
>> +#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
>> +static LONG NTAPI signal_handler(EXCEPTION_POINTERS *const e) {
>> +const char *err;
>> +
>> +if (!state.catch_signals)
>> +return EXCEPTION_CONTINUE_SEARCH;
>> +
>> +switch (e->ExceptionRecord->ExceptionCode) {
>> +case EXCEPTION_FLT_DIVIDE_BY_ZERO:
>> +case EXCEPTION_INT_DIVIDE_BY_ZERO:
>> +err = "fatal arithmetic error";
>> +break;
>> +case EXCEPTION_ILLEGAL_INSTRUCTION:
>> +case EXCEPTION_PRIV_INSTRUCTION:
>> +err = "illegal instruction";
>> +break;
>> +case EXCEPTION_ACCESS_VIOLATION:
>> +case EXCEPTION_ARRAY_BOUNDS_EXCEEDED:
>> +case EXCEPTION_DATATYPE_MISALIGNMENT:
>> +case EXCEPTION_STACK_OVERFLOW:
>> +err = "segmentation fault";
>> +break;
>> +case EXCEPTION_IN_PAGE_ERROR:
>> +err = "bus error";
>> +break;
>> +default:
>> +return EXCEPTION_CONTINUE_SEARCH;
>> +}
>> +state.catch_signals = 0;
>> +checkasm_fail_func("%s", err);
>> +checkasm_load_context();
>> +return EXCEPTION_CONTINUE_EXECUTION; /* never reached, but shuts up gcc
>> */ +}
>> +#endif
>> +#else
>> +static void signal_handler(const int s) {
>> +if (state.catch_signals) {
>> +state.catch_signals = 0;
>> +checkasm_fail_func("%s",
>> +   s == SIGFPE ? "fatal arithmetic error" :
>> +   s == SIGILL ? "illegal instruction" :
>> +   s == SIGBUS ? "bus error" :
>> + "segmentation fault");
>
>The current code for the error print-out is both simpler and more versatile, 
>so I don't get this.
>
>> +checkasm_load_context();
>> +} else {
>> +/* fall back to the default signal handler 

Re: [FFmpeg-devel] [PATCH] checkasm: Generalize crash handling

[Rémi Denis-Courmont]

Le 22 décembre 2023 00:03:59 GMT+02:00, Henrik Gramner via ffmpeg-devel 
 a écrit :
>On Thu, Dec 21, 2023 at 9:16 PM Rémi Denis-Courmont  wrote:
>> > +checkasm_fail_func("%s",
>> > +   s == SIGFPE ? "fatal arithmetic error" :
>> > +   s == SIGILL ? "illegal instruction" :
>> > +   s == SIGBUS ? "bus error" :
>> > + "segmentation fault");
>>
>> The current code for the error print-out is both simpler and more versatile,
>> so I don't get this.
>
>IMO "illegal instruction" is a far better error message than "fatal
>signal 4" (with an implementation-defined number which nobody knows
>the meaning of without having to look it up).

The current code prints the number and the name.

>
>> > +/* fall back to the default signal handler */
>> > +static const struct sigaction default_sa = { .sa_handler = SIG_DFL
>> > }; +sigaction(s, _sa, NULL);
>> > +raise(s);
>>
>> Why raise here? Returning from the handler will reevaluate the same code with
>> the same thread state, and trigger the default signal handler anyway (since
>> you don't modify the user context).
>
>No it wont, it'll get stuck in an infinite loop invoking the signal
>handler over and over. At least on my system.

No, it won't since the default signal handler was restored. And it's much less 
confusing to debug if the signal comes from where it was actually triggered 
than from explicit raise call.

>
>> > +const struct sigaction sa = {
>> > +.sa_handler = signal_handler,
>> > +.sa_flags = SA_NODEFER,
>>
>> That does not look very sane to me. If a recursive signal occurs, processing
>> it recursively is NOT a good idea. This would cause an infinite loop,
>> eventually a literal stack overflow after maxing out the processor for a 
>> while.
>> I'd rather let the OS kernel deal with the problem, by killing the process or
>> whatever the last resort is.
>>
>> > +#define checkasm_save_context() setjmp(checkasm_context_buf)
>> > +#define checkasm_load_context() longjmp(checkasm_context_buf, 1)
>> > +#endif
>>
>> Been there done that and it did not end well.
>> sigsetjmp() & co are necessary here.
>
>For all intents and purposes sigjmp()/longjmp() with SA_NODEFER does
>the same thing as sigsetjmp()/siglongjmp() without SA_NODEFER for this
>particular use case (no infinite recursion is possible the way the
>code is written). The change isn't necessary per se but it seems
>reasonable and I have no objections to it.
>___
>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 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/2] configure: Remove a redundant check for UWP mode

[Wu, Tong1]

>Subject: [FFmpeg-devel] [PATCH 1/2] configure: Remove a redundant check for
>UWP mode
>
>The check for UWP mode was duplicated from right above, in
>d54127c41a81cf2078a3504f78e0e4232cfe11b7.
>
>Also, instead of several lines with "enabled uwp && ...", make one
>"if enabled uwp; then" block.
>---
> configure | 30 +++---
> 1 file changed, 11 insertions(+), 19 deletions(-)
>
>diff --git a/configure b/configure
>index af0bebc1ac..69b755f274 100755
>--- a/configure
>+++ b/configure
>@@ -7102,9 +7102,8 @@ fi
>
> check_func_headers "windows.h" CreateDIBSection
>"$gdigrab_indev_extralibs"
>
>-# d3d11va requires linking directly to dxgi and d3d11 if not building for
>-# the desktop api partition
>-test_cpp <+# check if building for desktop or uwp
>+test_cpp < #ifdef WINAPI_FAMILY
> #include 
> #if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
>@@ -7117,23 +7116,16 @@ test_cpp  #endif
> EOF
>
>-# vaapi_win32 requires linking directly to dxgi if not building for
>-# the desktop api partition
>-test_cpp <-#ifdef WINAPI_FAMILY
>-#include 
>-#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
>-#error desktop, not uwp
>-#else
>-// WINAPI_FAMILY_APP, WINAPI_FAMILY_PHONE_APP => UWP
>-#endif
>-#else
>-#error no family set
>-#endif
>-EOF
>+mediafoundation_extralibs="-lmfuuid -lole32 -lstrmiids"
>
>-# mediafoundation requires linking directly to mfplat if building for uwp 
>target
>-enabled uwp && mediafoundation_extralibs="-lmfplat -lmfuuid -lole32 -
>lstrmiids" || mediafoundation_extralibs="-lmfuuid -lole32 -lstrmiids"
>+if enabled uwp; then
>+# In UWP mode, we can't use LoadLibrary+GetProcAddress to conditionally
>+# try to load these APIs at runtime, like we do in regular desktop mode -
>+# therefore, we need to link directly against these APIs.
>+d3d11va_extralibs="-ldxgi -ld3d11"
>+vaapi_win32_extralibs="-ldxgi"
>+mediafoundation_extralibs="-lmfplat $mediafoundation_extralibs"
>+fi
>
> enabled libdrm &&
> check_pkg_config libdrm_getfb2 libdrm "xf86drmMode.h"
>drmModeGetFB2
>--
>2.34.1

LGTM, 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-requ...@ffmpeg.org with subject "unsubscribe".
___
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: remove the QOA decoder

[Michael Niedermayer]

On Thu, Dec 21, 2023 at 08:43:16PM +0100, Tomas Härdin wrote:
> ons 2023-12-20 klockan 20:11 +0100 skrev Michael Niedermayer:
> > On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin wrote:
> > > tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George:
> > [...]
> > > [...] , but every line of code
> > > carries with it a non-zero maintenance burden
> > 
> > Assuming you mean with "non-zero" a "larger than zero" maintenance
> > burden
> > 
> > then we can proof this to be false
> 
> Doubt

ok
i seem to have said, "we". So lets do this together :)

heres an example (code by Dave Burton, not by me)

int main(int b,char**i){long long 
n=B,a=I^n,r=(a/b)>>4,y=atoi(*++i),_=(((a^n/b)*(y>>T)|y>>S))|(a^r);printf("%.8s\n",(char*)&_);}

clang -include stdio.h -include stdlib.h -Wall -Weverything -pedantic 
-DB=6945503773712347754LL -DI=5859838231191962459LL -DT=0 -DS=7 -o prog prog.c

try
./prog 1
./prog 2
./prog 3
...

Can you think of a way to add some lines of code to this that makes it more 
maintainable ?

if yes, then i think you proofed that adding code can reduce maintaince burden

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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] libavfilter/af_afir: R-V V dcmul_add

[flow gg]

It's at c908

According to the benchmark results, if vlseg2e64 is used, the speed is
almost as slow as C language (dcmul_add_rvv_f64: 86.2), if vsseg2e64 is
used, it will be only a bit slower (dcmul_add_rvv_f64: 50.2).

Rémi Denis-Courmont  于2023年12月22日周五 04:52写道：

> Le tiistaina 19. joulukuuta 2023, 4.53.12 EET flow gg a écrit :
> > c908:
> > dcmul_add_c: 88.0
> > dcmul_add_rvv_f64: 46.2
> >
> > Did not use vlseg2e64, because it is much slower than vlse64
> > Did not use vsseg2e64, because it is slightly slower than vsse64
>
> Is this about C910 or C908? I have not checked this specific function, but
> the
> general understanding for C908 has been the exact opposite so far, i.e.
> segmented accesses are fast, while strided accesses are (unsurprisingly)
> slow.
>
> See also
> https://camel-cdr.github.io/rvv-bench-results/canmv_k230/index.html
>
> --
> レミ・デニ-クールモン
> http://www.remlab.net/
>
>
>
> ___
> 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 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] Temporary delays in patch reviewing and testing by me

[Kieran Kunhya]

On Fri, 22 Dec 2023, 00:36 Michael Niedermayer, 
wrote:

> On Thu, Dec 21, 2023 at 03:22:20AM +0100, Michael Niedermayer wrote:
> > Hi all
> >
> > My main development machiene died today, so expect increased delays
> > about things that involve me/it until thats fixed
> >
> > Rest of the mail is just about the issue, and you can skip reading that
> >
> > Timeline:
> > box suddenly stopped, no reaction to any input or pings
> > power off and on did not bring it back, screen stayed dark, keyboard too
> > but fans spin up and theres power
> > opening it up i find it stuck on Q-code "0d" so i power it off
> > wiggle the ram modules a bit power it back on and it gets stuck on
> > qcode "15" i power cycle again and it reaches bios setup, so i go over
> all
> > values and just look but as i look, it hangs hard again
> > off/on again and we hit "0d" again
> > so i remove one of the CPU fans to get to the DIMM modules and
> reconfigure them like this:
> > B1A1 0+2 -> boot ok
> > B2A2 0+2 -> boot ok
> > B2A2 1+3 -> 0d
> > B2A2 0+3 -> boot ok
> > B1A1 1+2 -> 0d
> >
> > This is consistent with DIMM module 1 being faulty. But iam not 100%
> convinced
> > because this box never crashed not once, it was always rock solid and
> suddenly
> > one module is so faulty the box hangs so early.
> > Either way i ordered 4 new and bigger modules from 2 independant shops
> > they should be here soon but i dont know what "soon" is around christmess
> >
>
> > also i could try running it with just 2 modules, i might try that
> > tomorrow
>
> system seems working stable with 2 DIMM sticks
>

You should get comparable memory bandwidth with 2 sticks or 4 on consumer
grade systems. The differences are minor.

If you need to know which stick is bad memtest will tell you.

Kieran

>
___
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 6/6] lavc/takdsp: R-V V decorrelate_sm

[flow gg]

func ff_decorrelate_sm_rvv, zve32x
1:
vsetvli  t0, a2, e32, m8, ta, ma
vle32.v  v8, (a1)
sub a2,  a2, t0
vle32.v  v0, (a0)
vssra.vi  v8, v8, 1
vsub.vv  v16, v0, v8
vse32.v  v16, (a0)
sh2add   a0, t0, a0
vadd.vv  v16, v0, v8
vse32.v  v16, (a1)
sh2add   a1, t0, a1
bnez a2, 1b
ret
endfunc

Is this way? In this situation, or when using vsra, there will be some
tests that fail, and the result value differs by 1. I'm not sure where the
problem..

Rémi Denis-Courmont  于2023年12月22日周五 00:08写道：

> Le maanantaina 18. joulukuuta 2023, 17.16.27 EET flow gg a écrit :
> > C908:
> > decorrelate_sm_c: 130.0
> > decorrelate_sm_rvv_i32: 43.7
>
> +
> +func ff_decorrelate_sm_rvv, zve32x
> +1:
> +vsetvli  t0, a2, e32, m8, ta, ma
> +vle32.v  v0, (a0)
> +sub a2,  a2, t0
> +vle32.v  v8, (a1)
> +vsra.vi  v16, v8, 1
>
> You should load v8 first, since it is used as input before v0.
>
> +vsub.vv  v0, v0, v16
> +vse32.v  v0, (a0)
> +sh2add   a0, t0, a0
> +vadd.vv  v0, v0, v8
>
> You can use VSSRA, and then VADD won't need to depend on the output of
> VSUB.
>
> +vse32.v  v0, (a1)
> +sh2add   a1, t0, a1
> +bnez a2, 1b
> +ret
> +endfunc
>
> --
> 雷米‧德尼-库尔蒙
> http://www.remlab.net/
>
>
>
> ___
> 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 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 v1] avcodec/av1dec: Add tile list OBU to decompose list

[Wang, Fei W]

On Thu, 2023-12-21 at 20:14 +0100, Andreas Rheinhardt wrote:
> Wang, Fei W:
> > On Wed, 2023-12-20 at 17:11 +0100, Andreas Rheinhardt wrote:
> > > fei.w.wang-at-intel@ffmpeg.org:
> > > > From: Fei Wang 
> > > > 
> > > > Show the unsupported message and return unsupported for clips
> > > > contain
> > > > tile list OBU since it hasn't been implemented. Otherwise,
> > > > decoding
> > > > maybe successful but result is incorrect.
> > > > 
> > > > Signed-off-by: Fei Wang 
> > > > ---
> > > >  libavcodec/av1dec.c | 5 +
> > > >  1 file changed, 5 insertions(+)
> > > > 
> > > > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > > > index 4dcde234c6..629e37c3f8 100644
> > > > --- a/libavcodec/av1dec.c
> > > > +++ b/libavcodec/av1dec.c
> > > > @@ -805,6 +805,7 @@ static const CodedBitstreamUnitType
> > > > decompose_unit_types[] = {
> > > >  AV1_OBU_SEQUENCE_HEADER,
> > > >  AV1_OBU_TEMPORAL_DELIMITER,
> > > >  AV1_OBU_TILE_GROUP,
> > > > +AV1_OBU_TILE_LIST,
> > > 
> > > What do you need this for? Decomposing it would only change
> > > whether
> > > CodedBitstreamUnit.content is available, but you are only reading
> > > CodedBitstreamUnit.type.
> > 
> > To show the unsupported error and let user know that there are tile
> > list OBUs in bitstream that decoder can't handle them. Otherwise,
> > like
> > my commit mentioned, tile list obu bitsteam may be decoded
> > 'successful'
> > according to log.
> > 
> 
> As I said: You do not need CodedBitstreamUnit.content for the error
> message.

No, obu will be filtered if it is not listed in decompose, decoder
can't receive its type neither.

Thanks
Fei

> 
> > > >  };
> > > >  
> > > >  static av_cold int av1_decode_init(AVCodecContext *avctx)
> > > > @@ -1327,6 +1328,10 @@ static int
> > > > av1_receive_frame_internal(AVCodecContext *avctx, AVFrame
> > > > *frame)
> > > >  }
> > > >  break;
> > > >  case AV1_OBU_TILE_LIST:
> > > > +av_log(avctx, AV_LOG_ERROR, "Large scale tile
> > > > decoding
> > > > is unsupported.\n");
> > > > +ret = AVERROR_PATCHWELCOME;
> > > > +goto end;
> > > > +break;
> > > >  case AV1_OBU_TEMPORAL_DELIMITER:
> > > >  case AV1_OBU_PADDING:
> > > >  break;
> > > 
> > > ___
> > > 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 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 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 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/2] x86/takdsp: add avx2 versions of all functions

[James Almer]

On an Intel Core i7 12700k:

decorrelate_ls_c: 814.3
decorrelate_ls_sse2: 165.8
decorrelate_ls_avx2: 101.3
decorrelate_sf_c: 1602.6
decorrelate_sf_sse4: 640.1
decorrelate_sf_avx2: 324.6
decorrelate_sm_c: 1564.8
decorrelate_sm_sse2: 379.3
decorrelate_sm_avx2: 203.3
decorrelate_sr_c: 785.3
decorrelate_sr_sse2: 176.3
decorrelate_sr_avx2: 99.8

Signed-off-by: James Almer 
---
 libavcodec/x86/takdsp.asm| 36 ++--
 libavcodec/x86/takdsp_init.c | 11 +++
 2 files changed, 33 insertions(+), 14 deletions(-)

diff --git a/libavcodec/x86/takdsp.asm b/libavcodec/x86/takdsp.asm
index be8e1ab553..a5501cc285 100644
--- a/libavcodec/x86/takdsp.asm
+++ b/libavcodec/x86/takdsp.asm
@@ -28,7 +28,7 @@ pd_128: times 4 dd 128
 
 SECTION .text
 
-INIT_XMM sse2
+%macro TAK_DECORRELATE 0
 cglobal tak_decorrelate_ls, 3, 3, 2, p1, p2, length
 shl lengthd, 2
 add p1q, lengthq
@@ -73,10 +73,8 @@ cglobal tak_decorrelate_sm, 3, 3, 6, p1, p2, length
 mova m1, [p2q+lengthq]
 mova m3, [p1q+lengthq+mmsize]
 mova m4, [p2q+lengthq+mmsize]
-mova m2, m1
-mova m5, m4
-psradm2, 1
-psradm5, 1
+psradm2, m1, 1
+psradm5, m4, 1
 psubdm0, m2
 psubdm3, m5
 padddm1, m0
@@ -88,29 +86,39 @@ cglobal tak_decorrelate_sm, 3, 3, 6, p1, p2, length
 add lengthq, mmsize*2
 jl .loop
 RET
+%endmacro
 
-INIT_XMM sse4
+INIT_XMM sse2
+TAK_DECORRELATE
+INIT_YMM avx2
+TAK_DECORRELATE
+
+%macro TAK_DECORRELATE_SF 0
 cglobal tak_decorrelate_sf, 3, 3, 5, p1, p2, length, dshift, dfactor
 shl lengthd, 2
 add p1q, lengthq
 add p2q, lengthq
 neg lengthq
 
-movd m2, dshiftm
-movd m3, dfactorm
-pshufd   m3, m3, 0
-mova m4, [pd_128]
+movdxm2, dshiftm
+VPBROADCASTD m3, dfactorm
+VBROADCASTI128   m4, [pd_128]
 
 .loop:
-mova m0, [p1q+lengthq]
 mova m1, [p2q+lengthq]
-psradm1, m2
+psradm1, xm2
 pmulld   m1, m3
 padddm1, m4
 psradm1, 8
-pslldm1, m2
-psubdm1, m0
+pslldm1, xm2
+psubdm1, [p1q+lengthq]
 mova  [p1q+lengthq], m1
 add lengthq, mmsize
 jl .loop
 RET
+%endmacro
+
+INIT_XMM sse4
+TAK_DECORRELATE_SF
+INIT_YMM avx2
+TAK_DECORRELATE_SF
diff --git a/libavcodec/x86/takdsp_init.c b/libavcodec/x86/takdsp_init.c
index b2e6e639ee..c99a057b24 100644
--- a/libavcodec/x86/takdsp_init.c
+++ b/libavcodec/x86/takdsp_init.c
@@ -24,9 +24,13 @@
 #include "config.h"
 
 void ff_tak_decorrelate_ls_sse2(int32_t *p1, int32_t *p2, int length);
+void ff_tak_decorrelate_ls_avx2(int32_t *p1, int32_t *p2, int length);
 void ff_tak_decorrelate_sr_sse2(int32_t *p1, int32_t *p2, int length);
+void ff_tak_decorrelate_sr_avx2(int32_t *p1, int32_t *p2, int length);
 void ff_tak_decorrelate_sm_sse2(int32_t *p1, int32_t *p2, int length);
+void ff_tak_decorrelate_sm_avx2(int32_t *p1, int32_t *p2, int length);
 void ff_tak_decorrelate_sf_sse4(int32_t *p1, int32_t *p2, int length, int 
dshift, int dfactor);
+void ff_tak_decorrelate_sf_avx2(int32_t *p1, int32_t *p2, int length, int 
dshift, int dfactor);
 
 av_cold void ff_takdsp_init_x86(TAKDSPContext *c)
 {
@@ -42,5 +46,12 @@ av_cold void ff_takdsp_init_x86(TAKDSPContext *c)
 if (EXTERNAL_SSE4(cpu_flags)) {
 c->decorrelate_sf = ff_tak_decorrelate_sf_sse4;
 }
+
+if (EXTERNAL_AVX2_FAST(cpu_flags)) {
+c->decorrelate_ls = ff_tak_decorrelate_ls_avx2;
+c->decorrelate_sr = ff_tak_decorrelate_sr_avx2;
+c->decorrelate_sm = ff_tak_decorrelate_sm_avx2;
+c->decorrelate_sf = ff_tak_decorrelate_sf_avx2;
+}
 #endif
 }
-- 
2.43.0

___
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/2] checkasm/takdsp: add decorrelate_sf test

[James Almer]

Signed-off-by: James Almer 
---
 tests/checkasm/takdsp.c | 36 +---
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/tests/checkasm/takdsp.c b/tests/checkasm/takdsp.c
index 495b7242c5..8df93cfd52 100644
--- a/tests/checkasm/takdsp.c
+++ b/tests/checkasm/takdsp.c
@@ -24,6 +24,7 @@
 #include "libavutil/mem_internal.h"
 
 #include "libavcodec/takdsp.h"
+#include "libavcodec/mathops.h"
 
 #include "checkasm.h"
 
@@ -33,8 +34,9 @@
 buf[i] = rnd(); \
 } while (0)
 
-static void test_decorrelate_ls(TAKDSPContext *s) {
 #define BUF_SIZE 1024
+
+static void test_decorrelate_ls(TAKDSPContext *s) {
 declare_func(void, int32_t *, int32_t *, int);
 
 if (check_func(s->decorrelate_ls, "decorrelate_ls")) {
@@ -60,7 +62,6 @@ static void test_decorrelate_ls(TAKDSPContext *s) {
 }
 
 static void test_decorrelate_sr(TAKDSPContext *s) {
-#define BUF_SIZE 1024
 declare_func(void, int32_t *, int32_t *, int);
 
 if (check_func(s->decorrelate_sr, "decorrelate_sr")) {
@@ -86,7 +87,6 @@ static void test_decorrelate_sr(TAKDSPContext *s) {
 }
 
 static void test_decorrelate_sm(TAKDSPContext *s) {
-#define BUF_SIZE 1024
 declare_func(void, int32_t *, int32_t *, int);
 
 if (check_func(s->decorrelate_sm, "decorrelate_sm")) {
@@ -113,6 +113,35 @@ static void test_decorrelate_sm(TAKDSPContext *s) {
 report("decorrelate_sm");
 }
 
+static void test_decorrelate_sf(TAKDSPContext *s) {
+declare_func(void, int32_t *, int32_t *, int, int, int);
+
+if (check_func(s->decorrelate_sf, "decorrelate_sf")) {
+LOCAL_ALIGNED_32(int32_t, p1, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int32_t, p1_2, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int32_t, p2, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int32_t, p2_2, [BUF_SIZE]);
+int dshift, dfactor;
+
+randomize(p1, BUF_SIZE);
+memcpy(p1, p1_2, BUF_SIZE);
+randomize(p2, BUF_SIZE);
+memcpy(p2_2, p2, BUF_SIZE);
+dshift = (rnd() & 0xF) + 1;
+dfactor = sign_extend(rnd(), 10);
+call_ref(p1, p2, BUF_SIZE, dshift, dfactor);
+call_new(p1_2, p2_2, BUF_SIZE, dshift, dfactor);
+
+if (memcmp(p2, p2_2, BUF_SIZE) != 0){
+fail();
+}
+
+bench_new(p1, p2, BUF_SIZE, dshift, dfactor);
+}
+
+report("decorrelate_sf");
+}
+
 void checkasm_check_takdsp(void)
 {
 TAKDSPContext s = { 0 };
@@ -121,4 +150,5 @@ void checkasm_check_takdsp(void)
 test_decorrelate_ls();
 test_decorrelate_sr();
 test_decorrelate_sm();
+test_decorrelate_sf();
 }
-- 
2.43.0

___
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] Backporting Clang 14 fix to the 4.4 branch

[Brad Smith]

On 2023-12-21 7:34 p.m., Michael Niedermayer wrote:

On Thu, Dec 21, 2023 at 01:41:20AM -0500, Brad Smith wrote:

https://github.com/FFmpeg/FFmpeg/commit/ab792634197e364ca1bb194f9abe36836e42f12d

But the function is in libavformat/utils.c for 4.4 instead of
libavformat/seek.c.

Could the Clang 14 fix please be backported to the 4.4 branch?

done in 6ddd5111f4bfb5f0178bae4608b066d1e01d724c

thx


Thanks.
___
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] Temporary delays in patch reviewing and testing by me

[Michael Niedermayer]

On Thu, Dec 21, 2023 at 03:22:20AM +0100, Michael Niedermayer wrote:
> Hi all
> 
> My main development machiene died today, so expect increased delays
> about things that involve me/it until thats fixed
> 
> Rest of the mail is just about the issue, and you can skip reading that
> 
> Timeline:
> box suddenly stopped, no reaction to any input or pings
> power off and on did not bring it back, screen stayed dark, keyboard too
> but fans spin up and theres power
> opening it up i find it stuck on Q-code "0d" so i power it off
> wiggle the ram modules a bit power it back on and it gets stuck on
> qcode "15" i power cycle again and it reaches bios setup, so i go over all
> values and just look but as i look, it hangs hard again
> off/on again and we hit "0d" again
> so i remove one of the CPU fans to get to the DIMM modules and reconfigure 
> them like this:
> B1A1 0+2 -> boot ok
> B2A2 0+2 -> boot ok
> B2A2 1+3 -> 0d
> B2A2 0+3 -> boot ok
> B1A1 1+2 -> 0d
> 
> This is consistent with DIMM module 1 being faulty. But iam not 100% convinced
> because this box never crashed not once, it was always rock solid and suddenly
> one module is so faulty the box hangs so early.
> Either way i ordered 4 new and bigger modules from 2 independant shops
> they should be here soon but i dont know what "soon" is around christmess
> 

> also i could try running it with just 2 modules, i might try that
> tomorrow

system seems working stable with 2 DIMM sticks

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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] Backporting Clang 14 fix to the 4.4 branch

[Michael Niedermayer]

On Thu, Dec 21, 2023 at 01:41:20AM -0500, Brad Smith wrote:
> 
> https://github.com/FFmpeg/FFmpeg/commit/ab792634197e364ca1bb194f9abe36836e42f12d
> 
> But the function is in libavformat/utils.c for 4.4 instead of
> libavformat/seek.c.
> 
> Could the Clang 14 fix please be backported to the 4.4 branch?

done in 6ddd5111f4bfb5f0178bae4608b066d1e01d724c

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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] lavc: remove the QOA decoder

[Michael Niedermayer]

On Thu, Dec 21, 2023 at 05:37:58PM -0500, Vittorio Giovara wrote:
> On Thu, Dec 21, 2023 at 5:22 PM Nicolas George  wrote:
> 
> > Vittorio Giovara (12023-12-21):
> > > Oh so you know how it feels!
> >
> > I am not surprised to see your animosity against me is stronger than
> > your care about the project.
> >
> 
> Not sure what gave you the idea, but I have no animosity towards you and I
> appreciate your technical feedback when you share it.
> 

> What surprises me is that you feel discouraged by the same treatment you
> have towards others in other discussions: [...]

I think many people who feel discouraged by someones treatment, have
done similar to others.


> All
> I hope is that we can all communicate better in 2024 and be able to work
> together.

i strongly agree, i hope that too :)

I wanted to quote epictetus, but as i googled i found this, which is
a bit more elaborate
https://www.reddit.com/r/Stoicism/comments/afacdz/when_you_are_offended_at_any_mans_fault_epictetus/

maybe a good guiding principle for 2024 ?

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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] lavc: remove the QOA decoder

[Vittorio Giovara]

On Thu, Dec 21, 2023 at 6:14 PM Nicolas George  wrote:

> Vittorio Giovara (12023-12-21):
> > I agree, I hope you can work on your lack of self-awareness.
>
> Oh, the “Ah ?… Et moi, Cyrano-Savinien-Hercule De Bergerac.” comeback.
> You're really scrapping the bottom of the barrel, aren't your.
>

No, I'm just pointing out the obvious, but there is none so deaf as those
who will not hear.

Anyway the offtopic has been gone long enough, no point in continuing this
dead branch of a resurrected thread.
For real, no harm feelings, thanks for this pleasant and fruitful exchange.
-- 
Vittorio
___
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: remove the QOA decoder

[Nicolas George]

Vittorio Giovara (12023-12-21):
> I agree, I hope you can work on your lack of self-awareness.

Oh, the “Ah ?… Et moi, Cyrano-Savinien-Hercule De Bergerac.” comeback.
You're really scrapping the bottom of the barrel, aren't your.

-- 
  Nicolas George
___
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: remove the QOA decoder

[Vittorio Giovara]

On Thu, Dec 21, 2023 at 5:41 PM Nicolas George  wrote:

> Vittorio Giovara (12023-12-21):
> > Not sure what gave you the idea
>
> Mails like this one for example. The lack of self-awareness is
> hilarious.
>

I agree, I hope you can work on your lack of self-awareness.
-- 
Vittorio
___
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/2] avcodec/libjxlenc: Set AV_CODEC_CAP_DR1

[Andreas Rheinhardt]

This encoder uses ff_get_encode_buffer() to allocate the packet buffer.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/libjxlenc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index 055c9b7bb1..021e558687 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -486,6 +486,7 @@ const FFCodec ff_libjxl_encoder = {
 FF_CODEC_ENCODE_CB(libjxl_encode_frame),
 .close= libjxl_encode_close,
 .p.capabilities   = AV_CODEC_CAP_OTHER_THREADS |
+AV_CODEC_CAP_DR1 |
 AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
 .caps_internal= FF_CODEC_CAP_NOT_INIT_THREADSAFE |
 FF_CODEC_CAP_AUTO_THREADS | FF_CODEC_CAP_INIT_CLEANUP |
-- 
2.34.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/2] avcodec/libjxlenc: Don't refer to decoder in comments

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/libjxlenc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index d707f3a61b..055c9b7bb1 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -85,8 +85,8 @@ static float quality_to_distance(float quality)
 }
 
 /**
- * Initalize the decoder on a per-frame basis. All of these need to be set
- * once each time the decoder is reset, which it must be each frame to make
+ * Initalize the encoder on a per-frame basis. All of these need to be set
+ * once each time the encoder is reset, which it must be each frame to make
  * the image2 muxer work.
  *
  * @return   0 upon success, negative on failure.
@@ -104,7 +104,7 @@ static int libjxl_init_jxl_encoder(AVCodecContext *avctx)
 return AVERROR_EXTERNAL;
 }
 
-/* This needs to be set each time the decoder is reset */
+/* This needs to be set each time the encoder is reset */
 if (JxlEncoderSetParallelRunner(ctx->encoder, JxlThreadParallelRunner, 
ctx->runner)
 != JXL_ENC_SUCCESS) {
 av_log(avctx, AV_LOG_ERROR, "Failed to set JxlThreadParallelRunner\n");
@@ -446,7 +446,7 @@ static av_cold int libjxl_encode_close(AVCodecContext 
*avctx)
 ctx->runner = NULL;
 
 /*
- * destroying the decoder also frees
+ * destroying the encoder also frees
  * ctx->options so we don't need to
  */
 if (ctx->encoder)
-- 
2.34.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: remove the QOA decoder

[Nicolas George]

Vittorio Giovara (12023-12-21):
> Not sure what gave you the idea

Mails like this one for example. The lack of self-awareness is
hilarious.

-- 
  Nicolas George
___
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: remove the QOA decoder

[Vittorio Giovara]

On Thu, Dec 21, 2023 at 5:22 PM Nicolas George  wrote:

> Vittorio Giovara (12023-12-21):
> > Oh so you know how it feels!
>
> I am not surprised to see your animosity against me is stronger than
> your care about the project.
>

Not sure what gave you the idea, but I have no animosity towards you and I
appreciate your technical feedback when you share it.

What surprises me is that you feel discouraged by the same treatment you
have towards others in other discussions: it's been an actual concern of
mine that your long paragraphs of empty text and sometimes toxic messages
may have discouraged many people and companies to work on the project. All
I hope is that we can all communicate better in 2024 and be able to work
together.

Fwiw I'm glad you and Paul agree on something at least, though, let's
remember, the topic is a simple "new decoders should come with tests" and
its objections seem an odd hill to die on.
Cheers
-- 
Vittorio
___
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: remove the QOA decoder

[Nicolas George]

Vittorio Giovara (12023-12-21):
> Oh so you know how it feels!

I am not surprised to see your animosity against me is stronger than
your care about the project.

-- 
  Nicolas George


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 v8 2/5] libavcodec/webp: add support for animated WebP decoding

[Andreas Rheinhardt]

Thilo Borgmann via ffmpeg-devel:
> From: Josef Zlomek 
> 
> Fixes: 4907
> 
> Adds support for decoding of animated WebP.
> 
> The WebP decoder adds the animation related features according to the specs:
> https://developers.google.com/speed/webp/docs/riff_container#animation
> The frames of the animation may be smaller than the image canvas.
> Therefore, the frame is decoded to a temporary frame,
> then it is blended into the canvas, the canvas is copied to the output frame,
> and finally the frame is disposed from the canvas.
> 
> The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported.
> The background color is specified only as BGRA in the WebP file
> so it is converted to YUVA if YUV formats are output.
> 
> Signed-off-by: Josef Zlomek 
> ---
>  Changelog   |   1 +
>  libavcodec/codec_desc.c |   3 +-
>  libavcodec/version.h|   2 +-
>  libavcodec/webp.c   | 754 
>  4 files changed, 696 insertions(+), 64 deletions(-)
> 
> @@ -1298,12 +1326,12 @@ static int vp8_lossy_decode_frame(AVCodecContext 
> *avctx, AVFrame *p,
>  int ret;
>  
>  if (!s->initialized) {
> -ff_vp8_decode_init(avctx);
> +VP8Context *s_vp8 = s->avctx_vp8->priv_data;
> +s_vp8->actually_webp = 1;
>  s->initialized = 1;
> -s->v.actually_webp = 1;
>  }
>  avctx->pix_fmt = s->has_alpha ? AV_PIX_FMT_YUVA420P : AV_PIX_FMT_YUV420P;
> -s->lossless = 0;
> +s->avctx_vp8->pix_fmt = avctx->pix_fmt;
>  

Separating webp.c from vp8.c should be done in commit of its own. And
you did not really separate them, because you are overwriting internals
of the VP8 decoder.

- 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".

[FFmpeg-devel] [PATCH] configure: Don't pass -mfp16-format to MSVC on ARM

[Martin Storsjö]

The check for this option does succeed - MSVC accepts the option,
but prints a warning about it being unknown and ignored, for
each compiled object file:

cl : Command line warning D9002 : ignoring unknown option 
'-mfp16-format=ieee'

The configure script only attempts to add this option on ARM,
therefore this warning isn't seen by the majority of people
building with MSVC.

Making this option into a no-op probably isn't entirely right,
but on the other hand, we don't want to litter the code that
checks for support for the option with compiler specific
conditions either.
---
 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index 18fe8eaa5c..31d0039fed 100755
--- a/configure
+++ b/configure
@@ -4702,6 +4702,7 @@ msvc_common_flags(){
 -fPIC);;
 -mthumb)  ;;
 -march=*) ;;
+-mfp16-format=*)  ;;
 -lz)  echo zlib.lib ;;
 -lx264)   echo libx264.lib ;;
 -lstdc++) ;;
-- 
2.34.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] checkasm: Generalize crash handling

[Henrik Gramner via ffmpeg-devel]

On Thu, Dec 21, 2023 at 9:16 PM Rémi Denis-Courmont  wrote:
> > +checkasm_fail_func("%s",
> > +   s == SIGFPE ? "fatal arithmetic error" :
> > +   s == SIGILL ? "illegal instruction" :
> > +   s == SIGBUS ? "bus error" :
> > + "segmentation fault");
>
> The current code for the error print-out is both simpler and more versatile,
> so I don't get this.

IMO "illegal instruction" is a far better error message than "fatal
signal 4" (with an implementation-defined number which nobody knows
the meaning of without having to look it up).

> > +/* fall back to the default signal handler */
> > +static const struct sigaction default_sa = { .sa_handler = SIG_DFL
> > }; +sigaction(s, _sa, NULL);
> > +raise(s);
>
> Why raise here? Returning from the handler will reevaluate the same code with
> the same thread state, and trigger the default signal handler anyway (since
> you don't modify the user context).

No it wont, it'll get stuck in an infinite loop invoking the signal
handler over and over. At least on my system.

> > +const struct sigaction sa = {
> > +.sa_handler = signal_handler,
> > +.sa_flags = SA_NODEFER,
>
> That does not look very sane to me. If a recursive signal occurs, processing
> it recursively is NOT a good idea. This would cause an infinite loop,
> eventually a literal stack overflow after maxing out the processor for a 
> while.
> I'd rather let the OS kernel deal with the problem, by killing the process or
> whatever the last resort is.
>
> > +#define checkasm_save_context() setjmp(checkasm_context_buf)
> > +#define checkasm_load_context() longjmp(checkasm_context_buf, 1)
> > +#endif
>
> Been there done that and it did not end well.
> sigsetjmp() & co are necessary here.

For all intents and purposes sigjmp()/longjmp() with SA_NODEFER does
the same thing as sigsetjmp()/siglongjmp() without SA_NODEFER for this
particular use case (no infinite recursion is possible the way the
code is written). The change isn't necessary per se but it seems
reasonable and I have no objections to it.
___
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] Add new vf_tiltandshift filter

[Vittorio Giovara]

On Wed, Dec 20, 2023 at 2:56 PM Vittorio Giovara 
wrote:

>
>
> On Wed, Dec 20, 2023 at 2:50 PM Nicolas George  wrote:
>
>> Vittorio Giovara (12023-12-20):
>> > If there are no more comments, I'll push this today or tomorrow.
>>
>> I think the change you made after the last request might go too far, but
>> I have not had time to look at the code carefully enough to be sure.
>>
>> If a filter can produce several output frames from one input, then it
>> must send at lease one of the NEW frames.
>>
>> An illustration to make it clear: if I1 allows to compute O1a, O1b, O1c,
>> I2 allows to compute O2a, O2b, O2c, etc.
>>
>> Then when I1 arrives, the filter must output at least O1a, it can output
>> O1b and O1c or not.
>>
>> But when I2 arrives, it must output at lease O2a, which means it must
>> output O1b and O1c if that was not done at the time of I1.
>>
>> Your filter only outputs one frame per input, but it seems to me it can
>> create several frames.
>>
>
> the filter needs at least $width input frames to generate an output frame,
> so it queues them
> when the buffer is full, it will pop the head and generate the output
> frame when the next input frame arrives, but the amount of input frames in
> the queue needed to generate new frames is constant so it cannot output any
> additional frames
> at the end it will flush the buffer and generate the remaining output
> frames
> --
>

pushed thanks
-- 
Vittorio
___
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: remove the QOA decoder

[Vittorio Giovara]

On Thu, Dec 21, 2023 at 3:05 PM Paul B Mahol  wrote:

> On Thu, Dec 21, 2023 at 8:43 PM Tomas Härdin  wrote:
>
> > ons 2023-12-20 klockan 20:11 +0100 skrev Michael Niedermayer:
> > > On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin wrote:
> > > > tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George:
> > > [...]
> > > > [...] , but every line of code
> > > > carries with it a non-zero maintenance burden
> > >
> > > Assuming you mean with "non-zero" a "larger than zero" maintenance
> > > burden
> > >
> > > then we can proof this to be false
> >
> > Doubt
> >
> > > What iam trying to say is, the maintaince burden resulting from a
> > > change
> > > is complex
> >
> > Indeed
> >
> > > In this specific case here we have a patch proposing the removial of
> > > a decoder
> > > missing a test.
> > > Its easy to say the burden is less when the decoder is removed
> > > But its author recently left the project too
> >
> > This is one problem. But the careless attitude to shoving more features
> > into the codebase is far more serious. Every line of code is a CVE
> > waiting to happen. Apparently this is a difficult thing to grasp for
> > some contributors. It's an attitude I expect only from junior
> > developers.
> >
> > Ensuring C code is correct and safe is *hard*. I have spent time
> > formally verifying embedded C code for spaceflight. The lessons learned
> > from this has made me supremely suspicious of cowboy coding.
> >
> > I have raised this issue multiple times in this project to no avail. I
> > do not expect things to change.
> >
>
> Say what serious feature you contributed ? - Nothing.
>

Contributions to the process that makes us code better and keep higher
quality code are welcome.
Let's not fall into the trap of "no commits therefore your opinion is
invalid" way of thinking which only a fool would follow.
-- 
Vittorio
___
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: remove the QOA decoder

[Vittorio Giovara]

On Thu, Dec 21, 2023 at 3:31 PM Nicolas George  wrote:

> Paul B Mahol (12023-12-21):
> > Say what serious feature you contributed ? - Nothing.
>
> I did not want to say it, but since it is now in the open: Not nothing:
> negative. His naysaying discouraged me from working further on the
> built-in documentation system.
>

Oh so you know how it feels!
-- 
Vittorio
___
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/2] configure: Fix linking d3d12va in UWP mode

[Martin Storsjö]

---
 configure | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 69b755f274..18fe8eaa5c 100755
--- a/configure
+++ b/configure
@@ -3922,7 +3922,7 @@ swscale_suggest="libm stdatomic"
 
 avcodec_extralibs="pthreads_extralibs iconv_extralibs dxva2_extralibs 
lcms2_extralibs"
 avfilter_extralibs="pthreads_extralibs"
-avutil_extralibs="d3d11va_extralibs mediacodec_extralibs nanosleep_extralibs 
pthreads_extralibs vaapi_drm_extralibs vaapi_x11_extralibs 
vaapi_win32_extralibs vdpau_x11_extralibs"
+avutil_extralibs="d3d11va_extralibs d3d12va_extralibs mediacodec_extralibs 
nanosleep_extralibs pthreads_extralibs vaapi_drm_extralibs vaapi_x11_extralibs 
vaapi_win32_extralibs vdpau_x11_extralibs"
 
 # programs
 ffmpeg_deps="avcodec avfilter avformat threads"
@@ -7123,6 +7123,7 @@ if enabled uwp; then
 # try to load these APIs at runtime, like we do in regular desktop mode -
 # therefore, we need to link directly against these APIs.
 d3d11va_extralibs="-ldxgi -ld3d11"
+d3d12va_extralibs="-ldxgi -ld3d12"
 vaapi_win32_extralibs="-ldxgi"
 mediafoundation_extralibs="-lmfplat $mediafoundation_extralibs"
 fi
-- 
2.34.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/2] configure: Remove a redundant check for UWP mode

[Martin Storsjö]

The check for UWP mode was duplicated from right above, in
d54127c41a81cf2078a3504f78e0e4232cfe11b7.

Also, instead of several lines with "enabled uwp && ...", make one
"if enabled uwp; then" block.
---
 configure | 30 +++---
 1 file changed, 11 insertions(+), 19 deletions(-)

diff --git a/configure b/configure
index af0bebc1ac..69b755f274 100755
--- a/configure
+++ b/configure
@@ -7102,9 +7102,8 @@ fi
 
 check_func_headers "windows.h" CreateDIBSection "$gdigrab_indev_extralibs"
 
-# d3d11va requires linking directly to dxgi and d3d11 if not building for
-# the desktop api partition
-test_cpp <
 #if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
@@ -7117,23 +7116,16 @@ test_cpp <
-#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
-#error desktop, not uwp
-#else
-// WINAPI_FAMILY_APP, WINAPI_FAMILY_PHONE_APP => UWP
-#endif
-#else
-#error no family set
-#endif
-EOF
+mediafoundation_extralibs="-lmfuuid -lole32 -lstrmiids"
 
-# mediafoundation requires linking directly to mfplat if building for uwp 
target
-enabled uwp && mediafoundation_extralibs="-lmfplat -lmfuuid -lole32 
-lstrmiids" || mediafoundation_extralibs="-lmfuuid -lole32 -lstrmiids"
+if enabled uwp; then
+# In UWP mode, we can't use LoadLibrary+GetProcAddress to conditionally
+# try to load these APIs at runtime, like we do in regular desktop mode -
+# therefore, we need to link directly against these APIs.
+d3d11va_extralibs="-ldxgi -ld3d11"
+vaapi_win32_extralibs="-ldxgi"
+mediafoundation_extralibs="-lmfplat $mediafoundation_extralibs"
+fi
 
 enabled libdrm &&
 check_pkg_config libdrm_getfb2 libdrm "xf86drmMode.h" drmModeGetFB2
-- 
2.34.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 v3 0/1] avcodec/libjxlenc: Add libjxl_anim encoder

[Zsolt Vadász via ffmpeg-devel]

This patchset adds support for encoding animated JPEG XL images via a
new encoder (libjxl_anim). When using the encoder, the output format
needs to be set to raw video, as shown below:
`ffmpeg -i sample.gif -c:v libjxl_anim -f rawvideo out.jxl`

V3 changes:
- Renamed encoder to libjxl_anim for consistency
- PTS is now calculated
- JxlFrameHeader.duration is calculated from PTS instead of relying on
  AVFrame->duration being set
- This version also does not rely on AVCodecContext->frame_num either
- Disabled the container container format (JxlEncoderUseContainer)

Zsolt Vadász (1):
  avcodec/libjxlenc: Add libjxl_animated encoder

 configure  |   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libjxlenc.c | 226 ++---
 3 files changed, 189 insertions(+), 39 deletions(-)

-- 
2.34.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 v3 1/1] avcodec/libjxlenc: Add libjxl_animated encoder

[Zsolt Vadász via ffmpeg-devel]

---
 configure  |   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libjxlenc.c | 226 ++---
 3 files changed, 189 insertions(+), 39 deletions(-)

diff --git a/configure b/configure
index 7d2ee66000..2d27d8015a 100755
--- a/configure
+++ b/configure
@@ -3418,6 +3418,7 @@ libilbc_decoder_deps="libilbc"
 libilbc_encoder_deps="libilbc"
 libjxl_decoder_deps="libjxl libjxl_threads"
 libjxl_encoder_deps="libjxl libjxl_threads"
+libjxl_anim_encoder_deps="libjxl libjxl_threads"
 libkvazaar_encoder_deps="libkvazaar"
 libmodplug_demuxer_deps="libmodplug"
 libmp3lame_encoder_deps="libmp3lame"
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b0f004e15c..22c7227946 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -784,6 +784,7 @@ extern const FFCodec ff_libilbc_encoder;
 extern const FFCodec ff_libilbc_decoder;
 extern const FFCodec ff_libjxl_decoder;
 extern const FFCodec ff_libjxl_encoder;
+extern const FFCodec ff_libjxl_anim_encoder;
 extern const FFCodec ff_libmp3lame_encoder;
 extern const FFCodec ff_libopencore_amrnb_encoder;
 extern const FFCodec ff_libopencore_amrnb_decoder;
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index d707f3a61b..f23e86939e 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -34,6 +34,7 @@
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/pixfmt.h"
+#include "libavutil/rational.h"
 #include "libavutil/version.h"
 
 #include "avcodec.h"
@@ -49,11 +50,18 @@ typedef struct LibJxlEncodeContext {
 void *runner;
 JxlEncoder *encoder;
 JxlEncoderFrameSettings *options;
+JxlPixelFormat jxl_fmt;
 int effort;
 float distance;
 int modular;
 uint8_t *buffer;
 size_t buffer_size;
+int animated;
+/* Only used by libjxl_animated */
+AVRational libjxl_time_base;
+int is_first_frame;
+int64_t duration;
+AVFrame *prev;
 } LibJxlEncodeContext;
 
 /**
@@ -183,6 +191,8 @@ static av_cold int libjxl_encode_init(AVCodecContext *avctx)
 return AVERROR(ENOMEM);
 }
 
+ctx->animated = 0;
+
 return 0;
 }
 
@@ -237,28 +247,19 @@ static int libjxl_populate_primaries(void *avctx, 
JxlColorEncoding *jxl_color, e
 return 0;
 }
 
-/**
- * Encode an entire frame. Currently animation, is not supported by
- * this encoder, so this will always reinitialize a new still image
- * and encode a one-frame image (for image2 and image2pipe).
- */
-static int libjxl_encode_frame(AVCodecContext *avctx, AVPacket *pkt, const 
AVFrame *frame, int *got_packet)
+static int libjxl_encode_init_image(AVCodecContext *avctx, const AVFrame 
*frame)
 {
 LibJxlEncodeContext *ctx = avctx->priv_data;
 AVFrameSideData *sd;
 const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(frame->format);
 JxlBasicInfo info;
 JxlColorEncoding jxl_color;
-JxlPixelFormat jxl_fmt;
+JxlPixelFormat *jxl_fmt = >jxl_fmt;
 int bits_per_sample;
 #if JPEGXL_NUMERIC_VERSION >= JPEGXL_COMPUTE_NUMERIC_VERSION(0, 8, 0)
 JxlBitDepth jxl_bit_depth;
 #endif
-JxlEncoderStatus jret;
 int ret;
-size_t available = ctx->buffer_size;
-size_t bytes_written = 0;
-uint8_t *next_out = ctx->buffer;
 
 ret = libjxl_init_jxl_encoder(avctx);
 if (ret) {
@@ -268,23 +269,30 @@ static int libjxl_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt, const AVFra
 
 /* populate the basic info settings */
 JxlEncoderInitBasicInfo();
-jxl_fmt.num_channels = pix_desc->nb_components;
+jxl_fmt->num_channels = pix_desc->nb_components;
 info.xsize = frame->width;
 info.ysize = frame->height;
-info.num_extra_channels = (jxl_fmt.num_channels + 1) % 2;
-info.num_color_channels = jxl_fmt.num_channels - info.num_extra_channels;
-bits_per_sample = av_get_bits_per_pixel(pix_desc) / jxl_fmt.num_channels;
+info.num_extra_channels = (jxl_fmt->num_channels + 1) % 2;
+info.num_color_channels = jxl_fmt->num_channels - info.num_extra_channels;
+bits_per_sample = av_get_bits_per_pixel(pix_desc) / jxl_fmt->num_channels;
 info.bits_per_sample = avctx->bits_per_raw_sample > 0 && !(pix_desc->flags 
& AV_PIX_FMT_FLAG_FLOAT)
? avctx->bits_per_raw_sample : bits_per_sample;
 info.alpha_bits = (info.num_extra_channels > 0) * info.bits_per_sample;
 if (pix_desc->flags & AV_PIX_FMT_FLAG_FLOAT) {
 info.exponent_bits_per_sample = info.bits_per_sample > 16 ? 8 : 5;
 info.alpha_exponent_bits = info.alpha_bits ? 
info.exponent_bits_per_sample : 0;
-jxl_fmt.data_type = info.bits_per_sample > 16 ? JXL_TYPE_FLOAT : 
JXL_TYPE_FLOAT16;
+jxl_fmt->data_type = info.bits_per_sample > 16 ? JXL_TYPE_FLOAT : 
JXL_TYPE_FLOAT16;
 } else {
 info.exponent_bits_per_sample = 0;
 info.alpha_exponent_bits = 0;
-jxl_fmt.data_type = info.bits_per_sample <= 8 ? JXL_TYPE_UINT8 : 
JXL_TYPE_UINT16;
+

Re: [FFmpeg-devel] [PATCH] libavfilter/af_afir: R-V V dcmul_add

[Rémi Denis-Courmont]

Le tiistaina 19. joulukuuta 2023, 4.53.12 EET flow gg a écrit :
> c908:
> dcmul_add_c: 88.0
> dcmul_add_rvv_f64: 46.2
> 
> Did not use vlseg2e64, because it is much slower than vlse64
> Did not use vsseg2e64, because it is slightly slower than vsse64

Is this about C910 or C908? I have not checked this specific function, but the 
general understanding for C908 has been the exact opposite so far, i.e. 
segmented accesses are fast, while strided accesses are (unsurprisingly) slow.

See also https://camel-cdr.github.io/rvv-bench-results/canmv_k230/index.html

-- 
レミ・デニ-クールモン
http://www.remlab.net/



___
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: remove the QOA decoder

[Nicolas George]

Paul B Mahol (12023-12-21):
> Say what serious feature you contributed ? - Nothing.

I did not want to say it, but since it is now in the open: Not nothing:
negative. His naysaying discouraged me from working further on the
built-in documentation system.

-- 
  Nicolas George


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] checkasm: Generalize crash handling

[Rémi Denis-Courmont]

Le tiistaina 19. joulukuuta 2023, 14.02.00 EET Martin Storsjö a écrit :
> This replaces the riscv specific handling from
> 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is
> reverted, together with 286d6742218ba0235c32876b50bf593cb1986353)
> with a different implementation of the same (plus a bit more), based
> on the corresponding feature in dav1d's checkasm, supporting both Unix
> and Windows.
> 
> See in particular dav1d commits
> 0b6ee30eab2400e4f85b735ad29a68a842c34e21 and
> 0421f787ea592fd2cc74c887f20b8dc31393788b, authored by
> Henrik Gramner.
> 
> The overall approach is the same; set up a signal handler,
> store the state with setjmp/sigsetjmp, jump out of the crashing
> function with longjmp/siglongjmp.
> 
> The main difference is in what happens when the signal handler
> is invoked. In the previous implementation, it would resume from
> right before calling the crashing function, and then skip that call
> based on the setjmp return value.
> 
> In the imported implementation from dav1d, we return to right before
> the check_func() call, which will skip testing the current function
> (as the pointer is the same as it was before).
> 
> Other differences are:
> - Support for other signal handling mechanisms (Windows
>   AddVectoredExceptionHandler)
> - Using RtlCaptureContext/RtlRestoreContext instead of setjmp/longjmp
>   on Windows with SEH (which adds the design limitation that it doesn't
>   return a value like setjmp does)
> - Only catching signals once per function - if more than one
>   signal is delivered before signal handling is reenabled, any
>   signal is handled as it would without our handler
> - Not using an arch specific signal handler written in assembly
> ---
>  tests/checkasm/checkasm.c   | 100 ++--
>  tests/checkasm/checkasm.h   |  79 ++---
>  tests/checkasm/riscv/checkasm.S |  12 
>  3 files changed, 140 insertions(+), 51 deletions(-)
> 
> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> index 6318d9296b..668034c67f 100644
> --- a/tests/checkasm/checkasm.c
> +++ b/tests/checkasm/checkasm.c
> @@ -23,8 +23,10 @@
>  #include "config.h"
>  #include "config_components.h"
> 
> -#ifndef _GNU_SOURCE
> -# define _GNU_SOURCE // for syscall (performance monitoring API),
> strsignal() +#if CONFIG_LINUX_PERF
> +# ifndef _GNU_SOURCE
> +#  define _GNU_SOURCE // for syscall (performance monitoring API)
> +# endif
>  #endif
> 
>  #include 
> @@ -326,6 +328,7 @@ static struct {
>  const char *cpu_flag_name;
>  const char *test_name;
>  int verbose;
> +int catch_signals;

AFAICT, this needs to be volatile sigatomic_t

>  } state;
> 
>  /* PRNG state */
> @@ -627,6 +630,64 @@ static CheckasmFunc *get_func(CheckasmFunc **root,
> const char *name) return f;
>  }
> 
> +checkasm_context checkasm_context_buf;
> +
> +/* Crash handling: attempt to catch crashes and handle them
> + * gracefully instead of just aborting abruptly. */
> +#ifdef _WIN32
> +#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
> +static LONG NTAPI signal_handler(EXCEPTION_POINTERS *const e) {
> +const char *err;
> +
> +if (!state.catch_signals)
> +return EXCEPTION_CONTINUE_SEARCH;
> +
> +switch (e->ExceptionRecord->ExceptionCode) {
> +case EXCEPTION_FLT_DIVIDE_BY_ZERO:
> +case EXCEPTION_INT_DIVIDE_BY_ZERO:
> +err = "fatal arithmetic error";
> +break;
> +case EXCEPTION_ILLEGAL_INSTRUCTION:
> +case EXCEPTION_PRIV_INSTRUCTION:
> +err = "illegal instruction";
> +break;
> +case EXCEPTION_ACCESS_VIOLATION:
> +case EXCEPTION_ARRAY_BOUNDS_EXCEEDED:
> +case EXCEPTION_DATATYPE_MISALIGNMENT:
> +case EXCEPTION_STACK_OVERFLOW:
> +err = "segmentation fault";
> +break;
> +case EXCEPTION_IN_PAGE_ERROR:
> +err = "bus error";
> +break;
> +default:
> +return EXCEPTION_CONTINUE_SEARCH;
> +}
> +state.catch_signals = 0;
> +checkasm_fail_func("%s", err);
> +checkasm_load_context();
> +return EXCEPTION_CONTINUE_EXECUTION; /* never reached, but shuts up gcc
> */ +}
> +#endif
> +#else
> +static void signal_handler(const int s) {
> +if (state.catch_signals) {
> +state.catch_signals = 0;
> +checkasm_fail_func("%s",
> +   s == SIGFPE ? "fatal arithmetic error" :
> +   s == SIGILL ? "illegal instruction" :
> +   s == SIGBUS ? "bus error" :
> + "segmentation fault");

The current code for the error print-out is both simpler and more versatile, 
so I don't get this.

> +checkasm_load_context();
> +} else {
> +/* fall back to the default signal handler */
> +static const struct sigaction default_sa = { .sa_handler = SIG_DFL
> }; +sigaction(s, _sa, NULL);
> +raise(s);

Why raise here? Returning from the handler will reevaluate the 

Re: [FFmpeg-devel] [PATCH] lavc: remove the QOA decoder

[Paul B Mahol]

On Thu, Dec 21, 2023 at 8:43 PM Tomas Härdin  wrote:

> ons 2023-12-20 klockan 20:11 +0100 skrev Michael Niedermayer:
> > On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin wrote:
> > > tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George:
> > [...]
> > > [...] , but every line of code
> > > carries with it a non-zero maintenance burden
> >
> > Assuming you mean with "non-zero" a "larger than zero" maintenance
> > burden
> >
> > then we can proof this to be false
>
> Doubt
>
> > What iam trying to say is, the maintaince burden resulting from a
> > change
> > is complex
>
> Indeed
>
> > In this specific case here we have a patch proposing the removial of
> > a decoder
> > missing a test.
> > Its easy to say the burden is less when the decoder is removed
> > But its author recently left the project too
>
> This is one problem. But the careless attitude to shoving more features
> into the codebase is far more serious. Every line of code is a CVE
> waiting to happen. Apparently this is a difficult thing to grasp for
> some contributors. It's an attitude I expect only from junior
> developers.
>
> Ensuring C code is correct and safe is *hard*. I have spent time
> formally verifying embedded C code for spaceflight. The lessons learned
> from this has made me supremely suspicious of cowboy coding.
>
> I have raised this issue multiple times in this project to no avail. I
> do not expect things to change.
>

Say what serious feature you contributed ? - Nothing.
___
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: remove the QOA decoder

[Tomas Härdin]

ons 2023-12-20 klockan 20:11 +0100 skrev Michael Niedermayer:
> On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin wrote:
> > tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George:
> [...]
> > [...] , but every line of code
> > carries with it a non-zero maintenance burden
> 
> Assuming you mean with "non-zero" a "larger than zero" maintenance
> burden
> 
> then we can proof this to be false

Doubt

> What iam trying to say is, the maintaince burden resulting from a
> change
> is complex

Indeed

> In this specific case here we have a patch proposing the removial of
> a decoder
> missing a test.
> Its easy to say the burden is less when the decoder is removed
> But its author recently left the project too

This is one problem. But the careless attitude to shoving more features
into the codebase is far more serious. Every line of code is a CVE
waiting to happen. Apparently this is a difficult thing to grasp for
some contributors. It's an attitude I expect only from junior
developers.

Ensuring C code is correct and safe is *hard*. I have spent time
formally verifying embedded C code for spaceflight. The lessons learned
from this has made me supremely suspicious of cowboy coding.

I have raised this issue multiple times in this project to no avail. I
do not expect things to change.

/Tomas
___
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] FFmpeg 6.1.1

[Michael Niedermayer]

Hi all

I will probably make a 6.1.1 release in maybe 1-3 weeks due to bug/fixes
in it.
if you want something in it, please backport it now!

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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 v1] avcodec/av1dec: Add tile list OBU to decompose list

[Andreas Rheinhardt]

Wang, Fei W:
> On Wed, 2023-12-20 at 17:11 +0100, Andreas Rheinhardt wrote:
>> fei.w.wang-at-intel@ffmpeg.org:
>>> From: Fei Wang 
>>>
>>> Show the unsupported message and return unsupported for clips
>>> contain
>>> tile list OBU since it hasn't been implemented. Otherwise, decoding
>>> maybe successful but result is incorrect.
>>>
>>> Signed-off-by: Fei Wang 
>>> ---
>>>  libavcodec/av1dec.c | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
>>> index 4dcde234c6..629e37c3f8 100644
>>> --- a/libavcodec/av1dec.c
>>> +++ b/libavcodec/av1dec.c
>>> @@ -805,6 +805,7 @@ static const CodedBitstreamUnitType
>>> decompose_unit_types[] = {
>>>  AV1_OBU_SEQUENCE_HEADER,
>>>  AV1_OBU_TEMPORAL_DELIMITER,
>>>  AV1_OBU_TILE_GROUP,
>>> +AV1_OBU_TILE_LIST,
>>
>> What do you need this for? Decomposing it would only change whether
>> CodedBitstreamUnit.content is available, but you are only reading
>> CodedBitstreamUnit.type.
> 
> To show the unsupported error and let user know that there are tile
> list OBUs in bitstream that decoder can't handle them. Otherwise, like
> my commit mentioned, tile list obu bitsteam may be decoded 'successful'
> according to log.
> 

As I said: You do not need CodedBitstreamUnit.content for the error message.

>>
>>>  };
>>>  
>>>  static av_cold int av1_decode_init(AVCodecContext *avctx)
>>> @@ -1327,6 +1328,10 @@ static int
>>> av1_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
>>>  }
>>>  break;
>>>  case AV1_OBU_TILE_LIST:
>>> +av_log(avctx, AV_LOG_ERROR, "Large scale tile decoding
>>> is unsupported.\n");
>>> +ret = AVERROR_PATCHWELCOME;
>>> +goto end;
>>> +break;
>>>  case AV1_OBU_TEMPORAL_DELIMITER:
>>>  case AV1_OBU_PADDING:
>>>  break;
>>
>> ___
>> 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 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 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 6/6] lavc/takdsp: R-V V decorrelate_sm

[Rémi Denis-Courmont]

Le torstaina 21. joulukuuta 2023, 18.07.55 EET Rémi Denis-Courmont a écrit :
> You can use VSSRA, and then VADD won't need to depend on the output of VSUB.

P.S.: I have NOT checked which approach is actually faster.

-- 
Rémi Denis-Courmont
http://www.remlab.net/



___
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 6/6] lavc/takdsp: R-V V decorrelate_sm

[Rémi Denis-Courmont]

Le maanantaina 18. joulukuuta 2023, 17.16.27 EET flow gg a écrit :
> C908:
> decorrelate_sm_c: 130.0
> decorrelate_sm_rvv_i32: 43.7

+
+func ff_decorrelate_sm_rvv, zve32x
+1:
+vsetvli  t0, a2, e32, m8, ta, ma
+vle32.v  v0, (a0)
+sub a2,  a2, t0
+vle32.v  v8, (a1)
+vsra.vi  v16, v8, 1

You should load v8 first, since it is used as input before v0.

+vsub.vv  v0, v0, v16
+vse32.v  v0, (a0)
+sh2add   a0, t0, a0
+vadd.vv  v0, v0, v8

You can use VSSRA, and then VADD won't need to depend on the output of VSUB.

+vse32.v  v0, (a1)
+sh2add   a1, t0, a1
+bnez a2, 1b
+ret
+endfunc

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/



___
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 1/2] avformat/flvenc: support enhanced flv PacketTypeMetadata

[zhupengfei via ffmpeg-devel]

> 2023年12月18日 02:22，James Almer  写道：
> 
> On 12/17/2023 1:24 PM, zhupengfei via ffmpeg-devel wrote:
>> From: Zhu Pengfei <411294...@qq.com>
>> Signed-off-by: Zhu Pengfei <411294...@qq.com>
>> ---
>>  libavformat/flvenc.c | 155 +++
>>  1 file changed, 155 insertions(+)
>> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
>> index f6d10f331c..7268394b93 100644
>> --- a/libavformat/flvenc.c
>> +++ b/libavformat/flvenc.c
>> @@ -24,6 +24,7 @@
>>  #include "libavutil/intfloat.h"
>>  #include "libavutil/avassert.h"
>>  #include "libavutil/mathematics.h"
>> +#include "libavutil/mastering_display_metadata.h"
>>  #include "libavcodec/codec_desc.h"
>>  #include "libavcodec/mpeg4audio.h"
>>  #include "avio.h"
>> @@ -124,6 +125,7 @@ typedef struct FLVContext {
>>int flags;
>>  int64_t last_ts[FLV_STREAM_TYPE_NB];
>> +int write_metadata_pkt;
>>  } FLVContext;
>>static int get_audio_flags(AVFormatContext *s, AVCodecParameters *par)
>> @@ -478,6 +480,158 @@ static void write_metadata(AVFormatContext *s, 
>> unsigned int ts)
>>  avio_wb32(pb, flv->metadata_totalsize + 11);
>>  }
>>  +static void flv_write_metadata_packet(AVFormatContext *s, 
>> AVCodecParameters *par, unsigned int ts)
>> +{
>> +AVIOContext *pb = s->pb;
>> +FLVContext *flv = s->priv_data;
>> +AVContentLightMetadata *lightMetadata = NULL;
>> +AVMasteringDisplayMetadata *displayMetadata = NULL;
>> +const int flags_size = 5;
>> +int64_t metadata_size_pos = 0;
>> +int64_t total_size = 0;
>> +const AVPacketSideData *side_data = NULL;
>> +
>> +if (par->codec_id == AV_CODEC_ID_HEVC || par->codec_id == 
>> AV_CODEC_ID_AV1 ||
>> +par->codec_id == AV_CODEC_ID_VP9) {
>> +if (flv->write_metadata_pkt) return;
>> +
>> +side_data = av_packet_side_data_get(par->coded_side_data, 
>> par->nb_coded_side_data,
>> +
>> AV_PKT_DATA_CONTENT_LIGHT_LEVEL);
>> +if (side_data)
>> +lightMetadata = (AVContentLightMetadata *)side_data->data;
>> +
>> +side_data = av_packet_side_data_get(par->coded_side_data, 
>> par->nb_coded_side_data,
>> +
>> AV_PKT_DATA_MASTERING_DISPLAY_METADATA);
>> +if (side_data)
>> +displayMetadata = (AVMasteringDisplayMetadata *)side_data->data;
>> +
>> +if (!lightMetadata && !displayMetadata) return;
> 
> Again, why are you not writing anything when there's no static HDR metadata?
> transferCharacteristics, matrixCoefficients and colorPrimaries don't depend 
> on those, and can be written on their own. Similarly, you can write 
> lightMetadata when there's no displayMetadata, and vice versa.

This is a mistake,  I ignored this comment and will fix in the next patch.

> 
>> +
>> +/*
>> +* Reference Enhancing FLV
>> +* 
>> https://github.com/veovera/enhanced-rtmp/blob/main/enhanced-rtmp.pdf
>> +* */
>> +avio_w8(pb, FLV_TAG_TYPE_VIDEO); //write video tag type
>> +metadata_size_pos = avio_tell(pb);
>> +avio_wb24(pb, 0 + flags_size);
>> +put_timestamp(pb, ts); //ts = pkt->dts, gen
>> +avio_wb24(pb, flv->reserved);
>> +
>> +if (par->codec_id == AV_CODEC_ID_HEVC) {
>> +avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeMetadata| 
>> FLV_FRAME_VIDEO_INFO_CMD); // ExVideoTagHeader mode with PacketTypeMetadata
>> +avio_write(pb, "hvc1", 4);
>> +} else if (par->codec_id == AV_CODEC_ID_AV1 || par->codec_id == 
>> AV_CODEC_ID_VP9) {
>> +avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeMetadata| 
>> FLV_FRAME_VIDEO_INFO_CMD);
>> +avio_write(pb, par->codec_id == AV_CODEC_ID_AV1 ? "av01" : 
>> "vp09", 4);
>> +}
>> +
>> +avio_w8(pb, AMF_DATA_TYPE_STRING);
>> +put_amf_string(pb, "colorInfo");
>> +
>> +avio_w8(pb, AMF_DATA_TYPE_OBJECT);
>> +
>> +put_amf_string(pb, "colorConfig");  // colorConfig
>> +
>> +/* mixed array (hash) with size and string/type/data tuples */
>> +avio_w8(pb, AMF_DATA_TYPE_MIXEDARRAY);
>> +
>> +avio_wb32(pb, 0); // write array count
>> +
>> +if (par->color_trc != AVCOL_TRC_UNSPECIFIED &&
>> +par->color_trc < AVCOL_TRC_NB) {
>> +put_amf_string(pb, "transferCharacteristics");  // color_trc
>> +put_amf_double(pb, par->color_trc);
>> +}
>> +
>> +if (par->color_space != AVCOL_SPC_UNSPECIFIED &&
>> +par->color_space < AVCOL_SPC_NB) {
>> +put_amf_string(pb, "matrixCoefficients"); // colorspace
>> +put_amf_double(pb, par->color_space);
>> +}
>> +
>> +if (par->color_primaries != AVCOL_PRI_UNSPECIFIED &&
>> +par->color_primaries < AVCOL_PRI_NB) {
>> +put_amf_string(pb, "colorPrimaries"); // color_primaries
>> +put_amf_double(pb, par->color_primaries);
>> +}
>> +

Re: [FFmpeg-devel] [PATCH 3/3] avutil/hwcontext_d3d12va: remove unused variables

[Wu, Tong1]

>-Original Message-
>From: ffmpeg-devel  On Behalf Of James
>Almer
>Sent: Thursday, December 21, 2023 8:47 PM
>To: ffmpeg-devel@ffmpeg.org
>Subject: Re: [FFmpeg-devel] [PATCH 3/3] avutil/hwcontext_d3d12va: remove
>unused variables
>
>On 12/21/2023 9:42 AM, Martin Storsjö wrote:
>> On Thu, 21 Dec 2023, James Almer wrote:
>>
>>> Removes -Wunused-variable warnings.
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>> Were this meant to be used? Or are just a remnant of a previous
>>> interation of
>>> the set?

They are just leftovers of the previous version. Patch set LGTM, thanks.

>>>
>>> libavutil/hwcontext_d3d12va.c | 4 
>>> 1 file changed, 4 deletions(-)
>>>
>>> diff --git a/libavutil/hwcontext_d3d12va.c
>>> b/libavutil/hwcontext_d3d12va.c
>>> index 4ce29f250c..46832fd19b 100644
>>> --- a/libavutil/hwcontext_d3d12va.c
>>> +++ b/libavutil/hwcontext_d3d12va.c
>>> @@ -173,7 +173,6 @@ fail:
>>>
>>> static void d3d12va_frames_uninit(AVHWFramesContext *ctx)
>>> {
>>> -    AVD3D12VAFramesContext *frames_hwctx = ctx->hwctx;
>>>     D3D12VAFramesContext   *s    = ctx->internal->priv;
>>
>> Here, I'd prefer to get rid of the extra spaces once the other line,
>> which it was aligned to, is gone.
>>
>>> static int d3d12va_frames_init(AVHWFramesContext *ctx)
>>> {
>>>     AVD3D12VAFramesContext *hwctx    = ctx->hwctx;
>>> -    AVD3D12VADeviceContext *device_hwctx = ctx->device_ctx->hwctx;
>>> -    D3D12VAFramesContext   *s    = ctx->internal->priv;
>>
>> Ditto
>
>Amended locally. Thanks.
>___
>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 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 3/3] avutil/hwcontext_d3d12va: remove unused variables

[James Almer]

On 12/21/2023 9:42 AM, Martin Storsjö wrote:

On Thu, 21 Dec 2023, James Almer wrote:


Removes -Wunused-variable warnings.

Signed-off-by: James Almer 
---
Were this meant to be used? Or are just a remnant of a previous 
interation of

the set?

libavutil/hwcontext_d3d12va.c | 4 
1 file changed, 4 deletions(-)

diff --git a/libavutil/hwcontext_d3d12va.c 
b/libavutil/hwcontext_d3d12va.c

index 4ce29f250c..46832fd19b 100644
--- a/libavutil/hwcontext_d3d12va.c
+++ b/libavutil/hwcontext_d3d12va.c
@@ -173,7 +173,6 @@ fail:

static void d3d12va_frames_uninit(AVHWFramesContext *ctx)
{
-    AVD3D12VAFramesContext *frames_hwctx = ctx->hwctx;
    D3D12VAFramesContext   *s    = ctx->internal->priv;


Here, I'd prefer to get rid of the extra spaces once the other line, 
which it was aligned to, is gone.



static int d3d12va_frames_init(AVHWFramesContext *ctx)
{
    AVD3D12VAFramesContext *hwctx    = ctx->hwctx;
-    AVD3D12VADeviceContext *device_hwctx = ctx->device_ctx->hwctx;
-    D3D12VAFramesContext   *s    = ctx->internal->priv;


Ditto


Amended locally. Thanks.
___
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 3/3] avutil/hwcontext_d3d12va: remove unused variables

[Martin Storsjö]

On Thu, 21 Dec 2023, James Almer wrote:


Removes -Wunused-variable warnings.

Signed-off-by: James Almer 
---
Were this meant to be used? Or are just a remnant of a previous interation of
the set?

libavutil/hwcontext_d3d12va.c | 4 
1 file changed, 4 deletions(-)

diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
index 4ce29f250c..46832fd19b 100644
--- a/libavutil/hwcontext_d3d12va.c
+++ b/libavutil/hwcontext_d3d12va.c
@@ -173,7 +173,6 @@ fail:

static void d3d12va_frames_uninit(AVHWFramesContext *ctx)
{
-AVD3D12VAFramesContext *frames_hwctx = ctx->hwctx;
D3D12VAFramesContext   *s= ctx->internal->priv;


Here, I'd prefer to get rid of the extra spaces once the other line, which 
it was aligned to, is gone.



static int d3d12va_frames_init(AVHWFramesContext *ctx)
{
AVD3D12VAFramesContext *hwctx= ctx->hwctx;
-AVD3D12VADeviceContext *device_hwctx = ctx->device_ctx->hwctx;
-D3D12VAFramesContext   *s= ctx->internal->priv;


Ditto

// 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".

[FFmpeg-devel] [PATCH 3/3] avutil/hwcontext_d3d12va: remove unused variables

[James Almer]

Removes -Wunused-variable warnings.

Signed-off-by: James Almer 
---
Were this meant to be used? Or are just a remnant of a previous interation of
the set?

 libavutil/hwcontext_d3d12va.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
index 4ce29f250c..46832fd19b 100644
--- a/libavutil/hwcontext_d3d12va.c
+++ b/libavutil/hwcontext_d3d12va.c
@@ -173,7 +173,6 @@ fail:
 
 static void d3d12va_frames_uninit(AVHWFramesContext *ctx)
 {
-AVD3D12VAFramesContext *frames_hwctx = ctx->hwctx;
 D3D12VAFramesContext   *s= ctx->internal->priv;
 
 D3D12_OBJECT_RELEASE(s->sync_ctx.fence);
@@ -281,8 +280,6 @@ fail:
 static int d3d12va_frames_init(AVHWFramesContext *ctx)
 {
 AVD3D12VAFramesContext *hwctx= ctx->hwctx;
-AVD3D12VADeviceContext *device_hwctx = ctx->device_ctx->hwctx;
-D3D12VAFramesContext   *s= ctx->internal->priv;
 int i;
 
 for (i = 0; i < FF_ARRAY_ELEMS(supported_formats); i++) {
@@ -335,7 +332,6 @@ static int d3d12va_transfer_get_formats(AVHWFramesContext 
*ctx,
 enum AVHWFrameTransferDirection dir,
 enum AVPixelFormat **formats)
 {
-D3D12VAFramesContext *s = ctx->internal->priv;
 enum AVPixelFormat *fmts;
 
 fmts = av_malloc_array(2, sizeof(*fmts));
-- 
2.43.0

___
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/3] avutil/hwcontext_d3d12va: fix indentation in d3d12va_transfer_data()

[James Almer]

Removes -Wmisleading-indentation warnings.

Signed-off-by: James Almer 
---
 libavutil/hwcontext_d3d12va.c | 54 +--
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
index 052de3472f..4ce29f250c 100644
--- a/libavutil/hwcontext_d3d12va.c
+++ b/libavutil/hwcontext_d3d12va.c
@@ -410,35 +410,35 @@ static int d3d12va_transfer_data(AVHWFramesContext *ctx, 
AVFrame *dst,
 linesizes[i] = FFALIGN(frame->width * (frames_hwctx->format == 
DXGI_FORMAT_P010 ? 2 : 1),
D3D12_TEXTURE_DATA_PITCH_ALIGNMENT);
 
-staging_y_location = (D3D12_TEXTURE_COPY_LOCATION) {
-.Type  = D3D12_TEXTURE_COPY_TYPE_PLACED_FOOTPRINT,
-.PlacedFootprint = {
-.Offset = 0,
-.Footprint = {
-.Format   = frames_hwctx->format == DXGI_FORMAT_P010 ?
-DXGI_FORMAT_R16_UNORM 
: DXGI_FORMAT_R8_UNORM,
-.Width= ctx->width,
-.Height   = ctx->height,
-.Depth= 1,
-.RowPitch = linesizes[0],
-},
+staging_y_location = (D3D12_TEXTURE_COPY_LOCATION) {
+.Type  = D3D12_TEXTURE_COPY_TYPE_PLACED_FOOTPRINT,
+.PlacedFootprint = {
+.Offset = 0,
+.Footprint = {
+.Format   = frames_hwctx->format == DXGI_FORMAT_P010 ?
+DXGI_FORMAT_R16_UNORM : 
DXGI_FORMAT_R8_UNORM,
+.Width= ctx->width,
+.Height   = ctx->height,
+.Depth= 1,
+.RowPitch = linesizes[0],
 },
-};
-
-staging_uv_location = (D3D12_TEXTURE_COPY_LOCATION) {
-.Type  = D3D12_TEXTURE_COPY_TYPE_PLACED_FOOTPRINT,
-.PlacedFootprint = {
-.Offset = s->luma_component_size,
-.Footprint = {
-.Format   = frames_hwctx->format == DXGI_FORMAT_P010 ?
-
DXGI_FORMAT_R16G16_UNORM : DXGI_FORMAT_R8G8_UNORM,
-.Width= ctx->width  >> 1,
-.Height   = ctx->height >> 1,
-.Depth= 1,
-.RowPitch = linesizes[0],
-},
+},
+};
+
+staging_uv_location = (D3D12_TEXTURE_COPY_LOCATION) {
+.Type  = D3D12_TEXTURE_COPY_TYPE_PLACED_FOOTPRINT,
+.PlacedFootprint = {
+.Offset = s->luma_component_size,
+.Footprint = {
+.Format   = frames_hwctx->format == DXGI_FORMAT_P010 ?
+DXGI_FORMAT_R16G16_UNORM : 
DXGI_FORMAT_R8G8_UNORM,
+.Width= ctx->width  >> 1,
+.Height   = ctx->height >> 1,
+.Depth= 1,
+.RowPitch = linesizes[0],
 },
-};
+},
+};
 
 DX_CHECK(ID3D12CommandAllocator_Reset(s->command_allocator));
 
-- 
2.43.0

___
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/3] avutil/hwcontext_d3d12va: cast the input pointer array argument on av_image_copy calls

[James Almer]

Removes -Wincompatible-pointer-types warnings.

Signed-off-by: James Almer 
---
 libavutil/hwcontext_d3d12va.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
index 1600d94cb0..052de3472f 100644
--- a/libavutil/hwcontext_d3d12va.c
+++ b/libavutil/hwcontext_d3d12va.c
@@ -482,7 +482,7 @@ static int d3d12va_transfer_data(AVHWFramesContext *ctx, 
AVFrame *dst,
 DX_CHECK(ID3D12Resource_Map(s->staging_download_buffer, 0, NULL, (void 
**)_data));
 av_image_fill_pointers(data, ctx->sw_format, ctx->height, mapped_data, 
linesizes);
 
-av_image_copy(dst->data, dst->linesize, data, linesizes,
+av_image_copy(dst->data, dst->linesize,  (const uint8_t **)data, 
linesizes,
   ctx->sw_format, ctx->width, ctx->height);
 
 ID3D12Resource_Unmap(s->staging_download_buffer, 0, NULL);
@@ -500,7 +500,7 @@ static int d3d12va_transfer_data(AVHWFramesContext *ctx, 
AVFrame *dst,
 DX_CHECK(ID3D12Resource_Map(s->staging_upload_buffer, 0, NULL, (void 
**)_data));
 av_image_fill_pointers(data, ctx->sw_format, ctx->height, mapped_data, 
linesizes);
 
-av_image_copy(data, linesizes, src->data, src->linesize,
+av_image_copy(data, linesizes,  (const uint8_t **)src->data, 
src->linesize,
   ctx->sw_format, ctx->width, ctx->height);
 
 ID3D12Resource_Unmap(s->staging_upload_buffer, 0, NULL);
-- 
2.43.0

___
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: Generalize crash handling

[Martin Storsjö]

On Thu, 21 Dec 2023, Rémi Denis-Courmont wrote:


diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 6318d9296b..668034c67f 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -23,8 +23,10 @@
#include "config.h"
#include "config_components.h"

-#ifndef _GNU_SOURCE
-# define _GNU_SOURCE // for syscall (performance monitoring API), strsignal()
+#if CONFIG_LINUX_PERF
+# ifndef _GNU_SOURCE
+#  define _GNU_SOURCE // for syscall (performance monitoring API)
+# endif
#endif

#include 
@@ -326,6 +328,7 @@ static struct {
const char *cpu_flag_name;
const char *test_name;
int verbose;
+int catch_signals;
} state;

/* PRNG state */
@@ -627,6 +630,64 @@ static CheckasmFunc *get_func(CheckasmFunc **root, const 
char *name)
return f;
}

+checkasm_context checkasm_context_buf;
+
+/* Crash handling: attempt to catch crashes and handle them
+ * gracefully instead of just aborting abruptly. */
+#ifdef _WIN32
+#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
+static LONG NTAPI signal_handler(EXCEPTION_POINTERS *const e) {
+const char *err;
+
+if (!state.catch_signals)
+return EXCEPTION_CONTINUE_SEARCH;
+
+switch (e->ExceptionRecord->ExceptionCode) {
+case EXCEPTION_FLT_DIVIDE_BY_ZERO:
+case EXCEPTION_INT_DIVIDE_BY_ZERO:
+err = "fatal arithmetic error";
+break;
+case EXCEPTION_ILLEGAL_INSTRUCTION:
+case EXCEPTION_PRIV_INSTRUCTION:
+err = "illegal instruction";
+break;
+case EXCEPTION_ACCESS_VIOLATION:
+case EXCEPTION_ARRAY_BOUNDS_EXCEEDED:
+case EXCEPTION_DATATYPE_MISALIGNMENT:
+case EXCEPTION_STACK_OVERFLOW:
+err = "segmentation fault";
+break;
+case EXCEPTION_IN_PAGE_ERROR:
+err = "bus error";
+break;
+default:
+return EXCEPTION_CONTINUE_SEARCH;
+}
+state.catch_signals = 0;
+checkasm_fail_func("%s", err);
+checkasm_load_context();
+return EXCEPTION_CONTINUE_EXECUTION; /* never reached, but shuts up gcc */
+}
+#endif
+#else
+static void signal_handler(const int s) {
+if (state.catch_signals) {
+state.catch_signals = 0;
+checkasm_fail_func("%s",
+   s == SIGFPE ? "fatal arithmetic error" :
+   s == SIGILL ? "illegal instruction" :
+   s == SIGBUS ? "bus error" :
+ "segmentation fault");
+checkasm_load_context();


Use of format string is probably not async-signal-safe.


I'll have a look if it's possible to restructure this into doing the 
checkasm_fail_func call afterwards.


I would also be surprised if the load_context() function was safe in 
signal context. That's why the current code does pretty much nothing 
other than a long jump.


The load_context() function here is either longjmp or RtlRestoreContext.

// 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 v2] avutil/hwcontext_d3d12va: remove an unused function

[Martin Storsjö]

On Thu, 21 Dec 2023, Tong Wu wrote:


It caused lacking a public declaration build error with
-Werror=missing-prototypes.

Since DXGI_FORMAT is moved to public since patch set V10, this function
is no longer useful. Now remove it.

Signed-off-by: Tong Wu 
---
libavutil/hwcontext_d3d12va.c | 9 -
1 file changed, 9 deletions(-)


LGTM, thanks.

// 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] avutil/hwcontext_d3d12va: remove an unused function

[Wu, Tong1]

>
>On Thu, 21 Dec 2023, Tong Wu wrote:
>
>> Signed-off-by: Tong Wu 
>> ---
>> libavutil/hwcontext_d3d12va.c | 9 -
>> 1 file changed, 9 deletions(-)
>>
>> diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
>> index 1600d94cb0..4995518dbd 100644
>> --- a/libavutil/hwcontext_d3d12va.c
>> +++ b/libavutil/hwcontext_d3d12va.c
>> @@ -71,15 +71,6 @@ static void d3d12va_default_unlock(void *ctx)
>> ReleaseMutex(ctx);
>> }
>>
>> -DXGI_FORMAT av_d3d12va_map_sw_to_hw_format(enum AVPixelFormat
>pix_fmt)
>> -{
>> -switch (pix_fmt) {
>> -case AV_PIX_FMT_NV12:return DXGI_FORMAT_NV12;
>> -case AV_PIX_FMT_P010:return DXGI_FORMAT_P010;
>> -default: return DXGI_FORMAT_UNKNOWN;
>> -}
>> -}
>> -
>> static int d3d12va_fence_completion(AVD3D12VASyncContext *psync_ctx)
>> {
>> uint64_t completion = ID3D12Fence_GetCompletedValue(psync_ctx-
>>fence);
>> --
>> 2.41.0.windows.1
>
>LGTM, thanks.
>
>It might be good to mention that it was lacking a public declaration,
>which caused builds with -Werror=missing-prototypes to fail, and the
>reason why it was left behind and not needed.
>
>// Martin

Thanks, updated it.

___
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] avutil/hwcontext_d3d12va: remove an unused function

[Tong Wu]

It caused lacking a public declaration build error with
-Werror=missing-prototypes.

Since DXGI_FORMAT is moved to public since patch set V10, this function
is no longer useful. Now remove it.

Signed-off-by: Tong Wu 
---
 libavutil/hwcontext_d3d12va.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
index 1600d94cb0..4995518dbd 100644
--- a/libavutil/hwcontext_d3d12va.c
+++ b/libavutil/hwcontext_d3d12va.c
@@ -71,15 +71,6 @@ static void d3d12va_default_unlock(void *ctx)
 ReleaseMutex(ctx);
 }
 
-DXGI_FORMAT av_d3d12va_map_sw_to_hw_format(enum AVPixelFormat pix_fmt)
-{
-switch (pix_fmt) {
-case AV_PIX_FMT_NV12:return DXGI_FORMAT_NV12;
-case AV_PIX_FMT_P010:return DXGI_FORMAT_P010;
-default: return DXGI_FORMAT_UNKNOWN;
-}
-}
-
 static int d3d12va_fence_completion(AVD3D12VASyncContext *psync_ctx)
 {
 uint64_t completion = ID3D12Fence_GetCompletedValue(psync_ctx->fence);
-- 
2.41.0.windows.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] checkasm: Generalize crash handling

[Rémi Denis-Courmont]

Le 19 décembre 2023 14:02:00 GMT+02:00, "Martin Storsjö"  a 
écrit :
>This replaces the riscv specific handling from
>7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is
>reverted, together with 286d6742218ba0235c32876b50bf593cb1986353)
>with a different implementation of the same (plus a bit more), based
>on the corresponding feature in dav1d's checkasm, supporting both Unix
>and Windows.
>
>See in particular dav1d commits
>0b6ee30eab2400e4f85b735ad29a68a842c34e21 and
>0421f787ea592fd2cc74c887f20b8dc31393788b, authored by
>Henrik Gramner.
>
>The overall approach is the same; set up a signal handler,
>store the state with setjmp/sigsetjmp, jump out of the crashing
>function with longjmp/siglongjmp.
>
>The main difference is in what happens when the signal handler
>is invoked. In the previous implementation, it would resume from
>right before calling the crashing function, and then skip that call
>based on the setjmp return value.
>
>In the imported implementation from dav1d, we return to right before
>the check_func() call, which will skip testing the current function
>(as the pointer is the same as it was before).
>
>Other differences are:
>- Support for other signal handling mechanisms (Windows
>  AddVectoredExceptionHandler)
>- Using RtlCaptureContext/RtlRestoreContext instead of setjmp/longjmp
>  on Windows with SEH (which adds the design limitation that it doesn't
>  return a value like setjmp does)
>- Only catching signals once per function - if more than one
>  signal is delivered before signal handling is reenabled, any
>  signal is handled as it would without our handler
>- Not using an arch specific signal handler written in assembly
>---
> tests/checkasm/checkasm.c   | 100 ++--
> tests/checkasm/checkasm.h   |  79 ++---
> tests/checkasm/riscv/checkasm.S |  12 
> 3 files changed, 140 insertions(+), 51 deletions(-)
>
>diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
>index 6318d9296b..668034c67f 100644
>--- a/tests/checkasm/checkasm.c
>+++ b/tests/checkasm/checkasm.c
>@@ -23,8 +23,10 @@
> #include "config.h"
> #include "config_components.h"
> 
>-#ifndef _GNU_SOURCE
>-# define _GNU_SOURCE // for syscall (performance monitoring API), strsignal()
>+#if CONFIG_LINUX_PERF
>+# ifndef _GNU_SOURCE
>+#  define _GNU_SOURCE // for syscall (performance monitoring API)
>+# endif
> #endif
> 
> #include 
>@@ -326,6 +328,7 @@ static struct {
> const char *cpu_flag_name;
> const char *test_name;
> int verbose;
>+int catch_signals;
> } state;
> 
> /* PRNG state */
>@@ -627,6 +630,64 @@ static CheckasmFunc *get_func(CheckasmFunc **root, const 
>char *name)
> return f;
> }
> 
>+checkasm_context checkasm_context_buf;
>+
>+/* Crash handling: attempt to catch crashes and handle them
>+ * gracefully instead of just aborting abruptly. */
>+#ifdef _WIN32
>+#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
>+static LONG NTAPI signal_handler(EXCEPTION_POINTERS *const e) {
>+const char *err;
>+
>+if (!state.catch_signals)
>+return EXCEPTION_CONTINUE_SEARCH;
>+
>+switch (e->ExceptionRecord->ExceptionCode) {
>+case EXCEPTION_FLT_DIVIDE_BY_ZERO:
>+case EXCEPTION_INT_DIVIDE_BY_ZERO:
>+err = "fatal arithmetic error";
>+break;
>+case EXCEPTION_ILLEGAL_INSTRUCTION:
>+case EXCEPTION_PRIV_INSTRUCTION:
>+err = "illegal instruction";
>+break;
>+case EXCEPTION_ACCESS_VIOLATION:
>+case EXCEPTION_ARRAY_BOUNDS_EXCEEDED:
>+case EXCEPTION_DATATYPE_MISALIGNMENT:
>+case EXCEPTION_STACK_OVERFLOW:
>+err = "segmentation fault";
>+break;
>+case EXCEPTION_IN_PAGE_ERROR:
>+err = "bus error";
>+break;
>+default:
>+return EXCEPTION_CONTINUE_SEARCH;
>+}
>+state.catch_signals = 0;
>+checkasm_fail_func("%s", err);
>+checkasm_load_context();
>+return EXCEPTION_CONTINUE_EXECUTION; /* never reached, but shuts up gcc */
>+}
>+#endif
>+#else
>+static void signal_handler(const int s) {
>+if (state.catch_signals) {
>+state.catch_signals = 0;
>+checkasm_fail_func("%s",
>+   s == SIGFPE ? "fatal arithmetic error" :
>+   s == SIGILL ? "illegal instruction" :
>+   s == SIGBUS ? "bus error" :
>+ "segmentation fault");
>+checkasm_load_context();

Use of format string is probably not async-signal-safe. I would also be 
surprised if the load_context() function was safe in signal context. That's why 
the current code does pretty much nothing other than a long jump.

>+} else {
>+/* fall back to the default signal handler */
>+static const struct sigaction default_sa = { .sa_handler = SIG_DFL };
>+sigaction(s, _sa, NULL);
>+raise(s);
>+}
>+}
>+#endif
>+
> /* Perform tests and benchmarks for the specified cpu flag if supported by 
> 

Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_d3d12va: remove an unused function

[Martin Storsjö]

On Thu, 21 Dec 2023, Tong Wu wrote:


Signed-off-by: Tong Wu 
---
libavutil/hwcontext_d3d12va.c | 9 -
1 file changed, 9 deletions(-)

diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
index 1600d94cb0..4995518dbd 100644
--- a/libavutil/hwcontext_d3d12va.c
+++ b/libavutil/hwcontext_d3d12va.c
@@ -71,15 +71,6 @@ static void d3d12va_default_unlock(void *ctx)
ReleaseMutex(ctx);
}

-DXGI_FORMAT av_d3d12va_map_sw_to_hw_format(enum AVPixelFormat pix_fmt)
-{
-switch (pix_fmt) {
-case AV_PIX_FMT_NV12:return DXGI_FORMAT_NV12;
-case AV_PIX_FMT_P010:return DXGI_FORMAT_P010;
-default: return DXGI_FORMAT_UNKNOWN;
-}
-}
-
static int d3d12va_fence_completion(AVD3D12VASyncContext *psync_ctx)
{
uint64_t completion = ID3D12Fence_GetCompletedValue(psync_ctx->fence);
--
2.41.0.windows.1


LGTM, thanks.

It might be good to mention that it was lacking a public declaration, 
which caused builds with -Werror=missing-prototypes to fail, and the 
reason why it was left behind and not needed.


// 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 13/13 v3] fftools/ffmpeg: convert to a threaded architecture

[Paul B Mahol]

On Thu, Dec 7, 2023 at 6:26 PM Paul B Mahol  wrote:

>
>
> On Wed, Dec 6, 2023 at 2:38 PM Nicolas George  wrote:
>
>> James Almer (12023-12-06):
>> > I honestly can't believe you're arguing this.
>>
>> Yet I do, so I suggest you think a little harder to understand why I do.
>>
>> > And being condescending will not help your case.
>>
>> Can you tell that to Anton too please?
>>
>> > If i request -bitexact, i want bitexact output, regardless of running
>> on a
>> > core i3 or a Threadripper. There's nothing more to it.
>>
>> I had not noticed the -bitexact on the test command line. I will grant
>> the change is acceptable if bit-exact is requested.
>>
>> > Calling random output that happens to be "acceptable" within the
>> subjective
>> > expectations of the user as useful sounds to me like you're trying to
>> find
>> > an excuse to keep buggy code with unpredictable results around, just
>> because
>> > it's been there for a long time.
>>
>> Well, you are wrong, and what I explained is the real reason: most
>> subtitles are not timed that accurately. The subtitles on HBO's Last
>> Week Tonight, for example, can randomly lag or be early by several
>> seconds. Even serious subtitles, like the ones for scripted shows on
>> Netflix/Amazon/Crunchyroll/whatever vary by a few tenths of seconds,
>> i.e. several frames.
>>
>> And I have used this code. And I look carefully at subtitles. If the
>> result was lower quality than the source material, I would have noticed
>> and I would have endeavored to fix it. There never was need.
>>
>> Now, can Anton claim similar experience working with subtitles from the
>> real world? Most of this discussions points to the answer being no.
>>
>> > So, like Anton has asked several times, suggest a way to keep
>> deterministic
>> > and bitexact output without exponentially increasing memory consumption
>> due
>> > to buffering.
>>
>> I will spend time and effort searching for a solution when we agree to
>> work together.
>>
>> “Do this or I will break your code” is an unacceptable behavior, whether
>> it is directed at me or at Paul or at anybody else, and I do not spend
>> effort when unacceptable behavior is tolerated.
>>
>>
> From 3.4 version of ffmpeg to 6.1 version demuxing  truehd (-c:a copy)
> files dropped by factor of 2x speed.
> But simple transcode from doc/examples is still several times faster than
> that.
>
> I bet using mutexes and condition variables is far from perfect solution
> or fftools/ code is buggy.
>
> This is similar to -lavfi sources dropouts in performance but more used by
> users of truehd/any small packets format.
>

I found out if I increase queue size of thread for frames/packets in
fftools/ from 1 to >1 it increases speed in decoding by 10%.
Looks like other numbers greater than 2 do not make much any difference.

Still current state is sub-optimal.
___
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 v12 1/9] libavutil: add hwcontext_d3d12va and AV_PIX_FMT_D3D12

[Wu, Tong1]

>There are still no public external API users to actually test the API,
>which is concerning. It took months for the Vulkan API to be portable
>enough to work with the major Vulkan users out there. Granted, Vulkan
>is special.
>
>Is there any public test code out there? If not, I'd prefer the API to be
>declared as experimental for now, so we can make changes if needed.
>

Actually there have already been a number of discussions on this before for VLC 
and MPV.
https://code.videolan.org/videolan/vlc/-/issues/28360
https://github.com/mpv-player/mpv/issues/12071

Some have tried by themselves and it's working well. Since it cannot be 
official and public before it lands in FFmpeg, I believe it's probably very 
soon to have d3d12 hwdec support for them.

Thanks,
Tong


>Dec 21, 2023, 09:31 by haihao.xiang-at-intel@ffmpeg.org:
>
>> On Ma, 2023-12-18 at 06:28 +, Xiang, Haihao wrote:
>>
>>> On Di, 2023-12-05 at 14:46 +0800, Tong Wu wrote:
>>> > From: Wu Jianhua 
>>> >
>>> > Signed-off-by: Wu Jianhua 
>>> > Signed-off-by: Tong Wu 
>>> > ---
>>> >
>>> > Compared to v11, v12 set the initial value to 0 for the fence value,
>>> > fixing a potential dynamic pool sync issue. Hence removed the non zero
>>> > initial_pool_size for
>>> > d3d12va decoder.
>>> >
>>> > Some other minor error message changes.
>>> >
>>> >
>>> >
>>> >  configure  |   5 +
>>> >  doc/APIchanges |   5 +
>>> >  libavutil/Makefile |   3 +
>>> >  libavutil/hwcontext.c  |   4 +
>>> >  libavutil/hwcontext.h  |   1 +
>>> >  libavutil/hwcontext_d3d12va.c  | 703 +
>>> >  libavutil/hwcontext_d3d12va.h  | 134 +
>>> >  libavutil/hwcontext_d3d12va_internal.h |  59 +++
>>> >  libavutil/hwcontext_internal.h |   1 +
>>> >  libavutil/pixdesc.c    |   4 +
>>> >  libavutil/pixfmt.h |   7 +
>>> >  libavutil/tests/hwdevice.c |   2 +
>>> >  libavutil/version.h    |   2 +-
>>> >  13 files changed, 929 insertions(+), 1 deletion(-)
>>> >  create mode 100644 libavutil/hwcontext_d3d12va.c
>>> >  create mode 100644 libavutil/hwcontext_d3d12va.h
>>> >  create mode 100644 libavutil/hwcontext_d3d12va_internal.h
>>> >
>>> > diff --git a/configure b/configure
>>> > index d77c053226..1a343ac6b9 100755
>>> > --- a/configure
>>> > +++ b/configure
>>> > @@ -336,6 +336,7 @@ External library support:
>>> >    --disable-cuda-llvm  disable CUDA compilation using clang
>>> > [autodetect]
>>> >    --disable-cuvid  disable Nvidia CUVID support [autodetect]
>>> >    --disable-d3d11va    disable Microsoft Direct3D 11 video 
>>> > acceleration
>>> > code [autodetect]
>>> > +  --disable-d3d12va    disable Microsoft Direct3D 12 video 
>>> > acceleration
>>> > code [autodetect]
>>> >    --disable-dxva2  disable Microsoft DirectX 9 video acceleration
>>> > code [autodetect]
>>> >    --disable-ffnvcodec  disable dynamically linked Nvidia code
>>> > [autodetect]
>>> >    --enable-libdrm  enable DRM code (Linux) [no]
>>> > @@ -1926,6 +1927,7 @@ HWACCEL_AUTODETECT_LIBRARY_LIST="
>>> >  cuda_llvm
>>> >  cuvid
>>> >  d3d11va
>>> > +    d3d12va
>>> >  dxva2
>>> >  ffnvcodec
>>> >  nvdec
>>> > @@ -3048,6 +3050,7 @@ crystalhd_deps="libcrystalhd_libcrystalhd_if_h"
>>> >  cuda_deps="ffnvcodec"
>>> >  cuvid_deps="ffnvcodec"
>>> >  d3d11va_deps="dxva_h ID3D11VideoDecoder ID3D11VideoContext"
>>> > +d3d12va_deps="dxva_h ID3D12Device ID3D12VideoDecoder"
>>> >  dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode ole32 user32"
>>> >  ffnvcodec_deps_any="libdl LoadLibrary"
>>> >  mediacodec_deps="android"
>>> > @@ -6575,6 +6578,8 @@ check_type "windows.h dxgi1_2.h"
>"IDXGIOutput1"
>>> >  check_type "windows.h dxgi1_5.h" "IDXGIOutput5"
>>> >  check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
>>> >  check_type "windows.h d3d11.h" "ID3D11VideoContext"
>>> > +check_type "windows.h d3d12.h" "ID3D12Device"
>>> > +check_type "windows.h d3d12video.h" "ID3D12VideoDecoder"
>>> >  check_type "windows.h" "DPI_AWARENESS_CONTEXT" -
>D_WIN32_WINNT=0x0A00
>>> >  check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -
>>> > D_WIN32_WINNT=0x0602
>>> >  check_func_headers mfapi.h MFCreateAlignedMemoryBuffer -lmfplat
>>> > diff --git a/doc/APIchanges b/doc/APIchanges
>>> > index 4a2dc1c44f..0435926d80 100644
>>> > --- a/doc/APIchanges
>>> > +++ b/doc/APIchanges
>>> > @@ -2,6 +2,11 @@ The last version increases of all libraries were on
>2023-
>>> > 02-
>>> > 09
>>> >
>>> >  API changes, most recent first:
>>> >
>>> > +2023-11-07 - xx - lavu 58.33.100 - pixfmt.h hwcontext.h
>>> > hwcontext_d3d12va.h
>>> > +  Add AV_HWDEVICE_TYPE_D3D12VA and AV_PIX_FMT_D3D12.
>>> > +  Add AVD3D12VADeviceContext, AVD3D12VASyncContext,
>AVD3D12VAFrame and
>>> > +  AVD3D12VAFramesContext.
>>> > +
>>> >  2023-11-08 - b82957a66a7 - lavu 58.32.100 - 

Re: [FFmpeg-devel] [PATCH] checkasm: Generalize crash handling

[Henrik Gramner via ffmpeg-devel]

On Tue, Dec 19, 2023 at 1:02 PM Martin Storsjö  wrote:
> This replaces the riscv specific handling from
> 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is
> reverted, together with 286d6742218ba0235c32876b50bf593cb1986353)
> with a different implementation of the same (plus a bit more), based
> on the corresponding feature in dav1d's checkasm, supporting both Unix
> and Windows.

lgtm
___
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] d3d12va: Add a missing include for the declaration of ff_d3d12va_get_surface_index

[Wu, Tong1]

>From: ffmpeg-devel  On Behalf Of
>Martin Storsjö
>Sent: Thursday, December 21, 2023 5:48 PM
>To: ffmpeg-devel@ffmpeg.org
>Cc: Xiang, Haihao 
>Subject: Re: [FFmpeg-devel] [PATCH] d3d12va: Add a missing include for the
>declaration of ff_d3d12va_get_surface_index
>
>On Thu, 21 Dec 2023, Martin Storsjö wrote:
>
>> This fixes the following build error:
>>
>> src/libavcodec/d3d12va_decode.c:49:10: error: no previous prototype for
>function
>> 'ff_d3d12va_get_surface_index' [-Werror,-Wmissing-prototypes]
>>   49 | unsigned ff_d3d12va_get_surface_index(const AVCodecContext *avctx,
>>  |  ^
>> ---
>> libavcodec/d3d12va_decode.c | 1 +
>> 1 file changed, 1 insertion(+)
>
>Even after this change, the build still fails on a later file:
>
>src/libavutil/hwcontext_d3d12va.c:74:13: error: no previous prototype for
>function 'av_d3d12va_map_sw_to_hw_format' [-Werror,-Wmissing-
>prototypes]
>74 | DXGI_FORMAT av_d3d12va_map_sw_to_hw_format(enum
>AVPixelFormat pix_fmt)
>   | ^
>
>There's no declaration of this in any header - so please either make it
>static or ff_ prefixed, or add it to a header with the declaration visible
>at the function definition.
>
>// Martin

Thanks for pointing this out. I've sent a patch to remove this function. It's 
been useless after the d3d format became public at some previous version.

>
>___
>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 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] d3d12va: Add a missing include for the declaration of ff_d3d12va_get_surface_index

[Wu, Tong1]

>-Original Message-
>From: ffmpeg-devel  On Behalf Of
>Martin Storsjö
>Sent: Thursday, December 21, 2023 5:45 PM
>To: ffmpeg-devel@ffmpeg.org
>Cc: Xiang, Haihao 
>Subject: [FFmpeg-devel] [PATCH] d3d12va: Add a missing include for the
>declaration of ff_d3d12va_get_surface_index
>
>This fixes the following build error:
>
>src/libavcodec/d3d12va_decode.c:49:10: error: no previous prototype for
>function
> 'ff_d3d12va_get_surface_index' [-Werror,-Wmissing-prototypes]
>   49 | unsigned ff_d3d12va_get_surface_index(const AVCodecContext *avctx,
>  |  ^
>---
> libavcodec/d3d12va_decode.c | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/libavcodec/d3d12va_decode.c b/libavcodec/d3d12va_decode.c
>index 03e565066c..e0b67bf964 100644
>--- a/libavcodec/d3d12va_decode.c
>+++ b/libavcodec/d3d12va_decode.c
>@@ -33,6 +33,7 @@
> #include "avcodec.h"
> #include "decode.h"
> #include "d3d12va_decode.h"
>+#include "dxva2_internal.h"
>
> typedef struct HelperObjects {
> ID3D12CommandAllocator *command_allocator;
>--
>2.34.1
>

LGTM, 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-requ...@ffmpeg.org with subject "unsubscribe".
___
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] avutil/hwcontext_d3d12va: remove an unused function

[Tong Wu]

Signed-off-by: Tong Wu 
---
 libavutil/hwcontext_d3d12va.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
index 1600d94cb0..4995518dbd 100644
--- a/libavutil/hwcontext_d3d12va.c
+++ b/libavutil/hwcontext_d3d12va.c
@@ -71,15 +71,6 @@ static void d3d12va_default_unlock(void *ctx)
 ReleaseMutex(ctx);
 }
 
-DXGI_FORMAT av_d3d12va_map_sw_to_hw_format(enum AVPixelFormat pix_fmt)
-{
-switch (pix_fmt) {
-case AV_PIX_FMT_NV12:return DXGI_FORMAT_NV12;
-case AV_PIX_FMT_P010:return DXGI_FORMAT_P010;
-default: return DXGI_FORMAT_UNKNOWN;
-}
-}
-
 static int d3d12va_fence_completion(AVD3D12VASyncContext *psync_ctx)
 {
 uint64_t completion = ID3D12Fence_GetCompletedValue(psync_ctx->fence);
-- 
2.41.0.windows.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] [MXF] - Add jpeg2000 subdescriptor in MXF file (V2).

[Tomas Härdin]

ons 2023-12-20 klockan 18:04 +0100 skrev Cédric Le Barz:
> Le 19/12/2023 à 14:36, Tomas Härdin a écrit :
> > > +    for ( comp = 0; comp < component_count; comp++ ) {
> > > +    avio_write(pb, >j2k_info.j2k_comp_desc[3*comp] , 3);
> > > +    }
> > Looks like this could be simplified to just
> > 
> >    avio_write(pb, sc->j2k_info.j2k_comp_desc, 3*component_count);
> > 
> > > +    if (j2k_ncomponents != component_count) {
> > > +    av_log(s, AV_LOG_ERROR, "Incoherence about components
> > > image
> > > number.\n");
> > > +    }
> > I again feel this should be a hard error
> > 
> > > +    for (comp = 0; comp < j2k_ncomponents; comp++) {
> > > +    sc->j2k_info.j2k_comp_desc[comp*j2k_ncomponents] =
> > > bytestream2_get_byteu();   // Bitdepth for each component
> > > +    sc->j2k_info.j2k_comp_desc[comp*j2k_ncomponents+1] =
> > > bytestream2_get_byteu(); // Horizontal sampling for each
> > > component
> > > +    sc->j2k_info.j2k_comp_desc[comp*j2k_ncomponents+2] =
> > > bytestream2_get_byteu(); // Vertical sampling for each
> > > component
> > > +    }
> > Could be simplified to a single avio_read()
> > 
> > /Tomas
> > ___
> > 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".
> 
> Here is the new version of the patch taken into account your remarks.

Looks OK. Does this also work with RGB(A)? Seems to not be hardcoded
for YUV at least. Higher bitdepths would also be nice, I've been
working with lossless RGB48 J2K. Doesn't necessarily need to hold up
this patch, just curious.

/Tomas
___
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] avformat/riffenc: don't force WAVEFORMATEXTENSIBLE for flt/dbl LPCM

[Gyan Doshi]

2c2a167ca7 forced WAVEFORMATEXTENSIBLE for all LPCM streams with greater
than 16 bits per sample. However, WAVEFORMATEX allows IEEE Float samples
or any depth where raw depth == coded depth, see Remarks section at
https://learn.microsoft.com/en-us/windows/win32/api/mmreg/ns-mmreg-waveformatex
and samples M1F1-float32-AFsp, M1F1-float64-AFsp at
https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples.html

There are hardware devices and likely software players requiring float samples
that fail to qualify files with WAVEFORMATEXTENSIBLE headers.
---
Patchwork shows 2 tests failing that apparently weren't carried out locally.

 libavformat/riffenc.c   |  2 +-
 tests/ref/acodec/pcm-f32le  |  4 +--
 tests/ref/acodec/pcm-f64le  |  4 +--
 tests/ref/seek/acodec-pcm-f32le | 54 -
 tests/ref/seek/acodec-pcm-f64le | 54 -
 5 files changed, 59 insertions(+), 59 deletions(-)

diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 3325419b94..8accb69541 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -81,7 +81,7 @@ int ff_put_wav_header(AVFormatContext *s, AVIOContext *pb,
 av_channel_layout_compare(>ch_layout, 
&(AVChannelLayout)AV_CHANNEL_LAYOUT_STEREO)) ||
par->sample_rate > 48000 ||
par->codec_id == AV_CODEC_ID_EAC3 || par->codec_id 
== AV_CODEC_ID_DFPWM ||
-   av_get_bits_per_sample(par->codec_id) > 16;
+   (av_get_bits_per_sample(par->codec_id) > 16 && 
par->codec_tag != 0x0003);
 
 if (waveformatextensible)
 avio_wl16(pb, 0xfffe);
diff --git a/tests/ref/acodec/pcm-f32le b/tests/ref/acodec/pcm-f32le
index c0fdd70cd2..c63a2c4b70 100644
--- a/tests/ref/acodec/pcm-f32le
+++ b/tests/ref/acodec/pcm-f32le
@@ -1,4 +1,4 @@
-653d82a64b7bd96ac193e105e9f92d4c *tests/data/fate/acodec-pcm-f32le.wav
-2116880 tests/data/fate/acodec-pcm-f32le.wav
+03ae40a19deacaca6e0c4ec08dd35956 *tests/data/fate/acodec-pcm-f32le.wav
+2116858 tests/data/fate/acodec-pcm-f32le.wav
 95e54b261530a1bcf6de6fe3b21dc5f6 *tests/data/fate/acodec-pcm-f32le.out.wav
 stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  1058400/  1058400
diff --git a/tests/ref/acodec/pcm-f64le b/tests/ref/acodec/pcm-f64le
index 5c90e7bbbd..894d593ac1 100644
--- a/tests/ref/acodec/pcm-f64le
+++ b/tests/ref/acodec/pcm-f64le
@@ -1,4 +1,4 @@
-48b4cd378f47a50dc902aa03cc8280ed *tests/data/fate/acodec-pcm-f64le.wav
-4233680 tests/data/fate/acodec-pcm-f64le.wav
+69ffdb079600c53a00c5b0119b586a98 *tests/data/fate/acodec-pcm-f64le.wav
+4233658 tests/data/fate/acodec-pcm-f64le.wav
 95e54b261530a1bcf6de6fe3b21dc5f6 *tests/data/fate/acodec-pcm-f64le.out.wav
 stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  1058400/  1058400
diff --git a/tests/ref/seek/acodec-pcm-f32le b/tests/ref/seek/acodec-pcm-f32le
index 335a8a0729..0b6bb33bcb 100644
--- a/tests/ref/seek/acodec-pcm-f32le
+++ b/tests/ref/seek/acodec-pcm-f32le
@@ -1,53 +1,53 @@
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 80 size:  
4096
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 58 size:  
4096
 ret: 0 st:-1 flags:0  ts:-1.00
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 80 size:  
4096
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 58 size:  
4096
 ret: 0 st:-1 flags:1  ts: 1.894167
-ret: 0 st: 0 flags:1 dts: 1.894172 pts: 1.894172 pos: 668344 size:  
4096
+ret: 0 st: 0 flags:1 dts: 1.894172 pts: 1.894172 pos: 668322 size:  
4096
 ret: 0 st: 0 flags:0  ts: 0.788345
-ret: 0 st: 0 flags:1 dts: 0.788345 pts: 0.788345 pos: 278208 size:  
4096
+ret: 0 st: 0 flags:1 dts: 0.788345 pts: 0.788345 pos: 278186 size:  
4096
 ret: 0 st: 0 flags:1  ts:-0.317506
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 80 size:  
4096
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 58 size:  
4096
 ret: 0 st:-1 flags:0  ts: 2.576668
-ret: 0 st: 0 flags:1 dts: 2.576667 pts: 2.576667 pos: 909128 size:  
4096
+ret: 0 st: 0 flags:1 dts: 2.576667 pts: 2.576667 pos: 909106 size:  
4096
 ret: 0 st:-1 flags:1  ts: 1.470835
-ret: 0 st: 0 flags:1 dts: 1.470839 pts: 1.470839 pos: 518992 size:  
4096
+ret: 0 st: 0 flags:1 dts: 1.470839 pts: 1.470839 pos: 518970 size:  
4096
 ret: 0 st: 0 flags:0  ts: 0.365011
-ret: 0 st: 0 flags:1 dts: 0.365011 pts: 0.365011 pos: 128856 size:  
4096
+ret: 0 st: 0 flags:1 dts: 0.365011 pts: 0.365011 pos: 128834 size:  
4096
 ret: 0 st: 0 flags:1  ts:-0.740839
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 80 size:  
4096
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 58 size:  
4096
 ret: 0 st:-1 flags:0  ts: 2.153336
-ret: 0 st: 0 flags:1 dts: 2.15 pts: 

Re: [FFmpeg-devel] [PATCH] d3d12va: Add a missing include for the declaration of ff_d3d12va_get_surface_index

[Martin Storsjö]

On Thu, 21 Dec 2023, Martin Storsjö wrote:


This fixes the following build error:

src/libavcodec/d3d12va_decode.c:49:10: error: no previous prototype for function
'ff_d3d12va_get_surface_index' [-Werror,-Wmissing-prototypes]
  49 | unsigned ff_d3d12va_get_surface_index(const AVCodecContext *avctx,
 |  ^
---
libavcodec/d3d12va_decode.c | 1 +
1 file changed, 1 insertion(+)


Even after this change, the build still fails on a later file:

src/libavutil/hwcontext_d3d12va.c:74:13: error: no previous prototype for 
function 'av_d3d12va_map_sw_to_hw_format' [-Werror,-Wmissing-prototypes]

   74 | DXGI_FORMAT av_d3d12va_map_sw_to_hw_format(enum AVPixelFormat pix_fmt)
  | ^

There's no declaration of this in any header - so please either make it 
static or ff_ prefixed, or add it to a header with the declaration visible 
at the function definition.


// 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".

[FFmpeg-devel] [PATCH] d3d12va: Add a missing include for the declaration of ff_d3d12va_get_surface_index

[Martin Storsjö]

This fixes the following build error:

src/libavcodec/d3d12va_decode.c:49:10: error: no previous prototype for function
 'ff_d3d12va_get_surface_index' [-Werror,-Wmissing-prototypes]
   49 | unsigned ff_d3d12va_get_surface_index(const AVCodecContext *avctx,
  |  ^
---
 libavcodec/d3d12va_decode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/d3d12va_decode.c b/libavcodec/d3d12va_decode.c
index 03e565066c..e0b67bf964 100644
--- a/libavcodec/d3d12va_decode.c
+++ b/libavcodec/d3d12va_decode.c
@@ -33,6 +33,7 @@
 #include "avcodec.h"
 #include "decode.h"
 #include "d3d12va_decode.h"
+#include "dxva2_internal.h"
 
 typedef struct HelperObjects {
 ID3D12CommandAllocator *command_allocator;
-- 
2.34.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 v12 1/9] libavutil: add hwcontext_d3d12va and AV_PIX_FMT_D3D12

[Lynne]

There are still no public external API users to actually test the API,
which is concerning. It took months for the Vulkan API to be portable
enough to work with the major Vulkan users out there. Granted, Vulkan
is special.

Is there any public test code out there? If not, I'd prefer the API to be
declared as experimental for now, so we can make changes if needed.

Dec 21, 2023, 09:31 by haihao.xiang-at-intel@ffmpeg.org:

> On Ma, 2023-12-18 at 06:28 +, Xiang, Haihao wrote:
>
>> On Di, 2023-12-05 at 14:46 +0800, Tong Wu wrote:
>> > From: Wu Jianhua 
>> > 
>> > Signed-off-by: Wu Jianhua 
>> > Signed-off-by: Tong Wu 
>> > ---
>> > 
>> > Compared to v11, v12 set the initial value to 0 for the fence value,
>> > fixing a potential dynamic pool sync issue. Hence removed the non zero
>> > initial_pool_size for
>> > d3d12va decoder. 
>> > 
>> > Some other minor error message changes.
>> > 
>> > 
>> > 
>> >  configure  |   5 +
>> >  doc/APIchanges |   5 +
>> >  libavutil/Makefile |   3 +
>> >  libavutil/hwcontext.c  |   4 +
>> >  libavutil/hwcontext.h  |   1 +
>> >  libavutil/hwcontext_d3d12va.c  | 703 +
>> >  libavutil/hwcontext_d3d12va.h  | 134 +
>> >  libavutil/hwcontext_d3d12va_internal.h |  59 +++
>> >  libavutil/hwcontext_internal.h |   1 +
>> >  libavutil/pixdesc.c    |   4 +
>> >  libavutil/pixfmt.h |   7 +
>> >  libavutil/tests/hwdevice.c |   2 +
>> >  libavutil/version.h    |   2 +-
>> >  13 files changed, 929 insertions(+), 1 deletion(-)
>> >  create mode 100644 libavutil/hwcontext_d3d12va.c
>> >  create mode 100644 libavutil/hwcontext_d3d12va.h
>> >  create mode 100644 libavutil/hwcontext_d3d12va_internal.h
>> > 
>> > diff --git a/configure b/configure
>> > index d77c053226..1a343ac6b9 100755
>> > --- a/configure
>> > +++ b/configure
>> > @@ -336,6 +336,7 @@ External library support:
>> >    --disable-cuda-llvm  disable CUDA compilation using clang
>> > [autodetect]
>> >    --disable-cuvid  disable Nvidia CUVID support [autodetect]
>> >    --disable-d3d11va    disable Microsoft Direct3D 11 video 
>> > acceleration
>> > code [autodetect]
>> > +  --disable-d3d12va    disable Microsoft Direct3D 12 video 
>> > acceleration
>> > code [autodetect]
>> >    --disable-dxva2  disable Microsoft DirectX 9 video acceleration
>> > code [autodetect]
>> >    --disable-ffnvcodec  disable dynamically linked Nvidia code
>> > [autodetect]
>> >    --enable-libdrm  enable DRM code (Linux) [no]
>> > @@ -1926,6 +1927,7 @@ HWACCEL_AUTODETECT_LIBRARY_LIST="
>> >  cuda_llvm
>> >  cuvid
>> >  d3d11va
>> > +    d3d12va
>> >  dxva2
>> >  ffnvcodec
>> >  nvdec
>> > @@ -3048,6 +3050,7 @@ crystalhd_deps="libcrystalhd_libcrystalhd_if_h"
>> >  cuda_deps="ffnvcodec"
>> >  cuvid_deps="ffnvcodec"
>> >  d3d11va_deps="dxva_h ID3D11VideoDecoder ID3D11VideoContext"
>> > +d3d12va_deps="dxva_h ID3D12Device ID3D12VideoDecoder"
>> >  dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode ole32 user32"
>> >  ffnvcodec_deps_any="libdl LoadLibrary"
>> >  mediacodec_deps="android"
>> > @@ -6575,6 +6578,8 @@ check_type "windows.h dxgi1_2.h" "IDXGIOutput1"
>> >  check_type "windows.h dxgi1_5.h" "IDXGIOutput5"
>> >  check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
>> >  check_type "windows.h d3d11.h" "ID3D11VideoContext"
>> > +check_type "windows.h d3d12.h" "ID3D12Device"
>> > +check_type "windows.h d3d12video.h" "ID3D12VideoDecoder"
>> >  check_type "windows.h" "DPI_AWARENESS_CONTEXT" -D_WIN32_WINNT=0x0A00
>> >  check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -
>> > D_WIN32_WINNT=0x0602
>> >  check_func_headers mfapi.h MFCreateAlignedMemoryBuffer -lmfplat
>> > diff --git a/doc/APIchanges b/doc/APIchanges
>> > index 4a2dc1c44f..0435926d80 100644
>> > --- a/doc/APIchanges
>> > +++ b/doc/APIchanges
>> > @@ -2,6 +2,11 @@ The last version increases of all libraries were on 2023-
>> > 02-
>> > 09
>> >  
>> >  API changes, most recent first:
>> >  
>> > +2023-11-07 - xx - lavu 58.33.100 - pixfmt.h hwcontext.h
>> > hwcontext_d3d12va.h
>> > +  Add AV_HWDEVICE_TYPE_D3D12VA and AV_PIX_FMT_D3D12.
>> > +  Add AVD3D12VADeviceContext, AVD3D12VASyncContext, AVD3D12VAFrame and
>> > +  AVD3D12VAFramesContext.
>> > +
>> >  2023-11-08 - b82957a66a7 - lavu 58.32.100 - channel_layout.h
>> >    Add AV_CH_LAYOUT_7POINT2POINT3 and AV_CHANNEL_LAYOUT_7POINT2POINT3.
>> >    Add AV_CH_LAYOUT_9POINT1POINT4_BACK and
>> > AV_CHANNEL_LAYOUT_9POINT1POINT4_BACK.
>> > diff --git a/libavutil/Makefile b/libavutil/Makefile
>> > index 4711f8cde8..6a8566f1d9 100644
>> > --- a/libavutil/Makefile
>> > +++ b/libavutil/Makefile
>> > @@ -42,6 +42,7 @@ HEADERS =
>> > adler32.h \
>> >    hwcontext.h 

Re: [FFmpeg-devel] [PATCH v12 1/9] libavutil: add hwcontext_d3d12va and AV_PIX_FMT_D3D12

[Xiang, Haihao]

On Ma, 2023-12-18 at 06:28 +, Xiang, Haihao wrote:
> On Di, 2023-12-05 at 14:46 +0800, Tong Wu wrote:
> > From: Wu Jianhua 
> > 
> > Signed-off-by: Wu Jianhua 
> > Signed-off-by: Tong Wu 
> > ---
> > 
> > Compared to v11, v12 set the initial value to 0 for the fence value,
> > fixing a potential dynamic pool sync issue. Hence removed the non zero
> > initial_pool_size for
> > d3d12va decoder. 
> > 
> > Some other minor error message changes.
> > 
> > 
> > 
> >  configure  |   5 +
> >  doc/APIchanges |   5 +
> >  libavutil/Makefile |   3 +
> >  libavutil/hwcontext.c  |   4 +
> >  libavutil/hwcontext.h  |   1 +
> >  libavutil/hwcontext_d3d12va.c  | 703 +
> >  libavutil/hwcontext_d3d12va.h  | 134 +
> >  libavutil/hwcontext_d3d12va_internal.h |  59 +++
> >  libavutil/hwcontext_internal.h |   1 +
> >  libavutil/pixdesc.c    |   4 +
> >  libavutil/pixfmt.h |   7 +
> >  libavutil/tests/hwdevice.c |   2 +
> >  libavutil/version.h    |   2 +-
> >  13 files changed, 929 insertions(+), 1 deletion(-)
> >  create mode 100644 libavutil/hwcontext_d3d12va.c
> >  create mode 100644 libavutil/hwcontext_d3d12va.h
> >  create mode 100644 libavutil/hwcontext_d3d12va_internal.h
> > 
> > diff --git a/configure b/configure
> > index d77c053226..1a343ac6b9 100755
> > --- a/configure
> > +++ b/configure
> > @@ -336,6 +336,7 @@ External library support:
> >    --disable-cuda-llvm  disable CUDA compilation using clang
> > [autodetect]
> >    --disable-cuvid  disable Nvidia CUVID support [autodetect]
> >    --disable-d3d11va    disable Microsoft Direct3D 11 video acceleration
> > code [autodetect]
> > +  --disable-d3d12va    disable Microsoft Direct3D 12 video acceleration
> > code [autodetect]
> >    --disable-dxva2  disable Microsoft DirectX 9 video acceleration
> > code [autodetect]
> >    --disable-ffnvcodec  disable dynamically linked Nvidia code
> > [autodetect]
> >    --enable-libdrm  enable DRM code (Linux) [no]
> > @@ -1926,6 +1927,7 @@ HWACCEL_AUTODETECT_LIBRARY_LIST="
> >  cuda_llvm
> >  cuvid
> >  d3d11va
> > +    d3d12va
> >  dxva2
> >  ffnvcodec
> >  nvdec
> > @@ -3048,6 +3050,7 @@ crystalhd_deps="libcrystalhd_libcrystalhd_if_h"
> >  cuda_deps="ffnvcodec"
> >  cuvid_deps="ffnvcodec"
> >  d3d11va_deps="dxva_h ID3D11VideoDecoder ID3D11VideoContext"
> > +d3d12va_deps="dxva_h ID3D12Device ID3D12VideoDecoder"
> >  dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode ole32 user32"
> >  ffnvcodec_deps_any="libdl LoadLibrary"
> >  mediacodec_deps="android"
> > @@ -6575,6 +6578,8 @@ check_type "windows.h dxgi1_2.h" "IDXGIOutput1"
> >  check_type "windows.h dxgi1_5.h" "IDXGIOutput5"
> >  check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
> >  check_type "windows.h d3d11.h" "ID3D11VideoContext"
> > +check_type "windows.h d3d12.h" "ID3D12Device"
> > +check_type "windows.h d3d12video.h" "ID3D12VideoDecoder"
> >  check_type "windows.h" "DPI_AWARENESS_CONTEXT" -D_WIN32_WINNT=0x0A00
> >  check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -
> > D_WIN32_WINNT=0x0602
> >  check_func_headers mfapi.h MFCreateAlignedMemoryBuffer -lmfplat
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 4a2dc1c44f..0435926d80 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -2,6 +2,11 @@ The last version increases of all libraries were on 2023-
> > 02-
> > 09
> >  
> >  API changes, most recent first:
> >  
> > +2023-11-07 - xx - lavu 58.33.100 - pixfmt.h hwcontext.h
> > hwcontext_d3d12va.h
> > +  Add AV_HWDEVICE_TYPE_D3D12VA and AV_PIX_FMT_D3D12.
> > +  Add AVD3D12VADeviceContext, AVD3D12VASyncContext, AVD3D12VAFrame and
> > +  AVD3D12VAFramesContext.
> > +
> >  2023-11-08 - b82957a66a7 - lavu 58.32.100 - channel_layout.h
> >    Add AV_CH_LAYOUT_7POINT2POINT3 and AV_CHANNEL_LAYOUT_7POINT2POINT3.
> >    Add AV_CH_LAYOUT_9POINT1POINT4_BACK and
> > AV_CHANNEL_LAYOUT_9POINT1POINT4_BACK.
> > diff --git a/libavutil/Makefile b/libavutil/Makefile
> > index 4711f8cde8..6a8566f1d9 100644
> > --- a/libavutil/Makefile
> > +++ b/libavutil/Makefile
> > @@ -42,6 +42,7 @@ HEADERS =
> > adler32.h \
> >    hwcontext.h   \
> >    hwcontext_cuda.h  \
> >    hwcontext_d3d11va.h   \
> > +  hwcontext_d3d12va.h   \
> >    hwcontext_drm.h   \
> >    hwcontext_dxva2.h \
> >    hwcontext_qsv.h   \
> > @@ -190,6 +191,7 @@ OBJS =
> > adler32.o   

Re: [FFmpeg-devel] [PATCH v8 0/5] webp: add support for animated WebP decoding

[Thilo Borgmann via ffmpeg-devel]

Am 15.12.23 um 20:59 schrieb Thilo Borgmann via ffmpeg-devel:

Still images fixed, includes FATE tests, VP8 decoder decoupled so there are no 
more data races, fixed more asserts, fixed ffprobe regression, removed 
unnecessary parser changes, put the whole animated sequence into one packet.

Patch 3/5 is still there for making changes in lavc/webp reviewable but shall 
be stashed when pushing.

-Thilo


Josef Zlomek (2):
   libavcodec/webp: add support for animated WebP decoding
   libavformat/webp: add WebP demuxer

Thilo Borgmann (3):
   avcodec/webp: remove unused definitions
   avcodec/webp: make init_canvas_frame static
   fate: add test for animated WebP

  Changelog   |   2 +
  doc/demuxers.texi   |  28 +
  libavcodec/codec_desc.c |   3 +-
  libavcodec/version.h|   2 +-
  libavcodec/webp.c   | 748 ++--
  libavformat/Makefile|   1 +
  libavformat/allformats.c|   1 +
  libavformat/version.h   |   2 +-
  libavformat/webpdec.c   | 383 ++
  tests/fate/image.mak|   3 +
  tests/ref/fate/exif-image-webp  |   8 +-
  tests/ref/fate/webp-anim|  22 +
  tests/ref/fate/webp-rgb-lena-lossless   |   2 +-
  tests/ref/fate/webp-rgb-lena-lossless-rgb24 |   2 +-
  tests/ref/fate/webp-rgb-lossless|   2 +-
  tests/ref/fate/webp-rgb-lossy-q80   |   2 +-
  tests/ref/fate/webp-rgba-lossless   |   2 +-
  tests/ref/fate/webp-rgba-lossy-q80  |   2 +-
  18 files changed, 1141 insertions(+), 74 deletions(-)
  create mode 100644 libavformat/webpdec.c
  create mode 100644 tests/ref/fate/webp-anim


Ping.

-Thilo

___
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".