Fixes: floating point division by 0
Fixes: Ticket8213
Signed-off-by: Michael Niedermayer
---
libavcodec/lpc.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/lpc.h b/libavcodec/lpc.h
index 52170fd623..c99e568794 100644
--- a/libavcodec/lpc.h
+++ b/libavcodec/lpc.
Fixes: invalid shifts
Fixes: Ticket 8221
Signed-off-by: Michael Niedermayer
---
libavcodec/vc2enc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 2de6d4b17a..f0d2cdf62d 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -982,6 +9
Fixes: floating point division by 0
Fixes: Ticket8218
Signed-off-by: Michael Niedermayer
---
libavcodec/aaccoder.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/aaccoder.c b/libavcodec/aaccoder.c
index baa82489b1..11b0559e1c 100644
--- a/libavcodec/aaccod
On Mon, May 31, 2021 at 09:22:09AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-05-28 22:15:51)
> > Fixes: Ticket8003
> > Fixes: CVE-2020-20453
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/aacenc.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-
On Mon, May 31, 2021 at 09:55:15AM +0200, Anton Khirnov wrote:
> ---
> libavfilter/vf_scale.c | 182 +++--
> 1 file changed, 141 insertions(+), 41 deletions(-)
breaks: (lower 50% is bright green)
./ffplay -i mm-short.mpg -an -vf "tinterlace,scale=720:576:inte
On Tuesday, 25 May 2021 9:16:35 PM AEST Brad Hards wrote:
> Signed-off-by: Brad Hards
> ---
> libavcodec/nvenc.c | 71 +-
> libavcodec/nvenc.h | 2 ++
> 2 files changed, 60 insertions(+), 13 deletions(-)
>
> diff --git a/libavcodec/nvenc.c b/libavcode
On 01.06.2021 11:51, Brad Hards wrote:
Anything more on this version?
Brad
No, but we're investigating weird crashes that are caused by the s12m
timecodes _somehow_, so I'm holding off on merging any other changes in
that area until it's figured out.
smime.p7s
Description: S/MIME Crypto
On Mon, May 31, 2021 at 09:54:52AM +0200, Anton Khirnov wrote:
> There used to be more code inside them, but it was removed in
> 6de58b49032a206985602effec91e5e46c886ea2.
> ---
> libswscale/swscale.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
LGTM
thx
[...]
--
Michael Gn
On Mon, May 31, 2021 at 09:54:53AM +0200, Anton Khirnov wrote:
> ---
> libswscale/swscale.c | 150 ++-
> 1 file changed, 77 insertions(+), 73 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Take awa
On Mon, May 31, 2021 at 09:54:54AM +0200, Anton Khirnov wrote:
> ---
> libswscale/swscale.c | 100 +--
> 1 file changed, 50 insertions(+), 50 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Never tr
On Mon, May 31, 2021 at 09:54:55AM +0200, Anton Khirnov wrote:
> ---
> libswscale/swscale.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its not that you shouldnt use gotos but rather that you should
On Tuesday, 1 June 2021 8:01:13 PM AEST Timo Rothenpieler wrote:
> No, but we're investigating weird crashes that are caused by the s12m
> timecodes _somehow_, so I'm holding off on merging any other changes in
> that area until it's figured out.
Do you have a repro? Obviously motivated to unblock
On Mon, May 31, 2021 at 09:54:56AM +0200, Anton Khirnov wrote:
> ---
> libswscale/swscale.c | 53 +---
> 1 file changed, 30 insertions(+), 23 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us c
On Mon, May 31, 2021 at 09:54:59AM +0200, Anton Khirnov wrote:
> Reindent after previous commit, rewrap long lines.
> ---
> libswscale/swscale.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC78
On Mon, May 31, 2021 at 09:54:58AM +0200, Anton Khirnov wrote:
> ---
> libswscale/swscale.c | 29 ++---
> 1 file changed, 18 insertions(+), 11 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If the United States is
On Mon, May 31, 2021 at 09:55:01AM +0200, Anton Khirnov wrote:
> Also, fail with an error code rather than 0.
> ---
> libswscale/swscale.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC78
On 01.06.2021 12:46, Brad Hards wrote:
On Tuesday, 1 June 2021 8:01:13 PM AEST Timo Rothenpieler wrote:
No, but we're investigating weird crashes that are caused by the s12m
timecodes _somehow_, so I'm holding off on merging any other changes in
that area until it's figured out.
Do you have a r
On Mon, May 31, 2021 at 09:55:02AM +0200, Anton Khirnov wrote:
> ---
> libswscale/swscale.c | 20
> libswscale/swscale_internal.h | 6 ++
> libswscale/utils.c| 3 +++
> 3 files changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/libswscale/sw
On Mon, May 31, 2021 at 09:55:05AM +0200, Anton Khirnov wrote:
> ---
> libswscale/swscale.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, an
On Mon, May 31, 2021 at 09:55:06AM +0200, Anton Khirnov wrote:
> Also, return an error code on failure rather than 0.
> ---
> libswscale/swscale.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7870
On Mon, May 31, 2021 at 09:55:07AM +0200, Anton Khirnov wrote:
> ---
> libswscale/swscale.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
ok
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the li
On Mon, May 31, 2021 at 09:55:08AM +0200, Anton Khirnov wrote:
> Place it right after the input parameter validation. There is no point
> in performing any setup if the sws_scale() call won't do anything.
> ---
> libswscale/swscale.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
On Mon, May 31, 2021 at 09:55:09AM +0200, Anton Khirnov wrote:
> It does not interact in any way with the code setting up the image
> pointers/strides, so it should not be intermixed with it.
> ---
> libswscale/swscale.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
ok
thx
[..
On Mon, May 31, 2021 at 09:55:10AM +0200, Anton Khirnov wrote:
> It does not interact in any way with the code setting up the image
> pointers/strides, so it should not be intermixed with it.
> ---
> libswscale/swscale.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
ok
thx
[...]
On Mon, May 31, 2021 at 09:55:12AM +0200, Anton Khirnov wrote:
> ---
> libavfilter/vf_scale.c | 25 ++---
> 1 file changed, 14 insertions(+), 11 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little
On Mon, May 31, 2021 at 09:55:03AM +0200, Anton Khirnov wrote:
> Call the scaler function directly rather than through a function
> pointer. Drop the now-unused return value from ff_getSwsFunc() and
> rename the function to reflect its new role.
>
> This will be useful in the following commits, wh
On Mon, May 31, 2021 at 09:55:11AM +0200, Anton Khirnov wrote:
> Currently existing sws_scale() accepts as input a user-determined slice
> of input data and produces an indeterminate number of output lines.
swscale() should return the number of lines output
it does "return dstY - lastDstY;"
> Si
> -原始邮件-
> 发件人: "Jin Bo"
> 发送时间: 2021-05-28 10:04:41 (星期五)
> 收件人: ffmpeg-devel@ffmpeg.org
> 抄送: "Jin Bo"
> 主题: [FFmpeg-devel] [PATCH 3/3] libavcodec/mips: Fix fate errors reported
by clang
>
> The data width of gsldrc1/gsldlc1 should be 8 bytes wide.
>
> Signed-off-by: Jin Bo
> ---
>
They should not be accessed outside of libavformat.
Signed-off-by: James Almer
---
fftools/ffmpeg.c | 10 ++
fftools/ffmpeg.h | 1 +
fftools/ffmpeg_opt.c | 1 +
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index b3658d8f65..
This solves the memory leak reported in https://trac.ffmpeg.org/ticket/9273
Signed-off-by: Robert Bengtsson-Ölund
---
libavformat/http.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 1fc95c768c..476b9a8456 100644
--- a/liba
hldr -> hdlr
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7d839f447b..04f3e94158 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2804,7 +2804,7 @@ static int mov_write_hdlr_tag(AVForm
On 2021-06-01 23:36, Joel Linn wrote:
hldr -> hdlr
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7d839f447b..04f3e94158 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2804,7 +2
On 2021-06-01 23:44, Gyan Doshi wrote:
On 2021-06-01 23:36, Joel Linn wrote:
hldr -> hdlr
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7d839f447b..04f3e94158 100644
--- a/libavformat/movenc.c
Updated FATE hashes and added gamma 2.8. Also please note that FATE
samples are useless. I also fixed gamma 2.2 to System M.
Also this does not do YCbCr stuff, so no matrices are here.
Fixes more or less #6023, except for printing density stuff.
Co-authored-by: Paul B Mahol
---
libavcodec/dpxenc
On Tuesday, 1 June 2021 10:11:08 PM AEST Timo Rothenpieler wrote:
> On 01.06.2021 12:46, Brad Hards wrote:
> > On Tuesday, 1 June 2021 8:01:13 PM AEST Timo Rothenpieler wrote:
> >> No, but we're investigating weird crashes that are caused by the s12m
> >> timecodes _somehow_, so I'm holding off on
On 02.06.2021 00:29, Brad Hards wrote:
Is that consistent with the problem you are seeing?
Brad
It matches the backtrace on both linux and Windows.
Something deep inside the nvidia driver is doing an invalid read.
smime.p7s
Description: S/MIME Cryptographic Signature
__
On Fri, May 28, 2021 at 4:49 AM Michael Niedermayer
wrote:
> On Thu, May 27, 2021 at 09:44:10AM -0700, Mohammad Izadi wrote:
> > HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> should be passed to pac
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
Signed-off-by: Wenlong Ding
---
libavfilter/dnn/Makefile | 1 +
libavfilter/dnn/dnn_backend_native.h | 1 +
..._backend_native_layer_batchnormalization.c | 119 ++
..._backend_native_layer_batchnormalization.h | 44 +++
libavfilter/dnn/dnn_ba
Signed-off-by: Wenlong Ding
---
tests/dnn/.gitignore | 1 +
tests/dnn/Makefile| 1 +
tests/dnn/dnn-layer-batchnormalization-test.c | 117 ++
tests/fate/dnn.mak| 5 +
4 files changed, 124 inserti
On 2021-05-31 23:52, Gyan Doshi wrote:
Plan to push tomorrow.
Pushed as 071930de724166bfb90fc6d368c748771188fd94
On 2021-05-29 14:34, Gyan Doshi wrote:
---
I faced the same issue as the poster in
https://lists.ffmpeg.org/pipermail/ffmpeg-user/2018-March/039038.html
After patch, start_
These two patches check if a DirectShow device provides color
information and sets this in the AVStream. If a device provides equivalent
formats with and without color information, the format with color information
is used.
I'm a first-time contributor, hope all is in order.
Example output of l
Some DirectShow devices (Logitech C920 webcam) expose each DirectShow format
they support twice, once without and once with extended color information.
During format selection, both match, this patch ensures that the format with
extended color information is selected if it is available, else it
43 matches
Mail list logo
