ffmpeg -i 1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -s 640x480 -pix_fmt
rgb24 -y /dev/null -an
before: 150fps
after: 183fps
Signed-off-by: Hao Chen
---
libswscale/loongarch/Makefile |3 +-
libswscale/loongarch/output_lasx.c| 1982 +
ffmpeg -i 1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -s 640x480 -y /dev/null -an
before: 101fps
after: 138fps
Signed-off-by: Hao Chen
---
libswscale/loongarch/Makefile | 3 +
libswscale/loongarch/input_lasx.c | 202
libswscale/loongarch/swscale_init_loongarch.c
ffmpeg -i 1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -pix_fmt rgb24 -y /dev/null
-an
before: 178fps
after: 210fps
Signed-off-by: Hao Chen
---
libswscale/loongarch/Makefile | 2 +
libswscale/loongarch/rgb2rgb_lasx.c | 52 +++
v2: Some modifications were made according to the comments of the reviewers.
[PATCH v2 1/3] swscale/la: Optimize hscale functions with lasx.
[PATCH v2 2/3] swscale/la: Add yuv2rgb_lasx.c and rgb2rgb_lasx.c
[PATCH v2 3/3] swscale/la: Add output_lasx.c file.
This commit implements an iMDCT in pure assembly.
This is capable of processing any mod-8 transforms, rather than just
power of two, but since power of two is all we have assembly for
currently, that's what's supported.
It would really benefit if we could somehow use the C code to decide
which
Needed for the next patch.
We get this for the extremely small cost of a branch on _ns functions,
which wouldn't be used anyway with assembly.
Patch attached.
>From a62ecf3fb5bcb192566bb89d5fad2762baa6f95d Mon Sep 17 00:00:00 2001
From: Lynne
Date: Sat, 3 Sep 2022 03:34:57 +0200
Subject: [PATCH
Hi again,
On Fri, Sep 2, 2022 at 2:05 PM Paul B Mahol wrote:
> > > > So is there a filter that already dumps this information?
> > > Not in text but in visual, note that you can write own code that uses
> > > library to dump MV as text, because MV are exported when certain flag is
> > > enabled.
It is advantageous for ff_crop_tab, as the base pointer used to
access this table is not the first element of it. But the real
base pointer is still at a constant offset from the code/the GOT
and can therefore be accessed relative to the instruction pointer
(if supported by the arch) or relative
Am Fr., 2. Sept. 2022 um 23:56 Uhr schrieb Andreas Rheinhardt
:
>
> Carl Eugen Hoyos:
> > Fixes several warnings:
> > warning: format specifies type 'unsigned char' but the argument has type
> > 'unsigned int'
> > ---
> > libavformat/hevc.c | 8
> > 1 file changed, 4 insertions(+), 4
Carl Eugen Hoyos:
> Fixes several warnings:
> warning: format specifies type 'unsigned char' but the argument has type
> 'unsigned int'
> ---
> libavformat/hevc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/hevc.c b/libavformat/hevc.c
> index
On Mon, 22 Aug 2022, Hubert Mazur wrote:
Provide optimized implementation of vsad16 function for arm64.
Performance comparison tests are shown below.
- vsad_0_c: 285.0
- vsad_0_neon: 42.5
Benchmarks and tests are run with checkasm tool on AWS Graviton 3.
Signed-off-by: Hubert Mazur
---
Hi!
Attached patch reduces the stack size of an init function, fixes part
of ticket #9399.
Please comment, Carl Eugen
From 0f034ebed2388e89e241d7e08bf59d335b5c4cee Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 2 Sep 2022 23:36:29 +0200
Subject: [PATCH] lavc/cfhddata: Reduce
On Mon, 22 Aug 2022, Hubert Mazur wrote:
Add vectorized implementation of nsse16 function.
Performance comparison tests are shown below.
- nsse_0_c: 707.0
- nsse_0_neon: 120.0
Benchmarks and tests run with checkasm tool on AWS Graviton 3.
Signed-off-by: Hubert Mazur
---
Anton Khirnov:
> This state is not refcounted, so make sure it always has a well-defined
> owner.
> ---
> Steve, could you please test this?
> ---
> libavcodec/pthread_frame.c | 37 -
> 1 file changed, 32 insertions(+), 5 deletions(-)
>
> diff --git
Hi!
Attached patch fixes a few warnings.
Please comment, Carl Eugen
0001-lavf-hevc-Fix-type-specifiers-missed-in-8b5d1553.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Fri, Sep 2, 2022 at 8:04 PM Chema Gonzalez wrote:
> Hi again,
>
> On Fri, Sep 2, 2022 at 9:10 AM Paul B Mahol wrote:
> >
> > On Fri, Sep 2, 2022 at 5:12 PM Chema Gonzalez
> wrote:
> >
> > > So is there a filter that already dumps this information?
> > >
> >
> > Not in text but in visual,
This state is not refcounted, so make sure it always has a well-defined
owner.
---
Steve, could you please test this?
---
libavcodec/pthread_frame.c | 37 -
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/libavcodec/pthread_frame.c
Andreas Rheinhardt:
> ff_thread_video_encode_frame() already returns blank frames.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/encode.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
> index
Martijn van Beurden:
> First of all, thanks for reviewing.
>
> Op vr 2 sep. 2022 om 17:11 schreef Andreas Rheinhardt <
> andreas.rheinha...@outlook.com>:
>
>>> +static inline void put_sbits64(PutBitContext *pb, int n, int64_t value)
>>> +{
>>> +av_assert2(n >= 0 && n <= 64);
>>> +
>>> +
First of all, thanks for reviewing.
Op vr 2 sep. 2022 om 17:11 schreef Andreas Rheinhardt <
andreas.rheinha...@outlook.com>:
> > +static inline void put_sbits64(PutBitContext *pb, int n, int64_t value)
> > +{
> > +av_assert2(n >= 0 && n <= 64);
> > +
> > +put_bits64(pb, n,
Hi again,
On Fri, Sep 2, 2022 at 9:10 AM Paul B Mahol wrote:
>
> On Fri, Sep 2, 2022 at 5:12 PM Chema Gonzalez wrote:
>
> > So is there a filter that already dumps this information?
> >
>
> Not in text but in visual, note that you can write own code that uses
> library to dump MV as text,
On Fri, Sep 2, 2022 at 6:32 PM Michael Niedermayer
wrote:
> On Mon, Jun 13, 2022 at 09:13:19PM +0200, Michael Niedermayer wrote:
> > On Mon, Jun 13, 2022 at 12:10:44PM +0200, Paul B Mahol wrote:
> > > On Mon, Jun 13, 2022 at 11:48 AM Anton Khirnov
> wrote:
> > >
> > > > Quoting Paul B Mahol
On Mon, Jun 13, 2022 at 09:13:19PM +0200, Michael Niedermayer wrote:
> On Mon, Jun 13, 2022 at 12:10:44PM +0200, Paul B Mahol wrote:
> > On Mon, Jun 13, 2022 at 11:48 AM Anton Khirnov wrote:
> >
> > > Quoting Paul B Mahol (2022-06-13 11:34:44)
> > > > On Mon, Jun 13, 2022 at 11:10 AM Anton
On Fri, Sep 2, 2022 at 5:12 PM Chema Gonzalez wrote:
> So is there a filter that already dumps this information?
>
Not in text but in visual, note that you can write own code that uses
library to dump MV as text, because MV are exported when certain flag is
enabled.
>
> Thanks,
> -Chema
>
> On
So is there a filter that already dumps this information?
Thanks,
-Chema
On Fri, Sep 2, 2022 at 12:56 AM Paul B Mahol wrote:
>
> On Thu, Sep 1, 2022 at 8:43 PM Chema Gonzalez wrote:
>
> > Hi Paul,
> >
> > Can you please describe how you can get the MV values?
> >
>
> See how filters do it.
Martijn van Beurden:
> Add encoding of 32 bit-per-sample PCM to FLAC files to libavcodec.
> Coding to this format is at this point considered experimental and
> -strict -2 is needed to get ffmpeg to encode such files.
> ---
> libavcodec/flacenc.c| 499
Add encoding of 32 bit-per-sample PCM to FLAC files to libavcodec.
Coding to this format is at this point considered experimental and
-strict -2 is needed to get ffmpeg to encode such files.
---
libavcodec/flacenc.c| 499
libavcodec/put_bits.h | 7
Add decoding of FLAC files coding for 32 bit-per-sample PCM to libavcodec.
---
libavcodec/flac.c | 4 +-
libavcodec/flacdec.c | 248 ++
libavcodec/get_bits.h | 12 ++
libavcodec/mathops.h | 9 ++
4 files changed, 250 insertions(+), 23
Recently libFLAC gained the ability (not in any released version yet
though) to create FLAC files containing 32-bit int PCM samples. To
keep complexity reasonable, the choice was made to limit residuals
to 32-bit integers, which the encoder must make sure of. In case
the encoder cannot find any
On Fri, Sep 2, 2022 at 7:55 AM Lynne wrote:
> +movd xmm4, strided
> +neg t2d
> +movd xmm5, t2d
> +SPLATD xmm4
> +SPLATD xmm5
> +vperm2f128 m4, m4, m4, 0x00 ; +stride splatted
> +vperm2f128 m5, m5, m5, 0x00 ; -stride splatted
movd xm4, strided
pxor m5, m5
On Tue, 9 Aug 2022, Martin Storsjö wrote:
These were missed when h264_chroma_mc_func was changed in
e4a94d8b36c48d95a7d412c40d7b558422ff659c.
Signed-off-by: Martin Storsjö
---
libavcodec/arm/rv40dsp_init_arm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
OK'd by Andreas on
On Fri, 26 Aug 2022, Martin Storsjö wrote:
This fixes building for arm targets with optimizations disabled.
---
libavutil/arm/intmath.h | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/libavutil/arm/intmath.h b/libavutil/arm/intmath.h
index
On Sat, 27 Aug 2022, Martin Storsjö wrote:
The AArch64 assembly accesses those symbols directly, without
indirection via e.g. the GOT on ELF. In order for this not to
require text relocations, those symbols need to be resolved fully
at link time, i.e. those symbols can't be interposable.
Paul B Mahol:
> On Thu, Sep 1, 2022 at 11:50 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/libtheoraenc.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> So it currently does not compile or?
>
On Sun, Aug 28, 2022 at 07:39:53PM +0200, Michael Niedermayer wrote:
> On Sun, Aug 21, 2022 at 04:23:09PM +0200, Michael Niedermayer wrote:
> > On Sun, Aug 21, 2022 at 12:54:57PM +0200, Paul B Mahol wrote:
> > > On Fri, Aug 19, 2022 at 12:36 AM Michael Niedermayer
> > >
> > > wrote:
> > >
> > >
On Thu, Sep 1, 2022 at 11:50 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/libtheoraenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> So it currently does not compile or?
> diff --git
On Fri, Sep 2, 2022 at 10:15 AM Anton Khirnov wrote:
> Quoting Paul B Mahol (2022-09-02 10:14:49)
> > On Fri, Sep 2, 2022 at 10:04 AM Anton Khirnov wrote:
> >
> > > Quoting Paul B Mahol (2022-09-02 10:00:22)
> > > > On Fri, Sep 2, 2022 at 9:27 AM Anton Khirnov
> wrote:
> > > >
> > > > >
Quoting Paul B Mahol (2022-09-02 10:14:49)
> On Fri, Sep 2, 2022 at 10:04 AM Anton Khirnov wrote:
>
> > Quoting Paul B Mahol (2022-09-02 10:00:22)
> > > On Fri, Sep 2, 2022 at 9:27 AM Anton Khirnov wrote:
> > >
> > > > Quoting Paul B Mahol (2022-08-31 18:40:32)
> > > > > Patch attached.
> > > >
On Fri, Sep 2, 2022 at 10:04 AM Anton Khirnov wrote:
> Quoting Paul B Mahol (2022-09-02 10:00:22)
> > On Fri, Sep 2, 2022 at 9:27 AM Anton Khirnov wrote:
> >
> > > Quoting Paul B Mahol (2022-08-31 18:40:32)
> > > > Patch attached.
> > > >
> > > > From c539fcd63ca339c0299029f9de1b2aff613e3da8
Quoting Paul B Mahol (2022-09-02 10:00:22)
> On Fri, Sep 2, 2022 at 9:27 AM Anton Khirnov wrote:
>
> > Quoting Paul B Mahol (2022-08-31 18:40:32)
> > > Patch attached.
> > >
> > > From c539fcd63ca339c0299029f9de1b2aff613e3da8 Mon Sep 17 00:00:00 2001
> > > From: Paul B Mahol
> > > Date: Wed, 31
Quoting Steve Lhomme (2022-08-19 10:07:54)
> Hi,
>
> On 2022-08-02 16:19, Anton Khirnov wrote:
> > Why are you not resubmitting your original patch that stops copying
> > hwaccel_priv_data to the user-facing context?
> >
> > It seemed more correct to me, since the user-facing context should
On Fri, Sep 02, 2022 at 09:11:26AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2022-09-02 00:34:36)
> > On Tue, Jul 12, 2022 at 08:20:18PM +0200, Michael Niedermayer wrote:
> > > On Tue, Jun 14, 2022 at 12:09:59AM +0200, Michael Niedermayer wrote:
> > > > On Tue, Jun 14, 2022 at
On Fri, Sep 2, 2022 at 9:27 AM Anton Khirnov wrote:
> Quoting Paul B Mahol (2022-08-31 18:40:32)
> > Patch attached.
> >
> > From c539fcd63ca339c0299029f9de1b2aff613e3da8 Mon Sep 17 00:00:00 2001
> > From: Paul B Mahol
> > Date: Wed, 31 Aug 2022 18:36:04 +0200
> > Subject: [PATCH]
On Thu, Sep 1, 2022 at 8:43 PM Chema Gonzalez wrote:
> Hi Paul,
>
> Can you please describe how you can get the MV values?
>
See how filters do it. They visualize MV but using similar logic one could
dump them to ton of texts.
>
> Thanks,
> -Chema
>
>
> On Thu, Sep 1, 2022 at 10:52 AM Paul B
Quoting Paul B Mahol (2022-08-31 18:40:32)
> Patch attached.
>
> From c539fcd63ca339c0299029f9de1b2aff613e3da8 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Wed, 31 Aug 2022 18:36:04 +0200
> Subject: [PATCH] avcodec/amr*bdec: return only number of consumed bytes
Could mention where does
Quoting Michael Niedermayer (2022-09-02 00:34:36)
> On Tue, Jul 12, 2022 at 08:20:18PM +0200, Michael Niedermayer wrote:
> > On Tue, Jun 14, 2022 at 12:09:59AM +0200, Michael Niedermayer wrote:
> > > On Tue, Jun 14, 2022 at 12:01:14AM +0200, Paul B Mahol wrote:
> > > > On Mon, Jun 13, 2022 at
Quoting Carl Eugen Hoyos (2022-09-01 21:28:08)
> Hi!
>
> Attached patch fixes ticket #9799.
>
> Please comment, Carl Eugen
>
> From 2cce687961c3b56a92d88184269bf9fa075ae297 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Thu, 1 Sep 2022 20:55:54 +0200
> Subject: [PATCH] lavfi/rotate:
As I already said to you in private, I do not think the motivation and
use cases for this have been sufficiently established.
You claim this will bring massive advantages all over the place. You
should support these claims with some actual patches that demonstrate
these advantages on some real
48 matches
Mail list logo
