Re: [FFmpeg-devel] [PATCH] avcodec/mips: preload data in hevc sao edge 45 degree filter msa functions

2017-09-26 Thread Manojkumar Bhosale
LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Monday, September 25, 2017 6:09 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: preload data in hevc sao edge 45 
degree filter msa functions

From: Kaustubh Raste 

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_lpf_sao_msa.c |  197 
 1 file changed, 135 insertions(+), 62 deletions(-)

diff --git a/libavcodec/mips/hevc_lpf_sao_msa.c 
b/libavcodec/mips/hevc_lpf_sao_msa.c
index 39c647e..c192265 100644
--- a/libavcodec/mips/hevc_lpf_sao_msa.c
+++ b/libavcodec/mips/hevc_lpf_sao_msa.c
@@ -1878,23 +1878,25 @@ static void 
hevc_sao_edge_filter_45degree_4width_msa(uint8_t *dst,
  int32_t height)  {
 uint8_t *src_orig;
-int32_t h_cnt;
 uint32_t dst_val0, dst_val1;
-v8i16 edge_idx = { 1, 2, 0, 3, 4, 0, 0, 0 };
+v16i8 edge_idx = { 1, 2, 0, 3, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 
+ };
 v16u8 const1 = (v16u8) __msa_ldi_b(1);
-v16i8 zero = { 0 };
+v16i8 offset, sao_offset = LD_SB(sao_offset_val);
 v16u8 cmp_minus10, diff_minus10, src_minus10, cmp_minus11, diff_minus11;
 v16u8 src_minus11, src10, src11;
 v16i8 src_plus0, src_zero0, src_plus1, src_zero1, dst0;
-v8i16 sao_offset, src00, src01, offset_mask0, offset_mask1;
+v8i16 offset_mask0, offset_mask1;
 
-sao_offset = LD_SH(sao_offset_val);
+sao_offset = __msa_pckev_b(sao_offset, sao_offset);
 
 src_orig = src - 1;
+
+/* load in advance */
 LD_UB2(src_orig - src_stride, src_stride, src_minus10, src_minus11);
+LD_UB2(src_orig + src_stride, src_stride, src10, src11);
 
-for (h_cnt = (height >> 1); h_cnt--;) {
-LD_UB2(src_orig + src_stride, src_stride, src10, src11);
+for (height -= 2; height; height -= 2) {
+src_orig += (src_stride << 1);
 
 SLDI_B2_0_SB(src_minus11, src10, src_zero0, src_zero1, 1);
 SLDI_B2_0_SB(src10, src11, src_plus0, src_plus1, 2); @@ -1917,20 
+1919,22 @@ static void hevc_sao_edge_filter_45degree_4width_msa(uint8_t *dst,
 offset_mask0 = (v8i16) (__msa_hadd_u_h(diff_minus10, diff_minus10) + 
2);
 offset_mask1 = (v8i16) (__msa_hadd_u_h(diff_minus11, diff_minus11) + 
2);
 
-VSHF_H2_SH(edge_idx, edge_idx, sao_offset, sao_offset, offset_mask0,
-   offset_mask0, offset_mask0, offset_mask0);
-VSHF_H2_SH(edge_idx, edge_idx, sao_offset, sao_offset, offset_mask1,
-   offset_mask1, offset_mask1, offset_mask1);
-ILVEV_B2_SH(src_zero0, zero, src_zero1, zero, src00, src01);
-ADD2(offset_mask0, src00, offset_mask1, src01, offset_mask0,
- offset_mask1);
-CLIP_SH2_0_255(offset_mask0, offset_mask1);
+offset = __msa_pckev_b((v16i8) offset_mask1, (v16i8) offset_mask0);
+dst0 = __msa_pckev_b((v16i8) src_zero1, (v16i8) src_zero0);
 
-dst0 = __msa_pckev_b((v16i8) offset_mask1, (v16i8) offset_mask0);
+VSHF_B2_SB(edge_idx, edge_idx, sao_offset, sao_offset, offset,
+   offset, offset, offset);
+
+dst0 = (v16i8) __msa_xori_b((v16u8) dst0, 128);
+dst0 = __msa_adds_s_b(dst0, offset);
+dst0 = (v16i8) __msa_xori_b((v16u8) dst0, 128);
 
 src_minus10 = src10;
 src_minus11 = src11;
 
+/* load in advance */
+LD_UB2(src_orig + src_stride, src_stride, src10, src11);
+
 dst_val0 = __msa_copy_u_w((v4i32) dst0, 0);
 dst_val1 = __msa_copy_u_w((v4i32) dst0, 2);
 SW(dst_val0, dst);
@@ -1938,8 +1942,44 @@ static void 
hevc_sao_edge_filter_45degree_4width_msa(uint8_t *dst,
 SW(dst_val1, dst);
 
 dst += dst_stride;
-src_orig += (src_stride << 1);
 }
+
+SLDI_B2_0_SB(src_minus11, src10, src_zero0, src_zero1, 1);
+SLDI_B2_0_SB(src10, src11, src_plus0, src_plus1, 2);
+
+ILVR_B2_UB(src_plus0, src_minus10, src_plus1, src_minus11, src_minus10,
+   src_minus11);
+ILVR_B2_SB(src_zero0, src_zero0, src_zero1, src_zero1, src_zero0,
+   src_zero1);
+
+cmp_minus10 = ((v16u8) src_zero0 == src_minus10);
+diff_minus10 = __msa_nor_v(cmp_minus10, cmp_minus10);
+cmp_minus10 = (src_minus10 < (v16u8) src_zero0);
+diff_minus10 = __msa_bmnz_v(diff_minus10, const1, cmp_minus10);
+
+cmp_minus11 = ((v16u8) src_zero1 == src_minus11);
+diff_minus11 = __msa_nor_v(cmp_minus11, cmp_minus11);
+cmp_minus11 = (src_minus11 < (v16u8) src_zero1);
+diff_minus11 = __msa_bmnz_v(diff_minus11, const1, cmp_minus11);
+
+offset_mask0 = (v8i16) (__msa_hadd_u_h(diff_minus10, diff_minus10) + 2);
+offset_mask1 = (v8i16) (__msa_hadd_u_h(diff_minus11, diff_minus11) 
+ + 2);
+
+offset = __msa_pckev_b((v16i8) offset_mask1, (v16i8) offset_mask0);
+dst0 = __msa_pckev_b((v16i8) src_zero1, (v16i8) src_zero0);
+
+VSHF_

[FFmpeg-devel] [PATCH] avcodec/mips: Improve avc put mc 20, 01 and 03 msa functions

2017-09-26 Thread kaustubh.raste
From: Kaustubh Raste 

Remove loops and unroll as block sizes are known.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/h264qpel_msa.c |  441 +++-
 1 file changed, 432 insertions(+), 9 deletions(-)

diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec/mips/h264qpel_msa.c
index b7f6c3d..0b42bc4 100644
--- a/libavcodec/mips/h264qpel_msa.c
+++ b/libavcodec/mips/h264qpel_msa.c
@@ -148,6 +148,17 @@ static const uint8_t luma_mask_arr[16 * 8] = {
 hz_out_m;\
 } )
 
+#define AVC_DOT_SH3_SH(in0, in1, in2, coeff0, coeff1, coeff2)   \
+( { \
+v8i16 out0_m;   \
+\
+out0_m = __msa_dotp_s_h((v16i8) in0, (v16i8) coeff0);   \
+out0_m = __msa_dpadd_s_h(out0_m, (v16i8) in1, (v16i8) coeff1);  \
+out0_m = __msa_dpadd_s_h(out0_m, (v16i8) in2, (v16i8) coeff2);  \
+\
+out0_m; \
+} )
+
 static void avc_luma_hz_4w_msa(const uint8_t *src, int32_t src_stride,
uint8_t *dst, int32_t dst_stride,
int32_t height)
@@ -3373,55 +3384,467 @@ void ff_put_h264_qpel4_mc30_msa(uint8_t *dst, const 
uint8_t *src,
 void ff_put_h264_qpel16_mc20_msa(uint8_t *dst, const uint8_t *src,
  ptrdiff_t stride)
 {
-avc_luma_hz_16w_msa(src - 2, stride, dst, stride, 16);
+uint32_t loop_cnt;
+v16i8 src0, src1, src2, src3, src4, src5, src6, src7, mask0, mask1, mask2;
+v16i8 vec0, vec1, vec2, vec3, vec4, vec5, vec6, vec7, vec8, vec9, vec10;
+v16i8 vec11;
+v8i16 res0, res1, res2, res3, res4, res5, res6, res7;
+v16i8 minus5b = __msa_ldi_b(-5);
+v16i8 plus20b = __msa_ldi_b(20);
+
+LD_SB3(&luma_mask_arr[0], 16, mask0, mask1, mask2);
+src -= 2;
+
+for (loop_cnt = 4; loop_cnt--;) {
+LD_SB2(src, 8, src0, src1);
+src += stride;
+LD_SB2(src, 8, src2, src3);
+src += stride;
+LD_SB2(src, 8, src4, src5);
+src += stride;
+LD_SB2(src, 8, src6, src7);
+src += stride;
+
+XORI_B8_128_SB(src0, src1, src2, src3, src4, src5, src6, src7);
+VSHF_B2_SB(src0, src0, src1, src1, mask0, mask0, vec0, vec3);
+VSHF_B2_SB(src2, src2, src3, src3, mask0, mask0, vec6, vec9);
+VSHF_B2_SB(src0, src0, src1, src1, mask1, mask1, vec1, vec4);
+VSHF_B2_SB(src2, src2, src3, src3, mask1, mask1, vec7, vec10);
+VSHF_B2_SB(src0, src0, src1, src1, mask2, mask2, vec2, vec5);
+VSHF_B2_SB(src2, src2, src3, src3, mask2, mask2, vec8, vec11);
+HADD_SB4_SH(vec0, vec3, vec6, vec9, res0, res1, res2, res3);
+DPADD_SB4_SH(vec1, vec4, vec7, vec10, minus5b, minus5b, minus5b,
+ minus5b, res0, res1, res2, res3);
+DPADD_SB4_SH(vec2, vec5, vec8, vec11, plus20b, plus20b, plus20b,
+ plus20b, res0, res1, res2, res3);
+VSHF_B2_SB(src4, src4, src5, src5, mask0, mask0, vec0, vec3);
+VSHF_B2_SB(src6, src6, src7, src7, mask0, mask0, vec6, vec9);
+VSHF_B2_SB(src4, src4, src5, src5, mask1, mask1, vec1, vec4);
+VSHF_B2_SB(src6, src6, src7, src7, mask1, mask1, vec7, vec10);
+VSHF_B2_SB(src4, src4, src5, src5, mask2, mask2, vec2, vec5);
+VSHF_B2_SB(src6, src6, src7, src7, mask2, mask2, vec8, vec11);
+HADD_SB4_SH(vec0, vec3, vec6, vec9, res4, res5, res6, res7);
+DPADD_SB4_SH(vec1, vec4, vec7, vec10, minus5b, minus5b, minus5b,
+ minus5b, res4, res5, res6, res7);
+DPADD_SB4_SH(vec2, vec5, vec8, vec11, plus20b, plus20b, plus20b,
+ plus20b, res4, res5, res6, res7);
+SRARI_H4_SH(res0, res1, res2, res3, 5);
+SRARI_H4_SH(res4, res5, res6, res7, 5);
+SAT_SH4_SH(res0, res1, res2, res3, 7);
+SAT_SH4_SH(res4, res5, res6, res7, 7);
+PCKEV_B4_SB(res1, res0, res3, res2, res5, res4, res7, res6, vec0, vec1,
+vec2, vec3);
+XORI_B4_128_SB(vec0, vec1, vec2, vec3);
+ST_SB4(vec0, vec1, vec2, vec3, dst, stride);
+dst += (4 * stride);
+}
 }
 
 void ff_put_h264_qpel8_mc20_msa(uint8_t *dst, const uint8_t *src,
 ptrdiff_t stride)
 {
-avc_luma_hz_8w_msa(src - 2, stride, dst, stride, 8);
+v16u8 out0, out1, out2, out3;
+v16i8 src0, src1, src2, src3, src4, src5, src6, src7, mask0, mask1, mask2;
+v16i8 vec0, vec1, vec2, vec3, vec4, vec5, vec6, vec7, vec8, vec9, vec10;
+v16i8 vec11;
+v8i16 res0, res1, res2, res3, res4, res5, res6, res7;
+v16i8 minus5b = __msa_ldi_b(-5);
+v16i8 plus20b = __msa_ldi_b(20);
+
+LD_SB3(&luma_mask_arr[0], 16, mask0, mask1, 

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Removed generic function call in avc intra msa functions

2017-09-26 Thread Manojkumar Bhosale
LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Tuesday, September 26, 2017 10:40 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Removed generic function call in 
avc intra msa functions

From: Kaustubh Raste 

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/h264pred_msa.c |  215 +---
 1 file changed, 92 insertions(+), 123 deletions(-)

diff --git a/libavcodec/mips/h264pred_msa.c b/libavcodec/mips/h264pred_msa.c 
index c297aec..b9990c1 100644
--- a/libavcodec/mips/h264pred_msa.c
+++ b/libavcodec/mips/h264pred_msa.c
@@ -106,115 +106,6 @@ static void intra_predict_horiz_16x16_msa(uint8_t *src, 
int32_t src_stride,
dst, dst_stride);
 }
 
-static void intra_predict_dc_8x8_msa(uint8_t *src_top, uint8_t *src_left,
- int32_t src_stride_left,
- uint8_t *dst, int32_t dst_stride,
- uint8_t is_above, uint8_t is_left)
-{
-uint32_t row;
-uint32_t out, addition = 0;
-v16u8 src_above, store;
-v8u16 sum_above;
-v4u32 sum_top;
-v2u64 sum;
-
-if (is_left && is_above) {
-src_above = LD_UB(src_top);
-
-sum_above = __msa_hadd_u_h(src_above, src_above);
-sum_top = __msa_hadd_u_w(sum_above, sum_above);
-sum = __msa_hadd_u_d(sum_top, sum_top);
-addition = __msa_copy_u_w((v4i32) sum, 0);
-
-for (row = 0; row < 8; row++) {
-addition += src_left[row * src_stride_left];
-}
-
-addition = (addition + 8) >> 4;
-store = (v16u8) __msa_fill_b(addition);
-} else if (is_left) {
-for (row = 0; row < 8; row++) {
-addition += src_left[row * src_stride_left];
-}
-
-addition = (addition + 4) >> 3;
-store = (v16u8) __msa_fill_b(addition);
-} else if (is_above) {
-src_above = LD_UB(src_top);
-
-sum_above = __msa_hadd_u_h(src_above, src_above);
-sum_top = __msa_hadd_u_w(sum_above, sum_above);
-sum = __msa_hadd_u_d(sum_top, sum_top);
-sum = (v2u64) __msa_srari_d((v2i64) sum, 3);
-store = (v16u8) __msa_splati_b((v16i8) sum, 0);
-} else {
-store = (v16u8) __msa_ldi_b(128);
-}
-
-out = __msa_copy_u_w((v4i32) store, 0);
-
-for (row = 8; row--;) {
-SW(out, dst);
-SW(out, (dst + 4));
-dst += dst_stride;
-}
-}
-
-static void intra_predict_dc_16x16_msa(uint8_t *src_top, uint8_t *src_left,
-   int32_t src_stride_left,
-   uint8_t *dst, int32_t dst_stride,
-   uint8_t is_above, uint8_t is_left)
-{
-uint32_t row;
-uint32_t addition = 0;
-v16u8 src_above, store;
-v8u16 sum_above;
-v4u32 sum_top;
-v2u64 sum;
-
-if (is_left && is_above) {
-src_above = LD_UB(src_top);
-
-sum_above = __msa_hadd_u_h(src_above, src_above);
-sum_top = __msa_hadd_u_w(sum_above, sum_above);
-sum = __msa_hadd_u_d(sum_top, sum_top);
-sum_top = (v4u32) __msa_pckev_w((v4i32) sum, (v4i32) sum);
-sum = __msa_hadd_u_d(sum_top, sum_top);
-addition = __msa_copy_u_w((v4i32) sum, 0);
-
-for (row = 0; row < 16; row++) {
-addition += src_left[row * src_stride_left];
-}
-
-addition = (addition + 16) >> 5;
-store = (v16u8) __msa_fill_b(addition);
-} else if (is_left) {
-for (row = 0; row < 16; row++) {
-addition += src_left[row * src_stride_left];
-}
-
-addition = (addition + 8) >> 4;
-store = (v16u8) __msa_fill_b(addition);
-} else if (is_above) {
-src_above = LD_UB(src_top);
-
-sum_above = __msa_hadd_u_h(src_above, src_above);
-sum_top = __msa_hadd_u_w(sum_above, sum_above);
-sum = __msa_hadd_u_d(sum_top, sum_top);
-sum_top = (v4u32) __msa_pckev_w((v4i32) sum, (v4i32) sum);
-sum = __msa_hadd_u_d(sum_top, sum_top);
-sum = (v2u64) __msa_srari_d((v2i64) sum, 4);
-store = (v16u8) __msa_splati_b((v16i8) sum, 0);
-} else {
-store = (v16u8) __msa_ldi_b(128);
-}
-
-for (row = 16; row--;) {
-ST_UB(store, dst);
-dst += dst_stride;
-}
-}
-
 #define INTRA_PREDICT_VALDC_8X8_MSA(val)   
\
 static void intra_predict_##val##dc_8x8_msa(uint8_t *dst, int32_t dst_stride)  
\
 {  
\
@@ -646,8 +537,42 @@ void ff_h264_intra_pred_dc_16x16_msa(uint8_t *src, 
ptrdiff_t stride)
 uint8_t *src_top = src - stride;
 uint8_t *src_left = src - 1;
 uint8_t *dst = src;
+uint32_t addition = 0;
+v16u8 src_above, out;
+v8u16 sum_above;
+v4u32 sum_top;
+v2u64

Re: [FFmpeg-devel] [PATCH v4] fate: add tests for psnr and ssim filter

2017-09-26 Thread Tobias Rapp

On 20.09.2017 11:01, Tobias Rapp wrote:

Metadata filter output is passed through an Awk script comparing floats
against reference values with specified "fuzz" tolerance to account for
architectural differences (e.g. x86-32 vs. x86-64).

Signed-off-by: Tobias Rapp 
---
tested on Linux x86-32/64 and Mips (Qemu)

v4:
  - fixed iteration order of final print loop
  - update of debug output

v3:
  - avoid precision loss due to rounding of float values

v2:
  - removed CPUFLAGS work-around for ssim filter issue
  - added metadata float value post-processing script

  tests/fate-run.sh |  9 +
  tests/fate/filter-video.mak   | 14 
  tests/ref/fate/filter-refcmp-psnr-rgb | 45 
  tests/ref/fate/filter-refcmp-psnr-yuv | 45 
  tests/ref/fate/filter-refcmp-ssim-rgb | 30 
  tests/ref/fate/filter-refcmp-ssim-yuv | 30 
  tests/refcmp-metadata.awk | 64 +++
  7 files changed, 237 insertions(+)
  create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
  create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
  create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
  create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv
  create mode 100644 tests/refcmp-metadata.awk

[...]


I'd like to push this soon, if there are no objections (Nicolas?).

Regards,
Tobias

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


Re: [FFmpeg-devel] [PATCH 7/9] avcodec/h264: add decode_params callback to AVHWAccel

2017-09-26 Thread Hendrik Leppkes
On Tue, Sep 26, 2017 at 2:36 AM, Aman Gupta  wrote:
> From: Aman Gupta 
>
> This callback will be used by the VideoToolbox H264 hwaccel so that it
> can receive SPS and PPS NALUs. VideoToolbox requires PPS changes to be
> fed into the decoder session, and for the session to be recreated when
> the SPS changes.
> ---
>  libavcodec/avcodec.h | 12 
>  libavcodec/h264dec.c | 14 ++
>  2 files changed, 26 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 5c84974e03..14bb509f66 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3921,6 +3921,18 @@ typedef struct AVHWAccel {
>  int (*start_frame)(AVCodecContext *avctx, const uint8_t *buf, uint32_t 
> buf_size);
>
>  /**
> + * Callback for parameter data.
> + *
> + * Used for SPS/PPS in H264 streams.
> + *
> + * @param avctx the codec context
> + * @param buf the slice data buffer base
> + * @param buf_size the size of the slice in bytes
> + * @return zero if successful, a negative value otherwise
> + */
> +int (*decode_params)(AVCodecContext *avctx, const uint8_t *buf, uint32_t 
> buf_size);
> +
> +/**
>   * Callback for each slice.
>   *
>   * Meaningful slice information (codec specific) is guaranteed to
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index a8263f2e19..ab95beb020 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -738,6 +738,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  break;
>  case H264_NAL_SPS: {
>  GetBitContext tmp_gb = nal->gb;
> +if (avctx->hwaccel && avctx->hwaccel->decode_params) {
> +ret = avctx->hwaccel->decode_params(avctx,
> +nal->data,
> +nal->size);

You probably want nal->raw_data and raw_size here (and below),
hardware typically works on raw (escaped) data.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc chroma vert mc msa functions

2017-09-26 Thread Manojkumar Bhosale
LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Tuesday, September 26, 2017 10:56 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc chroma vert mc msa 
functions

From: Kaustubh Raste 

Replace generic with block size specific function.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/h264chroma_msa.c |  237 ++
 1 file changed, 112 insertions(+), 125 deletions(-)

diff --git a/libavcodec/mips/h264chroma_msa.c b/libavcodec/mips/h264chroma_msa.c
index c27830d..16e2fe4 100644
--- a/libavcodec/mips/h264chroma_msa.c
+++ b/libavcodec/mips/h264chroma_msa.c
@@ -302,8 +302,7 @@ static void avc_chroma_hz_8w_msa(uint8_t *src, uint8_t 
*dst, int32_t stride,
 }
 }
 
-static void avc_chroma_vt_2x2_msa(uint8_t *src, int32_t src_stride,
-  uint8_t *dst, int32_t dst_stride,
+static void avc_chroma_vt_2x2_msa(uint8_t *src, uint8_t *dst, int32_t 
+stride,
   uint32_t coeff0, uint32_t coeff1)  {
 uint16_t out0, out1;
@@ -315,7 +314,7 @@ static void avc_chroma_vt_2x2_msa(uint8_t *src, int32_t 
src_stride,
 v16i8 coeff_vec1 = __msa_fill_b(coeff1);
 v16u8 coeff_vec = (v16u8) __msa_ilvr_b(coeff_vec0, coeff_vec1);
 
-LD_SB3(src, src_stride, src0, src1, src2);
+LD_SB3(src, stride, src0, src1, src2);
 
 ILVR_B2_UB(src1, src0, src2, src1, tmp0, tmp1);
 
@@ -331,12 +330,11 @@ static void avc_chroma_vt_2x2_msa(uint8_t *src, int32_t 
src_stride,
 out1 = __msa_copy_u_h(res, 2);
 
 SH(out0, dst);
-dst += dst_stride;
+dst += stride;
 SH(out1, dst);
 }
 
-static void avc_chroma_vt_2x4_msa(uint8_t *src, int32_t src_stride,
-  uint8_t *dst, int32_t dst_stride,
+static void avc_chroma_vt_2x4_msa(uint8_t *src, uint8_t *dst, int32_t 
+stride,
   uint32_t coeff0, uint32_t coeff1)  {
 v16u8 src0, src1, src2, src3, src4; @@ -347,39 +345,7 @@ static void 
avc_chroma_vt_2x4_msa(uint8_t *src, int32_t src_stride,
 v16i8 coeff_vec1 = __msa_fill_b(coeff1);
 v16u8 coeff_vec = (v16u8) __msa_ilvr_b(coeff_vec0, coeff_vec1);
 
-LD_UB5(src, src_stride, src0, src1, src2, src3, src4);
-ILVR_B4_UB(src1, src0, src2, src1, src3, src2, src4, src3,
-   tmp0, tmp1, tmp2, tmp3);
-ILVR_W2_UB(tmp1, tmp0, tmp3, tmp2, tmp0, tmp2);
-
-tmp0 = (v16u8) __msa_ilvr_d((v2i64) tmp2, (v2i64) tmp0);
-
-res_r = __msa_dotp_u_h(tmp0, coeff_vec);
-res_r <<= 3;
-res_r = (v8u16) __msa_srari_h((v8i16) res_r, 6);
-res_r = __msa_sat_u_h(res_r, 7);
-
-res = (v8i16) __msa_pckev_b((v16i8) res_r, (v16i8) res_r);
-
-ST2x4_UB(res, 0, dst, dst_stride);
-}
-
-static void avc_chroma_vt_2x8_msa(uint8_t *src, int32_t src_stride,
-  uint8_t *dst, int32_t dst_stride,
-  uint32_t coeff0, uint32_t coeff1)
-{
-v16u8 src0, src1, src2, src3, src4, src5, src6, src7, src8;
-v16u8 tmp0, tmp1, tmp2, tmp3;
-v8i16 res;
-v8u16 res_r;
-v16i8 coeff_vec0 = __msa_fill_b(coeff0);
-v16i8 coeff_vec1 = __msa_fill_b(coeff1);
-v16u8 coeff_vec = (v16u8) __msa_ilvr_b(coeff_vec0, coeff_vec1);
-
-LD_UB5(src, src_stride, src0, src1, src2, src3, src4);
-src += (5 * src_stride);
-LD_UB4(src, src_stride, src5, src6, src7, src8);
-
+LD_UB5(src, stride, src0, src1, src2, src3, src4);
 ILVR_B4_UB(src1, src0, src2, src1, src3, src2, src4, src3,
tmp0, tmp1, tmp2, tmp3);
 ILVR_W2_UB(tmp1, tmp0, tmp3, tmp2, tmp0, tmp2); @@ -393,42 +359,21 @@ 
static void avc_chroma_vt_2x8_msa(uint8_t *src, int32_t src_stride,
 
 res = (v8i16) __msa_pckev_b((v16i8) res_r, (v16i8) res_r);
 
-ST2x4_UB(res, 0, dst, dst_stride);
-dst += (4 * dst_stride);
-
-ILVR_B4_UB(src5, src4, src6, src5, src7, src6, src8, src7,
-   tmp0, tmp1, tmp2, tmp3);
-ILVR_W2_UB(tmp1, tmp0, tmp3, tmp2, tmp0, tmp2);
-
-tmp0 = (v16u8) __msa_ilvr_d((v2i64) tmp2, (v2i64) tmp0);
-
-res_r = __msa_dotp_u_h(tmp0, coeff_vec);
-res_r <<= 3;
-res_r = (v8u16) __msa_srari_h((v8i16) res_r, 6);
-res_r = __msa_sat_u_h(res_r, 7);
-
-res = (v8i16) __msa_pckev_b((v16i8) res_r, (v16i8) res_r);
-
-ST2x4_UB(res, 0, dst, dst_stride);
-dst += (4 * dst_stride);
+ST2x4_UB(res, 0, dst, stride);
 }
 
-static void avc_chroma_vt_2w_msa(uint8_t *src, int32_t src_stride,
- uint8_t *dst, int32_t dst_stride,
+static void avc_chroma_vt_2w_msa(uint8_t *src, uint8_t *dst, int32_t 
+stride,
  uint32_t coeff0, uint32_t coeff1,
  int32_t height)  {
 if (2 == height) {
-avc_chroma_vt_2x2_msa(src, src_stride, dst, dst_stride, coeff0, 
coeff1);
+avc_chroma_vt_2x2_msa(src, dst, stride, coeff0, coef

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc weighted mc msa functions

2017-09-26 Thread Manojkumar Bhosale
LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Tuesday, September 26, 2017 10:51 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc weighted mc msa 
functions

From: Kaustubh Raste 

Replace generic with block size specific function.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/h264dsp_msa.c   |  423 ++-
 libavutil/mips/generic_macros_msa.h |   36 +++
 2 files changed, 306 insertions(+), 153 deletions(-)

diff --git a/libavcodec/mips/h264dsp_msa.c b/libavcodec/mips/h264dsp_msa.c 
index 422703d..5b06bd9 100644
--- a/libavcodec/mips/h264dsp_msa.c
+++ b/libavcodec/mips/h264dsp_msa.c
@@ -25,187 +25,201 @@ static void avc_wgt_4x2_msa(uint8_t *data, int32_t stride,
 int32_t log2_denom, int32_t src_weight,
 int32_t offset_in)  {
-uint32_t data0, data1;
+uint32_t tp0, tp1, offset_val;
 v16u8 zero = { 0 };
-v16u8 src0, src1;
-v4i32 res0, res1;
-v8i16 temp0, temp1, vec0, vec1, wgt, denom, offset;
-v8u16 out0, out1;
+v16u8 src0 = { 0 };
+v8i16 src0_r, tmp0, wgt, denom, offset;
 
-offset_in <<= (log2_denom);
-
-if (log2_denom) {
-offset_in += (1 << (log2_denom - 1));
-}
+offset_val = (unsigned) offset_in << log2_denom;
 
 wgt = __msa_fill_h(src_weight);
-offset = __msa_fill_h(offset_in);
+offset = __msa_fill_h(offset_val);
 denom = __msa_fill_h(log2_denom);
 
-data0 = LW(data);
-data1 = LW(data + stride);
-
-src0 = (v16u8) __msa_fill_w(data0);
-src1 = (v16u8) __msa_fill_w(data1);
+LW2(data, stride, tp0, tp1);
+INSERT_W2_UB(tp0, tp1, src0);
+src0_r = (v8i16) __msa_ilvr_b((v16i8) zero, (v16i8) src0);
+tmp0 = wgt * src0_r;
+tmp0 = __msa_adds_s_h(tmp0, offset);
+tmp0 = __msa_maxi_s_h(tmp0, 0);
+tmp0 = __msa_srlr_h(tmp0, denom);
+tmp0 = (v8i16) __msa_sat_u_h((v8u16) tmp0, 7);
+src0 = (v16u8) __msa_pckev_b((v16i8) tmp0, (v16i8) tmp0);
+ST4x2_UB(src0, data, stride);
+}
 
-ILVR_B2_SH(zero, src0, zero, src1, vec0, vec1);
-MUL2(wgt, vec0, wgt, vec1, temp0, temp1);
-ADDS_SH2_SH(temp0, offset, temp1, offset, temp0, temp1);
-MAXI_SH2_SH(temp0, temp1, 0);
+static void avc_wgt_4x4_msa(uint8_t *data, int32_t stride, int32_t log2_denom,
+int32_t src_weight, int32_t offset_in) {
+uint32_t tp0, tp1, tp2, tp3, offset_val;
+v16u8 src0 = { 0 };
+v8i16 src0_r, src1_r, tmp0, tmp1, wgt, denom, offset;
 
-out0 = (v8u16) __msa_srl_h(temp0, denom);
-out1 = (v8u16) __msa_srl_h(temp1, denom);
+offset_val = (unsigned) offset_in << log2_denom;
 
-SAT_UH2_UH(out0, out1, 7);
-PCKEV_B2_SW(out0, out0, out1, out1, res0, res1);
+wgt = __msa_fill_h(src_weight);
+offset = __msa_fill_h(offset_val);
+denom = __msa_fill_h(log2_denom);
 
-data0 = __msa_copy_u_w(res0, 0);
-data1 = __msa_copy_u_w(res1, 0);
-SW(data0, data);
-data += stride;
-SW(data1, data);
+LW4(data, stride, tp0, tp1, tp2, tp3);
+INSERT_W4_UB(tp0, tp1, tp2, tp3, src0);
+UNPCK_UB_SH(src0, src0_r, src1_r);
+MUL2(wgt, src0_r, wgt, src1_r, tmp0, tmp1);
+ADDS_SH2_SH(tmp0, offset, tmp1, offset, tmp0, tmp1);
+MAXI_SH2_SH(tmp0, tmp1, 0);
+tmp0 = __msa_srlr_h(tmp0, denom);
+tmp1 = __msa_srlr_h(tmp1, denom);
+SAT_UH2_SH(tmp0, tmp1, 7);
+src0 = (v16u8) __msa_pckev_b((v16i8) tmp1, (v16i8) tmp0);
+ST4x4_UB(src0, src0, 0, 1, 2, 3, data, stride);
 }
 
-static void avc_wgt_4x4multiple_msa(uint8_t *data, int32_t stride,
-int32_t height, int32_t log2_denom,
-int32_t src_weight, int32_t offset_in)
+static void avc_wgt_4x8_msa(uint8_t *data, int32_t stride, int32_t log2_denom,
+int32_t src_weight, int32_t offset_in)
 {
-uint8_t cnt;
-uint32_t data0, data1, data2, data3;
-v16u8 zero = { 0 };
-v16u8 src0, src1, src2, src3;
-v8u16 temp0, temp1, temp2, temp3, wgt;
-v8i16 denom, offset;
+uint32_t tp0, tp1, tp2, tp3, offset_val;
+v16u8 src0 = { 0 }, src1 = { 0 };
+v8i16 src0_r, src1_r, src2_r, src3_r, tmp0, tmp1, tmp2, tmp3;
+v8i16 wgt, denom, offset;
 
-offset_in <<= (log2_denom);
+offset_val = (unsigned) offset_in << log2_denom;
 
-if (log2_denom) {
-offset_in += (1 << (log2_denom - 1));
-}
-
-wgt = (v8u16) __msa_fill_h(src_weight);
-offset = __msa_fill_h(offset_in);
+wgt = __msa_fill_h(src_weight);
+offset = __msa_fill_h(offset_val);
 denom = __msa_fill_h(log2_denom);
 
-for (cnt = height / 4; cnt--;) {
-LW4(data, stride, data0, data1, data2, data3);
-
-src0 = (v16u8) __msa_fill_w(data0);
-src1 = (v16u8) __msa_fill_w(data1);
-src2 = (v16u8) __msa_fill_w(data2);
-src3 = (

Re: [FFmpeg-devel] [PATCH 3/9] avcodec/videotoolbox: h264 decoder on iOS is unable to decode interlaced video

2017-09-26 Thread Carl Eugen Hoyos
2017-09-26 2:36 GMT+02:00 Aman Gupta :

> +   case kCMVideoCodecType_H264 : {
> +  H264Context *h = avctx->priv_data;
> +  if (TARGET_OS_IPHONE && h->ps.sps->frame_mbs_only_flag == 0) {

I believe that for DVB 1080 transmissions the flag is
never set even for progressive frames, so this has
to be conditional depending on a new user option.
Imo, the default should be not to abort but others may
disagree.

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


[FFmpeg-devel] [PATCH 0/2] lavf: fixes for older GnuTLS

2017-09-26 Thread Moritz Barsnick
This series adds a fix for a regression for building with older GnuTLS
[1/2] and a silencing of warnings for ancient GnuTLS [2/2].

Moritz Barsnick (2):
  lavf/tls_gnutls: fix compilation with GnuTLS 2.x
  lavf/tls_gnutls: fix warnings from version check

 libavformat/tls_gnutls.c | 6 ++
 1 file changed, 6 insertions(+)

-- 
2.9.5

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


Re: [FFmpeg-devel] [PATCH 9/9] avcodec/videotoolbox: create avcC even when h264 extradata is missing

2017-09-26 Thread Carl Eugen Hoyos
2017-09-26 2:36 GMT+02:00 Aman Gupta :

> Removes the avctx->extradata_size requirement when
> creating avcC, since avctx->extradata is only used in the
> esds code path.

Please split the patch in a functional and a cosmetic change.

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


Re: [FFmpeg-devel] [PATCH] lavu/file: fix build on Android NDK with unified headers

2017-09-26 Thread Carl Eugen Hoyos
2017-09-26 3:52 GMT+02:00 Rodger Combs :

> +#  if defined(__USE_FILE_OFFSET64) && __ANDROID_API__ < 21 && 
> !defined(__LP64__)
> +#   ifdef mmap
> +#undef mmap
> +#   endif
> +void* mmap(void*, size_t, int, int, int, __kernel_off_t);

How can this issue be reproduced?

Shouldn't this be checked in configure?

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


[FFmpeg-devel] [PATCH 2/2] lavf/tls_gnutls: fix warnings from version check

2017-09-26 Thread Moritz Barsnick
The GnuTLS version is checked through the macro GNUTLS_VERSION_NUMBER,
but this wasn't introduced before 2.7.2. Building with older versions
of GnuTLS (using icc) warns:

src/libavformat/tls_gnutls.c(38): warning #193: zero used for undefined 
preprocessing identifier "GNUTLS_VERSION_NUMBER"
  #if HAVE_THREADS && GNUTLS_VERSION_NUMBER <= 0x020b00

This adds a fallback to the older, deprecated LIBGNUTLS_VERSION_NUMBER
macro.

Signed-off-by: Moritz Barsnick 
---
 libavformat/tls_gnutls.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
index 7174dfd..5ce6c3d 100644
--- a/libavformat/tls_gnutls.c
+++ b/libavformat/tls_gnutls.c
@@ -35,6 +35,10 @@
 #include "libavutil/opt.h"
 #include "libavutil/parseutils.h"
 
+#ifndef GNUTLS_VERSION_NUMBER
+#define GNUTLS_VERSION_NUMBER LIBGNUTLS_VERSION_NUMBER
+#endif
+
 #if HAVE_THREADS && GNUTLS_VERSION_NUMBER <= 0x020b00
 #include 
 #include "libavutil/thread.h"
-- 
2.9.5

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


[FFmpeg-devel] [PATCH 1/2] lavf/tls_gnutls: fix compilation with GnuTLS 2.x

2017-09-26 Thread Moritz Barsnick
Commit 598e41684066feba701d19ca7443d24b9e5efa77 added use of
GNUTLS_E_PREMATURE_TERMINATION, which wasn't introduced to GnuTLS
before 2.99.x / 3.x. This fixes compilation with older versions.

Signed-off-by: Moritz Barsnick 
---
 libavformat/tls_gnutls.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
index 38f8ea4..7174dfd 100644
--- a/libavformat/tls_gnutls.c
+++ b/libavformat/tls_gnutls.c
@@ -72,7 +72,9 @@ static int print_tls_error(URLContext *h, int ret)
 switch (ret) {
 case GNUTLS_E_AGAIN:
 case GNUTLS_E_INTERRUPTED:
+#ifdef GNUTLS_E_PREMATURE_TERMINATION
 case GNUTLS_E_PREMATURE_TERMINATION:
+#endif
 break;
 case GNUTLS_E_WARNING_ALERT_RECEIVED:
 av_log(h, AV_LOG_WARNING, "%s\n", gnutls_strerror(ret));
-- 
2.9.5

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


Re: [FFmpeg-devel] [PATCH] swscale_unscaled: fix DITHER_COPY macro, use it only for dst_depth == 8

2017-09-26 Thread Carl Eugen Hoyos
2017-09-26 1:33 GMT+02:00 Mateusz :

> I've sent C code patch 2017-09-06 (and nothing) so I thought that the
> problem is with speed. For simplicity I've attached this patch.

You could (wait a day or two and) either add an option to
select your dithering code or put it under #ifdef so more
people can test it.

[...]

> In theory it is enough to make only dst = (src + dither)>>shift;
> -- white in limited range has 0 on bits to remove (235*4 for example)
> so overflow is impossible. For files with full range not marked as
> full range overflow is possible (for dither > 0) and white goes
> to black. tmp - (tmp>>dst_depth) undoing this overflow.

(Not necessarily related, sorry if I misunderstand:)
Valid limited-range frames can contain some pixels with peak
values outside of the defined range.

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


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

2017-09-26 Thread Manojkumar Bhosale
LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Tuesday, September 26, 2017 1:20 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc put mc 20, 01 and 03 
msa functions

From: Kaustubh Raste 

Remove loops and unroll as block sizes are known.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/h264qpel_msa.c |  441 +++-
 1 file changed, 432 insertions(+), 9 deletions(-)

diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec/mips/h264qpel_msa.c 
index b7f6c3d..0b42bc4 100644
--- a/libavcodec/mips/h264qpel_msa.c
+++ b/libavcodec/mips/h264qpel_msa.c
@@ -148,6 +148,17 @@ static const uint8_t luma_mask_arr[16 * 8] = {
 hz_out_m;\
 } )
 
+#define AVC_DOT_SH3_SH(in0, in1, in2, coeff0, coeff1, coeff2)   \
+( { \
+v8i16 out0_m;   \
+\
+out0_m = __msa_dotp_s_h((v16i8) in0, (v16i8) coeff0);   \
+out0_m = __msa_dpadd_s_h(out0_m, (v16i8) in1, (v16i8) coeff1);  \
+out0_m = __msa_dpadd_s_h(out0_m, (v16i8) in2, (v16i8) coeff2);  \
+\
+out0_m; \
+} )
+
 static void avc_luma_hz_4w_msa(const uint8_t *src, int32_t src_stride,
uint8_t *dst, int32_t dst_stride,
int32_t height) @@ -3373,55 +3384,467 @@ void 
ff_put_h264_qpel4_mc30_msa(uint8_t *dst, const uint8_t *src,  void 
ff_put_h264_qpel16_mc20_msa(uint8_t *dst, const uint8_t *src,
  ptrdiff_t stride)  {
-avc_luma_hz_16w_msa(src - 2, stride, dst, stride, 16);
+uint32_t loop_cnt;
+v16i8 src0, src1, src2, src3, src4, src5, src6, src7, mask0, mask1, mask2;
+v16i8 vec0, vec1, vec2, vec3, vec4, vec5, vec6, vec7, vec8, vec9, vec10;
+v16i8 vec11;
+v8i16 res0, res1, res2, res3, res4, res5, res6, res7;
+v16i8 minus5b = __msa_ldi_b(-5);
+v16i8 plus20b = __msa_ldi_b(20);
+
+LD_SB3(&luma_mask_arr[0], 16, mask0, mask1, mask2);
+src -= 2;
+
+for (loop_cnt = 4; loop_cnt--;) {
+LD_SB2(src, 8, src0, src1);
+src += stride;
+LD_SB2(src, 8, src2, src3);
+src += stride;
+LD_SB2(src, 8, src4, src5);
+src += stride;
+LD_SB2(src, 8, src6, src7);
+src += stride;
+
+XORI_B8_128_SB(src0, src1, src2, src3, src4, src5, src6, src7);
+VSHF_B2_SB(src0, src0, src1, src1, mask0, mask0, vec0, vec3);
+VSHF_B2_SB(src2, src2, src3, src3, mask0, mask0, vec6, vec9);
+VSHF_B2_SB(src0, src0, src1, src1, mask1, mask1, vec1, vec4);
+VSHF_B2_SB(src2, src2, src3, src3, mask1, mask1, vec7, vec10);
+VSHF_B2_SB(src0, src0, src1, src1, mask2, mask2, vec2, vec5);
+VSHF_B2_SB(src2, src2, src3, src3, mask2, mask2, vec8, vec11);
+HADD_SB4_SH(vec0, vec3, vec6, vec9, res0, res1, res2, res3);
+DPADD_SB4_SH(vec1, vec4, vec7, vec10, minus5b, minus5b, minus5b,
+ minus5b, res0, res1, res2, res3);
+DPADD_SB4_SH(vec2, vec5, vec8, vec11, plus20b, plus20b, plus20b,
+ plus20b, res0, res1, res2, res3);
+VSHF_B2_SB(src4, src4, src5, src5, mask0, mask0, vec0, vec3);
+VSHF_B2_SB(src6, src6, src7, src7, mask0, mask0, vec6, vec9);
+VSHF_B2_SB(src4, src4, src5, src5, mask1, mask1, vec1, vec4);
+VSHF_B2_SB(src6, src6, src7, src7, mask1, mask1, vec7, vec10);
+VSHF_B2_SB(src4, src4, src5, src5, mask2, mask2, vec2, vec5);
+VSHF_B2_SB(src6, src6, src7, src7, mask2, mask2, vec8, vec11);
+HADD_SB4_SH(vec0, vec3, vec6, vec9, res4, res5, res6, res7);
+DPADD_SB4_SH(vec1, vec4, vec7, vec10, minus5b, minus5b, minus5b,
+ minus5b, res4, res5, res6, res7);
+DPADD_SB4_SH(vec2, vec5, vec8, vec11, plus20b, plus20b, plus20b,
+ plus20b, res4, res5, res6, res7);
+SRARI_H4_SH(res0, res1, res2, res3, 5);
+SRARI_H4_SH(res4, res5, res6, res7, 5);
+SAT_SH4_SH(res0, res1, res2, res3, 7);
+SAT_SH4_SH(res4, res5, res6, res7, 7);
+PCKEV_B4_SB(res1, res0, res3, res2, res5, res4, res7, res6, vec0, vec1,
+vec2, vec3);
+XORI_B4_128_SB(vec0, vec1, vec2, vec3);
+ST_SB4(vec0, vec1, vec2, vec3, dst, stride);
+dst += (4 * stride);
+}
 }
 
 void ff_put_h264_qpel8_mc20_msa(uint8_t *dst, const uint8_t *src,
 ptrdiff_t stride)  {
-avc_luma_hz_8w_msa(src - 2, stride, dst, stride, 8);
+v16u8 out0, out1, out2, out3;
+v16i8 src0, src1, src2, src3, src4, sr

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: fix decoding of some h264 bitstreams

2017-09-26 Thread wm4
On Mon, 25 Sep 2017 11:49:51 -0700
Aman Gupta  wrote:

> On Mon, Sep 25, 2017 at 3:06 AM, wm4  wrote:
> 
> > On Mon, 25 Sep 2017 09:02:36 +0200
> > Hendrik Leppkes  wrote:
> >  
> > > On Mon, Sep 25, 2017 at 3:31 AM, Aman Gupta  wrote:  
> > > >
> > > > How do the other hwaccels handle mid-stream SPS changes?
> > > >  
> > >
> > > Real HWAccels (ie. VAAPI, VDPAU or DXVA) communicate the SPS/PPS
> > > content for every frame, they don't keep a persistent state internally
> > > - that way the only "state" is the frame size and pixel format, and
> > > when those change get_format is called and the hwaccel re-initialized.  
> >
> > Maybe it would be better if VT detected SPS/PPS changes itself, and
> > reinitialized the VT session on demand when feeding slices. This way we
> > wouldn't have to mess with the normal h264 software decoder reinit
> > logic.
> >  
> 
> Agreed. I'm trying to figure out the most efficient way to detect when the
> SPS/PPS changes.
> 
> Previously I tried feeding in the SPS/PPS NALs from the decoder into the VT
> hwaccel (with a new `decode_params` callback), and using that to store a
> copy of the NAL in the hwaccel. I used a memcmp() against the previously
> stored value to detect when changes occurred and restarted the
> decompression session according. This approach worked well, but doesn't
> handle some streams which use multiple PPS.
> 
> The most fool-proof way would be to construct a new avcC every time and
> only restart the session when it changes. But that seems quite expensive to
> be doing all the time.
> 
> I'm also still not sure if the VT decoder needs to be restarted on SPS
> changes only, or PPS as well. Do new PPS usually accompany a new SPS? Is it
> also possible to have multiple SPS used at the same time? (The avcC
> construction code in videotoolbox.c assumes one SPS and one or more PPS).

I don't think it's too expensive. Keep in mind that we copy around the
actual slices 2 times as well, and the cost of rebuilding the avcc is
probably the smallest part, and the memcmp would barely matter.

Also I think what matters is whether VT sees the SPS/PPS slices at all.
Didn't you have success with feeding them as part of the sample buffer
(along with slice NALs)? I wonder if VT would be fine with the SPS and
PPS repeated for every slice.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] videotoolbox: log errors

2017-09-26 Thread wm4
On Mon, 25 Sep 2017 16:14:08 -0700
Aman Gupta  wrote:

> On Wed, May 24, 2017 at 6:47 AM, wm4  wrote:
> 
> > With the new decode API, you can't handle errors directly in the API
> > user - you only know that the hwaccel did not initialize at all.
> >
> > Add some approximate logging.
> > ---
> >  libavcodec/videotoolbox.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> > index d36a33efcd..85cd2215c9 100644
> > --- a/libavcodec/videotoolbox.c
> > +++ b/libavcodec/videotoolbox.c
> > @@ -648,15 +648,21 @@ static int videotoolbox_default_init(AVCodecContext
> > *avctx)
> >
> >  switch (status) {
> >  case kVTVideoDecoderNotAvailableNowErr:
> > +av_log(avctx, AV_LOG_VERBOSE, "VideoToolbox session not
> > available.\n");
> > +return AVERROR(ENOSYS);
> >  case kVTVideoDecoderUnsupportedDataFormatErr:
> > +av_log(avctx, AV_LOG_VERBOSE, "VideoToolbox does not support this
> > format.\n");
> >  return AVERROR(ENOSYS);
> >  case kVTVideoDecoderMalfunctionErr:
> > +av_log(avctx, AV_LOG_VERBOSE, "VideoToolbox malfunction.\n");
> >  return AVERROR(EINVAL);
> >  case kVTVideoDecoderBadDataErr :
> > +av_log(avctx, AV_LOG_VERBOSE, "VideoToolbox reported invalid
> > data.\n");
> >  return AVERROR_INVALIDDATA;
> >  case 0:
> >  return 0;
> >  default:
> > +av_log(avctx, "Unknown VideoToolbox session creation error %u\n",
> > (unsigned)status);
> >  
> 
> Is OSStatus really unsigned? When I've encountered VT errors in the past
> they've usually been negative integers.

Don't know. Aren't they usually fourccs? In any case it should be good
enough to reconstruct the original error code from logs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2 3/3] ffprobe: add support for logging gamma side data

2017-09-26 Thread wm4
On Mon, 25 Sep 2017 16:44:45 -0300
James Almer  wrote:

> On 9/25/2017 4:28 PM, Rostislav Pehlivanov wrote:
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  ffprobe.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/ffprobe.c b/ffprobe.c
> > index b2e8949d9f..171f856c2d 100644
> > --- a/ffprobe.c
> > +++ b/ffprobe.c
> > @@ -2227,6 +2227,9 @@ static void show_frame(WriterContext *w, AVFrame 
> > *frame, AVStream *stream,
> >  if (tag)
> >  print_str(tag->key, tag->value);
> >  print_int("size", sd->size);
> > +} else if (sd->type == AV_FRAME_DATA_GAMMA) {  
> 
> Check that sd->size >= sizeof(AVRational) as well.

It's guaranteed to be that size.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2 1/3] lavu: add an AV_FRAME_DATA_GAMMA side data type

2017-09-26 Thread wm4
On Mon, 25 Sep 2017 20:28:07 +0100
Rostislav Pehlivanov  wrote:

> 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 d06144f1e9..427d7e5613 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2015-08-28
>  
>  API changes, most recent first:
>  
> +2017-09-24 - xxx - lavu 55.77.199 - frame.h
> +Add AV_FRAME_DATA_GAMMA side data type.
> +
>  2017-xx-xx - xxx - lavu 55.76.100 / 56.6.0 - pixdesc.h
>Add av_color_range_from_name(), av_color_primaries_from_name(),
>av_color_transfer_from_name(), av_color_space_from_name(), and
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 013043c250..e44ba18105 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,

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


Re: [FFmpeg-devel] [PATCH 5/9] avcodec/videotoolbox: print descriptive errors on decode failures

2017-09-26 Thread wm4
On Mon, 25 Sep 2017 17:36:27 -0700
Aman Gupta  wrote:

> From: Aman Gupta 
> 
> ---
>  libavcodec/videotoolbox.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 1de556f3e8..f56ab1f8c9 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -425,7 +425,22 @@ static int videotoolbox_common_end_frame(AVCodecContext 
> *avctx, AVFrame *frame)
>  status = videotoolbox_session_decode_frame(avctx);
>  
>  if (status) {
> -av_log(avctx, AV_LOG_ERROR, "Failed to decode frame (%d)\n", status);
> +const char *error = NULL;
> +switch (status) {
> +case kVTVideoDecoderBadDataErr:
> +error = "bad data";
> +break;
> +case kVTVideoDecoderMalfunctionErr:
> +error = "decoder malfunction";
> +break;
> +case kVTInvalidSessionErr:
> +error = "invalid session";
> +break;
> +default:
> +error = "unknown";
> +break;
> +}
> +av_log(avctx, AV_LOG_ERROR, "Failed to decode frame (%s, %d)\n", 
> error, status);
>  return AVERROR_UNKNOWN;
>  }
>  

Is status really an int? If not, it should be casted (the safest way to
deal with "opaque" typedefs).

Bonus points for moving the error status->string switch mapping to a
separate function.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 8/9] avcodec/videotoolbox: use decode_params to propagate PPS changes and restart on SPS changes

2017-09-26 Thread wm4
On Mon, 25 Sep 2017 17:36:30 -0700
Aman Gupta  wrote:

> From: Aman Gupta 
> 
> If the VideoToolbox session needs to be restarted, and
> videotoolbox_start() fails for some reason (for instance, if the video
> is interlaced and the decoder is running on iOS), avcodec will return
> AVERROR_EXTERNAL. This can be used by the API user to switch to another
> decoder.
> ---
>  libavcodec/vda_vt_internal.h |  6 ++
>  libavcodec/videotoolbox.c| 45 
> +++-
>  2 files changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vda_vt_internal.h b/libavcodec/vda_vt_internal.h
> index e55a813899..49c91791ee 100644
> --- a/libavcodec/vda_vt_internal.h
> +++ b/libavcodec/vda_vt_internal.h
> @@ -47,6 +47,12 @@ typedef struct VTContext {
>  // Non-NULL if the new hwaccel API is used. This is only a separate 
> struct
>  // to ease compatibility with the old API.
>  struct AVVideotoolboxContext *vt_ctx;
> +
> +// Current H264 parameters (used to trigger decoder restart on SPS 
> changes).
> +uint8_t *sps;
> +uint32_tsps_len;
> +unsigned intsps_capa;
> +boolreconfig_needed;
>  } VTContext;
>  
>  int ff_videotoolbox_alloc_frame(AVCodecContext *avctx, AVFrame *frame);
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index f56ab1f8c9..6c8477c2ce 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -41,6 +41,9 @@
>  
>  #define VIDEOTOOLBOX_ESDS_EXTRADATA_PADDING  12
>  
> +static void videotoolbox_stop(AVCodecContext *avctx);
> +static int videotoolbox_start(AVCodecContext *avctx);
> +
>  static void videotoolbox_buffer_release(void *opaque, uint8_t *data)
>  {
>  CVPixelBufferRef cv_buffer = (CVImageBufferRef)data;
> @@ -148,6 +151,33 @@ int ff_videotoolbox_h264_start_frame(AVCodecContext 
> *avctx,
>  return 0;
>  }
>  
> +static int videotoolbox_h264_decode_params(AVCodecContext *avctx,
> +   const uint8_t *buffer,
> +   uint32_t size)
> +{
> +VTContext *vtctx = avctx->internal->hwaccel_priv_data;
> +H264Context *h  = avctx->priv_data;
> +
> +if (h->is_avc == 1)
> +return 0;

Should that matter?

> +switch (buffer[0] & 0x1f) {
> +case H264_NAL_SPS:
> +if (!vtctx->sps || vtctx->sps_len != size || memcmp(buffer, 
> vtctx->sps, size) != 0) {
> +vtctx->sps = av_fast_realloc(vtctx->sps, &vtctx->sps_capa, 
> size);
> +if (vtctx->sps)
> +memcpy(vtctx->sps, buffer, size);
> +if (vtctx->sps_len)
> +vtctx->reconfig_needed = true;
> +vtctx->sps_len = size;
> +}
> +break;
> +}

To be honest, I think just rebuilding the avcc and testing for a change
would be simpler. Unless there's a good reason not to reinit when only
the PPS changes.

Might also make sense to pass the NAL type as parameter to the
AVHWAccel function?

Otherwise I'm fine with it.

> +// pass-through new PPS to the decoder
> +return ff_videotoolbox_h264_decode_slice(avctx, buffer, size);
> +}
> +
>  int ff_videotoolbox_h264_decode_slice(AVCodecContext *avctx,
>const uint8_t *buffer,
>uint32_t size)
> @@ -180,6 +210,7 @@ int ff_videotoolbox_uninit(AVCodecContext *avctx)
>  VTContext *vtctx = avctx->internal->hwaccel_priv_data;
>  if (vtctx) {
>  av_freep(&vtctx->bitstream);
> +av_freep(&vtctx->sps);
>  if (vtctx->frame)
>  CVPixelBufferRelease(vtctx->frame);
>  }
> @@ -419,7 +450,16 @@ static int videotoolbox_common_end_frame(AVCodecContext 
> *avctx, AVFrame *frame)
>  AVVideotoolboxContext *videotoolbox = videotoolbox_get_context(avctx);
>  VTContext *vtctx = avctx->internal->hwaccel_priv_data;
>  
> -if (!videotoolbox->session || !vtctx->bitstream)
> +if (vtctx->reconfig_needed == true) {
> +vtctx->reconfig_needed = false;
> +av_log(avctx, AV_LOG_VERBOSE, "VideoToolbox decoder needs reconfig, 
> restarting..\n");
> +videotoolbox_stop(avctx);
> +if (videotoolbox_start(avctx) != 0) {
> +return AVERROR_EXTERNAL;
> +}
> +}
> +
> +if (!videotoolbox->session || !vtctx->bitstream || 
> !vtctx->bitstream_size)
>  return AVERROR_INVALIDDATA;
>  
>  status = videotoolbox_session_decode_frame(avctx);
> @@ -432,9 +472,11 @@ static int videotoolbox_common_end_frame(AVCodecContext 
> *avctx, AVFrame *frame)
>  break;
>  case kVTVideoDecoderMalfunctionErr:
>  error = "decoder malfunction";
> +vtctx->reconfig_needed = true;
>  break;
>  case kVTInvalidSessionErr:
>  error = "invalid sessi

Re: [FFmpeg-devel] [PATCH 9/9] avcodec/videotoolbox: create avcC even when h264 extradata is missing

2017-09-26 Thread wm4
On Mon, 25 Sep 2017 17:36:31 -0700
Aman Gupta  wrote:

> From: Aman Gupta 
> 
> Removes the avctx->extradata_size requirement when creating avcC, since
> avctx->extradata is only used in the esds code path.
> 
> This fixes an issue where the VideoToolbox decoder would not work unless
> avformat_find_stream_info() was called.
> ---
>  libavcodec/videotoolbox.c | 65 
> +++
>  1 file changed, 32 insertions(+), 33 deletions(-)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 6c8477c2ce..de51b9a7c4 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -538,46 +538,45 @@ static CFDictionaryRef 
> videotoolbox_decoder_config_create(CMVideoCodecType codec
>   
> kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder,
>   kCFBooleanTrue);
>  
> -if (avctx->extradata_size) {
> -CFMutableDictionaryRef avc_info;
> -CFDataRef data = NULL;
> +CFMutableDictionaryRef avc_info;
> +CFDataRef data = NULL;
>  
> -avc_info = CFDictionaryCreateMutable(kCFAllocatorDefault,
> - 1,
> - &kCFTypeDictionaryKeyCallBacks,
> - 
> &kCFTypeDictionaryValueCallBacks);
> +avc_info = CFDictionaryCreateMutable(kCFAllocatorDefault,
> + 1,
> + &kCFTypeDictionaryKeyCallBacks,
> + &kCFTypeDictionaryValueCallBacks);
>  
> -switch (codec_type) {
> -case kCMVideoCodecType_MPEG4Video :
> +switch (codec_type) {
> +case kCMVideoCodecType_MPEG4Video:
> +if (avctx->extradata_size)
>  data = videotoolbox_esds_extradata_create(avctx);
> -if (data)
> -CFDictionarySetValue(avc_info, CFSTR("esds"), data);
> -break;
> -case kCMVideoCodecType_H264 : {
> -H264Context *h = avctx->priv_data;
> -if (TARGET_OS_IPHONE && h->ps.sps->frame_mbs_only_flag == 0) {
> -av_log(avctx, AV_LOG_ERROR, "VideoToolbox cannot decode 
> interlaced fields on iOS\n");
> -CFRelease(avc_info);
> -goto fail;
> -}
> -data = ff_videotoolbox_avcc_extradata_create(avctx);
> -if (data)
> -CFDictionarySetValue(avc_info, CFSTR("avcC"), data);
> -break;
> -}
> -default:
> -break;
> +if (data)
> +CFDictionarySetValue(avc_info, CFSTR("esds"), data);
> +break;
> +case kCMVideoCodecType_H264: {
> +H264Context *h = avctx->priv_data;
> +if (TARGET_OS_IPHONE && h->ps.sps->frame_mbs_only_flag == 0) {
> +av_log(avctx, AV_LOG_ERROR, "VideoToolbox cannot decode 
> interlaced fields on iOS\n");
> +CFRelease(avc_info);
> +goto fail;
>  }
> +data = ff_videotoolbox_avcc_extradata_create(avctx);
> +if (data)
> +CFDictionarySetValue(avc_info, CFSTR("avcC"), data);
> +break;
> +}
> +default:
> +break;
> +}
>  
> -CFDictionarySetValue(config_info,
> -
> kCMFormatDescriptionExtension_SampleDescriptionExtensionAtoms,
> -avc_info);
> +CFDictionarySetValue(config_info,
> +kCMFormatDescriptionExtension_SampleDescriptionExtensionAtoms,
> +avc_info);
>  
> -if (data)
> -CFRelease(data);
> +if (data)
> +CFRelease(data);
>  
> -CFRelease(avc_info);
> -}
> +CFRelease(avc_info);
>  return config_info;
>  
>  fail:

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


Re: [FFmpeg-devel] [PATCH 0/2] lavf: fixes for older GnuTLS

2017-09-26 Thread Carl Eugen Hoyos
2017-09-26 13:25 GMT+02:00 Moritz Barsnick :
> This series adds a fix for a regression for building with older GnuTLS
> [1/2] and a silencing of warnings for ancient GnuTLS [2/2].

Patchset applied.

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


Re: [FFmpeg-devel] [PATCH] avformat/libopenmpt: Query duration and metadata after selecting subsong

2017-09-26 Thread Josh de Kock

On 24/09/2017 15:35, Jörn Heusipp wrote:


On 09/17/2017 03:35 PM, Jörn Heusipp wrote:

Duration depends on the selected subsong and thus must be queried after
selecting the subsong. There is no compelling reason to query other
metadata earlier either.

Signed-off-by: Jörn Heusipp 
---


ping?


This looks fine I've tested with latest libopenmpt. Pushed.

Thanks,

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


Re: [FFmpeg-devel] [PATCH v2 3/3] ffprobe: add support for logging gamma side data

2017-09-26 Thread James Almer
On 9/26/2017 9:14 AM, wm4 wrote:
> On Mon, 25 Sep 2017 16:44:45 -0300
> James Almer  wrote:
> 
>> On 9/25/2017 4:28 PM, Rostislav Pehlivanov wrote:
>>> Signed-off-by: Rostislav Pehlivanov 
>>> ---
>>>  ffprobe.c | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/ffprobe.c b/ffprobe.c
>>> index b2e8949d9f..171f856c2d 100644
>>> --- a/ffprobe.c
>>> +++ b/ffprobe.c
>>> @@ -2227,6 +2227,9 @@ static void show_frame(WriterContext *w, AVFrame 
>>> *frame, AVStream *stream,
>>>  if (tag)
>>>  print_str(tag->key, tag->value);
>>>  print_int("size", sd->size);
>>> +} else if (sd->type == AV_FRAME_DATA_GAMMA) {  
>>
>> Check that sd->size >= sizeof(AVRational) as well.
> 
> It's guaranteed to be that size.

Other side data types without a related struct check for size. See gop
timecode, expecting an int64_t, and display matrix, expecting 9 int32_t.
Maybe those should also be removed if that's indeed the case.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2 3/3] ffprobe: add support for logging gamma side data

2017-09-26 Thread wm4
On Tue, 26 Sep 2017 11:12:41 -0300
James Almer  wrote:

> On 9/26/2017 9:14 AM, wm4 wrote:
> > On Mon, 25 Sep 2017 16:44:45 -0300
> > James Almer  wrote:
> >   
> >> On 9/25/2017 4:28 PM, Rostislav Pehlivanov wrote:  
> >>> Signed-off-by: Rostislav Pehlivanov 
> >>> ---
> >>>  ffprobe.c | 3 +++
> >>>  1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/ffprobe.c b/ffprobe.c
> >>> index b2e8949d9f..171f856c2d 100644
> >>> --- a/ffprobe.c
> >>> +++ b/ffprobe.c
> >>> @@ -2227,6 +2227,9 @@ static void show_frame(WriterContext *w, AVFrame 
> >>> *frame, AVStream *stream,
> >>>  if (tag)
> >>>  print_str(tag->key, tag->value);
> >>>  print_int("size", sd->size);
> >>> +} else if (sd->type == AV_FRAME_DATA_GAMMA) {
> >>
> >> Check that sd->size >= sizeof(AVRational) as well.  
> > 
> > It's guaranteed to be that size.  
> 
> Other side data types without a related struct check for size. See gop
> timecode, expecting an int64_t, and display matrix, expecting 9 int32_t.
> Maybe those should also be removed if that's indeed the case.

Maybe that should wait until side data merging is fully removed (which
could cause this), to avoid creating yet another pointless discussion.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2 3/3] ffprobe: add support for logging gamma side data

2017-09-26 Thread James Almer
On 9/26/2017 11:23 AM, wm4 wrote:
> On Tue, 26 Sep 2017 11:12:41 -0300
> James Almer  wrote:
> 
>> On 9/26/2017 9:14 AM, wm4 wrote:
>>> On Mon, 25 Sep 2017 16:44:45 -0300
>>> James Almer  wrote:
>>>   
 On 9/25/2017 4:28 PM, Rostislav Pehlivanov wrote:  
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  ffprobe.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/ffprobe.c b/ffprobe.c
> index b2e8949d9f..171f856c2d 100644
> --- a/ffprobe.c
> +++ b/ffprobe.c
> @@ -2227,6 +2227,9 @@ static void show_frame(WriterContext *w, AVFrame 
> *frame, AVStream *stream,
>  if (tag)
>  print_str(tag->key, tag->value);
>  print_int("size", sd->size);
> +} else if (sd->type == AV_FRAME_DATA_GAMMA) {

 Check that sd->size >= sizeof(AVRational) as well.  
>>>
>>> It's guaranteed to be that size.  
>>
>> Other side data types without a related struct check for size. See gop
>> timecode, expecting an int64_t, and display matrix, expecting 9 int32_t.
>> Maybe those should also be removed if that's indeed the case.
> 
> Maybe that should wait until side data merging is fully removed (which
> could cause this), to avoid creating yet another pointless discussion.

Side data merging is only for packet side data it seems, so no issues in
that regard.

In any case, it hardly a problem, so nevermind.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Frame CRC muxer

2017-09-26 Thread Bjorn Roche
On Mon, Sep 25, 2017 at 3:12 PM, James Almer  wrote:

> On 9/25/2017 3:49 PM, Bjorn Roche wrote:
> > Hi there,
> >
> > I have a patch for this issue:
> >
> > https://trac.ffmpeg.org/ticket/4443
> >
> > However, when running the automated ("fate") tests, I get the error
> pasted
> > below. I'm not sure what's going on since the output formats look
> different
> > when running a the test vs when I run the same command with my built-in
> > FFmpeg. e.g.:
> >
> > my compiled ffmpeg:
> >
> > 0,  2,  2,1,  438, 0x4776d352, S=1, 1024,
> > 0xcfc8799f
> >
> >
> > built-in ffmpeg:
> >
> >
> > 0,  2,  2,1,  438, 0x4776d352, S=2,1,
> > 0x00010001, 1024, 0xcfc8799f
> >
> >
> > Neither format looks like this:
> > https://ffmpeg.org/ffmpeg-formats.html#framecrc-1. (I don't know what
> the
> > S=X. means, so I am not sure what it's telling me has changed, if
> > anything.)
>
> The S stands for side data, and the X is the amount of side data
> elements embedded in the packet. Values after that are size and crc
> checksum of each side data element.
>

Ah, excellent, that makes sense. Thanks for your response!

bjorn

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


Re: [FFmpeg-devel] Frame CRC muxer

2017-09-26 Thread Bjorn Roche
On Mon, Sep 25, 2017 at 4:03 PM, Carl Eugen Hoyos 
wrote:

> 2017-09-25 20:49 GMT+02:00 Bjorn Roche :
>
> > In the meantime, I've attached the patch if anyone wants to look at it.
>
> Can you explain why you had to patch the gif encoder?
> I thought it is able to encode transparency, no?


Sure, and thanks for taking a look at it!

Unfortunately, while the gif encoder does support transparency, it only
works correctly for a single frame. After that, it produces incorrect
results because the pixels from the previous frame "show through"
transparent pixels instead of being replaced.

This is because the encoder preserves transparency from the incoming frame
to the saved image, which works fine in some cases, such as in the first
(or only) frame or if the disposal method supports it, but the disposal
method the muxer was using did not support it.

The solution I came up with was to have the codec signal the muxer using
the side data about which disposal method it should use. That way, it can
use the best optimization for the situation, but still support transparency.

An alternative would be to move the code that writes the disposal method
from the muxer to the codec, which, IMO is where it belongs, but when I
started to do that it looked like many changes were required to make that
work.

bjorn


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


[FFmpeg-devel] [PATCH 0/4] avdevice/decklink: 10-bit video out and sources/sinks support

2017-09-26 Thread Devin Heitmueller
Hello all,

Below please find several patches which fix a couple of bugs as well
as adding support for 10-bit video on output and the "-sources" and
"-sinks" argument when specified by ffmpeg.c.

If you have any question/concerns, please don't hesitate to reply.

Thanks,

Devin Heitmueller

Devin Heitmueller (4):
  avdevice/decklink: Fix segfault when running -list_devices on OSX
  libavdevice/decklink: add support for -sources and -sinks arguments
  Add support for 10-bit output for Decklink SDI
  livavdevice/decklink: Don't allow any codecs but V210 and UYVY422

 libavdevice/decklink_common.cpp |  54 ++--
 libavdevice/decklink_common.h   |   2 +-
 libavdevice/decklink_dec.cpp|  22 ++-
 libavdevice/decklink_dec.h  |   1 +
 libavdevice/decklink_dec_c.c|   1 +
 libavdevice/decklink_enc.cpp| 134 
 libavdevice/decklink_enc.h  |   1 +
 libavdevice/decklink_enc_c.c|   1 +
 8 files changed, 182 insertions(+), 34 deletions(-)

-- 
2.13.2

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


[FFmpeg-devel] [PATCH 1/4] avdevice/decklink: Fix segfault when running -list_devices on OSX

2017-09-26 Thread Devin Heitmueller
The string is allocated with CFStringGetCString but was being
deallocated with free(), which would intermittently result in
a segmentation fault.  Use the correct function for freeing the
allocated CFString.

Signed-off-by: Devin Heitmueller 
---
 libavdevice/decklink_common.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index cbb591ce64..7745575d0e 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -84,7 +84,7 @@ static char *dup_cfstring_to_utf8(CFStringRef w)
 }
 #define DECKLINK_STRconst __CFString *
 #define DECKLINK_STRDUP dup_cfstring_to_utf8
-#define DECKLINK_FREE(s) free((void *) s)
+#define DECKLINK_FREE(s) CFRelease(s)
 #define DECKLINK_BOOL bool
 #else
 #define DECKLINK_STRconst char *
-- 
2.13.2

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


[FFmpeg-devel] [PATCH 4/4] livavdevice/decklink: Don't allow any codecs but V210 and UYVY422

2017-09-26 Thread Devin Heitmueller
Make sure that codecs other than V210 or wrapped avframes with
uyvy422 video are passed to decklink output (which would result
in undefined behavior).

Signed-off-by: Devin Heitmueller 
---
 libavdevice/decklink_enc.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 0d965699ec..8f08ded933 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -159,6 +159,10 @@ static int decklink_setup_video(AVFormatContext *avctx, 
AVStream *st)
" Only AV_PIX_FMT_UYVY422 is supported.\n");
 return -1;
 }
+} else if (c->codec_id != AV_CODEC_ID_V210) {
+av_log(avctx, AV_LOG_ERROR, "Unsupported codec type!"
+   " Only V210 and wrapped frame with AV_PIX_FMT_UYVY422 are 
supported.\n");
+return -1;
 }
 
 if (ff_decklink_set_format(avctx, c->width, c->height,
-- 
2.13.2

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


[FFmpeg-devel] [PATCH 2/4] libavdevice/decklink: add support for -sources and -sinks arguments

2017-09-26 Thread Devin Heitmueller
Add support for enumerating the sources/sinks via the ffmpeg
command line options, as opposed to having to create a real pipeline
and use the "-list_devices" option which does exit() after dumping
out the options.

Note that this patch preserves the existing "-list_devices" option,
but now shares common code for the actual enumeration.

Signed-off-by: Devin Heitmueller 
---
 libavdevice/decklink_common.cpp | 52 +
 libavdevice/decklink_common.h   |  2 +-
 libavdevice/decklink_dec.cpp| 22 -
 libavdevice/decklink_dec.h  |  1 +
 libavdevice/decklink_dec_c.c|  1 +
 libavdevice/decklink_enc.cpp| 22 -
 libavdevice/decklink_enc.h  |  1 +
 libavdevice/decklink_enc_c.c|  1 +
 8 files changed, 95 insertions(+), 7 deletions(-)

diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 7745575d0e..86d6fbb74b 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -37,6 +37,7 @@ extern "C" {
 #include "libavutil/imgutils.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/bswap.h"
+#include "avdevice.h"
 }
 
 #include "decklink_common.h"
@@ -261,24 +262,67 @@ int ff_decklink_set_format(AVFormatContext *avctx, 
decklink_direction_t directio
 return ff_decklink_set_format(avctx, 0, 0, 0, 0, AV_FIELD_UNKNOWN, 
direction, num);
 }
 
-int ff_decklink_list_devices(AVFormatContext *avctx)
+int ff_decklink_list_devices(AVFormatContext *avctx,
+struct AVDeviceInfoList *device_list,
+int show_inputs, int show_outputs)
 {
 IDeckLink *dl = NULL;
 IDeckLinkIterator *iter = CreateDeckLinkIteratorInstance();
+int ret = 0;
+
 if (!iter) {
 av_log(avctx, AV_LOG_ERROR, "Could not create DeckLink iterator\n");
 return AVERROR(EIO);
 }
-av_log(avctx, AV_LOG_INFO, "Blackmagic DeckLink devices:\n");
+
 while (iter->Next(&dl) == S_OK) {
+IDeckLinkOutput *output_config;
+IDeckLinkInput *input_config;
 const char *displayName;
+AVDeviceInfo *new_device = NULL;
+int add = 0;
+
 ff_decklink_get_display_name(dl, &displayName);
-av_log(avctx, AV_LOG_INFO, "\t'%s'\n", displayName);
+
+if (show_outputs) {
+if (dl->QueryInterface(IID_IDeckLinkOutput, (void 
**)&output_config) == S_OK) {
+output_config->Release();
+add = 1;
+}
+}
+
+if (show_inputs) {
+if (dl->QueryInterface(IID_IDeckLinkInput, (void **)&input_config) 
== S_OK) {
+input_config->Release();
+add = 1;
+}
+}
+
+if (add == 1) {
+new_device = (AVDeviceInfo *) av_mallocz(sizeof(AVDeviceInfo));
+if (!new_device) {
+ret = AVERROR(ENOMEM);
+goto next;
+}
+new_device->device_name = av_strdup(displayName);
+new_device->device_description = av_strdup(displayName);
+if (!new_device->device_description || !new_device->device_name) {
+ret = AVERROR(ENOMEM);
+goto next;
+}
+
+if ((ret = av_dynarray_add_nofree(&device_list->devices,
+  &device_list->nb_devices, 
new_device)) < 0) {
+goto next;
+}
+}
+
+next:
 av_free((void *) displayName);
 dl->Release();
 }
 iter->Release();
-return 0;
+return ret;
 }
 
 int ff_decklink_list_formats(AVFormatContext *avctx, decklink_direction_t 
direction)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 749eb0f8b8..f81b33ada4 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -135,7 +135,7 @@ static const BMDVideoConnection 
decklink_video_connection_map[] = {
 HRESULT ff_decklink_get_display_name(IDeckLink *This, const char 
**displayName);
 int ff_decklink_set_format(AVFormatContext *avctx, int width, int height, int 
tb_num, int tb_den, enum AVFieldOrder field_order, decklink_direction_t 
direction = DIRECTION_OUT, int num = 0);
 int ff_decklink_set_format(AVFormatContext *avctx, decklink_direction_t 
direction, int num);
-int ff_decklink_list_devices(AVFormatContext *avctx);
+int ff_decklink_list_devices(AVFormatContext *avctx, struct AVDeviceInfoList 
*device_list, int show_inputs, int show_outputs);
 int ff_decklink_list_formats(AVFormatContext *avctx, decklink_direction_t 
direction = DIRECTION_OUT);
 void ff_decklink_cleanup(AVFormatContext *avctx);
 int ff_decklink_init_device(AVFormatContext *avctx, const char* name);
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index c271ff3639..cb282055c6 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -38,6 +38,7 @@ extern "C" {
 #include "libavutil/time.h"
 #include

[FFmpeg-devel] [PATCH 3/4] Add support for 10-bit output for Decklink SDI

2017-09-26 Thread Devin Heitmueller
From: Devin Heitmueller 

Can be tested via the following command:

./ffmpeg -i foo.ts -f decklink -vcodec v210 'DeckLink Duo (1)'

Note that the 8-bit support works as it did before, and setting
the pix_fmt isn't required for 10-bit mode.  The code defaults to
operating in 8-bit mode when no vcodec is specified, for backward
compatibility.

Signed-off-by: Devin Heitmueller 
---
 libavdevice/decklink_enc.cpp | 110 ---
 1 file changed, 83 insertions(+), 27 deletions(-)

diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 0f654faa19..0d965699ec 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -44,20 +44,45 @@ extern "C" {
 class decklink_frame : public IDeckLinkVideoFrame
 {
 public:
-decklink_frame(struct decklink_ctx *ctx, AVFrame *avframe) :
-   _ctx(ctx), _avframe(avframe),  _refs(1) { }
-
-virtual long   STDMETHODCALLTYPE GetWidth  (void)  { 
return _avframe->width; }
-virtual long   STDMETHODCALLTYPE GetHeight (void)  { 
return _avframe->height; }
-virtual long   STDMETHODCALLTYPE GetRowBytes   (void)  { 
return _avframe->linesize[0] < 0 ? -_avframe->linesize[0] : 
_avframe->linesize[0]; }
-virtual BMDPixelFormat STDMETHODCALLTYPE GetPixelFormat(void)  { 
return bmdFormat8BitYUV; }
-virtual BMDFrameFlags  STDMETHODCALLTYPE GetFlags  (void)  { 
return _avframe->linesize[0] < 0 ? bmdFrameFlagFlipVertical : 
bmdFrameFlagDefault; }
+decklink_frame(struct decklink_ctx *ctx, AVFrame *avframe, AVCodecID 
codec_id, int height, int width) :
+_ctx(ctx), _avframe(avframe), _avpacket(NULL), _codec_id(codec_id), 
_height(height), _width(width),  _refs(1) { }
+decklink_frame(struct decklink_ctx *ctx, AVPacket *avpacket, AVCodecID 
codec_id, int height, int width) :
+_ctx(ctx), _avframe(NULL), _avpacket(avpacket), _codec_id(codec_id), 
_height(height), _width(width), _refs(1) { }
+
+virtual long   STDMETHODCALLTYPE GetWidth  (void)  { 
return _width; }
+virtual long   STDMETHODCALLTYPE GetHeight (void)  { 
return _height; }
+virtual long   STDMETHODCALLTYPE GetRowBytes   (void)
+{
+  if (_codec_id == AV_CODEC_ID_WRAPPED_AVFRAME)
+  return _avframe->linesize[0] < 0 ? -_avframe->linesize[0] : 
_avframe->linesize[0];
+  else
+  return ((GetWidth() + 47) / 48) * 128;
+}
+virtual BMDPixelFormat STDMETHODCALLTYPE GetPixelFormat(void)
+{
+if (_codec_id == AV_CODEC_ID_WRAPPED_AVFRAME)
+return bmdFormat8BitYUV;
+else
+return bmdFormat10BitYUV;
+}
+virtual BMDFrameFlags  STDMETHODCALLTYPE GetFlags  (void)
+{
+   if (_codec_id == AV_CODEC_ID_WRAPPED_AVFRAME)
+   return _avframe->linesize[0] < 0 ? bmdFrameFlagFlipVertical : 
bmdFrameFlagDefault;
+   else
+   return bmdFrameFlagDefault;
+}
+
 virtual HRESULTSTDMETHODCALLTYPE GetBytes  (void **buffer)
 {
+  if (_avframe) {
 if (_avframe->linesize[0] < 0)
 *buffer = (void *)(_avframe->data[0] + _avframe->linesize[0] * 
(_avframe->height - 1));
 else
 *buffer = (void *)(_avframe->data[0]);
+  } else {
+*buffer = (void *)(_avpacket->data);
+  }
 return S_OK;
 }
 
@@ -70,7 +95,10 @@ public:
 {
 int ret = --_refs;
 if (!ret) {
-av_frame_free(&_avframe);
+if (_codec_id == AV_CODEC_ID_WRAPPED_AVFRAME)
+av_frame_free(&_avframe);
+else
+av_packet_unref(_avpacket);
 delete this;
 }
 return ret;
@@ -78,6 +106,10 @@ public:
 
 struct decklink_ctx *_ctx;
 AVFrame *_avframe;
+AVPacket *_avpacket;
+AVCodecID _codec_id;
+int _height;
+int _width;
 
 private:
 std::atomic  _refs;
@@ -92,7 +124,10 @@ public:
 struct decklink_ctx *ctx = frame->_ctx;
 AVFrame *avframe = frame->_avframe;
 
-av_frame_unref(avframe);
+if (avframe)
+av_frame_unref(avframe);
+else
+av_packet_unref(frame->_avpacket);
 
 pthread_mutex_lock(&ctx->mutex);
 ctx->frames_buffer_available_spots++;
@@ -118,11 +153,14 @@ static int decklink_setup_video(AVFormatContext *avctx, 
AVStream *st)
 return -1;
 }
 
-if (c->format != AV_PIX_FMT_UYVY422) {
-av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format!"
-   " Only AV_PIX_FMT_UYVY422 is supported.\n");
-return -1;
+if (c->codec_id == AV_CODEC_ID_WRAPPED_AVFRAME) {
+if (c->format != AV_PIX_FMT_UYVY422) {
+av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format!"
+   " Only AV_PIX_FMT_UYVY422 is supported.\n");
+return -1;
+}
 }
+
 if (ff_decklink_se

Re: [FFmpeg-devel] [PATCH] lavu/file: fix build on Android NDK with unified headers

2017-09-26 Thread Rodger Combs
I used this rather absurd configure invocation:

BINDIR=$(realpath $(dirname $(ndk-which gcc)))
NDKDIR=$(dirname $(dirname $(dirname $(dirname $(dirname $BINDIR)
TARGET=16
ARCH=arm
TRIPLE=arm-linux-androideabi
SUFFIX=-4.9
PLATARCH=arm

../configure \
--enable-cross-compile \
--arch=$ARCH \
--cross_prefix="$NDKDIR/toolchains/$TRIPLE$SUFFIX/prebuilt/darwin-x86_64/bin/$TRIPLE-"
 \
--extra-cflags=-D__ANDROID_API__=$TARGET \
--extra-cflags="--sysroot=$NDKDIR/sysroot" \
--extra-cflags="-isystem $NDKDIR/sysroot/usr/include/$TRIPLE" \
--extra-cflags="-mfloat-abi=softfp" \
--extra-ldflags="--sysroot=$NDKDIR/platforms/android-$TARGET/arch-$PLATARCH" \
--extra-ldexeflags=-pie \
--enable-debug \
--target-os=android

The issue is that the unified headers don't declare mmap() on target API 
versions before 21 on 32-bit platforms when 
__USE_FILE_OFFSET64/_FILE_OFFSET_BITS=64 is set, because this sets off_t to be 
off64_t, and mmap64 isn't available until API 21. This doesn't matter for 
ffmpeg, since we never use the offset arg anyway, so we can just declare the 
function ourselves.

I'm not sure what one would do about this in configure.

> On Sep 26, 2017, at 06:27, Carl Eugen Hoyos  wrote:
> 
> 2017-09-26 3:52 GMT+02:00 Rodger Combs :
> 
>> +#  if defined(__USE_FILE_OFFSET64) && __ANDROID_API__ < 21 && 
>> !defined(__LP64__)
>> +#   ifdef mmap
>> +#undef mmap
>> +#   endif
>> +void* mmap(void*, size_t, int, int, int, __kernel_off_t);
> 
> How can this issue be reproduced?
> 
> Shouldn't this be checked in configure?
> 
> 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] lavf/dashenc: add format_options option, mirroring segment.c

2017-09-26 Thread Jan Ekstrom
On Tue, Sep 26, 2017 at 4:52 AM, Rodger Combs  wrote:
> ---
>  libavformat/dashenc.c | 13 +
>  1 file changed, 13 insertions(+)

LGTM.

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


[FFmpeg-devel] [PATCH] libavformat: Add format context parameter to ff_id3v2_read_dict

2017-09-26 Thread Lukas Stabe
The format context (when not NULL) is used to store chapter information,
which was not previously supported by ff_id3v2_read_dict.

This fixes https://trac.ffmpeg.org/ticket/6558
---
 libavformat/hls.c   | 2 +-
 libavformat/id3v2.c | 4 ++--
 libavformat/id3v2.h | 6 --
 libavformat/utils.c | 2 +-
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 0995345bbf..f37bfa4e4f 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -909,7 +909,7 @@ static void parse_id3(AVFormatContext *s, AVIOContext *pb,
 static const char id3_priv_owner_ts[] = 
"com.apple.streaming.transportStreamTimestamp";
 ID3v2ExtraMeta *meta;
 
-ff_id3v2_read_dict(pb, metadata, ID3v2_DEFAULT_MAGIC, extra_meta);
+ff_id3v2_read_dict(NULL, pb, metadata, ID3v2_DEFAULT_MAGIC, extra_meta);
 for (meta = *extra_meta; meta; meta = meta->next) {
 if (!strcmp(meta->tag, "PRIV")) {
 ID3v2ExtraMetaPRIV *priv = meta->data;
diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
index 05346350ad..2327d93379 100644
--- a/libavformat/id3v2.c
+++ b/libavformat/id3v2.c
@@ -1097,10 +1097,10 @@ static void id3v2_read_internal(AVIOContext *pb, 
AVDictionary **metadata,
 merge_date(metadata);
 }
 
-void ff_id3v2_read_dict(AVIOContext *pb, AVDictionary **metadata,
+void ff_id3v2_read_dict(AVFormatContext *s, AVIOContext *pb, AVDictionary 
**metadata,
 const char *magic, ID3v2ExtraMeta **extra_meta)
 {
-id3v2_read_internal(pb, metadata, NULL, magic, extra_meta, 0);
+id3v2_read_internal(pb, metadata, s, magic, extra_meta, 0);
 }
 
 void ff_id3v2_read(AVFormatContext *s, const char *magic,
diff --git a/libavformat/id3v2.h b/libavformat/id3v2.h
index 9d7bf1c03c..d8768e955a 100644
--- a/libavformat/id3v2.h
+++ b/libavformat/id3v2.h
@@ -97,13 +97,15 @@ int ff_id3v2_tag_len(const uint8_t *buf);
 /**
  * Read an ID3v2 tag into specified dictionary and retrieve supported extra 
metadata.
  *
- * Chapters are not currently read by this variant.
+ * Chapters are not currently only read by this variant when s is not NULL.
  *
  * @param metadata Parsed metadata is stored here
  * @param extra_meta If not NULL, extra metadata is parsed into a list of
  * ID3v2ExtraMeta structs and *extra_meta points to the head of the list
+ * @param s If not NULL, chapter information is stored in the provided context
  */
-void ff_id3v2_read_dict(AVIOContext *pb, AVDictionary **metadata, const char 
*magic, ID3v2ExtraMeta **extra_meta);
+void ff_id3v2_read_dict(AVFormatContext *s, AVIOContext *pb, AVDictionary 
**metadata,
+const char *magic, ID3v2ExtraMeta **extra_meta);
 
 /**
  * Read an ID3v2 tag, including supported extra metadata and chapters.
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 7abca632b5..079a8211d2 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -588,7 +588,7 @@ int avformat_open_input(AVFormatContext **ps, const char 
*filename,
 
 /* e.g. AVFMT_NOFILE formats will not have a AVIOContext */
 if (s->pb)
-ff_id3v2_read_dict(s->pb, &s->internal->id3v2_meta, 
ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta);
+ff_id3v2_read_dict(s, s->pb, &s->internal->id3v2_meta, 
ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta);
 
 
 if (!(s->flags&AVFMT_FLAG_PRIV_OPT) && s->iformat->read_header)
-- 
2.14.1

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


Re: [FFmpeg-devel] [PATCH] libavformat: Add format context parameter to ff_id3v2_read_dict

2017-09-26 Thread wm4
On Tue, 26 Sep 2017 08:49:44 +0200
Lukas Stabe  wrote:

> The format context (when not NULL) is used to store chapter information,
> which was not previously supported by ff_id3v2_read_dict.
> 
> This fixes https://trac.ffmpeg.org/ticket/6558
> ---

Kind of worried what happens if the ID3 information conflicts with the
normal container information. As you know, libavformat accepts even mp4
or mkv files with ID3v2 header.

Do you think this is a potential issue?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 2/3] lavf/dashenc: add format_options option, mirroring segment.c

2017-09-26 Thread Rodger Combs
---
 libavformat/dashenc.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 92d398ab50..7ed48905f5 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -100,6 +100,7 @@ typedef struct DASHContext {
 AVRational min_frame_rate, max_frame_rate;
 int ambiguous_frame_rate;
 const char *utc_timing_url;
+const char *format_options_str;
 } DASHContext;
 
 static struct codec_string {
@@ -785,6 +786,17 @@ static int dash_init(AVFormatContext *s)
 dict_set_int(&opts, "cluster_time_limit", c->min_seg_duration / 
1000, 0);
 dict_set_int(&opts, "cluster_size_limit", 5 * 1024 * 1024, 0); // 
set a large cluster size limit
 }
+
+if (c->format_options_str) {
+ret = av_dict_parse_string(&opts, c->format_options_str, "=", ":", 
0);
+if (ret < 0) {
+av_log(s, AV_LOG_ERROR, "Could not parse format options list 
'%s'\n",
+   c->format_options_str);
+av_dict_free(&opts);
+return ret;
+}
+}
+
 if ((ret = avformat_init_output(ctx, &opts)) < 0)
 return ret;
 os->ctx_inited = 1;
@@ -1190,6 +1202,7 @@ static const AVOption options[] = {
 { "init_seg_name", "DASH-templated name to used for the initialization 
segment", OFFSET(init_seg_name), AV_OPT_TYPE_STRING, {.str = 
"init-stream$RepresentationID$.m4s"}, 0, 0, E },
 { "media_seg_name", "DASH-templated name to used for the media segments", 
OFFSET(media_seg_name), AV_OPT_TYPE_STRING, {.str = 
"chunk-stream$RepresentationID$-$Number%05d$.m4s"}, 0, 0, E },
 { "utc_timing_url", "URL of the page that will return the UTC timestamp in 
ISO format", OFFSET(utc_timing_url), AV_OPT_TYPE_STRING, { 0 }, 0, 0, E },
+{ "format_options", "set list of options for the underlying mp4 muxer", 
OFFSET(format_options_str), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E },
 { NULL },
 };
 
-- 
2.14.1

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


[FFmpeg-devel] [PATCH 1/3] lavf/dashenc: fix merge error (write_header vs init_output)

2017-09-26 Thread Rodger Combs
---
 libavformat/dashenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 240ff41380..92d398ab50 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -785,7 +785,7 @@ static int dash_init(AVFormatContext *s)
 dict_set_int(&opts, "cluster_time_limit", c->min_seg_duration / 
1000, 0);
 dict_set_int(&opts, "cluster_size_limit", 5 * 1024 * 1024, 0); // 
set a large cluster size limit
 }
-if ((ret = avformat_write_header(ctx, &opts)) < 0)
+if ((ret = avformat_init_output(ctx, &opts)) < 0)
 return ret;
 os->ctx_inited = 1;
 avio_flush(ctx->pb);
-- 
2.14.1

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


[FFmpeg-devel] [PATCH 3/3] lavf/dashenc: unset codec_tag when it doesn't match the underlying muxer

2017-09-26 Thread Rodger Combs
---
 libavformat/dashenc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 7ed48905f5..3a4b6478d1 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -763,6 +763,11 @@ static int dash_init(AVFormatContext *s)
 ctx->avoid_negative_ts = s->avoid_negative_ts;
 ctx->flags = s->flags;
 
+if (ctx->oformat->codec_tag &&
+av_codec_get_id (ctx->oformat->codec_tag, st->codecpar->codec_tag) 
!= st->codecpar->codec_id &&
+av_codec_get_tag(ctx->oformat->codec_tag, st->codecpar->codec_id) 
!= 0)
+st->codecpar->codec_tag = 0;
+
 if ((ret = avio_open_dyn_buf(&ctx->pb)) < 0)
 return ret;
 
-- 
2.14.1

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


[FFmpeg-devel] [PATCH] tools/libav-merge-next-commit: run properly on a branch that isn't master

2017-09-26 Thread Rodger Combs
---
 tools/libav-merge-next-commit | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libav-merge-next-commit b/tools/libav-merge-next-commit
index 9bd03fabf8..e2674008f6 100755
--- a/tools/libav-merge-next-commit
+++ b/tools/libav-merge-next-commit
@@ -7,7 +7,7 @@ fi
 
 [ "$1" = "noop" ] && merge_opts="-s ours"
 
-nextrev=$(git rev-list libav/master --not master --no-merges | tail -n1)
+nextrev=$(git rev-list libav/master --not HEAD --no-merges | tail -n1)
 if [ -z "$nextrev" ]; then
 printf "Nothing to merge..\n"
 exit 0
-- 
2.14.1

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


[FFmpeg-devel] [PATCH] avcodec/v4l2_m2m: fix draining process (dequeue without input)

2017-09-26 Thread Jorge Ramirez-Ortiz
Stopping the codec when no more input is available causes captured
buffers that might be ready to be dequeued to be invalidated.

This commit follows the V4L2 API more closely:
1. on the last valid input buffer, it sets the V4L2_BUF_FLAG_LAST.
2. ffmpeg then will continue dequeuing captured buffers until EPIPE is
raised by the driver (EOF condition)

This also has the advantage of making the timeout on dequeuing capture
buffers while draining unnecessary.
---
 libavcodec/v4l2_context.c | 162 ++
 1 file changed, 64 insertions(+), 98 deletions(-)

diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index d675c55..f06a7ff 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -189,40 +189,6 @@ reinit_run:
 return 1;
 }
 
-static int v4l2_stop_decode(V4L2Context *ctx)
-{
-struct v4l2_decoder_cmd cmd = {
-.cmd = V4L2_DEC_CMD_STOP,
-};
-int ret;
-
-ret = ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_DECODER_CMD, &cmd);
-if (ret) {
-/* DECODER_CMD is optional */
-if (errno == ENOTTY)
-return ff_v4l2_context_set_status(ctx, VIDIOC_STREAMOFF);
-}
-
-return 0;
-}
-
-static int v4l2_stop_encode(V4L2Context *ctx)
-{
-struct v4l2_encoder_cmd cmd = {
-.cmd = V4L2_ENC_CMD_STOP,
-};
-int ret;
-
-ret = ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_ENCODER_CMD, &cmd);
-if (ret) {
-/* ENCODER_CMD is optional */
-if (errno == ENOTTY)
-return ff_v4l2_context_set_status(ctx, VIDIOC_STREAMOFF);
-}
-
-return 0;
-}
-
 static V4L2Buffer* v4l2_dequeue_v4l2buf(V4L2Context *ctx, int timeout)
 {
 struct v4l2_plane planes[VIDEO_MAX_PLANES];
@@ -236,6 +202,13 @@ static V4L2Buffer* v4l2_dequeue_v4l2buf(V4L2Context *ctx, 
int timeout)
 
 if (V4L2_TYPE_IS_OUTPUT(ctx->type))
 pfd.events =  POLLOUT | POLLWRNORM;
+else {
+/* on the capture queue */
+if (ctx_to_m2mctx(ctx)->draining) {
+/* ignore driver requests for more input and just wait for a valid 
frame */
+pfd.events = POLLIN | POLLRDNORM | POLLPRI;
+}
+}
 
 for (;;) {
 ret = poll(&pfd, 1, timeout);
@@ -243,50 +216,45 @@ static V4L2Buffer* v4l2_dequeue_v4l2buf(V4L2Context *ctx, 
int timeout)
 break;
 if (errno == EINTR)
 continue;
-
-/* timeout is being used to indicate last valid bufer when draining */
-if (ctx_to_m2mctx(ctx)->draining)
-ctx->done = 1;
-
 return NULL;
 }
 
-/* 0. handle errors */
+/* handle errors */
 if (pfd.revents & POLLERR) {
 av_log(logger(ctx), AV_LOG_WARNING, "%s POLLERR\n", ctx->name);
 return NULL;
 }
 
-/* 1. handle resolution changes */
+/* handle resolution changes */
 if (pfd.revents & POLLPRI) {
 ret = v4l2_handle_event(ctx);
 if (ret < 0) {
 /* if re-init failed, abort */
-ctx->done = EINVAL;
+ctx->done = 1;
 return NULL;
 }
 if (ret) {
 /* if re-init was successfull drop the buffer (if there was one)
- * since we had to reconfigure capture (unmap all buffers)
- */
+ * since we had to reconfigure capture (unmap all buffers) */
 return NULL;
 }
 }
 
-/* 2. dequeue the buffer */
+/* dequeue the buffer or provide more input */
 if (pfd.revents & (POLLIN | POLLRDNORM | POLLOUT | POLLWRNORM)) {
 
-if (!V4L2_TYPE_IS_OUTPUT(ctx->type)) {
-/* there is a capture buffer ready */
-if (pfd.revents & (POLLIN | POLLRDNORM))
-goto dequeue;
+if (V4L2_TYPE_IS_OUTPUT(ctx->type))
+goto dequeue;
 
-/* the driver is ready to accept more input; instead of waiting 
for the capture
- * buffer to complete we return NULL so input can proceed (we are 
single threaded)
- */
-if (pfd.revents & (POLLOUT | POLLWRNORM))
-return NULL;
-}
+/* there is a capture buffer ready */
+if (pfd.revents & (POLLIN | POLLRDNORM))
+goto dequeue;
+
+/* the driver is ready to accept more input: instead of waiting for
+ * the capture buffer to complete, return NULL so input can proceed
+ * (we are single threaded after all) */
+if (pfd.revents & (POLLOUT | POLLWRNORM))
+return NULL;
 
 dequeue:
 memset(&buf, 0, sizeof(buf));
@@ -301,23 +269,25 @@ dequeue:
 ret = ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_DQBUF, &buf);
 if (ret) {
 if (errno != EAGAIN) {
-ctx->done = errno;
+ctx->done = 1;
 if (errno != EPIPE)
-av_log(logger(ctx), AV_LOG_DEBUG, "%s VIDIOC_DQBUF, errno 
(%s)\n",
+av_log(logger(ctx), AV_LOG_ERROR, "%s VIDIOC_DQBUF, errno 

Re: [FFmpeg-devel] [PATCH] mov: fix decode of fragments that overlap in time

2017-09-26 Thread Michael Niedermayer
Hi

On Mon, Sep 25, 2017 at 02:12:26PM -0700, John Stebbins wrote:
> 
> 
> On 09/25/2017 01:12 PM, Carl Eugen Hoyos wrote:
> > 2017-09-25 19:10 GMT+02:00 John Stebbins :
> >> When keyframe intervals of dash segments are not perfectly aligned,
> >> fragments in the stream can overlap in time. Append new "trun" index
> >> entries to the end of the index instead of sorting by timestamp.
> >> Sorting by timestamp causes packets to be read out of decode order and
> >> results in decode errors.
> >> ---
> >>  libavformat/mov.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavformat/mov.c b/libavformat/mov.c
> >> index 2519707345..b2bc7c2c3d 100644
> >> --- a/libavformat/mov.c
> >> +++ b/libavformat/mov.c
> >> @@ -4339,8 +4339,8 @@ static int mov_read_trun(MOVContext *c, AVIOContext 
> >> *pb, MOVAtom atom)
> >>MOV_FRAG_SAMPLE_FLAG_DEPENDS_YES));
> >>  if (keyframe)
> >>  distance = 0;
> >> -ctts_index = av_add_index_entry(st, offset, dts, sample_size, 
> >> distance,
> >> -keyframe ? AVINDEX_KEYFRAME : 0);
> >> +ctts_index = add_index_entry(st, offset, dts, sample_size, 
> >> distance,
> >> + keyframe ? AVINDEX_KEYFRAME : 0);
> > I can confirm that this fixes playback with FFplay but it shows
> > many warnings (Non-monotonous DTS) with ffmpeg: Is this
> > unavoidable?
> >
> >
> 
> Fixing the non-monotonous DTS in ffmpeg would require more consideration. The 
> overlapping frames need to be dropped
> somewhere after they are decoded and before they are presented. 
> 

> I've given this some thought, but other ideas are certainly welcome. The 
> demuxer is probably the most appropriate place
> for marking the frames as needing to be dropped since it has the "knowledge" 
> about why there are overlapping
> timestamps.  I.e. you only want to drop frames in this particular scenario 
> and not generally when timestamps go
> backwards.  I don't think there is currently any facility for marking frames 
> to be dropped after decoding, but it seems
> like AVPacketSideData would be the appropriate mechanism for such marking.  
> FYI, such a facility for marking frames to
> drop would also be useful for frame accurate playback of MP4 edit lists.

This sounds like:

/**
 * Flag is used to discard packets which are required to maintain valid
 * decoder state but are not required for output and should be dropped
 * after decoding.
 **/
#define AV_PKT_FLAG_DISCARD   0x0004


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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


[FFmpeg-devel] [PATCH 1/2] avcodec/hevc_ps: extract SPS fields required for hvcC construction

2017-09-26 Thread Aman Gupta
From: Aman Gupta 

---
 libavcodec/hevc_ps.c | 3 ++-
 libavcodec/hevc_ps.h | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 500fee03d8..902917d4dd 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -893,7 +893,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb, 
unsigned int *sps_id,
 return AVERROR_INVALIDDATA;
 }
 
-skip_bits1(gb); // temporal_id_nesting_flag
+sps->temporal_id_nesting_flag = get_bits(gb, 1);
 
 if ((ret = parse_ptl(gb, avctx, &sps->ptl, sps->max_sub_layers)) < 0)
 return ret;
@@ -956,6 +956,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb, 
unsigned int *sps_id,
sps->bit_depth, bit_depth_chroma);
 return AVERROR_INVALIDDATA;
 }
+sps->bit_depth_chroma = bit_depth_chroma;
 
 ret = map_pixel_format(avctx, sps);
 if (ret < 0)
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index 4e6c3bc849..76f8eb31e6 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -232,6 +232,7 @@ typedef struct HEVCSPS {
 HEVCWindow pic_conf_win;
 
 int bit_depth;
+int bit_depth_chroma;
 int pixel_shift;
 enum AVPixelFormat pix_fmt;
 
@@ -244,6 +245,7 @@ typedef struct HEVCSPS {
 int num_reorder_pics;
 int max_latency_increase;
 } temporal_layer[HEVC_MAX_SUB_LAYERS];
+uint8_t temporal_id_nesting_flag;
 
 VUI vui;
 PTL ptl;
-- 
2.13.5 (Apple Git-94)

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


[FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

2017-09-26 Thread Aman Gupta
From: Aman Gupta 

---
 configure|   2 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/hevc_refs.c   |   3 +
 libavcodec/hevcdec.c |  12 ++-
 libavcodec/vda_vt_internal.h |   1 +
 libavcodec/videotoolbox.c| 203 +++
 6 files changed, 221 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index ba38a73906..d353e9d824 100755
--- a/configure
+++ b/configure
@@ -2687,6 +2687,8 @@ hevc_vaapi_hwaccel_deps="vaapi 
VAPictureParameterBufferHEVC"
 hevc_vaapi_hwaccel_select="hevc_decoder"
 hevc_vdpau_hwaccel_deps="vdpau VdpPictureInfoHEVC"
 hevc_vdpau_hwaccel_select="hevc_decoder"
+hevc_videotoolbox_hwaccel_deps="videotoolbox"
+hevc_videotoolbox_hwaccel_select="hevc_decoder"
 mjpeg_cuvid_hwaccel_deps="cuda cuvid"
 mjpeg_cuvid_hwaccel_select="mjpeg_cuvid_decoder"
 mpeg_xvmc_hwaccel_deps="xvmc"
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index db2db158f3..efc646634b 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -84,6 +84,7 @@ static void register_all(void)
 REGISTER_HWACCEL(HEVC_QSV,  hevc_qsv);
 REGISTER_HWACCEL(HEVC_VAAPI,hevc_vaapi);
 REGISTER_HWACCEL(HEVC_VDPAU,hevc_vdpau);
+REGISTER_HWACCEL(HEVC_VIDEOTOOLBOX, hevc_videotoolbox);
 REGISTER_HWACCEL(MJPEG_CUVID,   mjpeg_cuvid);
 REGISTER_HWACCEL(MPEG1_CUVID,   mpeg1_cuvid);
 REGISTER_HWACCEL(MPEG1_XVMC,mpeg1_xvmc);
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 68c730edcc..ac462d350b 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -208,6 +208,9 @@ int ff_hevc_output_frame(HEVCContext *s, AVFrame *out, int 
flush)
 if (nb_output) {
 HEVCFrame *frame = &s->DPB[min_idx];
 
+if (frame->frame->format == AV_PIX_FMT_VIDEOTOOLBOX && 
frame->frame->buf[0]->size == 1)
+return 0;
+
 ret = av_frame_ref(out, frame->frame);
 if (frame->flags & HEVC_FRAME_FLAG_BUMPING)
 ff_hevc_unref_frame(s, frame, HEVC_FRAME_FLAG_OUTPUT | 
HEVC_FRAME_FLAG_BUMPING);
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 2306c51ed3..2e4add2ae3 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -352,7 +352,11 @@ static void export_stream_params(AVCodecContext *avctx, 
const HEVCParamSets *ps,
 
 static enum AVPixelFormat get_format(HEVCContext *s, const HEVCSPS *sps)
 {
-#define HWACCEL_MAX (CONFIG_HEVC_DXVA2_HWACCEL + 
CONFIG_HEVC_D3D11VA_HWACCEL * 2 + CONFIG_HEVC_VAAPI_HWACCEL + 
CONFIG_HEVC_VDPAU_HWACCEL)
+#define HWACCEL_MAX (CONFIG_HEVC_DXVA2_HWACCEL + \
+ CONFIG_HEVC_D3D11VA_HWACCEL * 2 + \
+ CONFIG_HEVC_VAAPI_HWACCEL + \
+ CONFIG_HEVC_VIDEOTOOLBOX_HWACCEL + \
+ CONFIG_HEVC_VDPAU_HWACCEL)
 enum AVPixelFormat pix_fmts[HWACCEL_MAX + 2], *fmt = pix_fmts;
 
 switch (sps->pix_fmt) {
@@ -371,6 +375,9 @@ static enum AVPixelFormat get_format(HEVCContext *s, const 
HEVCSPS *sps)
 #if CONFIG_HEVC_VDPAU_HWACCEL
 *fmt++ = AV_PIX_FMT_VDPAU;
 #endif
+#if CONFIG_HEVC_VIDEOTOOLBOX_HWACCEL
+*fmt++ = AV_PIX_FMT_VIDEOTOOLBOX;
+#endif
 break;
 case AV_PIX_FMT_YUV420P10:
 #if CONFIG_HEVC_DXVA2_HWACCEL
@@ -383,6 +390,9 @@ static enum AVPixelFormat get_format(HEVCContext *s, const 
HEVCSPS *sps)
 #if CONFIG_HEVC_VAAPI_HWACCEL
 *fmt++ = AV_PIX_FMT_VAAPI;
 #endif
+#if CONFIG_HEVC_VIDEOTOOLBOX_HWACCEL
+*fmt++ = AV_PIX_FMT_VIDEOTOOLBOX;
+#endif
 break;
 }
 
diff --git a/libavcodec/vda_vt_internal.h b/libavcodec/vda_vt_internal.h
index e55a813899..326a60a695 100644
--- a/libavcodec/vda_vt_internal.h
+++ b/libavcodec/vda_vt_internal.h
@@ -59,4 +59,5 @@ int ff_videotoolbox_h264_decode_slice(AVCodecContext *avctx,
   const uint8_t *buffer,
   uint32_t size);
 CFDataRef ff_videotoolbox_avcc_extradata_create(AVCodecContext *avctx);
+CFDataRef ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx);
 #endif /* AVCODEC_VDA_VT_INTERNAL_H */
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index dd13e2581b..078174cc61 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -32,6 +32,7 @@
 #include "libavutil/hwcontext.h"
 #include "bytestream.h"
 #include "h264dec.h"
+#include "hevcdec.h"
 #include "mpegvideo.h"
 #include 
 
@@ -115,6 +116,174 @@ CFDataRef 
ff_videotoolbox_avcc_extradata_create(AVCodecContext *avctx)
 return data;
 }
 
+CFDataRef ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
+{
+HEVCContext *h = avctx->priv_data;
+const HEVCVPS *vps = (const HEVCVPS *)h->ps.vps_list[0]->data;
+const HEVCSPS *sps = (const HEVCSPS *)h->ps.sps_list[0]->data;
+int i, num_pps = 0;
+const HEVCPPS *pps = h->ps.pps;
+PTLCommon ptlc = vps->ptl.general_ptl;
+VUI vui = sps->vui;
+uint8_t para

Re: [FFmpeg-devel] [PATCH v3] avcodec/hevc_sei: Support HEVC paired fields.

2017-09-26 Thread Michael Niedermayer
On Sun, Sep 24, 2017 at 10:13:11PM -0500, Brian Matherly wrote:
> From: Brian Matherly 
> 
> Correctly set the interlaced_frame and top_field_first fields when pic_struct
> indicates paired fields.
> ---
>  libavcodec/hevc_sei.c |   4 +-
>  tests/fate/hevc.mak   |   6 +-
>  tests/ref/fate/hevc-paired-fields | 120 
> ++
>  3 files changed, 127 insertions(+), 3 deletions(-)
>  create mode 100644 tests/ref/fate/hevc-paired-fields

the test seems to fail on big endian: (mips qemu)

@@ -14,7 +14,7 @@
 pkt_size=229528
 width=1920
 height=540
-pix_fmt=yuv422p10le
+pix_fmt=yuv422p10be
 sample_aspect_ratio=1:1
 pict_type=I
 coded_picture_number=0
@@ -44,7 +44,7 @@
 pkt_size=95954
 width=1920
 height=540
-pix_fmt=yuv422p10le
+pix_fmt=yuv422p10be
 sample_aspect_ratio=1:1
 pict_type=B
 coded_picture_number=0
@@ -74,7 +74,7 @@
 pkt_size=114837
 width=1920
 height=540
-pix_fmt=yuv422p10le
+pix_fmt=yuv422p10be
 sample_aspect_ratio=1:1
 pict_type=B
 coded_picture_number=0
@@ -104,7 +104,7 @@
 pkt_size=85098
 width=1920
 height=540
-pix_fmt=yuv422p10le
+pix_fmt=yuv422p10be
 sample_aspect_ratio=1:1
 pict_type=B
 coded_picture_number=0

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

2017-09-26 Thread James Almer
On 9/26/2017 10:08 PM, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  configure|   2 +
>  libavcodec/allcodecs.c   |   1 +
>  libavcodec/hevc_refs.c   |   3 +
>  libavcodec/hevcdec.c |  12 ++-
>  libavcodec/vda_vt_internal.h |   1 +
>  libavcodec/videotoolbox.c| 203 
> +++
>  6 files changed, 221 insertions(+), 1 deletion(-)

> +CFDataRef ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
> +{
> +HEVCContext *h = avctx->priv_data;
> +const HEVCVPS *vps = (const HEVCVPS *)h->ps.vps_list[0]->data;
> +const HEVCSPS *sps = (const HEVCSPS *)h->ps.sps_list[0]->data;
> +int i, num_pps = 0;
> +const HEVCPPS *pps = h->ps.pps;
> +PTLCommon ptlc = vps->ptl.general_ptl;
> +VUI vui = sps->vui;
> +uint8_t parallelismType;
> +CFDataRef data = NULL;
> +uint8_t *p;
> +int vt_extradata_size = 23 + 5 + vps->data_size + 5 + sps->data_size + 3;
> +uint8_t *vt_extradata;
> +
> +for (i = 0; i < MAX_PPS_COUNT; i++) {
> +if (h->ps.pps_list[i]) {
> +const HEVCPPS *pps = (const HEVCPPS *)h->ps.pps_list[i]->data;
> +vt_extradata_size += 2 + pps->data_size;
> +num_pps++;
> +}
> +}
> +
> +vt_extradata = av_malloc(vt_extradata_size);
> +if (!vt_extradata)
> +return NULL;
> +p = vt_extradata;
> +
> +/* unsigned int(8) configurationVersion = 1; */
> +AV_W8(p + 0, 1);

p is uint8_t*. Seems weird using AV_W8() for it.

Yes, i know ff_videotoolbox_avcc_extradata_create() uses it, but there's
no reason to extend that behavior to new functions.

> +
> +/*
> + * unsigned int(2) general_profile_space;
> + * unsigned int(1) general_tier_flag;
> + * unsigned int(5) general_profile_idc;
> + */
> +AV_W8(p + 1, ptlc.profile_space << 6 |
> + ptlc.tier_flag << 5 |
> + ptlc.profile_idc);
> +
> +/* unsigned int(32) general_profile_compatibility_flags; */
> +memcpy(p + 2, ptlc.profile_compatibility_flag, 4);
> +
> +/* unsigned int(48) general_constraint_indicator_flags; */
> +AV_W8(p + 6, ptlc.progressive_source_flag<< 7 |
> + ptlc.interlaced_source_flag << 6 |
> + ptlc.non_packed_constraint_flag << 5 |
> + ptlc.frame_only_constraint_flag << 4);
> +AV_W8(p + 7, 0);
> +AV_W8(p + 8, 0);
> +AV_W8(p + 9, 0);
> +AV_W8(p + 10, 0);
> +AV_W8(p + 11, 0);
> +
> +/* unsigned int(8) general_level_idc; */
> +AV_W8(p + 12, ptlc.level_idc);
> +
> +/*
> + * bit(4) reserved = ‘’b;
> + * unsigned int(12) min_spatial_segmentation_idc;
> + */
> +AV_W8(p + 13, 0xf0 | (vui.min_spatial_segmentation_idc >> 4));
> +AV_W8(p + 14, vui.min_spatial_segmentation_idc & 0xff);
> +
> +/*
> + * bit(6) reserved = ‘11’b;
> + * unsigned int(2) parallelismType;
> + */
> +if (!vui.min_spatial_segmentation_idc)
> +parallelismType = 0;
> +else if (pps->entropy_coding_sync_enabled_flag && 
> pps->tiles_enabled_flag)
> +parallelismType = 0;
> +else if (pps->entropy_coding_sync_enabled_flag)
> +parallelismType = 3;
> +else if (pps->tiles_enabled_flag)
> +parallelismType = 2;
> +else
> +parallelismType = 1;
> +AV_W8(p + 15, 0xfc | parallelismType);
> +
> +/*
> + * bit(6) reserved = ‘11’b;
> + * unsigned int(2) chromaFormat;
> + */
> +AV_W8(p + 16, sps->chroma_format_idc | 0xfc);
> +
> +/*
> + * bit(5) reserved = ‘1’b;
> + * unsigned int(3) bitDepthLumaMinus8;
> + */
> +AV_W8(p + 17, (sps->bit_depth - 8) | 0xfc);
> +
> +/*
> + * bit(5) reserved = ‘1’b;
> + * unsigned int(3) bitDepthChromaMinus8;
> + */
> +AV_W8(p + 18, (sps->bit_depth_chroma - 8) | 0xfc);
> +
> +/* bit(16) avgFrameRate; */
> +AV_W8(p + 19, 0);
> +AV_W8(p + 20, 0);
> +
> +/*
> + * bit(2) constantFrameRate;
> + * bit(3) numTemporalLayers;
> + * bit(1) temporalIdNested;
> + * unsigned int(2) lengthSizeMinusOne;
> + */
> +AV_W8(p + 21, 0 << 6 |
> +  sps->max_sub_layers   << 3 |
> +  sps->temporal_id_nesting_flag << 2 |
> +  3);
> +
> +/* unsigned int(8) numOfArrays; */
> +AV_W8(p + 22, 3);
> +
> +p += 23;
> +/* vps */
> +/*
> + * bit(1) array_completeness;
> + * unsigned int(1) reserved = 0;
> + * unsigned int(6) NAL_unit_type;
> + */
> +AV_W8(p, 1 << 7 |
> + HEVC_NAL_VPS & 0x3f);
> +/* unsigned int(16) numNalus; */
> +AV_W8(p + 1, 0);
> +AV_W8(p + 2, 1);
> +/* unsigned int(16) nalUnitLength; */
> +AV_W8(p + 3, vps->data_size >> 8);
> +AV_W8(p + 4, vps->data_size & 0x);
> +/* bit(8*nalUnitLength) nalUnit; */
> +memcpy(p + 5, vps->data, vps->data_size);
> +p += 5 +

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

2017-09-26 Thread Aman Gupta
On Tue, Sep 26, 2017 at 7:20 PM, James Almer  wrote:

> On 9/26/2017 10:08 PM, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > ---
> >  configure|   2 +
> >  libavcodec/allcodecs.c   |   1 +
> >  libavcodec/hevc_refs.c   |   3 +
> >  libavcodec/hevcdec.c |  12 ++-
> >  libavcodec/vda_vt_internal.h |   1 +
> >  libavcodec/videotoolbox.c| 203 ++
> +
> >  6 files changed, 221 insertions(+), 1 deletion(-)
>
> > +CFDataRef ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
> > +{
> > +HEVCContext *h = avctx->priv_data;
> > +const HEVCVPS *vps = (const HEVCVPS *)h->ps.vps_list[0]->data;
> > +const HEVCSPS *sps = (const HEVCSPS *)h->ps.sps_list[0]->data;
> > +int i, num_pps = 0;
> > +const HEVCPPS *pps = h->ps.pps;
>

One thing that surprised me.. when this is invoked, h->vps and h->sps are
not yet set. Only h->pps has a value. I had to pull the vps and sps from
the vps_list/sps_list directly.


> > +PTLCommon ptlc = vps->ptl.general_ptl;
> > +VUI vui = sps->vui;
> > +uint8_t parallelismType;
> > +CFDataRef data = NULL;
> > +uint8_t *p;
> > +int vt_extradata_size = 23 + 5 + vps->data_size + 5 +
> sps->data_size + 3;
> > +uint8_t *vt_extradata;
> > +
> > +for (i = 0; i < MAX_PPS_COUNT; i++) {
> > +if (h->ps.pps_list[i]) {
> > +const HEVCPPS *pps = (const HEVCPPS
> *)h->ps.pps_list[i]->data;
> > +vt_extradata_size += 2 + pps->data_size;
> > +num_pps++;
> > +}
> > +}
> > +
> > +vt_extradata = av_malloc(vt_extradata_size);
> > +if (!vt_extradata)
> > +return NULL;
> > +p = vt_extradata;
> > +
> > +/* unsigned int(8) configurationVersion = 1; */
> > +AV_W8(p + 0, 1);
>
> p is uint8_t*. Seems weird using AV_W8() for it.
>
> Yes, i know ff_videotoolbox_avcc_extradata_create() uses it, but there's
> no reason to extend that behavior to new functions.
>

Are you recommending simple array access instead, i.e. `p[0] = 1`?

I just noticed the avcc creation is using AV_WB16() which would simplify
some of my code.


>
> > +
> > +/*
> > + * unsigned int(2) general_profile_space;
> > + * unsigned int(1) general_tier_flag;
> > + * unsigned int(5) general_profile_idc;
> > + */
> > +AV_W8(p + 1, ptlc.profile_space << 6 |
> > + ptlc.tier_flag << 5 |
> > + ptlc.profile_idc);
> > +
> > +/* unsigned int(32) general_profile_compatibility_flags; */
> > +memcpy(p + 2, ptlc.profile_compatibility_flag, 4);
> > +
> > +/* unsigned int(48) general_constraint_indicator_flags; */
> > +AV_W8(p + 6, ptlc.progressive_source_flag<< 7 |
> > + ptlc.interlaced_source_flag << 6 |
> > + ptlc.non_packed_constraint_flag << 5 |
> > + ptlc.frame_only_constraint_flag << 4);
> > +AV_W8(p + 7, 0);
> > +AV_W8(p + 8, 0);
> > +AV_W8(p + 9, 0);
> > +AV_W8(p + 10, 0);
> > +AV_W8(p + 11, 0);
> > +
> > +/* unsigned int(8) general_level_idc; */
> > +AV_W8(p + 12, ptlc.level_idc);
> > +
> > +/*
> > + * bit(4) reserved = ‘’b;
> > + * unsigned int(12) min_spatial_segmentation_idc;
> > + */
> > +AV_W8(p + 13, 0xf0 | (vui.min_spatial_segmentation_idc >> 4));
> > +AV_W8(p + 14, vui.min_spatial_segmentation_idc & 0xff);
> > +
> > +/*
> > + * bit(6) reserved = ‘11’b;
> > + * unsigned int(2) parallelismType;
> > + */
> > +if (!vui.min_spatial_segmentation_idc)
> > +parallelismType = 0;
> > +else if (pps->entropy_coding_sync_enabled_flag &&
> pps->tiles_enabled_flag)
> > +parallelismType = 0;
> > +else if (pps->entropy_coding_sync_enabled_flag)
> > +parallelismType = 3;
> > +else if (pps->tiles_enabled_flag)
> > +parallelismType = 2;
> > +else
> > +parallelismType = 1;
> > +AV_W8(p + 15, 0xfc | parallelismType);
> > +
> > +/*
> > + * bit(6) reserved = ‘11’b;
> > + * unsigned int(2) chromaFormat;
> > + */
> > +AV_W8(p + 16, sps->chroma_format_idc | 0xfc);
> > +
> > +/*
> > + * bit(5) reserved = ‘1’b;
> > + * unsigned int(3) bitDepthLumaMinus8;
> > + */
> > +AV_W8(p + 17, (sps->bit_depth - 8) | 0xfc);
> > +
> > +/*
> > + * bit(5) reserved = ‘1’b;
> > + * unsigned int(3) bitDepthChromaMinus8;
> > + */
> > +AV_W8(p + 18, (sps->bit_depth_chroma - 8) | 0xfc);
> > +
> > +/* bit(16) avgFrameRate; */
> > +AV_W8(p + 19, 0);
> > +AV_W8(p + 20, 0);
>

This could be AV_WB16() instead for instance.


> > +
> > +/*
> > + * bit(2) constantFrameRate;
> > + * bit(3) numTemporalLayers;
> > + * bit(1) temporalIdNested;
> > + * unsigned int(2) lengthSizeMinusOne;
> > + */
> > +AV_W8(p + 21, 0 << 6 |
> > +  sps->max_sub_layers   << 3 |
> > +  

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

2017-09-26 Thread James Almer
On 9/26/2017 11:49 PM, Aman Gupta wrote:
> On Tue, Sep 26, 2017 at 7:20 PM, James Almer  wrote:
>> On 9/26/2017 10:08 PM, Aman Gupta wrote:
>>> +for (i = 0; i < MAX_PPS_COUNT; i++) {
>>> +if (h->ps.pps_list[i]) {
>>
>> I think this hints that there's no guarantee that the entire buffer of
>> size vt_extradata_size will be filled with data.
>> Keeping that in mind, you should use av_mallocz() for vt_extradata.
>>
>> Also, why did you use MAX_PPS_COUNT here but not to set vt_extradata_size?
>>
> 
> Hmm, I used MAX_PPS_COUNT in both loops (they should be identical as I
> copy/pasted), and the calculated size is exact based on the size of the *PS
> data. This is verified with the assert() at the end of this function. The
> approach was copied wholesale from avcc_create().

You're right, i missed the first loop. Nevermind this part then. I
missed it and assumed the buffer was allocated with the maximum size it
could in theory be needed.

> 
> 
>>
>>
>>> +const HEVCPPS *pps = (const HEVCPPS
>> *)h->ps.pps_list[i]->data;
>>> +AV_W8(p + 0, pps->data_size >> 8);
>>> +AV_W8(p + 1, pps->data_size & 0x);
>>> +memcpy(p + 2, pps->data, pps->data_size);
>>> +p += 2 + pps->data_size;
>>> +}
>>> +}
>>> +
>>> +av_assert0(p - vt_extradata == vt_extradata_size);
>>
>> This and all the pointer handling you did above makes me think the best
>> solution would be to use the bytestream2's PutByteContext API instead.
>>
>>> +
>>> +data = CFDataCreate(kCFAllocatorDefault, vt_extradata,
>> vt_extradata_size);
>>
>> As i mentioned above, i don't think the entire buffer is guaranteed to
>> be always filled to the last byte. The bytestream2 API would let you
>> keep track of how much you wrote to it and pass that to this function.
>>
> 
> I will check out bytestream2 and see if it simplifies things. I'm using an
> extra loop to pre-calculate the size of the hvcC that I might be able to
> get rid of with the bytestream2 API.

You need to know the size of the allocated buffer (or the size you
intend to fill at most) to initialize the bytestream2 struct, so the
first loop will probably still be needed.

> 
> One advantage of the current approach is that it mimics the code in
> libavformat/hevc.c's hvcc_write(). This will make it easier to keep them in
> sync in the future.

lavf's hevc.c uses the AVIOContext API rather than intreadwrite.h or the
bytestream2 API, so not really much in sync beyond all of them being
able to write values of 8 or 16 bits each.

The bytestream2 API will let you clean some code as it handles the
pointer itself as it writes data, but as long as the size calculation
before the av_malloc() call is correct then the bytestream2 overwrite
protection feature wouldn't be useful.
You could use the unchecked bytestream2 API directly, or just keep the
current approach.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] libavformat: Add format context parameter to ff_id3v2_read_dict

2017-09-26 Thread Lukas Stabe
> Kind of worried what happens if the ID3 information conflicts with the
> normal container information. As you know, libavformat accepts even mp4
> or mkv files with ID3v2 header.
> 
> Do you think this is a potential issue?

I'm quite new to the ffmpeg source, but if I'm reading things correctly, with 
this patch
the format specific chapters would, depending on how the format sets the 
chapter ids,
override, be appended to or mix with the id3 chapters.

I would not expect to find non-mp3 files with id3 chapter tags in the wild, but 
this patch
would probably misbehave with those.

The proper solution here would probably be to parse the chapters into 
extra_meta in read_chapter
and create another function that parses that into the format context similar to 
how ff_id3v2_parse_apic
works. That's quite a bigger change than this one however, and requires 
touching a bunch of places
(everywhere ff_id3v2_read_dict and ff_id3v2_read are used), so I don't feel 
like I'm familiar enough with
ffmpeg to do that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2017-09-26 Thread Jeyapal, Karthick
>Sorry for the late reply, the last was busy week. Here are some more
>comments:

Thanks for your comments. Please find the updated patch attached with your 
comments incorporated.

Regards,
Karthick


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


[FFmpeg-devel] ffmpeg have program decoding ACC ltam audo stream

2017-09-26 Thread jkung
Good afternoon Sir;

 

I am using OMXplayer in Raspberry Pi to play our recorded TS for DVBt2
Braodcast.

 

Seems ffmpeg had problem decoding the audio stream - ACC ltam 5.1

 

Appreciate your advise

 

Thank you very much

 

 

Johnson Kung

Antechnic Engineering Pte Ltd

50 Ubi Avenue 3 #05-02 Frontier

S(408866)

Mobile: 9631-2875

Office: 6282-8690

 

 

 

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