Re: [FFmpeg-devel] [FFmpeg-cvslog] aacenc: support extended channel layouts using PCEs

[Nicolas George]

Le nonidi 19 brumaire, an CCXXVI, Rostislav Pehlivanov a écrit :
> ffmpeg | branch: master | Rostislav Pehlivanov  | Mon 
> Oct  3 19:53:11 2016 +0100| [fbf295e2bd4d48d7a0a094ed5afce2fa5b6cf35a] | 
> committer: Rostislav Pehlivanov
> 
> aacenc: support extended channel layouts using PCEs
> 
> This commit implements support for PCE (Program Configuration Elements) in the
> AAC encoder, and as such allows for encoding of channel layouts not present
> in the presets defined by the spec (which only lists the 8 most common ones).
> 
> This has been a highly requested feature and is also the first open source 
> encoder
> to support this many layouts.
> 
> Many thanks to pkviet  who implemented support for and
> verified all channel layouts.

This broke fate-aac-yoraw-encode.

stddev:  160.76 PSNR: 52.21 MAXDIFF: 3105 bytes:   576972/   577536
stddev: |160.76 - 259| >= 17

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH 03/11] avutil: detect when AVX-512 is available

[James Darnley]

---
I've changed this patch slightly because I discovered that it would cause an
illegal instruction exception on much older processors (probably all without
AVX).  I was running xgetbv() almost uncontitionally.  Now it is a little more
like what is the in x264 patch.

 libavutil/x86/cpu.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/libavutil/x86/cpu.c b/libavutil/x86/cpu.c
index f33088c8c7..589fdef7da 100644
--- a/libavutil/x86/cpu.c
+++ b/libavutil/x86/cpu.c
@@ -97,6 +97,7 @@ int ff_get_cpu_flags_x86(void)
 int max_std_level, max_ext_level, std_caps = 0, ext_caps = 0;
 int family = 0, model = 0;
 union { int i[3]; char c[12]; } vendor;
+int xcr0_lo = 0, xcr0_hi = 0;
 
 if (!cpuid_test())
 return 0; /* CPUID not supported */
@@ -132,8 +133,8 @@ int ff_get_cpu_flags_x86(void)
 /* Check OXSAVE and AVX bits */
 if ((ecx & 0x1800) == 0x1800) {
 /* Check for OS support */
-xgetbv(0, eax, edx);
-if ((eax & 0x6) == 0x6) {
+xgetbv(0, xcr0_lo, xcr0_hi);
+if ((xcr0_lo & 0x6) == 0x6) {
 rval |= AV_CPU_FLAG_AVX;
 if (ecx & 0x1000)
 rval |= AV_CPU_FLAG_FMA3;
@@ -154,6 +155,13 @@ int ff_get_cpu_flags_x86(void)
 if (ebx & 0x0100)
 rval |= AV_CPU_FLAG_BMI2;
 }
+#if HAVE_AVX512 /* F, CD, BW, DQ, VL */
+if ((xcr0_lo & 0xe6) == 0xe6) {
+if ((ebx & 0xd003) == 0xd003)
+rval |= AV_CPU_FLAG_AVX512;
+
+}
+#endif
 }
 
 cpuid(0x8000, max_ext_level, ebx, ecx, edx);
-- 
2.15.0

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

[FFmpeg-devel] [PATCH 09/11] avcodec/blockdsp: roll-up x86asm preprocessor loop

[James Darnley]

From: James Darnley 

---
 libavcodec/x86/blockdsp.asm | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/libavcodec/x86/blockdsp.asm b/libavcodec/x86/blockdsp.asm
index 9d203df8f5..9d0e8a3242 100644
--- a/libavcodec/x86/blockdsp.asm
+++ b/libavcodec/x86/blockdsp.asm
@@ -38,22 +38,19 @@ cglobal clear_block, 1, 1, %1, blocks
 %assign %%i 0
 %rep %2
 mova  [blocksq+mmsize*(0+%%i)], m0
-mova  [blocksq+mmsize*(1+%%i)], m0
-mova  [blocksq+mmsize*(2+%%i)], m0
-mova  [blocksq+mmsize*(3+%%i)], m0
-%assign %%i %%i+4
+%assign %%i %%i+1
 %endrep
 RET
 %endmacro
 
 INIT_MMX mmx
 %define ZERO pxor
-CLEAR_BLOCK 0, 4
+CLEAR_BLOCK 0, 16
 INIT_XMM sse
 %define ZERO xorps
-CLEAR_BLOCK 1, 2
+CLEAR_BLOCK 1, 8
 INIT_YMM avx
-CLEAR_BLOCK 1, 1
+CLEAR_BLOCK 1, 4
 
 ;-
 ; void ff_clear_blocks(int16_t *blocks);
-- 
2.15.0

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

[FFmpeg-devel] [PATCH 02/11] avutil: add AVX-512 flags

[James Darnley]

---
 libavutil/cpu.c   | 6 +-
 libavutil/cpu.h   | 1 +
 libavutil/tests/cpu.c | 1 +
 libavutil/x86/cpu.h   | 2 ++
 4 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index c8401b8258..6548cc3042 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -80,7 +80,8 @@ void av_force_cpu_flags(int arg){
 AV_CPU_FLAG_XOP  |
 AV_CPU_FLAG_FMA3 |
 AV_CPU_FLAG_FMA4 |
-AV_CPU_FLAG_AVX2 ))
+AV_CPU_FLAG_AVX2 |
+AV_CPU_FLAG_AVX512   ))
 && !(arg & AV_CPU_FLAG_MMX)) {
 av_log(NULL, AV_LOG_WARNING, "MMX implied by specified flags\n");
 arg |= AV_CPU_FLAG_MMX;
@@ -126,6 +127,7 @@ int av_parse_cpu_flags(const char *s)
 #define CPUFLAG_AVX2 (AV_CPU_FLAG_AVX2 | CPUFLAG_AVX)
 #define CPUFLAG_BMI2 (AV_CPU_FLAG_BMI2 | AV_CPU_FLAG_BMI1)
 #define CPUFLAG_AESNI(AV_CPU_FLAG_AESNI| CPUFLAG_SSE42)
+#define CPUFLAG_AVX512   (AV_CPU_FLAG_AVX512   | CPUFLAG_AVX2)
 static const AVOption cpuflags_opts[] = {
 { "flags"   , NULL, 0, AV_OPT_TYPE_FLAGS, { .i64 = 0 }, INT64_MIN, 
INT64_MAX, .unit = "flags" },
 #if   ARCH_PPC
@@ -154,6 +156,7 @@ int av_parse_cpu_flags(const char *s)
 { "3dnowext", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = CPUFLAG_3DNOWEXT
 },.unit = "flags" },
 { "cmov", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_CMOV
 },.unit = "flags" },
 { "aesni"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = CPUFLAG_AESNI   
 },.unit = "flags" },
+{ "avx512"  , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = CPUFLAG_AVX512  
 },.unit = "flags" },
 #elif ARCH_ARM
 { "armv5te",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_ARMV5TE 
 },.unit = "flags" },
 { "armv6",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_ARMV6   
 },.unit = "flags" },
@@ -216,6 +219,7 @@ int av_parse_cpu_caps(unsigned *flags, const char *s)
 { "3dnowext", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
AV_CPU_FLAG_3DNOWEXT },.unit = "flags" },
 { "cmov", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_CMOV
 },.unit = "flags" },
 { "aesni",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_AESNI   
 },.unit = "flags" },
+{ "avx512"  , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_AVX512  
 },.unit = "flags" },
 
 #define CPU_FLAG_P2 AV_CPU_FLAG_CMOV | AV_CPU_FLAG_MMX
 #define CPU_FLAG_P3 CPU_FLAG_P2 | AV_CPU_FLAG_MMX2 | AV_CPU_FLAG_SSE
diff --git a/libavutil/cpu.h b/libavutil/cpu.h
index 9e5d40affe..91523f3f5a 100644
--- a/libavutil/cpu.h
+++ b/libavutil/cpu.h
@@ -55,6 +55,7 @@
 #define AV_CPU_FLAG_FMA30x1 ///< Haswell FMA3 functions
 #define AV_CPU_FLAG_BMI10x2 ///< Bit Manipulation Instruction Set 1
 #define AV_CPU_FLAG_BMI20x4 ///< Bit Manipulation Instruction Set 2
+#define AV_CPU_FLAG_AVX512 0x10 ///< AVX-512 functions
 
 #define AV_CPU_FLAG_ALTIVEC  0x0001 ///< standard
 #define AV_CPU_FLAG_VSX  0x0002 ///< ISA 2.06
diff --git a/libavutil/tests/cpu.c b/libavutil/tests/cpu.c
index f02a54cbbb..ce45b715a0 100644
--- a/libavutil/tests/cpu.c
+++ b/libavutil/tests/cpu.c
@@ -73,6 +73,7 @@ static const struct {
 { AV_CPU_FLAG_BMI1,  "bmi1"   },
 { AV_CPU_FLAG_BMI2,  "bmi2"   },
 { AV_CPU_FLAG_AESNI, "aesni"  },
+{ AV_CPU_FLAG_AVX512,"avx512" },
 #endif
 { 0 }
 };
diff --git a/libavutil/x86/cpu.h b/libavutil/x86/cpu.h
index 309b8e746c..7f4e5d08bb 100644
--- a/libavutil/x86/cpu.h
+++ b/libavutil/x86/cpu.h
@@ -50,6 +50,7 @@
 #define X86_FMA4(flags) CPUEXT(flags, FMA4)
 #define X86_AVX2(flags) CPUEXT(flags, AVX2)
 #define X86_AESNI(flags)CPUEXT(flags, AESNI)
+#define X86_AVX512(flags)   CPUEXT(flags, AVX512)
 
 #define EXTERNAL_AMD3DNOW(flags)CPUEXT_SUFFIX(flags, _EXTERNAL, AMD3DNOW)
 #define EXTERNAL_AMD3DNOWEXT(flags) CPUEXT_SUFFIX(flags, _EXTERNAL, 
AMD3DNOWEXT)
@@ -79,6 +80,7 @@
 #define EXTERNAL_AVX2_FAST(flags)   CPUEXT_SUFFIX_FAST2(flags, _EXTERNAL, 
AVX2, AVX)
 #define EXTERNAL_AVX2_SLOW(flags)   CPUEXT_SUFFIX_SLOW2(flags, _EXTERNAL, 
AVX2, AVX)
 #define EXTERNAL_AESNI(flags)   CPUEXT_SUFFIX(flags, _EXTERNAL, AESNI)
+#define EXTERNAL_AVX512(flags)  CPUEXT_SUFFIX(flags, _EXTERNAL, AVX512)
 
 #define INLINE_AMD3DNOW(flags)  CPUEXT_SUFFIX(flags, _INLINE, AMD3DNOW)
 #define INLINE_AMD3DNOWEXT(flags)   CPUEXT_SUFFIX(flags, _INLINE, AMD3DNOWEXT)
-- 
2.15.0

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

[FFmpeg-devel] [PATCH] lavc/pngdec: fix av_bprint_finalize() usage.

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavcodec/pngdec.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 20707f0ae5..1d72f9542a 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -524,9 +524,9 @@ static int decode_text_chunk(PNGDecContext *s, uint32_t 
length, int compressed,
 if ((ret = decode_zbuf(, data, data_end)) < 0)
 return ret;
 text_len = bp.len;
-av_bprint_finalize(, (char **));
-if (!text)
-return AVERROR(ENOMEM);
+ret = av_bprint_finalize(, (char **));
+if (ret < 0)
+return ret;
 } else {
 text = (uint8_t *)data;
 text_len = data_end - text;
@@ -862,9 +862,9 @@ static int decode_iccp_chunk(PNGDecContext *s, int length, 
AVFrame *f)
 if ((ret = decode_zbuf(, s->gb.buffer, s->gb.buffer + length)) < 0)
 return ret;
 
-av_bprint_finalize(, (char **));
-if (!data)
-return AVERROR(ENOMEM);
+ret = av_bprint_finalize(, (char **));
+if (ret < 0)
+return ret;
 
 sd = av_frame_new_side_data(f, AV_FRAME_DATA_ICC_PROFILE, bp.len);
 if (!sd) {
@@ -1317,9 +1317,9 @@ static int decode_frame_common(AVCodecContext *avctx, 
PNGDecContext *s,
 
 av_bprint_init(, 0, -1);
 av_bprintf(, "%i/%i", num, 10);
-av_bprint_finalize(, _str);
-if (!gamma_str)
-return AVERROR(ENOMEM);
+ret = av_bprint_finalize(, _str);
+if (ret < 0)
+return ret;
 
 av_dict_set(>metadata, "gamma", gamma_str, 
AV_DICT_DONT_STRDUP_VAL);
 
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 05/11] avcodec: add stride alignment needed for AVX-512

[James Darnley]

---
 configure | 2 ++
 libavcodec/internal.h | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 146a87324c..fce8030d91 100755
--- a/configure
+++ b/configure
@@ -1886,6 +1886,7 @@ ARCH_FEATURES="
 local_aligned
 simd_align_16
 simd_align_32
+simd_align_64
 "
 
 BUILTIN_LIST="
@@ -2385,6 +2386,7 @@ fast_clz_if_any="aarch64 alpha avr32 mips ppc x86"
 fast_unaligned_if_any="aarch64 ppc x86"
 simd_align_16_if_any="altivec neon sse"
 simd_align_32_if_any="avx"
+simd_align_64_if_any="avx512"
 
 # system capabilities
 symver_if_any="symver_asm_label symver_gnu_asm"
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 7748f09f54..84070431ed 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -87,7 +87,9 @@
 
 #define FF_SIGNBIT(x) ((x) >> CHAR_BIT * sizeof(x) - 1)
 
-#if HAVE_SIMD_ALIGN_32
+#if HAVE_SIMD_ALIGN_64
+#   define STRIDE_ALIGN 64 /* AVX-512 */
+#elif HAVE_SIMD_ALIGN_32
 #   define STRIDE_ALIGN 32
 #elif HAVE_SIMD_ALIGN_16
 #   define STRIDE_ALIGN 16
-- 
2.15.0

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

[FFmpeg-devel] [PATCH 08/11] avcodec/v210enc: add AVX-512 10-bit line pack function

[James Darnley]

---
 libavcodec/x86/v210enc.asm| 5 +
 libavcodec/x86/v210enc_init.c | 7 +++
 2 files changed, 12 insertions(+)

diff --git a/libavcodec/x86/v210enc.asm b/libavcodec/x86/v210enc.asm
index 965f2bea3c..5068af27f8 100644
--- a/libavcodec/x86/v210enc.asm
+++ b/libavcodec/x86/v210enc.asm
@@ -103,6 +103,11 @@ INIT_YMM avx2
 v210_planar_pack_10
 %endif
 
+%if HAVE_AVX512_EXTERNAL
+INIT_YMM avx512
+v210_planar_pack_10
+%endif
+
 %macro v210_planar_pack_8 0
 
 ; v210_planar_pack_8(const uint8_t *y, const uint8_t *u, const uint8_t *v, 
uint8_t *dst, ptrdiff_t width)
diff --git a/libavcodec/x86/v210enc_init.c b/libavcodec/x86/v210enc_init.c
index e997b4b67a..e8aac373a0 100644
--- a/libavcodec/x86/v210enc_init.c
+++ b/libavcodec/x86/v210enc_init.c
@@ -32,6 +32,9 @@ void ff_v210_planar_pack_10_ssse3(const uint16_t *y, const 
uint16_t *u,
 void ff_v210_planar_pack_10_avx2(const uint16_t *y, const uint16_t *u,
  const uint16_t *v, uint8_t *dst,
  ptrdiff_t width);
+void ff_v210_planar_pack_10_avx512(const uint16_t *y, const uint16_t *u,
+   const uint16_t *v, uint8_t *dst,
+   ptrdiff_t width);
 
 av_cold void ff_v210enc_init_x86(V210EncContext *s)
 {
@@ -51,4 +54,8 @@ av_cold void ff_v210enc_init_x86(V210EncContext *s)
 s->sample_factor_10 = 2;
 s->pack_line_10 = ff_v210_planar_pack_10_avx2;
 }
+
+if (EXTERNAL_AVX512(cpu_flags)) {
+s->pack_line_10 = ff_v210_planar_pack_10_avx512;
+}
 }
-- 
2.15.0

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_tile: add skip option

[Paul B Mahol]

On 11/7/17, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi  |  5 +
>  libavfilter/vf_tile.c | 53
> ++-
>  2 files changed, 49 insertions(+), 9 deletions(-)
>

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

[FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode

[James Cowgill]

In commit 061a0c14bb57 ("decode: restructure the core decoding code"), the
deprecated avcodec_decode_* APIs were reworked so that they called into the
new avcodec_send_packet / avcodec_receive_frame API. This had the side effect
of prohibiting sending new packets containing data after a drain
packet, but in previous versions of FFmpeg this "worked" and some
applications relied on it.

To restore some compatibility, reset the codec if we receive a new non-drain
packet using the old API after draining has completed. While this does
not give the same behaviour as the old API did, in the majority of cases
it works and it does not require changes to any other part of the decoding
code.

Fixes ticket #6775
Signed-off-by: James Cowgill 
---
 libavcodec/decode.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 86fe5aef52..2f1932fa85 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -726,6 +726,11 @@ static int compat_decode(AVCodecContext *avctx, AVFrame 
*frame,
 
 av_assert0(avci->compat_decode_consumed == 0);
 
+if (avci->draining_done && pkt && pkt->size != 0) {
+av_log(avctx, AV_LOG_WARNING, "Got unexpected packet after EOF\n");
+avcodec_flush_buffers(avctx);
+}
+
 *got_frame = 0;
 avci->compat_decode = 1;
 
-- 
2.15.0

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

Re: [FFmpeg-devel] [PATCH] avformat/dashdec: fix memleak of rep_dest->parent null

[刘歧]

> 在 2017年11月9日，16:28，Carl Eugen Hoyos  写道：
> 
> Hi!
> 
>> Am 09.11.2017 um 00:52 schrieb Steven Liu :
>> 
>> fix ticket id: #6820
> 
> I find the commit message misleading.
> 
>> use the current DASHContext for the rep_dest
> 
> This may be better imo.
ok, i will use this line to make commit message leading “use the current 
DASHContext for the rep_dest”

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



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

Re: [FFmpeg-devel] [FFmpeg-cvslog] aacenc: support extended channel layouts using PCEs

[Kv Pham]

Le 9 nov. 2017 10:12 AM, "Nicolas George"  a écrit :

Le nonidi 19 brumaire, an CCXXVI, Rostislav Pehlivanov a écrit :
> ffmpeg | branch: master | Rostislav Pehlivanov  |
Mon Oct  3 19:53:11 2016 +0100| [fbf295e2bd4d48d7a0a094ed5afce2fa5b6cf35a]
| committer: Rostislav Pehlivanov
>
> aacenc: support extended channel layouts using PCEs
>
> This commit implements support for PCE (Program Configuration Elements)
in the
> AAC encoder, and as such allows for encoding of channel layouts not
present
> in the presets defined by the spec (which only lists the 8 most common
ones).
>
> This has been a highly requested feature and is also the first open
source encoder
> to support this many layouts.
>
> Many thanks to pkviet  who implemented support for
and
> verified all channel layouts.

This broke fate-aac-yoraw-encode.

stddev:  160.76 PSNR: 52.21 MAXDIFF: 3105 bytes:   576972/   577536
stddev: |160.76 - 259| >= 17


Regards,

--
  Nicolas George


Thanks a lot.
That's probably related to the fixes that I pointed out in my last message
on the thread.
I'll run fate later today on my aacdev branch on github
github.com/pkviet/FFmpeg to check that this fixes the issues.
(amusant de croiser un autre archicube; moi, s92. Les échanges sont parfois
vraiment musclés ici, il ne faut pas être susceptible ! :) )
Regards,
pkv
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: slice processing for geq

[Marc-Antoine ARNAUD]

Please find the merged patch in attachement.

Thanks

Le mer. 8 nov. 2017 à 17:12, Paul B Mahol  a écrit :

> On 11/8/17, Marc-Antoine ARNAUD  wrote:
> > This patch will fix the stride issue.
> > Is it valid for you ?
> >
> > Does it required to merge these 2 patches ? (and remove base64 encoding
> on
> > the first one)
>
> Please merge those two patches, base64 encoding should not be needed
> (it helps to faster review patches if they are not encoded).
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


0001-avfilter-slice-processing-for-geq.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 07/11] checkasm: support for AVX-512 functions

[James Darnley]

---
 tests/checkasm/checkasm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index b8b0e32dbd..9fb1438bdb 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -192,6 +192,7 @@ static const struct {
 { "FMA3", "fma3", AV_CPU_FLAG_FMA3 },
 { "FMA4", "fma4", AV_CPU_FLAG_FMA4 },
 { "AVX2", "avx2", AV_CPU_FLAG_AVX2 },
+{ "AVX-512",  "avx512",   AV_CPU_FLAG_AVX512 },
 #endif
 { NULL }
 };
-- 
2.15.0

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

[FFmpeg-devel] [PATCH 10/11] avcodec/blockdsp: add AVX-512 version of clear_block(s)

[James Darnley]

From: James Darnley 

Also adjust alignment requirements where nessecary.
---
Whether this patch is committed or not the change to 4xm.c should be picked to
master because the alignment is wrong for the AVX version of this function.  I
assume it hasn't been noticed yet because it manages to be 32-byte aligned
without intervention.

 libavcodec/4xm.c   |  2 +-
 libavcodec/asv.h   |  3 ++-
 libavcodec/bink.c  |  4 ++--
 libavcodec/dnxhdenc.h  |  2 +-
 libavcodec/eamad.c |  2 +-
 libavcodec/eatqi.c |  2 +-
 libavcodec/g2meet.c|  2 +-
 libavcodec/ituh263dec.c|  2 +-
 libavcodec/mdec.c  |  2 +-
 libavcodec/mimic.c |  2 +-
 libavcodec/mjpegdec.h  |  3 ++-
 libavcodec/proresdec2.c|  6 +++---
 libavcodec/speedhq.c   |  2 +-
 libavcodec/wmv2.h  |  2 +-
 libavcodec/x86/blockdsp.asm| 14 ++
 libavcodec/x86/blockdsp_init.c |  8 
 libavutil/internal.h   |  6 ++
 tests/checkasm/blockdsp.c  |  4 ++--
 18 files changed, 49 insertions(+), 19 deletions(-)

diff --git a/libavcodec/4xm.c b/libavcodec/4xm.c
index 5547dfd87f..a97f051232 100644
--- a/libavcodec/4xm.c
+++ b/libavcodec/4xm.c
@@ -145,7 +145,7 @@ typedef struct FourXContext {
 int mv[256];
 VLC pre_vlc;
 int last_dc;
-DECLARE_ALIGNED(16, int16_t, block)[6][64];
+DECLARE_ALIGNED(STRIDE_ALIGN, int16_t, block)[6][64];
 void *bitstream_buffer;
 unsigned int bitstream_buffer_size;
 int version;
diff --git a/libavcodec/asv.h b/libavcodec/asv.h
index a1366b6fe4..024ffa349a 100644
--- a/libavcodec/asv.h
+++ b/libavcodec/asv.h
@@ -35,6 +35,7 @@
 #include "bswapdsp.h"
 #include "fdctdsp.h"
 #include "idctdsp.h"
+#include "internal.h"
 #include "get_bits.h"
 #include "pixblockdsp.h"
 #include "put_bits.h"
@@ -54,7 +55,7 @@ typedef struct ASV1Context {
 int mb_height;
 int mb_width2;
 int mb_height2;
-DECLARE_ALIGNED(32, int16_t, block)[6][64];
+DECLARE_ALIGNED(STRIDE_ALIGN, int16_t, block)[6][64];
 uint16_t intra_matrix[64];
 int q_intra_matrix[64];
 uint8_t *bitstream_buffer;
diff --git a/libavcodec/bink.c b/libavcodec/bink.c
index c4cf617a8b..eee19512f7 100644
--- a/libavcodec/bink.c
+++ b/libavcodec/bink.c
@@ -818,7 +818,7 @@ static int binkb_decode_plane(BinkContext *c, AVFrame 
*frame, GetBitContext *gb,
 int v, col[2];
 const uint8_t *scan;
 int xoff, yoff;
-LOCAL_ALIGNED_32(int16_t, block, [64]);
+LOCAL_ALIGNED_64(int16_t, block, [64]);
 LOCAL_ALIGNED_16(int32_t, dctblock, [64]);
 int coordmap[64];
 int ybias = is_key ? -15 : 0;
@@ -985,7 +985,7 @@ static int bink_decode_plane(BinkContext *c, AVFrame 
*frame, GetBitContext *gb,
 uint8_t *dst, *prev, *ref_start, *ref_end;
 int v, col[2];
 const uint8_t *scan;
-LOCAL_ALIGNED_32(int16_t, block, [64]);
+LOCAL_ALIGNED_64(int16_t, block, [64]);
 LOCAL_ALIGNED_16(uint8_t, ublock, [64]);
 LOCAL_ALIGNED_16(int32_t, dctblock, [64]);
 int coordmap[64], quant_idx, coef_count, coef_idx[64];
diff --git a/libavcodec/dnxhdenc.h b/libavcodec/dnxhdenc.h
index 963821ac81..4567a4aa8a 100644
--- a/libavcodec/dnxhdenc.h
+++ b/libavcodec/dnxhdenc.h
@@ -74,7 +74,7 @@ typedef struct DNXHDEncContext {
 unsigned min_padding;
 int intra_quant_bias;
 
-DECLARE_ALIGNED(32, int16_t, blocks)[12][64];
+DECLARE_ALIGNED(STRIDE_ALIGN, int16_t, blocks)[12][64];
 DECLARE_ALIGNED(16, uint8_t, edge_buf_y)[512]; // has to hold 16x16 uint16 
when depth=10
 DECLARE_ALIGNED(16, uint8_t, edge_buf_uv)[2][512]; // has to hold 16x16 
uint16_t when depth=10
 
diff --git a/libavcodec/eamad.c b/libavcodec/eamad.c
index 7f28abbafe..0f638b43f6 100644
--- a/libavcodec/eamad.c
+++ b/libavcodec/eamad.c
@@ -54,7 +54,7 @@ typedef struct MadContext {
 GetBitContext gb;
 void *bitstream_buf;
 unsigned int bitstream_buf_size;
-DECLARE_ALIGNED(32, int16_t, block)[64];
+DECLARE_ALIGNED(STRIDE_ALIGN, int16_t, block)[64];
 ScanTable scantable;
 uint16_t quant_matrix[64];
 int mb_x;
diff --git a/libavcodec/eatqi.c b/libavcodec/eatqi.c
index 1a847a35da..9527bc2713 100644
--- a/libavcodec/eatqi.c
+++ b/libavcodec/eatqi.c
@@ -51,7 +51,7 @@ typedef struct TqiContext {
 uint16_t intra_matrix[64];
 int last_dc[3];
 
-DECLARE_ALIGNED(32, int16_t, block)[6][64];
+DECLARE_ALIGNED(STRIDE_ALIGN, int16_t, block)[6][64];
 } TqiContext;
 
 static av_cold int tqi_decode_init(AVCodecContext *avctx)
diff --git a/libavcodec/g2meet.c b/libavcodec/g2meet.c
index 842095ba3b..57ff92c002 100644
--- a/libavcodec/g2meet.c
+++ b/libavcodec/g2meet.c
@@ -122,7 +122,7 @@ typedef struct JPGContext {
 
 VLCdc_vlc[2], ac_vlc[2];
 intprev_dc[3];
-DECLARE_ALIGNED(32, int16_t, block)[6][64];
+DECLARE_ALIGNED(STRIDE_ALIGN, int16_t, block)[6][64];
 
 uint8_t*buf;
 } 

[FFmpeg-devel] [PATCH 06/11] x86inc: AVX-512 support

[James Darnley]

From: Henrik Gramner 

AVX-512 consists of a plethora of different extensions, but in order to keep
things a bit more manageable we group together the following extensions
under a single baseline cpu flag which should cover SKL-X and future CPUs:
 * AVX-512 Foundation (F)
 * AVX-512 Conflict Detection Instructions (CD)
 * AVX-512 Byte and Word Instructions (BW)
 * AVX-512 Doubleword and Quadword Instructions (DQ)
 * AVX-512 Vector Length Extensions (VL)

On x86-64 AVX-512 provides 16 additional vector registers, prefer using
those over existing ones since it allows us to avoid using `vzeroupper`
unless more than 16 vector registers are required. They also happen to
be volatile on Windows which means that we don't need to save and restore
existing xmm register contents unless more than 22 vector registers are
required.

Big thanks to Intel for their support.
---
 libavutil/x86/x86inc.asm | 172 ++-
 1 file changed, 139 insertions(+), 33 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 6a054a3e09..f3dd2b788a 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -337,6 +337,8 @@ DECLARE_REG_TMP_SIZE 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14
 %endmacro
 
 %define required_stack_alignment ((mmsize + 15) & ~15)
+%define vzeroupper_required (mmsize > 16 && (ARCH_X86_64 == 0 || xmm_regs_used 
> 16 || notcpuflag(avx512)))
+%define high_mm_regs (16*cpuflag(avx512))
 
 %macro ALLOC_STACK 1-2 0 ; stack_size, n_xmm_regs (for win64 only)
 %ifnum %1
@@ -450,15 +452,16 @@ DECLARE_REG 14, R13, 120
 
 %macro WIN64_PUSH_XMM 0
 ; Use the shadow space to store XMM6 and XMM7, the rest needs stack space 
allocated.
-%if xmm_regs_used > 6
+%if xmm_regs_used > 6 + high_mm_regs
 movaps [rstk + stack_offset +  8], xmm6
 %endif
-%if xmm_regs_used > 7
+%if xmm_regs_used > 7 + high_mm_regs
 movaps [rstk + stack_offset + 24], xmm7
 %endif
-%if xmm_regs_used > 8
+%assign %%xmm_regs_on_stack xmm_regs_used - high_mm_regs - 8
+%if %%xmm_regs_on_stack > 0
 %assign %%i 8
-%rep xmm_regs_used-8
+%rep %%xmm_regs_on_stack
 movaps [rsp + (%%i-8)*16 + stack_size + 32], xmm %+ %%i
 %assign %%i %%i+1
 %endrep
@@ -467,10 +470,11 @@ DECLARE_REG 14, R13, 120
 
 %macro WIN64_SPILL_XMM 1
 %assign xmm_regs_used %1
-ASSERT xmm_regs_used <= 16
-%if xmm_regs_used > 8
+ASSERT xmm_regs_used <= 16 + high_mm_regs
+%assign %%xmm_regs_on_stack xmm_regs_used - high_mm_regs - 8
+%if %%xmm_regs_on_stack > 0
 ; Allocate stack space for callee-saved xmm registers plus shadow 
space and align the stack.
-%assign %%pad (xmm_regs_used-8)*16 + 32
+%assign %%pad %%xmm_regs_on_stack*16 + 32
 %assign stack_size_padded %%pad + ((-%%pad-stack_offset-gprsize) & 
(STACK_ALIGNMENT-1))
 SUB rsp, stack_size_padded
 %endif
@@ -479,9 +483,10 @@ DECLARE_REG 14, R13, 120
 
 %macro WIN64_RESTORE_XMM_INTERNAL 0
 %assign %%pad_size 0
-%if xmm_regs_used > 8
-%assign %%i xmm_regs_used
-%rep xmm_regs_used-8
+%assign %%xmm_regs_on_stack xmm_regs_used - high_mm_regs - 8
+%if %%xmm_regs_on_stack > 0
+%assign %%i xmm_regs_used - high_mm_regs
+%rep %%xmm_regs_on_stack
 %assign %%i %%i-1
 movaps xmm %+ %%i, [rsp + (%%i-8)*16 + stack_size + 32]
 %endrep
@@ -494,10 +499,10 @@ DECLARE_REG 14, R13, 120
 %assign %%pad_size stack_size_padded
 %endif
 %endif
-%if xmm_regs_used > 7
+%if xmm_regs_used > 7 + high_mm_regs
 movaps xmm7, [rsp + stack_offset - %%pad_size + 24]
 %endif
-%if xmm_regs_used > 6
+%if xmm_regs_used > 6 + high_mm_regs
 movaps xmm6, [rsp + stack_offset - %%pad_size +  8]
 %endif
 %endmacro
@@ -509,12 +514,12 @@ DECLARE_REG 14, R13, 120
 %assign xmm_regs_used 0
 %endmacro
 
-%define has_epilogue regs_used > 7 || xmm_regs_used > 6 || mmsize == 32 || 
stack_size > 0
+%define has_epilogue regs_used > 7 || stack_size > 0 || vzeroupper_required || 
xmm_regs_used > 6+high_mm_regs
 
 %macro RET 0
 WIN64_RESTORE_XMM_INTERNAL
 POP_IF_USED 14, 13, 12, 11, 10, 9, 8, 7
-%if mmsize == 32
+%if vzeroupper_required
 vzeroupper
 %endif
 AUTO_REP_RET
@@ -538,9 +543,10 @@ DECLARE_REG 12, R15, 56
 DECLARE_REG 13, R12, 64
 DECLARE_REG 14, R13, 72
 
-%macro PROLOGUE 2-5+ ; #args, #regs, #xmm_regs, [stack_size,] arg_names...
+%macro PROLOGUE 2-5+ 0 ; #args, #regs, #xmm_regs, [stack_size,] arg_names...
 %assign num_args %1
 %assign regs_used %2
+%assign xmm_regs_used %3
 ASSERT regs_used >= num_args
 SETUP_STACK_POINTER %4
 ASSERT regs_used <= 15
@@ -550,7 +556,7 @@ DECLARE_REG 14, R13, 72
 DEFINE_ARGS_INTERNAL %0, %4, %5
 %endmacro
 
-%define has_epilogue regs_used > 9 || mmsize == 32 || stack_size > 0
+%define 

[FFmpeg-devel] [PATCH 00/11] AVX-512 support (v.2)

[James Darnley]

A few changes from last time.  A couple of the patches have notes on them.

I've dropped the patch which added Nasm's smartalign feature which was causing
problems building rv34dsp.asm.  I don't know why.  Eventually I try to look at
it again.

I've also added 3 functions that acutally use ZMM registers.

Henrik Gramner (1):
  x86inc: AVX-512 support

James Darnley (10):
  configure: test whether x86 assembler supports AVX-512
  avutil: add AVX-512 flags
  avutil: detect when AVX-512 is available
  avutil: add alignment needed for AVX-512
  avcodec: add stride alignment needed for AVX-512
  checkasm: support for AVX-512 functions
  avcodec/v210enc: add AVX-512 10-bit line pack function
  avcodec/blockdsp: roll-up x86asm preprocessor loop
  avcodec/blockdsp: add AVX-512 version of clear_block(s)
  avcodec/lossless_videodsp: add AVX-512 version of add_bytes

 configure   |   7 ++
 libavcodec/4xm.c|   2 +-
 libavcodec/asv.h|   3 +-
 libavcodec/bink.c   |   4 +-
 libavcodec/dnxhdenc.h   |   2 +-
 libavcodec/eamad.c  |   2 +-
 libavcodec/eatqi.c  |   2 +-
 libavcodec/g2meet.c |   2 +-
 libavcodec/internal.h   |   4 +-
 libavcodec/ituh263dec.c |   2 +-
 libavcodec/mdec.c   |   2 +-
 libavcodec/mimic.c  |   2 +-
 libavcodec/mjpegdec.h   |   3 +-
 libavcodec/proresdec2.c |   6 +-
 libavcodec/speedhq.c|   2 +-
 libavcodec/wmv2.h   |   2 +-
 libavcodec/x86/blockdsp.asm |  25 +++--
 libavcodec/x86/blockdsp_init.c  |   8 ++
 libavcodec/x86/lossless_videodsp.asm|   5 +
 libavcodec/x86/lossless_videodsp_init.c |   5 +
 libavcodec/x86/v210enc.asm  |   5 +
 libavcodec/x86/v210enc_init.c   |   7 ++
 libavutil/cpu.c |   6 +-
 libavutil/cpu.h |   1 +
 libavutil/internal.h|   6 ++
 libavutil/mem.c |   2 +-
 libavutil/tests/cpu.c   |   1 +
 libavutil/x86/cpu.c |  14 ++-
 libavutil/x86/cpu.h |   2 +
 libavutil/x86/x86inc.asm| 172 ++--
 tests/checkasm/blockdsp.c   |   4 +-
 tests/checkasm/checkasm.c   |   1 +
 32 files changed, 247 insertions(+), 64 deletions(-)

-- 
2.15.0

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

[FFmpeg-devel] [PATCH 11/11] avcodec/lossless_videodsp: add AVX-512 version of add_bytes

[James Darnley]

---
 libavcodec/x86/lossless_videodsp.asm| 5 +
 libavcodec/x86/lossless_videodsp_init.c | 5 +
 2 files changed, 10 insertions(+)

diff --git a/libavcodec/x86/lossless_videodsp.asm 
b/libavcodec/x86/lossless_videodsp.asm
index ba4d4f0153..5649348f86 100644
--- a/libavcodec/x86/lossless_videodsp.asm
+++ b/libavcodec/x86/lossless_videodsp.asm
@@ -229,6 +229,11 @@ INIT_YMM avx2
 ADD_BYTES
 %endif
 
+%if HAVE_AVX512_EXTERNAL
+INIT_ZMM avx512
+ADD_BYTES
+%endif
+
 %macro ADD_HFYU_LEFT_LOOP_INT16 2 ; %1 = dst alignment (a/u), %2 = src 
alignment (a/u)
 add wd, wd
 add srcq, wq
diff --git a/libavcodec/x86/lossless_videodsp_init.c 
b/libavcodec/x86/lossless_videodsp_init.c
index 4f20c1ce92..80d6972f36 100644
--- a/libavcodec/x86/lossless_videodsp_init.c
+++ b/libavcodec/x86/lossless_videodsp_init.c
@@ -26,6 +26,7 @@
 void ff_add_bytes_mmx(uint8_t *dst, uint8_t *src, ptrdiff_t w);
 void ff_add_bytes_sse2(uint8_t *dst, uint8_t *src, ptrdiff_t w);
 void ff_add_bytes_avx2(uint8_t *dst, uint8_t *src, ptrdiff_t w);
+void ff_add_bytes_avx512(uint8_t *dst, uint8_t *src, ptrdiff_t w);
 
 void ff_add_median_pred_mmxext(uint8_t *dst, const uint8_t *top,
const uint8_t *diff, ptrdiff_t w,
@@ -119,4 +120,8 @@ void ff_llviddsp_init_x86(LLVidDSPContext *c)
 if (EXTERNAL_AVX2_FAST(cpu_flags)) {
 c->add_bytes   = ff_add_bytes_avx2;
 }
+
+if (EXTERNAL_AVX512(cpu_flags)) {
+c->add_bytes   = ff_add_bytes_avx512;
+}
 }
-- 
2.15.0

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

[FFmpeg-devel] [PATCH 01/11] configure: test whether x86 assembler supports AVX-512

[James Darnley]

---
 configure | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configure b/configure
index f396abda5b..146a87324c 100755
--- a/configure
+++ b/configure
@@ -406,6 +406,7 @@ Optimization options (experts only):
   --disable-fma3   disable FMA3 optimizations
   --disable-fma4   disable FMA4 optimizations
   --disable-avx2   disable AVX2 optimizations
+  --disable-avx512 disable AVX-512 optimizations
   --disable-aesni  disable AESNI optimizations
   --disable-armv5tedisable armv5te optimizations
   --disable-armv6  disable armv6 optimizations
@@ -1840,6 +1841,7 @@ ARCH_EXT_LIST_X86_SIMD="
 amd3dnowext
 avx
 avx2
+avx512
 fma3
 fma4
 mmx
@@ -2364,6 +2366,7 @@ xop_deps="avx"
 fma3_deps="avx"
 fma4_deps="avx"
 avx2_deps="avx"
+avx512_deps="avx2"
 
 mmx_external_deps="x86asm"
 mmx_inline_deps="inline_asm x86"
@@ -5664,6 +5667,7 @@ EOF
 elf*) enabled debug && append X86ASMFLAGS $x86asm_debug ;;
 esac
 
+check_x86asm "vmovdqa32 [eax]{k1}{z}, zmm0"|| disable 
avx512_external
 check_x86asm "vextracti128 xmm0, ymm0, 0"  || disable avx2_external
 check_x86asm "vpmacsdd xmm0, xmm1, xmm2, xmm3" || disable xop_external
 check_x86asm "vfmaddps ymm0, ymm1, ymm2, ymm3" || disable fma4_external
@@ -6794,6 +6798,7 @@ if enabled x86; then
 echo "AESNI enabled ${aesni-no}"
 echo "AVX enabled   ${avx-no}"
 echo "AVX2 enabled  ${avx2-no}"
+echo "AVX-512 enabled   ${avx512-no}"
 echo "XOP enabled   ${xop-no}"
 echo "FMA3 enabled  ${fma3-no}"
 echo "FMA4 enabled  ${fma4-no}"
-- 
2.15.0

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

[FFmpeg-devel] [PATCH 04/11] avutil: add alignment needed for AVX-512

[James Darnley]

---
This patch gained the alignmnet increase in mem.c

 libavutil/mem.c | 2 +-
 libavutil/x86/cpu.c | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavutil/mem.c b/libavutil/mem.c
index 6ad409daf4..cdf539306f 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -61,7 +61,7 @@ void  free(void *ptr);
 
 #include "mem_internal.h"
 
-#define ALIGN (HAVE_AVX ? 32 : 16)
+#define ALIGN (HAVE_AVX512 ? 64 : HAVE_AVX ? 32 : 16)
 
 /* NOTE: if you want to override these functions with your own
  * implementations (not recommended) you have to link libav* as
diff --git a/libavutil/x86/cpu.c b/libavutil/x86/cpu.c
index 589fdef7da..01b3c39c1e 100644
--- a/libavutil/x86/cpu.c
+++ b/libavutil/x86/cpu.c
@@ -246,6 +246,8 @@ size_t ff_get_cpu_max_align_x86(void)
 {
 int flags = av_get_cpu_flags();
 
+if (flags & AV_CPU_FLAG_AVX512)
+return 64;
 if (flags & (AV_CPU_FLAG_AVX2  |
  AV_CPU_FLAG_AVX   |
  AV_CPU_FLAG_XOP   |
-- 
2.15.0

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

Re: [FFmpeg-devel] [PATCH] avformat/dashdec: fix memleak of rep_dest->parent null

[Carl Eugen Hoyos]

Hi!

> Am 09.11.2017 um 00:52 schrieb Steven Liu :
> 
> fix ticket id: #6820

I find the commit message misleading.

> use the current DASHContext for the rep_dest

This may be better imo.

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

[FFmpeg-devel] [PATCH 2/3] avformat/tcp: use generic socket API

[Nablet Developer]

this allows to implement other protocols which use
API similar to BSD sockets (e.g. Haivision SRT)

Signed-off-by: Nablet Developer 
---
 libavformat/tcp.c | 118 +++---
 libavformat/tcp.h |  59 +++
 2 files changed, 119 insertions(+), 58 deletions(-)
 create mode 100644 libavformat/tcp.h

diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index 07b4ed9..a775230 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -32,26 +32,12 @@
 #include 
 #endif
 
-typedef struct TCPContext {
-const AVClass *class;
-int fd;
-int listen;
-int open_timeout;
-int rw_timeout;
-int listen_timeout;
-int recv_buffer_size;
-int send_buffer_size;
-} TCPContext;
-
-#define OFFSET(x) offsetof(TCPContext, x)
+#include "tcp.h"
+
 #define D AV_OPT_FLAG_DECODING_PARAM
 #define E AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
-{ "listen",  "Listen for incoming connections",  OFFSET(listen),   
  AV_OPT_TYPE_INT, { .i64 = 0 }, 0,   2,   .flags = D|E },
-{ "timeout", "set timeout (in microseconds) of socket I/O operations", 
OFFSET(rw_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, 
.flags = D|E },
-{ "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 },
+TCP_COMMON_OPTS
 { NULL }
 };
 
@@ -63,7 +49,7 @@ static const AVClass tcp_class = {
 };
 
 /* return non zero if error */
-static int tcp_open(URLContext *h, const char *uri, int flags)
+int ff_tcp_open(URLContext *h, const char *uri, int flags)
 {
 struct addrinfo hints = { 0 }, *ai, *cur_ai;
 int port, fd = -1;
@@ -75,10 +61,15 @@ static int tcp_open(URLContext *h, const char *uri, int 
flags)
 char portstr[10];
 s->open_timeout = 500;
 
+s->api = s->api ? s->api : _socket_api;
+s->proto = s->proto ? s->proto : "tcp";
+
 av_url_split(proto, sizeof(proto), NULL, 0, hostname, sizeof(hostname),
 , path, sizeof(path), uri);
-if (strcmp(proto, "tcp"))
+if (strcmp(proto, s->proto)) {
+av_log(h, AV_LOG_ERROR, "incorrect protocol %s %s\n", proto, s->proto);
 return AVERROR(EINVAL);
+}
 if (port <= 0 || port >= 65536) {
 av_log(h, AV_LOG_ERROR, "Port missing in uri\n");
 return AVERROR(EINVAL);
@@ -132,37 +123,42 @@ static int tcp_open(URLContext *h, const char *uri, int 
flags)
 }
 #endif
 
-fd = ff_socket(cur_ai->ai_family,
-   cur_ai->ai_socktype,
-   cur_ai->ai_protocol);
+fd = s->api->socket(cur_ai->ai_family,
+cur_ai->ai_socktype,
+cur_ai->ai_protocol);
 if (fd < 0) {
-ret = ff_neterrno();
+ret = s->api->neterrno();
 goto fail;
 }
 
 /* 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, >recv_buffer_size, sizeof 
(s->recv_buffer_size));
+s->api->setsockopt (fd, SOL_SOCKET, SO_RCVBUF, >recv_buffer_size, 
sizeof (s->recv_buffer_size));
 }
 if (s->send_buffer_size > 0) {
-setsockopt (fd, SOL_SOCKET, SO_SNDBUF, >send_buffer_size, sizeof 
(s->send_buffer_size));
+s->api->setsockopt (fd, SOL_SOCKET, SO_SNDBUF, >send_buffer_size, 
sizeof (s->send_buffer_size));
+}
+
+if (s->set_options_pre) {
+if ((ret = s->set_options_pre(h, fd)) < 0)
+goto fail1;
 }
 
 if (s->listen == 2) {
 // multi-client
-if ((ret = ff_listen(fd, cur_ai->ai_addr, cur_ai->ai_addrlen)) < 0)
+if ((ret = ff_listen_ex(s->api, fd, cur_ai->ai_addr, 
cur_ai->ai_addrlen)) < 0)
 goto fail1;
 } else if (s->listen == 1) {
 // single client
-if ((ret = ff_listen_bind(fd, cur_ai->ai_addr, cur_ai->ai_addrlen,
-  s->listen_timeout, h)) < 0)
+if ((ret = ff_listen_bind_ex(s->api, fd, cur_ai->ai_addr, 
cur_ai->ai_addrlen,
+ s->listen_timeout, h)) < 0)
 goto fail1;
 // Socket descriptor already closed here. Safe to overwrite to client 
one.
 fd = ret;
 } else {
-if ((ret = ff_listen_connect(fd, cur_ai->ai_addr, cur_ai->ai_addrlen,
- s->open_timeout / 1000, h, 
!!cur_ai->ai_next)) < 0) {
+if ((ret = ff_listen_connect_ex(s->api, 

[FFmpeg-devel] [PATCH 3/3] avformat/opensrt: add Haivision Open SRT protocol

[Nablet Developer]

protocol requires libsrt (https://github.com/Haivision/srt) to be
installed

Signed-off-by: Nablet Developer 
---
 configure   |  10 ++
 libavformat/Makefile|   1 +
 libavformat/opensrt.c   | 418 
 libavformat/protocols.c |   1 +
 4 files changed, 430 insertions(+)
 create mode 100644 libavformat/opensrt.c

diff --git a/configure b/configure
index f396abd..b44df0e 100755
--- a/configure
+++ b/configure
@@ -293,6 +293,7 @@ External library support:
   --enable-opengl  enable OpenGL rendering [no]
   --enable-openssl enable openssl, needed for https support
if gnutls is not used [no]
+  --enable-opensrt enable Haivision Open SRT protoco [no]
   --disable-sndio  disable sndio support [autodetect]
   --disable-schannel   disable SChannel SSP, needed for TLS support on
Windows if openssl and gnutls are not used 
[autodetect]
@@ -1638,6 +1639,7 @@ EXTERNAL_LIBRARY_LIST="
 openal
 opencl
 opengl
+opensrt
 "
 
 HWACCEL_AUTODETECT_LIBRARY_LIST="
@@ -3139,6 +3141,8 @@ libsmbclient_protocol_deps="libsmbclient gplv3"
 libssh_protocol_deps="libssh"
 mmsh_protocol_select="http_protocol"
 mmst_protocol_select="network"
+opensrt_protocol_select="network"
+opensrt_protocol_deps="opensrt"
 rtmp_protocol_conflict="librtmp_protocol"
 rtmp_protocol_select="tcp_protocol"
 rtmp_protocol_suggest="zlib"
@@ -6102,6 +6106,8 @@ enabled omx   && require_header OMX_Core.h
 enabled omx_rpi   && { check_header OMX_Core.h ||
{ ! enabled cross_compile && add_cflags 
-isystem/opt/vc/include/IL && check_header OMX_Core.h ; } ||
die "ERROR: OpenMAX IL headers not found"; } && 
enable omx
+#enabled opensrt   && check_lib srt srt/srt.h srt_socket -lsrt
+enabled opensrt   && require_pkg_config libsrt "srt >= 1.2.0" 
srt/srt.h srt_socket
 enabled openssl   && { use_pkg_config openssl openssl openssl/ssl.h 
OPENSSL_init_ssl ||
use_pkg_config openssl openssl openssl/ssl.h 
SSL_library_init ||
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl -lcrypto ||
@@ -6156,6 +6162,10 @@ if enabled decklink; then
 esac
 fi
 
+if enabled opensrt; then
+opensrt_protocol_extralibs="$opensrt_protocol_extralibs -lsrt"
+fi
+
 enabled securetransport &&
 check_func SecIdentityCreate "-Wl,-framework,CoreFoundation 
-Wl,-framework,Security" &&
 check_lib securetransport "Security/SecureTransport.h Security/Security.h" 
"SSLCreateContext SecItemImport" "-Wl,-framework,CoreFoundation 
-Wl,-framework,Security" ||
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 146a465..5116d31 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -596,6 +596,7 @@ TLS-OBJS-$(CONFIG_SCHANNEL)  += tls_schannel.o
 OBJS-$(CONFIG_TLS_PROTOCOL)  += tls.o $(TLS-OBJS-yes)
 OBJS-$(CONFIG_UDP_PROTOCOL)  += udp.o
 OBJS-$(CONFIG_UDPLITE_PROTOCOL)  += udp.o
+OBJS-$(CONFIG_OPENSRT_PROTOCOL)  += opensrt.o
 OBJS-$(CONFIG_UNIX_PROTOCOL) += unix.o
 
 # libavdevice dependencies
diff --git a/libavformat/opensrt.c b/libavformat/opensrt.c
new file mode 100644
index 000..bc58368
--- /dev/null
+++ b/libavformat/opensrt.c
@@ -0,0 +1,418 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Haivision Open SRT (Secure Reliable Transport) protocol
+ */
+
+#include "avformat.h"
+#include "libavutil/avassert.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/time.h"
+
+#include "internal.h"
+#include "network.h"
+#include "os_support.h"
+#include "url.h"
+#if HAVE_POLL_H
+#include 
+#endif
+
+#include "tcp.h"
+
+#if CONFIG_OPENSRT_PROTOCOL
+#include 
+#endif
+
+enum SRTMode {
+SRT_MODE_CALLER = 0,
+SRT_MODE_LISTENER = 1,
+SRT_MODE_RENDEZVOUS = 2
+};
+
+typedef struct SRTContext {
+struct TCPContext tcp_context;
+/* SRT socket options (srt/srt.h) */
+int64_t maxbw;
+int pbkeylen;
+char * passphrase;
+int mss;
+int fc;
+int ipttl;
+int 

[FFmpeg-devel] [PATCH 1/3] avformat/network: allow to specify custom socket API

[Nablet Developer]

Signed-off-by: Nablet Developer 
---
 libavformat/network.c | 196 --
 libavformat/network.h |  34 +
 2 files changed, 161 insertions(+), 69 deletions(-)

diff --git a/libavformat/network.c b/libavformat/network.c
index 6c3d9de..80d6f6e 100644
--- a/libavformat/network.c
+++ b/libavformat/network.c
@@ -74,24 +74,104 @@ int ff_network_init(void)
 return 1;
 }
 
+#if HAVE_WINSOCK2_H
+int ff_neterrno(void)
+{
+int err = WSAGetLastError();
+switch (err) {
+case WSAEWOULDBLOCK:
+return AVERROR(EAGAIN);
+case WSAEINTR:
+return AVERROR(EINTR);
+case WSAEPROTONOSUPPORT:
+return AVERROR(EPROTONOSUPPORT);
+case WSAETIMEDOUT:
+return AVERROR(ETIMEDOUT);
+case WSAECONNREFUSED:
+return AVERROR(ECONNREFUSED);
+case WSAEINPROGRESS:
+return AVERROR(EINPROGRESS);
+}
+return -err;
+}
+#endif
+
+// wrap into function as ff_neterrno is define on *nix
+static int ff_neterrno_wrapper(void)
+{
+return ff_neterrno();
+}
+
+int ff_socket(int af, int type, int proto)
+{
+int fd;
+
+#ifdef SOCK_CLOEXEC
+fd = socket(af, type | SOCK_CLOEXEC, proto);
+if (fd == -1 && errno == EINVAL)
+#endif
+{
+fd = socket(af, type, proto);
+#if HAVE_FCNTL
+if (fd != -1) {
+if (fcntl(fd, F_SETFD, FD_CLOEXEC) == -1)
+av_log(NULL, AV_LOG_DEBUG, "Failed to set close on exec\n");
+}
+#endif
+}
+#ifdef SO_NOSIGPIPE
+if (fd != -1)
+setsockopt(fd, SOL_SOCKET, SO_NOSIGPIPE, &(int){1}, sizeof(int));
+#endif
+return fd;
+}
+
+
+const struct socket_api bsd_socket_api = {
+.poll = poll,
+.bind = bind,
+.socket = ff_socket,
+.listen = listen,
+.connect = connect,
+.setsockopt = setsockopt,
+.getsockopt = getsockopt,
+.accept = accept,
+.close = closesocket,
+.socket_nonblock = ff_socket_nonblock,
+.neterrno = ff_neterrno_wrapper,
+.send = send,
+.recv = recv,
+.shutdown = shutdown
+};
+
 int ff_network_wait_fd(int fd, int write)
 {
+return ff_network_wait_fd_ex(_socket_api, fd, write);
+}
+
+int ff_network_wait_fd_ex(const struct socket_api * api, int fd, int write)
+{
 int ev = write ? POLLOUT : POLLIN;
 struct pollfd p = { .fd = fd, .events = ev, .revents = 0 };
 int ret;
-ret = poll(, 1, POLLING_TIME);
-return ret < 0 ? ff_neterrno() : p.revents & (ev | POLLERR | POLLHUP) ? 0 
: AVERROR(EAGAIN);
+ret = api->poll(, 1, POLLING_TIME);
+return ret < 0 ? api->neterrno() : p.revents & (ev | POLLERR | POLLHUP) ? 
0 : AVERROR(EAGAIN);
 }
 
 int ff_network_wait_fd_timeout(int fd, int write, int64_t timeout, 
AVIOInterruptCB *int_cb)
 {
+return ff_network_wait_fd_timeout_ex(_socket_api, fd, write, timeout, 
int_cb);
+}
+
+int ff_network_wait_fd_timeout_ex(const struct socket_api * api, int fd, int 
write, int64_t timeout, AVIOInterruptCB *int_cb)
+{
 int ret;
 int64_t wait_start = 0;
 
 while (1) {
 if (ff_check_interrupt(int_cb))
 return AVERROR_EXIT;
-ret = ff_network_wait_fd(fd, write);
+ret = ff_network_wait_fd_ex(api, fd, write);
 if (ret != AVERROR(EAGAIN))
 return ret;
 if (timeout > 0) {
@@ -110,28 +190,6 @@ void ff_network_close(void)
 #endif
 }
 
-#if HAVE_WINSOCK2_H
-int ff_neterrno(void)
-{
-int err = WSAGetLastError();
-switch (err) {
-case WSAEWOULDBLOCK:
-return AVERROR(EAGAIN);
-case WSAEINTR:
-return AVERROR(EINTR);
-case WSAEPROTONOSUPPORT:
-return AVERROR(EPROTONOSUPPORT);
-case WSAETIMEDOUT:
-return AVERROR(ETIMEDOUT);
-case WSAECONNREFUSED:
-return AVERROR(ECONNREFUSED);
-case WSAEINPROGRESS:
-return AVERROR(EINPROGRESS);
-}
-return -err;
-}
-#endif
-
 int ff_is_multicast_address(struct sockaddr *addr)
 {
 if (addr->sa_family == AF_INET) {
@@ -146,7 +204,7 @@ int ff_is_multicast_address(struct sockaddr *addr)
 return 0;
 }
 
-static int ff_poll_interrupt(struct pollfd *p, nfds_t nfds, int timeout,
+static int ff_poll_interrupt_ex(const struct socket_api * api, struct pollfd 
*p, nfds_t nfds, int timeout,
  AVIOInterruptCB *cb)
 {
 int runs = timeout / POLLING_TIME;
@@ -155,7 +213,7 @@ static int ff_poll_interrupt(struct pollfd *p, nfds_t nfds, 
int timeout,
 do {
 if (ff_check_interrupt(cb))
 return AVERROR_EXIT;
-ret = poll(p, nfds, POLLING_TIME);
+ret = api->poll(p, nfds, POLLING_TIME);
 if (ret != 0)
 break;
 } while (timeout <= 0 || runs-- > 0);
@@ -163,65 +221,52 @@ static int ff_poll_interrupt(struct pollfd *p, nfds_t 
nfds, int timeout,
 if (!ret)
 return AVERROR(ETIMEDOUT);
 if (ret < 0)
-return ff_neterrno();
+return api->neterrno();
 return ret;
 }
 
-int ff_socket(int af, int type, int proto)
+int 

[FFmpeg-devel] [PATCH 0/3] avformat/opensrt: add Haivision Open SRT protocol

[Nablet Developer]

the following patches implement Haivision SRT protocol.
name OpenSRT is used to distinguish it from SRT subtitles.
patches avoid copy-paste and associated maintanance burden
by re-using existing code as much as possible (more
specifically, tcp.c and network.c).
network.c now allows to use other BSD-like socket APIs,
for instance SRT or UDT.
tcp.c is used as base for SRT protocol implementation,
as SRT socket API closely ressambles TCP sockets.

Nablet Developer (3):
  avformat/network: allow to specify custom socket API
  avformat/tcp: use generic socket API
  avformat/opensrt: add Haivision Open SRT protocol

 configure   |  10 ++
 libavformat/Makefile|   1 +
 libavformat/network.c   | 196 +++
 libavformat/network.h   |  34 
 libavformat/opensrt.c   | 418 
 libavformat/protocols.c |   1 +
 libavformat/tcp.c   | 118 +++---
 libavformat/tcp.h   |  59 +++
 8 files changed, 710 insertions(+), 127 deletions(-)
 create mode 100644 libavformat/opensrt.c
 create mode 100644 libavformat/tcp.h

-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_tile: add skip option

[Nicolas George]

Le nonidi 19 brumaire, an CCXXVI, Paul B Mahol a écrit :
> ping

Please, it has not yet been 48 hours. I cannot promise to have time to
look at it carefully enough before Sunday.

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 3/3] avformat/opensrt: add Haivision Open SRT protocol

[Kv Pham]

Le 9 nov. 2017 10:32 AM, "Nablet Developer"  a écrit :

protocol requires libsrt (https://github.com/Haivision/srt) to be
installed

Signed-off-by: Nablet Developer 
---
 configure   |  10 ++
 libavformat/Makefile|   1 +
 libavformat/opensrt.c   | 418 ++
++
 libavformat/protocols.c |   1 +
 4 files changed, 430 insertions(+)
 create mode 100644 libavformat/opensrt.c

diff --git a/configure b/configure
index f396abd..b44df0e 100755
--- a/configure
+++ b/configure
@@ -293,6 +293,7 @@ External library support:
   --enable-opengl  enable OpenGL rendering [no]
   --enable-openssl enable openssl, needed for https support
if gnutls is not used [no]
+  --enable-opensrt enable Haivision Open SRT protoco [no]
   --disable-sndio  disable sndio support [autodetect]
   --disable-schannel   disable SChannel SSP, needed for TLS support on
Windows if openssl and gnutls are not used
[autodetect]
@@ -1638,6 +1639,7 @@ EXTERNAL_LIBRARY_LIST="
 openal
 opencl
 opengl
+opensrt
 "

 HWACCEL_AUTODETECT_LIBRARY_LIST="
@@ -3139,6 +3141,8 @@ libsmbclient_protocol_deps="libsmbclient gplv3"
 libssh_protocol_deps="libssh"
 mmsh_protocol_select="http_protocol"
 mmst_protocol_select="network"
+opensrt_protocol_select="network"
+opensrt_protocol_deps="opensrt"
 rtmp_protocol_conflict="librtmp_protocol"
 rtmp_protocol_select="tcp_protocol"
 rtmp_protocol_suggest="zlib"
@@ -6102,6 +6106,8 @@ enabled omx   && require_header OMX_Core.h
 enabled omx_rpi   && { check_header OMX_Core.h ||
{ ! enabled cross_compile && add_cflags
-isystem/opt/vc/include/IL && check_header OMX_Core.h ; } ||
die "ERROR: OpenMAX IL headers not found";
} && enable omx
+#enabled opensrt   && check_lib srt srt/srt.h srt_socket -lsrt
+enabled opensrt   && require_pkg_config libsrt "srt >= 1.2.0"
srt/srt.h srt_socket
 enabled openssl   && { use_pkg_config openssl openssl
openssl/ssl.h OPENSSL_init_ssl ||
use_pkg_config openssl openssl
openssl/ssl.h SSL_library_init ||
check_lib openssl openssl/ssl.h
SSL_library_init -lssl -lcrypto ||
@@ -6156,6 +6162,10 @@ if enabled decklink; then
 esac
 fi

+if enabled opensrt; then
+opensrt_protocol_extralibs="$opensrt_protocol_extralibs -lsrt"
+fi
+
 enabled securetransport &&
 check_func SecIdentityCreate "-Wl,-framework,CoreFoundation
-Wl,-framework,Security" &&
 check_lib securetransport "Security/SecureTransport.h
Security/Security.h" "SSLCreateContext SecItemImport"
"-Wl,-framework,CoreFoundation -Wl,-framework,Security" ||
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 146a465..5116d31 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -596,6 +596,7 @@ TLS-OBJS-$(CONFIG_SCHANNEL)  +=
tls_schannel.o
 OBJS-$(CONFIG_TLS_PROTOCOL)  += tls.o $(TLS-OBJS-yes)
 OBJS-$(CONFIG_UDP_PROTOCOL)  += udp.o
 OBJS-$(CONFIG_UDPLITE_PROTOCOL)  += udp.o
+OBJS-$(CONFIG_OPENSRT_PROTOCOL)  += opensrt.o
 OBJS-$(CONFIG_UNIX_PROTOCOL) += unix.o

 # libavdevice dependencies
diff --git a/libavformat/opensrt.c b/libavformat/opensrt.c
new file mode 100644
index 000..bc58368
--- /dev/null
+++ b/libavformat/opensrt.c
@@ -0,0 +1,418 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA
+ */
+
+/**
+ * @file
+ * Haivision Open SRT (Secure Reliable Transport) protocol
+ */
+
+#include "avformat.h"
+#include "libavutil/avassert.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/time.h"
+
+#include "internal.h"
+#include "network.h"
+#include "os_support.h"
+#include "url.h"
+#if HAVE_POLL_H
+#include 
+#endif
+
+#include "tcp.h"
+
+#if CONFIG_OPENSRT_PROTOCOL
+#include 
+#endif
+
+enum SRTMode {
+SRT_MODE_CALLER = 0,
+SRT_MODE_LISTENER = 1,
+SRT_MODE_RENDEZVOUS = 2
+};
+
+typedef struct SRTContext {
+struct TCPContext tcp_context;
+/* SRT socket options (srt/srt.h) */
+int64_t maxbw;
+int pbkeylen;
+char * 

Re: [FFmpeg-devel] [PATCH 1/2] lavc/libkvazaar: switch to ff_alloc_packet2

[Arttu Ylä-Outinen]

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

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

[kaustubh.raste]

From: Kaustubh Raste 

Use mask buffer.

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/hevcdsp_msa.c |  541 -
 1 file changed, 312 insertions(+), 229 deletions(-)

diff --git a/libavcodec/mips/hevcdsp_msa.c b/libavcodec/mips/hevcdsp_msa.c
index b17127c..81db62b 100644
--- a/libavcodec/mips/hevcdsp_msa.c
+++ b/libavcodec/mips/hevcdsp_msa.c
@@ -456,7 +456,7 @@ static void hevc_hz_8t_4w_msa(uint8_t *src, int32_t 
src_stride,
 v16i8 vec0, vec1, vec2, vec3;
 v8i16 dst0, dst1, dst2, dst3;
 v8i16 filter_vec, const_vec;
-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);
 
 src -= 3;
 const_vec = __msa_ldi_h(128);
@@ -511,7 +511,7 @@ static void hevc_hz_8t_8w_msa(uint8_t *src, int32_t 
src_stride,
 v16i8 vec0, vec1, vec2, vec3;
 v8i16 dst0, dst1, dst2, dst3;
 v8i16 filter_vec, const_vec;
-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);
 
 src -= 3;
 const_vec = __msa_ldi_h(128);
@@ -559,8 +559,75 @@ static void hevc_hz_8t_12w_msa(uint8_t *src, int32_t 
src_stride,
int16_t *dst, int32_t dst_stride,
const int8_t *filter, int32_t height)
 {
-hevc_hz_8t_8w_msa(src, src_stride, dst, dst_stride, filter, height);
-hevc_hz_8t_4w_msa(src + 8, src_stride, dst + 8, dst_stride, filter, 
height);
+uint32_t loop_cnt;
+int64_t res0, res1, res2, res3;
+v16i8 src0, src1, src2, src3, src4, src5, src6, src7;
+v16i8 mask0, mask1, mask2, mask3, mask4, mask5, mask6, mask7;
+v16i8 vec0, vec1, vec2, vec3, vec4, vec5;
+v8i16 filt0, filt1, filt2, filt3, dst0, dst1, dst2, dst3, dst4, dst5;
+v8i16 filter_vec, const_vec;
+
+src -= 3;
+const_vec = __msa_ldi_h(128);
+const_vec <<= 6;
+
+filter_vec = LD_SH(filter);
+SPLATI_H4_SH(filter_vec, 0, 1, 2, 3, filt0, filt1, filt2, filt3);
+
+mask0 = LD_SB(ff_hevc_mask_arr);
+mask1 = mask0 + 2;
+mask2 = mask0 + 4;
+mask3 = mask0 + 6;
+mask4 = LD_SB(ff_hevc_mask_arr + 16);
+mask5 = mask4 + 2;
+mask6 = mask4 + 4;
+mask7 = mask4 + 6;
+
+for (loop_cnt = 4; loop_cnt--;) {
+LD_SB4(src, src_stride, src0, src1, src2, src3);
+LD_SB4(src + 8, src_stride, src4, src5, src6, src7);
+src += (4 * src_stride);
+XORI_B8_128_SB(src0, src1, src2, src3, src4, src5, src6, src7);
+
+dst0 = const_vec;
+dst1 = const_vec;
+dst2 = const_vec;
+dst3 = const_vec;
+dst4 = const_vec;
+dst5 = const_vec;
+VSHF_B2_SB(src0, src0, src1, src1, mask0, mask0, vec0, vec1);
+VSHF_B2_SB(src2, src2, src3, src3, mask0, mask0, vec2, vec3);
+VSHF_B2_SB(src4, src5, src6, src7, mask4, mask4, vec4, vec5);
+DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt0, filt0, filt0, filt0, dst0,
+ dst1, dst2, dst3);
+DPADD_SB2_SH(vec4, vec5, filt0, filt0, dst4, dst5);
+VSHF_B2_SB(src0, src0, src1, src1, mask1, mask1, vec0, vec1);
+VSHF_B2_SB(src2, src2, src3, src3, mask1, mask1, vec2, vec3);
+VSHF_B2_SB(src4, src5, src6, src7, mask5, mask5, vec4, vec5);
+DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt1, filt1, filt1, filt1, dst0,
+ dst1, dst2, dst3);
+DPADD_SB2_SH(vec4, vec5, filt1, filt1, dst4, dst5);
+VSHF_B2_SB(src0, src0, src1, src1, mask2, mask2, vec0, vec1);
+VSHF_B2_SB(src2, src2, src3, src3, mask2, mask2, vec2, vec3);
+VSHF_B2_SB(src4, src5, src6, src7, mask6, mask6, vec4, vec5);
+DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt2, filt2, filt2, filt2, dst0,
+ dst1, dst2, dst3);
+DPADD_SB2_SH(vec4, vec5, filt2, filt2, dst4, dst5);
+VSHF_B2_SB(src0, src0, src1, src1, mask3, mask3, vec0, vec1);
+VSHF_B2_SB(src2, src2, src3, src3, mask3, mask3, vec2, vec3);
+VSHF_B2_SB(src4, src5, src6, src7, mask7, mask7, vec4, vec5);
+DPADD_SB4_SH(vec0, vec1, vec2, vec3, filt3, filt3, filt3, filt3, dst0,
+ dst1, dst2, dst3);
+DPADD_SB2_SH(vec4, vec5, filt3, filt3, dst4, dst5);
+
+res0 = __msa_copy_s_d((v2i64) dst4, 0);
+res1 = __msa_copy_s_d((v2i64) dst4, 1);
+res2 = __msa_copy_s_d((v2i64) dst5, 0);
+res3 = __msa_copy_s_d((v2i64) dst5, 1);
+ST_SH4(dst0, dst1, dst2, dst3, dst, dst_stride);
+SD4(res0, res1, res2, res3, (dst + 8), dst_stride);
+dst += (4 * dst_stride);
+}
 }
 
 static void hevc_hz_8t_16w_msa(uint8_t *src, int32_t src_stride,
@@ -568,13 +635,13 @@ static void hevc_hz_8t_16w_msa(uint8_t *src, int32_t 
src_stride,
const int8_t *filter, int32_t height)
 {
 uint32_t loop_cnt;
-v16i8 src0, src1, src2, src3, src4, src5, src6, src7;
+v16i8 

Re: [FFmpeg-devel] [FFmpeg-cvslog] aacenc: support extended channel layouts using PCEs

[Rostislav Pehlivanov]

On 9 November 2017 at 09:37, Kv Pham  wrote:

> Le 9 nov. 2017 10:12 AM, "Nicolas George"  a écrit :
>
> Le nonidi 19 brumaire, an CCXXVI, Rostislav Pehlivanov a écrit :
> > ffmpeg | branch: master | Rostislav Pehlivanov  |
> Mon Oct  3 19:53:11 2016 +0100| [fbf295e2bd4d48d7a0a094ed5afce2fa5b6cf35a]
> | committer: Rostislav Pehlivanov
> >
> > aacenc: support extended channel layouts using PCEs
> >
> > This commit implements support for PCE (Program Configuration Elements)
> in the
> > AAC encoder, and as such allows for encoding of channel layouts not
> present
> > in the presets defined by the spec (which only lists the 8 most common
> ones).
> >
> > This has been a highly requested feature and is also the first open
> source encoder
> > to support this many layouts.
> >
> > Many thanks to pkviet  who implemented support for
> and
> > verified all channel layouts.
>
> This broke fate-aac-yoraw-encode.
>
> stddev:  160.76 PSNR: 52.21 MAXDIFF: 3105 bytes:   576972/   577536
> stddev: |160.76 - 259| >= 17
>
>
> Regards,
>
> --
>   Nicolas George
>
>
> Thanks a lot.
> That's probably related to the fixes that I pointed out in my last message
> on the thread.
> I'll run fate later today on my aacdev branch on github
> github.com/pkviet/FFmpeg to check that this fixes the issues.
> (amusant de croiser un autre archicube; moi, s92. Les échanges sont parfois
> vraiment musclés ici, il ne faut pas être susceptible ! :) )
> Regards,
> pkv
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Correct, the fix for 5.1/.0 also fixed this test.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/pngdec: fix av_bprint_finalize() usage.

[Rostislav Pehlivanov]

On 9 November 2017 at 08:49, Nicolas George  wrote:

> Signed-off-by: Nicolas George 
> ---
>  libavcodec/pngdec.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index 20707f0ae5..1d72f9542a 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -524,9 +524,9 @@ static int decode_text_chunk(PNGDecContext *s,
> uint32_t length, int compressed,
>  if ((ret = decode_zbuf(, data, data_end)) < 0)
>  return ret;
>  text_len = bp.len;
> -av_bprint_finalize(, (char **));
> -if (!text)
> -return AVERROR(ENOMEM);
> +ret = av_bprint_finalize(, (char **));
> +if (ret < 0)
> +return ret;
>  } else {
>  text = (uint8_t *)data;
>  text_len = data_end - text;
> @@ -862,9 +862,9 @@ static int decode_iccp_chunk(PNGDecContext *s, int
> length, AVFrame *f)
>  if ((ret = decode_zbuf(, s->gb.buffer, s->gb.buffer + length)) < 0)
>  return ret;
>
> -av_bprint_finalize(, (char **));
> -if (!data)
> -return AVERROR(ENOMEM);
> +ret = av_bprint_finalize(, (char **));
> +if (ret < 0)
> +return ret;
>
>  sd = av_frame_new_side_data(f, AV_FRAME_DATA_ICC_PROFILE, bp.len);
>  if (!sd) {
> @@ -1317,9 +1317,9 @@ static int decode_frame_common(AVCodecContext
> *avctx, PNGDecContext *s,
>
>  av_bprint_init(, 0, -1);
>  av_bprintf(, "%i/%i", num, 10);
> -av_bprint_finalize(, _str);
> -if (!gamma_str)
> -return AVERROR(ENOMEM);
> +ret = av_bprint_finalize(, _str);
> +if (ret < 0)
> +return ret;
>
>  av_dict_set(>metadata, "gamma", gamma_str,
> AV_DICT_DONT_STRDUP_VAL);
>
> --
> 2.14.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


Its not really a fix since bprint can't return non-ENOMEM. All were copied
from one place in the code.
Aside from that LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] aptx: implement the aptX bluetooth codec

[Aurelien Jacobs]

On Thu, Nov 09, 2017 at 12:52:34AM +, Rostislav Pehlivanov wrote:
> On 8 November 2017 at 22:41, Aurelien Jacobs  wrote:
> 
> > On Wed, Nov 08, 2017 at 06:26:03PM +0100, Michael Niedermayer wrote:
> > > On Wed, Nov 08, 2017 at 02:06:09PM +0100, Aurelien Jacobs wrote:
> > > [...]
> > > > +}
> > > > +
> > > > +/*
> > > > + * Compute the convolution of the signal with the coefficients, and
> > reduce
> > > > + * to 24 bits by applying the specified right shifting.
> > > > + */
> > > > +av_always_inline
> > > > +static int32_t aptx_qmf_convolution(FilterSignal *signal,
> > > > +const int32_t coeffs[FILTER_TAPS],
> > > > +int shift)
> > > > +{
> > > > +int32_t *sig = >buffer[signal->pos];
> > > > +int64_t e = 0;
> > > > +
> > >
> > > > +for (int i = 0; i < FILTER_TAPS; i++)
> > >
> > > "for (int" is something we avoided as some comilers didnt like it,
> > > iam not sure if this is still true but there are none in the codebase
> >
> > If you insist on this I will of course change it, but hey, we require
> > a C99 compiler since a long time and we use so many features of C99
> > that I really don't get why we couldn't use "for (int".
> > I can't imagine that any relevant C compiler would not support this
> > nowadays !
> > What I propose is to get this in as is, and see if anyone encounter
> > issue with any compiler. If any issue arise, I will of course send a
> > patch to fix it.
> >
> > Here is an updated patch.
> >
> >
> Send another patch because some people are beyond convincing and its really
> pissing me off. Really. In particular maybe those compiler writers at
> Microsoft who seem to think shipping something that doesn't support such a
> simple yet important feature is important.
> Or maybe users who don't want to update a 6 year old version of msvc.
> Or maybe us because we support compiling with msvc at all when its clearly
> _not_ a C compiler and this project is written in C.

Here you go.

Just for reference, splitting the déclaration out of the for loop added
19 lines in this file, which is a 2.3 % increase of the line count.
(I'm not sure this file is representative of the rest of the code base)
>From a0c78c471247847b841eff631f6d3a4a7db868d9 Mon Sep 17 00:00:00 2001
From: Aurelien Jacobs 
Date: Thu, 31 Aug 2017 20:12:54 +0200
Subject: [PATCH 1/2] aptx: implement the aptX bluetooth codec

The encoder was reverse engineered from binary library and from
EP0398973B1 patent (long expired).
The decoder was simply deduced from the encoder.
---
 doc/general.texi|   2 +
 libavcodec/Makefile |   2 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/aptx.c   | 845 
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 +
 6 files changed, 858 insertions(+)
 create mode 100644 libavcodec/aptx.c

diff --git a/doc/general.texi b/doc/general.texi
index e6ae277d23..de4efee913 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -993,6 +993,8 @@ following image formats are supported:
 @item Amazing Studio PAF Audio @tab @tab  X
 @item Apple lossless audio   @tab  X  @tab  X
 @tab QuickTime fourcc 'alac'
+@item aptX   @tab  X  @tab  X
+@tab Used in Bluetooth A2DP
 @item ATRAC1 @tab @tab  X
 @item ATRAC3 @tab @tab  X
 @item ATRAC3+@tab @tab  X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 45f4db5939..95c843dee7 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -188,6 +188,8 @@ OBJS-$(CONFIG_AMV_ENCODER) += mjpegenc.o mjpegenc_common.o \
 OBJS-$(CONFIG_ANM_DECODER) += anm.o
 OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o cga_data.o
 OBJS-$(CONFIG_APE_DECODER) += apedec.o
+OBJS-$(CONFIG_APTX_DECODER)+= aptx.o
+OBJS-$(CONFIG_APTX_ENCODER)+= aptx.o
 OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
 OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
 OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d96e499ba7..463f7ed64e 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -406,6 +406,7 @@ static void register_all(void)
 REGISTER_DECODER(AMRNB, amrnb);
 REGISTER_DECODER(AMRWB, amrwb);
 REGISTER_DECODER(APE,   ape);
+REGISTER_ENCDEC (APTX,  aptx);
 REGISTER_DECODER(ATRAC1,atrac1);
 REGISTER_DECODER(ATRAC3,atrac3);
 REGISTER_DECODER(ATRAC3AL,  atrac3al);
diff --git a/libavcodec/aptx.c b/libavcodec/aptx.c
new file mode 100644
index 00..32e0d01dcf
--- /dev/null
+++ b/libavcodec/aptx.c
@@ -0,0 +1,845 @@
+/*
+ * Audio Processing Technology codec for Bluetooth (aptX)
+ *
+ * Copyright (C) 2017  Aurelien Jacobs 
+ *
+ * 

Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode

[Derek Buitenhuis]

On 11/9/2017 12:21 PM, James Cowgill wrote:
> +if (avci->draining_done && pkt && pkt->size != 0) {
> +av_log(avctx, AV_LOG_WARNING, "Got unexpected packet after EOF\n");
> +avcodec_flush_buffers(avctx);
> +}

Is it more sensible to actually return an error here? Otherwise it's just 
enabling
future incorrect code; API users tend to ignore stderr warnings. I guess an 
argument
could be made both ways.

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

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

[Rostislav Pehlivanov]

On 9 November 2017 at 08:01, pkv.stream  wrote:

> Le 09/11/2017 à 4:43 AM, Rostislav Pehlivanov a écrit :
>
>> On 18 October 2017 at 11:05, pkv.stream  wrote:
>>
>> Le 02/10/2017 à 8:39 PM, Rostislav Pehlivanov a écrit :
>>>
>>> On 2 October 2017 at 18:43, pkv.stream  wrote:

 Le 02/10/2017 à 7:23 PM, Michael Niedermayer a écrit :

> On Mon, Oct 02, 2017 at 12:52:53AM +0200, pkv.stream wrote:
>
>> 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

 aacenc.h |  239 ++

>>> +++--
>>> 1 file changed, 233 insertions(+), 6 deletions(-)
>>> 929275fe34af4d0048bac2be928957288cb75ddd
>>> 0001-avcodec-aacenc-PCE-for-al
>>> l-ffmpeg-usual-layouts.patch
>>>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
>>>
>>> this seems not to apply cleanly here, did i miss something ?
>>>
>> Hi Michael
>>
> this needs to be applied after the initial patch by atomnuker which he
> did
> not apply since this required work.
> What i submitted was not aimed at being pushed since there is probably
> still work to do.
> Depending on what he wants to do with his patch, I'll resubmit a
> working
> patch later, properly rebased.
> Sorry about the mess.
> regards
>
>
> Applying: avcodec/aacenc: PCE for all ffmpeg usual layouts
>
>> error: sha1 information is lacking or useless (libavcodec/aacenc.h).
>> error: could not build fake ancestor
>> Patch failed at 0001 avcodec/aacenc: PCE for all ffmpeg usual layouts
>> The copy of the patch that failed is found in: .git/rebase-apply/patch
>>
>>
>> [...]
>>
>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
>> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
> Give me a few hours and I'll test it and submit a v2 of my patch with
 your
 improvements.
 ___
 ffmpeg-devel mailing list
 ffmpeg-devel@ffmpeg.org
 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

 Hi
>>>
>>> any updates ?
>>>
>>> regards
>>>
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>>
>> Hi,
>> Very sorry it took me this long but I finally got motivated and got around
>> to checking your patch
>>
>> I have to say I'm impressed, everything works perfectly, decodes fine and
>> the mappings were all fine. This is a big feature which many people have
>> requested and complained the encoder lacks support for.
>>
>> I've done some minor changes to the code on the encoder side (an INFO
>> print
>> instead of a warning), to the comments (just alignment) and for the
>> ambisonic layouts (made them use the defines) and I've pushed it.
>>
>> Thanks a lot
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Hi atomnuker,
>
> that's wonderful;
>
> there are two things also:
>
> 1) there are changes to make to the list of channel layouts not requiring
> PCE
>
> ==> AV_CH_LAYOUT_5POINT0 to AV_CH_LAYOUT_5POINT0_BACK since the previous
> is 5.0(side) while the latter is 5.0 which is what is in spec (table 1.19
> ISO/IEC 14496-3:200X(E) or table 42 ISO/IEC 13818-7:2004(E) )
>
> see patch in attachment (can't be applied directly due to rebasing issues
> from your initial patch)
>
>
Checked the spec, you're right, fixed.



> 2) for everything to work I had to also apply the patch from here:
>
> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/217357.html
>
> If you ffmpeg -loglevel debug , you will see that on non-default channel
> 

Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode

[Hendrik Leppkes]

On Thu, Nov 9, 2017 at 1:21 PM, James Cowgill  wrote:
> In commit 061a0c14bb57 ("decode: restructure the core decoding code"), the
> deprecated avcodec_decode_* APIs were reworked so that they called into the
> new avcodec_send_packet / avcodec_receive_frame API. This had the side effect
> of prohibiting sending new packets containing data after a drain
> packet, but in previous versions of FFmpeg this "worked" and some
> applications relied on it.
>
> To restore some compatibility, reset the codec if we receive a new non-drain
> packet using the old API after draining has completed. While this does
> not give the same behaviour as the old API did, in the majority of cases
> it works and it does not require changes to any other part of the decoding
> code.
>
> Fixes ticket #6775
> Signed-off-by: James Cowgill 
> ---
>  libavcodec/decode.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 86fe5aef52..2f1932fa85 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -726,6 +726,11 @@ static int compat_decode(AVCodecContext *avctx, AVFrame 
> *frame,
>
>  av_assert0(avci->compat_decode_consumed == 0);
>
> +if (avci->draining_done && pkt && pkt->size != 0) {
> +av_log(avctx, AV_LOG_WARNING, "Got unexpected packet after EOF\n");
> +avcodec_flush_buffers(avctx);
> +}
> +

I don't think this is a good idea. Draining and not flushing
afterwards is a bug in the calling code, and even before recent
changes it would result in inconsistent behavior and even crashes
(with select decoders).

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

Re: [FFmpeg-devel] [PATCH] lavc/pngdec: fix av_bprint_finalize() usage.

[Rostislav Pehlivanov]

On 9 November 2017 at 13:15, Nicolas George  wrote:

> Le nonidi 19 brumaire, an CCXXVI, Rostislav Pehlivanov a écrit :
> > Its not really a fix since bprint can't return non-ENOMEM. All were
> copied
>
> For now, and only because you looked at the code. But the current code
> does not follow the documentation, so it is really a fix.
>
>
That type of fix is called a correction.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] aptx: implement the aptX bluetooth codec

[Rostislav Pehlivanov]

On 9 November 2017 at 13:37, Aurelien Jacobs  wrote:

> On Thu, Nov 09, 2017 at 12:52:34AM +, Rostislav Pehlivanov wrote:
> > On 8 November 2017 at 22:41, Aurelien Jacobs  wrote:
> >
> > > On Wed, Nov 08, 2017 at 06:26:03PM +0100, Michael Niedermayer wrote:
> > > > On Wed, Nov 08, 2017 at 02:06:09PM +0100, Aurelien Jacobs wrote:
> > > > [...]
> > > > > +}
> > > > > +
> > > > > +/*
> > > > > + * Compute the convolution of the signal with the coefficients,
> and
> > > reduce
> > > > > + * to 24 bits by applying the specified right shifting.
> > > > > + */
> > > > > +av_always_inline
> > > > > +static int32_t aptx_qmf_convolution(FilterSignal *signal,
> > > > > +const int32_t
> coeffs[FILTER_TAPS],
> > > > > +int shift)
> > > > > +{
> > > > > +int32_t *sig = >buffer[signal->pos];
> > > > > +int64_t e = 0;
> > > > > +
> > > >
> > > > > +for (int i = 0; i < FILTER_TAPS; i++)
> > > >
> > > > "for (int" is something we avoided as some comilers didnt like it,
> > > > iam not sure if this is still true but there are none in the codebase
> > >
> > > If you insist on this I will of course change it, but hey, we require
> > > a C99 compiler since a long time and we use so many features of C99
> > > that I really don't get why we couldn't use "for (int".
> > > I can't imagine that any relevant C compiler would not support this
> > > nowadays !
> > > What I propose is to get this in as is, and see if anyone encounter
> > > issue with any compiler. If any issue arise, I will of course send a
> > > patch to fix it.
> > >
> > > Here is an updated patch.
> > >
> > >
> > Send another patch because some people are beyond convincing and its
> really
> > pissing me off. Really. In particular maybe those compiler writers at
> > Microsoft who seem to think shipping something that doesn't support such
> a
> > simple yet important feature is important.
> > Or maybe users who don't want to update a 6 year old version of msvc.
> > Or maybe us because we support compiling with msvc at all when its
> clearly
> > _not_ a C compiler and this project is written in C.
>
> Here you go.
>
> Just for reference, splitting the déclaration out of the for loop added
> 19 lines in this file, which is a 2.3 % increase of the line count.
> (I'm not sure this file is representative of the rest of the code base)
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Still some issues:

1.) You need to set AVCodec->supported_samplerates for the encoder, since
in the raw aptx muxer you always set the samplerate as 44100. Does the
codec/container support other samplerates?

2.) "Frame must have a multiple of 4 samples" gets printed out when trying
to resample a 48000 file and encode it to aptx.
What you need to do is to remove AV_CODEC_CAP_VARIABLE_FRAME_SIZE from the
capabilities and set some sane default for avctx->frame_size if
avctx->frame_size is unset. Users can override it prior to encoder init and
you can do it through the command line using -frame_size. If the user sets
the frame_size, check if its a multiple of 4 and use it. Else, error out.
If it isn't set (e.g. its 0), use the default (1024 is a good value).

3.) The packet timestamps on the encoder side are missing. Use the
AudioFrameQueue API (libavcodec/audio_frame_queue.h) which at every frame
counts how many samples you're given via the avframe and calculates what
dts/pts to set on the avpacket.
Just call ff_af_queue_init at the end of your init function (after the
frame size is set and checked), call ff_af_queue_add at the start of your
encode function and ff_af_queue_remove with the number of samples you
encoded and pointers to the packet pts/duration fields. And make sure to
call ff_af_queue_close on uninit, which will print out an error if you've
encoded more samples than you've received or less samples than you've
recevied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/pngdec: fix av_bprint_finalize() usage.

[Derek Buitenhuis]

On 11/9/2017 1:23 PM, Rostislav Pehlivanov wrote:
>> For now, and only because you looked at the code. But the current code
>> does not follow the documentation, so it is really a fix.
>>
>>
> That type of fix is called a correction.

It's a fix. Relying on internal implementation knowledge is a bug and wrong.

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

Re: [FFmpeg-devel] [PATCH] lavc/pngdec: fix av_bprint_finalize() usage.

[Nicolas George]

Le nonidi 19 brumaire, an CCXXVI, Rostislav Pehlivanov a écrit :
> Its not really a fix since bprint can't return non-ENOMEM. All were copied

For now, and only because you looked at the code. But the current code
does not follow the documentation, so it is really a fix.

> from one place in the code.

Which was my fault, no doubt about that.

> Aside from that LGTM

Pushed, thanks.

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 1/2] aptx: implement the aptX bluetooth codec

[James Almer]

On 11/9/2017 10:37 AM, Aurelien Jacobs wrote:
> On Thu, Nov 09, 2017 at 12:52:34AM +, Rostislav Pehlivanov wrote:
>> On 8 November 2017 at 22:41, Aurelien Jacobs  wrote:
>>
>>> On Wed, Nov 08, 2017 at 06:26:03PM +0100, Michael Niedermayer wrote:
 On Wed, Nov 08, 2017 at 02:06:09PM +0100, Aurelien Jacobs wrote:
 [...]
> +}
> +
> +/*
> + * Compute the convolution of the signal with the coefficients, and
>>> reduce
> + * to 24 bits by applying the specified right shifting.
> + */
> +av_always_inline
> +static int32_t aptx_qmf_convolution(FilterSignal *signal,
> +const int32_t coeffs[FILTER_TAPS],
> +int shift)
> +{
> +int32_t *sig = >buffer[signal->pos];
> +int64_t e = 0;
> +

> +for (int i = 0; i < FILTER_TAPS; i++)

 "for (int" is something we avoided as some comilers didnt like it,
 iam not sure if this is still true but there are none in the codebase
>>>
>>> If you insist on this I will of course change it, but hey, we require
>>> a C99 compiler since a long time and we use so many features of C99
>>> that I really don't get why we couldn't use "for (int".
>>> I can't imagine that any relevant C compiler would not support this
>>> nowadays !
>>> What I propose is to get this in as is, and see if anyone encounter
>>> issue with any compiler. If any issue arise, I will of course send a
>>> patch to fix it.
>>>
>>> Here is an updated patch.
>>>
>>>
>> Send another patch because some people are beyond convincing and its really
>> pissing me off. Really. In particular maybe those compiler writers at
>> Microsoft who seem to think shipping something that doesn't support such a
>> simple yet important feature is important.
>> Or maybe users who don't want to update a 6 year old version of msvc.
>> Or maybe us because we support compiling with msvc at all when its clearly
>> _not_ a C compiler and this project is written in C.
> 
> Here you go.
> 
> Just for reference, splitting the déclaration out of the for loop added
> 19 lines in this file, which is a 2.3 % increase of the line count.
> (I'm not sure this file is representative of the rest of the code base)

If you combine lines like

+int channel;
+int ret;

and

+int pos, channel, sample;
+int ret;

You can reduce that a bit.

Don't send a new patch just for that. Only if there's some other change
requested. Whoever commits this can change it before pushing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavc/libx265: switch to ff_alloc_packet2

[Derek Buitenhuis]

On 11/9/2017 12:39 AM, Jun Zhao wrote:
> From 5afdf252b3bb6f8c7a276c2a8bde8f4a95d170e4 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Wed, 8 Nov 2017 21:04:51 +0800
> Subject: [PATCH 2/2] lavc/libx265: switch to ff_alloc_packet2
> 
> ff_alloc_packet have been deprecated, switch to use
> ff_alloc_packet2.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/libx265.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Should be OK.

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

Re: [FFmpeg-devel] [PATCH] configure: fix the non pkg-config libmfx check

[James Almer]

On 11/9/2017 2:31 PM, James Almer wrote:
> Based on a patch by Aaron Levinson.
> 
> Signed-off-by: James Almer 
> ---
> Untested
> 
>  configure | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index f396abda5b..7dd540bad3 100755
> --- a/configure
> +++ b/configure
> @@ -2772,6 +2772,7 @@ wmv3_vaapi_hwaccel_select="vc1_vaapi_hwaccel"
>  wmv3_vdpau_hwaccel_select="vc1_vdpau_hwaccel"
>  
>  # hardware-accelerated codecs
> +libmfx_suggest="advapi32"

OnN second thought, this line is probably superfluous. The changes to
the require() call below should have the same effect.

>  omx_deps="libdl pthreads"
>  omx_rpi_select="omx"
>  qsv_deps="libmfx"
> @@ -5824,6 +5825,7 @@ check_header asm/types.h
>  # so we also check that atomics actually work here
>  check_builtin stdatomic_h stdatomic.h "atomic_int foo, bar = 
> ATOMIC_VAR_INIT(-1); atomic_store(, 0)"
>  
> +check_lib advapi32 "windows.h"RegQueryInfoKey  -ladvapi32
>  check_lib ole32"windows.h"CoTaskMemFree-lole32
>  check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
>  check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
> @@ -5981,7 +5983,7 @@ enabled libkvazaar&& require_pkg_config 
> libkvazaar "kvazaar >= 0.8.1" kv
>  # pkg-config support.  Instead, users should make sure that the build
>  # can find the libraries and headers through other means.
>  enabled libmfx&& { use_pkg_config libmfx libmfx "mfx/mfxvideo.h" 
> MFXInit ||
> -   { require libmfx "mfx/mfxvideo.h" MFXInit 
> -llibmfx && warn "using libmfx without pkg-config"; } }
> +   { require libmfx "mfx/mfxvideo.h" MFXInit 
> "-llibmfx $advapi32_extralibs" && warn "using libmfx without pkg-config"; } }
>  enabled libmodplug&& require_pkg_config libmodplug libmodplug 
> libmodplug/modplug.h ModPlug_Load
>  enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h 
> lame_set_VBR_quality -lmp3lame
>  enabled libmysofa && require libmysofa "mysofa.h" mysofa_load 
> -lmysofa $zlib_extralibs
> 

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

[FFmpeg-devel] [PATCH] configure: fix the non pkg-config libmfx check

[James Almer]

Based on a patch by Aaron Levinson.

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

 configure | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index f396abda5b..7dd540bad3 100755
--- a/configure
+++ b/configure
@@ -2772,6 +2772,7 @@ wmv3_vaapi_hwaccel_select="vc1_vaapi_hwaccel"
 wmv3_vdpau_hwaccel_select="vc1_vdpau_hwaccel"
 
 # hardware-accelerated codecs
+libmfx_suggest="advapi32"
 omx_deps="libdl pthreads"
 omx_rpi_select="omx"
 qsv_deps="libmfx"
@@ -5824,6 +5825,7 @@ check_header asm/types.h
 # so we also check that atomics actually work here
 check_builtin stdatomic_h stdatomic.h "atomic_int foo, bar = 
ATOMIC_VAR_INIT(-1); atomic_store(, 0)"
 
+check_lib advapi32 "windows.h"RegQueryInfoKey  -ladvapi32
 check_lib ole32"windows.h"CoTaskMemFree-lole32
 check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
 check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
@@ -5981,7 +5983,7 @@ enabled libkvazaar&& require_pkg_config 
libkvazaar "kvazaar >= 0.8.1" kv
 # pkg-config support.  Instead, users should make sure that the build
 # can find the libraries and headers through other means.
 enabled libmfx&& { use_pkg_config libmfx libmfx "mfx/mfxvideo.h" 
MFXInit ||
-   { require libmfx "mfx/mfxvideo.h" MFXInit 
-llibmfx && warn "using libmfx without pkg-config"; } }
+   { require libmfx "mfx/mfxvideo.h" MFXInit 
"-llibmfx $advapi32_extralibs" && warn "using libmfx without pkg-config"; } }
 enabled libmodplug&& require_pkg_config libmodplug libmodplug 
libmodplug/modplug.h ModPlug_Load
 enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h 
lame_set_VBR_quality -lmp3lame
 enabled libmysofa && require libmysofa "mysofa.h" mysofa_load -lmysofa 
$zlib_extralibs
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode

[James Cowgill]

Hi,

On 09/11/17 14:02, Hendrik Leppkes wrote:
> On Thu, Nov 9, 2017 at 1:21 PM, James Cowgill  wrote:
>> In commit 061a0c14bb57 ("decode: restructure the core decoding code"), the
>> deprecated avcodec_decode_* APIs were reworked so that they called into the
>> new avcodec_send_packet / avcodec_receive_frame API. This had the side effect
>> of prohibiting sending new packets containing data after a drain
>> packet, but in previous versions of FFmpeg this "worked" and some
>> applications relied on it.
>>
>> To restore some compatibility, reset the codec if we receive a new non-drain
>> packet using the old API after draining has completed. While this does
>> not give the same behaviour as the old API did, in the majority of cases
>> it works and it does not require changes to any other part of the decoding
>> code.
>>
>> Fixes ticket #6775
>> Signed-off-by: James Cowgill 
>> ---
>>  libavcodec/decode.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>> index 86fe5aef52..2f1932fa85 100644
>> --- a/libavcodec/decode.c
>> +++ b/libavcodec/decode.c
>> @@ -726,6 +726,11 @@ static int compat_decode(AVCodecContext *avctx, AVFrame 
>> *frame,
>>
>>  av_assert0(avci->compat_decode_consumed == 0);
>>
>> +if (avci->draining_done && pkt && pkt->size != 0) {
>> +av_log(avctx, AV_LOG_WARNING, "Got unexpected packet after EOF\n");
>> +avcodec_flush_buffers(avctx);
>> +}
>> +
> 
> I don't think this is a good idea. Draining and not flushing
> afterwards is a bug in the calling code, and even before recent
> changes it would result in inconsistent behavior and even crashes
> (with select decoders).

I am fully aware that this will only trigger if the calling code is
buggy. I am trying to avoid silent breakage of those applications doing
this when upgrading to ffmpeg 3.4.

I was looking at the documentation of avcodec_decode_* recently because
of this and I had some trouble deciding if using the API this way was
incorrect. I expect the downstreams affected thought that what they were
doing was fine and then got angry when ffmpeg suddenly "broke" their
code. This patch at least allows some sort of "transitional period"
until downstreams update.

From the perspective of Debian, I could either apply this patch to
ffmpeg, or I would have to go through over 100 reverse dependencies to
see if they abuse the API and then fix them. I currently know of two
(gst-libav1.0 and kodi), but there could be more - especially within
less used packages.

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

Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[Clément Bœsch]

On Wed, Nov 08, 2017 at 09:26:13PM +, Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  doc/developer.texi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index a7b4f1d737..de7d887451 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -132,6 +132,9 @@ designated struct initializers (@samp{struct s x = @{ .i 
> = 17 @};});
>  @item
>  compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
>  
> +@item
> +for loops with variable definition (@samp{for (int i = 0; i < 8; i++)});
> +

I'm fine with this and would be happy to update all the code I maintain in
FFmpeg to follow this pattern. But I have a few questions/reservations:

- what does it imply for mixed statements and declarations?

  If we still do not allow them, how are you going to make the compiler
  reject them but not the for (int ... ) form?

  Also, allowing this but not the mixed statements and declarations means
  this is a style decision and not a technical one anymore.

- are we going to accept all kind of patches to change the coding style
  all over the codebase?

- this require a Changelog entry as it has a technical impact (which could
  be considered negligible).

Overall, I'd enjoy this change being accepted (even along mixed statements
and declarations).

[...]

-- 
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 10/11] avcodec/blockdsp: add AVX-512 version of clear_block(s)

[Martin Vignali]

2017-11-09 12:58 GMT+01:00 James Darnley :

> From: James Darnley 
>
> Also adjust alignment requirements where nessecary.
> ---
> Whether this patch is committed or not the change to 4xm.c should be
> picked to
> master because the alignment is wrong for the AVX version of this
> function.  I
> assume it hasn't been noticed yet because it manages to be 32-byte aligned
> without intervention.
>
>
Thanks for fixing, the 4xm, i miss it in the avx patch

Just by curiosity : can you post the checkasm result (i can't test AVX512) ?

lgtm

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

Re: [FFmpeg-devel] [DEVEL][PATCH] ffmpeg: fix channel_layout bug on non-default layout

[Michael Niedermayer]

On Thu, Oct 05, 2017 at 12:37:13AM +0200, pkv.stream wrote:
> Le 04/10/2017 à 11:18 PM, Moritz Barsnick a écrit :
> >On Mon, Oct 02, 2017 at 21:50:50 +0200, pkv.stream wrote:
> >>  if (!ost->stream_copy) {
> >>-char *sample_fmt = NULL;
> >>+
> >>+   char *sample_fmt = NULL;
> >This is very obviously a patch which will not be accepted.
> >
> >
> >>-MATCH_PER_STREAM_OPT(sample_fmts, str, sample_fmt, oc, st);
> >>+   AVDictionaryEntry *output_layout = 
> >>av_dict_get(o->g->codec_opts, "channel_layout",NULL, AV_DICT_MATCH_CASE);
> >>+if (output_layout)
> >>+ost->enc_ctx->channel_layout = strtoull(output_layout->value, 
> >>NULL, 10);
> >>+
> >>+   MATCH_PER_STREAM_OPT(sample_fmts, str, sample_fmt, oc, st);
> >Your indentation is totally wrong, and makes use of tabs. Please follow
> >the ffmpeg style.
> 
> styling fixed
> thanks for your input
> 
> 

>  ffmpeg_opt.c |   11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 2af07f4366efdfaf1018bb2ea29be672befe0823  
> 0001-ffmpeg-fix-channel_layout-bug-on-non-default-layout.patch
> From 4ec55dc88923108132307b41300a1abddf32e6f7 Mon Sep 17 00:00:00 2001
> From: pkviet 
> Date: Mon, 2 Oct 2017 11:14:31 +0200
> Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout
> 
> Fix for ticket 6706.
> The -channel_layout option was not working when the channel layout was not
> a default one (ex: for 4 channels, quad was interpreted as 4.0 which is
> the default layout for 4 channels; or octagonal interpreted as 7.1).
> This led to the spurious auto-insertion of an auto-resampler filter
> remapping the channels even if input and output had identical channel
> layouts.
> The fix operates by directly calling the channel layout if defined in
> options. If the layout is undefined, the default layout is selected as
> before the fix.
> ---
>  ffmpeg_opt.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> index 100fa76..cf5a63c 100644
> --- a/ffmpeg_opt.c
> +++ b/ffmpeg_opt.c
> @@ -1804,6 +1804,12 @@ static OutputStream *new_audio_stream(OptionsContext 
> *o, AVFormatContext *oc, in
>  
>  MATCH_PER_STREAM_OPT(audio_channels, i, audio_enc->channels, oc, st);
>  
> +AVDictionaryEntry *output_layout = av_dict_get(o->g->codec_opts,
> +   "channel_layout",
> +   NULL, 
> AV_DICT_MATCH_CASE);

This doesnt look right

not an issue of the patch as such but
why is the channel_layout option per file and not per stream?

also currently mixed statemts and declarations arent allowed


> +if (output_layout)
> +ost->enc_ctx->channel_layout = strtoull(output_layout->value, 
> NULL, 10);

audio_enc


> +
>  MATCH_PER_STREAM_OPT(sample_fmts, str, sample_fmt, oc, st);
>  if (sample_fmt &&
>  (audio_enc->sample_fmt = av_get_sample_fmt(sample_fmt)) == 
> AV_SAMPLE_FMT_NONE) {
> @@ -2524,7 +2530,10 @@ loop_end:
> (count + 1) * sizeof(*f->sample_rates));
>  }
>  if (ost->enc_ctx->channels) {
> -f->channel_layout = 
> av_get_default_channel_layout(ost->enc_ctx->channels);

> +if (ost->enc_ctx->channel_layout)
> +f->channel_layout = ost->enc_ctx->channel_layout;
> +else
> +f->channel_layout = 
> av_get_default_channel_layout(ost->enc_ctx->channels);

if () {
} else

is better as tat way future patches do not need to change existing
lines maing patches more readable if ever a line is added

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] configure: fix the non pkg-config libmfx check

[James Almer]

On 11/9/2017 2:51 PM, James Almer wrote:
> On 11/9/2017 2:31 PM, James Almer wrote:
>> Based on a patch by Aaron Levinson.
>>
>> Signed-off-by: James Almer 
>> ---
>> Untested
>>
>>  configure | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index f396abda5b..7dd540bad3 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2772,6 +2772,7 @@ wmv3_vaapi_hwaccel_select="vc1_vaapi_hwaccel"
>>  wmv3_vdpau_hwaccel_select="vc1_vdpau_hwaccel"
>>  
>>  # hardware-accelerated codecs
>> +libmfx_suggest="advapi32"
> 
> OnN second thought, this line is probably superfluous. The changes to
> the require() call below should have the same effect.

Approved on IRC by Aaron Levinson with this line removed, so pushed.

> 
>>  omx_deps="libdl pthreads"
>>  omx_rpi_select="omx"
>>  qsv_deps="libmfx"
>> @@ -5824,6 +5825,7 @@ check_header asm/types.h
>>  # so we also check that atomics actually work here
>>  check_builtin stdatomic_h stdatomic.h "atomic_int foo, bar = 
>> ATOMIC_VAR_INIT(-1); atomic_store(, 0)"
>>  
>> +check_lib advapi32 "windows.h"RegQueryInfoKey  -ladvapi32
>>  check_lib ole32"windows.h"CoTaskMemFree-lole32
>>  check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
>>  check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
>> @@ -5981,7 +5983,7 @@ enabled libkvazaar&& require_pkg_config 
>> libkvazaar "kvazaar >= 0.8.1" kv
>>  # pkg-config support.  Instead, users should make sure that the build
>>  # can find the libraries and headers through other means.
>>  enabled libmfx&& { use_pkg_config libmfx libmfx 
>> "mfx/mfxvideo.h" MFXInit ||
>> -   { require libmfx "mfx/mfxvideo.h" MFXInit 
>> -llibmfx && warn "using libmfx without pkg-config"; } }
>> +   { require libmfx "mfx/mfxvideo.h" MFXInit 
>> "-llibmfx $advapi32_extralibs" && warn "using libmfx without pkg-config"; } }
>>  enabled libmodplug&& require_pkg_config libmodplug libmodplug 
>> libmodplug/modplug.h ModPlug_Load
>>  enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h 
>> lame_set_VBR_quality -lmp3lame
>>  enabled libmysofa && require libmysofa "mysofa.h" mysofa_load 
>> -lmysofa $zlib_extralibs
>>
> 

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

Re: [FFmpeg-devel] [PATCH] Fix missing used attribute for inline assembly variables

[Teresa Johnson]

I implemented this change to add a new macro. I tried to find the variables
used in MANGLE and change those to use the new DECLARE_ASM_ALIGNED, and the
build succeeds with these changes. New changes are in cl/172133815.

Teresa

On Wed, Nov 1, 2017 at 7:25 AM, Teresa Johnson  wrote:

>
>
> On Tue, Oct 31, 2017 at 5:42 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> Hi
>>
>> On Tue, Oct 31, 2017 at 04:29:18PM +, Teresa Johnson wrote:
>> > It's needed for the same reason the used attribute was already added to
>> the
>> > "static const" variables. For those, when building with just -O2, they
>> > could be removed by optimization since they had local (file) scope, and
>> we
>> > couldn't see the uses in the inline assembly (without the used
>> attribute).
>> > With ThinLTO we have whole program scope, so even though they are
>> > non-static and have global scope we can do dead code elimination on
>> them if
>> > we don't see that they are used.
>>
>> currently we add "used" to DECLARE_ASM_CONST()
>> which is specific to inline asm use.
>>
>> DECLARE_ALIGNED() is not specific to use in asm.
>>
>> For DECLARE_ASM_CONST() the "used" is unneeded only in the subset of
>> inline asm cases where it is accessed through the asm operands like:
>> __asm__ volatile(
>> "movq  %0, %%mm7\n\t"
>> "movq  %1, %%mm6\n\t"
>> ::"m"(red_16mask),"m"(green_16mask));
>>
>> The compiler has full vissibility here of the access and if it removes
>> it its a  compiler bug.
>>
>> this is compared to code like:
>>  "pand "MANGLE(mask24l)", %%mm0\n\t"
>>
>> Here the compiler has no easy vissibility of the use, it is part of
>> the asm string.
>>
>> and comparing this to DECLARE_ALIGNED(), the big difference is
>> that DECLARE_ALIGNED() is used by plain C code which never should need
>> "used". So adding "used" to DECLARE_ALIGNED() would add alot more
>> "unused detection overriding" than what is needed
>>
>
> Perhaps then an additional macro is needed for variables that are
> currently DECLARED_ALIGNED but used by MANGLE, which adds the used
> attribute. What do you suggest?
> Teresa
>
>
>>
>>
>>
>> >
>> > Teresa
>> >
>> > On Tue, Oct 31, 2017 at 4:19 PM, Michael Niedermayer
>> > > > wrote:
>> >
>> > > On Tue, Oct 31, 2017 at 03:52:14PM +, Thomas Köppe wrote:
>> > > > +Teresa, who drafted the patch initially.
>> > > >
>> > > > On 31 October 2017 at 15:38, Michael Niedermayer
>> > > > >
>> > > > wrote:
>> > > >
>> > > > > On Tue, Oct 31, 2017 at 12:16:18PM +, Thomas Köppe wrote:
>> > > > > > Variables used in inline assembly need to be marked with
>> > > > > attribute((used)).
>> > > > >
>> > > > > This should not be the case.
>> > > > > Variables referenced through in/out operands should not need that.
>> > > > > Only ones accessed directly bypassing operands should need this
>> > > > >
>> > > >
>> > > > I've added Teresa to the thread, who initially analyzed the
>> problem. (For
>> > > > background on ThinLTO, see here cppcon talk:
>> > > > https://www.youtube.com/watch?v=p9nH2vZ2mNo.)
>> > > >
>> > > > [...]
>> > > > > > -#define DECLARE_ALIGNED(n,t,v)  t __attribute__
>> ((aligned
>> > > (n)))
>> > > > > v
>> > > > > > +#define DECLARE_ALIGNED(n,t,v)  t av_used __attribute__
>> > > > > ((aligned (n))) v
>> > > > >
>> > > > > which variables actually are affected/ need this ?
>> > > > >
>> > > >
>> > > > Without this annotation, and when compiling and linking with
>> ThinLTO, I
>> > > get
>> > > > an undefined reference to "ff_h264_cabac_tables", and also to
>> > > > "ff_pw_96", "ff_pw_53",
>> > > > "ff_pw_42", "ff_w" and many more.
>> > >
>> > > i guess these are all accessed directly, like through MANGLE()
>> > >
>> > >
>> > > >
>> > > >
>> > > > > Marking all aligned variables as used makes it harder to spot
>> unused
>> > > > > variables leading to accumulation of cruft
>> > > > >
>> > > >
>> > > > I see. Maybe we can annotate only the affected variables more
>> granularly?
>> > > > ___
>> > > > ffmpeg-devel mailing list
>> > > > ffmpeg-devel@ffmpeg.org
>> > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> > >
>> > > --
>> > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
>> 87040B0FAB
>> > >
>> > > Avoid a single point of failure, be that a person or equipment.
>> > >
>> >
>> >
>> >
>> > --
>> > Teresa Johnson |  Software Engineer |  tejohn...@google.com |
>> 408-460-2413
>> > ___
>> > ffmpeg-devel mailing list
>> > ffmpeg-devel@ffmpeg.org
>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> I am the wisest man alive, for I know one thing, and that is that I know
>> nothing. -- Socrates
>>
>
>
>
> --
> Teresa Johnson |  Software Engineer |  tejohn...@google.com |
> 

Re: [FFmpeg-devel] [PATCH] configure, fftools/Makefile: Copy .pdb files to bindir for MSVC builds for make install

[Aaron Levinson]

Ping

On 10/31/2017 11:05 AM, Aaron Levinson wrote:

When ffmpeg is built using MSVC, symbols are stored separately from
executables and libraries in .pdb files.  However, unlike with
gcc-based builds, when make install is invoked, symbols, in the form
of .pdb files, which are important for debugging, are not copied to
bindir.  This change corrects this deficiency for MSVC builds.  Files
are also uninstalled appropriately when make uninstall is exercised.

Note: General idea for how to properly handle the copying of PDB files
associated with programs suggested by Hendrik Leppkes.

Comments:

-- configure:
a) Leverage already existing SLIB_INSTALL_EXTRA_SHLIB facility (which
is already pretty specific to Windows) to add .pdb files, in
addition to .lib files, for shared libraries to bindir during make
install.
b) Add PROG_INSTALL_EXTRA_BIN variable for MSVC builds and also add it
to the section that causes it to be added to config.mak.  This is
used in Makefile to copy any additional files associated with
programs.  For MSVC, it is used to copy the pdb files associated
with any executables that are built.  Note that such executables
are build with _g in the file name and are later copied to a
filename without _g in the file name.  As such, the PDB files have
_g in the file name.

-- fftools/Makefile: Enhance install-progs and uninstall-progs targets
to handle PROG_INSTALL_EXTRA_BIN if defined.  It uses a similar
procedure as already in place for SLIB_INSTALL_EXTRA_SHLIB in
library.mak.

Signed-off-by: Aaron Levinson 
---
  configure| 4 +++-
  fftools/Makefile | 2 ++
  2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 2ac6fed98a..feb86b2069 100755
--- a/configure
+++ b/configure
@@ -5101,9 +5101,10 @@ case $target_os in
  SLIB_CREATE_DEF_CMD='$(SRC_PATH)/compat/windows/makedef 
$(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)'
  SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
  SLIB_INSTALL_LINKS=
-SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
+SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib) 
$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.pdb)'
  SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
  SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def) 
-implib:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)'
+PROG_INSTALL_EXTRA_BIN='$(AVPROGS-yes:%=%$(PROGSSUF)_g.pdb)'
  enabled x86_64 && objformat="win64" || objformat="win32"
  ranlib=:
  enable dos_paths
@@ -7034,6 +7035,7 @@ SLIB_INSTALL_NAME=${SLIB_INSTALL_NAME}
  SLIB_INSTALL_LINKS=${SLIB_INSTALL_LINKS}
  SLIB_INSTALL_EXTRA_LIB=${SLIB_INSTALL_EXTRA_LIB}
  SLIB_INSTALL_EXTRA_SHLIB=${SLIB_INSTALL_EXTRA_SHLIB}
+PROG_INSTALL_EXTRA_BIN=${PROG_INSTALL_EXTRA_BIN}
  VERSION_SCRIPT_POSTPROCESS_CMD=${VERSION_SCRIPT_POSTPROCESS_CMD}
  SAMPLES:=${samples:-\$(FATE_SAMPLES)}
  NOREDZONE_FLAGS=$noredzone_flags
diff --git a/fftools/Makefile b/fftools/Makefile
index c867814a71..8c121b9762 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -47,11 +47,13 @@ install-progs-$(CONFIG_SHARED): install-libs
  install-progs: install-progs-yes $(AVPROGS)
$(Q)mkdir -p "$(BINDIR)"
$(INSTALL) -c -m 755 $(AVPROGS) "$(BINDIR)"
+   $(if $(PROG_INSTALL_EXTRA_BIN), $(INSTALL) -m 644 $(PROG_INSTALL_EXTRA_BIN) 
"$(BINDIR)")
  
  uninstall: uninstall-progs
  
  uninstall-progs:

$(RM) $(addprefix "$(BINDIR)/", $(ALLAVPROGS))
+   $(if $(PROG_INSTALL_EXTRA_BIN), $(RM) $(addprefix "$(BINDIR)/", 
$(PROG_INSTALL_EXTRA_BIN)))
  
  clean::

$(RM) $(ALLAVPROGS) $(ALLAVPROGS_G) $(CLEANSUFFIXES:%=fftools/%)


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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/libx265: switch to ff_alloc_packet2

[Michael Niedermayer]

On Thu, Nov 09, 2017 at 01:51:30PM +, Derek Buitenhuis wrote:
> On 11/9/2017 12:39 AM, Jun Zhao wrote:
> > From 5afdf252b3bb6f8c7a276c2a8bde8f4a95d170e4 Mon Sep 17 00:00:00 2001
> > From: Jun Zhao 
> > Date: Wed, 8 Nov 2017 21:04:51 +0800
> > Subject: [PATCH 2/2] lavc/libx265: switch to ff_alloc_packet2
> > 
> > ff_alloc_packet have been deprecated, switch to use
> > ff_alloc_packet2.
> > 
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavcodec/libx265.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Should be OK.

will apply

thanks

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/libkvazaar: switch to ff_alloc_packet2

[Michael Niedermayer]

On Thu, Nov 09, 2017 at 10:27:50AM +0200, Arttu Ylä-Outinen wrote:
> LGTM

will apply

thx

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Parse upto 2 keyframes after the edit list end in mov_fix_index.

[Michael Niedermayer]

On Wed, Nov 08, 2017 at 04:13:46PM -0800, Sasi Inguva wrote:
> Partially fixes t/6699.
> ---
>  libavformat/mov.c | 32 
> ---
>  tests/fate/mov.mak|  4 
>  tests/ref/fate/mov-elst-ends-betn-b-and-i | 31 ++
>  3 files changed, 56 insertions(+), 11 deletions(-)
>  create mode 100644 tests/ref/fate/mov-elst-ends-betn-b-and-i

seems not passing fate here or i did something silly

--- ./tests/ref/fate/mov-elst-ends-betn-b-and-i 2017-11-09 21:14:14.425558802 
+0100
+++ tests/data/fate/mov-elst-ends-betn-b-and-i  2017-11-09 21:21:15.957563829 
+0100
@@ -7,25 +7,27 @@
 #dimensions 0: 320x240
 #sar 0: 1/1
 #stream#, dts,pts, duration, size, hash
-0,  0,  0,1,   115200, 4e5dc2b806e394cd666c968f736fecd0
-0,  1,  1,1,   115200, 7a3c7473d44c5f60c07655f6fc0c2ac3
-0,  2,  2,1,   115200, 038254422a603a3270c09cdcd149707b
-0,  3,  3,1,   115200, 7553b6b4547cb23ef8f0392ed5a5d4b0
-0,  4,  4,1,   115200, 6d017ede7f446124af7308667cb0dc41
-0,  5,  5,1,   115200, 77752f0288ae64f857732b8e62e47457
-0,  6,  6,1,   115200, d656833951af99330625f7c6de7685c4
-0,  7,  7,1,   115200, 14338b833e431e566ac98da841600bfe
-0,  8,  8,1,   115200, 07ea95d1659f3c4424a470a546d0df6e
-0,  9,  9,1,   115200, fd05b8cc83072f813e89d394d1f6efc6
-0, 10, 10,1,   115200, 750b82ca5c7e901545e7b1aa69692426
-0, 11, 11,1,   115200, 7347679ab09bc936047368b8caebcaff
-0, 12, 12,1,   115200, 63a23fdd57ac8462b9ffbcb12ab717b3
-0, 13, 13,1,   115200, 705257a1c99693db233e2a3ee027adcf
-0, 14, 14,1,   115200, df861a2ec7a4ef70e82b1c28025e5a48
-0, 15, 15,1,   115200, 2a8b403c077b6b43aa71eaf7d1537713
-0, 16, 16,1,   115200, 973b5cd3ce473e3970dfa96045553172
-0, 17, 17,1,   115200, fc612c0afeae3b6576b5ee2f3f119832
-0, 18, 18,1,   115200, 97074fe5a0b6e7e8470729654092e56c
-0, 19, 19,1,   115200, 8cf9337201065335b3aa4da21dc9b37a
-0, 20, 20,1,   115200, 93ff3589294cc0673af3daee1e7fe42a
-0, 21, 21,1,   115200, c0b6fd870a022f374f9d6c697e8e293d
+0,  0,  0,1,   115200, e10741e5457e9326d5e992e6c05c3e32
+0,  1,  1,1,   115200, 7e20f8729b6b53dc11791927bf4a5aec
+0,  2,  2,1,   115200, 4e5dc2b806e394cd666c968f736fecd0
+0,  3,  3,1,   115200, 7a3c7473d44c5f60c07655f6fc0c2ac3
+0,  4,  4,1,   115200, 038254422a603a3270c09cdcd149707b
+0,  5,  5,1,   115200, 7553b6b4547cb23ef8f0392ed5a5d4b0
+0,  6,  6,1,   115200, 6d017ede7f446124af7308667cb0dc41
+0,  7,  7,1,   115200, 77752f0288ae64f857732b8e62e47457
+0,  8,  8,1,   115200, d656833951af99330625f7c6de7685c4
+0,  9,  9,1,   115200, 14338b833e431e566ac98da841600bfe
+0, 10, 10,1,   115200, 07ea95d1659f3c4424a470a546d0df6e
+0, 11, 11,1,   115200, fd05b8cc83072f813e89d394d1f6efc6
+0, 12, 12,1,   115200, 750b82ca5c7e901545e7b1aa69692426
+0, 13, 13,1,   115200, 7347679ab09bc936047368b8caebcaff
+0, 14, 14,1,   115200, 63a23fdd57ac8462b9ffbcb12ab717b3
+0, 15, 15,1,   115200, 705257a1c99693db233e2a3ee027adcf
+0, 16, 16,1,   115200, df861a2ec7a4ef70e82b1c28025e5a48
+0, 17, 17,1,   115200, 2a8b403c077b6b43aa71eaf7d1537713
+0, 18, 18,1,   115200, 973b5cd3ce473e3970dfa96045553172
+0, 19, 19,1,   115200, fc612c0afeae3b6576b5ee2f3f119832
+0, 20, 20,1,   115200, 97074fe5a0b6e7e8470729654092e56c
+0, 21, 21,1,   115200, 8cf9337201065335b3aa4da21dc9b37a
+0, 22, 22,1,   115200, 93ff3589294cc0673af3daee1e7fe42a
+0, 23, 23,1,   115200, c0b6fd870a022f374f9d6c697e8e293d
Test mov-elst-ends-betn-b-and-i failed. Look at 
tests/data/fate/mov-elst-ends-betn-b-and-i.err for details.
make: *** [fate-mov-elst-ends-betn-b-and-i] Error 1

[...]
--
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

Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: make some function static

[James Almer]

On 11/9/2017 2:07 AM, Aaron Levinson wrote:
> On 11/8/2017 7:20 PM, James Almer wrote:
>> Should fix ticket #6822
>>
>> Signed-off-by: James Almer 
>> ---
>>   libavdevice/decklink_dec.cpp | 8 
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
>> index 191547ff10..e90b42811a 100644
>> --- a/libavdevice/decklink_dec.cpp
>> +++ b/libavdevice/decklink_dec.cpp
>> @@ -262,8 +262,8 @@ static uint8_t*
>> teletext_data_unit_from_ancillary_packet(uint16_t *py, uint16_t
>>   return tgt;
>>   }
>>   -uint8_t *vanc_to_cc(AVFormatContext *avctx, uint16_t *buf, size_t
>> words,
>> -    unsigned _count)
>> +static uint8_t *vanc_to_cc(AVFormatContext *avctx, uint16_t *buf,
>> size_t words,
>> +   unsigned _count)
>>   {
>>   size_t i, len = (buf[5] & 0xff) + 6 + 1;
>>   uint8_t cdp_sum, rate;
>> @@ -352,8 +352,8 @@ uint8_t *vanc_to_cc(AVFormatContext *avctx,
>> uint16_t *buf, size_t words,
>>   return cc;
>>   }
>>   -uint8_t *get_metadata(AVFormatContext *avctx, uint16_t *buf, size_t
>> width,
>> -  uint8_t *tgt, size_t tgt_size, AVPacket *pkt)
>> +static uint8_t *get_metadata(AVFormatContext *avctx, uint16_t *buf,
>> size_t width,
>> + uint8_t *tgt, size_t tgt_size, AVPacket
>> *pkt)
>>   {
>>   decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
>>   uint16_t *max_buf = buf + width;
>>
> 
> LGTM

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

Re: [FFmpeg-devel] [PATCH 11/11] avcodec/lossless_videodsp: add AVX-512 version of add_bytes

[Martin Vignali]

2017-11-09 12:58 GMT+01:00 James Darnley :

> ---
>  libavcodec/x86/lossless_videodsp.asm| 5 +
>  libavcodec/x86/lossless_videodsp_init.c | 5 +
>  2 files changed, 10 insertions(+)
>
> diff --git a/libavcodec/x86/lossless_videodsp.asm
> b/libavcodec/x86/lossless_videodsp.asm
> index ba4d4f0153..5649348f86 100644
> --- a/libavcodec/x86/lossless_videodsp.asm
> +++ b/libavcodec/x86/lossless_videodsp.asm
> @@ -229,6 +229,11 @@ INIT_YMM avx2
>  ADD_BYTES
>  %endif
>
> +%if HAVE_AVX512_EXTERNAL
> +INIT_ZMM avx512
> +ADD_BYTES
> +%endif
> +
>  %macro ADD_HFYU_LEFT_LOOP_INT16 2 ; %1 = dst alignment (a/u), %2 = src
> alignment (a/u)
>  add wd, wd
>  add srcq, wq
> diff --git a/libavcodec/x86/lossless_videodsp_init.c
> b/libavcodec/x86/lossless_videodsp_init.c
> index 4f20c1ce92..80d6972f36 100644
> --- a/libavcodec/x86/lossless_videodsp_init.c
> +++ b/libavcodec/x86/lossless_videodsp_init.c
> @@ -26,6 +26,7 @@
>  void ff_add_bytes_mmx(uint8_t *dst, uint8_t *src, ptrdiff_t w);
>  void ff_add_bytes_sse2(uint8_t *dst, uint8_t *src, ptrdiff_t w);
>  void ff_add_bytes_avx2(uint8_t *dst, uint8_t *src, ptrdiff_t w);
> +void ff_add_bytes_avx512(uint8_t *dst, uint8_t *src, ptrdiff_t w);
>
>  void ff_add_median_pred_mmxext(uint8_t *dst, const uint8_t *top,
> const uint8_t *diff, ptrdiff_t w,
> @@ -119,4 +120,8 @@ void ff_llviddsp_init_x86(LLVidDSPContext *c)
>  if (EXTERNAL_AVX2_FAST(cpu_flags)) {
>  c->add_bytes   = ff_add_bytes_avx2;
>  }
> +
> +if (EXTERNAL_AVX512(cpu_flags)) {
> +c->add_bytes   = ff_add_bytes_avx512;
> +}
>  }
>
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 11/11] avcodec/lossless_videodsp: add AVX-512 version of add_bytes

[Martin Vignali]

2017-11-09 20:37 GMT+01:00 Martin Vignali :

>
>
> 2017-11-09 12:58 GMT+01:00 James Darnley :
>
>> ---
>>  libavcodec/x86/lossless_videodsp.asm| 5 +
>>  libavcodec/x86/lossless_videodsp_init.c | 5 +
>>  2 files changed, 10 insertions(+)
>>
>> diff --git a/libavcodec/x86/lossless_videodsp.asm
>> b/libavcodec/x86/lossless_videodsp.asm
>> index ba4d4f0153..5649348f86 100644
>> --- a/libavcodec/x86/lossless_videodsp.asm
>> +++ b/libavcodec/x86/lossless_videodsp.asm
>> @@ -229,6 +229,11 @@ INIT_YMM avx2
>>  ADD_BYTES
>>  %endif
>>
>> +%if HAVE_AVX512_EXTERNAL
>> +INIT_ZMM avx512
>> +ADD_BYTES
>> +%endif
>> +
>>  %macro ADD_HFYU_LEFT_LOOP_INT16 2 ; %1 = dst alignment (a/u), %2 = src
>> alignment (a/u)
>>  add wd, wd
>>  add srcq, wq
>> diff --git a/libavcodec/x86/lossless_videodsp_init.c
>> b/libavcodec/x86/lossless_videodsp_init.c
>> index 4f20c1ce92..80d6972f36 100644
>> --- a/libavcodec/x86/lossless_videodsp_init.c
>> +++ b/libavcodec/x86/lossless_videodsp_init.c
>> @@ -26,6 +26,7 @@
>>  void ff_add_bytes_mmx(uint8_t *dst, uint8_t *src, ptrdiff_t w);
>>  void ff_add_bytes_sse2(uint8_t *dst, uint8_t *src, ptrdiff_t w);
>>  void ff_add_bytes_avx2(uint8_t *dst, uint8_t *src, ptrdiff_t w);
>> +void ff_add_bytes_avx512(uint8_t *dst, uint8_t *src, ptrdiff_t w);
>>
>>  void ff_add_median_pred_mmxext(uint8_t *dst, const uint8_t *top,
>> const uint8_t *diff, ptrdiff_t w,
>> @@ -119,4 +120,8 @@ void ff_llviddsp_init_x86(LLVidDSPContext *c)
>>  if (EXTERNAL_AVX2_FAST(cpu_flags)) {
>>  c->add_bytes   = ff_add_bytes_avx2;
>>  }
>> +
>> +if (EXTERNAL_AVX512(cpu_flags)) {
>> +c->add_bytes   = ff_add_bytes_avx512;
>> +}
>>  }
>>
>>
> lgtm
>
> Can you post your checkasm benchmark result for this ?

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

Re: [FFmpeg-devel] [PATCH 09/11] avcodec/blockdsp: roll-up x86asm preprocessor loop

[Martin Vignali]

2017-11-09 12:58 GMT+01:00 James Darnley :

> From: James Darnley 
>
> ---
>  libavcodec/x86/blockdsp.asm | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/x86/blockdsp.asm b/libavcodec/x86/blockdsp.asm
> index 9d203df8f5..9d0e8a3242 100644
> --- a/libavcodec/x86/blockdsp.asm
> +++ b/libavcodec/x86/blockdsp.asm
> @@ -38,22 +38,19 @@ cglobal clear_block, 1, 1, %1, blocks
>  %assign %%i 0
>  %rep %2
>  mova  [blocksq+mmsize*(0+%%i)], m0
>
>
> do you still need (0+%%i ) ?
Maybe (untested), %%i is enough ?

otherwise lgtm.

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

Re: [FFmpeg-devel] [PATCH 08/11] avcodec/v210enc: add AVX-512 10-bit line pack function

[Martin Vignali]

2017-11-09 12:58 GMT+01:00 James Darnley :

> ---
>  libavcodec/x86/v210enc.asm| 5 +
>  libavcodec/x86/v210enc_init.c | 7 +++
>  2 files changed, 12 insertions(+)
>
> diff --git a/libavcodec/x86/v210enc.asm b/libavcodec/x86/v210enc.asm
> index 965f2bea3c..5068af27f8 100644
> --- a/libavcodec/x86/v210enc.asm
> +++ b/libavcodec/x86/v210enc.asm
> @@ -103,6 +103,11 @@ INIT_YMM avx2
>  v210_planar_pack_10
>  %endif
>
> +%if HAVE_AVX512_EXTERNAL
> +INIT_YMM avx512
> +v210_planar_pack_10
> +%endif
> +
>  %macro v210_planar_pack_8 0
>
>  ; v210_planar_pack_8(const uint8_t *y, const uint8_t *u, const uint8_t
> *v, uint8_t *dst, ptrdiff_t width)
> diff --git a/libavcodec/x86/v210enc_init.c b/libavcodec/x86/v210enc_init.c
> index e997b4b67a..e8aac373a0 100644
> --- a/libavcodec/x86/v210enc_init.c
> +++ b/libavcodec/x86/v210enc_init.c
> @@ -32,6 +32,9 @@ void ff_v210_planar_pack_10_ssse3(const uint16_t *y,
> const uint16_t *u,
>  void ff_v210_planar_pack_10_avx2(const uint16_t *y, const uint16_t *u,
>   const uint16_t *v, uint8_t *dst,
>   ptrdiff_t width);
> +void ff_v210_planar_pack_10_avx512(const uint16_t *y, const uint16_t *u,
> +   const uint16_t *v, uint8_t *dst,
> +   ptrdiff_t width);
>
>  av_cold void ff_v210enc_init_x86(V210EncContext *s)
>  {
> @@ -51,4 +54,8 @@ av_cold void ff_v210enc_init_x86(V210EncContext *s)
>  s->sample_factor_10 = 2;
>  s->pack_line_10 = ff_v210_planar_pack_10_avx2;
>  }
> +
> +if (EXTERNAL_AVX512(cpu_flags)) {
> +s->pack_line_10 = ff_v210_planar_pack_10_avx512;
> +}
>  }
> --
>
>
I doesn't want to block this patch, but
like you say (in your previous version), that this version is not faster,
i'm not sure, it's interesting to apply it.
You already made "real" avx512 version for other funcs, in order to check
the rest of yours patchs.

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

Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[James Almer]

On 11/9/2017 2:46 PM, Clément Bœsch wrote:
> On Wed, Nov 08, 2017 at 09:26:13PM +, Rostislav Pehlivanov wrote:
>> Signed-off-by: Rostislav Pehlivanov 
>> ---
>>  doc/developer.texi | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/doc/developer.texi b/doc/developer.texi
>> index a7b4f1d737..de7d887451 100644
>> --- a/doc/developer.texi
>> +++ b/doc/developer.texi
>> @@ -132,6 +132,9 @@ designated struct initializers (@samp{struct s x = @{ .i 
>> = 17 @};});
>>  @item
>>  compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
>>  
>> +@item
>> +for loops with variable definition (@samp{for (int i = 0; i < 8; i++)});
>> +
> 
> I'm fine with this and would be happy to update all the code I maintain in
> FFmpeg to follow this pattern. But I have a few questions/reservations:
> 
> - what does it imply for mixed statements and declarations?
> 
>   If we still do not allow them, how are you going to make the compiler
>   reject them but not the for (int ... ) form?

No way to do that i guess. If we remove the warning, it will never catch
any kind of mixed declarations and statements anymore.

> 
>   Also, allowing this but not the mixed statements and declarations means
>   this is a style decision and not a technical one anymore.

Expanding on the above, doing this will become hard to enforce without
the warning, unless people reviewing patches start looking very closely
for them.

> 
> - are we going to accept all kind of patches to change the coding style
>   all over the codebase?

I'd rather not allow that. Big cosmetics changes tend to make using git
blame a PITA.

> 
> - this require a Changelog entry as it has a technical impact (which could
>   be considered negligible).

No, Changelog is not for this kind of change.

Maybe we should add some sort of changelog specific for doc/developer or
similar documentation.

> 
> Overall, I'd enjoy this change being accepted (even along mixed statements
> and declarations).

I personally find the current style cleaner looking, but i wouldn't
oppose this if it can be proven we're not breaking compilers currently
supported (and still used) just for it, as Mark requested in another email.
Afaik, MSVC 2012 and older stopped working with ffmpeg some time ago, or
at least are not tested by FATE any more.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[Clément Bœsch]

On Thu, Nov 09, 2017 at 04:56:07PM -0300, James Almer wrote:
[...]
> > - this require a Changelog entry as it has a technical impact (which could
> >   be considered negligible).
> 
> No, Changelog is not for this kind of change.
> 

Sorry, I should have elaborated: I meant to document in the Changelog the
drop of support for the specific affected compilers.

-- 
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/9] lavfi/paletteuse: check get_color return value

[Clément Bœsch]

On Wed, Nov 08, 2017 at 07:17:45PM +0100, Timo Rothenpieler wrote:
> Fixes CID #1420396
> ---
>  libavfilter/vf_paletteuse.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
> index ed80ab04d5..1980907e70 100644
> --- a/libavfilter/vf_paletteuse.c
> +++ b/libavfilter/vf_paletteuse.c
> @@ -380,8 +380,11 @@ static av_always_inline int 
> get_dst_color_err(PaletteUseContext *s,
>  const uint8_t r = c >> 16 & 0xff;
>  const uint8_t g = c >>  8 & 0xff;
>  const uint8_t b = c   & 0xff;
> +uint32_t dstc;
>  const int dstx = color_get(s, c, a, r, g, b, search_method);
> -const uint32_t dstc = s->palette[dstx];
> +if (dstx < 0)
> +return dstx;
> +dstc = s->palette[dstx];
>  *er = r - (dstc >> 16 & 0xff);
>  *eg = g - (dstc >>  8 & 0xff);
>  *eb = b - (dstc   & 0xff);

should be fine

-- 
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] Fix missing used attribute for inline assembly variables

[Thomas Köppe]

Thank you, I'll package this up as a patch and send it as a separate mail.

On 9 November 2017 at 11:52, Teresa Johnson  wrote:

> I implemented this change to add a new macro. I tried to find the
> variables used in MANGLE and change those to use the new
> DECLARE_ASM_ALIGNED, and the build succeeds with these changes. New changes
> are in cl/172133815 .
>
> Teresa
>
> On Wed, Nov 1, 2017 at 7:25 AM, Teresa Johnson 
> wrote:
>
>>
>>
>> On Tue, Oct 31, 2017 at 5:42 PM, Michael Niedermayer <
>> mich...@niedermayer.cc> wrote:
>>
>>> Hi
>>>
>>> On Tue, Oct 31, 2017 at 04:29:18PM +, Teresa Johnson wrote:
>>> > It's needed for the same reason the used attribute was already added
>>> to the
>>> > "static const" variables. For those, when building with just -O2, they
>>> > could be removed by optimization since they had local (file) scope,
>>> and we
>>> > couldn't see the uses in the inline assembly (without the used
>>> attribute).
>>> > With ThinLTO we have whole program scope, so even though they are
>>> > non-static and have global scope we can do dead code elimination on
>>> them if
>>> > we don't see that they are used.
>>>
>>> currently we add "used" to DECLARE_ASM_CONST()
>>> which is specific to inline asm use.
>>>
>>> DECLARE_ALIGNED() is not specific to use in asm.
>>>
>>> For DECLARE_ASM_CONST() the "used" is unneeded only in the subset of
>>> inline asm cases where it is accessed through the asm operands like:
>>> __asm__ volatile(
>>> "movq  %0, %%mm7\n\t"
>>> "movq  %1, %%mm6\n\t"
>>> ::"m"(red_16mask),"m"(green_16mask));
>>>
>>> The compiler has full vissibility here of the access and if it removes
>>> it its a  compiler bug.
>>>
>>> this is compared to code like:
>>>  "pand "MANGLE(mask24l)", %%mm0\n\t"
>>>
>>> Here the compiler has no easy vissibility of the use, it is part of
>>> the asm string.
>>>
>>> and comparing this to DECLARE_ALIGNED(), the big difference is
>>> that DECLARE_ALIGNED() is used by plain C code which never should need
>>> "used". So adding "used" to DECLARE_ALIGNED() would add alot more
>>> "unused detection overriding" than what is needed
>>>
>>
>> Perhaps then an additional macro is needed for variables that are
>> currently DECLARED_ALIGNED but used by MANGLE, which adds the used
>> attribute. What do you suggest?
>> Teresa
>>
>>
>>>
>>>
>>>
>>> >
>>> > Teresa
>>> >
>>> > On Tue, Oct 31, 2017 at 4:19 PM, Michael Niedermayer
>>> >> > > wrote:
>>> >
>>> > > On Tue, Oct 31, 2017 at 03:52:14PM +, Thomas Köppe wrote:
>>> > > > +Teresa, who drafted the patch initially.
>>> > > >
>>> > > > On 31 October 2017 at 15:38, Michael Niedermayer
>>> >> > > >
>>> > > > wrote:
>>> > > >
>>> > > > > On Tue, Oct 31, 2017 at 12:16:18PM +, Thomas Köppe wrote:
>>> > > > > > Variables used in inline assembly need to be marked with
>>> > > > > attribute((used)).
>>> > > > >
>>> > > > > This should not be the case.
>>> > > > > Variables referenced through in/out operands should not need
>>> that.
>>> > > > > Only ones accessed directly bypassing operands should need this
>>> > > > >
>>> > > >
>>> > > > I've added Teresa to the thread, who initially analyzed the
>>> problem. (For
>>> > > > background on ThinLTO, see here cppcon talk:
>>> > > > https://www.youtube.com/watch?v=p9nH2vZ2mNo.)
>>> > > >
>>> > > > [...]
>>> > > > > > -#define DECLARE_ALIGNED(n,t,v)  t __attribute__
>>> ((aligned
>>> > > (n)))
>>> > > > > v
>>> > > > > > +#define DECLARE_ALIGNED(n,t,v)  t av_used
>>> __attribute__
>>> > > > > ((aligned (n))) v
>>> > > > >
>>> > > > > which variables actually are affected/ need this ?
>>> > > > >
>>> > > >
>>> > > > Without this annotation, and when compiling and linking with
>>> ThinLTO, I
>>> > > get
>>> > > > an undefined reference to "ff_h264_cabac_tables", and also to
>>> > > > "ff_pw_96", "ff_pw_53",
>>> > > > "ff_pw_42", "ff_w" and many more.
>>> > >
>>> > > i guess these are all accessed directly, like through MANGLE()
>>> > >
>>> > >
>>> > > >
>>> > > >
>>> > > > > Marking all aligned variables as used makes it harder to spot
>>> unused
>>> > > > > variables leading to accumulation of cruft
>>> > > > >
>>> > > >
>>> > > > I see. Maybe we can annotate only the affected variables more
>>> granularly?
>>> > > > ___
>>> > > > ffmpeg-devel mailing list
>>> > > > ffmpeg-devel@ffmpeg.org
>>> > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> > >
>>> > > --
>>> > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
>>> 87040B0FAB
>>> > >
>>> > > Avoid a single point of failure, be that a person or equipment.
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > Teresa Johnson |  Software Engineer |  tejohn...@google.com |
>>> 408-460-2413
>>> > ___
>>> > ffmpeg-devel 

Re: [FFmpeg-devel] [PATCH] lavu/timecode: clarify error msg for timecode_rate

[Gyan Doshi]

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

Re: [FFmpeg-devel] [PATCH]lavf/dashdec: Fix several memleaks

[Michael Niedermayer]

On Wed, Nov 08, 2017 at 10:46:27PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes several memleaks found testing ticket #6820 (I
> cannot reproduce the crash).
> 
> Please comment, Carl Eugen

>  dashdec.c |   22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 557d3b077beb6b9d73ed401761a318ebd5079c3d  
> 0001-lavf-dashdec-Fix-several-memleaks.patch
> From 915eae44e2f9bd7fb5ae78aa697338f348db3e08 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Wed, 8 Nov 2017 22:44:06 +0100
> Subject: [PATCH] lavf/dashdec: Fix several memleaks.

probably ok but iam not maintainer of this

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[James Almer]

On 11/9/2017 5:08 PM, Clément Bœsch wrote:
> On Thu, Nov 09, 2017 at 04:56:07PM -0300, James Almer wrote:
> [...]
>>> - this require a Changelog entry as it has a technical impact (which could
>>>   be considered negligible).
>>
>> No, Changelog is not for this kind of change.
>>
> 
> Sorry, I should have elaborated: I meant to document in the Changelog the
> drop of support for the specific affected compilers.

Oh right. In that case i guess yes, we did add lines about support for
new compilers there after all.

But still, Mark's concerns should be addressed before anything is decided.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DEVEL][PATCH] ffmpeg: fix channel_layout bug on non-default layout

[pkv.stream]

Hi Michael,


  ffmpeg_opt.c |   11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)
2af07f4366efdfaf1018bb2ea29be672befe0823  
0001-ffmpeg-fix-channel_layout-bug-on-non-default-layout.patch
 From 4ec55dc88923108132307b41300a1abddf32e6f7 Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Mon, 2 Oct 2017 11:14:31 +0200
Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout

Fix for ticket 6706.
The -channel_layout option was not working when the channel layout was not
a default one (ex: for 4 channels, quad was interpreted as 4.0 which is
the default layout for 4 channels; or octagonal interpreted as 7.1).
This led to the spurious auto-insertion of an auto-resampler filter
remapping the channels even if input and output had identical channel
layouts.
The fix operates by directly calling the channel layout if defined in
options. If the layout is undefined, the default layout is selected as
before the fix.
---
  ffmpeg_opt.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 100fa76..cf5a63c 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1804,6 +1804,12 @@ static OutputStream *new_audio_stream(OptionsContext *o, 
AVFormatContext *oc, in
  
  MATCH_PER_STREAM_OPT(audio_channels, i, audio_enc->channels, oc, st);
  
+AVDictionaryEntry *output_layout = av_dict_get(o->g->codec_opts,

+   "channel_layout",
+   NULL, 
AV_DICT_MATCH_CASE);

This doesnt look right

not an issue of the patch as such but
why is the channel_layout option per file and not per stream?



just my ignorance; do you mean this is not the right way to retrieve the 
channel_layout option from an audio stream ?

Could you give me a hint on how to retrieve correctly the option ?

the goal is to get rid of :

l. 2526 in ffmpeg_opt.c :  f->channel_layout = 
av_get_default_channel_layout(ost->enc_ctx->channels);

from commit 
https://github.com/FFmpeg/FFmpeg/commit/198e8b8e774659eacaa7058c7f5704029af5bbbf#diff-3662f9bbf5b9e46a224a4e65b17254ba


(merge from libav) which is causing the auto-insert of a filter which 
rematrix a non default channel layout into a default one (ex: octagonal 
to 7.1).







also currently mixed statemts and declarations arent allowed

yes sorry; I've learned that from the ongoing discussion  on the 'for  
int loop' and will fix if I am able to find the right way to solve the 
ticket



+if (output_layout)
+ost->enc_ctx->channel_layout = strtoull(output_layout->value, 
NULL, 10);

audio_enc


ok

+
  MATCH_PER_STREAM_OPT(sample_fmts, str, sample_fmt, oc, st);
  if (sample_fmt &&
  (audio_enc->sample_fmt = av_get_sample_fmt(sample_fmt)) == 
AV_SAMPLE_FMT_NONE) {
@@ -2524,7 +2530,10 @@ loop_end:
 (count + 1) * sizeof(*f->sample_rates));
  }
  if (ost->enc_ctx->channels) {
-f->channel_layout = 
av_get_default_channel_layout(ost->enc_ctx->channels);
+if (ost->enc_ctx->channel_layout)
+f->channel_layout = ost->enc_ctx->channel_layout;
+else
+f->channel_layout = 
av_get_default_channel_layout(ost->enc_ctx->channels);

if () {
} else

is better as tat way future patches do not need to change existing
lines maing patches more readable if ever a line is added


sure, thanks for the explanation ; will fix



[...]



___
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] examples/vaapi_encode: Add a VA-API encode example.

[Mark Thompson]

On 06/11/17 06:56, Jun Zhao wrote:
> From d16f766363d9ecc240b0f8e025c2a8f91ea4775e Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Mon, 6 Nov 2017 14:45:27 +0800
> Subject: [PATCH] examples/vaapi_encode: Add a VA-API encode example.
> 
> add a VA-API encode example, only support NV12 input, usage like:
> ./vaapi_encode 1920 1080 test.yuv test.h264
> 
> Signed-off-by: Jun Zhao 
> Signed-off-by: Liu, Kaixuan 
> ---
>  configure   |   2 +
>  doc/examples/Makefile   |   1 +
>  doc/examples/vaapi_encode.c | 308 
> 
>  3 files changed, 311 insertions(+)
>  create mode 100644 doc/examples/vaapi_encode.c
> 
> diff --git a/configure b/configure
> index 1b0f064607..2df0205e09 100755
> --- a/configure
> +++ b/configure
> @@ -1524,6 +1524,7 @@ EXAMPLE_LIST="
>  scaling_video_example
>  transcode_aac_example
>  transcoding_example
> +vaapi_encode_example
>  "
>  
>  EXTERNAL_AUTODETECT_LIBRARY_LIST="
> @@ -3294,6 +3295,7 @@ resampling_audio_example_deps="avutil swresample"
>  scaling_video_example_deps="avutil swscale"
>  transcode_aac_example_deps="avcodec avformat swresample"
>  transcoding_example_deps="avfilter avcodec avformat avutil"
> +vaapi_encode_example_deps="avfilter avcodec avformat avutil"
>  
>  # EXTRALIBS_LIST
>  cpu_init_extralibs="pthreads_extralibs"
> diff --git a/doc/examples/Makefile b/doc/examples/Makefile
> index 58afd71b85..da5af36532 100644
> --- a/doc/examples/Makefile
> +++ b/doc/examples/Makefile
> @@ -19,6 +19,7 @@ EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE)  += 
> resampling_audio
>  EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video
>  EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac
>  EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE)   += transcoding
> +EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE)  += vaapi_encode
>  
>  EXAMPLES   := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)$(EXESUF))
>  EXAMPLES_G := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)_g$(EXESUF))
> diff --git a/doc/examples/vaapi_encode.c b/doc/examples/vaapi_encode.c
> new file mode 100644
> index 00..02b1ac5a4a
> --- /dev/null
> +++ b/doc/examples/vaapi_encode.c
> @@ -0,0 +1,308 @@
> +/*
> + * Video Acceleration API (video encoding) encode sample
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +/**
> + * @file
> + * Intel VAAPI-accelerated encoding example.
> + *
> + * @example vaapi_encode.c
> + * This example shows how to do VAAPI-accelerated encoding. now only support 
> NV12
> + * raw file, usage like: vaapi_enc 1920 1080 input.yuv output.h264
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +typedef struct FilterContext {
> +AVFilterContext *buffersink_ctx;
> +AVFilterContext *buffersrc_ctx;
> +AVFilterGraph   *filter_graph;
> +} FilterContext;
> +
> +static int width, height;
> +static AVBufferRef *hw_device_ctx = NULL;
> +
> +static int init_filter(FilterContext *filter_ctx, char *args, AVBufferRef 
> *hw_device_ctx)
> +{
> +char filter_spec[] = "format=nv12,hwupload";
> +int  ret = 0, i = 0;
> +const AVFilter *buffersrc, *buffersink;
> +AVFilterContext *buffersrc_ctx, *buffersink_ctx;
> +AVFilterInOut *outputs = avfilter_inout_alloc();
> +AVFilterInOut *inputs  = avfilter_inout_alloc();
> +AVFilterGraph *filter_graph = avfilter_graph_alloc();
> +
> +buffersrc = avfilter_get_by_name("buffer");
> +buffersink = avfilter_get_by_name("buffersink");
> +if (!buffersrc || !buffersink) {
> +av_log(NULL, AV_LOG_ERROR, "filtering source or sink element not 
> found\n");
> +ret = AVERROR_UNKNOWN;
> +goto fail;
> +}
> +
> +ret = avfilter_graph_create_filter(_ctx, buffersrc, "in",
> +   args, NULL, filter_graph);
> +if (ret < 0) {
> +av_log(NULL, AV_LOG_ERROR, "Cannot create buffer source. Error 
> code:%s\n", av_err2str(ret));
> +goto fail;
> +}
> +ret = avfilter_graph_create_filter(_ctx, buffersink, "out",
> +   

Re: [FFmpeg-devel] [PATCH 3/3] avformat/opensrt: add Haivision Open SRT protocol

[Nicolas George]

Le nonidi 19 brumaire, an CCXXVI, Nablet Developer a écrit :
> protocol requires libsrt (https://github.com/Haivision/srt) to be
> installed
> 
> Signed-off-by: Nablet Developer 
> ---
>  configure   |  10 ++
>  libavformat/Makefile|   1 +
>  libavformat/opensrt.c   | 418 
> 
>  libavformat/protocols.c |   1 +
>  4 files changed, 430 insertions(+)
>  create mode 100644 libavformat/opensrt.c

Can you explain the logic of the implementation? I have a hard time
understanding why you call the tcp protocol from here after forcing it
to call back here.

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/3] avformat/tcp: use generic socket API

[Michael Niedermayer]

On Thu, Nov 09, 2017 at 04:31:31PM +0700, Nablet Developer wrote:
> this allows to implement other protocols which use
> API similar to BSD sockets (e.g. Haivision SRT)
> 
> Signed-off-by: Nablet Developer 
> ---
>  libavformat/tcp.c | 118 
> +++---

>  libavformat/tcp.h |  59 +++

missing standard inclusion guards

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

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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

Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[Aurelien Jacobs]

On Thu, Nov 09, 2017 at 04:56:07PM -0300, James Almer wrote:
> On 11/9/2017 2:46 PM, Clément Bœsch wrote:
> > On Wed, Nov 08, 2017 at 09:26:13PM +, Rostislav Pehlivanov wrote:
> >> Signed-off-by: Rostislav Pehlivanov 
> >> ---
> >>  doc/developer.texi | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/doc/developer.texi b/doc/developer.texi
> >> index a7b4f1d737..de7d887451 100644
> >> --- a/doc/developer.texi
> >> +++ b/doc/developer.texi
> >> @@ -132,6 +132,9 @@ designated struct initializers (@samp{struct s x = @{ 
> >> .i = 17 @};});
> >>  @item
> >>  compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
> >>  
> >> +@item
> >> +for loops with variable definition (@samp{for (int i = 0; i < 8; i++)});
> >> +
> > 
> > I'm fine with this and would be happy to update all the code I maintain in
> > FFmpeg to follow this pattern. But I have a few questions/reservations:
> > 
> > - what does it imply for mixed statements and declarations?

Nothing at all. It is unrelated to mixed statements and declarations.

> >   If we still do not allow them, how are you going to make the compiler
> >   reject them but not the for (int ... ) form?

By not changing anything at all. That is already what happens right now.

> No way to do that i guess. If we remove the warning, it will never catch
> any kind of mixed declarations and statements anymore.

No need to remove any warning. The -Wdeclaration-after-statement does
not emit warnings regarding for loops with declarations.

> >   Also, allowing this but not the mixed statements and declarations means
> >   this is a style decision and not a technical one anymore.

Allowing limiting the scope of a variable to a loop seems like a
technical decision to me, but I understand that some consider it more
of a style decision.

> > [...]
> > 
> > Overall, I'd enjoy this change being accepted (even along mixed statements
> > and declarations).

Just for the record, I would enjoy it as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavu/timecode: clarify error msg for timecode_rate

[Michael Niedermayer]

On Sun, Nov 05, 2017 at 09:40:41PM +0530, Gyan Doshi wrote:
> Prompted by an issue reported at StackExchange, patch changes error
> message for timecode_rate values below 1.
> 
> The user-supplied value for timecode_rate in drawtext is rounded
> to nearest integer. So, a supplied value of 0.49 or lower is rounded
> to 0. This throws a misleading error message which says "Timecode
> frame rate must be specified". Changed message to account for values
> under one.
> 
> Also noted supported framerates for drop TC.
> 
> Regards,
> Gyan

>  doc/filters.texi |4 +++-
>  libavutil/timecode.c |2 +-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 46ec36f411475b98d95396db7f239cb832fd80ae  
> 0001-lavu-timecode-clarify-error-msg-for-timecode_rate.patch
> From ef152e77da4d1ea40d452b9cc86dcc51df1e20a7 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Sun, 5 Nov 2017 21:29:22 +0530
> Subject: [PATCH] lavu/timecode: clarify error msg for timecode_rate
> 
> The user-supplied value for timecode_rate in drawtext is rounded
> to nearest integer. So, a supplied value of 0.49 or lower is rounded to 0.
> This throws a misleading error message which says "Timecode frame rate must be
> specified". Changed message to account for values under one.
> 
> Also noted supported framerates for drop TC.

will apply

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

Re: [FFmpeg-devel] [PATCH 1/2] aptx: implement the aptX bluetooth codec

[Aurelien Jacobs]

On Thu, Nov 09, 2017 at 02:32:44PM +, Rostislav Pehlivanov wrote:
> On 9 November 2017 at 13:37, Aurelien Jacobs  wrote:
> 
> > On Thu, Nov 09, 2017 at 12:52:34AM +, Rostislav Pehlivanov wrote:
> > > On 8 November 2017 at 22:41, Aurelien Jacobs  wrote:
> > >
> > > > On Wed, Nov 08, 2017 at 06:26:03PM +0100, Michael Niedermayer wrote:
> > > > > On Wed, Nov 08, 2017 at 02:06:09PM +0100, Aurelien Jacobs wrote:
> > > > > [...]
> > > > > > +}
> > > > > > +
> > > > > > +/*
> > > > > > + * Compute the convolution of the signal with the coefficients,
> > and
> > > > reduce
> > > > > > + * to 24 bits by applying the specified right shifting.
> > > > > > + */
> > > > > > +av_always_inline
> > > > > > +static int32_t aptx_qmf_convolution(FilterSignal *signal,
> > > > > > +const int32_t
> > coeffs[FILTER_TAPS],
> > > > > > +int shift)
> > > > > > +{
> > > > > > +int32_t *sig = >buffer[signal->pos];
> > > > > > +int64_t e = 0;
> > > > > > +
> > > > >
> > > > > > +for (int i = 0; i < FILTER_TAPS; i++)
> > > > >
> > > > > "for (int" is something we avoided as some comilers didnt like it,
> > > > > iam not sure if this is still true but there are none in the codebase
> > > >
> > > > If you insist on this I will of course change it, but hey, we require
> > > > a C99 compiler since a long time and we use so many features of C99
> > > > that I really don't get why we couldn't use "for (int".
> > > > I can't imagine that any relevant C compiler would not support this
> > > > nowadays !
> > > > What I propose is to get this in as is, and see if anyone encounter
> > > > issue with any compiler. If any issue arise, I will of course send a
> > > > patch to fix it.
> > > >
> > > > Here is an updated patch.
> > > >
> > > >
> > > Send another patch because some people are beyond convincing and its
> > really
> > > pissing me off. Really. In particular maybe those compiler writers at
> > > Microsoft who seem to think shipping something that doesn't support such
> > a
> > > simple yet important feature is important.
> > > Or maybe users who don't want to update a 6 year old version of msvc.
> > > Or maybe us because we support compiling with msvc at all when its
> > clearly
> > > _not_ a C compiler and this project is written in C.
> >
> > Here you go.
> >
> > Just for reference, splitting the déclaration out of the for loop added
> > 19 lines in this file, which is a 2.3 % increase of the line count.
> > (I'm not sure this file is representative of the rest of the code base)
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> Still some issues:
> 
> 1.) You need to set AVCodec->supported_samplerates for the encoder, since
> in the raw aptx muxer you always set the samplerate as 44100. Does the
> codec/container support other samplerates?

The codec is actually samplerate agnostic.
It only convert each group of 4 samples to a 16 bit integer.
There is no other information than the samples themselves in the
encoded stream. No header, no frame size, no samplerate.
And there is no standard container used to store aptX along with
the needed metadata such as the samplerate. It is meant to be streamed
thru bluetooth using the A2DP "protocol" which includes its own metadata
signaling with samplerate.
The raw muxer/demuxer that I implemented is mostly for testing purpose,
not really for practical use.
So with this in mind, I don't think that it make any sense to set
AVCodec->supported_samplerates.
I don't think I set the samplerate anywhere in the encoder.
I only set it in the demuxer to a default 44100 just to be able to
playback test files even though there is no way to know its actual
samplerate.

> 2.) "Frame must have a multiple of 4 samples" gets printed out when trying
> to resample a 48000 file and encode it to aptx.
> What you need to do is to remove AV_CODEC_CAP_VARIABLE_FRAME_SIZE from the
> capabilities and set some sane default for avctx->frame_size if
> avctx->frame_size is unset. Users can override it prior to encoder init and
> you can do it through the command line using -frame_size. If the user sets
> the frame_size, check if its a multiple of 4 and use it. Else, error out.
> If it isn't set (e.g. its 0), use the default (1024 is a good value).

OK, I will try this.
And I should probably document that for acheiving the lowest possible
latency for realtime bluetooth streaming, frame_size shoud be set to
4 samples.

> 3.) The packet timestamps on the encoder side are missing. Use the
> AudioFrameQueue API (libavcodec/audio_frame_queue.h) which at every frame
> counts how many samples you're given via the avframe and calculates what
> dts/pts to set on the avpacket.
> Just call ff_af_queue_init at the end of your init function (after the
> frame size is set and checked), call 

Re: [FFmpeg-devel] [DEVEL][PATCH] ffmpeg: fix channel_layout bug on non-default layout

[Michael Niedermayer]

On Thu, Nov 09, 2017 at 09:37:33PM +0100, pkv.stream wrote:
> Hi Michael,
> 
> >>  ffmpeg_opt.c |   11 ++-
> >>  1 file changed, 10 insertions(+), 1 deletion(-)
> >>2af07f4366efdfaf1018bb2ea29be672befe0823  
> >>0001-ffmpeg-fix-channel_layout-bug-on-non-default-layout.patch
> >> From 4ec55dc88923108132307b41300a1abddf32e6f7 Mon Sep 17 00:00:00 2001
> >>From: pkviet 
> >>Date: Mon, 2 Oct 2017 11:14:31 +0200
> >>Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout
> >>
> >>Fix for ticket 6706.
> >>The -channel_layout option was not working when the channel layout was not
> >>a default one (ex: for 4 channels, quad was interpreted as 4.0 which is
> >>the default layout for 4 channels; or octagonal interpreted as 7.1).
> >>This led to the spurious auto-insertion of an auto-resampler filter
> >>remapping the channels even if input and output had identical channel
> >>layouts.
> >>The fix operates by directly calling the channel layout if defined in
> >>options. If the layout is undefined, the default layout is selected as
> >>before the fix.
> >>---
> >>  ffmpeg_opt.c | 11 ++-
> >>  1 file changed, 10 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> >>index 100fa76..cf5a63c 100644
> >>--- a/ffmpeg_opt.c
> >>+++ b/ffmpeg_opt.c
> >>@@ -1804,6 +1804,12 @@ static OutputStream *new_audio_stream(OptionsContext 
> >>*o, AVFormatContext *oc, in
> >>  MATCH_PER_STREAM_OPT(audio_channels, i, audio_enc->channels, oc, 
> >> st);
> >>+AVDictionaryEntry *output_layout = av_dict_get(o->g->codec_opts,
> >>+   "channel_layout",
> >>+   NULL, 
> >>AV_DICT_MATCH_CASE);
> >This doesnt look right
> >
> >not an issue of the patch as such but
> >why is the channel_layout option per file and not per stream?
> 
> 
> just my ignorance; do you mean this is not the right way to retrieve
> the channel_layout option from an audio stream ?

I think there is more buggy with how the channel_layout is handled

try this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout 5 test.wav
and this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout:a 5 test.wav

while it may appear that the are both working this is deceiving.
I think only the channel number gets actually used in the 2nd case

Look at what your code with av_dict_get() reads.
It does not obtain the 5 in the 2nd case

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

Never trust a computer, one day, it may think you are the virus. -- Compn


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

[FFmpeg-devel] [PATCH] lavf/mov.c: Parse upto 2 keyframes after the edit list end in mov_fix_index.

[Sasi Inguva]

Partially fixes t/6699.
---
 libavformat/mov.c | 32 +++---
 tests/fate/mov.mak|  4 
 tests/ref/fate/mov-elst-ends-betn-b-and-i | 33 +++
 3 files changed, 58 insertions(+), 11 deletions(-)
 create mode 100644 tests/ref/fate/mov-elst-ends-betn-b-and-i

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7954db6e47..436ae42cbb 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3295,6 +3295,7 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
 int packet_skip_samples = 0;
 MOVIndexRange *current_index_range;
 int i;
+int found_keyframe_after_edit = 0;
 
 if (!msc->elst_data || msc->elst_count <= 0 || nb_old <= 0) {
 return;
@@ -3390,6 +3391,7 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
 
 // Iterate over index and arrange it according to edit list
 edit_list_start_encountered = 0;
+found_keyframe_after_edit = 0;
 for (; current < e_old_end; current++, index++) {
 // check  if frame outside edit list mark it for discard
 frame_duration = (current + 1 <  e_old_end) ?
@@ -3502,18 +3504,26 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
 }
 
 // Break when found first key frame after edit entry completion
-if (((curr_cts + frame_duration) >= (edit_list_duration + 
edit_list_media_time)) &&
+if ((curr_cts + frame_duration >= (edit_list_duration + 
edit_list_media_time)) &&
 ((flags & AVINDEX_KEYFRAME) || ((st->codecpar->codec_type == 
AVMEDIA_TYPE_AUDIO {
-
-if (ctts_data_old && ctts_sample_old != 0) {
-if (add_ctts_entry(>ctts_data, >ctts_count,
-   >ctts_allocated_size,
-   ctts_sample_old - 
edit_list_start_ctts_sample,
-   ctts_data_old[ctts_index_old].duration) 
== -1) {
-av_log(mov->fc, AV_LOG_ERROR, "Cannot add CTTS entry 
%"PRId64" - {%"PRId64", %d}\n",
-   ctts_index_old, ctts_sample_old - 
edit_list_start_ctts_sample,
-   ctts_data_old[ctts_index_old].duration);
-break;
+if (ctts_data_old) {
+// If we have CTTS and this is the the first keyframe 
after edit elist,
+// wait for one more, because there might be trailing 
B-frames after this I-frame
+// that do belong to the edit.
+if (st->codecpar->codec_type != AVMEDIA_TYPE_AUDIO && 
found_keyframe_after_edit == 0) {
+found_keyframe_after_edit = 1;
+continue;
+}
+if (ctts_sample_old != 0) {
+if (add_ctts_entry(>ctts_data, >ctts_count,
+   >ctts_allocated_size,
+   ctts_sample_old - 
edit_list_start_ctts_sample,
+   
ctts_data_old[ctts_index_old].duration) == -1) {
+av_log(mov->fc, AV_LOG_ERROR, "Cannot add CTTS 
entry %"PRId64" - {%"PRId64", %d}\n",
+   ctts_index_old, ctts_sample_old - 
edit_list_start_ctts_sample,
+   ctts_data_old[ctts_index_old].duration);
+break;
+}
 }
 }
 break;
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 01893a0767..76f66ff498 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -10,6 +10,7 @@ FATE_MOV = fate-mov-3elist \
fate-mov-gpmf-remux \
fate-mov-440hz-10ms \
fate-mov-ibi-elst-starts-b \
+   fate-mov-elst-ends-betn-b-and-i \
 
 FATE_MOV_FFPROBE = fate-mov-aac-2048-priming \
fate-mov-zombie \
@@ -42,6 +43,9 @@ fate-mov-1elist-ends-last-bframe: CMD = framemd5 -i 
$(TARGET_SAMPLES)/mov/mov-1e
 # Makes sure that we handle timestamps of packets in case of multiple edit 
lists with one of them ending on a B-frame correctly.
 fate-mov-2elist-elist1-ends-bframe: CMD = framemd5 -i 
$(TARGET_SAMPLES)/mov/mov-2elist-elist1-ends-bframe.mov
 
+# Makes sure that if edit list ends on a B-frame but before the I-frame, then 
we output the B-frame but discard the I-frame.
+fate-mov-elst-ends-betn-b-and-i: CMD = framemd5 -i 
$(TARGET_SAMPLES)/mov/elst_ends_betn_b_and_i.mp4
+
 # Makes sure that we handle edit lists and start padding correctly.
 fate-mov-440hz-10ms: CMD = framemd5 -i $(TARGET_SAMPLES)/mov/440hz-10ms.m4a
 
diff --git a/tests/ref/fate/mov-elst-ends-betn-b-and-i 
b/tests/ref/fate/mov-elst-ends-betn-b-and-i
new file mode 100644
index 00..d6f325bba2
--- /dev/null
+++ 

[FFmpeg-devel] [Patch] Fix for ticket 6658 (Dash demuxer segfault)

[Colin NG]

- Add a function to handle the base URL Processing described in section 5.6.5 
of IEC_23009-1.

- Fix for downloading content with byte range selection


diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index f63f1ff..19ef6f8 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -349,6 +349,16 @@ static void update_options(char **dest, const char *name, 
void *src)
 av_freep(dest);
 }
 
+static int isLocal(char *url) {
+
+if (av_strstart(url, "http://;, NULL) || av_strstart(url, "https://;, 
NULL))
+{
+return FALSE;
+}
+
+return TRUE;
+}
+
 static int open_url(AVFormatContext *s, AVIOContext **pb, const char *url,
 AVDictionary *opts, AVDictionary *opts2, int *is_http)
 {
@@ -392,7 +402,16 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 else if (strcmp(proto_name, "file") || !strncmp(url, "file,", 5))
 return AVERROR_INVALIDDATA;
 
-ret = s->io_open(s, pb, url, AVIO_FLAG_READ, );
+{
+av_freep(pb);
+AVDictionary *opts = NULL;
+set_httpheader_options(c, opts);
+ret = avio_open2(pb, url, AVIO_FLAG_READ, c->interrupt_callback, 
);
+av_dict_free();
+if (ret < 0)
+return ret;
+}
+
 if (ret >= 0) {
 // update cookies on http response with setcookies.
 char *new_cookies = NULL;
@@ -416,11 +435,156 @@ static int open_url(AVFormatContext *s, AVIOContext 
**pb, const char *url,
 return ret;
 }
 
-static char *get_content_url(xmlNodePtr *baseurl_nodes,
- int n_baseurl_nodes,
- char *rep_id_val,
- char *rep_bandwidth_val,
- char *val)
+
+static int resolve_content_path(AVFormatContext *s, const char *url,  
xmlNodePtr *baseurl_nodes,  int n_baseurl_nodes) {
+
+int i;
+char *text;
+char tmp_str[MAX_URL_SIZE];
+char tmp_str_2[MAX_URL_SIZE];
+
+char *path = malloc(MAX_URL_SIZE);
+int nameSize = 0;
+int updated = 0;
+
+av_strlcpy(tmp_str, url, strlen(url)+1);
+char *mpdName = strtok (tmp_str," /");
+
+while ((mpdName =strtok (NULL, "/")) != NULL)
+{
+nameSize = strlen(mpdName);
+}
+
+memset(path, 0, MAX_URL_SIZE* sizeof(char));
+av_strlcpy (path, url, strlen(url)-nameSize+1 );
+
+int rootId = 0;
+xmlNodePtr  *node = NULL;
+for (rootId = n_baseurl_nodes-1; rootId >0; rootId--)
+{
+if ((node = baseurl_nodes[rootId])== NULL) continue;
+
+if (isLocal(xmlNodeGetContent(node)) == FALSE)  {
+break;
+}
+}
+
+node = baseurl_nodes[rootId];
+char *baseurl = xmlNodeGetContent(node);
+char *root_url = (!av_strcasecmp(baseurl, ""))? path: baseurl;
+
+if (node)  {
+xmlNodeSetContent(node, root_url);
+}
+
+int size = strlen(root_url);
+int isRootLocal = isLocal(root_url);
+
+char token ='/';
+if (strncmp(_url[size-1],, 1) != 0)
+{
+strcat(root_url, "/");
+size++;
+}
+
+for (i = 0; i < n_baseurl_nodes; ++i)
+{
+if (i==rootId) continue;
+text = xmlNodeGetContent(baseurl_nodes[i]);
+if (text)
+{
+memset(tmp_str, 0, sizeof(tmp_str));
+
+if (isLocal(text) == TRUE && isRootLocal == FALSE)
+{
+av_strlcpy(tmp_str, root_url, size+1);
+}
+if (text)
+{
+int start = (strncmp(text, , 1) == 0) ? 1: 0;
+memset(tmp_str_2, 0, sizeof(tmp_str_2));
+av_strlcat(tmp_str, text+start, MAX_URL_SIZE);
+xmlFree(text);
+}
+xmlNodeSetContent(baseurl_nodes[i], tmp_str);
+updated = 1;
+}
+}
+
+free(path);
+return updated;
+
+}
+
+static int av_strchr(const char *str, char tok) {
+
+char * pch;
+int *pos;
+int ctr = 0;
+pch=strchr(str, tok);
+pos = av_mallocz( strlen(str)*sizeof(int));
+while (pch!=NULL)  {
+pos[ctr] = pch-str+1;
+pch=strchr(pch+1, tok);
+ctr++;
+}
+
+return pos[ctr-2];
+}
+static void updatePath(AVFormatContext *s, char *baseURL, char *locale) {
+
+int len = strlen(baseURL);
+int upDir=0;
+
+if (!locale  || isLocal(locale) == FALSE)
+return;
+
+char curDirChar[] = "./";
+char parentDirChar[] = "../";
+
+while (av_strstart(locale, curDirChar, NULL) == TRUE) {
+locale = av_strireplace(locale, curDirChar, "");
+}
+
+while (av_strstart(locale, parentDirChar, NULL) == TRUE) {
+locale = av_strireplace(locale, parentDirChar, "");
+upDir++;
+}
+
+char *pch = strchr (baseURL, '/');
+
+if (upDir == 0 || pch == NULL)
+goto finish;
+
+int depth = 0;
+int *marker = (int *)av_mallocz(strlen(baseURL)*sizeof(int));
+
+memset(marker, 0, strlen(baseURL)*sizeof(int));
+
+   

[FFmpeg-devel] [PATCH] h264dec: h264_select_output_frame() - fill correctly has_b_frames based on the level

[Jaroslav Kysela]

The current code does not handle correctly the situation when 
sps->num_reoder_frames
was set using the level. The incorrect has_b_frames results in the wrong DTS 
guess and
malformed output (wrong 'Non-monotonous DTS' fixup).

sps->num_reorder_frames is set in the function 
ff_h264_decode_seq_parameter_set(),
see comment: 'if the maximum delay is not stored in the SPS, derive it based on 
the
level'.

Issue: #6810
---
 libavcodec/h264_slice.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 35dcabd611..04b10656e0 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1287,6 +1287,7 @@ static int h264_select_output_frame(H264Context *h)
 h->mmco_reset = 0;
 
 if (sps->bitstream_restriction_flag ||
+sps->ref_frame_count ||
 h->avctx->strict_std_compliance >= FF_COMPLIANCE_STRICT) {
 h->avctx->has_b_frames = FFMAX(h->avctx->has_b_frames, 
sps->num_reorder_frames);
 }
-- 
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/dashdec: fix memleak of rep_dest->parent null

[Steven Liu]

2017-11-09 16:28 GMT+08:00 Carl Eugen Hoyos :
> Hi!
>
>> Am 09.11.2017 um 00:52 schrieb Steven Liu :
>>
>> fix ticket id: #6820
>
> I find the commit message misleading.
>
>> use the current DASHContext for the rep_dest
>
> This may be better imo.
Pushed and applied this suggestion.


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

Re: [FFmpeg-devel] [PATCH] avformat/img2enc: add frame_pts option for make output filename

[Steven Liu]

2017-10-31 23:47 GMT+08:00 Steven Liu :
> when use frame_pts option, the output image name can be set with PTS
> of current frame.
>
> Signed-off-by: Steven Liu 
> ---
>  doc/muxers.texi   | 9 +
>  libavformat/img2enc.c | 7 +++
>  2 files changed, 16 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 91bbe673c5..af5349e683 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -894,9 +894,18 @@ can be used:
>  ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1 
> "%Y-%m-%d_%H-%M-%S.jpg"
>  @end example
>
> +You can set the file name with current frame's PTS:
> +@example
> +ffmpeg -f v4l2 -r 1 -i /dev/video0 -copyts -f image2 -frame_pts true %d.jpg"
> +@end example
> +
>  @subsection Options
>
>  @table @option
> +@item frame_pts
> +If set to 1, expand the filename with pts from pkt->pts.
> +Default value is 0.
> +
>  @item start_number
>  Start the sequence from the specified number. Default value is 1.
>
> diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
> index d793807b33..be87435b83 100644
> --- a/libavformat/img2enc.c
> +++ b/libavformat/img2enc.c
> @@ -42,6 +42,7 @@ typedef struct VideoMuxData {
>  char target[4][1024];
>  int update;
>  int use_strftime;
> +int frame_pts;
>  const char *muxer;
>  int use_rename;
>  } VideoMuxData;
> @@ -99,6 +100,11 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
>  av_log(s, AV_LOG_ERROR, "Could not get frame filename with 
> strftime\n");
>  return AVERROR(EINVAL);
>  }
> +} else if (img->frame_pts) {
> +if (av_get_frame_filename2(filename, sizeof(filename), 
> img->path, pkt->pts, AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 0) {
> +av_log(s, AV_LOG_ERROR, "Cannot write filename by pts of the 
> frames.");
> +return AVERROR(EINVAL);
> +}
>  } else if (av_get_frame_filename2(filename, sizeof(filename), 
> img->path,
>img->img_number,
>AV_FRAME_FILENAME_FLAGS_MULTIPLE) 
> < 0 &&
> @@ -207,6 +213,7 @@ static const AVOption muxoptions[] = {
>  { "update",   "continuously overwrite one file", OFFSET(update),  
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,   1, ENC },
>  { "start_number", "set first number in the sequence", 
> OFFSET(img_number), AV_OPT_TYPE_INT,  { .i64 = 1 }, 0, INT_MAX, ENC },
>  { "strftime", "use strftime for filename", OFFSET(use_strftime),  
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
> +{ "frame_pts","use current frame pts for filename", 
> OFFSET(frame_pts),  AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
>  { "atomic_writing", "write files atomically (using temporary files and 
> renames)", OFFSET(use_rename), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
>  { NULL },
>  };
> --
> 2.11.0 (Apple Git-81)
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] h264dec: h264_select_output_frame() - fill correctly has_b_frames based on the level

[Hendrik Leppkes]

On Thu, Nov 9, 2017 at 9:38 PM, Jaroslav Kysela  wrote:
> The current code does not handle correctly the situation when 
> sps->num_reoder_frames
> was set using the level. The incorrect has_b_frames results in the wrong DTS 
> guess and
> malformed output (wrong 'Non-monotonous DTS' fixup).
>
> sps->num_reorder_frames is set in the function 
> ff_h264_decode_seq_parameter_set(),
> see comment: 'if the maximum delay is not stored in the SPS, derive it based 
> on the
> level'.
>
> Issue: #6810
> ---
>  libavcodec/h264_slice.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 35dcabd611..04b10656e0 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -1287,6 +1287,7 @@ static int h264_select_output_frame(H264Context *h)
>  h->mmco_reset = 0;
>
>  if (sps->bitstream_restriction_flag ||
> +sps->ref_frame_count ||
>  h->avctx->strict_std_compliance >= FF_COMPLIANCE_STRICT) {
>  h->avctx->has_b_frames = FFMAX(h->avctx->has_b_frames, 
> sps->num_reorder_frames);
>  }

This behavior has actually been intentional in the past to keep the
decode delay lower.
If this is supposed to be changed (which needs to be discussed first),
the std_compliance value should probably be adjusted to NORMAL instead
of strict, instead of adding the additional condition here
(num_reorder_frames is only set from the profile if ref_frame_count is
> 0 in the first place).

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

Re: [FFmpeg-devel] [PATCH] avfilter: slice processing for geq

[Michael Niedermayer]

On Thu, Nov 09, 2017 at 10:22:23AM +, Marc-Antoine ARNAUD wrote:
> Please find the merged patch in attachement.
> 
> Thanks
> 
> Le mer. 8 nov. 2017 à 17:12, Paul B Mahol  a écrit :
> 
> > On 11/8/17, Marc-Antoine ARNAUD  wrote:
> > > This patch will fix the stride issue.
> > > Is it valid for you ?
> > >
> > > Does it required to merge these 2 patches ? (and remove base64 encoding
> > on
> > > the first one)
> >
> > Please merge those two patches, base64 encoding should not be needed
> > (it helps to faster review patches if they are not encoded).
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >

>  vf_geq.c |  124 
> +--
>  1 file changed, 90 insertions(+), 34 deletions(-)
> b41a90fffb5ddef553661007a38659c602f7ce56  
> 0001-avfilter-slice-processing-for-geq.patch
> From ac2a6322fa96835e02a24c31f014fb360e26561f Mon Sep 17 00:00:00 2001
> From: Marc-Antoine Arnaud 
> Date: Thu, 9 Nov 2017 11:19:43 +0100
> Subject: [PATCH] avfilter: slice processing for geq
> Content-Type: text/x-patch; charset="utf-8"

crashes:
./ffmpeg_g -f lavfi -i 
'nullsrc=s=200x200,format=yuv444p16,geq=X*Y/10:sin(X/10)*255:cos(Y/10)*255' 
-vframes 5 -y blah.avi

==24616== Thread 7:
==24616== Invalid write of size 2
==24616==at 0x4F3AAF: slice_geq_filter (vf_geq.c:289)
==24616==by 0x48E4C9: worker_func (pthread.c:50)
==24616==by 0x11DB932: run_jobs (slicethread.c:61)
==24616==by 0x11DBA04: thread_worker (slicethread.c:85)
==24616==by 0xC45D183: start_thread (pthread_create.c:312)
==24616==by 0xC770FFC: clone (clone.S:111)
==24616==  Address 0x1177143e is 93,214 bytes inside a block of size 93,215 
alloc'd
==24616==at 0x4C2A6C5: memalign (vg_replace_malloc.c:727)
==24616==by 0x4C2A760: posix_memalign (vg_replace_malloc.c:876)
==24616==by 0x11B0C43: av_malloc (mem.c:87)
==24616==by 0x11987CC: av_buffer_alloc (buffer.c:72)
==24616==by 0x1198831: av_buffer_allocz (buffer.c:85)
==24616==by 0x1198F29: pool_alloc_buffer (buffer.c:312)
==24616==by 0x1199057: av_buffer_pool_get (buffer.c:349)
==24616==by 0x489D6D: ff_frame_pool_get (framepool.c:222)
==24616==by 0x58F6EB: ff_default_get_video_buffer (video.c:89)
==24616==by 0x58F768: ff_get_video_buffer (video.c:102)
==24616==by 0x4F3BF3: geq_filter_frame (vf_geq.c:312)
==24616==by 0x472FD0: ff_filter_frame_framed (avfilter.c:1104)
==24616==by 0x473800: ff_filter_frame_to_filter (avfilter.c:1252)
==24616==by 0x4739F8: ff_filter_activate_default (avfilter.c:1301)
==24616==by 0x473C12: ff_filter_activate (avfilter.c:1462)
==24616==by 0x478A4F: ff_filter_graph_run_once (avfiltergraph.c:1456)
==24616==by 0x478C72: get_frame_internal (buffersink.c:110)
==24616==by 0x478CCF: av_buffersink_get_frame_flags (buffersink.c:121)
==24616==by 0x441808: lavfi_read_packet (lavfi.c:410)
==24616==by 0x7AC315: ff_read_packet (utils.c:822)
==24616==
--24616-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - 
exiting
--24616-- si_code=80;  Faulting address: 0x0;  sp: 0x40a075db0

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Parse upto 2 keyframes after the edit list end in mov_fix_index.

[Sasi Inguva]

Sorry, about this. i had uncommitted changes. Attaching the patch.

On Thu, Nov 9, 2017 at 12:22 PM, Michael Niedermayer  wrote:

> On Wed, Nov 08, 2017 at 04:13:46PM -0800, Sasi Inguva wrote:
> > Partially fixes t/6699.
> > ---
> >  libavformat/mov.c | 32
> ---
> >  tests/fate/mov.mak|  4 
> >  tests/ref/fate/mov-elst-ends-betn-b-and-i | 31
> ++
> >  3 files changed, 56 insertions(+), 11 deletions(-)
> >  create mode 100644 tests/ref/fate/mov-elst-ends-betn-b-and-i
>
> seems not passing fate here or i did something silly
>
> --- ./tests/ref/fate/mov-elst-ends-betn-b-and-i 2017-11-09 21:14:
> 14.425558802 +0100
> +++ tests/data/fate/mov-elst-ends-betn-b-and-i  2017-11-09
> 21:21:15.957563829 +0100
> @@ -7,25 +7,27 @@
>  #dimensions 0: 320x240
>  #sar 0: 1/1
>  #stream#, dts,pts, duration, size, hash
> -0,  0,  0,1,   115200,
> 4e5dc2b806e394cd666c968f736fecd0
> -0,  1,  1,1,   115200,
> 7a3c7473d44c5f60c07655f6fc0c2ac3
> -0,  2,  2,1,   115200,
> 038254422a603a3270c09cdcd149707b
> -0,  3,  3,1,   115200,
> 7553b6b4547cb23ef8f0392ed5a5d4b0
> -0,  4,  4,1,   115200,
> 6d017ede7f446124af7308667cb0dc41
> -0,  5,  5,1,   115200,
> 77752f0288ae64f857732b8e62e47457
> -0,  6,  6,1,   115200,
> d656833951af99330625f7c6de7685c4
> -0,  7,  7,1,   115200,
> 14338b833e431e566ac98da841600bfe
> -0,  8,  8,1,   115200,
> 07ea95d1659f3c4424a470a546d0df6e
> -0,  9,  9,1,   115200,
> fd05b8cc83072f813e89d394d1f6efc6
> -0, 10, 10,1,   115200,
> 750b82ca5c7e901545e7b1aa69692426
> -0, 11, 11,1,   115200,
> 7347679ab09bc936047368b8caebcaff
> -0, 12, 12,1,   115200,
> 63a23fdd57ac8462b9ffbcb12ab717b3
> -0, 13, 13,1,   115200,
> 705257a1c99693db233e2a3ee027adcf
> -0, 14, 14,1,   115200,
> df861a2ec7a4ef70e82b1c28025e5a48
> -0, 15, 15,1,   115200,
> 2a8b403c077b6b43aa71eaf7d1537713
> -0, 16, 16,1,   115200,
> 973b5cd3ce473e3970dfa96045553172
> -0, 17, 17,1,   115200,
> fc612c0afeae3b6576b5ee2f3f119832
> -0, 18, 18,1,   115200,
> 97074fe5a0b6e7e8470729654092e56c
> -0, 19, 19,1,   115200,
> 8cf9337201065335b3aa4da21dc9b37a
> -0, 20, 20,1,   115200,
> 93ff3589294cc0673af3daee1e7fe42a
> -0, 21, 21,1,   115200,
> c0b6fd870a022f374f9d6c697e8e293d
> +0,  0,  0,1,   115200,
> e10741e5457e9326d5e992e6c05c3e32
> +0,  1,  1,1,   115200,
> 7e20f8729b6b53dc11791927bf4a5aec
> +0,  2,  2,1,   115200,
> 4e5dc2b806e394cd666c968f736fecd0
> +0,  3,  3,1,   115200,
> 7a3c7473d44c5f60c07655f6fc0c2ac3
> +0,  4,  4,1,   115200,
> 038254422a603a3270c09cdcd149707b
> +0,  5,  5,1,   115200,
> 7553b6b4547cb23ef8f0392ed5a5d4b0
> +0,  6,  6,1,   115200,
> 6d017ede7f446124af7308667cb0dc41
> +0,  7,  7,1,   115200,
> 77752f0288ae64f857732b8e62e47457
> +0,  8,  8,1,   115200,
> d656833951af99330625f7c6de7685c4
> +0,  9,  9,1,   115200,
> 14338b833e431e566ac98da841600bfe
> +0, 10, 10,1,   115200,
> 07ea95d1659f3c4424a470a546d0df6e
> +0, 11, 11,1,   115200,
> fd05b8cc83072f813e89d394d1f6efc6
> +0, 12, 12,1,   115200,
> 750b82ca5c7e901545e7b1aa69692426
> +0, 13, 13,1,   115200,
> 7347679ab09bc936047368b8caebcaff
> +0, 14, 14,1,   115200,
> 63a23fdd57ac8462b9ffbcb12ab717b3
> +0, 15, 15,1,   115200,
> 705257a1c99693db233e2a3ee027adcf
> +0, 16, 16,1,   115200,
> df861a2ec7a4ef70e82b1c28025e5a48
> +0, 17, 17,1,   115200,
> 2a8b403c077b6b43aa71eaf7d1537713
> +0, 18, 18,1,   115200,
> 973b5cd3ce473e3970dfa96045553172
> +0, 19, 19,1,   115200,
> fc612c0afeae3b6576b5ee2f3f119832
> +0, 20, 20,1,   115200,
> 97074fe5a0b6e7e8470729654092e56c
> +0, 21, 21,1,   115200,
> 8cf9337201065335b3aa4da21dc9b37a
> +0, 22, 22,1,   115200,
> 93ff3589294cc0673af3daee1e7fe42a
> +0, 23, 23,1,   115200,
> c0b6fd870a022f374f9d6c697e8e293d
> Test mov-elst-ends-betn-b-and-i failed. Look at
> tests/data/fate/mov-elst-ends-betn-b-and-i.err for details.
> make: *** 

Re: [FFmpeg-devel] [PATCH]lavf/dashdec: Fix several memleaks

[Steven Liu]

2017-11-10 2:55 GMT+08:00 Michael Niedermayer :
> On Wed, Nov 08, 2017 at 10:46:27PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes several memleaks found testing ticket #6820 (I
>> cannot reproduce the crash).
>>
>> Please comment, Carl Eugen
>
>>  dashdec.c |   22 +-
>>  1 file changed, 13 insertions(+), 9 deletions(-)
>> 557d3b077beb6b9d73ed401761a318ebd5079c3d  
>> 0001-lavf-dashdec-Fix-several-memleaks.patch
>> From 915eae44e2f9bd7fb5ae78aa697338f348db3e08 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Wed, 8 Nov 2017 22:44:06 +0100
>> Subject: [PATCH] lavf/dashdec: Fix several memleaks.
>
> probably ok but iam not maintainer of this

Tested passed.

Pushed

Thanks
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Complexity theory is the science of finding the exact solution to an
> approximation. Benchmarking OTOH is finding an approximation of the exact
>
> ___
> 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 1/2] aptx: implement the aptX bluetooth codec

[Rostislav Pehlivanov]

On 9 November 2017 at 22:48, Aurelien Jacobs  wrote:

> On Thu, Nov 09, 2017 at 02:32:44PM +, Rostislav Pehlivanov wrote:
> > On 9 November 2017 at 13:37, Aurelien Jacobs  wrote:
> >
> > > On Thu, Nov 09, 2017 at 12:52:34AM +, Rostislav Pehlivanov wrote:
> > > > On 8 November 2017 at 22:41, Aurelien Jacobs 
> wrote:
> > > >
> > > > > On Wed, Nov 08, 2017 at 06:26:03PM +0100, Michael Niedermayer
> wrote:
> > > > > > On Wed, Nov 08, 2017 at 02:06:09PM +0100, Aurelien Jacobs wrote:
> > > > > > [...]
> > > > > > > +}
> > > > > > > +
> > > > > > > +/*
> > > > > > > + * Compute the convolution of the signal with the
> coefficients,
> > > and
> > > > > reduce
> > > > > > > + * to 24 bits by applying the specified right shifting.
> > > > > > > + */
> > > > > > > +av_always_inline
> > > > > > > +static int32_t aptx_qmf_convolution(FilterSignal *signal,
> > > > > > > +const int32_t
> > > coeffs[FILTER_TAPS],
> > > > > > > +int shift)
> > > > > > > +{
> > > > > > > +int32_t *sig = >buffer[signal->pos];
> > > > > > > +int64_t e = 0;
> > > > > > > +
> > > > > >
> > > > > > > +for (int i = 0; i < FILTER_TAPS; i++)
> > > > > >
> > > > > > "for (int" is something we avoided as some comilers didnt like
> it,
> > > > > > iam not sure if this is still true but there are none in the
> codebase
> > > > >
> > > > > If you insist on this I will of course change it, but hey, we
> require
> > > > > a C99 compiler since a long time and we use so many features of C99
> > > > > that I really don't get why we couldn't use "for (int".
> > > > > I can't imagine that any relevant C compiler would not support this
> > > > > nowadays !
> > > > > What I propose is to get this in as is, and see if anyone encounter
> > > > > issue with any compiler. If any issue arise, I will of course send
> a
> > > > > patch to fix it.
> > > > >
> > > > > Here is an updated patch.
> > > > >
> > > > >
> > > > Send another patch because some people are beyond convincing and its
> > > really
> > > > pissing me off. Really. In particular maybe those compiler writers at
> > > > Microsoft who seem to think shipping something that doesn't support
> such
> > > a
> > > > simple yet important feature is important.
> > > > Or maybe users who don't want to update a 6 year old version of msvc.
> > > > Or maybe us because we support compiling with msvc at all when its
> > > clearly
> > > > _not_ a C compiler and this project is written in C.
> > >
> > > Here you go.
> > >
> > > Just for reference, splitting the déclaration out of the for loop added
> > > 19 lines in this file, which is a 2.3 % increase of the line count.
> > > (I'm not sure this file is representative of the rest of the code base)
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > >
> > Still some issues:
> >
> > 1.) You need to set AVCodec->supported_samplerates for the encoder, since
> > in the raw aptx muxer you always set the samplerate as 44100. Does the
> > codec/container support other samplerates?
>
> The codec is actually samplerate agnostic.
> It only convert each group of 4 samples to a 16 bit integer.
> There is no other information than the samples themselves in the
> encoded stream. No header, no frame size, no samplerate.
> And there is no standard container used to store aptX along with
> the needed metadata such as the samplerate. It is meant to be streamed
> thru bluetooth using the A2DP "protocol" which includes its own metadata
> signaling with samplerate.
> The raw muxer/demuxer that I implemented is mostly for testing purpose,
> not really for practical use.
> So with this in mind, I don't think that it make any sense to set
> AVCodec->supported_samplerates.
> I don't think I set the samplerate anywhere in the encoder.
> I only set it in the demuxer to a default 44100 just to be able to
> playback test files even though there is no way to know its actual
> samplerate.
>
>
Ah, I see.
In this case set the allowed samplerate to 48000 on the encoder side and
the output samplerate in the demuxer to the same. Pretty much all systems,
be it bluetooth, I2S or some other interface run at 48khz so that's what we
should set it so its as compatible as possible. Nothing but systems which
handle redbook cds use 44100hz.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [Patch] Fix for ticket 6658 (Dash demuxer segfault)

[Carl Eugen Hoyos]

2017-11-09 1:19 GMT+01:00 Colin NG :
> - Add a function to handle the base URL Processing described in section 5.6.5 
> of IEC_23009-1.
>
> - Fix for downloading content with byte range selection

This sounds as if the patch should be split in two.

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

Re: [FFmpeg-devel] [PATCH 03/11] avutil: detect when AVX-512 is available

[James Almer]

On 11/9/2017 8:58 AM, James Darnley wrote:
> ---
> I've changed this patch slightly because I discovered that it would cause an
> illegal instruction exception on much older processors (probably all without
> AVX).  I was running xgetbv() almost uncontitionally.  Now it is a little more
> like what is the in x264 patch.
> 
>  libavutil/x86/cpu.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/libavutil/x86/cpu.c b/libavutil/x86/cpu.c
> index f33088c8c7..589fdef7da 100644
> --- a/libavutil/x86/cpu.c
> +++ b/libavutil/x86/cpu.c
> @@ -97,6 +97,7 @@ int ff_get_cpu_flags_x86(void)
>  int max_std_level, max_ext_level, std_caps = 0, ext_caps = 0;
>  int family = 0, model = 0;
>  union { int i[3]; char c[12]; } vendor;
> +int xcr0_lo = 0, xcr0_hi = 0;
>  
>  if (!cpuid_test())
>  return 0; /* CPUID not supported */
> @@ -132,8 +133,8 @@ int ff_get_cpu_flags_x86(void)
>  /* Check OXSAVE and AVX bits */
>  if ((ecx & 0x1800) == 0x1800) {
>  /* Check for OS support */
> -xgetbv(0, eax, edx);
> -if ((eax & 0x6) == 0x6) {
> +xgetbv(0, xcr0_lo, xcr0_hi);
> +if ((xcr0_lo & 0x6) == 0x6) {
>  rval |= AV_CPU_FLAG_AVX;
>  if (ecx & 0x1000)
>  rval |= AV_CPU_FLAG_FMA3;
> @@ -154,6 +155,13 @@ int ff_get_cpu_flags_x86(void)
>  if (ebx & 0x0100)
>  rval |= AV_CPU_FLAG_BMI2;
>  }
> +#if HAVE_AVX512 /* F, CD, BW, DQ, VL */

Nit: Maybe move this chunk inside the HAVE_AVX2 block, at the end of it,
right above the BMI checks.

> +if ((xcr0_lo & 0xe6) == 0xe6) {

Nit: The proper check here i think would be

if ((xcr0_lo & 0xe0) == 0xe0) {
if ((rval & AV_CPU_FLAG_AVX) && (ebx & 0xd003) == 0xd003)
rval |= AV_CPU_FLAG_AVX512;
}

But it's functionally the same.

> +if ((ebx & 0xd003) == 0xd003)
> +rval |= AV_CPU_FLAG_AVX512;
> +
> +}
> +#endif
>  }
>  
>  cpuid(0x8000, max_ext_level, ebx, ecx, edx);
> 

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

Re: [FFmpeg-devel] [PATCH 04/11] avutil: add alignment needed for AVX-512

[James Almer]

On 11/9/2017 8:58 AM, James Darnley wrote:
> ---
> This patch gained the alignmnet increase in mem.c
> 
>  libavutil/mem.c | 2 +-
>  libavutil/x86/cpu.c | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/mem.c b/libavutil/mem.c
> index 6ad409daf4..cdf539306f 100644
> --- a/libavutil/mem.c
> +++ b/libavutil/mem.c
> @@ -61,7 +61,7 @@ void  free(void *ptr);
>  
>  #include "mem_internal.h"
>  
> -#define ALIGN (HAVE_AVX ? 32 : 16)
> +#define ALIGN (HAVE_AVX512 ? 64 : HAVE_AVX ? 32 : 16)

Wrap the second ternary conditional operation with brackets, just to be
safe.

>  
>  /* NOTE: if you want to override these functions with your own
>   * implementations (not recommended) you have to link libav* as
> diff --git a/libavutil/x86/cpu.c b/libavutil/x86/cpu.c
> index 589fdef7da..01b3c39c1e 100644
> --- a/libavutil/x86/cpu.c
> +++ b/libavutil/x86/cpu.c
> @@ -246,6 +246,8 @@ size_t ff_get_cpu_max_align_x86(void)
>  {
>  int flags = av_get_cpu_flags();
>  
> +if (flags & AV_CPU_FLAG_AVX512)
> +return 64;
>  if (flags & (AV_CPU_FLAG_AVX2  |
>   AV_CPU_FLAG_AVX   |
>   AV_CPU_FLAG_XOP   |
> 

LGTM if all the align functions used in mem.c accept the value 64.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 05/11] avcodec: add stride alignment needed for AVX-512

[James Almer]

On 11/9/2017 8:58 AM, James Darnley wrote:
> ---
>  configure | 2 ++
>  libavcodec/internal.h | 4 +++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index 146a87324c..fce8030d91 100755
> --- a/configure
> +++ b/configure
> @@ -1886,6 +1886,7 @@ ARCH_FEATURES="
>  local_aligned
>  simd_align_16
>  simd_align_32
> +simd_align_64
>  "
>  
>  BUILTIN_LIST="
> @@ -2385,6 +2386,7 @@ fast_clz_if_any="aarch64 alpha avr32 mips ppc x86"
>  fast_unaligned_if_any="aarch64 ppc x86"
>  simd_align_16_if_any="altivec neon sse"
>  simd_align_32_if_any="avx"
> +simd_align_64_if_any="avx512"
>  
>  # system capabilities
>  symver_if_any="symver_asm_label symver_gnu_asm"
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> index 7748f09f54..84070431ed 100644
> --- a/libavcodec/internal.h
> +++ b/libavcodec/internal.h
> @@ -87,7 +87,9 @@
>  
>  #define FF_SIGNBIT(x) ((x) >> CHAR_BIT * sizeof(x) - 1)
>  
> -#if HAVE_SIMD_ALIGN_32
> +#if HAVE_SIMD_ALIGN_64
> +#   define STRIDE_ALIGN 64 /* AVX-512 */
> +#elif HAVE_SIMD_ALIGN_32
>  #   define STRIDE_ALIGN 32
>  #elif HAVE_SIMD_ALIGN_16
>  #   define STRIDE_ALIGN 16
> 

LGTM, but I'd really like to find a way to start using
av_get_cpu_max_align() as it was meant to be done when it was
introduced, instead of keeping hardcoding alignment based on configure
time options.

Maybe adding a line to the av_force_cpu_flags() and
av_set_cpu_flags_mask() doxy stating you should reinit all your decoder
and encoder contexts after calling them or similar.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/11] configure: test whether x86 assembler supports AVX-512

[James Almer]

On 11/9/2017 8:58 AM, James Darnley wrote:
> ---
>  configure | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/configure b/configure
> index f396abda5b..146a87324c 100755
> --- a/configure
> +++ b/configure
> @@ -406,6 +406,7 @@ Optimization options (experts only):
>--disable-fma3   disable FMA3 optimizations
>--disable-fma4   disable FMA4 optimizations
>--disable-avx2   disable AVX2 optimizations
> +  --disable-avx512 disable AVX-512 optimizations
>--disable-aesni  disable AESNI optimizations
>--disable-armv5tedisable armv5te optimizations
>--disable-armv6  disable armv6 optimizations
> @@ -1840,6 +1841,7 @@ ARCH_EXT_LIST_X86_SIMD="
>  amd3dnowext
>  avx
>  avx2
> +avx512
>  fma3
>  fma4
>  mmx
> @@ -2364,6 +2366,7 @@ xop_deps="avx"
>  fma3_deps="avx"
>  fma4_deps="avx"
>  avx2_deps="avx"
> +avx512_deps="avx2"
>  
>  mmx_external_deps="x86asm"
>  mmx_inline_deps="inline_asm x86"
> @@ -5664,6 +5667,7 @@ EOF
>  elf*) enabled debug && append X86ASMFLAGS $x86asm_debug ;;
>  esac
>  
> +check_x86asm "vmovdqa32 [eax]{k1}{z}, zmm0"|| disable 
> avx512_external
>  check_x86asm "vextracti128 xmm0, ymm0, 0"  || disable 
> avx2_external
>  check_x86asm "vpmacsdd xmm0, xmm1, xmm2, xmm3" || disable 
> xop_external
>  check_x86asm "vfmaddps ymm0, ymm1, ymm2, ymm3" || disable 
> fma4_external
> @@ -6794,6 +6798,7 @@ if enabled x86; then
>  echo "AESNI enabled ${aesni-no}"
>  echo "AVX enabled   ${avx-no}"
>  echo "AVX2 enabled  ${avx2-no}"
> +echo "AVX-512 enabled   ${avx512-no}"
>  echo "XOP enabled   ${xop-no}"
>  echo "FMA3 enabled  ${fma3-no}"
>  echo "FMA4 enabled  ${fma4-no}"
> 

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

Re: [FFmpeg-devel] [PATCH 02/11] avutil: add AVX-512 flags

[James Almer]

On 11/9/2017 8:58 AM, James Darnley wrote:
> ---
>  libavutil/cpu.c   | 6 +-
>  libavutil/cpu.h   | 1 +
>  libavutil/tests/cpu.c | 1 +
>  libavutil/x86/cpu.h   | 2 ++
>  4 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/cpu.c b/libavutil/cpu.c
> index c8401b8258..6548cc3042 100644
> --- a/libavutil/cpu.c
> +++ b/libavutil/cpu.c
> @@ -80,7 +80,8 @@ void av_force_cpu_flags(int arg){
>  AV_CPU_FLAG_XOP  |
>  AV_CPU_FLAG_FMA3 |
>  AV_CPU_FLAG_FMA4 |
> -AV_CPU_FLAG_AVX2 ))
> +AV_CPU_FLAG_AVX2 |
> +AV_CPU_FLAG_AVX512   ))
>  && !(arg & AV_CPU_FLAG_MMX)) {
>  av_log(NULL, AV_LOG_WARNING, "MMX implied by specified flags\n");
>  arg |= AV_CPU_FLAG_MMX;
> @@ -126,6 +127,7 @@ int av_parse_cpu_flags(const char *s)
>  #define CPUFLAG_AVX2 (AV_CPU_FLAG_AVX2 | CPUFLAG_AVX)
>  #define CPUFLAG_BMI2 (AV_CPU_FLAG_BMI2 | AV_CPU_FLAG_BMI1)
>  #define CPUFLAG_AESNI(AV_CPU_FLAG_AESNI| CPUFLAG_SSE42)
> +#define CPUFLAG_AVX512   (AV_CPU_FLAG_AVX512   | CPUFLAG_AVX2)
>  static const AVOption cpuflags_opts[] = {
>  { "flags"   , NULL, 0, AV_OPT_TYPE_FLAGS, { .i64 = 0 }, INT64_MIN, 
> INT64_MAX, .unit = "flags" },
>  #if   ARCH_PPC
> @@ -154,6 +156,7 @@ int av_parse_cpu_flags(const char *s)
>  { "3dnowext", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = CPUFLAG_3DNOWEXT  
>},.unit = "flags" },
>  { "cmov", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_CMOV  
>},.unit = "flags" },
>  { "aesni"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = CPUFLAG_AESNI 
>},.unit = "flags" },
> +{ "avx512"  , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = CPUFLAG_AVX512
>},.unit = "flags" },
>  #elif ARCH_ARM
>  { "armv5te",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> AV_CPU_FLAG_ARMV5TE  },.unit = "flags" },
>  { "armv6",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_ARMV6 
>},.unit = "flags" },
> @@ -216,6 +219,7 @@ int av_parse_cpu_caps(unsigned *flags, const char *s)
>  { "3dnowext", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> AV_CPU_FLAG_3DNOWEXT },.unit = "flags" },
>  { "cmov", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_CMOV  
>},.unit = "flags" },
>  { "aesni",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_AESNI 
>},.unit = "flags" },
> +{ "avx512"  , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> AV_CPU_FLAG_AVX512   },.unit = "flags" },
>  
>  #define CPU_FLAG_P2 AV_CPU_FLAG_CMOV | AV_CPU_FLAG_MMX
>  #define CPU_FLAG_P3 CPU_FLAG_P2 | AV_CPU_FLAG_MMX2 | AV_CPU_FLAG_SSE
> diff --git a/libavutil/cpu.h b/libavutil/cpu.h
> index 9e5d40affe..91523f3f5a 100644
> --- a/libavutil/cpu.h
> +++ b/libavutil/cpu.h
> @@ -55,6 +55,7 @@
>  #define AV_CPU_FLAG_FMA30x1 ///< Haswell FMA3 functions
>  #define AV_CPU_FLAG_BMI10x2 ///< Bit Manipulation Instruction 
> Set 1
>  #define AV_CPU_FLAG_BMI20x4 ///< Bit Manipulation Instruction 
> Set 2
> +#define AV_CPU_FLAG_AVX512 0x10 ///< AVX-512 functions

NIt: "AVX-512 functions: requires OS support even if YMM/ZMM registers
aren't used"

That's more in line with the AVX and AVX2 lines.

>  
>  #define AV_CPU_FLAG_ALTIVEC  0x0001 ///< standard
>  #define AV_CPU_FLAG_VSX  0x0002 ///< ISA 2.06
> diff --git a/libavutil/tests/cpu.c b/libavutil/tests/cpu.c
> index f02a54cbbb..ce45b715a0 100644
> --- a/libavutil/tests/cpu.c
> +++ b/libavutil/tests/cpu.c
> @@ -73,6 +73,7 @@ static const struct {
>  { AV_CPU_FLAG_BMI1,  "bmi1"   },
>  { AV_CPU_FLAG_BMI2,  "bmi2"   },
>  { AV_CPU_FLAG_AESNI, "aesni"  },
> +{ AV_CPU_FLAG_AVX512,"avx512" },
>  #endif
>  { 0 }
>  };
> diff --git a/libavutil/x86/cpu.h b/libavutil/x86/cpu.h
> index 309b8e746c..7f4e5d08bb 100644
> --- a/libavutil/x86/cpu.h
> +++ b/libavutil/x86/cpu.h
> @@ -50,6 +50,7 @@
>  #define X86_FMA4(flags) CPUEXT(flags, FMA4)
>  #define X86_AVX2(flags) CPUEXT(flags, AVX2)
>  #define X86_AESNI(flags)CPUEXT(flags, AESNI)
> +#define X86_AVX512(flags)   CPUEXT(flags, AVX512)
>  
>  #define EXTERNAL_AMD3DNOW(flags)CPUEXT_SUFFIX(flags, _EXTERNAL, AMD3DNOW)
>  #define EXTERNAL_AMD3DNOWEXT(flags) CPUEXT_SUFFIX(flags, _EXTERNAL, 
> AMD3DNOWEXT)
> @@ -79,6 +80,7 @@
>  #define EXTERNAL_AVX2_FAST(flags)   CPUEXT_SUFFIX_FAST2(flags, _EXTERNAL, 
> AVX2, AVX)
>  #define EXTERNAL_AVX2_SLOW(flags)   CPUEXT_SUFFIX_SLOW2(flags, _EXTERNAL, 
> AVX2, AVX)
>  #define EXTERNAL_AESNI(flags)   CPUEXT_SUFFIX(flags, _EXTERNAL, AESNI)
> +#define EXTERNAL_AVX512(flags)  CPUEXT_SUFFIX(flags, _EXTERNAL, AVX512)
>  
>  #define INLINE_AMD3DNOW(flags)  CPUEXT_SUFFIX(flags, _INLINE, AMD3DNOW)
>  #define INLINE_AMD3DNOWEXT(flags)   CPUEXT_SUFFIX(flags, _INLINE, 
> 

Re: [FFmpeg-devel] [DEVEL][PATCH] ffmpeg: fix channel_layout bug on non-default layout

[pkv.stream]

Le 10/11/2017 à 1:12 AM, Michael Niedermayer a écrit :

On Thu, Nov 09, 2017 at 09:37:33PM +0100, pkv.stream wrote:

Hi Michael,


  ffmpeg_opt.c |   11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)
2af07f4366efdfaf1018bb2ea29be672befe0823  
0001-ffmpeg-fix-channel_layout-bug-on-non-default-layout.patch
 From 4ec55dc88923108132307b41300a1abddf32e6f7 Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Mon, 2 Oct 2017 11:14:31 +0200
Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout

Fix for ticket 6706.
The -channel_layout option was not working when the channel layout was not
a default one (ex: for 4 channels, quad was interpreted as 4.0 which is
the default layout for 4 channels; or octagonal interpreted as 7.1).
This led to the spurious auto-insertion of an auto-resampler filter
remapping the channels even if input and output had identical channel
layouts.
The fix operates by directly calling the channel layout if defined in
options. If the layout is undefined, the default layout is selected as
before the fix.
---
  ffmpeg_opt.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 100fa76..cf5a63c 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1804,6 +1804,12 @@ static OutputStream *new_audio_stream(OptionsContext *o, 
AVFormatContext *oc, in
  MATCH_PER_STREAM_OPT(audio_channels, i, audio_enc->channels, oc, st);
+AVDictionaryEntry *output_layout = av_dict_get(o->g->codec_opts,
+   "channel_layout",
+   NULL, 
AV_DICT_MATCH_CASE);

This doesnt look right

not an issue of the patch as such but
why is the channel_layout option per file and not per stream?


just my ignorance; do you mean this is not the right way to retrieve
the channel_layout option from an audio stream ?

I think there is more buggy with how the channel_layout is handled

try this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout 5 test.wav
and this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout:a 5 test.wav

while it may appear that the are both working this is deceiving.
I think only the channel number gets actually used in the 2nd case

Look at what your code with av_dict_get() reads.
It does not obtain the 5 in the 2nd case


Hi Michael,

Thanks for the explanation;
actually I have the impression that it's worse than that.
In the second case indeed av_dict_get() doesn't get the 5 (was not aware 
of channel_layout:a syntax , is it documented somewhere ?)
In the first case, the 5 is recognized but the auto resampler spouts 
errors :


ffmpeg -loglevel debug -channel_layout octagonal -i test.mkv 
-channel_layout 5 test.wav

...
Successfully opened the file.
Parsing a group of options: output url test.wav.
Applying option channel_layout (set channel layout) with argument 5.
Successfully parsed a group of options.
Opening an output file: test.wav.
[file @ 018F66CF5C20] Setting default whitelist 'file,crypto'
Successfully opened the file.
Stream mapping:
  Stream #0:1 -> #0:0 (pcm_s24le (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
cur_dts is invalid (this is harmless if it occurs once at the start per 
stream)

    Last message repeated 3 times
detected 8 logical cores
[graph_0_in_0_1 @ 018F66D05760] Setting 'time_base' to value '1/48000'
[graph_0_in_0_1 @ 018F66D05760] Setting 'sample_rate' to value '48000'
[graph_0_in_0_1 @ 018F66D05760] Setting 'sample_fmt' to value 's32'
[graph_0_in_0_1 @ 018F66D05760] Setting 'channel_layout' to value 
'0x737'
[graph_0_in_0_1 @ 018F66D05760] tb:1/48000 samplefmt:s32 
samplerate:48000 chlayout:0x737

[format_out_0_0 @ 018F687E0C60] Setting 'sample_fmts' to value 's16'
[format_out_0_0 @ 018F687E0C60] Setting 'channel_layouts' to value '0x5'
[format_out_0_0 @ 018F687E0C60] auto-inserting filter 
'auto_resampler_0' between the filter 'Parsed_anull_0' and the filter 
'format_out_0_0'
[AVFilterGraph @ 018F66D48DE0] query_formats: 4 queried, 6 merged, 3 
already done, 0 delayed
[auto_resampler_0 @ 018F687E0EC0] [SWR @ 018F66D2CE80] Using 
fltp internally between filters
[auto_resampler_0 @ 018F687E0EC0] [SWR @ 018F66D2CE80] Output 
channel layout '2 channels (FL+FC)' is not supported
[auto_resampler_0 @ 018F687E0EC0] Failed to configure output pad on 
auto_resampler_0

Error reinitializing filters!
Failed to inject frame into filter network: Invalid argument
Error while processing the decoded data for stream #0:1

Not sure why swr_build_matrix is issuing an error. Is this a case of a 
bug hiding another bug ? namely (1) wrongly matrixing to default 
channel_layout instead of real one  , (2)  auto-inserted filter which 
seems only able to deal with non default layout ( that is to say,  
anything other than mono stereo 2.1 4.0 5.0 5.1 7.1 hexadecagonal).


If you have ideas to 

Re: [FFmpeg-devel] [PATCH 1/2] aptx: implement the aptX bluetooth codec

[Aurelien Jacobs]

On Thu, Nov 09, 2017 at 03:22:21AM +0100, Michael Niedermayer wrote:
> On Wed, Nov 08, 2017 at 11:41:16PM +0100, Aurelien Jacobs wrote:
> > On Wed, Nov 08, 2017 at 06:26:03PM +0100, Michael Niedermayer wrote:
> > > On Wed, Nov 08, 2017 at 02:06:09PM +0100, Aurelien Jacobs wrote:
> > > [...]
> > > > +}
> > > > +
> > > > +/*
> > > > + * Compute the convolution of the signal with the coefficients, and 
> > > > reduce
> > > > + * to 24 bits by applying the specified right shifting.
> > > > + */
> > > > +av_always_inline
> > > > +static int32_t aptx_qmf_convolution(FilterSignal *signal,
> > > > +const int32_t coeffs[FILTER_TAPS],
> > > > +int shift)
> > > > +{
> > > > +int32_t *sig = >buffer[signal->pos];
> > > > +int64_t e = 0;
> > > > +
> > > 
> > > > +for (int i = 0; i < FILTER_TAPS; i++)
> > > 
> > > "for (int" is something we avoided as some comilers didnt like it,
> > > iam not sure if this is still true but there are none in the codebase
> > 
> > If you insist on this I will of course change it, but hey, we require
> 
> me personally, not really, i used "for (int" style as long as
> i can remember outside ffmpeg but i also would like to keep supportng
> all platforms ...

OK, got it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode

[Nicolas George]

Le nonidi 19 brumaire, an CCXXVI, Derek Buitenhuis a écrit :
> Is it more sensible to actually return an error here? Otherwise it's just 
> enabling
> future incorrect code; API users tend to ignore stderr warnings. I guess an 
> argument
> could be made both ways.

Actually, if the use of the API is clearly wrong, then an immediate
crash with an assert failure would be even better, IMHO, because it
cannot be ignored. But if there is code out there doing it, then a soft
transition with a warning would be in order.

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 3/3] avformat/opensrt: add Haivision Open SRT protocol

[nablet developer]

On 10-Nov-17 03:35, Nicolas George wrote:

Can you explain the logic of the implementation? I have a hard time
understanding why you call the tcp protocol from here after forcing it
to call back here.

Regards,


the idea is to avoid code duplication as much as possible, and try to 
re-use existing, well-maintained and well-tested code.

this time I've chosen tcp.c rather udp.c for two reasons:
1. SRT socket API actually resembles tcp, as it uses connection and 
related methods (connect/listen/accept)

2. tcp.c code is much more clean and straightforward rather udp.c
the first thing which obviously differs between tcp and srt are socket 
api calls, but there is direct mapping for most of them, e.g.:

socket -> srt_socket
connect -> srt_connect
listen -> srt_listen
very few of srt socket calls are different, e.g. srt doesn't provide 
send/recv, but provides sendmsg/recvmsg, also it doesn't provide poll, 
but has epoll_wait.
with simple wrappers, it allows to use existing logic of tcp.c and 
network.c without modifications.
for calling back srt from tcp, that's the second difference - srt has 
lots of additional socket options,
and some of these socket options has to be set prior to connection, 
others after connection (called pre and post options in srt).

Haivision explicitly requested to add these options into ffmpeg component.
so, there are two calls back in tcp_open - to set options just before 
connection, and to set options right after connections.
if you have some advice on how it can be implemented better, I am open 
for suggestions and advises.

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

Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[Clément Bœsch]

On Fri, Nov 10, 2017 at 12:18:07AM +0100, Aurelien Jacobs wrote:
[...]
> > >   Also, allowing this but not the mixed statements and declarations means
> > >   this is a style decision and not a technical one anymore.
> 
> Allowing limiting the scope of a variable to a loop seems like a
> technical decision to me, but I understand that some consider it more
> of a style decision.
> 

What I meant by that is that currently the for (int ..) form is prevented
by style but also technical argument (compiler compatibility). If you
remove the technical argument by breaking the compiler compatibility of
such form, what remains is only a style choice to make between mixed
stat/decl and for (int ...); AFAIK there is no difference for a compiler
between the two.

-- 
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] aacenc: WIP support for PCEs

[pkv.stream]

Le 09/11/2017 à 4:43 AM, Rostislav Pehlivanov a écrit :

On 18 October 2017 at 11:05, pkv.stream  wrote:


Le 02/10/2017 à 8:39 PM, Rostislav Pehlivanov a écrit :


On 2 October 2017 at 18:43, pkv.stream  wrote:

Le 02/10/2017 à 7:23 PM, Michael Niedermayer a écrit :

On Mon, Oct 02, 2017 at 12:52:53AM +0200, pkv.stream wrote:

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

aacenc.h |  239 ++

+++--
1 file changed, 233 insertions(+), 6 deletions(-)
929275fe34af4d0048bac2be928957288cb75ddd
0001-avcodec-aacenc-PCE-for-al
l-ffmpeg-usual-layouts.patch
   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

this seems not to apply cleanly here, did i miss something ?

Hi Michael

this needs to be applied after the initial patch by atomnuker which he
did
not apply since this required work.
What i submitted was not aimed at being pushed since there is probably
still work to do.
Depending on what he wants to do with his patch, I'll resubmit a working
patch later, properly rebased.
Sorry about the mess.
regards


Applying: avcodec/aacenc: PCE for all ffmpeg usual layouts

error: sha1 information is lacking or useless (libavcodec/aacenc.h).
error: could not build fake ancestor
Patch failed at 0001 avcodec/aacenc: PCE for all ffmpeg usual layouts
The copy of the patch that failed is found in: .git/rebase-apply/patch


[...]



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



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



Give me a few hours and I'll test it and submit a v2 of my patch with your
improvements.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Hi

any updates ?

regards


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



Hi,
Very sorry it took me this long but I finally got motivated and got around
to checking your patch

I have to say I'm impressed, everything works perfectly, decodes fine and
the mappings were all fine. This is a big feature which many people have
requested and complained the encoder lacks support for.

I've done some minor changes to the code on the encoder side (an INFO print
instead of a warning), to the comments (just alignment) and for the
ambisonic layouts (made them use the defines) and I've pushed it.

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


Hi atomnuker,

that's wonderful;

there are two things also:

1) there are changes to make to the list of channel layouts not 
requiring PCE


==> AV_CH_LAYOUT_5POINT0 to AV_CH_LAYOUT_5POINT0_BACK since the previous 
is 5.0(side) while the latter is 5.0 which is what is in spec (table 
1.19 ISO/IEC 14496-3:200X(E) or table 42 ISO/IEC 13818-7:2004(E) )


see patch in attachment (can't be applied directly due to rebasing 
issues from your initial patch)


2) for everything to work I had to also apply the patch from here:

http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/217357.html

If you ffmpeg -loglevel debug , you will see that on non-default channel 
layouts, there is an auto insertion of a resampler filter : the 
channel_layout option is not passed correctly in the chain.


for instance: ffmpeg -channel_layout octagonal -i input.wav -c:a aac 
-channel_layout octagonal out.mkv will matrix the input from octagonal 
to 7.1 before the encoding.


Check ticket 6706 for details of the issue.

I am not knowledgeable enough to be sure my fix is correct; it's working 
for sure, but I've had very few feedback (only Michael and Moritz about 
styling issues).


Maybe you could have a look.

Regards

pkv


From 847334071ff13a00d54b9f55ccf29c7553ab83f1 Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Mon, 6 Nov 2017 10:03:47 +0100
Subject: [PATCH] avcodec/aacenc: fix default channels

Fix default channels not requiring PCE. Replaces 5.0 and 5.1 definitions; 7.1 
should be AV_CH_LAYOUT_7POINT1_WIDE_BACK