From: Zhao Zhili
There are two issues here. Firstly, the floating-point comparison
is always true. Seconly, the code depends on the default value of
min_hard_comp implicitly, which can be dangerous.
Partially fixes ticket 9859.
---
fftools/ffmpeg_filter.c | 3 +--
1 file changed, 1 insertion(+)
On Tue, 13 Sep 2022, Hubert Mazur wrote:
Provide optimized implementation for pix_median_abs16 function.
Forgot to update this part of the commit message here too.
Performance comparison tests are shown below.
- median_sad_1_c: 273.7
- median_sad_1_neon: 98.2
Benchmarks and tests run with c
On Tue, 13 Sep 2022, Hubert Mazur wrote:
Provide optimized implementation for pix_median_abs16 function.
You've forgot to update this part of the commit message.
Performance comparison tests are shown below.
- vsad_5_c: 94.7
- vsad_5_neon: 20.7
Benchmarks and tests run with checkasm tool on
On Tue, 13 Sep 2022, Hubert Mazur wrote:
Provide optimized implementation for pix_median_abs16 function.
Performance comparison tests are shown below.
- median_sad_0_c: 722.0
- median_sad_0_neon: 144.7
Benchmarks and tests run with checkasm tool on AWS Graviton 3.
Signed-off-by: Hubert Mazur
From: Rémi Denis-Courmont
This is no longer used since 46089967722f74e794865a044f5f682f26628802.
It also has no implementations other than the plain C one.
---
libavcodec/fmtconvert.c | 9 -
libavcodec/fmtconvert.h | 10 --
2 files changed, 19 deletions(-)
diff --git a/libavcod
Hi,
On Wed, Sep 14, 2022 at 2:27 PM Kyle Swanson wrote:
> Thanks for the fix, I will apply this soon.
>
Pushed.
Thanks,
Kyle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
On Fri, Sep 16, 2022 at 1:15 PM Michael Niedermayer
wrote:
>
> On Fri, Sep 16, 2022 at 10:39:22AM -0700, Pierre-Anthony Lemieux wrote:
> > On Fri, Sep 16, 2022 at 10:27 AM Michael Niedermayer
> > wrote:
> > >
> > > On Wed, Sep 07, 2022 at 01:02:33PM -0700, p...@sandflow.com wrote:
> > > > From: P
On Fri, Sep 16, 2022 at 10:39:22AM -0700, Pierre-Anthony Lemieux wrote:
> On Fri, Sep 16, 2022 at 10:27 AM Michael Niedermayer
> wrote:
> >
> > On Wed, Sep 07, 2022 at 01:02:33PM -0700, p...@sandflow.com wrote:
> > > From: Pierre-Anthony Lemieux
> > >
> > > Addresses coverity 1512414
> > >
> > >
---
tests/fate/flac.mak | 4
1 file changed, 4 insertions(+)
diff --git a/tests/fate/flac.mak b/tests/fate/flac.mak
index 115cc965e1..3424b2bf82 100644
--- a/tests/fate/flac.mak
+++ b/tests/fate/flac.mak
@@ -6,6 +6,7 @@ FATE_FLAC += fate-flac-16-chmode-indep
Add encoding of 32 bit-per-sample PCM to FLAC files to libavcodec.
Coding to this format is at this point considered experimental and
-strict experimental is needed to get ffmpeg to encode such files.
---
libavcodec/flacenc.c| 518
libavcodec/put_bits.h
Add decoding of FLAC files coding for 32 bit-per-sample PCM to libavcodec.
---
libavcodec/flac.c | 4 +-
libavcodec/flacdec.c | 250 ++
libavcodec/get_bits.h | 12 ++
libavcodec/mathops.h | 9 ++
4 files changed, 251 insertions(+), 24 deletions(-)
Recently libFLAC gained the ability (first released in FLAC 1.4.0)
to create FLAC files containing 32-bit int PCM samples. To
keep complexity reasonable, the choice was made to limit residuals
to 32-bit integers, which the encoder must make sure of. In case
the encoder cannot find any predictor of
Op do 15 sep. 2022 om 21:52 schreef Martijn van Beurden :
> Op do 15 sep. 2022 om 20:20 schreef Andreas Rheinhardt <
> andreas.rheinha...@outlook.com>:
>
>> (In any case, I don't get why there are two samples: The flac decoder is
>> intra-only, so if you made the samples so that one of the frames
On Fri, Sep 16, 2022 at 10:39 AM Pierre-Anthony Lemieux
wrote:
>
> On Fri, Sep 16, 2022 at 10:27 AM Michael Niedermayer
> wrote:
> >
> > On Wed, Sep 07, 2022 at 01:02:33PM -0700, p...@sandflow.com wrote:
> > > From: Pierre-Anthony Lemieux
> > >
> > > Addresses coverity 1512414
> > >
> > > ---
>
On Fri, Sep 16, 2022 at 02:33:02PM -0400, Scott Theisen wrote:
> Ping. Still applies cleanly.
iam not against this but iam also not really sure i prefer the new
code.
Maybe other people have a clearer opinion ...
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0
r...@remlab.net:
> From: Rémi Denis-Courmont
>
> This is not used anywhere and has no implementations other than the
> plain C one.
> ---
> libavcodec/fmtconvert.c | 9 -
> libavcodec/fmtconvert.h | 10 --
> 2 files changed, 19 deletions(-)
>
> diff --git a/libavcodec/fmtconver
From: Rémi Denis-Courmont
This is not used anywhere and has no implementations other than the
plain C one.
---
libavcodec/fmtconvert.c | 9 -
libavcodec/fmtconvert.h | 10 --
2 files changed, 19 deletions(-)
diff --git a/libavcodec/fmtconvert.c b/libavcodec/fmtconvert.c
index f
On Sun, Sep 11, 2022 at 04:27:21PM +0200, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 50955/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5148704872464384
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Si
On Sun, Sep 11, 2022 at 04:27:20PM +0200, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes:
> 50936/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HDR_fuzzer-5423041009549312
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmp
Ping. Still applies cleanly.
On 5/15/22 16:18, Scott Theisen wrote:
switch-case over es_type and then perform a linear search over
startcode.
---
This version doesn't use stdbool.h but is otherwise identical.
libavformat/mpeg.c | 213 +++--
1 file chan
On 9/16/22 14:19, Scott Theisen wrote:
My modified versions of avpriv_find_start_code were accepted into MythTV,
which caused clang-tidy to raise a bugprone-branch-clone warning. The
for loop's if statement has therefore been modified to not duplicate
This should say while loop.
the branch p
The input/output functionality was used by only
(ff_)mpeg1_find_frame_end().
If the state/start_code input is a local variable and only one buffer is used,
then no history is needed.
In loops and inline functions: if ignoring history, don't initialize start_code,
so it isn't reset twice each time
Have the compiler enforce not changing the addresses these parameters point to.
No functional change.
---
libavcodec/utils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 63bf4b8cb7..0635c5dcaa 100644
--- a/libavcodec/utils.c
---
libavcodec/mpeg12dec.c | 2 +-
libavformat/rtpenc_mpv.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index b857353ab8..6a7af91fad 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1746,7 +1746,7 @@
---
libavcodec/startcode.h | 26 +-
libavcodec/utils.c | 10 +-
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/libavcodec/startcode.h b/libavcodec/startcode.h
index 833754af09..69389c729c 100644
--- a/libavcodec/startcode.h
+++ b/libavcodec/star
---
libavcodec/utils.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index fc8cd87366..83f7d8a01a 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -983,18 +983,20 @@ const uint8_t *avpriv_find_start_code(const
The expected number of iterations may increase by one for an input
of alternating 0 and 1 bytes. Instead of incrementing by 2 everytime,
it now alternates between incrementing by 1 and by 3.
For the check p[-2] != 0:
This slightly reduces the number of iterations by starting with three
new bytes
No functional change.
---
libavcodec/utils.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 2f57418ff7..d6ab21b1a0 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1006,10 +1006,11 @@ const uint8_t *avpriv_find
This slightly changes what is considered valid in the following cases:
cavsdec.c: 0x00XX is now considered invalid.
mpeg12dec.c: 0x00XX is now considered invalid.
(where X is any value)
IS_MARKER is equivalent since VC1_CODE_RES0 = 0x0100
---
libavcodec/cavsdec.c | 2
My modified versions of avpriv_find_start_code were accepted into MythTV,
which caused clang-tidy to raise a bugprone-branch-clone warning. The
for loop's if statement has therefore been modified to not duplicate
the branch payload.
There are no other changes from v3.
Regards,
Scott Theisen
On Sun, Sep 11, 2022 at 12:30:42AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -2147448926 + -198321 cannot be represented
> in type 'int'
> Fixes:
> 48798/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5739619273015296
> Fixes:
> 48798/clusterfuzz-testcase-
On Sun, Sep 11, 2022 at 12:30:46AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -8427924 * 256 cannot be represented in type
> 'int'
> Fixes:
> 48798/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TTA_fuzzer-5409428670644224
>
> Found-by: continuous fuzzing process
> h
On Sun, Sep 11, 2022 at 12:30:45AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 127 + 2147483536 cannot be represented in
> type 'int'
> Fixes:
> 48798/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-6014034970804224
>
> Found-by: continuous fuzzing proce
On Sun, Sep 11, 2022 at 12:30:44AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 17121181824 * 538976288 cannot be represented
> in type 'long long'
> Fixes:
> 48798/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5915330316206080
>
> Found-by: continuous fuzzi
On Fri, Sep 16, 2022 at 05:13:46PM +0200, Paul B Mahol wrote:
> lgtm
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
signature.
Ping; it still applies cleanly.
-Scott Theisen
On 5/15/22 14:50, Scott Theisen wrote:
Ping; it still applies cleanly.
-Scott Theisen
On 2/8/22 15:32, Scott Theisen wrote:
Also add a few clarifying comments.
---
libavcodec/cbs_mpeg2.c | 16
1 file changed, 8 insertions(+),
On Fri, Sep 09, 2022 at 06:02:36PM +0800, Shiyou Yin wrote:
>
>
> > 2022年9月9日 17:41，Hao Chen 写道：
> >
> > v2: Modifies the format of the Commit message.
> >
> > [PATCH v2 1/2] lavc/mips: Fix bugs in me_cmp_msa.c file.
> > [PATCH v2 2/2] lavc/mips: Fix hevc decoding bugs on MIPS paltform.
> >
>
On Fri, Sep 16, 2022 at 10:27 AM Michael Niedermayer
wrote:
>
> On Wed, Sep 07, 2022 at 01:02:33PM -0700, p...@sandflow.com wrote:
> > From: Pierre-Anthony Lemieux
> >
> > Addresses coverity 1512414
> >
> > ---
> > libavformat/imfdec.c | 15 ---
> > 1 file changed, 12 insertions(+),
printf %s with a NULL pointer is undefined behavior. Not returning
a NULL pointer makes for a nicer function for API users, including
in FFmpeg, since then you don't have to check it, instead you can
just print it. 32/44 uses in FFmpeg did not check for NULL.
This also matches behavior with avco
On Wed, Sep 07, 2022 at 01:02:33PM -0700, p...@sandflow.com wrote:
> From: Pierre-Anthony Lemieux
>
> Addresses coverity 1512414
>
> ---
> libavformat/imfdec.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
lgtm
___
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 with subject "unsubscribe".
On 9/15/2022 10:16 PM, James Almer wrote:
On 9/15/2022 10:10 PM, Andreas Rheinhardt wrote:
Signed-off-by: Andreas Rheinhardt
---
Maybe use av_channel_layout_check?
libavcodec/decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode
Up until now, libswscale/output.c used a macro to write
an output pixel which involved a call to av_pix_fmt_desc_get()
to find out whether the input pixel format is BE or LE
despite this being known at compile-time (there are templates
per pixfmt). Even worse, these calls are made in a loop,
so tha
Up until now, libswscale/input.c used a macro to read
an input pixel which involved a call to av_pix_fmt_desc_get()
to find out whether the input pixel format is BE or LE
despite this being known at compile-time (there are templates
per pixfmt). Even worse, these calls are made in a loop,
so that e
This block was scheduled for removal, which means that no validation would have
taken place after the old API was removed.
It was algo going to mistakenly remove an unrelated bits_per_coded_sample
check.
Signed-off-by: James Almer
---
libavcodec/avcodec.c | 22 --
1 file chan
This block was scheduled for removal, which means that no validation would have
taken place after the old API was removed.
It was algo going to mistakenly remove an unrelated bits_per_coded_sample
check.
Signed-off-by: James Almer
---
libavcodec/avcodec.c | 22 --
1 file chan
On Thu, Sep 15, 2022 at 03:46:28PM -0700, p...@sandflow.com wrote:
> From: Pierre-Anthony Lemieux
>
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ed2ec0b90c..2d37f0b86a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -436,6
On Fri, Sep 16, 2022 at 09:00:24AM +0200, Anton Khirnov wrote:
> Quoting Andreas Rheinhardt (2022-09-09 20:15:22)
> > Michael Niedermayer:
> > > On Thu, Sep 08, 2022 at 11:44:51PM +0200, Andreas Rheinhardt wrote:
> > >> Michael Niedermayer:
> > >>> On Thu, Sep 08, 2022 at 09:38:51PM +0200, Andreas
> From: Wang Yaqiang
>
> When determining whether a packet should be decrypted,
> should use the stsd_id of the fragment where the current packet is located.
>
> Signed-off-by: Wang Yaqiang
> ---
> libavformat/isom.h | 1 +
> libavformat/mov.c | 7 ---
> 2 files changed, 5 insertions(+)
On 9/8/22, Andreas Rheinhardt wrote:
> Up until now, libswscale/output.c used a macro to write
> an output pixel which involved a call to av_pix_fmt_desc_get()
> to find out whether the input pixel format is BE or LE
> despite this being known at compile-time (there are templates
> per pixfmt). Ev
>Envoyé : mardi 13 septembre 2022 23:31
>Mantissas are the last data in the channel subsegment and it appears it is
>sometimes missing a very few bits for the parsing to complete.
>This should not be confused with data corruption.
Here is a very short sample set with an audacity screen grab which
On 9/16/22, Andreas Rheinhardt wrote:
> Possible since 9325d88eba8038b3e2a4485e473a018410379e2d.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/adx.c| 52 --
> libavcodec/adxdec.c | 68 +++--
> 2 files changed,
On 9/16/22, Andreas Rheinhardt wrote:
> Obsolete since b024209b1fe57b7902d30a8e0d38f5ecb628e6f3.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
LGTM
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 0b4
Obsolete since b024209b1fe57b7902d30a8e0d38f5ecb628e6f3.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 0b46bc0173..8a7b6d522a 100644
--- a/libavcodec/Makefile
+++ b/lib
Possible since 9325d88eba8038b3e2a4485e473a018410379e2d.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/adx.c| 52 --
libavcodec/adxdec.c | 68 +++--
2 files changed, 60 insertions(+), 60 deletions(-)
diff --git a/lib
Quoting Andreas Rheinhardt (2022-09-09 20:15:22)
> Michael Niedermayer:
> > On Thu, Sep 08, 2022 at 11:44:51PM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> On Thu, Sep 08, 2022 at 09:38:51PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > [...]
> >>> To me if i
56 matches
Mail list logo
