dont.b...@gmail.com:
>> dont.b...@gmail.com:
>>> From: walle
>>>
>>> lock screen or other permission notification in win7 or
>>> higher windows version would case BitBlt return false,
>>> and gdigrab_read_packet will return AVERROR(EIO) and do nothing to
>>> allocated packet data, then memory leak
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm_data.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/adpcm_data.c b/libavcodec/adpcm_data.c
index e34e04d5e9..768a18a378 100644
--- a/libavcodec/adpcm_data.c
+++ b/libavcodec/adpcm_data.c
@@ -178,10 +178,22 @@ cons
Some DVRs (e.g. D7008FH made by Zhuhai Ltd) output the same format .dav file,
but use ZLAV/zlav tags to delimit the packets instead of DHAV/dhav.
Signed-off-by: Michael Keeley
---
Changelog | 1 +
libavformat/dhav.c| 31 ++-
libavformat/version.h | 2
actually let me just answer what you (moritz) said first.
yes, i specifically meant that. i was talking about MPEG-2 Part 3 and in
particular the multichannel feature that it had.
i just mentioned MPEG-1 Audio Layer I because i haven't seen any encoding tool
for that one yet. it was extensively
alright.
guess i'll just take this to ffmpeg-user then...
___
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 "unsu
Hi Amon,
these are actually good questions for the ffmpeg-user mailing list.
(ffmpeg-devel is for discussion about the actual development of
ffmpeg.)
On Fri, Oct 23, 2020 at 19:09:18 +, Amon Gibson Albuquerque Nunes wrote:
> i wondered what would happen if ffmpeg had actual decoding (and
> enc
The longest code here is 12 bits long and can be read in two attempts.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg4videodec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 95a0e63a29..c26ad616b8 100
Signed-off-by: Andreas Rheinhardt
---
libavcodec/imc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/imc.c b/libavcodec/imc.c
index 6766d53643..70ad5b1dbd 100644
--- a/libavcodec/imc.c
+++ b/libavcodec/imc.c
@@ -110,6 +110,7 @@ typedef struct IMCContext {
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg4videodec.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index c26ad616b8..ff5c6acf67 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@
Signed-off-by: Andreas Rheinhardt
---
libavcodec/atrac3plus.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/libavcodec/atrac3plus.c b/libavcodec/atrac3plus.c
index 8d17889582..6b046a887e 100644
--- a/libavcodec/atrac3plus.c
+++ b/libavcodec/atrac3plus.c
@@ -192,12
Michael Niedermayer:
> Fixes: heap-buffer-overflow
> Fixes:
> 26487/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-5742553675333632
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
>
so, i was researching some MPEG history and i wondered what would happen if
ffmpeg had actual decoding (and encoding) support for MPEG-2 Audio...
no it's not AAC, it's what MPEG has called a "backwards compatible" extension
that "enhances" MPEG-1 audio that allows multichannel encoding of up to 5
Fixes: signed integer overflow: -9223372036854775807 - 48000 cannot be
represented in type 'long long'
Fixes:
26521/clusterfuzz-testcase-minimized-ffmpeg_dem_DIRAC_fuzzer-5635536506847232
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-
Fixes: shift exponent 64 is too large for 64-bit type 'unsigned long long'
Fixes:
26497/clusterfuzz-testcase-minimized-ffmpeg_dem_AVI_fuzzer-5690188355076096
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
--
With a IO block size of 1 byte potentially megabytes are quite slow to read,
thus
limit the number
Fixes:
26511/clusterfuzz-testcase-minimized-ffmpeg_dem_NUV_fuzzer-5679249073373184
Fixes:
26517/clusterfuzz-testcase-minimized-ffmpeg_dem_XMV_fuzzer-6316634501021696
Fixes:
26518/clusterfuzz-test
Fixes: NULL ptr dereference
Fixes:
26508/clusterfuzz-testcase-minimized-ffmpeg_dem_AAX_fuzzer-5694725249826816
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/aaxdec.c | 2 +-
1 file changed,
Signed-off-by: Michael Niedermayer
---
tools/target_dem_fuzzer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/target_dem_fuzzer.c b/tools/target_dem_fuzzer.c
index 4add459aef..992b1a4d89 100644
--- a/tools/target_dem_fuzzer.c
+++ b/tools/target_dem_fuzzer.c
@@ -195,7
Fixes: heap-buffer-overflow
Fixes:
26487/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-5742553675333632
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/magicyuv.c | 3 +++
Fixes: signed integer overflow: 9223372036854775807 + 564 cannot be represented
in type 'long'
Fixes:
26494/clusterfuzz-testcase-minimized-ffmpeg_dem_VOC_fuzzer-576754158849228
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Mic
Fixes: OOM
Fixes:
26503/clusterfuzz-testcase-minimized-ffmpeg_dem_RSD_fuzzer-6530816735444992
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/rsd.c | 2 ++
1 file changed, 2 insertions(+)
di
On 10/23/2020 10:17 AM, Alan Kelly wrote:
> Fixed. The wrong step size was used causing a write passed the end of
> the buffer. yuv2yuvX_mmxext is now called if there are any remaining pixels.
Please fix the commit subject (It's too long and contains commentary),
and keep comments about fixes be
Fixed. The wrong step size was used causing a write passed the end of
the buffer. yuv2yuvX_mmxext is now called if there are any remaining
pixels.
There is currently no checkasm for these functions. Is this required for
submission?
(Apologies for the double mail, I used git send-email but it
Signed-off-by: Zane van Iperen
---
tests/fate/acodec.mak | 4
tests/ref/acodec/adpcm-ima_alp | 4
2 files changed, 8 insertions(+)
create mode 100644 tests/ref/acodec/adpcm-ima_alp
diff --git a/tests/fate/acodec.mak b/tests/fate/acodec.mak
index 8ac71b1b27..35b597859c 100644
Signed-off-by: Zane van Iperen
---
Changelog | 1 +
libavcodec/Makefile| 1 +
libavcodec/adpcmenc.c | 40
libavcodec/allcodecs.c | 1 +
libavcodec/version.h | 4 ++--
5 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/C
Signed-off-by: Zane van Iperen
---
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/alp.c| 148 ++-
libavformat/version.h| 2 +-
5 files changed, 151 insertions(+), 2 deletions(-)
d
Sample rate is always 22050. Verified by trying various files in the game.
Signed-off-by: Zane van Iperen
---
libavformat/alp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/alp.c b/libavformat/alp.c
index 4c2e8f0652..e1da312b8c 100644
--- a/libavformat/alp.c
++
Fixed. The wrong step size was used causing a write passed the end of
the buffer. yuv2yuvX_mmxext is now called if there are any remaining pixels.
---
libswscale/x86/Makefile | 1 +
libswscale/x86/swscale.c| 75 --
libswscale/x86/yuv2yuvX.asm | 105
Signed-off-by: Andreas Rheinhardt
---
libavcodec/atrac3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/atrac3.c b/libavcodec/atrac3.c
index a3e7d96a65..1e884a56b6 100644
--- a/libavcodec/atrac3.c
+++ b/libavcodec/atrac3.c
@@ -247,7 +247,7 @@ static void read_
Signed-off-by: Andreas Rheinhardt
---
libavcodec/atrac3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/atrac3.c b/libavcodec/atrac3.c
index 01b7f06bff..a3e7d96a65 100644
--- a/libavcodec/atrac3.c
+++ b/libavcodec/atrac3.c
@@ -247,7 +247,7 @@ static void read_
The longest code of any of the VLC tables used is eight bits long, so
using nine bits long VLC tables is wasteful. Furthermore, there are only
seven VLC tables used, yet the code up until now made it look like there
should be eight. This has been corrected, too.
Signed-off-by: Andreas Rheinhardt
> dont.b...@gmail.com:
> > From: walle
> >
> > lock screen or other permission notification in win7 or
> > higher windows version would case BitBlt return false,
> > and gdigrab_read_packet will return AVERROR(EIO) and do nothing to
> > allocated packet data, then memory leak happend. It's necessa
On Thu, Oct 22, 2020 at 08:25:49PM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/wma.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
probably ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good pe
On Thu, Oct 22, 2020 at 08:45:43PM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/wmadec.c | 9 -
> 1 file changed, 9 deletions(-)
probably ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best a
On Sun, Oct 18, 2020 at 12:08:39AM +0200, Michael Niedermayer wrote:
> Fixes: Timeout (too looong -> 1 ms)
> Fixes:
> 26366/clusterfuzz-testcase-minimized-ffmpeg_dem_SDX_fuzzer-5655584843759616
> Fixes:
> 26391/clusterfuzz-testcase-minimized-ffmpeg_dem_ALP_fuzzer-5484026133217280
>
> Found-by: c
On Sun, Oct 18, 2020 at 12:08:41AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 19922944 * 1024 cannot be represented in type
> 'int'
> Fixes:
> 26402/clusterfuzz-testcase-minimized-ffmpeg_dem_VMD_fuzzer-5745470053548032
>
> Found-by: continuous fuzzing process
> https://
On Sun, Oct 18, 2020 at 12:08:38AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 55255 * 53207 cannot be represented in type
> 'int'
> Fixes:
> 26387/clusterfuzz-testcase-minimized-ffmpeg_dem_AVS2_fuzzer-568426071552
>
> Found-by: continuous fuzzing process
> https://g
On Sun, Oct 18, 2020 at 12:08:37AM +0200, Michael Niedermayer wrote:
> Fixes: Infinite loop
> Fixes:
> 26376/clusterfuzz-testcase-minimized-ffmpeg_dem_PCM_U32LE_fuzzer-6050518830678016
> Fixes:
> 26377/clusterfuzz-testcase-minimized-ffmpeg_dem_TY_fuzzer-4838195726123008
> Fixes:
> 26384/clusterf
On Thu, Oct 22, 2020 at 06:55:37PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Thu, Oct 22, 2020 at 07:55:31AM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> Fixes: SEGV on unknown address 0x
> >>> Fixes:
> >>> 26482/clusterfuzz-testcase-minimized-f
38 matches
Mail list logo