On Fri, Aug 9, 2024 at 11:08 AM sfan5 wrote:
>
> revised commit message as suggested
Patch applied. Thanks !
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or ema
On Sat, Aug 17, 2024 at 5:38 AM Marth64 wrote:
>
> I would like to get DVD seeking in and some recent bugfixes (initial
> patchset was sent, working on revision). I'm chasing one last
> lingering issue with chapter-based extraction.
> Hopefully, I can make a breakthrough or get help to fix it soo
Quoting Anton Khirnov (2024-08-16 10:44:42)
> ping
Will push the rest of this set in a couple days unless there are further
comments.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-deve
The only thing this function does beyond calling av_get_pix_fmt() is
falling back onto parsing the argument as a number. No other filters
should need to do this.
---
libavfilter/formats.c | 15 ---
libavfilter/internal.h | 11 ---
libavfilter/vf_format.c | 17 +++
---
libavfilter/avfiltergraph.c | 1 +
libavfilter/buffersrc.c | 1 +
libavfilter/internal.h | 6 --
libavfilter/video.h | 6 ++
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
index 0da2f8462b..6317f
It does not do anything when the links are already configured.
---
libavfilter/f_streamselect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/f_streamselect.c b/libavfilter/f_streamselect.c
index 07d55a7506..ecdcc7f269 100644
--- a/libavfilter/f_streamselect.c
+++
That is a more appropriate place for those functions.
---
libavfilter/audio.c | 36 +++
libavfilter/audio.h | 25
libavfilter/formats.c | 38 -
libavfilter/internal.h | 27 --
internal.h currently mixes interfaces intended to be used by filters
with those that should be limited to generic filter- or graph-level
code.
---
libavfilter/af_acontrast.c | 1 +
libavfilter/af_acopy.c | 1 +
libavfilter/af_acrusher.c | 1 +
libavfilter/af_a
Nothing in it needs to be visible to filters.
---
libavfilter/avfilter.c | 6 ++
libavfilter/avfilter_internal.h | 18 ++
libavfilter/filters.h | 25 ++---
3 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/libavfilter/avfil
---
libavfilter/avfilter_internal.h | 15 +++
libavfilter/filters.h | 15 ---
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/libavfilter/avfilter_internal.h b/libavfilter/avfilter_internal.h
index 3b8d6fe60e..8386183745 100644
--- a/libavfilter/a
Quoting Dale Curtis (2024-07-31 23:10:24)
> On Wed, Jul 31, 2024 at 4:32 AM Anton Khirnov wrote:
>
> > Quoting Dale Curtis (2024-07-31 01:14:13)
> > > I realized there are a couple more allocations that can be skipped here
> > > when a codec is not on the allow list. Here's the updated patch.
> >
Quoting Danny Hong (2024-08-16 21:49:05)
> Quoting Anton Khirnov (2024-08-16 09:32:28)
> > The way this will work is that different views will be output by decoder
> > as separate frames with side data indicating their view ID.
>
> Thanks for the info again! Wouldn't it be easier for the user/co
Quoting Dale Curtis (2024-08-02 18:54:04)
> This results in an unnecessary ~800k allocation with H.264. A
> nearby callsite uses avcodec_is_open() to avoid this, so do the
> same when exiting avformat_find_stream_info().
>
> Signed-off-by: Dale Curtis
> ---
> libavformat/demux.c | 9 ++---
>
>
> FP_INFINITE is a return value from fpclassify(), not a double.
>
> Does maybe using av_int2double(UINT64_C(0xFFF) << 52) help your slow
> startup?
>
Sadly, no.
double log = (fpclassify(val) == FP_ZERO ? av_int2double(UINT64_C(0xFFF) <<
52) : floor(log10(fabs(val;
gives the same long-star
On 8/16/2024 4:49 PM, Danny Hong wrote:
Quoting Anton Khirnov (2024-08-16 09:32:28)
The way this will work is that different views will be output by decoder
as separate frames with side data indicating their view ID.
Thanks for the info again! Wouldn't it be easier for the user/consumer of
t
On Fri, Aug 16, 2024 at 1:16 PM Martin Storsjö wrote:
> On Thu, 15 Aug 2024, Ramiro Polla wrote:
> > checkasm --bench for Raspberry Pi 5 Model B Rev 1.0:
> > sse_0_c: 241.5
> > sse_0_neon: 37.2
> > sse_0_dotprod: 22.2
> > vsse_4_c: 148.7
> > vsse_4_neon: 31.0
> > vsse_4_dotprod: 15.7
> > ---
> > l
Le 17 août 2024 06:09:16 GMT+03:00, Mike Lieman a écrit :
>From b2ddfdd9ed695a1f47ed6251369abca08864e3ab Mon Sep 17 00:00:00 2001
>From: Mike Lieman
>Date: Fri, 16 Aug 2024 23:05:51 -0400
>Subject: [PATCH] use proper macro to avoid issue with prior
>avutil/timestamp.c
> patch causing long start
I now understand that and am trying to work through the logic to see why
we are getting this strange behaviour.When I have some free time, I
think I'm going to have to step through this with gdb since without the
context of what's actually in buf, ts, and tb I can't understand what's
going on
How can I test the weight and biweight of H.264? I haven't seen the related
test code..
tests/checkasm/checkasm --bench --test=h264dsp
Rémi Denis-Courmont 于2024年8月15日周四 16:10写道：
>
>
> Le 3 août 2024 13:30:34 GMT+03:00, u...@foxmail.com a écrit :
> >From: sunyuechi
> >
> >
On Sat, Aug 17, 2024 at 3:27 PM Mike Lieman wrote:
>
> >
> > FP_INFINITE is a return value from fpclassify(), not a double.
> >
> > Does maybe using av_int2double(UINT64_C(0xFFF) << 52) help your slow
> > startup?
> >
>
> Sadly, no.
>
> double log = (fpclassify(val) == FP_ZERO ? av_int2double(UINT
>
> On Sat, Aug 17, 2024 at 11:29 AM Hendrik Leppkes
> wrote:
> Or you could check if your build uses ffast-math, not sure we support that
>
Hot Dog! We have a weiner!
Removing -ffast-math from my mplayer build appears to have resolved the
issue. Thank you for your time and guidance.
attached
>From 9e312c20d10839cb2c731acd23bc1b00177cd7dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Llu=C3=ADs=20Batlle=20i=20Rossell?=
Date: Sat, 17 Aug 2024 18:03:37 +0200
Subject: [PATCH] Less CPU use in hwaccel MJPEG decoding
It skips the unnecessary unescaping the entropy-encoded data in case o
v2 attached.
I had crippled the indentation.
On Sat, Aug 17, 2024 at 06:05:24PM +0200, Lluís Batlle i Rossell wrote:
> attached
>From ea2d702daa88bf3b1bde1f03c26c69bb8ab9e2b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Llu=C3=ADs=20Batlle=20i=20Rossell?=
Date: Sat, 17 Aug 2024 18:03:37 +0200
Subjec
Hi
On Fri, Aug 16, 2024 at 10:41:54AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-08-15 22:49:03)
> > On Thu, Aug 15, 2024 at 07:38:50PM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2024-08-15 09:33:07)
> > > > Text was stolen from the linux kernel
> > > > Thi
On Fri, Aug 16, 2024 at 10:41:54AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-08-15 22:49:03)
> > On Thu, Aug 15, 2024 at 07:38:50PM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2024-08-15 09:33:07)
[...]
> > This is just a small step in improving things and r
Le 17 août 2024 19:32:00 GMT+03:00, Michael Niedermayer
a écrit :
>Hi
>
>On Fri, Aug 16, 2024 at 10:41:54AM +0200, Anton Khirnov wrote:
>> Quoting Michael Niedermayer (2024-08-15 22:49:03)
>> > On Thu, Aug 15, 2024 at 07:38:50PM +0200, Anton Khirnov wrote:
>> > > Quoting Michael Niedermayer (20
On Wed, Aug 14, 2024 at 04:32:36PM -0700, Dale Curtis wrote:
> MAX_MBPAIR_SIZE was added in 23f5cff92cdcfa55a735c458fcb5f95c0e0f3b1f
> to prevent CABAC/CAVLC overread issues. It adds 256kb of padding to
> RBSP allocations. AFAICT it seems unnecessary with the checked
> bitstream reader. Dropping th
On Wed, 14 Aug 2024, Marc-Antoine Arnaud wrote:
---
libavformat/mxfdec.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
Why would you want to tune this?
Thanks,
Marton
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index a5863445ab5..df958819300 100644
---
On 8/17/2024 3:04 PM, Michael Niedermayer wrote:
On Wed, Aug 14, 2024 at 04:32:36PM -0700, Dale Curtis wrote:
MAX_MBPAIR_SIZE was added in 23f5cff92cdcfa55a735c458fcb5f95c0e0f3b1f
to prevent CABAC/CAVLC overread issues. It adds 256kb of padding to
RBSP allocations. AFAICT it seems unnecessary wi
On Sat, 6 Jul 2024, Rémi Denis-Courmont wrote:
Le lauantaina 6. heinäkuuta 2024, 19.20.33 EEST Andreas Rheinhardt a écrit :
Rémi Denis-Courmont:
> Le lauantaina 6. heinäkuuta 2024, 18.23.00 EEST Andreas Rheinhardt a écrit
:
>>
>> This adds an indirection. I have asked you to actually benchma
On Sat, Aug 17, 2024 at 01:32:56AM +0200, epira...@gmail.com wrote:
>
>
> On 17 Aug 2024, at 1:11, Michael Niedermayer wrote:
>
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/APIchanges | 4
> > libavcodec/avcodec.h | 4
> > 2 files changed, 8 insertions(+)
> >
> > diff
---
libavcodec/vvc/dsp.c| 4 ++--
libavcodec/vvc/inter_template.c | 10 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavcodec/vvc/dsp.c b/libavcodec/vvc/dsp.c
index 648d54ebb2..7463d8c9de 100644
--- a/libavcodec/vvc/dsp.c
+++ b/libavcodec/vvc/dsp.c
@@ -8
---
libavcodec/vvc/dsp.c| 25 +
libavcodec/vvc/dsp.h| 4 +-
libavcodec/vvc/inter_template.c | 65 ++---
3 files changed, 31 insertions(+), 63 deletions(-)
diff --git a/libavcodec/vvc/dsp.c b/libavcodec/vvc/dsp.c
index 7463d8c9de..43
BDoF used about 10%–25% of the CPU for some clips.
Here are the FPS for one run; please ignore the negative values, as they may be
due to round-to-round variation
clips | before | after | delta
||---|---
apply_bdof_8_8x16_c: 5718.7
apply_bdof_8_8x16_avx2: 1029.9
apply_bdof_8_16x8_c: 5669.4
apply_bdof_8_16x8_avx2: 592.2
apply_bdof_8_16x16_c: 11313.4
apply_bdof_8_16x16_avx2: 1211.9
apply_bdof_10_8x16_c: 6295.7
apply_bdof_10_8x16_avx2: 1019.9
apply_bdof_10_16x8_c: 5548.2
apply_bdof_10_16x8_avx2: 580.9
On 8/17/2024 10:48 PM, Nuo Mi wrote:
+pxorm6, m6
+phaddw m%2, m6
+phaddw m%2, m6
Horizonal adds are slow. Can't you do this with normal adds, shifts and
blend?
+vpermq m%2, m%2, q0020
+pshufd
This commit cleans up and refactors the mess of private state upon
private state that used to be.
Now, FFHWBaseEncodePicture is fully initialized upon call-time,
and, most importantly, this lets APIs which require initialization
data for frames (VkImageViews) to initialize this for both the
input
37 matches
Mail list logo
