tis 2024-05-14 klockan 14:28 +0300 skrev Rémi Denis-Courmont:
>
>
> Le 14 mai 2024 10:37:20 GMT+03:00, "Tomas Härdin" a
> écrit :
> > Formal methods would be better than the heuristics coverity uses.
>
> That sounds like wishful thinking, or at least a distant pipe dream.
> Lets stick to what i
Look good to me.
2024-05-08 18:07:49 "yinshiyou-hf" 写道：
> Compile with '--disable-lasx', ‘lumRangeFromJpeg_lasx’ undeclared.
> ---
> libswscale/loongarch/swscale_init_loongarch.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libswscale/loongarch/swscale_init_loongarch.c
> b/libsws
Signed-off-by: Shiqi Zhu
---
libavformat/demux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/demux.c b/libavformat/demux.c
index ecefe7e0a7..e19b8b6473 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -1112,7 +1112,7 @@ static void compute_pkt_fiel
>-Original Message-
>From: ffmpeg-devel On Behalf Of Mark
>Thompson
>Sent: Wednesday, May 15, 2024 3:56 AM
>To: ffmpeg-devel@ffmpeg.org
>Subject: Re: [FFmpeg-devel] [PATCH v8 01/15] avcodec/vaapi_encode:
>introduce a base layer for vaapi encode
>
>On 18/04/2024 09:58, tong1.wu-at-intel
>-Original Message-
>From: ffmpeg-devel On Behalf Of Mark
>Thompson
>Sent: Wednesday, May 15, 2024 4:47 AM
>To: ffmpeg-devel@ffmpeg.org
>Subject: Re: [FFmpeg-devel] [PATCH v8 05/15] avcodec/vaapi_encode: move
>the dpb logic from VAAPI to base layer
>
>On 18/04/2024 09:58, tong1.wu-at-intel
>-Original Message-
>From: ffmpeg-devel On Behalf Of Mark
>Thompson
>Sent: Wednesday, May 15, 2024 4:56 AM
>To: ffmpeg-devel@ffmpeg.org
>Subject: Re: [FFmpeg-devel] [PATCH v8 06/15] avcodec/vaapi_encode: extract
>the init function to base layer
>
>On 18/04/2024 09:59, tong1.wu-at-intel
>-Original Message-
>From: ffmpeg-devel On Behalf Of Mark
>Thompson
>Sent: Wednesday, May 15, 2024 5:06 AM
>To: ffmpeg-devel@ffmpeg.org
>Subject: Re: [FFmpeg-devel] [PATCH v8 11/15] avcodec/vaapi_encode: extract a
>get_recon_format function to base layer
>
>On 18/04/2024 09:59, tong1.wu-at
Shiqi Zhu:
> Signed-off-by: Shiqi Zhu
> ---
> libavformat/demux.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/demux.c b/libavformat/demux.c
> index ecefe7e0a7..e19b8b6473 100644
> --- a/libavformat/demux.c
> +++ b/libavformat/demux.c
> @@ -1112,7 +1112,7
Andreas Rheinhardt:
> Forgotten in b314d0685c8c1fbcf8455e59c7f444290c7c.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> tests/checkasm/hevc_add_res.c | 2 +-
> tests/checkasm/hevc_deblock.c | 6 --
> tests/checkasm/hevc_pel.c | 28 ++--
> tests/checkasm/hevc_
Andreas Rheinhardt:
> The only multiplicators used in scalarproduct_and_madd_*
> are -1, 0 and +1. Yet it is of type int and the checkasm
> test uses the complete range of int for it, leading to overflows
> that don't happen for actual users.
>
> Fix this by using a more reasonable range for mul:
Andreas:
>
> Shiqi Zhu:
> > Signed-off-by: Shiqi Zhu
> > ---
> > libavformat/demux.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/demux.c b/libavformat/demux.c
> > index ecefe7e0a7..e19b8b6473 100644
> > --- a/libavformat/demux.c
> > +++ b/libavformat
Signed-off-by: Shiqi Zhu
---
libavformat/demux.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/demux.c b/libavformat/demux.c
index e19b8b6473..74be509c8b 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -856,15 +856,16 @@ static void update_in
Andreas:
>
> Hiccup Zhu:
> > The purpose of this patch is to calculate pts and dts when using pcmdemux.
> > Is there anything wrong with doing this, or do you have any suggestions for
> > improvement?
> >
>
> 1. Don't top-post on this list.
> 2. PTS and DTS are already produced with this demuxer. A
On Wed, May 01, 2024 at 09:10:51PM +, Tom Vaughan wrote:
> When I attempt to pass vbv-end and vbv-end-fr-adj parameters to x265, FFMPEG
> fails.
>
> x265 [error]: vbv-end-fr-adj cannot be enabled when total number of frames is
> unknown
>
> x265 needs to know how many frames it is encoding
Currently, libsvtav1 does not send pass number or stat buffer to SVT-AV1, which
means that 2-pass encoding is not possible using FFMPEG;
if a user wants to do 2-pass encoding using SVT-AV1, they have to use
SvtAv1EncApp.
This patch adds 2-pass encoding support to libsvtav1 using the stats buffers
On 5/15/2024 11:14 AM, Fredrik Lundkvist via ffmpeg-devel wrote:
Currently, libsvtav1 does not send pass number or stat buffer to SVT-AV1, which
means that 2-pass encoding is not possible using FFMPEG;
if a user wants to do 2-pass encoding using SVT-AV1, they have to use
SvtAv1EncApp.
This patc
This version strongly implies AVClass is only used alongside AVOption.
I'm not sure when or if e.g. AVClass::category would be used by an external
API developer, but happy to change the text if anyone has a use case.
I accept the argument that the previous version was linked more widely
than it wa
Derived from detailed explanations kindly provided by Stefano Sabatini:
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325903.html
---
doc/context.md | 394 +
1 file changed, 394 insertions(+)
create mode 100644 doc/context.md
diff --git a/do
---
libavutil/log.h | 11 ---
libavutil/opt.h | 7 ---
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/libavutil/log.h b/libavutil/log.h
index ab7ceabe22..cfbf416679 100644
--- a/libavutil/log.h
+++ b/libavutil/log.h
@@ -59,9 +59,14 @@ typedef enum {
struct AVOptionRa
Some headings needed to be rewritten to accomodate the text,
(hopefully) without changing the meaning.
---
libavcodec/aac/aacdec.h| 2 +-
libavcodec/aacenc.h| 2 +-
libavcodec/ac3enc.h| 2 +-
libavcodec/amfenc.h| 2 +-
libavcodec/atra
Doxygen thinks any text like "Context for foo" is a link to a struct called
"Context".
Add a description and a better link, to avoid confusing readers.
---
libavformat/async.c | 3 +++
libavformat/cache.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/libavformat/async.c b/libavformat/as
Le tiistaina 14. toukokuuta 2024, 20.12.31 EEST Thilo Borgmann via ffmpeg-devel
a écrit :
> ---
> This text including the link is also meant to be published via our socal
> media.
>
> src/index | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/index b/src/index
> index d035ff
On 15/05/2024 17:54, Andrew Sayers wrote:
Some headings needed to be rewritten to accomodate the text,
(hopefully) without changing the meaning.
---
libavcodec/aac/aacdec.h| 2 +-
libavcodec/aacenc.h| 2 +-
libavcodec/ac3enc.h| 2 +-
libavcodec/
---
libavcodec/h264dsp.c | 2 +
libavcodec/h264dsp.h | 2 +
libavcodec/riscv/Makefile| 2 +
libavcodec/riscv/h264dsp_init.c | 40 +++
libavcodec/riscv/startcode_rvb.S | 83
libavcodec/riscv/vc1dsp_init.c | 7 ++-
6
---
libavcodec/riscv/Makefile| 1 +
libavcodec/riscv/h264dsp_init.c | 5
libavcodec/riscv/startcode_rvv.S | 44
libavcodec/riscv/vc1dsp_init.c | 16 +++-
4 files changed, 60 insertions(+), 6 deletions(-)
create mode 100644 libavcodec/risc
Is the test result missing here?
Rémi Denis-Courmont 于2024年5月16日周四 01:11写道：
> ---
> libavcodec/riscv/Makefile| 1 +
> libavcodec/riscv/h264dsp_init.c | 5
> libavcodec/riscv/startcode_rvv.S | 44
> libavcodec/riscv/vc1dsp_init.c | 16 +++---
This calculates the optimal vector type value at run-time based on the
hardware vector length and the FLAC LPC prediction order. In this
particular case, the additional computation is easily amortised over
the loop iterations:
T-Head C908:
C V before V after
1 48.0214.7 95.2
2
On 15.05.24 18:39, Rémi Denis-Courmont wrote:
Le tiistaina 14. toukokuuta 2024, 20.12.31 EEST Thilo Borgmann via ffmpeg-devel
a écrit :
---
This text including the link is also meant to be published via our socal
media.
src/index | 8
1 file changed, 8 insertions(+)
diff --git a/
Le keskiviikkona 15. toukokuuta 2024, 20.33.04 EEST flow gg a écrit :
> Is the test result missing here?
fate-h264 and fate-vc1, yes.
IMO, passing tests is implied and I don't think it worth mentioning.
--
Rémi Denis-Courmont
http://www.remlab.net/
Hi
So as I said in the coverity thread it would be good if we could get at
least part of the codebase covered using formal tools. To this effect I
sat down for an hour just now and gave libavutil/common.h a go with
Frama-C's Eva plugin [1;2]. This plugin performs value analysis, which
is a much si
This is pretty much the same as for lpc16, though it only improves half
as large prediction orders. With 128-bit vectors, this gives:
C V old V new
1 69.2 181.5 95.5
2 107.7 180.7 95.2
3 145.5 180.0 103.5
4 183.0 179.2 102.7
5 220.7 178.5 128.0
6 257.7 194.0 127.5
7
On Wed, May 15, 2024 at 09:39:43PM +0200, Tomas Härdin wrote:
> Hi
>
> So as I said in the coverity thread it would be good if we could get at
> least part of the codebase covered using formal tools. To this effect I
> sat down for an hour just now and gave libavutil/common.h a go with
> Frama-C's
The value was being parsed as base 4, so the value "4" was invalid and
would result in ts_layering_mode being set to 0.
Signed-off-by: Aaron Thompson
---
libavcodec/libvpxenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
ind
> > + ret = av_reallocp(¶m->rc_stats_buffer.buf, param->rc_stats_buffer.sz);
> Why realloc instead of malloc?
As far as I gathered, rc_stats_buffer.buf is already allocated by SVT-AV1; if
malloc is preferred, I can change it and test to make sure it doesn’t cause any
obvious issues.
> Wouldn'
34 matches
Mail list logo
