On 11/25/18, Mark Harris wrote:
> ---
> libavfilter/vf_chromashift.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_chromashift.c b/libavfilter/vf_chromashift.c
> index 068c3c1b68..d073256b99 100644
> --- a/libavfilter/vf_chromashift.c
> +++ b/libavfilte
On 11/25/18, Mark Harris wrote:
> ---
> libavformat/vivo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/vivo.c b/libavformat/vivo.c
> index c9e9c37f37..9b9189f307 100644
> --- a/libavformat/vivo.c
> +++ b/libavformat/vivo.c
> @@ -166,7 +166,7 @@ static int
On Sat, Nov 24, 2018 at 02:44:45 +0100, Timo Rothenpieler wrote:
> +// available then add/substract them here.
^ nit: subtract
> -{"extra_hw_frames", "Number of extra hardware frames to allocate for the
> user", OFFSET(extra_hw_frames), AV_OPT_TYPE
On Sat, Nov 24, 2018 at 2:23 PM René J.V. Bertin wrote:
> I have had my ML subscriptions set to not receive emails for a few years now.
> So when I got the invitation to vote (which I don't consider Spam btw) my
> first reflex was to confirm that I do not have any current issues with
> perceive
Fixes #7278.
Signed-off-by: Paul B Mahol
---
libavcodec/ac3dec.c | 19 ---
libavformat/ac3dec.c | 2 +-
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 43b22b7654..90e4dc8a1f 100644
--- a/libavcodec/ac3dec.c
+++ b/
On 24/11/18 01:44, Timo Rothenpieler wrote:
> ---
> libavcodec/decode.c| 9 +
> libavcodec/options_table.h | 2 +-
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index c89c77c43a..08ae8788a2 100644
> --- a/libavcodec
Hi,
The lone power8 fate failing test seems like an aliasing issue.
I've isolated it into the attached standalone test case. Compiling it
with
gcc -std=c11 -maltivec -mabi=altivec -mvsx -O3 -fno-tree-vectorize
-o test test.c
reproduces on gcc 8.2.0, dropping the optimization level fixes it. This
On Sun, 25 Nov 2018 17:17:58 +0200
Lauri Kasanen wrote:
> This code would probably crash on systems where unaligned access is
> prohibited, I think the incoming block is just 16-bit aligned.
I see the block comes from aligned malloc, so scratch that part, it's at
least 128-bit aligned.
- Lauri
If the frames context creation fails then the command queue reference
need not exist when uninit is called.
---
libavutil/hwcontext_opencl.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index c745b91775.
On 24/05/2018 15:26, Mironov, Mikhail wrote:
> AMD has published OpenCL extension which allows split D3D11 texture interoped
> as a single 2D image into two 2D images representing Y and UV planes.
> https://www.khronos.org/registry/OpenCL/extensions/amd/cl_amd_planar_yuv.txt
I had a go at impleme
On 7/4/18, Baptiste Coudurier wrote:
> ---
> libavformat/sccdec.c | 100 ---
> 1 file changed, 56 insertions(+), 44 deletions(-)
>
Will those scc patches be applied?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffm
This will enable us to change e.g. the parameter sets of H.2645 in ways
that would change the parsing process of future units. An example of
this is the h264_redundant_pps bsf.
The actual implementation of the underlying codec-dependent
make_writable functions is not contained in this commit.
Sign
2018-11-25 22:05 GMT+01:00, Andreas Rheinhardt
:
> +.make_writable = NULL,
Why do you think these are needed?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Since c6a63e11092c975b89d824f08682fe31948d3686, the parameter sets
modified as content of PPS units were references shared with the
CodedBitstreamH264Context, so modifying them alters the parsing process
of future access units which meant that frames often got discarded
because invalid values were
On Sat, Nov 24, 2018 at 11:31:16AM +0800, Jun Zhao wrote:
> Use AV_PKT_DATA_CPB_PROPERTIES to save max bit rate for esds box,
> and update fate at the same time.
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/isom.c | 19 ---
> tests/ref/fate/adtstoas
2018-11-24 18:44 GMT+01:00, Martin Vignali :
> Patch in attach fix prores-metadata test
> add bitexact mode, to avoid to write encoder in target mov
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpe
It seem that the failure is not in the new extension but before, in the interop
from D3D11 to OCL. It can happen in two cases: OCL device/context are created
without D3D11 device or format of the texture is not supported. NV12 is
supported. I went through the latest ffmpeg snapshot and found tha
Carl Eugen Hoyos:
> 2018-11-25 22:05 GMT+01:00, Andreas Rheinhardt
> :
>
>> +.make_writable = NULL,
>
> Why do you think these are needed?
>
> Carl Eugen
It's not needed. If left out, .make_writable will be implicitly initialized to
a NULL pointer because the various ff_cbs_type_xyz all
2018-11-25 22:44 GMT+01:00, Andreas Rheinhardt
:
> Carl Eugen Hoyos:
>> 2018-11-25 22:05 GMT+01:00, Andreas Rheinhardt
>> :
>>
>>> +.make_writable = NULL,
>>
>> Why do you think these are needed?
>>
> It's not needed. If left out, .make_writable will be implicitly initialized
> to a NULL po
---
libavutil/hwcontext_opencl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index e6cef74269..6a26354c87 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -542,9 +542,9 @@ stati
On 25/11/2018 21:28, Mironov, Mikhail wrote:
> It seem that the failure is not in the new extension but before, in the
> interop from D3D11 to OCL. It can happen in two cases: OCL device/context are
> created without D3D11 device or format of the texture is not supported. NV12
> is supported. I
On 25/11/2018 22:22, Mark Thompson wrote:
> On 25/11/2018 21:28, Mironov, Mikhail wrote:
>> It seem that the failure is not in the new extension but before, in the
>> interop from D3D11 to OCL. It can happen in two cases: OCL device/context
>> are created without D3D11 device or format of the tex
On Sat, Nov 24, 2018 at 08:59:50PM +0100, Martin Vignali wrote:
> proresdec2.c |5 +
> 1 file changed, 5 insertions(+)
> 99ab52ec787a2de79da37daa0e17c7885fcb558f
> 0010-avcodec-proresdec-align-height-buffer-to-16-avoid-se.patch
> From 3c319ed4ef51e25bccfa0b4fc50edf0bcebf2f0a Mon Sep 17 0
2018-11-25 16:17 GMT+01:00, Lauri Kasanen :
> Hi,
>
> The lone power8 fate failing test seems like an aliasing issue.
> I've isolated it into the attached standalone test case. Compiling it
> with
> gcc -std=c11 -maltivec -mabi=altivec -mvsx -O3 -fno-tree-vectorize
> -o test test.c
>
> reproduces o
On Sat, Nov 24, 2018 at 11:04:38PM +0100, Martin Vignali wrote:
> proresenc_anatoliy.c | 36 +++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
> 61e39289b0bfaafd515c5dab14805c1b4cdc0ad7
> 0012-avcodec-prores_aw-add-vendor-option.patch
> From cf9e3b3bc0c739c
On Sat, Nov 24, 2018 at 01:02:02PM -0800, Mark Harris wrote:
> The alloc_size attribute is valid only on functions that return a
> pointer. GCC 9 (not yet released) warns about invalid usage:
>
> ./libavutil/mem.h:342:1: warning: 'alloc_size' attribute ignored on a
> function returning int' [-Wa
On 11/25/2018 10:01 PM, Michael Niedermayer wrote:
> On Sat, Nov 24, 2018 at 01:02:02PM -0800, Mark Harris wrote:
>> The alloc_size attribute is valid only on functions that return a
>> pointer. GCC 9 (not yet released) warns about invalid usage:
>>
>> ./libavutil/mem.h:342:1: warning: 'alloc_size
On Sat, Nov 24, 2018 at 11:04:38PM +0100, Martin Vignali wrote:
> proresenc_anatoliy.c | 49 ++---
> 1 file changed, 46 insertions(+), 3 deletions(-)
> 44fe346a2be4d3d3ce2c903daf9cd599437627cc
> 0013-avcodec-prores_aw-only-set-color-prim-trc-space.pa
On 2018-11-25 17:29, James Almer wrote:
> On 11/25/2018 10:01 PM, Michael Niedermayer wrote:
>> On Sat, Nov 24, 2018 at 01:02:02PM -0800, Mark Harris wrote:
>>> The alloc_size attribute is valid only on functions that return a
>>> pointer. GCC 9 (not yet released) warns about invalid usage:
>>>
>>
On Sat, Nov 24, 2018 at 11:33:01AM +0200, Lauri Kasanen wrote:
> On Fri, 23 Nov 2018 23:01:02 +0100
> Michael Niedermayer wrote:
>
> > On Fri, Nov 23, 2018 at 10:38:13AM +0200, Lauri Kasanen wrote:
> > > I mean, if my patch adds no failures, is that enough to apply it?
> >
> > yes that and the t
Fixes: left shift of 255 by 24 places cannot be represented in type 'int'
Fixes:
11377/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5694319101476864
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niederm
On Mon, Nov 26, 2018 at 5:23 AM Michael Niedermayer
wrote:
>
> On Sat, Nov 24, 2018 at 11:31:16AM +0800, Jun Zhao wrote:
> > Use AV_PKT_DATA_CPB_PROPERTIES to save max bit rate for esds box,
> > and update fate at the same time.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavformat/isom.c
Signed-off-by: Ruiling Song
---
configure | 1 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/opencl/transpose.cl | 35 +
libavfilter/opencl_source.h | 1 +
libavfilter/transpose.h | 34 +
33 matches
Mail list logo
