The code predates ff_vk_get_pooled_buffer().
---
libavcodec/vulkan_decode.c | 47 +++---
libavcodec/vulkan_decode.h | 2 +
libavcodec/vulkan_video.c | 82 --
libavcodec/vulkan_video.h | 7
4 files changed, 34 insertions(+), 104 deletions
Quoting Michael Niedermayer (2024-07-17 23:20:19)
> On Tue, Jul 16, 2024 at 07:11:46PM +0200, Anton Khirnov wrote:
> > Makes sure discarded frames do not cause EAGAIN to be returned during
> > flushing, which is forbidden.
> > ---
> > libavcodec/decode.c | 11 ---
> > 1 file changed, 8 ins
Quoting Michael Niedermayer (2024-07-18 00:32:38)
> the data for each decoder task should be together and not scattered around
> more than needed, reducing cache efficiency
>
> putting all this extra code in the inner per pixel loop is not ok
> especially not for the sake of avoiding a memcpy of a
Quoting Michael Niedermayer (2024-07-18 00:37:25)
> On Tue, Jul 16, 2024 at 07:11:27PM +0200, Anton Khirnov wrote:
> > In all cases except decoding version 1 it's either not used, or contains
> > a copy of a table from quant_tables, which we can just as well use
> > directly.
> >
> > When decoding
On Fri, 12 Jul 2024, Leo Izen wrote:
Indexed color images use three colors for sBIT, but the function
ff_png_get_nb_channels returns 1 in this case. We should avoid erroring
out on valid files in this scenario.
Please mention that this is a regression since
84b454935fae2633a8a5dd075e22393f
Quoting Michael Niedermayer (2024-07-18 00:42:05)
> all the stuff should be put together close so its efficiently
> using CPU caches
Which is why it shares its cacheline with PutBitContext, because the
code benefits from having the both in the cache, right? And the 4-byte
hole in PutBitContext is
On Tue, 16 Jul 2024, Andrew Sayers wrote:
I'm having trouble managing this conversation. On one hand, you've brought up
several important details that would need to be included in a new patch.
On the other hand, I'm pretty sure we're talking past each other on the big
problems, and need to s
Hello,
I adressed the issues/concerns that were raised with the first revision
of the patch.
Any feedback? Did I do something wrong?
Best regards
Stefan
Am 06.07.24 um 23:08 schrieb Stefan Oltmanns via ffmpeg-devel:
Hello,
this is revised patch, to sum up the changes:
The current VapourSynt
Quoting James Almer (2024-07-18 04:03:30)
> Signed-off-by: James Almer
> ---
> fftools/ffmpeg_demux.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
> index 528e02149f..6f7d78c896 100644
> --- a/fftools/ffmpeg_demux.c
>
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 random access to the video. Also the exact number of
frames of a clip has to be kno
I hadn't noticed av_fourcc2str() before - so long as it's patched to handle "!",
it would be a clear improvement over the earlier patches.
The example in the "!" patch is "BUG!", which is handled in error.c, but shows
that "!" is considered a valid FourCC character.
I think I understand the fate
For example, AVERROR_BUG is "BUG!"
---
libavutil/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/utils.c b/libavutil/utils.c
index 94d247bbee..a94589e873 100644
--- a/libavutil/utils.c
+++ b/libavutil/utils.c
@@ -81,7 +81,7 @@ char *av_fourcc_make_string(char
AVERROR messages should always be less than zero, and are often FourCCs.
For error codes that aren't explicitly handled by error.c (e.g. undocumented
system error codes, or internal error codes that leaked to the public API),
print the FourCC code so the user has a little more information to work
---
tests/fate/source-check.sh | 8
tests/ref/fate/source | 1 +
2 files changed, 9 insertions(+)
diff --git a/tests/fate/source-check.sh b/tests/fate/source-check.sh
index 4d7e175784..71f01cbdec 100755
--- a/tests/fate/source-check.sh
+++ b/tests/fate/source-check.sh
@@ -45,4 +45,1
On Wed, 17 Jul 2024 20:07:54 +0200 Michael Niedermayer
wrote:
> On Tue, Jul 16, 2024 at 01:23:17PM +0200, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > ---
> > fftools/ffprobe.c | 1 +
> > 1 file changed, 1 insertion(+)
>
> breaks fate / needs update to fate
Fixed, thanks for pointing tha
From: Niklas Haas
This field is used to signal the compression method in use.
---
doc/APIchanges| 3 +++
libavutil/dovi_meta.h | 9 +
libavutil/version.h | 2 +-
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 5751216b24..80a
From: Niklas Haas
---
libavformat/dovi_isom.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/libavformat/dovi_isom.c b/libavformat/dovi_isom.c
index d49aa5a75f..269374cff9 100644
--- a/libavformat/dovi_isom.c
+++ b/libavformat/dovi_isom.c
@@ -57,11 +57,1
From: Niklas Haas
---
libavformat/mpegts.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index c66a1ea6ed..6b02187eb1 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2213,10 +2213,12 @@ int ff_parse_mpeg2_
From: Niklas Haas
---
libavformat/dump.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 78b2481d90..5e1f367742 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -416,13 +416,15 @@ static void dump_dovi_conf(void *
From: Niklas Haas
---
fftools/ffprobe.c | 9 +
tests/ref/fate/matroska-dovi-write-config7 | 1 +
tests/ref/fate/matroska-dovi-write-config8 | 1 +
3 files changed, 11 insertions(+)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 0b7d4ce0d7..f9bc830f33 1
Hi Stefan,
On 7/6/24 23:08, Stefan Oltmanns via ffmpeg-devel wrote:
this is revised patch, to sum up the changes:
The current VapourSynth implementation is rarely used, as it links the
VapourSynth library at build time, making the resulting build unable to
run when VapourSynth is not installed.
> On Jul 18, 2024, at 17:26, Marton Balint wrote:
>
>
> On Tue, 16 Jul 2024, Andrew Sayers wrote:
>
>> I'm having trouble managing this conversation. On one hand, you've brought
>> up
>> several important details that would need to be included in a new patch.
>> On the other hand, I'm pret
Quoting Stefan Oltmanns via ffmpeg-devel (2024-07-18 11:37:56)
> Hello,
>
> I adressed the issues/concerns that were raised with the first revision
> of the patch.
> Any feedback? Did I do something wrong?
I dislike the concept in general, not to mention adding unacceptable
global state.
--
Ant
Hi Ramiro,
Am 18.07.24 um 13:08 schrieb Ramiro Polla:
Hi Stefan,
[...]
+
+#include
+
struct VSState {
VSScript *vss;
};
+typedef const VSSCRIPTAPI *(*VSScriptGetAPIFunc)(int version);
+
+typedef struct VSScriptLibrary {
+ void *library;
+ const VSSCRIPTAPI *vssapi;
+} VSScriptL
On 7/18/24 4:47 AM, Marton Balint wrote:
On Fri, 12 Jul 2024, Leo Izen wrote:
Indexed color images use three colors for sBIT, but the function
ff_png_get_nb_channels returns 1 in this case. We should avoid erroring
out on valid files in this scenario.
Please mention that this is a regressio
On Thu, Jul 18, 2024 at 2:48 PM Stefan Oltmanns via ffmpeg-devel
wrote:
> Am 18.07.24 um 13:08 schrieb Ramiro Polla:
> >> [...]
> >> +
> >> +#include
> >> +
> >> struct VSState {
> >> VSScript *vss;
> >> };
> >>
> >> +typedef const VSSCRIPTAPI *(*VSScriptGetAPIFunc)(int version);
> >> +
>
Hi Ramiro,
Am 18.07.24 um 15:04 schrieb Ramiro Polla:
[...]
+static VSScriptLibrary vs_script_library;
Does vs_script_library have to be a global?
I think it has to: ffmpeg allows multiple input files, in case you open
two VapourSynth files you want to load the Library only once.
It sho
On Mon, Jul 15, 2024 at 10:33 PM Tomas Härdin wrote:
>
> fre 2024-07-12 klockan 12:51 -0700 skrev Pierre-Anthony Lemieux:
> > On Thu, Jul 11, 2024 at 10:28 PM Tomas Härdin wrote:
> > >
> > > > +if (s->in_tile_headers == 1 && s->isHT && (!s-
> > > > > Ccap15_b11))
> > > > +
On Thu, Jul 18, 2024 at 3:41 PM Stefan Oltmanns via ffmpeg-devel
wrote:
> Am 18.07.24 um 15:04 schrieb Ramiro Polla:
> [...]
>
> +static VSScriptLibrary vs_script_library;
> >>>
> >>> Does vs_script_library have to be a global?
> >>>
> >>
> >> I think it has to: ffmpeg allows multi
On Thu, Jul 18, 2024 at 12:21:11PM +0200, 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-ac
On Thu, Jul 18, 2024 at 10:20:09AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-07-18 00:32:38)
> > the data for each decoder task should be together and not scattered around
> > more than needed, reducing cache efficiency
> >
> > putting all this extra code in the inner per pix
On Thu, Jul 18, 2024 at 11:08:59AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-07-18 00:42:05)
> > all the stuff should be put together close so its efficiently
> > using CPU caches
>
> Which is why it shares its cacheline with PutBitContext, because the
> code benefits from ha
Am 18.07.24 um 16:21 schrieb Ramiro Polla:
On Thu, Jul 18, 2024 at 3:41 PM Stefan Oltmanns via ffmpeg-devel
wrote:
Am 18.07.24 um 15:04 schrieb Ramiro Polla:
[...]
+static VSScriptLibrary vs_script_library;
Does vs_script_library have to be a global?
I think it has to: ffmpeg allows mu
From: sunyuechi
C908 X60
avg_8_2x2_c:1.21.2
avg_8_2x2_rvv_i32 :0.70.7
avg_8_2x4_c:2.02.0
avg_8_2x4_rvv_i
> Again, I don't think that a maximul multiplier belongs here. If the
calling
> code cannot scale the multiplier up, then it should be a normal loop
providing
> the same code for all VLENs.
I think it's acceptable to add such a parameter, which isn't particularly
common in other files, because thi
Quoting Michael Niedermayer (2024-07-18 16:31:51)
> On Thu, Jul 18, 2024 at 10:20:09AM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-07-18 00:32:38)
> > > the data for each decoder task should be together and not scattered around
> > > more than needed, reducing cache efficiency
On 18 Jul 2024, at 16:21, Ramiro Polla wrote:
> On Thu, Jul 18, 2024 at 3:41 PM Stefan Oltmanns via ffmpeg-devel
> wrote:
>> Am 18.07.24 um 15:04 schrieb Ramiro Polla:
>> [...]
>>
>> +static VSScriptLibrary vs_script_library;
>
> Does vs_script_library have to be a global?
Quoting Michael Niedermayer (2024-07-18 16:48:06)
> On Thu, Jul 18, 2024 at 11:08:59AM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-07-18 00:42:05)
> > > all the stuff should be put together close so its efficiently
> > > using CPU caches
> >
> > Which is why it shares its cac
On Thu, Jul 18, 2024 at 10:20 AM Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-07-18 00:32:38)
> > the data for each decoder task should be together and not scattered
> around
> > more than needed, reducing cache efficiency
> >
> > putting all this extra code in the inner per pixel loo
On Thu, Jul 18, 2024 at 5:31 PM Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-07-18 16:48:06)
> > On Thu, Jul 18, 2024 at 11:08:59AM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2024-07-18 00:42:05)
> > > > all the stuff should be put together close so its efficiently
Quoting Michael Niedermayer (2024-07-18 00:49:41)
> The need for passing an additional pointer around
>
> seems to me a net negative
It makes it explicitly clear which data is per-slice, and which
per-frame/global, which is much harder to figure out with current code.
--
Anton Khirnov
_
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.
Loading the library at runtime makes it so much more useful, because you
can distribute ffmpeg binaries without forcing the user to install
Quoting Paul B Mahol (2024-07-18 17:31:50)
> On Thu, Jul 18, 2024 at 10:20 AM Anton Khirnov wrote:
>
> > Quoting Michael Niedermayer (2024-07-18 00:32:38)
> > > the data for each decoder task should be together and not scattered
> > around
> > > more than needed, reducing cache efficiency
> > >
>
On Thu, Jul 18, 2024 at 12:48 PM Andrew Sayers
wrote:
> For example, AVERROR_BUG is "BUG!"
> ---
> libavutil/utils.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/utils.c b/libavutil/utils.c
> index 94d247bbee..a94589e873 100644
> --- a/libavutil/utils.c
> ++
On Thu, Jul 18, 2024 at 5:43 PM Anton Khirnov wrote:
> Quoting Paul B Mahol (2024-07-18 17:31:50)
> > On Thu, Jul 18, 2024 at 10:20 AM Anton Khirnov
> wrote:
> >
> > > Quoting Michael Niedermayer (2024-07-18 00:32:38)
> > > > the data for each decoder task should be together and not scattered
>
On Thu, Jul 18, 2024 at 05:14:12PM +0200, Anton Khirnov wrote:
[...]
> diff --git a/libavcodec/ffv1dec_template.c b/libavcodec/ffv1dec_template.c
> index 97a28b085a..d68bbda5be 100644
> --- a/libavcodec/ffv1dec_template.c
> +++ b/libavcodec/ffv1dec_template.c
> @@ -30,6 +30,7 @@ RENAME(decode_line)
On Thu, Jul 18, 2024 at 10:20:09AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-07-18 00:32:38)
> > the data for each decoder task should be together and not scattered around
> > more than needed, reducing cache efficiency
> >
> > putting all this extra code in the inner per pix
On Thu, Jul 18, 2024 at 05:36:39PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-07-18 00:49:41)
> > The need for passing an additional pointer around
> >
> > seems to me a net negative
>
> It makes it explicitly clear which data is per-slice, and which
> per-frame/global, which
On Thu, Jul 18, 2024 at 05:31:16PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-07-18 16:48:06)
> > On Thu, Jul 18, 2024 at 11:08:59AM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2024-07-18 00:42:05)
[...]
> > >
> > > Another factor that matters in efficient ca
T-Head C908 (cycles):
h264_idct4_dc_add_8bpp_c:94.7
h264_idct4_dc_add_8bpp_rvv_i32: 55.0 (before)
h264_idct4_dc_add_8bpp_rvv_i32: 34.5 (after)
h264_idct4_dc_add_9bpp_c:94.7
h264_idct4_dc_add_9bpp_rvv_i32: 43.5 (before)
h264_idct4_dc_add_9bpp_rvv_i32: 38.2 (after)
h264_idct4_dc_a
---
libavcodec/riscv/h264idct_rvv.S | 108 ++--
1 file changed, 18 insertions(+), 90 deletions(-)
diff --git a/libavcodec/riscv/h264idct_rvv.S b/libavcodec/riscv/h264idct_rvv.S
index 48de65ec0b..505f491308 100644
--- a/libavcodec/riscv/h264idct_rvv.S
+++ b/libavcodec/r
From: "J. Dekker"
No functional changes. This just moves the assembler so that it can be
referenced by other functions in h264idct_rvv.S with local jumps.
Edited-by: Rémi Denis-Courmont
---
libavcodec/riscv/h264dsp_rvv.S | 103 ---
libavcodec/riscv/h264idct_rvv.S |
This reuses the DC bypass functions from the multiple IDCT functions, to
leverage vector code.
As an added bonus, the caller functions can now rely on the callee functions
to preserve their parameters, thus cutting down on stack spills.
---
libavcodec/riscv/h264idct_rvv.S | 76 +++
---
libavcodec/riscv/h264idct_rvv.S | 100 ++--
1 file changed, 45 insertions(+), 55 deletions(-)
diff --git a/libavcodec/riscv/h264idct_rvv.S b/libavcodec/riscv/h264idct_rvv.S
index c42db6ef29..c74ea18c19 100644
--- a/libavcodec/riscv/h264idct_rvv.S
+++ b/libavcodec/r
Fixes: MemLeak
Fixes:
69853/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-4660448545275904
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions(+)
Fixes: out of array read
Fixes: poc3
Reported-by: VulDB CNA Team
Signed-off-by: Michael Niedermayer
---
libavcodec/pnmdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/pnmdec.c b/libavcodec/pnmdec.c
index a6945549bd5..59013ada495 100644
--- a/libavcodec/pnmdec.
On 7/18/2024 7:16 PM, Michael Niedermayer wrote:
Fixes: MemLeak
Fixes:
69853/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-4660448545275904
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libav
Ensure the values are spec complaint and that no integer overflow can happen.
Signed-off-by: James Almer
---
libavformat/iamf_parse.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c
index a176c7d13a..dd394c
58 matches
Mail list logo
