Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc non-uni hv mc msa functions

[Manojkumar Bhosale]

LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Monday, November 6, 2017 6:07 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc non-uni hv mc msa 
functions

From: Kaustubh Raste 

Use mask buffer.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevcdsp_msa.c | 1478 -
 1 file changed, 870 insertions(+), 608 deletions(-)

diff --git a/libavcodec/mips/hevcdsp_msa.c b/libavcodec/mips/hevcdsp_msa.c
index 73cc3ea..b17127c 100644
--- a/libavcodec/mips/hevcdsp_msa.c
+++ b/libavcodec/mips/hevcdsp_msa.c
@@ -22,6 +22,13 @@
 #include "libavcodec/mips/hevcdsp_mips.h"
 #include "libavcodec/mips/hevc_macros_msa.h"
 
+static const uint8_t ff_hevc_mask_arr[16 * 2] __attribute__((aligned(0x40))) = 
{
+/* 8 width cases */
+0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8,
+/* 4 width cases */
+0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20
+};
+
 static void hevc_copy_4w_msa(uint8_t *src, int32_t src_stride,
  int16_t *dst, int32_t dst_stride,
  int32_t height)
@@ -1308,31 +1315,28 @@ static void hevc_hv_8t_4w_msa(uint8_t *src, int32_t 
src_stride,
   int32_t height)
 {
 uint32_t loop_cnt;
-v16i8 src0, src1, src2, src3, src4, src5, src6, src7, src8;
+int32_t dst_stride_in_bytes = 2 * dst_stride;
+v16i8 src0, src1, src2, src3, src4, src5, src6, src7, src8, src9, src10;
 v8i16 filt0, filt1, filt2, filt3;
-v4i32 filt_h0, filt_h1, filt_h2, filt_h3;
+v8i16 filt_h0, filt_h1, filt_h2, filt_h3;
 v16i8 mask1, mask2, mask3;
 v8i16 filter_vec, const_vec;
 v16i8 vec0, vec1, vec2, vec3, vec4, vec5, vec6, vec7;
 v16i8 vec8, vec9, vec10, vec11, vec12, vec13, vec14, vec15;
-v8i16 dst30, dst41, dst52, dst63, dst66, dst87;
-v4i32 dst0_r, dst1_r;
-v8i16 dst10_r, dst32_r, dst54_r, dst76_r;
-v8i16 dst21_r, dst43_r, dst65_r, dst87_r;
-v16i8 mask0 = {
-0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20
-};
-v8u16 mask4 = { 0, 4, 1, 5, 2, 6, 3, 7 };
+v8i16 dst30, dst41, dst52, dst63, dst66, dst97, dst108;
+v4i32 dst0_r, dst1_r, dst2_r, dst3_r;
+v8i16 dst10_r, dst32_r, dst54_r, dst76_r, dst98_r;
+v8i16 dst21_r, dst43_r, dst65_r, dst87_r, dst109_r;
+v16i8 mask0 = LD_SB(ff_hevc_mask_arr + 16);
 
 src -= ((3 * src_stride) + 3);
 filter_vec = LD_SH(filter_x);
 SPLATI_H4_SH(filter_vec, 0, 1, 2, 3, filt0, filt1, filt2, filt3);
 
 filter_vec = LD_SH(filter_y);
-vec0 = __msa_clti_s_b((v16i8) filter_vec, 0);
-filter_vec = (v8i16) __msa_ilvr_b(vec0, (v16i8) filter_vec);
+UNPCK_R_SB_SH(filter_vec, filter_vec);
 
-SPLATI_W4_SW(filter_vec, filt_h0, filt_h1, filt_h2, filt_h3);
+SPLATI_W4_SH(filter_vec, filt_h0, filt_h1, filt_h2, filt_h3);
 
 mask1 = mask0 + 2;
 mask2 = mask0 + 4;
@@ -1364,47 +1368,56 @@ static void hevc_hv_8t_4w_msa(uint8_t *src, int32_t 
src_stride,
 DPADD_SB4_SH(vec12, vec13, vec14, vec15, filt0, filt1, filt2, filt3,
  dst63, dst63, dst63, dst63);
 
-ILVR_H3_SH(dst41, dst30, dst52, dst41, dst63, dst52,
-   dst10_r, dst21_r, dst32_r);
-dst43_r = __msa_ilvl_h(dst41, dst30);
-dst54_r = __msa_ilvl_h(dst52, dst41);
-dst65_r = __msa_ilvl_h(dst63, dst52);
+ILVRL_H2_SH(dst41, dst30, dst10_r, dst43_r);
+ILVRL_H2_SH(dst52, dst41, dst21_r, dst54_r);
+ILVRL_H2_SH(dst63, dst52, dst32_r, dst65_r);
 dst66 = (v8i16) __msa_splati_d((v2i64) dst63, 1);
 
-for (loop_cnt = height >> 1; loop_cnt--;) {
-LD_SB2(src, src_stride, src7, src8);
-src += (2 * src_stride);
-XORI_B2_128_SB(src7, src8);
+for (loop_cnt = height >> 2; loop_cnt--;) {
+LD_SB4(src, src_stride, src7, src8, src9, src10);
+src += (4 * src_stride);
+XORI_B4_128_SB(src7, src8, src9, src10);
 
-VSHF_B4_SB(src7, src8, mask0, mask1, mask2, mask3,
+VSHF_B4_SB(src7, src9, mask0, mask1, mask2, mask3,
vec0, vec1, vec2, vec3);
-dst87 = const_vec;
+VSHF_B4_SB(src8, src10, mask0, mask1, mask2, mask3,
+   vec4, vec5, vec6, vec7);
+dst97 = const_vec;
+dst108 = const_vec;
 DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt1, filt2, filt3,
- dst87, dst87, dst87, dst87);
-dst76_r = __msa_ilvr_h(dst87, dst66);
+ dst97, dst97, dst97, dst97);
+DPADD_SB4_SH(vec4, vec5, vec6, vec7, filt0, filt1, filt2, filt3,
+ dst108, dst108, dst108, dst108);
+
+dst76_r = __msa_ilvr_h(dst97, dst66);
+ILVRL_H2_SH(dst108, dst97, dst87_r, dst109_r);
+dst66 = (v8i16) __msa_splati_d((v2i64) dst97, 1);
+dst98_r = __msa_ilvr_h(dst66, 

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni weighted 4 tap vt mc msa functions

[Manojkumar Bhosale]

LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Monday, November 6, 2017 4:29 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni weighted 4 tap 
vt mc msa functions

From: Kaustubh Raste 

Use global mask buffer for appropriate mask load.
Use immediate unsigned saturation for clip to max saving one vector register.
Remove unused macro.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_uniw_msa.c | 1052 ++--
 1 file changed, 529 insertions(+), 523 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_uniw_msa.c 
b/libavcodec/mips/hevc_mc_uniw_msa.c
index 31fec73..f9ecb41 100644
--- a/libavcodec/mips/hevc_mc_uniw_msa.c
+++ b/libavcodec/mips/hevc_mc_uniw_msa.c
@@ -29,33 +29,6 @@ static const uint8_t ff_hevc_mask_arr[16 * 2] 
__attribute__((aligned(0x40))) = {
 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20
 };
 
-#define HEVC_UNIW_RND_CLIP2(in0, in1, wgt, offset, rnd,  \
-out0_r, out1_r, out0_l, out1_l)  \
-{\
-ILVR_H2_SW(in0, in0, in1, in1, out0_r, out1_r);  \
-ILVL_H2_SW(in0, in0, in1, in1, out0_l, out1_l);  \
-DOTP_SH4_SW(out0_r, out1_r, out0_l, out1_l, wgt, wgt, wgt, wgt,  \
-out0_r, out1_r, out0_l, out1_l); \
-SRAR_W4_SW(out0_r, out1_r, out0_l, out1_l, rnd); \
-ADD4(out0_r, offset, out1_r, offset, \
- out0_l, offset, out1_l, offset, \
- out0_r, out1_r, out0_l, out1_l);\
-out0_r = CLIP_SW_0_255(out0_r);  \
-out1_r = CLIP_SW_0_255(out1_r);  \
-out0_l = CLIP_SW_0_255(out0_l);  \
-out1_l = CLIP_SW_0_255(out1_l);  \
-}
-
-#define HEVC_UNIW_RND_CLIP4(in0, in1, in2, in3, wgt, offset, rnd,  \
-out0_r, out1_r, out2_r, out3_r,\
-out0_l, out1_l, out2_l, out3_l)\
-{  \
-HEVC_UNIW_RND_CLIP2(in0, in1, wgt, offset, rnd,\
-out0_r, out1_r, out0_l, out1_l);   \
-HEVC_UNIW_RND_CLIP2(in2, in3, wgt, offset, rnd,\
-out2_r, out3_r, out2_l, out3_l);   \
-}
-
 #define HEVC_UNIW_RND_CLIP2_MAX_SATU_H(in0_h, in1_h, wgt_w, offset_h, rnd_w,  \
out0_h, out1_h)\
 { \
@@ -3266,55 +3239,54 @@ static void hevc_vt_uniwgt_4t_4x2_msa(uint8_t *src,
   uint8_t *dst,
   int32_t dst_stride,
   const int8_t *filter,
-  int32_t height,
   int32_t weight,
   int32_t offset,
   int32_t rnd_val)
 {
+v16u8 out;
 v16i8 src0, src1, src2, src3, src4;
 v16i8 src10_r, src32_r, src21_r, src43_r;
 v16i8 src2110, src4332;
-v8i16 dst10;
+v8i16 dst0;
 v4i32 dst0_r, dst0_l;
 v8i16 filt0, filt1;
-v8i16 filter_vec, const_vec;
-v4i32 weight_vec, offset_vec, rnd_vec;
+v8i16 filter_vec, weight_vec_h, offset_vec, denom_vec;
+v4i32 weight_vec, rnd_vec;
 
 src -= src_stride;
 
-const_vec = __msa_ldi_h(128);
-const_vec <<= 6;
 weight = weight & 0x;
 
 weight_vec = __msa_fill_w(weight);
-offset_vec = __msa_fill_w(offset);
 rnd_vec = __msa_fill_w(rnd_val);
 
+weight *= 128;
+rnd_val -= 6;
+
+weight_vec_h = __msa_fill_h(weight);
+offset_vec = __msa_fill_h(offset);
+denom_vec = __msa_fill_h(rnd_val);
+
+weight_vec_h = __msa_srar_h(weight_vec_h, denom_vec);
+offset_vec = __msa_adds_s_h(offset_vec, weight_vec_h);
+
 filter_vec = LD_SH(filter);
 SPLATI_H2_SH(filter_vec, 0, 1, filt0, filt1);
 
-LD_SB3(src, src_stride, src0, src1, src2);
-src += (3 * src_stride);
+LD_SB5(src, src_stride, src0, src1, src2, src3, src4);
 ILVR_B2_SB(src1, src0, src2, src1, src10_r, src21_r);
-src2110 = (v16i8) __msa_ilvr_d((v2i64) src21_r, (v2i64) src10_r);
-src2110 = (v16i8) __msa_xori_b((v16u8) src2110, 128);
-LD_SB2(src, src_stride, src3, src4);
 ILVR_B2_SB(src3, src2, src4, src3, src32_r, src43_r);
-src4332 = (v16i8) __msa_ilvr_d((v2i64) src43_r, (v2i64) src32_r);
-src4332 = (v16i8) __msa_xori_b((v16u8) 

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni 4 tap hv mc msa functions

[Manojkumar Bhosale]

LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Monday, November 6, 2017 4:21 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni 4 tap hv mc msa 
functions

From: Kaustubh Raste 

Use global mask buffer for appropriate mask load.
Remove unused macro and table.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_uni_msa.c | 1125 +++--
 1 file changed, 566 insertions(+), 559 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_uni_msa.c 
b/libavcodec/mips/hevc_mc_uni_msa.c
index 993dad0..740c970 100644
--- a/libavcodec/mips/hevc_mc_uni_msa.c
+++ b/libavcodec/mips/hevc_mc_uni_msa.c
@@ -283,25 +283,6 @@ static void copy_width64_msa(uint8_t *src, int32_t 
src_stride,
 }
 }
 
-static const uint8_t mc_filt_mask_arr[16 * 3] = {
-/* 8 width cases */
-0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8,
-/* 4 width cases */
-0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20,
-/* 4 width cases */
-8, 9, 9, 10, 10, 11, 11, 12, 24, 25, 25, 26, 26, 27, 27, 28
-};
-
-#define FILT_4TAP_DPADD_S_H(vec0, vec1, filt0, filt1)   \
-( { \
-v8i16 tmp0; \
-\
-tmp0 = __msa_dotp_s_h((v16i8) vec0, (v16i8) filt0); \
-tmp0 = __msa_dpadd_s_h(tmp0, (v16i8) vec1, (v16i8) filt1);  \
-\
-tmp0;   \
-} )
-
 static void common_hz_8t_4x4_msa(uint8_t *src, int32_t src_stride,
  uint8_t *dst, int32_t dst_stride,
  const int8_t *filter)
@@ -3109,19 +3090,18 @@ static void hevc_hv_uni_4t_4x2_msa(uint8_t *src,
uint8_t *dst,
int32_t dst_stride,
const int8_t *filter_x,
-   const int8_t *filter_y,
-   int32_t height)
+   const int8_t *filter_y)
 {
+v16u8 out;
 v16i8 src0, src1, src2, src3, src4;
 v8i16 filt0, filt1;
-v4i32 filt_h0, filt_h1;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8 };
+v8i16 filt_h0, filt_h1;
+v16i8 mask0 = LD_SB(ff_hevc_mask_arr + 16);
 v16i8 mask1;
-v8i16 filter_vec, const_vec;
+v8i16 filter_vec, tmp;
 v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v8i16 dst0, dst1, dst2, dst3, dst4;
-v4i32 dst0_r, dst1_r;
-v8i16 dst10_r, dst32_r, dst21_r, dst43_r;
+v8i16 dst20, dst31, dst42, dst10, dst32, dst21, dst43;
+v4i32 dst0, dst1;
 
 src -= (src_stride + 1);
 
@@ -3129,60 +3109,35 @@ static void hevc_hv_uni_4t_4x2_msa(uint8_t *src,
 SPLATI_H2_SH(filter_vec, 0, 1, filt0, filt1);
 
 filter_vec = LD_SH(filter_y);
-vec0 = __msa_clti_s_b((v16i8) filter_vec, 0);
-filter_vec = (v8i16) __msa_ilvr_b(vec0, (v16i8) filter_vec);
+UNPCK_R_SB_SH(filter_vec, filter_vec);
 
-SPLATI_W2_SW(filter_vec, 0, filt_h0, filt_h1);
+SPLATI_W2_SH(filter_vec, 0, filt_h0, filt_h1);
 
 mask1 = mask0 + 2;
 
-const_vec = __msa_ldi_h(128);
-const_vec <<= 6;
-
-LD_SB3(src, src_stride, src0, src1, src2);
-src += (3 * src_stride);
-
-XORI_B3_128_SB(src0, src1, src2);
-
-VSHF_B2_SB(src0, src0, src0, src0, mask0, mask1, vec0, vec1);
-VSHF_B2_SB(src1, src1, src1, src1, mask0, mask1, vec2, vec3);
-VSHF_B2_SB(src2, src2, src2, src2, mask0, mask1, vec4, vec5);
-
-dst0 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst0, dst0);
-dst1 = const_vec;
-DPADD_SB2_SH(vec2, vec3, filt0, filt1, dst1, dst1);
-dst2 = const_vec;
-DPADD_SB2_SH(vec4, vec5, filt0, filt1, dst2, dst2);
-
-ILVR_H2_SH(dst1, dst0, dst2, dst1, dst10_r, dst21_r);
-LD_SB2(src, src_stride, src3, src4);
-XORI_B2_128_SB(src3, src4);
-
-/* row 3 */
-VSHF_B2_SB(src3, src3, src3, src3, mask0, mask1, vec0, vec1);
-dst3 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst3, dst3);
-
-dst32_r = __msa_ilvr_h(dst3, dst2);
-dst0_r = HEVC_FILT_4TAP(dst10_r, dst32_r, filt_h0, filt_h1);
-dst0_r >>= 6;
-
-/* row 4 */
-VSHF_B2_SB(src4, src4, src4, src4, mask0, mask1, vec0, vec1);
-dst4 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst4, dst4);
-
-dst43_r = __msa_ilvr_h(dst4, dst3);
-dst1_r = HEVC_FILT_4TAP(dst21_r, dst43_r, filt_h0, filt_h1);
-dst1_r >>= 6;
-
-dst0_r = (v4i32) __msa_pckev_h((v8i16) dst1_r, (v8i16) dst0_r);
-dst0_r = (v4i32) __msa_srari_h((v8i16) dst0_r, 6);
-dst0_r = (v4i32) CLIP_SH_0_255(dst0_r);
-dst0_r = 

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi wgt 4 tap hv mc msa functions

[Manojkumar Bhosale]

LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Monday, November 6, 2017 11:33 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi wgt 4 tap hv mc 
msa functions

From: Kaustubh Raste 

Use global mask buffer for appropriate mask load.
Use immediate unsigned saturation for clip to max saving one vector register.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_biw_msa.c | 1396 +++--
 1 file changed, 872 insertions(+), 524 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_biw_msa.c 
b/libavcodec/mips/hevc_mc_biw_msa.c
index 0e5f8a0..ea65f00 100644
--- a/libavcodec/mips/hevc_mc_biw_msa.c
+++ b/libavcodec/mips/hevc_mc_biw_msa.c
@@ -4495,26 +4495,25 @@ static void hevc_hv_biwgt_4t_4x2_msa(uint8_t *src0_ptr,
  int32_t dst_stride,
  const int8_t *filter_x,
  const int8_t *filter_y,
- int32_t height,
  int32_t weight0,
  int32_t weight1,
  int32_t offset0,
  int32_t offset1,
  int32_t rnd_val)
 {
+uint64_t tp0, tp1;
 int32_t offset, weight;
-v8i16 in0, in1;
+v8i16 in0 = { 0 };
+v16u8 out;
 v16i8 src0, src1, src2, src3, src4;
 v8i16 filt0, filt1;
-v4i32 filt_h0, filt_h1;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8 };
+v8i16 filt_h0, filt_h1;
+v16i8 mask0 = LD_SB(ff_hevc_mask_arr + 16);
 v16i8 mask1;
-v8i16 filter_vec, const_vec;
+v8i16 filter_vec, tmp, weight_vec;
 v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v8i16 dst0, dst1, dst2, dst3, dst4;
-v4i32 dst0_r, dst1_r, dst0_l;
-v8i16 dst10_r, dst32_r, dst21_r, dst43_r;
-v4i32 weight_vec, offset_vec, rnd_vec;
+v8i16 dst20, dst31, dst42, dst10, dst32, dst21, dst43, tmp0, tmp1;
+v4i32 dst0, dst1, offset_vec, rnd_vec, const_vec;
 
 src0_ptr -= (src_stride + 1);
 
@@ -4522,10 +4521,9 @@ static void hevc_hv_biwgt_4t_4x2_msa(uint8_t *src0_ptr,
 SPLATI_H2_SH(filter_vec, 0, 1, filt0, filt1);
 
 filter_vec = LD_SH(filter_y);
-vec0 = __msa_clti_s_b((v16i8) filter_vec, 0);
-filter_vec = (v8i16) __msa_ilvr_b(vec0, (v16i8) filter_vec);
+UNPCK_R_SB_SH(filter_vec, filter_vec);
 
-SPLATI_W2_SW(filter_vec, 0, filt_h0, filt_h1);
+SPLATI_W2_SH(filter_vec, 0, filt_h0, filt_h1);
 
 mask1 = mask0 + 2;
 
@@ -4533,56 +4531,44 @@ static void hevc_hv_biwgt_4t_4x2_msa(uint8_t *src0_ptr,
 weight0 = weight0 & 0x;
 weight = weight0 | (weight1 << 16);
 
-const_vec = __msa_ldi_h(128);
+const_vec = __msa_fill_w((128 * weight1));
 const_vec <<= 6;
 offset_vec = __msa_fill_w(offset);
-weight_vec = __msa_fill_w(weight);
+weight_vec = (v8i16) __msa_fill_w(weight);
 rnd_vec = __msa_fill_w(rnd_val + 1);
+offset_vec += const_vec;
 
-LD_SB3(src0_ptr, src_stride, src0, src1, src2);
-src0_ptr += (3 * src_stride);
-XORI_B3_128_SB(src0, src1, src2);
+LD_SB5(src0_ptr, src_stride, src0, src1, src2, src3, src4);
+XORI_B5_128_SB(src0, src1, src2, src3, src4);
 
-VSHF_B2_SB(src0, src0, src0, src0, mask0, mask1, vec0, vec1);
-VSHF_B2_SB(src1, src1, src1, src1, mask0, mask1, vec2, vec3);
-VSHF_B2_SB(src2, src2, src2, src2, mask0, mask1, vec4, vec5);
-dst0 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst0, dst0);
-dst1 = const_vec;
-DPADD_SB2_SH(vec2, vec3, filt0, filt1, dst1, dst1);
-dst2 = const_vec;
-DPADD_SB2_SH(vec4, vec5, filt0, filt1, dst2, dst2);
-ILVR_H2_SH(dst1, dst0, dst2, dst1, dst10_r, dst21_r);
+VSHF_B2_SB(src0, src2, src0, src2, mask0, mask1, vec0, vec1);
+VSHF_B2_SB(src1, src3, src1, src3, mask0, mask1, vec2, vec3);
+VSHF_B2_SB(src2, src4, src2, src4, mask0, mask1, vec4, vec5);
 
-LD_SB2(src0_ptr, src_stride, src3, src4);
-LD_SH2(src1_ptr, src2_stride, in0, in1);
-in0 = (v8i16) __msa_ilvr_d((v2i64) in1, (v2i64) in0);
-XORI_B2_128_SB(src3, src4);
-/* row 3 */
-VSHF_B2_SB(src3, src3, src3, src3, mask0, mask1, vec0, vec1);
-dst3 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst3, dst3);
-dst32_r = __msa_ilvr_h(dst3, dst2);
-dst0_r = HEVC_FILT_4TAP(dst10_r, dst32_r, filt_h0, filt_h1);
-dst0_r >>= 6;
-/* row 4 */
-VSHF_B2_SB(src4, src4, src4, src4, mask0, mask1, vec0, vec1);
-dst4 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst4, dst4);
-dst43_r = __msa_ilvr_h(dst4, dst3);
-dst1_r = HEVC_FILT_4TAP(dst21_r, dst43_r, filt_h0, filt_h1);
-dst1_r >>= 6;
-dst1_r = (v4i32) __msa_pckev_h((v8i16) 

Re: [FFmpeg-devel] [PATCH 2/4] libavformat/tcp: Added an option to reuse sockets

[Jeyapal, Karthick]

>On 11/3/17, 9:44 PM, "Aman Gupta"  wrote:
>
>I recently implemented keepalive support in the hls demuxer, and have been
>using it with a lot of success. See my patchset:
>http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/217353.html
>
>Aman

Thanks a lot for your excellent suggestion. 
I was not aware of the global function ff_http_do_new_request.
Now I will attempt to re-implement this feature along similar lines of your 
patch.

Regards,
Karthick 

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

Re: [FFmpeg-devel] [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input format

[Jeyapal, Karthick]

>On 11/6/17, 6:19 AM, "Marton Balint"  wrote:
>
>>On Fri, 27 Oct 2017, Jeyapal, Karthick wrote:
>
>> Please find the patch attached.
>>
>
>Thanks, below some comments:

Thanks a lot for your detailed comments. I have incorporated all your comments 
in this new patch(es).
Also, I have split it as two patches as you suggested. Please find them 
attached.

Regards,
Karthick




0001-libavdevice-decklink-Refactored-ff_decklink_set_form.patch
Description: 0001-libavdevice-decklink-Refactored-ff_decklink_set_form.patch


0002-libavdevice-decklink_dec-Autodetect-the-video-input-.patch
Description: 0002-libavdevice-decklink_dec-Autodetect-the-video-input-.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH V2] examples/vaapi_encode: Add a VA-API encode example.

[Jun Zhao]

V2: Fix the build error (avfiltergraph.h have been remove with merge
99ba85a0).
From 48fa48129de4f81812c2c11faf30fff7312640d4 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 6 Nov 2017 14:45:27 +0800
Subject: [PATCH V2] examples/vaapi_encode: Add a VA-API encode example.

add a VA-API encode example, only support NV12 input, usage like:
./vaapi_encode 1920 1080 test.yuv test.h264

Signed-off-by: Jun Zhao 
Signed-off-by: Liu, Kaixuan 
---
 configure   |   2 +
 doc/examples/Makefile   |   1 +
 doc/examples/vaapi_encode.c | 308 
 3 files changed, 311 insertions(+)
 create mode 100644 doc/examples/vaapi_encode.c

diff --git a/configure b/configure
index 83b4cc9364..a4d39712c3 100755
--- a/configure
+++ b/configure
@@ -1524,6 +1524,7 @@ EXAMPLE_LIST="
 scaling_video_example
 transcode_aac_example
 transcoding_example
+vaapi_encode_example
 "
 
 EXTERNAL_AUTODETECT_LIBRARY_LIST="
@@ -3294,6 +3295,7 @@ resampling_audio_example_deps="avutil swresample"
 scaling_video_example_deps="avutil swscale"
 transcode_aac_example_deps="avcodec avformat swresample"
 transcoding_example_deps="avfilter avcodec avformat avutil"
+vaapi_encode_example_deps="avfilter avcodec avformat avutil"
 
 # EXTRALIBS_LIST
 cpu_init_extralibs="pthreads_extralibs"
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 58afd71b85..da5af36532 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -19,6 +19,7 @@ EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE)  += 
resampling_audio
 EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video
 EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac
 EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE)   += transcoding
+EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE)  += vaapi_encode
 
 EXAMPLES   := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)$(EXESUF))
 EXAMPLES_G := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)_g$(EXESUF))
diff --git a/doc/examples/vaapi_encode.c b/doc/examples/vaapi_encode.c
new file mode 100644
index 00..462ae47b5a
--- /dev/null
+++ b/doc/examples/vaapi_encode.c
@@ -0,0 +1,308 @@
+/*
+ * Video Acceleration API (video encoding) encode sample
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * Intel VAAPI-accelerated encoding example.
+ *
+ * @example vaapi_encode.c
+ * This example shows how to do VAAPI-accelerated encoding. now only support 
NV12
+ * raw file, usage like: vaapi_enc 1920 1080 input.yuv output.h264
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+typedef struct FilterContext {
+AVFilterContext *buffersink_ctx;
+AVFilterContext *buffersrc_ctx;
+AVFilterGraph   *filter_graph;
+} FilterContext;
+
+static int width, height;
+static AVBufferRef *hw_device_ctx = NULL;
+
+static int init_filter(FilterContext *filter_ctx, char *args, AVBufferRef 
*hw_device_ctx)
+{
+char filter_spec[] = "format=nv12,hwupload";
+int  ret = 0, i = 0;
+const AVFilter *buffersrc, *buffersink;
+AVFilterContext *buffersrc_ctx, *buffersink_ctx;
+AVFilterInOut *outputs = avfilter_inout_alloc();
+AVFilterInOut *inputs  = avfilter_inout_alloc();
+AVFilterGraph *filter_graph = avfilter_graph_alloc();
+
+buffersrc = avfilter_get_by_name("buffer");
+buffersink = avfilter_get_by_name("buffersink");
+if (!buffersrc || !buffersink) {
+av_log(NULL, AV_LOG_ERROR, "filtering source or sink element not 
found\n");
+ret = AVERROR_UNKNOWN;
+goto fail;
+}
+
+ret = avfilter_graph_create_filter(_ctx, buffersrc, "in",
+   args, NULL, filter_graph);
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR, "Cannot create buffer source. Error 
code:%s\n", av_err2str(ret));
+goto fail;
+}
+ret = avfilter_graph_create_filter(_ctx, buffersink, "out",
+   NULL, NULL, filter_graph);
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR, "Cannot create buffer sink. Error 
code:%s\n", av_err2str(ret));
+goto fail;
+}
+
+outputs->name   = av_strdup("in");
+

Re: [FFmpeg-devel] [PATCH] examples/vaapi_encode: Add a VA-API encode example.

[Jun Zhao]

On 2017/11/7 9:38, Michael Niedermayer wrote:
> On Mon, Nov 06, 2017 at 02:56:16PM +0800, Jun Zhao wrote:
>>  configure   |2 
>>  doc/examples/Makefile   |1 
>>  doc/examples/vaapi_encode.c |  308 
>> 
>>  3 files changed, 311 insertions(+)
>> b4a1cfca5fb56770fae68218661f060e25ffe769  
>> 0001-examples-vaapi_encode-Add-a-VA-API-encode-example.patch
>> From d16f766363d9ecc240b0f8e025c2a8f91ea4775e Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Mon, 6 Nov 2017 14:45:27 +0800
>> Subject: [PATCH] examples/vaapi_encode: Add a VA-API encode example.
>>
>> add a VA-API encode example, only support NV12 input, usage like:
>> ./vaapi_encode 1920 1080 test.yuv test.h264
>>
>> Signed-off-by: Jun Zhao 
>> Signed-off-by: Liu, Kaixuan 
>> ---
>>  configure   |   2 +
>>  doc/examples/Makefile   |   1 +
>>  doc/examples/vaapi_encode.c | 308 
>> 
>>  3 files changed, 311 insertions(+)
>>  create mode 100644 doc/examples/vaapi_encode.c
> fails to build
> arm$ make examples
> CC  doc/examples/vaapi_encode.o
> src/doc/examples/vaapi_encode.c:36:39: fatal error: 
> libavfilter/avfiltergraph.h: No such file or directory
> compilation terminated.
> make: *** [doc/examples/vaapi_encode.o] Error 1
>
>
> [...]
Will submit V2 to fix the build error. Tks.
>
>
> ___
> 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 v3] pngdec: expose gAMA and cHRM chunks as side data

[Michael Niedermayer]

On Mon, Nov 06, 2017 at 05:59:27PM +, Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/pngdec.c | 32 
>  1 file changed, 32 insertions(+)

probably ok if tested

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Michael Niedermayer]

On Tue, Nov 07, 2017 at 01:36:57AM +, Mironov, Mikhail wrote:
> 
> 
> > theres no match for ID3D11VideoContext in my d3d11.h
> 
> > my mingw stuff should be just the official packages from
> > ubuntu LTS 14.04
> 
> Then how would you compile hwcontext_d3d11va.h where ID3D11DeviceContext and 
> ID3D11VideoDevice  are used?

config.h lists:
#define CONFIG_D3D11VA 0

so this would not get compiled as its disabled


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

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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

Re: [FFmpeg-devel] libavcodec/mpegvideo : remove warning introduce by previous patch

[James Almer]

On 11/6/2017 8:05 PM, Martin Vignali wrote:
> Hello,
> 
> Sorry, i put the ret variable declaration in the previous patch, at the
> wrong place (at the start of the func, instead of inside the
> FF_API_DEBUG_MV part
> 
> patch in attach fix warning,
> 
> Martin

I'm not sure why you bothered to change disabled code in the first
place, but pushed nonetheless.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] examples/vaapi_encode: Add a VA-API encode example.

[Michael Niedermayer]

On Mon, Nov 06, 2017 at 02:56:16PM +0800, Jun Zhao wrote:
> 

>  configure   |2 
>  doc/examples/Makefile   |1 
>  doc/examples/vaapi_encode.c |  308 
> 
>  3 files changed, 311 insertions(+)
> b4a1cfca5fb56770fae68218661f060e25ffe769  
> 0001-examples-vaapi_encode-Add-a-VA-API-encode-example.patch
> From d16f766363d9ecc240b0f8e025c2a8f91ea4775e Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Mon, 6 Nov 2017 14:45:27 +0800
> Subject: [PATCH] examples/vaapi_encode: Add a VA-API encode example.
> 
> add a VA-API encode example, only support NV12 input, usage like:
> ./vaapi_encode 1920 1080 test.yuv test.h264
> 
> Signed-off-by: Jun Zhao 
> Signed-off-by: Liu, Kaixuan 
> ---
>  configure   |   2 +
>  doc/examples/Makefile   |   1 +
>  doc/examples/vaapi_encode.c | 308 
> 
>  3 files changed, 311 insertions(+)
>  create mode 100644 doc/examples/vaapi_encode.c

fails to build
arm$ make examples
CC  doc/examples/vaapi_encode.o
src/doc/examples/vaapi_encode.c:36:39: fatal error: 
libavfilter/avfiltergraph.h: No such file or directory
compilation terminated.
make: *** [doc/examples/vaapi_encode.o] Error 1


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> theres no match for ID3D11VideoContext in my d3d11.h

> my mingw stuff should be just the official packages from
> ubuntu LTS 14.04

Then how would you compile hwcontext_d3d11va.h where ID3D11DeviceContext and 
ID3D11VideoDevice  are used?

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

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Michael Niedermayer]

On Mon, Nov 06, 2017 at 11:28:38PM +, Mironov, Mikhail wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Michael Niedermayer
> > Sent: November 6, 2017 5:47 PM
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> > GPUs based on AMF SDK
> > 
> > On Sat, Nov 04, 2017 at 10:49:44PM -0500, Mikhail Mironov wrote:
> > > From fc6a3f63eb9c3734f4101cee2a2f5707e063ab62 Mon Sep 17 00:00:00
> > 2001
> > > From: mmironov 
> > > Date: Fri, 27 Oct 2017 13:03:15 -0400
> > > Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for
> > AMD
> > > GPUs  based on AMF SDK
> > >
> > > Signed-off-by: mmironov 
> > > ---
> > >  Changelog|3 +-
> > >  compat/amd/amfsdkenc.h   | 1753
> > ++
> > >  configure|   25 +
> > >  libavcodec/Makefile  |4 +
> > >  libavcodec/allcodecs.c   |2 +
> > >  libavcodec/amfenc.c  |  515 ++
> > >  libavcodec/amfenc.h  |  137 
> > >  libavcodec/amfenc_h264.c |  366 ++  libavcodec/amfenc_hevc.c
> > > |  294 
> > >  libavcodec/version.h |4 +-
> > >  10 files changed, 3100 insertions(+), 3 deletions(-)  create mode
> > > 100644 compat/amd/amfsdkenc.h  create mode 100644
> > libavcodec/amfenc.c
> > > create mode 100644 libavcodec/amfenc.h  create mode 100644
> > > libavcodec/amfenc_h264.c  create mode 100644 libavcodec/amfenc_hevc.c
> > 
> > This seems to fail building in mingw64
> 
> This is strange. Just in case: my build setup is described here:
> https://github.com/Xaymar/ffmpeg-amf/blob/master/Build.txt
> 
> I also attached full amfsdkenc.h header file in case I made a mistake with 
> git integration.
> 
> 
> > 
> > make
> > CC  libavcodec/amfenc.o
> > In file included from src/libavcodec/amfenc.c:22:0:
> > src/libavutil/hwcontext_d3d11va.h:71:5: error: unknown type name
> > ‘ID3D11VideoDevice’
> >  ID3D11VideoDevice   *video_device;
> >  ^
> > src/libavutil/hwcontext_d3d11va.h:79:5: error: unknown type name
> > ‘ID3D11VideoContext’
> >  ID3D11VideoContext  *video_context;
> >  ^
> 
> This is declared in d3d11.h and came with mingw64. Mine version has it:
> msys64new\mingw64\x86_64-w64-mingw32\include\d3d11.h  - attached.
> Is it possible that we use different versions of mingw? Do you have it 
> declared?

theres no match for ID3D11VideoContext in my d3d11.h

my mingw stuff should be just the official packages from
ubuntu LTS 14.04

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc avg mc 10, 30, 01 and 03 msa functions

[Michael Niedermayer]

On Mon, Nov 06, 2017 at 01:20:16PM +, Manojkumar Bhosale wrote:
> LGTM

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi 4 tap hv mc msa functions

[Michael Niedermayer]

On Mon, Nov 06, 2017 at 01:20:51PM +, Manojkumar Bhosale wrote:
> LGTM

will apply

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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

Re: [FFmpeg-devel] [PATCH] avformat: move priv_pts from AVStream to an internal struct

[Michael Niedermayer]

On Sun, Nov 05, 2017 at 03:06:56PM -0300, James Almer wrote:
> It has no reason to be in a public header, even if defined as private.
> 
> Signed-off-by: James Almer 
> ---
> To be honest, none of the fields below the "not part of the API" notice
> have any reason to be in the public struct, but this one is particularly
> pointless and ugly to have there as FFFrac is defined in internal.h
> 
>  libavformat/avformat.h |  2 --
>  libavformat/internal.h |  2 ++
>  libavformat/mux.c  | 18 +-
>  libavformat/utils.c|  6 +++---
>  4 files changed, 14 insertions(+), 14 deletions(-)

probably ok

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

Re: [FFmpeg-devel] Must I subscribe to ffmpeg-devel in order to submit a patch?

[Lou Logan]

Hi,

On Sat, 4 Nov 2017 21:52:28 -0700
Jim DeLaHunt  wrote:

> Hello, ffmpeg developers:
> 
> I'm gearing up to submit a patch, adding an FAQ to the documentation. 
> According to , 
> "Patches should be posted to the ffmpeg-devel 
>  mailing list."  
> But neither that section, nor the ffmpeg-devel list information at 
>  is clear about 
> whether one must be subscribed to the list in order to post to it.

No, you do not need to be subscribed to any mailing list to send a
message or a patch.

However:

* You will not directly receive replies unless you ask to be CCd (and
  replying users will occasionally forget to do so).

* Your messages will remain in the moderation queue until a mailing
  list admin manually approves it which usually occurs once or twice a
  day but sometimes longer.

Although it is not necessary to do so it is recommended to subscribe
when submitting patches for these reasons. The volume of messages may be
considered to be high, but filtering the messages by List-Id is
effective in filtering them to a dedicated location. You can always
unsubscribe or disable receiving messages once your patch has been
accepted.

If you still do not want to subscribe you can always view messages and
reply via the archives:



Speaking of which, I CCd you but others who have replied may not have
so see the archives for their replies:


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

[FFmpeg-devel] libavcodec/mpegvideo : remove warning introduce by previous patch

[Martin Vignali]

Hello,

Sorry, i put the ret variable declaration in the previous patch, at the
wrong place (at the start of the func, instead of inside the
FF_API_DEBUG_MV part

patch in attach fix warning,

Martin


0001-libavcodec-mepgvideo-remove-warning-introduce-by-pre.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Michael Niedermayer]

On Sat, Nov 04, 2017 at 10:49:44PM -0500, Mikhail Mironov wrote:
> From fc6a3f63eb9c3734f4101cee2a2f5707e063ab62 Mon Sep 17 00:00:00 2001
> From: mmironov 
> Date: Fri, 27 Oct 2017 13:03:15 -0400
> Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for AMD GPUs
>  based on AMF SDK
> 
> Signed-off-by: mmironov 
> ---
>  Changelog|3 +-
>  compat/amd/amfsdkenc.h   | 1753 
> ++
>  configure|   25 +
>  libavcodec/Makefile  |4 +
>  libavcodec/allcodecs.c   |2 +
>  libavcodec/amfenc.c  |  515 ++
>  libavcodec/amfenc.h  |  137 
>  libavcodec/amfenc_h264.c |  366 ++
>  libavcodec/amfenc_hevc.c |  294 
>  libavcodec/version.h |4 +-
>  10 files changed, 3100 insertions(+), 3 deletions(-)
>  create mode 100644 compat/amd/amfsdkenc.h
>  create mode 100644 libavcodec/amfenc.c
>  create mode 100644 libavcodec/amfenc.h
>  create mode 100644 libavcodec/amfenc_h264.c
>  create mode 100644 libavcodec/amfenc_hevc.c

This seems to fail building in mingw64

make
CC  libavcodec/amfenc.o
In file included from src/libavcodec/amfenc.c:22:0:
src/libavutil/hwcontext_d3d11va.h:71:5: error: unknown type name 
‘ID3D11VideoDevice’
 ID3D11VideoDevice   *video_device;
 ^
src/libavutil/hwcontext_d3d11va.h:79:5: error: unknown type name 
‘ID3D11VideoContext’
 ID3D11VideoContext  *video_context;
 ^
In file included from src/libavcodec/amfenc.h:24:0,
 from src/libavcodec/amfenc.c:27:
src/compat/amd/amfsdkenc.h:191:23: error: no previous prototype for 
‘AMFConstructRect’ [-Werror=missing-prototypes]
 AMF_INLINE struct AMFRect AMFConstructRect(amf_int32 left, amf_int32 top, 
amf_int32 right, amf_int32 bottom)
   ^
src/compat/amd/amfsdkenc.h:203:23: error: no previous prototype for 
‘AMFConstructSize’ [-Werror=missing-prototypes]
 AMF_INLINE struct AMFSize AMFConstructSize(amf_int32 width, amf_int32 height)
   ^
src/compat/amd/amfsdkenc.h:215:24: error: no previous prototype for 
‘AMFConstructPoint’ [-Werror=missing-prototypes]
 AMF_INLINE struct AMFPoint AMFConstructPoint(amf_int32 x, amf_int32 y)
^
src/compat/amd/amfsdkenc.h:227:23: error: no previous prototype for 
‘AMFConstructRate’ [-Werror=missing-prototypes]
 AMF_INLINE struct AMFRate AMFConstructRate(amf_uint32 num, amf_uint32 den)
   ^
src/compat/amd/amfsdkenc.h:239:24: error: no previous prototype for 
‘AMFConstructRatio’ [-Werror=missing-prototypes]
 AMF_INLINE struct AMFRatio AMFConstructRatio(amf_uint32 num, amf_uint32 den)
^
In file included from src/libavcodec/amfenc.h:24:0,
 from src/libavcodec/amfenc.c:27:
src/compat/amd/amfsdkenc.h:275:24: error: no previous prototype for 
‘AMFConstructColor’ [-Werror=missing-prototypes]
 AMF_INLINE struct AMFColor AMFConstructColor(amf_uint8 r, amf_uint8 g, 
amf_uint8 b, amf_uint8 a)
^
In file included from src/libavcodec/amfenc.h:24:0,
 from src/libavcodec/amfenc.c:27:
src/compat/amd/amfsdkenc.h:293:45: error: no previous prototype for 
‘amf_variant_alloc’ [-Werror=missing-prototypes]
 AMF_INLINE void* AMF_CDECL_CALL amf_variant_alloc(amf_size count)
 ^
src/compat/amd/amfsdkenc.h:297:44: error: no previous prototype for 
‘amf_variant_free’ [-Werror=missing-prototypes]
 AMF_INLINE void AMF_CDECL_CALL amf_variant_free(void* ptr)
^
cc1: some warnings being treated as errors
make: *** [libavcodec/amfenc.o] Error 1


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] remove last use of deprecated avcodec_get_chroma_sub_sample

[James Almer]

On 11/6/2017 6:47 PM, Martin Vignali wrote:
> Hello,
> 
> patch in attach remove last use of this func
> replace it by av_pix_fmt_get_chroma_sub_sample, and return check
> 
> remove several warning
> 
> based on previous patch by Nicolas Frattaroli
> 
> 
> also remove the comment, where it's recommanded to use the deprecated func

Split and pushed. Thanks.

> 
> pass fate test for me
> 
> 
> Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter:vf_libvmaf: fix errors while running with psnr=1 and improve docs

[Carl Eugen Hoyos]

2017-11-06 21:27 GMT+01:00 Ronald S. Bultje :
> Hi,
>
> On Mon, Nov 6, 2017 at 1:58 PM, Carl Eugen Hoyos  wrote:
>
>> It is one thing to know that within FFmpeg, we do not modify
>> a pointer target and therefore decide to cast, but isn't it
>> another (bad) thing to assume this for an external library?
>
> I'm guessing that what you mean is "libvmaf may not touch it right now, but
> the API doesn't guarantee that such an implementation detail doesn't change
> in the future", right?
>
> Yes, you're right. Potential solutions are to make libvmaf const-correct or
> to strdup in our implementation.

> I'm fine with both

Me too.

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

[FFmpeg-devel] remove last use of deprecated avcodec_get_chroma_sub_sample

[Martin Vignali]

Hello,

patch in attach remove last use of this func
replace it by av_pix_fmt_get_chroma_sub_sample, and return check

remove several warning

based on previous patch by Nicolas Frattaroli


also remove the comment, where it's recommanded to use the deprecated func

pass fate test for me


Martin


0003-remove-use-of-deprecated-avcodec_get_chroma_sub_samp.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/8] x86inc: reduce difference to x264 upstream

[James Almer]

On 11/6/2017 5:28 PM, James Darnley wrote:
> On 2017-11-06 21:15, James Almer wrote:
>> On 11/6/2017 4:56 PM, James Darnley wrote:
>>> Line 733 is the align command to align the start of the function.  I
>>> can't see why it fails here but not on any other function in that file
>>> or any other file.
>>>
>>> After some cutting and pasting there is something about the mmxext
>>> function on line 159.  Cutting it out with the following diff, and
>>> building it will succeed.
>>>
 ...
>>>
>>> I honestly have no idea why that causes a problem for the following
>>> function.  I thought it might be the lower-case ret rather than the
>>> upper-case RET macro but changing it doesn't change the error.
>>
>> Try compiling with
>>
>> make libavcodec/x86/rv34dsp.dbg.asm DBG=1
>> make libavcodec/x86/rv34dsp.dbg.o DBG=1
>>
>> To bypass all the macro obfuscation and get errors pointing to the exact
>> problematic line in the preprocessed .dbg.asm file
> 
> WTF?!  Both those lines run without error.

The first one is supposed to. It's just pre processes the asm file and
creates a new one. The second command should fail, though, assuming
assembling the normal libavcodec/x86/rv34dsp.o object also fails.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/8] x86inc: reduce difference to x264 upstream

[James Darnley]

On 2017-11-06 21:15, James Almer wrote:
> On 11/6/2017 4:56 PM, James Darnley wrote:
>> Line 733 is the align command to align the start of the function.  I
>> can't see why it fails here but not on any other function in that file
>> or any other file.
>>
>> After some cutting and pasting there is something about the mmxext
>> function on line 159.  Cutting it out with the following diff, and
>> building it will succeed.
>>
>>> ...
>>
>> I honestly have no idea why that causes a problem for the following
>> function.  I thought it might be the lower-case ret rather than the
>> upper-case RET macro but changing it doesn't change the error.
> 
> Try compiling with
> 
> make libavcodec/x86/rv34dsp.dbg.asm DBG=1
> make libavcodec/x86/rv34dsp.dbg.o DBG=1
> 
> To bypass all the macro obfuscation and get errors pointing to the exact
> problematic line in the preprocessed .dbg.asm file

WTF?!  Both those lines run without error.

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

Re: [FFmpeg-devel] [PATCH] avfilter:vf_libvmaf: fix errors while running with psnr=1 and improve docs

[Ronald S. Bultje]

Hi,

On Mon, Nov 6, 2017 at 1:58 PM, Carl Eugen Hoyos  wrote:

> It is one thing to know that within FFmpeg, we do not modify
> a pointer target and therefore decide to cast, but isn't it
> another (bad) thing to assume this for an external library?


I'm guessing that what you mean is "libvmaf may not touch it right now, but
the API doesn't guarantee that such an implementation detail doesn't change
in the future", right?

Yes, you're right. Potential solutions are to make libvmaf const-correct or
to strdup in our implementation. I'm fine with both, although I'd prefer if
we didn't strdup every frame, i.e. move it to some global init/uninit
function.

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

Re: [FFmpeg-devel] [PATCH 6/8] x86inc: reduce difference to x264 upstream

[James Almer]

On 11/6/2017 4:56 PM, James Darnley wrote:
> On 2017-10-31 04:30, Michael Niedermayer wrote:
>> On Mon, Oct 30, 2017 at 02:08:33PM +0100, James Darnley wrote:
>>> These changes were commited to x264 in b568a256 "Experimental nasm
>>> support"
>>> ---
>>>  libavutil/x86/x86inc.asm | 16 ++--
>>>  1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> breaks build:
>>
>> libavcodec/x86/rv34dsp.asm:211: error: parser: instruction expected
>> libavcodec/x86/rv34dsp.asm:211: error: label or instruction expected at 
>> start of line
>> libavcodec/x86/rv34dsp.asm:213: error: parser: instruction expected
>> libavcodec/x86/rv34dsp.asm:213: error: label or instruction expected at 
>> start of line
>> make: *** [libavcodec/x86/rv34dsp.o] Error 1
>> make: *** Waiting for unfinished jobs
>>
>> NASM version 2.10.09 compiled on Dec 29 2013
> 
> This is very weird.  I have reproduced it on 2.13.01 on my server but I
> couldn't on my laptop.  After a `make distclean` I can.  I think that is
> the bug with nasm not listing includes as dependencies so I wasn't
> rebuilding those objects.
> 
>> libavcodec/x86/rv34dsp.asm:211: error: parser: instruction expected
>> libavcodec/x86/rv34dsp.asm:173: ... from macro `RV34_IDCT_DC_ADD' defined 
>> here
>> libavutil/x86/x86inc.asm:707: ... from macro `cglobal' defined here
>> libavutil/x86/x86inc.asm:733: ... from macro `cglobal_internal' defined here
>> libavcodec/x86/rv34dsp.asm:211: error: label or instruction expected at 
>> start of line
>> libavcodec/x86/rv34dsp.asm:173: ... from macro `RV34_IDCT_DC_ADD' defined 
>> here
>> libavutil/x86/x86inc.asm:707: ... from macro `cglobal' defined here
>> libavutil/x86/x86inc.asm:733: ... from macro `cglobal_internal' defined here
>> libavcodec/x86/rv34dsp.asm:213: error: parser: instruction expected
>> libavcodec/x86/rv34dsp.asm:173: ... from macro `RV34_IDCT_DC_ADD' defined 
>> here
>> libavutil/x86/x86inc.asm:707: ... from macro `cglobal' defined here
>> libavutil/x86/x86inc.asm:733: ... from macro `cglobal_internal' defined here
>> libavcodec/x86/rv34dsp.asm:213: error: label or instruction expected at 
>> start of line
>> libavcodec/x86/rv34dsp.asm:173: ... from macro `RV34_IDCT_DC_ADD' defined 
>> here
>> libavutil/x86/x86inc.asm:707: ... from macro `cglobal' defined here
>> libavutil/x86/x86inc.asm:733: ... from macro `cglobal_internal' defined here
> 
> Line 733 is the align command to align the start of the function.  I
> can't see why it fails here but not on any other function in that file
> or any other file.
> 
> After some cutting and pasting there is something about the mmxext
> function on line 159.  Cutting it out with the following diff, and
> building it will succeed.
> 
>> diff --git a/libavcodec/x86/rv34dsp.asm b/libavcodec/x86/rv34dsp.asm
>> index 692b4acfcd..3448f82e75 100644
>> --- a/libavcodec/x86/rv34dsp.asm
>> +++ b/libavcodec/x86/rv34dsp.asm
>> @@ -156,17 +156,6 @@ cglobal rv34_idct_dc_add, 3, 3
>>  packuswb %2, %2
>>  movd %1, %2
>>  %endmacro
>> -INIT_MMX mmxext
>> -cglobal rv34_idct_add, 3,3,0, d, s, b
>> -ROW_TRANSFORM   bq
>> -COL_TRANSFORM [dq], mm0, [pw_col_coeffs+ 0], [pw_col_coeffs+ 8]
>> -mova   mm0, [pw_col_coeffs+ 0]
>> -COL_TRANSFORM  [dq+sq], mm4, mm0, [pw_col_coeffs+ 8]
>> -mova   mm4, [pw_col_coeffs+ 8]
>> -lea dq, [dq + 2*sq]
>> -COL_TRANSFORM [dq], mm6, mm0, mm4
>> -COL_TRANSFORM  [dq+sq], mm7, mm0, mm4
>> -ret
>>
>>  ; ff_rv34_idct_dc_add_sse4(uint8_t *dst, int stride, int dc);
>>  %macro RV34_IDCT_DC_ADD 0
> 
> I honestly have no idea why that causes a problem for the following
> function.  I thought it might be the lower-case ret rather than the
> upper-case RET macro but changing it doesn't change the error.

Try compiling with

make libavcodec/x86/rv34dsp.dbg.asm DBG=1
make libavcodec/x86/rv34dsp.dbg.o DBG=1

To bypass all the macro obfuscation and get errors pointing to the exact
problematic line in the preprocessed .dbg.asm file
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/8] x86inc: reduce difference to x264 upstream

[James Darnley]

On 2017-10-31 04:30, Michael Niedermayer wrote:
> On Mon, Oct 30, 2017 at 02:08:33PM +0100, James Darnley wrote:
>> These changes were commited to x264 in b568a256 "Experimental nasm
>> support"
>> ---
>>  libavutil/x86/x86inc.asm | 16 ++--
>>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> breaks build:
> 
> libavcodec/x86/rv34dsp.asm:211: error: parser: instruction expected
> libavcodec/x86/rv34dsp.asm:211: error: label or instruction expected at start 
> of line
> libavcodec/x86/rv34dsp.asm:213: error: parser: instruction expected
> libavcodec/x86/rv34dsp.asm:213: error: label or instruction expected at start 
> of line
> make: *** [libavcodec/x86/rv34dsp.o] Error 1
> make: *** Waiting for unfinished jobs
> 
> NASM version 2.10.09 compiled on Dec 29 2013

This is very weird.  I have reproduced it on 2.13.01 on my server but I
couldn't on my laptop.  After a `make distclean` I can.  I think that is
the bug with nasm not listing includes as dependencies so I wasn't
rebuilding those objects.

> libavcodec/x86/rv34dsp.asm:211: error: parser: instruction expected
> libavcodec/x86/rv34dsp.asm:173: ... from macro `RV34_IDCT_DC_ADD' defined here
> libavutil/x86/x86inc.asm:707: ... from macro `cglobal' defined here
> libavutil/x86/x86inc.asm:733: ... from macro `cglobal_internal' defined here
> libavcodec/x86/rv34dsp.asm:211: error: label or instruction expected at start 
> of line
> libavcodec/x86/rv34dsp.asm:173: ... from macro `RV34_IDCT_DC_ADD' defined here
> libavutil/x86/x86inc.asm:707: ... from macro `cglobal' defined here
> libavutil/x86/x86inc.asm:733: ... from macro `cglobal_internal' defined here
> libavcodec/x86/rv34dsp.asm:213: error: parser: instruction expected
> libavcodec/x86/rv34dsp.asm:173: ... from macro `RV34_IDCT_DC_ADD' defined here
> libavutil/x86/x86inc.asm:707: ... from macro `cglobal' defined here
> libavutil/x86/x86inc.asm:733: ... from macro `cglobal_internal' defined here
> libavcodec/x86/rv34dsp.asm:213: error: label or instruction expected at start 
> of line
> libavcodec/x86/rv34dsp.asm:173: ... from macro `RV34_IDCT_DC_ADD' defined here
> libavutil/x86/x86inc.asm:707: ... from macro `cglobal' defined here
> libavutil/x86/x86inc.asm:733: ... from macro `cglobal_internal' defined here

Line 733 is the align command to align the start of the function.  I
can't see why it fails here but not on any other function in that file
or any other file.

After some cutting and pasting there is something about the mmxext
function on line 159.  Cutting it out with the following diff, and
building it will succeed.

> diff --git a/libavcodec/x86/rv34dsp.asm b/libavcodec/x86/rv34dsp.asm
> index 692b4acfcd..3448f82e75 100644
> --- a/libavcodec/x86/rv34dsp.asm
> +++ b/libavcodec/x86/rv34dsp.asm
> @@ -156,17 +156,6 @@ cglobal rv34_idct_dc_add, 3, 3
>  packuswb %2, %2
>  movd %1, %2
>  %endmacro
> -INIT_MMX mmxext
> -cglobal rv34_idct_add, 3,3,0, d, s, b
> -ROW_TRANSFORM   bq
> -COL_TRANSFORM [dq], mm0, [pw_col_coeffs+ 0], [pw_col_coeffs+ 8]
> -mova   mm0, [pw_col_coeffs+ 0]
> -COL_TRANSFORM  [dq+sq], mm4, mm0, [pw_col_coeffs+ 8]
> -mova   mm4, [pw_col_coeffs+ 8]
> -lea dq, [dq + 2*sq]
> -COL_TRANSFORM [dq], mm6, mm0, mm4
> -COL_TRANSFORM  [dq+sq], mm7, mm0, mm4
> -ret
> 
>  ; ff_rv34_idct_dc_add_sse4(uint8_t *dst, int stride, int dc);
>  %macro RV34_IDCT_DC_ADD 0

I honestly have no idea why that causes a problem for the following
function.  I thought it might be the lower-case ret rather than the
upper-case RET macro but changing it doesn't change the error.

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

Re: [FFmpeg-devel] [PATCH] avformat/rtpdec_asf: free the buffer pointed by the AVIOContext

[James Almer]

On 11/6/2017 3:54 PM, Carl Eugen Hoyos wrote:
> 2017-11-06 17:29 GMT+01:00 James Almer :
>> Don't free the buffer allocated in ff_wms_parse_sdp_a_line() after
>> calling avformat_open_input(), as it may free it and replace it with
>> another one.
>>
>> Should fix ticket #6808
> 
> I can confirm that the patch fixes the issue, consider using av_freep.

No point, the AVIOContext is local and the av_free() call happens right
before returning from the function.

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

Re: [FFmpeg-devel] [PATCH] avfilter:vf_libvmaf: fix errors while running with psnr=1 and improve docs

[Carl Eugen Hoyos]

2017-11-06 15:09 GMT+01:00 Ronald S. Bultje :
> Hi,
>
> On Mon, Nov 6, 2017 at 8:21 AM, Carl Eugen Hoyos  wrote:
>
>> 2017-11-06 13:52 GMT+01:00 Ronald S. Bultje :

>> > Split, and pushed.
>>
>> +format = (char *) s->desc->name;
>>
>> Isn't this cast a bad idea?
>
> It's an API thing. We can either strdup(), or use a cast, or have a
> compiler warning.

Yes.

> libvmaf does not modify the argument even if it doesn't
> use const here.

I hoped (and assumed) so.

What I meant was:
It is one thing to know that within FFmpeg, we do not modify
a pointer target and therefore decide to cast, but isn't it
another (bad) thing to assume this for an external library?

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

Re: [FFmpeg-devel] [PATCH] avformat/rtpdec_asf: free the buffer pointed by the AVIOContext

[Carl Eugen Hoyos]

2017-11-06 17:29 GMT+01:00 James Almer :
> Don't free the buffer allocated in ff_wms_parse_sdp_a_line() after
> calling avformat_open_input(), as it may free it and replace it with
> another one.
>
> Should fix ticket #6808

I can confirm that the patch fixes the issue, consider using av_freep.

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

Re: [FFmpeg-devel] [PATCH v3] lavu: add an AV_FRAME_DATA_GAMMA side data type

[Nicolas George]

Le sextidi 16 brumaire, an CCXXVI, Rostislav Pehlivanov a écrit :
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  doc/APIchanges  | 3 +++
>  libavutil/frame.h   | 6 ++
>  libavutil/version.h | 2 +-
>  3 files changed, 10 insertions(+), 1 deletion(-)

Sorry if it has come up before, but why not just add

AVRational gamma;

with 0/0 meaning unspecified? It seems like a relevant information, at
least as much as AVColor*. And overall much simpler.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH v3] pngdec: expose gAMA and cHRM chunks as side data

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/pngdec.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 0d6612ccca..9ce57b7e70 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -25,6 +25,7 @@
 #include "libavutil/bprint.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/stereo3d.h"
+#include "libavutil/mastering_display_metadata.h"
 
 #include "avcodec.h"
 #include "bytestream.h"
@@ -1287,6 +1288,37 @@ static int decode_frame_common(AVCodecContext *avctx, 
PNGDecContext *s,
 goto fail;
 break;
 }
+case MKTAG('c', 'H', 'R', 'M'): {
+AVMasteringDisplayMetadata *mdm = 
av_mastering_display_metadata_create_side_data(p);
+if (!mdm) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
+mdm->white_point[0] = av_make_q(bytestream2_get_be32(>gb), 
10);
+mdm->white_point[1] = av_make_q(bytestream2_get_be32(>gb), 
10);
+
+/* RGB Primaries */
+for (i = 0; i < 3; i++) {
+mdm->display_primaries[i][0] = 
av_make_q(bytestream2_get_be32(>gb), 10);
+mdm->display_primaries[i][1] = 
av_make_q(bytestream2_get_be32(>gb), 10);
+}
+
+mdm->has_primaries = 1;
+bytestream2_skip(>gb, 4); /* crc */
+break;
+}
+case MKTAG('g', 'A', 'M', 'A'): {
+AVFrameSideData *sd = av_frame_new_side_data(p, 
AV_FRAME_DATA_GAMMA, sizeof(AVRational));
+if (!sd) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
+*((AVRational *)sd->data) = 
av_make_q(bytestream2_get_be32(>gb), 10);
+bytestream2_skip(>gb, 4); /* crc */
+break;
+}
 case MKTAG('I', 'E', 'N', 'D'):
 if (!(s->pic_state & PNG_ALLIMAGE))
 av_log(avctx, AV_LOG_ERROR, "IEND without all image\n");
-- 
2.15.0.403.gc27cc4dac6

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

[FFmpeg-devel] Support for h264/SVC over RTP and SVC base layer decoding in h264

[Breeden, Joshua]

> can you add a fate test for this ?

I took a look around the existing tests to see how the existing extradata 
parsing is being tested, but didn't find anything. Is there something existing 
that I'm not seeing? If not, could you provide a little more guidance on how 
you'd like this tested? Since the modification uses an existing function 
without modification, I'd prefer to avoid reinventing the wheel if possible.

> (i assume a test for rtp would be hard but if not, that would be
 welcome too)

Yes, without RTP SVC packetization, which this patch does not provide, this 
would be quite difficult to accomplish.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3] lavu: add an AV_FRAME_DATA_GAMMA side data type

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 doc/APIchanges  | 3 +++
 libavutil/frame.h   | 6 ++
 libavutil/version.h | 2 +-
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 1490d67f27..75051deaf8 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2017-11-06 - xxx - lavu 56.01.100 - frame.h
+  Add the AV_FRAME_DATA_GAMMA side data type.
+
  8< - FFmpeg 3.4 was cut here  8< -
 
 2017-09-28 - b6cf66ae1c - lavc 57.106.104 - avcodec.h
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 0c6aab1c02..64dcf3a397 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -141,6 +141,12 @@ enum AVFrameSideDataType {
  * metadata key entry "name".
  */
 AV_FRAME_DATA_ICC_PROFILE,
+
+/**
+ * The data contains an AVRational which describes the exponent needed to
+ * compensate for nonlinearity in the input signal.
+ */
+AV_FRAME_DATA_GAMMA,
 };
 
 enum AVActiveFormatDescription {
diff --git a/libavutil/version.h b/libavutil/version.h
index 1bc4b2a6cb..cf8ec498e4 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -80,7 +80,7 @@
 
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR   0
+#define LIBAVUTIL_VERSION_MINOR   1
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.15.0.403.gc27cc4dac6

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

[FFmpeg-devel] [PATCH] avformat/rtpdec_asf: free the buffer pointed by the AVIOContext

[James Almer]

Don't free the buffer allocated in ff_wms_parse_sdp_a_line() after
calling avformat_open_input(), as it may free it and replace it with
another one.

Should fix ticket #6808

Signed-off-by: James Almer 
---
Untested.

 libavformat/rtpdec_asf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/rtpdec_asf.c b/libavformat/rtpdec_asf.c
index 2c09fda10b..09f214a71c 100644
--- a/libavformat/rtpdec_asf.c
+++ b/libavformat/rtpdec_asf.c
@@ -139,12 +139,12 @@ int ff_wms_parse_sdp_a_line(AVFormatContext *s, const 
char *p)
 ret = avformat_open_input(>asf_ctx, "", iformat, );
 av_dict_free();
 if (ret < 0) {
-av_free(buf);
+av_free(pb.buffer);
 return ret;
 }
 av_dict_copy(>metadata, rt->asf_ctx->metadata, 0);
 rt->asf_pb_pos = avio_tell();
-av_free(buf);
+av_free(pb.buffer);
 rt->asf_ctx->pb = NULL;
 }
 return ret;
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH 1/3] sbc: implement SBC codec (low-complexity subband codec)

[James Almer]

On 11/5/2017 8:35 PM, Aurelien Jacobs wrote:
> This was originally based on libsbc, and was fully integrated into ffmpeg.
> ---
>  doc/general.texi |   2 +
>  libavcodec/Makefile  |   4 +
>  libavcodec/allcodecs.c   |   2 +
>  libavcodec/arm/Makefile  |   3 +
>  libavcodec/arm/sbcdsp_armv6.S| 245 ++
>  libavcodec/arm/sbcdsp_init_arm.c | 105 ++
>  libavcodec/arm/sbcdsp_neon.S | 714 
> +++
>  libavcodec/avcodec.h |   2 +
>  libavcodec/codec_desc.c  |  12 +
>  libavcodec/sbc.c | 316 +
>  libavcodec/sbc.h | 121 +++
>  libavcodec/sbcdec.c  | 469 +
>  libavcodec/sbcdec_data.c | 127 +++
>  libavcodec/sbcdec_data.h |  44 +++
>  libavcodec/sbcdsp.c  | 569 +++
>  libavcodec/sbcdsp.h  |  86 +
>  libavcodec/sbcdsp_data.c | 335 ++
>  libavcodec/sbcdsp_data.h |  57 
>  libavcodec/sbcenc.c  | 461 +
>  libavcodec/x86/Makefile  |   2 +
>  libavcodec/x86/sbcdsp.asm| 290 
>  libavcodec/x86/sbcdsp_init.c |  51 +++
>  22 files changed, 4017 insertions(+)
>  create mode 100644 libavcodec/arm/sbcdsp_armv6.S
>  create mode 100644 libavcodec/arm/sbcdsp_init_arm.c
>  create mode 100644 libavcodec/arm/sbcdsp_neon.S
>  create mode 100644 libavcodec/sbc.c
>  create mode 100644 libavcodec/sbc.h
>  create mode 100644 libavcodec/sbcdec.c
>  create mode 100644 libavcodec/sbcdec_data.c
>  create mode 100644 libavcodec/sbcdec_data.h
>  create mode 100644 libavcodec/sbcdsp.c
>  create mode 100644 libavcodec/sbcdsp.h
>  create mode 100644 libavcodec/sbcdsp_data.c
>  create mode 100644 libavcodec/sbcdsp_data.h
>  create mode 100644 libavcodec/sbcenc.c
>  create mode 100644 libavcodec/x86/sbcdsp.asm
>  create mode 100644 libavcodec/x86/sbcdsp_init.c

This needs to be split into at least four patches.
One to add the decoder (plus codec ID, descriptor and such things), one
to add the encoder (and the dsp framework), one to add the x86 assembly
optimizations for the encoder, and one for the arm optimizations.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter:vf_libvmaf: fix errors while running with psnr=1 and improve docs

[Ashish Pratap Singh]

Hi,

On Nov 6, 2017 18:22, "Ronald S. Bultje"  wrote:

Hi,

On Thu, Oct 12, 2017 at 4:43 PM, Carl Eugen Hoyos 
wrote:

> 2017-10-11 15:53 GMT+02:00 Ashish Pratap Singh :
>
> > Hi, this patch fixes the seg fault which ocuured while running libvmaf
> filter
> > with option psnr=1. This also improves libvmaf doc a bit.
>
> Please split in two patches.


Split, and pushed.

Ronald

Thanks.

___
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:vf_libvmaf: fix errors while running with psnr=1 and improve docs

[Ronald S. Bultje]

Hi,

On Mon, Nov 6, 2017 at 8:21 AM, Carl Eugen Hoyos  wrote:

> 2017-11-06 13:52 GMT+01:00 Ronald S. Bultje :
> > Hi,
> >
> > On Thu, Oct 12, 2017 at 4:43 PM, Carl Eugen Hoyos 
> > wrote:
> >
> >> 2017-10-11 15:53 GMT+02:00 Ashish Pratap Singh :
> >>
> >> > Hi, this patch fixes the seg fault which ocuured while running libvmaf
> >> > filter with option psnr=1. This also improves libvmaf doc a bit.
> >>
> >> Please split in two patches.
> >
> > Split, and pushed.
>
> +format = (char *) s->desc->name;
>
> Isn't this cast a bad idea?


It's an API thing. We can either strdup(), or use a cast, or have a
compiler warning. libvmaf does not modify the argument even if it doesn't
use const here.

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

Re: [FFmpeg-devel] [PATCH 1/3] sbc: implement SBC codec (low-complexity subband codec)

[James Almer]

On 11/6/2017 9:53 AM, Carl Eugen Hoyos wrote:
> 2017-11-06 5:40 GMT+01:00 Rostislav Pehlivanov :
> 
>>> +{
>>> +.id= AV_CODEC_ID_SBC,
>>> +.type  = AVMEDIA_TYPE_AUDIO,
>>> +.name  = "sbc",
>>> +.long_name = NULL_IF_CONFIG_SMALL("SBC (low-complexity subband
>>> codec)"),
>>> +},
>>> +{
>>> +.id= AV_CODEC_ID_MSBC,
>>> +.type  = AVMEDIA_TYPE_AUDIO,
>>> +.name  = "msbc",
>>> +.long_name = NULL_IF_CONFIG_SMALL("mSBC (wideband speech mono
>>> SBC)"),
>>> +},
>>>
>>
>> Is there a bitstream difference between the two? I don't think so, so you
>> should instead define FF_PROFILE_SBC_WB and use a single codec ID.
> 
> Would that have an advantage?
> 
> One day, somebody will it into isom and define two different codec_tags...

DTS audio has a lot of different codec tags in isom, including DTS-E
which is a completely different bitstream altogether, and we have a
single codec ID for them all.

The de/muxer can handle it just fine, so it's not an issue.

> 
> Carl Eugen
> ___
> 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] avutil/frame: Add avcodec_private_ref to AVFrame

[James Almer]

On 11/6/2017 9:19 AM, Timo Rothenpieler wrote:
> Am 05.11.2017 um 14:35 schrieb James Almer:
>> On 11/5/2017 9:34 AM, Michael Niedermayer wrote:
>>> This gives libavcodec a field that it can freely and safely use.
>>> Avoiding the need of wraping of a users opaque_ref field and its issues.
>>
>> Could this perhaps be in an opaque internal struct instead, much like
>> AVCodecInternal and whatnot? As wm4 said in the relevant discussion,
>> this approach is nonoptimal and *will* snowball into a mess of fields if
>> other libav* libraries start requiring their own buffers in a frame.
>> An internal field of an opaque struct being in a public header is much
>> cleaner and easier to maintain than adding such specific fields that may
>> at some point in the future need to be removed.
> 
> The problem here is that avcodec, due to nested decoders and the like,
> might potentially wrap this field multiple times internally, so it
> basically has to be something avcodec specific.

And an opaque internal struct would require avpriv_ symbols to be
accessed from outside libavutil, so it's an ugly solution nonetheless. I
already told Michael to discard the suggestion.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter:vf_libvmaf: fix errors while running with psnr=1 and improve docs

[Carl Eugen Hoyos]

2017-11-06 13:52 GMT+01:00 Ronald S. Bultje :
> Hi,
>
> On Thu, Oct 12, 2017 at 4:43 PM, Carl Eugen Hoyos 
> wrote:
>
>> 2017-10-11 15:53 GMT+02:00 Ashish Pratap Singh :
>>
>> > Hi, this patch fixes the seg fault which ocuured while running libvmaf
>> > filter with option psnr=1. This also improves libvmaf doc a bit.
>>
>> Please split in two patches.
>
> Split, and pushed.

+format = (char *) s->desc->name;

Isn't this cast a bad idea?

Thank you for reviving this, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi 4 tap hv mc msa functions

[Manojkumar Bhosale]

LGTM

From: ffmpeg-devel [ffmpeg-devel-boun...@ffmpeg.org] on behalf of 
kaustubh.ra...@imgtec.com [kaustubh.ra...@imgtec.com]
Sent: Monday, November 06, 2017 11:15 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi 4 tap hv mc   
msa functions

From: Kaustubh Raste 

Use global mask buffer for appropriate mask load.
Use immediate unsigned saturation for clip to max saving one vector register.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_bi_msa.c | 1140 +++---
 1 file changed, 685 insertions(+), 455 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_bi_msa.c b/libavcodec/mips/hevc_mc_bi_msa.c
index e9c9184..b17 100644
--- a/libavcodec/mips/hevc_mc_bi_msa.c
+++ b/libavcodec/mips/hevc_mc_bi_msa.c
@@ -3772,20 +3772,20 @@ static void hevc_hv_bi_4t_4x2_msa(uint8_t *src0_ptr,
   uint8_t *dst,
   int32_t dst_stride,
   const int8_t *filter_x,
-  const int8_t *filter_y,
-  int32_t height)
+  const int8_t *filter_y)
 {
-v8i16 in0, in1;
+uint64_t tp0, tp1;
+v16u8 out;
+v8i16 in0 = { 0 };
 v16i8 src0, src1, src2, src3, src4;
 v8i16 filt0, filt1;
-v4i32 filt_h0, filt_h1;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8 };
+v8i16 filt_h0, filt_h1;
+v16i8 mask0 = LD_SB(ff_hevc_mask_arr + 16);
 v16i8 mask1;
 v8i16 filter_vec, const_vec;
 v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v8i16 dst0, dst1, dst2, dst3, dst4;
-v4i32 dst0_r, dst1_r;
-v8i16 dst10_r, dst32_r, dst21_r, dst43_r;
+v8i16 dst20, dst31, dst42, dst10, dst32, dst21, dst43, tmp;
+v4i32 dst0, dst1;

 src0_ptr -= (src_stride + 1);

@@ -3793,56 +3793,43 @@ static void hevc_hv_bi_4t_4x2_msa(uint8_t *src0_ptr,
 SPLATI_H2_SH(filter_vec, 0, 1, filt0, filt1);

 filter_vec = LD_SH(filter_y);
-vec0 = __msa_clti_s_b((v16i8) filter_vec, 0);
-filter_vec = (v8i16) __msa_ilvr_b(vec0, (v16i8) filter_vec);
+UNPCK_R_SB_SH(filter_vec, filter_vec);

-SPLATI_W2_SW(filter_vec, 0, filt_h0, filt_h1);
+SPLATI_W2_SH(filter_vec, 0, filt_h0, filt_h1);

 mask1 = mask0 + 2;

 const_vec = __msa_ldi_h(128);
 const_vec <<= 6;

-LD_SB3(src0_ptr, src_stride, src0, src1, src2);
-src0_ptr += (3 * src_stride);
-XORI_B3_128_SB(src0, src1, src2);
-
-VSHF_B2_SB(src0, src0, src0, src0, mask0, mask1, vec0, vec1);
-VSHF_B2_SB(src1, src1, src1, src1, mask0, mask1, vec2, vec3);
-VSHF_B2_SB(src2, src2, src2, src2, mask0, mask1, vec4, vec5);
-dst0 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst0, dst0);
-dst1 = const_vec;
-DPADD_SB2_SH(vec2, vec3, filt0, filt1, dst1, dst1);
-dst2 = const_vec;
-DPADD_SB2_SH(vec4, vec5, filt0, filt1, dst2, dst2);
-ILVR_H2_SH(dst1, dst0, dst2, dst1, dst10_r, dst21_r);
-
-LD_SB2(src0_ptr, src_stride, src3, src4);
-LD_SH2(src1_ptr, src2_stride, in0, in1);
-in0 = (v8i16) __msa_ilvr_d((v2i64) in1, (v2i64) in0);
-XORI_B2_128_SB(src3, src4);
-/* row 3 */
-VSHF_B2_SB(src3, src3, src3, src3, mask0, mask1, vec0, vec1);
-dst3 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst3, dst3);
-dst32_r = __msa_ilvr_h(dst3, dst2);
-dst0_r = HEVC_FILT_4TAP(dst10_r, dst32_r, filt_h0, filt_h1);
-dst0_r >>= 6;
-/* row 4 */
-VSHF_B2_SB(src4, src4, src4, src4, mask0, mask1, vec0, vec1);
-dst4 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst4, dst4);
-dst43_r = __msa_ilvr_h(dst4, dst3);
-dst1_r = HEVC_FILT_4TAP(dst21_r, dst43_r, filt_h0, filt_h1);
-dst1_r >>= 6;
-dst0_r = (v4i32) __msa_pckev_h((v8i16) dst1_r, (v8i16) dst0_r);
-dst0_r = (v4i32) __msa_adds_s_h((v8i16) dst0_r, in0);
-dst0_r = (v4i32) __msa_srari_h((v8i16) dst0_r, 7);
-dst0_r = (v4i32) CLIP_SH_0_255(dst0_r);
-
-dst0_r = (v4i32) __msa_pckev_b((v16i8) dst0_r, (v16i8) dst0_r);
-ST4x2_UB(dst0_r, dst, dst_stride);
+LD_SB5(src0_ptr, src_stride, src0, src1, src2, src3, src4);
+XORI_B5_128_SB(src0, src1, src2, src3, src4);
+
+LD2(src1_ptr, src2_stride, tp0, tp1);
+INSERT_D2_SH(tp0, tp1, in0);
+in0 = __msa_adds_s_h(in0, const_vec);
+
+VSHF_B2_SB(src0, src2, src0, src2, mask0, mask1, vec0, vec1);
+VSHF_B2_SB(src1, src3, src1, src3, mask0, mask1, vec2, vec3);
+VSHF_B2_SB(src2, src4, src2, src4, mask0, mask1, vec4, vec5);
+
+dst20 = HEVC_FILT_4TAP_SH(vec0, vec1, filt0, filt1);
+dst31 = HEVC_FILT_4TAP_SH(vec2, vec3, filt0, filt1);
+dst42 = HEVC_FILT_4TAP_SH(vec4, vec5, filt0, filt1);
+
+ILVRL_H2_SH(dst31, dst20, dst10, dst32);
+ILVRL_H2_SH(dst42, dst31, dst21, dst43);
+
+dst0 = HEVC_FILT_4TAP(dst10, dst32, 

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc avg mc 10, 30, 01 and 03 msa functions

[Manojkumar Bhosale]

LGTM

From: ffmpeg-devel [ffmpeg-devel-boun...@ffmpeg.org] on behalf of 
kaustubh.ra...@imgtec.com [kaustubh.ra...@imgtec.com]
Sent: Monday, November 06, 2017 10:49 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc avg mc 10, 30,
01 and 03 msa functions

From: Kaustubh Raste 

Align the mask buffer to 64 bytes.
Load the specific destination bytes instead of MSA load and pack.
Remove unused macros and functions.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/h264qpel_msa.c | 1269 
 1 file changed, 751 insertions(+), 518 deletions(-)

diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec/mips/h264qpel_msa.c
index dd11f00..9c779bd 100644
--- a/libavcodec/mips/h264qpel_msa.c
+++ b/libavcodec/mips/h264qpel_msa.c
@@ -21,7 +21,7 @@
 #include "libavutil/mips/generic_macros_msa.h"
 #include "h264dsp_mips.h"

-static const uint8_t luma_mask_arr[16 * 8] = {
+static const uint8_t luma_mask_arr[16 * 6] __attribute__((aligned(0x40))) = {
 /* 8 width cases */
 0, 5, 1, 6, 2, 7, 3, 8, 4, 9, 5, 10, 6, 11, 7, 12,
 1, 4, 2, 5, 3, 6, 4, 7, 5, 8, 6, 9, 7, 10, 8, 11,
@@ -31,9 +31,6 @@ static const uint8_t luma_mask_arr[16 * 8] = {
 0, 5, 1, 6, 2, 7, 3, 8, 16, 21, 17, 22, 18, 23, 19, 24,
 1, 4, 2, 5, 3, 6, 4, 7, 17, 20, 18, 21, 19, 22, 20, 23,
 2, 3, 3, 4, 4, 5, 5, 6, 18, 19, 19, 20, 20, 21, 21, 22,
-
-2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 24, 25,
-3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 24, 25, 26
 };

 #define AVC_CALC_DPADD_B_6PIX_2COEFF_SH(vec0, vec1, vec2, vec3, vec4, vec5,  \
@@ -356,414 +353,6 @@ static void avc_luma_hv_qrt_16x16_msa(const uint8_t 
*src_x,
 }
 }

-static void avc_luma_hz_qrt_and_aver_dst_4x4_msa(const uint8_t *src,
- int32_t src_stride,
- uint8_t *dst,
- int32_t dst_stride,
- uint8_t hor_offset)
-{
-uint8_t slide;
-v16i8 src0, src1, src2, src3;
-v16u8 dst0, dst1, dst2, dst3;
-v16i8 mask0, mask1, mask2;
-v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v8i16 out0, out1;
-v16i8 minus5b = __msa_ldi_b(-5);
-v16i8 plus20b = __msa_ldi_b(20);
-v16u8 res0, res1;
-
-LD_SB3(_mask_arr[48], 16, mask0, mask1, mask2);
-
-if (hor_offset) {
-slide = 3;
-} else {
-slide = 2;
-}
-
-LD_SB4(src, src_stride, src0, src1, src2, src3);
-LD_UB4(dst, dst_stride, dst0, dst1, dst2, dst3);
-
-XORI_B4_128_SB(src0, src1, src2, src3);
-VSHF_B2_SB(src0, src1, src2, src3, mask0, mask0, vec0, vec1);
-HADD_SB2_SH(vec0, vec1, out0, out1);
-VSHF_B2_SB(src0, src1, src2, src3, mask1, mask1, vec2, vec3);
-DPADD_SB2_SH(vec2, vec3, minus5b, minus5b, out0, out1);
-VSHF_B2_SB(src0, src1, src2, src3, mask2, mask2, vec4, vec5);
-DPADD_SB2_SH(vec4, vec5, plus20b, plus20b, out0, out1);
-SRARI_H2_SH(out0, out1, 5);
-SAT_SH2_SH(out0, out1, 7);
-
-PCKEV_B2_UB(out0, out0, out1, out1, res0, res1);
-
-src0 = __msa_sld_b(src0, src0, slide);
-src1 = __msa_sld_b(src1, src1, slide);
-src2 = __msa_sld_b(src2, src2, slide);
-src3 = __msa_sld_b(src3, src3, slide);
-src0 = (v16i8) __msa_insve_w((v4i32) src0, 1, (v4i32) src1);
-src1 = (v16i8) __msa_insve_w((v4i32) src2, 1, (v4i32) src3);
-res0 = (v16u8) __msa_aver_s_b((v16i8) res0, src0);
-res1 = (v16u8) __msa_aver_s_b((v16i8) res1, src1);
-
-XORI_B2_128_UB(res0, res1);
-
-dst0 = (v16u8) __msa_insve_w((v4i32) dst0, 1, (v4i32) dst1);
-dst1 = (v16u8) __msa_insve_w((v4i32) dst2, 1, (v4i32) dst3);
-
-AVER_UB2_UB(res0, dst0, res1, dst1, dst0, dst1);
-
-ST4x4_UB(dst0, dst1, 0, 1, 0, 1, dst, dst_stride);
-}
-
-static void avc_luma_hz_qrt_and_aver_dst_8x8_msa(const uint8_t *src,
- int32_t src_stride,
- uint8_t *dst,
- int32_t dst_stride,
- uint8_t hor_offset)
-{
-uint8_t slide;
-uint32_t loop_cnt;
-v16i8 src0, src1, src2, src3;
-v16i8 mask0, mask1, mask2;
-v16u8 dst0, dst1, dst2, dst3;
-v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v16i8 vec6, vec7, vec8, vec9, vec10, vec11;
-v8i16 out0, out1, out2, out3;
-v16i8 minus5b = __msa_ldi_b(-5);
-v16i8 plus20b = __msa_ldi_b(20);
-v16i8 res0, res1, res2, res3;
-
-LD_SB3(_mask_arr[0], 16, mask0, mask1, mask2);
-
-if (hor_offset) {
-slide = 3;
-} else {
-slide = 2;
-}
-
-for (loop_cnt = 2; loop_cnt--;) {
-LD_SB4(src, src_stride, src0, src1, src2, src3);
-src += (4 * src_stride);
-
-LD_UB4(dst, 

[FFmpeg-devel] [PATCH]configure: libvmaf is not GPLv2-compatible

[Carl Eugen Hoyos]

Hi!

I believe the following patch is necessary to fix the libvmaf license
dependencies.

Please comment, Carl Eugen
From 4f71e84f7b89031a6a808e4291d412e5371f677d Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 6 Nov 2017 14:15:31 +0100
Subject: [PATCH] configure: libvmaf is not GPLv2-compatible.

---
 configure |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 1b0f064..2d5a640 100755
--- a/configure
+++ b/configure
@@ -1569,6 +1569,7 @@ EXTERNAL_LIBRARY_VERSION3_LIST="
 gmp
 libopencore_amrnb
 libopencore_amrwb
+libvmaf
 libvo_amrwbenc
 rkmpp
 "
@@ -1625,7 +1626,6 @@ EXTERNAL_LIBRARY_LIST="
 libtheora
 libtwolame
 libv4l2
-libvmaf
 libvorbis
 libvpx
 libwavpack
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]lavc/pcm-dvd: Do not use an incompatible pointer on big-endian.

[Carl Eugen Hoyos]

2017-11-06 11:53 GMT+01:00 Hendrik Leppkes :
> On Wed, Nov 1, 2017 at 6:33 PM, Carl Eugen Hoyos  wrote:
>> 2017-11-01 18:18 GMT+01:00 Hendrik Leppkes :
>>> On Wed, Nov 1, 2017 at 5:13 PM, Carl Eugen Hoyos  wrote:
 Hi!

 Attached patch silences a gcc warning, tested with Fever.vob


 @@ -163,10 +162,12 @@ static void *pcm_dvd_decode_samples(AVCodecContext 
 *avctx, const uint8_t *src,
 switch (avctx->bits_per_coded_sample) {
 case 16: {
 #if HAVE_BIGENDIAN
 +int8_t *dst16 = dst;
 bytestream2_get_buffer(, dst16, blocks * s->block_size);
 -dst16 += blocks * s->block_size / 2;
 +dst16 += blocks * s->block_size;
 #else
 int samples = blocks * avctx->channels;
 +int16_t *dst16 = dst;
 do {
 *dst16++ = bytestream2_get_be16u();
 } while (--samples);
>>>
>>> This results in quite misleading code. dst16 is named like that
>>> because its a 16-bit pointer, using the same pointer with different
>>> types based on this ifdef seems error-prone in the future.
>>
>> Agree, new patch attached.
>
> I think you attached the wrong patch, this is an old version of the
> pcm-bluray patch.

New try attached.

Thank you, Carl Eugen
From 244eb73d55e4f1eb85d1f8bcf8f12542d0e57537 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 1 Nov 2017 18:31:29 +0100
Subject: [PATCH] lavc/pcm-dvd: Do not use an incompatible pointer on
 big-endian.

Fixes the following gcc warning:
libavcodec/pcm-dvd.c:166:37: warning: passing argument 2 of 'bytestream2_get_buffer' from incompatible pointer type
---
 libavcodec/pcm-dvd.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavcodec/pcm-dvd.c b/libavcodec/pcm-dvd.c
index 0a751a8..329b555 100644
--- a/libavcodec/pcm-dvd.c
+++ b/libavcodec/pcm-dvd.c
@@ -153,7 +153,6 @@ static void *pcm_dvd_decode_samples(AVCodecContext *avctx, const uint8_t *src,
 void *dst, int blocks)
 {
 PCMDVDContext *s = avctx->priv_data;
-int16_t *dst16   = dst;
 int32_t *dst32   = dst;
 GetByteContext gb;
 int i;
@@ -163,15 +162,17 @@ static void *pcm_dvd_decode_samples(AVCodecContext *avctx, const uint8_t *src,
 switch (avctx->bits_per_coded_sample) {
 case 16: {
 #if HAVE_BIGENDIAN
-bytestream2_get_buffer(, dst16, blocks * s->block_size);
-dst16 += blocks * s->block_size / 2;
+int8_t *dst8 = dst;
+bytestream2_get_buffer(, dst8, blocks * s->block_size);
+return dst8 + blocks * s->block_size;
 #else
 int samples = blocks * avctx->channels;
+int16_t *dst16 = dst;
 do {
 *dst16++ = bytestream2_get_be16u();
 } while (--samples);
-#endif
 return dst16;
+#endif
 }
 case 20:
 if (avctx->channels == 1) {
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 1/3] sbc: implement SBC codec (low-complexity subband codec)

[Carl Eugen Hoyos]

2017-11-06 5:40 GMT+01:00 Rostislav Pehlivanov :

>> +{
>> +.id= AV_CODEC_ID_SBC,
>> +.type  = AVMEDIA_TYPE_AUDIO,
>> +.name  = "sbc",
>> +.long_name = NULL_IF_CONFIG_SMALL("SBC (low-complexity subband
>> codec)"),
>> +},
>> +{
>> +.id= AV_CODEC_ID_MSBC,
>> +.type  = AVMEDIA_TYPE_AUDIO,
>> +.name  = "msbc",
>> +.long_name = NULL_IF_CONFIG_SMALL("mSBC (wideband speech mono
>> SBC)"),
>> +},
>>
>
> Is there a bitstream difference between the two? I don't think so, so you
> should instead define FF_PROFILE_SBC_WB and use a single codec ID.

Would that have an advantage?

One day, somebody will it into isom and define two different codec_tags...

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

Re: [FFmpeg-devel] [PATCH] avfilter:vf_libvmaf: fix errors while running with psnr=1 and improve docs

[Ronald S. Bultje]

Hi,

On Thu, Oct 12, 2017 at 4:43 PM, Carl Eugen Hoyos 
wrote:

> 2017-10-11 15:53 GMT+02:00 Ashish Pratap Singh :
>
> > Hi, this patch fixes the seg fault which ocuured while running libvmaf
> filter
> > with option psnr=1. This also improves libvmaf doc a bit.
>
> Please split in two patches.


Split, and pushed.

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-11-06 11:50 GMT+01:00 Paul B Mahol :
> On 11/5/17, Carl Eugen Hoyos  wrote:
>> 2017-10-09 0:24 GMT+02:00 Carl Eugen Hoyos :
>>> 2017-10-07 16:51 GMT+02:00 Carl Eugen Hoyos :
 2017-10-01 18:23 GMT+02:00 Carl Eugen Hoyos :
> 2017-09-27 18:08 GMT+02:00 Carl Eugen Hoyos :
>
>> The existing amr demuxer does not allow reading streams,
>> it requires the 3GPP-conforming file header.
>> Attached patch allows reading amrnb and amrwb from (live)
>> streams, fixes ticket #6678.
>
> New patch with auto-detection attached, passes probecheck.

 Simplified patch attached that does not duplicate two small arrays
 in the object file that are already duplicated in the source code.
 The uninitialized variable is also fixed.
>>>
>>> The last version triggered for repeated bytes (like adp),
>>> new version attached.
>>
>> Patch applied.
>
> Please remove codec_tag line you set in those demuxers.

Done.

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

[FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc non-uni hv mc msa functions

[kaustubh.raste]

From: Kaustubh Raste 

Use mask buffer.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevcdsp_msa.c | 1478 -
 1 file changed, 870 insertions(+), 608 deletions(-)

diff --git a/libavcodec/mips/hevcdsp_msa.c b/libavcodec/mips/hevcdsp_msa.c
index 73cc3ea..b17127c 100644
--- a/libavcodec/mips/hevcdsp_msa.c
+++ b/libavcodec/mips/hevcdsp_msa.c
@@ -22,6 +22,13 @@
 #include "libavcodec/mips/hevcdsp_mips.h"
 #include "libavcodec/mips/hevc_macros_msa.h"
 
+static const uint8_t ff_hevc_mask_arr[16 * 2] __attribute__((aligned(0x40))) = 
{
+/* 8 width cases */
+0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8,
+/* 4 width cases */
+0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20
+};
+
 static void hevc_copy_4w_msa(uint8_t *src, int32_t src_stride,
  int16_t *dst, int32_t dst_stride,
  int32_t height)
@@ -1308,31 +1315,28 @@ static void hevc_hv_8t_4w_msa(uint8_t *src, int32_t 
src_stride,
   int32_t height)
 {
 uint32_t loop_cnt;
-v16i8 src0, src1, src2, src3, src4, src5, src6, src7, src8;
+int32_t dst_stride_in_bytes = 2 * dst_stride;
+v16i8 src0, src1, src2, src3, src4, src5, src6, src7, src8, src9, src10;
 v8i16 filt0, filt1, filt2, filt3;
-v4i32 filt_h0, filt_h1, filt_h2, filt_h3;
+v8i16 filt_h0, filt_h1, filt_h2, filt_h3;
 v16i8 mask1, mask2, mask3;
 v8i16 filter_vec, const_vec;
 v16i8 vec0, vec1, vec2, vec3, vec4, vec5, vec6, vec7;
 v16i8 vec8, vec9, vec10, vec11, vec12, vec13, vec14, vec15;
-v8i16 dst30, dst41, dst52, dst63, dst66, dst87;
-v4i32 dst0_r, dst1_r;
-v8i16 dst10_r, dst32_r, dst54_r, dst76_r;
-v8i16 dst21_r, dst43_r, dst65_r, dst87_r;
-v16i8 mask0 = {
-0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20
-};
-v8u16 mask4 = { 0, 4, 1, 5, 2, 6, 3, 7 };
+v8i16 dst30, dst41, dst52, dst63, dst66, dst97, dst108;
+v4i32 dst0_r, dst1_r, dst2_r, dst3_r;
+v8i16 dst10_r, dst32_r, dst54_r, dst76_r, dst98_r;
+v8i16 dst21_r, dst43_r, dst65_r, dst87_r, dst109_r;
+v16i8 mask0 = LD_SB(ff_hevc_mask_arr + 16);
 
 src -= ((3 * src_stride) + 3);
 filter_vec = LD_SH(filter_x);
 SPLATI_H4_SH(filter_vec, 0, 1, 2, 3, filt0, filt1, filt2, filt3);
 
 filter_vec = LD_SH(filter_y);
-vec0 = __msa_clti_s_b((v16i8) filter_vec, 0);
-filter_vec = (v8i16) __msa_ilvr_b(vec0, (v16i8) filter_vec);
+UNPCK_R_SB_SH(filter_vec, filter_vec);
 
-SPLATI_W4_SW(filter_vec, filt_h0, filt_h1, filt_h2, filt_h3);
+SPLATI_W4_SH(filter_vec, filt_h0, filt_h1, filt_h2, filt_h3);
 
 mask1 = mask0 + 2;
 mask2 = mask0 + 4;
@@ -1364,47 +1368,56 @@ static void hevc_hv_8t_4w_msa(uint8_t *src, int32_t 
src_stride,
 DPADD_SB4_SH(vec12, vec13, vec14, vec15, filt0, filt1, filt2, filt3,
  dst63, dst63, dst63, dst63);
 
-ILVR_H3_SH(dst41, dst30, dst52, dst41, dst63, dst52,
-   dst10_r, dst21_r, dst32_r);
-dst43_r = __msa_ilvl_h(dst41, dst30);
-dst54_r = __msa_ilvl_h(dst52, dst41);
-dst65_r = __msa_ilvl_h(dst63, dst52);
+ILVRL_H2_SH(dst41, dst30, dst10_r, dst43_r);
+ILVRL_H2_SH(dst52, dst41, dst21_r, dst54_r);
+ILVRL_H2_SH(dst63, dst52, dst32_r, dst65_r);
 dst66 = (v8i16) __msa_splati_d((v2i64) dst63, 1);
 
-for (loop_cnt = height >> 1; loop_cnt--;) {
-LD_SB2(src, src_stride, src7, src8);
-src += (2 * src_stride);
-XORI_B2_128_SB(src7, src8);
+for (loop_cnt = height >> 2; loop_cnt--;) {
+LD_SB4(src, src_stride, src7, src8, src9, src10);
+src += (4 * src_stride);
+XORI_B4_128_SB(src7, src8, src9, src10);
 
-VSHF_B4_SB(src7, src8, mask0, mask1, mask2, mask3,
+VSHF_B4_SB(src7, src9, mask0, mask1, mask2, mask3,
vec0, vec1, vec2, vec3);
-dst87 = const_vec;
+VSHF_B4_SB(src8, src10, mask0, mask1, mask2, mask3,
+   vec4, vec5, vec6, vec7);
+dst97 = const_vec;
+dst108 = const_vec;
 DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt1, filt2, filt3,
- dst87, dst87, dst87, dst87);
-dst76_r = __msa_ilvr_h(dst87, dst66);
+ dst97, dst97, dst97, dst97);
+DPADD_SB4_SH(vec4, vec5, vec6, vec7, filt0, filt1, filt2, filt3,
+ dst108, dst108, dst108, dst108);
+
+dst76_r = __msa_ilvr_h(dst97, dst66);
+ILVRL_H2_SH(dst108, dst97, dst87_r, dst109_r);
+dst66 = (v8i16) __msa_splati_d((v2i64) dst97, 1);
+dst98_r = __msa_ilvr_h(dst66, dst108);
+
 dst0_r = HEVC_FILT_8TAP(dst10_r, dst32_r, dst54_r, dst76_r,
 filt_h0, filt_h1, filt_h2, filt_h3);
-dst87_r = __msa_vshf_h((v8i16) mask4, dst87, dst87);
 dst1_r = HEVC_FILT_8TAP(dst21_r, dst43_r, dst65_r, dst87_r,

Re: [FFmpeg-devel] [PATCH] avutil/frame: Add avcodec_private_ref to AVFrame

[Timo Rothenpieler]

I would prefer if this field would not be library-specific, but
perhaps just "private_ref" which is not allowed to be touched by
users, and documented to only be valid while within one library - ie.
if you pass a frame from avcodec to avfilter, avfilter could take over
the field (and just free any info, if its still in there).
This would avoid any chances of adding a multitude of fields later,
and a single AVFrame instance is not going to be used in multiple
libraries at the same time anyway (the contents might, but not the
actual AVFrame struct)


that should be easy to implement ...

a disadvantage is the slightly higher chance of mixing up types if
some codepath doesnt cleanup the field

question is what do most prefer ?
avcodec_private_ref ?   (that is one for each of the 2 libs)
private_ref ?
avframe_internal_ref ?  (that is a private struct defined in avutil 
similar to AVCodecInternal)


I like private_ref.

Following this approach also keeps the diff to libav small.



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] avutil/frame: Add avcodec_private_ref to AVFrame

[Timo Rothenpieler]

Am 05.11.2017 um 14:35 schrieb James Almer:

On 11/5/2017 9:34 AM, Michael Niedermayer wrote:

This gives libavcodec a field that it can freely and safely use.
Avoiding the need of wraping of a users opaque_ref field and its issues.


Could this perhaps be in an opaque internal struct instead, much like
AVCodecInternal and whatnot? As wm4 said in the relevant discussion,
this approach is nonoptimal and *will* snowball into a mess of fields if
other libav* libraries start requiring their own buffers in a frame.
An internal field of an opaque struct being in a public header is much
cleaner and easier to maintain than adding such specific fields that may
at some point in the future need to be removed.


The problem here is that avcodec, due to nested decoders and the like, 
might potentially wrap this field multiple times internally, so it 
basically has to be something avcodec specific.




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

[FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni weighted 4 tap vt mc msa functions

[kaustubh.raste]

From: Kaustubh Raste 

Use global mask buffer for appropriate mask load.
Use immediate unsigned saturation for clip to max saving one vector register.
Remove unused macro.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_uniw_msa.c | 1052 ++--
 1 file changed, 529 insertions(+), 523 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_uniw_msa.c 
b/libavcodec/mips/hevc_mc_uniw_msa.c
index 31fec73..f9ecb41 100644
--- a/libavcodec/mips/hevc_mc_uniw_msa.c
+++ b/libavcodec/mips/hevc_mc_uniw_msa.c
@@ -29,33 +29,6 @@ static const uint8_t ff_hevc_mask_arr[16 * 2] 
__attribute__((aligned(0x40))) = {
 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20
 };
 
-#define HEVC_UNIW_RND_CLIP2(in0, in1, wgt, offset, rnd,  \
-out0_r, out1_r, out0_l, out1_l)  \
-{\
-ILVR_H2_SW(in0, in0, in1, in1, out0_r, out1_r);  \
-ILVL_H2_SW(in0, in0, in1, in1, out0_l, out1_l);  \
-DOTP_SH4_SW(out0_r, out1_r, out0_l, out1_l, wgt, wgt, wgt, wgt,  \
-out0_r, out1_r, out0_l, out1_l); \
-SRAR_W4_SW(out0_r, out1_r, out0_l, out1_l, rnd); \
-ADD4(out0_r, offset, out1_r, offset, \
- out0_l, offset, out1_l, offset, \
- out0_r, out1_r, out0_l, out1_l);\
-out0_r = CLIP_SW_0_255(out0_r);  \
-out1_r = CLIP_SW_0_255(out1_r);  \
-out0_l = CLIP_SW_0_255(out0_l);  \
-out1_l = CLIP_SW_0_255(out1_l);  \
-}
-
-#define HEVC_UNIW_RND_CLIP4(in0, in1, in2, in3, wgt, offset, rnd,  \
-out0_r, out1_r, out2_r, out3_r,\
-out0_l, out1_l, out2_l, out3_l)\
-{  \
-HEVC_UNIW_RND_CLIP2(in0, in1, wgt, offset, rnd,\
-out0_r, out1_r, out0_l, out1_l);   \
-HEVC_UNIW_RND_CLIP2(in2, in3, wgt, offset, rnd,\
-out2_r, out3_r, out2_l, out3_l);   \
-}
-
 #define HEVC_UNIW_RND_CLIP2_MAX_SATU_H(in0_h, in1_h, wgt_w, offset_h, rnd_w,  \
out0_h, out1_h)\
 { \
@@ -3266,55 +3239,54 @@ static void hevc_vt_uniwgt_4t_4x2_msa(uint8_t *src,
   uint8_t *dst,
   int32_t dst_stride,
   const int8_t *filter,
-  int32_t height,
   int32_t weight,
   int32_t offset,
   int32_t rnd_val)
 {
+v16u8 out;
 v16i8 src0, src1, src2, src3, src4;
 v16i8 src10_r, src32_r, src21_r, src43_r;
 v16i8 src2110, src4332;
-v8i16 dst10;
+v8i16 dst0;
 v4i32 dst0_r, dst0_l;
 v8i16 filt0, filt1;
-v8i16 filter_vec, const_vec;
-v4i32 weight_vec, offset_vec, rnd_vec;
+v8i16 filter_vec, weight_vec_h, offset_vec, denom_vec;
+v4i32 weight_vec, rnd_vec;
 
 src -= src_stride;
 
-const_vec = __msa_ldi_h(128);
-const_vec <<= 6;
 weight = weight & 0x;
 
 weight_vec = __msa_fill_w(weight);
-offset_vec = __msa_fill_w(offset);
 rnd_vec = __msa_fill_w(rnd_val);
 
+weight *= 128;
+rnd_val -= 6;
+
+weight_vec_h = __msa_fill_h(weight);
+offset_vec = __msa_fill_h(offset);
+denom_vec = __msa_fill_h(rnd_val);
+
+weight_vec_h = __msa_srar_h(weight_vec_h, denom_vec);
+offset_vec = __msa_adds_s_h(offset_vec, weight_vec_h);
+
 filter_vec = LD_SH(filter);
 SPLATI_H2_SH(filter_vec, 0, 1, filt0, filt1);
 
-LD_SB3(src, src_stride, src0, src1, src2);
-src += (3 * src_stride);
+LD_SB5(src, src_stride, src0, src1, src2, src3, src4);
 ILVR_B2_SB(src1, src0, src2, src1, src10_r, src21_r);
-src2110 = (v16i8) __msa_ilvr_d((v2i64) src21_r, (v2i64) src10_r);
-src2110 = (v16i8) __msa_xori_b((v16u8) src2110, 128);
-LD_SB2(src, src_stride, src3, src4);
 ILVR_B2_SB(src3, src2, src4, src3, src32_r, src43_r);
-src4332 = (v16i8) __msa_ilvr_d((v2i64) src43_r, (v2i64) src32_r);
-src4332 = (v16i8) __msa_xori_b((v16u8) src4332, 128);
-
-dst10 = const_vec;
-DPADD_SB2_SH(src2110, src4332, filt0, filt1, dst10, dst10);
-
-ILVRL_H2_SW(dst10, dst10, dst0_r, dst0_l);
+ILVR_D2_SB(src21_r, src10_r, src43_r, src32_r, src2110, src4332);
+XORI_B2_128_SB(src2110, src4332);
+dst0 = HEVC_FILT_4TAP_SH(src2110, src4332, filt0, 

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Paul B Mahol]

On 11/5/17, Carl Eugen Hoyos  wrote:
> 2017-10-09 0:24 GMT+02:00 Carl Eugen Hoyos :
>> 2017-10-07 16:51 GMT+02:00 Carl Eugen Hoyos :
>>> 2017-10-01 18:23 GMT+02:00 Carl Eugen Hoyos :
 2017-09-27 18:08 GMT+02:00 Carl Eugen Hoyos :

> The existing amr demuxer does not allow reading streams,
> it requires the 3GPP-conforming file header.
> Attached patch allows reading amrnb and amrwb from (live)
> streams, fixes ticket #6678.

 New patch with auto-detection attached, passes probecheck.
>>>
>>> Simplified patch attached that does not duplicate two small arrays
>>> in the object file that are already duplicated in the source code.
>>> The uninitialized variable is also fixed.
>>
>> The last version triggered for repeated bytes (like adp),
>> new version attached.
>
> Patch applied.

Please remove codec_tag line you set in those demuxers.
Codec tag makes sense to set only and only if container have such tag.
Raw containers nowhere stores tags so no reason to set it to .mov values
either.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/pcm-bluray: Do not use incompatible pointers on big-endian.

[Hendrik Leppkes]

On Wed, Nov 1, 2017 at 7:01 PM, Carl Eugen Hoyos  wrote:
> 2017-11-01 18:31 GMT+01:00 Hendrik Leppkes :
>> On Wed, Nov 1, 2017 at 6:25 PM, Carl Eugen Hoyos  wrote:
>>> 2017-11-01 18:16 GMT+01:00 Hendrik Leppkes :
 On Wed, Nov 1, 2017 at 5:16 PM, Carl Eugen Hoyos  
 wrote:
> Hi!
>
> Attached patch silences two gcc warnings, no sample for odd channel count 
> found.
>
>  #if HAVE_BIGENDIAN
> -bytestream2_get_buffer(, dst16, avctx->channels * 
> 2);
> -dst16 += avctx->channels;
> +uint8_t *dst = frame->data[0];
> +bytestream2_get_buffer(, frame->data[0], 
> avctx->channels * 2);
> +dst += avctx->channels * 2;
>  #else
>  channel = avctx->channels;
>  do {

 This hunk seems fishy. dst is only ever set, never read, and this code
 is executed in a loop but always writes to the same position.
>>>
>>> I had sent the wrong version, please review this one.
>>
>> That still won't work, dst is declared within the loop, so its reset
>> back to the start at the beginning of the frame each iteration.
>
> New try attached.
>

The indentation of the variable declaration seems off. Shouldn't it be
on the level of the do?
Otherwise it should probably work fine.

Wouldn't it be easier to cast the type, though? Just wondering, not
blocking the patch.

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

Re: [FFmpeg-devel] [PATCH]lavc/pcm-dvd: Do not use an incompatible pointer on big-endian.

[Hendrik Leppkes]

On Wed, Nov 1, 2017 at 6:33 PM, Carl Eugen Hoyos  wrote:
> 2017-11-01 18:18 GMT+01:00 Hendrik Leppkes :
>> On Wed, Nov 1, 2017 at 5:13 PM, Carl Eugen Hoyos  wrote:
>>> Hi!
>>>
>>> Attached patch silences a gcc warning, tested with Fever.vob
>>>
>>>
>>> @@ -163,10 +162,12 @@ static void *pcm_dvd_decode_samples(AVCodecContext 
>>> *avctx, const uint8_t *src,
>>> switch (avctx->bits_per_coded_sample) {
>>> case 16: {
>>> #if HAVE_BIGENDIAN
>>> +int8_t *dst16 = dst;
>>> bytestream2_get_buffer(, dst16, blocks * s->block_size);
>>> -dst16 += blocks * s->block_size / 2;
>>> +dst16 += blocks * s->block_size;
>>> #else
>>> int samples = blocks * avctx->channels;
>>> +int16_t *dst16 = dst;
>>> do {
>>> *dst16++ = bytestream2_get_be16u();
>>> } while (--samples);
>>
>> This results in quite misleading code. dst16 is named like that
>> because its a 16-bit pointer, using the same pointer with different
>> types based on this ifdef seems error-prone in the future.
>
> Agree, new patch attached.
>

I think you attached the wrong patch, this is an old version of the
pcm-bluray patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni 4 tap hv mc msa functions

[kaustubh.raste]

From: Kaustubh Raste 

Use global mask buffer for appropriate mask load.
Remove unused macro and table.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_uni_msa.c | 1125 +++--
 1 file changed, 566 insertions(+), 559 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_uni_msa.c 
b/libavcodec/mips/hevc_mc_uni_msa.c
index 993dad0..740c970 100644
--- a/libavcodec/mips/hevc_mc_uni_msa.c
+++ b/libavcodec/mips/hevc_mc_uni_msa.c
@@ -283,25 +283,6 @@ static void copy_width64_msa(uint8_t *src, int32_t 
src_stride,
 }
 }
 
-static const uint8_t mc_filt_mask_arr[16 * 3] = {
-/* 8 width cases */
-0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8,
-/* 4 width cases */
-0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20,
-/* 4 width cases */
-8, 9, 9, 10, 10, 11, 11, 12, 24, 25, 25, 26, 26, 27, 27, 28
-};
-
-#define FILT_4TAP_DPADD_S_H(vec0, vec1, filt0, filt1)   \
-( { \
-v8i16 tmp0; \
-\
-tmp0 = __msa_dotp_s_h((v16i8) vec0, (v16i8) filt0); \
-tmp0 = __msa_dpadd_s_h(tmp0, (v16i8) vec1, (v16i8) filt1);  \
-\
-tmp0;   \
-} )
-
 static void common_hz_8t_4x4_msa(uint8_t *src, int32_t src_stride,
  uint8_t *dst, int32_t dst_stride,
  const int8_t *filter)
@@ -3109,19 +3090,18 @@ static void hevc_hv_uni_4t_4x2_msa(uint8_t *src,
uint8_t *dst,
int32_t dst_stride,
const int8_t *filter_x,
-   const int8_t *filter_y,
-   int32_t height)
+   const int8_t *filter_y)
 {
+v16u8 out;
 v16i8 src0, src1, src2, src3, src4;
 v8i16 filt0, filt1;
-v4i32 filt_h0, filt_h1;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8 };
+v8i16 filt_h0, filt_h1;
+v16i8 mask0 = LD_SB(ff_hevc_mask_arr + 16);
 v16i8 mask1;
-v8i16 filter_vec, const_vec;
+v8i16 filter_vec, tmp;
 v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
-v8i16 dst0, dst1, dst2, dst3, dst4;
-v4i32 dst0_r, dst1_r;
-v8i16 dst10_r, dst32_r, dst21_r, dst43_r;
+v8i16 dst20, dst31, dst42, dst10, dst32, dst21, dst43;
+v4i32 dst0, dst1;
 
 src -= (src_stride + 1);
 
@@ -3129,60 +3109,35 @@ static void hevc_hv_uni_4t_4x2_msa(uint8_t *src,
 SPLATI_H2_SH(filter_vec, 0, 1, filt0, filt1);
 
 filter_vec = LD_SH(filter_y);
-vec0 = __msa_clti_s_b((v16i8) filter_vec, 0);
-filter_vec = (v8i16) __msa_ilvr_b(vec0, (v16i8) filter_vec);
+UNPCK_R_SB_SH(filter_vec, filter_vec);
 
-SPLATI_W2_SW(filter_vec, 0, filt_h0, filt_h1);
+SPLATI_W2_SH(filter_vec, 0, filt_h0, filt_h1);
 
 mask1 = mask0 + 2;
 
-const_vec = __msa_ldi_h(128);
-const_vec <<= 6;
-
-LD_SB3(src, src_stride, src0, src1, src2);
-src += (3 * src_stride);
-
-XORI_B3_128_SB(src0, src1, src2);
-
-VSHF_B2_SB(src0, src0, src0, src0, mask0, mask1, vec0, vec1);
-VSHF_B2_SB(src1, src1, src1, src1, mask0, mask1, vec2, vec3);
-VSHF_B2_SB(src2, src2, src2, src2, mask0, mask1, vec4, vec5);
-
-dst0 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst0, dst0);
-dst1 = const_vec;
-DPADD_SB2_SH(vec2, vec3, filt0, filt1, dst1, dst1);
-dst2 = const_vec;
-DPADD_SB2_SH(vec4, vec5, filt0, filt1, dst2, dst2);
-
-ILVR_H2_SH(dst1, dst0, dst2, dst1, dst10_r, dst21_r);
-LD_SB2(src, src_stride, src3, src4);
-XORI_B2_128_SB(src3, src4);
-
-/* row 3 */
-VSHF_B2_SB(src3, src3, src3, src3, mask0, mask1, vec0, vec1);
-dst3 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst3, dst3);
-
-dst32_r = __msa_ilvr_h(dst3, dst2);
-dst0_r = HEVC_FILT_4TAP(dst10_r, dst32_r, filt_h0, filt_h1);
-dst0_r >>= 6;
-
-/* row 4 */
-VSHF_B2_SB(src4, src4, src4, src4, mask0, mask1, vec0, vec1);
-dst4 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst4, dst4);
-
-dst43_r = __msa_ilvr_h(dst4, dst3);
-dst1_r = HEVC_FILT_4TAP(dst21_r, dst43_r, filt_h0, filt_h1);
-dst1_r >>= 6;
-
-dst0_r = (v4i32) __msa_pckev_h((v8i16) dst1_r, (v8i16) dst0_r);
-dst0_r = (v4i32) __msa_srari_h((v8i16) dst0_r, 6);
-dst0_r = (v4i32) CLIP_SH_0_255(dst0_r);
-dst0_r = (v4i32) __msa_pckev_b((v16i8) dst0_r, (v16i8) dst0_r);
+LD_SB5(src, src_stride, src0, src1, src2, src3, src4);
+XORI_B5_128_SB(src0, src1, src2, src3, src4);
 
-ST4x2_UB(dst0_r, dst, dst_stride);
+VSHF_B2_SB(src0, src2, src0, src2, mask0, mask1, vec0, vec1);
+VSHF_B2_SB(src1, src3, src1, 

Re: [FFmpeg-devel] On in-tree external headers

[Jorge Ramirez]

On 11/05/2017 11:12 PM, Jan Ekstrom wrote:

I also feel like whatever this rule would look like, it's already practiced
that way. There isn't really a way not do decide this on a case by case
basis. Luckily it's not something that comes up every other day.
If someone would submit random third party library headers to compat/ for no
apparent reason other than comfort, it would certainly be rejected.

Yes, the rule most certainly would contain something along the lines
of "...this is something that should be considered on a case-by-case
basis with a reasoning being mentioned and considered..."


+1.

also what about adding the justification to some sort of readme in the 
include path (compat/cude/README.tx, compat/avisynth/README.txt and so 
on) ; just to others trying to figure out when it is acceptable to 
include external headers have explicit guidelines.




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