CID: 1455685
Signed-off-by: Steven Liu
---
libavformat/av1dec.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
index a0cad55668..7cbc7ef9bf 100644
--- a/libavformat/av1dec.c
+++ b/libavformat/av1dec.c
@@ -193,7 +193,11 @@ retry
Steven Liu:
> CID: 1455685
> Signed-off-by: Steven Liu
> ---
> libavformat/av1dec.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
> index a0cad55668..7cbc7ef9bf 100644
> --- a/libavformat/av1dec.c
> +++ b/libavformat/av1
On 11/14/2019 7:24 AM, Steven Liu wrote:
> CID: 1455685
> Signed-off-by: Steven Liu
> ---
> libavformat/av1dec.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
> index a0cad55668..7cbc7ef9bf 100644
> --- a/libavformat/av1
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_lut3d.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 9e820a17c9..9ba86f7238 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter
From: Limin Wang
Signed-off-by: Limin Wang
---
have tested with x86_64(apple darwin, linux gcc), x86_32(linux), mips
tests/fate/filter-video.mak | 6 ++
tests/ref/fate/filter-pixfmts-lut1d | 24
tests/ref/fate/filter-pixfmts-lut3d | 24
From: Limin Wang
Signed-off-by: Limin Wang
---
tests/fate-run.sh | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index aec12c16a3..6ea0ab4f3c 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -385,6 +385,8 @@ pixfmts(
From: Limin Wang
Signed-off-by: Limin Wang
---
libswscale/swscale_unscaled.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index d9260c151a..d6d294f90c 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unsca
The current approach has two different calls to av_bsf_send_packet():
A normal one, sending a packet; and an extraordinary one just for
flushing. These can be unified into one by making use of the newly
documented fact that av_bsf_send_packet() allows to signal flushing via
empty packets (i.e. pack
to match its actual implementation.
Explicitly allowing empty packets to signal flushing helps getting rid
of special cases. It does not hinder the ability to send i.e.
timing-only packets, because one can send packets with zero size and
pkt->data set.
Signed-off-by: Andreas Rheinhardt
---
liba
On 11/14/2019 11:06 AM, Andreas Rheinhardt wrote:
> to match its actual implementation.
>
> Explicitly allowing empty packets to signal flushing helps getting rid
> of special cases. It does not hinder the ability to send i.e.
> timing-only packets, because one can send packets with zero size and
On 11/14/2019 11:06 AM, Andreas Rheinhardt wrote:
> The current approach has two different calls to av_bsf_send_packet():
> A normal one, sending a packet; and an extraordinary one just for
> flushing. These can be unified into one by making use of the newly
> documented fact that av_bsf_send_packe
to match its actual implementation.
Explicitly allowing empty packets to signal flushing helps getting rid
of special cases. It does not hinder the ability to send i.e.
timing-only packets, because one can send packets with zero size and
pkt->data set.
Signed-off-by: Andreas Rheinhardt
---
I use
On 11/14/2019 11:44 AM, Andreas Rheinhardt wrote:
> to match its actual implementation.
>
> Explicitly allowing empty packets to signal flushing helps getting rid
> of special cases. It does not hinder the ability to send i.e.
> timing-only packets, because one can send packets with zero size and
> -Original Message-
> From: ffmpeg-devel On Behalf Of Fu,
> Linjie
> Sent: Monday, November 11, 2019 17:43
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Async the
> encoding and output procedure of encoder
>
> > -Original Message-
> > From
This also works when passing the -format_code parameter.
On Wed, Nov 13, 2019 at 7:04 PM Ilinca Tudose wrote:
> My previous email was incorrect about "-wait_for_tc 1". The 2 commands
> used were:
>
> (1)
> ffmpeg -loglevel trace -timecode_format rp188any -wait_for_tc 1 -f
> decklink -probesize
Fixes: memleaks
Fixes:
18429/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-6210814364614656
Fixes:
18722/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5680535690543104
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/mast
Fixes: index 9 out of bounds for type 'const uint64_t [8][256]'
Fixes:
18409/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5767030560522240
Fixes:
18720/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5651995784642560
Found-by: continuous fuzzing process
ht
Fixes: signed integer overflow: 2147483188 + 2048 cannot be represented in type
'int'
Fixes:
18741/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUESPEECH_fuzzer-5748950460268544
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-
Fixes: out of array read
Fixes:
18715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5659333417500672
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/agm.c | 2 +-
1 file changed
Fixes: signed integer overflow: 2119056926 - -134217728 cannot be represented
in type 'int'
Fixes:
18728/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5747539563511808
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-b
On Wed, Nov 13, 2019 at 10:25:31AM +0800, Steven Liu wrote:
>
>
> > 在 2019年11月13日，09:02，myp...@gmail.com 写道：
> >
> > On Wed, Nov 13, 2019 at 7:24 AM Paul B Mahol wrote:
> >>
> >> On 11/13/19, Michael Niedermayer wrote:
> >>> On Tue, Nov 12, 2019 at 12:48:09PM +0100, Paul B Mahol wrote:
>
LGTM
On 11/14/19, Michael Niedermayer wrote:
> Fixes: out of array read
> Fixes:
> 18715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5659333417500672
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael
Set the option to false by default, to match libaomdec wrapper.
---
libavcodec/libdav1d.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index cf4b178f1d..5efa8eeb48 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -40,6 +40,7
On 11/14/2019 2:15 PM, Thierry Foucu wrote:
> Set the option to false by default, to match libaomdec wrapper.
> ---
> libavcodec/libdav1d.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
> index cf4b178f1d..5efa8eeb48 100644
> --- a/liba
On Wed, Nov 13, 2019 at 12:24:34AM +0100, Paul B Mahol wrote:
> On 11/13/19, Michael Niedermayer wrote:
> > On Tue, Nov 12, 2019 at 12:48:09PM +0100, Paul B Mahol wrote:
> >> If this filter is same speed or better than boxblur, it should replace
> >> boxblur filter, as boxblur filter is GPL.
> >
>
Patch proposed by Sitan Liu
---
libavcodec/amfenc_hevc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
index 7c9a33ab33..a9ccab168c 100644
--- a/libavcodec/amfenc_hevc.c
+++ b/libavcodec/amfenc_hevc.c
@@ -136,7 +136,7
On Thu, Nov 14, 2019 at 9:20 AM James Almer wrote:
> On 11/14/2019 2:15 PM, Thierry Foucu wrote:
> > Set the option to false by default, to match libaomdec wrapper.
> > ---
> > libavcodec/libdav1d.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/libavcodec/libdav1d.c b/libavc
Disable by default to output all the layers, to match libaomdec wrapper.
Add option to select the operating point for the spatial layers.
---
libavcodec/libdav1d.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index cf4b178f1d..ea4ef641bf
On 2019-11-14 20:19, James Almer wrote:
On 11/14/2019 2:15 PM, Thierry Foucu wrote:
Set the option to false by default, to match libaomdec wrapper.
---
libavcodec/libdav1d.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index cf4b178f1d.
On 14-11-2019 01:12 am, Michael Niedermayer wrote:
Moving and changing code at the same time makes it hard to see th difference.
Idealy all code moves should be seperate from changes to the code.
also more generally, spliting this patch up would simpify review
Split into two. First patch mos
On 11/14/2019 2:31 PM, Andrey Semashev wrote:
> On 2019-11-14 20:19, James Almer wrote:
>> On 11/14/2019 2:15 PM, Thierry Foucu wrote:
>>> Set the option to false by default, to match libaomdec wrapper.
>>> ---
>>> libavcodec/libdav1d.c | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff
On 2019-11-14 20:48, James Almer wrote:
On 11/14/2019 2:31 PM, Andrey Semashev wrote:
On 2019-11-14 20:19, James Almer wrote:
On 11/14/2019 2:15 PM, Thierry Foucu wrote:
Set the option to false by default, to match libaomdec wrapper.
---
libavcodec/libdav1d.c | 4
1 file changed, 4 i
Hi,
On Thu, Nov 14, 2019 at 2:12 PM Andrey Semashev
wrote:
> I think there needs to be some consistency across different lavc
> decoders. If we consider that lavc should produce one decoded frame per
> one encoded one, even if the encoded one contains multiple layers, then
> that should be true
Hello,
This patch is nearly identical to commit
02f909dc24b1f05cfbba75077c7707b905e63cd2, but is intended to backport
the fix for CVE-2019-17542 to ffmpeg version 3.4.6, which is in use on
RHEL 7 systems that get ffmpeg from rpmfusion.
https://github.com/FFmpeg/FFmpeg/commit/02f909dc24b1f05cfbba7
Hello,
This patch is nearly identical to commit
8df6884832ec413cf032dfaa45c23b1c7876670c, but is intended to backport
the fix for CVE-2019-17539 to ffmpeg version 3.4.6, which is in use on
RHEL 7 systems that get ffmpeg from rpmfusion.
https://github.com/FFmpeg/FFmpeg/commit/8df6884832ec413cf032d
On Thu, Nov 14, 2019 at 11:33 AM Ronald S. Bultje
wrote:
> Hi,
>
> On Thu, Nov 14, 2019 at 2:12 PM Andrey Semashev >
> wrote:
>
> > I think there needs to be some consistency across different lavc
> > decoders. If we consider that lavc should produce one decoded frame per
> > one encoded one, ev
Writing a unit (always a frame) in cbs_vp9 used an intermediate buffer
to write the frame header followed by the frame data that was copied
into said buffer. Afterwards, the final buffer for the frame was
allocated and everything copied into this buffer. But it is trivial to
compute the needed size
Hello,
I was wondering if anyone can verify whether or not CVE-2019-15942
affects ffmpeg version 3.4.6. From trac ticket 8093
(https://trac.ffmpeg.org/ticket/8093), it looks like it was a
"regression since 992532ee3122d7938a7581988eea401b57de8189". I'm not
well versed with git, but running "git
On Thu, Nov 14, 2019 at 9:31 PM James Boyle wrote:
> Hello,
>
> I was wondering if anyone can verify whether or not CVE-2019-15942
> affects ffmpeg version 3.4.6. From trac ticket 8093
> (https://trac.ffmpeg.org/ticket/8093), it looks like it was a
> "regression since 992532ee3122d7938a7581988ee
On Wed, 13 Nov 2019, Ilinca Tudose wrote:
My previous email was incorrect about "-wait_for_tc 1". The 2 commands used
were:
(1)
ffmpeg -loglevel trace -timecode_format rp188any -wait_for_tc 1 -f
decklink -probesize 15M -analyzeduration 5M -i "DeckLink Quad (1)" -t 30
-preset veryfast output
Hi,
On Wed, Nov 13, 2019 at 10:36 PM Limin Wang wrote:
> Please ignore the patch, I haven't used the old version. As vmaf library use
> libvmaf.pc, it better to keep it filename same, so let waiting vmaf to fix
> it.
Merged your PR over on the VMAF repo. This FFmpeg patch should be ignored.
Tha
On Wed, 13 Nov 2019, Gyan wrote:
As suggested in the review of an earlier patch*, this one drops frames till a
TC is seen.
From 0932db9d14dea215c1b0e5dcac4eac16cd6a Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Mon, 9 Sep 2019 18:33:09 +0530
Subject: [PATCH] avdevice/decklink: add
On Thu, Nov 14, 2019 at 09:46:22PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> have tested with x86_64(apple darwin, linux gcc), x86_32(linux), mips
tested on mingw32/64, qemu arm/mips
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730
On Thu, Nov 14, 2019 at 09:46:23PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libswscale/swscale_unscaled.c | 2 ++
> 1 file changed, 2 insertions(+)
probably ok
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC78704
BDMV does not seem to use it.
Signed-off-by: Marton Balint
---
doc/muxers.texi | 3 ++-
libavformat/mpegtsenc.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 4e76b40151..aa4bde518d 100644
--- a/doc/muxers.texi
+++ b/doc/mu
On Thu, Nov 14, 2019 at 11:12:23PM +0530, Gyan wrote:
>
>
> On 14-11-2019 01:12 am, Michael Niedermayer wrote:
> >Moving and changing code at the same time makes it hard to see th difference.
> >Idealy all code moves should be seperate from changes to the code.
> >
> >also more generally, splitin
On Thu, Nov 14, 2019 at 03:01:29PM -0500, James Boyle wrote:
> Hello,
>
> This patch is nearly identical to commit
> 8df6884832ec413cf032dfaa45c23b1c7876670c, but is intended to backport
> the fix for CVE-2019-17539 to ffmpeg version 3.4.6, which is in use on
> RHEL 7 systems that get ffmpeg from
On Fri, Nov 15, 2019 at 1:26 AM Michael Niedermayer
wrote:
>
> On Wed, Nov 13, 2019 at 12:24:34AM +0100, Paul B Mahol wrote:
> > On 11/13/19, Michael Niedermayer wrote:
> > > On Tue, Nov 12, 2019 at 12:48:09PM +0100, Paul B Mahol wrote:
> > >> If this filter is same speed or better than boxblur,
On 15-11-2019 04:01 am, Michael Niedermayer wrote:
On Thu, Nov 14, 2019 at 11:12:23PM +0530, Gyan wrote:
On 14-11-2019 01:12 am, Michael Niedermayer wrote:
Moving and changing code at the same time makes it hard to see th difference.
Idealy all code moves should be seperate from changes to t
On 15-11-2019 03:02 am, Marton Balint wrote:
On Wed, 13 Nov 2019, Ilinca Tudose wrote:
My previous email was incorrect about "-wait_for_tc 1". The 2
commands used
were:
(1)
ffmpeg -loglevel trace -timecode_format rp188any -wait_for_tc 1 -f
decklink -probesize 15M -analyzeduration 5M -i
On 15-11-2019 03:23 am, Marton Balint wrote:
On Wed, 13 Nov 2019, Gyan wrote:
As suggested in the review of an earlier patch*, this one drops
frames till a TC is seen.
From 0932db9d14dea215c1b0e5dcac4eac16cd6a Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Mon, 9 Sep 2019 18:33:0
From: fgodt
Signed-off-by: fgodt
---
libavdevice/gdigrab.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index f406fa..0ab0cfed01 100644
--- a/libavdevice/gdigrab.c
+++ b/libavdevice/gdigrab.c
@@ -53,6 +53,8 @@
> 在 2019年11月3日，20:14，Marton Balint 写道：
>
>
>
> On Fri, 25 Oct 2019, Ole Andre Birkedal wrote:
>
>> I think this is the best solution, with just one new flag +utc_pdt that will
>> force timestamps of PDT to be in UTC with the format -MM-DDThh:mm:ssZ.
>> Too many flags will be confusing,
53 matches
Mail list logo
