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,
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
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 +++
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
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
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 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
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
---
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
---
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
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
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
---
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
-原始邮件-
发件人: "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
---
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;"
>
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,
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: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: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: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: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
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:
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,
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
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
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:
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
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:
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
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: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
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
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
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
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
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
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
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
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
---
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
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
+++
Am 31.05.21 um 20:54 schrieb Lynne:
> May 31, 2021, 19:59 by nomis...@web.de:
>
>> Hi everyone. Back in March 2020 a set of patches for AC-4 support into
>> FFmpeg was posted on this
>> list. As these patches are not integrated in FFmpeg the HandBrake team was
>> considering if we should
>> add
>On 5/31/21, 6:00 PM, "Przemysław Sobala" wrote:
>
>Could any maintainer take a look at that?
Pushed with minor indentation changes.
Thanks,
Karthick
>--
>Best regards
>Przemysław Sobala
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Clang is more strict on the type of asm operands, float or double
type variable should use constraint 'f', integer variable should
use constraint 'r'.
Signed-off-by: Jin Bo
---
libavcodec/mips/constants.c | 89 +++--
libavcodec/mips/constants.h | 88 +++--
44 matches
Mail list logo
