> 2020年11月26日 下午12:43，Vignesh Ravichandran
> 写道：
>
> This check may not be enough. The below values would pass the check which
> should not be the case:
> 20-11-26T08:34:00.000
> 2020-11-26T8:34:00.000
> 2020-11-26T08:60:00.000
> 2020-11-26T08:60:0.000
> 2020-13-26T08:34:00.000
>
> The regex
spec did not forbid this.
Here is da1vd code:
https://code.videolan.org/videolan/dav1d/-/blob/master/src/obu.c#L1057
If update_grain == 0, it will copy film grain data from the reference
frame to the current frame.
Maybe we can do the same thing on CBS, Other acceleration like vaapi,
will get ben
User may use '-disable_film_grain 1' to disable film grain.
---
libavcodec/qsvdec.c | 5 +
libavcodec/qsvdec.h | 2 ++
libavcodec/qsvdec_other.c | 13 -
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index c666
---
libavcodec/qsvdec.h | 13 +
libavcodec/qsvdec_h2645.c | 12 ++--
libavcodec/qsvdec_other.c | 6 +-
3 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/libavcodec/qsvdec.h b/libavcodec/qsvdec.h
index f3b7344cba..10e8cf7f91 100644
--- a/libavcodec/qsvd
This check may not be enough. The below values would pass the check which
should not be the case:
20-11-26T08:34:00.000
2020-11-26T8:34:00.000
2020-11-26T08:60:00.000
2020-11-26T08:60:0.000
2020-13-26T08:34:00.000
The regex check approach mentioned earlier checks:
1. The value is in "-MM-DDThh
Nov 26, 2020, 01:02 by jamr...@gmail.com:
> On 11/25/2020 8:00 PM, Lynne wrote:
>
>> Our struct is a [2][25], libdav1d's is a [2][25 + 3] so the last 3
>> v coefficients were missing.
>> Copy each plane's coefficients separately.
>>
>> Patch attached.
>>
>
> Ok if tested to match values after copy
Our struct is a [2][25], libdav1d's is a [2][25 + 3] so the last 3
v coefficients were missing.
Copy each plane's coefficients separately.
Patch attached.
>From 5197be53406921513eec9277b029eefc1deec5c6 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Wed, 25 Nov 2020 23:46:29 +0100
Subject: [PATCH] l
> 2020年11月25日 下午9:57，Vignesh Ravichandran 写道：
>
> Sure, how about the snippet below:
>
> regex_t regex;
> regcomp(®ex,
> "([12][0-9]{3}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])T([01][1-9]|2[0-3]):([0-5][0-9]):([0-5][0-9]).([0-9]{3}))",
> REG_EXTENDED);
> if (regexec(®ex, ptr, 0, NULL, 0) == RE
Nov 20, 2020, 18:26 by d...@lynne.ee:
> This improves performance and helps a little when given FDs without
> any synchronization fences.
>
> Patch attached.
>
Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/lis
Nov 25, 2020, 12:50 by ffm...@haasn.xyz:
> From: Niklas Haas
>
> These two extensions and two features are both optionally used by
> libplacebo to speed up rendering, so it makes sense for libavutil to
> automatically enable them as well.
>
Thanks, pushed.
___
Nov 23, 2020, 17:02 by d...@lynne.ee:
> Nov 23, 2020, 15:06 by jamr...@gmail.com:
>
>> On 11/23/2020 9:08 AM, Lynne wrote:
>>
>>
>>> From e11df30e25f1b27a4ec3efb7dc894b8cf59113d2 Mon Sep 17 00:00:00 2001
>>> From: Lynne
>>> Date: Thu, 12 Nov 2020 12:44:30 +0100
>>> Subject: [PATCH v3 1/4] libavut
On Wed, Nov 04, 2020 at 01:06:43AM +0100, Michael Niedermayer wrote:
> Fixes: left shift of 65536 by 15 places cannot be represented in type 'int'
> Fixes:
> 26801/clusterfuzz-testcase-minimized-ffmpeg_dem_MPC8_fuzzer-5164313092030464
>
> Found-by: continuous fuzzing process
> https://github.com
On Fri, Oct 30, 2020 at 10:52:04PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -4683718486770919638 * 2 cannot be
> represented in type 'long'
> Fixes:
> 26704/clusterfuzz-testcase-minimized-ffmpeg_dem_MPC8_fuzzer-6327056939614208
>
> Found-by: continuous fuzzing process
On Fri, Oct 30, 2020 at 10:52:03PM +0100, Michael Niedermayer wrote:
> Fixes: leak in mov_read_dref()
> Fixes:
> 26698/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5638785444085760
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
On 11/25/2020 8:00 PM, Lynne wrote:
Our struct is a [2][25], libdav1d's is a [2][25 + 3] so the last 3
v coefficients were missing.
Copy each plane's coefficients separately.
Patch attached.
Ok if tested to match values after copying.
___
ffmpeg-deve
Cosmetic change in preparation for the following patches.
Signed-off-by: James Almer
---
libavcodec/cbs_av1.h | 62 +++-
libavcodec/cbs_av1_syntax_template.c | 7 ++--
libavcodec/nvdec_av1.c | 59 +-
3 files changed,
This reverts commit f9eec6298387fe72cd8035ff45276cfc3da784a8.
This does not effectively cover all cases. The values for some frames need
to be inferred by the decoder.
Signed-off-by: James Almer
---
libavcodec/nvdec_av1.c | 57 +++---
1 file changed, 26 inser
They are not always coded in the bistream for each frame. In some cases, the
values need to be taken from a reference frame.
See section 6.8.20 from the AV1 spec.
Signed-off-by: James Almer
---
libavcodec/av1dec.c | 25 +
libavcodec/av1dec.h | 2 ++
2 files changed, 27
Signed-off-by: James Almer
---
libavcodec/dxva2_av1.c | 63 +-
1 file changed, 32 insertions(+), 31 deletions(-)
diff --git a/libavcodec/dxva2_av1.c b/libavcodec/dxva2_av1.c
index c6cbd48f5f..72c38f5d12 100644
--- a/libavcodec/dxva2_av1.c
+++ b/libavcodec/
Signed-off-by: James Almer
---
libavcodec/nvdec_av1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/nvdec_av1.c b/libavcodec/nvdec_av1.c
index 1bac1fe26c..bd920d814a 100644
--- a/libavcodec/nvdec_av1.c
+++ b/libavcodec/nvdec_av1.c
@@ -42,7 +42,7 @@ static int nvde
From: Sebastian Dröge
Instead of failing to parse such CDP packets, simply skip over the time
code data and read the CC data following it.
Also add some more length checks in related to this and the existing
parsing code to prevent reading out of bounds memory.
---
libavdevice/decklink_dec.cpp
On Mon, Nov 23, 2020 at 2:49 PM Wonkap Jang
wrote:
>
> Hi James,
>
> On Wed, Nov 18, 2020 at 1:13 PM James Zern
> wrote:
>
> > Hi,
> >
> > On Mon, Nov 16, 2020 at 2:36 PM Wonkap Jang
> > wrote:
> > >
> > > In order to fine-control referencing schemes in VP9 encoding, there
> > > is a need to use
On 11/24/2020 5:59 AM, Guangxin Xu wrote:
Hi Hendrik,
two related questions:
1. Seems it's a generic code. Could we handle this in the av1dec.c?
2. For the current code, what's happened if frame A ref to B, B ref to C.
and both A, B has update_grain == 0.
Is that considered a valid bitstream?
Sure, how about the snippet below:
regex_t regex;
regcomp(®ex,
"([12][0-9]{3}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])T([01][1-9]|2[0-3]):([0-5][0-9]):([0-5][0-9]).([0-9]{3}))",
REG_EXTENDED);
if (regexec(®ex, ptr, 0, NULL, 0) == REG_NOMATCH) {
ret = AVERROR_INVALIDDATA;
goto fail;
}
On Wed,
> 2020年11月25日 下午7:49，Vignesh Ravichandran 写道：
>
> We could add a simple check like below to prevent it:
>
> if (sscanf(ptr, "%d-%d-%dT%d:%d:%d.%lf", &y, &M, &d, &h, &m, &s, &ms) != 7)
> {
> ret = AVERROR_INVALIDDATA;
> goto fail;
> }
>
> Please let me know.
Not sure this is better way, what
From: Niklas Haas
This filter conceptually maps the libplacebo `pl_renderer` API into
libavfilter, which is a high-level image rendering API designed to
produce RGB output. As such, there's no way to avoid e.g. chroma
interpolation with this filter.
That being said, `pl_renderer` supports automa
From: Niklas Haas
These two extensions and two features are both optionally used by
libplacebo to speed up rendering, so it makes sense for libavutil to
automatically enable them as well.
---
libavutil/hwcontext_vulkan.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavutil/hwconte
We could add a simple check like below to prevent it:
if (sscanf(ptr, "%d-%d-%dT%d:%d:%d.%lf", &y, &M, &d, &h, &m, &s, &ms) != 7)
{
ret = AVERROR_INVALIDDATA;
goto fail;
}
Please let me know.
Thanks,
Vignesh
On Wed, Nov 25, 2020 at 11:29 AM Steven Liu wrote:
>
>
> > 2020年11月25日 下午1:16，Vig
28 matches
Mail list logo
