Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc idct msa functions

2017-09-13 Thread Manojkumar Bhosale 
LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Tuesday, September 12, 2017 5:02 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc idct msa functions

From: Kaustubh Raste 

Align the buffers. Remove reduandant constant array.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_idct_msa.c |  255 ++-
 1 file changed, 171 insertions(+), 84 deletions(-)

diff --git a/libavcodec/mips/hevc_idct_msa.c b/libavcodec/mips/hevc_idct_msa.c 
index d483707..0943119 100644
--- a/libavcodec/mips/hevc_idct_msa.c
+++ b/libavcodec/mips/hevc_idct_msa.c
@@ -21,18 +21,18 @@
 #include "libavutil/mips/generic_macros_msa.h"
 #include "libavcodec/mips/hevcdsp_mips.h"
 
-static const int16_t gt8x8_cnst[16] = {
+static const int16_t gt8x8_cnst[16] __attribute__ ((aligned (64))) = {
 64, 64, 83, 36, 89, 50, 18, 75, 64, -64, 36, -83, 75, -89, -50, -18  };
 
-static const int16_t gt16x16_cnst[64] = {
+static const int16_t gt16x16_cnst[64] __attribute__ ((aligned (64))) = 
+{
 64, 83, 64, 36, 89, 75, 50, 18, 90, 80, 57, 25, 70, 87, 9, 43,
 64, 36, -64, -83, 75, -18, -89, -50, 87, 9, -80, -70, -43, 57, -25, -90,
 64, -36, -64, 83, 50, -89, 18, 75, 80, -70, -25, 90, -87, 9, 43, 57,
 64, -83, 64, -36, 18, -50, 75, -89, 70, -87, 90, -80, 9, -43, -57, 25  };
 
-static const int16_t gt32x32_cnst0[256] = {
+static const int16_t gt32x32_cnst0[256] __attribute__ ((aligned (64))) 
+= {
 90, 90, 88, 85, 82, 78, 73, 67, 61, 54, 46, 38, 31, 22, 13, 4,
 90, 82, 67, 46, 22, -4, -31, -54, -73, -85, -90, -88, -78, -61, -38, -13,
 88, 67, 31, -13, -54, -82, -90, -78, -46, -4, 38, 73, 90, 85, 61, 22, @@ 
-51,21 +51,17 @@ static const int16_t gt32x32_cnst0[256] = {
 4, -13, 22, -31, 38, -46, 54, -61, 67, -73, 78, -82, 85, -88, 90, -90  };
 
-static const int16_t gt32x32_cnst1[64] = {
+static const int16_t gt32x32_cnst1[64] __attribute__ ((aligned (64))) = 
+{
 90, 87, 80, 70, 57, 43, 25, 9, 87, 57, 9, -43, -80, -90, -70, -25,
 80, 9, -70, -87, -25, 57, 90, 43, 70, -43, -87, 9, 90, 25, -80, -57,
 57, -80, -25, 90, -9, -87, 43, 70, 43, -90, 57, 25, -87, 70, 9, -80,
 25, -70, 90, -80, 43, 9, -57, 87, 9, -25, 43, -57, 70, -80, 87, -90  };
 
-static const int16_t gt32x32_cnst2[16] = {
+static const int16_t gt32x32_cnst2[16] __attribute__ ((aligned (64))) = 
+{
 89, 75, 50, 18, 75, -18, -89, -50, 50, -89, 18, 75, 18, -50, 75, -89  };
 
-static const int16_t gt32x32_cnst3[16] = {
-64, 64, 64, 64, 83, 36, -36, -83, 64, -64, -64, 64, 36, -83, 83, -36
-};
-
 #define HEVC_IDCT4x4_COL(in_r0, in_l0, in_r1, in_l1,  \
  sum0, sum1, sum2, sum3, shift)   \
 { \
@@ -323,8 +319,12 @@ static void hevc_idct_4x4_msa(int16_t *coeffs)
 HEVC_IDCT4x4_COL(in_r0, in_l0, in_r1, in_l1, sum0, sum1, sum2, sum3, 7);
 TRANSPOSE4x4_SW_SW(sum0, sum1, sum2, sum3, in_r0, in_l0, in_r1, in_l1);
 HEVC_IDCT4x4_COL(in_r0, in_l0, in_r1, in_l1, sum0, sum1, sum2, sum3, 12);
-TRANSPOSE4x4_SW_SW(sum0, sum1, sum2, sum3, sum0, sum1, sum2, sum3);
-PCKEV_H2_SH(sum1, sum0, sum3, sum2, in0, in1);
+
+/* Pack and transpose */
+PCKEV_H2_SH(sum2, sum0, sum3, sum1, in0, in1);
+ILVRL_H2_SW(in1, in0, sum0, sum1);
+ILVRL_W2_SH(sum1, sum0, in0, in1);
+
 ST_SH2(in0, in1, coeffs, 8);
 }
 
@@ -432,27 +432,35 @@ static void hevc_idct_8x32_column_msa(int16_t *coeffs, 
uint8_t buf_pitch,
 const int16_t *filter_ptr0 = >32x32_cnst0[0];
 const int16_t *filter_ptr1 = >32x32_cnst1[0];
 const int16_t *filter_ptr2 = >32x32_cnst2[0];
-const int16_t *filter_ptr3 = >32x32_cnst3[0];
+const int16_t *filter_ptr3 = >8x8_cnst[0];
 int16_t *src0 = (coeffs + buf_pitch);
 int16_t *src1 = (coeffs + 2 * buf_pitch);
 int16_t *src2 = (coeffs + 4 * buf_pitch);
 int16_t *src3 = (coeffs);
 int32_t cnst0, cnst1;
-int32_t tmp_buf[8 * 32];
-int32_t *tmp_buf_ptr = &tmp_buf[0];
+int32_t tmp_buf[8 * 32 + 15];
+int32_t *tmp_buf_ptr = tmp_buf + 15;
 v8i16 in0, in1, in2, in3, in4, in5, in6, in7;
 v8i16 src0_r, src1_r, src2_r, src3_r, src4_r, src5_r, src6_r, src7_r;
 v8i16 src0_l, src1_l, src2_l, src3_l, src4_l, src5_l, src6_l, src7_l;
 v8i16 filt0, filter0, filter1, filter2, filter3;
 v4i32 sum0_r, sum0_l, sum1_r, sum1_l, tmp0_r, tmp0_l, tmp1_r, tmp1_l;
 
+/* Align pointer to 64 byte boundary */
+tmp_buf_ptr = (int32_t *)(((uintptr_t) tmp_buf_ptr) & ~(uintptr_t) 
+ 63);
+
 /* process coeff 4, 12, 20, 28 */
 LD_SH4(src2, 8 * buf_pitch, in0, in1, in2, in3);
 ILVR_H2_SH(in1, in0, in3, in2, src0_r, src1_r);
 ILVL_H2_SH(in1, in0, in3, in2, src0_l, src1_l);
 
+LD_SH2(src3, 16 * buf_pitch, in4, in6);
+LD_SH2((src3 + 8 * buf_pitch), 16 * buf_pitch, in5, in7);
+ILVR_H2_SH(in6

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc lpf msa functions

2017-09-13 Thread Manojkumar Bhosale 
LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Tuesday, September 12, 2017 4:45 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc lpf msa functions

From: Kaustubh Raste 

Seperate the filter processing in all strong, all weak and strong + weak cases.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_lpf_sao_msa.c |  750 ++--
 1 file changed, 556 insertions(+), 194 deletions(-)

diff --git a/libavcodec/mips/hevc_lpf_sao_msa.c 
b/libavcodec/mips/hevc_lpf_sao_msa.c
index da1db51..79b156f 100644
--- a/libavcodec/mips/hevc_lpf_sao_msa.c
+++ b/libavcodec/mips/hevc_lpf_sao_msa.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015 Manojkumar Bhosale (manojkumar.bhos...@imgtec.com)
+ * Copyright (c) 2015 -2017 Manojkumar Bhosale 
+ (manojkumar.bhos...@imgtec.com)
  *
  * This file is part of FFmpeg.
  *
@@ -35,12 +35,14 @@ static void hevc_loopfilter_luma_hor_msa(uint8_t *src, 
int32_t stride,
 uint8_t *q3 = src + (stride << 1) + stride;
 uint8_t flag0, flag1;
 int32_t dp00, dq00, dp30, dq30, d00, d30;
+int32_t d0030, d0434;
 int32_t dp04, dq04, dp34, dq34, d04, d34;
 int32_t tc0, p_is_pcm0, q_is_pcm0, beta30, beta20, tc250;
 int32_t tc4, p_is_pcm4, q_is_pcm4, tc254, tmp;
 uint64_t dst_val0, dst_val1;
 v16u8 dst0, dst1, dst2, dst3, dst4, dst5;
 v2i64 cmp0, cmp1, cmp2, p_is_pcm_vec, q_is_pcm_vec;
+v2i64 cmp3;
 v8u16 temp0, temp1;
 v8i16 temp2;
 v8i16 tc_pos, tc_neg;
@@ -54,62 +56,86 @@ static void hevc_loopfilter_luma_hor_msa(uint8_t *src, 
int32_t stride,
 dq30 = abs(q2[3] - (q1[3] << 1) + q0[3]);
 d00 = dp00 + dq00;
 d30 = dp30 + dq30;
-p_is_pcm0 = p_is_pcm[0];
-q_is_pcm0 = q_is_pcm[0];
 dp04 = abs(p2[4] - (p1[4] << 1) + p0[4]);
 dq04 = abs(q2[4] - (q1[4] << 1) + q0[4]);
 dp34 = abs(p2[7] - (p1[7] << 1) + p0[7]);
 dq34 = abs(q2[7] - (q1[7] << 1) + q0[7]);
 d04 = dp04 + dq04;
 d34 = dp34 + dq34;
+
+p_is_pcm0 = p_is_pcm[0];
 p_is_pcm4 = p_is_pcm[1];
+q_is_pcm0 = q_is_pcm[0];
 q_is_pcm4 = q_is_pcm[1];
 
-if (!p_is_pcm0 || !p_is_pcm4 || !q_is_pcm0 || !q_is_pcm4) {
-if (!(d00 + d30 >= beta) || !(d04 + d34 >= beta)) {
-p3_src = LD_UH(p3);
-p2_src = LD_UH(p2);
-p1_src = LD_UH(p1);
-p0_src = LD_UH(p0);
-q0_src = LD_UH(q0);
-q1_src = LD_UH(q1);
-q2_src = LD_UH(q2);
-q3_src = LD_UH(q3);
-
-tc0 = tc[0];
-beta30 = beta >> 3;
-beta20 = beta >> 2;
-tc250 = ((tc0 * 5 + 1) >> 1);
-tc4 = tc[1];
-tc254 = ((tc4 * 5 + 1) >> 1);
-
-flag0 = (abs(p3[0] - p0[0]) + abs(q3[0] - q0[0]) < beta30 &&
- abs(p0[0] - q0[0]) < tc250 &&
- abs(p3[3] - p0[3]) + abs(q3[3] - q0[3]) < beta30 &&
- abs(p0[3] - q0[3]) < tc250 &&
- (d00 << 1) < beta20 && (d30 << 1) < beta20);
-cmp0 = __msa_fill_d(flag0);
-
-flag1 = (abs(p3[4] - p0[4]) + abs(q3[4] - q0[4]) < beta30 &&
- abs(p0[4] - q0[4]) < tc254 &&
- abs(p3[7] - p0[7]) + abs(q3[7] - q0[7]) < beta30 &&
- abs(p0[7] - q0[7]) < tc254 &&
- (d04 << 1) < beta20 && (d34 << 1) < beta20);
-cmp1 = __msa_fill_d(flag1);
-cmp2 = __msa_ilvev_d(cmp1, cmp0);
-cmp2 = __msa_ceqi_d(cmp2, 0);
-
-ILVR_B8_UH(zero, p3_src, zero, p2_src, zero, p1_src, zero, p0_src,
-   zero, q0_src, zero, q1_src, zero, q2_src, zero, q3_src,
-   p3_src, p2_src, p1_src, p0_src, q0_src, q1_src, q2_src,
-   q3_src);
-
-cmp0 = (v2i64) __msa_fill_h(tc0);
-cmp1 = (v2i64) __msa_fill_h(tc4);
-tc_pos = (v8i16) __msa_ilvev_d(cmp1, cmp0);
+cmp0 = __msa_fill_d(p_is_pcm0);
+cmp1 = __msa_fill_d(p_is_pcm4);
+p_is_pcm_vec = __msa_ilvev_d(cmp1, cmp0);
+p_is_pcm_vec = __msa_ceqi_d(p_is_pcm_vec, 0);
+
+d0030 = (d00 + d30) >= beta;
+d0434 = (d04 + d34) >= beta;
+
+cmp0 = (v2i64) __msa_fill_w(d0030);
+cmp1 = (v2i64) __msa_fill_w(d0434);
+cmp3 = (v2i64) __msa_ilvev_w((v4i32) cmp1, (v4i32) cmp0);
+cmp3 = (v2i64) __msa_ceqi_w((v4i32) cmp3, 0);
+
+if ((!p_is_pcm0 || !p_is_pcm4 || !q_is_pcm0 || !q_is_pcm4) &&
+(!d0030 || !d0434)) {
+p3_src = LD_UH(p3);
+p2_src = LD_UH(p2);
+p1_src = LD_UH(p1);
+p0_src = LD_UH(p0);
+
+cmp0 = __msa_fill_d(q_is_pcm0);
+cmp1 = __msa_fill_d(q_is_pcm4);
+q_is_pcm_vec = __msa_ilvev_d(cmp1, cmp0);
+q_is_pcm_vec = __msa_ceqi_d(q_is_pcm_vec, 0);
+
+tc0 = tc[0];
+beta30 = beta >> 3;
+beta20 = beta >> 2;
+

Re: [FFmpeg-devel] [V5 2/4] lavc/vaapi_encode: Add max slices number query.

2017-09-13 Thread Moritz Barsnick 
On Thu, Aug 24, 2017 at 09:13:09 +0800, Jun Zhao wrote:
> +// Supported max-slices number per frame. (0 means driver cannot
> +// support max mutil-slices query)
  ^ multi

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [V5 3/4] lavc/vaapi_encode_h264: respect "slices" option in h264 vaapi encoder

2017-09-13 Thread Moritz Barsnick 
On Thu, Aug 24, 2017 at 09:13:20 +0800, Jun Zhao wrote:
> +av_log(avctx, AV_LOG_ERROR, "The max slices number per frame "
> +   "cannot more than %d.\n", ctx->max_slices);

"cannot be more"
(This remark also applies to the h265 patch.)

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/pngdec: Fix () placement

2017-09-13 Thread Moritz Barsnick 
On Wed, Aug 23, 2017 at 22:26:45 +0200, Alexander Strasser wrote:
> > -if ((ret = decode_zbuf(&bp, s->gb.buffer, s->gb.buffer + length) < 0))
> > +if ((ret = decode_zbuf(&bp, s->gb.buffer, s->gb.buffer + length)) < 0)
> 
> IMHO another reason not to do the assignment and the comparison on the same
> line inside the if-condition in C.
> 
> I mean you need the extra parens and if you are not careful enough you will 
> just get it silently wrong like it was above.
> 
> Probably we found enough of such errors to discourage that style in FFmpeg?

This also looks fishy:
./libavformat/mxfdec.c:2314:if ((ret = 
avpriv_dict_set_timestamp(&s->metadata, name, mxf_timestamp_to_int64(var)) < 
0)) \
(It's inside a macro.)

And this one went for overkill (i.e. it's correct, but uses one set too
many on its outside):
./libavdevice/avdevice.c:156:if (((ret = av_opt_set_dict(s->priv_data, 
device_options)) < 0))

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add vmafmotion filter

2017-09-13 Thread Ronald S. Bultje 
Hi,

On Wed, Sep 6, 2017 at 4:04 PM, Ashish Pratap Singh 
wrote:

> From: Ashish Singh 
>
> Hi, this patch changes previous one to framesync2.
> SIMD is a work in progress for this filter.
>
> Signed-off-by: Ashish Singh 
> ---
>  Changelog   |   1 +
>  doc/filters.texi|  16 ++
>  libavfilter/Makefile|   1 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/vf_vmafmotion.c | 413 ++
> ++
>  libavfilter/vmaf_motion.h   |  42 +
>  6 files changed, 474 insertions(+)
>  create mode 100644 libavfilter/vf_vmafmotion.c
>  create mode 100644 libavfilter/vmaf_motion.h


One more general comment on this filter: it appears to me that the motion
is calculated based on the reference, and we only use the "main" to apply
the metadata to. Although this makes sense from the "vmaf" filter
perspective, I'm actually wondering if - from the perspective of the
"vmafmotion" filter alone, it wouldn't be simpler to just have a single
filterpad input ("reference") and apply the metadata on it (when used by
itself). (The "vmaf" filter could still apply metadata on the "main").

What do people think? Would you prefer the "vmaf" and "vmafmotion" to
consistently apply the metadata on the "main" video frames, or would you
prefer that the "vmafmotion" filter more accurately presents which frame is
used for the motion scoring, which also happens to lead to simpler code /
filterchains?

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add vmafmotion filter

2017-09-13 Thread Ashish Pratap Singh 
Hi,

On Wed, Sep 13, 2017 at 6:40 PM, Ronald S. Bultje 
wrote:

> Hi,
>
> On Wed, Sep 6, 2017 at 4:04 PM, Ashish Pratap Singh 
> wrote:
>
>> From: Ashish Singh 
>>
>> Hi, this patch changes previous one to framesync2.
>> SIMD is a work in progress for this filter.
>>
>> Signed-off-by: Ashish Singh 
>> ---
>>  Changelog   |   1 +
>>  doc/filters.texi|  16 ++
>>  libavfilter/Makefile|   1 +
>>  libavfilter/allfilters.c|   1 +
>>  libavfilter/vf_vmafmotion.c | 413 ++
>> ++
>>  libavfilter/vmaf_motion.h   |  42 +
>>  6 files changed, 474 insertions(+)
>>  create mode 100644 libavfilter/vf_vmafmotion.c
>>  create mode 100644 libavfilter/vmaf_motion.h
>
>
> One more general comment on this filter: it appears to me that the motion
> is calculated based on the reference, and we only use the "main" to apply
> the metadata to. Although this makes sense from the "vmaf" filter
> perspective, I'm actually wondering if - from the perspective of the
> "vmafmotion" filter alone, it wouldn't be simpler to just have a single
> filterpad input ("reference") and apply the metadata on it (when used by
> itself). (The "vmaf" filter could still apply metadata on the "main").
>
> What do people think? Would you prefer the "vmaf" and "vmafmotion" to
> consistently apply the metadata on the "main" video frames, or would you
> prefer that the "vmafmotion" filter more accurately presents which frame is
> used for the motion scoring, which also happens to lead to simpler code /
> filterchains?
>
> Ronald
>

yeah, you are right. In this filter only reference video is considered. So
I can make it a single filterpad input if everything is fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [Patch] CUDA Thumbnail Filter

2017-09-13 Thread Timo Rothenpieler 
Will apply with some minor changes (some unused variables are still 
left, and some cleanup is missing) soon if nobody objects.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add vmafmotion filter

2017-09-13 Thread Tobias Rapp 

On 13.09.2017 15:10, Ronald S. Bultje wrote:

Hi,

On Wed, Sep 6, 2017 at 4:04 PM, Ashish Pratap Singh 
wrote:


From: Ashish Singh 

Hi, this patch changes previous one to framesync2.
SIMD is a work in progress for this filter.

Signed-off-by: Ashish Singh 
---
  Changelog   |   1 +
  doc/filters.texi|  16 ++
  libavfilter/Makefile|   1 +
  libavfilter/allfilters.c|   1 +
  libavfilter/vf_vmafmotion.c | 413 ++
++
  libavfilter/vmaf_motion.h   |  42 +
  6 files changed, 474 insertions(+)
  create mode 100644 libavfilter/vf_vmafmotion.c
  create mode 100644 libavfilter/vmaf_motion.h



One more general comment on this filter: it appears to me that the motion
is calculated based on the reference, and we only use the "main" to apply
the metadata to. Although this makes sense from the "vmaf" filter
perspective, I'm actually wondering if - from the perspective of the
"vmafmotion" filter alone, it wouldn't be simpler to just have a single
filterpad input ("reference") and apply the metadata on it (when used by
itself). (The "vmaf" filter could still apply metadata on the "main").

What do people think? Would you prefer the "vmaf" and "vmafmotion" to
consistently apply the metadata on the "main" video frames, or would you
prefer that the "vmafmotion" filter more accurately presents which frame is
used for the motion scoring, which also happens to lead to simpler code /
filterchains?


So when I understand this correctly the "vmafmotion" filter would work 
similar (in structure) to the "idet" filter, comparing consecutive 
frames on a single filterpad input and attaching metadata to the output 
frames? Yes, that would make using the "vmafmotion" filter more simple 
and flexible, IMHO.


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: check if NAN can be used as a constant initializer

2017-09-13 Thread James Almer 
Some targets, like NetBSD and DJGPP, don't seem to support it.

Signed-off-by: James Almer 
---
 configure | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configure b/configure
index ab1550d39b..4855ca54c9 100755
--- a/configure
+++ b/configure
@@ -3222,6 +3222,7 @@ pixfmts_super2xsai_test_deps="super2xsai_filter"
 tinterlace_filter_deps="gpl"
 tinterlace_merge_test_deps="tinterlace_filter"
 tinterlace_pad_test_deps="tinterlace_filter"
+tonemap_filter_deps="const_nan"
 uspp_filter_deps="gpl avcodec"
 vaguedenoiser_filter_deps="gpl"
 vidstabdetect_filter_deps="libvidstab"
@@ -5324,6 +5325,11 @@ unsigned int endian = 'B' << 24 | 'I' << 16 | 'G' << 8 | 
'E';
 EOF
 od -t x1 $TMPO | grep -q '42 *49 *47 *45' && enable bigendian
 
+check_cc <
+void foo(void) { struct { double d; } static const bar[] = { { NAN } }; }
+EOF
+
 if ! enabled ppc64 || enabled bigendian; then
 disable vsx
 fi
-- 
2.13.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/frame_thread_encoder: Fix AV_OPT_TYPE_STRING handling in avctx

2017-09-13 Thread Reimar Döffinger 
This is the equivalent to what 7d317d4706b49d572a1eb5269438753be18362c7
did for the codec-specific options.
av_opt_copy has specific handling so it's fine that we already copied
the whole context before.

Signed-off-by: Reimar Döffinger 
---
 libavcodec/frame_thread_encoder.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/frame_thread_encoder.c 
b/libavcodec/frame_thread_encoder.c
index 35a37c4..31a9fe9 100644
--- a/libavcodec/frame_thread_encoder.c
+++ b/libavcodec/frame_thread_encoder.c
@@ -199,6 +199,9 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx, 
AVDictionary *options){
 goto fail;
 tmpv = thread_avctx->priv_data;
 *thread_avctx = *avctx;
+int ret = av_opt_copy(thread_avctx, avctx);
+if (ret < 0)
+goto fail;
 thread_avctx->priv_data = tmpv;
 thread_avctx->internal = NULL;
 if (avctx->codec->priv_class) {
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavf/mpegts: Consider 0x0f just a hint towards aac

2017-09-13 Thread Carl Eugen Hoyos 
Hi!

Attached patch fixes ticket #6657.

Please comment, Carl Eugen
From d806a243e97de8c245958dc6f8d2646217cc5105 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 13 Sep 2017 19:05:10 +0200
Subject: [PATCH] lavf/mpegts: Consider stream_type 0x0f just a hint toward
 AAC.

It is also used in the wild to signal latm.

Fixes ticket #6657.
---
 libavformat/mpegts.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 4d2f5c6..53cbcfb 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -814,7 +814,7 @@ static int mpegts_set_stream_info(AVStream *st, PESContext *pes,
 st->codecpar->codec_tag = pes->stream_type;
 
 mpegts_find_stream_type(st, pes->stream_type, ISO_types);
-if (pes->stream_type == 4)
+if (pes->stream_type == 4 || pes->stream_type == 0x0f)
 st->request_probe = 50;
 if ((prog_reg_desc == AV_RL32("HDMV") ||
  prog_reg_desc == AV_RL32("HDPR")) &&
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: check if NAN can be used as a constant initializer

2017-09-13 Thread Carl Eugen Hoyos 
2017-09-13 19:10 GMT+02:00 James Almer :
> Some targets, like NetBSD and DJGPP, don't seem to support it.
>
> Signed-off-by: James Almer 
> ---
>  configure | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/configure b/configure
> index ab1550d39b..4855ca54c9 100755
> --- a/configure
> +++ b/configure
> @@ -3222,6 +3222,7 @@ pixfmts_super2xsai_test_deps="super2xsai_filter"
>  tinterlace_filter_deps="gpl"
>  tinterlace_merge_test_deps="tinterlace_filter"
>  tinterlace_pad_test_deps="tinterlace_filter"
> +tonemap_filter_deps="const_nan"

No objections but what was wrong with using another
default to avoid the additional check?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [Patch] CUDA Thumbnail Filter

2017-09-13 Thread Rostislav Pehlivanov 
On 13 September 2017 at 14:43, Timo Rothenpieler 
wrote:

> Will apply with some minor changes (some unused variables are still left,
> and some cleanup is missing) soon if nobody objects.
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
I did object and have NAK'd the patch currently.
Make the submitter submit a new version themselves and I'll approve it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/pngdec: Fix () placement

2017-09-13 Thread Reimar Döffinger 
On Wed, Aug 23, 2017 at 10:26:45PM +0200, Alexander Strasser wrote:
> On 2017-08-22 17:23 +, Michael Niedermayer wrote:
> > ffmpeg | branch: master | Michael Niedermayer  | 
> > Tue Aug 22 18:36:26 2017 +0200| [a2e444d5bb2e3115d3afcc0cca9d1506c90436a2] 
> > | committer: Michael Niedermayer
> > 
> > avcodec/pngdec: Fix () placement
> > 
> > Signed-off-by: Michael Niedermayer 
> > 
> > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=a2e444d5bb2e3115d3afcc0cca9d1506c90436a2
> > ---
> > 
> >  libavcodec/pngdec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> > index 4fc1c5a062..dce8faf168 100644
> > --- a/libavcodec/pngdec.c
> > +++ b/libavcodec/pngdec.c
> > @@ -858,7 +858,7 @@ static int decode_iccp_chunk(PNGDecContext *s, int 
> > length, AVFrame *f)
> >  
> >  length = FFMAX(length - 1, 0);
> >  
> > -if ((ret = decode_zbuf(&bp, s->gb.buffer, s->gb.buffer + length) < 0))
> > +if ((ret = decode_zbuf(&bp, s->gb.buffer, s->gb.buffer + length)) < 0)
> 
> IMHO another reason not to do the assignment and the comparison on the same
> line inside the if-condition in C.
> 
> I mean you need the extra parens and if you are not careful enough you will 
> just get it silently wrong like it was above.
> 
> Probably we found enough of such errors to discourage that style in FFmpeg?

It's happening over and over, and I for that reason complain about this
style every time.
But few people so far have been convinced by it that it's a really
bad idea (though IMHO it would still be bad style and readability even
without all the bugs it caused).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: check if NAN can be used as a constant initializer

2017-09-13 Thread James Almer 
On 9/13/2017 2:23 PM, Carl Eugen Hoyos wrote:
> 2017-09-13 19:10 GMT+02:00 James Almer :
>> Some targets, like NetBSD and DJGPP, don't seem to support it.
>>
>> Signed-off-by: James Almer 
>> ---
>>  configure | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/configure b/configure
>> index ab1550d39b..4855ca54c9 100755
>> --- a/configure
>> +++ b/configure
>> @@ -3222,6 +3222,7 @@ pixfmts_super2xsai_test_deps="super2xsai_filter"
>>  tinterlace_filter_deps="gpl"
>>  tinterlace_merge_test_deps="tinterlace_filter"
>>  tinterlace_pad_test_deps="tinterlace_filter"
>> +tonemap_filter_deps="const_nan"
> 
> No objections but what was wrong with using another
> default to avoid the additional check?

DBL_MIN and DBL_MAX are both valid values for the option. Turning one of
them into "auto" does not seem like a good idea to me.

If someone else has a better solution than a simple check for broken
toolchains at configure time then I'll drop this patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/frame_thread_encoder: Fix AV_OPT_TYPE_STRING handling in avctx

2017-09-13 Thread Reimar Döffinger 
On Wed, Sep 13, 2017 at 07:12:48PM +0200, Reimar Döffinger wrote:
> This is the equivalent to what 7d317d4706b49d572a1eb5269438753be18362c7
> did for the codec-specific options.
> av_opt_copy has specific handling so it's fine that we already copied
> the whole context before.

Btw, if someone can make time for reviewing it that would likely
be time well spent.
For example it seems the code also leaks the memory for the AVPacket
it mallocs sometimes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [Patch] CUDA Thumbnail Filter

2017-09-13 Thread Timo Rothenpieler 

I did object and have NAK'd the patch currently.
Make the submitter submit a new version themselves and I'll approve it.


There was a new version submitted already, I just replied to the wrong one.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: check if NAN can be used as a constant initializer

2017-09-13 Thread Reimar Döffinger 
On Wed, Sep 13, 2017 at 02:49:59PM -0300, James Almer wrote:
> On 9/13/2017 2:23 PM, Carl Eugen Hoyos wrote:
> > 2017-09-13 19:10 GMT+02:00 James Almer :
> >> Some targets, like NetBSD and DJGPP, don't seem to support it.
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >>  configure | 6 ++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/configure b/configure
> >> index ab1550d39b..4855ca54c9 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -3222,6 +3222,7 @@ pixfmts_super2xsai_test_deps="super2xsai_filter"
> >>  tinterlace_filter_deps="gpl"
> >>  tinterlace_merge_test_deps="tinterlace_filter"
> >>  tinterlace_pad_test_deps="tinterlace_filter"
> >> +tonemap_filter_deps="const_nan"
> > 
> > No objections but what was wrong with using another
> > default to avoid the additional check?
> 
> DBL_MIN and DBL_MAX are both valid values for the option. Turning one of
> them into "auto" does not seem like a good idea to me.
> 
> If someone else has a better solution than a simple check for broken
> toolchains at configure time then I'll drop this patch.

Not having a better solution, but at least vf_zscale looks to me like it should
have the same issue.
It would look at but less "silly" if it was a check used for more
than just one filter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: check if NAN can be used as a constant initializer

2017-09-13 Thread James Almer 
On 9/13/2017 3:08 PM, Reimar Döffinger wrote:
> On Wed, Sep 13, 2017 at 02:49:59PM -0300, James Almer wrote:
>> On 9/13/2017 2:23 PM, Carl Eugen Hoyos wrote:
>>> 2017-09-13 19:10 GMT+02:00 James Almer :
 Some targets, like NetBSD and DJGPP, don't seem to support it.

 Signed-off-by: James Almer 
 ---
  configure | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/configure b/configure
 index ab1550d39b..4855ca54c9 100755
 --- a/configure
 +++ b/configure
 @@ -3222,6 +3222,7 @@ pixfmts_super2xsai_test_deps="super2xsai_filter"
  tinterlace_filter_deps="gpl"
  tinterlace_merge_test_deps="tinterlace_filter"
  tinterlace_pad_test_deps="tinterlace_filter"
 +tonemap_filter_deps="const_nan"
>>>
>>> No objections but what was wrong with using another
>>> default to avoid the additional check?
>>
>> DBL_MIN and DBL_MAX are both valid values for the option. Turning one of
>> them into "auto" does not seem like a good idea to me.
>>
>> If someone else has a better solution than a simple check for broken
>> toolchains at configure time then I'll drop this patch.
> 
> Not having a better solution, but at least vf_zscale looks to me like it 
> should
> have the same issue.
Ah, thanks for spotting that. No affected FATE client seems to link
libzimg so they wouldn't have failed in vf_zscale after this or any
other solution for vf_tonemap was committed.

> It would look at but less "silly" if it was a check used for more
> than just one filter.

Will add it and push. If someone has a better solution then this one can
be replaced.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: check if NAN can be used as a constant initializer

2017-09-13 Thread Hendrik Leppkes 
On Wed, Sep 13, 2017 at 7:49 PM, James Almer  wrote:
> On 9/13/2017 2:23 PM, Carl Eugen Hoyos wrote:
>> 2017-09-13 19:10 GMT+02:00 James Almer :
>>> Some targets, like NetBSD and DJGPP, don't seem to support it.
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>>  configure | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/configure b/configure
>>> index ab1550d39b..4855ca54c9 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -3222,6 +3222,7 @@ pixfmts_super2xsai_test_deps="super2xsai_filter"
>>>  tinterlace_filter_deps="gpl"
>>>  tinterlace_merge_test_deps="tinterlace_filter"
>>>  tinterlace_pad_test_deps="tinterlace_filter"
>>> +tonemap_filter_deps="const_nan"
>>
>> No objections but what was wrong with using another
>> default to avoid the additional check?
>
> DBL_MIN and DBL_MAX are both valid values for the option. Turning one of
> them into "auto" does not seem like a good idea to me.
>

valid perhaps, but also reasonably useful? ie. would anyone ever use
them and get a useful result?

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfdec: use the common packet pts setter function for opatom files

2017-09-13 Thread Marton Balint 


On Fri, 8 Sep 2017, Michael Niedermayer wrote:


On Thu, Sep 07, 2017 at 05:11:40PM +0200, Marton Balint wrote:

Fixes ticket #6631.

Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)


please add a fate this if you push this


Unfortunately we only have a sample which is around 16 MB but it seems 
like an overkill to add such a big sample to the fate suite for such 
a minor feature. And I am also not very fond of truncating the file and 
adding truncated files to the fate suite... So unless somebody can provide 
an opAtom AVC intra file which is only a few frames long, I see no good 
way to fate test this. Do you have an idea how to proceed?


Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3] avformat/mpegts: opus muxing & demuxing for mapping family 255

2017-09-13 Thread pkv.stream 

Le 08/09/2017 à 1:46 AM, pkv.stream a écrit :

Hi,

I've removed inline declarations in the patch since they're not 
accepted in ffmpeg.


Thanks for any more comments or reviews.

Regards



bump, initial submission 08/29

Got some comments from Michael (thanks again Michael) but that's all.

Should I ping those who brought opus support to mpegts / mapping_family 
to opus , for instance ?


Regards

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: check if NAN can be used as a constant initializer

2017-09-13 Thread James Almer 
On 9/13/2017 3:36 PM, Hendrik Leppkes wrote:
> On Wed, Sep 13, 2017 at 7:49 PM, James Almer  wrote:
>> On 9/13/2017 2:23 PM, Carl Eugen Hoyos wrote:
>>> 2017-09-13 19:10 GMT+02:00 James Almer :
 Some targets, like NetBSD and DJGPP, don't seem to support it.

 Signed-off-by: James Almer 
 ---
  configure | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/configure b/configure
 index ab1550d39b..4855ca54c9 100755
 --- a/configure
 +++ b/configure
 @@ -3222,6 +3222,7 @@ pixfmts_super2xsai_test_deps="super2xsai_filter"
  tinterlace_filter_deps="gpl"
  tinterlace_merge_test_deps="tinterlace_filter"
  tinterlace_pad_test_deps="tinterlace_filter"
 +tonemap_filter_deps="const_nan"
>>>
>>> No objections but what was wrong with using another
>>> default to avoid the additional check?
>>
>> DBL_MIN and DBL_MAX are both valid values for the option. Turning one of
>> them into "auto" does not seem like a good idea to me.
>>
> 
> valid perhaps, but also reasonably useful? ie. would anyone ever use
> them and get a useful result?

Maybe not, but I'm not going to spend time reading and testing the code
to find out if that's the case when the maintainer hasn't dealt with
this himself for an entire month.

As i said, if anyone has a better or preferred solution I'll not oppose
a patch implementing it and reverting mine.

> 
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/extract_extradata: return an error when buffer allocation fails

2017-09-13 Thread James Almer 
ret is 0 by default.
---
 libavcodec/extract_extradata_bsf.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/extract_extradata_bsf.c 
b/libavcodec/extract_extradata_bsf.c
index 4cd0ca1137..ed6509c681 100644
--- a/libavcodec/extract_extradata_bsf.c
+++ b/libavcodec/extract_extradata_bsf.c
@@ -101,14 +101,17 @@ static int extract_extradata_h2645(AVBSFContext *ctx, 
AVPacket *pkt,
 
 if (s->remove) {
 filtered_buf = av_buffer_alloc(pkt->size + 
AV_INPUT_BUFFER_PADDING_SIZE);
-if (!filtered_buf)
+if (!filtered_buf) {
+ret = AVERROR(ENOMEM);
 goto fail;
+}
 filtered_data = filtered_buf->data;
 }
 
 extradata = av_malloc(extradata_size + AV_INPUT_BUFFER_PADDING_SIZE);
 if (!extradata) {
 av_buffer_unref(&filtered_buf);
+ret = AVERROR(ENOMEM);
 goto fail;
 }
 
-- 
2.13.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/extract_extradata: return an error when buffer allocation fails

2017-09-13 Thread Mark Thompson 
On 13/09/17 21:06, James Almer wrote:
> ret is 0 by default.
> ---
>  libavcodec/extract_extradata_bsf.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/extract_extradata_bsf.c 
> b/libavcodec/extract_extradata_bsf.c
> index 4cd0ca1137..ed6509c681 100644
> --- a/libavcodec/extract_extradata_bsf.c
> +++ b/libavcodec/extract_extradata_bsf.c
> @@ -101,14 +101,17 @@ static int extract_extradata_h2645(AVBSFContext *ctx, 
> AVPacket *pkt,
>  
>  if (s->remove) {
>  filtered_buf = av_buffer_alloc(pkt->size + 
> AV_INPUT_BUFFER_PADDING_SIZE);
> -if (!filtered_buf)
> +if (!filtered_buf) {
> +ret = AVERROR(ENOMEM);
>  goto fail;
> +}
>  filtered_data = filtered_buf->data;
>  }
>  
>  extradata = av_malloc(extradata_size + AV_INPUT_BUFFER_PADDING_SIZE);
>  if (!extradata) {
>  av_buffer_unref(&filtered_buf);
> +ret = AVERROR(ENOMEM);
>  goto fail;
>  }

LGTM.

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/extract_extradata: return an error when buffer allocation fails

2017-09-13 Thread James Almer 
On 9/13/2017 5:20 PM, Mark Thompson wrote:
> On 13/09/17 21:06, James Almer wrote:
>> ret is 0 by default.
>> ---
>>  libavcodec/extract_extradata_bsf.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/extract_extradata_bsf.c 
>> b/libavcodec/extract_extradata_bsf.c
>> index 4cd0ca1137..ed6509c681 100644
>> --- a/libavcodec/extract_extradata_bsf.c
>> +++ b/libavcodec/extract_extradata_bsf.c
>> @@ -101,14 +101,17 @@ static int extract_extradata_h2645(AVBSFContext *ctx, 
>> AVPacket *pkt,
>>  
>>  if (s->remove) {
>>  filtered_buf = av_buffer_alloc(pkt->size + 
>> AV_INPUT_BUFFER_PADDING_SIZE);
>> -if (!filtered_buf)
>> +if (!filtered_buf) {
>> +ret = AVERROR(ENOMEM);
>>  goto fail;
>> +}
>>  filtered_data = filtered_buf->data;
>>  }
>>  
>>  extradata = av_malloc(extradata_size + 
>> AV_INPUT_BUFFER_PADDING_SIZE);
>>  if (!extradata) {
>>  av_buffer_unref(&filtered_buf);
>> +ret = AVERROR(ENOMEM);
>>  goto fail;
>>  }
> 
> LGTM.

Pushed and backported.

Thanks.

> 
> - Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: check if NAN can be used as a constant initializer

2017-09-13 Thread Derek Buitenhuis 
On 9/13/2017 8:39 PM, James Almer wrote:
> Maybe not, but I'm not going to spend time reading and testing the code
> to find out if that's the case when the maintainer hasn't dealt with
> this himself for an entire month.

He's on vacation, I think.

> As i said, if anyone has a better or preferred solution I'll not oppose
> a patch implementing it and reverting mine.

I prefer this one, because, for example, it covers zscale, too, which
can't be fixed by using DBL_MAX/DBL_MIN, since NAN is part of libzimg's
public API.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add support for RockChip Media Process Platform

2017-09-13 Thread James Almer 
On 9/11/2017 5:21 AM, LongChair . wrote:
> 
> 
> Le 10/09/2017 à 19:13, James Almer a écrit :
>> On 9/9/2017 4:00 AM, LongChair . wrote:
>>> From: LongChair 
>>>
>>> This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
>>> Will return frames holding an AVDRMFrameDescriptor struct in buf[0] that 
>>> allows drm / dmabuf usage.
>>> Was tested on RK3288 (TinkerBoard) and RK3328.
>>>
>>> Changes from Previous patch :
>>> - Frame colorspace info is now filled.
>>> - Frame interlacing is now filled (Note : currently had a bug in mpp which 
>>> will be fixed soon by rockchip, will set the frame to progressive).
>>> - hw_frame_context returns none as format for the rockchip specific 10 bits.
>>> - Added support for MPEG4 codec
>>> - Added support for VP9 codec.
>>> - the ION format has been kept for MPP init (rather than DRM) as this is 
>>> the only one working right, using DRM format will cause assertions upon 
>>> close.
>>> - Other minor comments have been taken into account
>>> ---
>>>  Changelog  |   1 +
>>>  configure  |  16 ++
>>>  libavcodec/Makefile|   5 +
>>>  libavcodec/allcodecs.c |   5 +
>>>  libavcodec/rkmppdec.c  | 584 
>>> +
>>>  5 files changed, 611 insertions(+)
>>>  create mode 100644 libavcodec/rkmppdec.c
>>> +#define RKMPP_DEC(NAME, ID, BSFS) \
>>> +RKMPP_DEC_CLASS(NAME) \
>>> +AVCodec ff_##NAME##_rkmpp_decoder = { \
>>> +.name   = #NAME "_rkmpp", \
>>> +.long_name  = NULL_IF_CONFIG_SMALL(#NAME " (rkmpp)"), \
>>> +.type   = AVMEDIA_TYPE_VIDEO, \
>>> +.id = ID, \
>>> +.priv_data_size = sizeof(RKMPPDecodeContext), \
>>> +.init   = rkmpp_init_decoder, \
>>> +.close  = rkmpp_close_decoder, \
>>> +.receive_frame  = rkmpp_receive_frame, \
>>> +.flush  = rkmpp_flush, \
>>> +.priv_class = &rkmpp_##NAME##_dec_class, \
>>> +.capabilities   = AV_CODEC_CAP_DELAY, \
>> Add AV_CODEC_CAP_AVOID_PROBING as well.
> What would that flag change ?

Avoids using this decoder for probing. Read the flag's doxy in avcodec.h
for the rationale.

>>
>>> +.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS, \
>> It doesn't look like you're setting pkt_dts anywhere?
> True, I can remove that one.
>>
>>> +.pix_fmts   = (const enum AVPixelFormat[]) { 
>>> AV_PIX_FMT_DRM_PRIME, \
>>> + AV_PIX_FMT_NONE}, 
>>> \
>>> +.bsfs   = BSFS, \
>>> +};
>>> +
>>> +RKMPP_DEC(h264,  AV_CODEC_ID_H264,  "h264_mp4toannexb")
>>> +RKMPP_DEC(hevc,  AV_CODEC_ID_HEVC,  "hevc_mp4toannexb")
>>> +RKMPP_DEC(mpeg4, AV_CODEC_ID_MPEG4, NULL)
>>> +RKMPP_DEC(vp8,   AV_CODEC_ID_VP8,   NULL)
>>> +RKMPP_DEC(vp9,   AV_CODEC_ID_VP9,   NULL)
>>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter

2017-09-13 Thread Thomas Mundt 
2017-09-06 22:15 GMT+02:00 Thomas Mundt :

> 2017-09-01 1:55 GMT+02:00 Thomas Mundt :
>
>> 2017-09-01 1:22 GMT+02:00 Michael Niedermayer :
>>
>>> On Fri, Sep 01, 2017 at 01:18:11AM +0200, Michael Niedermayer wrote:
>>> > On Thu, Aug 31, 2017 at 10:40:12PM +0200, Thomas Mundt wrote:
>>> > > 2017-08-31 21:42 GMT+02:00 Michael Niedermayer
>>> :
>>> > >
>>> > > > On Wed, Aug 30, 2017 at 03:54:08AM +0200, Thomas Mundt wrote:
>>> > > > > Hi,
>>> > > > >
>>> > > > > we did a transcoding cascade test at work were over-sharpening
>>> became
>>> > > > > visible with the complex low-pass filter. This patch rectifies
>>> the
>>> > > > > behaviour.
>>> > > > >
>>> > > > > Please comment...
>>> > > >
>>> > > > did you perform subjective and or objective tests ?
>>> > > >
>>> > > > objective being some metric like PSNR vs correctly sampled data
>>> > > > subjective being double blind tests with humans about which they
>>> prefer
>>> > > >
>>> > >
>>> > > The tests have been subjective with a team of video engineers and
>>> > > technicians with several test files.
>>> > >
>>> > > I did a quick SSIM/PSNR check with the first generation of an HD->SD
>>> file
>>> > > as a reference against the 6th generation.
>>> >
>>> > if its better then iam fine with it. No more comments from me
>>>
>>> ahh, forgot, you may want tp add the tests you did and their results
>>> to the commit message
>>
>>
>> Sure, new patch attached.
>>
>
> Ping
>

Ping!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [Patch] CUDA Thumbnail Filter

2017-09-13 Thread Rostislav Pehlivanov 
On 13 September 2017 at 19:12, Timo Rothenpieler 
wrote:

> I did object and have NAK'd the patch currently.
>> Make the submitter submit a new version themselves and I'll approve it.
>>
>
> There was a new version submitted already, I just replied to the wrong one.
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Should be fine then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] kmsgrab: fix build error when use old libdrm

2017-09-13 Thread Jun Zhao 

From 8c7ddfcabf686f213aa59544d90055d20bdac0f7 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Wed, 13 Sep 2017 20:21:38 -0400
Subject: [PATCH] kmsgrab: fix build error when use old libdrm

DRM_FORMAT_R16 adding from libdrm 2.4.82, fix the build error
when libdrm < 2.4.82.

Signed-off-by: Jun Zhao 
---
 libavdevice/kmsgrab.c   | 2 ++
 libavutil/hwcontext_vaapi.c | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c
index d0b9cf5001..49eb44f6f2 100644
--- a/libavdevice/kmsgrab.c
+++ b/libavdevice/kmsgrab.c
@@ -203,7 +203,9 @@ static const struct {
 uint32_t drm_format;
 } kmsgrab_formats[] = {
 { AV_PIX_FMT_GRAY8,DRM_FORMAT_R8   },
+#ifdef DRM_FORMAT_R16
 { AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16  },
+#endif
 { AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888   },
 { AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888   },
 { AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 2cc6f26715..837b79da11 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -920,7 +920,7 @@ static const struct {
 } vaapi_drm_format_map[] = {
 DRM_MAP(NV12, 2, DRM_FORMAT_R8,  DRM_FORMAT_RG88),
 DRM_MAP(NV12, 1, DRM_FORMAT_NV12),
-#ifdef VA_FOURCC_P010
+#if defined(VA_FOURCC_P010) && defined(DRM_FORMAT_R16)
 DRM_MAP(P010, 2, DRM_FORMAT_R16, DRM_FORMAT_RG1616),
 #endif
 DRM_MAP(BGRA, 1, DRM_FORMAT_BGRA),
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [V5 2/4] lavc/vaapi_encode: Add max slices number query.

2017-09-13 Thread Jun Zhao 


On 2017/9/13 20:18, Moritz Barsnick wrote:
> On Thu, Aug 24, 2017 at 09:13:09 +0800, Jun Zhao wrote:
>> +// Supported max-slices number per frame. (0 means driver cannot
>> +// support max mutil-slices query)
>   ^ multi
>
> Moritz
Tks. will fix the typo.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [V5 3/4] lavc/vaapi_encode_h264: respect "slices" option in h264 vaapi encoder

2017-09-13 Thread Jun Zhao 


On 2017/9/13 20:20, Moritz Barsnick wrote:
> On Thu, Aug 24, 2017 at 09:13:20 +0800, Jun Zhao wrote:
>> +av_log(avctx, AV_LOG_ERROR, "The max slices number per frame "
>> +   "cannot more than %d.\n", ctx->max_slices);
> "cannot be more"
> (This remark also applies to the h265 patch.)
>
> Moritz
Tks, will fix the syntax in 264/265 patch.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 03/20] lavc: Add coded bitstream read/write API

2017-09-13 Thread Michael Niedermayer 
On Wed, Sep 13, 2017 at 12:43:53AM +0100, Mark Thompson wrote:
> (cherry picked from commit 18f1706f331bf5dd565774eae680508c8d3a97ad)
> (cherry picked from commit 44cde38c8acbef7d5250e6d1b52b1020871e093b)
> ---
>  configure |   1 +
>  libavcodec/Makefile   |   1 +
>  libavcodec/cbs.c  | 466 
> ++
>  libavcodec/cbs.h  | 274 +++
>  libavcodec/cbs_internal.h |  83 +
>  5 files changed, 825 insertions(+)
>  create mode 100644 libavcodec/cbs.c
>  create mode 100644 libavcodec/cbs.h
>  create mode 100644 libavcodec/cbs_internal.h
> 
> diff --git a/configure b/configure
> index 4dd11efe5e..2e84b1f892 100755
> --- a/configure
> +++ b/configure
> @@ -2112,6 +2112,7 @@ CONFIG_EXTRA="
>  blockdsp
>  bswapdsp
>  cabac
> +cbs
>  dirac_parse
>  dvprofile
>  exif
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 999632cf9e..d9612d68d0 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -59,6 +59,7 @@ OBJS-$(CONFIG_AUDIODSP)+= audiodsp.o
>  OBJS-$(CONFIG_BLOCKDSP)+= blockdsp.o
>  OBJS-$(CONFIG_BSWAPDSP)+= bswapdsp.o
>  OBJS-$(CONFIG_CABAC)   += cabac.o
> +OBJS-$(CONFIG_CBS) += cbs.o
>  OBJS-$(CONFIG_CRYSTALHD)   += crystalhd.o
>  OBJS-$(CONFIG_DCT) += dct.o dct32_fixed.o dct32_float.o
>  OBJS-$(CONFIG_ERROR_RESILIENCE)+= error_resilience.o
> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
> new file mode 100644
> index 00..13bc25728f
> --- /dev/null
> +++ b/libavcodec/cbs.c
> @@ -0,0 +1,466 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include 
> +
> +#include "config.h"
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/common.h"
> +
> +#include "cbs.h"
> +#include "cbs_internal.h"
> +
> +
> +static const CodedBitstreamType *cbs_type_table[] = {
> +};
> +
> +int ff_cbs_init(CodedBitstreamContext *ctx,
> +enum AVCodecID codec_id, void *log_ctx)
> +{
> +const CodedBitstreamType *type;
> +int i;
> +
> +type = NULL;
> +for (i = 0; i < FF_ARRAY_ELEMS(cbs_type_table); i++) {
> +if (cbs_type_table[i]->codec_id == codec_id) {
> +type = cbs_type_table[i];
> +break;
> +}
> +}
> +if (!type)
> +return AVERROR(EINVAL);
> +
> +ctx->log_ctx = log_ctx;
> +ctx->codec   = type;
> +
> +ctx->priv_data = av_mallocz(ctx->codec->priv_data_size);
> +if (!ctx->priv_data)
> +return AVERROR(ENOMEM);
> +
> +ctx->decompose_unit_types = NULL;
> +
> +ctx->trace_enable = 0;
> +ctx->trace_level  = AV_LOG_TRACE;
> +
> +return 0;
> +}
> +
> +void ff_cbs_close(CodedBitstreamContext *ctx)
> +{
> +if (ctx->codec && ctx->codec->close)
> +ctx->codec->close(ctx);
> +
> +av_freep(&ctx->priv_data);
> +}
> +
> +static void cbs_unit_uninit(CodedBitstreamContext *ctx,
> +CodedBitstreamUnit *unit)
> +{
> +if (ctx->codec->free_unit && unit->content && !unit->content_external)
> +ctx->codec->free_unit(unit);
> +
> +av_freep(&unit->data);
> +unit->data_size = 0;
> +unit->data_bit_padding = 0;
> +}
> +
> +void ff_cbs_fragment_uninit(CodedBitstreamContext *ctx,
> +CodedBitstreamFragment *frag)
> +{
> +int i;
> +
> +for (i = 0; i < frag->nb_units; i++)
> +cbs_unit_uninit(ctx, &frag->units[i]);
> +av_freep(&frag->units);
> +frag->nb_units = 0;
> +
> +av_freep(&frag->data);
> +frag->data_size= 0;
> +frag->data_bit_padding = 0;
> +}
> +
> +static int cbs_read_fragment_content(CodedBitstreamContext *ctx,
> + CodedBitstreamFragment *frag)
> +{
> +int err, i, j;
> +
> +for (i = 0; i < frag->nb_units; i++) {
> +if (ctx->decompose_unit_types) {
> +for (j = 0; j < ctx->nb_decompose_unit_types; j++) {
> +if (ctx->decompose_unit_types[j] == frag->units[i].type)
> +break;
> +}
> +if (j >= ctx->nb_decompose_unit_types)
> +

Re: [FFmpeg-devel] [PATCH 18/20] mpeg12: Move finding the best frame rate to common code

2017-09-13 Thread Michael Niedermayer 
On Wed, Sep 13, 2017 at 12:44:08AM +0100, Mark Thompson wrote:
> Previously in the mpeg2_metadata filter.  Also adds a test.
[...]
> +for (c = 1; c <= max_code; c++) {
> +for (n = 1; n <= (mpeg2 ? 4 : 1); n++) {
> +for (d = 1; d <= (mpeg2 ? 32 : 1); d++) {
> +AVRational test, error;
> +int cmp;
> +
> +test = av_mul_q(ff_mpeg12_frame_rate_tab[c],
> +(AVRational) { n, d });
> +
> +cmp = av_cmp_q(test, frame_rate);
> +if (cmp == 0) {
> +best_c = c;
> +best_n = n;
> +best_d = d;
> +goto found;
> +}
> +
> +if (cmp < 0)
> +error = av_div_q(frame_rate, test);
> +else
> +error = av_div_q(test, frame_rate);
> +
> +cmp = av_cmp_q(error, best_error);
> +if (cmp < 0 || (cmp == 0 && n == 1 && d == 1)) {
> +best_c = c;
> +best_n = n;
> +best_d = d;
> +best_error = error;
> +}
> +}
> +}
> +}
[...]
> -for (i = 1; i < FF_ARRAY_ELEMS(frame_rate_table); i++) {
> -AVRational fr, error;
> -int n, d, cmp;
> -for (n = 1; n <= 4; n++) {
> -for (d = 1; d <= 32; d++) {
> -fr = av_mul_q(frame_rate_table[i],
> -  (AVRational) { n, d });
> -cmp = av_cmp_q(fr, ctx->frame_rate);
> -if (cmp == 0) {
> -code  = i;
> -ext_n = n;
> -ext_d = d;
> -goto found_frame_rate;
> -}
> -if (cmp < 0)
> -error = av_div_q(ctx->frame_rate, fr);
> -else
> -error = av_div_q(fr, ctx->frame_rate);
> -cmp = av_cmp_q(error, best_error);
> -if (cmp < 0 || (cmp == 0 && n == 1 && d == 1)) {
> -code  = i;
> -ext_n = n;
> -ext_d = d;
> -best_error = error;
> -}
> -}
> -}
> -}

This doesnt just move the code, it also changes it
(this makes it harder to determine if the chnages are just cosmetic or
 not)

[...]

--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: add normalize filter

2017-09-13 Thread Richard Ling 
Hi,

This patch adds a filter to normalize (contrast stretch) RGB video.
Comments welcome.

R.

From f08f132ecd79718d0ce6fb07f99c84ab5dd52ee4 Mon Sep 17 00:00:00 2001
From: Richard Ling 
Date: Thu, 14 Sep 2017 13:18:50 +1000
Subject: [PATCH] avfilter: add normalize filter

---
 doc/filters.texi   |  79 +
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_normalize.c | 415
+
 4 files changed, 496 insertions(+)
 create mode 100644 libavfilter/vf_normalize.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 830de54..1e7712a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10808,6 +10808,85 @@ Add temporal and uniform noise to input video:
 noise=alls=20:allf=t+u
 @end example

+@section normalize
+
+Normalize RGB video (aka histogram stretching, contrast stretching).
+See: https://en.wikipedia.org/wiki/Normalization_(image_processing)
+
+For each channel of each frame, the filter computes the input range and
maps
+it linearly to the user-specified output range. The output range defaults
+to the full dynamic range from pure black to pure white.
+
+Temporal smoothing can be used on the input range to reduce flickering
(rapid
+changes in brightness) caused when small dark or bright objects enter or
leave
+the scene. This is similar to the auto-exposure (automatic gain control)
on a
+video camera, and, like a video camera, it may cause a period of over- or
+under-exposure of the video.
+
+The R,G,B channels can be normalized independently, which may cause some
+color shifting, or linked together as a single channel, which prevents
+color shifting. Linked normalization preserves hue. Independent
normalization
+does not, so it can be used to remove some color casts. Independent and
linked
+normalization can be combined in any ratio.
+
+The normalize filter accepts the following options:
+
+@table @option
+@item blackpt
+@item whitept
+Colors which define the output range. The minimum input value is mapped to
+the @var{blackpt}. The maximum input value is mapped to the @var{whitept}.
+The defaults are black and white respectively. Specifying white for
+@var{blackpt} and black for @var{whitept} will give color-inverted,
+normalized video. Shades of grey can be used to reduce the dynamic range
+(contrast). Specifying saturated colors here can create some interesting
+effects.
+
+@item smoothing
+The amount of temporal smoothing, expressed in seconds. the input range of
+each channel is smoothed using a rolling average over that many seconds of
+video. Defaults to 0.0 (no temporal smoothing).  The maximum is 60 seconds.
+
+@item independence
+Controls the ratio of independent (color shifting) channel normalization to
+linked (color preserving) normalization. 0.0 is fully linked, 1.0 is fully
+independent. Defaults to fully independent.
+
+@item strength
+Overall strength of the filter. 1.0 is full strength. 0.0 is a rather
+expensive no-op.
+
+@end table
+
+@subsection Examples
+
+Stretch video contrast to use the full dynamic range, with no temporal
+smoothing; may flicker depending on the source content:
+@example
+normalize=black:white:0
+@end example
+
+As above, but with 2 seconds of temporal smoothing; flicker should be
+reduced, depending on the source content:
+@example
+normalize=black:white:2
+@end example
+
+As above, but with hue-preserving linked channel normalization:
+@example
+normalize=black:white:2:1
+@end example
+
+As above, but with half strength:
+@example
+normalize=black:white:2:1:0.5
+@end example
+
+Map the darkest input color to red, the brightest input color to cyan:
+@example
+normalize=red:cyan
+@end example
+
 @section null

 Pass the video source unchanged to the output.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 8aa974e..31f8170 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -243,6 +243,7 @@ OBJS-$(CONFIG_NLMEANS_FILTER)+=
vf_nlmeans.o
 OBJS-$(CONFIG_NNEDI_FILTER)  += vf_nnedi.o
 OBJS-$(CONFIG_NOFORMAT_FILTER)   += vf_format.o
 OBJS-$(CONFIG_NOISE_FILTER)  += vf_noise.o
+OBJS-$(CONFIG_NORMALIZE_FILTER)  += vf_normalize.o
 OBJS-$(CONFIG_NULL_FILTER)   += vf_null.o
 OBJS-$(CONFIG_OCR_FILTER)+= vf_ocr.o
 OBJS-$(CONFIG_OCV_FILTER)+= vf_libopencv.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 63e8672..af2287b 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -255,6 +255,7 @@ static void register_all(void)
 REGISTER_FILTER(NNEDI,  nnedi,  vf);
 REGISTER_FILTER(NOFORMAT,   noformat,   vf);
 REGISTER_FILTER(NOISE,  noise,  vf);
+REGISTER_FILTER(NORMALIZE,  normalize,  vf);
 REGISTER_FILTER(NULL,   null,   vf);
 REGISTER_FILTER(OCR,ocr,vf);
 REGISTER_FILTER(OCV,

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-13 Thread James Almer 
On 9/7/2017 6:56 PM, Mark Thompson wrote:
> +pkt->data  = (uint8_t*)frame;
> +pkt->size  = sizeof(*frame);
> +pkt->pts   = now;
> +pkt->flags = AV_PKT_FLAG_TRUSTED;

pkt->flags |= AV_PKT_FLAG_TRUSTED;

I know pkt->flags is zeroed by default, but that may change in the
future. And ORing/XORing is the proper way to set flags anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] avdevice/decklink_dec: Added VANC search for all resolutions

2017-09-13 Thread Jeyapal, Karthick 
Thanks for your comments. Please find the patch attached as per your comments.

Regards,
Karthick


0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch
Description: 0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC

2017-09-13 Thread Jeyapal, Karthick 
Hi Marton,

Thanks a lot for your comments. I have modified the patch as per all your 
comments, except the below one.

>> +tgt = teletext_data_unit_from_ancillary_packet(buf, buf + 1920, 
>> tgt, cctx->teletext_lines, 0);
>
>this should be
>tgt = teletext_data_unit_from_ancillary_packet(buf, buf + len, 
> tgt, cctx->teletext_lines, 1);
>

I have modified it as

tgt = teletext_data_unit_from_ancillary_packet(buf, buf + len, tgt, 
cctx->teletext_lines, 0);

That was just to be in consistency with the existing code. Because current code 
passes allow_multipacket as 0. Let me know if my understanding here is correct.

Please find the patch attached.

Regards,
Karthick





0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
Description: 0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel