>
> The one-tailed (we are not considering whether "fast" is slower than
> "normal") homoscedastic ("equal variance sampled, not paired") student t
> test has a p value of 0.009638597, which for a typical p value threshold of
> 0.05 would reject the null hypothesis ("they are the same speed") and
>
Andreas Rheinhardt:
> c801ab43c36e8c4f88121aa09af26c77bcbd671b caused a regression: The stream
> number is now parsed with strtoll without a fixed basis; as a
> consequence, the "010" in a variant stream mapping like "a:010" is now
> treated as an octal number (i.e. as eight, not ten). This was not
c801ab43c36e8c4f88121aa09af26c77bcbd671b caused a regression: The stream
number is now parsed with strtoll without a fixed basis; as a
consequence, the "010" in a variant stream mapping like "a:010" is now
treated as an octal number (i.e. as eight, not ten). This was not
intended and may break some
On Mon, Jun 15, 2020 at 03:40:50AM +0200, Andreas Rheinhardt wrote:
> Commit 17e88bf0df21906633a7d36d9f2aeeeb5b6d3267 created a memleak by
> removing a call to ff_iir_filter_free_coeffsp on error; this has been
> found by Coverity (ID 1464159). This commit fixes the memleak by
> readding the call t
Hi,
On Sat, Jun 13, 2020 at 12:11 PM Kieran Kunhya wrote:
> Hello,
>
> I have run the following commands on the following CPU which is 7 years
> old:
> Intel(R) Xeon(R) CPU E3-1265L v3
>
> ffmpeg_g -i matrixbench_mpeg2.mpg -f null -
> and
> ffmpeg_g -flags2 fast -i matrixbench_mpeg2.mpg -f null
Commit 17e88bf0df21906633a7d36d9f2aeeeb5b6d3267 created a memleak by
removing a call to ff_iir_filter_free_coeffsp on error; this has been
found by Coverity (ID 1464159). This commit fixes the memleak by
readding the call to ff_iir_filter_free_coeffsp.
Notice that this is not a simple revert, beca
On Mon, Jun 15, 2020 at 12:10:14AM +0200, Michael Niedermayer wrote:
> Fixes: assertion failure
> Fixes:
> 23422/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5746026064642048
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpe
Signed-off-by: Andreas Rheinhardt
---
libavformat/mov.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 683ad49e7a..8bc220408c 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -857,27 +857,20 @@ static int
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpl2dec.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/mpl2dec.c b/libavformat/mpl2dec.c
index bea258d9e9..38445c7aad 100644
--- a/libavformat/mpl2dec.c
+++ b/libavformat/mpl2dec.c
@@ -83,7 +83,6 @@ static int
Signed-off-by: Andreas Rheinhardt
---
libavformat/sccdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/sccdec.c b/libavformat/sccdec.c
index 72f47f70de..c08c58ef97 100644
--- a/libavformat/sccdec.c
+++ b/libavformat/sccdec.c
@@ -66,7 +66,7 @@ static int scc
Signed-off-by: Andreas Rheinhardt
---
libavformat/mov.c | 112 ++
1 file changed, 53 insertions(+), 59 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 8bc220408c..e30cd1ef1a 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@
Signed-off-by: Andreas Rheinhardt
---
libavformat/pjsdec.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/pjsdec.c b/libavformat/pjsdec.c
index e30c23d830..1f1d51c404 100644
--- a/libavformat/pjsdec.c
+++ b/libavformat/pjsdec.c
@@ -67,7 +67,6 @@ static int pjs_r
Signed-off-by: Andreas Rheinhardt
---
libavformat/mov.c | 34 --
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7c8c9bcb51..683ad49e7a 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -863,14 +86
Signed-off-by: Andreas Rheinhardt
---
libavformat/mov.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 72e868527a..7c8c9bcb51 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2545,11 +2545,8 @@ int ff_mov_read_stsd_
Signed-off-by: Andreas Rheinhardt
---
This patch and all the following patches are not intended to be
backported to 4.3.
libavformat/mov.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4e68532b69..b2f2f8a3dd 100644
---
Given that av_get_packet returns a blank packet on error, the only
difference to the current approach (that uses intermediate AVPackets on
the stack) is that st->attached_pic will be properly initialized on error
(i.e. the timestamps are AV_NOPTS_VALUE) whereas right now st->attached_pic
is only ze
Only read str_size bytes from offset 30 of extradata if the extradata is
indeed at least 30 + str_size bytes long.
Signed-off-by: Andreas Rheinhardt
---
Honestly I don't know the spec describing the actual layout of the
reel_name tag, but looking at this code as well as the one in movenc
makes it
mov_read_custom tries to read three strings belonging to three different
tags. When an already encountered tag is encountered again, a new buffer
for the string to be read is allocated and stored in the pointer
destined for this particular tag. But in this scenario, said pointer
already holds the a
The argument pertaining to a printf %s conversion specifier must not
be NULL, even if the precision (i.e. the number of characters to write)
is zero. If it is NULL, it is undefined behaviour.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 4 +++-
1 file changed, 3 insertions(+
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt
---
libavformat/subviewer1dec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/subviewer1
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt
---
libavformat/vplayerdec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/vplayerdec.c
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt
---
libavformat/webvttdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/webvttdec.c b/libavformat/webvt
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt
---
libavformat/subviewerdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/subviewerdec.c b/libavformat
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if allocating the AVStream for the subtitles fails.
Signed-off-by: Andreas Rheinhardt
---
libavformat/tedcaptionsdec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/tedcaptio
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle
or when creating extradata.
Signed-off-by: Andreas Rheinhardt
---
libavformat/samidec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/samide
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt
---
libavformat/stldec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/stldec.c b/libavf
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt
---
libavformat/pjsdec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/pjsdec.c b/libavf
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt
---
libavformat/sccdec.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/sccdec.c b/li
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt
---
libavformat/srtdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/srtdec.c b/libavformat/srtdec.c
in
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon creating an AVStream.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpsubdec.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/mpsubdec.c b/libavfor
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt
---
libavformat/jacosubdec.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/jacosubdec
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt
---
libavformat/lrcdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/lrcdec.c b/libavformat/lrcdec.c
inde
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle
or when allocating extradata.
Signed-off-by: Andreas Rheinhardt
---
libavformat/microdvddec.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletion
By default, a demuxer's read_close function is not called automatically
if an error happens when reading the header; instead it is up to the
demuxer to clean up after itself in this case. The mov demuxer did this
by calling its read_close function when it encountered some errors when
reading the he
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpl2dec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/mpl2dec.c b/liba
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt
---
libavformat/aqtitledec.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/aqtitlede
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle
or if creating the extradata failed.
Signed-off-by: Andreas Rheinhardt
---
libavformat/assdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavforma
In certain error scenarios, the underlying Matroska demuxer was not
properly closed, causing leaks.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroska
matroska_parse_block currently asserts that the duration is not equal to
AV_NOPTS_VALUE, but there is nothing that actually guarantees this. It
is easy to create (spec-compliant) files which run into this assert;
so replace it and instead cap the duration to INT64_MAX, as the duration
field of an A
When demuxing a Matroska/WebM file, streams are added for tracks and for
attachments, so that the array containing the former can be NULL even
when the corresponding AVFormatContext has streams. So check for there
to be tracks in the MatroskaDemuxContext instead of just streams in the
AVFormatConte
Fixes possible leaks of id3v2 metadata as well as an AVDES struct in
case the content is encrypted and an error happens lateron.
Signed-off-by: Andreas Rheinhardt
---
libavformat/omadec.c | 42 +++---
1 file changed, 27 insertions(+), 15 deletions(-)
diff --g
EBML binary elements are already made reference-counted when read;
so when populating the AVStream.attached_pic, one does not need to
allocate a new buffer for the data; instead the current code just
creates a new reference to the underlying AVBuffer. But this can be
improved even further: Just mov
On Sun, Jun 14, 2020 at 18:56:06 +0200, Levis Florian wrote:
Small nit:
> +{ "delivery_mode", "Delivery more (non-persistent: 1/persistent: 2)",
> OFFSET(delivery_mode), AV_OPT_TYPE_INT, { .i64 = AMQP_DELIVERY_PERSISTENT },
> 1, 2, .flags = E, "delivery_mode"},
Fixes: assertion failure
Fixes:
23422/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5746026064642048
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/tiff.c | 4
1 file cha
>
> > Also the speed benefits are tiny overall, sub-1%.
>
> This claim is not supported by the statistics you posted
>
For the overall decoding of MPEG-2 the VLC/dequant functions take up
roughly 30% of decoding time.
FAST vs normal is about 2% faster on the VLC/dequant functions, therefore
the to
On Sun, Jun 14, 2020 at 06:50:04PM +0100, Kieran Kunhya wrote:
> On Sun, 14 Jun 2020 at 18:47, Carl Eugen Hoyos wrote:
>
> > Am So., 14. Juni 2020 um 02:33 Uhr schrieb Kieran Kunhya :
> >
> > > Logical fallacy.
> >
> > Could you please stop this?
> >
> > Apart from the personal attack, we have fa
On 6/14/2020 1:24 PM, Michael Niedermayer wrote:
> On Thu, Jun 11, 2020 at 01:13:20PM -0300, James Almer wrote:
>> If this happens, it's a sign of parsing issues earlier in the process, or
>> misuse by the calling module.
>>
>> Prevents creating invalid bitstreams.
>>
>> Signed-off-by: James Almer
On 14 Jun 2020, at 15:42, Michael Niedermayer wrote:
On Sun, Jun 14, 2020 at 12:52:44AM +0200, Marvin Scholz wrote:
---
doc/protocols.texi| 3 +++
libavformat/icecast.c | 6 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 7
On 6/14/20, Michael Niedermayer wrote:
> On Sun, Jun 14, 2020 at 07:40:43PM +0200, Paul B Mahol wrote:
>> On 6/14/20, Jean-Baptiste Kempf wrote:
>> > Hello people,
>> >
>> > Just for your information, I kicked out Paul from the IRC channel
>> > #ffmpeg-devel.
>> >
>> > The IRC log is the followin
On Sun, Jun 14, 2020 at 06:32:31PM +0100, Kieran Kunhya wrote:
> On Sun, 14 Jun 2020 at 17:32, Michael Niedermayer
> wrote:
>
> > On Sun, Jun 14, 2020 at 05:05:35PM +0100, Kieran Kunhya wrote:
> > > In addition here are results when precomputing the quant tables:
> > >
> > > Precalculated
> > > 6
On Sun, Jun 14, 2020 at 08:06:46PM +0200, Michael Niedermayer wrote:
> Fixes: assertion failure
> Fixes:
> 23434/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5227750851084288.fuzz
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
On 14/06/2020 18:40, Paul B Mahol wrote:
> The part I was arguing is applying patches which are clearly blocked.
> Some developers apparently can do that. And other developers opinions
> means nothing much.
It would be good if this community could learn that even being right does
not make it OK fo
On Tue, 9 Jun 2020, Marton Balint wrote:
Max region ID is 87. Also the region affects not only the G0 charset but G2 and
the national subset as well.
Signed-off-by: Marton Balint
---
doc/decoders.texi| 2 +-
libavcodec/libzvbi-teletextdec.c | 2 +-
2 files changed, 2 insertions
On Sun, Jun 14, 2020 at 08:19:18PM +0200, Marton Balint wrote:
>
>
> On Sun, 14 Jun 2020, Michael Niedermayer wrote:
>
> > Alternatively we could free the already allocated element
>
> Yeah, I kind of prefer that, we potentially allow non-string values to occur
> multiple times, so I'd say let'
On Sun, Jun 14, 2020 at 07:40:43PM +0200, Paul B Mahol wrote:
> On 6/14/20, Jean-Baptiste Kempf wrote:
> > Hello people,
> >
> > Just for your information, I kicked out Paul from the IRC channel
> > #ffmpeg-devel.
> >
> > The IRC log is the following:
> >
> > 19:23 <@durandal_1707> Watch me now re
On Sun, 14 Jun 2020, Michael Niedermayer wrote:
Alternatively we could free the already allocated element
Yeah, I kind of prefer that, we potentially allow non-string values to
occur multiple times, so I'd say let's allow string values as well, even
if that is not common. (I am not sure if
Fixes: assertion failure
Fixes:
23434/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5227750851084288.fuzz
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/4xm.c | 3 +++
1 file changed,
Alternatively we could free the already allocated element
Fixes: memleak
Fixes:
23415/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5124814510751744
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
On Sun, Jun 14, 2020, at 19:48, Kieran Kunhya wrote:
> > The part I was arguing is applying patches which are clearly blocked.
> > Some developers apparently can do that. And other developers opinions
> > means nothing much.
> >
>
> The sooner we have a technical committee and code of conduct, t
On Sun, 14 Jun 2020 at 18:47, Carl Eugen Hoyos wrote:
> Am So., 14. Juni 2020 um 02:33 Uhr schrieb Kieran Kunhya :
>
> > Logical fallacy.
>
> Could you please stop this?
>
> Apart from the personal attack, we have far too many known, reproducible
> bugs to spend time on discussing code that you d
> The part I was arguing is applying patches which are clearly blocked.
> Some developers apparently can do that. And other developers opinions
> means nothing much.
>
The sooner we have a technical committee and code of conduct, the sooner
that change can happen.
You can't call people Hitler for
On Sun, Jun 14, 2020, at 19:40, Paul B Mahol wrote:
> On 6/14/20, Jean-Baptiste Kempf wrote:
> > Hello people,
> >
> > Just for your information, I kicked out Paul from the IRC channel
> > #ffmpeg-devel.
> >
> > The IRC log is the following:
> >
> > 19:23 <@durandal_1707> Watch me now removing s
Am So., 14. Juni 2020 um 02:33 Uhr schrieb Kieran Kunhya :
> Logical fallacy.
Could you please stop this?
Apart from the personal attack, we have far too many known, reproducible
bugs to spend time on discussing code that you don't like (for whatever
reason) but fortunately don't have to maintai
On 6/14/2020 1:28 PM, Paul B Mahol wrote:
> On 6/14/20, Jean-Baptiste Kempf wrote:
>> On Sun, Jun 14, 2020, at 17:58, Paul B Mahol wrote:
>>> On 6/14/20, Jean-Baptiste Kempf wrote:
On Thu, Jun 11, 2020, at 17:37, Paul B Mahol wrote:
> On 6/11/20, Michael Niedermayer wrote:
>> On Wed
On 6/14/20, Jean-Baptiste Kempf wrote:
> Hello people,
>
> Just for your information, I kicked out Paul from the IRC channel
> #ffmpeg-devel.
>
> The IRC log is the following:
>
> 19:23 <@durandal_1707> Watch me now removing sonic crap
> 19:24 <@durandal_1707> you insensitve clod
> 19:24 <@j-b> Wa
On Sun, 14 Jun 2020 at 17:32, Michael Niedermayer
wrote:
> On Sun, Jun 14, 2020 at 05:05:35PM +0100, Kieran Kunhya wrote:
> > In addition here are results when precomputing the quant tables:
> >
> > Precalculated
> > 6439
> > 6424
> > 6407
> > 6436
> > 6437
> > Mean 6428.6
> > Stdev 13.42758355
>
On Sun, Jun 14, 2020 at 10:34 PM Paul B Mahol wrote:
> On 6/5/20, Ashutosh Pradhan wrote:
> > diff --git a/Changelog b/Changelog
> > index 711c843b99..905b91b570 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -75,7 +75,7 @@ version :
> > - PFM decoder
> > - dblur video filter
> > - Rea
Hello people,
Just for your information, I kicked out Paul from the IRC channel #ffmpeg-devel.
The IRC log is the following:
19:23 <@durandal_1707> Watch me now removing sonic crap
19:24 <@durandal_1707> you insensitve clod
19:24 <@j-b> Watch me now removing your commit access
19:24 < thardin> d
On Sat, Jun 13, 2020 at 10:03:44PM +0200, Michael Niedermayer wrote:
> Alternatively these conditions could be treated as errors
> Fixes:
> 23147/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5639254549200896
> Fixes: signed integer overflow: 9223372036854775807 + 1 cannot b
On Sat, Jun 13, 2020 at 10:03:45PM +0200, Michael Niedermayer wrote:
> Fixes: Timeout (longer than my patience vs 1sec)
> Fixes:
> 22984/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MV30_fuzzer-5630021988515840
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tr
On Thu, Jun 11, 2020 at 11:07:52PM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -144876608 * 16 cannot be represented in type
> 'int'
> Fixes:
> 22782/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-6039584977977344
>
> Found-by: continuous fuzzing process
On Thu, Jun 11, 2020 at 11:07:53PM +0200, Michael Niedermayer wrote:
> Fixes: shift exponent 35 is too large for 32-bit type 'int'
> Fixes:
> 22857/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5202709358837760
>
> Found-by: continuous fuzzing process
> https://github.com/goo
On Mon, Jun 08, 2020 at 12:14:50PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/utils.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who
On Sun, Jun 07, 2020 at 09:35:45PM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 2142077091 + 6881070 cannot be represented in
> type 'int'
> Fixes:
> 22737/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-595839681920
>
> Found-by: continuous fuzzin
On Sat, Jun 13, 2020 at 11:17:41PM +0800, leviz...@live.cn wrote:
> From: zhaoyi
>
> ---
> libavformat/tcp.c | 204 ++
> 1 file changed, 204 insertions(+)
seems to break build on mingw64
AR libavdevice/libavdevice.a
AR libavfilter/libavfilte
On 6/5/20, Ashutosh Pradhan wrote:
> diff --git a/Changelog b/Changelog
> index 711c843b99..905b91b570 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -75,7 +75,7 @@ version :
> - PFM decoder
> - dblur video filter
> - Real War KVAG muxer
> -
> +- atone filter
>
> version 4.2:
> - tpad filter
Hi,
To Marton Balint that reviewed my patch:
I tried to send fixed patch specify the --in-reply-to option, but I
guess it's not the good way to do it, cause I see a new thread on the
patchwork (20200614165606.36659-1-levis.flor...@gmail.com)
git format-patch -M origin/master -o outgoing/
git
Hi,
I hope this reply will go to the correct thread.
I reworked my patch after Marton Balint review.
* fix: missing documentation
* fix: use AV_OPT_TYPE_CONST
Signed-off-by: Levis Florian
---
doc/protocols.texi| 13 +
libavformat/libamqp.c | 6 +-
2 files changed, 18 inser
On Sat, Jun 13, 2020 at 01:23:41PM +0200, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes:
> 23245/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5723121327013888.fuzz
will apply patchset with requested modifications
[...]
--
Michael GnuPG fingerprint: 9F
Am So., 14. Juni 2020 um 17:52 Uhr schrieb Marton Balint :
>
>
>
> On Sun, 14 Jun 2020, Carl Eugen Hoyos wrote:
>
> > Am So., 14. Juni 2020 um 17:40 Uhr schrieb Marton Balint :
> >>
> >>
> >>
> >> On Sun, 14 Jun 2020, Carl Eugen Hoyos wrote:
> >>
> >> > Am So., 14. Juni 2020 um 16:26 Uhr schrieb Ma
On Sun, Jun 14, 2020, at 18:28, Paul B Mahol wrote:
> > If you want this code remove, get it removed by either consensus or a vote.
> > Not by screaming.
>
> You are mistaken, Mr. President.
> This code is under codec cap experimental and can be removed at will.
Experimental cap does not mean th
On Sun, Jun 14, 2020 at 05:05:35PM +0100, Kieran Kunhya wrote:
> In addition here are results when precomputing the quant tables:
>
> Precalculated
> 6439
> 6424
> 6407
> 6436
> 6437
> Mean 6428.6
> Stdev 13.42758355
does that work on a wider range of videos and CPUs ?
from what i remember really
Am So., 14. Juni 2020 um 18:22 Uhr schrieb Paul B Mahol :
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/movenc.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 5d8dc4fd5d..520aaafb74 100644
> --- a/libavformat/m
On 6/14/20, Jean-Baptiste Kempf wrote:
> On Sun, Jun 14, 2020, at 17:58, Paul B Mahol wrote:
>> On 6/14/20, Jean-Baptiste Kempf wrote:
>> > On Thu, Jun 11, 2020, at 17:37, Paul B Mahol wrote:
>> >> On 6/11/20, Michael Niedermayer wrote:
>> >> > On Wed, May 20, 2020 at 08:59:20PM +0200, Michael N
On Thu, Jun 11, 2020 at 01:13:20PM -0300, James Almer wrote:
> If this happens, it's a sign of parsing issues earlier in the process, or
> misuse by the calling module.
>
> Prevents creating invalid bitstreams.
>
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_av1.c | 3 ++-
> 1 file change
Fixes #4616.
Signed-off-by: Paul B Mahol
---
libavformat/mov.c | 24
1 file changed, 24 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2fc27d2aec..6d83a8a4b3 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7854,6 +7854,27 @@ static int
Signed-off-by: Paul B Mahol
---
libavformat/movenc.c | 16
1 file changed, 16 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 5d8dc4fd5d..520aaafb74 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5582,6 +5582,22 @@ int ff_mov_write_
On Sun, Jun 14, 2020, at 17:58, Paul B Mahol wrote:
> On 6/14/20, Jean-Baptiste Kempf wrote:
> > On Thu, Jun 11, 2020, at 17:37, Paul B Mahol wrote:
> >> On 6/11/20, Michael Niedermayer wrote:
> >> > On Wed, May 20, 2020 at 08:59:20PM +0200, Michael Niedermayer wrote:
> >> >> On Mon, May 11, 2020
In addition here are results when precomputing the quant tables:
Precalculated
6439
6424
6407
6436
6437
Mean 6428.6
Stdev 13.42758355
Kieran
On Sun, 14 Jun 2020 at 16:05, Kieran Kunhya wrote:
> Did you remove the branch for FLAGS2_FAST and the large amount of inlined
>> code when making this m
> From: ffmpeg-devel On Behalf Of Fu,
> Linjie
> Sent: Friday, June 12, 2020 10:39
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 4/5] fftools/ffmpeg: flush and
> recreate encoder instance if resolution changes
>
> > From: Nicolas George
> > Sent: Friday, June 12, 2020 00:
On 6/14/20, Jean-Baptiste Kempf wrote:
> On Thu, Jun 11, 2020, at 17:37, Paul B Mahol wrote:
>> On 6/11/20, Michael Niedermayer wrote:
>> > On Wed, May 20, 2020 at 08:59:20PM +0200, Michael Niedermayer wrote:
>> >> On Mon, May 11, 2020 at 01:07:54AM +0200, Paul B Mahol wrote:
>> >> > NAK
>> >> >
On 6/14/20, Carl Eugen Hoyos wrote:
> Am So., 14. Juni 2020 um 17:08 Uhr schrieb Paul B Mahol :
>>
>> On 6/14/20, Carl Eugen Hoyos wrote:
>> > Am So., 14. Juni 2020 um 14:22 Uhr schrieb Paul B Mahol
>> > :
>> >>
>> >> Fixes #4616.
>> >>
>> >> Signed-off-by: Paul B Mahol
>> >> ---
>> >> libavfor
On Sun, 14 Jun 2020, Carl Eugen Hoyos wrote:
Am So., 14. Juni 2020 um 17:40 Uhr schrieb Marton Balint :
On Sun, 14 Jun 2020, Carl Eugen Hoyos wrote:
> Am So., 14. Juni 2020 um 16:26 Uhr schrieb Marton Balint :
>>
>>
>>
>> On Sun, 14 Jun 2020, Carl Eugen Hoyos wrote:
>>
>> > Am So., 14. Ju
Hi,
On 03/06/2020 08:02, Nelson Gomez wrote:
Bumping this patchset (and apologies if Outlook mangles the threading)
[...]
Nelson Gomez (3):
swscale: make yuv2interleavedX more asm-friendly
swscale/x86/output: add AVX2 version of yuv2nv12cX
swscale: cosmetic fixes
libswscale/output.
Am So., 14. Juni 2020 um 17:40 Uhr schrieb Marton Balint :
>
>
>
> On Sun, 14 Jun 2020, Carl Eugen Hoyos wrote:
>
> > Am So., 14. Juni 2020 um 16:26 Uhr schrieb Marton Balint :
> >>
> >>
> >>
> >> On Sun, 14 Jun 2020, Carl Eugen Hoyos wrote:
> >>
> >> > Am So., 14. Juni 2020 um 12:05 Uhr schrieb Pa
On Sun, 14 Jun 2020, Carl Eugen Hoyos wrote:
Am So., 14. Juni 2020 um 16:26 Uhr schrieb Marton Balint :
On Sun, 14 Jun 2020, Carl Eugen Hoyos wrote:
> Am So., 14. Juni 2020 um 12:05 Uhr schrieb Paul B Mahol :
>>
>> [...] this patch should be merged.
>
> I still believe this is one of the
Am So., 14. Juni 2020 um 17:08 Uhr schrieb Paul B Mahol :
>
> On 6/14/20, Carl Eugen Hoyos wrote:
> > Am So., 14. Juni 2020 um 14:22 Uhr schrieb Paul B Mahol :
> >>
> >> Fixes #4616.
> >>
> >> Signed-off-by: Paul B Mahol
> >> ---
> >> libavformat/mov.c | 24
> >> 1 file
On Thu, Jun 11, 2020, at 17:37, Paul B Mahol wrote:
> On 6/11/20, Michael Niedermayer wrote:
> > On Wed, May 20, 2020 at 08:59:20PM +0200, Michael Niedermayer wrote:
> >> On Mon, May 11, 2020 at 01:07:54AM +0200, Paul B Mahol wrote:
> >> > NAK
> >> >
> >> > please remove this code fully.
> >>
> >>
On Sat, Jun 13, 2020, at 16:18, James Almer wrote:
> On 6/13/2020 9:12 AM, Lynne wrote:
> > Jun 13, 2020, 12:23 by mich...@niedermayer.cc:
> > I even asked you on IRC whether your previous 2 commits fixed the crash, so
> > I know whether
> > to try fixing it, and you didn't even respond. You didn'
On 6/14/20, Marton Balint wrote:
>
>
> On Sun, 14 Jun 2020, Paul B Mahol wrote:
>
>> Nothing happened of this, so this patch should be merged.
>
> What do you mean? Ass output support got added to libzvbi-teletextdec in
> 2018.
And how is ass output support relevant to give FFmpeg decoder support
1 - 100 of 128 matches
Mail list logo
