> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Sunday, September 4, 2022 8:58 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] d3dva security hw+threads
>
> Quoting Timo Rothenpieler (2022-09-02 0
Le sunnuntaina 4. syyskuuta 2022, 9.39.36 EEST Lynne a écrit :
> In particular, doing the tail, which consists of 2 equal length transforms.
> On AVX we interleave the coefficients from 2x4pt transforms during
> lookups since we can do them simultaneously and save on
> shuffles. Doing them individu
The following changes since commit b6e8fc1c201d58672639134a737137e1ba7b55fe:
avcodec/speexdec: improve support for speex in non-ogg (2022-09-04 11:31:57
+0200)
are waiting thorough bashing at your express convenience up to:
riscv: float vector dot product with RVV (2022-09-04 16:45:38 +0300
From: Rémi Denis-Courmont
---
libavutil/riscv/float_dsp_init.c | 9 -
libavutil/riscv/float_dsp_rvv.S | 34
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/libavutil/riscv/float_dsp_init.c b/libavutil/riscv/float_dsp_init.c
index 279412c0
From: Rémi Denis-Courmont
---
libavutil/riscv/float_dsp_init.c | 6 +
libavutil/riscv/float_dsp_rvv.S | 42
2 files changed, 48 insertions(+)
diff --git a/libavutil/riscv/float_dsp_init.c b/libavutil/riscv/float_dsp_init.c
index 4135284c76..a1bb112ec7 1006
From: Rémi Denis-Courmont
---
libavutil/riscv/float_dsp_init.c | 3 +++
libavutil/riscv/float_dsp_rvv.S | 19 +++
2 files changed, 22 insertions(+)
diff --git a/libavutil/riscv/float_dsp_init.c b/libavutil/riscv/float_dsp_init.c
index a1bb112ec7..8539fe9ac5 100644
--- a/libavu
From: Rémi Denis-Courmont
---
libavutil/riscv/float_dsp_init.c | 2 ++
libavutil/riscv/float_dsp_rvv.S | 18 ++
2 files changed, 20 insertions(+)
diff --git a/libavutil/riscv/float_dsp_init.c b/libavutil/riscv/float_dsp_init.c
index 8539fe9ac5..2165394585 100644
--- a/libavuti
From: Rémi Denis-Courmont
---
libavutil/riscv/float_dsp_init.c | 3 +++
libavutil/riscv/float_dsp_rvv.S | 22 ++
2 files changed, 25 insertions(+)
diff --git a/libavutil/riscv/float_dsp_init.c b/libavutil/riscv/float_dsp_init.c
index 2165394585..1183460181 100644
--- a/lib
From: Rémi Denis-Courmont
---
libavutil/riscv/float_dsp_init.c | 3 +++
libavutil/riscv/float_dsp_rvv.S | 35
2 files changed, 38 insertions(+)
diff --git a/libavutil/riscv/float_dsp_init.c b/libavutil/riscv/float_dsp_init.c
index 1183460181..887706d899 100644
From: Rémi Denis-Courmont
---
libavutil/riscv/float_dsp_init.c | 2 ++
libavutil/riscv/float_dsp_rvv.S | 23 +++
2 files changed, 25 insertions(+)
diff --git a/libavutil/riscv/float_dsp_init.c b/libavutil/riscv/float_dsp_init.c
index 887706d899..7c2fc10e99 100644
--- a/lib
From: Rémi Denis-Courmont
RVV defines a total of 12 different extensions: V, Zvl32b, Zvl64b,
Zvl128b, Zvl256b, Zvl512b, Zvl1024b, Zve32x, Zve32f, Zve64x, Zve64f and
Zve64d.
At this stage, we don't expose the vector length extensions Zvl*, as
the vector length is most commonly determined at run-t
From: Rémi Denis-Courmont
---
libavutil/riscv/asm.S | 33 +
1 file changed, 33 insertions(+)
create mode 100644 libavutil/riscv/asm.S
diff --git a/libavutil/riscv/asm.S b/libavutil/riscv/asm.S
new file mode 100644
index 00..31001b8bdb
--- /dev/null
+++ b
From: Rémi Denis-Courmont
This is based on existing code from the VLC git tree with two minor
changes to account for the different function prototypes.
---
libavutil/float_dsp.c| 2 ++
libavutil/float_dsp.h| 1 +
libavutil/riscv/Makefile | 4 ++-
libavutil/risc
Sep 4, 2022, 15:54 by r...@remlab.net:
> The following changes since commit b6e8fc1c201d58672639134a737137e1ba7b55fe:
>
> avcodec/speexdec: improve support for speex in non-ogg (2022-09-04 11:31:57
> +0200)
>
> are waiting thorough bashing at your express convenience up to:
>
> riscv: float vec
Another critical fix for decoder.
From e61c05f721eee756739ba7cd864486ea9704b3c9 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 4 Sep 2022 20:50:16 +0200
Subject: [PATCH] avcodec/flac: smallest frame is 10 bytes
Fixes #9270
Signed-off-by: Paul B Mahol
---
libavcodec/flac.h| 2 +-
li
Le sunnuntaina 4. syyskuuta 2022, 20.48.26 EEST Lynne a écrit :
> > The pointer arithmetic could be slightly optimised with SH2ADD and
> > SH3ADD instructions from the Zvba extension. This would require more
> > conditional code, or requiring support for Zvba for probably neglible
> > performance g
On 8/30/22 8:23 PM, Stephen Hutchinson wrote:
Initialized to 1:1, but if the script sets these properties, it
will be set to those instead (0:0 disables it, apparently).
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 8
1 file changed, 8 insertions(+)
diff --git a/l
On 8/30/22 8:23 PM, Stephen Hutchinson wrote:
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 52 ++
1 file changed, 52 insertions(+)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index d978e6ec40..7bb2977383 100644
--- a/
On 8/30/22 8:23 PM, Stephen Hutchinson wrote:
Signed-off-by: Stephen Hutchinson
---
libavformat/avisynth.c | 348 -
1 file changed, 174 insertions(+), 174 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 7bb2977383..b426a
On 9/4/22 14:54, Paul B Mahol wrote:
Another critical fix for decoder.
___
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 w
On 8/25/22 3:46 AM, Steinar Apalnes wrote:
tor. 25. aug. 2022 kl. 02:11 skrev Stephen Hutchinson :
On 8/24/22 1:04 PM, Steinar Apalnes wrote:
tir. 8. feb. 2022 kl. 12:03 skrev Stephen Hutchinson :
* Field Order
* Chroma Location
* Color Transfer Characteristics
* Color Range
* Color Primarie
On Mon, 22 Aug 2022, Hubert Mazur wrote:
Provide optimized implementation of vsse16 for arm64.
Performance comparison tests are shown below.
- vsse_0_c: 254.4
- vsse_0_neon: 64.7
Benchmarks and tests are run with checkasm tool on AWS Graviton 3.
Signed-off-by: Hubert Mazur
---
libavcodec/aar
On Mon, 22 Aug 2022, Hubert Mazur wrote:
Provide optimized implementation for vsad_intra16 function for arm64.
Performance comparison tests are shown below.
- vsad_4_c: 177.2
- vsad_4_neon: 24.5
Benchmarks and tests are run with checkasm tool on AWS Gravtion 3.
Signed-off-by: Hubert Mazur
--
On Mon, 22 Aug 2022, Hubert Mazur wrote:
Provide optimized implementation for vsse_intra16 for arm64.
Performance tests are shown below.
- vsse_4_c: 153.7
- vsse_4_neon: 34.2
Benchmarks and tests are run with checkasm tool on AWS Graviton 3.
Signed-off-by: Hubert Mazur
---
libavcodec/aarch64
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
---
libavcodec/aarch64/me
Andreas Rheinhardt andreas.rheinhardt at outlook.com
Wed Aug 31 05:54:12 EEST 2022
>
> > +#if HAVE_THREADS
> > +
> > +struct work_pool_data
> > +{
> > +AVFormatContext *ctx;
> > +struct representation *pls;
> > +struct representation *common_pls;
> > +pthread_mutex_t *common_mutex;
On Fri, Sep 02, 2022 at 06:48:57PM +0200, Paul B Mahol wrote:
> 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 a
Right now, it is nearly ordered by "left codes in the tree first";
the only exception is the escape value which has been put at the
end. This commit moves it to the place it should have according
to the above order. This is in preparation for further commits.
Signed-off-by: Andreas Rheinhardt
---
This is possible because the codes are already ordered
from left to right in the tree. It avoids having to create
the codes ourselves and will enable the codes table
to be removed altogether once the encoder stops using it.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dvdec.c | 9 +++--
The codes can be easily calculated, so the table is unnecessary.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dv_tablegen.h | 5 +++-
libavcodec/dvdata.c | 54
libavcodec/dvdata.h | 1 -
3 files changed, 4 insertions(+), 56 deletions(-)
d
Forgotten in 6d484671ecb612c32cbda0fab65f961743aff5f8.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dvdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
index 8f68d2715d..3857ed1266 100644
--- a/libavcodec/dvdec.c
+++ b/libavcode
Instead reuse the destination RL VLC as scratch space.
This is possible, because the (implicit) codes here are already
ordered from left-to-right in the tree and because the codelengths
are increasing, which implies that mapping from VLC entries to the
corresponding entries used to initialize the V
These codes are already ordered from left-to-right in the tree,
so one can just use ff_init_vlc_static_from_lengths().
Signed-off-by: Andreas Rheinhardt
---
libavcodec/wmavoice.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/libavcodec/wmavoice.c b/libavcode
It allows to replace tables of big codes (uint16_t and uint32_t)
by tables of smaller symbols (mostly uint8_t).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/wmaprodata.h | 551
libavcodec/wmaprodec.c | 42 +--
2 files changed, 236 insertions(+), 357
Signed-off-by: Andreas Rheinhardt
---
libavcodec/wmaprodec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/wmaprodec.c b/libavcodec/wmaprodec.c
index 1909ce2dad..698841dcaf 100644
--- a/libavcodec/wmaprodec.c
+++ b/libavcodec/wmaprodec.c
@@ -320,7 +320,7 @@ st
By using a symbol table one can already bake in applying
a LUT on the return value of get_vlc2(). So change the
symbol table for the vec2 and vec4 tables to avoid
using the symbol_to_vec2/4 LUTs.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/wmaprodata.h | 147 +---
Lukas Fellechner:
> Andreas Rheinhardt andreas.rheinhardt at outlook.com
> Wed Aug 31 05:54:12 EEST 2022
>>
>>> +#if HAVE_THREADS
>>> +
>>> +struct work_pool_data
>>> +{
>>> +AVFormatContext *ctx;
>>> +struct representation *pls;
>>> +struct representation *common_pls;
>>> +pthread_
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> trailing_padding seems to be unused and could actually be deprecated.
>
Will apply this patchset tomorrow unless there are objections. Notice
that I really like to have a second opinion on whether trailing_padding
should be printed
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/libtheoraenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libtheoraenc.c b/libavcodec/libtheoraenc.c
> index 22835553d6..92bf3a133c 100644
> --- a/libavcodec/libtheoraenc.c
> +
The FFV1 decoder only uses the last frame's data to conceal
errors. The encoder does not have this problem and therefore
only uses the current frame and none of the ThreadFrames.
So only allocate them for the decoder.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ffv1.c| 13 -
Signed-off-by: Andreas Rheinhardt
---
libavfilter/avfilter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index 965f5d0f63..6740339808 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -62,7 +62,7 @@ static v
Signed-off-by: Andreas Rheinhardt
---
Will apply this tomorrow unless there are objections.
libavutil/tests/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavutil/tests/.gitignore b/libavutil/tests/.gitignore
index 919010e4fc..87895912f5 100644
--- a/libavutil/tests/.gitignore
On 9/4/2022 8:36 PM, Andreas Rheinhardt wrote:
Signed-off-by: Andreas Rheinhardt
---
Will apply this tomorrow unless there are objections.
LGTM. Backport it to the 5.1 branch too, please.
libavutil/tests/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavutil/tests/.giti
Signed-off-by: Andreas Rheinhardt
---
Will apply tomorrow unless there are objections.
tools/.gitignore | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/.gitignore b/tools/.gitignore
index c0958f40cb..7c45896923 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -3,6 +3,7 @@
/b
Starting with an h264 implementation. Can be extended to support other codecs.
A few caveats:
- OpenGOP streams are currently not supported. The firt packet must be an IDR
frame.
- In some streams, a few frames at the end may not get a reordered PTS when
they reference frames past EOS. The cod
On Mon, 2022-08-29 at 14:01 +, Xiang, Haihao wrote:
> On Mon, 2022-08-29 at 08:17 -0300, James Almer wrote:
> > On 8/29/2022 4:27 AM, Xiang, Haihao wrote:
> > > From: Haihao Xiang
> > >
> > > AV_PIX_FMT_VUYX is used in FFmpeg for 8bit 4:4:4 content on Intel HW,
> > > and MFX_FOURCC_AYUV is us
On Thu, 2022-09-01 at 10:12 +0800, Xiang, Haihao wrote:
> From: Haihao Xiang
>
> Currently AVBR is disabled and VBR is the default method if maxrate is
> not specified on Linux, but AVBR is the default one if maxrate is not
> specified on Windows. In order to make user experience better accross
>
Instead of the potentially adjusted ones. Otherwise, if config_props() is
called again and if using force_original_aspect_ratio, the already adjusted
values could be altered again.
Example command line
scale=size=1920x1000:force_original_aspect_ratio=decrease:force_divisible_by=2
user value 1920x
Hi Anton,
On 2022-09-02 22:59, Anton Khirnov wrote:
This state is not refcounted, so make sure it always has a well-defined
owner.
---
Steve, could you please test this?
I can confirm it doesn't leak the context and plays correctly. It also
doesn't crash ;)
---
libavcodec/pthread_frame.c
Quoting Steve Lhomme (2022-09-05 07:42:17)
> Hi Anton,
>
> On 2022-09-02 22:59, Anton Khirnov wrote:
> > This state is not refcounted, so make sure it always has a well-defined
> > owner.
> > ---
> > Steve, could you please test this?
>
> I can confirm it doesn't leak the context and plays correc
Quoting Soft Works (2022-09-04 09:43:36)
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Anton Khirnov
> > Sent: Sunday, September 4, 2022 8:58 AM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [RFC] d3dva securi
On Sun, 2022-09-04 at 22:04 -0700, Philip Langdale wrote:
> On Mon, 5 Sep 2022 02:47:44 +
> "Xiang, Haihao" wrote:
>
> > On Mon, 2022-08-29 at 14:01 +, Xiang, Haihao wrote:
> > > On Mon, 2022-08-29 at 08:17 -0300, James Almer wrote:
> > > > On 8/29/2022 4:27 AM, Xiang, Haihao wrote:
>
52 matches
Mail list logo