[FFmpeg-devel] [PATCH] avcodec/v4l2_m2m: Remove unnecessary unref before frame_free

2023-12-16 Thread Zhao Zhili 
From: Zhao Zhili 

Signed-off-by: Zhao Zhili 
---
 libavcodec/v4l2_m2m.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index 602efb7a16..bac3eb0588 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -255,7 +255,6 @@ static void v4l2_m2m_destroy_context(void *opaque, uint8_t 
*context)
 
 if (s->fd >= 0)
 close(s->fd);
-av_frame_unref(s->frame);
 av_frame_free(>frame);
 av_packet_unref(>buf_pkt);
 
-- 
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 09/35] avcodec/proresenc_kostya: fix chroma quantisation matrix in frame header

2023-12-16 Thread Stefano Sabatini 
On date Monday 2023-12-11 02:35:10 +0100, Clément Bœsch wrote:
> ---
>  libavcodec/proresenc_kostya.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
> index 2d45f9a685..103051830a 100644
> --- a/libavcodec/proresenc_kostya.c
> +++ b/libavcodec/proresenc_kostya.c
> @@ -1019,7 +1019,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
> *pkt,
>  bytestream_put_byte(, ctx->quant_mat[i]);
>  // chroma quantisation matrix
>  for (i = 0; i < 64; i++)
> -bytestream_put_byte(, ctx->quant_mat[i]);
> +bytestream_put_byte(, ctx->quant_chroma_mat[i]);

Looks good, but I wonder, is this covered by tests and a results in a
reference change?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] fate: Allow running multiple rounds of tests with differing settings

2023-12-16 Thread Martin Storsjö 

On Wed, 13 Dec 2023, Martin Storsjö wrote:


On Wed, 13 Dec 2023, Rémi Denis-Courmont wrote:


Le tiistaina 12. joulukuuta 2023, 0.14.06 EET Martin Storsjö a écrit :

This can be used to run tests multple times, with e.g. differing
QEMU settings, by adding something like this to the FATE configuration
file:

target_exec="qemu-aarch64-static"
fate_targets="fate-checkasm fate-cpu"

fate_environments="sve128 sve256 sve512"
sve128_env="QEMU_CPU=max,sve128=on"
sve256_env="QEMU_CPU=max,sve256=on"
sve512_env="QEMU_CPU=max,sve512=on"


I'm fine with that, but for the sake of generality, shouldn't rather the 
entire target_exec prefix be indirected? Some runners may want to use 
command line flags rather than environment variables.


Yes - that's also doable. One can e.g. do this:

---
target_exec="qemu-aarch64-static -cpu \$(MY_CPU)"
fate_targets="fate-checkasm fate-cpu"

fate_environments="sve128 sve256 sve512"
sve128_env="MY_CPU=max,sve128=on"
sve256_env="MY_CPU=max,sve256=on"
sve512_env="MY_CPU=max,sve512=on"
---

That way, one can also make the whole target_exec be e.g. \$(EXEC_CMD) and 
set the full command via the individual envs. It's not quite as comfortable, 
but should be doable and allow fully generic setups.


If this sounds reasonable enough, I would go ahead and land this, together 
with 
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20231127123118.3622784-1-mar...@martin.st/.


I guess this feature should have some documentation as well - I can draft 
up a v2 with docs before going ahead with it, if the feature overall looks 
acceptable.


// 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] riscv: vc1dsp: Don't check vlenb before checking the CPU flags

2023-12-16 Thread Martin Storsjö 

On Sat, 16 Dec 2023, Rémi Denis-Courmont wrote:


Le perjantaina 15. joulukuuta 2023, 17.38.45 EET Martin Storsjö a écrit :

We can't call ff_get_rv_vlenb() if we don't have RVV available
at all.

Due to the SIGILL signal handler in checkasm catching it, in an
unexpected place, this caused checkasm to hang instead of reporting
the issue.
---
 libavcodec/riscv/vc1dsp_init.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
index 0d22d28f4d..e47b644f80 100644
--- a/libavcodec/riscv/vc1dsp_init.c
+++ b/libavcodec/riscv/vc1dsp_init.c
@@ -35,15 +35,13 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
 #if HAVE_RVV
 int flags = av_get_cpu_flags();

-if (ff_get_rv_vlenb() >= 16) {
+if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
+dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
+dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
 if (flags & AV_CPU_FLAG_RVV_I64) {
 dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
 dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
 }
-if (flags & AV_CPU_FLAG_RVV_I32) {
-dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
-dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
-}
 }
 #endif
 }


Acked-by: Rémi Denis-Courmont 


Thanks, pushed.

// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/vc1dsp: fix R-V V vector lengths

2023-12-16 Thread Martin Storsjö 

On Sat, 16 Dec 2023, Rémi Denis-Courmont wrote:


The 8x4 and 4x4 use a needlessly large multiplier (unless/until we care
about embedded 64-bit-vector hardware). This is merely suboptimal.

The 8x4 case also uses an incorrect vector length, which leads to incorrect
behaviour on future/hypothetical hardware with 256-bit or larger vectors.

Pointed-out-by: Martin Storsjö 
---
libavcodec/riscv/vc1dsp_rvv.S | 8 
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/riscv/vc1dsp_rvv.S b/libavcodec/riscv/vc1dsp_rvv.S
index 1a503ecc87..4a00945ead 100644
--- a/libavcodec/riscv/vc1dsp_rvv.S
+++ b/libavcodec/riscv/vc1dsp_rvv.S
@@ -68,7 +68,7 @@ endfunc

func ff_vc1_inv_trans_8x4_dc_rvv, zve64x
lht2, (a2)
-vsetivli  zero, 8, e8, mf2, ta, ma
+vsetivli  zero, 4, e8, mf4, ta, ma
vlse64.v  v0, (a0), a1
sh1addt2, t2, t2
addi  t2, t2, 1
@@ -84,14 +84,14 @@ func ff_vc1_inv_trans_8x4_dc_rvv, zve64x
vmax.vx   v4, v4, zero
vsetvli   zero, zero, e8, m2, ta, ma
vnclipu.wiv0, v4, 0
-vsetivli  zero, 8, e8, mf2, ta, ma
+vsetivli  zero, 4, e8, mf4, ta, ma
vsse64.v  v0, (a0), a1
ret
endfunc

func ff_vc1_inv_trans_4x4_dc_rvv, zve32x
lht2, (a2)
-vsetivli  zero, 4, e8, mf2, ta, ma
+vsetivli  zero, 4, e8, mf4, ta, ma
vlse32.v  v0, (a0), a1
slli  t1, t2, 4
add   t2, t2, t1
@@ -107,7 +107,7 @@ func ff_vc1_inv_trans_4x4_dc_rvv, zve32x
vmax.vx   v2, v2, zero
vsetvli   zero, zero, e8, m1, ta, ma
vnclipu.wiv0, v2, 0
-vsetivli  zero, 4, e8, mf2, ta, ma
+vsetivli  zero, 4, e8, mf4, ta, ma
vsse32.v  v0, (a0), a1
ret
endfunc
--
2.43.0


The fix sounds reasonable (although I can't say I've followed the code). 
Anyway, I've tested that it does indeed fix the checkasm test, so feel 
free to push - 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 08/35] avcodec/proresenc_kostya: save a few operations in DC encoding

2023-12-16 Thread Stefano Sabatini 
On date Monday 2023-12-11 02:35:09 +0100, Clément Bœsch wrote:
> This matches the logic from proresenc_anatoliy.
> ---
>  libavcodec/proresenc_kostya.c | 21 ++---
>  1 file changed, 6 insertions(+), 15 deletions(-)

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 07/35] avcodec/proresenc_anatoliy: move DC codebook LUT to shared proresdata

2023-12-16 Thread Stefano Sabatini 
On date Monday 2023-12-11 02:35:08 +0100, Clément Bœsch wrote:
> This is going to be shared with proresenc_kostya in the upcoming commit.
> ---
>  libavcodec/proresdata.c | 2 ++
>  libavcodec/proresdata.h | 1 +
>  libavcodec/proresenc_anatoliy.c | 3 +--
>  3 files changed, 4 insertions(+), 2 deletions(-)

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 06/35] avcodec/proresenc_anatoliy: remove duplicated define

2023-12-16 Thread Stefano Sabatini 
On date Monday 2023-12-11 02:35:07 +0100, Clément Bœsch wrote:
> This is already defined in proresdata.h
> ---
>  libavcodec/proresenc_anatoliy.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
> index 6b2e513bed..c6f49be9b8 100644
> --- a/libavcodec/proresenc_anatoliy.c
> +++ b/libavcodec/proresenc_anatoliy.c
> @@ -266,8 +266,6 @@ static av_always_inline int get_level(int val)
>  return (val ^ sign) - sign;
>  }
>  
> -#define FIRST_DC_CB 0xB8
> -
>  static const uint8_t dc_codebook[7] = { 0x04, 0x28, 0x28, 0x4D, 0x4D, 0x70, 
> 0x70};

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 1/2] lavfi: introduce textutils

2023-12-16 Thread Stefano Sabatini 
On date Saturday 2023-12-09 19:12:29 +0100, Stefano Sabatini wrote:
> On date Sunday 2023-12-03 16:05:40 +0100, Stefano Sabatini wrote:
> > On date Thursday 2023-11-30 01:49:13 +0100, Stefano Sabatini wrote:
> > > Generalize drawtext utilities to make them usable in other filters.
> > > This will be needed to introduce the QR code source and filter without
> > > duplicating functionality.
> > > ---
> > >  libavfilter/Makefile  |   2 +-
> > >  libavfilter/textutils.c   | 379 +++
> > >  libavfilter/textutils.h   | 182 +
> > >  libavfilter/vf_drawtext.c | 533 ++
> > >  4 files changed, 693 insertions(+), 403 deletions(-)
> > >  create mode 100644 libavfilter/textutils.c
> > >  create mode 100644 libavfilter/textutils.h
> > 
> > Updated (with more doc and a more genric ff_print_formatted_eval_expr
> > function).
> 
> Rev 3.

> From d9d033dcb8c3a8a473fd08db209f782f99a65780 Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini 
> Date: Mon, 20 Nov 2023 01:13:17 +0100
> Subject: [PATCH 1/2] lavfi: introduce textutils
> 
> Generalize drawtext utilities to make them usable in other filters.
> This will be needed to introduce the QR code source and filter without
> duplicating functionality.
> ---
>  libavfilter/Makefile  |   2 +-
>  libavfilter/textutils.c   | 382 +++
>  libavfilter/textutils.h   | 229 
>  libavfilter/vf_drawtext.c | 533 ++
>  4 files changed, 743 insertions(+), 403 deletions(-)
>  create mode 100644 libavfilter/textutils.c
>  create mode 100644 libavfilter/textutils.h

Ping, if there are no objections or comments I plan to push this in a
week or something.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] gdigrab: Allow capturing a window by its handle

2023-12-16 Thread Stefano Sabatini 
On date Thursday 2023-12-14 11:32:44 +0100, Lena wrote:
> Updated the wording of the documentation, and added error checking for strtol.
> 
> I looked at how other parts of the codebase check for errors on strtol and 
> implemented it that way (iec61883, filter_units_bsf, etc).
> 
> As for checking if the string value is larger/smaller than a long, i don't 
> think there's a need, as the documentation says it'd just get set to 
> LONG_MIN/LONG_MAX and fail anyway.
> 
> 
> x11grab can capture windows by their ID, but gdigrab can only capture windows 
> by their names, internally calling FindWindowW to lookup its handle.
> 
> This patch simply allows the user to specify a window handle directly.
> Signed-off-by: Lena 
> ---
>  doc/indevs.texi   |  8 ++--
>  libavdevice/gdigrab.c | 15 ++-
>  2 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/indevs.texi b/doc/indevs.texi
> index 863536a34d..a0c684f545 100644
> --- a/doc/indevs.texi
> +++ b/doc/indevs.texi
> @@ -722,7 +722,7 @@ Win32 GDI-based screen capture device.
>  
>  This device allows you to capture a region of the display on Windows.
>  
> -There are two options for the input filename:
> +Amongst options for the imput filenames are such elements as:
>  @example
>  desktop
>  @end example
> @@ -730,9 +730,13 @@ or
>  @example
>  title=@var{window_title}
>  @end example
> +or
> +@example
> +hwnd=@var{window_hwnd}
> +@end example
>  
>  The first option will capture the entire desktop, or a fixed region of the
> -desktop. The second option will instead capture the contents of a single
> +desktop. The second and third options will instead capture the contents of a 
> single
>  window, regardless of its position on the screen.
>  
>  For example, to grab the entire desktop using @command{ffmpeg}:
> diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
> index c069232472..3153b6f711 100644
> --- a/libavdevice/gdigrab.c
> +++ b/libavdevice/gdigrab.c
> @@ -273,9 +273,22 @@ gdigrab_read_header(AVFormatContext *s1)
>  }
>  } else if (!strcmp(filename, "desktop")) {
>  hwnd = NULL;
> +} else if (!strncmp(filename, "hwnd=", 5)) {
> +name = filename + 5;
> +char *p;
> +
> +hwnd = strtol(name, , 0);
> +
> +if (p == NULL || p == name || p[0] == '\0')
> +{
> +av_log(s1, AV_LOG_ERROR,

> +   "Invalid window handle.\n");

Here you can provide some context:
"Invalid window handle '%s', must be an valid integer.", name

Looks good otherwise, 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] [PATCH] src/consulting: correct cell alignment after b7a2be0611

2023-12-16 Thread Gyan Doshi 
The removal of an entry in the middle column left a 'hole'
in the grid.

Container tags shifted to restore alignment.
---
 src/consulting | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/consulting b/src/consulting
index 1e205b5..801ea8a 100644
--- a/src/consulting
+++ b/src/consulting
@@ -106,8 +106,6 @@ E.g.:
   
  

- 
-
   
 
   Steven Liu
@@ -121,6 +119,8 @@ E.g.:
   
  

+ 
+
   
 
   Gyan Doshi
-- 
2.39.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] [RFC] fftools/ffmpeg and libavdevice/sdl issue

2023-12-16 Thread Stefano Sabatini 
On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
> Anton Khirnov (12023-12-14):
[...]
> > I have to strongly disagree. This is neither practically workable,
> > nor a good goal to aim at.
> 
> And I strongly agree with Stefano. Having the tools just thin wrappers
> around the libraries is the only way to ensure the libraries are
> maximally useful for other applications. Otherwise, useful code will
> only reside in the tools and be only available through a clumsy
> command-line interface.
> 
> >  This mindset IMO inevitably leads to (among
> > other problems):

> > * endless scope creep

Scope creep is a general tendency in software, as it tends to grow
with more functionality and use cases in mind (FFmpeg itself started
as an MPEG decoder). OTOH there is good and bad scope creep, it is bad
if the functionality goes beyond the original design and core use
case, or if the extension is not carefully designed and suffers from
assumptions which limit how the software can be used. For example,
making constraints about where the main thread can be executed.

(Unrelated note: I greatly appreciate Anton's threaded architecture
endeavor, and I'm fine with the idea that something can result broken
as a consequence of a major redesign, but I also think we should fix
what can be fixed rather than just dismiss that as "not useful". Also
this is a community project, so it's not only Anton's responsibility
to fix that, since we all benefit from his work).

> > * bloated, inefficient, and buggy libraries, trying (and failing) to
> >   support every use case under the sun

> > * myopic API design aimed at fulfilling the needs of precisely one
> >   caller; this is a problem e.g avfilter badly suffers from, and to a
> >   lesser extent avformat

Note that these two statements conflicting. If you try to support most
of the use cases, it will be flexible by definition. For example, if
we design the API to be only usable from ffmpeg.c, it will be limited
in scope and usefullness.

Desigining something which is generic, flexible, and efficient at the
same time is hard, but that does not mean that it cannot be done.
 
> I see no argument supporting this opinion of yours. Quite the opposite,
> over the years, Stefano and others, including me, have made some headway
> in this direction without hitting these pitfalls.

Same here, these sound like vague statements, and I fail to see how
they are related to that very generic design vision.
___
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] web: remove myself from FFmpeg consulting page

2023-12-16 Thread James Almer 

On 12/16/2023 11:52 AM, Paul B Mahol wrote:

On Sat, Dec 16, 2023 at 3:49 PM James Almer  wrote:


On 12/16/2023 11:47 AM, Paul B Mahol wrote:

On Sat, Dec 16, 2023 at 3:45 PM James Almer  wrote:


On 12/16/2023 11:43 AM, Paul B Mahol wrote:

On Sat, Dec 16, 2023 at 3:41 PM James Almer  wrote:


On 12/16/2023 11:34 AM, Paul B Mahol wrote:

Can someone commit this already?


You still have commit rights.



For web?


Yes, The ssh key you use for ffmpeg.git should work for ffmpeg-web.git

too.




Dunno what is git url.


Push url should be g...@git.ffmpeg.org:ffmpeg-web.git



Cloning into 'ffmpeg-web'...
Enter passphrase for key '/home/computer/.ssh/id_rsa':
FATAL: R any ffmpeg-web durandal DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


Weird, i thought it was the same key, but guess not.

I just pushed it for you.
___
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] web: remove myself from FFmpeg consulting page

2023-12-16 Thread Paul B Mahol 
On Sat, Dec 16, 2023 at 3:49 PM James Almer  wrote:

> On 12/16/2023 11:47 AM, Paul B Mahol wrote:
> > On Sat, Dec 16, 2023 at 3:45 PM James Almer  wrote:
> >
> >> On 12/16/2023 11:43 AM, Paul B Mahol wrote:
> >>> On Sat, Dec 16, 2023 at 3:41 PM James Almer  wrote:
> >>>
>  On 12/16/2023 11:34 AM, Paul B Mahol wrote:
> > Can someone commit this already?
> 
>  You still have commit rights.
> 
> >>>
> >>> For web?
> >>
> >> Yes, The ssh key you use for ffmpeg.git should work for ffmpeg-web.git
> too.
> >>
> >
> > Dunno what is git url.
>
> Push url should be g...@git.ffmpeg.org:ffmpeg-web.git


Cloning into 'ffmpeg-web'...
Enter passphrase for key '/home/computer/.ssh/id_rsa':
FATAL: R any ffmpeg-web durandal DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


> ___
> 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] web: remove myself from FFmpeg consulting page

2023-12-16 Thread James Almer 

On 12/16/2023 11:47 AM, Paul B Mahol wrote:

On Sat, Dec 16, 2023 at 3:45 PM James Almer  wrote:


On 12/16/2023 11:43 AM, Paul B Mahol wrote:

On Sat, Dec 16, 2023 at 3:41 PM James Almer  wrote:


On 12/16/2023 11:34 AM, Paul B Mahol wrote:

Can someone commit this already?


You still have commit rights.



For web?


Yes, The ssh key you use for ffmpeg.git should work for ffmpeg-web.git too.



Dunno what is git url.


Push url should be g...@git.ffmpeg.org:ffmpeg-web.git
___
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] web: remove myself from FFmpeg consulting page

2023-12-16 Thread Paul B Mahol 
On Sat, Dec 16, 2023 at 3:45 PM James Almer  wrote:

> On 12/16/2023 11:43 AM, Paul B Mahol wrote:
> > On Sat, Dec 16, 2023 at 3:41 PM James Almer  wrote:
> >
> >> On 12/16/2023 11:34 AM, Paul B Mahol wrote:
> >>> Can someone commit this already?
> >>
> >> You still have commit rights.
> >>
> >
> > For web?
>
> Yes, The ssh key you use for ffmpeg.git should work for ffmpeg-web.git too.
>

Dunno what is git url.


> ___
> 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] web: remove myself from FFmpeg consulting page

2023-12-16 Thread James Almer 

On 12/16/2023 11:43 AM, Paul B Mahol wrote:

On Sat, Dec 16, 2023 at 3:41 PM James Almer  wrote:


On 12/16/2023 11:34 AM, Paul B Mahol wrote:

Can someone commit this already?


You still have commit rights.



For web?


Yes, The ssh key you use for ffmpeg.git should work for ffmpeg-web.git too.
___
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] web: remove myself from FFmpeg consulting page

2023-12-16 Thread Paul B Mahol 
On Sat, Dec 16, 2023 at 3:41 PM James Almer  wrote:

> On 12/16/2023 11:34 AM, Paul B Mahol wrote:
> > Can someone commit this already?
>
> You still have commit rights.
>

For web?


> ___
> 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] web: remove myself from FFmpeg consulting page

2023-12-16 Thread James Almer 

On 12/16/2023 11:34 AM, Paul B Mahol wrote:

Can someone commit this already?


You still have commit rights.
___
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] web: remove myself from FFmpeg consulting page

2023-12-16 Thread Paul B Mahol 
Can someone commit this already?
___
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] lavfi/overlay: factorize definition of planar and package blending functions

2023-12-16 Thread Stefano Sabatini 
---
 libavfilter/vf_overlay.c | 260 ---
 1 file changed, 53 insertions(+), 207 deletions(-)

diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index fa39abb23a..caf0634b51 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -690,213 +690,59 @@ static av_always_inline void 
blend_slice_planar_rgb(AVFilterContext *ctx,
 alpha_composite_8_8bits(src, dst, src_w, src_h, dst_w, dst_h, x, y, 
jobnr, nb_jobs);
 }
 
-static int blend_slice_yuv420(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_8_8bits(ctx, td->dst, td->src, 1, 1, 0, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuva420(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_8_8bits(ctx, td->dst, td->src, 1, 1, 1, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuv420p10(AVFilterContext *ctx, void *arg, int jobnr, 
int nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_16_10bits(ctx, td->dst, td->src, 1, 1, 0, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuva420p10(AVFilterContext *ctx, void *arg, int jobnr, 
int nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_16_10bits(ctx, td->dst, td->src, 1, 1, 1, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuv422p10(AVFilterContext *ctx, void *arg, int jobnr, 
int nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_16_10bits(ctx, td->dst, td->src, 1, 0, 0, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuva422p10(AVFilterContext *ctx, void *arg, int jobnr, 
int nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_16_10bits(ctx, td->dst, td->src, 1, 0, 1, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuv422(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_8_8bits(ctx, td->dst, td->src, 1, 0, 0, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuva422(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_8_8bits(ctx, td->dst, td->src, 1, 0, 1, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuv444(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_8_8bits(ctx, td->dst, td->src, 0, 0, 0, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuva444(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_8_8bits(ctx, td->dst, td->src, 0, 0, 1, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuv444p10(AVFilterContext *ctx, void *arg, int jobnr, 
int nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_16_10bits(ctx, td->dst, td->src, 0, 0, 0, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuva444p10(AVFilterContext *ctx, void *arg, int jobnr, 
int nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_16_10bits(ctx, td->dst, td->src, 0, 0, 1, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_gbrp(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_planar_rgb(ctx, td->dst, td->src, 0, 0, 0, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_gbrap(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_planar_rgb(ctx, td->dst, td->src, 0, 0, 1, s->x, s->y, 1, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuv420_pm(AVFilterContext *ctx, void *arg, int jobnr, 
int nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_8_8bits(ctx, td->dst, td->src, 1, 1, 0, s->x, s->y, 0, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuva420_pm(AVFilterContext *ctx, void *arg, int jobnr, 
int nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-blend_slice_yuv_8_8bits(ctx, td->dst, td->src, 1, 1, 1, s->x, s->y, 0, 
jobnr, nb_jobs);
-return 0;
-}
-
-static int blend_slice_yuv422_pm(AVFilterContext *ctx, void *arg, int jobnr, 
int nb_jobs)
-{
-OverlayContext *s = ctx->priv;
-ThreadData *td = arg;
-

Re: [FFmpeg-devel] [PATCH 2/4] avcodec/cbs_vp8: Do not use assert to check for end

2023-12-16 Thread James Almer 

On 12/16/2023 9:16 AM, Michael Niedermayer wrote:

Fixes: abort()
Fixes: 
64232/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5417957987319808

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
  libavcodec/cbs_vp8.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/cbs_vp8.c b/libavcodec/cbs_vp8.c
index 01d4b9cefef..b76cde98517 100644
--- a/libavcodec/cbs_vp8.c
+++ b/libavcodec/cbs_vp8.c
@@ -329,7 +329,9 @@ static int cbs_vp8_read_unit(CodedBitstreamContext *ctx,
  
  pos = get_bits_count();

  pos /= 8;
-av_assert0(pos <= unit->data_size);
+
+if (pos > unit->data_size)
+return AVERROR_INVALIDDATA;


Wouldn't this be hiding a bug in the parsing code? The assert is there 
to ensure no overread happened.


  
  frame->data_ref = av_buffer_ref(unit->data_ref);

  if (!frame->data_ref)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 4/4] avformat/mov: do not set sign bit for chunk_offsets

2023-12-16 Thread Michael Niedermayer 
Fixes: signed integer overflow: 2314885530818453536 - -7412889664301817824 
cannot be represented in type 'long'
Fixes: 
64296/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6304027146846208

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/mov.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 30cf7a15b01..65c5c8c288c 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2242,8 +2242,13 @@ static int mov_read_stco(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 for (i = 0; i < entries && !pb->eof_reached; i++)
 sc->chunk_offsets[i] = avio_rb32(pb);
 else if (atom.type == MKTAG('c','o','6','4'))
-for (i = 0; i < entries && !pb->eof_reached; i++)
+for (i = 0; i < entries && !pb->eof_reached; i++) {
 sc->chunk_offsets[i] = avio_rb64(pb);
+if (sc->chunk_offsets[i] < 0) {
+av_log(c->fc, AV_LOG_WARNING, "Impossible chunk_offset\n");
+sc->chunk_offsets[i] = 0;
+}
+}
 else
 return AVERROR_INVALIDDATA;
 
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/4] avcodec/jpeglsdec: Check Jpeg-LS LSE

2023-12-16 Thread Michael Niedermayer 
Fixes: signed integer overflow: 2147478526 + 33924 cannot be represented in 
type 'int'
Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
Fixes: 
64243/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEGLS_fuzzer-5195717848989696

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/jpeglsdec.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
index ec163b8964d..c245cf0279c 100644
--- a/libavcodec/jpeglsdec.c
+++ b/libavcodec/jpeglsdec.c
@@ -382,6 +382,19 @@ int ff_jpegls_decode_picture(MJpegDecodeContext *s, int 
near,
 state->T3 = s->t3;
 state->reset  = s->reset;
 ff_jpegls_reset_coding_parameters(state, 0);
+
+/* Testing parameters here, we cannot test in LSE or SOF because
+ * these interdepend and are allowed in either order
+ */
+if (state->maxval >= (1T1 > state->T2 ||
+state->T2 > state->T3 ||
+state->T3 > state->maxval ||
+state->reset > FFMAX(255, state->maxval)) {
+ret = AVERROR_INVALIDDATA;
+goto end;
+}
+
 ff_jpegls_init_state(state);
 
 if (s->bits <= 8)
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/4] tools/target_dec_fuzzer: Adjust Threshold for VP6A

2023-12-16 Thread Michael Niedermayer 
Fixes: Timeout
Fixes: 
64220/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP6A_fuzzer-5653856213925888

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 tools/target_dec_fuzzer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index e59db6697df..84b646b7f45 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -304,6 +304,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
size) {
 case AV_CODEC_ID_VP4: maxpixels  /= 4096;  break;
 case AV_CODEC_ID_VP5: maxpixels  /= 256;   break;
 case AV_CODEC_ID_VP6F:maxpixels  /= 4096;  break;
+case AV_CODEC_ID_VP6A:maxpixels  /= 4096;  break;
 case AV_CODEC_ID_VP7: maxpixels  /= 256;   break;
 case AV_CODEC_ID_VP9: maxpixels  /= 4096;  break;
 case AV_CODEC_ID_WAVPACK: maxsamples /= 1024;  break;
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/4] avcodec/cbs_vp8: Do not use assert to check for end

2023-12-16 Thread Michael Niedermayer 
Fixes: abort()
Fixes: 
64232/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5417957987319808

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/cbs_vp8.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/cbs_vp8.c b/libavcodec/cbs_vp8.c
index 01d4b9cefef..b76cde98517 100644
--- a/libavcodec/cbs_vp8.c
+++ b/libavcodec/cbs_vp8.c
@@ -329,7 +329,9 @@ static int cbs_vp8_read_unit(CodedBitstreamContext *ctx,
 
 pos = get_bits_count();
 pos /= 8;
-av_assert0(pos <= unit->data_size);
+
+if (pos > unit->data_size)
+return AVERROR_INVALIDDATA;
 
 frame->data_ref = av_buffer_ref(unit->data_ref);
 if (!frame->data_ref)
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] lavc/opusdsp: simplify R-V V postfilter

2023-12-16 Thread Rémi Denis-Courmont 
This skips the round-trip to scalar register for the sliding 'x'
coefficients, improving performance by about 5%. The trick here is that
the vector slide-up instruction preserves elements in destination vector
until the slide offset.

The switch from vfslide1up.vf to vslideup.vi also allows the elimination
of data dependencies on consecutive slides. Since the specifications
recommend sticking to power of two offsets, we could slide as follows:

vslideup.vi v8, v0, 2
vslideup.vi v4, v0, 1
vslideup.vi v12, v8, 1
vslideup.vi v16, v8, 2

However in the device under test, this seems to make performance slightly
worse, so this is left for (in)validation with future better hardware.
---
 libavcodec/riscv/opusdsp_rvv.S | 30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/libavcodec/riscv/opusdsp_rvv.S b/libavcodec/riscv/opusdsp_rvv.S
index 79ae86c30e..9a8914c78d 100644
--- a/libavcodec/riscv/opusdsp_rvv.S
+++ b/libavcodec/riscv/opusdsp_rvv.S
@@ -26,40 +26,34 @@ func ff_opus_postfilter_rvv, zve32f
 flw fa1, 4(a2) // g1
 sub t0, a0, t1
 flw fa2, 8(a2) // g2
+addit1, t0, -2 * 4 // data - (period + 2) = initial 
+vsetivli zero, 4, e32, m4, ta, ma
 addit0, t0, 2 * 4 // data - (period - 2) = initial 
-
-flw ft4, -16(t0)
+vle32.v v16, (t1)
 addit3, a1, -2 // maximum parallelism w/o stepping our tail
-flw ft3, -12(t0)
-flw ft2,  -8(t0)
-flw ft1,  -4(t0)
 1:
+vslidedown.vi v8, v16, 2
 min t1, a3, t3
+vslide1down.vx v12, v16, zero
 vsetvli t1, t1, e32, m4, ta, ma
 vle32.v v0, (t0) // x0
 sub a3, a3, t1
-vle32.v v28, (a0)
+vslide1down.vx v4, v8, zero
 sh2add  t0, t1, t0
-vfslide1up.vf v4, v0, ft1
+vle32.v v28, (a0)
 addit2, t1, -4
-vfslide1up.vf v8, v4, ft2
-vfslide1up.vf v12, v8, ft3
-vfslide1up.vf v16, v12, ft4
+vslideup.vi v4, v0, 1
+vslideup.vi v8, v4, 1
+vslideup.vi v12, v8, 1
+vslideup.vi v16, v12, 1
 vfadd.vv v20, v4, v12
 vfadd.vv v24, v0, v16
-vslidedown.vx v12, v0, t2
+vslidedown.vx v16, v0, t2
 vfmacc.vf v28, fa0, v8
-vslidedown.vi v4, v12, 2
 vfmacc.vf v28, fa1, v20
-vslide1down.vx v8, v12, zero
 vfmacc.vf v28, fa2, v24
-vslide1down.vx v0, v4, zero
 vse32.v v28, (a0)
-vfmv.f.s ft4, v12
 sh2add  a0, t1, a0
-vfmv.f.s ft2, v4
-vfmv.f.s ft3, v8
-vfmv.f.s ft1, v0
 bneza3, 1b
 
 ret
-- 
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] avfilter/metal: fix compile below iOS 13

2023-12-16 Thread xufuji456 via ffmpeg-devel 
Here is the msg: "libavfilter/metal/utils.m:35: error: 'MTLGPUFamilyCommon3' is 
only available on iOS 13.0"
More Info: 
https://developer.apple.com/documentation/metal/mtlgpufamily/mtlgpufamilycommon3

Signed-off-by: xufuji456 <839789...@qq.com>
---
 libavfilter/metal/utils.m | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/metal/utils.m b/libavfilter/metal/utils.m
index f365d3ceea..bb1825ae35 100644
--- a/libavfilter/metal/utils.m
+++ b/libavfilter/metal/utils.m
@@ -31,7 +31,7 @@ void ff_metal_compute_encoder_dispatch(id device,
 BOOL fallback = YES;
 // MAC_OS_X_VERSION_10_15 is only defined on SDKs new enough to include 
its functionality (including iOS, tvOS, etc)
 #ifdef MAC_OS_X_VERSION_10_15
-if (@available(macOS 10.15, iOS 11, tvOS 14.5, *)) {
+if (@available(macOS 10.15, iOS 13, tvOS 14.5, *)) {
 if ([device supportsFamily:MTLGPUFamilyCommon3]) {
 MTLSize threadsPerGrid = MTLSizeMake(width, height, 1);
 [encoder dispatchThreads:threadsPerGrid 
threadsPerThreadgroup:threadsPerThreadgroup];
-- 
2.39.3 (Apple Git-145)

___
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] swr/swresample: avoid reapplication of firstpts

2023-12-16 Thread Gyan Doshi 




On 2023-12-15 11:46 pm, Michael Niedermayer wrote:

On Fri, Dec 15, 2023 at 12:30:46PM +0530, Gyan Doshi wrote:

During a resampling operation where

1) user has specified first_pts
2) SWR_FLAG_RESAMPLE is not set initially (directly or otherwise)
3) first_pts has been fulfilled (always using hard compensation)

then upon first encountering a delay where a soft compensation is
required, swr_set_compensation will lead to another init of swr which
will reset outpts to the specified firstpts thus leading to an output
frame having its pts = firstpts. When the next input frame is received,
swr will see a large delay and inject silence from firstpts to the
current frame's pts. This can lead to severe desync and in worst case,
loss of audio playback.

Parameter firstpts initialized to AV_NOPTS_VALUE in swr_alloc and then
checked in swr_init to avoid resetting outpts, thus avoiding reapplication
of firstpts.

Fixes #4131.
---
  libswresample/options.c| 1 +
  libswresample/swresample.c | 5 +++--
  2 files changed, 4 insertions(+), 2 deletions(-)

LGTM

also can a fate test be added for this ?


v3 with fate test sent.

Regards,
Gyan

___
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] swr/swresample: avoid reapplication of firstpts

2023-12-16 Thread Gyan Doshi 
During a resampling operation where

1) user has specified first_pts
2) SWR_FLAG_RESAMPLE is not set initially (directly or otherwise)
3) first_pts has been fulfilled (always using hard compensation)

then upon first encountering a delay where a soft compensation is
required, swr_set_compensation will lead to another init of swr which
will reset outpts to the specified firstpts thus leading to an output
frame having its pts = firstpts. When the next input frame is received,
swr will see a large delay and inject silence from firstpts to the
current frame's pts. This can lead to severe desync and in worst case,
loss of audio playback.

Parameter firstpts initialized to AV_NOPTS_VALUE in swr_alloc and then
checked in swr_init to avoid resetting outpts, thus avoiding reapplication
of firstpts.

Fixes #4131.
---
Added fate test

 libswresample/options.c   |  1 +
 libswresample/swresample.c|  5 +++--
 tests/fate/libswresample.mak  |  3 +++
 tests/ref/fate/swr-async-firstpts | 24 
 4 files changed, 31 insertions(+), 2 deletions(-)
 create mode 100644 tests/ref/fate/swr-async-firstpts

diff --git a/libswresample/options.c b/libswresample/options.c
index fb109fdbab..d8cf85c053 100644
--- a/libswresample/options.c
+++ b/libswresample/options.c
@@ -171,6 +171,7 @@ av_cold struct SwrContext *swr_alloc(void){
 if(s){
 s->av_class= _class;
 av_opt_set_defaults(s);
+s->firstpts = AV_NOPTS_VALUE;
 }
 return s;
 }
diff --git a/libswresample/swresample.c b/libswresample/swresample.c
index f2a9b40474..1cf83a803f 100644
--- a/libswresample/swresample.c
+++ b/libswresample/swresample.c
@@ -375,8 +375,9 @@ av_cold int swr_init(struct SwrContext *s){
 if (s->firstpts_in_samples != AV_NOPTS_VALUE) {
 if (!s->async && s->min_compensation >= FLT_MAX/2)
 s->async = 1;
-s->firstpts =
-s->outpts   = s->firstpts_in_samples * s->out_sample_rate;
+if (s->firstpts == AV_NOPTS_VALUE)
+s->firstpts =
+s->outpts   = s->firstpts_in_samples * s->out_sample_rate;
 } else
 s->firstpts = AV_NOPTS_VALUE;
 
diff --git a/tests/fate/libswresample.mak b/tests/fate/libswresample.mak
index f2108016af..0d29f76024 100644
--- a/tests/fate/libswresample.mak
+++ b/tests/fate/libswresample.mak
@@ -1082,6 +1082,9 @@ $(call 
CROSS_TEST,$(SAMPLERATES_LITE),ARESAMPLE_EXACT_LIN_ASYNC,s32p,s32le,s16)
 $(call CROSS_TEST,$(SAMPLERATES_LITE),ARESAMPLE_EXACT_LIN_ASYNC,fltp,f32le,s16)
 $(call CROSS_TEST,$(SAMPLERATES_LITE),ARESAMPLE_EXACT_LIN_ASYNC,dblp,f64le,s16)
 
+FATE_SWR_RESAMPLE-$(call FILTERDEMDEC, ARESAMPLE ASETPTS ATRIM SINE, , 
PCM_S16LE, LAVFI_INDEV) += fate-swr-async-firstpts
+fate-swr-async-firstpts: CMD = framecrc -auto_conversion_filters -copyts -f 
lavfi -i 
"sine=r=1000:samples_per_frame=100,asetpts=PTS+S+S*floor(ld(1)/4)+st(1\,ld(1)+1)*0,atrim=end=2"
 -filter:a aresample=async=300:first_pts=0
+
 FATE_SWR_RESAMPLE-$(call FILTERDEMDECENCMUX, ARESAMPLE, WAV, PCM_S16LE, 
PCM_S16LE, WAV) += $(FATE_SWR_RESAMPLE)
 fate-swr-resample: $(FATE_SWR_RESAMPLE-yes)
 FATE_SWR += $(FATE_SWR_RESAMPLE-yes)
diff --git a/tests/ref/fate/swr-async-firstpts 
b/tests/ref/fate/swr-async-firstpts
new file mode 100644
index 00..3f6b290bab
--- /dev/null
+++ b/tests/ref/fate/swr-async-firstpts
@@ -0,0 +1,24 @@
+#tb 0: 1/1000
+#media_type 0: audio
+#codec_id 0: pcm_s16le
+#sample_rate 0: 1000
+#channel_layout_name 0: mono
+0,  0,  0,  132,  264, 0xc2981f45
+0,132,132,   68,  136, 0xe78e468d
+0,200,200,  100,  200, 0xd55c67d0
+0,300,300,  100,  200, 0xd55c67d0
+0,400,400,  100,  200, 0xd55c67d0
+0,500,500,   93,  186, 0x85ca5db4
+0,593,593,  110,  220, 0xa2655d0b
+0,703,703,  108,  216, 0x95cb6f01
+0,811,811,  108,  216, 0xf35668b8
+0,919,919,  149,  298, 0xc273245f
+0,   1068,   1068,  136,  272, 0xedeb6e0a
+0,   1204,   1204,   98,  196, 0xea18668e
+0,   1302,   1302,   98,  196, 0x412861e7
+0,   1400,   1400,   98,  196, 0x7ec361b2
+0,   1498,   1498,  110,  220, 0xf3ae6a6a
+0,   1608,   1608,  108,  216, 0xab2f6c93
+0,   1716,   1716,  107,  214, 0x50de6eb9
+0,   1823,   1823,  106,  212, 0x67b8656d
+0,   1929,   1929,   18,   36, 0x2b7911c6
-- 
2.39.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 v2] riscv: vc1dsp: Don't check vlenb before checking the CPU flags

2023-12-16 Thread Rémi Denis-Courmont 
Le perjantaina 15. joulukuuta 2023, 17.38.45 EET Martin Storsjö a écrit :
> We can't call ff_get_rv_vlenb() if we don't have RVV available
> at all.
> 
> Due to the SIGILL signal handler in checkasm catching it, in an
> unexpected place, this caused checkasm to hang instead of reporting
> the issue.
> ---
>  libavcodec/riscv/vc1dsp_init.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
> index 0d22d28f4d..e47b644f80 100644
> --- a/libavcodec/riscv/vc1dsp_init.c
> +++ b/libavcodec/riscv/vc1dsp_init.c
> @@ -35,15 +35,13 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
>  #if HAVE_RVV
>  int flags = av_get_cpu_flags();
> 
> -if (ff_get_rv_vlenb() >= 16) {
> +if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
> +dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
> +dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
>  if (flags & AV_CPU_FLAG_RVV_I64) {
>  dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
>  dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
>  }
> -if (flags & AV_CPU_FLAG_RVV_I32) {
> -dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
> -dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
> -}
>  }
>  #endif
>  }

Acked-by: 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".

[FFmpeg-devel] [PATCH] lavc/vc1dsp: fix R-V V vector lengths

2023-12-16 Thread Rémi Denis-Courmont 
The 8x4 and 4x4 use a needlessly large multiplier (unless/until we care
about embedded 64-bit-vector hardware). This is merely suboptimal.

The 8x4 case also uses an incorrect vector length, which leads to incorrect
behaviour on future/hypothetical hardware with 256-bit or larger vectors.

Pointed-out-by: Martin Storsjö 
---
 libavcodec/riscv/vc1dsp_rvv.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/riscv/vc1dsp_rvv.S b/libavcodec/riscv/vc1dsp_rvv.S
index 1a503ecc87..4a00945ead 100644
--- a/libavcodec/riscv/vc1dsp_rvv.S
+++ b/libavcodec/riscv/vc1dsp_rvv.S
@@ -68,7 +68,7 @@ endfunc
 
 func ff_vc1_inv_trans_8x4_dc_rvv, zve64x
 lht2, (a2)
-vsetivli  zero, 8, e8, mf2, ta, ma
+vsetivli  zero, 4, e8, mf4, ta, ma
 vlse64.v  v0, (a0), a1
 sh1addt2, t2, t2
 addi  t2, t2, 1
@@ -84,14 +84,14 @@ func ff_vc1_inv_trans_8x4_dc_rvv, zve64x
 vmax.vx   v4, v4, zero
 vsetvli   zero, zero, e8, m2, ta, ma
 vnclipu.wiv0, v4, 0
-vsetivli  zero, 8, e8, mf2, ta, ma
+vsetivli  zero, 4, e8, mf4, ta, ma
 vsse64.v  v0, (a0), a1
 ret
 endfunc
 
 func ff_vc1_inv_trans_4x4_dc_rvv, zve32x
 lht2, (a2)
-vsetivli  zero, 4, e8, mf2, ta, ma
+vsetivli  zero, 4, e8, mf4, ta, ma
 vlse32.v  v0, (a0), a1
 slli  t1, t2, 4
 add   t2, t2, t1
@@ -107,7 +107,7 @@ func ff_vc1_inv_trans_4x4_dc_rvv, zve32x
 vmax.vx   v2, v2, zero
 vsetvli   zero, zero, e8, m1, ta, ma
 vnclipu.wiv0, v2, 0
-vsetivli  zero, 4, e8, mf2, ta, ma
+vsetivli  zero, 4, e8, mf4, ta, ma
 vsse32.v  v0, (a0), a1
 ret
 endfunc
-- 
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 v3 2/2] fate: Add fsync filter tests

2023-12-16 Thread Thilo Borgmann via ffmpeg-devel 
---
 tests/Makefile   |  6 +++-
 tests/fate/filter-video.mak  |  6 
 tests/maps/fsync-down|  7 
 tests/maps/fsync-up  | 57 +
 tests/ref/fate/filter-fsync-down | 12 +++
 tests/ref/fate/filter-fsync-up   | 62 
 6 files changed, 149 insertions(+), 1 deletion(-)
 create mode 100644 tests/maps/fsync-down
 create mode 100644 tests/maps/fsync-up
 create mode 100644 tests/ref/fate/filter-fsync-down
 create mode 100644 tests/ref/fate/filter-fsync-up

diff --git a/tests/Makefile b/tests/Makefile
index 444c09b3de..c7892a9313 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -23,7 +23,7 @@ FFMPEG=ffmpeg$(PROGSSUF)$(EXESUF)
 $(AREF): CMP=
 
 APITESTSDIR := tests/api
-FATE_OUTDIRS = tests/data tests/data/fate tests/data/filtergraphs 
tests/data/lavf tests/data/lavf-fate tests/data/pixfmt tests/vsynth1 
$(APITESTSDIR)
+FATE_OUTDIRS = tests/data tests/data/fate tests/data/filtergraphs 
tests/data/maps tests/data/lavf tests/data/lavf-fate tests/data/pixfmt 
tests/vsynth1 $(APITESTSDIR)
 OUTDIRS += $(FATE_OUTDIRS)
 
 $(VREF): tests/videogen$(HOSTEXESUF) | tests/vsynth1
@@ -66,6 +66,10 @@ tests/data/filtergraphs/%: TAG = COPY
 tests/data/filtergraphs/%: $(SRC_PATH)/tests/filtergraphs/% | 
tests/data/filtergraphs
$(M)cp $< $@
 
+tests/data/maps/%: TAG = COPY
+tests/data/maps/%: $(SRC_PATH)/tests/maps/% | tests/data/maps
+   $(M)cp $< $@
+
 RUNNING_FATE := $(filter check fate%,$(filter-out fate-rsync,$(MAKECMDGOALS)))
 
 # Check sanity of dependencies when running FATE tests.
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index b57ef88c9b..072169ac7e 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -395,6 +395,12 @@ FATE_FILTER_SAMPLES-$(call FILTERDEMDEC, FPS SCALE, MOV, 
QTRLE) += fate-filter-f
 fate-filter-fps-cfr: CMD = framecrc -auto_conversion_filters -i 
$(TARGET_SAMPLES)/qtrle/apple-animation-variable-fps-bug.mov -r 30 -fps_mode 
cfr -pix_fmt yuv420p
 fate-filter-fps: CMD = framecrc -auto_conversion_filters -i 
$(TARGET_SAMPLES)/qtrle/apple-animation-variable-fps-bug.mov -vf fps=30 
-pix_fmt yuv420p
 
+FATE_FILTER_SAMPLES-$(call FILTERFRAMECRC, TESTSRC2 FSYNC, FILE_PROTOCOL) += 
fate-filter-fsync-up fate-filter-fsync-down
+fate-filter-fsync-up: tests/data/maps/fsync-up
+fate-filter-fsync-up: CMD = framecrc -lavfi 
testsrc2=r=25:d=1,fsync=f=tests/data/maps/fsync-up
+fate-filter-fsync-down: tests/data/maps/fsync-down
+fate-filter-fsync-down: CMD = framecrc -lavfi 
testsrc2=r=25:d=1,fsync=f=tests/data/maps/fsync-down
+
 FATE_FILTER_ALPHAEXTRACT_ALPHAMERGE := $(addprefix 
fate-filter-alphaextract_alphamerge_, rgb yuv)
 FATE_FILTER_VSYNTH_PGMYUV-$(call ALLYES, SCALE_FILTER FORMAT_FILTER 
SPLIT_FILTER ALPHAEXTRACT_FILTER ALPHAMERGE_FILTER) += 
$(FATE_FILTER_ALPHAEXTRACT_ALPHAMERGE)
 $(FATE_FILTER_ALPHAEXTRACT_ALPHAMERGE): fate-filter-alphaextract_alphamerge_%: 
tests/data/filtergraphs/alphamerge_alphaextract_%
diff --git a/tests/maps/fsync-down b/tests/maps/fsync-down
new file mode 100644
index 00..107761ecbe
--- /dev/null
+++ b/tests/maps/fsync-down
@@ -0,0 +1,7 @@
+1 0 1/7
+5 1 1/7
+8 2 1/7
+12 3 1/7
+16 4 1/7
+19 5 1/7
+23 6 1/7
diff --git a/tests/maps/fsync-up b/tests/maps/fsync-up
new file mode 100644
index 00..c37a1fae14
--- /dev/null
+++ b/tests/maps/fsync-up
@@ -0,0 +1,57 @@
+0 0 1/57
+0 1 1/57
+1 2 1/57
+1 3 1/57
+1 4 1/57
+2 5 1/57
+2 6 1/57
+3 7 1/57
+3 8 1/57
+4 9 1/57
+4 10 1/57
+5 11 1/57
+5 12 1/57
+5 13 1/57
+6 14 1/57
+6 15 1/57
+7 16 1/57
+7 17 1/57
+8 18 1/57
+8 19 1/57
+8 20 1/57
+9 21 1/57
+9 22 1/57
+10 23 1/57
+10 24 1/57
+11 25 1/57
+11 26 1/57
+12 27 1/57
+12 28 1/57
+12 29 1/57
+13 30 1/57
+13 31 1/57
+14 32 1/57
+14 33 1/57
+15 34 1/57
+15 35 1/57
+16 36 1/57
+16 37 1/57
+16 38 1/57
+17 39 1/57
+17 40 1/57
+18 41 1/57
+18 42 1/57
+19 43 1/57
+19 44 1/57
+19 45 1/57
+20 46 1/57
+20 47 1/57
+21 48 1/57
+21 49 1/57
+22 50 1/57
+22 51 1/57
+23 52 1/57
+23 53 1/57
+23 54 1/57
+24 55 1/57
+24 56 1/57
diff --git a/tests/ref/fate/filter-fsync-down b/tests/ref/fate/filter-fsync-down
new file mode 100644
index 00..d3f04060ad
--- /dev/null
+++ b/tests/ref/fate/filter-fsync-down
@@ -0,0 +1,12 @@
+#tb 0: 1/7
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 320x240
+#sar 0: 1/1
+0,  0,  0,1,   115200, 0x7ed43658
+0,  1,  1,1,   115200, 0x5418f45b
+0,  2,  2,1,   115200, 0x9872fad9
+0,  3,  3,1,   115200, 0x4dbbf2e0
+0,  4,  4,1,   115200, 0xcce711f5
+0,  5,  5,1,   115200, 0xaa341025
+0,  6,  6,1,   115200, 0xb41eeaac
diff --git a/tests/ref/fate/filter-fsync-up b/tests/ref/fate/filter-fsync-up
new file mode 100644
index 00..ea7f7efe2d
--- /dev/null
+++ b/tests/ref/fate/filter-fsync-up
@@ -0,0 +1,62 @@
+#tb 0: 1/57

[FFmpeg-devel] [PATCH v3 1/2] avfilter: Add fsync filter

2023-12-16 Thread Thilo Borgmann via ffmpeg-devel 
---
 Changelog|   1 +
 MAINTAINERS  |   1 +
 configure|   2 +
 doc/filters.texi |  33 +
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/version.h|   2 +-
 libavfilter/vf_fsync.c   | 286 +++
 8 files changed, 326 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/vf_fsync.c

diff --git a/Changelog b/Changelog
index 67ef92eb02..a25278d227 100644
--- a/Changelog
+++ b/Changelog
@@ -9,6 +9,7 @@ version :
 - aap filter
 - demuxing, decoding, filtering, encoding, and muxing in the
   ffmpeg CLI now all run in parallel
+- fsync filter
 
 version 6.1:
 - libaribcaption decoder
diff --git a/MAINTAINERS b/MAINTAINERS
index 39b37ee0c5..4257fcad98 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -343,6 +343,7 @@ Filters:
   vf_delogo.c   Jean Delvare (CC )
   vf_drawbox.c/drawgrid Andrey Utkin
   vf_extractplanes.cPaul B Mahol
+  vf_fsync.cThilo Borgmann
   vf_histogram.cPaul B Mahol
   vf_hqx.c  Clément Bœsch
   vf_idet.c Pascal Massimino
diff --git a/configure b/configure
index 7d2ee66000..2328c96dde 100755
--- a/configure
+++ b/configure
@@ -3745,6 +3745,7 @@ frei0r_deps_any="libdl LoadLibrary"
 frei0r_filter_deps="frei0r"
 frei0r_src_filter_deps="frei0r"
 fspp_filter_deps="gpl"
+fsync_filter_deps="avformat"
 gblur_vulkan_filter_deps="vulkan spirv_compiler"
 hflip_vulkan_filter_deps="vulkan spirv_compiler"
 histeq_filter_deps="gpl"
@@ -7647,6 +7648,7 @@ enabled cover_rect_filter   && prepend avfilter_deps 
"avformat avcodec"
 enabled ebur128_filter && enabled swresample && prepend avfilter_deps 
"swresample"
 enabled elbg_filter && prepend avfilter_deps "avcodec"
 enabled find_rect_filter&& prepend avfilter_deps "avformat avcodec"
+enabled fsync_filter&& prepend avfilter_deps "avformat"
 enabled mcdeint_filter  && prepend avfilter_deps "avcodec"
 enabled movie_filter&& prepend avfilter_deps "avformat avcodec"
 enabled pan_filter  && prepend avfilter_deps "swresample"
diff --git a/doc/filters.texi b/doc/filters.texi
index 6d00ba2c3f..9f19cba9df 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14681,6 +14681,39 @@ option may cause flicker since the B-Frames have often 
larger QP. Default is
 
 @end table
 
+@anchor{fsync}
+@section fsync
+
+Synchronize video frames with an external mapping from a file.
+
+For each input PTS given in the map file it either drops or creates as many 
frames as necessary to recreate the sequence of output frames given in the map 
file.
+
+This filter is useful to recreate the output frames of a framerate conversion 
by the @ref{fps} filter, recorded into a map file using the ffmpeg option 
@code{-stats_mux_pre}, and do further processing to the corresponding frames 
e.g. quality comparison.
+
+Each line of the map file must contain three items per input frame, the input 
PTS (decimal), the output PTS (decimal) and the output TIMEBASE 
(decimal/decimal), seperated by a space.
+This file format corresponds to the output of 
@code{-stats_mux_pre_fmt="@{ptsi@} @{pts@} @{tb@}"}.
+
+The filter assumes the map file is sorted by increasing input PTS.
+
+The filter accepts the following options:
+@table @option
+
+@item file, f
+The filename of the map file to be used.
+@end table
+
+Example:
+@example
+# Convert a video to 25 fps and record a MAP_FILE file with the default format 
of this filter
+ffmpeg -i INPUT -vf fps=fps=25 -stats_mux_pre MAP_FILE -stats_mux_pre_fmt 
"@{ptsi@} @{pts@} @{tb@}" OUTPUT
+
+# Sort MAP_FILE by increasing input PTS
+sort -n MAP_FILE
+
+# Use INPUT, OUTPUT and the MAP_FILE from above to compare the corresponding 
frames in INPUT and OUTPUT via SSIM
+ffmpeg -i INPUT -i OUTPUT -filter_complex 
'[0:v]fsync=file=MAP_FILE[ref];[1:v][ref]ssim' -f null -
+@end example
+
 @section gblur
 
 Apply Gaussian blur filter.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 63725f91b4..612616dfb4 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -323,6 +323,7 @@ OBJS-$(CONFIG_FREEZEDETECT_FILTER)   += 
vf_freezedetect.o
 OBJS-$(CONFIG_FREEZEFRAMES_FILTER)   += vf_freezeframes.o
 OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o
 OBJS-$(CONFIG_FSPP_FILTER)   += vf_fspp.o qp_table.o
+OBJS-$(CONFIG_FSYNC_FILTER)  += vf_fsync.o
 OBJS-$(CONFIG_GBLUR_FILTER)  += vf_gblur.o
 OBJS-$(CONFIG_GBLUR_VULKAN_FILTER)   += vf_gblur_vulkan.o vulkan.o 
vulkan_filter.o
 OBJS-$(CONFIG_GEQ_FILTER)+= vf_geq.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ed7c32be94..b32ffb2d71 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -299,6 +299,7 @@ extern const AVFilter ff_vf_freezedetect;

[FFmpeg-devel] [PATCH v3 0/2] avfilter: Add fsync filter

2023-12-16 Thread Thilo Borgmann via ffmpeg-devel 
Synchronize video frames with an external mapping from a file.
Follows up on the idea in 
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305986.html 
implemented as a filter.

Not storing the frame map in a probably huge string but buffering
piece-wise. Using a fixed format string. Passthrough for all pixel
formats.

Thilo Borgmann (2):
  avfilter: Add fsync filter
  fate: Add fsync filter tests

 Changelog|   1 +
 MAINTAINERS  |   1 +
 configure|   2 +
 doc/filters.texi |  33 
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/version.h|   2 +-
 libavfilter/vf_fsync.c   | 286 +++
 tests/Makefile   |   6 +-
 tests/fate/filter-video.mak  |   6 +
 tests/maps/fsync-down|   7 +
 tests/maps/fsync-up  |  57 ++
 tests/ref/fate/filter-fsync-down |  12 ++
 tests/ref/fate/filter-fsync-up   |  62 +++
 14 files changed, 475 insertions(+), 2 deletions(-)
 create mode 100644 libavfilter/vf_fsync.c
 create mode 100644 tests/maps/fsync-down
 create mode 100644 tests/maps/fsync-up
 create mode 100644 tests/ref/fate/filter-fsync-down
 create mode 100644 tests/ref/fate/filter-fsync-up

-- 
2.37.1 (Apple Git-137.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 1/2] avfilter: Add fsync filter

2023-12-16 Thread Thilo Borgmann via ffmpeg-devel 

Am 15.12.23 um 15:17 schrieb Andreas Rheinhardt:

Thilo Borgmann via ffmpeg-devel:

---
  Changelog|   1 +
  MAINTAINERS  |   1 +
  doc/filters.texi |  33 +
  libavfilter/Makefile |   1 +
  libavfilter/allfilters.c |   1 +
  libavfilter/version.h|   2 +-
  libavfilter/vf_fsync.c   | 304 +++
  7 files changed, 342 insertions(+), 1 deletion(-)
  create mode 100644 libavfilter/vf_fsync.c

[...]
+// fills the buffer from cur to end, add \0 at EOF
+static int buf_fill(FsyncContext *ctx)
+{
+int ret;
+int num = ctx->end - ctx->cur;
+
+ret = avio_read(ctx->avio_ctx, ctx->cur, num);
+if (ret < 0)
+return ret;
+if (ret < num) {
+*(ctx->cur + ret) = '\0';
+}
+
+return ret;
+}
+
+// copies cur to end to the beginning and fills the rest
+static int buf_reload(FsyncContext *ctx)
+{
+int i, ret;
+int num = ctx->end - ctx->cur;
+
+for (i = 0; i < num; i++) {
+ctx->buf[i] = *ctx->cur++;
+}
+
+ctx->cur = ctx->buf + i;
+ret = buf_fill(ctx);
+if (ret < 0)
+return ret;
+ctx->cur = ctx->buf;


I wonder whether you should not just use avio_read_to_bprint() for all
of this.


I tested a bit. It appears good for filling the buffer with one function call, 
getting the stuff out for scanf appears not as well as when and how to refill 
the buffer. Comparing a bit to f_metadata where this is used, the necessary 
function get bigger and more complex than this easily.
Maybe its just I didn't use it often enough, but this char* handling appears 
easier and less complex to me.
So if you don't insist I'd leave it that way.


+
+return ret;
+}
+
+// skip from cur over eol
+static void buf_skip_eol(FsyncContext *ctx)
+{
+char *i;
+for (i = ctx->cur; i < ctx->end; i++) {
+if (*i != '\n')// && *i != '\r')
+break;
+}
+ctx->cur = i;
+}
+
+// get number of bytes from cur until eol
+static int buf_get_line_count(FsyncContext *ctx)
+{
+int ret = 0;
+char *i;
+for (i = ctx->cur; i < ctx->end; i++, ret++) {
+if (*i == '\0' || *i == '\n')
+return ret;


If you unconditionally added a single \0 to the end of the buffer, you
could use strchr() here.


I'd need two strchr() calls, for \0 and \n, plus the interpretation of the 
resulting pointers.
Where \0 would always be found at the end of the buffer which needs another if 
to see if its what I need or do need to load more data.



[...]
+
+static av_cold void fsync_uninit(AVFilterContext *ctx)
+{
+FsyncContext *s = ctx->priv;
+
+avio_close(s->avio_ctx);


avio_closep()


+av_freep(>buf);
+av_frame_unref(s->last_frame);


I expect that this needs to be changed to av_frame_free(). Anyway, you
should run your tests via valgrind/asan.


Asan is fine both ways, so I assume it wouldn't catch it?
Changed to av_frame_free anyways.

There appears no Valgrind nor msan to be available for OSX.
'leaks' also even complains it cannot really do its job:

"Can't examine target process's malloc zone asan_0x10c134950, so memory 
analysis will be incomplete or incorrect.
Reason: for security, cannot load non-system library 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib

Process 49784 is not debuggable. Due to security restrictions, leaks can only show 
or save contents of readonly memory of restricted processes."

Am I out of options on OSX? Seems like the first real drawback when on a mac...


Fixed all the other things for v3.

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