On Wed, Oct 13, 2021 at 3:57 PM Paul B Mahol wrote:
> Why this filter is being applied at first place at all?
>
> It is extraordinary slow and used very slow algorithm and reallocates
> memory all the time.
>
Additionally so called fast mode, which is indeed faster than bilateral
filter, is unus
Signed-off-by: Wu Jianhua
---
libavfilter/x86/vf_exposure.asm| 5 +
libavfilter/x86/vf_exposure_init.c | 6 ++
2 files changed, 11 insertions(+)
diff --git a/libavfilter/x86/vf_exposure.asm b/libavfilter/x86/vf_exposure.asm
index 3351c6fb3b..a0d25afbc4 100644
--- a/libavfilter/x86/vf
Performance data(Less is better):
exposure_c:857394
exposure_asm: 327589
Signed-off-by: Wu Jianhua
---
libavfilter/exposure.h | 36 +++
libavfilter/vf_exposure.c | 36 +--
libavfilter/x86/Makefile | 2 ++
libavfilter/x86/vf_exp
Signed-off-by: Wu Jianhua
---
libavfilter/vf_exposure.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavfilter/vf_exposure.c b/libavfilter/vf_exposure.c
index 045ae710d3..9fd9f88293 100644
--- a/libavfilter/vf_exposure.c
+++ b/libavfilter/vf_exposure.c
@@ -57,6 +57,7 @@
Signed-off-by: Wu Jianhua
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c| 3 ++
tests/checkasm/checkasm.h| 1 +
tests/checkasm/vf_exposure.c | 68
tests/fate/checkasm.mak | 1 +
5 files changed, 74 insertions(+)
create mode
NACK, exposure can be changed at runtime.
___
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".
On Fri, Oct 22, 2021 at 1:13 AM Michael Niedermayer
wrote:
>
> On Fri, Oct 22, 2021 at 12:32:18AM +0300, Jan Ekström wrote:
> > On Fri, Oct 22, 2021 at 12:21 AM Jan Ekström wrote:
> > >
> > > On Thu, Oct 21, 2021 at 11:49 PM Michael Niedermayer
> > > wrote:
> > > >
> > > > On Thu, Oct 21, 2021 a
Paul B Mahol wrote:
> Sent: Friday, October 22, 2021 4:59 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Wu, Jianhua
> Subject: Re: [FFmpeg-devel] [PATCH 3/4] avfilter/vf_exposure: calculate
> scale when initializing filter
>
> NACK, exposure can be changed at runtim
Performance data(Less is better):
exposure_c:857394
exposure_asm: 327589
Signed-off-by: Wu Jianhua
---
libavfilter/exposure.h | 36 +++
libavfilter/vf_exposure.c | 36 +--
libavfilter/x86/Makefile | 2 ++
libavfilter/x86/vf_exp
Signed-off-by: Wu Jianhua
---
libavfilter/x86/vf_exposure.asm| 5 +
libavfilter/x86/vf_exposure_init.c | 6 ++
2 files changed, 11 insertions(+)
diff --git a/libavfilter/x86/vf_exposure.asm b/libavfilter/x86/vf_exposure.asm
index 3351c6fb3b..a0d25afbc4 100644
--- a/libavfilter/x86/vf
Signed-off-by: Wu Jianhua
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c| 3 ++
tests/checkasm/checkasm.h| 1 +
tests/checkasm/vf_exposure.c | 62
tests/fate/checkasm.mak | 1 +
5 files changed, 68 insertions(+)
create mode
Hi.
Currently, there is no legitimate way to flush data buffered within the
muxer for applications that choose to use av_interleaved_write_frame.
Actually one could flush muxer buffers with av_write_frame, but docs forbid
mixing av_interleaved_write_frame/av_write_frame within a single muxing
cont
From: Caleb Whiting
This allows more precise selection of windows.
---
libavdevice/gdigrab.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index c069232472..266da3414c 100644
--- a/libavdevi
Oh, there is a problem with return codes.
av_interleaved_write_frame:
* @return 0 on success, a negative AVERROR on error.
av_write_frame:
* @return < 0 on error, = 0 if OK, 1 if flushed and there is no more data
to flush
I could:
- add "1" to the list of possible return codes of
av_interleave
On Fri, Oct 22, 2021 at 12:20:19PM +0300, Jan Ekström wrote:
> On Fri, Oct 22, 2021 at 1:13 AM Michael Niedermayer
> wrote:
> >
> > On Fri, Oct 22, 2021 at 12:32:18AM +0300, Jan Ekström wrote:
> > > On Fri, Oct 22, 2021 at 12:21 AM Jan Ekström wrote:
> > > >
> > > > On Thu, Oct 21, 2021 at 11:49
On Fri, Oct 22, 2021 at 6:16 PM Michael Niedermayer
wrote:
>
> On Fri, Oct 22, 2021 at 12:20:19PM +0300, Jan Ekström wrote:
> > On Fri, Oct 22, 2021 at 1:13 AM Michael Niedermayer
> > wrote:
> > >
> > > On Fri, Oct 22, 2021 at 12:32:18AM +0300, Jan Ekström wrote:
> > > > On Fri, Oct 22, 2021 at 1
On Fri, Oct 22, 2021 at 08:42:14PM +0300, Jan Ekström wrote:
> On Fri, Oct 22, 2021 at 6:16 PM Michael Niedermayer
> wrote:
> >
> > On Fri, Oct 22, 2021 at 12:20:19PM +0300, Jan Ekström wrote:
> > > On Fri, Oct 22, 2021 at 1:13 AM Michael Niedermayer
> > > wrote:
> > > >
> > > > On Fri, Oct 22, 2
On Thu, Oct 21, 2021 at 08:49:36PM -0400, Leo Izen wrote:
> Use the external libjxl library to add decoding for JPEG XL
> images, and add the appropriate image2 muxers and demuxers
> to read/write JPEG XL image files.
> ---
> MAINTAINERS | 2 +
> configure | 5 +
>
On Fri, Oct 22, 2021 at 12:00:19AM +0200, Mattias Wadman wrote:
> On Thu, Oct 21, 2021 at 10:35 PM Michael Niedermayer
> wrote:
>
> > On Thu, Oct 21, 2021 at 10:17:25PM +0200, Paul B Mahol wrote:
> > > LGTM for now
> >
> > will apply the improved variant below
> >
> > diff --git a/libavcodec/flac
On Fri, Oct 22, 2021 at 11:26 PM Michael Niedermayer
wrote:
>
> On Fri, Oct 22, 2021 at 08:42:14PM +0300, Jan Ekström wrote:
> > On Fri, Oct 22, 2021 at 6:16 PM Michael Niedermayer
> > wrote:
> > >
> > > On Fri, Oct 22, 2021 at 12:20:19PM +0300, Jan Ekström wrote:
> > > > On Fri, Oct 22, 2021 at
On Sat, Oct 23, 2021 at 12:11 AM Jan Ekström wrote:
>
> On Fri, Oct 22, 2021 at 11:26 PM Michael Niedermayer
> wrote:
> >
> > On Fri, Oct 22, 2021 at 08:42:14PM +0300, Jan Ekström wrote:
> > > On Fri, Oct 22, 2021 at 6:16 PM Michael Niedermayer
> > > wrote:
> > > >
> > > > On Fri, Oct 22, 2021 a
On Fri, Oct 22, 2021 at 4:31 PM Michael Niedermayer
wrote:
>
> This should be split between libavcodec and libavformat
How so? the avformat patch won't work without the avcodec codec ID
addition anyway, so the avformat patch still requires changing
avcodec.
> also probe still fails
> Failure of j
On Sat, Oct 23, 2021 at 12:13 AM Jan Ekström wrote:
>
> On Sat, Oct 23, 2021 at 12:11 AM Jan Ekström wrote:
> >
> > On Fri, Oct 22, 2021 at 11:26 PM Michael Niedermayer
> > wrote:
> > >
> > > On Fri, Oct 22, 2021 at 08:42:14PM +0300, Jan Ekström wrote:
> > > > On Fri, Oct 22, 2021 at 6:16 PM Mic
On Fri, Oct 22, 2021 at 05:14:46PM -0400, Leo Izen wrote:
> On Fri, Oct 22, 2021 at 4:31 PM Michael Niedermayer
> wrote:
> >
> > This should be split between libavcodec and libavformat
> How so? the avformat patch won't work without the avcodec codec ID
> addition anyway, so the avformat patch sti
Fixes: ./ffplay dav.y4m -vf "scale=hd1080:threads=4"
Found-by: Paul
Signed-off-by: Michael Niedermayer
---
libswscale/utils.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 367b0ea5015..3752c3ec38c 100644
--- a/libswscale/uti
Signed-off-by: Michael Niedermayer
---
libswscale/utils.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 3752c3ec38c..632f6fd4648 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -995,7 +995,10 @@ int sws_setColorsp
On Thu, Oct 21, 2021 at 4:49 PM Derek Buitenhuis
wrote:
>
> Signed-off-by: Derek Buitenhuis
> ---
> All known encoders, etc. expect RPUs in this format, to my knowledge.
> (There is no spec for parsing the RPUs, even privately, and not a single
> piece of software that would benefit from that
Do
On 10/22/2021 6:45 PM, Michael Niedermayer wrote:
Fixes: ./ffplay dav.y4m -vf "scale=hd1080:threads=4"
Found-by: Paul
Signed-off-by: Michael Niedermayer
---
libswscale/utils.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
inde
On 10/22/2021 6:45 PM, Michael Niedermayer wrote:
Signed-off-by: Michael Niedermayer
---
libswscale/utils.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 3752c3ec38c..632f6fd4648 100644
--- a/libswscale/utils.c
+++ b/libs
29 matches
Mail list logo