Stop raising tensions here.
On Sat, Apr 3, 2021 at 10:07 PM Kieran Kunhya wrote:
> Hey code of conduct committee, can we ban this person?
>
> Kieran
>
> Sent from my mobile device
>
> On Sat, 3 Apr 2021, 22:06 RADSL, wrote:
>
> >
> > On 4/3/2021 12:47 PM, Kieran Kunhya wrote:
> > > Who are you
On Sat, Apr 3, 2021 at 1:01 PM Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-04-02 20:27:24)
> > Hi all
> >
> > CFHD currently has even with all fixes (ignoring ones with objections)
> applied a null pointer
> > read and out of array write issue remaining.
> >
> > My patch which makes
As always, make sure that you do not break or add new regressions for
decoding existing valid files.
On Sat, Apr 3, 2021 at 4:54 PM Michael Niedermayer
wrote:
> On Sat, Apr 03, 2021 at 04:39:06PM +0200, Michael Niedermayer wrote:
> > Fixes: out of array accesses
> > Fixes:
> 29754/clusterfuzz-te
Fixes the following GCC warning:
warning: format ‘%lld’ expects argument of type ‘long long int’,
but argument 4 has type ‘int64_t’ {aka ‘long int’} [-Wformat=]
Signed-off-by: Andreas Rheinhardt
---
Will apply soon.
libavfilter/vf_find_rect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
On 2021-04-04 15:01, Andreas Rheinhardt wrote:
Fixes the following GCC warning:
warning: format ‘%lld’ expects argument of type ‘long long int’,
but argument 4 has type ‘int64_t’ {aka ‘long int’} [-Wformat=]
Weird. I switched to lld because gcc (10.2) recommended it.
In fact, I just looked t
Gyan Doshi (12021-04-04):
> > Fixes the following GCC warning:
> > warning: format ‘%lld’ expects argument of type ‘long long int’,
> > but argument 4 has type ‘int64_t’ {aka ‘long int’} [-Wformat=]
>
> Weird. I switched to lld because gcc (10.2) recommended it.
>
> In fact, I just looked through
Gyan Doshi:
>
>
> On 2021-04-04 15:01, Andreas Rheinhardt wrote:
>> Fixes the following GCC warning:
>> warning: format ‘%lld’ expects argument of type ‘long long int’,
>> but argument 4 has type ‘int64_t’ {aka ‘long int’} [-Wformat=]
>
> Weird. I switched to lld because gcc (10.2) recommended i
On 2021-04-04 15:29, Andreas Rheinhardt wrote:
Gyan Doshi:
On 2021-04-04 15:01, Andreas Rheinhardt wrote:
Fixes the following GCC warning:
warning: format ‘%lld’ expects argument of type ‘long long int’,
but argument 4 has type ‘int64_t’ {aka ‘long int’} [-Wformat=]
Weird. I switched to lld
Guo, Yejun (12021-04-01):
> > Is this allowed to be negative? Can/should this be size_t?
> There was a long discussion about size_t/int/uint32_t when I added
> struct AVRegionOfInterest in frame.h, and finally size_t is not chosen.
Then at least unsigned.
> yes, we can add a version number (enum
On Sat, 3 Apr 2021, Andreas Rheinhardt wrote:
Implements ticket #9113.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpegtsenc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 35c835c484..dbd3b
On 4/4/2021 7:01 AM, Nicolas George wrote:
Guo, Yejun (12021-04-01):
Is this allowed to be negative? Can/should this be size_t?
There was a long discussion about size_t/int/uint32_t when I added
struct AVRegionOfInterest in frame.h, and finally size_t is not chosen.
Then at least unsigned.
Nicolas George:
> Guo, Yejun (12021-04-01):
>>> Is this allowed to be negative? Can/should this be size_t?
>> There was a long discussion about size_t/int/uint32_t when I added
>> struct AVRegionOfInterest in frame.h, and finally size_t is not chosen.
>
> Then at least unsigned.
>
>> yes, we can
James Almer:
> On 4/4/2021 7:01 AM, Nicolas George wrote:
>> Guo, Yejun (12021-04-01):
Is this allowed to be negative? Can/should this be size_t?
>>> There was a long discussion about size_t/int/uint32_t when I added
>>> struct AVRegionOfInterest in frame.h, and finally size_t is not chosen.
>
James Almer (12021-04-04):
> This solution is what was used for video_enc_params.h, so i agree it should
> be used here too. What's missing is a check for idx < nb_bbox before
> accessing the offset in question, so an inline function instead of a #define
> with a check for the above would be needed
Andreas Rheinhardt (12021-04-04):
> That's a variable-length array. That's a C99 feature we do not require.
We have used variable-length arrays in the past. We have eliminated them
from our code base not because lack of support, IIRC, but because they
have a tendency to ruin compiler optimization.
From: Andriy Gelman
Signed-off-by: Andriy Gelman
---
libavformat/rtsp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 76efbf42cd..6438e2edb8 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1466,9 +1466,9 @@ i
From: Andriy Gelman
Currently it is only checked that the rtp port does not exceed rtp_port_max.
---
libavformat/rtsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 6438e2edb8..e6a068148b 100644
--- a/libavformat/rtsp.c
+++ b/l
From: Andriy Gelman
Fixed by setting port offset to zero when it cannot be computed.
To reproduce:
$ ffmpeg -min_port 32000 -max_port 32001 -i
rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov -f null -
[1]303871 floating point exception (core dumped)
Signed-off-by: Andriy G
Marton Balint:
>
>
> On Sat, 3 Apr 2021, Andreas Rheinhardt wrote:
>
>> Implements ticket #9113.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/mpegtsenc.c | 18 +-
>> 1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/libavformat/mpegtsenc.c b/liba
On Sun, 4 Apr 2021, Andreas Rheinhardt wrote:
Marton Balint:
On Sat, 3 Apr 2021, Andreas Rheinhardt wrote:
Implements ticket #9113.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpegtsenc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavfo
av_buffer_create() will start taking a size argument of size_t type.
Signed-off-by: James Almer
---
libavutil/video_enc_params.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/video_enc_params.c b/libavutil/video_enc_params.c
index 635176ab91..e6a8e38d94 100644
--- a/libavutil/v
On 4/4/2021 4:42 AM, Paul B Mahol wrote:
On Sat, Apr 3, 2021 at 1:01 PM Anton Khirnov wrote:
Quoting Michael Niedermayer (2021-04-02 20:27:24)
Hi all
CFHD currently has even with all fixes (ignoring ones with objections)
applied a null pointer
read and out of array write issue remaining.
On 4/4/2021 4:46 AM, Paul B Mahol wrote:
As always, make sure that you do not break or add new regressions for
decoding existing valid files.
Coverage of cfhd by FATE is really low. Pretty much half of the decoder
is untested right now:
http://coverage.ffmpeg.org/index.src_libavcodec_cfhd.c.h
Fixes: Invalid read of size 4
Fixes: ASAN_Deadlysignal.zip
Found-by: Hardik Shah
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7805330bf9..ef73f3199d 100644
--- a/libavformat/mov.c
+++ b
On 4/4/2021 6:44 PM, Michael Niedermayer wrote:
Fixes: Invalid read of size 4
Fixes: ASAN_Deadlysignal.zip
Found-by: Hardik Shah
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7805330
On Sun, 10. Jan 10:57, Andriy Gelman wrote:
> On Thu, 17. Dec 10:42, Andriy Gelman wrote:
> > On Tue, 08. Dec 22:35, Andriy Gelman wrote:
> > > Hi Zhao,
> > >
> > > Thanks for reviewing.
> > >
> > > On Tue, 08. Dec 13:25, "zhilizhao(赵志立)" wrote:
> > > >
> > > >
> > > > > On Dec 8, 2020, at 12:
From: Andreas Rheinhardt
This mostly reverts commit 4b2863ff01b1fe93d9a518523c9098d17a9d8c6f.
Said commit removed the freeing code from ff_mpv_common_init(),
ff_mpv_common_frame_size_change() and ff_mpeg_framesize_alloc() and
instead added the FF_CODEC_CAP_INIT_CLEANUP to several codecs that use
From: Andreas Rheinhardt
When slice-threading is used, ff_mpv_common_init() duplicates
the first MpegEncContext and allocates some buffers for each
MpegEncContext (the first as well as the copies). But the count of
allocated MpegEncContexts is not updated until after everything has
been allocated
From: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 36 +++-
1 file changed, 15 insertions(+), 21 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 7327204e99..7eddbdcc37 100644
--- a/libavcodec/m
In case of resolution changes rv20_decode_picture_header() closes and
reopens its MpegEncContext; it checks the latter for errors, yet when
an error happens, it might happen that no new attempt at
reinitialization is performed when decoding the next frame; this leads
to crashes lateron.
This commi
The RealVideo 3.0 and 4.0 decoders call ff_mpv_common_init() only during
their init function and not during decode_frame(); when the size of the
frame changes, they call ff_mpv_common_frame_size_change(). Yet upon
error, said function calls ff_mpv_common_end() which frees the whole
MpegEncContext a
Before 998c9f15d1ca8c7489775ebcca51623b915988f1, initializing an
MpegEncContext's IDCT parts occured in ff_mpv_common_init() and this
has been called in h261_decode_frame(), not h261_decode_init().
Yet said commit factored this out of ff_mpv_common_init() and therefore
there is no reason any more
32 matches
Mail list logo
