On Tue, Nov 10, 2020 at 12:04:51AM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 64 * 33686018 cannot be represented in type
> 'int'
> Fixes:
> 26911/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THEORA_fuzzer-4904975073017856
>
> Found-by: continuous fuzzing process
On Wed, Nov 04, 2020 at 01:06:45AM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/icodec.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/icodec.c b/libavformat/icodec.c
> index c061f3ec42..cf1e60815e
On Wed, Nov 04, 2020 at 01:06:46AM +0100, Michael Niedermayer wrote:
> Fixes: NULL pointer dereference
> Fixes:
> 26814/clusterfuzz-testcase-minimized-ffmpeg_dem_ICO_fuzzer-5758487797432320
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
On Fri, Nov 13, 2020 at 02:14:05AM +0100, Timo Rothenpieler wrote:
> On 13.11.2020 02:05, lance.lmw...@gmail.com wrote:
> > On Thu, Nov 12, 2020 at 05:56:57PM +0100, Timo Rothenpieler wrote:
> > > Technically, libvmaf itself does not, but our filter does, and there is
> > > no other sensible way
Nov 12, 2020, 22:39 by jamr...@gmail.com:
> On 11/12/2020 2:42 PM, Lynne wrote:
>
>> This introduces a new field to allow decoders to export their film grain
>> parameters.
>> Will be used by the next patch.
>>
>> Patch attached.
>>
>> From d5d5e1e5f90938ac5cfa462efc13658ab411246b Mon Sep 17
On 13.11.2020 02:05, lance.lmw...@gmail.com wrote:
On Thu, Nov 12, 2020 at 05:56:57PM +0100, Timo Rothenpieler wrote:
Technically, libvmaf itself does not, but our filter does, and there is
no other sensible way to prevent a build with --enable-libvmaf from
succeeding while not actually
On Thu, Nov 12, 2020 at 05:56:57PM +0100, Timo Rothenpieler wrote:
> Technically, libvmaf itself does not, but our filter does, and there is
> no other sensible way to prevent a build with --enable-libvmaf from
> succeeding while not actually enabling the filter.
If it's private filter, I think
Nov 12, 2020, 19:46 by jamr...@gmail.com:
> On 11/12/2020 2:42 PM, Lynne wrote:
>
>> This patch introduces a new frame side data type AVFilmGrainParams for use
>> with video codecs which are able to use it.
>>
>> It is generalized rather than being AV1 specific as AV2 is expected to carry
>> the
Nov 12, 2020, 19:07 by jamr...@gmail.com:
> On 11/12/2020 2:42 PM, Lynne wrote:
>
>> +if (p->frame_hdr->film_grain.present && (!dav1d->apply_grain ||
>> +(c->export_side_data & AV_CODEC_EXPORT_DATA_FILM_GRAIN))) {
>> +AVFilmGrainParams *fgp;
>> +if
IO functions are expected to return AVERROR_EOF instead of 0
nowadays. This is also expected by other higher level layers
within the http protocol itself (e.g. the reconnect mechanism).
---
libavformat/http.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
When the check was added (in 3668701f9600, in 2015), some IO
functions returned 0 on EOF (in particular, the TCP protocol
did, but the TLS protocol returned AVERROR_EOF). Since
0e1f771d2200d in 2017, the TCP protocol also returns AVERROR_EOF
instead of 0, making the check for premature end never
The spec in section 6.8.20 states the parameters should be loaded from a
reference frame indexed by film_grain_params_ref_idx.
Signed-off-by: James Almer
---
libavcodec/nvdec_av1.c | 57 +++---
1 file changed, 31 insertions(+), 26 deletions(-)
diff --git
This patch introduces a new frame side data type AVFilmGrainParams for use
with video codecs which are able to use it.
It is generalized rather than being AV1 specific as AV2 is expected to carry
the same data, as well as the fact there already exist rarely-used
specifications
for both H.264
This patch is relatively straightforward with one exception:
the decoder option flag.
The option was introduced to troubleshoot but its existence is conflicting
and redundant now that we have a codec-generic flag.
Hence this patch deprecates it.
The way it interacts with
Am Do., 12. Nov. 2020 um 11:30 Uhr schrieb Tobias Rapp :
>
> On 11.11.2020 17:15, Carl Eugen Hoyos wrote:
> > Not necessarily related: In no way whatsoever does the LGPL mandate
> > dynamic linking (this was claimed several times lately).
> The "License Compliance Checklist" on
This introduces a new field to allow decoders to export their film grain
parameters.
Will be used by the next patch.
Patch attached.
>From d5d5e1e5f90938ac5cfa462efc13658ab411246b Mon Sep 17 00:00:00 2001
From: Lynne
Date: Thu, 12 Nov 2020 17:46:09 +0100
Subject: [PATCH v2 2/3] libavcodec: add
Derek Buitenhuis:
> On 12/11/2020 20:51, Andreas Rheinhardt wrote:
>> The ff_init_vlc_... functions are inherently thread-safe: Everything is
>> modified only once and directly set to its final value; so it's no
>> problem if two threads are initializing the same static VLC at the same
>> time.
>
On 11/12/2020 2:42 PM, Lynne wrote:
This introduces a new field to allow decoders to export their film grain
parameters.
Will be used by the next patch.
Patch attached.
From d5d5e1e5f90938ac5cfa462efc13658ab411246b Mon Sep 17 00:00:00 2001
From: Lynne
Date: Thu, 12 Nov 2020 17:46:09 +0100
On 12.11.2020 22:23, James Almer wrote:
On 11/12/2020 6:19 PM, Timo Rothenpieler wrote:
Are you sure this is necessary at all?
If apply_grain is 0, the value of those should be entirely irrelevant.
This is not about apply_grain == 0, but about apply_grain == 1 &&
update_grain == 0.
In those
On 12/11/2020 20:51, Andreas Rheinhardt wrote:
> The ff_init_vlc_... functions are inherently thread-safe: Everything is
> modified only once and directly set to its final value; so it's no
> problem if two threads are initializing the same static VLC at the same
> time.
Hmm, indeed. At the
On 11/12/2020 6:19 PM, Timo Rothenpieler wrote:
Are you sure this is necessary at all?
If apply_grain is 0, the value of those should be entirely irrelevant.
This is not about apply_grain == 0, but about apply_grain == 1 &&
update_grain == 0.
In those cases, the parser only reads a frame
On 12.11.2020 22:19, Timo Rothenpieler wrote:
Are you sure this is necessary at all?
If apply_grain is 0, the value of those should be entirely irrelevant.
As in, just always set them, and just move the fg_header definition to
the top.
___
Are you sure this is necessary at all?
If apply_grain is 0, the value of those should be entirely irrelevant.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or
The spec in section 6.8.20 states the parameters should be loaded from a
reference frame indexed by film_grain_params_ref_idx.
Signed-off-by: James Almer
---
Untested.
libavcodec/nvdec_av1.c | 58 --
1 file changed, 33 insertions(+), 25 deletions(-)
We now have access to the raw frame header, so use that
Signed-off-by: James Almer
---
libavcodec/av1dec.c | 8 ++--
libavcodec/av1dec.h | 1 -
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 84c9ca93d5..c1967f03bd 100644
---
Signed-off-by: James Almer
---
libavcodec/av1dec.c | 14 ++
libavcodec/av1dec.h | 3 +++
2 files changed, 17 insertions(+)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index ad8e7d1dd5..84c9ca93d5 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -442,6 +442,8
Derek Buitenhuis:
> On 10/11/2020 10:46, Andreas Rheinhardt wrote:
>>
>> +#define INIT_VLC_STATIC_FROM_LENGTHS(vlc, bits, nb_codes, lens, len_wrap, \
>> + symbols, symbols_wrap, symbols_size, \
>> + offset, flags,
On 10/11/2020 10:46, Andreas Rheinhardt wrote:
>
> +#define INIT_VLC_STATIC_FROM_LENGTHS(vlc, bits, nb_codes, lens, len_wrap, \
> + symbols, symbols_wrap, symbols_size, \
> + offset, flags, static_size) \
> +
On Mon, 2020-11-09 at 22:53 +, Joakim Tjernlund wrote:
> On Sun, 2020-11-08 at 15:13 +0100, Michael Niedermayer wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you recognize the sender and know
> > the content is
On 11/12/2020 2:42 PM, Lynne wrote:
This patch introduces a new frame side data type AVFilmGrainParams for use
with video codecs which are able to use it.
It is generalized rather than being AV1 specific as AV2 is expected to carry
the same data, as well as the fact there already exist
Nov 12, 2020, 14:49 by jamr...@gmail.com:
> On 11/12/2020 8:59 AM, Lynne wrote:
>
>> +if (dav1d->apply_grain < 0 &&
>> +c->export_side_data & AV_CODEC_EXPORT_DATA_FILM_GRAIN)
>> +dav1d->apply_grain = 0;
>>
>
> Don't overwrite a Libdav1dContext field that was set by an
The other branch already covers cases where enable_order_hint is true
and frame is of type Inter.
Regression since ddb0e4fecdef24e8c7b90fa0a41d13e642ea732f
Fixes Coverity issues #1469194 and #1469195.
Signed-off-by: James Almer
---
libavcodec/cbs_av1_syntax_template.c | 3 ---
1 file changed,
On 11/12/2020 2:42 PM, Lynne wrote:
This patch is relatively straightforward with one exception:
the decoder option flag.
The option was introduced to troubleshoot but its existence is conflicting
and redundant now that we have a codec-generic flag.
Hence this patch deprecates it.
The way it
Signed-off-by: Andreas Rheinhardt
---
libavformat/asfdec_o.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/libavformat/asfdec_o.c b/libavformat/asfdec_o.c
index 9fd38f1bfe..655ba9f9ef 100644
--- a/libavformat/asfdec_o.c
+++ b/libavformat/asfdec_o.c
@@ -1542,14
A variable has been assigned a value twice consecutively; essentially
the same happens when one performs av_init_packet on an AVPacket after
a call to av_packet_unref.
Found via PVS-Studio (see ticket #8156).
Signed-off-by: Andreas Rheinhardt
---
This and the next one are old commits that are
The ASF specification of Metadata Objects' stream number is as follows:
"Specifies whether the entry applies to a specific digital media stream
or whether it applies to the whole file. A value of 0 in this field
indicates that it applies to the whole file; otherwise, the entry
applies only to the
The ASF file format has a limit of 127 streams and the "asf_o" demuxer
(the ASF demuxer from Libav) has an array of pointers for a structure
called ASFStream that is allocated on demand for every stream. Attached
pictures are not streams in the sense of the ASF specification, yet the
demuxer
Nov 12, 2020, 13:03 by andreas.rheinha...@gmail.com:
> Lynne:
>
>>
>> @@ -420,7 +485,7 @@ static av_cold int libdav1d_close(AVCodecContext *c)
>> static const AVOption libdav1d_options[] = {
>> { "tilethreads", "Tile threads", OFFSET(tile_threads), AV_OPT_TYPE_INT, {
>> .i64 = 0 }, 0,
Technically, libvmaf itself does not, but our filter does, and there is
no other sensible way to prevent a build with --enable-libvmaf from
succeeding while not actually enabling the filter.
---
configure | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
This patch is relatively straightforward with one exception:
the decoder option flag.
The option was introduced to troubleshoot but its existence is conflicting
and redundant now that we have a codec-generic flag.
Hence this patch deprecates it.
The way it interacts with
This patch introduces a new frame side data type AVFilmGrainParams for use
with video codecs able to offload film grain application during presentation.
It is generalized rather than being AV1 specific as AV2 is expected to carry
the same data, as well as the fact it was based on general
On 11/12/2020 8:58 AM, Lynne wrote:
This patch introduces a new frame side data type AVFilmGrainParams for use
with video codecs able to offload film grain application during presentation.
It is generalized rather than being AV1 specific as AV2 is expected to carry
the same data, as well as the
On 11/12/2020 11:34 AM, Lynne wrote:
Nov 12, 2020, 14:49 by jamr...@gmail.com:
On 11/12/2020 8:59 AM, Lynne wrote:
+if (dav1d->apply_grain < 0 &&
+c->export_side_data & AV_CODEC_EXPORT_DATA_FILM_GRAIN)
+dav1d->apply_grain = 0;
Don't overwrite a Libdav1dContext field
On 11/12/2020 8:59 AM, Lynne wrote:
This patch is relatively straightforward with one exception:
the decoder option flag.
The option was introduced to troubleshoot but its existence is conflicting
and redundant now that we have a codec-generic flag.
Hence this patch deprecates it.
The way it
On Thu, Nov 12, 2020 at 2:56 AM Carl Eugen Hoyos wrote:
> > Am 12.11.2020 um 00:41 schrieb David Michael :
> >> On Wed, Nov 11, 2020 at 6:20 PM Carl Eugen Hoyos
> >> wrote:
> >>> Am Mi., 11. Nov. 2020 um 16:30 Uhr schrieb David Michael
> >>> :
> >>> There are two issues:
> >>>
> >>> The unused
Hi Paul,
On Sat, Nov 07, 2020 at 00:27:15 +0100, Paul B Mahol wrote:
Just some minor grammar/spelling corrections:
> +This filter expands or compress each half-cycle of audio samples
compresses
> +(local set of samples all above or all bellow zero) depending on threshold
> value,
> +so audio
Lynne:
>
> @@ -420,7 +485,7 @@ static av_cold int libdav1d_close(AVCodecContext *c)
> static const AVOption libdav1d_options[] = {
> { "tilethreads", "Tile threads", OFFSET(tile_threads), AV_OPT_TYPE_INT,
> { .i64 = 0 }, 0, DAV1D_MAX_TILE_THREADS, VD },
> { "framethreads", "Frame
On 11.11.2020 17:15, Carl Eugen Hoyos wrote:
Not necessarily related: In no way whatsoever does the LGPL mandate
dynamic linking (this was claimed several times lately).
The "License Compliance Checklist" on http://ffmpeg.org/legal.html lists
dynamic linking under point 2.
I know that in
Ronald S. Bultje (12020-11-11):
> > Also, I believe it would be good for us internally, since it would
> > - allow other libraries to do IO cleanly without depending on lavf
> > - force us to clean up avio public API, which is not in a great shape
>
> Avio public API would be great, regardless of
---
It now works on x86-32
libswscale/x86/Makefile | 1 +
libswscale/x86/swscale.c| 75
libswscale/x86/yuv2yuvX.asm | 110
3 files changed, 121 insertions(+), 65 deletions(-)
create mode 100644 libswscale/x86/yuv2yuvX.asm
50 matches
Mail list logo
