Re: [FFmpeg-devel] [PATCH] hlsenc: Fixing HLS_TEMP_FILE usage with, HLS_SECOND_LEVEL_SEGMENT_... flags

[Liu Steven]

> 在 2018年2月20日，上午5:00，Bodecs Bela  写道：
> 
> Dear All,
> 
> Currently using HLS_TEMP together with HLS_SECOND_LEVEL_SEGMENT_DURATION
> and/or HLS_SECOND_LEVEL_SEGMENT_SIZE gives error at end of each segment
> writing and the final segment file names do not contain the desired
> data. This patch fixes this bug by delaying the initilization of
> original segment filename until end of actual temp file renaming.
> This will skip the interfering.
> 
> Please review this bug fix. Thank you in advance.
> 
> 
> best regards,
> 
> Bela Bodecs
> 
> <0001-hlsenc-Fixing-HLS_TEMP_FILE-usage-with-HLS_SECOND_LE.patch>

LGTM


Thanks
Steven

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

[FFmpeg-devel] [PATCH] lavfi/vf_transpose: fix regression with semiplanar formats

[Rodger Combs]

(e.g. nv12)

Regression since 7b19e76aeb0ace57b99aaef156bbfe592e43e65e
---
 libavfilter/vf_transpose.c  | 50 +++--
 tests/ref/fate/filter-pixfmts-transpose |  8 +++---
 2 files changed, 33 insertions(+), 25 deletions(-)

diff --git a/libavfilter/vf_transpose.c b/libavfilter/vf_transpose.c
index 3ff4cb4249..74a4bbcf58 100644
--- a/libavfilter/vf_transpose.c
+++ b/libavfilter/vf_transpose.c
@@ -52,6 +52,14 @@ enum TransposeDir {
 TRANSPOSE_CLOCK_FLIP,
 };
 
+typedef struct TransVtable {
+void (*transpose_8x8)(uint8_t *src, ptrdiff_t src_linesize,
+  uint8_t *dst, ptrdiff_t dst_linesize);
+void (*transpose_block)(uint8_t *src, ptrdiff_t src_linesize,
+uint8_t *dst, ptrdiff_t dst_linesize,
+int w, int h);
+} TransVtable;
+
 typedef struct TransContext {
 const AVClass *class;
 int hsub, vsub;
@@ -61,11 +69,7 @@ typedef struct TransContext {
 int passthrough;///< PassthroughType, landscape passthrough mode 
enabled
 int dir;///< TransposeDir
 
-void (*transpose_8x8)(uint8_t *src, ptrdiff_t src_linesize,
-  uint8_t *dst, ptrdiff_t dst_linesize);
-void (*transpose_block)(uint8_t *src, ptrdiff_t src_linesize,
-uint8_t *dst, ptrdiff_t dst_linesize,
-int w, int h);
+TransVtable vtables[4];
 } TransContext;
 
 static int query_formats(AVFilterContext *ctx)
@@ -233,19 +237,22 @@ static int config_props_output(AVFilterLink *outlink)
 else
 outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
 
-switch (s->pixsteps[0]) {
-case 1: s->transpose_block = transpose_block_8_c;
-s->transpose_8x8   = transpose_8x8_8_c;  break;
-case 2: s->transpose_block = transpose_block_16_c;
-s->transpose_8x8   = transpose_8x8_16_c; break;
-case 3: s->transpose_block = transpose_block_24_c;
-s->transpose_8x8   = transpose_8x8_24_c; break;
-case 4: s->transpose_block = transpose_block_32_c;
-s->transpose_8x8   = transpose_8x8_32_c; break;
-case 6: s->transpose_block = transpose_block_48_c;
-s->transpose_8x8   = transpose_8x8_48_c; break;
-case 8: s->transpose_block = transpose_block_64_c;
-s->transpose_8x8   = transpose_8x8_64_c; break;
+for (int i = 0; i < 4; i++) {
+TransVtable *v = >vtables[i];
+switch (s->pixsteps[i]) {
+case 1: v->transpose_block = transpose_block_8_c;
+v->transpose_8x8   = transpose_8x8_8_c;  break;
+case 2: v->transpose_block = transpose_block_16_c;
+v->transpose_8x8   = transpose_8x8_16_c; break;
+case 3: v->transpose_block = transpose_block_24_c;
+v->transpose_8x8   = transpose_8x8_24_c; break;
+case 4: v->transpose_block = transpose_block_32_c;
+v->transpose_8x8   = transpose_8x8_32_c; break;
+case 6: v->transpose_block = transpose_block_48_c;
+v->transpose_8x8   = transpose_8x8_48_c; break;
+case 8: v->transpose_block = transpose_block_64_c;
+v->transpose_8x8   = transpose_8x8_64_c; break;
+}
 }
 
 av_log(ctx, AV_LOG_VERBOSE,
@@ -290,6 +297,7 @@ static int filter_slice(AVFilterContext *ctx, void *arg, 
int jobnr,
 uint8_t *dst, *src;
 int dstlinesize, srclinesize;
 int x, y;
+TransVtable *v = >vtables[plane];
 
 dstlinesize = out->linesize[plane];
 dst = out->data[plane] + start * dstlinesize;
@@ -308,20 +316,20 @@ static int filter_slice(AVFilterContext *ctx, void *arg, 
int jobnr,
 
 for (y = start; y < end - 7; y += 8) {
 for (x = 0; x < outw - 7; x += 8) {
-s->transpose_8x8(src + x * srclinesize + y * pixstep,
+v->transpose_8x8(src + x * srclinesize + y * pixstep,
  srclinesize,
  dst + (y - start) * dstlinesize + x * pixstep,
  dstlinesize);
 }
 if (outw - x > 0 && end - y > 0)
-s->transpose_block(src + x * srclinesize + y * pixstep,
+v->transpose_block(src + x * srclinesize + y * pixstep,
srclinesize,
dst + (y - start) * dstlinesize + x * 
pixstep,
dstlinesize, outw - x, end - y);
 }
 
 if (end - y > 0)
-s->transpose_block(src + 0 * srclinesize + y * pixstep,
+v->transpose_block(src + 0 * srclinesize + y * pixstep,
srclinesize,
dst + (y - start) * dstlinesize + 0 * pixstep,
dstlinesize, outw, end - y);
diff --git a/tests/ref/fate/filter-pixfmts-transpose 

[FFmpeg-devel] [PATCH 1/2] avcodec/g2meet: Check tile dimensions with av_image_check_size2()

[Michael Niedermayer]

Fixes: OOM
Fixes: 
6216/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-4983807968018432

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

diff --git a/libavcodec/g2meet.c b/libavcodec/g2meet.c
index 842095ba3b..a46157218f 100644
--- a/libavcodec/g2meet.c
+++ b/libavcodec/g2meet.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 
+#include "libavutil/imgutils.h"
 #include "libavutil/intreadwrite.h"
 
 #include "avcodec.h"
@@ -1451,7 +1452,8 @@ static int g2m_decode_frame(AVCodecContext *avctx, void 
*data,
 c->tile_height = bytestream2_get_be32();
 if (c->tile_width <= 0 || c->tile_height <= 0 ||
 ((c->tile_width | c->tile_height) & 0xF) ||
-c->tile_width * (uint64_t)c->tile_height >= INT_MAX / 4
+c->tile_width * (uint64_t)c->tile_height >= INT_MAX / 4 ||
+av_image_check_size2(c->tile_width, c->tile_height, 
avctx->max_pixels, avctx->pix_fmt, 0, avctx) < 0
 ) {
 av_log(avctx, AV_LOG_ERROR,
"Invalid tile dimensions %dx%d\n",
-- 
2.16.2

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

[FFmpeg-devel] [PATCH 2/2] avcodec/truemotion2rt: Check input buffer size

[Michael Niedermayer]

Fixes: Timeout
Fixes: 
6250/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2RT_fuzzer-5479814011027456

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

diff --git a/libavcodec/truemotion2rt.c b/libavcodec/truemotion2rt.c
index d63918742d..9df0b527bb 100644
--- a/libavcodec/truemotion2rt.c
+++ b/libavcodec/truemotion2rt.c
@@ -116,6 +116,9 @@ static int truemotion2rt_decode_frame(AVCodecContext 
*avctx, void *data,
 if (ret < 0)
 return ret;
 
+if (avctx->width / s->hscale * avctx->height * s->delta_size > avpkt->size 
* 8LL * 4)
+return AVERROR_INVALIDDATA;
+
 ret = init_get_bits8(gb, avpkt->data + ret, avpkt->size - ret);
 if (ret < 0)
 return ret;
-- 
2.16.2

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

Re: [FFmpeg-devel] SBC codec reworked

[Carl Eugen Hoyos]

2018-02-21 23:37 GMT+01:00 Aurelien Jacobs :

> I finnally came back to this SBC codec patchset.
> I made the changes to only have one CODEC_ID for both sbc and msbc.

How is it possible to distinguish between them if they share
a codec_id?

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

Re: [FFmpeg-devel] [PATCH v2 1/3] libavfilter/vf_fps: Add tests for start_time option

[Michael Niedermayer]

On Mon, Feb 19, 2018 at 07:54:35PM -0500, Calvin Walton wrote:
> ---
>  tests/fate/filter-video.mak  |  4 +++-
>  tests/ref/fate/filter-fps-start-drop | 11 +++
>  tests/ref/fate/filter-fps-start-fill | 11 +++
>  3 files changed, 25 insertions(+), 1 deletion(-)
>  create mode 100644 tests/ref/fate/filter-fps-start-drop
>  create mode 100644 tests/ref/fate/filter-fps-start-fill

will apply

thx

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH] avformat/flvdec: Set broken_sizes for FlixEngine.

[Niki Bowe]

On Fri, Feb 16, 2018 at 3:25 PM, Nikolas Bowe  wrote:

> ---
>  libavformat/flvdec.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 0217cef842..b86451fcbf 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -598,7 +598,9 @@ static int amf_parse_object(AVFormatContext *s,
> AVStream *astream,
>  if (version > 0 && version <= 655)
>  flv->broken_sizes = 1;
>  }
> -} else if (!strcmp(key, "metadatacreator") &&
> !strcmp(str_val, "MEGA")) {
> +} else if (!strcmp(key, "metadatacreator")
> +&& (!strcmp(str_val, "MEGA")
> +|| !strncmp(str_val, "FlixEngine", 10))) {
>  flv->broken_sizes = 1;
>  }
>  }
> --
> 2.16.1.291.g4437f3f132-goog
>
>
For a bit of context, we found some very old videos which suffered from
corruption after 9e6a2427558a718be0c1fffacffd935f630a7a8d, but were fine
before.
These had "End of AC stream reached in vp6_parse_coeff" warnings in logs.
These also had flv Packet mismatch warnings.
Adding FlixEngine to the list of flv muxers which produce broken packet
sizes fixes this corruption.

FlixEngine is very old and not maintained or available anymore (since
2010), so we won't need to worry about newer versions fixing the issue.


-- 

Nikolas Bowe |  SWE |  nb...@google.com |  408-565-5137
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avfilter: Add support for colour range as a link parameter

[Philip Langdale]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 21 Feb 2018 23:37:57 +0100
Nicolas George  wrote:

> Philip Langdale (2018-02-21):
> > As part of achieving our YUVJ-free future, it needs to be possible
> > to pass the colour range property from a decoder context to an
> > encoder context. In the absence of filters, this is obviously
> > trivial, but as soon as filters are introduced, there needs to
> > be a way to pass and preserve the property (or modify it, as
> > some filters will do).
> > 
> > Based on existing properties of this type, this change adds a
> > link property and ways to set it from a buffer source and get it
> > from a buffer sink.  
> 
> I am not sure when I will be able to give a close look at the code,
> so I make my general comment immediately:
> 
> Are you sure this is a property that must be forwarded and not
> negotiated?
> 
> You seem to say that encoders may support a limited set of ranges. It
> looks like the range should be constrained by the output, like the
> pixel format, and negotiated on the chain to insert a conversion
> filter if necessary.
> 
> But I am not familiar with color ranges. I just want to make sure you
> have considered the question.
> 
> Regards,
> 

Negotiation is part of Paul's larger changeset, and will be a useful
feature. My change is still a strict improvement over the current state
of the world - where range is not propagated at all, regardless of
compatibility. In those situations where negotiation is required, the
status quo will essentially continue, with the range value not
accurately reflecting the frame contents.

- --phil
-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlqN9woACgkQ+NaxlGp1aC6DvgCfaDsw2OsmY0xkXgajn6t7vWKx
/XsAoIl2B760kvv8PPRxWdkGUbV/tCdv
=F60C
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add -vf scale example for making pixels square

[Tomas Härdin]

tis 2018-02-20 klockan 02:35 +0100 skrev Michael Niedermayer:
> On Mon, Feb 19, 2018 at 06:45:11PM +0100, Tomas Härdin wrote:
> > 
> >  filters.texi |   13 +
> >  1 file changed, 13 insertions(+)
> > af8d1d10b307cc4123fda3f8a0d5cd3c9e86b7d7  0001-Add-vf-scale-
> > example-for-making-pixels-square.patch
> > From 9605df7c8402fb8d5fdbb55ae05639338a1ae0a1 Mon Sep 17 00:00:00
> > 2001
> > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= 
> > Date: Mon, 19 Feb 2018 18:42:25 +0100
> > Subject: [PATCH] Add -vf scale example for making pixels square
> > 
> > This is a common use case.
> > ---
> >  doc/filters.texi | 13 +
> >  1 file changed, 13 insertions(+)
> 
> should be ok
> 
> thx

pushed

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

[FFmpeg-devel] [PATCH 9/9] Changelog: list the new SBC codec

[Aurelien Jacobs]

---
 Changelog | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Changelog b/Changelog
index 2acdbbea30..163cc77880 100644
--- a/Changelog
+++ b/Changelog
@@ -39,6 +39,7 @@ version :
 - Removed the ffmenc and ffmdec muxer and demuxer
 - VideoToolbox HEVC encoder and hwaccel
 - VAAPI-accelerated ProcAmp (color balance), denoise and sharpness filters
+- native SBC encoder and decoder
 
 
 version 3.4:
-- 
2.16.1

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

[FFmpeg-devel] [PATCH 6/9] sbc: add raw muxer for SBC

[Aurelien Jacobs]

---
 doc/general.texi |  2 +-
 libavformat/Makefile |  1 +
 libavformat/allformats.c |  1 +
 libavformat/rawenc.c | 13 +
 4 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/doc/general.texi b/doc/general.texi
index bf62288f64..118bfd8bd9 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -479,7 +479,7 @@ library:
 @item raw NULL  @tab X @tab
 @item raw video @tab X @tab X
 @item raw id RoQ@tab X @tab
-@item raw SBC   @tab   @tab X
+@item raw SBC   @tab X @tab X
 @item raw Shorten   @tab   @tab X
 @item raw TAK   @tab   @tab X
 @item raw TrueHD@tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 1efa3a54f8..8f3272efdf 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -449,6 +449,7 @@ OBJS-$(CONFIG_SAMI_DEMUXER)  += samidec.o 
subtitles.o
 OBJS-$(CONFIG_SAP_DEMUXER)   += sapdec.o
 OBJS-$(CONFIG_SAP_MUXER) += sapenc.o
 OBJS-$(CONFIG_SBC_DEMUXER)   += sbcdec.o rawdec.o
+OBJS-$(CONFIG_SBC_MUXER) += rawenc.o
 OBJS-$(CONFIG_SBG_DEMUXER)   += sbgdec.o
 OBJS-$(CONFIG_SCC_DEMUXER)   += sccdec.o subtitles.o
 OBJS-$(CONFIG_SCC_MUXER) += sccenc.o subtitles.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 04164607ce..05894094a7 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -351,6 +351,7 @@ extern AVInputFormat  ff_sami_demuxer;
 extern AVInputFormat  ff_sap_demuxer;
 extern AVOutputFormat ff_sap_muxer;
 extern AVInputFormat  ff_sbc_demuxer;
+extern AVOutputFormat ff_sbc_muxer;
 extern AVInputFormat  ff_sbg_demuxer;
 extern AVInputFormat  ff_scc_demuxer;
 extern AVOutputFormat ff_scc_muxer;
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index dcf880d17e..caf4607dde 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -439,6 +439,19 @@ AVOutputFormat ff_rawvideo_muxer = {
 };
 #endif
 
+#if CONFIG_SBC_MUXER
+AVOutputFormat ff_sbc_muxer = {
+.name  = "sbc",
+.long_name = NULL_IF_CONFIG_SMALL("raw SBC"),
+.mime_type = "audio/x-sbc",
+.extensions= "sbc,msbc",
+.audio_codec   = AV_CODEC_ID_SBC,
+.write_header  = force_one_stream,
+.write_packet  = ff_raw_write_packet,
+.flags = AVFMT_NOTIMESTAMPS,
+};
+#endif
+
 #if CONFIG_TRUEHD_MUXER
 AVOutputFormat ff_truehd_muxer = {
 .name  = "truehd",
-- 
2.16.1

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

[FFmpeg-devel] [PATCH 7/9] sbcenc: add MMX optimizations

[Aurelien Jacobs]

This was originally based on libsbc, and was fully integrated into ffmpeg.

Rough speed test:
C version:speed= 592x
MMX version:  speed= 785x
---
 libavcodec/sbcdsp.c  |   3 +
 libavcodec/sbcdsp.h  |   2 +
 libavcodec/x86/Makefile  |   2 +
 libavcodec/x86/sbcdsp.asm| 285 +++
 libavcodec/x86/sbcdsp_init.c |  51 
 5 files changed, 343 insertions(+)
 create mode 100644 libavcodec/x86/sbcdsp.asm
 create mode 100644 libavcodec/x86/sbcdsp_init.c

diff --git a/libavcodec/sbcdsp.c b/libavcodec/sbcdsp.c
index e155387f0d..2d0addcf28 100644
--- a/libavcodec/sbcdsp.c
+++ b/libavcodec/sbcdsp.c
@@ -379,4 +379,7 @@ av_cold void ff_sbcdsp_init(SBCDSPContext *s)
 /* Default implementation for scale factors calculation */
 s->sbc_calc_scalefactors = sbc_calc_scalefactors;
 s->sbc_calc_scalefactors_j = sbc_calc_scalefactors_j;
+
+if (ARCH_X86)
+ff_sbcdsp_init_x86(s);
 }
diff --git a/libavcodec/sbcdsp.h b/libavcodec/sbcdsp.h
index 66ed7d324e..127e6a8a11 100644
--- a/libavcodec/sbcdsp.h
+++ b/libavcodec/sbcdsp.h
@@ -80,4 +80,6 @@ struct sbc_dsp_context {
  */
 void ff_sbcdsp_init(SBCDSPContext *s);
 
+void ff_sbcdsp_init_x86(SBCDSPContext *s);
+
 #endif /* AVCODEC_SBCDSP_H */
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index a805cd37b4..2350c8bbee 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -63,6 +63,7 @@ OBJS-$(CONFIG_PNG_DECODER) += x86/pngdsp_init.o
 OBJS-$(CONFIG_PRORES_DECODER)  += x86/proresdsp_init.o
 OBJS-$(CONFIG_PRORES_LGPL_DECODER) += x86/proresdsp_init.o
 OBJS-$(CONFIG_RV40_DECODER)+= x86/rv40dsp_init.o
+OBJS-$(CONFIG_SBC_ENCODER) += x86/sbcdsp_init.o
 OBJS-$(CONFIG_SVQ1_ENCODER)+= x86/svq1enc_init.o
 OBJS-$(CONFIG_TAK_DECODER) += x86/takdsp_init.o
 OBJS-$(CONFIG_TRUEHD_DECODER)  += x86/mlpdsp_init.o
@@ -172,6 +173,7 @@ X86ASM-OBJS-$(CONFIG_PNG_DECODER)  += x86/pngdsp.o
 X86ASM-OBJS-$(CONFIG_PRORES_DECODER)   += x86/proresdsp.o
 X86ASM-OBJS-$(CONFIG_PRORES_LGPL_DECODER) += x86/proresdsp.o
 X86ASM-OBJS-$(CONFIG_RV40_DECODER) += x86/rv40dsp.o
+X86ASM-OBJS-$(CONFIG_SBC_ENCODER)  += x86/sbcdsp.o
 X86ASM-OBJS-$(CONFIG_SVQ1_ENCODER) += x86/svq1enc.o
 X86ASM-OBJS-$(CONFIG_TAK_DECODER)  += x86/takdsp.o
 X86ASM-OBJS-$(CONFIG_TRUEHD_DECODER)   += x86/mlpdsp.o
diff --git a/libavcodec/x86/sbcdsp.asm b/libavcodec/x86/sbcdsp.asm
new file mode 100644
index 00..4e02263a63
--- /dev/null
+++ b/libavcodec/x86/sbcdsp.asm
@@ -0,0 +1,285 @@
+;**
+;* SIMD optimized SBC encoder DSP functions
+;*
+;* Copyright (C) 2017  Aurelien Jacobs 
+;* Copyright (C) 2008-2010  Nokia Corporation
+;* Copyright (C) 2004-2010  Marcel Holtmann 
+;* Copyright (C) 2004-2005  Henryk Ploetz 
+;* Copyright (C) 2005-2006  Brad Midgley 
+;*
+;* 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
+;**
+
+%include "libavutil/x86/x86util.asm"
+
+SECTION_RODATA
+
+scale_mask: times 2 dd 0x8000; 1 << (SBC_PROTO_FIXED_SCALE - 1)
+
+SECTION .text
+
+;***
+;void ff_sbc_analyze_4(const int16_t *in, int32_t *out, const int16_t *consts);
+;***
+INIT_MMX mmx
+cglobal sbc_analyze_4, 3, 3, 4, in, out, consts
+movq  m0, [inq]
+movq  m1, [inq+8]
+pmaddwd   m0, [constsq]
+pmaddwd   m1, [constsq+8]
+paddd m0, [scale_mask]
+paddd m1, [scale_mask]
+
+movq  m2, [inq+16]
+movq  m3, [inq+24]
+pmaddwd   m2, [constsq+16]
+pmaddwd   m3, [constsq+24]
+paddd m0, m2
+paddd m1, m3
+
+movq  m2, [inq+32]
+movq  m3, [inq+40]
+pmaddwd   m2, [constsq+32]
+pmaddwd   m3, [constsq+40]
+paddd m0, m2
+paddd m1, m3
+
+movq  m2, [inq+48]
+movq  m3, [inq+56]
+pmaddwd   m2, 

[FFmpeg-devel] [PATCH 3/9] sbc: add parser for SBC

[Aurelien Jacobs]

---
 libavcodec/Makefile |   1 +
 libavcodec/parser.c |   1 +
 libavcodec/sbc_parser.c | 124 
 3 files changed, 126 insertions(+)
 create mode 100644 libavcodec/sbc_parser.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index e2a87e404c..53d199201b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1014,6 +1014,7 @@ OBJS-$(CONFIG_PNG_PARSER)  += png_parser.o
 OBJS-$(CONFIG_PNM_PARSER)  += pnm_parser.o pnm.o
 OBJS-$(CONFIG_RV30_PARSER) += rv34_parser.o
 OBJS-$(CONFIG_RV40_PARSER) += rv34_parser.o
+OBJS-$(CONFIG_SBC_PARSER)  += sbc_parser.o
 OBJS-$(CONFIG_SIPR_PARSER) += sipr_parser.o
 OBJS-$(CONFIG_TAK_PARSER)  += tak_parser.o tak.o
 OBJS-$(CONFIG_VC1_PARSER)  += vc1_parser.o vc1.o vc1data.o  \
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index 0c66e80b96..f43b197d5e 100644
--- a/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -65,6 +65,7 @@ extern AVCodecParser ff_png_parser;
 extern AVCodecParser ff_pnm_parser;
 extern AVCodecParser ff_rv30_parser;
 extern AVCodecParser ff_rv40_parser;
+extern AVCodecParser ff_sbc_parser;
 extern AVCodecParser ff_sipr_parser;
 extern AVCodecParser ff_tak_parser;
 extern AVCodecParser ff_vc1_parser;
diff --git a/libavcodec/sbc_parser.c b/libavcodec/sbc_parser.c
new file mode 100644
index 00..4633196d3f
--- /dev/null
+++ b/libavcodec/sbc_parser.c
@@ -0,0 +1,124 @@
+/*
+ * SBC parser
+ *
+ * Copyright (C) 2017  Aurelien Jacobs 
+ *
+ * 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
+ */
+
+#include "sbc.h"
+#include "parser.h"
+
+typedef struct SBCParseContext {
+ParseContext pc;
+uint8_t header[3];
+int header_size;
+int buffered_size;
+} SBCParseContext;
+
+static int sbc_parse_header(AVCodecParserContext *s, AVCodecContext *avctx,
+const uint8_t *data, size_t len)
+{
+static const int sample_rates[4] = { 16000, 32000, 44100, 48000 };
+int sr, blocks, mode, subbands, bitpool, channels, joint;
+int length;
+
+if (len < 3)
+return -1;
+
+if (data[0] == MSBC_SYNCWORD && data[1] == 0 && data[2] == 0) {
+avctx->channels = 1;
+avctx->sample_fmt = AV_SAMPLE_FMT_S16;
+avctx->sample_rate = 16000;
+avctx->frame_size = 120;
+s->duration = avctx->frame_size;
+return 57;
+}
+
+if (data[0] != SBC_SYNCWORD)
+return -2;
+
+sr   =   (data[1] >> 6) & 0x03;
+blocks   = (((data[1] >> 4) & 0x03) + 1) << 2;
+mode =   (data[1] >> 2) & 0x03;
+subbands = (((data[1] >> 0) & 0x01) + 1) << 2;
+bitpool  = data[2];
+
+channels = mode == SBC_MODE_MONO ? 1 : 2;
+joint= mode == SBC_MODE_JOINT_STEREO;
+
+length = 4 + (subbands * channels) / 2;
+if (channels == 1 || mode == SBC_MODE_DUAL_CHANNEL)
+length += ((channels * blocks * bitpool) + 7) / 8;
+else
+length += (((joint ? subbands : 0) + blocks * bitpool) + 7) / 8;
+
+avctx->channels = channels;
+avctx->sample_fmt = AV_SAMPLE_FMT_S16;
+avctx->sample_rate = sample_rates[sr];
+avctx->frame_size = subbands * blocks;
+s->duration = avctx->frame_size;
+return length;
+}
+
+static int sbc_parse(AVCodecParserContext *s, AVCodecContext *avctx,
+ const uint8_t **poutbuf, int *poutbuf_size,
+ const uint8_t *buf, int buf_size)
+{
+SBCParseContext *pc = s->priv_data;
+int next;
+
+if (s->flags & PARSER_FLAG_COMPLETE_FRAMES) {
+next = buf_size;
+} else {
+if (pc->header_size) {
+memcpy(pc->header + pc->header_size, buf,
+   sizeof(pc->header) - pc->header_size);
+next = sbc_parse_header(s, avctx, pc->header, sizeof(pc->header))
+ - pc->buffered_size;
+pc->header_size = 0;
+} else {
+next = sbc_parse_header(s, avctx, buf, buf_size);
+if (next >= buf_size)
+next = -1;
+}
+
+if (next < 0) {
+pc->header_size = FFMIN(sizeof(pc->header), buf_size);
+memcpy(pc->header, buf, pc->header_size);
+

[FFmpeg-devel] [PATCH 5/9] sbc: implement SBC encoder (low-complexity subband codec)

[Aurelien Jacobs]

This was originally based on libsbc, and was fully integrated into ffmpeg.
---
 doc/general.texi |   2 +-
 libavcodec/Makefile  |   1 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/sbcdsp.c  | 382 +++
 libavcodec/sbcdsp.h  |  83 ++
 libavcodec/sbcdsp_data.c | 329 +
 libavcodec/sbcdsp_data.h |  55 +++
 libavcodec/sbcenc.c  | 411 +++
 8 files changed, 1263 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/sbcdsp.c
 create mode 100644 libavcodec/sbcdsp.h
 create mode 100644 libavcodec/sbcdsp_data.c
 create mode 100644 libavcodec/sbcdsp_data.h
 create mode 100644 libavcodec/sbcenc.c

diff --git a/doc/general.texi b/doc/general.texi
index 930c1e8bf2..bf62288f64 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1118,7 +1118,7 @@ following image formats are supported:
 @tab Real low bitrate AC-3 codec
 @item RealAudio Lossless @tab @tab  X
 @item RealAudio SIPR / ACELP.NET @tab @tab  X
-@item SBC (low-complexity subband codec) @tab @tab  X
+@item SBC (low-complexity subband codec) @tab  X  @tab  X
 @tab Used in Bluetooth A2DP
 @item Shorten@tab @tab  X
 @item Sierra VMD audio   @tab @tab  X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 53d199201b..ddae75bb9a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -584,6 +584,7 @@ OBJS-$(CONFIG_SUNRAST_DECODER) += sunrast.o
 OBJS-$(CONFIG_SUNRAST_ENCODER) += sunrastenc.o
 OBJS-$(CONFIG_LIBRSVG_DECODER) += librsvgdec.o
 OBJS-$(CONFIG_SBC_DECODER) += sbcdec.o sbcdec_data.o sbc.o
+OBJS-$(CONFIG_SBC_ENCODER) += sbcenc.o sbc.o sbcdsp.o sbcdsp_data.o
 OBJS-$(CONFIG_SVQ1_DECODER)+= svq1dec.o svq1.o svq13.o h263data.o
 OBJS-$(CONFIG_SVQ1_ENCODER)+= svq1enc.o svq1.o  h263data.o  \
   h263.o ituh263enc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 7d9097dcf7..de3bea8bc0 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -453,6 +453,7 @@ extern AVCodec ff_ra_144_encoder;
 extern AVCodec ff_ra_144_decoder;
 extern AVCodec ff_ra_288_decoder;
 extern AVCodec ff_ralf_decoder;
+extern AVCodec ff_sbc_encoder;
 extern AVCodec ff_sbc_decoder;
 extern AVCodec ff_shorten_decoder;
 extern AVCodec ff_sipr_decoder;
diff --git a/libavcodec/sbcdsp.c b/libavcodec/sbcdsp.c
new file mode 100644
index 00..e155387f0d
--- /dev/null
+++ b/libavcodec/sbcdsp.c
@@ -0,0 +1,382 @@
+/*
+ * Bluetooth low-complexity, subband codec (SBC)
+ *
+ * Copyright (C) 2017  Aurelien Jacobs 
+ * Copyright (C) 2012-2013  Intel Corporation
+ * Copyright (C) 2008-2010  Nokia Corporation
+ * Copyright (C) 2004-2010  Marcel Holtmann 
+ * Copyright (C) 2004-2005  Henryk Ploetz 
+ * Copyright (C) 2005-2006  Brad Midgley 
+ *
+ * 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
+ * SBC basic "building bricks"
+ */
+
+#include 
+#include 
+#include 
+#include "libavutil/common.h"
+#include "libavutil/intmath.h"
+#include "libavutil/intreadwrite.h"
+#include "sbc.h"
+#include "sbcdsp.h"
+#include "sbcdsp_data.h"
+
+/*
+ * A reference C code of analysis filter with SIMD-friendly tables
+ * reordering and code layout. This code can be used to develop platform
+ * specific SIMD optimizations. Also it may be used as some kind of test
+ * for compiler autovectorization capabilities (who knows, if the compiler
+ * is very good at this stuff, hand optimized assembly may be not strictly
+ * needed for some platform).
+ *
+ * Note: It is also possible to make a simple variant of analysis filter,
+ * which needs only a single constants table without taking care about
+ * even/odd cases. This simple variant of filter can be implemented without
+ * input data permutation. The only thing that would be lost is the
+ * possibility to use pairwise SIMD multiplications. But for some simple
+ * CPU cores without SIMD extensions it can be useful. If anybody is
+ * interested in implementing such variant of a filter, sourcecode from
+ * 

[FFmpeg-devel] [PATCH 8/9] sbcenc: add armv6 and neon asm optimizations

[Aurelien Jacobs]

This was originally based on libsbc, and was fully integrated into ffmpeg.
---
 libavcodec/arm/Makefile  |   3 +
 libavcodec/arm/sbcdsp_armv6.S| 245 ++
 libavcodec/arm/sbcdsp_init_arm.c | 105 ++
 libavcodec/arm/sbcdsp_neon.S | 714 +++
 libavcodec/sbcdsp.c  |   2 +
 libavcodec/sbcdsp.h  |   1 +
 6 files changed, 1070 insertions(+)
 create mode 100644 libavcodec/arm/sbcdsp_armv6.S
 create mode 100644 libavcodec/arm/sbcdsp_init_arm.c
 create mode 100644 libavcodec/arm/sbcdsp_neon.S

diff --git a/libavcodec/arm/Makefile b/libavcodec/arm/Makefile
index 1eeac5449e..fd2401f4e5 100644
--- a/libavcodec/arm/Makefile
+++ b/libavcodec/arm/Makefile
@@ -42,6 +42,7 @@ OBJS-$(CONFIG_DCA_DECODER) += 
arm/synth_filter_init_arm.o
 OBJS-$(CONFIG_HEVC_DECODER)+= arm/hevcdsp_init_arm.o
 OBJS-$(CONFIG_MLP_DECODER) += arm/mlpdsp_init_arm.o
 OBJS-$(CONFIG_RV40_DECODER)+= arm/rv40dsp_init_arm.o
+OBJS-$(CONFIG_SBC_ENCODER) += arm/sbcdsp_init_arm.o
 OBJS-$(CONFIG_VORBIS_DECODER)  += arm/vorbisdsp_init_arm.o
 OBJS-$(CONFIG_VP6_DECODER) += arm/vp6dsp_init_arm.o
 OBJS-$(CONFIG_VP9_DECODER) += arm/vp9dsp_init_10bpp_arm.o   \
@@ -81,6 +82,7 @@ ARMV6-OBJS-$(CONFIG_VP8DSP)+= arm/vp8_armv6.o 
  \
 
 # decoders/encoders
 ARMV6-OBJS-$(CONFIG_MLP_DECODER)   += arm/mlpdsp_armv6.o
+ARMV6-OBJS-$(CONFIG_SBC_ENCODER)   += arm/sbcdsp_armv6.o
 
 
 # VFP optimizations
@@ -140,6 +142,7 @@ NEON-OBJS-$(CONFIG_HEVC_DECODER)   += 
arm/hevcdsp_init_neon.o   \
 NEON-OBJS-$(CONFIG_RV30_DECODER)   += arm/rv34dsp_neon.o
 NEON-OBJS-$(CONFIG_RV40_DECODER)   += arm/rv34dsp_neon.o\
   arm/rv40dsp_neon.o
+NEON-OBJS-$(CONFIG_SBC_ENCODER)+= arm/sbcdsp_neon.o
 NEON-OBJS-$(CONFIG_VORBIS_DECODER) += arm/vorbisdsp_neon.o
 NEON-OBJS-$(CONFIG_VP6_DECODER)+= arm/vp6dsp_neon.o
 NEON-OBJS-$(CONFIG_VP9_DECODER)+= arm/vp9itxfm_16bpp_neon.o \
diff --git a/libavcodec/arm/sbcdsp_armv6.S b/libavcodec/arm/sbcdsp_armv6.S
new file mode 100644
index 00..f1ff845798
--- /dev/null
+++ b/libavcodec/arm/sbcdsp_armv6.S
@@ -0,0 +1,245 @@
+/*
+ * Bluetooth low-complexity, subband codec (SBC)
+ *
+ * Copyright (C) 2017  Aurelien Jacobs 
+ * Copyright (C) 2008-2010  Nokia Corporation
+ * Copyright (C) 2004-2010  Marcel Holtmann 
+ * Copyright (C) 2004-2005  Henryk Ploetz 
+ * Copyright (C) 2005-2006  Brad Midgley 
+ *
+ * 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
+ * SBC ARMv6 optimizations. The instructions are scheduled for ARM11 pipeline.
+ */
+
+#include "libavutil/arm/asm.S"
+
+function ff_sbc_analyze_4_armv6, export=1
+@ r0 = in, r1 = out, r2 = consts
+push{r1, r3-r7, lr}
+push{r8-r12, r14}
+ldrdr4,  r5,  [r0, #0]
+ldrdr6,  r7,  [r2, #0]
+ldrdr8,  r9,  [r0, #16]
+ldrdr10, r11, [r2, #16]
+mov r14, #0x8000
+smlad   r3,  r4,  r6,  r14
+smlad   r12, r5,  r7,  r14
+ldrdr4,  r5,  [r0, #32]
+ldrdr6,  r7,  [r2, #32]
+smlad   r3,  r8,  r10, r3
+smlad   r12, r9,  r11, r12
+ldrdr8,  r9,  [r0, #48]
+ldrdr10, r11, [r2, #48]
+smlad   r3,  r4,  r6,  r3
+smlad   r12, r5,  r7,  r12
+ldrdr4,  r5,  [r0, #64]
+ldrdr6,  r7,  [r2, #64]
+smlad   r3,  r8,  r10, r3
+smlad   r12, r9,  r11, r12
+ldrdr8,  r9,  [r0, #8]
+ldrdr10, r11, [r2, #8]
+smlad   r3,  r4,  r6,  r3@ t1[0] is done
+smlad   r12, r5,  r7,  r12   @ t1[1] is done
+ldrdr4,  r5,  [r0, #24]
+ldrdr6,  r7,  [r2, #24]
+pkhtb   r3,  r12, r3, asr #16@ combine t1[0] and t1[1]
+smlad   

[FFmpeg-devel] [PATCH 4/9] sbc: add raw demuxer for SBC

[Aurelien Jacobs]

---
 doc/general.texi |  1 +
 libavformat/Makefile |  1 +
 libavformat/allformats.c |  1 +
 libavformat/sbcdec.c | 33 +
 4 files changed, 36 insertions(+)
 create mode 100644 libavformat/sbcdec.c

diff --git a/doc/general.texi b/doc/general.texi
index 1b009a4b89..930c1e8bf2 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -479,6 +479,7 @@ library:
 @item raw NULL  @tab X @tab
 @item raw video @tab X @tab X
 @item raw id RoQ@tab X @tab
+@item raw SBC   @tab   @tab X
 @item raw Shorten   @tab   @tab X
 @item raw TAK   @tab   @tab X
 @item raw TrueHD@tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 7ac1ba95ad..1efa3a54f8 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -448,6 +448,7 @@ OBJS-$(CONFIG_S337M_DEMUXER) += s337m.o spdif.o
 OBJS-$(CONFIG_SAMI_DEMUXER)  += samidec.o subtitles.o
 OBJS-$(CONFIG_SAP_DEMUXER)   += sapdec.o
 OBJS-$(CONFIG_SAP_MUXER) += sapenc.o
+OBJS-$(CONFIG_SBC_DEMUXER)   += sbcdec.o rawdec.o
 OBJS-$(CONFIG_SBG_DEMUXER)   += sbgdec.o
 OBJS-$(CONFIG_SCC_DEMUXER)   += sccdec.o subtitles.o
 OBJS-$(CONFIG_SCC_MUXER) += sccenc.o subtitles.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index e75cd917e4..04164607ce 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -350,6 +350,7 @@ extern AVInputFormat  ff_s337m_demuxer;
 extern AVInputFormat  ff_sami_demuxer;
 extern AVInputFormat  ff_sap_demuxer;
 extern AVOutputFormat ff_sap_muxer;
+extern AVInputFormat  ff_sbc_demuxer;
 extern AVInputFormat  ff_sbg_demuxer;
 extern AVInputFormat  ff_scc_demuxer;
 extern AVOutputFormat ff_scc_muxer;
diff --git a/libavformat/sbcdec.c b/libavformat/sbcdec.c
new file mode 100644
index 00..ae74a220dc
--- /dev/null
+++ b/libavformat/sbcdec.c
@@ -0,0 +1,33 @@
+/*
+ * RAW SBC demuxer
+ * Copyright (C) 2017  Aurelien Jacobs 
+ *
+ * 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
+ */
+
+#include "avformat.h"
+#include "rawdec.h"
+
+AVInputFormat ff_sbc_demuxer = {
+.name   = "sbc",
+.long_name  = NULL_IF_CONFIG_SMALL("raw SBC (low-complexity subband 
codec)"),
+.extensions = "sbc,msbc",
+.raw_codec_id   = AV_CODEC_ID_SBC,
+.read_header= ff_raw_audio_read_header,
+.read_packet= ff_raw_read_partial_packet,
+.flags  = AVFMT_GENERIC_INDEX,
+};
-- 
2.16.1

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

[FFmpeg-devel] [PATCH 2/9] sbc: implement SBC decoder (low-complexity subband codec)

[Aurelien Jacobs]

This was originally based on libsbc, and was fully integrated into ffmpeg.
---
 doc/general.texi |   2 +
 libavcodec/Makefile  |   1 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/avcodec.h |   1 +
 libavcodec/codec_desc.c  |   7 +
 libavcodec/sbc.c | 271 +++
 libavcodec/sbc.h | 121 ++
 libavcodec/sbcdec.c  | 411 +++
 libavcodec/sbcdec_data.c | 127 +++
 libavcodec/sbcdec_data.h |  44 +
 10 files changed, 986 insertions(+)
 create mode 100644 libavcodec/sbc.c
 create mode 100644 libavcodec/sbc.h
 create mode 100644 libavcodec/sbcdec.c
 create mode 100644 libavcodec/sbcdec_data.c
 create mode 100644 libavcodec/sbcdec_data.h

diff --git a/doc/general.texi b/doc/general.texi
index 9ddcccf041..1b009a4b89 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1117,6 +1117,8 @@ following image formats are supported:
 @tab Real low bitrate AC-3 codec
 @item RealAudio Lossless @tab @tab  X
 @item RealAudio SIPR / ACELP.NET @tab @tab  X
+@item SBC (low-complexity subband codec) @tab @tab  X
+@tab Used in Bluetooth A2DP
 @item Shorten@tab @tab  X
 @item Sierra VMD audio   @tab @tab  X
 @tab Used in Sierra VMD files.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3d4b738e0b..e2a87e404c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -583,6 +583,7 @@ OBJS-$(CONFIG_SUBVIEWER_DECODER)   += subviewerdec.o 
ass.o
 OBJS-$(CONFIG_SUNRAST_DECODER) += sunrast.o
 OBJS-$(CONFIG_SUNRAST_ENCODER) += sunrastenc.o
 OBJS-$(CONFIG_LIBRSVG_DECODER) += librsvgdec.o
+OBJS-$(CONFIG_SBC_DECODER) += sbcdec.o sbcdec_data.o sbc.o
 OBJS-$(CONFIG_SVQ1_DECODER)+= svq1dec.o svq1.o svq13.o h263data.o
 OBJS-$(CONFIG_SVQ1_ENCODER)+= svq1enc.o svq1.o  h263data.o  \
   h263.o ituh263enc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 774b78ef09..7d9097dcf7 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -453,6 +453,7 @@ extern AVCodec ff_ra_144_encoder;
 extern AVCodec ff_ra_144_decoder;
 extern AVCodec ff_ra_288_decoder;
 extern AVCodec ff_ralf_decoder;
+extern AVCodec ff_sbc_decoder;
 extern AVCodec ff_shorten_decoder;
 extern AVCodec ff_sipr_decoder;
 extern AVCodec ff_smackaud_decoder;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index bc0eacd66b..ae84ba7212 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -635,6 +635,7 @@ enum AVCodecID {
 AV_CODEC_ID_DOLBY_E,
 AV_CODEC_ID_APTX,
 AV_CODEC_ID_APTX_HD,
+AV_CODEC_ID_SBC,
 
 /* subtitle codecs */
 AV_CODEC_ID_FIRST_SUBTITLE = 0x17000,  ///< A dummy ID pointing at 
the start of subtitle codecs.
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 44a54a31c9..b5d495c5d4 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2863,6 +2863,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("aptX HD (Audio Processing 
Technology for Bluetooth)"),
 .props = AV_CODEC_PROP_LOSSY,
 },
+{
+.id= AV_CODEC_ID_SBC,
+.type  = AVMEDIA_TYPE_AUDIO,
+.name  = "sbc",
+.long_name = NULL_IF_CONFIG_SMALL("SBC (low-complexity subband 
codec)"),
+.props = AV_CODEC_PROP_LOSSY,
+},
 
 /* subtitle codecs */
 {
diff --git a/libavcodec/sbc.c b/libavcodec/sbc.c
new file mode 100644
index 00..f7dba79f4f
--- /dev/null
+++ b/libavcodec/sbc.c
@@ -0,0 +1,271 @@
+/*
+ * Bluetooth low-complexity, subband codec (SBC)
+ *
+ * Copyright (C) 2017  Aurelien Jacobs 
+ * Copyright (C) 2012-2013  Intel Corporation
+ * Copyright (C) 2008-2010  Nokia Corporation
+ * Copyright (C) 2004-2010  Marcel Holtmann 
+ * Copyright (C) 2004-2005  Henryk Ploetz 
+ * Copyright (C) 2005-2008  Brad Midgley 
+ *
+ * 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
+ * SBC common functions for the encoder and decoder
+ */
+
+#include "avcodec.h"
+#include 

[FFmpeg-devel] [PATCH 1/9] crc: add AV_CRC_8_SBC as a 8 bits CRC with polynomial 0x1D

[Aurelien Jacobs]

---
 libavutil/crc.c   | 26 ++
 libavutil/crc.h   |  1 +
 libavutil/tests/crc.c |  7 ---
 tests/ref/fate/crc|  1 +
 4 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/libavutil/crc.c b/libavutil/crc.c
index d44550c9c0..c45ea63a62 100644
--- a/libavutil/crc.c
+++ b/libavutil/crc.c
@@ -52,6 +52,30 @@ static const AVCRC av_crc_table[AV_CRC_MAX][257] = {
 0xDE, 0xD9, 0xD0, 0xD7, 0xC2, 0xC5, 0xCC, 0xCB, 0xE6, 0xE1, 0xE8, 0xEF,
 0xFA, 0xFD, 0xF4, 0xF3, 0x01
 },
+[AV_CRC_8_EBU] = {
+0x00, 0x1D, 0x3A, 0x27, 0x74, 0x69, 0x4E, 0x53, 0xE8, 0xF5, 0xD2, 0xCF,
+0x9C, 0x81, 0xA6, 0xBB, 0xCD, 0xD0, 0xF7, 0xEA, 0xB9, 0xA4, 0x83, 0x9E,
+0x25, 0x38, 0x1F, 0x02, 0x51, 0x4C, 0x6B, 0x76, 0x87, 0x9A, 0xBD, 0xA0,
+0xF3, 0xEE, 0xC9, 0xD4, 0x6F, 0x72, 0x55, 0x48, 0x1B, 0x06, 0x21, 0x3C,
+0x4A, 0x57, 0x70, 0x6D, 0x3E, 0x23, 0x04, 0x19, 0xA2, 0xBF, 0x98, 0x85,
+0xD6, 0xCB, 0xEC, 0xF1, 0x13, 0x0E, 0x29, 0x34, 0x67, 0x7A, 0x5D, 0x40,
+0xFB, 0xE6, 0xC1, 0xDC, 0x8F, 0x92, 0xB5, 0xA8, 0xDE, 0xC3, 0xE4, 0xF9,
+0xAA, 0xB7, 0x90, 0x8D, 0x36, 0x2B, 0x0C, 0x11, 0x42, 0x5F, 0x78, 0x65,
+0x94, 0x89, 0xAE, 0xB3, 0xE0, 0xFD, 0xDA, 0xC7, 0x7C, 0x61, 0x46, 0x5B,
+0x08, 0x15, 0x32, 0x2F, 0x59, 0x44, 0x63, 0x7E, 0x2D, 0x30, 0x17, 0x0A,
+0xB1, 0xAC, 0x8B, 0x96, 0xC5, 0xD8, 0xFF, 0xE2, 0x26, 0x3B, 0x1C, 0x01,
+0x52, 0x4F, 0x68, 0x75, 0xCE, 0xD3, 0xF4, 0xE9, 0xBA, 0xA7, 0x80, 0x9D,
+0xEB, 0xF6, 0xD1, 0xCC, 0x9F, 0x82, 0xA5, 0xB8, 0x03, 0x1E, 0x39, 0x24,
+0x77, 0x6A, 0x4D, 0x50, 0xA1, 0xBC, 0x9B, 0x86, 0xD5, 0xC8, 0xEF, 0xF2,
+0x49, 0x54, 0x73, 0x6E, 0x3D, 0x20, 0x07, 0x1A, 0x6C, 0x71, 0x56, 0x4B,
+0x18, 0x05, 0x22, 0x3F, 0x84, 0x99, 0xBE, 0xA3, 0xF0, 0xED, 0xCA, 0xD7,
+0x35, 0x28, 0x0F, 0x12, 0x41, 0x5C, 0x7B, 0x66, 0xDD, 0xC0, 0xE7, 0xFA,
+0xA9, 0xB4, 0x93, 0x8E, 0xF8, 0xE5, 0xC2, 0xDF, 0x8C, 0x91, 0xB6, 0xAB,
+0x10, 0x0D, 0x2A, 0x37, 0x64, 0x79, 0x5E, 0x43, 0xB2, 0xAF, 0x88, 0x95,
+0xC6, 0xDB, 0xFC, 0xE1, 0x5A, 0x47, 0x60, 0x7D, 0x2E, 0x33, 0x14, 0x09,
+0x7F, 0x62, 0x45, 0x58, 0x0B, 0x16, 0x31, 0x2C, 0x97, 0x8A, 0xAD, 0xB0,
+0xE3, 0xFE, 0xD9, 0xC4, 0x01
+},
 [AV_CRC_16_ANSI] = {
 0x, 0x0580, 0x0F80, 0x0A00, 0x1B80, 0x1E00, 0x1400, 0x1180,
 0x3380, 0x3600, 0x3C00, 0x3980, 0x2800, 0x2D80, 0x2780, 0x2200,
@@ -305,6 +329,7 @@ static void id ## _init_table_once(void)
 #define CRC_INIT_TABLE_ONCE(id) ff_thread_once( ## _once_control, id ## 
_init_table_once)
 
 DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_8_ATM,  0,  8,   0x07)
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_8_EBU,  0,  8,   0x1D)
 DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_16_ANSI,0, 16, 0x8005)
 DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_16_CCITT,   0, 16, 0x1021)
 DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_24_IEEE,0, 24,   0x864CFB)
@@ -351,6 +376,7 @@ const AVCRC *av_crc_get_table(AVCRCId crc_id)
 #if !CONFIG_HARDCODED_TABLES
 switch (crc_id) {
 case AV_CRC_8_ATM:  CRC_INIT_TABLE_ONCE(AV_CRC_8_ATM); break;
+case AV_CRC_8_EBU:  CRC_INIT_TABLE_ONCE(AV_CRC_8_EBU); break;
 case AV_CRC_16_ANSI:CRC_INIT_TABLE_ONCE(AV_CRC_16_ANSI); break;
 case AV_CRC_16_CCITT:   CRC_INIT_TABLE_ONCE(AV_CRC_16_CCITT); break;
 case AV_CRC_24_IEEE:CRC_INIT_TABLE_ONCE(AV_CRC_24_IEEE); break;
diff --git a/libavutil/crc.h b/libavutil/crc.h
index fe9a7c8fcb..47e22b4c78 100644
--- a/libavutil/crc.h
+++ b/libavutil/crc.h
@@ -54,6 +54,7 @@ typedef enum {
 AV_CRC_32_IEEE_LE,  /*< reversed bitorder version of AV_CRC_32_IEEE */
 AV_CRC_16_ANSI_LE,  /*< reversed bitorder version of AV_CRC_16_ANSI */
 AV_CRC_24_IEEE,
+AV_CRC_8_EBU,
 AV_CRC_MAX, /*< Not part of public API! Do not use outside 
libavutil. */
 }AVCRCId;
 
diff --git a/libavutil/tests/crc.c b/libavutil/tests/crc.c
index 9825d6bec9..413aada8a2 100644
--- a/libavutil/tests/crc.c
+++ b/libavutil/tests/crc.c
@@ -25,20 +25,21 @@ int main(void)
 {
 uint8_t buf[1999];
 int i;
-static const unsigned p[6][3] = {
+static const unsigned p[7][3] = {
 { AV_CRC_32_IEEE_LE, 0xEDB88320, 0x3D5CDD04 },
 { AV_CRC_32_IEEE   , 0x04C11DB7, 0xC0F5BAE0 },
 { AV_CRC_24_IEEE   , 0x864CFB  , 0xB704CE   },
 { AV_CRC_16_ANSI_LE, 0xA001, 0xBFD8 },
 { AV_CRC_16_ANSI   , 0x8005, 0x1FBB },
-{ AV_CRC_8_ATM , 0x07  , 0xE3   }
+{ AV_CRC_8_ATM , 0x07  , 0xE3   },
+{ AV_CRC_8_EBU , 0x1D  , 0xD6   },
 };
 const AVCRC *ctx;
 
 for (i = 0; i < sizeof(buf); i++)
 buf[i] = i + i * i;
 
-for (i = 0; i < 6; i++) {
+for (i = 0; i < 7; i++) {
 ctx = av_crc_get_table(p[i][0]);
 printf("crc %08X = %X\n", p[i][1], av_crc(ctx, 0, buf, sizeof(buf)));
 }
diff --git a/tests/ref/fate/crc b/tests/ref/fate/crc

[FFmpeg-devel] SBC codec reworked

[Aurelien Jacobs]

Hi,

I finnally came back to this SBC codec patchset.
I made the changes to only have one CODEC_ID for both sbc and msbc.
I think I took care of all the remarks from previous review.
Any more comments ?

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

Re: [FFmpeg-devel] [PATCH 1/3] avfilter: Add support for colour range as a link parameter

[Nicolas George]

Philip Langdale (2018-02-21):
> As part of achieving our YUVJ-free future, it needs to be possible
> to pass the colour range property from a decoder context to an
> encoder context. In the absence of filters, this is obviously
> trivial, but as soon as filters are introduced, there needs to
> be a way to pass and preserve the property (or modify it, as
> some filters will do).
> 
> Based on existing properties of this type, this change adds a
> link property and ways to set it from a buffer source and get it
> from a buffer sink.

I am not sure when I will be able to give a close look at the code, so I
make my general comment immediately:

Are you sure this is a property that must be forwarded and not
negotiated?

You seem to say that encoders may support a limited set of ranges. It
looks like the range should be constrained by the output, like the pixel
format, and negotiated on the chain to insert a conversion filter if
necessary.

But I am not familiar with color ranges. I just want to make sure you
have considered the question.

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 2/3] avfilter: Set output link colour range where appropriate

[Philip Langdale]

Certain filters set or modify the output colour range. Today, they
do that per-frame, but now that we have a link property, they need
to set that as well.

Signed-off-by: Philip Langdale 
---
 libavfilter/avf_showcqt.c  |  1 +
 libavfilter/avf_showspectrum.c |  1 +
 libavfilter/version.h  |  2 +-
 libavfilter/vf_colorspace.c|  4 
 libavfilter/vf_scale.c |  8 +++-
 libavfilter/vf_setparams.c | 11 +++
 libavfilter/vf_waveform.c  |  1 +
 libavfilter/vf_zscale.c| 21 +++--
 8 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
index 875ba48cee..ee6654358a 100644
--- a/libavfilter/avf_showcqt.c
+++ b/libavfilter/avf_showcqt.c
@@ -1363,6 +1363,7 @@ static int config_output(AVFilterLink *outlink)
 outlink->h = s->height;
 s->format = outlink->format;
 outlink->sample_aspect_ratio = av_make_q(1, 1);
+outlink->color_range = AVCOL_RANGE_JPEG;
 outlink->frame_rate = s->rate;
 outlink->time_base = av_mul_q(av_inv_q(s->rate), av_make_q(1, PTS_STEP));
 av_log(ctx, AV_LOG_INFO, "video: %dx%d %s %d/%d fps, bar_h = %d, axis_h = 
%d, sono_h = %d.\n",
diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index 956f62f3ad..52fa018317 100644
--- a/libavfilter/avf_showspectrum.c
+++ b/libavfilter/avf_showspectrum.c
@@ -307,6 +307,7 @@ static int config_output(AVFilterLink *outlink)
 outlink->w = s->w;
 outlink->h = s->h;
 outlink->sample_aspect_ratio = (AVRational){1,1};
+outlink->color_range = AVCOL_RANGE_JPEG;
 
 if (s->legend) {
 s->start_x = log10(inlink->sample_rate) * 25;
diff --git a/libavfilter/version.h b/libavfilter/version.h
index babb4187b4..1f0497b3e6 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -31,7 +31,7 @@
 
 #define LIBAVFILTER_VERSION_MAJOR   7
 #define LIBAVFILTER_VERSION_MINOR  13
-#define LIBAVFILTER_VERSION_MICRO 100
+#define LIBAVFILTER_VERSION_MICRO 101
 
 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
LIBAVFILTER_VERSION_MINOR, \
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index 71ea08a20f..5455648710 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -1048,6 +1048,7 @@ static int config_props(AVFilterLink *outlink)
 {
 AVFilterContext *ctx = outlink->dst;
 AVFilterLink *inlink = outlink->src->inputs[0];
+ColorSpaceContext *s = ctx->priv;
 
 if (inlink->w % 2 || inlink->h % 2) {
 av_log(ctx, AV_LOG_ERROR, "Invalid odd size (%dx%d)\n",
@@ -1060,6 +1061,9 @@ static int config_props(AVFilterLink *outlink)
 outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
 outlink->time_base = inlink->time_base;
 
+if (s->user_rng != AVCOL_RANGE_UNSPECIFIED)
+outlink->color_range = s->user_rng;
+
 return 0;
 }
 
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 9f45032e85..21ae709d6b 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -342,11 +342,16 @@ static int config_props(AVFilterLink *outlink)
 } else
 outlink->sample_aspect_ratio = inlink0->sample_aspect_ratio;
 
-av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d fmt:%s sar:%d/%d -> w:%d h:%d 
fmt:%s sar:%d/%d flags:0x%0x\n",
+if (scale->out_range != AVCOL_RANGE_UNSPECIFIED)
+outlink->color_range = scale->out_range;
+
+av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d fmt:%s sar:%d/%d range:%d -> w:%d 
h:%d fmt:%s sar:%d/%d range:%d flags:0x%0x\n",
inlink ->w, inlink ->h, av_get_pix_fmt_name( inlink->format),
inlink->sample_aspect_ratio.num, inlink->sample_aspect_ratio.den,
+   inlink->color_range,
outlink->w, outlink->h, av_get_pix_fmt_name(outlink->format),
outlink->sample_aspect_ratio.num, outlink->sample_aspect_ratio.den,
+   outlink->color_range,
scale->flags);
 return 0;
 
@@ -363,6 +368,7 @@ static int config_props_ref(AVFilterLink *outlink)
 outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
 outlink->time_base = inlink->time_base;
 outlink->frame_rate = inlink->frame_rate;
+outlink->color_range = inlink->color_range;
 
 return 0;
 }
diff --git a/libavfilter/vf_setparams.c b/libavfilter/vf_setparams.c
index 8427f98ba8..2b47e2d20b 100644
--- a/libavfilter/vf_setparams.c
+++ b/libavfilter/vf_setparams.c
@@ -56,6 +56,16 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
 return ff_filter_frame(ctx->outputs[0], frame);
 }
 
+static int config_output(AVFilterLink *outlink)
+{
+AVFilterContext *ctx = outlink->src;
+SetParamsContext *s = ctx->priv;
+
+if (s->color_range >= 0)
+outlink->color_range = s->color_range;
+return 0;
+}
+
 static const AVFilterPad inputs[] = {
 {
 .name = "default",
@@ -69,6 +79,7 @@ static 

[FFmpeg-devel] [PATCH 3/3] fftools/ffmpeg: Support passing colour range from decoder to encoder

[Philip Langdale]

This is relatively straightforward; we set the colour range from the
encoder context into the buffersrc parameters and then set the range
on the decoder from the buffersink.

I did not touch ifilter as part of this change, as I'm not sure whether
it is relevant. ifilter initialisation seems to be done from an AVFrame,
and it seems conceptually undesirable to set the link colour range on
that basis. The one possible reason to handle this is if if the input
is not a decoder and so the color range would come from codecpar. If
so, it could be handled as a separate change.

Signed-off-by: Philip Langdale 
---
 fftools/ffmpeg.c| 2 ++
 fftools/ffmpeg_filter.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index a37de2ff98..ff824b864f 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3385,6 +3385,8 @@ static int init_output_stream_encode(OutputStream *ost)
 av_mul_q(ost->frame_aspect_ratio, (AVRational){ enc_ctx->height, 
enc_ctx->width }) :
 av_buffersink_get_sample_aspect_ratio(ost->filter->filter);
 
+enc_ctx->color_range = 
av_buffersink_get_color_range(ost->filter->filter);
+
 enc_ctx->pix_fmt = av_buffersink_get_format(ost->filter->filter);
 if (dec_ctx)
 enc_ctx->bits_per_raw_sample = FFMIN(dec_ctx->bits_per_raw_sample,
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 877fd670e6..30cb0bc378 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -755,6 +755,7 @@ static int configure_input_video_filter(FilterGraph *fg, 
InputFilter *ifilter,
 return AVERROR(ENOMEM);
 memset(par, 0, sizeof(*par));
 par->format = AV_PIX_FMT_NONE;
+par->color_range = ist->dec_ctx->color_range;
 
 if (ist->dec_ctx->codec_type == AVMEDIA_TYPE_AUDIO) {
 av_log(NULL, AV_LOG_ERROR, "Cannot connect video filter to audio 
input\n");
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 1/3] avfilter: Add support for colour range as a link parameter

[Philip Langdale]

As part of achieving our YUVJ-free future, it needs to be possible
to pass the colour range property from a decoder context to an
encoder context. In the absence of filters, this is obviously
trivial, but as soon as filters are introduced, there needs to
be a way to pass and preserve the property (or modify it, as
some filters will do).

Based on existing properties of this type, this change adds a
link property and ways to set it from a buffer source and get it
from a buffer sink.

Signed-off-by: Philip Langdale 
---
 doc/APIchanges   |  5 +
 libavfilter/avfilter.c   |  2 ++
 libavfilter/avfilter.h   |  2 ++
 libavfilter/buffersink.c |  1 +
 libavfilter/buffersink.h |  1 +
 libavfilter/buffersrc.c  | 23 +--
 libavfilter/buffersrc.h  |  5 +
 libavfilter/version.h|  2 +-
 libavfilter/video.c  |  1 +
 9 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index a98475366d..1c583420d1 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,11 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-02-xx - xxx - lavfi 7.13.100 - avfilter.h
+
+  Add AVFilterLink.color_range, and mechanisms to set/get it on
+  buffersrc and buffersink.
+
 2018-02-xx - xxx
   Change av_ripemd_update(), av_murmur3_update() and av_hash_update() length
   parameter type to size_t at next major bump.
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index 7553f7c36a..9b93e8177e 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -338,6 +338,8 @@ int avfilter_config_links(AVFilterContext *filter)
 link->w = inlink->w;
 if (!link->h)
 link->h = inlink->h;
+if (link->color_range == AVCOL_RANGE_UNSPECIFIED)
+link->color_range = inlink->color_range;
 } else if (!link->w || !link->h) {
 av_log(link->src, AV_LOG_ERROR,
"Video source filters must set their output link's "
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index 2d1195eeeb..ae3287a69e 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -600,6 +600,8 @@ struct AVFilterLink {
  */
 AVBufferRef *hw_frames_ctx;
 
+enum AVColorRange color_range;  ///< agreed upon video color range
+
 #ifndef FF_INTERNAL_FIELDS
 
 /**
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 0f87b5439a..897396cac4 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -194,6 +194,7 @@ MAKE_AVFILTERLINK_ACCESSOR(AVRational   , frame_rate
 )
 MAKE_AVFILTERLINK_ACCESSOR(int  , w  )
 MAKE_AVFILTERLINK_ACCESSOR(int  , h  )
 MAKE_AVFILTERLINK_ACCESSOR(AVRational   , sample_aspect_ratio)
+MAKE_AVFILTERLINK_ACCESSOR(enum AVColorRange, color_range)
 
 MAKE_AVFILTERLINK_ACCESSOR(int  , channels   )
 MAKE_AVFILTERLINK_ACCESSOR(uint64_t , channel_layout )
diff --git a/libavfilter/buffersink.h b/libavfilter/buffersink.h
index 21d6bb505b..d91e3fe448 100644
--- a/libavfilter/buffersink.h
+++ b/libavfilter/buffersink.h
@@ -114,6 +114,7 @@ AVRational   av_buffersink_get_frame_rate  
(const AVFilterContext *c
 int  av_buffersink_get_w   (const AVFilterContext 
*ctx);
 int  av_buffersink_get_h   (const AVFilterContext 
*ctx);
 AVRational   av_buffersink_get_sample_aspect_ratio (const AVFilterContext 
*ctx);
+enum AVColorRange av_buffersink_get_color_range (const AVFilterContext 
*ctx);
 
 int  av_buffersink_get_channels(const AVFilterContext 
*ctx);
 uint64_t av_buffersink_get_channel_layout  (const AVFilterContext 
*ctx);
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index cd56f8ca45..2517f10feb 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -52,6 +52,7 @@ typedef struct BufferSourceContext {
 int   w, h;
 enum AVPixelFormat  pix_fmt;
 AVRationalpixel_aspect;
+int   color_range;
 char  *sws_param;
 
 AVBufferRef *hw_frames_ctx;
@@ -111,6 +112,8 @@ int av_buffersrc_parameters_set(AVFilterContext *ctx, 
AVBufferSrcParameters *par
 s->pixel_aspect = param->sample_aspect_ratio;
 if (param->frame_rate.num > 0 && param->frame_rate.den > 0)
 s->frame_rate = param->frame_rate;
+if (param->color_range > AVCOL_RANGE_UNSPECIFIED)
+s->color_range = param->color_range;
 if (param->hw_frames_ctx) {
 av_buffer_unref(>hw_frames_ctx);
 s->hw_frames_ctx = av_buffer_ref(param->hw_frames_ctx);
@@ -279,13 +282,19 @@ static av_cold int init_video(AVFilterContext *ctx)
 return AVERROR(EINVAL);
 }
 
+if 

Re: [FFmpeg-devel] [PATCH] doc/filters: add links to ffmpeg-utils and ffmpeg documentation

[Lou Logan]

On Tue, Feb 20, 2018, at 2:01 AM, Tobias Rapp wrote:
> Signed-off-by: Tobias Rapp 
> ---
>  doc/filters.texi | 48 ++--
>  1 file changed, 26 insertions(+), 22 deletions(-)
[...]
> @@ -9322,8 +9323,9 @@ A '|'-separated list of parameters to pass to the 
> frei0r effect.
>  A frei0r effect parameter can be a boolean (its value is either
>  "y" or "n"), a double, a color (specified as
>  @var{R}/@var{G}/@var{B}, where @var{R}, @var{G}, and @var{B} are 
> floating point
> -numbers between 0.0 and 1.0, inclusive) or by a color description 
> specified in the "Color"
> -section in the ffmpeg-utils manual), a position (specified as @var{X}/
> @var{Y}, where
> +numbers between 0.0 and 1.0, inclusive) or by a color description 
> specified in the
> +@ref{color syntax,,"Color" section in the ffmpeg-utils manual,ffmpeg-
> utils}),

You can remove that errant ")" if you feel like it (I know you didn't introduce 
that).

Otherwise, LGTM.

I have never really liked the resulting link structure as shown in the HTML 
output, but I don't hate it enough to actually do anything about it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 0/3] Pass colour range from source to sink v2

[Philip Langdale]

This change turns out to be a subset of a much bigger change that Paul
put together back in December and which didn't get enough review
coverage for him to comfortably push. I didn't know about that, so I
redid a bunch of stuff, but the end result is what I think is a logical
subset of the complete YUVJ purge which can be reviewed and pushed on
its own.

Unlike Paul's complete set of changes, this does not include any
replacement of YUVJ code with color_range code and doesn't include
any range negotiation. It is strictly just passing the range from one
end to the other, assuming a range value is set by some means. This
is more useful than you may think as many demuxers and decoders set
the range, and many encoders and muxers respect the range.

Today, we have a colour range property on decoders and encoders. The
decoder sets the property on itself to reflect what it is decoding,
and the user sets it on the encoder to reflect what is being encoded.

However, we don't support a way to pass it through filter chains and
'ffmpeg' does not make any attempt to set it on the encoder.

This set of changes introduces a way to do this, by defining a new
filter link property, and allowing it to be set on a buffersrc and
read back from a buffersink.

We then extend the various relevant filters to set the property
when they manipulate the colour range, and finally, we get 'ffmpeg'
to get and set the range appropriately.

After this change, it is now possible to correctly pass the colour
range through a pipeline so that it it influences encoder behaviour,
and is recorded in the container, where relevant.

Philip Langdale (3):
  avfilter: Add support for colour range  as a link parameter
  avfilter: Set output link colour range where appropriate
  fftools/ffmpeg: Support passing colour range from decoder to encoder

 doc/APIchanges |  5 +
 fftools/ffmpeg.c   |  2 ++
 fftools/ffmpeg_filter.c|  1 +
 libavfilter/avf_showcqt.c  |  1 +
 libavfilter/avf_showspectrum.c |  1 +
 libavfilter/avfilter.c |  2 ++
 libavfilter/avfilter.h |  2 ++
 libavfilter/buffersink.c   |  1 +
 libavfilter/buffersink.h   |  1 +
 libavfilter/buffersrc.c| 23 +--
 libavfilter/buffersrc.h|  5 +
 libavfilter/version.h  |  4 ++--
 libavfilter/vf_colorspace.c|  4 
 libavfilter/vf_scale.c |  8 +++-
 libavfilter/vf_setparams.c | 11 +++
 libavfilter/vf_waveform.c  |  1 +
 libavfilter/vf_zscale.c| 21 +++--
 libavfilter/video.c|  1 +
 18 files changed, 87 insertions(+), 7 deletions(-)

-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH 02/10] avformat/mxfdec: fix essence_offset calculation

[Marton Balint]

On Wed, 21 Feb 2018, Tomas Härdin wrote:


lör 2018-02-17 klockan 22:45 +0100 skrev Marton Balint:

The reference point for a KAG is the first byte of the key of a Partition Pack.

Fixes ticket #2817.
Fixes ticket #5317.

> Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index fcae863ef4..95767ccba4 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2875,8 +2875,8 @@ static int mxf_read_header(AVFormatContext *s)
  *   for OPAtom we still need the actual essence_offset 
though (the KL's length can vary)
  */
 int64_t op1a_essence_offset =
-round_to_kag(mxf->current_partition->this_partition +
- mxf->current_partition->pack_length,   
mxf->current_partition->kag_size) +
+mxf->current_partition->this_partition +
+round_to_kag(mxf->current_partition->pack_length,   
mxf->current_partition->kag_size) +
 round_to_kag(mxf->current_partition->header_byte_count, 
mxf->current_partition->kag_size) +
 round_to_kag(mxf->current_partition->index_byte_count,  
mxf->current_partition->kag_size);


This seems like a rather elemental miscalculation, that I wrote even. I
took a look at S377m, it had this to say:


The first gridline in any partition is the first byte of the key of
the partition pack that defines that
partition.


Each partition starts at ThisPartition (plus run-in) so this patch
should be correct. What's perhaps more suspect is the calculation
itself. It should *always* be possible to locate where Op1a essence
starts, by scanning to the first essence KLV. MXF is flexible enough
that having some sketchy calculation for where it *might* be is
probably not correct. One is free to insert any amount of padding


The next patch more or less handles this by checking for a system item 
key and explicitly setting the offset if that is found. An essence alone 
however might not be the first essence, it is also possible that we 
already skipped an unknown essence key, or an unknown system item key, so 
I decided to keep the code as is if the first recognized essence is not a 
system item.


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

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

[Michael Niedermayer]

On Tue, Feb 20, 2018 at 09:44:29AM +0100, Felix Matouschek wrote:
> I rebased the patch on the current master, it does apply again.
> 
> Tested it - still works.

ok, this patch was laying around for enough weeks on the mailing list,
will be part of my next push (unless some last minute issue is found)

Thanks

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

[王消寒]

jstebbins: kindly ping!

On Fri, Feb 16, 2018 at 2:42 PM, Xiaohan Wang (王消寒) 
wrote:

> +jstebbins@ who wrote that code.
>
> On Fri, Feb 16, 2018 at 12:30 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Thu, Feb 15, 2018 at 12:10:33PM -0800, Xiaohan Wang (王消寒) wrote:
>> >
>>
>> >  mov.c |3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> > 5597d0b095f8b15eb11503010a51c2bc2c022413
>> 0001-ffmpeg-Fix-memset-size-on-ctts_data-in-mov_read_trun.patch
>> > From 7c1e6b50ebe35b2a38c4f1d0a988e31eccbd0ead Mon Sep 17 00:00:00 2001
>> > From: Xiaohan Wang 
>> > Date: Thu, 15 Feb 2018 12:05:53 -0800
>> > Subject: [PATCH] ffmpeg: Fix memset size on ctts_data in mov_read_trun()
>> >
>> > The allocated size of sc->ctts_data is
>> > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
>> >
>> > The size to memset at offset sc->ctts_data + sc->ctts_count should be
>> > (st->nb_index_entries + entries - sc->ctts_count) *
>> sizeof(*sc->ctts_data))
>> >
>> > The current code missed |entries| I believe.
>>
>> shouldnt "entries" be read by this function later and so shouldnt need a
>> memset?
>> I didnt write this, but it looks a bit to me as if it was intended to only
>> clear the area that would not be read later
>>
>
> I thought we only had sc->ctts_count entries before av_fast_realloc, so
> memset everything starting from sc->ctts_data + sc->ctts_count couldn't
> go wrong. But I am not familiar with this code and that could totally be
> wrong. I added jstebbins@ who wrote the code and hopefully we can get
> expert opinion there.
>
>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> No great genius has ever existed without some touch of madness. --
>> Aristotle
>>
>> ___
>> 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 02/10] avformat/mxfdec: fix essence_offset calculation

[Tomas Härdin]

lör 2018-02-17 klockan 22:45 +0100 skrev Marton Balint:
> The reference point for a KAG is the first byte of the key of a Partition 
> Pack.
> 
> Fixes ticket #2817.
> Fixes ticket #5317.
> 
> > Signed-off-by: Marton Balint 
> ---
>  libavformat/mxfdec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index fcae863ef4..95767ccba4 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -2875,8 +2875,8 @@ static int mxf_read_header(AVFormatContext *s)
>   *   for OPAtom we still need the actual essence_offset 
> though (the KL's length can vary)
>   */
>  int64_t op1a_essence_offset =
> -round_to_kag(mxf->current_partition->this_partition +
> - mxf->current_partition->pack_length,   
> mxf->current_partition->kag_size) +
> +mxf->current_partition->this_partition +
> +round_to_kag(mxf->current_partition->pack_length,   
> mxf->current_partition->kag_size) +
>  round_to_kag(mxf->current_partition->header_byte_count, 
> mxf->current_partition->kag_size) +
>  round_to_kag(mxf->current_partition->index_byte_count,  
> mxf->current_partition->kag_size);

This seems like a rather elemental miscalculation, that I wrote even. I
took a look at S377m, it had this to say:

> The first gridline in any partition is the first byte of the key of
> the partition pack that defines that
> partition.

Each partition starts at ThisPartition (plus run-in) so this patch
should be correct. What's perhaps more suspect is the calculation
itself. It should *always* be possible to locate where Op1a essence
starts, by scanning to the first essence KLV. MXF is flexible enough
that having some sketchy calculation for where it *might* be is
probably not correct. One is free to insert any amount of padding

Of course this entire patchset would be unnecessary if we just used
bmxlib instead.

/Tomas

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

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[wm4]

On Sun, 18 Feb 2018 17:58:16 +
Josh de Kock  wrote:

> This should be the last of the major API changes. I'm not entirely
> sure if I missed anything. 
> 
> Josh
> 

All 3 patches LGTM if all tests pass and ffmpeg.c codec/device/filter
listing is the same as before the patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mpegenc - reject unsupported audio streams

[Michael Niedermayer]

On Tue, Feb 20, 2018 at 08:47:47PM +0530, Gyan Doshi wrote:
>  mpegenc.c |4 
>  1 file changed, 4 insertions(+)
> 1546f15d202546d69494e49a1a90a7668be9  
> 0002-avformat-mpegenc-reject-unsupported-audio-streams.patch
> From f0aabc7b9f959dc94084fb6d9b644104fc203566 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Tue, 20 Feb 2018 20:42:21 +0530
> Subject: [PATCH 2/2] avformat/mpegenc - reject unsupported audio streams
> 
> Only MP2, MP3, PCM S16BE, AC3 and DTS audio codecs
> are supported by the muxer.
> ---
>  libavformat/mpegenc.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
> index 4c6fa67fb8..59e3f8c83f 100644
> --- a/libavformat/mpegenc.c
> +++ b/libavformat/mpegenc.c
> @@ -392,6 +392,10 @@ static av_cold int mpeg_mux_init(AVFormatContext *ctx)
>  stream->lpcm_header[1] = (st->codecpar->channels - 1) | (j 
> << 4);
>  stream->lpcm_header[2] = 0x80;
>  stream->lpcm_align = st->codecpar->channels * 2;
> +} else if (st->codecpar->codec_id != AV_CODEC_ID_MP2 &&
> +   st->codecpar->codec_id != AV_CODEC_ID_MP3) {
> +   av_log(ctx, AV_LOG_ERROR, "Unsupported audio codec. 
> Must be one of mp2, mp3, pcm_s16be, ac3 or dts.\n");
> +   goto fail;

this looks like its missing AV_CODEC_ID_MP1 at least

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

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


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

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[wm4]

On Wed, 21 Feb 2018 19:14:59 +0100
Michael Niedermayer  wrote:

> On Wed, Feb 21, 2018 at 09:27:02AM +0100, wm4 wrote:
> > On Tue, 20 Feb 2018 21:45:12 +0100
> > Michael Niedermayer  wrote:
> >   
> > > On Tue, Feb 20, 2018 at 06:28:20PM +0100, wm4 wrote:  
> > > > On Tue, 20 Feb 2018 17:30:32 +0100
> > > > Michael Niedermayer  wrote:
> > > > 
> > > > > On Tue, Feb 20, 2018 at 10:17:02AM -0300, James Almer wrote:
> > > > > > On 2/20/2018 9:21 AM, wm4 wrote:  
> > > > > > > On Tue, 20 Feb 2018 08:47:51 -0300
> > > > > > > James Almer  wrote:  
> [...]
> > > > And for the 100th time: the new API is completely orthogonal to
> > > > allowing user-registered components. Since nobody could actually use
> > > > the API before, it's no problem to drop the old APIs now, and to add
> > > > actually working API once the other, much much much bigger problems are
> > > > solved.
> > > > 
> > > > Even if you argue that keeping the linked list is absolutely necessary,
> > > > the new API could support a linked list too.
> > > > 
> > > > > is it the ff_* symbols you are thinking of ?
> > > > 
> > > > ff_ symbols are private.
> > > > 
> > > > > This is a problem for an existing API it is not a problem for a new 
> > > > > API as
> > > > > we can change the symbols if they are intended to be used for 
> > > > > individual
> > > > > component registration.
> > > > > The whole discussion is about designing a new API. So any limitation 
> > > > > of
> > > > > an existing API can be changed.
> > > > > 
> > > > > There also should be no need to call register_all in the existing API,
> > > > > and there cannot be such a problem in a new design because it would be
> > > > > a new design you wouldnt design it to "not work".
> > > > 
> > > > You're just being contradictory all across the board here. In other
> > > > places you're claiming this register mechanism is needed for
> > > > security or to make it possible to eliminate unused components when
> > > > static linking. But if all components are already registered without
> > > > doing anything, how is that supposed to work?
> > > 
> > > If an application wants to register all, it calls the register_all()
> > > function
> > > If an application wants to register a subset it registers just that
> > > subset and does not call register_all  
> > 
> > But you just said on your mail "There also should be no need to call
> > register_all in the existing API,". How is that supposed to mesh with 
> > "If an application wants to register a subset it registers just that
> > subset and does not call register_all".  
> 
> I see no contradiction between what you quote, if that is what you meant:
> "There also should be no need to call register_all in the existing API,"
> and
> "If an application wants to register a subset it registers just that subset 
> and does not call register_all"

If there's no contradiction, it implies that either the first register
call will implicitly unregister all "automatically" registered
components, or the code has to explicitly unregister components. but in
both cases this would still require linking all components even if you
use static linking.

So you have the following possibilities:
- register_all needs to be called
  - contradicts your claim it doesn't need to be called
- register_all needs not to be called
  - all components are already registered implicitly
=> static linking will pull in all components
  - but the application can register a subset of components it needs
(your claim)
=> probably means components get unregistered as soon as the
   application registers a subset (or some really tricky linker
   magic that removes the auto registration code if manual
   registration functions are used?)

Well, which is it? But you could also just explicitly say what you have
in mind.

> 
> > 
> > But indeed one goal was that applications don't have to call the
> > completely pointless register_all functions.  
> 
> >   
> > > And even the documentation says this currently:
> > > /**
> > >  * Register all the codecs, parsers and bitstream filters which were 
> > > enabled at
> > >  * configuration time. If you do not call this function you can select 
> > > exactly
> > >  * which formats you want to support, by using the individual registration
> > >  * functions.
> > >  *  
> > 
> > Explain how that could actually work with dynamic linking.  
> 
> If you see an issue with dynamic linking, please
> explain what you mean, and i will try to show that it does not
> affect a newly designed API.

ff_ symbols are not exported across DSO/DLL boundaries. You seem to be
mixing the discussion about old and new APIs, yes. Part of your
argument was that it breaks things that _were_ possible, but as I have
been telling you, selective registration of components could not be
used with dynamic linking.

> Fundamentally, one can 

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[Michael Niedermayer]

On Wed, Feb 21, 2018 at 09:27:02AM +0100, wm4 wrote:
> On Tue, 20 Feb 2018 21:45:12 +0100
> Michael Niedermayer  wrote:
> 
> > On Tue, Feb 20, 2018 at 06:28:20PM +0100, wm4 wrote:
> > > On Tue, 20 Feb 2018 17:30:32 +0100
> > > Michael Niedermayer  wrote:
> > >   
> > > > On Tue, Feb 20, 2018 at 10:17:02AM -0300, James Almer wrote:  
> > > > > On 2/20/2018 9:21 AM, wm4 wrote:
> > > > > > On Tue, 20 Feb 2018 08:47:51 -0300
> > > > > > James Almer  wrote:
[...]
> > > And for the 100th time: the new API is completely orthogonal to
> > > allowing user-registered components. Since nobody could actually use
> > > the API before, it's no problem to drop the old APIs now, and to add
> > > actually working API once the other, much much much bigger problems are
> > > solved.
> > > 
> > > Even if you argue that keeping the linked list is absolutely necessary,
> > > the new API could support a linked list too.
> > >   
> > > > is it the ff_* symbols you are thinking of ?  
> > > 
> > > ff_ symbols are private.
> > >   
> > > > This is a problem for an existing API it is not a problem for a new API 
> > > > as
> > > > we can change the symbols if they are intended to be used for individual
> > > > component registration.
> > > > The whole discussion is about designing a new API. So any limitation of
> > > > an existing API can be changed.
> > > > 
> > > > There also should be no need to call register_all in the existing API,
> > > > and there cannot be such a problem in a new design because it would be
> > > > a new design you wouldnt design it to "not work".  
> > > 
> > > You're just being contradictory all across the board here. In other
> > > places you're claiming this register mechanism is needed for
> > > security or to make it possible to eliminate unused components when
> > > static linking. But if all components are already registered without
> > > doing anything, how is that supposed to work?  
> > 
> > If an application wants to register all, it calls the register_all()
> > function
> > If an application wants to register a subset it registers just that
> > subset and does not call register_all
> 
> But you just said on your mail "There also should be no need to call
> register_all in the existing API,". How is that supposed to mesh with 
> "If an application wants to register a subset it registers just that
> subset and does not call register_all".

I see no contradiction between what you quote, if that is what you meant:
"There also should be no need to call register_all in the existing API,"
and
"If an application wants to register a subset it registers just that subset and 
does not call register_all"


> 
> But indeed one goal was that applications don't have to call the
> completely pointless register_all functions.

> 
> > And even the documentation says this currently:
> > /**
> >  * Register all the codecs, parsers and bitstream filters which were 
> > enabled at
> >  * configuration time. If you do not call this function you can select 
> > exactly
> >  * which formats you want to support, by using the individual registration
> >  * functions.
> >  *
> 
> Explain how that could actually work with dynamic linking.

If you see an issue with dynamic linking, please
explain what you mean, and i will try to show that it does not
affect a newly designed API.
Fundamentally, one can of course proof this simply by showing that
other libs do have working registration style functions even when
dynamically linked.


> 
> > 
> > >   
> > > >   
> > > > > 
> > > > > Nevermind then, my argument was focused on preventing losing some link
> > > > > time optimization for static libraries assuming proper API usage.
> > > > > 
> > > > > > 
> > > > > > And that can't be made with dynamic linking either. If you 
> > > > > > statically
> > > > > > link anyway, you probably control everything, and you can configure 
> > > > > > this
> > > > > > stuff at compile time.
> > > > > > 
> > > > > > Then I guess there's this very special case where a fuzzer 
> > > > > > statically
> > > > > > links to libavcodec, and registers only a few components 
> > > > > > (technically
> > > > > > violating the API and by guessing the component symbol name), and
> > > > > > without calling the register_all functions. This would make the
> > > > > > resulting executable much smaller, which is apparently important
> > > > > > because Google (who runs the fuzzers for their oss-fuzz project) is 
> > > > > > too
> > > > > > poor (?) to host all the statically linked fuzzers, _or_ the 
> > > > > > whitelist
> > > > > > stuff is not enough to trick the fuzzer into not trying to fuzz the
> > > > > > wrong code. In addition, it's apparently infeasible to just build
> > > > > > every fuzzer with a separate libavcodec. (Not sure about the 
> > > > > > details, it
> > > > > > was something like this.)
> > > > > > 
> > > > > > Those requirements are really quite nebulous. I don't 

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mpegenc - log error msgs for unsupported LPCM streams

[Michael Niedermayer]

On Tue, Feb 20, 2018 at 08:47:14PM +0530, Gyan Doshi wrote:
>  mpegenc.c |   15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> ce683c8f43bc80d03c4fb3efaeb9978ed1d2c860  
> 0001-avformat-mpegenc-log-error-msgs-for-unsupported-LPCM.patch
> From 5f5cc12ff449fecfe668ec4537b8f2bb16d896d7 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Tue, 20 Feb 2018 20:31:28 +0530
> Subject: [PATCH 1/2] avformat/mpegenc - log error msgs for unsupported LPCM
>  streams
> 
> The MPEG-PS muxer only accepts PCM streams having up to 8 channels
> and the following sampling rates: 32/44.1/48/96 kHz.
> ---
>  libavformat/mpegenc.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)

will apply

thx

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

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


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

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[James Almer]

On 2/21/2018 5:04 PM, wm4 wrote:
> On Sun, 18 Feb 2018 17:58:16 +
> Josh de Kock  wrote:
> 
>> This should be the last of the major API changes. I'm not entirely
>> sure if I missed anything. 
>>
>> Josh
>>
> 
> All 3 patches LGTM if all tests pass and ffmpeg.c codec/device/filter
> listing is the same as before the patch.

I recall he mentioned on IRC some problems with threading after further
testing this set. I don't know if that was fixed (he at least didn't sed
an updated version), or if it was some artifact of a dirty testing tree.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

[Thomas Mundt]

Hi,

2018-02-12 16:37 GMT+01:00 Vasile Toncu :

> Hello,
>
> there have been some discussions about tinterlace filter licensing. In the
> end, I was unable to contact all the authorship holders.
>
> The main author, one from MPlayer project, is Michael Zucchi. It is quite
> probably that the copyright is holden by the company that he worked for,
> Ximian, which no longer exists. It is less probably that I'll came up with
> the approval off all the parts involved in this deal.
>
> However, some of the later developers of tinterlace agreed to release the
> parts they wrote under LGPL. I mention here Thomas Mundt and Stefano
> Sabatini.
>
> This being said, I come up with a new filter - reinterlace - which
> implements all the tinterlace functionalities and adds a few more.
>
> The new filter is added to ffmpeg without --enable-gpl and/or
> --enable-nonfree. However, it these configure options are specified, the
> reinterlace will use ASM opts, imported from tinterlace. I've used support
> for 16bit depth video from the code written by Thomas Mundt. I added 2 new
> modes MERGE_BFF and MERGE_TFF. I've changed MODE_PAD, so it does not drop
> last frame from the input - tinterlace did so.
>
> In terms of performance, reinterlace gives basically the same fps as
> tinterlace does.
>
> Here is the patch thats adds the filter. If everything goes well with this
> patch, I'll add a new patch that changes current tinterlace with
> reinterlace.
>

since I´m maintainer of the tinterlace filter I should review your patch.
Unfortunately I don´t have a possibility to compile or test it ATM.
So the review is incomplete and following comments are only parts of the
changes that might be necessary.
Also I don´t know which requirements have to be fulfilled for porting code
from GPL to LGPL.
I will need help from more experienced ffmpeg developers.


> Thanks,
>
> -Vasile Toncu
>
> From 45010f4b4671edfe1318b84285d09dd28a882d63 Mon Sep 17 00:00:00 2001
> From: Vasile Toncu 
> Date: Mon, 12 Feb 2018 14:16:27 +0200
> Subject: [PATCH] Added reitnerlace filter.
>
> ---
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/reinterlace.h | 141 +++
>  libavfilter/vf_reinterlace.c  | 773
> ++
>  libavfilter/x86/Makefile  |   1 +
>  libavfilter/x86/vf_reinterlace_init.c | 101 +
>  6 files changed, 1018 insertions(+)
>  create mode 100644 libavfilter/reinterlace.h
>  create mode 100644 libavfilter/vf_reinterlace.c
>  create mode 100644 libavfilter/x86/vf_reinterlace_init.c
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 6a60836..c3095ba 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -286,6 +286,7 @@ OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
>  OBJS-$(CONFIG_READEIA608_FILTER) += vf_readeia608.o
>  OBJS-$(CONFIG_READVITC_FILTER)   += vf_readvitc.o
>  OBJS-$(CONFIG_REALTIME_FILTER)   += f_realtime.o
> +OBJS-$(CONFIG_REINTERLACE_FILTER)+= vf_reinterlace.o
>  OBJS-$(CONFIG_REMAP_FILTER)  += vf_remap.o framesync.o
>  OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
>  OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o
> lavfutils.o vf_removelogo.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 9adb109..60fb9b5 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -295,6 +295,7 @@ static void register_all(void)
>  REGISTER_FILTER(READEIA608, readeia608, vf);
>  REGISTER_FILTER(READVITC,   readvitc,   vf);
>  REGISTER_FILTER(REALTIME,   realtime,   vf);
> +REGISTER_FILTER(REINTERLACE,reinterlace,vf);
>  REGISTER_FILTER(REMAP,  remap,  vf);
>  REGISTER_FILTER(REMOVEGRAIN,removegrain,vf);
>  REGISTER_FILTER(REMOVELOGO, removelogo, vf);
> diff --git a/libavfilter/reinterlace.h b/libavfilter/reinterlace.h
> new file mode 100644
> index 000..bb66f63
> --- /dev/null
> +++ b/libavfilter/reinterlace.h
> @@ -0,0 +1,141 @@
> +/*
> + * Copyright (c) 2017 Vasile Toncu 
> + Copyright (c) 2017 Thomas Mundt 
> + *
> + * 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
> 

Re: [FFmpeg-devel] [PATCH v2] libavformat/tls: pass numeric hostnames to tls_connect_cbs()

[Stefan _]

Hadn't seen that one, it does indeed describe this exact problem.
I've included it in the commit message, new patch attached.

On 20.02.2018 at 22:30 Carl Eugen Hoyos wrote:
> 2018-02-20 19:40 GMT+01:00 Stefan _ :
>
>> attached patch fixes a small issue with the libtls backend.
> Please mention ticket #7029 if it is related.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


From 1f8eccb9450847271dae2543e4d8bbb32fc89161 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Tue, 20 Feb 2018 19:18:13 +0100
Subject: [PATCH] libavformat/tls: pass numeric hostnames to tls_connect_cbs()

Numeric hosts in certificates are not very common, but supported by LibreSSL.
Forward the IP address to make verification work in this case.
Fixes ticket #7029.
---
 libavformat/tls_libtls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/tls_libtls.c b/libavformat/tls_libtls.c
index 1321f7922..ba83b56ff 100644
--- a/libavformat/tls_libtls.c
+++ b/libavformat/tls_libtls.c
@@ -119,7 +119,7 @@ static int ff_tls_open(URLContext *h, const char *uri, int flags, AVDictionary *
 
 if (!c->listen) {
 ret = tls_connect_cbs(p->ctx, tls_read_callback, tls_write_callback,
-c->tcp, !c->numerichost ? c->host : NULL);
+c->tcp, c->host);
 } else {
 struct tls *ctx_new;
 ret = tls_accept_cbs(p->ctx, _new, tls_read_callback,
-- 
2.16.2

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

[FFmpeg-devel] Stream description

[Francesco, Cuzzocrea]

Hi to all

I'm writing a module for ffmpeg that demuxes custom file format. Up to 
now audio is ok but I haven't figured out how


to describe video.  Our format is jpeg2000 4:2:2 stored on file as per 
field, that is there is filed0 codestream and field 1


codestream for each frame. This is the description I made for video stream:

    // Add video stream
    v_st = avformat_new_stream(cblt->fc, NULL);
    if (!v_st) {
    av_log(cblt->fc, AV_LOG_ERROR, "could not allocate video 
stream\n");

    ret = AVERROR(ENOMEM);
    goto fail_and_free;
    }

    v_st->index = 0;    v_st->id = 0;

   v_st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
    v_st->codecpar->width = 1920;

   v_st->codecpar->codec_id = AV_CODEC_ID_JPEG2000;
    v_st->codecpar->format = AV_PIX_FMT_YUV422P;
    v_st->codecpar->height = 540; /* Field height, not frame height */
    v_st->codecpar->field_order = AV_FIELD_TB;
    v_st->time_base.num = 1; v_st->time_base.den = 25;
    v_st->avg_frame_rate.num = 25; v_st->avg_frame_rate.den = 1;

    v_st->duration = 75 ; // Clip is of 3 seconds => 75 frames
    v_st->start_time = 0;
    v_st->nb_frames = 75;
    v_st->sample_aspect_ratio.num = 4; v_st->sample_aspect_ratio.den = 3;

With this description only field 0 is decoded.  If in the 
blt_read_packet function


I insert field 0 codestream and field 1 codestream, in the Packet data 
buffer, I receive an error.


How can I describe my stream as per field ?

regards

--
/***\
*Ing. Francesco  Cuzzocrea
*company:BLT Italia srlweb:  http://www.blt.it
*address:via Rosselli, 91 city:  Lido di CAMAIORE
*country:ITALY zip:  55043-i
*  Tel. :+39 0584 904788   Fax:  +39 0584 904789
* e-mail:   france...@bltitalia.com
\***/
--  BLT will be at BVE2018 (27 Feb ~ 1 Mar 2018)  -  Booth  H18   --

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

Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: use a linked list to queue packets

[James Almer]

On 2/21/2018 4:43 AM, wm4 wrote:
> On Wed, 21 Feb 2018 00:08:45 -0300
> James Almer  wrote:
> 
>> It's more robust and efficient.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/matroskadec.c | 90 
>> +++
>>  1 file changed, 52 insertions(+), 38 deletions(-)
>>
>> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>> index 2faaf9dfb8..241ee5fed1 100644
>> --- a/libavformat/matroskadec.c
>> +++ b/libavformat/matroskadec.c
>> @@ -338,9 +338,8 @@ typedef struct MatroskaDemuxContext {
>>  int64_t segment_start;
>>  
>>  /* the packet queue */
>> -AVPacket **packets;
>> -int num_packets;
>> -AVPacket *prev_pkt;
>> +AVPacketList *queue;
>> +AVPacketList *queue_end;
>>  
>>  int done;
>>  
>> @@ -2722,11 +2721,14 @@ fail:
>>  static int matroska_deliver_packet(MatroskaDemuxContext *matroska,
>> AVPacket *pkt)
>>  {
>> -if (matroska->num_packets > 0) {
>> +if (matroska->queue) {
>>  MatroskaTrack *tracks = matroska->tracks.elem;
>>  MatroskaTrack *track;
>> -memcpy(pkt, matroska->packets[0], sizeof(AVPacket));
>> -av_freep(>packets[0]);
>> +AVPacketList *pktl = matroska->queue;
>> +
>> +av_packet_move_ref(pkt, >pkt);
>> +matroska->queue = pktl->next;
>> +av_free(pktl);
>>  track = [pkt->stream_index];
>>  if (track->has_palette) {
>>  uint8_t *pal = av_packet_new_side_data(pkt, 
>> AV_PKT_DATA_PALETTE, AVPALETTE_SIZE);
>> @@ -2737,41 +2739,45 @@ static int 
>> matroska_deliver_packet(MatroskaDemuxContext *matroska,
>>  }
>>  track->has_palette = 0;
>>  }
>> -if (matroska->num_packets > 1) {
>> -void *newpackets;
>> -memmove(>packets[0], >packets[1],
>> -(matroska->num_packets - 1) * sizeof(AVPacket *));
>> -newpackets = av_realloc(matroska->packets,
>> -(matroska->num_packets - 1) *
>> -sizeof(AVPacket *));
>> -if (newpackets)
>> -matroska->packets = newpackets;
>> -} else {
>> -av_freep(>packets);
>> -matroska->prev_pkt = NULL;
>> -}
>> -matroska->num_packets--;
>> +if (!matroska->queue)
>> +matroska->queue_end = NULL;
>>  return 0;
>>  }
>>  
>>  return -1;
>>  }
>>  
>> +static int matroska_queue_packet(MatroskaDemuxContext *matroska, AVPacket 
>> *pkt)
>> +{
>> +AVPacketList *pktl = av_malloc(sizeof(*pktl));
>> +
>> +if (!pktl)
>> +return AVERROR(ENOMEM);
>> +av_packet_move_ref(>pkt, pkt);
>> +pktl->next = NULL;
>> +
>> +if (matroska->queue_end)
>> +matroska->queue_end->next = pktl;
>> +else
>> +matroska->queue = pktl;
>> +matroska->queue_end = pktl;
>> +
>> +return 0;
>> +}
>> +
>>  /*
>>   * Free all packets in our internal queue.
>>   */
>>  static void matroska_clear_queue(MatroskaDemuxContext *matroska)
>>  {
>> -matroska->prev_pkt = NULL;
>> -if (matroska->packets) {
>> -int n;
>> -for (n = 0; n < matroska->num_packets; n++) {
>> -av_packet_unref(matroska->packets[n]);
>> -av_freep(>packets[n]);
>> -}
>> -av_freep(>packets);
>> -matroska->num_packets = 0;
>> +AVPacketList *pktl;
>> +
>> +while (pktl = matroska->queue) {
>> +av_packet_unref(>pkt);
>> +matroska->queue = pktl->next;
>> +av_free(pktl);
>>  }
>> +matroska->queue_end = NULL;
>>  }
>>  
>>  static int matroska_parse_laces(MatroskaDemuxContext *matroska, uint8_t 
>> **buf,
>> @@ -2953,7 +2959,11 @@ static int 
>> matroska_parse_rm_audio(MatroskaDemuxContext *matroska,
>>  track->audio.buf_timecode = AV_NOPTS_VALUE;
>>  pkt->pos  = pos;
>>  pkt->stream_index = st->index;
>> -dynarray_add(>packets, >num_packets, pkt);
>> +ret = matroska_queue_packet(matroska, pkt);
>> +if (ret < 0) {
>> +av_packet_free();
>> +return AVERROR(ENOMEM);
>> +}
>>  }
>>  
>>  return 0;
>> @@ -3152,8 +3162,11 @@ static int matroska_parse_webvtt(MatroskaDemuxContext 
>> *matroska,
>>  pkt->duration = duration;
>>  pkt->pos = pos;
>>  
>> -dynarray_add(>packets, >num_packets, pkt);
>> -matroska->prev_pkt = pkt;
>> +err = matroska_queue_packet(matroska, pkt);
>> +if (err < 0) {
>> +av_packet_free();
>> +return AVERROR(ENOMEM);
>> +}
>>  
>>  return 0;
>>  }
>> @@ -3268,8 +3281,11 @@ FF_DISABLE_DEPRECATION_WARNINGS
>>  FF_ENABLE_DEPRECATION_WARNINGS
>>  #endif
>>  
>> -dynarray_add(>packets, >num_packets, pkt);
>> -matroska->prev_pkt = pkt;
>> +res = matroska_queue_packet(matroska, pkt);
>> +

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

[Sven Dueking]

> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag von
> Michael Niedermayer
> Gesendet: Mittwoch, 21. Februar 2018 14:35
> An: FFmpeg development discussions and patches
> Betreff: Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision Open
> SRT protocol
> 
> On Wed, Feb 21, 2018 at 10:16:48AM +0100, Sven Dueking wrote:
> > protocol requires libsrt (https://github.com/Haivision/srt) to be
> > installed
> >
> > Signed-off-by: Sven Dueking 
> > ---
> >  MAINTAINERS |   1 +
> >  configure   |   5 +
> >  doc/protocols.texi  | 134 ++-
> >  libavformat/Makefile|   1 +
> >  libavformat/opensrt.c   | 589
> > 
> >  libavformat/protocols.c |   1 +
> >  6 files changed, 730 insertions(+), 1 deletion(-)  create mode 100644
> > libavformat/opensrt.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index b691bd5..3e0355a 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -499,6 +499,7 @@ Protocols:
> >http.cRonald S. Bultje
> >libssh.c  Lukasz Marek
> >mms*.cRonald S. Bultje
> > +  opensrt.c sven Dueking
> >udp.c Luca Abeni
> >icecast.c Marvin Scholz
> >
> > diff --git a/configure b/configure
> > index 013308c..9a78bae 100755
> > --- a/configure
> > +++ b/configure
> > @@ -294,6 +294,7 @@ External library support:
> >--enable-opengl  enable OpenGL rendering [no]
> >--enable-openssl enable openssl, needed for https support
> > if gnutls or libtls is not used [no]
> > +  --enable-opensrt enable Haivision Open SRT protocol [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] @@ -1648,6 +1649,7 @@ EXTERNAL_LIBRARY_LIST="
> >  mediacodec
> >  openal
> >  opengl
> > +opensrt
> 
> there is something wrong with newlines
> this patch is corrupted and cannot be tested or applied
> 
> [...]

Hi Michael,

Sorry, no idea why this happens. Patch attached.

> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> then the original author, trying to rewrite it will not make it better.


0001-avformat-opensrt-add-Haivision-Open-SRT-protocol.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

On Wed, Feb 21, 2018 at 10:16:48AM +0100, Sven Dueking wrote:
> protocol requires libsrt (https://github.com/Haivision/srt) to be installed
> 
> Signed-off-by: Sven Dueking 
> ---
>  MAINTAINERS |   1 +
>  configure   |   5 +
>  doc/protocols.texi  | 134 ++-
>  libavformat/Makefile|   1 +
>  libavformat/opensrt.c   | 589
> 
>  libavformat/protocols.c |   1 +
>  6 files changed, 730 insertions(+), 1 deletion(-)  create mode 100644
> libavformat/opensrt.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b691bd5..3e0355a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -499,6 +499,7 @@ Protocols:
>http.cRonald S. Bultje
>libssh.c  Lukasz Marek
>mms*.cRonald S. Bultje
> +  opensrt.c sven Dueking
>udp.c Luca Abeni
>icecast.c Marvin Scholz
>  
> diff --git a/configure b/configure
> index 013308c..9a78bae 100755
> --- a/configure
> +++ b/configure
> @@ -294,6 +294,7 @@ External library support:
>--enable-opengl  enable OpenGL rendering [no]
>--enable-openssl enable openssl, needed for https support
> if gnutls or libtls is not used [no]
> +  --enable-opensrt enable Haivision Open SRT protocol [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] @@ -1648,6 +1649,7 @@ EXTERNAL_LIBRARY_LIST="
>  mediacodec
>  openal
>  opengl
> +opensrt

there is something wrong with newlines
this patch is corrupted and cannot be tested or applied

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: set AV_DISPOSITION_DEPENDENT for mix_type=0 supplementary audio

[Michael Niedermayer]

On Fri, Feb 16, 2018 at 11:06:39AM -0800, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  fftools/ffmpeg.c   | 1 +
>  libavformat/avformat.h | 1 +
>  libavformat/dump.c | 2 ++
>  libavformat/mpegts.c   | 3 +++
>  4 files changed, 7 insertions(+)
> 
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index a37de2ff98..bea922b0aa 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -3592,6 +3592,7 @@ static int init_output_stream(OutputStream *ost, char 
> *error, int error_len)
>  { "clean_effects"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> AV_DISPOSITION_CLEAN_EFFECTS },.unit = "flags" },
>  { "captions", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> AV_DISPOSITION_CAPTIONS  },.unit = "flags" },
>  { "descriptions", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> AV_DISPOSITION_DESCRIPTIONS  },.unit = "flags" },
> +{ "dependent"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> AV_DISPOSITION_DEPENDENT },.unit = "flags" },
>  { "metadata", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> AV_DISPOSITION_METADATA  },.unit = "flags" },
>  { NULL },
>  };


> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 4ea1b5ab72..78e87be8fb 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -845,6 +845,7 @@ typedef struct AVStreamInternal AVStreamInternal;
>  #define AV_DISPOSITION_CAPTIONS 0x1
>  #define AV_DISPOSITION_DESCRIPTIONS 0x2
>  #define AV_DISPOSITION_METADATA 0x4
> +#define AV_DISPOSITION_DEPENDENT0x8
>  

These all should have more documentation (relevant for teh patch is just the
newly added one of course)

thx

[...]
-- 
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: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[Michael Niedermayer]

On Wed, Feb 21, 2018 at 04:04:15PM +0700, Muhammad Faiz wrote:
> On Tue, Feb 20, 2018 at 2:30 AM, Michael Niedermayer
>  wrote:
> > On Sun, Feb 18, 2018 at 05:58:16PM +, Josh de Kock wrote:
> >> This should be the last of the major API changes. I'm not entirely
> >> sure if I missed anything.
> >
> > Moving from a register based system where a user app can register
> > any subset to a system which registers all via an array will
> > increase the size of statically linked binaries for users only
> > using a subset.
> >
> > An example of this effect for codecs is tools/target_dec_fuzzer.c
> 
> Just an idea.
> Is it possible to generate just one executable to fuzz all decoders?

I suggested this last year already:
https://github.com/google/oss-fuzz/pull/559#issuecomment-298438415

From what i remember, this suggestion was not favoured

IIRC, after this we then eliminated all parts that can be and used 
the  linker with registering just the needed components to reduce the
size to within the constraints



> The target decoder can be added as an argument or environment variable.
> e.g: ./fuzzer --target aac
> or FUZZER_TARGET=aac ./fuzzer
> 
> With this approach, we can save lot of disk space.

ffmpeg-devel really is the wrong place to discuss this.
The best bet is probably just to implement it (make sure it works, existing
testcases still reproduce issues, stack traces still are useable, ...)
and send a pull request to ossfuzz (with a CC to me or ffmpeg-devel)

Iam not able to say yes or no to this as i simply do not know why some
of the preferrances in the design exist.

thx

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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

Re: [FFmpeg-devel] [PATCH 2/2] Implement dynamic loading of NewTek NDI library

[Nicolas George]

Marton Balint (2018-02-20):
> The patch might has merits even if the library remains in the NONFREE
> section, no?

I see more code and easier circumvention of the GPL, but no merit.
Please be more specific.

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 v4 2/2] avformat/libopenmpt: Probe file format from file data if possible

[Jörn Heusipp]

When building with libopenmpt 0.3, use the libopenmpt file header
probing functions for probing. libopenmpt probing functions are
allocation-free and designed to be as fast as possible.

For libopenmpt 0.2, or when libopenmpt 0.3 file header probing cannot
probe successfully due to too small probe buffer, test the filename
against the file extensions supported by the libopenmpt library that
is actually linked, instead of relying on a hard-coded file extension
list. File extension testing is also allocation-free and designed to
be fast in libopenmpt. Avoiding a hard-coded file extension list is
useful because later libopenmpt versions will likely add support for
more module file formats.

libopenmpt file header probing is tested regularly against the FATE
suite and other diverse file collections by libopenmpt upstream in
order to avoid false positives.

FATE passes with './configure --enable-libopenmpt' as well as with
'./configure --enable-libopenmpt --enable-libmodplug'.

libopenmpt probing adds about 5%..10% cpu time (depending on precise
usage pattern and host CPU and compiler version used for libopenmpt)
compared to all current internal FFmpeg probing functions combined in
tools/probetest for all of its module formats combined (currently 41
modules formats in libopenmpt 0.3.4 and 234 file formats in FFmpeg).

Signed-off-by: Jörn Heusipp 
---
 libavformat/libopenmpt.c | 57 
 1 file changed, 57 insertions(+)

diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
index 5efbdc4..0fff702 100644
--- a/libavformat/libopenmpt.c
+++ b/libavformat/libopenmpt.c
@@ -218,6 +218,62 @@ static int read_seek_openmpt(AVFormatContext *s, int 
stream_idx, int64_t ts, int
 return 0;
 }
 
+static int probe_openmpt_extension(AVProbeData *p)
+{
+const char *ext;
+if (p->filename) {
+ext = strrchr(p->filename, '.');
+if (ext && strlen(ext + 1) > 0) {
+ext++;  /* skip '.' */
+if (openmpt_is_extension_supported(ext) == 1)
+return AVPROBE_SCORE_EXTENSION;
+}
+}
+return 0;
+}
+
+static int read_probe_openmpt(AVProbeData *p)
+{
+#if OPENMPT_API_VERSION_AT_LEAST(0,3,0)
+int probe_result;
+if (p->buf && p->buf_size > 0) {
+probe_result = openmpt_probe_file_header_without_filesize(
+   OPENMPT_PROBE_FILE_HEADER_FLAGS_DEFAULT,
+   p->buf, p->buf_size,
+   _logfunc, NULL, NULL, NULL, NULL, NULL);
+if (probe_result == OPENMPT_PROBE_FILE_HEADER_RESULT_SUCCESS) {
+/* As probing here relies on code external to FFmpeg, do not return
+ * AVPROBE_SCORE_MAX in order to reduce the impact in the rare
+ * cases of false positives.
+ */
+return AVPROBE_SCORE_MIME + 1;
+} else if (probe_result == 
OPENMPT_PROBE_FILE_HEADER_RESULT_WANTMOREDATA) {
+if (probe_openmpt_extension(p) > 0) {
+return AVPROBE_SCORE_RETRY;
+} else {
+if (p->buf_size >= 
openmpt_probe_file_header_get_recommended_size()) {
+/* We have already received the recommended amount of data
+ * and still cannot decide. Return a rather low score.
+ */
+return AVPROBE_SCORE_RETRY / 2;
+} else {
+/* The file extension is unknown and we have very few data
+ * bytes available. libopenmpt cannot decide anything here,
+ * and returning any score > 0 would result in successfull
+ * probing of random data.
+ */
+return 0;
+}
+}
+} else if (probe_result == OPENMPT_PROBE_FILE_HEADER_RESULT_FAILURE) {
+return 0;
+}
+}
+#endif
+/* for older libopenmpt, fall back to file extension probing */
+return probe_openmpt_extension(p);
+}
+
 static const AVClass class_openmpt = {
 .class_name = "libopenmpt",
 .item_name  = av_default_item_name,
@@ -229,6 +285,7 @@ AVInputFormat ff_libopenmpt_demuxer = {
 .name   = "libopenmpt",
 .long_name  = NULL_IF_CONFIG_SMALL("Tracker formats (libopenmpt)"),
 .priv_data_size = sizeof(OpenMPTContext),
+.read_probe = read_probe_openmpt,
 .read_header= read_header_openmpt,
 .read_packet= read_packet_openmpt,
 .read_close = read_close_openmpt,
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] Added support for version field flag 0x04 in OpenEXR files

[Daniel Flehner Heen]

Ok, thanks. Glad it's getting sorted :)

On Feb 21, 2018 12:01, "Martin Vignali"  wrote:

> 2018-02-21 1:25 GMT+01:00 Daniel Flehner Heen :
>
> > Hi!
> >
> > First time poster so please excuse any mistakes made. I've tried
> submitting
> > a patch through git send-email but got issues authentication through
> gmail.
> > Attached is a patch file created with git format-patch.
> >
> > Commit message:
> >
> > Added support for version field flag 0x04 in OpenEXR files regarding long
> > names in attributes.
> > Should have no impact on decoding of images.
> >
> > Also added a bit more verbose logging of OpenEXR 2.x flags not yet
> > supported.
> >
>
> Hello,
>
> A similar patch, have been post on this mailing list, and i plan to apply
> it soon (probably not before the end of the week)
> The discussion can be follow here :
> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225443.html
> (the patch i plan to apply can be found here :
> http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/
> 20180217/da0052a9/attachment.obj
> )
>
> Looking your patch, doesn't sure it's correct,
> Long name flag can be set with tile or deep data (same idea for multipart
> and deep data (there is a sample in the official repo if i correctly
> remember))
> So it's not one flag or another.
>
> Martin
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v4 1/2] avformat/libopenmpt: Update file extensions list for libopenmpt 0.3

[Jörn Heusipp]

Signed-off-by: Jörn Heusipp 
---
 libavformat/libopenmpt.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
index 30c3d6e..5efbdc4 100644
--- a/libavformat/libopenmpt.c
+++ b/libavformat/libopenmpt.c
@@ -234,5 +234,9 @@ AVInputFormat ff_libopenmpt_demuxer = {
 .read_close = read_close_openmpt,
 .read_seek  = read_seek_openmpt,
 .priv_class = _openmpt,
-.extensions = 
"669,amf,ams,dbm,digi,dmf,dsm,far,gdm,imf,it,j2b,m15,mdl,med,mmcmp,mms,mo3,mod,mptm,mt2,mtm,nst,okt,plm,ppm,psm,pt36,ptm,s3m,sfx,sfx2,stk,stm,ult,umx,wow,xm,xpk",
+#if OPENMPT_API_VERSION_AT_LEAST(0,3,0)
+.extensions = 
"669,amf,ams,dbm,digi,dmf,dsm,dtm,far,gdm,ice,imf,it,j2b,m15,mdl,med,mmcmp,mms,mo3,mod,mptm,mt2,mtm,nst,okt,plm,ppm,psm,pt36,ptm,s3m,sfx,sfx2,st26,stk,stm,stp,ult,umx,wow,xm,xpk",
+#else
+.extensions = 
"669,amf,ams,dbm,digi,dmf,dsm,far,gdm,ice,imf,it,j2b,m15,mdl,med,mmcmp,mms,mo3,mod,mptm,mt2,mtm,nst,okt,plm,ppm,psm,pt36,ptm,s3m,sfx,sfx2,st26,stk,stm,ult,umx,wow,xm,xpk",
+#endif
 };
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] Added support for version field flag 0x04 in OpenEXR files

[Martin Vignali]

2018-02-21 1:25 GMT+01:00 Daniel Flehner Heen :

> Hi!
>
> First time poster so please excuse any mistakes made. I've tried submitting
> a patch through git send-email but got issues authentication through gmail.
> Attached is a patch file created with git format-patch.
>
> Commit message:
>
> Added support for version field flag 0x04 in OpenEXR files regarding long
> names in attributes.
> Should have no impact on decoding of images.
>
> Also added a bit more verbose logging of OpenEXR 2.x flags not yet
> supported.
>

Hello,

A similar patch, have been post on this mailing list, and i plan to apply
it soon (probably not before the end of the week)
The discussion can be follow here :
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225443.html
(the patch i plan to apply can be found here :
http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180217/da0052a9/attachment.obj
)

Looking your patch, doesn't sure it's correct,
Long name flag can be set with tile or deep data (same idea for multipart
and deep data (there is a sample in the official repo if i correctly
remember))
So it's not one flag or another.

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

[FFmpeg-devel] reinterlace filter review

[Vasile Toncu]

Hello,

will be there any review for the reinterlace filter [1].

Do you consider adding it to the next  release of ffmpeg?

Thanks,

Vasile Toncu

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

Re: [FFmpeg-devel] reinterlace filter review

[Vasile Toncu]

On 2/21/2018 12:21 PM, Vasile Toncu wrote:

will be there any review for the reinterlace filter [1].

[1] http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225257.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Sven Dueking]

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

Signed-off-by: Sven Dueking 
---
 MAINTAINERS |   1 +
 configure   |   5 +
 doc/protocols.texi  | 134 ++-
 libavformat/Makefile|   1 +
 libavformat/opensrt.c   | 589

 libavformat/protocols.c |   1 +
 6 files changed, 730 insertions(+), 1 deletion(-)  create mode 100644
libavformat/opensrt.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b691bd5..3e0355a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -499,6 +499,7 @@ Protocols:
   http.cRonald S. Bultje
   libssh.c  Lukasz Marek
   mms*.cRonald S. Bultje
+  opensrt.c sven Dueking
   udp.c Luca Abeni
   icecast.c Marvin Scholz
 
diff --git a/configure b/configure
index 013308c..9a78bae 100755
--- a/configure
+++ b/configure
@@ -294,6 +294,7 @@ External library support:
   --enable-opengl  enable OpenGL rendering [no]
   --enable-openssl enable openssl, needed for https support
if gnutls or libtls is not used [no]
+  --enable-opensrt enable Haivision Open SRT protocol [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] @@ -1648,6 +1649,7 @@ EXTERNAL_LIBRARY_LIST="
 mediacodec
 openal
 opengl
+opensrt
 "
 
 HWACCEL_AUTODETECT_LIBRARY_LIST="
@@ -3157,6 +3159,8 @@ libssh_protocol_deps="libssh"
 libtls_conflict="openssl gnutls"
 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"
@@ -6028,6 +6032,7 @@ 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   && require_pkg_config libsrt "srt >= 1.2.0"
srt/srt.h srt_socket
 enabled openssl   && { check_pkg_config openssl openssl
openssl/ssl.h OPENSSL_init_ssl ||
check_pkg_config openssl openssl
openssl/ssl.h SSL_library_init ||
check_lib openssl openssl/ssl.h
SSL_library_init -lssl -lcrypto || diff --git a/doc/protocols.texi
b/doc/protocols.texi index c24dc74..1d49eaa 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -752,12 +752,144 @@ Truncate existing files on write, if set to 1. A
value of 0 prevents  truncating. Default value is 1.
 
 @item workgroup
-Set the workgroup used for making connections. By default workgroup is not
specified.
+Set the workgroup used for making connections. By default workgroup is 
+not specified.
 
 @end table
 
 For more information see: @url{http://www.samba.org/}.
 
+@section srt
+
+Haivision Secure Reliable Transport Protocol via libsrt.
+
+The required syntax for a SRT url is:
+@example
+srt://@var{hostname}:@var{port}[?@var{options}]
+@end example
+
+@var{options} contains a list of &-separated options of the form 
+@var{key}=@var{val}.
+
+This protocol accepts the following options.
+
+@table @option
+@item connect_timeout
+Connection timeout. SRT cannot connect for RTT > 1500 msec
+(2 handshake exchanges) with the default connect timeout of
+3 seconds. This option applies to the caller and rendezvous connection 
+modes. The connect timeout is 10 times the value set for the rendezvous 
+mode (which can be used as a workaround for this connection problem 
+with earlier versions).
+
+@item fc=@var{bytes}
+Flight Flag Size (Window Size), in bytes. FC is actually an internal 
+parameter and you should set it to not less than 
+@option{recv_buffer_size} and @option{mss}. The default value is 
+relatively large, therefore unless you set a very large receiver 
+buffer, you do not need to change this option. Default value is 25600.
+
+@item inputbw=@var{bytes/seconds}
+Sender nominal input rate, in bytes per seconds. Used along with 
+@option{oheadbw}, when @option{maxbw} is set to relative (0), to 
+calculate maximum sending rate when recovery packets are sent along 
+with main media stream:
+@option{inputbw} * (100 + @option{oheadbw}) / 100 if @option{inputbw} 
+is not set while @option{maxbw} is set to relative (0), the actual 
+ctual input rate is evaluated inside the library. Default value is 0.
+
+@item iptos=@var{tos}
+IP Type of Service. Applies to sender only. Default value is 0xB8.
+
+@item 

Re: [FFmpeg-devel] [PATCH 2/2] Implement dynamic loading of NewTek NDI library

[Marton Balint]

On Wed, 21 Feb 2018, Maksym Veremeyenko wrote:


21.02.2018 0:39, Carl Eugen Hoyos пише:

2018-02-20 23:35 GMT+01:00 Marton Balint :


On Tue, 20 Feb 2018, Carl Eugen Hoyos wrote:


2018-02-20 17:32 GMT+01:00 Maksym Veremeyenko :


attached patch implement dynamic loading of NewTek library and
drop dependencies from NewTek SDK (if previous patch with
including headers applied)


This patch is not ok assuming the runtime library is not open
source and has a license compatible with the GPL.


The patch might has merits even if the library remains in the
NONFREE section, no?


It might, I do not immediately see them, though.


patch without altering *EXTERNAL_LIBRARY_NONFREE_LIST* has any chance to 
be reviewed?


Sure:


From 8c0337878bdb8a1ccbc56ede42686e2a4d8e882e Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko 
Date: Tue, 20 Feb 2018 17:16:46 +0200
Subject: [PATCH 2/2] Implement dynamic loading of NewTek NDI library

---
 configure  |   8 +--
 libavdevice/Makefile   |   4 +-
 libavdevice/libndi_newtek_common.c | 105 +
 libavdevice/libndi_newtek_common.h |   4 +-
 libavdevice/libndi_newtek_dec.c|  32 ++-
 libavdevice/libndi_newtek_enc.c|  16 --
 6 files changed, 144 insertions(+), 25 deletions(-)
 create mode 100644 libavdevice/libndi_newtek_common.c

diff --git a/configure b/configure
index 013308c..4782c77 100755
--- a/configure
+++ b/configure
@@ -1569,7 +1569,6 @@ EXTERNAL_LIBRARY_GPL_LIST="

 EXTERNAL_LIBRARY_NONFREE_LIST="
 decklink
-libndi_newtek
 libfdk_aac
 openssl
 libtls
@@ -1648,6 +1647,7 @@ EXTERNAL_LIBRARY_LIST="
 mediacodec
 openal
 opengl
+libndi_newtek
 "


Some people disagree with this, so better leave it in NONFREE for now.



 HWACCEL_AUTODETECT_LIBRARY_LIST="
@@ -3093,10 +3093,11 @@ decklink_indev_deps="decklink threads"
 decklink_indev_extralibs="-lstdc++"
 decklink_outdev_deps="decklink threads"
 decklink_outdev_extralibs="-lstdc++"
+libndi_newtek_deps_any="libdl LoadLibrary"
 libndi_newtek_indev_deps="libndi_newtek"
-libndi_newtek_indev_extralibs="-lndi"
+libndi_newtek_indev_extralibs=""


I believe you can simply delete this line.


 libndi_newtek_outdev_deps="libndi_newtek"
-libndi_newtek_outdev_extralibs="-lndi"
+libndi_newtek_outdev_extralibs=""


And this.


 dshow_indev_deps="IBaseFilter"
 dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi"
 fbdev_indev_deps="linux_fb_h"
@@ -5866,7 +5867,6 @@ enabled cuda_sdk  && require cuda_sdk cuda.h 
cuCtxCreate -lcuda
 enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
 enabled decklink  && { require_header DeckLinkAPI.h &&
{ check_cpp_condition DeckLinkAPIVersion.h 
"BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a060100" || die "ERROR: Decklink API version 
must be >= 10.6.1."; } }
-enabled libndi_newtek && require_header Processing.NDI.Lib.h


As other already pointed out, external headers in ffmpeg source tree are not
welcome anymore, so I guess you should keep this check. Maybe you should also
check the version of the headers, because you require SDK version V3 from 
now on, right?



 enabled frei0r&& require_header frei0r.h
 enabled gmp   && require gmp gmp.h mpz_export -lgmp
 enabled gnutls&& require_pkg_config gnutls gnutls gnutls/gnutls.h 
gnutls_global_init
diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index 8228d62..2d3322e 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -19,8 +19,8 @@ OBJS-$(CONFIG_BKTR_INDEV)+= bktr.o
 OBJS-$(CONFIG_CACA_OUTDEV)   += caca.o
 OBJS-$(CONFIG_DECKLINK_OUTDEV)   += decklink_enc.o decklink_enc_c.o 
decklink_common.o
 OBJS-$(CONFIG_DECKLINK_INDEV)+= decklink_dec.o decklink_dec_c.o 
decklink_common.o
-OBJS-$(CONFIG_LIBNDI_NEWTEK_OUTDEV)  += libndi_newtek_enc.o
-OBJS-$(CONFIG_LIBNDI_NEWTEK_INDEV)   += libndi_newtek_dec.o
+OBJS-$(CONFIG_LIBNDI_NEWTEK_OUTDEV)  += libndi_newtek_enc.o 
libndi_newtek_common.o
+OBJS-$(CONFIG_LIBNDI_NEWTEK_INDEV)   += libndi_newtek_dec.o 
libndi_newtek_common.o
 OBJS-$(CONFIG_DSHOW_INDEV)   += dshow_crossbar.o dshow.o 
dshow_enummediatypes.o \
 dshow_enumpins.o dshow_filter.o \
 dshow_pin.o dshow_common.o
diff --git a/libavdevice/libndi_newtek_common.c 
b/libavdevice/libndi_newtek_common.c
new file mode 100644
index 000..5202993
--- /dev/null
+++ b/libavdevice/libndi_newtek_common.c
@@ -0,0 +1,105 @@
+/*
+ * NewTek NDI common code
+ * Copyright (c) 2018 Maksym Veremeyenko
+ *
+ * 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 

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[Muhammad Faiz]

On Tue, Feb 20, 2018 at 2:30 AM, Michael Niedermayer
 wrote:
> On Sun, Feb 18, 2018 at 05:58:16PM +, Josh de Kock wrote:
>> This should be the last of the major API changes. I'm not entirely
>> sure if I missed anything.
>
> Moving from a register based system where a user app can register
> any subset to a system which registers all via an array will
> increase the size of statically linked binaries for users only
> using a subset.
>
> An example of this effect for codecs is tools/target_dec_fuzzer.c

Just an idea.
Is it possible to generate just one executable to fuzz all decoders?
The target decoder can be added as an argument or environment variable.
e.g: ./fuzzer --target aac
or FUZZER_TARGET=aac ./fuzzer

With this approach, we can save lot of disk space.


>
> This effect results because when the linker collects all objects
> of all static libs with a user application it can remove all symbols
> which are not referenced.
> If there is a single array that references all codecs, filters, formats
> and this array is referenced by a function which must be used then
> nothing can be removed at the link stage
>
> OTOH with a register function a register all which refernces all
> a user application can simply not use the reference all code and register
> the specific subset it needs with individual register calls.
> In this case the linker can ommit the register all and all codecs, formats
> and filters teh user application does not explicitly refer too.
> In the case where this applies this results in significantly smaller files
>
> I also expect they link faster and load faster but i forgot to benchmark this
> when i realized this issue exists and tested ...
>
> I am thus in favor of a system that does not unconditionally reference every
> codec/format/filter
>
> There can also be an advantage security wise if unneeded parts are never
> "registered"
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many things microsoft did are stupid, but not doing something just because
> microsoft did it is even more stupid. If everything ms did were stupid they
> would be bankrupt already.
>
> ___
> 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 0/3] Finish new iteration APIs

[wm4]

On Tue, 20 Feb 2018 21:45:12 +0100
Michael Niedermayer  wrote:

> On Tue, Feb 20, 2018 at 06:28:20PM +0100, wm4 wrote:
> > On Tue, 20 Feb 2018 17:30:32 +0100
> > Michael Niedermayer  wrote:
> >   
> > > On Tue, Feb 20, 2018 at 10:17:02AM -0300, James Almer wrote:  
> > > > On 2/20/2018 9:21 AM, wm4 wrote:
> > > > > On Tue, 20 Feb 2018 08:47:51 -0300
> > > > > James Almer  wrote:
> > > > > 
> > > > >>> It has fully achieved its objectives. There's no more visible global
> > > > >>> mutable state, and the actual global mutable state has been reduced 
> > > > >>> to
> > > > >>> less than 5 codec entries.  
> > > > >>
> > > > >> It's true that after the deprecation period they will effectively be 
> > > > >> the
> > > > >> only ones still mutable, but shouldn't the objective be to cover 
> > > > >> them all?
> > > > > 
> > > > > That would be nice. But this has been discussed before. No kind of
> > > > > different registration API could fix this issue either, unless we 
> > > > > start
> > > > > mallocing AVCodec structs and require the user to free them, or
> > > > > something equally absurd. The proper solution for this specific issue
> > > > > would be making a new API that somehow replaces AVCodec.pix_fmts.
> > > > > 
> > > > >>>
> > > > >>> Why are we discussing this _again_?  
> > > > >>
> > > > >> Because a drawback has been found, namely that link time optimization
> > > > >> using static libraries can't remove "non registered" modules anymore,
> > > > >> and now depends fully on what's enabled at configure time.
> > > > >> Ideally, a better registration based API that follows what i 
> > > > >> described
> > > > >> above should be designed with care.
> > > > > 
> > > > > Oh yeah, bikeshed attack by Michael. As it was said a few thousand 
> > > > > times
> > > > > already, public API users could NOT use the registration stuff to
> > > > > register only specific components at runtime. So they have to use the
> > > > > register_all variants, which pull in _all_ components even with static
> > > > > linking.
> > > > 
> > > > Oh, i assumed it was possible to use avcodec_register() on a manual
> > > > basis in a proper API usage scenario, but i see now that's not the 
> > > > case.
> > > 
> > > of course its possible to use avcodec_register() on a manual basis in a 
> > > proper API usage scenario, why would it not be ?
> > > 
> > > why do you think this function exists or was written ?  
> > 
> > I don't know, but it didn't make any sense. And wouldn't have made for
> > years to come.  
> 
> thats backward
> 
> if you look at git history the very first checkin 
> commit 9aeeeb63f7e1ab7b0b7bb839a5f258667a2d2d78 (HEAD)
> Author: Fabrice Bellard 
> Date:   Wed Dec 20 00:02:47 2000 +
> 
> Initial revision
> 
> has code like this:
> 
> ffmpeg.c:register_avencoder(_encoder);
> ffmpeg.c:register_avencoder(_encoder);
> ffmpeg.c:register_avencoder(_encoder);
> ffmpeg.c:register_avencoder(_encoder);
> 
> Here the application did use the register API to selectivly register
> codecs.

That's before FFmpeg has a stable API or even just ABI. It took a
decade or so to get there. I also think we didn't find a single
application that tried to do this these days. Maybe the fact that it
simply didn't work with dynamic linking also mattered.

> 
> 
> > 
> > And for the 100th time: the new API is completely orthogonal to
> > allowing user-registered components. Since nobody could actually use
> > the API before, it's no problem to drop the old APIs now, and to add
> > actually working API once the other, much much much bigger problems are
> > solved.
> > 
> > Even if you argue that keeping the linked list is absolutely necessary,
> > the new API could support a linked list too.
> >   
> > > is it the ff_* symbols you are thinking of ?  
> > 
> > ff_ symbols are private.
> >   
> > > This is a problem for an existing API it is not a problem for a new API as
> > > we can change the symbols if they are intended to be used for individual
> > > component registration.
> > > The whole discussion is about designing a new API. So any limitation of
> > > an existing API can be changed.
> > > 
> > > There also should be no need to call register_all in the existing API,
> > > and there cannot be such a problem in a new design because it would be
> > > a new design you wouldnt design it to "not work".  
> > 
> > You're just being contradictory all across the board here. In other
> > places you're claiming this register mechanism is needed for
> > security or to make it possible to eliminate unused components when
> > static linking. But if all components are already registered without
> > doing anything, how is that supposed to work?  
> 
> If an application wants to register all, it calls the register_all()
> function
> If an application wants to register a subset it registers just that
> 

Re: [FFmpeg-devel] [PATCH 1/3] avformat/movenc: addition of flag to fragment at every frame

[Dixit, Vishwanath]

>On 2/20/18, 8:28 PM, "Michael Niedermayer"  wrote:
>
>On Mon, Feb 19, 2018 at 11:25:09AM +0530, vdi...@akamai.com wrote:
>> From: Vishwanath Dixit 
>> 
>> ---
>>  libavformat/movenc.c | 10 +++---
>>  libavformat/movenc.h |  1 +
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>
>will apply
>
>thx
Thanks for applying the patch…

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