The kernel defaults to initializing the field to 0 when modifiers
are not used and this happens to be linear. If we end up actually
passing the modifier to a driver, tiling issues happen.
So if the kernel doesn't return a modifier set it explicitly to
INVALID. That way later processing knows there
On Fri, Nov 13, 2020 at 07:50:16PM +0100, Marton Balint wrote:
>
>
> On Fri, 13 Nov 2020, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavdevice/decklink_dec_c.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
On 11/12/2020 3:22 PM, James Almer wrote:
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
This way we can pass explicit modifiers in. Sometimes the
modifier matters for the number of memory planes that
libva accepts, in particular when dealing with
driver-compressed textures. Furthermore the driver might
not actually be able to determine the implicit modifier
if all the buffer-passing h
As we get a new set of objects each frame anyway, we
do not gain anything by keeping the modifier constant.
This helps with capturing when switching your setup a
bit, e.g. from ingame to desktop or from X11 to wayland.
---
libavdevice/kmsgrab.c | 7 ---
1 file changed, 7 deletions(-)
diff --
On Fri, 13 Nov 2020, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavdevice/decklink_dec_c.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index f3fdcd3..6e43c9e 1
On Fri, Nov 13, 2020 at 05:44:44PM +1100, Peter Ross wrote:
> 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_THEOR
On Fri, Nov 13, 2020 at 05:37:39PM +1100, Peter Ross wrote:
> 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 pr
On Fri, Nov 13, 2020 at 05:36:59PM +1100, Peter Ross wrote:
> 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/l
James Almer (12020-11-13):
> I thought that was -lto behavior.
No, I am sure of what I am saying about classic static libraries. I do
not know link-time optimizations very well, but I suspect they relate to
optimizing withing a single object file.
> Don't think they were.
I strongly suspect some
On Fri, Nov 13, 2020 at 10:30:01PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavformat/rtsp.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
should be ok
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611
On Thu, Nov 12, 2020 at 09:33:18AM +0100, Alan Kelly wrote:
> ---
> It now works on x86-32
> libswscale/x86/Makefile | 1 +
> libswscale/x86/swscale.c| 75
> libswscale/x86/yuv2yuvX.asm | 110
> 3 files changed, 121 insertio
On 11/13/2020 11:40 AM, Nicolas George wrote:
James Almer (12020-11-13):
This results in a libavfilter binary that links to libvmaf for no reason,
potentially bloating it if it was linked statically.
That is not how static linking works. Static linking takes in the
library exactly the object f
Found-by: Anton
Signed-off-by: Michael Niedermayer
---
libavformat/avidec.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index 7e527e15ee..0ab7348d74 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -111,13 +111,6 @@ static c
On Fri, Nov 13, 2020 at 11:34:09AM -0300, James Almer wrote:
> On 11/13/2020 11:27 AM, lance.lmw...@gmail.com wrote:
> > On Fri, Nov 13, 2020 at 01:20:57PM +0100, Timo Rothenpieler wrote:
> > > On 13.11.2020 02:23, lance.lmw...@gmail.com wrote:
> > > > On Fri, Nov 13, 2020 at 02:14:05AM +0100, Timo
James Almer (12020-11-13):
> This results in a libavfilter binary that links to libvmaf for no reason,
> potentially bloating it if it was linked statically.
That is not how static linking works. Static linking takes in the
library exactly the object files required by the binary and other
object f
On 11/13/2020 11:27 AM, lance.lmw...@gmail.com wrote:
On Fri, Nov 13, 2020 at 01:20:57PM +0100, Timo Rothenpieler wrote:
On 13.11.2020 02:23, lance.lmw...@gmail.com wrote:
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
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/rtsp.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 5ef2f23..d9832bb 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -2247,9 +2247,7 @@ redo:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavdevice/decklink_dec_c.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index f3fdcd3..6e43c9e 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavde
On Fri, Nov 13, 2020 at 01:20:57PM +0100, Timo Rothenpieler wrote:
> On 13.11.2020 02:23, lance.lmw...@gmail.com wrote:
> > 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, T
Fixes: Timeout (>10sec -> 134ms)
Fixes:
27245/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CSCD_fuzzer-575318210772992
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cscd.c | 2 +-
1 fil
On 13.11.2020 02:23, lance.lmw...@gmail.com wrote:
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,
Please also add cuMemcpyAsync while at it.
What for and where is this needed?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.
Signed-off-by: leozhang
---
include/ffnvcodec/dynlink_cuda.h | 1 +
include/ffnvcodec/dynlink_loader.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/include/ffnvcodec/dynlink_cuda.h b/include/ffnvcodec/dynlink_cuda.h
index 117fdc5..1686894 100644
--- a/include/ffnvcodec/dynlink_cuda.h
24 matches
Mail list logo
