Quoting Michael Niedermayer (2024-07-22 23:14:04)
> On Mon, Jul 22, 2024 at 11:43:21AM +0200, Anton Khirnov wrote:
> > There is no reason to delay it and this is a more natural place for
> > this code.
>
> There is a reason.
> By doing it later the surrounding pixels are available and one could
>
From: Fei Wang
Fix cmd:
ffmpeg.exe -init_hw_device d3d11va=d3d -init_hw_device qsv=qsv@d3d \
-filter_hw_device d3d -hwaccel qsv -hwaccel_output_format qsv \
-i in.h264 -vf "hwmap,format=d3d11,hwdownload,format=nv12" -y out.yuv
Signed-off-by: Fei Wang
---
libavutil/hwcontext_qsv.c | 7
Am 22.07.24 um 08:57 schrieb Anton Khirnov:
Quoting Stefan Oltmanns (2024-07-18 14:12:42)
Hello Anton,
can you eloborate on that? What is unacceptable with my patch that is
perfectly fine in the AviSynth input module? It's the very same concept.
It's not perfectly fine in avisynth, I dislike
On 23/07/2024 01:01, Josh Allmann wrote:
On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote:
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *aft
On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote:
>
> Encoders may emit a buffering period SEI without a corresponding
> SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
>
> During Annex B conversion, this may result in the SPS/PPS being
> inserted *after* the buffering period SEI but b
On Wed, Jul 17, 2024 at 08:47:45AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-07-11 11:49:37)
> > Found by code review related to coverity
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/avio.h | 2 +-
> > 1 file chang
On Mon, Jul 22, 2024 at 06:13:43PM -0300, James Almer wrote:
> On 7/21/2024 10:50 AM, Michael Niedermayer wrote:
> > No distros are listed on downstreams that are not EOL that use 4.1
> > ---
> > src/download| 37 -
> > src/olddownload | 37 +++
On Mon, Jul 22, 2024 at 11:43:21AM +0200, Anton Khirnov wrote:
> There is no reason to delay it and this is a more natural place for
> this code.
There is a reason.
By doing it later the surrounding pixels are available and one could
compute motion vectors from these surroundings and use all kinds
On 7/21/2024 10:50 AM, Michael Niedermayer wrote:
No distros are listed on downstreams that are not EOL that use 4.1
---
src/download| 37 -
src/olddownload | 37 +
2 files changed, 37 insertions(+), 37 deletions(-)
On 7/21/2024 10:50 AM, Michael Niedermayer wrote:
Only ubuntu 23.10 uses 6.0 according to downstreams and that is EOL in a few
days
also 23.10 users will probably upgrade to 24.04 LTS so shouldnt affect anyone
---
src/download| 36
src/olddownload | 36
---
tests/checkasm/riscv/checkasm.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/checkasm/riscv/checkasm.S b/tests/checkasm/riscv/checkasm.S
index 835cc7d315..e8bcbb271e 100644
--- a/tests/checkasm/riscv/checkasm.S
+++ b/tests/checkasm/riscv/checkasm.S
@@ -75,6 +75,8 @@ func checka
Currently the start of the byte range for each function is aligned to
4 bytes. But this can lead to situations whence the function is preceded
by a 2-byte C.NOP at the aligned 4-byte boundary. Then the first actual
instruction and the function symbol are only aligned on 2 bytes.
This forcefully di
---
tests/checkasm/riscv/checkasm.S | 4
1 file changed, 4 insertions(+)
diff --git a/tests/checkasm/riscv/checkasm.S b/tests/checkasm/riscv/checkasm.S
index 73ca85f344..835cc7d315 100644
--- a/tests/checkasm/riscv/checkasm.S
+++ b/tests/checkasm/riscv/checkasm.S
@@ -49,6 +49,7 @@ saved_regs
---
libswscale/riscv/input_rvv.S | 12
libswscale/riscv/range_rvv.S | 4
libswscale/riscv/rgb2rgb_rvb.S | 1 +
libswscale/riscv/rgb2rgb_rvv.S | 7 +++
4 files changed, 24 insertions(+)
diff --git a/libswscale/riscv/input_rvv.S b/libswscale/riscv/input_rvv.S
index 1d7d
---
libavfilter/riscv/af_afir_rvv.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/riscv/af_afir_rvv.S b/libavfilter/riscv/af_afir_rvv.S
index 04ec2e50d8..2d2b8b1ed3 100644
--- a/libavfilter/riscv/af_afir_rvv.S
+++ b/libavfilter/riscv/af_afir_rvv.S
@@ -22,6 +22,7 @@
// void ff
---
libavcodec/riscv/aacencdsp_rvv.S | 2 ++
libavcodec/riscv/aacpsdsp_rvv.S| 5 +
libavcodec/riscv/ac3dsp_rvb.S | 2 ++
libavcodec/riscv/ac3dsp_rvv.S | 4
libavcodec/riscv/ac3dsp_rvvb.S | 1 +
libavcodec/riscv/alacdsp_rvv.S | 3 +++
libavcodec/riscv/audiodsp
---
libavutil/riscv/fixed_dsp_rvv.S | 6 ++
libavutil/riscv/float_dsp_rvv.S | 12
libavutil/riscv/lls_rvv.S | 1 +
3 files changed, 19 insertions(+)
diff --git a/libavutil/riscv/fixed_dsp_rvv.S b/libavutil/riscv/fixed_dsp_rvv.S
index 6bac5813b8..7a872f7763 100644
--- a/li
This instruction, if aligned on a 4-byte boundary, defines a valid target
("landing pad") for an indirect call or jump. Since this instruction is a
HINT, it is safe to assemble even if not included in the target
instruction set architecture.
The necessary alignment is already provided by the `func
This saves one register and one instruction per transform.
add16 and add16intra thus become stack-less.
---
libavcodec/riscv/h264dsp_init.c | 25
libavcodec/riscv/h264idct_rvv.S | 51 -
2 files changed, 38 insertions(+), 38 deletions(-)
diff --git
The B extension was finally ratified in May 2024, encompassing:
- Zba (addresses),
- Zbb (basics) and
- Zbs (single bits).
It does not include Zbc (base-2 polynomials).
---
doc/APIchanges| 3 +++
libavutil/cpu.c | 1 +
libavutil/cpu.h | 1 +
libavutil/riscv/cpu.c
configure checks that the assembler supports the B extension (or rather
its constituents) anyway. These macros were dodging sanity checks for
unsupported instructions and nothing else.
---
libavutil/riscv/asm.S | 19 ---
1 file changed, 19 deletions(-)
diff --git a/libavutil/riscv
---
libavutil/riscv/fixed_dsp_rvv.S | 14 +++---
libavutil/riscv/float_dsp_rvv.S | 24
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/libavutil/riscv/fixed_dsp_rvv.S b/libavutil/riscv/fixed_dsp_rvv.S
index 6bac5813b8..0fa6aab3d4 100644
--- a/libav
---
libswscale/riscv/input_rvv.S | 12 ++--
libswscale/riscv/range_rvv.S | 8
libswscale/riscv/rgb2rgb_rvb.S | 2 +-
libswscale/riscv/rgb2rgb_rvv.S | 12 ++--
4 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/libswscale/riscv/input_rvv.S b/libswscale/r
---
libavfilter/riscv/af_afir_rvv.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/riscv/af_afir_rvv.S b/libavfilter/riscv/af_afir_rvv.S
index 04ec2e50d8..2107d97166 100644
--- a/libavfilter/riscv/af_afir_rvv.S
+++ b/libavfilter/riscv/af_afir_rvv.S
@@ -21,7 +21,7 @
---
libavcodec/riscv/aacencdsp_rvv.S | 4 +--
libavcodec/riscv/aacpsdsp_rvv.S| 10 +++
libavcodec/riscv/ac3dsp_rvv.S | 6 ++--
libavcodec/riscv/ac3dsp_rvvb.S | 2 +-
libavcodec/riscv/alacdsp_rvv.S | 6 ++--
libavcodec/riscv/audiodsp_rvv.S| 6 ++--
libavcodec/riscv/b
The RISC-V B bit manipulation extension was ratified only two months ago.
But it is strictly equivalent to the union of the zba, zbb and zbs
extensions which were defined almost 3 years earlier. Rather than require
new assembler, we can just match the extension name manually and translate
it into i
This reworks the func/endfunc macros to support any number of ISA extension
as parameters.
---
libavutil/riscv/asm.S | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/libavutil/riscv/asm.S b/libavutil/riscv/asm.S
index 2cf4f7b7ab..78e9defbd4 100644
--- a/libavut
On Mon, Jul 22, 2024 at 4:01 PM Hendrik Leppkes wrote:
> On Mon, Jul 22, 2024 at 2:14 PM Ramiro Polla wrote:
> > On Mon, Jul 22, 2024 at 12:15 AM Hendrik Leppkes
> > wrote:
> > > On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel
> > > wrote:
> > > > Am 18.07.24 um 17:23 schrieb
At this point, they are identical to the C code, except for isntruction
ordering. In fact, they are typically slower or no faster than the C code.
(Also FWIW, they were incorrectly flagged as requiring fast unaligned memory
accesses.)
---
libavcodec/riscv/Makefile| 3 +-
libavcodec/riscv/
In the 8-bit case, we can actually read/write 8 aligned pixel values per
load/store, which unsurprisingly tends to be faster on 64-bit systems (and
makes no differences on 32-bit systems). This requires ifdef'ing though.
---
libavcodec/vp9dsp_template.c | 32
1 fil
Same as previous commit.
---
libavcodec/vp9dsp_template.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vp9dsp_template.c b/libavcodec/vp9dsp_template.c
index 5c4fb5d6e2..da3cc28e5e 100644
--- a/libavcodec/vp9dsp_template.c
+++ b/libavcodec/vp9dsp_temp
This lets the compiler unroll ever so slightly better (at least in the
16x16 case for RISC-V GCC).
---
libavcodec/vp9dsp_template.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/vp9dsp_template.c b/libavcodec/vp9dsp_template.c
index 9b11661704..5c4fb5d6e2 1
On Thu, Jul 18, 2024 at 6:16 AM Stefan Oltmanns via ffmpeg-devel
wrote:
>
> AviSynth (or better VapourSynth) as filter sounds great, but is it possible?
> The reason why input plugins (like FFmpegSource2) in
> AviSynth/VapourSynth create an index file in a first pass is to allow
> frame-accurate r
On Tue, Jul 2, 2024 at 1:39 PM Michael Niedermayer
wrote:
>
> On Mon, May 27, 2024 at 01:52:26AM +0200, Michael Niedermayer wrote:
> > Fixes: CID1598550 Resource leak
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavdevice/dshow.c | 2 +-
> > 1 fi
On Wed, Jul 17, 2024 at 1:43 AM patches wrote:
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Roger Pack
> Sent: Wednesday, July 17, 2024 3:03 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] avdevice/dshow: Don't skip audio devices
> i
On Mon, Jul 22, 2024 at 9:15 PM Martin Storsjö wrote:
> On Mon, 22 Jul 2024, Zhao Zhili wrote:
>
> > ffmpeg | branch: master | Zhao Zhili | Tue Jul
> 16 00:19:15 2024 +0800| [2d4ef304c9e13f5e8abe37c20ddd0f17102c6393] |
> committer: Nuo Mi
> >
> > avcodec/vvc: Add aarch64 neon optimization for AL
Am 22.07.24 um 14:13 schrieb Ramiro Polla:
On Mon, Jul 22, 2024 at 12:15 AM Hendrik Leppkes wrote:
On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel
wrote:
Am 18.07.24 um 17:23 schrieb epira...@gmail.com:
Well, the DLL directory is added to PATH by the VapourSynth install
On Mon, Jul 22, 2024 at 2:14 PM Ramiro Polla wrote:
>
> On Mon, Jul 22, 2024 at 12:15 AM Hendrik Leppkes wrote:
> > On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel
> > wrote:
> > >
> > > Am 18.07.24 um 17:23 schrieb epira...@gmail.com:
> > > >
> > > >>>
> > > >>> Well, the DLL
On Mon, 22 Jul 2024, Zhao Zhili wrote:
ffmpeg | branch: master | Zhao Zhili | Tue Jul 16
00:19:15 2024 +0800| [2d4ef304c9e13f5e8abe37c20ddd0f17102c6393] | committer: Nuo Mi
avcodec/vvc: Add aarch64 neon optimization for ALF
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=2d4ef304c
On Tue, Jul 16, 2024 at 8:39 PM Nuo Mi wrote:
> Hi Zhili,
> Good job. Appreciate it.
> With this patch, we're very close to smooth 4K@30 playback on my M2.
>
Applied.
Thank you, Zhili, for our first Neon optimizations.
> On Tue, Jul 16, 2024 at 12:19 AM Zhao Zhili
> wrote:
>
>> From: Zhao Zhil
On Mon, Jul 22, 2024 at 12:15 AM Hendrik Leppkes wrote:
> On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel
> wrote:
> >
> > Am 18.07.24 um 17:23 schrieb epira...@gmail.com:
> > >
> > >>>
> > >>> Well, the DLL directory is added to PATH by the VapourSynth installer,
> > >>> but fo
On 21/07/2024 23:53, James Almer wrote:
> Signed-off-by: James Almer
> ---
> configure | 3 +
> doc/general_contents.texi | 13 ++
> libavcodec/Makefile | 1 +
> libavcodec/lcevcdec.c | 276 ++
> libavcodec/lcevcdec.h | 44 ++
On 2024-07-22 01:01 pm, Gyan Doshi wrote:
On 2024-07-22 12:53 pm, Shin Han wrote:
Hi
We found a very simple typo in the libvmaf_cuda section of doc/filters
where the order of the [dis] and [ref] labels is reversed.
We believe fixing this typo would be benefical of those who are new to
usin
That variable is shared between frame threads in the same defective way
described in the previous commit. Fix it by adding a RefStruct-managed
arrays of flags that is propagated across frame threads in the standard
manner.
Remove now-unused FFV1Context.fsrc
---
libavcodec/ffv1.c| 2 ++
libav
There is no reason to delay it and this is a more natural place for
this code.
---
libavcodec/ffv1dec.c | 53 ++--
1 file changed, 27 insertions(+), 26 deletions(-)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index aa2c35880e..5821a4156a 100644
No paletted pixel formats are supported by the decoder.
---
libavcodec/ffv1dec.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 7dc4a537a9..aa2c35880e 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -981,10
On Sat, Jul 20, 2024 at 10:19:18AM -0400, Aaron wrote:
> On Fri, Jul 19, 2024 at 07:54:37PM -0400, Peter Ross wrote:
>
> > can you post a sample file somewhere
>
> Of course. Here are some you can try out:
>
> gm_us.wve: (Stereo - 15 FPS) https://0x0.st/X97A.wve
> gm_sp.wve: (Stereo - 15 FPS) h
On 22 Jul 2024, at 0:47, gnattu via ffmpeg-devel wrote:
> The __builtin_available function does not do compile time check
> for the availablity of the CVBufferCopyAttachments function
> which will fail the build. Check the availability during configure.
>
> Signed-off-by: Gnattu OC
> ---
> con
On 2024-07-22 12:53 pm, Shin Han wrote:
Hi
We found a very simple typo in the libvmaf_cuda section of doc/filters
where the order of the [dis] and [ref] labels is reversed.
We believe fixing this typo would be benefical of those who are new to
using ffmpeg and libvmaf_cuda.
Will apply.
Tha
Hi
We found a very simple typo in the libvmaf_cuda section of doc/filters
where the order of the [dis] and [ref] labels is reversed.
We believe fixing this typo would be benefical of those who are new to
using ffmpeg and libvmaf_cuda.
Thanks
BR
Han Shin
>From 860ce5a597d1999d555ee8d8cf1eb76a
50 matches
Mail list logo
