Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Refine edit list start seek, based on PTS computed from CTTS.

2017-11-03 Thread Michael Niedermayer
On Thu, Nov 02, 2017 at 05:33:28PM -0700, Sasi Inguva wrote:
> Partially fixes t/6699.
> ---
>  libavformat/mov.c| 129 
> +++
>  tests/fate/mov.mak   |   8 +++
>  tests/ref/fate/mov-ibi-elst-starts-b |  33 +
>  3 files changed, 127 insertions(+), 43 deletions(-)
>  create mode 100644 tests/ref/fate/mov-ibi-elst-starts-b

will apply

thanks

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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


Re: [FFmpeg-devel] [PATCH] HW accelerator: Indicate when HW acceleration is in use

2017-11-03 Thread Michael Niedermayer
On Fri, Nov 03, 2017 at 11:35:33AM -0700, Michele Lim wrote:
> Having clear indication of when a hardware accelerator is in
> operation prevents false assumptions, for e.g., in situations when
> the command line argument inadvertently omits options for enabling
> it, resulting to the framework silently switching to the SW path.
> 
> Signed-off-by: Michele Lim 
> ---
>  fftools/ffmpeg_hw.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/fftools/ffmpeg_hw.c b/fftools/ffmpeg_hw.c
> index a4d1cad..f071746 100644
> --- a/fftools/ffmpeg_hw.c
> +++ b/fftools/ffmpeg_hw.c
> @@ -306,6 +306,8 @@ int hw_device_setup_for_decode(InputStream *ist)
>  if (!ist->dec_ctx->hw_device_ctx)
>  return AVERROR(ENOMEM);
>  
> +/* Indicate HW accelerator has been prepared for decode */
> +av_log(ist->dec_ctx, AV_LOG_INFO, "HW accelerator prepared for decode: 
> %s\n", av_hwdevice_get_type_name(type));
>  return 0;
>  }
>  

> @@ -331,6 +333,9 @@ int hw_device_setup_for_encode(OutputStream *ost)
>  // No device required.
>  return 0;
>  }
> +
> +/* Indicate HW accelerator has been prepared for encode */
> +av_log(ost->enc_ctx, AV_LOG_INFO, "HW accelerator prepared for encode: 
> %s\n", av_hwdevice_get_type_name(type));
>  }

i dont know if this extra info is desireable or not but
this code is unreachable

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

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


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


Re: [FFmpeg-devel] [PATCH] avformat/dv : change audio format endianess to BE

2017-11-03 Thread Lou Logan
On Fri, Nov 3, 2017, at 04:49 PM, Michael Niedermayer wrote:
> This does not explain why this change is done.
> does it fix a bug?
> does it make the code faster?

ffmbc uses BE too, but I'm ignorant as to why it does.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2017-11-03 Thread Manojkumar Bhosale
LGTM

From: ffmpeg-devel [ffmpeg-devel-boun...@ffmpeg.org] on behalf of 
kaustubh.ra...@imgtec.com [kaustubh.ra...@imgtec.com]
Sent: Friday, November 03, 2017 1:05 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni weighted 4   
tap hz mc msa functions

From: Kaustubh Raste 

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

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_uniw_msa.c |  892 ++--
 1 file changed, 448 insertions(+), 444 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_uniw_msa.c 
b/libavcodec/mips/hevc_mc_uniw_msa.c
index 0796b0a..31fec73 100644
--- a/libavcodec/mips/hevc_mc_uniw_msa.c
+++ b/libavcodec/mips/hevc_mc_uniw_msa.c
@@ -29,19 +29,6 @@ static const uint8_t ff_hevc_mask_arr[16 * 2] 
__attribute__((aligned(0x40))) = {
 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20
 };

-#define HEVC_HV_UNIW_RND_CLIP4(in0, in1, in2, in3, wgt, offset, rnd,   \
-   out0, out1, out2, out3) \
-{  \
-MUL4(in0, wgt, in1, wgt, in2, wgt, in3, wgt, out0, out1, out2, out3);  \
-SRAR_W4_SW(out0, out1, out2, out3, rnd);   \
-ADD4(out0, offset, out1, offset, out2, offset, out3, offset,   \
- out0, out1, out2, out3);  \
-out0 = CLIP_SW_0_255(out0);\
-out1 = CLIP_SW_0_255(out1);\
-out2 = CLIP_SW_0_255(out2);\
-out3 = CLIP_SW_0_255(out3);\
-}
-
 #define HEVC_UNIW_RND_CLIP2(in0, in1, wgt, offset, rnd,  \
 out0_r, out1_r, out0_l, out1_l)  \
 {\
@@ -2382,19 +2369,19 @@ static void hevc_hz_uniwgt_4t_4x2_msa(uint8_t *src,
   uint8_t *dst,
   int32_t dst_stride,
   const int8_t *filter,
-  int32_t height,
   int32_t weight,
   int32_t offset,
   int32_t rnd_val)
 {
+v16u8 out;
 v8i16 filt0, filt1;
 v16i8 src0, src1, vec0, vec1;
 v16i8 mask1;
 v8i16 dst0;
 v4i32 dst0_r, dst0_l;
-v8i16 filter_vec, const_vec;
-v4i32 weight_vec, offset_vec, rnd_vec;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20 };
+v8i16 filter_vec, weight_vec_h, offset_vec, denom_vec;
+v4i32 weight_vec, rnd_vec;
+v16i8 mask0 = LD_SB(&ff_hevc_mask_arr[16]);

 src -= 1;

@@ -2405,29 +2392,33 @@ static void hevc_hz_uniwgt_4t_4x2_msa(uint8_t *src,

 weight = weight & 0x;

-const_vec = __msa_ldi_h(128);
-const_vec <<= 6;
-
 weight_vec = __msa_fill_w(weight);
-offset_vec = __msa_fill_w(offset);
 rnd_vec = __msa_fill_w(rnd_val);

+weight *= 128;
+rnd_val -= 6;
+
+weight_vec_h = __msa_fill_h(weight);
+offset_vec = __msa_fill_h(offset);
+denom_vec = __msa_fill_h(rnd_val);
+
+weight_vec_h = __msa_srar_h(weight_vec_h, denom_vec);
+offset_vec = __msa_adds_s_h(offset_vec, weight_vec_h);
+
 LD_SB2(src, src_stride, src0, src1);
 XORI_B2_128_SB(src0, src1);

 VSHF_B2_SB(src0, src1, src0, src1, mask0, mask1, vec0, vec1);
-dst0 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst0, dst0);
+dst0 = HEVC_FILT_4TAP_SH(vec0, vec1, filt0, filt1);

 ILVRL_H2_SW(dst0, dst0, dst0_r, dst0_l);
 DOTP_SH2_SW(dst0_r, dst0_l, weight_vec, weight_vec, dst0_r, dst0_l);
 SRAR_W2_SW(dst0_r, dst0_l, rnd_vec);
-ADD2(dst0_r, offset_vec, dst0_l, offset_vec, dst0_r, dst0_l);
-dst0_r = CLIP_SW_0_255(dst0_r);
-dst0_l = CLIP_SW_0_255(dst0_l);
-
-HEVC_PCK_SW_SB2(dst0_l, dst0_r, dst0_r);
-ST4x2_UB(dst0_r, dst, dst_stride);
+dst0 = __msa_pckev_h((v8i16) dst0_l, (v8i16) dst0_r);
+dst0 = __msa_adds_s_h(dst0, offset_vec);
+dst0 = CLIP_SH_0_255_MAX_SATU(dst0);
+out = (v16u8) __msa_pckev_b((v16i8) dst0, (v16i8) dst0);
+ST4x2_UB(out, dst, dst_stride);
 dst += (4 * dst_stride);
 }

@@ -2436,19 +2427,18 @@ static void hevc_hz_uniwgt_4t_4x4_msa(uint8_t *src,
   uint8_t *dst,
   int32_t dst_stride,
   const int8_t *filter,
-  int32_t height,
   int32_t weight,
   i

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

2017-11-03 Thread Manojkumar Bhosale
LGTM

From: ffmpeg-devel [ffmpeg-devel-boun...@ffmpeg.org] on behalf of 
kaustubh.ra...@imgtec.com [kaustubh.ra...@imgtec.com]
Sent: Friday, November 03, 2017 12:29 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc uni 4 tap hz and 
vt mc msa functions

From: Kaustubh Raste 

Use global mask buffer for appropriate mask load.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_uni_msa.c |  509 -
 1 file changed, 274 insertions(+), 235 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_uni_msa.c 
b/libavcodec/mips/hevc_mc_uni_msa.c
index 7d24858..993dad0 100644
--- a/libavcodec/mips/hevc_mc_uni_msa.c
+++ b/libavcodec/mips/hevc_mc_uni_msa.c
@@ -1947,7 +1947,7 @@ static void common_hz_4t_4x2_msa(uint8_t *src, int32_t 
src_stride,
 v16u8 out;
 v8i16 filt, res0;

-mask0 = LD_SB(&mc_filt_mask_arr[16]);
+mask0 = LD_SB(&ff_hevc_mask_arr[16]);
 src -= 1;

 /* rearranging filter */
@@ -1959,7 +1959,7 @@ static void common_hz_4t_4x2_msa(uint8_t *src, int32_t 
src_stride,
 LD_SB2(src, src_stride, src0, src1);
 XORI_B2_128_SB(src0, src1);
 VSHF_B2_SB(src0, src1, src0, src1, mask0, mask1, vec0, vec1);
-res0 = FILT_4TAP_DPADD_S_H(vec0, vec1, filt0, filt1);
+res0 = HEVC_FILT_4TAP_SH(vec0, vec1, filt0, filt1);
 res0 = __msa_srari_h(res0, 6);
 res0 = __msa_sat_s_h(res0, 7);
 out = PCKEV_XORI128_UB(res0, res0);
@@ -1974,7 +1974,7 @@ static void common_hz_4t_4x4_msa(uint8_t *src, int32_t 
src_stride,
 v8i16 filt, out0, out1;
 v16u8 out;

-mask0 = LD_SB(&mc_filt_mask_arr[16]);
+mask0 = LD_SB(&ff_hevc_mask_arr[16]);
 src -= 1;

 /* rearranging filter */
@@ -2001,7 +2001,7 @@ static void common_hz_4t_4x8_msa(uint8_t *src, int32_t 
src_stride,
 v16u8 out;
 v8i16 filt, out0, out1, out2, out3;

-mask0 = LD_SB(&mc_filt_mask_arr[16]);
+mask0 = LD_SB(&ff_hevc_mask_arr[16]);
 src -= 1;

 /* rearranging filter */
@@ -2038,7 +2038,7 @@ static void common_hz_4t_4x16_msa(uint8_t *src, int32_t 
src_stride,
 v16u8 out;
 v8i16 filt, out0, out1, out2, out3;

-mask0 = LD_SB(&mc_filt_mask_arr[16]);
+mask0 = LD_SB(&ff_hevc_mask_arr[16]);
 src -= 1;

 /* rearranging filter */
@@ -2098,12 +2098,11 @@ static void common_hz_4t_6w_msa(uint8_t *src, int32_t 
src_stride,
 uint8_t *dst, int32_t dst_stride,
 const int8_t *filter, int32_t height)
 {
-uint32_t loop_cnt;
 v16i8 src0, src1, src2, src3, filt0, filt1, mask0, mask1;
 v16u8 out4, out5;
 v8i16 filt, out0, out1, out2, out3;

-mask0 = LD_SB(&mc_filt_mask_arr[0]);
+mask0 = LD_SB(&ff_hevc_mask_arr[0]);
 src -= 1;

 /* rearranging filter */
@@ -2112,21 +2111,31 @@ static void common_hz_4t_6w_msa(uint8_t *src, int32_t 
src_stride,

 mask1 = mask0 + 2;

-for (loop_cnt = (height >> 2); loop_cnt--;) {
-LD_SB4(src, src_stride, src0, src1, src2, src3);
-src += (4 * src_stride);
+LD_SB4(src, src_stride, src0, src1, src2, src3);
+src += (4 * src_stride);

-XORI_B4_128_SB(src0, src1, src2, src3);
-HORIZ_4TAP_8WID_4VECS_FILT(src0, src1, src2, src3, mask0, mask1, filt0,
-   filt1, out0, out1, out2, out3);
-SRARI_H4_SH(out0, out1, out2, out3, 6);
-SAT_SH4_SH(out0, out1, out2, out3, 7);
+XORI_B4_128_SB(src0, src1, src2, src3);
+HORIZ_4TAP_8WID_4VECS_FILT(src0, src1, src2, src3, mask0, mask1, filt0,
+   filt1, out0, out1, out2, out3);
+SRARI_H4_SH(out0, out1, out2, out3, 6);
+SAT_SH4_SH(out0, out1, out2, out3, 7);
+out4 = PCKEV_XORI128_UB(out0, out1);
+out5 = PCKEV_XORI128_UB(out2, out3);
+ST6x4_UB(out4, out5, dst, dst_stride);
+dst += (4 * dst_stride);

-out4 = PCKEV_XORI128_UB(out0, out1);
-out5 = PCKEV_XORI128_UB(out2, out3);
-ST6x4_UB(out4, out5, dst, dst_stride);
-dst += (4 * dst_stride);
-}
+LD_SB4(src, src_stride, src0, src1, src2, src3);
+src += (4 * src_stride);
+
+XORI_B4_128_SB(src0, src1, src2, src3);
+HORIZ_4TAP_8WID_4VECS_FILT(src0, src1, src2, src3, mask0, mask1, filt0,
+   filt1, out0, out1, out2, out3);
+SRARI_H4_SH(out0, out1, out2, out3, 6);
+SAT_SH4_SH(out0, out1, out2, out3, 7);
+out4 = PCKEV_XORI128_UB(out0, out1);
+out5 = PCKEV_XORI128_UB(out2, out3);
+ST6x4_UB(out4, out5, dst, dst_stride);
+dst += (4 * dst_stride);
 }

 static void common_hz_4t_8x2mult_msa(uint8_t *src, int32_t src_stride,
@@ -2138,7 +2147,7 @@ static void common_hz_4t_8x2mult_msa(uint8_t *src, 
int32_t src_stride,
 v16u8 out;
 v8i16 filt, vec0, vec1, vec2, vec3;

-mask0 = LD_SB(&mc_filt_mask_arr[0]);
+mask0 = LD_SB(&ff_hevc_mask_arr[0]);
 src -= 1;

 filt = LD_SH(filter);
@@ -2172,7

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

2017-11-03 Thread Michael Niedermayer
On Fri, Nov 03, 2017 at 12:22:50PM +, Manojkumar Bhosale wrote:
> LGTM

applied


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

Avoid a single point of failure, be that a person or equipment.


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


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

2017-11-03 Thread Michael Niedermayer
On Fri, Nov 03, 2017 at 12:22:40PM +, Manojkumar Bhosale wrote:
> LGTM

will apply

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

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



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


Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc avg mc 20, 21 and 23 msa functions

2017-11-03 Thread Michael Niedermayer
On Fri, Nov 03, 2017 at 12:22:34PM +, Manojkumar Bhosale wrote:
> LGTM

will apply

thx

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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


Re: [FFmpeg-devel] [PATCH] avformat/dv : change audio format endianess to BE

2017-11-03 Thread Michael Niedermayer
On Tue, Oct 17, 2017 at 08:38:21PM +0300, Александр Слободенюк wrote:
> Hello again!
> 
> I  have checked (updated and fixed) the patch on BE machine (qemu-mips with 
> BE linux kernel, lscpu shows big endian): the CRCs of the sound are the
> same:
> 
> (first link was get directly from 
> http://www.mediafire.com/file/8agcdgs2f9kqlbi/submarine.dv)
> wget 
> http://download1643.mediafireuserdownload.com/h3we3e4t26tg/8agcdgs2f9kqlbi/submarine.dv
> wget https://trac.ffmpeg.org/raw-attachment/ticket/1589/A1590.dv
> 
> ./ffmpeg -i submarine.dv audio-submarine.wav
> ./ffmpeg -i A1589.dv audio-12bit.wav
> 
> (I  had  to  extract the audio out because with video CRCs are not the
> same on BE and LE machines on master version of ffmpeg)
> 
> ./ffmpeg -i audio-submarine.wav -f crc - 2>/dev/null
> CRC=0x96b2ce8c
> 
> ./ffmpeg -i audio-12bit.wav -f crc - 2>/dev/null
> CRC=0x01c9318a
> 
> --
> So, this CRCs are the same for all of the variants:
> 
> - not patched ffmpeg on LE machine
> - patched ffmpeg on LE machine
> - not patched ffmpeg on BE machine
> - patched ffmpeg on BE machine
> --
> 
> Attaching the updated to current master patch.

>  dv.c  |   30 ++
>  dvenc.c   |9 -
>  mov.c |2 +-
>  version.h |2 +-
>  4 files changed, 16 insertions(+), 27 deletions(-)
> 9e8192ee964aaf97bc14ab13f10718cf6bfd1e45  
> 0001-avformat-dv-change-audio-format-endianess-to-BE.patch
> From 4cdb0d8b79d91c94480c292847311e51f1b25704 Mon Sep 17 00:00:00 2001
> From: Aleksandr Slobodeniuk 
> Date: Tue, 17 Oct 2017 17:59:30 +0300

> Subject: [PATCH] avformat/dv : change audio format endianess to BE

This does not explain why this change is done.
does it fix a bug?
does it make the code faster?

The commit message should explain this

> 
> ---
>  libavformat/dv.c  | 30 ++
>  libavformat/dvenc.c   |  9 -
>  libavformat/mov.c |  2 +-
>  libavformat/version.h |  2 +-
>  4 files changed, 16 insertions(+), 27 deletions(-)
> 
> diff --git a/libavformat/dv.c b/libavformat/dv.c
> index 06de044..df5fec0 100644
> --- a/libavformat/dv.c
> +++ b/libavformat/dv.c
> @@ -116,13 +116,13 @@ static const int dv_audio_frequency[3] = {
>   * 3. Audio is always returned as 16-bit linear samples: 12-bit nonlinear 
> samples
>   *are converted into 16-bit linear ones.
>   */
> -static int dv_extract_audio(const uint8_t *frame, uint8_t **ppcm,
> +static int dv_extract_audio(const uint8_t *frame, uint16_t **ppcm,
>  const AVDVProfile *sys)
>  {
>  int size, chan, i, j, d, of, smpls, freq, quant, half_ch;
> -uint16_t lc, rc;
> +uint16_t lc, rc, *pcm;
>  const uint8_t *as_pack;
> -uint8_t *pcm, ipcm;
> +uint8_t ipcm;
>  
>  as_pack = dv_extract_pack(frame, dv_audio_source);
>  if (!as_pack)/* No audio ? */
> @@ -177,13 +177,9 @@ static int dv_extract_audio(const uint8_t *frame, 
> uint8_t **ppcm,
>  if (of * 2 >= size)
>  continue;
>  
> -/* FIXME: maybe we have to admit that DV is a
> - * big-endian PCM */
> -pcm[of * 2] = frame[d + 1];
> -pcm[of * 2 + 1] = frame[d];
> -
> -if (pcm[of * 2 + 1] == 0x80 && pcm[of * 2] == 0x00)
> -pcm[of * 2 + 1] = 0;

> +pcm[of] = ((uint16_t*)frame)[d/2];

Divisions should be avoided in the inner loops as they can be slow

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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


[FFmpeg-devel] Avoid corrupting diagnostic state with _Pragma changes.

2017-11-03 Thread Dale Curtis
The macros for ICC and MSVC correctly push and pop the diagnostic
state of the compiler when disabling deprecation warnings. The
ones for clang/gcc should do the same. Without this, if a blanket
deprecation warning is applied to the code base it'll be flipped
back on incorrectly with FF_ENABLE_DEPRECATION_WARNINGS.

Signed-off-by: Dale Curtis 
From 73a488e07a328d05aa2b507a551b0c1e4b8a81c8 Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Fri, 3 Nov 2017 17:10:55 -0700
Subject: [PATCH] Avoid corrupting diagnostic state with _Pragma changes.

The macros for ICC and MSVC correctly push and pop the diagnostic
state of the compiler when disabling deprecation warnings. The
ones for clang/gcc should do the same. Without this, if a blanket
deprecation warning is applied to the code base it'll be flipped
back on incorrectly with FF_ENABLE_DEPRECATION_WARNINGS.

Signed-off-by: Dale Curtis 
---
 libavutil/internal.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/internal.h b/libavutil/internal.h
index 6f92f71e8e..3e6c54e58a 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -77,8 +77,8 @@
 #define FF_DISABLE_DEPRECATION_WARNINGS __pragma(warning(push)) __pragma(warning(disable:4996))
 #define FF_ENABLE_DEPRECATION_WARNINGS  __pragma(warning(pop))
 #else
-#define FF_DISABLE_DEPRECATION_WARNINGS _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
-#define FF_ENABLE_DEPRECATION_WARNINGS  _Pragma("GCC diagnostic warning \"-Wdeprecated-declarations\"")
+#define FF_DISABLE_DEPRECATION_WARNINGS _Pragma("GCC diagnostic push") _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
+#define FF_ENABLE_DEPRECATION_WARNINGS  _Pragma("GCC diagnostic pop")
 #endif
 #else
 #define FF_DISABLE_DEPRECATION_WARNINGS
-- 
2.15.0.403.gc27cc4dac6-goog

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


[FFmpeg-devel] [PATCH 1/3] avcodec/exr: fix undefined shift in pxr24_uncompress()

2017-11-03 Thread Michael Niedermayer
Fixes: runtime error: left shift of 255 by 24 places cannot be represented in 
type 'int'
Fixes: 3787/clusterfuzz-testcase-minimized-5728764920070144

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/exr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 0b755db3cb..b1ecde4ebd 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -855,7 +855,7 @@ static int pxr24_uncompress(EXRContext *s, const uint8_t 
*src,
 in = ptr[2] + td->xsize;
 
 for (j = 0; j < td->xsize; ++j) {
-uint32_t diff = (*(ptr[0]++) << 24) |
+uint32_t diff = ((unsigned)*(ptr[0]++) << 24) |
 (*(ptr[1]++) << 16) |
 (*(ptr[2]++) << 8);
 pixel += diff;
-- 
2.15.0

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


[FFmpeg-devel] [PATCH 2/3] avcodec/h264idct_template: Fix integer overflows in ff_h264_idct8_add()

2017-11-03 Thread Michael Niedermayer
Fixes: runtime error: signed integer overflow: -503316480 + -2013265038 cannot 
be represented in type 'int'
Fixes: 3805/clusterfuzz-testcase-minimized-6578427831255040

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/h264idct_template.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/h264idct_template.c b/libavcodec/h264idct_template.c
index fbd07cb8d5..7526bdd812 100644
--- a/libavcodec/h264idct_template.c
+++ b/libavcodec/h264idct_template.c
@@ -91,10 +91,10 @@ void FUNCC(ff_h264_idct8_add)(uint8_t *_dst, int16_t 
*_block, int stride){
 const int a5 = -block[i+1*8] + (unsigned)block[i+7*8] + block[i+5*8] + 
(block[i+5*8]>>1);
 const int a7 =  block[i+3*8] + (unsigned)block[i+5*8] + block[i+1*8] + 
(block[i+1*8]>>1);
 
-const int b1 = (a7>>2) + a1;
-const int b3 =  a3 + (a5>>2);
-const int b5 = (a3>>2) - a5;
-const int b7 =  a7 - (a1>>2);
+const int b1 = (a7>>2) + (unsigned)a1;
+const int b3 =  (unsigned)a3 + (a5>>2);
+const int b5 = (a3>>2) - (unsigned)a5;
+const int b7 =  (unsigned)a7 - (a1>>2);
 
 block[i+0*8] = b0 + b7;
 block[i+7*8] = b0 - b7;
-- 
2.15.0

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


[FFmpeg-devel] [PATCH 3/3] avcodec/dvbsubdec: Avoid re-computing clut

2017-11-03 Thread Michael Niedermayer
Fixes: Timeout
Fixes: 3218/clusterfuzz-testcase-5390672154591232

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/dvbsubdec.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/libavcodec/dvbsubdec.c b/libavcodec/dvbsubdec.c
index 85a59f3ced..c60aa9a34d 100644
--- a/libavcodec/dvbsubdec.c
+++ b/libavcodec/dvbsubdec.c
@@ -96,6 +96,9 @@ typedef struct DVBSubRegion {
 int clut;
 int bgcolor;
 
+uint8_t computed_clut[4*256];
+int has_computed_clut;
+
 uint8_t *pbuf;
 int buf_size;
 int dirty;
@@ -647,7 +650,7 @@ static int dvbsub_read_8bit_string(AVCodecContext *avctx,
 return pixels_read;
 }
 
-static void compute_default_clut(AVSubtitleRect *rect, int w, int h)
+static void compute_default_clut(uint8_t *clut, AVSubtitleRect *rect, int w, 
int h)
 {
 uint8_t list[256] = {0};
 uint8_t list_inv[256];
@@ -703,7 +706,7 @@ static void compute_default_clut(AVSubtitleRect *rect, int 
w, int h)
 count = FFMAX(i - 1, 1);
 for (i--; i>=0; i--) {
 int v = i*255/count;
-AV_WN32(rect->data[1] + 4*list_inv[i], RGBA(v/2,v,v/2,v));
+AV_WN32(clut + 4*list_inv[i], RGBA(v/2,v,v/2,v));
 }
 }
 
@@ -809,8 +812,14 @@ static int save_subtitle_set(AVCodecContext *avctx, 
AVSubtitle *sub, int *got_ou
 
 memcpy(rect->data[0], region->pbuf, region->buf_size);
 
-if ((clut == &default_clut && ctx->compute_clut == -1) || 
ctx->compute_clut == 1)
-compute_default_clut(rect, rect->w, rect->h);
+if ((clut == &default_clut && ctx->compute_clut == -1) || 
ctx->compute_clut == 1) {
+if (!region->has_computed_clut) {
+compute_default_clut(region->computed_clut, rect, rect->w, 
rect->h);
+region->has_computed_clut = 1;
+}
+
+memcpy(rect->data[1], region->computed_clut, 
sizeof(region->computed_clut));
+}
 
 #if FF_API_AVPICTURE
 FF_DISABLE_DEPRECATION_WARNINGS
@@ -959,6 +968,7 @@ static void dvbsub_parse_pixel_data_block(AVCodecContext 
*avctx, DVBSubObjectDis
 }
 }
 
+region->has_computed_clut = 0;
 }
 
 static int dvbsub_parse_object_segment(AVCodecContext *avctx,
-- 
2.15.0

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


Re: [FFmpeg-devel] [PATCH]lavc/dnxhddata: Do not print frame rates with supported profiles

2017-11-03 Thread Carl Eugen Hoyos
2017-10-31 3:05 GMT+01:00 Carl Eugen Hoyos :
> Hi!
>
> Attached patch is meant to fix ticket #4815: Nobody can maintain the
> list of frame-rates, the current output primarily leads to confusion
> instead of helping users.

I will commit this patch if there are no objections.

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


Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

2017-11-03 Thread Carl Eugen Hoyos
2017-10-24 18:40 GMT+02:00 Bjorn Roche :

> - I don’t know if/how to update the FATE tests.

A quick way (that needs some double-checking) is:
$ make GEN=1 SAMPLES=fate-suite fate

(This overwrites all values with the new output.)

Is the new side-data unavoidable?
(Would the only alternative be to merge the muxer into the
encoder?)

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


Re: [FFmpeg-devel] [PATCH]lavc/alac: Avoid allocating huge memory blocks for malicious alac input.

2017-11-03 Thread Carl Eugen Hoyos
2017-11-01 17:03 GMT+01:00 Carl Eugen Hoyos :
> 2017-11-01 17:01 GMT+01:00 Paul B Mahol :
>> On 11/1/17, Carl Eugen Hoyos  wrote:
>>> 2017-11-01 15:40 GMT+01:00 Paul B Mahol :
 On 11/1/17, Carl Eugen Hoyos  wrote:
> Hi!
>
> It appears to me that the alac decoder can be used for DoS,
> the attached patch limits the maximum frame size to eight
> times the default value.
> (Higher values brake our encoder here.)
>
> Please comment and / or suggest another value, Carl Eugen
>

 So alac encoder can not handle bigger frames or what?

 Look at other alac encoders, what are their limit on frame size?
>>>
>>> I am not sure if it is enough to look on Apple's encoder, after
>>> all, their decoder looks exploitable (or maybe I miss something).
>>>
 The limit you set is too low IMHO.
>>>
>>> Could you suggest a limit that's below the several-GB area?
>>
>> I remmeber some lossless audio codecs can have very big
>> frames, several MB.
>
> So what about 4096 * 4096 as an arbitrary limit?

Any opinion?

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


Re: [FFmpeg-devel] [PATCH]tests/fate: Fix fitsdec-gbrap16 on big-endian hardware

2017-11-03 Thread Carl Eugen Hoyos
2017-11-02 23:44 GMT+01:00 Michael Niedermayer :
> On Wed, Nov 01, 2017 at 09:41:58PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes fate-fitsdec on big-endian.
>>
>> Please comment, Carl Eugen
>
>>  b/tests/fate/fits.mak  |4 ++--
>>  b/tests/ref/fate/fitsdec-gbrap16le |6 ++
>>  tests/ref/fate/fitsdec-gbrap16 |6 --
>>  3 files changed, 8 insertions(+), 8 deletions(-)
>> c39c8f21e9d3b2c15b6ac9ed9e7b2d0b864b4863  
>> 0001-tests-fate-Fix-fitsdec-gbrap16-test-on-big-endian-ha.patch
>> From 61032df04a35d7cc939fa41e71ee3f882c3658c3 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Wed, 1 Nov 2017 21:39:33 +0100
>> Subject: [PATCH] tests/fate: Fix fitsdec-gbrap16 test on big-endian hardware.
>
> LGTM

Patch applied.

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


Re: [FFmpeg-devel] PATCH] h2645: Allocate a single buffer per packet. Drastically reduces memory usage on pathological streams.

2017-11-03 Thread Carl Eugen Hoyos
2017-11-03 19:23 GMT+01:00 Kieran Kunhya :
> This patch fixes very high memory usage on pathological streams.

Please mention the ticket number in the commit message.

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


Re: [FFmpeg-devel] [PATCH] Add android_capture indev

2017-11-03 Thread Carl Eugen Hoyos
2017-11-03 16:21 GMT+01:00 Felix Matouschek :

>>> +if (format == IMAGE_FORMAT_ANDROID) {
>>
>> It would be better to support as many pixel formats as possible.
>
> For now I settled on YUV420P, as the API doc states all
> devices must support it. I do not have the resources to
> test every format.

You could add those that you can test (but yuv420p is of
course a very useful start).

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


Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block

2017-11-03 Thread Thilo Borgmann
Am 03.11.17 um 21:13 schrieb Paul B Mahol:
> On 11/3/17, Thilo Borgmann  wrote:
>> Am 02.11.17 um 21:32 schrieb Umair Khan:
>>> Hi,
>>>
>>> On Fri, Oct 20, 2017 at 1:44 AM, Ronald S. Bultje 
>>> wrote:

 Hi,

 On Thu, Oct 19, 2017 at 4:03 PM, Umair Khan  wrote:

> I tried decoding the file in both the cases and I don't see any
> address related error in the console while decoding. Following is the
> output after I apply the patch :-
>
 [..]

> Is there something which I'm missing?
>

 You need to run under valgrind or compile with address sanitizer support:
 configure --toolchain=gcc-asan or --toolchain=clang-asan, depending on
 the
 name of clang on your system.
>>>
>>> Thanks for the help. I was finally able to reproduce the error.
>>>
>>> I have been trying to debug this heap-buffer-overflow error for some
>>> days. I have finally found the source of the issue at least.
>>>
>>> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/alsdec.c#L934
>>>
>>> raw_samples pointer is overflowing inside that loop. I haven't thought
>>> of a proper fix for this yet. I'll look at the documentation to
>>> understand the logic first.
>>>
>>> However, in case someone (Thilo?) already has some idea on fixing it,
>>> that'd be great.
>>
>> I don't remember exactly but you will need to figure out what the actual
>> limit is for opt_order.
>>
>> If I could give a closer hint, this bug would have been fixed a long time
>> ago...
>>
>> You could have a look at the reference codec code and look where they limit
>> that opt_order/buffer size.
> 
> There are already patches by Michael and me which deals with this bug.
> Which you do not want to apply and without real proof.

Yes and no. If you search some more in the archives, you'll also find
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202513.html

The idea of Michael and you that you are referring to, is basically to double a 
part of buffer size calculation to be "more" failsafe. However, especially if 
Umair wants to dig in now, we should better solve the root of the issue and 
find the actual required buffer size instead of guessing, don't we?

We cannot accept the removal of the predictor order check alltogether because 
of the fuzzed file we have. This is what I vetoed in the past (IIRC) and has 
been suggested by myself, Umair and I think Paul, too.
Wrong?

What we could do and I would not veto on, would be to have a bigger buffer like 
Michael's in
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195113.html
However, this should be tested again and should get a comment in the code 
because that buffer size is not reflected in the spec as far as I can tell.
Also, this would not actually remove that bug from my own list about ALS. That 
might be fine with you but not the way I think we should proceed. I'd rather 
love to see Umair fixing it correctly.

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


Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block

2017-11-03 Thread Paul B Mahol
On 11/3/17, Thilo Borgmann  wrote:
> Am 02.11.17 um 21:32 schrieb Umair Khan:
>> Hi,
>>
>> On Fri, Oct 20, 2017 at 1:44 AM, Ronald S. Bultje 
>> wrote:
>>>
>>> Hi,
>>>
>>> On Thu, Oct 19, 2017 at 4:03 PM, Umair Khan  wrote:
>>>
 I tried decoding the file in both the cases and I don't see any
 address related error in the console while decoding. Following is the
 output after I apply the patch :-

>>> [..]
>>>
 Is there something which I'm missing?

>>>
>>> You need to run under valgrind or compile with address sanitizer support:
>>> configure --toolchain=gcc-asan or --toolchain=clang-asan, depending on
>>> the
>>> name of clang on your system.
>>
>> Thanks for the help. I was finally able to reproduce the error.
>>
>> I have been trying to debug this heap-buffer-overflow error for some
>> days. I have finally found the source of the issue at least.
>>
>> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/alsdec.c#L934
>>
>> raw_samples pointer is overflowing inside that loop. I haven't thought
>> of a proper fix for this yet. I'll look at the documentation to
>> understand the logic first.
>>
>> However, in case someone (Thilo?) already has some idea on fixing it,
>> that'd be great.
>
> I don't remember exactly but you will need to figure out what the actual
> limit is for opt_order.
>
> If I could give a closer hint, this bug would have been fixed a long time
> ago...
>
> You could have a look at the reference codec code and look where they limit
> that opt_order/buffer size.

There are already patches by Michael and me which deals with this bug.
Which you do not want to apply and without real proof.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] HW accelerator: Indicate when HW acceleration is in use

2017-11-03 Thread Michele Lim
Having clear indication of when a hardware accelerator is in
operation prevents false assumptions, for e.g., in situations when
the command line argument inadvertently omits options for enabling
it, resulting to the framework silently switching to the SW path.

Signed-off-by: Michele Lim 
---
 fftools/ffmpeg_hw.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/fftools/ffmpeg_hw.c b/fftools/ffmpeg_hw.c
index a4d1cad..f071746 100644
--- a/fftools/ffmpeg_hw.c
+++ b/fftools/ffmpeg_hw.c
@@ -306,6 +306,8 @@ int hw_device_setup_for_decode(InputStream *ist)
 if (!ist->dec_ctx->hw_device_ctx)
 return AVERROR(ENOMEM);
 
+/* Indicate HW accelerator has been prepared for decode */
+av_log(ist->dec_ctx, AV_LOG_INFO, "HW accelerator prepared for decode: 
%s\n", av_hwdevice_get_type_name(type));
 return 0;
 }
 
@@ -331,6 +333,9 @@ int hw_device_setup_for_encode(OutputStream *ost)
 // No device required.
 return 0;
 }
+
+/* Indicate HW accelerator has been prepared for encode */
+av_log(ost->enc_ctx, AV_LOG_INFO, "HW accelerator prepared for encode: 
%s\n", av_hwdevice_get_type_name(type));
 }
 
 static int hwaccel_retrieve_data(AVCodecContext *avctx, AVFrame *input)
-- 
2.7.4

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


Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block

2017-11-03 Thread Thilo Borgmann
Am 02.11.17 um 21:32 schrieb Umair Khan:
> Hi,
> 
> On Fri, Oct 20, 2017 at 1:44 AM, Ronald S. Bultje  wrote:
>>
>> Hi,
>>
>> On Thu, Oct 19, 2017 at 4:03 PM, Umair Khan  wrote:
>>
>>> I tried decoding the file in both the cases and I don't see any
>>> address related error in the console while decoding. Following is the
>>> output after I apply the patch :-
>>>
>> [..]
>>
>>> Is there something which I'm missing?
>>>
>>
>> You need to run under valgrind or compile with address sanitizer support:
>> configure --toolchain=gcc-asan or --toolchain=clang-asan, depending on the
>> name of clang on your system.
> 
> Thanks for the help. I was finally able to reproduce the error.
> 
> I have been trying to debug this heap-buffer-overflow error for some
> days. I have finally found the source of the issue at least.
> 
> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/alsdec.c#L934
> 
> raw_samples pointer is overflowing inside that loop. I haven't thought
> of a proper fix for this yet. I'll look at the documentation to
> understand the logic first.
> 
> However, in case someone (Thilo?) already has some idea on fixing it,
> that'd be great.

I don't remember exactly but you will need to figure out what the actual limit 
is for opt_order.

If I could give a closer hint, this bug would have been fixed a long time ago...

You could have a look at the reference codec code and look where they limit 
that opt_order/buffer size.

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


Re: [FFmpeg-devel] order T-shirts

2017-11-03 Thread Thilo Borgmann
Hi,

> My suggestion would be, that we could order Thomas' design for all
> the developers and requests I've recieved by now and that we take
> Lou's for our stock for give-aways during conferences. Just my
> thinking...

no further comments so I did order alike. Should recieve them next week and the 
first of you will have their shirts soon thereafter.

-Thilo

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


[FFmpeg-devel] PATCH] h2645: Allocate a single buffer per packet. Drastically reduces memory usage on pathological streams.

2017-11-03 Thread Kieran Kunhya
This patch fixes very high memory usage on pathological streams.


0001-h2645-Allocate-a-single-buffer-per-packet.-Drastical.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] web/template_head2: Remove net neutrality script

2017-11-03 Thread Kieran Kunhya
On Thu, 2 Nov 2017 at 21:12 Lou Logan  wrote:

> I would prefer it if the site did not involve politics.
>
> I implemented a client side solution using an ad blocker, so consider
> this patch dropped.
>

I agree, the popup is annoying.
I would like to save the bees, whales, environment, 25p freddo bar etc but
FFmpeg is not the place to do it.

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


[FFmpeg-devel] [PATCH] avcodec/xan: Check for bitstream end in xan_huffman_decode()

2017-11-03 Thread Michael Niedermayer
Fixes: Timeout
Fixes: 3707/clusterfuzz-testcase-6465922706440192

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/xan.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/xan.c b/libavcodec/xan.c
index 8b4ec82405..1ccf164847 100644
--- a/libavcodec/xan.c
+++ b/libavcodec/xan.c
@@ -131,7 +131,10 @@ static int xan_huffman_decode(uint8_t *dest, int dest_len,
 return ret;
 
 while (val != 0x16) {
-unsigned idx = val - 0x17 + get_bits1(&gb) * byte;
+unsigned idx;
+if (get_bits_left(&gb) < 1)
+return AVERROR_INVALIDDATA;
+idx = val - 0x17 + get_bits1(&gb) * byte;
 if (idx >= 2 * byte)
 return AVERROR_INVALIDDATA;
 val = src[idx];
-- 
2.15.0

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


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

2017-11-03 Thread Aman Gupta
On Fri, Nov 3, 2017 at 4:10 AM, Jeyapal, Karthick 
wrote:

> >On 11/3/17, 2:18 PM, "Nicolas George"  wrote:
>
> >I strongly oppose this: we do not want new global state.
> I also agree. I am open to suggestions, and I would be happy re-implement
> this feature without new global state.
>
> >Also, I am very doubtful about the feature itself. It is public, and as
> >such should be usable for many uses, but I do not see it useful for
> >anything but patches 3 and 4.
> Well beyond patch 3 and 4, this feature is usable for HLS player, DASH
> player and DASH encoder.
> Any other segmented streaming standard would also benefit from this
> feature.
> With internet streaming having moved towards segmented streaming
> standards, I would think this feature is very useful.
> Right now, the performance of hlsenc, dashenc etc., suffers terribly for
> http output with lower segment sizes.
> Also, this feature could be extended for HTTPS/TLS connections as well.
>
> >Furthermore, it is a break of abstraction,
> >sockets lose their simple and clear API, they are not really closed when
> >they are closed, etc.
> Technically it doesn’t break any abstraction. Internally reusing socket
> connections,
> could be thought of as an implementation level detail to improve
> performance.
> For example, android HTTP APIs reuse the sockets internally to improve
> performance
> without affecting the abstraction.
> https://developer.android.com/reference/java/net/HttpURLConnection.html
>
> >If you are trying to implement keepalive HTTP for HLS, then most of the
> >code should be in http.c and hls*.c, not tcp.c.
> That’s a very good point. I had also thought in similar lines. Here is an
> approach that I could think of.
> - Open just one http connection from hlsenc.c
> - Somehow call http_shutdown instead of http_close during end of
> segments/file
> - For opening a new segment/file hlsenc calls http_write (with relevant
> http headers
> composed by hlsenc) instead of a fresh http_open
> If ffmpeg maintainers agree to the above approach, I am willing to
> implement it
> that way.
>


I recently implemented keepalive support in the hls demuxer, and have been
using it with a lot of success. See my patchset:
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/217353.html

Aman


>
> Or if anybody proposes a better approach, I am willing to consider that as
> well.
>
> >Regards,
> >
> >--
> >  Nicolas George
>
>
> ___
> 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] Add android_capture indev

2017-11-03 Thread Felix Matouschek

Hello,

Am 02.11.2017 um 14:40 schrieb Nicolas George:

When reading the subject of the mail, I first thought it would be about
screen capture. Furthermore, there is code for audio, but it is not
connected to anything, and it does not seem that the android API
connects audio and video together.

For all these reasons, I suggest you name this device maybe
android_camera, and keep android_mic for audio capture.

Will do so.


You are parsing the "filename" of the device into a key=value syntax.
This is not a good idea, and I really would not like another key=value
parser in the code base.

How do cameraIds look? If the string values are friendly enough, they
can be used as filenames as is.
I removed parsing of the "filename" and replaced it with a 
"camera_index" parameter.


I do not know how cameraIds are formed on different devices, seems like 
internal cameras
just use numbers but external devices may use a string. I do not have 
multiple devices to test
this. In my opionion an index for the list of all cameras should be 
sufficient.



Can the error be translated into a human-readable message?

Will try to do that, I need to add the according strings for it somehow.


Is it really the official way of getting the resolution and format of
the video? If so, were the Android people drunk?

Seem like it.


+if (format == IMAGE_FORMAT_ANDROID) {

It would be better to support as many pixel formats as possible.
For now I settled on YUV420P, as the API doc states all devices must 
support it. I do not

have the resources to test every format.


+side_data = av_packet_new_side_data(&pktl_next->pkt,
+AV_PKT_DATA_DISPLAYMATRIX, sizeof(display_matrix));

It would probably be best to avoid sending the side data repeatedly if
it does not change.
Is it sufficient to append the matrix just once? I thought every 
AVPacket could have a different matrix.



+error:
+pthread_mutex_unlock(&ctx->mutex);
+AImage_delete(image);
+
+return;

It seems error conditions are not taken into account. Is it on purpose?
You mean for example ENOMEM if allocating fails and aborting the whole 
"session"? Could do that.


Regards, 


I working on addressing all issues.

Greetings,
Felix

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


Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

2017-11-03 Thread 刘歧

> 在 2017年11月3日,18:20,Dixit, Vishwanath  写道:
> 
>> On 11/3/17, 3:24 PM, "Steven Liu"  wrote:
>> make fate-filter-hls-append
>> 
>>   you can grep hls append in the file
> I think that is also a test for hls decoder. Basically, I am trying to find, 
> if there are any basic tests available for hls encoder.
look at your mail title please!
and read the test case which i write for the fate-filter-hls-append
> 
> Regards,
> Vishwanath
> 
> ___
> 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] snowenc: fix use of deprecated API

2017-11-03 Thread Michael Niedermayer
On Thu, Nov 02, 2017 at 08:12:48PM +0100, ffm...@fratti.ch wrote:
> From: Nicolas Frattaroli 
> 
> Replace avcodec_get_chroma_sub_sample with the recommended
> av_pix_fmt_get_chroma_sub_sample, which fixes a compilation warning.
> ---
>  libavcodec/snowenc.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)

applied

thanks

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

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


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


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

2017-11-03 Thread Manojkumar Bhosale
LGTM

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

From: Kaustubh Raste 

Use global mask buffer for appropriate mask load.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_biw_msa.c |  587 -
 1 file changed, 247 insertions(+), 340 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_biw_msa.c 
b/libavcodec/mips/hevc_mc_biw_msa.c
index 75c1c7a..0e5f8a0 100644
--- a/libavcodec/mips/hevc_mc_biw_msa.c
+++ b/libavcodec/mips/hevc_mc_biw_msa.c
@@ -2633,22 +2633,21 @@ static void hevc_hz_biwgt_4t_4x2_msa(uint8_t *src0_ptr,
  uint8_t *dst,
  int32_t dst_stride,
  const int8_t *filter,
- int32_t height,
  int32_t weight0,
  int32_t weight1,
  int32_t offset0,
  int32_t offset1,
  int32_t rnd_val)
 {
-int32_t offset, weight;
+int32_t offset, weight, constant;
 v8i16 filt0, filt1;
 v16i8 src0, src1;
 v8i16 in0, in1;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20 };
+v16i8 mask0 = LD_SB(&ff_hevc_mask_arr[16]);
 v16i8 mask1, vec0, vec1;
 v8i16 dst0;
 v4i32 dst0_r, dst0_l;
-v8i16 filter_vec, const_vec;
+v8i16 out0, filter_vec;
 v4i32 weight_vec, offset_vec, rnd_vec;
 
 src0_ptr -= 1;
@@ -2661,9 +2660,10 @@ static void hevc_hz_biwgt_4t_4x2_msa(uint8_t *src0_ptr,
 offset = (offset0 + offset1) << rnd_val;
 weight0 = weight0 & 0x;
 weight = weight0 | (weight1 << 16);
+constant = 128 * weight1;
+constant <<= 6;
+offset += constant;
 
-const_vec = __msa_ldi_h(128);
-const_vec <<= 6;
 offset_vec = __msa_fill_w(offset);
 weight_vec = __msa_fill_w(weight);
 rnd_vec = __msa_fill_w(rnd_val + 1);
@@ -2674,18 +2674,16 @@ static void hevc_hz_biwgt_4t_4x2_msa(uint8_t *src0_ptr,
 XORI_B2_128_SB(src0, src1);
 
 VSHF_B2_SB(src0, src1, src0, src1, mask0, mask1, vec0, vec1);
-dst0 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst0, dst0);
+dst0 = HEVC_FILT_4TAP_SH(vec0, vec1, filt0, filt1);
 
 ILVRL_H2_SW(dst0, in0, dst0_r, dst0_l);
 dst0_r = __msa_dpadd_s_w(offset_vec, (v8i16) dst0_r, (v8i16) weight_vec);
 dst0_l = __msa_dpadd_s_w(offset_vec, (v8i16) dst0_l, (v8i16) weight_vec);
 SRAR_W2_SW(dst0_r, dst0_l, rnd_vec);
-dst0_r = CLIP_SW_0_255(dst0_r);
-dst0_l = CLIP_SW_0_255(dst0_l);
-
-HEVC_PCK_SW_SB2(dst0_l, dst0_r, dst0_r);
-ST4x2_UB(dst0_r, dst, dst_stride);
+dst0_r = (v4i32) __msa_pckev_h((v8i16) dst0_l, (v8i16) dst0_r);
+out0 = CLIP_SH_0_255(dst0_r);
+out0 = (v8i16) __msa_pckev_b((v16i8) out0, (v16i8) out0);
+ST4x2_UB(out0, dst, dst_stride);
 }
 
 static void hevc_hz_biwgt_4t_4x4_msa(uint8_t *src0_ptr,
@@ -2695,22 +2693,21 @@ static void hevc_hz_biwgt_4t_4x4_msa(uint8_t *src0_ptr,
  uint8_t *dst,
  int32_t dst_stride,
  const int8_t *filter,
- int32_t height,
  int32_t weight0,
  int32_t weight1,
  int32_t offset0,
  int32_t offset1,
  int32_t rnd_val)
 {
-int32_t offset, weight;
+int32_t offset, weight, constant;
 v8i16 filt0, filt1;
 v16i8 src0, src1, src2, src3;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20 };
+v16i8 mask0 = LD_SB(&ff_hevc_mask_arr[16]);
 v16i8 mask1;
 v8i16 dst0, dst1;
 v16i8 vec0, vec1;
 v8i16 in0, in1, in2, in3;
-v8i16 filter_vec, const_vec;
+v8i16 filter_vec;
 v4i32 weight_vec, offset_vec, rnd_vec;
 
 src0_ptr -= 1;
@@ -2724,9 +2721,10 @@ static void hevc_hz_biwgt_4t_4x4_msa(uint8_t *src0_ptr,
 offset = (offset0 + offset1) << rnd_val;
 weight0 = weight0 & 0x;
 weight = weight0 | (weight1 << 16);
+constant = 128 * weight1;
+constant <<= 6;
+offset += constant;
 
-const_vec = __msa_ldi_h(128);
-const_vec <<= 6;
 offset_vec = __msa_fill_w(offset);
 weight_vec = __msa_fill_w(weight);
 rnd_vec = __msa_fill_w(rnd_val + 1);
@@ -2737,11 +2735,9 @@ static void hevc_hz_biwgt_4t_4x4_msa(uint8_t *src0_ptr,
 ILVR_D2_SH(in1, in0, in3, in2, in0, in1);
 
 VSHF_B2_SB(src0, src1, src0, src1, mask0, mask1, vec0, vec1);
-dst0 = const_vec;

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

2017-11-03 Thread Manojkumar Bhosale
LGTM

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

From: Kaustubh Raste 

Use global mask buffer for appropriate mask load.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_bi_msa.c |  428 +++---
 1 file changed, 210 insertions(+), 218 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_bi_msa.c b/libavcodec/mips/hevc_mc_bi_msa.c
index 9c03ef8..e9c9184 100644
--- a/libavcodec/mips/hevc_mc_bi_msa.c
+++ b/libavcodec/mips/hevc_mc_bi_msa.c
@@ -2183,7 +2183,7 @@ static void hevc_hz_bi_4t_4x2_msa(uint8_t *src0_ptr,
 v8i16 filt0, filt1;
 v16i8 src0, src1, dst0, vec0, vec1;
 v8i16 in0, in1;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20 };
+v16i8 mask0 = LD_SB(&ff_hevc_mask_arr[16]);
 v16i8 mask1;
 v8i16 tmp0;
 v8i16 filter_vec, const_vec;
@@ -2226,7 +2226,8 @@ static void hevc_hz_bi_4t_4x4_msa(uint8_t *src0_ptr,
 v8i16 filt0, filt1;
 v16i8 src0, src1, src2, src3, dst0, vec0, vec1;
 v8i16 in0, in1, in2, in3;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20 };
+v16i8 vec2, vec3;
+v16i8 mask0 = LD_SB(&ff_hevc_mask_arr[16]);
 v16i8 mask1;
 v8i16 tmp0, tmp1;
 v8i16 filter_vec, const_vec;
@@ -2247,12 +2248,12 @@ static void hevc_hz_bi_4t_4x4_msa(uint8_t *src0_ptr,
 ILVR_D2_SH(in1, in0, in3, in2, in0, in1);
 XORI_B4_128_SB(src0, src1, src2, src3);
 
-VSHF_B2_SB(src0, src1, src0, src1, mask0, mask1, vec0, vec1);
 tmp0 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, tmp0, tmp0);
-VSHF_B2_SB(src2, src3, src2, src3, mask0, mask1, vec0, vec1);
 tmp1 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, tmp1, tmp1);
+VSHF_B2_SB(src0, src1, src2, src3, mask0, mask0, vec0, vec1);
+VSHF_B2_SB(src0, src1, src2, src3, mask1, mask1, vec2, vec3);
+DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt0, filt1, filt1, tmp0, 
tmp1,
+ tmp0, tmp1);
 HEVC_BI_RND_CLIP2(in0, in1, tmp0, tmp1, 7, tmp0, tmp1);
 dst0 = __msa_pckev_b((v16i8) tmp1, (v16i8) tmp0);
 
@@ -2273,8 +2274,8 @@ static void hevc_hz_bi_4t_4x8multiple_msa(uint8_t 
*src0_ptr,
 v16i8 src0, src1, src2, src3, src4, src5, src6, src7;
 v16i8 dst0, dst1;
 v8i16 in0, in1, in2, in3, in4, in5, in6, in7;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20 };
-v16i8 mask1, vec0, vec1;
+v16i8 mask0 = LD_SB(&ff_hevc_mask_arr[16]);
+v16i8 mask1, vec0, vec1, vec2, vec3;
 v8i16 tmp0, tmp1, tmp2, tmp3;
 v8i16 filter_vec, const_vec;
 
@@ -2300,18 +2301,18 @@ static void hevc_hz_bi_4t_4x8multiple_msa(uint8_t 
*src0_ptr,
 ILVR_D2_SH(in5, in4, in7, in6, in2, in3);
 XORI_B8_128_SB(src0, src1, src2, src3, src4, src5, src6, src7);
 
-VSHF_B2_SB(src0, src1, src0, src1, mask0, mask1, vec0, vec1);
 tmp0 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, tmp0, tmp0);
-VSHF_B2_SB(src2, src3, src2, src3, mask0, mask1, vec0, vec1);
 tmp1 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, tmp1, tmp1);
-VSHF_B2_SB(src4, src5, src4, src5, mask0, mask1, vec0, vec1);
 tmp2 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, tmp2, tmp2);
-VSHF_B2_SB(src6, src7, src6, src7, mask0, mask1, vec0, vec1);
 tmp3 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, tmp3, tmp3);
+VSHF_B2_SB(src0, src1, src2, src3, mask0, mask0, vec0, vec1);
+VSHF_B2_SB(src4, src5, src6, src7, mask0, mask0, vec2, vec3);
+DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt0, filt0, filt0, tmp0,
+ tmp1, tmp2, tmp3);
+VSHF_B2_SB(src0, src1, src2, src3, mask1, mask1, vec0, vec1);
+VSHF_B2_SB(src4, src5, src6, src7, mask1, mask1, vec2, vec3);
+DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt1, filt1, filt1, filt1, tmp0,
+ tmp1, tmp2, tmp3);
 
 HEVC_BI_RND_CLIP4(in0, in1, in2, in3,
   tmp0, tmp1, tmp2, tmp3, 7, tmp0, tmp1, tmp2, tmp3); 
@@ -2357,9 +2358,9 @@ static void hevc_hz_bi_4t_6w_msa(uint8_t *src0_ptr,
 v8i16 filt0, filt1;
 v16i8 src0, src1, src2, src3;
 v8i16 in0, in1, in2, in3;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8 };
+v16i8 mask0 = LD_SB(&ff_hevc_mask_arr[0]);
 v16i8 mask1;
-v16i8 vec0, vec1;
+v16i8 vec0, vec1, vec2, vec3;
 v8i16 dst0, dst1, dst2, dst3;
 v8i16 filter_vec, const_vec;
 
@@ -2380,18 +2381,18 @@ static void hevc_hz_bi_4t_6w_msa(uint8_t *src0_ptr,
 src1_ptr += (4 * src2_stride);
 XORI_B4_128_SB(src0, src1, src2, src3);
 
-VSHF_B2_SB(src0, src0, src0, src0, mask0, mask1, vec

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc avg mc 20, 21 and 23 msa functions

2017-11-03 Thread Manojkumar Bhosale
LGTM

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
kaustubh.ra...@imgtec.com
Sent: Friday, November 3, 2017 10:39 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Kaustubh Raste
Subject: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc avg mc 20, 21 and 23 
msa functions

From: Kaustubh Raste 

Load the specific destination bytes instead of MSA load and pack.
Remove unused macros and functions.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/h264qpel_msa.c | 1274 ++--
 1 file changed, 834 insertions(+), 440 deletions(-)

diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec/mips/h264qpel_msa.c
index 3df72f5..dd11f00 100644
--- a/libavcodec/mips/h264qpel_msa.c
+++ b/libavcodec/mips/h264qpel_msa.c
@@ -21,30 +21,6 @@
 #include "libavutil/mips/generic_macros_msa.h"
 #include "h264dsp_mips.h"
 
-#define AVC_CALC_DPADD_H_6PIX_2COEFF_SH(in0, in1, in2, in3, in4, in5)\
-( {  \
-v4i32 tmp0_m, tmp1_m;\
-v8i16 out0_m, out1_m, out2_m, out3_m;\
-v8i16 minus5h_m = __msa_ldi_h(-5);   \
-v8i16 plus20h_m = __msa_ldi_h(20);   \
- \
-ILVRL_H2_SW(in5, in0, tmp0_m, tmp1_m);   \
- \
-tmp0_m = __msa_hadd_s_w((v8i16) tmp0_m, (v8i16) tmp0_m); \
-tmp1_m = __msa_hadd_s_w((v8i16) tmp1_m, (v8i16) tmp1_m); \
- \
-ILVRL_H2_SH(in1, in4, out0_m, out1_m);   \
-DPADD_SH2_SW(out0_m, out1_m, minus5h_m, minus5h_m, tmp0_m, tmp1_m);  \
-ILVRL_H2_SH(in2, in3, out2_m, out3_m);   \
-DPADD_SH2_SW(out2_m, out3_m, plus20h_m, plus20h_m, tmp0_m, tmp1_m);  \
- \
-SRARI_W2_SW(tmp0_m, tmp1_m, 10); \
-SAT_SW2_SW(tmp0_m, tmp1_m, 7);   \
-out0_m = __msa_pckev_h((v8i16) tmp1_m, (v8i16) tmp0_m);  \
- \
-out0_m;  \
-} )
-
 static const uint8_t luma_mask_arr[16 * 8] = {
 /* 8 width cases */
 0, 5, 1, 6, 2, 7, 3, 8, 4, 9, 5, 10, 6, 11, 7, 12,
@@ -75,44 +51,6 @@ static const uint8_t luma_mask_arr[16 * 8] = {
 DPADD_SB2_SH(tmp0_m, tmp1_m, plus20b_m, plus20b_m, out1, out2);  \
 }
 
-#define AVC_CALC_DPADD_H_6PIX_2COEFF_R_SH(vec0, vec1, vec2, vec3, vec4, vec5)  
\
-( {
\
-v4i32 tmp1_m;  
\
-v8i16 tmp2_m, tmp3_m;  
\
-v8i16 minus5h_m = __msa_ldi_h(-5); 
\
-v8i16 plus20h_m = __msa_ldi_h(20); 
\
-   
\
-tmp1_m = (v4i32) __msa_ilvr_h((v8i16) vec5, (v8i16) vec0); 
\
-tmp1_m = __msa_hadd_s_w((v8i16) tmp1_m, (v8i16) tmp1_m);   
\
-   
\
-ILVR_H2_SH(vec1, vec4, vec2, vec3, tmp2_m, tmp3_m);
\
-DPADD_SH2_SW(tmp2_m, tmp3_m, minus5h_m, plus20h_m, tmp1_m, tmp1_m);
\
-   
\
-tmp1_m = __msa_srari_w(tmp1_m, 10);
\
-tmp1_m = __msa_sat_s_w(tmp1_m, 7); 
\
-   
\
-tmp2_m = __msa_pckev_h((v8i16) tmp1_m, (v8i16) tmp1_m);
\
-   
\
-tmp2_m;
\
-} )
-
-#define AVC_XOR_VSHF_B_AND_APPLY_6TAP_HORIZ_FILT_SH(src0, src1,  \
-mask0, mask1, mask2) \
-( {  \
-v8i16 hz_out_m;  \
-v16i8 vec0_m, vec1_m, vec2_m;\
-v16i8 minus5b_m = __msa_ldi_b(-5);   \
-v16i8 plus20b_m = __msa_ldi_b(20);   \
-

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

2017-11-03 Thread Jeyapal, Karthick
>On 11/3/17, 2:18 PM, "Nicolas George"  wrote:

>I strongly oppose this: we do not want new global state.
I also agree. I am open to suggestions, and I would be happy re-implement this 
feature without new global state.

>Also, I am very doubtful about the feature itself. It is public, and as
>such should be usable for many uses, but I do not see it useful for
>anything but patches 3 and 4. 
Well beyond patch 3 and 4, this feature is usable for HLS player, DASH player 
and DASH encoder. 
Any other segmented streaming standard would also benefit from this feature.
With internet streaming having moved towards segmented streaming standards, I 
would think this feature is very useful.
Right now, the performance of hlsenc, dashenc etc., suffers terribly for http 
output with lower segment sizes.
Also, this feature could be extended for HTTPS/TLS connections as well.

>Furthermore, it is a break of abstraction,
>sockets lose their simple and clear API, they are not really closed when
>they are closed, etc.
Technically it doesn’t break any abstraction. Internally reusing socket 
connections,
could be thought of as an implementation level detail to improve performance. 
For example, android HTTP APIs reuse the sockets internally to improve 
performance
without affecting the abstraction.
https://developer.android.com/reference/java/net/HttpURLConnection.html
 
>If you are trying to implement keepalive HTTP for HLS, then most of the
>code should be in http.c and hls*.c, not tcp.c.
That’s a very good point. I had also thought in similar lines. Here is an 
approach that I could think of. 
- Open just one http connection from hlsenc.c
- Somehow call http_shutdown instead of http_close during end of segments/file
- For opening a new segment/file hlsenc calls http_write (with relevant http 
headers 
composed by hlsenc) instead of a fresh http_open
If ffmpeg maintainers agree to the above approach, I am willing to implement it 
that way. 

Or if anybody proposes a better approach, I am willing to consider that as well.

>Regards,
>
>-- 
>  Nicolas George


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


Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

2017-11-03 Thread Dixit, Vishwanath
>On 11/3/17, 3:24 PM, "Steven Liu"  wrote:
>make fate-filter-hls-append
>
>you can grep hls append in the file
I think that is also a test for hls decoder. Basically, I am trying to find, if 
there are any basic tests available for hls encoder.

Regards,
Vishwanath

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


Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

2017-11-03 Thread Steven Liu


在 2017年11月3日,下午5:44,Dixit, Vishwanath  写道:

>> On 10/24/17, 12:58 PM, "Liu Steven"  wrote:
>>   tests/fate/filter-audio.mak
>>   reference it
> I went through this file. The only HLS related test seems to be for HLS 
> decoder (fate-filter-hls). I think, FATE does not have any test for HLS 
> encoder yet. Could you please confirm this?  
make fate-filter-hls-append

you can grep hls append in the file
> 
> Regards,
> Vishwanath
> 
> ___
> 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] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

2017-11-03 Thread Dixit, Vishwanath
>On 10/24/17, 12:58 PM, "Liu Steven"  wrote:
>tests/fate/filter-audio.mak
>reference it
I went through this file. The only HLS related test seems to be for HLS decoder 
(fate-filter-hls). I think, FATE does not have any test for HLS encoder yet. 
Could you please confirm this?  

Regards,
Vishwanath

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


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

2017-11-03 Thread Nicolas George
Le tridi 13 brumaire, an CCXXVI, Karthick J a écrit :
> +static TCPSocket *first_socket = NULL;



> +avpriv_lock_avformat();
> +socket->next = first_socket;
> +first_socket = socket;
> +avpriv_unlock_avformat();

I strongly oppose this: we do not want new global state.

Also, I am very doubtful about the feature itself. It is public, and as
such should be usable for many uses, but I do not see it useful for
anything but patches 3 and 4. Furthermore, it is a break of abstraction,
sockets lose their simple and clear API, they are not really closed when
they are closed, etc.

If you are trying to implement keepalive HTTP for HLS, then most of the
code should be in http.c and hls*.c, not tcp.c.

Regards,

-- 
  Nicolas George


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/4] libavformat/tcp: Added an option to reuse sockets

2017-11-03 Thread Hendrik Leppkes
On Fri, Nov 3, 2017 at 9:27 AM, Karthick J  wrote:
> ---
>  doc/protocols.texi  |   4 ++
>  libavformat/tcp.c   | 150 
> 
>  libavformat/tcp.h   |  27 ++
>  libavformat/utils.c |   2 +
>  4 files changed, 183 insertions(+)
>  create mode 100644 libavformat/tcp.h
>
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index a7968ff..62d317d 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -1242,6 +1242,10 @@ Set receive buffer size, expressed bytes.
>
>  @item send_buffer_size=@var{bytes}
>  Set send buffer size, expressed bytes.
> +
> +@item reuse_sockets=@var{1|0}
> +Reuse sockets instead of opening a new socket each time.
> +Default value is 0.
>  @end table
>
>  The following example shows how to setup a listening TCP connection
> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> index 06368ff..8bca628 100644
> --- a/libavformat/tcp.c
> +++ b/libavformat/tcp.c
> @@ -1,6 +1,7 @@
>  /*
>   * TCP protocol
>   * Copyright (c) 2002 Fabrice Bellard
> + * Copyright (c) 2017 Akamai Technologies, Inc
>   *
>   * This file is part of FFmpeg.
>   *
> @@ -19,6 +20,8 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
>   */
>  #include "avformat.h"
> +#include "tcp.h"
> +#include "libavcodec/internal.h"
>  #include "libavutil/avassert.h"
>  #include "libavutil/parseutils.h"
>  #include "libavutil/opt.h"
> @@ -38,6 +41,7 @@ typedef struct TCPOptions {
>  int listen_timeout;
>  int recv_buffer_size;
>  int send_buffer_size;
> +int reuse_sockets;
>  } TCPOptions;
>
>  typedef struct TCPContext {
> @@ -47,6 +51,16 @@ typedef struct TCPContext {
>  TCPOptions options;
>  } TCPContext;
>
> +typedef struct TCPSocket {
> +char *hostname;
> +int  port;
> +int in_use;
> +int64_t last_close_time;
> +int  fd;
> +TCPOptions options;
> +struct TCPSocket *next;
> +} TCPSocket;
> +
>  #define OFFSET(x) (offsetof(TCPContext, options) + offsetof(TCPOptions, x))
>  #define D AV_OPT_FLAG_DECODING_PARAM
>  #define E AV_OPT_FLAG_ENCODING_PARAM
> @@ -56,6 +70,7 @@ static const AVOption options[] = {
>  { "listen_timeout",  "Connection awaiting timeout (in milliseconds)",
>   OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 
> INT_MAX, .flags = D|E },
>  { "send_buffer_size", "Socket send buffer size (in bytes)",  
>   OFFSET(send_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 
> INT_MAX, .flags = D|E },
>  { "recv_buffer_size", "Socket receive buffer size (in bytes)",   
>   OFFSET(recv_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 
> INT_MAX, .flags = D|E },
> +{ "reuse_sockets", "Reuse sockets instead of opening a new socket each 
> time", OFFSET(reuse_sockets), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, 
> .flags = D|E },
>  { NULL }
>  };
>
> @@ -66,6 +81,116 @@ static const AVClass tcp_class = {
>  .version= LIBAVUTIL_VERSION_INT,
>  };
>
> +static TCPSocket *first_socket = NULL;

We're not very fond of global state, especially in new code. A better
way would be to have a socket pool structure that a caller can manage,
instead of having it globally.
(Additionally, we're also trying to really get rid of the global
avformat lock, which this is using).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 3/4] libavformat/http: Reuse TCP sockets when 'multiple_requests' is set

2017-11-03 Thread Karthick J
---
 libavformat/http.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index bd9148f..b7bdcdc 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -227,6 +227,9 @@ static int http_open_cnx_internal(URLContext *h, 
AVDictionary **options)
 ff_url_join(buf, sizeof(buf), lower_proto, NULL, hostname, port, NULL);
 
 if (!s->hd) {
+if (s->multiple_requests && !strcmp(lower_proto, "tcp")) {
+av_dict_set_int(options, "reuse_sockets", 1, 0);
+}
 err = ffurl_open_whitelist(&s->hd, buf, AVIO_FLAG_READ_WRITE,
&h->interrupt_callback, options,
h->protocol_whitelist, 
h->protocol_blacklist, h);
-- 
1.9.1

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


[FFmpeg-devel] [PATCH 4/4] libavformat/hlsenc: Persistent HTTP connections supported as an option

2017-11-03 Thread Karthick J
---
 doc/muxers.texi  | 3 +++
 libavformat/hlsenc.c | 5 -
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 91bbe67..1e1468c 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -794,6 +794,9 @@ files.
 @item http_user_agent
 Override User-Agent field in HTTP header. Applicable only for HTTP output.
 
+@item http_persistent
+Use persistent HTTP connections. Applicable only for HTTP output.
+
 @end table
 
 @anchor{ico}
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5ea9d21..79db77a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -175,6 +175,7 @@ typedef struct HLSContext {
 double initial_prog_date_time;
 char current_segment_final_filename_fmt[1024]; // when renaming segments
 char *user_agent;
+int http_persistent;
 } HLSContext;
 
 static int get_int_from_double(double val)
@@ -228,7 +229,8 @@ static void set_http_options(AVFormatContext *s, 
AVDictionary **options, HLSCont
 }
 if (c->user_agent)
 av_dict_set(options, "user_agent", c->user_agent, 0);
-
+if (c->http_persistent)
+av_dict_set_int(options, "multiple_requests", c->http_persistent, 0);
 }
 
 static int replace_int_data_in_filename(char *buf, int buf_size, const char 
*filename, char placeholder, int64_t number)
@@ -1829,6 +1831,7 @@ static const AVOption options[] = {
 {"epoch", "seconds since epoch", 0, AV_OPT_TYPE_CONST, {.i64 = 
HLS_START_SEQUENCE_AS_SECONDS_SINCE_EPOCH }, INT_MIN, INT_MAX, E, 
"start_sequence_source_type" },
 {"datetime", "current datetime as MMDDhhmmss", 0, AV_OPT_TYPE_CONST, 
{.i64 = HLS_START_SEQUENCE_AS_FORMATTED_DATETIME }, INT_MIN, INT_MAX, E, 
"start_sequence_source_type" },
 {"http_user_agent", "override User-Agent field in HTTP header", 
OFFSET(user_agent), AV_OPT_TYPE_STRING, {.str = NULL},  0, 0,E},
+{"http_persistent", "Use persistent HTTP connections", 
OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
 { NULL },
 };
 
-- 
1.9.1

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


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

2017-11-03 Thread Karthick J
---
 doc/protocols.texi  |   4 ++
 libavformat/tcp.c   | 150 
 libavformat/tcp.h   |  27 ++
 libavformat/utils.c |   2 +
 4 files changed, 183 insertions(+)
 create mode 100644 libavformat/tcp.h

diff --git a/doc/protocols.texi b/doc/protocols.texi
index a7968ff..62d317d 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1242,6 +1242,10 @@ Set receive buffer size, expressed bytes.
 
 @item send_buffer_size=@var{bytes}
 Set send buffer size, expressed bytes.
+
+@item reuse_sockets=@var{1|0}
+Reuse sockets instead of opening a new socket each time.
+Default value is 0.
 @end table
 
 The following example shows how to setup a listening TCP connection
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index 06368ff..8bca628 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -1,6 +1,7 @@
 /*
  * TCP protocol
  * Copyright (c) 2002 Fabrice Bellard
+ * Copyright (c) 2017 Akamai Technologies, Inc
  *
  * This file is part of FFmpeg.
  *
@@ -19,6 +20,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 #include "avformat.h"
+#include "tcp.h"
+#include "libavcodec/internal.h"
 #include "libavutil/avassert.h"
 #include "libavutil/parseutils.h"
 #include "libavutil/opt.h"
@@ -38,6 +41,7 @@ typedef struct TCPOptions {
 int listen_timeout;
 int recv_buffer_size;
 int send_buffer_size;
+int reuse_sockets;
 } TCPOptions;
 
 typedef struct TCPContext {
@@ -47,6 +51,16 @@ typedef struct TCPContext {
 TCPOptions options;
 } TCPContext;
 
+typedef struct TCPSocket {
+char *hostname;
+int  port;
+int in_use;
+int64_t last_close_time;
+int  fd;
+TCPOptions options;
+struct TCPSocket *next;
+} TCPSocket;
+
 #define OFFSET(x) (offsetof(TCPContext, options) + offsetof(TCPOptions, x))
 #define D AV_OPT_FLAG_DECODING_PARAM
 #define E AV_OPT_FLAG_ENCODING_PARAM
@@ -56,6 +70,7 @@ static const AVOption options[] = {
 { "listen_timeout",  "Connection awaiting timeout (in milliseconds)",  
OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, 
.flags = D|E },
 { "send_buffer_size", "Socket send buffer size (in bytes)",
OFFSET(send_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, 
.flags = D|E },
 { "recv_buffer_size", "Socket receive buffer size (in bytes)", 
OFFSET(recv_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, 
.flags = D|E },
+{ "reuse_sockets", "Reuse sockets instead of opening a new socket each 
time", OFFSET(reuse_sockets), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, 
.flags = D|E },
 { NULL }
 };
 
@@ -66,6 +81,116 @@ static const AVClass tcp_class = {
 .version= LIBAVUTIL_VERSION_INT,
 };
 
+static TCPSocket *first_socket = NULL;
+
+static TCPSocket* tcp_socket_create (TCPContext *s, char *name, int port)
+{
+TCPSocket *p = NULL;
+
+p = (TCPSocket *) calloc (1, sizeof(TCPSocket));
+if (p == NULL) {
+return NULL;
+}
+
+p->hostname = strdup(name);
+p->port = port;
+p->in_use = 1;
+p->fd = s->fd;
+p->options = s->options;
+p->next = NULL;
+
+return p;
+}
+
+static int tcp_socket_free (TCPSocket *socket)
+{
+if (socket) {
+closesocket(socket->fd);
+free(socket->hostname);
+free(socket);
+}
+return 0;
+}
+
+static void tcp_list_add(TCPContext *s, char *name, int port)
+{
+TCPSocket *socket = tcp_socket_create(s, name, port);
+
+if (!socket)
+return;
+avpriv_lock_avformat();
+socket->next = first_socket;
+first_socket = socket;
+avpriv_unlock_avformat();
+
+}
+
+static void tcp_list_remove_next(TCPSocket *socket)
+{
+TCPSocket *temp;
+if (socket) {
+temp = socket->next;
+socket->next = socket->next->next;
+} else {
+temp = first_socket;
+first_socket = first_socket->next;
+}
+tcp_socket_free(temp);
+
+}
+
+static int tcp_socket_find (TCPContext *s, char *name, int port)
+{
+int lfd = -1;
+TCPSocket *p = first_socket;
+TCPSocket *prev = NULL;
+int64_t current_time = av_gettime();
+avpriv_lock_avformat();
+while(p) {
+const int idle_timeout = 60 * 100;
+// Remove idle connections
+if (!p->in_use && (current_time - p->last_close_time) > idle_timeout) {
+tcp_list_remove_next(prev);
+} else {
+// Reuse the connection if a correct match if found
+if (!p->in_use && lfd == -1 &&
+!strcmp(p->hostname, name) && (p->port == port) &&
+!memcmp(&p->options, &s->options, sizeof(s->options))) {
+p->in_use = 1;
+lfd = p->fd;
+}
+prev = p;
+}
+p = p->next;
+
+}
+avpriv_unlock_avformat();
+return lfd;
+}
+
+static void tcp_socket_release (int search_fd)
+{
+TCPSocket *p = first_sock

[FFmpeg-devel] [PATCH 1/4] libformat/tcp: Moved all options to a separate structure

2017-11-03 Thread Karthick J
---
 libavformat/tcp.c | 46 +-
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index 07b4ed9..06368ff 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -32,18 +32,22 @@
 #include 
 #endif
 
-typedef struct TCPContext {
-const AVClass *class;
-int fd;
+typedef struct TCPOptions {
 int listen;
-int open_timeout;
 int rw_timeout;
 int listen_timeout;
 int recv_buffer_size;
 int send_buffer_size;
+} TCPOptions;
+
+typedef struct TCPContext {
+const AVClass *class;
+int fd;
+int open_timeout;
+TCPOptions options;
 } TCPContext;
 
-#define OFFSET(x) offsetof(TCPContext, x)
+#define OFFSET(x) (offsetof(TCPContext, options) + offsetof(TCPOptions, x))
 #define D AV_OPT_FLAG_DECODING_PARAM
 #define E AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
@@ -87,26 +91,26 @@ static int tcp_open(URLContext *h, const char *uri, int 
flags)
 if (p) {
 if (av_find_info_tag(buf, sizeof(buf), "listen", p)) {
 char *endptr = NULL;
-s->listen = strtol(buf, &endptr, 10);
+s->options.listen = strtol(buf, &endptr, 10);
 /* assume if no digits were found it is a request to enable it */
 if (buf == endptr)
-s->listen = 1;
+s->options.listen = 1;
 }
 if (av_find_info_tag(buf, sizeof(buf), "timeout", p)) {
-s->rw_timeout = strtol(buf, NULL, 10);
+s->options.rw_timeout = strtol(buf, NULL, 10);
 }
 if (av_find_info_tag(buf, sizeof(buf), "listen_timeout", p)) {
-s->listen_timeout = strtol(buf, NULL, 10);
+s->options.listen_timeout = strtol(buf, NULL, 10);
 }
 }
-if (s->rw_timeout >= 0) {
+if (s->options.rw_timeout >= 0) {
 s->open_timeout =
-h->rw_timeout   = s->rw_timeout;
+h->rw_timeout   = s->options.rw_timeout;
 }
 hints.ai_family = AF_UNSPEC;
 hints.ai_socktype = SOCK_STREAM;
 snprintf(portstr, sizeof(portstr), "%d", port);
-if (s->listen)
+if (s->options.listen)
 hints.ai_flags |= AI_PASSIVE;
 if (!hostname[0])
 ret = getaddrinfo(NULL, portstr, &hints, &ai);
@@ -142,21 +146,21 @@ static int tcp_open(URLContext *h, const char *uri, int 
flags)
 
 /* Set the socket's send or receive buffer sizes, if specified.
If unspecified or setting fails, system default is used. */
-if (s->recv_buffer_size > 0) {
-setsockopt (fd, SOL_SOCKET, SO_RCVBUF, &s->recv_buffer_size, sizeof 
(s->recv_buffer_size));
+if (s->options.recv_buffer_size > 0) {
+setsockopt (fd, SOL_SOCKET, SO_RCVBUF, &s->options.recv_buffer_size, 
sizeof (s->options.recv_buffer_size));
 }
-if (s->send_buffer_size > 0) {
-setsockopt (fd, SOL_SOCKET, SO_SNDBUF, &s->send_buffer_size, sizeof 
(s->send_buffer_size));
+if (s->options.send_buffer_size > 0) {
+setsockopt (fd, SOL_SOCKET, SO_SNDBUF, &s->options.send_buffer_size, 
sizeof (s->options.send_buffer_size));
 }
 
-if (s->listen == 2) {
+if (s->options.listen == 2) {
 // multi-client
 if ((ret = ff_listen(fd, cur_ai->ai_addr, cur_ai->ai_addrlen)) < 0)
 goto fail1;
-} else if (s->listen == 1) {
+} else if (s->options.listen == 1) {
 // single client
 if ((ret = ff_listen_bind(fd, cur_ai->ai_addr, cur_ai->ai_addrlen,
-  s->listen_timeout, h)) < 0)
+  s->options.listen_timeout, h)) < 0)
 goto fail1;
 // Socket descriptor already closed here. Safe to overwrite to client 
one.
 fd = ret;
@@ -198,11 +202,11 @@ static int tcp_accept(URLContext *s, URLContext **c)
 TCPContext *sc = s->priv_data;
 TCPContext *cc;
 int ret;
-av_assert0(sc->listen);
+av_assert0(sc->options.listen);
 if ((ret = ffurl_alloc(c, s->filename, s->flags, &s->interrupt_callback)) 
< 0)
 return ret;
 cc = (*c)->priv_data;
-ret = ff_accept(sc->fd, sc->listen_timeout, s);
+ret = ff_accept(sc->fd, sc->options.listen_timeout, s);
 if (ret < 0)
 return ret;
 cc->fd = ret;
-- 
1.9.1

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


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

2017-11-03 Thread kaustubh.raste
From: Kaustubh Raste 

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

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_uniw_msa.c |  892 ++--
 1 file changed, 448 insertions(+), 444 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_uniw_msa.c 
b/libavcodec/mips/hevc_mc_uniw_msa.c
index 0796b0a..31fec73 100644
--- a/libavcodec/mips/hevc_mc_uniw_msa.c
+++ b/libavcodec/mips/hevc_mc_uniw_msa.c
@@ -29,19 +29,6 @@ static const uint8_t ff_hevc_mask_arr[16 * 2] 
__attribute__((aligned(0x40))) = {
 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20
 };
 
-#define HEVC_HV_UNIW_RND_CLIP4(in0, in1, in2, in3, wgt, offset, rnd,   \
-   out0, out1, out2, out3) \
-{  \
-MUL4(in0, wgt, in1, wgt, in2, wgt, in3, wgt, out0, out1, out2, out3);  \
-SRAR_W4_SW(out0, out1, out2, out3, rnd);   \
-ADD4(out0, offset, out1, offset, out2, offset, out3, offset,   \
- out0, out1, out2, out3);  \
-out0 = CLIP_SW_0_255(out0);\
-out1 = CLIP_SW_0_255(out1);\
-out2 = CLIP_SW_0_255(out2);\
-out3 = CLIP_SW_0_255(out3);\
-}
-
 #define HEVC_UNIW_RND_CLIP2(in0, in1, wgt, offset, rnd,  \
 out0_r, out1_r, out0_l, out1_l)  \
 {\
@@ -2382,19 +2369,19 @@ static void hevc_hz_uniwgt_4t_4x2_msa(uint8_t *src,
   uint8_t *dst,
   int32_t dst_stride,
   const int8_t *filter,
-  int32_t height,
   int32_t weight,
   int32_t offset,
   int32_t rnd_val)
 {
+v16u8 out;
 v8i16 filt0, filt1;
 v16i8 src0, src1, vec0, vec1;
 v16i8 mask1;
 v8i16 dst0;
 v4i32 dst0_r, dst0_l;
-v8i16 filter_vec, const_vec;
-v4i32 weight_vec, offset_vec, rnd_vec;
-v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20 };
+v8i16 filter_vec, weight_vec_h, offset_vec, denom_vec;
+v4i32 weight_vec, rnd_vec;
+v16i8 mask0 = LD_SB(&ff_hevc_mask_arr[16]);
 
 src -= 1;
 
@@ -2405,29 +2392,33 @@ static void hevc_hz_uniwgt_4t_4x2_msa(uint8_t *src,
 
 weight = weight & 0x;
 
-const_vec = __msa_ldi_h(128);
-const_vec <<= 6;
-
 weight_vec = __msa_fill_w(weight);
-offset_vec = __msa_fill_w(offset);
 rnd_vec = __msa_fill_w(rnd_val);
 
+weight *= 128;
+rnd_val -= 6;
+
+weight_vec_h = __msa_fill_h(weight);
+offset_vec = __msa_fill_h(offset);
+denom_vec = __msa_fill_h(rnd_val);
+
+weight_vec_h = __msa_srar_h(weight_vec_h, denom_vec);
+offset_vec = __msa_adds_s_h(offset_vec, weight_vec_h);
+
 LD_SB2(src, src_stride, src0, src1);
 XORI_B2_128_SB(src0, src1);
 
 VSHF_B2_SB(src0, src1, src0, src1, mask0, mask1, vec0, vec1);
-dst0 = const_vec;
-DPADD_SB2_SH(vec0, vec1, filt0, filt1, dst0, dst0);
+dst0 = HEVC_FILT_4TAP_SH(vec0, vec1, filt0, filt1);
 
 ILVRL_H2_SW(dst0, dst0, dst0_r, dst0_l);
 DOTP_SH2_SW(dst0_r, dst0_l, weight_vec, weight_vec, dst0_r, dst0_l);
 SRAR_W2_SW(dst0_r, dst0_l, rnd_vec);
-ADD2(dst0_r, offset_vec, dst0_l, offset_vec, dst0_r, dst0_l);
-dst0_r = CLIP_SW_0_255(dst0_r);
-dst0_l = CLIP_SW_0_255(dst0_l);
-
-HEVC_PCK_SW_SB2(dst0_l, dst0_r, dst0_r);
-ST4x2_UB(dst0_r, dst, dst_stride);
+dst0 = __msa_pckev_h((v8i16) dst0_l, (v8i16) dst0_r);
+dst0 = __msa_adds_s_h(dst0, offset_vec);
+dst0 = CLIP_SH_0_255_MAX_SATU(dst0);
+out = (v16u8) __msa_pckev_b((v16i8) dst0, (v16i8) dst0);
+ST4x2_UB(out, dst, dst_stride);
 dst += (4 * dst_stride);
 }
 
@@ -2436,19 +2427,18 @@ static void hevc_hz_uniwgt_4t_4x4_msa(uint8_t *src,
   uint8_t *dst,
   int32_t dst_stride,
   const int8_t *filter,
-  int32_t height,
   int32_t weight,
   int32_t offset,
   int32_t rnd_val)
 {
+v16u8 out;
 v8i16 filt0, filt1;
 v16i8 src0, src1, src2, src3;
-v16i8 mask1, vec0, vec1;
+v16i8 mask1, vec0, vec1, vec2, vec3;
 v8i16 dst0, dst1;
-v4i32 dst0_r, dst1_r, dst0_l, dst1_l;
-v8i16 filter_vec, const_vec;
-v4i32 weight_vec, offset

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

2017-11-03 Thread kaustubh.raste
From: Kaustubh Raste 

Use global mask buffer for appropriate mask load.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevc_mc_uni_msa.c |  509 -
 1 file changed, 274 insertions(+), 235 deletions(-)

diff --git a/libavcodec/mips/hevc_mc_uni_msa.c 
b/libavcodec/mips/hevc_mc_uni_msa.c
index 7d24858..993dad0 100644
--- a/libavcodec/mips/hevc_mc_uni_msa.c
+++ b/libavcodec/mips/hevc_mc_uni_msa.c
@@ -1947,7 +1947,7 @@ static void common_hz_4t_4x2_msa(uint8_t *src, int32_t 
src_stride,
 v16u8 out;
 v8i16 filt, res0;
 
-mask0 = LD_SB(&mc_filt_mask_arr[16]);
+mask0 = LD_SB(&ff_hevc_mask_arr[16]);
 src -= 1;
 
 /* rearranging filter */
@@ -1959,7 +1959,7 @@ static void common_hz_4t_4x2_msa(uint8_t *src, int32_t 
src_stride,
 LD_SB2(src, src_stride, src0, src1);
 XORI_B2_128_SB(src0, src1);
 VSHF_B2_SB(src0, src1, src0, src1, mask0, mask1, vec0, vec1);
-res0 = FILT_4TAP_DPADD_S_H(vec0, vec1, filt0, filt1);
+res0 = HEVC_FILT_4TAP_SH(vec0, vec1, filt0, filt1);
 res0 = __msa_srari_h(res0, 6);
 res0 = __msa_sat_s_h(res0, 7);
 out = PCKEV_XORI128_UB(res0, res0);
@@ -1974,7 +1974,7 @@ static void common_hz_4t_4x4_msa(uint8_t *src, int32_t 
src_stride,
 v8i16 filt, out0, out1;
 v16u8 out;
 
-mask0 = LD_SB(&mc_filt_mask_arr[16]);
+mask0 = LD_SB(&ff_hevc_mask_arr[16]);
 src -= 1;
 
 /* rearranging filter */
@@ -2001,7 +2001,7 @@ static void common_hz_4t_4x8_msa(uint8_t *src, int32_t 
src_stride,
 v16u8 out;
 v8i16 filt, out0, out1, out2, out3;
 
-mask0 = LD_SB(&mc_filt_mask_arr[16]);
+mask0 = LD_SB(&ff_hevc_mask_arr[16]);
 src -= 1;
 
 /* rearranging filter */
@@ -2038,7 +2038,7 @@ static void common_hz_4t_4x16_msa(uint8_t *src, int32_t 
src_stride,
 v16u8 out;
 v8i16 filt, out0, out1, out2, out3;
 
-mask0 = LD_SB(&mc_filt_mask_arr[16]);
+mask0 = LD_SB(&ff_hevc_mask_arr[16]);
 src -= 1;
 
 /* rearranging filter */
@@ -2098,12 +2098,11 @@ static void common_hz_4t_6w_msa(uint8_t *src, int32_t 
src_stride,
 uint8_t *dst, int32_t dst_stride,
 const int8_t *filter, int32_t height)
 {
-uint32_t loop_cnt;
 v16i8 src0, src1, src2, src3, filt0, filt1, mask0, mask1;
 v16u8 out4, out5;
 v8i16 filt, out0, out1, out2, out3;
 
-mask0 = LD_SB(&mc_filt_mask_arr[0]);
+mask0 = LD_SB(&ff_hevc_mask_arr[0]);
 src -= 1;
 
 /* rearranging filter */
@@ -2112,21 +2111,31 @@ static void common_hz_4t_6w_msa(uint8_t *src, int32_t 
src_stride,
 
 mask1 = mask0 + 2;
 
-for (loop_cnt = (height >> 2); loop_cnt--;) {
-LD_SB4(src, src_stride, src0, src1, src2, src3);
-src += (4 * src_stride);
+LD_SB4(src, src_stride, src0, src1, src2, src3);
+src += (4 * src_stride);
 
-XORI_B4_128_SB(src0, src1, src2, src3);
-HORIZ_4TAP_8WID_4VECS_FILT(src0, src1, src2, src3, mask0, mask1, filt0,
-   filt1, out0, out1, out2, out3);
-SRARI_H4_SH(out0, out1, out2, out3, 6);
-SAT_SH4_SH(out0, out1, out2, out3, 7);
+XORI_B4_128_SB(src0, src1, src2, src3);
+HORIZ_4TAP_8WID_4VECS_FILT(src0, src1, src2, src3, mask0, mask1, filt0,
+   filt1, out0, out1, out2, out3);
+SRARI_H4_SH(out0, out1, out2, out3, 6);
+SAT_SH4_SH(out0, out1, out2, out3, 7);
+out4 = PCKEV_XORI128_UB(out0, out1);
+out5 = PCKEV_XORI128_UB(out2, out3);
+ST6x4_UB(out4, out5, dst, dst_stride);
+dst += (4 * dst_stride);
 
-out4 = PCKEV_XORI128_UB(out0, out1);
-out5 = PCKEV_XORI128_UB(out2, out3);
-ST6x4_UB(out4, out5, dst, dst_stride);
-dst += (4 * dst_stride);
-}
+LD_SB4(src, src_stride, src0, src1, src2, src3);
+src += (4 * src_stride);
+
+XORI_B4_128_SB(src0, src1, src2, src3);
+HORIZ_4TAP_8WID_4VECS_FILT(src0, src1, src2, src3, mask0, mask1, filt0,
+   filt1, out0, out1, out2, out3);
+SRARI_H4_SH(out0, out1, out2, out3, 6);
+SAT_SH4_SH(out0, out1, out2, out3, 7);
+out4 = PCKEV_XORI128_UB(out0, out1);
+out5 = PCKEV_XORI128_UB(out2, out3);
+ST6x4_UB(out4, out5, dst, dst_stride);
+dst += (4 * dst_stride);
 }
 
 static void common_hz_4t_8x2mult_msa(uint8_t *src, int32_t src_stride,
@@ -2138,7 +2147,7 @@ static void common_hz_4t_8x2mult_msa(uint8_t *src, 
int32_t src_stride,
 v16u8 out;
 v8i16 filt, vec0, vec1, vec2, vec3;
 
-mask0 = LD_SB(&mc_filt_mask_arr[0]);
+mask0 = LD_SB(&ff_hevc_mask_arr[0]);
 src -= 1;
 
 filt = LD_SH(filter);
@@ -2172,7 +2181,7 @@ static void common_hz_4t_8x4mult_msa(uint8_t *src, 
int32_t src_stride,
 v16u8 tmp0, tmp1;
 v8i16 filt, out0, out1, out2, out3;
 
-mask0 = LD_SB(&mc_filt_mask_arr[0]);
+mask0 = LD_SB(&ff_hevc_mask_arr[0]);
 src -= 1;
 
 /* rearranging filter */
@@ -2221,8 +2230,8 @@ static void common_hz_4t_12w_msa(uint