Hi, good day,
I think something is wrong with this v2 patch, it is showing as corrupt in
the patchwork system.
See here:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/69b8a7a5-3826-4aef-88e1-2984d61a5...@skybound.link/
By chance did you modify the .patch file directly?
I found that the subject for this v5 set of patches was wrong.
I have posted the v6 with the correction.
> On Aug 1, 2024, at 10:58, WATANABE Osamu
> wrote:
>
> According to the suggestions for v4, I have posted the patch set v5.
>
> It is confirmed that the decoder with v5 passes all the conf
This commit adds support for placeholder pass parsing.
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000.h | 2 +
libavcodec/jpeg2000dec.c | 352 +
libavcodec/jpeg2000htdec.c | 90 +-
3 files changed, 326 insertions(+), 118 deletions(-)
This commit fixes wrong treatment of MAGBP value in Ccap15 and bugs in HT block
decoding.
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000dec.c | 11 +--
libavcodec/jpeg2000htdec.c | 136 ++---
libavcodec/jpeg2000htdec.h | 2 +-
3 files changed, 89 inse
This commit adds support for CAP and CPF markers. Decoder will exit when
encountering an illegal codestream.
It is confirmed that the decoder passes all the test cases in FATE and
ISO/IEC 15444-4.
The subject was wrong in the v5 set of patches. The v6 corrects it.
Signed-off-by: Osamu Watanabe
Signed-off-by: James Almer
---
tests/fate/mov.mak | 11 +
tests/ref/fate/mov-mp4-iamf-5_1_4-h264 | 568 +
2 files changed, 579 insertions(+)
create mode 100644 tests/ref/fate/mov-mp4-iamf-5_1_4-h264
diff --git a/tests/fate/mov.mak b/tests/fate/mov.ma
Fixes crashes when muxing video tracks alongside IAMF ones.
Signed-off-by: James Almer
---
libavformat/movenc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index ae49582a1a..87ec368d52 100644
--- a/libavformat/movenc
According to the suggestions for v4, I have posted the patch set v5.
It is confirmed that the decoder with v5 passes all the conformance testing
defined in ISO/IEC 15444-4.
Best,
Osamu
> On Jul 31, 2024, at 6:39, Michael Niedermayer wrote:
>
> On Tue, Jul 30, 2024 at 10:22:37PM +0200, Tomas
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000dec.c | 11 +--
libavcodec/jpeg2000htdec.c | 136 ++---
libavcodec/jpeg2000htdec.h | 2 +-
3 files changed, 89 insertions(+), 60 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000.h | 2 +
libavcodec/jpeg2000dec.c | 352 +
libavcodec/jpeg2000htdec.c | 90 +-
3 files changed, 326 insertions(+), 118 deletions(-)
diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000.h| 8 +++
libavcodec/jpeg2000dec.c | 128 ++-
libavcodec/jpeg2000dec.h | 7 +++
3 files changed, 142 insertions(+), 1 deletion(-)
diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index d00
Niklas Haas:
> From: Niklas Haas
>
> This replaces the myriad of existing lists in AVCodec by a unified API
> call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite
> substantially, while also making this more trivially extensible.
>
> In addition to the already covered lists, add
On Mon, 13 Nov 2023 at 09:40, Adrien Guinet wrote:
>
> This commit introduces new options to support more than one decryption
> keys:
> * add a decryption_keys option to MOV, that supports a dictionnary of
> KID=>key (in hex), using AV_OPT_TYPE_DICT
> * add the corresponding cenc_decryption_keys
On Wed, Jul 31, 2024 at 2:29 PM Dale Curtis wrote:
> On Wed, Jul 31, 2024 at 2:10 PM Dale Curtis
> wrote:
>
>> On Wed, Jul 31, 2024 at 4:32 AM Anton Khirnov wrote:
>>
>>> Quoting Dale Curtis (2024-07-31 01:14:13)
>>> > I realized there are a couple more allocations that can be skipped here
>>>
On 7/31/2024 4:54 PM, Michael Niedermayer wrote:
Fixes: division by zero
Fixes:
70561/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-6199435013455872
Fixes:
70565/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5783790316748800
Found-by: continuous fuzzing process
https://github
On 7/31/2024 4:54 PM, Michael Niedermayer wrote:
Fixes:
70458/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5259339779080192
Fixes: Assertion width > 0 && width <= 32 failed at libavcodec/cbs.c:608
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/ma
On Wed, Jul 31, 2024 at 2:10 PM Dale Curtis wrote:
> On Wed, Jul 31, 2024 at 4:32 AM Anton Khirnov wrote:
>
>> Quoting Dale Curtis (2024-07-31 01:14:13)
>> > I realized there are a couple more allocations that can be skipped here
>> > when a codec is not on the allow list. Here's the updated pat
On Wed, Jul 31, 2024 at 4:32 AM Anton Khirnov wrote:
> Quoting Dale Curtis (2024-07-31 01:14:13)
> > I realized there are a couple more allocations that can be skipped here
> > when a codec is not on the allow list. Here's the updated patch.
> >
> > - dale
> >
> > On Mon, Jul 29, 2024 at 10:19 AM
On Wed, Jul 31, 2024 at 09:54:10PM +0200, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes:
> 70741/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5703668010647552
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffm
These are really just wrappers for idct4_add16intra functions, which are in
turn mostly wrappers for idct4_add and idct4_dc_add functions.
For benchmarks refer to the later two sets.
---
libavcodec/riscv/h264dsp_init.c | 24 ++--
libavcodec/riscv/h264idct_rvv.S | 97 ++
Fixes: out of array access
Fixes:
70741/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5703668010647552
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/snow.c | 2 +-
1 file cha
The snow encoder uses block based motion estimation which can read out of array
if
insufficient alignment is used
It may be better to only apply this for the encoder, as it would safe a few
bytes of memory
for the decoder. Until then, this fixes the issue in a simple way.
Fixes: out of array ac
Fixes: out of array access
Fixes:
70734/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-4741427068731392
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/aac/aacdec_usac.c | 4
Fixes: division by zero
Fixes:
70561/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-6199435013455872
Fixes:
70565/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5783790316748800
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Si
Fixes: Assertion 0 failed at libavcodec/aac/aacdec_usac.c:1646
Fixes:
70541/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-5190889543106560
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
-
Fixes:
70458/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5259339779080192
Fixes: Assertion width > 0 && width <= 32 failed at libavcodec/cbs.c:608
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niederm
On Mon, Jul 15, 2024 at 03:59:12PM +0200, Michael Niedermayer wrote:
> On Tue, Jun 18, 2024 at 07:28:18PM +0200, Andreas Rheinhardt wrote:
> > Michael Niedermayer:
> > > The snow encoder uses block based motion estimation which can read out of
> > > array if
> > > insufficient alignment is used
>
Le keskiviikkona 31. heinäkuuta 2024, 13.36.00 EEST flow gg a écrit :
> I'm a bit confused because the calculation here goes up to 32 bits and then
> returns to 8 bits. It seems that the vmax and vnclipu instructions can't be
> removed by using round-related instructions？
You seem to be adding 64
This is really just a wrapper for idct4_add16intra, which is in turm mostly
a wrapper for idct4_add and idct4_dc_add.
For benchmarks refer to the later two.
---
libavcodec/riscv/h264dsp_init.c | 14 ++--
libavcodec/riscv/h264idct_rvv.S | 59 +
2 files changed,
Thank you for the detailed explanation. One more question: I understand
that assembly code needs to be further broken down, but what's the issue
with adding this code to the init section of the C code here? I think this
C code is just mimicking the init section of the C code in x86.
Rémi Denis-Cou
On 2024/07/31 5:44, Michael Niedermayer wrote:
On Mon, Jul 29, 2024 at 01:30:34AM +0900, TADANO Tokumei wrote:
On 2024/07/28 18:26, Michael Niedermayer wrote:
On Sun, Jul 28, 2024 at 01:42:09AM +0900, TADANO Tokumei wrote:
On 2024/07/27 13:30, TADANO Tokumei wrote:
Add an OpenCL filter for f
---
libavutil/riscv/intmath.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/riscv/intmath.h b/libavutil/riscv/intmath.h
index 24f165eef1..a09248f903 100644
--- a/libavutil/riscv/intmath.h
+++ b/libavutil/riscv/intmath.h
@@ -84,8 +84,8 @@ static av_always_inline
Fixes relevant warnings when compiling with --enable-hardcoded-tables
Signed-off-by: James Almer
---
libavcodec/aacps_tablegen_template.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/aacps_tablegen_template.c
b/libavcodec/aacps_tablegen_template.c
index e70edf884b..e05887b9b
Le tiistaina 30. heinäkuuta 2024, 20.57.28 EEST flow gg a écrit :
> From my understanding, moving from supporting only 128b to adding 256b
> versions can simultaneously improve LMUL and solve some issues related to
> insufficient vector registers (vvc, vp9).
To the contrary, if vectors are too sho
Should fix ticket #5.
Signed-off-by: James Almer
---
Untested.
libavutil/hwcontext_vaapi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 4cb25dd032..15fd84aa40 100644
--- a/libavutil/hwcontext_vaapi.c
+++
On Wed, Jul 31, 2024 at 01:26:23PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-07-24 20:44:50)
> > On Tue, Jul 16, 2024 at 07:11:48PM +0200, Anton Khirnov wrote:
> > > Reorganize the code such that the frame threading code does not call the
> > > decoders directly, but instead c
This puts lavu frame buffer allocator helpers in sync with lavc's decoder frame
buffer allocator's STRIDE_ALIGN define.
Remove the comment about av_cpu_max_align() while at it as using it is not
ideal when CPU flags can be changed mid process.
Should fix ticket #6.
Signed-off-by: James Almer
On Wed, Jul 31, 2024 at 10:50:11AM +0200, Anton Khirnov wrote:
> All remaining accesses to them are for fields that have the same value
> in the main encoder context.
> ---
> libavcodec/ffv1enc.c | 55 +--
> libavcodec/ffv1enc_template.c | 29 +-
On Wed, Jul 31, 2024 at 10:33:09AM +0200, Anton Khirnov wrote:
> It cannot change between slices.
> ---
> libavcodec/ffv1.c | 6 +++---
> libavcodec/ffv1dec.c | 19 +--
> libavcodec/ffv1dec_template.c | 14 --
> libavcodec/ffv1enc.c | 11 +
On Sun, 28 Jul 2024 12:25:06 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> ---
> libavutil/dovi_meta.h | 28 +++-
> 1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
> index c942d0e133..5e8a1e43d7 100644
Quoting Dale Curtis (2024-07-31 01:14:13)
> I realized there are a couple more allocations that can be skipped here
> when a codec is not on the allow list. Here's the updated patch.
>
> - dale
>
> On Mon, Jul 29, 2024 at 10:19 AM Dale Curtis
> wrote:
>
> > This ensures that if a codec isn't on
Quoting Michael Niedermayer (2024-07-24 20:44:50)
> On Tue, Jul 16, 2024 at 07:11:48PM +0200, Anton Khirnov wrote:
> > Reorganize the code such that the frame threading code does not call the
> > decoders directly, but instead calls back into the generic decoding
> > code. This avoids duplicating t
On Tue, Jul 30, 2024 at 03:05:22PM +0200, Ramiro Polla wrote:
> On Tue, Jul 23, 2024 at 2:46 PM Ramiro Polla wrote:
> > This will be used in the upcoming yuv42{0,2}p -> gbrp unscaled
> > colorspace converters.
>
> ping on this patchset.
Maybe you can add benchmarks to things changing performance
I'm a bit confused because the calculation here goes up to 32 bits and then
returns to 8 bits. It seems that the vmax and vnclipu instructions can't be
removed by using round-related instructions？
Rémi Denis-Courmont 于2024年7月29日周一 23:21写道：
> Le tiistaina 23. heinäkuuta 2024, 11.51.48 EEST u...@f
The specification says that if either the numerator or the
denominator is zero then the SAR is to be intended unspecified.
Internally ffmpeg represents an unspecified SAR as 0/1, while
fractions with a zero denominator are not handled properly;
so we bridge the gap by replacing x/0 with 0/1.
Signe
Hi,
Il 30/07/24 22:54, michael at niedermayer.cc (Michael Niedermayer) ha
scritto:
Why does playback fail ? > 1/1 and unspecified are different things, 0/0 would
be unspecified
where does 20480/0 turn into 20480/1 ? or did i misunderstand this?
It seems that denominator 0 is replaced with 1
All remaining accesses to them are for fields that have the same value
in the main encoder context.
---
libavcodec/ffv1enc.c | 55 +--
libavcodec/ffv1enc_template.c | 29 +-
2 files changed, 41 insertions(+), 43 deletions(-)
diff --git a/li
It cannot change between slices.
---
libavcodec/ffv1.c | 6 +++---
libavcodec/ffv1dec.c | 19 +--
libavcodec/ffv1dec_template.c | 14 --
libavcodec/ffv1enc.c | 11 ++-
libavcodec/ffv1enc_template.c | 12 +++-
5 files change
48 matches
Mail list logo
