Fixes: Timeout
Fixes:
30325/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6048395703746560
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
Michael Niedermayer:
> Fixes: signed integer overflow: 2147483647 + 64 cannot be represented in type
> 'int'
> Fixes:
> 30333/clusterfuzz-testcase-minimized-ffmpeg_dem_RM_fuzzer-5175286983426048
>
> Found-by: continuous fuzzing process
>
then add new parser bellow
On Mon, Feb 15, 2021 at 8:16 PM Carl Eugen Hoyos wrote:
> Am Mo., 15. Feb. 2021 um 19:13 Uhr schrieb Carl Eugen Hoyos
> :
> >
> > Am Mo., 15. Feb. 2021 um 02:39 Uhr schrieb Paul B Mahol <
> one...@gmail.com>:
> > >
> > > Why you use pbm decoder for probing of pfm
Hi!
Attached patch is necessary for a new pfm demuxer.
Please comment, Carl Eugen
From bd8d192651b3778c2cda387dbdce58eb377ca077 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 15 Feb 2021 23:22:35 +0100
Subject: [PATCH] lavc/pnm_parser: Add a pfm parser.
A parser cannot support more
Carl Eugen Hoyos:
> Hi!
>
> Attached patch is necessary for a new pfm demuxer.
>
> Please comment, Carl Eugen
>
Can't we just wait and increment the number of codec_ids a parser can
support at the next bump?
- Andreas
___
ffmpeg-devel mailing list
ff_pfm_parser
On Mon, Feb 15, 2021 at 8:29 PM Carl Eugen Hoyos wrote:
> Am Mo., 15. Feb. 2021 um 20:18 Uhr schrieb Paul B Mahol >:
> >
> > then add new parser bellow
>
> Already working on it:
> ff_pnm2_parser or ff_pfm_parser?
> Or another idea?
>
> Thank you, Carl Eugen
>
Am Mo., 15. Feb. 2021 um 20:18 Uhr schrieb Paul B Mahol :
>
> then add new parser bellow
Already working on it:
ff_pnm2_parser or ff_pfm_parser?
Or another idea?
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Fixes: signed integer overflow: 2147483647 + 64 cannot be represented in type
'int'
Fixes:
30333/clusterfuzz-testcase-minimized-ffmpeg_dem_RM_fuzzer-5175286983426048
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael
Andreas Rheinhardt:
> Also, test modifying colorspace properties and the default_mode
> passthrough which is used here to create a file that has no default
> track at all.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> tests/fate/matroska.mak | 8 +++
>
Fixes: Timeout (long -> 5sec)
Fixes:
30269/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP7_fuzzer-5430325004075008
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vp8.c | 6 +++---
1
While this is mode source code, it generates less binary code and can be
more cleanly extended to H.266.
---
On 14/02/2021 19:45, Andreas Rheinhardt wrote:
Nuo Mi:
From: Mark Thompson
---
libavcodec/cbs_h2645.c | 171 +++--
1 file changed, 130
Am Mo., 15. Feb. 2021 um 19:13 Uhr schrieb Carl Eugen Hoyos
:
>
> Am Mo., 15. Feb. 2021 um 02:39 Uhr schrieb Paul B Mahol :
> >
> > Why you use pbm decoder for probing of pfm files?
>
> The only samples I found have the extension pbm and I
> simply misunderstood how you designed this since my
>
Fixes: OOM
Fixes:
27780/clusterfuzz-testcase-minimized-ffmpeg_dem_VIVIDAS_fuzzer-5097985075314688
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/vividas.c | 2 +-
1 file changed, 1
Andreas Rheinhardt:
> It furthermore tests the demuxer's handling of chained SeekHeads,
> level 1-elements after the Clusters and the muxer's capability of
> writing huge TrackNumbers as well as expanding the Cues' length field
> by one byte if necessary to fill the reserved space. It also tests
>
On 11/02/2021 08:15, Guo, Yejun wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Mark
Thompson
Sent: 2021年2月11日 6:19
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH V2 08/10] libavutil: add side data
AVDnnBoundingBox for dnn based detect/classify filters
On
While parsing ref_frame_config, AVdictionary needs to be manually
deallocated.
---
libavcodec/libvpxenc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 284cb9a108..941c3fdd88 100644
--- a/libavcodec/libvpxenc.c
+++
On Mon, Feb 15, 2021 at 09:23:11PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout (long -> 5sec)
> Fixes:
> 30269/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP7_fuzzer-5430325004075008
>
> Found-by: continuous fuzzing process
>
Am Mo., 15. Feb. 2021 um 02:39 Uhr schrieb Paul B Mahol :
>
> Why you use pbm decoder for probing of pfm files?
The only samples I found have the extension pbm and I
simply misunderstood how you designed this since my
samples were detected as pbm (because of their
extension).
Will fix, Carl
On 2/14/2021 11:32 AM, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
libavfilter/x86/vf_gblur.asm| 49 +
libavfilter/x86/vf_gblur_init.c | 17 ++--
2 files changed, 63 insertions(+), 3 deletions(-)
diff --git a/libavfilter/x86/vf_gblur.asm
Before macOS 11, the encoded h264 sample contains fixed SEI before
IDR frame, which the content is below
06 05 10 b9 ed b9 30 5d 21 4b 71 83 71 2c 10 a3
14 bb 29 80
The length of the encoded SEI nalu is 20 byte. According to
the ITU-T H.264 Recommendation section 7.3.2.3.1, the last byte
0x80
The MPEG-PS muxer uses a custom queue of custom packets. To keep track
of it, it has a pointer (named predecode_packet) to the head of the
queue and a pointer to where the next packet is to be added (it points
to the next-pointer of the last element of the queue); furthermore,
there is also a
Do this by moving the check before the allocation.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpegenc.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
index 1204e57f04..14b904b152 100644
---
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpegenc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
index 14b904b152..d37f181eaa 100644
--- a/libavformat/mpegenc.c
+++ b/libavformat/mpegenc.c
@@ -1151,7 +1151,7 @@
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpegenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
index 810dd717ca..1204e57f04 100644
--- a/libavformat/mpegenc.c
+++ b/libavformat/mpegenc.c
@@ -1262,6 +1262,11 @@ static void
Nuo Mi:
> On Mon, Feb 15, 2021 at 3:45 AM Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
>> Nuo Mi:
>>> From: Mark Thompson
>>>
>>>
>>> -}
>>> +static int cbs_h2645_replace_ps(CodedBitstreamContext *ctx,
>>> +CodedBitstreamUnit *unit)
>>> +{
>>> +
sharpbai:
> Before macOS 11, the encoded h264 sample contains fixed SEI before
> IDR frame, which the content is below
>
> 06 05 10 b9 ed b9 30 5d 21 4b 71 83 71 2c 10 a3
> 14 bb 29 80
>
> The length of the encoded SEI nalu is 20 byte. According to
> the ITU-T H.264 Recommendation section
Andreas Rheinhardt:
> Up until now, when doing frame thread encoding, each worker thread
> tried to allocate an AVPacket for every AVFrame to be encoded; said
> packets would then be handed back to the main thread, where the content
> of said packet is copied into the packet actually destined for
On Mon, Feb 15, 2021 at 7:51 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> sharpbai:
> > Before macOS 11, the encoded h264 sample contains fixed SEI before
> > IDR frame, which the content is below
> >
> > 06 05 10 b9 ed b9 30 5d 21 4b 71 83 71 2c 10 a3
> > 14 bb 29 80
> >
> >
On 2/14/2021 8:20 PM, Andreas Rheinhardt wrote:
Such a scenario is undefined behaviour and would also indicate a bug
in our code.
Suggested-by: James Almer
Signed-off-by: Andreas Rheinhardt
---
libavformat/utils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/utils.c
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/exrenc.c| 480 +
libavformat/img2enc.c | 2 +-
4 files changed, 483 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/exrenc.c
diff
Normally, video packets are muxed before audio packets for mxf (there is
a dedicated interleave function for this); furthermore the first (video)
packet triggers writing the actual header. Yet when the first video packet
fails the checks performed on it, it will be an audio packet that leads
to
On 2/15/2021 1:41 PM, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/exrenc.c| 480 +
libavformat/img2enc.c | 2 +-
4 files changed, 483 insertions(+), 1
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".
The md5 test up until now ignored errors from ffmpeg (the cli) and just
md5'ed whatever ffmpeg has output; while testing scenarios in which
ffmpeg fails has its merits, errors should not be overlooked by default;
doing so also reduces the effectiveness of sanitizers as errors from
them are
The mxf_d10 muxer is very picky regarding the input it accepts:
The only video accepted is MPEG-2 with absolutely constant bitrate,
i.e. all packets need to have exactly the same size; and only a few
bitrates are accepted.
The sample file used did not abide by this: Writing the first packet
(a
Doing so is still bitexact.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfenc.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 509cae8442..3bfe2a5c1a 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 3bfe2a5c1a..72edaa9e30 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -752,7 +752,7 @@ static void
mxf distinguishes codec profiles by different UIDs and therefore needs
to check that the input is actually compatible with mxf (i.e. if there
is a defined UID for it). If not, then sometimes the UID would be set to
NULL and writing the (video) packet would fail. Yet the following audio
packet
38 matches
Mail list logo
