date:20171001

Re: [FFmpeg-devel] [PATCH]lavf/img2dec: Auto-detect svg images

2017-10-01 Thread Clément Bœsch

On Mon, Oct 02, 2017 at 01:20:15AM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch implements auto-detection of svg images.
> 
> Please review, Carl Eugen

> From f06137f38f166740565e58d5c7c88777508f59ec Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Mon, 2 Oct 2017 01:13:29 +0200
> Subject: [PATCH] lavf/img2dec: Auto-detect svg images.
> 
> ---
>  libavformat/img2dec.c |   17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index 19cae87..468c820 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @@ -34,6 +34,7 @@
>  #include "internal.h"
>  #include "img2.h"
>  #include "libavcodec/mjpeg.h"
> +#include "subtitles.h"
>  
>  #if HAVE_GLOB
>  /* Locally define as 0 (bitwise-OR no-op) any missing glob options that
> @@ -875,8 +876,20 @@ static int sunrast_probe(AVProbeData *p)
>  
>  static int svg_probe(AVProbeData *p)
>  {
> -if (av_match_ext(p->filename, "svg") || av_match_ext(p->filename, 
> "svgz"))
> -return AVPROBE_SCORE_EXTENSION + 1;
> +const uint8_t *b = p->buf;
> +const uint8_t *end = p->buf + p->buf_size;
> +if (memcmp(p->buf, " +return 0;
> +while (b < end) {
> +b += ff_subtitles_next_line(b);
> +if (b >= end)
> +return 0;

> +if (!strstr(b, " +continue;

at least the svg from inkscape do not have a doctype

> +b += 9;
> +if (strstr(b, "svg"))
> +return AVPROBE_SCORE_MAX;
> +}A

don't you want to keep an extension fallback?

also, I would guess strstr() is going to be slow, so maybe just look for a
line starting with "

[FFmpeg-devel] [PATCH] fate: add test for iTunes gapless MP3

2017-10-01 Thread Christopher Snowhill


I've finally assembled a fate test for this patch.

The test file goes here:

/gapless/gapless-itunes.mp3

I have uploaded a copy here:

https://f.losno.co/gapless-itunes.mp3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fate: add test for iTunes gapless MP3

2017-10-01 Thread Christopher Snowhill

---
 tests/fate/gapless.mak| 3 ++-
 tests/ref/fate/gapless-mp3-itunes | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/gapless-mp3-itunes

diff --git a/tests/fate/gapless.mak b/tests/fate/gapless.mak
index 0253b9ec61..46b3b98c13 100644
--- a/tests/fate/gapless.mak
+++ b/tests/fate/gapless.mak
@@ -1,5 +1,6 @@
-FATE_GAPLESS-$(CONFIG_MP3_DEMUXER) += fate-gapless-mp3
+FATE_GAPLESS-$(CONFIG_MP3_DEMUXER) += fate-gapless-mp3 fate-gapless-mp3-itunes
 fate-gapless-mp3: CMD = gapless $(TARGET_SAMPLES)/gapless/gapless.mp3
+fate-gapless-mp3-itunes: CMD = gapless 
$(TARGET_SAMPLES)/gapless/gapless-itunes.mp3
 
 FATE_GAPLESS-$(CONFIG_MP3_DEMUXER) += fate-audiomatch-square-mp3
 fate-audiomatch-square-mp3: CMD = audio_match 
$(TARGET_SAMPLES)/audiomatch/square3.mp3 
$(TARGET_SAMPLES)/audiomatch/square3.wav
diff --git a/tests/ref/fate/gapless-mp3-itunes 
b/tests/ref/fate/gapless-mp3-itunes
new file mode 100644
index 00..0337ca3e38
--- /dev/null
+++ b/tests/ref/fate/gapless-mp3-itunes
@@ -0,0 +1,5 @@
+45c78bcbfc9efddb3389ab518095728d *tests/data/fate/gapless-mp3-itunes.out-1
+596b51d8634e184d3a67b1cd072f7d73
+45c78bcbfc9efddb3389ab518095728d *tests/data/fate/gapless-mp3-itunes.out-2
+596b51d8634e184d3a67b1cd072f7d73
+c8cd71407ac5bbfadf5ccf7b5a64430c *tests/data/fate/gapless-mp3-itunes.out-3
-- 
2.13.5 (Apple Git-94)

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/proresdec2: Use LAST_SKIP_BITS where possible

2017-10-01 Thread James Almer

On 10/1/2017 11:18 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/proresdec2.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
> index 22dc70eeb4..9647aa7ebc 100644
> --- a/libavcodec/proresdec2.c
> +++ b/libavcodec/proresdec2.c
> @@ -250,7 +250,7 @@ static int decode_picture_header(AVCodecContext *avctx, 
> const uint8_t *buf, cons
>  return pic_data_size;
>  }
>  
> -#define DECODE_CODEWORD(val, codebook)  \
> +#define DECODE_CODEWORD(val, codebook, SKIP_BITSf)  \

Nit: SKIP.

SKIP_BITSf is kinda ugly.

>  do {\
>  unsigned int rice_order, exp_order, switch_bits;\
>  unsigned int q, buf, bits;  \
> @@ -271,14 +271,14 @@ static int decode_picture_header(AVCodecContext *avctx, 
> const uint8_t *buf, cons
>  return AVERROR_INVALIDDATA; \
>  val = SHOW_UBITS(re, gb, bits) - (1 << exp_order) + \
>  ((switch_bits + 1) << rice_order);  \
> -SKIP_BITS(re, gb, bits);\
> +SKIP_BITSf(re, gb, bits);   \
>  } else if (rice_order) {\
>  SKIP_BITS(re, gb, q+1); \
>  val = (q << rice_order) + SHOW_UBITS(re, gb, rice_order);   \
> -SKIP_BITS(re, gb, rice_order);  \
> +SKIP_BITSf(re, gb, rice_order); \
>  } else {\
>  val = q;\
> -SKIP_BITS(re, gb, q+1); \
> +SKIP_BITSf(re, gb, q+1);\
>  }   \
>  } while (0)
>  
> @@ -296,7 +296,7 @@ static av_always_inline int 
> decode_dc_coeffs(GetBitContext *gb, int16_t *out,
>  
>  OPEN_READER(re, gb);
>  
> -DECODE_CODEWORD(code, FIRST_DC_CB);
> +DECODE_CODEWORD(code, FIRST_DC_CB, LAST_SKIP_BITS);
>  prev_dc = TOSIGNED(code);
>  out[0] = prev_dc;
>  
> @@ -305,7 +305,7 @@ static av_always_inline int 
> decode_dc_coeffs(GetBitContext *gb, int16_t *out,
>  code = 5;
>  sign = 0;
>  for (i = 1; i < blocks_per_slice; i++, out += 64) {
> -DECODE_CODEWORD(code, dc_codebook[FFMIN(code, 6U)]);
> +DECODE_CODEWORD(code, dc_codebook[FFMIN(code, 6U)], LAST_SKIP_BITS);
>  if(code) sign ^= -(code & 1);
>  else sign  = 0;
>  prev_dc += (((code + 1) >> 1) ^ sign) - sign;
> @@ -341,14 +341,14 @@ static av_always_inline int 
> decode_ac_coeffs(AVCodecContext *avctx, GetBitContex
>  if (!bits_left || (bits_left < 32 && !SHOW_UBITS(re, gb, bits_left)))
>  break;
>  
> -DECODE_CODEWORD(run, run_to_cb[FFMIN(run,  15)]);
> +DECODE_CODEWORD(run, run_to_cb[FFMIN(run,  15)], LAST_SKIP_BITS);
>  pos += run + 1;
>  if (pos >= max_coeffs) {
>  av_log(avctx, AV_LOG_ERROR, "ac tex damaged %d, %d\n", pos, 
> max_coeffs);
>  return AVERROR_INVALIDDATA;
>  }
>  
> -DECODE_CODEWORD(level, lev_to_cb[FFMIN(level, 9)]);
> +DECODE_CODEWORD(level, lev_to_cb[FFMIN(level, 9)], SKIP_BITS);
>  level += 1;
>  
>  i = pos >> log2_block_count;
> 

No comments about the actual change.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] avcodec/decklink_dec: use av_packet_add_side_data()

2017-10-01 Thread James Almer

It uses the existing buffer instead of allocating a new one.

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

 libavdevice/decklink_dec.cpp | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 386c64a177..025fee8602 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -390,10 +390,8 @@ uint8_t *get_metadata(AVFormatContext *avctx, uint16_t 
*buf, size_t width,
 clear_parity_bits(buf, len);
 data = vanc_to_cc(avctx, buf, width, data_len);
 if (data) {
-uint8_t *pkt_cc = av_packet_new_side_data(pkt, 
AV_PKT_DATA_A53_CC, data_len);
-if (pkt_cc)
-memcpy(pkt_cc, data, data_len);
-av_free(data);
+if (av_packet_add_side_data(pkt, AV_PKT_DATA_A53_CC, data, 
data_len) < 0)
+av_free(data);
 }
 } else {
 av_log(avctx, AV_LOG_DEBUG, "Unknown meta data DID = 0x%.2x SDID = 
0x%.2x\n",
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 2/3] avcodec/decklink_dec: remove av_dup_packet() usage

2017-10-01 Thread James Almer

It's no longer needed after the last commit.

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

 libavdevice/decklink_dec.cpp | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index b0c2fb8791..386c64a177 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -458,10 +458,6 @@ static int avpacket_queue_put(AVPacketQueue *q, AVPacket 
*pkt)
 av_log(q->avctx, AV_LOG_WARNING,  "Decklink input buffer overrun!\n");
 return -1;
 }
-/* duplicate the packet */
-if (av_dup_packet(pkt) < 0) {
-return -1;
-}
 
 pkt1 = (AVPacketList *)av_malloc(sizeof(AVPacketList));
 if (!pkt1) {
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 1/3] avcodec/decklink_dec: use av_packet_from_data() to create packets from an already allocated buffer

2017-10-01 Thread James Almer

As a side effect, the packets will now be refcounted.

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

 libavdevice/decklink_dec.cpp | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 8a14094474..b0c2fb8791 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -689,7 +689,6 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 //To be made sure it still applies
 pkt.flags   |= AV_PKT_FLAG_KEY;
 pkt.stream_index = ctx->video_st->index;
-pkt.data = (uint8_t *)frameBytes;
 pkt.size = videoFrame->GetRowBytes() *
videoFrame->GetHeight();
 //fprintf(stderr,"Video Frame size %d ts %d\n", pkt.size, pkt.pts);
@@ -749,16 +748,16 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 txt_pkt.pts = pkt.pts;
 txt_pkt.dts = pkt.dts;
 txt_pkt.stream_index = ctx->teletext_st->index;
-txt_pkt.data = txt_buf0;
-txt_pkt.size = txt_buf - txt_buf0;
-if (avpacket_queue_put(>queue, _pkt) < 0) {
+if (av_packet_from_data(_pkt, txt_buf0, txt_buf - 
txt_buf0) < 0 ||
+avpacket_queue_put(>queue, _pkt) < 0) {
 ++ctx->dropped;
 }
 }
 }
 }
 
-if (avpacket_queue_put(>queue, ) < 0) {
+if (av_packet_from_data(, (uint8_t *)frameBytes, pkt.size) < 0 ||
+avpacket_queue_put(>queue, ) < 0) {
 ++ctx->dropped;
 }
 }
@@ -779,9 +778,9 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 //fprintf(stderr,"Audio Frame size %d ts %d\n", pkt.size, pkt.pts);
 pkt.flags   |= AV_PKT_FLAG_KEY;
 pkt.stream_index = ctx->audio_st->index;
-pkt.data = (uint8_t *)audioFrameBytes;
 
-if (avpacket_queue_put(>queue, ) < 0) {
+if (av_packet_from_data(, (uint8_t *)audioFrameBytes, pkt.size) < 
0 ||
+avpacket_queue_put(>queue, ) < 0) {
 ++ctx->dropped;
 }
 }
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 2/3] avcodec/proresdec2: SKIP_BITS() does not work with len=32

2017-10-01 Thread Michael Niedermayer

Fixes: invalid shift
Fixes: 3482/clusterfuzz-testcase-minimized-5446915875405824

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

diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index e077908027..22dc70eeb4 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -267,7 +267,7 @@ static int decode_picture_header(AVCodecContext *avctx, 
const uint8_t *buf, cons
 \
 if (q > switch_bits) { /* exp golomb */ \
 bits = exp_order - switch_bits + (q<<1);\
-if (bits > MIN_CACHE_BITS)  \
+if (bits > FFMIN(MIN_CACHE_BITS, 31))   \
 return AVERROR_INVALIDDATA; \
 val = SHOW_UBITS(re, gb, bits) - (1 << exp_order) + \
 ((switch_bits + 1) << rice_order);  \
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 1/3] avcodec/hevcdsp_template: Fix undefined shift

2017-10-01 Thread Michael Niedermayer

Fixes: runtime error: left shift of negative value -255
Fixes: 3373/clusterfuzz-testcase-minimized-5604083912146944

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

diff --git a/libavcodec/hevcdsp_template.c b/libavcodec/hevcdsp_template.c
index 75763ce85e..e09c661759 100644
--- a/libavcodec/hevcdsp_template.c
+++ b/libavcodec/hevcdsp_template.c
@@ -1486,7 +1486,7 @@ static void FUNC(put_hevc_epel_bi_w_hv)(uint8_t *_dst, 
ptrdiff_t _dststride, uin
 for (y = 0; y < height; y++) {
 for (x = 0; x < width; x++)
 dst[x] = av_clip_pixel(((EPEL_FILTER(tmp, MAX_PB_SIZE) >> 6) * wx1 
+ src2[x] * wx0 +
-((ox0 + ox1 + 1) << log2Wd)) >> (log2Wd + 
1));
+((ox0 + ox1 + 1) * (1 << log2Wd))) >> 
(log2Wd + 1));
 tmp  += MAX_PB_SIZE;
 dst  += dststride;
 src2 += MAX_PB_SIZE;
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 3/3] avcodec/proresdec2: Use LAST_SKIP_BITS where possible

2017-10-01 Thread Michael Niedermayer

Signed-off-by: Michael Niedermayer 
---
 libavcodec/proresdec2.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 22dc70eeb4..9647aa7ebc 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -250,7 +250,7 @@ static int decode_picture_header(AVCodecContext *avctx, 
const uint8_t *buf, cons
 return pic_data_size;
 }
 
-#define DECODE_CODEWORD(val, codebook)  \
+#define DECODE_CODEWORD(val, codebook, SKIP_BITSf)  \
 do {\
 unsigned int rice_order, exp_order, switch_bits;\
 unsigned int q, buf, bits;  \
@@ -271,14 +271,14 @@ static int decode_picture_header(AVCodecContext *avctx, 
const uint8_t *buf, cons
 return AVERROR_INVALIDDATA; \
 val = SHOW_UBITS(re, gb, bits) - (1 << exp_order) + \
 ((switch_bits + 1) << rice_order);  \
-SKIP_BITS(re, gb, bits);\
+SKIP_BITSf(re, gb, bits);   \
 } else if (rice_order) {\
 SKIP_BITS(re, gb, q+1); \
 val = (q << rice_order) + SHOW_UBITS(re, gb, rice_order);   \
-SKIP_BITS(re, gb, rice_order);  \
+SKIP_BITSf(re, gb, rice_order); \
 } else {\
 val = q;\
-SKIP_BITS(re, gb, q+1); \
+SKIP_BITSf(re, gb, q+1);\
 }   \
 } while (0)
 
@@ -296,7 +296,7 @@ static av_always_inline int decode_dc_coeffs(GetBitContext 
*gb, int16_t *out,
 
 OPEN_READER(re, gb);
 
-DECODE_CODEWORD(code, FIRST_DC_CB);
+DECODE_CODEWORD(code, FIRST_DC_CB, LAST_SKIP_BITS);
 prev_dc = TOSIGNED(code);
 out[0] = prev_dc;
 
@@ -305,7 +305,7 @@ static av_always_inline int decode_dc_coeffs(GetBitContext 
*gb, int16_t *out,
 code = 5;
 sign = 0;
 for (i = 1; i < blocks_per_slice; i++, out += 64) {
-DECODE_CODEWORD(code, dc_codebook[FFMIN(code, 6U)]);
+DECODE_CODEWORD(code, dc_codebook[FFMIN(code, 6U)], LAST_SKIP_BITS);
 if(code) sign ^= -(code & 1);
 else sign  = 0;
 prev_dc += (((code + 1) >> 1) ^ sign) - sign;
@@ -341,14 +341,14 @@ static av_always_inline int 
decode_ac_coeffs(AVCodecContext *avctx, GetBitContex
 if (!bits_left || (bits_left < 32 && !SHOW_UBITS(re, gb, bits_left)))
 break;
 
-DECODE_CODEWORD(run, run_to_cb[FFMIN(run,  15)]);
+DECODE_CODEWORD(run, run_to_cb[FFMIN(run,  15)], LAST_SKIP_BITS);
 pos += run + 1;
 if (pos >= max_coeffs) {
 av_log(avctx, AV_LOG_ERROR, "ac tex damaged %d, %d\n", pos, 
max_coeffs);
 return AVERROR_INVALIDDATA;
 }
 
-DECODE_CODEWORD(level, lev_to_cb[FFMIN(level, 9)]);
+DECODE_CODEWORD(level, lev_to_cb[FFMIN(level, 9)], SKIP_BITS);
 level += 1;
 
 i = pos >> log2_block_count;
-- 
2.14.2

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

[FFmpeg-devel] [PATCH] avcodec/encode: remove usage of av_dup_packet()

2017-10-01 Thread James Almer

Signed-off-by: James Almer 
---
 libavcodec/encode.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 525ee1f5d6..dd50486bcf 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -222,10 +222,12 @@ int attribute_align_arg 
avcodec_encode_audio2(AVCodecContext *avctx,
 }
 avpkt->buf  = user_pkt.buf;
 avpkt->data = user_pkt.data;
-} else {
-if (av_dup_packet(avpkt) < 0) {
-ret = AVERROR(ENOMEM);
-}
+} else if (!avpkt->buf) {
+AVPacket tmp = { 0 };
+ret = av_packet_ref(, avpkt);
+if (ret < 0)
+return ret;
+*avpkt = tmp;
 }
 }
 
@@ -318,10 +320,12 @@ int attribute_align_arg 
avcodec_encode_video2(AVCodecContext *avctx,
 }
 avpkt->buf  = user_pkt.buf;
 avpkt->data = user_pkt.data;
-} else {
-if (av_dup_packet(avpkt) < 0) {
-ret = AVERROR(ENOMEM);
-}
+} else if (!avpkt->buf) {
+AVPacket tmp = { 0 };
+ret = av_packet_ref(, avpkt);
+if (ret < 0)
+return ret;
+*avpkt = tmp;
 }
 }
 
-- 
2.14.1

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

Re: [FFmpeg-devel] libavcodec/blockdsp : add AVX version

2017-10-01 Thread Ronald S. Bultje

Hi,

On Sun, Oct 1, 2017 at 7:46 PM, Martin Vignali 
wrote:

> I also modify several decoder/encoder, in order to fix the DECLARE_ALIGNED
> from 16 to 32
>

How did you decide which ones to change?

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

Re: [FFmpeg-devel] libavcodec/blockdsp : add AVX version

2017-10-01 Thread James Almer

On 10/1/2017 8:46 PM, Martin Vignali wrote:
> Hello,
> 
> After taking a look on blockdsp
> ./tests/checkasm/checkasm --test=blockdsp --bench
> 
> the result of clear_blocks is slower on my computer than the C version
> except if we add an avx version
> 
> In attach patch to add avx version
> for clear_block and clear_blocks
> 
> result : (Kaby Lake, Mac os 10.12)
> checkasm: all 6 tests passed
> blockdsp.clear_block_c: 15.9
> blockdsp.clear_block_mmx: 16.4
> blockdsp.clear_block_sse: 7.4
> blockdsp.clear_block_avx: 3.9
> 
> blockdsp.clear_blocks_c: 29.6
> blockdsp.clear_blocks_mmx: 99.1
> blockdsp.clear_blocks_sse: 48.4
> blockdsp.clear_blocks_avx: 24.4

On a Haswell Windows x64 I get

benchmarking with native FFmpeg timers
blockdsp.clear_block_c: 28.0
blockdsp.clear_block_mmx: 14.0
blockdsp.clear_block_sse: 6.0
blockdsp.clear_block_avx: 4.0
blockdsp.clear_blocks_c: 77.0
blockdsp.clear_blocks_mmx: 94.0
blockdsp.clear_blocks_sse: 46.0
blockdsp.clear_blocks_avx: 23.0

I used GCC 7.2. clear_blocks_mmx is slower than c for me as well, but
not the rest.
Your compiler seems to have done a much better job than mine. Is it
Clang? Does it somehow have vectorization enabled perhaps? Because
that's not supposed to happen.

> 
> I also modify several decoder/encoder, in order to fix the DECLARE_ALIGNED
> from 16 to 32
> 
> I run make fate SAMPLES=fate-suite/
> i have several errors, but after a check, these errors
> doesn't seems to be related to this patch

Make sure to clean your build folder if you recently pulled new commits
from the git repository. Reconfigure if necessary.

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

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

[FFmpeg-devel] libavcodec/blockdsp : add AVX version

2017-10-01 Thread Martin Vignali

Hello,

After taking a look on blockdsp
./tests/checkasm/checkasm --test=blockdsp --bench

the result of clear_blocks is slower on my computer than the C version
except if we add an avx version

In attach patch to add avx version
for clear_block and clear_blocks

result : (Kaby Lake, Mac os 10.12)
checkasm: all 6 tests passed
blockdsp.clear_block_c: 15.9
blockdsp.clear_block_mmx: 16.4
blockdsp.clear_block_sse: 7.4
blockdsp.clear_block_avx: 3.9

blockdsp.clear_blocks_c: 29.6
blockdsp.clear_blocks_mmx: 99.1
blockdsp.clear_blocks_sse: 48.4
blockdsp.clear_blocks_avx: 24.4

I also modify several decoder/encoder, in order to fix the DECLARE_ALIGNED
from 16 to 32

I run make fate SAMPLES=fate-suite/
i have several errors, but after a check, these errors
doesn't seems to be related to this patch

Martin


0001-libavcodec-blockdsp-add-AVX-version.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

2017-10-01 Thread James Almer

On 10/1/2017 8:31 PM, Carl Eugen Hoyos wrote:
> 2017-10-02 1:27 GMT+02:00 James Almer :
>> On 10/1/2017 8:22 PM, Carl Eugen Hoyos wrote:
>>> 2017-10-02 1:20 GMT+02:00 James Almer :
 On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote:
> 2017-10-02 0:55 GMT+02:00 James Almer :
>> Do it during install instead, like with the libraries.
>>
>> There's no benefit making a stripped copy of the CLI tools in the
>> build folder. Doing it during install saves build time and storage
>> space.
>
> This makes it much more difficult to request backtrace etc.
> from users.

 How so? The installed binaries are always stripped (unless configured
 with --disable-stripping), with or without this patch.
>>>
>>> We currently simply ask for "ffmpeg_g" output, even a user
>>> who has no idea about debugging either has this executable
>>> or not.
>>
>> Then we start asking for ffmpeg output. We always request testing and
>> backtraces using git head, and after this patch that will always be an
>> unstripped binary, so I don't get how this is an issue.
> 
> External packagers provide current binaries for all major operating
> systems, so I don't understand how asking current git head is
> related to asking debug information.

I'm honestly very confused. You do understand that the point of this
patch is to avoid a duplicate binary on the build folder and nothing
else, right? Installation is not affected. make install will behave
exactly the same after this patch as it had before, and that's what
external packagers package.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

2017-10-01 Thread Carl Eugen Hoyos

2017-10-02 1:27 GMT+02:00 James Almer :
> On 10/1/2017 8:22 PM, Carl Eugen Hoyos wrote:
>> 2017-10-02 1:20 GMT+02:00 James Almer :
>>> On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote:
 2017-10-02 0:55 GMT+02:00 James Almer :
> Do it during install instead, like with the libraries.
>
> There's no benefit making a stripped copy of the CLI tools in the
> build folder. Doing it during install saves build time and storage
> space.

 This makes it much more difficult to request backtrace etc.
 from users.
>>>
>>> How so? The installed binaries are always stripped (unless configured
>>> with --disable-stripping), with or without this patch.
>>
>> We currently simply ask for "ffmpeg_g" output, even a user
>> who has no idea about debugging either has this executable
>> or not.
>
> Then we start asking for ffmpeg output. We always request testing and
> backtraces using git head, and after this patch that will always be an
> unstripped binary, so I don't get how this is an issue.

External packagers provide current binaries for all major operating
systems, so I don't understand how asking current git head is
related to asking debug information.

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

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

2017-10-01 Thread James Almer

On 10/1/2017 8:22 PM, Carl Eugen Hoyos wrote:
> 2017-10-02 1:20 GMT+02:00 James Almer :
>> On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote:
>>> 2017-10-02 0:55 GMT+02:00 James Almer :
 Do it during install instead, like with the libraries.

 There's no benefit making a stripped copy of the CLI tools in the
 build folder. Doing it during install saves build time and storage
 space.
>>>
>>> This makes it much more difficult to request backtrace etc.
>>> from users.
>>
>> How so? The installed binaries are always stripped (unless configured
>> with --disable-stripping), with or without this patch.
> 
> We currently simply ask for "ffmpeg_g" output, even a user
> who has no idea about debugging either has this executable
> or not.
> 
> Carl Eugen

Then we start asking for ffmpeg output. We always request testing and
backtraces using git head, and after this patch that will always be an
unstripped binary, so I don't get how this is an issue.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

2017-10-01 Thread Carl Eugen Hoyos

2017-10-02 1:20 GMT+02:00 James Almer :
> On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote:
>> 2017-10-02 0:55 GMT+02:00 James Almer :
>>> Do it during install instead, like with the libraries.
>>>
>>> There's no benefit making a stripped copy of the CLI tools in the
>>> build folder. Doing it during install saves build time and storage
>>> space.
>>
>> This makes it much more difficult to request backtrace etc.
>> from users.
>
> How so? The installed binaries are always stripped (unless configured
> with --disable-stripping), with or without this patch.

We currently simply ask for "ffmpeg_g" output, even a user
who has no idea about debugging either has this executable
or not.

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

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

2017-10-01 Thread James Almer

On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote:
> 2017-10-02 0:55 GMT+02:00 James Almer :
>> Do it during install instead, like with the libraries.
>>
>> There's no benefit making a stripped copy of the CLI tools in the
>> build folder. Doing it during install saves build time and storage
>> space.
> 
> This makes it much more difficult to request backtrace etc.
> from users.

How so? The installed binaries are always stripped (unless configured
with --disable-stripping), with or without this patch.

> 
> A similar patch was rejected a few years ago.
> 
> 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

[FFmpeg-devel] [PATCH]lavf/img2dec: Auto-detect svg images

2017-10-01 Thread Carl Eugen Hoyos

Hi!

Attached patch implements auto-detection of svg images.

Please review, Carl Eugen
From f06137f38f166740565e58d5c7c88777508f59ec Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 2 Oct 2017 01:13:29 +0200
Subject: [PATCH] lavf/img2dec: Auto-detect svg images.

---
 libavformat/img2dec.c |   17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 19cae87..468c820 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -34,6 +34,7 @@
 #include "internal.h"
 #include "img2.h"
 #include "libavcodec/mjpeg.h"
+#include "subtitles.h"
 
 #if HAVE_GLOB
 /* Locally define as 0 (bitwise-OR no-op) any missing glob options that
@@ -875,8 +876,20 @@ static int sunrast_probe(AVProbeData *p)
 
 static int svg_probe(AVProbeData *p)
 {
-if (av_match_ext(p->filename, "svg") || av_match_ext(p->filename, "svgz"))
-return AVPROBE_SCORE_EXTENSION + 1;
+const uint8_t *b = p->buf;
+const uint8_t *end = p->buf + p->buf_size;
+if (memcmp(p->buf, "= end)
+return 0;
+if (!strstr(b, "___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

2017-10-01 Thread Carl Eugen Hoyos

2017-10-02 0:55 GMT+02:00 James Almer :
> Do it during install instead, like with the libraries.
>
> There's no benefit making a stripped copy of the CLI tools in the
> build folder. Doing it during install saves build time and storage
> space.

This makes it much more difficult to request backtrace etc.
from users.

A similar patch was rejected a few years ago.

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

[FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

2017-10-01 Thread James Almer

Do it during install instead, like with the libraries.

There's no benefit making a stripped copy of the CLI tools in the
build folder. Doing it during install saves build time and storage
space.

Signed-off-by: James Almer 
---
FATE slots will love this, especially those running on disk space
deprived VMs.

 Makefile  |  6 +-
 doc/examples/Makefile |  7 ++-
 fftools/Makefile  | 10 +-
 3 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/Makefile b/Makefile
index 3007da50f7..1c6bc2fbb9 100644
--- a/Makefile
+++ b/Makefile
@@ -96,11 +96,7 @@ include $(SRC_PATH)/doc/examples/Makefile
 
 libavcodec/utils.o libavformat/utils.o libavdevice/avdevice.o 
libavfilter/avfilter.o libavutil/utils.o libpostproc/postprocess.o 
libswresample/swresample.o libswscale/utils.o : libavutil/ffversion.h
 
-$(PROGS): %$(PROGSSUF)$(EXESUF): %$(PROGSSUF)_g$(EXESUF)
-   $(CP) $< $@
-   $(STRIP) $@
-
-%$(PROGSSUF)_g$(EXESUF): $(FF_DEP_LIBS)
+$(PROGS): %$(PROGSSUF)$(EXESUF): $(FF_DEP_LIBS)
$(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(OBJS-$*) $(FF_EXTRALIBS)
 
 VERSION_SH  = $(SRC_PATH)/ffbuild/version.sh
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index ff958d33c6..c813da4505 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -21,16 +21,14 @@ DOC_EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += 
transcode_aac
 DOC_EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE)   += transcoding
 
 DOC_EXAMPLES   := $(DOC_EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)$(EXESUF))
-DOC_EXAMPLES_G := 
$(DOC_EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)_g$(EXESUF))
 ALL_DOC_EXAMPLES   := $(DOC_EXAMPLES) 
$(DOC_EXAMPLES-:%=doc/examples/%$(PROGSSUF)$(EXESUF))
-ALL_DOC_EXAMPLES_G := $(DOC_EXAMPLES_G) 
$(DOC_EXAMPLES-:%=doc/examples/%$(PROGSSUF)_g$(EXESUF))
 PROGS  += $(DOC_EXAMPLES)
 
 EXAMPLES_FILES := $(wildcard $(SRC_PATH)/doc/examples/*.c) 
$(SRC_PATH)/doc/examples/README
 EXAMPLE_MAKEFILE := $(SRC_PATH)/doc/examples/Makefile
 
 $(foreach P,$(DOC_EXAMPLES),$(eval OBJS-$(P:%$(PROGSSUF)$(EXESUF)=%) = 
$(P:%$(PROGSSUF)$(EXESUF)=%).o))
-$(DOC_EXAMPLES_G): %$(PROGSSUF)_g$(EXESUF): %.o
+$(DOC_EXAMPLES): %$(PROGSSUF)$(EXESUF): %.o
 
 examples: $(DOC_EXAMPLES)
 
@@ -40,8 +38,7 @@ OBJDIRS += doc/examples
 DOXY_INPUT += $(DOC_EXAMPLES:%$(PROGSSUF)$(EXESUF)=%.c)
 
 examplesclean:
-   $(RM) $(ALL_DOC_EXAMPLES) $(ALL_DOC_EXAMPLES_G)
-   $(RM) $(CLEANSUFFIXES:%=doc/examples/%)
+   $(RM) $(ALL_DOC_EXAMPLES) $(CLEANSUFFIXES:%=doc/examples/%)
 
 docclean:: examplesclean
 
diff --git a/fftools/Makefile b/fftools/Makefile
index 094f6d6265..37ff131165 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -8,7 +8,6 @@ PROGS   += $(AVPROGS)
 
 AVBASENAMES  = ffmpeg ffplay ffprobe ffserver
 ALLAVPROGS   = $(AVBASENAMES:%=%$(PROGSSUF)$(EXESUF))
-ALLAVPROGS_G = $(AVBASENAMES:%=%$(PROGSSUF)_g$(EXESUF))
 
 OBJS-ffmpeg+= fftools/ffmpeg_opt.o 
fftools/ffmpeg_filter.o fftools/ffmpeg_hw.o
 OBJS-ffmpeg-$(CONFIG_CUVID)+= fftools/ffmpeg_cuvid.o
@@ -22,11 +21,11 @@ OBJS-ffserver  += 
fftools/ffserver_config.o
 define DOFFTOOL
 OBJS-$(1)-$(CONFIG_OPENCL) += fftools/cmdutils_opencl.o
 OBJS-$(1) += fftools/cmdutils.o fftools/$(1).o $(OBJS-$(1)-yes)
-$(1)$(PROGSSUF)_g$(EXESUF): $$(OBJS-$(1))
+$(1)$(PROGSSUF)$(EXESUF): $$(OBJS-$(1))
 $$(OBJS-$(1)): | fftools
 $$(OBJS-$(1)): CFLAGS  += $(CFLAGS-$(1))
-$(1)$(PROGSSUF)_g$(EXESUF): LDFLAGS += $(LDFLAGS-$(1))
-$(1)$(PROGSSUF)_g$(EXESUF): FF_EXTRALIBS += $(EXTRALIBS-$(1))
+$(1)$(PROGSSUF)$(EXESUF): LDFLAGS += $(LDFLAGS-$(1))
+$(1)$(PROGSSUF)$(EXESUF): FF_EXTRALIBS += $(EXTRALIBS-$(1))
 -include $$(OBJS-$(1):.o=.d)
 endef
 
@@ -47,6 +46,7 @@ install-progs-$(CONFIG_SHARED): install-libs
 install-progs: install-progs-yes $(AVPROGS)
$(Q)mkdir -p "$(BINDIR)"
$(INSTALL) -c -m 755 $(AVPROGS) "$(BINDIR)"
+   $(STRIP) $(addprefix "$(BINDIR)/", $(AVPROGS))
 
 uninstall: uninstall-progs
 
@@ -54,4 +54,4 @@ uninstall-progs:
$(RM) $(addprefix "$(BINDIR)/", $(ALLAVPROGS))
 
 clean::
-   $(RM) $(ALLAVPROGS) $(ALLAVPROGS_G) $(CLEANSUFFIXES:%=fftools/%)
+   $(RM) $(ALLAVPROGS) $(CLEANSUFFIXES:%=fftools/%)
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH] aacenc: WIP support for PCEs

2017-10-01 Thread pkv.stream


Le 02/10/2017 à 12:43 AM, Carl Eugen Hoyos a écrit :

2017-10-02 0:40 GMT+02:00 pkv.stream :

Hi atomnuker,

got your PCE working;

the patch you attached contains tabs, they cannot be committed
to the FFmpeg repository, please remove them.
(Or one tab.)


thanks for pointing out.
Removed the offending tab.



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



From 647fb61708bc1279f9dc17c679052a778dce5fbb Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Sun, 24 Sep 2017 16:11:17 +0200
Subject: [PATCH] avcodec/aacenc: PCE for all ffmpeg usual layouts

PCE for all usual layouts listed in channel_layout_map
(channel_layout.c) have been added.
All encodes with PCE are decoded correctly by ffmpeg aac decoder (not
checked with others).
The correctness of the channel positions in the encodes have been checked
 by splitting the channels to independent audio tracks.
Two non standard layouts have been added in the PCE for support of 9 and
 10 channels, which are useful for ambisonics.
For layouts with LFE, the LFE element has been replaced by a SCE because
the encoder always puts the LFE as last channel, irrespective of
config_map and reorder_map. This is not optimal but it enables these
layouts.
---
 libavcodec/aacenc.h | 239 ++--
 1 file changed, 233 insertions(+), 6 deletions(-)

diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
index 346d989..31afd04 100644
--- a/libavcodec/aacenc.h
+++ b/libavcodec/aacenc.h
@@ -99,6 +99,33 @@ typedef struct AACPCEInfo {
 uint8_t reorder_map[16]; ///< maps channels from lavc 
to aac order
 } AACPCEInfo;
 
+/**
+ *List of PCE (Program Configuration Element) for the channel layouts listed 
in channel_layout.h
+ *
+ *For those wishing in the future to add other layouts:
+ * - num_ele: number of elements in each group of front, side, back, lfe 
channels;
+ * (an element is of type SCE (single channel) , CPE (channel pair) for the 
first 3 groups;
+ * and is LFE for LFE group).
+ * - pairing: 0 for an SCE element or 1 for a CPE; does not apply to LFE group
+ * - index: there are three independent indices for SCE, CPE and LFE;
+ *   they are incremented irrespective of the group to which the element 
belongs;
+ *   they are not reset when going from one group to another
+ *
+ *   Example: for 7.0 channel layout,
+ *  .pairing = { { 1, 0 }, { 1 }, { 1 }, }, (3 CPE and 1 SCE in front 
group)
+ *  .index = { { 0, 0 }, { 1 }, { 2 }, }, index is 0 for the single SCE
+ *   but goes from 0 to 2 for the CPEs .
+ *
+ *  The index order impacts the channel ordering. But is otherwise arbitrary
+ * (the sequence could have been 2, 0, 1 instead of 0, 1, 2).
+ * Spec allows discontinuous indices, e.g. if one has a total of two SCE, 
SCE.0 SCE.15 is OK per spec;
+ * BUT it won't be decoded by ffmpeg aac decoder which at this time requires 
that indices fully cover some range starting from 0.
+ * (SCE.1 SCE.0 is OK but not SCE.0 SCE.15).
+ *
+ * - config_map: total number of elements and their types. Beware, the way the 
types are ordered impacts the final channel ordering.
+ * - reorder_map: reorders the channels.
+ *
+ */
 static const AACPCEInfo aac_pce_configs[] = {
 {
 .layout = AV_CH_LAYOUT_MONO,
@@ -117,20 +144,220 @@ static const AACPCEInfo aac_pce_configs[] = {
 .reorder_map = { 0, 1 },
 },
 {
+.layout = AV_CH_LAYOUT_2POINT1,
+.num_ele = { 1, 0, 0, 1 },
+.pairing = { { 1 }, },
+.index = { { 0 },{ 0 },{ 0 },{ 0 } },
+.config_map = { 2, TYPE_CPE, TYPE_LFE },
+.reorder_map = { 0, 1, 2 },
+},
+{
+.layout = AV_CH_LAYOUT_2_1,
+.num_ele = { 1, 0, 1, 0 },
+.pairing = { { 1 },{ 0 },{ 0 } },
+.index = { { 0 },{ 0 },{ 0 }, },
+.config_map = { 2, TYPE_CPE, TYPE_SCE },
+.reorder_map = { 0, 1, 2 },
+},
+{
 .layout = AV_CH_LAYOUT_SURROUND,
 .num_ele = { 2, 0, 0, 0 },
 .pairing = { { 1, 0 }, },
-.index = { { 0, 1 }, },
-.config_map = { 2, TYPE_SCE, TYPE_CPE },
-.reorder_map = { 2, 0, 1 },
+.index = { { 0, 0 }, },
+.config_map = { 2, TYPE_CPE, TYPE_SCE, },
+.reorder_map = { 0, 1, 2 },
+},
+{
+.layout = AV_CH_LAYOUT_3POINT1,
+.num_ele = { 2, 0, 0, 1 },
+.pairing = { { 1, 0 }, },
+.index = { { 0, 0 }, { 0 }, { 0 }, { 0 }, },
+.config_map = { 3, TYPE_CPE, TYPE_SCE, TYPE_LFE },
+.reorder_map = { 0, 1, 2, 3 },
 },
 {
 .layout = AV_CH_LAYOUT_4POINT0,
 .num_ele = { 2, 0, 1, 0 },
 .pairing = { { 1, 0 }, { 0 }, { 0 }, },
-.index = { { 0, 1 }, { 0 }, { 0 } },
-.config_map = { 3, TYPE_SCE, TYPE_CPE, TYPE_SCE },
-.reorder_map = { 2, 0, 1, 3 },
+

Re: [FFmpeg-devel] [PATCH] aacenc: WIP support for PCEs

2017-10-01 Thread Carl Eugen Hoyos

2017-10-02 0:40 GMT+02:00 pkv.stream :
> Hi atomnuker,
>
> got your PCE working;

the patch you attached contains tabs, they cannot be committed
to the FFmpeg repository, please remove them.
(Or one tab.)

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

Re: [FFmpeg-devel] [PATCH] aacenc: WIP support for PCEs

2017-10-01 Thread pkv.stream


Hi atomnuker,

got your PCE working;
my previous issues where index related and were the reasons ffmpeg aac 
decoder would issue errors.


So found out:
- index is not reset between groups of front, side, back;
- it runs actually for each type (SCE, CPE, LFE)
- for ffmpeg aac decoder to work, the list of index for a type must be 
continuous (and probably start with 0, although the order is arbitrary); 
ex: 0 1 2 or 2 0 1 are ok but not 0 4

I've corrected your PCE table accordingly.

I've tested the correctness of the PCE encode for all the layouts listed 
in the attachment through the following systematic procedure:
 - pcm stream with required number of channels declared with 
-channel_layout identical to destination (to avoid any automatic channel 
matrixing)
- the encoded file was decoded, channels split into mono streams in the 
order of the channels. This allowed me to check the channel orders are 
fine as well as the correctness of the aac encode itself.


For channels layouts with LFE starting from 4.1, I have had issues with 
the order of the LFE channel. When encoding with PCE, the LFE channel is 
always positioned as the last one even if the PCE positions it 
elsewhere; the -config_map and -reorder_map options make no difference.


So either these layouts with LFE should be removed from the table; or a 
workaround could be to replace the LFE by a SCE. This is not 
sub-optimal, in terms of bitrate. But maybe as a convenience to user 
this might be ok provisionally, until a real fix is found.
I have no opinion on the matter, but have provided working PCEs for 
these layouts with LFE, in case.


I have added two convenience layouts in the PCE table , with 9 and 10 
channels. They might be of use for order 2 ambisonics or mixed 
ambisonics (of course this assumes the user has ordered his channels in 
a meaningful way for a third party software since ffmpeg does not 
provide ambisonics information yet).


Also, during the research into this PCE, I uncovered a bug with 
-channel_layout option which initially is not passed correctly for 
non-default layouts; output filters detect the layout as the default one 
(for instance 4.0 instead of quad).
This means there are auto-inserts of unneeded filters remapping the 
channels.
For instance when encoding a quad pcm source  to aac file with quad 
layout with PCE, an auto-insertion of aformat filter remaps quad source 
to 4.0.

This completely blows up the aac PCE encode since channel matrixing occurs.
I have a separate patch for that issue (see ticket 6706).

regards

From 507fa698974fe72d297e01c90396e602de0d42da Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Sun, 24 Sep 2017 16:11:17 +0200
Subject: [PATCH] avcodec/aacenc: PCE for all ffmpeg usual layouts

PCE for all usual layouts listed in channel_layout_map
(channel_layout.c) have been added.
All encodes with PCE are decoded correctly by ffmpeg aac decoder (not
checked with others).
The correctness of the channel positions in the encodes have been checked
 by splitting the channels to independent audio tracks.
Two non standard layouts have been added in the PCE for support of 9 and
 10 channels, which are useful for ambisonics.
For layouts with LFE, the LFE element has been replaced by a SCE because
the encoder always puts the LFE as last channel, irrespective of
config_map and reorder_map. This is not optimal but it enables these
layouts.
---
 libavcodec/aacenc.c |   2 +-
 libavcodec/aacenc.h | 239 ++--
 2 files changed, 234 insertions(+), 7 deletions(-)

diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
index 2996996..faa0684 100644
--- a/libavcodec/aacenc.c
+++ b/libavcodec/aacenc.c
@@ -565,7 +565,7 @@ static int aac_encode_frame(AVCodecContext *avctx, AVPacket 
*avpkt,
 return 0;
 }
 
-copy_input_samples(s, frame);
+   copy_input_samples(s, frame);
 if (s->psypp)
 ff_psy_preprocess(s->psypp, s->planar_samples, s->channels);
 
diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
index 346d989..31afd04 100644
--- a/libavcodec/aacenc.h
+++ b/libavcodec/aacenc.h
@@ -99,6 +99,33 @@ typedef struct AACPCEInfo {
 uint8_t reorder_map[16]; ///< maps channels from lavc 
to aac order
 } AACPCEInfo;
 
+/**
+ *List of PCE (Program Configuration Element) for the channel layouts listed 
in channel_layout.h
+ *
+ *For those wishing in the future to add other layouts:
+ * - num_ele: number of elements in each group of front, side, back, lfe 
channels;
+ * (an element is of type SCE (single channel) , CPE (channel pair) for the 
first 3 groups;
+ * and is LFE for LFE group).
+ * - pairing: 0 for an SCE element or 1 for a CPE; does not apply to LFE group
+ * - index: there are three independent indices for SCE, CPE and LFE;
+ *   they are incremented irrespective of the group to which the element 
belongs;
+ *   they are not reset when going from one group to another
+ *
+ *   Example:

Re: [FFmpeg-devel] [PATCH] avcodec/avpacket: deprecate av_copy_packet_side_data()

2017-10-01 Thread James Almer

On 9/25/2017 5:20 PM, James Almer wrote:
> It leaks memory and destroys the dst packet in case of failure, and it
> ultimately duplicates functionality already existing in the saner
> av_packet_copy_props().
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/avcodec.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 5c84974e03..bca9f30de3 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -4621,7 +4621,10 @@ int av_copy_packet(AVPacket *dst, const AVPacket *src);
>   * Copy packet side data
>   *
>   * @return 0 on success, negative AVERROR on fail
> + *
> + * @deprecated Use av_packet_copy_props
>   */
> +attribute_deprecated
>  int av_copy_packet_side_data(AVPacket *dst, const AVPacket *src);
>  
>  /**

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

Re: [FFmpeg-devel] libavcodec/exr : add x86 SIMD for predictor

2017-10-01 Thread James Almer

On 10/1/2017 4:52 PM, Martin Vignali wrote:
> Hello,
> 
> in attach new patch
> 
> pass fate test for me (X86_64 osX)
> 
> Check asm (Kaby Lake)
> 
> checkasm: all 5 tests passed
> predictor_c: 11042.9
> predictor_ssse3: 1736.4
> predictor_avx: 1675.4
> predictor_avx2: 1245.4
> ...
> 
> Martin

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

Re: [FFmpeg-devel] [RFC] fate/cineform : add test for yuv 10b

2017-10-01 Thread Carl Eugen Hoyos

2017-09-25 11:46 GMT+02:00 Martin Vignali :
>>
>>
>> Yes.
>>
>> Or we could switch now to a file that we know we will have
>> to add.
>> No strong opinion here: I just wanted to point out that we
>> will need another sample - that we already have. I wonder
>> if keeping the size of fate small(er) is also a relevant
>> argument.
>>
>
> Ok,
> feel free to replace the file, and send a new fate test patch

Alternative patch attached.
File in http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket6675/
Current file size: 1244380
New file: 2892690

The new file shows a visual issue with the current decoder.

Carl Eugen
From aabf425e19247ad0be3d667842fc81f63ae6ea3b Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Sun, 1 Oct 2017 21:57:54 +0200
Subject: [PATCH] fate: Add test for cineform yuv 10b.

---
 tests/Makefile|1 +
 tests/fate/cineform.mak   |5 +
 tests/ref/fate/cineform-yuv10b-hd |6 ++
 3 files changed, 12 insertions(+)
 create mode 100644 tests/fate/cineform.mak
 create mode 100644 tests/ref/fate/cineform-yuv10b-hd

diff --git a/tests/Makefile b/tests/Makefile
index 99f7e17..67d14dc 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -116,6 +116,7 @@ include $(SRC_PATH)/tests/fate/bmp.mak
 include $(SRC_PATH)/tests/fate/canopus.mak
 include $(SRC_PATH)/tests/fate/cdxl.mak
 include $(SRC_PATH)/tests/fate/checkasm.mak
+include $(SRC_PATH)/tests/fate/cineform.mak
 include $(SRC_PATH)/tests/fate/concatdec.mak
 include $(SRC_PATH)/tests/fate/cover-art.mak
 include $(SRC_PATH)/tests/fate/dca.mak
diff --git a/tests/fate/cineform.mak b/tests/fate/cineform.mak
new file mode 100644
index 000..ca65eef
--- /dev/null
+++ b/tests/fate/cineform.mak
@@ -0,0 +1,5 @@
+FATE_CINEFORM += fate-cineform-yuv10b-hd
+fate-cineform-yuv10b-hd: CMD = framecrc -i $(TARGET_SAMPLES)/cineform/cineform_colour.mov -pix_fmt yuv422p10le -an
+
+FATE_SAMPLES_AVCONV-$(call DEMDEC, MOV, CFHD) += $(FATE_CINEFORM)
+fate-cineform: $(FATE_CINEFORM)
diff --git a/tests/ref/fate/cineform-yuv10b-hd b/tests/ref/fate/cineform-yuv10b-hd
new file mode 100644
index 000..200f504
--- /dev/null
+++ b/tests/ref/fate/cineform-yuv10b-hd
@@ -0,0 +1,6 @@
+#tb 0: 1/30
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 1920x1080
+#sar 0: 1/1
+0,  0,  0,1,  8294400, 0x46ef6c43
-- 
1.7.10.4

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

Re: [FFmpeg-devel] libavcodec/exr : add x86 SIMD for predictor

2017-10-01 Thread Martin Vignali

Hello,

in attach new patch

pass fate test for me (X86_64 osX)

Check asm (Kaby Lake)

checkasm: all 5 tests passed
predictor_c: 11042.9
predictor_ssse3: 1736.4
predictor_avx: 1675.4
predictor_avx2: 1245.4
...

Martin


0001-libavcodec-exr-add-x86-SIMD-for-predictor.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2017-10-01 Thread Carl Eugen Hoyos

2017-10-01 20:44 GMT+02:00 Ronald S. Bultje :
> Hi,
>
> On Sun, Oct 1, 2017 at 12:17 PM, Carl Eugen Hoyos 
> wrote:
>
>> 2017-10-01 14:03 GMT+02:00 Ronald S. Bultje :
>> > Hi,
>> >
>> > On Sat, Sep 30, 2017 at 3:40 PM, Carl Eugen Hoyos 
>> > wrote:
>>
>> >> Attached patch also support GBRP, I don't know if this is a good or
>> >> bad idea.
>> >
>> > I would personally probably err on the side of caution, but no strong
>> > opinions. If this works (I assume it does), I guess it's fine (?).
>>
>> Do you want me to commit (with or without GBRP)?
>>
>> Sorry, I really don't know if this is supposed to do something
>> useful or not.
>>
>
> vmafmotion in itself isn't very useful, but it's part of the native vmaf
> filter, which will be quite useful.
>
> I'd suggest to commit it without GBRP support for now. I'm not against GBRP
> support per se, I just don't know if the results are meaningful (since we'd
> base the metric on the G channel only), so I'd rather be conservative.

Pushed without GBRP, thank you!

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

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

2017-10-01 Thread Ronald S. Bultje

Hi,

On Sun, Oct 1, 2017 at 12:17 PM, Carl Eugen Hoyos 
wrote:

> 2017-10-01 14:03 GMT+02:00 Ronald S. Bultje :
> > Hi,
> >
> > On Sat, Sep 30, 2017 at 3:40 PM, Carl Eugen Hoyos 
> > wrote:
>
> >> Attached patch also support GBRP, I don't know if this is a good or
> >> bad idea.
> >
> > I would personally probably err on the side of caution, but no strong
> > opinions. If this works (I assume it does), I guess it's fine (?).
>
> Do you want me to commit (with or without GBRP)?
>
> Sorry, I really don't know if this is supposed to do something
> useful or not.
>

vmafmotion in itself isn't very useful, but it's part of the native vmaf
filter, which will be quite useful.

I'd suggest to commit it without GBRP support for now. I'm not against GBRP
support per se, I just don't know if the results are meaningful (since we'd
base the metric on the G channel only), so I'd rather be conservative.

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

[FFmpeg-devel] [PATCH 2/2] mov: fix non-monotonous DTS when fragments overlap in time

2017-10-01 Thread John Stebbins

---
 libavformat/mov.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index c7422cd9ed..bc3c9cb35b 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4267,6 +4267,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 int data_offset = 0;
 unsigned entries, first_sample_flags = frag->flags;
 int flags, distance, i;
+int64_t last_dts = AV_NOPTS_VALUE;
 
 for (i = 0; i < c->fc->nb_streams; i++) {
 if (c->fc->streams[i]->id == frag->track_id) {
@@ -4294,6 +4295,10 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 offset = frag->base_data_offset + data_offset;
 distance = 0;
 av_log(c->fc, AV_LOG_TRACE, "first sample flags 0x%x\n", 
first_sample_flags);
+
+if (st->nb_index_entries)
+last_dts = st->index_entries[st->nb_index_entries-1].timestamp;
+
 for (i = 0; i < entries && !pb->eof_reached; i++) {
 unsigned sample_size = frag->size;
 int sample_flags = i ? frag->flags : first_sample_flags;
@@ -4302,6 +4307,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 int keyframe = 0;
 int ctts_index = 0;
 int old_nb_index_entries = st->nb_index_entries;
+int index_entry_flags = 0;
 
 if (flags & MOV_TRUN_SAMPLE_DURATION) sample_duration = avio_rb32(pb);
 if (flags & MOV_TRUN_SAMPLE_SIZE) sample_size = avio_rb32(pb);
@@ -4338,10 +4344,16 @@ static int mov_read_trun(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 keyframe =
 !(sample_flags & (MOV_FRAG_SAMPLE_FLAG_IS_NON_SYNC |
   MOV_FRAG_SAMPLE_FLAG_DEPENDS_YES));
-if (keyframe)
+if (keyframe) {
 distance = 0;
+index_entry_flags |= AVINDEX_KEYFRAME;
+}
+// Fragments can overlap in time.  Discard overlapping frames after
+// decoding.
+if (last_dts >= dts)
+index_entry_flags |= AVINDEX_DISCARD_FRAME;
 ctts_index = add_index_entry(st, offset, dts, sample_size, distance,
- keyframe ? AVINDEX_KEYFRAME : 0);
+ index_entry_flags);
 if (ctts_index >= 0 && old_nb_index_entries < st->nb_index_entries) {
 unsigned int size_needed = st->nb_index_entries * 
sizeof(*sc->ctts_data);
 unsigned int request_size = size_needed > sc->ctts_allocated_size ?
-- 
2.13.5

___
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-10-01 Thread Carl Eugen Hoyos

2017-09-29 5:38 GMT+02:00 Jeyapal, Karthick :
>>On 9/29/17, 7:36 AM, "James Almer"  wrote:
>>>
>>> +static inline uint16_t parity (uint16_t x)
>>> +{
>>> +uint16_t i;
>>> +for (i = 4 * sizeof (x); i > 0; i /= 2)
>>> +x ^= x >> i;
>>> +return x & 1;
>>> +}
>>
>>Can't you use av_parity() instead?
>
> Yes, I can. Thanks for pointing it out. But that patch has been submitted
> already. Hence, I have attached a fresh patch with this suggested change.

Pushed assuming you have tested this.

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/dvbsubdec: Split best score computation out of loop in compute_default_clut()

2017-10-01 Thread Clément Bœsch

On Sun, Oct 01, 2017 at 06:10:36PM +0200, Michael Niedermayer wrote:
> 3% faster
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dvbsubdec.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/dvbsubdec.c b/libavcodec/dvbsubdec.c
> index 6a40f2376f..e60bf41936 100644
> --- a/libavcodec/dvbsubdec.c
> +++ b/libavcodec/dvbsubdec.c
> @@ -681,14 +681,17 @@ static void compute_default_clut(AVSubtitleRect *rect, 
> int w, int h)
>  int l_r = x+1  int l_t = y ? L(0, -1) : 1;
>  int l_b = y+1 -int score;
>  if (l_m)
>  continue;
>  scoretab[v] += l_l + l_r + l_t + l_b;
> -score = 1024LL*scoretab[v] / counttab[v];
> +}
> +}
> +for (x = 0; x < 256; x++) {
> +if (scoretab[x]) {
> +int score = 1024LL*scoretab[x] / counttab[x];
>  if (score > bestscore) {
>  bestscore = score;
> -bestv = v;
> +bestv = x;
>  }
>  }
>  }

OK

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/dvbsubdec: Factor a few expressions out of compute_default_clut()

2017-10-01 Thread Clément Bœsch

On Sun, Oct 01, 2017 at 06:10:35PM +0200, Michael Niedermayer wrote:
> 32% faster loop
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dvbsubdec.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/libavcodec/dvbsubdec.c b/libavcodec/dvbsubdec.c
> index b683109643..6a40f2376f 100644
> --- a/libavcodec/dvbsubdec.c
> +++ b/libavcodec/dvbsubdec.c
> @@ -653,8 +653,9 @@ static void compute_default_clut(AVSubtitleRect *rect, 
> int w, int h)
>  uint8_t list_inv[256];
>  int counttab[256] = {0};
>  int count, i, x, y;
> +ptrdiff_t ls = rect->linesize[0];

You use this variable in 3 places where the length doesn't matter; please
use a longer name (maybe "lsize", "stride", or even "linesize").

>  
> -#define V(x,y) rect->data[0][(x) + (y)*rect->linesize[0]]
> +#define V(x,y) rect->data[0][(x) + (y)*ls]
>  for (y = 0; y  for (x = 0; x  int v = V(x,y) + 1;
> @@ -665,7 +666,7 @@ static void compute_default_clut(AVSubtitleRect *rect, 
> int w, int h)
>  counttab[v-1] += !!((v!=vl) + (v!=vr) + (v!=vt) + (v!=vb));
>  }
>  }
> -#define L(x,y) list[ rect->data[0][(x) + (y)*rect->linesize[0]] ]

> +#define L(x,y) list[ d[(x) + (y)*ls] ]

since you modify this line, feel free to drop the extra spacing
after and before the [].

>  
>  for (i = 0; i<256; i++) {
>  int scoretab[256] = {0};
> @@ -673,12 +674,13 @@ static void compute_default_clut(AVSubtitleRect *rect, 
> int w, int h)
>  int bestv = 0;
>  for (y = 0; y  for (x = 0; x -int v = rect->data[0][x + y*rect->linesize[0]];
> +uint8_t *d = >data[0][x + y*ls];
> +int v = *d;
>  int l_m = list[v];
> -int l_l = x ? L(x-1, y) : 1;
> -int l_r = x+1 -int l_t = y ? L(x, y-1) : 1;
> -int l_b = y+1 +int l_l = x ? L(-1, 0) : 1;
> +int l_r = x+1 +int l_t = y ? L(0, -1) : 1;
> +int l_b = y+1

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

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

2017-10-01 Thread Carl Eugen Hoyos

2017-09-27 18:08 GMT+02:00 Carl Eugen Hoyos :

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

New patch with auto-detection attached, passes probecheck.

Please comment, Carl Eugen
From 5539b3a9f6195fed91cbf10d4ecb2b7e6c75ac99 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 1 Oct 2017 18:13:14 +0200
Subject: [PATCH] lavf/amr: Add amrnb and amrwb demuxers.

Fixes ticket #6678.
---
 libavformat/Makefile |2 ++
 libavformat/allformats.c |2 ++
 libavformat/amr.c|   10 ++-
 libavformat/amr.h|   34 +
 libavformat/amrnb.c  |   73 ++
 libavformat/amrwb.c  |   73 ++
 libavformat/version.h|4 +--
 7 files changed, 189 insertions(+), 9 deletions(-)
 create mode 100644 libavformat/amr.h
 create mode 100644 libavformat/amrnb.c
 create mode 100644 libavformat/amrwb.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index df709c29..bf8fb86 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -87,6 +87,8 @@ OBJS-$(CONFIG_AIFF_MUXER)+= aiffenc.o id3v2enc.o
 OBJS-$(CONFIG_AIX_DEMUXER)   += aixdec.o
 OBJS-$(CONFIG_AMR_DEMUXER)   += amr.o
 OBJS-$(CONFIG_AMR_MUXER) += amr.o
+OBJS-$(CONFIG_AMRNB_DEMUXER) += amrnb.o
+OBJS-$(CONFIG_AMRWB_DEMUXER) += amrwb.o
 OBJS-$(CONFIG_ANM_DEMUXER)   += anm.o
 OBJS-$(CONFIG_APC_DEMUXER)   += apc.o
 OBJS-$(CONFIG_APE_DEMUXER)   += ape.o apetag.o img2.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 405ddb5..dc8984e 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -63,6 +63,8 @@ static void register_all(void)
 REGISTER_MUXDEMUX(AIFF, aiff);
 REGISTER_DEMUXER (AIX,  aix);
 REGISTER_MUXDEMUX(AMR,  amr);
+REGISTER_DEMUXER (AMRNB,amrnb);
+REGISTER_DEMUXER (AMRWB,amrwb);
 REGISTER_DEMUXER (ANM,  anm);
 REGISTER_DEMUXER (APC,  apc);
 REGISTER_DEMUXER (APE,  ape);
diff --git a/libavformat/amr.c b/libavformat/amr.c
index b5194a2..40653ce 100644
--- a/libavformat/amr.c
+++ b/libavformat/amr.c
@@ -29,11 +29,7 @@ Only mono files are supported.
 #include "libavutil/channel_layout.h"
 #include "avformat.h"
 #include "internal.h"
-
-typedef struct {
-uint64_t cumulated_size;
-uint64_t block_count;
-} AMRContext;
+#include "amr.h"
 
 static const char AMR_header[]   = "#!AMR\n";
 static const char AMRWB_header[] = "#!AMR-WB\n";
@@ -110,7 +106,7 @@ static int amr_read_header(AVFormatContext *s)
 return 0;
 }
 
-static int amr_read_packet(AVFormatContext *s, AVPacket *pkt)
+int ff_amr_read_packet(AVFormatContext *s, AVPacket *pkt)
 {
 AVCodecParameters *par = s->streams[0]->codecpar;
 int read, size = 0, toc, mode;
@@ -171,7 +167,7 @@ AVInputFormat ff_amr_demuxer = {
 .priv_data_size = sizeof(AMRContext),
 .read_probe = amr_probe,
 .read_header= amr_read_header,
-.read_packet= amr_read_packet,
+.read_packet= ff_amr_read_packet,
 .flags  = AVFMT_GENERIC_INDEX,
 };
 #endif
diff --git a/libavformat/amr.h b/libavformat/amr.h
new file mode 100644
index 000..5c3760e
--- /dev/null
+++ b/libavformat/amr.h
@@ -0,0 +1,34 @@
+/*
+ * amr file format
+ * Copyright (c) 2001 FFmpeg project
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVFORMAT_AMR_H
+#define AVFORMAT_AMR_H
+
+#include "avformat.h"
+
+typedef struct {
+uint64_t cumulated_size;
+uint64_t block_count;
+} AMRContext;
+
+int ff_amr_read_packet(AVFormatContext *s, AVPacket *pkt);
+
+#endif
diff --git a/libavformat/amrnb.c b/libavformat/amrnb.c
new file mode 100644
index 000..cdfe976
--- /dev/null
+++ b/libavformat/amrnb.c
@@ -0,0 +1,73 @@
+/*
+ * amr-nb file format
+ * Copyright (c) 2017 Carl Eugen Hoyos
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it

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

2017-10-01 Thread Carl Eugen Hoyos

2017-10-01 14:03 GMT+02:00 Ronald S. Bultje :
> Hi,
>
> On Sat, Sep 30, 2017 at 3:40 PM, Carl Eugen Hoyos 
> wrote:

>> Attached patch also support GBRP, I don't know if this is a good or
>> bad idea.
>
> I would personally probably err on the side of caution, but no strong
> opinions. If this works (I assume it does), I guess it's fine (?).

Do you want me to commit (with or without GBRP)?

Sorry, I really don't know if this is supposed to do something
useful or not.

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

[FFmpeg-devel] [PATCH 1/2] avcodec/dvbsubdec: Factor a few expressions out of compute_default_clut()

2017-10-01 Thread Michael Niedermayer

32% faster loop

Signed-off-by: Michael Niedermayer 
---
 libavcodec/dvbsubdec.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/libavcodec/dvbsubdec.c b/libavcodec/dvbsubdec.c
index b683109643..6a40f2376f 100644
--- a/libavcodec/dvbsubdec.c
+++ b/libavcodec/dvbsubdec.c
@@ -653,8 +653,9 @@ static void compute_default_clut(AVSubtitleRect *rect, int 
w, int h)
 uint8_t list_inv[256];
 int counttab[256] = {0};
 int count, i, x, y;
+ptrdiff_t ls = rect->linesize[0];
 
-#define V(x,y) rect->data[0][(x) + (y)*rect->linesize[0]]
+#define V(x,y) rect->data[0][(x) + (y)*ls]
 for (y = 0; ydata[0][(x) + (y)*rect->linesize[0]] ]
+#define L(x,y) list[ d[(x) + (y)*ls] ]
 
 for (i = 0; i<256; i++) {
 int scoretab[256] = {0};
@@ -673,12 +674,13 @@ static void compute_default_clut(AVSubtitleRect *rect, 
int w, int h)
 int bestv = 0;
 for (y = 0; ydata[0][x + y*rect->linesize[0]];
+uint8_t *d = >data[0][x + y*ls];
+int v = *d;
 int l_m = list[v];
-int l_l = x ? L(x-1, y) : 1;
-int l_r = x+1http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avcodec/dvbsubdec: Split best score computation out of loop in compute_default_clut()

2017-10-01 Thread Michael Niedermayer

3% faster

Signed-off-by: Michael Niedermayer 
---
 libavcodec/dvbsubdec.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavcodec/dvbsubdec.c b/libavcodec/dvbsubdec.c
index 6a40f2376f..e60bf41936 100644
--- a/libavcodec/dvbsubdec.c
+++ b/libavcodec/dvbsubdec.c
@@ -681,14 +681,17 @@ static void compute_default_clut(AVSubtitleRect *rect, 
int w, int h)
 int l_r = x+1 bestscore) {
 bestscore = score;
-bestv = v;
+bestv = x;
 }
 }
 }
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH V2 2/2] lavc/vaapi_decode: fix profile search when disable exact profile match.

2017-10-01 Thread Mark Thompson

On 29/09/17 02:58, Jun Zhao wrote:
> From 94604d623de1fec6f363dcda4d61712865257a0a Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Thu, 21 Sep 2017 02:44:42 -0400
> Subject: [PATCH V2 2/2] lavc/vaapi_decode: fix profile search when disable
>  exact profile match.
> 
> when disable exact profile, use the alt_profile for VAAPI HWAccel
> decoder.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/vaapi_decode.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index cf58aae4c6..f0dccf481b 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -328,7 +328,7 @@ static int vaapi_decode_make_config(AVCodecContext *avctx)
>  if (j < profile_count) {
>  if (exact_match)
>  break;
> -alt_profile = vaapi_profile_map[i].codec_profile;
> +alt_profile = vaapi_profile_map[i].va_profile;
>  }
>  }
>  av_freep(_list);
> @@ -348,6 +348,7 @@ static int vaapi_decode_make_config(AVCodecContext *avctx)
>  av_log(avctx, AV_LOG_WARNING, "Using possibly-"
> "incompatible profile %d instead.\n",
> alt_profile);
> +profile = alt_profile;
>  } else {
>  av_log(avctx, AV_LOG_VERBOSE, "Codec %s profile %d not "
> "supported for hardware decode.\n",
> -- 
> 2.11.0
> 

Yeah, that looks right to me now.

The message comes out a bit strange, though, because the two profile values are 
in different namespaces?  One is an FF_PROFILE_*, the other is a VAProfile* - I 
think it's better to use the FF_PROFILE_* values in messages, because they 
match what is actually in the stream (profile_idc, etc.).  Maybe the first of 
the paired messages should also be WARNING too, so that it makes more sense 
with default level (info) output.

Thanks,

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

Re: [FFmpeg-devel] libavcodec/exr : add x86 SIMD for predictor

2017-10-01 Thread James Almer

On 10/1/2017 11:35 AM, Henrik Gramner wrote:
> On Sun, Oct 1, 2017 at 4:14 PM, James Almer  wrote:
>> We normally use int for counters, and don't mix declaration and statements.
>> And in any case ptrdiff_t would be "more correct" for this.
> 
> Ah right. C90, ugh. Too used to C99.

No, we're c99. c11 even (for atomics only), except for that one thing
because we explicitly call gcc with -Wdeclaration-after-statement :P

Is it worth warning about it? I don't know. Supposedly some old gcc
version in some target would fail with mixed declarations and code even
with -std=c99, but by now this is probably just cargo cult.

> 
> Yeah, feel free to use whatever datatype that's most appropriate for
> the FFmpeg standard, wouldn't size_t make more sense than ptrdiff_t
> for a size though?

The counter i is used as a pointer offset, so i think ptrdiff_t is more
appropriate.

In any case, using int will generate at most a movsxd instruction or
similar on 64bit targets. And if we're to start using ptrdiff_t, size_t
or whatever instead of int for the counters in for loops then it should
be done in general and not just on a single new function.

> 
>> We have both of those in constants.c, so use instead
>>
>> cextern pb_15
>> cextern pb_80
> 
> Good point. Any idea why the heck is it called pb_80 btw? Seems like a
> very inconsistent mix of decimal and hex.

Different developers adding constants as needed, i guess. All pw_ and
pd_ constants use decimal, and all pb_ use hex except for 15. And nobody
really wants to do cosmetics work :P

> 
>> Does that apply to Haswell and newer? Was wondering why so many of the
>> AVX functions that only used the three operand instructions were
>> reported to be as fast or even slower than <= SSE4 versions for me.
> 
> Since Ivy Bridge on Intel IIRC. No idea about AMD. Eliminating reg-reg
> moves with AVX also saves a little bit of code size (and thus cache)
> as well, which might add up over hundreds of functions.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

[FFmpeg-devel] [PATCH] avdevice/decklink_dec: fix multipacket op47 decoding

2017-10-01 Thread Marton Balint

It was disabled by mistake.

Signed-off-by: Marton Balint 
---
 libavdevice/decklink_dec.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 9f6c4598ba..cbad4d6ee2 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -379,7 +379,7 @@ uint8_t *get_metadata(AVFormatContext *avctx, uint16_t 
*buf, size_t width,
 av_log(avctx, AV_LOG_WARNING, "VANC parity or checksum 
incorrect\n");
 goto skip_packet;
 }
-tgt = teletext_data_unit_from_ancillary_packet(buf + 3, buf + len, 
tgt, cctx->teletext_lines, 0);
+tgt = teletext_data_unit_from_ancillary_packet(buf + 3, buf + len, 
tgt, cctx->teletext_lines, 1);
 } else if (did == 0x61 && sdid == 0x01) {
 unsigned int data_len;
 uint8_t *data;
-- 
2.13.5

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

Re: [FFmpeg-devel] [PATCH V2 1/2] ffmpeg: re-enable hwaccel_lax_profile_check use hwaccel_flags.

2017-10-01 Thread Mark Thompson

On 29/09/17 02:58, Jun Zhao wrote:
> From e2a7cce88d2a47c7e598b59d24258fea8d809c22 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Thu, 21 Sep 2017 02:41:29 -0400
> Subject: [PATCH V2 1/2] ffmpeg: re-enable hwaccel_lax_profile_check use
>  hwaccel_flags.
> 
> re-enable hwaccel_lax_profile_check option use hwaccel_flags.
> 
> Signed-off-by: Jun Zhao 
> ---
>  ffmpeg.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 1d248bc269..4f2b9d69d9 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -2859,6 +2859,9 @@ static enum AVPixelFormat get_format(AVCodecContext *s, 
> const enum AVPixelFormat
>  
>  ist->active_hwaccel_id = hwaccel->id;
>  ist->hwaccel_pix_fmt   = *p;
> +
> +if (hwaccel_lax_profile_check)
> +s->hwaccel_flags |= AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH;
>  break;
>  }
>  
> -- 
> 2.11.0
> 

I'm inclined to say we should just remove the ad-hoc global lax_profile_check 
option (which was previously implemented only in ffmpeg.c code for VAAPI) and 
add a per-stream -hwaccel_flags option to set AVCodecContext.hwaccel_flags 
directly instead.  That can contain "ignore_level" and "allow_profile_mismatch" 
together, and maybe future flags if appropriate.

What do you think?

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

Re: [FFmpeg-devel] libavcodec/exr : add x86 SIMD for predictor

2017-10-01 Thread Henrik Gramner

On Sun, Oct 1, 2017 at 4:14 PM, James Almer  wrote:
> We normally use int for counters, and don't mix declaration and statements.
> And in any case ptrdiff_t would be "more correct" for this.

Ah right. C90, ugh. Too used to C99.

Yeah, feel free to use whatever datatype that's most appropriate for
the FFmpeg standard, wouldn't size_t make more sense than ptrdiff_t
for a size though?

> We have both of those in constants.c, so use instead
>
> cextern pb_15
> cextern pb_80

Good point. Any idea why the heck is it called pb_80 btw? Seems like a
very inconsistent mix of decimal and hex.

> Does that apply to Haswell and newer? Was wondering why so many of the
> AVX functions that only used the three operand instructions were
> reported to be as fast or even slower than <= SSE4 versions for me.

Since Ivy Bridge on Intel IIRC. No idea about AMD. Eliminating reg-reg
moves with AVX also saves a little bit of code size (and thus cache)
as well, which might add up over hundreds of functions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/exr : add x86 SIMD for predictor

2017-10-01 Thread James Almer

On 10/1/2017 9:47 AM, Henrik Gramner wrote:
> On Fri, Sep 22, 2017 at 11:12 PM, Martin Vignali
>  wrote:
>> +static void predictor_scalar(uint8_t *src, ptrdiff_t size)
>> +{
>> +uint8_t *t= src + 1;
>> +uint8_t *stop = src + size;
>> +
>> +while (t < stop) {
>> +int d = (int) t[-1] + (int) t[0] - 128;
>> +t[0] = d;
>> +++t;
>> +}
>> +}
> 
> Can be simplified quite a bit:
> 
> static void predictor_scalar(uint8_t *src, ptrdiff_t size)
> {
> for (size_t i = 1; i < size; i++)

We normally use int for counters, and don't mix declaration and statements.
And in any case ptrdiff_t would be "more correct" for this.

> src[i] += src[i-1] - 128;
> }
> 
>> +SECTION_RODATA 32
>> +
>> +neg_128: times 16 db -128
>> +shuffle_15: times 16 db 15
> 
> Drop the 32-byte alignment from the section directive, we don't need it here.
> 
> db -128 is weird since it's identical to +128. I would rename those as such:
> 
> pb_128: times 16 db 128
> pb_15:  times 16 db 15

We have both of those in constants.c, so use instead

cextern pb_15
cextern pb_80

> 
>> +INIT_XMM ssse3
>> +cglobal predictor, 2,3,5, src, size, tmp
>> +
>> +movtmpb, [srcq]
>> +xortmpb, -128
>> +mov  [srcq], tmpb
>> +
>> +;offset src by size
>> +addsrcq, sizeq
>> +neg   sizeq; size = offset for src
>> +
>> +;init mm
>> +mova m0, [neg_128] ; m0 = const for xor high byte
>> +mova m1, [shuffle_15]  ; m1 = shuffle mask
>> +pxor m2, m2; m2 = prev_buffer
>> +
>> +
>> +.loop:
>> +mova m3, [srcq + sizeq]
>> +pxor m3, m0
>> +
>> +;compute prefix sum
>> +mova m4, m3
>> +pslldq   m4, 1
>> +
>> +paddbm4, m3
>> +mova m3, m4
>> +pslldq   m3, 2
>> +
>> +paddbm3, m4
>> +mova m4, m3
>> +pslldq   m4, 4
>> +
>> +paddbm4, m3
>> +mova m3, m4
>> +pslldq   m3, 8
>> +
>> +paddbm4, m2
>> +paddbm4, m3
>> +
>> +mova [srcq + sizeq], m4
>> +
>> +;broadcast high byte for next iter
>> +pshufb m4, m1
>> +mova m2, m4
>> +
>> +add sizeq, mmsize
>> +jl .loop
>> +RET
> 
> %macro PREDICTOR 0
> cglobal predictor, 2,3,5, src, size, tmp
> %if mmsize == 32
> vbroadcasti128   m0, [pb_128]
> %else
> movaxm0, [pb_128]
> %endif
> movaxm1, [pb_15]
> movaxm2, xm0
> addsrcq, sizeq
> neg   sizeq
> .loop:
> pxor m3, m0, [srcq + sizeq]
> pslldq   m4, m3, 1
> paddbm3, m4
> pslldq   m4, m3, 2
> paddbm3, m4
> pslldq   m4, m3, 4
> paddbm3, m4
> pslldq   m4, m3, 8
> %if mmsize == 32
> paddbm3, m4
> paddb   xm2, xm3
> vextracti128xm4, m3, 1
> mova [srcq + sizeq], xm2
> pshufb  xm2, xm1
> paddb   xm2, xm4
> mova [srcq + sizeq + 16], xm2
> %else
> paddbm2, m3
> paddbm2, m4
> mova [srcq + sizeq], m2
> %endif
> pshufb  xm2, xm1
> add   sizeq, mmsize
> jl .loop
> RET
> %endmacro
> 
> INIT_XMM ssse3
> PREDICTOR
> 
> INIT_XMM avx
> PREDICTOR
> 
> %if HAVE_AVX2_EXTERNAL
> INIT_YMM avx2
> PREDICTOR
> %endif
> 
> predictor_c: 15351.5
> predictor_ssse3: 1206.5
> predictor_avx: 1207.5
> predictor_avx2: 880.0
> 
> On SKL-X. Only tested in checkasm.
> 
> AVX is same speed as SSSE3 since modern Intel CPU:s eliminate reg-reg
> moves in the register renaming stage, but somewhat older CPU:s such as
> Sandy Bridge, which is still quite popular, does not so it should help
> there.

Does that apply to Haswell and newer? Was wondering why so many of the
AVX functions that only used the three operand instructions were
reported to be as fast or even slower than <= SSE4 versions for me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/exr : add x86 SIMD for predictor

2017-10-01 Thread Henrik Gramner

On Fri, Sep 22, 2017 at 11:12 PM, Martin Vignali
 wrote:
> +static void predictor_scalar(uint8_t *src, ptrdiff_t size)
> +{
> +uint8_t *t= src + 1;
> +uint8_t *stop = src + size;
> +
> +while (t < stop) {
> +int d = (int) t[-1] + (int) t[0] - 128;
> +t[0] = d;
> +++t;
> +}
> +}

Can be simplified quite a bit:

static void predictor_scalar(uint8_t *src, ptrdiff_t size)
{
for (size_t i = 1; i < size; i++)
src[i] += src[i-1] - 128;
}

> +SECTION_RODATA 32
> +
> +neg_128: times 16 db -128
> +shuffle_15: times 16 db 15

Drop the 32-byte alignment from the section directive, we don't need it here.

db -128 is weird since it's identical to +128. I would rename those as such:

pb_128: times 16 db 128
pb_15:  times 16 db 15

> +INIT_XMM ssse3
> +cglobal predictor, 2,3,5, src, size, tmp
> +
> +movtmpb, [srcq]
> +xortmpb, -128
> +mov  [srcq], tmpb
> +
> +;offset src by size
> +addsrcq, sizeq
> +neg   sizeq; size = offset for src
> +
> +;init mm
> +mova m0, [neg_128] ; m0 = const for xor high byte
> +mova m1, [shuffle_15]  ; m1 = shuffle mask
> +pxor m2, m2; m2 = prev_buffer
> +
> +
> +.loop:
> +mova m3, [srcq + sizeq]
> +pxor m3, m0
> +
> +;compute prefix sum
> +mova m4, m3
> +pslldq   m4, 1
> +
> +paddbm4, m3
> +mova m3, m4
> +pslldq   m3, 2
> +
> +paddbm3, m4
> +mova m4, m3
> +pslldq   m4, 4
> +
> +paddbm4, m3
> +mova m3, m4
> +pslldq   m3, 8
> +
> +paddbm4, m2
> +paddbm4, m3
> +
> +mova [srcq + sizeq], m4
> +
> +;broadcast high byte for next iter
> +pshufb m4, m1
> +mova m2, m4
> +
> +add sizeq, mmsize
> +jl .loop
> +RET

%macro PREDICTOR 0
cglobal predictor, 2,3,5, src, size, tmp
%if mmsize == 32
vbroadcasti128   m0, [pb_128]
%else
movaxm0, [pb_128]
%endif
movaxm1, [pb_15]
movaxm2, xm0
addsrcq, sizeq
neg   sizeq
.loop:
pxor m3, m0, [srcq + sizeq]
pslldq   m4, m3, 1
paddbm3, m4
pslldq   m4, m3, 2
paddbm3, m4
pslldq   m4, m3, 4
paddbm3, m4
pslldq   m4, m3, 8
%if mmsize == 32
paddbm3, m4
paddb   xm2, xm3
vextracti128xm4, m3, 1
mova [srcq + sizeq], xm2
pshufb  xm2, xm1
paddb   xm2, xm4
mova [srcq + sizeq + 16], xm2
%else
paddbm2, m3
paddbm2, m4
mova [srcq + sizeq], m2
%endif
pshufb  xm2, xm1
add   sizeq, mmsize
jl .loop
RET
%endmacro

INIT_XMM ssse3
PREDICTOR

INIT_XMM avx
PREDICTOR

%if HAVE_AVX2_EXTERNAL
INIT_YMM avx2
PREDICTOR
%endif

predictor_c: 15351.5
predictor_ssse3: 1206.5
predictor_avx: 1207.5
predictor_avx2: 880.0

On SKL-X. Only tested in checkasm.

AVX is same speed as SSSE3 since modern Intel CPU:s eliminate reg-reg
moves in the register renaming stage, but somewhat older CPU:s such as
Sandy Bridge, which is still quite popular, does not so it should help
there.

On Fri, Sep 22, 2017 at 11:12 PM, Martin Vignali
 wrote:
> Hello,
>
> in attach a patch
> with a port to asm of the predictor part of this patch :
>
> https://github.com/openexr/openexr/pull/229/commits/4198128397c033d4f69e5cc0833195da500c31cf
>
> Tested on OSX, pass fate test for me
> Check asm also pass for me
>
> Results with reorder simd disable :
> SSSE3 : 94.5s
> 1036758 decicycles in predictor,  130751 runs,321 skips
>
> Scalar : 114s
> 4255109 decicycles in predictor,  130276 runs,796 skips
>
> using reorder and predictor simd : 82.6s
>
>
> Check asm benchmark :
> ./tests/checkasm/checkasm --test=exrdsp --bench
>
> predictor_c: 10635.1
> predictor_ssse3: 1634.6
>
>
> Comments welcome
>
>
> Martin
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2017-10-01 Thread Ronald S. Bultje

Hi,

On Sat, Sep 30, 2017 at 3:40 PM, Carl Eugen Hoyos 
wrote:

> 2017-09-30 20:30 GMT+02:00 Ronald S. Bultje :
> > Hi Carl,
> >
> > On Sat, Sep 30, 2017 at 2:19 PM, Carl Eugen Hoyos 
> > wrote:
> >
> >> 2017-09-30 19:47 GMT+02:00 Ronald S. Bultje :
> >> > Hi Carl,
> >> >
> >> > On Sat, Sep 30, 2017 at 1:31 PM, Carl Eugen Hoyos  >
> >> > wrote:
> >> >
> >> >> Hi!
> >> >>
> >> >> 2017-09-15 22:47 GMT+02:00 Ashish Pratap Singh  >:
> >> >>
> >> >> > +static int query_formats(AVFilterContext *ctx)
> >> >> > +{
> >> >> > +static const enum AVPixelFormat pix_fmts[] = {
> >> >> > +AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P,
> >> >> > AV_PIX_FMT_YUV420P,
> >> >> > +AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV422P10,
> >> >> > AV_PIX_FMT_YUV420P10,
> >> >>
> >> >> Is the algorithm only defined for these formats and bit-depth
> >> >> or are there just missing features?
> >> >> Gray and gray10 come to mind...
> >> >>
> >> >
> >> > Great question! I _believe_ that vmaf overall is luma-only, so it
> should
> >> be
> >> > entirely independent of chroma.
> >>
> >> Then imo, above function is just wrong, it should check for
> >> non-rgb or similar (think of YUVA444 and friends).
> >>
> >
> > I don't think I'm familiar enough with lavfi to send a patch, can you
> send
> > one? What I've asked Ashish to do (and what he's done here) is simply to
> > reproduce as closely as possible what Netflix' code does, and they only
> > support 420, 422 and 444 for 8 and 10 bits/component. I'm happy to
> support
> > more if I know how to.
>
> Attached patch also support GBRP, I don't know if this is a good or
> bad idea.
>

I would personally probably err on the side of caution, but no strong
opinions. If this works (I assume it does), I guess it's fine (?).

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

Re: [FFmpeg-devel] libavcodec/exr : add x86 SIMD for predictor

2017-10-01 Thread Martin Vignali

2017-09-22 23:12 GMT+02:00 Martin Vignali :

> Hello,
>
> in attach a patch
> with a port to asm of the predictor part of this patch :
>
> https://github.com/openexr/openexr/pull/229/commits/
> 4198128397c033d4f69e5cc0833195da500c31cf
>
> Tested on OSX, pass fate test for me
> Check asm also pass for me
>
> Results with reorder simd disable :
> SSSE3 : 94.5s
> 1036758 decicycles in predictor,  130751 runs,321 skips
>
> Scalar : 114s
> 4255109 decicycles in predictor,  130276 runs,796 skips
>
> using reorder and predictor simd : 82.6s
>
>
> Check asm benchmark :
> ./tests/checkasm/checkasm --test=exrdsp --bench
>
> predictor_c: 10635.1
> predictor_ssse3: 1634.6
>
>
> Comments welcome
>
>
> Martin
>
>
Ping
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

48 matches

Mail list logo