On 6/10/17, James Darnley wrote:
> On 2017-06-09 13:41, Ivan Kalvachev wrote:
>> On 6/9/17, Michael Niedermayer wrote:
>>> seems this breaks build with mingw64, didnt investigate but it
>>> fails with these errors:
>>>
>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_sea
On Sun, Jun 11, 2017 at 11:34 AM, Ivan Kalvachev wrote:
> On 6/10/17, James Darnley wrote:
>> On 2017-06-09 13:41, Ivan Kalvachev wrote:
>>> On 6/9/17, Michael Niedermayer wrote:
seems this breaks build with mingw64, didnt investigate but it
fails with these errors:
libavcode
On 6/11/17, Hendrik Leppkes wrote:
> On Sun, Jun 11, 2017 at 11:34 AM, Ivan Kalvachev
> wrote:
>> On 6/10/17, James Darnley wrote:
>>> On 2017-06-09 13:41, Ivan Kalvachev wrote:
On 6/9/17, Michael Niedermayer wrote:
> seems this breaks build with mingw64, didnt investigate but it
>
On Fri, Jun 09, 2017 at 09:07:39PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Jun 8, 2017 at 8:57 PM, Michael Niedermayer
> wrote:
>
> > On Thu, Jun 08, 2017 at 06:35:07PM -0400, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Thu, Jun 8, 2017 at 6:10 PM, Michael Niedermayer
> >
> > > wr
On Sun, 11 Jun 2017 03:58:30 +0300
Ivan Kalvachev wrote:
> Of course, as FFmpeg developer, it is your right to initiate a vote
> that would prevent Michael from trying to make FFmpeg more secure.
> He has always complied with official decisions.
Nothing but polemic nonsense intended to scare oth
On Sun, 11 Jun 2017 13:26:44 +0200
Michael Niedermayer wrote:
> Iam fighting on this issue because i see this pushing FFmpeg into a
> direction where the code is harder to understand and harder to maintain
> and we already have many open bugs
That's funny, because whenever I see something strang
On Sun, 11 Jun 2017 05:24:16 +
"LongChair ." wrote:
> From: LongChair
>
> ---
> Changelog | 1 +
> configure | 12 ++
> libavcodec/Makefile| 4 +
> libavcodec/allcodecs.c | 6 +
> libavcodec/drmprime.h | 17 ++
> libavcodec/rkmppdec.c | 522
> ++
On 6/11/17, Michael Niedermayer wrote:
> On Fri, Jun 09, 2017 at 09:07:39PM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Thu, Jun 8, 2017 at 8:57 PM, Michael Niedermayer
>>
>> wrote:
>>
>> > On Thu, Jun 08, 2017 at 06:35:07PM -0400, Ronald S. Bultje wrote:
>> > > Hi,
>> > >
>> > > On Thu, Jun 8
Fixes CID 1396855
---
libavfilter/unsharp_opencl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/unsharp_opencl.c b/libavfilter/unsharp_opencl.c
index d84920c590..1545455846 100644
--- a/libavfilter/unsharp_opencl.c
+++ b/libavfilter/unsharp_opencl.c
@@ -43,7
Fixes CID 1396840
---
libavutil/opencl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/opencl.c b/libavutil/opencl.c
index af35770e06..202756516b 100644
--- a/libavutil/opencl.c
+++ b/libavutil/opencl.c
@@ -169,7 +169,7 @@ const char *av_opencl_errstr(cl_int status)
Fixes CIDs 1396414 and 1396415
---
libavfilter/vf_scale_npp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_scale_npp.c b/libavfilter/vf_scale_npp.c
index b5acce653b..c36772e800 100644
--- a/libavfilter/vf_scale_npp.c
+++ b/libavfilter/vf_scale_npp.c
@@ -400,7
Fixes CID 1403236
---
libavfilter/vf_signature.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_signature.c b/libavfilter/vf_signature.c
index f0078ba1a6..c20b0bfabb 100644
--- a/libavfilter/vf_signature.c
+++ b/libavfilter/vf_signature.c
@@ -576,7 +576,7 @@ sta
Fixes CID 1396267
---
libavformat/pcmdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/pcmdec.c b/libavformat/pcmdec.c
index 3c7e8ac84b..d0ceea6fa9 100644
--- a/libavformat/pcmdec.c
+++ b/libavformat/pcmdec.c
@@ -68,6 +68,7 @@ static int pcm_read_header(AVFormatContext *s)
Fixes CIDs 1403238 and 1403239
---
libavfilter/signature_lookup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index 272c717c77..7de4a88ca2 100644
--- a/libavfilter/signature_lookup.c
+++ b/libavfilter/signature
Fixes CID 1396837
---
libavformat/librtmp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/librtmp.c b/libavformat/librtmp.c
index 146df660ac..f3cfa9a8e2 100644
--- a/libavformat/librtmp.c
+++ b/libavformat/librtmp.c
@@ -239,7 +239,10 @@ static int rtmp_open(UR
Fixes CIDs 1403234 and 1403235
---
libavfilter/vf_signature.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_signature.c b/libavfilter/vf_signature.c
index 06b1b910d4..f0078ba1a6 100644
--- a/libavfilter/vf_signature.c
+++ b/libavfilter/vf_signature.c
@@ -26
Fixes CID 1400440
---
libavcodec/vaapi_encode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 7e9c00f51d..9336bbecd4 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -738,7 +738,7 @@ fail:
s
Fixes CID 1404889
---
libavcodec/h264_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 2564c6c6c3..1a304f318f 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -155,7 +155,7 @@ found:
stati
Fixes CID 1409924
---
libavcodec/dcaadpcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dcaadpcm.c b/libavcodec/dcaadpcm.c
index 8742c7ccf6..aff737ddb6 100644
--- a/libavcodec/dcaadpcm.c
+++ b/libavcodec/dcaadpcm.c
@@ -80,7 +80,7 @@ static int64_t find_best_filte
On 6/9/2017 6:35 PM, Vittorio Giovara wrote:
> Signed-off-by: Vittorio Giovara
> ---
> libavcodec/hevc_sei.c | 9 +
> libavcodec/hevc_sei.h | 7 +++
> libavcodec/hevcdec.c | 5 +
> 3 files changed, 21 insertions(+)
>
> diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
>
On 11/06/17 15:07, Timo Rothenpieler wrote:
> Fixes CID 1404889
> ---
> libavcodec/h264_parser.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
> index 2564c6c6c3..1a304f318f 100644
> --- a/libavcodec/h264_parser.c
> ++
Seems dubious? That is not a small structure, and it's being used essentially
write-only here to skip over an unwanted part of the slice header - since it
will only ever write to a small proportion of the elements, initialising all of
them to zero feels like a waste.
(The only argument in Cov
This reduces the worst case from O(n²) to O(n) time
Fixes Timeout
Fixes: 2127/clusterfuzz-testcase-minimized-6595787859427328
Signed-off-by: Michael Niedermayer
---
libavcodec/htmlsubtitles.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/libavcodec/ht
On 11/06/17 16:12, Timo Rothenpieler wrote:
>> Seems dubious? That is not a small structure, and it's being used
>> essentially write-only here to skip over an unwanted part of the slice
>> header - since it will only ever write to a small proportion of the
>> elements, initialising all of them
Also return an error if the weight denominator is incorrect, rather
than overriding it with zero and continuing.
---
libavcodec/h264_parse.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
index 3d2007
On 6/11/17, Timo Rothenpieler wrote:
> Fixes CID 1396267
> ---
> libavformat/pcmdec.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/pcmdec.c b/libavformat/pcmdec.c
> index 3c7e8ac84b..d0ceea6fa9 100644
> --- a/libavformat/pcmdec.c
> +++ b/libavformat/pcmdec.c
> @@ -68,6 +
Fixes ticket #6413
Signed-off-by: James Almer
---
The public key authentication also tries to use the password variable. I
don't know if NULL is valid in that case or not.
Perhaps for that one it would be better to replace the current usage of
legacy API instead.
libavformat/libssh.c | 2 +-
1
On 6/3/2017 2:40 PM, James Almer wrote:
> On 5/27/2017 7:00 PM, James Almer wrote:
>> As defined in "VP Codec ISO Media File Format Binding v1.0"
>> https://github.com/webmproject/vp9-dash/blob/master/VPCodecISOMediaFileFormatBinding.md
>>
>> Signed-off-by: James Almer
>> ---
>> libavformat/mov.c
On Sun, Jun 11, 2017 at 03:21:38PM +0200, Paul B Mahol wrote:
> On 6/11/17, Michael Niedermayer wrote:
> > On Fri, Jun 09, 2017 at 09:07:39PM -0400, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Thu, Jun 8, 2017 at 8:57 PM, Michael Niedermayer
> >>
> >> wrote:
> >>
> >> > On Thu, Jun 08, 2017 at
On 6/11/2017 10:21 AM, Paul B Mahol wrote:
> On 6/11/17, Michael Niedermayer wrote:
>> On Fri, Jun 09, 2017 at 09:07:39PM -0400, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Thu, Jun 8, 2017 at 8:57 PM, Michael Niedermayer
>>>
>>> wrote:
>>>
On Thu, Jun 08, 2017 at 06:35:07PM -0400, Ronald S.
On 2017-06-11 11:34, Ivan Kalvachev wrote:
> On 6/10/17, James Darnley wrote:
>> On 2017-06-09 13:41, Ivan Kalvachev wrote:
>>>
>>> const_*_edge is used on only one place is the code.
>>> Would you check if this patch fixes the issue.
>>>
>>> I expected that the addresses would be pre-calculated
>
2017-06-11 22:05 GMT+08:00 Timo Rothenpieler :
> Fixes CID 1396837
> ---
> libavformat/librtmp.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/librtmp.c b/libavformat/librtmp.c
> index 146df660ac..f3cfa9a8e2 100644
> --- a/libavformat/librtmp.c
> +++ b/li
Hi Michael,
Hoping to get your thoughts on the grepability issue (wrt my previous
email). If it needs to be on a single line there's no reason the new format
cannot be changed to do so (removing the \n and adding a separator,
really). However I'm a big fan of it as-is (for both scale and scale2ref
I've been using this patch for the past week now and I believe it's
good to go. Does someone want to take a second look before merging?
On Mon, Jun 5, 2017 at 6:55 AM, Kevin Mark wrote:
> The scale2ref filter will now maintain the DAR of the main input and
> not the DAR of the reference input. Th
I screwed up my git-send-email. Please ignore this patch as I already
submitted what should be an identical one on June 7th. My apologies.
On Mon, Jun 12, 2017 at 1:51 AM, Kevin Mark wrote:
> The input width and height is known at parse time so there's no
> reason ow/oh should not be usable when
According to libavfilter/scale.c, if the width and height are both
less than or equal to 0 then the input size is used for both
dimensions. It does not need to be -1. -1:-1 is the same as 0:0 which
is the same as -10:-42, etc.
if (w < 0 && h < 0)
eval_w = eval_h = 0;
The documentation for the
The input width and height is known at parse time so there's no
reason ow/oh should not be usable when using 0 as the width or
height expression.
Previously in "scale=0:ow" ow would be set to "0" which works,
conveniently, as "scale=0:0" is perfectly valid input but this breaks
down when you do so
Still interested in thoughts on this patch/discussion.
Thanks,
Kevin
On Wed, Jun 7, 2017 at 3:54 AM, Kevin Mark wrote:
> I also have to wonder if it would be advantageous to add the cast on
> the right side as well. That way the var_values variables will have
> the proper truncated values on fut
38 matches
Mail list logo
