[FFmpeg-devel] [PATCH] avfilter/vf_overlay: remove duplicate parse line

[Steven Liu]

duplicate av_expr_eval x_pexpr, remove the second one.

Signed-off-by: Steven Liu 
---
 libavfilter/vf_overlay.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index aa5835ae3a..240f6f3803 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -149,7 +149,6 @@ static void eval_expr(AVFilterContext *ctx)
 
 s->var_values[VAR_X] = av_expr_eval(s->x_pexpr, s->var_values, NULL);
 s->var_values[VAR_Y] = av_expr_eval(s->y_pexpr, s->var_values, NULL);
-s->var_values[VAR_X] = av_expr_eval(s->x_pexpr, s->var_values, NULL);
 s->x = normalize_xy(s->var_values[VAR_X], s->hsub);
 s->y = normalize_xy(s->var_values[VAR_Y], s->vsub);
 }
-- 
2.14.3 (Apple Git-98)



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

[FFmpeg-devel] [PATCH 1/5] lavfi: VAAPI VPP common infrastructure.

[Jun Zhao]

From 17278f448133826593941ac6b105a4e81cc8b255 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 8 Jan 2018 15:56:43 +0800
Subject: [PATCH 1/5] lavfi: VAAPI VPP common infrastructure.

Re-work the VA-API common infrastructure.

Signed-off-by: Jun Zhao 
---
 libavfilter/vaapi_vpp.c | 366 
 libavfilter/vaapi_vpp.h |  75 ++
 2 files changed, 441 insertions(+)
 create mode 100644 libavfilter/vaapi_vpp.c
 create mode 100644 libavfilter/vaapi_vpp.h

diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c
new file mode 100644
index 00..326a716990
--- /dev/null
+++ b/libavfilter/vaapi_vpp.c
@@ -0,0 +1,366 @@
+/*
+ * 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 
+
+#include "libavutil/avassert.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_vaapi.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "vaapi_vpp.h"
+
+#include "libavutil/pixdesc.h"
+
+int vaapi_vpp_query_formats(AVFilterContext *avctx)
+{
+enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_VAAPI, AV_PIX_FMT_NONE,
+};
+int err;
+
+if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
+  &avctx->inputs[0]->out_formats)) < 0)
+return err;
+if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
+  &avctx->outputs[0]->in_formats)) < 0)
+return err;
+
+return 0;
+}
+
+int vaapi_vpp_pipeline_uninit(VAAPIVPPContext *ctx)
+{
+int i;
+for (i = 0; i < ctx->nb_filter_buffers; i++) {
+if (ctx->filter_buffers[i] != VA_INVALID_ID) {
+vaDestroyBuffer(ctx->hwctx->display, ctx->filter_buffers[i]);
+ctx->filter_buffers[i] = VA_INVALID_ID;
+}
+}
+ctx->nb_filter_buffers = 0;
+
+if (ctx->va_context != VA_INVALID_ID) {
+vaDestroyContext(ctx->hwctx->display, ctx->va_context);
+ctx->va_context = VA_INVALID_ID;
+}
+
+if (ctx->va_config != VA_INVALID_ID) {
+vaDestroyConfig(ctx->hwctx->display, ctx->va_config);
+ctx->va_config = VA_INVALID_ID;
+}
+
+av_buffer_unref(&ctx->output_frames_ref);
+av_buffer_unref(&ctx->device_ref);
+ctx->hwctx = 0;
+
+return 0;
+}
+
+int vaapi_vpp_config_input(AVFilterLink *inlink, VAAPIVPPContext *ctx)
+{
+AVFilterContext *avctx = inlink->dst;
+
+if (ctx->pipeline_uninit)
+ctx->pipeline_uninit(avctx);
+
+if (!inlink->hw_frames_ctx) {
+av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
+   "required to associate the processing device.\n");
+return AVERROR(EINVAL);
+}
+
+ctx->input_frames_ref = av_buffer_ref(inlink->hw_frames_ctx);
+ctx->input_frames = (AVHWFramesContext*)ctx->input_frames_ref->data;
+
+return 0;
+}
+
+int vaapi_vpp_config_output(AVFilterLink *outlink, VAAPIVPPContext *ctx)
+{
+AVFilterContext *avctx = outlink->src;
+AVVAAPIHWConfig *hwconfig = NULL;
+AVHWFramesConstraints *constraints = NULL;
+AVVAAPIFramesContext *va_frames;
+VAStatus vas;
+int err, i;
+
+if (ctx->pipeline_uninit)
+ctx->pipeline_uninit(avctx);
+
+av_assert0(ctx->input_frames);
+ctx->device_ref = av_buffer_ref(ctx->input_frames->device_ref);
+ctx->hwctx = ((AVHWDeviceContext*)ctx->device_ref->data)->hwctx;
+
+av_assert0(ctx->va_config == VA_INVALID_ID);
+vas = vaCreateConfig(ctx->hwctx->display, VAProfileNone,
+ VAEntrypointVideoProc, 0, 0, &ctx->va_config);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Failed to create processing pipeline "
+   "config: %d (%s).\n", vas, vaErrorStr(vas));
+err = AVERROR(EIO);
+goto fail;
+}
+
+hwconfig = av_hwdevice_hwconfig_alloc(ctx->device_ref);
+if (!hwconfig) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+hwconfig->config_id = ctx->va_config;
+
+constraints = av_hwdevice_get_hwframe_constraints(ctx->device_ref,
+  hwconfig);
+if (!constraints) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+
+if (ctx->output_format == AV_PIX_FMT_NONE)
+ctx->output_format = ctx->in

[FFmpeg-devel] [PATCH 4/5] lavfi: add ProcAmp(color balance) vaapi video filter.

[Jun Zhao]

From 72b242449086d7366ee524e608bb8f178c15b8cf Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 8 Jan 2018 16:12:41 +0800
Subject: [PATCH 4/5] lavfi: add ProcAmp(color balance) vaapi video filter.

add ProcAmp(color balance) vaapi video filter, use the option
like -vf "procamp_vaapi=b=10:h=120:c=2.8:s=3.7" to set
brightness/hue/contrast/saturation.

Signed-off-by: Yun Zhou 
Signed-off-by: Jun Zhao 
---
 configure  |   1 +
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_procamp_vaapi.c | 308 +
 4 files changed, 311 insertions(+)
 create mode 100644 libavfilter/vf_procamp_vaapi.c

diff --git a/configure b/configure
index 1c3e505b04..366a67d327 100755
--- a/configure
+++ b/configure
@@ -3245,6 +3245,7 @@ perspective_filter_deps="gpl"
 phase_filter_deps="gpl"
 pp7_filter_deps="gpl"
 pp_filter_deps="gpl postproc"
+procamp_vaapi_filter_deps="vaapi VAProcPipelineParameterBuffer"
 program_opencl_filter_deps="opencl"
 pullup_filter_deps="gpl"
 removelogo_filter_deps="avcodec avformat swscale"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index bbc97a0831..43d0dd36e6 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -275,6 +275,7 @@ OBJS-$(CONFIG_PP_FILTER) += vf_pp.o
 OBJS-$(CONFIG_PP7_FILTER)+= vf_pp7.o
 OBJS-$(CONFIG_PREMULTIPLY_FILTER)+= vf_premultiply.o framesync.o
 OBJS-$(CONFIG_PREWITT_FILTER)+= vf_convolution.o
+OBJS-$(CONFIG_PROCAMP_VAAPI_FILTER)  += vf_procamp_vaapi.o vaapi_vpp.o
 OBJS-$(CONFIG_PROGRAM_OPENCL_FILTER) += vf_program_opencl.o opencl.o 
framesync.o
 OBJS-$(CONFIG_PSEUDOCOLOR_FILTER)+= vf_pseudocolor.o
 OBJS-$(CONFIG_PSNR_FILTER)   += vf_psnr.o framesync.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 42516bbdf9..63550628e5 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -284,6 +284,7 @@ static void register_all(void)
 REGISTER_FILTER(PP7,pp7,vf);
 REGISTER_FILTER(PREMULTIPLY,premultiply,vf);
 REGISTER_FILTER(PREWITT,prewitt,vf);
+REGISTER_FILTER(PROCAMP_VAAPI,  procamp_vaapi,  vf);
 REGISTER_FILTER(PROGRAM_OPENCL, program_opencl, vf);
 REGISTER_FILTER(PSEUDOCOLOR,pseudocolor,vf);
 REGISTER_FILTER(PSNR,   psnr,   vf);
diff --git a/libavfilter/vf_procamp_vaapi.c b/libavfilter/vf_procamp_vaapi.c
new file mode 100644
index 00..d169d54ebe
--- /dev/null
+++ b/libavfilter/vf_procamp_vaapi.c
@@ -0,0 +1,308 @@
+/*
+ * 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 
+
+#include 
+#include 
+
+#include "libavutil/avassert.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_vaapi.h"
+#include "libavutil/mem.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "vaapi_vpp.h"
+
+typedef struct ProcampVAAPIContext {
+const AVClass *class;
+
+VAAPIVPPContext   *vpp_ctx;
+
+float bright;
+float hue;
+float saturation;
+float contrast;
+} ProcampVAAPIContext;
+
+static int procamp_vaapi_query_formats(AVFilterContext *avctx)
+{
+return vaapi_vpp_query_formats(avctx);
+}
+
+static int procamp_vaapi_pipeline_uninit(AVFilterContext *avctx)
+{
+ProcampVAAPIContext *ctx =  avctx->priv;
+VAAPIVPPContext *vpp_ctx =  ctx->vpp_ctx;
+
+return vaapi_vpp_pipeline_uninit(vpp_ctx);
+}
+
+static int procamp_vaapi_config_input(AVFilterLink *inlink)
+{
+AVFilterContext *avctx   = inlink->dst;
+ProcampVAAPIContext *ctx = avctx->priv;
+VAAPIVPPContext *vpp_ctx = ctx->vpp_ctx;
+
+return vaapi_vpp_config_input(inlink, vpp_ctx);
+}
+
+static int procamp_vaapi_build_filter_params(AVFilterContext *avctx)
+{
+ProcampVAAPIContext *ctx = avctx->priv;
+VAAPIVPPContext *vpp_ctx = ctx->vpp_ctx;
+VAStatus vas;
+VAProcFilterParameterBufferColorBalance procamp_params[4];
+VAProcFilterCapColorBalance procamp_caps[VAProcColorBalanceCount];
+int num_caps;
+
+memset(&procamp_params, 0, sizeof(procamp_params));
+memset(&procamp_caps, 0, sizeo

[FFmpeg-devel] [PATCH 2/5] lavfi: use common VPP infrastructure for vf_scale_vaapi.

[Jun Zhao]

From 24f60485868087906aa479ebf039590338320754 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 8 Jan 2018 16:02:35 +0800
Subject: [PATCH 2/5] lavfi: use common VPP infrastructure for vf_scale_vaapi.

Use the common VPP infrastructure re-work vf_scale_vaapi.

Signed-off-by: Jun Zhao 
---
 libavfilter/Makefile |   2 +-
 libavfilter/vf_scale_vaapi.c | 298 ++-
 2 files changed, 38 insertions(+), 262 deletions(-)

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index ef4729dd3f..3d8dd2c890 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -296,7 +296,7 @@ OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o 
scale.o
 OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
vf_scale_cuda.ptx.o
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
 OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
-OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o
+OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
vaapi_vpp.o
 OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
 OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
 OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
index 22e928c098..9c019a4790 100644
--- a/libavfilter/vf_scale_vaapi.c
+++ b/libavfilter/vf_scale_vaapi.c
@@ -33,87 +33,40 @@
 #include "internal.h"
 #include "scale.h"
 #include "video.h"
+#include "vaapi_vpp.h"
 
 typedef struct ScaleVAAPIContext {
 const AVClass *class;
 
-AVVAAPIDeviceContext *hwctx;
-AVBufferRef *device_ref;
-
-int valid_ids;
-VAConfigID  va_config;
-VAContextID va_context;
-
-AVBufferRef   *input_frames_ref;
-AVHWFramesContext *input_frames;
-
-AVBufferRef   *output_frames_ref;
-AVHWFramesContext *output_frames;
+VAAPIVPPContext *vpp_ctx;
 
 char *output_format_string;
-enum AVPixelFormat output_format;
 
 char *w_expr;  // width expression string
 char *h_expr;  // height expression string
-
-int output_width;  // computed width
-int output_height; // computed height
 } ScaleVAAPIContext;
 
 
 static int scale_vaapi_query_formats(AVFilterContext *avctx)
 {
-enum AVPixelFormat pix_fmts[] = {
-AV_PIX_FMT_VAAPI, AV_PIX_FMT_NONE,
-};
-int err;
-
-if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
-  &avctx->inputs[0]->out_formats)) < 0)
-return err;
-if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
-  &avctx->outputs[0]->in_formats)) < 0)
-return err;
-
-return 0;
+return vaapi_vpp_query_formats(avctx);
 }
 
-static int scale_vaapi_pipeline_uninit(ScaleVAAPIContext *ctx)
+static int scale_vaapi_pipeline_uninit(AVFilterContext *avctx)
 {
-if (ctx->va_context != VA_INVALID_ID) {
-vaDestroyContext(ctx->hwctx->display, ctx->va_context);
-ctx->va_context = VA_INVALID_ID;
-}
-
-if (ctx->va_config != VA_INVALID_ID) {
-vaDestroyConfig(ctx->hwctx->display, ctx->va_config);
-ctx->va_config = VA_INVALID_ID;
-}
-
-av_buffer_unref(&ctx->output_frames_ref);
-av_buffer_unref(&ctx->device_ref);
-ctx->hwctx = 0;
+ScaleVAAPIContext *ctx = avctx->priv;
+VAAPIVPPContext *vpp_ctx = ctx->vpp_ctx;
 
-return 0;
+return vaapi_vpp_pipeline_uninit(vpp_ctx);
 }
 
 static int scale_vaapi_config_input(AVFilterLink *inlink)
 {
 AVFilterContext *avctx = inlink->dst;
 ScaleVAAPIContext *ctx = avctx->priv;
+VAAPIVPPContext *vpp_ctx = ctx->vpp_ctx;
 
-scale_vaapi_pipeline_uninit(ctx);
-
-if (!inlink->hw_frames_ctx) {
-av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
-   "required to associate the processing device.\n");
-return AVERROR(EINVAL);
-}
-
-ctx->input_frames_ref = av_buffer_ref(inlink->hw_frames_ctx);
-ctx->input_frames = (AVHWFramesContext*)ctx->input_frames_ref->data;
-
-return 0;
+return vaapi_vpp_config_input(inlink, vpp_ctx);
 }
 
 static int scale_vaapi_config_output(AVFilterLink *outlink)
@@ -121,176 +74,46 @@ static int scale_vaapi_config_output(AVFilterLink 
*outlink)
 AVFilterLink *inlink = outlink->src->inputs[0];
 AVFilterContext *avctx = outlink->src;
 ScaleVAAPIContext *ctx = avctx->priv;
-AVVAAPIHWConfig *hwconfig = NULL;
-AVHWFramesConstraints *constraints = NULL;
-AVVAAPIFramesContext *va_frames;
-VAStatus vas;
-int err, i;
-
-scale_vaapi_pipeline_uninit(ctx);
-
-ctx->device_ref = av_buffer_ref(ctx->input_frames->device_ref);
-ctx->hwctx = ((AVHWDeviceContext*)ctx->device_ref->data)->hwctx;
-
-av_assert0(ctx->va_config == VA_INVALID_ID);
-vas = vaCreateConfig(ctx->hwctx->display, VAProfileNone,
- VAEntrypointVideoProc, 0, 0, &ctx->va_con

[FFmpeg-devel] [PATCH 5/5] lavfi: add misc(denoise/sharpness) VPP video filter.

[Jun Zhao]

From 5be7c9c55e1ad092223a13f465da3b1a2f1d01b3 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 8 Jan 2018 16:19:17 +0800
Subject: [PATCH 5/5] lavfi: add misc(denoise/sharpness) VPP video filter.

add misc(denoise/sharpness) VPP video filter.

 Signed-off-by: Yun Zhou 
 Signed-off-by: Jun Zhao 
---
 configure   |   1 +
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_misc_vaapi.c | 328 
 4 files changed, 331 insertions(+)
 create mode 100644 libavfilter/vf_misc_vaapi.c

diff --git a/configure b/configure
index 366a67d327..3b8743db4d 100755
--- a/configure
+++ b/configure
@@ -3227,6 +3227,7 @@ kerndeint_filter_deps="gpl"
 ladspa_filter_deps="ladspa libdl"
 lv2_filter_deps="lv2"
 mcdeint_filter_deps="avcodec gpl"
+misc_vaapi_filter_deps="vaapi VAProcPipelineParameterBuffer"
 movie_filter_deps="avcodec avformat"
 mpdecimate_filter_deps="gpl"
 mpdecimate_filter_select="pixelutils"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 43d0dd36e6..970597b706 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -247,6 +247,7 @@ OBJS-$(CONFIG_METADATA_FILTER)   += f_metadata.o
 OBJS-$(CONFIG_MIDEQUALIZER_FILTER)   += vf_midequalizer.o framesync.o
 OBJS-$(CONFIG_MINTERPOLATE_FILTER)   += vf_minterpolate.o 
motion_estimation.o
 OBJS-$(CONFIG_MIX_FILTER)+= vf_mix.o
+OBJS-$(CONFIG_MISC_VAAPI_FILTER) += vf_misc_vaapi.o vaapi_vpp.o
 OBJS-$(CONFIG_MPDECIMATE_FILTER) += vf_mpdecimate.o
 OBJS-$(CONFIG_NEGATE_FILTER) += vf_lut.o
 OBJS-$(CONFIG_NLMEANS_FILTER)+= vf_nlmeans.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 63550628e5..e5b713ea08 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -257,6 +257,7 @@ static void register_all(void)
 REGISTER_FILTER(MIDEQUALIZER,   midequalizer,   vf);
 REGISTER_FILTER(MINTERPOLATE,   minterpolate,   vf);
 REGISTER_FILTER(MIX,mix,vf);
+REGISTER_FILTER(MISC_VAAPI, misc_vaapi, vf);
 REGISTER_FILTER(MPDECIMATE, mpdecimate, vf);
 REGISTER_FILTER(NEGATE, negate, vf);
 REGISTER_FILTER(NLMEANS,nlmeans,vf);
diff --git a/libavfilter/vf_misc_vaapi.c b/libavfilter/vf_misc_vaapi.c
new file mode 100644
index 00..f6ef764b09
--- /dev/null
+++ b/libavfilter/vf_misc_vaapi.c
@@ -0,0 +1,328 @@
+/*
+ * 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 
+
+#include 
+#include 
+
+#include "libavutil/avassert.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_vaapi.h"
+#include "libavutil/mem.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "vaapi_vpp.h"
+
+typedef struct MiscVAAPIContext {
+const AVClass *class;
+
+VAAPIVPPContext   *vpp_ctx;
+
+VAProcFilterCap denoise_caps;
+int denoise; // enable denoise algo. level is the optional
+ // value from the interval [-1, 100], -1 means 
disabled
+
+VAProcFilterCap sharpness_caps;
+int sharpness;   // enable sharpness. level is the optional value
+ // from the interval [-1, 100], -1 means disabled
+int num_filter_bufs;
+VABufferID filter_bufs[VAProcFilterCount];
+} MiscVAAPIContext;
+
+static int misc_vaapi_query_formats(AVFilterContext *avctx)
+{
+return vaapi_vpp_query_formats(avctx);
+}
+
+static int misc_vaapi_pipeline_uninit(AVFilterContext *avctx)
+{
+MiscVAAPIContext *ctx =  avctx->priv;
+VAAPIVPPContext *vpp_ctx =  ctx->vpp_ctx;
+
+return vaapi_vpp_pipeline_uninit(vpp_ctx);
+}
+
+static int misc_vaapi_config_input(AVFilterLink *inlink)
+{
+AVFilterContext *avctx   = inlink->dst;
+MiscVAAPIContext *ctx = avctx->priv;
+VAAPIVPPContext *vpp_ctx = ctx->vpp_ctx;
+
+return vaapi_vpp_config_input(inlink, vpp_ctx);
+}
+
+static float map_to_range(
+int input, int in_min, int in_max,
+float out_min, float out_max)
+{
+return (input - in_min) * (out_max - out_min) / (in_max - in_min) + 
out_min;
+}
+
+static int misc_vaapi_buil

[FFmpeg-devel] [PATCH 3/5] lavfi: use common VPP infrastructure for vf_deinterlace_vaapi.

[Jun Zhao]

From 0274a13bc933e4d82a937afb6886b4132834ecff Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 8 Jan 2018 16:07:38 +0800
Subject: [PATCH 3/5] lavfi: use common VPP infrastructure for
 vf_deinterlace_vaapi.

Use the common VPP infrastructure re-work vf_deinterlace_vaapi.

Signed-off-by: Jun Zhao 
---
 libavfilter/Makefile   |   2 +-
 libavfilter/vf_deinterlace_vaapi.c | 318 ++---
 2 files changed, 51 insertions(+), 269 deletions(-)

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 3d8dd2c890..bbc97a0831 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -171,7 +171,7 @@ OBJS-$(CONFIG_DECONVOLVE_FILTER) += 
vf_convolve.o framesync.o
 OBJS-$(CONFIG_DEFLATE_FILTER)+= vf_neighbor.o
 OBJS-$(CONFIG_DEFLICKER_FILTER)  += vf_deflicker.o
 OBJS-$(CONFIG_DEINTERLACE_QSV_FILTER)+= vf_deinterlace_qsv.o
-OBJS-$(CONFIG_DEINTERLACE_VAAPI_FILTER)  += vf_deinterlace_vaapi.o
+OBJS-$(CONFIG_DEINTERLACE_VAAPI_FILTER)  += vf_deinterlace_vaapi.o 
vaapi_vpp.o
 OBJS-$(CONFIG_DEJUDDER_FILTER)   += vf_dejudder.o
 OBJS-$(CONFIG_DELOGO_FILTER) += vf_delogo.o
 OBJS-$(CONFIG_DESHAKE_FILTER)+= vf_deshake.o
diff --git a/libavfilter/vf_deinterlace_vaapi.c 
b/libavfilter/vf_deinterlace_vaapi.c
index 44c5ae7642..f9f5fcd096 100644
--- a/libavfilter/vf_deinterlace_vaapi.c
+++ b/libavfilter/vf_deinterlace_vaapi.c
@@ -33,31 +33,19 @@
 #include "formats.h"
 #include "internal.h"
 #include "video.h"
+#include "vaapi_vpp.h"
 
 #define MAX_REFERENCES 8
 
 typedef struct DeintVAAPIContext {
 const AVClass *class;
 
-AVVAAPIDeviceContext *hwctx;
-AVBufferRef   *device_ref;
+VAAPIVPPContext   *vpp_ctx;
 
 intmode;
 intfield_rate;
 intauto_enable;
 
-intvalid_ids;
-VAConfigID va_config;
-VAContextIDva_context;
-
-AVBufferRef   *input_frames_ref;
-AVHWFramesContext *input_frames;
-
-AVBufferRef   *output_frames_ref;
-AVHWFramesContext *output_frames;
-intoutput_height;
-intoutput_width;
-
 VAProcFilterCapDeinterlacing
deint_caps[VAProcDeinterlacingCount];
 int nb_deint_caps;
@@ -67,8 +55,6 @@ typedef struct DeintVAAPIContext {
 intqueue_count;
 AVFrame   *frame_queue[MAX_REFERENCES];
 intextra_delay_for_timestamps;
-
-VABufferID filter_buffer;
 } DeintVAAPIContext;
 
 static const char *deint_vaapi_mode_name(int mode)
@@ -87,80 +73,43 @@ static const char *deint_vaapi_mode_name(int mode)
 
 static int deint_vaapi_query_formats(AVFilterContext *avctx)
 {
-enum AVPixelFormat pix_fmts[] = {
-AV_PIX_FMT_VAAPI, AV_PIX_FMT_NONE,
-};
-int err;
-
-if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
-  &avctx->inputs[0]->out_formats)) < 0)
-return err;
-if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
-  &avctx->outputs[0]->in_formats)) < 0)
-return err;
-
-return 0;
+return vaapi_vpp_query_formats(avctx);
 }
 
 static int deint_vaapi_pipeline_uninit(AVFilterContext *avctx)
 {
 DeintVAAPIContext *ctx = avctx->priv;
+VAAPIVPPContext *vpp_ctx = ctx->vpp_ctx;
 int i;
 
 for (i = 0; i < ctx->queue_count; i++)
 av_frame_free(&ctx->frame_queue[i]);
 ctx->queue_count = 0;
 
-if (ctx->filter_buffer != VA_INVALID_ID) {
-vaDestroyBuffer(ctx->hwctx->display, ctx->filter_buffer);
-ctx->filter_buffer = VA_INVALID_ID;
-}
-
-if (ctx->va_context != VA_INVALID_ID) {
-vaDestroyContext(ctx->hwctx->display, ctx->va_context);
-ctx->va_context = VA_INVALID_ID;
-}
-
-if (ctx->va_config != VA_INVALID_ID) {
-vaDestroyConfig(ctx->hwctx->display, ctx->va_config);
-ctx->va_config = VA_INVALID_ID;
-}
-
-av_buffer_unref(&ctx->device_ref);
-ctx->hwctx = NULL;
-
-return 0;
+return vaapi_vpp_pipeline_uninit(vpp_ctx);
 }
 
 static int deint_vaapi_config_input(AVFilterLink *inlink)
 {
 AVFilterContext   *avctx = inlink->dst;
-DeintVAAPIContext *ctx = avctx->priv;
-
-deint_vaapi_pipeline_uninit(avctx);
-
-if (!inlink->hw_frames_ctx) {
-av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
-   "required to associate the processing device.\n");
-return AVERROR(EINVAL);
-}
+DeintVAAPIContext *ctx   = avctx->priv;
 
-ctx->input_frames_ref = av_buffer_ref(inlink->hw_frames_ctx);
-ctx->input_frames = (AVHWFramesContext*)ctx->input_frames_ref->data;
+VAAPIVPPContext *vpp_ctx = ctx->vpp_ctx;
 
-return 0;
+return vaapi_vpp_config_input(inlink, vpp_ctx);
 }
 
 static int deint_vaapi_build_filter_params(AVFilterContext *avctx)
 {
-  

[FFmpeg-devel] [PATCH 3/5] lavfi: use common VPP infrastructure for vf_deinterlace_vaapi.

[Jun Zhao]

From 0274a13bc933e4d82a937afb6886b4132834ecff Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 8 Jan 2018 16:07:38 +0800
Subject: [PATCH 3/5] lavfi: use common VPP infrastructure for
 vf_deinterlace_vaapi.

Use the common VPP infrastructure re-work vf_deinterlace_vaapi.

Signed-off-by: Jun Zhao 
---
 libavfilter/Makefile   |   2 +-
 libavfilter/vf_deinterlace_vaapi.c | 318 ++---
 2 files changed, 51 insertions(+), 269 deletions(-)

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 3d8dd2c890..bbc97a0831 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -171,7 +171,7 @@ OBJS-$(CONFIG_DECONVOLVE_FILTER) += 
vf_convolve.o framesync.o
 OBJS-$(CONFIG_DEFLATE_FILTER)+= vf_neighbor.o
 OBJS-$(CONFIG_DEFLICKER_FILTER)  += vf_deflicker.o
 OBJS-$(CONFIG_DEINTERLACE_QSV_FILTER)+= vf_deinterlace_qsv.o
-OBJS-$(CONFIG_DEINTERLACE_VAAPI_FILTER)  += vf_deinterlace_vaapi.o
+OBJS-$(CONFIG_DEINTERLACE_VAAPI_FILTER)  += vf_deinterlace_vaapi.o 
vaapi_vpp.o
 OBJS-$(CONFIG_DEJUDDER_FILTER)   += vf_dejudder.o
 OBJS-$(CONFIG_DELOGO_FILTER) += vf_delogo.o
 OBJS-$(CONFIG_DESHAKE_FILTER)+= vf_deshake.o
diff --git a/libavfilter/vf_deinterlace_vaapi.c 
b/libavfilter/vf_deinterlace_vaapi.c
index 44c5ae7642..f9f5fcd096 100644
--- a/libavfilter/vf_deinterlace_vaapi.c
+++ b/libavfilter/vf_deinterlace_vaapi.c
@@ -33,31 +33,19 @@
 #include "formats.h"
 #include "internal.h"
 #include "video.h"
+#include "vaapi_vpp.h"
 
 #define MAX_REFERENCES 8
 
 typedef struct DeintVAAPIContext {
 const AVClass *class;
 
-AVVAAPIDeviceContext *hwctx;
-AVBufferRef   *device_ref;
+VAAPIVPPContext   *vpp_ctx;
 
 intmode;
 intfield_rate;
 intauto_enable;
 
-intvalid_ids;
-VAConfigID va_config;
-VAContextIDva_context;
-
-AVBufferRef   *input_frames_ref;
-AVHWFramesContext *input_frames;
-
-AVBufferRef   *output_frames_ref;
-AVHWFramesContext *output_frames;
-intoutput_height;
-intoutput_width;
-
 VAProcFilterCapDeinterlacing
deint_caps[VAProcDeinterlacingCount];
 int nb_deint_caps;
@@ -67,8 +55,6 @@ typedef struct DeintVAAPIContext {
 intqueue_count;
 AVFrame   *frame_queue[MAX_REFERENCES];
 intextra_delay_for_timestamps;
-
-VABufferID filter_buffer;
 } DeintVAAPIContext;
 
 static const char *deint_vaapi_mode_name(int mode)
@@ -87,80 +73,43 @@ static const char *deint_vaapi_mode_name(int mode)
 
 static int deint_vaapi_query_formats(AVFilterContext *avctx)
 {
-enum AVPixelFormat pix_fmts[] = {
-AV_PIX_FMT_VAAPI, AV_PIX_FMT_NONE,
-};
-int err;
-
-if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
-  &avctx->inputs[0]->out_formats)) < 0)
-return err;
-if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
-  &avctx->outputs[0]->in_formats)) < 0)
-return err;
-
-return 0;
+return vaapi_vpp_query_formats(avctx);
 }
 
 static int deint_vaapi_pipeline_uninit(AVFilterContext *avctx)
 {
 DeintVAAPIContext *ctx = avctx->priv;
+VAAPIVPPContext *vpp_ctx = ctx->vpp_ctx;
 int i;
 
 for (i = 0; i < ctx->queue_count; i++)
 av_frame_free(&ctx->frame_queue[i]);
 ctx->queue_count = 0;
 
-if (ctx->filter_buffer != VA_INVALID_ID) {
-vaDestroyBuffer(ctx->hwctx->display, ctx->filter_buffer);
-ctx->filter_buffer = VA_INVALID_ID;
-}
-
-if (ctx->va_context != VA_INVALID_ID) {
-vaDestroyContext(ctx->hwctx->display, ctx->va_context);
-ctx->va_context = VA_INVALID_ID;
-}
-
-if (ctx->va_config != VA_INVALID_ID) {
-vaDestroyConfig(ctx->hwctx->display, ctx->va_config);
-ctx->va_config = VA_INVALID_ID;
-}
-
-av_buffer_unref(&ctx->device_ref);
-ctx->hwctx = NULL;
-
-return 0;
+return vaapi_vpp_pipeline_uninit(vpp_ctx);
 }
 
 static int deint_vaapi_config_input(AVFilterLink *inlink)
 {
 AVFilterContext   *avctx = inlink->dst;
-DeintVAAPIContext *ctx = avctx->priv;
-
-deint_vaapi_pipeline_uninit(avctx);
-
-if (!inlink->hw_frames_ctx) {
-av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
-   "required to associate the processing device.\n");
-return AVERROR(EINVAL);
-}
+DeintVAAPIContext *ctx   = avctx->priv;
 
-ctx->input_frames_ref = av_buffer_ref(inlink->hw_frames_ctx);
-ctx->input_frames = (AVHWFramesContext*)ctx->input_frames_ref->data;
+VAAPIVPPContext *vpp_ctx = ctx->vpp_ctx;
 
-return 0;
+return vaapi_vpp_config_input(inlink, vpp_ctx);
 }
 
 static int deint_vaapi_build_filter_params(AVFilterContext *avctx)
 {
-  

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Hendrik Leppkes]

On Mon, Jan 8, 2018 at 1:38 AM, Rostislav Pehlivanov
 wrote:
>
> That's okay - for encoding switch the profile depending on both the
> avctx->profile setting and the samplerate and list all supported
> samplerates for all profiles in the AVCodec structure. We do something
> similar in the AAC encoder where we pick different settings depending on
> the profile and change the profile depending on the settings listed.
> If there's an overlap, pick a sane default unless the user forces a profile
> using profile:a. If forced and the samplerate isn't supported - error out
> and let the user know.
> For decoding set the profile via the demuxer. There doesn't have to be just
> one demuxer for a codec. If there are major changes in how you parse
> profiles go ahead and make a new one which sets the codec ID and the
> profile.
>

I don't think there is any precedent for "profile" being mandatory for
a decoder to work, so that might be iffy. Decoders usually set
profile, don't require it.
ie. from the docs:
* - decoding: Set by libavcodec.

There is plenty precedent for using "codec_tag" however, so that may
be a better choice - and can hold the tag from the "container" as-is
as well.

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

Re: [FFmpeg-devel] [PATCH] avcodec: increase AV_INPUT_BUFFER_PADDING_SIZE to 64

[Reimar Döffinger]

On Mon, Jan 08, 2018 at 04:14:22AM +0100, Michael Niedermayer wrote:
> On Sun, Jan 07, 2018 at 11:42:25PM -0300, James Almer wrote:
> > On 1/7/2018 11:06 PM, Michael Niedermayer wrote:
> > > On Sun, Jan 07, 2018 at 01:22:38AM -0300, James Almer wrote:
> > >> AVX-512 support has been introduced, and even if no functions currently
> > >> use zmm registers (able to load as much as 64 bytes of consecutive data
> > >> per instruction), they will be added eventually.
> > >>
> > >> Signed-off-by: James Almer 
> > >> ---
> > >> Same rationale as when it was increased to 32 back in commit
> > >> 67d29da4bd23057a1f646568442a77b844cb2d1b.
> > >>
> > >>  libavcodec/avcodec.h  | 2 +-
> > >>  libavcodec/x86/hevc_sao.asm   | 2 +-
> > >>  libavcodec/x86/hevc_sao_10bit.asm | 2 +-
> > >>  3 files changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > causes assertion failure:
> > > ./ffmpeg -i bgc.sub.dub.ogm x.webm
> > > 
> > > Assertion 64 <= 52 failed at libavformat/oggparseogm.c:109
> > > Aborted (core dumped)
> > 
> > How do you say this should be fixed? Why should
> > AV_INPUT_BUFFER_PADDING_SIZE be lower or equal to 52?
> > 
> > I have no idea about OGM, so i could use some help.
> 
> cc-ing reimar, maybe he remembers, the assert seems to come from:
> 
> commit 7c8d477299c9b5e89fc30ed22f9e42b50761342c
> Author: Reimar Döffinger 
> Date:   Mon Feb 6 22:04:46 2012 +0100
> 
> Make AAC in Ogg (ogm) work.

The assert probably never made sense (probably left-over from an early
try that would do the allocation earlier on, in that case we wouldn't have
needed to reallocate the data to add the padding before storing in
extradata), but it should have been removed at the latest when the code
was switched to use ff_alloc_extradata.
Either way, it should no longer be relevant.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: increase AV_INPUT_BUFFER_PADDING_SIZE to 64

[Carl Eugen Hoyos]

2018-01-08 11:44 GMT+01:00 Reimar Döffinger :
> On Mon, Jan 08, 2018 at 04:14:22AM +0100, Michael Niedermayer wrote:
>> On Sun, Jan 07, 2018 at 11:42:25PM -0300, James Almer wrote:
>> > On 1/7/2018 11:06 PM, Michael Niedermayer wrote:
>> > > On Sun, Jan 07, 2018 at 01:22:38AM -0300, James Almer wrote:
>> > >> AVX-512 support has been introduced, and even if no functions currently
>> > >> use zmm registers (able to load as much as 64 bytes of consecutive data
>> > >> per instruction), they will be added eventually.
>> > >>
>> > >> Signed-off-by: James Almer 
>> > >> ---
>> > >> Same rationale as when it was increased to 32 back in commit
>> > >> 67d29da4bd23057a1f646568442a77b844cb2d1b.
>> > >>
>> > >>  libavcodec/avcodec.h  | 2 +-
>> > >>  libavcodec/x86/hevc_sao.asm   | 2 +-
>> > >>  libavcodec/x86/hevc_sao_10bit.asm | 2 +-
>> > >>  3 files changed, 3 insertions(+), 3 deletions(-)
>> > >
>> > > causes assertion failure:
>> > > ./ffmpeg -i bgc.sub.dub.ogm x.webm
>> > >
>> > > Assertion 64 <= 52 failed at libavformat/oggparseogm.c:109
>> > > Aborted (core dumped)
>> >
>> > How do you say this should be fixed? Why should
>> > AV_INPUT_BUFFER_PADDING_SIZE be lower or equal to 52?
>> >
>> > I have no idea about OGM, so i could use some help.
>>
>> cc-ing reimar, maybe he remembers, the assert seems to come from:
>>
>> commit 7c8d477299c9b5e89fc30ed22f9e42b50761342c
>> Author: Reimar Döffinger 
>> Date:   Mon Feb 6 22:04:46 2012 +0100
>>
>> Make AAC in Ogg (ogm) work.
>
> The assert probably never made sense (probably left-over from an early
> try that would do the allocation earlier on, in that case we wouldn't have
> needed to reallocate the data to add the padding before storing in
> extradata), but it should have been removed at the latest when the code
> was switched to use ff_alloc_extradata.
> Either way, it should no longer be relevant.

I removed the assert.

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

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Carl Eugen Hoyos]

2018-01-08 11:32 GMT+01:00 Hendrik Leppkes :
> On Mon, Jan 8, 2018 at 1:38 AM, Rostislav Pehlivanov
>  wrote:
>>
>> That's okay - for encoding switch the profile depending on both the
>> avctx->profile setting and the samplerate and list all supported
>> samplerates for all profiles in the AVCodec structure. We do something
>> similar in the AAC encoder where we pick different settings depending on
>> the profile and change the profile depending on the settings listed.
>> If there's an overlap, pick a sane default unless the user forces a profile
>> using profile:a. If forced and the samplerate isn't supported - error out
>> and let the user know.
>> For decoding set the profile via the demuxer. There doesn't have to be just
>> one demuxer for a codec. If there are major changes in how you parse
>> profiles go ahead and make a new one which sets the codec ID and the
>> profile.
>>
>
> I don't think there is any precedent for "profile" being mandatory for
> a decoder to work, so that might be iffy. Decoders usually set
> profile, don't require it.
> ie. from the docs:
> * - decoding: Set by libavcodec.
>
> There is plenty precedent for using "codec_tag" however, so that may
> be a better choice - and can hold the tag from the "container" as-is
> as well.

While I don't understand why even having more than one codec_id for
the same codec (which afaiu isn't the case here) would be an issue, I
don't think we should invent codec_tags unless necessary.

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_overlay: remove duplicate parse line

[Nicolas George]

Steven Liu (2018-01-08):
> duplicate av_expr_eval x_pexpr, remove the second one.

No. It is necessary if x is expressed from y.

Regards,

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

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Hendrik Leppkes]

On Mon, Jan 8, 2018 at 1:27 PM, Carl Eugen Hoyos  wrote:
> 2018-01-08 11:32 GMT+01:00 Hendrik Leppkes :
>> On Mon, Jan 8, 2018 at 1:38 AM, Rostislav Pehlivanov
>>  wrote:
>>>
>>> That's okay - for encoding switch the profile depending on both the
>>> avctx->profile setting and the samplerate and list all supported
>>> samplerates for all profiles in the AVCodec structure. We do something
>>> similar in the AAC encoder where we pick different settings depending on
>>> the profile and change the profile depending on the settings listed.
>>> If there's an overlap, pick a sane default unless the user forces a profile
>>> using profile:a. If forced and the samplerate isn't supported - error out
>>> and let the user know.
>>> For decoding set the profile via the demuxer. There doesn't have to be just
>>> one demuxer for a codec. If there are major changes in how you parse
>>> profiles go ahead and make a new one which sets the codec ID and the
>>> profile.
>>>
>>
>> I don't think there is any precedent for "profile" being mandatory for
>> a decoder to work, so that might be iffy. Decoders usually set
>> profile, don't require it.
>> ie. from the docs:
>> * - decoding: Set by libavcodec.
>>
>> There is plenty precedent for using "codec_tag" however, so that may
>> be a better choice - and can hold the tag from the "container" as-is
>> as well.
>
> While I don't understand why even having more than one codec_id for
> the same codec (which afaiu isn't the case here) would be an issue, I
> don't think we should invent codec_tags unless necessary.
>

We're not inventing them if they are a copy from the container
bitstream tag field.

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_overlay: remove duplicate parse line

[Paul B Mahol]

On 1/8/18, Nicolas George  wrote:
> Steven Liu (2018-01-08):
>> duplicate av_expr_eval x_pexpr, remove the second one.
>
> No. It is necessary if x is expressed from y.
>
> Regards,

Comment should be added so such patches do not pop again.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Carl Eugen Hoyos]

2018-01-08 13:37 GMT+01:00 Hendrik Leppkes :
> On Mon, Jan 8, 2018 at 1:27 PM, Carl Eugen Hoyos  wrote:
>> 2018-01-08 11:32 GMT+01:00 Hendrik Leppkes :
>>> On Mon, Jan 8, 2018 at 1:38 AM, Rostislav Pehlivanov
>>>  wrote:

 That's okay - for encoding switch the profile depending on both the
 avctx->profile setting and the samplerate and list all supported
 samplerates for all profiles in the AVCodec structure. We do something
 similar in the AAC encoder where we pick different settings depending on
 the profile and change the profile depending on the settings listed.
 If there's an overlap, pick a sane default unless the user forces a profile
 using profile:a. If forced and the samplerate isn't supported - error out
 and let the user know.
 For decoding set the profile via the demuxer. There doesn't have to be just
 one demuxer for a codec. If there are major changes in how you parse
 profiles go ahead and make a new one which sets the codec ID and the
 profile.

>>>
>>> I don't think there is any precedent for "profile" being mandatory for
>>> a decoder to work, so that might be iffy. Decoders usually set
>>> profile, don't require it.
>>> ie. from the docs:
>>> * - decoding: Set by libavcodec.
>>>
>>> There is plenty precedent for using "codec_tag" however, so that may
>>> be a better choice - and can hold the tag from the "container" as-is
>>> as well.
>>
>> While I don't understand why even having more than one codec_id for
>> the same codec (which afaiu isn't the case here) would be an issue, I
>> don't think we should invent codec_tags unless necessary.
>>
>
> We're not inventing them if they are a copy from the container
> bitstream tag field.

I completely agree!

Is there a container bitstream tag field in this case?

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

[FFmpeg-devel] [PATCH] avformat/aiffdec: AIFF fix in case of ANNO

[endushka]

From: Eduard Sinelnikov 

Apple's AIFF protocol clearly states that each chucnk which is odd sized a 
padding should be added.
In the old version of aiffdec adding of padding was done in `get_meta`. And in 
case of unknown chunk name it was done in defalut case.
The new version has deleted the padding in default case and added padding 
adding after the switch.
But the new version didn't removed the padding adding in the `get_meta` 
function so in some cases padding was added twice which leaded to a bug.
---
 libavformat/aiffdec.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
index 99e05c7..20decc5 100644
--- a/libavformat/aiffdec.c
+++ b/libavformat/aiffdec.c
@@ -81,11 +81,10 @@ static void get_meta(AVFormatContext *s, const char *key, 
int size)
 av_free(str);
 return;
 }
-size += (size&1)-res;
+size -= res;
 str[res] = 0;
 av_dict_set(&s->metadata, key, str, AV_DICT_DONT_STRDUP_VAL);
-}else
-size+= size&1;
+}
 
 avio_skip(s->pb, size);
 }
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH 1/2] avresample: remove deprecated attribute from the AVAudioResampleContext struct

[James Almer]

On 1/4/2018 3:41 PM, James Almer wrote:
> Having all the public functions marked as deprecated is enough.
> 
> This gets rid of a warning spam when compiling any file including
> libavresample/avresample.h even when avresample is not enabled, like
> it's the case with fftools/cmdutils.c
> 
> Signed-off-by: James Almer 
> ---
>  libavresample/avresample.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavresample/avresample.h b/libavresample/avresample.h
> index 440e1a16e7..5ac9adb44b 100644
> --- a/libavresample/avresample.h
> +++ b/libavresample/avresample.h
> @@ -103,7 +103,7 @@
>  
>  #define AVRESAMPLE_MAX_CHANNELS 32
>  
> -typedef attribute_deprecated struct AVAudioResampleContext 
> AVAudioResampleContext;
> +typedef struct AVAudioResampleContext AVAudioResampleContext;
>  
>  /**
>   * @deprecated use libswresample

Will push this tonight.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/7] avformat: add url field to AVFormatContext

[Marton Balint]

On Mon, 8 Jan 2018, Bang He wrote:


On Sun, Jan 7, 2018 at 4:50 AM, Marton Balint  wrote:


This will replace the 1024 character limited filename field. Compatiblity
for
output contexts are provided by copying filename field to URL if URL is
unset
and by providing an internal function for muxers to set both url and
filename
at once.

Signed-off-by: Marton Balint 
---
 doc/APIchanges |  3 +++
 libavformat/avformat.h | 15 +++
 libavformat/internal.h |  7 +++
 libavformat/mux.c  | 11 ++-
 libavformat/utils.c| 14 ++
 libavformat/version.h  |  2 +-
 6 files changed, 50 insertions(+), 2 deletions(-)



[...]


@@ -5624,3 +5630,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
 return st->internal->avctx->time_base;
 #endif
 }
+
+void ff_format_set_url(AVFormatContext *s, char *url)
+{
+av_assert0(url);
+av_freep(&s->url);
+s->url = url;


mybe you should: s->url=av_strdup(url)



This is intentional, as the URL can be typically a result of av_sprintf or 
av_bprintf buffer, so re-allocating it would be a waste. Also this way the 
function can remain void because it always succeeds.


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

Re: [FFmpeg-devel] [PATCH 3/4] avformat/libopenmpt: Update file extensions list for libopenmpt 0.3

[Jörn Heusipp]

On 01/08/2018 12:48 AM, Carl Eugen Hoyos wrote:

2018-01-07 15:40 GMT+01:00 Jörn Heusipp :

On 01/06/2018 04:06 PM, Carl Eugen Hoyos wrote:

2018-01-06 11:07 GMT+01:00 Jörn Heusipp
:




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



I believe this change can be made without the version check.


Why would that be better?


Only because of the simplification:
Other parts of FFmpeg will not support the files anyway, and I am sure
we can find a real-world files that have one of above extensions but are
not supported by libopenmpt (because they are completely different
files).


Absolutely. Without doing any further research, I know at least of .mod 
(also used by JVC camcorders and others for some MPEG variant (I do not 
know the details)) and .umx (which can also contain wav or mp3 or 
similar instead of module music files). Also, .sfx is probably used by a 
ton of games as a generic extension for any sound effects.
Given the sheer amount of file extensions, there are likely even more 
conflicts that I am not aware of.



Can't libopenmpt be configured to support only some of above file
types?


No, that is not possible.


But feel free to ignore my suggestion.


Listing too many file extensions increases the chance of false-positives 
which I think warrants listing as few as possible depending on 
libopenmpt version.

In any case, I do not have a particularly strong opinion on that matter.
So maybe someone else wants to comment on that?


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

Re: [FFmpeg-devel] [PATCH 4/4] avformat/libopenmpt: Probe file format from file data if possible

[Jörn Heusipp]

On 01/08/2018 12:57 AM, Carl Eugen Hoyos wrote:

2018-01-07 15:40 GMT+01:00 Jörn Heusipp :

On 01/06/2018 04:10 PM, Carl Eugen Hoyos wrote:

2018-01-06 11:07 GMT+01:00 Jörn Heusipp
:




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.


You could also test tools/probetest


I was not aware of that tool. Thanks for the suggestion.

It currently lists a failure related to libopenmpt:
Failure of libopenmpt probing code with score=76 type=0 p=FDC size=1024


I did not look at this closely but I suspect libopenmpt should return a
smaller score in this case.


We (libopenmpt developers) are currently considering making the 
heuristic for M15 files even stricter. The changes will land in 
libopenmpt 0.3.5.
libopenmpt 0.3.5 versus 0.3.4 or earlier can be distinguished at runtime 
via openmpt_get_library_version(). I would be fine with only doing 
probing via libopenmpt in FFmpeg starting with libopenmt 0.3.5 and 
relying on file extensions for earlier versions.


However, the data that tools/probetest.c generates here fundamentally 
does have a somewhat high probability of looking like a completely legit 
M15 file. False positives are not really avoidable completely no matter 
what libopenmpt does here. The failing data is synthetic, and I am not 
seeing any M15 false positives at all on real-world file collections 
(media and non-media files (tested on 1.2 million data and system files)).



A solution could be to never return a high value for the FFmpeg
probe function.


Maybe, but given what tools/probetest generates here, I somewhat doubt 
these examples have any real-world implication at all.
Anyway, in case a lower score is deemed to be useful, do you have any 
suggestions which score I should pick? AVPROBE_SCORE_EXTENSION or less 
would probably not be very useful, so what comes to mind for me is 
AVPROBE_SCORE_EXTENSION+1 (51).




Looking at tools/probetest.c, that would be a file with very few bits set.
libopenmpt detects the random data in question as M15 .MOD files (original
Amiga 15 samples .mod files), and there is sadly not much that can be done
about that. There are perfectly valid real-world M15 .MOD files with only 73
bits set in the first 600 bytes (untouchables-station.mod,
).
The following up to 64*4*4*63 bytes could even be completely 0 (empty
pattern data) for valid files (even without the file being totally silent).
The generated random data that tools/probetest complains about here contains
46 bits set to 1 in the first 600 bytes. What follows are various other
examples with up to 96 bits set to 1. Completely loading a file like that
would very likely reject it (in particular, libopenmpt can deduce the
expected file size from the sample headers and, with some slack to account
for corrupted real-world examples, reject files with non-matching size),
however, that is not possible when only probing the file header.
The libopenmpt API allows for the file header probing functions to return
false-positives, however false-negatives are not allowed.

Performance numbers shown by tools/probetest are what I had expected
(measured on an AMD A4-5000, during normal Xorg session (i.e. not 100%
idle)):



[...]


109589637233 cycles,   libopenmpt


This sadly may not be acceptable, others may want to comment.


   2672917981   libopenmpt (per module format)

At first glance, libopenmpt looks huge here in comparison. However one
should consider that libopenmpt internally has to probe for (currently) 41
different module file formats, going through 41 separate probing functions
internally.

Dividing 109589637233 by 41 gives 2672917981, which is in the ballpark of
all other probing functions in ffmpeg.


What are your expectations for probing speed of 41 completely distinct 
file formats?
Even only h261,h263,h264,hevc,aac,ac3 (raw streams) combined take more 
time than libopenmpt takes for its 41 formats together.
All other FFmpeg probing functions combined (234 formats) take 
1201426924609 cycles. libopenmpt adds 109589637233 cycles for 41 
different file formats to that, which is about 10%. I do not think 
probing performance is in general that performance critical that would 
make 10% a problem, especially considering that for real-world use cases 
when probing a whole media library, the data also has to be read from 
storage in the first place.



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

Re: [FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data

[Jacob Trimble]

> I'd assume we'd wait with applying this until the mp4 patch that uses
> it is reviewed. I'm fine with this patch and I think it can be pushed
> as it is, although I just noticed an APIchanges entry and minor version
> bump is actually missing. You could add them when sending the final
> patch set.

Added APIchanges entry and version bump.

> The format of teh side data should be choosen so that demuxers and encoders
> producing it can interoperate with muxers and decoders consuming it.

> Please correct me if iam wrong but if some containers can store more than
> others, then the "other" containers would not use that extra information nor
> set it but it could still be using a compatible representation for 
> interoperability

Well I guess I can do the same thing for this as for the
frame-specific encryption info.  There will be a user-friendly struct
for accessing it and a binary format that will be stored in the side
data.  This will allow different (de)muxers to use the data in a
generic way.

> These should be checked against size, making sure the data is consistent

Done.  Also added addition overflow checking.

On Fri, Jan 5, 2018 at 2:42 PM, James Almer  wrote:
> This being in libavutil, the two functions using AVPacket should be
> changed to take and return a byte array instead, that the caller
> manually either got from side data, or will afterwards adds as side data.

Done.
From 332f20f951fc4db77a83f9dc60f75e84717b4fd0 Mon Sep 17 00:00:00 2001
From: Jacob Trimble 
Date: Tue, 5 Dec 2017 14:52:22 -0800
Subject: [PATCH] avcodec/avcodec.h: Add encryption info side data.

This new side-data will contain info on how a packet is encrypted.
This allows the app to handle packet decryption.

Signed-off-by: Jacob Trimble 
---
 doc/APIchanges  |   4 +
 libavcodec/avcodec.h|  13 ++
 libavutil/Makefile  |   2 +
 libavutil/encryption_info.c | 295 
 libavutil/encryption_info.h | 200 ++
 libavutil/version.h |   2 +-
 6 files changed, 515 insertions(+), 1 deletion(-)
 create mode 100644 libavutil/encryption_info.c
 create mode 100644 libavutil/encryption_info.h

diff --git a/doc/APIchanges b/doc/APIchanges
index d66c842521..b771031740 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-xx-xx - xxx - lavu 56.8.100 - encryption_info.h
+  Add AVEncryptionInitInfo and AVEncryptionInfo structures to hold new side-data
+  for encryption info.
+
 2018-01-xx - xxx - lavfi 7.11.101 - avfilter.h
   Deprecate avfilter_link_get_channels(). Use av_buffersink_get_channels().
 
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c13deb599f..cc74a9a740 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1341,6 +1341,19 @@ enum AVPacketSideDataType {
  */
 AV_PKT_DATA_A53_CC,
 
+/**
+ * This side data is encryption initialization data.
+ * The format is not part of ABI, use av_encryption_init_info_* methods to
+ * access.
+ */
+AV_PKT_DATA_ENCRYPTION_INIT_DATA,
+
+/**
+ * This side data contains encryption info for how to decrypt the packet.
+ * The format is not part of ABI, use av_encryption_info_* methods to access.
+ */
+AV_PKT_DATA_ENCRYPTION_INFO,
+
 /**
  * The number of side data types.
  * This is not part of the public API/ABI in the sense that it may
diff --git a/libavutil/Makefile b/libavutil/Makefile
index d7474f59e4..760fce3b30 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -24,6 +24,7 @@ HEADERS = adler32.h \
   dict.h\
   display.h \
   downmix_info.h\
+  encryption_info.h \
   error.h   \
   eval.h\
   fifo.h\
@@ -107,6 +108,7 @@ OBJS = adler32.o\
dict.o   \
display.o\
downmix_info.o   \
+   encryption_info.o\
error.o  \
eval.o   \
fifo.o   \
diff --git a/libavutil/encryption_info.c b/libavutil/encryption_info.c
new file mode 100644
index 00..f79a9cad5d
--- /dev/null
+++

Re: [FFmpeg-devel] [PATCH] avcodec/opus_parser: Check payload_len in parse_opus_ts_header()

[Michael Niedermayer]

On Sun, Jan 07, 2018 at 03:15:19AM +0100, Michael Niedermayer wrote:
> Fixes: clusterfuzz-testcase-minimized-6134545979277312
> Fixes: crbug 797469
> 
> Reported-by: Matt Wolenetz 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/opus_parser.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)

applied

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/diracdec: Fix integer overflow with quant

[Michael Niedermayer]

On Sun, Jan 07, 2018 at 11:13:36PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 2 + 2147483646 cannot be represented in type 
> 'int'
> Fixes: 4792/clusterfuzz-testcase-minimized-6322450775146496
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/diracdec.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

will apply patchset

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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] avcodec/h264addpx_template: Fixes integer overflows

[Michael Niedermayer]

On Sun, Jan 07, 2018 at 04:12:58AM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 512 + 2147483491 cannot be represented in 
> type 'int'
> Fixes: 4780/clusterfuzz-testcase-minimized-4709066174627840
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264addpx_template.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)

will apply

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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/6] dashdec: Support for multiple video/audio streams

[Moritz Barsnick]

On Sun, Jan 07, 2018 at 18:46:06 +, Stefan _ wrote:

I can't judge the logic, but:

> +int64_t currentTime = 0;
> +currentTime = 
> get_segment_start_time_based_on_timeline(cur_video, cur_video->cur_seq_no) / 
> cur_video->fragment_timescale;

The assignment "= 0" isn't being used.

> +int64_t currentTime = 0;
> +currentTime = 
> get_segment_start_time_based_on_timeline(cur_audio, cur_audio->cur_seq_no) / 
> cur_audio->fragment_timescale;

Ditto (further down).

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

Re: [FFmpeg-devel] [PATCH 2/2] avdevice/decklink: addition of absolute wallclock option for pts source

[Moritz Barsnick]

On Mon, Jan 08, 2018 at 10:56:56 +0530, vdi...@akamai.com wrote:

> -{ "audio_pts", "audio pts source",   OFFSET(audio_pts_source),
> AV_OPT_TYPE_INT,   { .i64 = PTS_SRC_AUDIO}, 1, 4, DEC, "pts_source"},
> -{ "video_pts", "video pts source",   OFFSET(video_pts_source),
> AV_OPT_TYPE_INT,   { .i64 = PTS_SRC_VIDEO}, 1, 4, DEC, "pts_source"},
> +{ "audio_pts", "audio pts source",   OFFSET(audio_pts_source),
> AV_OPT_TYPE_INT,   { .i64 = PTS_SRC_AUDIO}, 1, 5, DEC, "pts_source"},
> +{ "video_pts", "video pts source",   OFFSET(video_pts_source),
> AV_OPT_TYPE_INT,   { .i64 = PTS_SRC_VIDEO}, 1, 5, DEC, "pts_source"},

This cries for a max macro:

 PTS_SRC_VIDEO = 2,
 PTS_SRC_REFERENCE = 3,
 PTS_SRC_WALLCLOCK = 4,
+PTS_SRC_ABS_WALLCLOCK = 5,
+PTS_SRC_NB
 } DecklinkPtsSource;

and then

+{ "audio_pts", "audio pts source",   OFFSET(audio_pts_source),
AV_OPT_TYPE_INT,   { .i64 = PTS_SRC_AUDIO}, 1, PTS_SRC_NB-1, DEC, 
"pts_source"},
+{ "video_pts", "video pts source",   OFFSET(video_pts_source),
AV_OPT_TYPE_INT,   { .i64 = PTS_SRC_VIDEO}, 1, PTS_SRC_NB-1, DEC, 
"pts_source"},

>  break;
>  case PTS_SRC_WALLCLOCK:
> +case PTS_SRC_ABS_WALLCLOCK:

Coverty and similar tools like fall-throughs to be marked as such to
avoid false warnings.

> +else if(ctx->audio_pts_source == PTS_SRC_ABS_WALLCLOCK || 
> ctx->video_pts_source == PTS_SRC_ABS_WALLCLOCK)

"else if ("

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

[FFmpeg-devel] [PATCH] avutil/aes_ctr: Add method to set 16-byte IV.

[Jacob Trimble]

Signed-off-by: Jacob Trimble 
---
 doc/APIchanges| 3 +++
 libavutil/aes_ctr.c   | 6 ++
 libavutil/aes_ctr.h   | 7 ++-
 libavutil/tests/aes_ctr.c | 2 +-
 libavutil/version.h   | 2 +-
 5 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index b771031740..4e07a806eb 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-xx-xx - xxx - lavu 56.9.100 - aes_ctr.h
+  Add method to set the 16-byte IV.
+
 2018-xx-xx - xxx - lavu 56.8.100 - encryption_info.h
   Add AVEncryptionInitInfo and AVEncryptionInfo structures to hold new 
side-data
   for encryption info.
diff --git a/libavutil/aes_ctr.c b/libavutil/aes_ctr.c
index e9c568fe0d..0c2e86785f 100644
--- a/libavutil/aes_ctr.c
+++ b/libavutil/aes_ctr.c
@@ -45,6 +45,12 @@ void av_aes_ctr_set_iv(struct AVAESCTR *a, const uint8_t* iv)
 a->block_offset = 0;
 }
 
+void av_aes_ctr_set_full_iv(struct AVAESCTR *a, const uint8_t* iv)
+{
+memcpy(a->counter, iv, sizeof(a->counter));
+a->block_offset = 0;
+}
+
 const uint8_t* av_aes_ctr_get_iv(struct AVAESCTR *a)
 {
 return a->counter;
diff --git a/libavutil/aes_ctr.h b/libavutil/aes_ctr.h
index f596fa6a46..e4aae126a7 100644
--- a/libavutil/aes_ctr.h
+++ b/libavutil/aes_ctr.h
@@ -67,10 +67,15 @@ const uint8_t* av_aes_ctr_get_iv(struct AVAESCTR *a);
 void av_aes_ctr_set_random_iv(struct AVAESCTR *a);
 
 /**
- * Forcefully change the iv
+ * Forcefully change the 8-byte iv
  */
 void av_aes_ctr_set_iv(struct AVAESCTR *a, const uint8_t* iv);
 
+/**
+ * Forcefully change the "full" 16-byte iv, including the counter
+ */
+void av_aes_ctr_set_full_iv(struct AVAESCTR *a, const uint8_t* iv);
+
 /**
  * Increment the top 64 bit of the iv (performed after each frame)
  */
diff --git a/libavutil/tests/aes_ctr.c b/libavutil/tests/aes_ctr.c
index c5ebeda7ac..00fdb05d13 100644
--- a/libavutil/tests/aes_ctr.c
+++ b/libavutil/tests/aes_ctr.c
@@ -45,7 +45,7 @@ int main (void)
 
 av_aes_ctr_set_random_iv(ae);
 iv =   av_aes_ctr_get_iv(ae);
-av_aes_ctr_set_iv(ad, iv);
+av_aes_ctr_set_full_iv(ad, iv);
 
 av_aes_ctr_crypt(ae, tmp, plain, sizeof(tmp));
 av_aes_ctr_crypt(ad, tmp, tmp,   sizeof(tmp));
diff --git a/libavutil/version.h b/libavutil/version.h
index d7398c41c5..0c032c8553 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR   8
+#define LIBAVUTIL_VERSION_MINOR   9
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.16.0.rc0.223.g4a4ac83678-goog

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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Increase support for common encryption.

[Jacob Trimble]

> You can't remove API just like that without a deprecation period.
> Add a new av_aes_ctr_set_full_iv() function, and either leave
> av_aes_ctr_set_iv() alone or deprecate it if it effectively becomes
> superfluous after adding the new function.
>
> Also, this patch needs to be split in three. One for the aes_crt
> changes, one for the encryption_info changes, and one for mov changes,
> with a minor libavutil version bump for the former two, and the
> corresponding APIChanges entry.
> Alternatively, you could also squash the new encryption_info API from
> this patch into the one that actually introduces the entire feature.

Whoops, I thought that was internal-only.  Done and split into its own change.

On Sat, Jan 6, 2018 at 7:30 AM, Carl Eugen Hoyos  wrote:
> 2018-01-05 20:49 GMT+01:00 Jacob Trimble :
>
>> +if (!frag_stream_info->encryption_index) {
>> +frag_stream_info->encryption_index = 
>> av_mallocz(sizeof(MOVEncryptionIndex));
>
> sizeof(variable), please.
>
> [...]
>
>> +sample_count = avio_rb32(pb);
>> +
>> +encryption_index->encrypted_samples = 
>> av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);
>
> This should be avoided if possible, see below.
>
>> +if (!encryption_index->encrypted_samples) {
>>  return AVERROR(ENOMEM);
>>  }
>> +encryption_index->nb_encrypted_samples = sample_count;
>>
>> -return av_aes_ctr_init(sc->cenc.aes_ctr, c->decryption_key);
>> +for (i = 0; i < sample_count; i++) {
>
> Please check here for eof...
>
>> +ret = mov_read_sample_encryption_info(c, pb, sc, 
>> &encryption_index->encrypted_samples[i], use_subsamples);
>
> ... and insert a realloc here to avoid the large allocation above, see 
> 1112ba01.

Done.

>
> Thank you, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From 0aafd18a05e23bdbe72529e2e1cd81fd98a4149a Mon Sep 17 00:00:00 2001
From: Jacob Trimble 
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.

- Parse schm atom to get different encryption schemes.
- Allow senc atom to appear in track fragments.
- Allow 16-byte IVs.
- Allow constant IVs (specified in tenc).
- Allow only tenc to specify encryption (i.e. no senc/saiz/saio).
- Use sample descriptor to detect clear fragments.

This doesn't support:
- Different sample descriptor holding different encryption info.
  - Only first sample descriptor can be encrypted.
- Encrypted sample groups (i.e. seig).
- Non-'cenc' encryption scheme when using -decryption_key.

This removes support for saio/saiz atoms, but it was incorrect before.
A follow-up change will add correct support for those.

Signed-off-by: Jacob Trimble 
---
 libavformat/isom.h |  20 +-
 libavformat/mov.c  | 434 ++---
 tests/fate/mov.mak |   8 +
 tests/ref/fate/mov-frag-encrypted  |  57 +
 tests/ref/fate/mov-tenc-only-encrypted |  57 +
 5 files changed, 423 insertions(+), 153 deletions(-)
 create mode 100644 tests/ref/fate/mov-frag-encrypted
 create mode 100644 tests/ref/fate/mov-tenc-only-encrypted

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 65676fb0f5..3794b1f0fd 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -27,6 +27,7 @@
 #include 
 #include 
 
+#include "libavutil/encryption_info.h"
 #include "libavutil/mastering_display_metadata.h"
 #include "libavutil/spherical.h"
 #include "libavutil/stereo3d.h"
@@ -108,12 +109,20 @@ typedef struct MOVSbgp {
 unsigned int index;
 } MOVSbgp;
 
+typedef struct MOVEncryptionIndex {
+// Individual encrypted samples.  If there are no elements, then the default
+// settings will be used.
+unsigned int nb_encrypted_samples;
+AVEncryptionInfo **encrypted_samples;
+} MOVEncryptionIndex;
+
 typedef struct MOVFragmentStreamInfo {
 int id;
 int64_t sidx_pts;
 int64_t first_tfra_pts;
 int64_t tfdt_dts;
 int index_entry;
+MOVEncryptionIndex *encryption_index;
 } MOVFragmentStreamInfo;
 
 typedef struct MOVFragmentIndexItem {
@@ -214,15 +223,10 @@ typedef struct MOVStreamContext {
 
 int has_sidx;  // If there is an sidx entry for this stream.
 struct {
-int use_subsamples;
-uint8_t* auxiliary_info;
-uint8_t* auxiliary_info_end;
-uint8_t* auxiliary_info_pos;
-uint8_t auxiliary_info_default_size;
-uint8_t* auxiliary_info_sizes;
-size_t auxiliary_info_sizes_count;
-int64_t auxiliary_info_index;
 struct AVAESCTR* aes_ctr;
+unsigned int per_sample_iv_size;  // Either 0, 8, or 16.
+AVEncryptionInfo *default_encrypted_sample;
+MOVEncryptionIndex *encryption_index;
 } cenc;
 } MOVStreamContext;
 
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 22faecfc17..4aeb379216 100644
--- a/libavformat/mov.c
++

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.

[Jacob Trimble]

On Fri, Jan 5, 2018 at 3:41 PM, Carl Eugen Hoyos  wrote:
> 2018-01-05 23:58 GMT+01:00 Jacob Trimble :
>> On Fri, Jan 5, 2018 at 2:01 PM, Carl Eugen Hoyos  wrote:
>>> 2018-01-05 22:29 GMT+01:00 Jacob Trimble 
>>> :
 On Fri, Jan 5, 2018 at 12:41 PM, Carl Eugen Hoyos  
 wrote:
> 2018-01-05 20:49 GMT+01:00 Jacob Trimble 
> :
>
>> +entry_count = avio_rb32(pb);
>> +encryption_index->auxiliary_offsets = 
>> av_malloc_array(sizeof(size_t), entry_count);
>
> (sizeof(variable) instead of sizeof(type), please.)
>
> But since this could be used for a dos attack, please change this
> to something similar to 1112ba01.
> If it is easy to avoid it, very short files should not allocate
> gigabytes.

 Switched to calculating the size based on the number of remaining
 bytes and returning an error if it doesn't match what is read.
>>>
>>> Sorry if I miss something:
>>>
 +entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version == 
 0 ? 4 : 8);
 +if (avio_rb32(pb) != entry_count) {
 +av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
 +return AVERROR_INVALIDDATA;
 +}
 +encryption_index->auxiliary_offsets =
 +av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), 
 entry_count);
>>>
>>> Does this avoid a 1G allocation for a file of a few bytes?
>>>
>>> Didn't you simply increase the number of needed bytes to change in a valid
>>> mov file to behave maliciously from one to two?
>>
>> From what I can tell, the mov_read_default method (which is what reads
>> child atoms) will verify "atom.size" to fit inside the parent atom.
>> This means that for "atom.size" to be excessively large for the file
>> size, the input would need to be non-seekable (since I think the
>> top-level atom uses the file size) and all the atoms would need to
>> have invalid sizes.
>
> (I did not check this but I am not convinced the sample I fixed last
> week is so sophisticated.)
>
>> But technically I guess it is possible.
>
> Thank you.
>
>> But this is basically malloc some number of bytes then read that many
>> bytes.  The only alternative I can think of (in the face of
>> non-seekable inputs) is to try-read in chunks until we hit EOF or the
>> end of the expected size.  This seems like a lot of extra work that is
>
>> not mirrored elsewhere.
>
> On the contrary.
>
> But you are right, I forgot to write that you have to add an "if (!eof)"
> to the reading loops, see the function that above commit changed.
>
>> There are several cases where this isn't explicitly checked.
>
> Yes, and they will be fixed, please don't add another one.
>
>> Also, how does this attack work?  If the number is way too big, well
>> get EOM and error out.
>
> Which not only causes dos but also makes checking for other (if you
> like: more dangerous) issues more difficult which is bad. We already
> know that there are cases where the issue is hard to avoid, I believe
> this is not such a case.
>
> It is possible to create (valid) samples that allocate a huge amount
> of memory but very small files should not immediately allocate an
> amount of several G.

Done.

>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From 524f81fd4b7ab31c576271f2747087bd16ca8734 Mon Sep 17 00:00:00 2001
From: Jacob Trimble 
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Fix parsing of saio/siaz atoms in encrypted
 content.

This doesn't support saio atoms with more than one offset.

Signed-off-by: Jacob Trimble 
---
 libavformat/isom.h |   6 ++
 libavformat/mov.c  | 232 +
 2 files changed, 238 insertions(+)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 3794b1f0fd..3de8053da2 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -114,6 +114,12 @@ typedef struct MOVEncryptionIndex {
 // settings will be used.
 unsigned int nb_encrypted_samples;
 AVEncryptionInfo **encrypted_samples;
+
+uint8_t* auxiliary_info_sizes;
+size_t auxiliary_info_sample_count;
+uint8_t auxiliary_info_default_size;
+size_t* auxiliary_offsets;  ///< Absolute seek position
+size_t auxiliary_offsets_count;
 } MOVEncryptionIndex;
 
 typedef struct MOVFragmentStreamInfo {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4aeb379216..71cc9a3af3 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5863,6 +5863,223 @@ end:
 return ret;
 }
 
+static int mov_parse_auxiliary_info(MOVContext *c, MOVStreamContext *sc, AVIOContext *pb, MOVEncryptionIndex *encryption_index)
+{
+AVEncryptionInfo **sample, **encrypted_samples;
+int64_t prev_pos;
+size_t sample_count, sample_info_size, i;
+int ret = 0;
+unsigned int alloc_size = 0;
+
+if (encryption_index->nb_encrypted_samples)
+  

Re: [FFmpeg-devel] [PATCH] avfilter: add dumpwave filter.

[Kyle Swanson]

Hi,

Can you provide some context for this? Please add docs as well.
Can't really test this because it segfaults for me:  ./ffmpeg -f lavfi
-i anoisesrc -af dumpwave -f null -

On Sun, Jan 7, 2018 at 4:36 PM,  wrote:
>
> From: Dmytro Humeniuk 
>
> Signed-off-by: Dmytro Humeniuk 
> ---
>  Changelog  |   1 +
>  libavfilter/Makefile   |   1 +
>  libavfilter/af_dumpwave.c  | 273 
> +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/version.h  |   4 +-
>  tests/fate/filter-audio.mak|   5 +
>  tests/ref/fate/filter-dumpwave |   1 +
>  7 files changed, 284 insertions(+), 2 deletions(-)
>  create mode 100644 libavfilter/af_dumpwave.c
>  create mode 100644 tests/ref/fate/filter-dumpwave
>
> diff --git a/Changelog b/Changelog
> index 61075b3392..40fd624449 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -38,6 +38,7 @@ version :
>  - Removed the ffserver program
>  - Removed the ffmenc and ffmdec muxer and demuxer
>  - VideoToolbox HEVC encoder and hwaccel
> +- dumpwave audio filter
>
>
>  version 3.4:
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 256dfabd66..020d90ee01 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -122,6 +122,7 @@ OBJS-$(CONFIG_TREMOLO_FILTER)+= 
> af_tremolo.o
>  OBJS-$(CONFIG_VIBRATO_FILTER)+= af_vibrato.o 
> generate_wave_table.o
>  OBJS-$(CONFIG_VOLUME_FILTER) += af_volume.o
>  OBJS-$(CONFIG_VOLUMEDETECT_FILTER)   += af_volumedetect.o
> +OBJS-$(CONFIG_DUMPWAVE_FILTER)   += af_dumpwave.o
>
>  OBJS-$(CONFIG_AEVALSRC_FILTER)   += aeval.o
>  OBJS-$(CONFIG_ANOISESRC_FILTER)  += asrc_anoisesrc.o
> diff --git a/libavfilter/af_dumpwave.c b/libavfilter/af_dumpwave.c
> new file mode 100644
> index 00..493b5b7ff2
> --- /dev/null
> +++ b/libavfilter/af_dumpwave.c
> @@ -0,0 +1,273 @@
> +/*
> + * Copyright (c) 2017 Dmytro Humeniuk
> + *
> + * 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
> + * waveform audio filter – dumps RMS amplitude to JSON file like SoundCloud 
> does
> + */
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/avstring.h"
> +#include "libavutil/channel_layout.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/parseutils.h"
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "audio.h"
> +#include "internal.h"
> +
> +typedef struct DumpWaveContext {
> +const AVClass *class;
> +int w, h;
> +AVRational rate;
> +int col;
> +char *json;
> +char *str;
> +double *values;
> +int64_t c, n, max_samples;
> +double sum; /* sum of the squared samples per segment */
> +} DumpWaveContext;
> +
> +#define OFFSET(x) offsetof(DumpWaveContext, x)
> +#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
> +
> +static const AVOption dumpwave_options[] = {
> +{ "s","set dump size", OFFSET(w), AV_OPT_TYPE_IMAGE_SIZE, {.str = 
> "600x240"}, 0, 0, FLAGS },
> +{ "c", "set number of samples per item",  OFFSET(c), AV_OPT_TYPE_INT64,  
> {.i64 = 0}, 0, INT64_MAX, FLAGS },

Use more descriptive parameter names. Also, per item? What is an item?

> +{ "json", "set dump file", OFFSET(json), AV_OPT_TYPE_STRING, { .str = 
> NULL }, 0, 0, FLAGS },
> +{ NULL }
> +};
> +
> +AVFILTER_DEFINE_CLASS(dumpwave);
> +
> +static int config_output(AVFilterLink *outlink)
> +{
> +DumpWaveContext *dumpwave = outlink->src->priv;
> +const int ch_width = dumpwave->w;
> +dumpwave->values = av_malloc(ch_width * sizeof(double));
> +dumpwave->str = av_malloc(ch_width*sizeof(int));
> +dumpwave->max_samples = dumpwave->c * outlink->channels;
> +
> +return 0;
> +}
> +
> +static av_cold void uninit(AVFilterContext *ctx)
> +{
> +DumpWaveContext *dumpwave = ctx->priv;
> +const int ch_height = dumpwave->h;
> +const int ch_width = dumpwave->w;
> +char *result = dumpwave->str;
> +FILE *dump_fp = NULL;
> +
> +if (dumpwave->json && !(dump_fp = av_fopen_utf8(dumpwave->json, "w")))
> +av_log(ctx, AV_LOG_WARNING, "dump failed.\n");
> +
> +if (dump_fp) {
> +fprintf(dump_fp, "{\"width\":%d,\"height\":%d,\"s

Re: [FFmpeg-devel] [PATCH 3/3] avformat/mov: Expose encryption info to the app.

[Jacob Trimble]

On Fri, Jan 5, 2018 at 12:55 PM, Jacob Trimble  wrote:
> On Fri, Jan 5, 2018 at 12:43 PM, Carl Eugen Hoyos  wrote:
>> 2018-01-05 20:49 GMT+01:00 Jacob Trimble :
>>
>>> +AV_WB32(side_data, size);
>>> +AV_WL32(side_data + 4, MKTAG('p','s','s','h'));
>>
>> I didn't check:
>> Is this what applications on both big- and little-endian expect?
>
> Yes.  This should match the MP4 atom, so the size and 'pssh' string
> should be big-endian.
>
>>
>> Carl Eugen
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Updated with the new design for the side data and applied the realloc
fix to avoid large allocations.
From da01baef5ead8194a991470de6b477ab59424617 Mon Sep 17 00:00:00 2001
From: Jacob Trimble 
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Expose encryption info to the app.

This exposes encryption info from the container to the app.  This
includes key ID, IV, and subsample byte ranges.  The info is passed
using the new side-data AV_PKT_DATA_ENCRYPTION_DATA and
AV_PKT_DATA_ENCRYPTION_INIT_DATA.

Signed-off-by: Jacob Trimble 
---
 libavformat/mov.c | 92 +++
 1 file changed, 92 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 71cc9a3af3..30165e6dc5 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6080,6 +6080,91 @@ static int mov_read_saio(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 return 0;
 }
 
+static int mov_read_pssh(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVEncryptionInitInfo *info;
+uint8_t **key_ids;
+AVStream *st;
+uint8_t *side_data, *extra_data;
+size_t side_data_size;
+int ret = 0;
+unsigned int version, kid_count, extra_data_size, alloc_size = 0, i = 0;
+
+if (c->fc->nb_streams < 1)
+return 0;
+st = c->fc->streams[c->fc->nb_streams-1];
+
+version = avio_r8(pb); /* version */
+avio_rb24(pb);  /* flags */
+
+info = av_encryption_init_info_alloc(/* system_id_size */ 16, /* num_key_ids */ 0,
+ /* key_id_size */ 16, /* data_size */ 0);
+if (!info)
+return AVERROR(ENOMEM);
+
+if (avio_read(pb, info->system_id, 16) != 16) {
+av_log(c->fc, AV_LOG_ERROR, "Failed to read the system id\n");
+ret = AVERROR_INVALIDDATA;
+goto finish;
+}
+
+if (version > 0) {
+kid_count = avio_rb32(pb);
+for (; i < kid_count && !pb->eof_reached; i++) {
+unsigned int min_kid_count = FFMIN(FFMAX(i, 1024), kid_count);
+key_ids = av_fast_realloc(info->key_ids, &alloc_size,
+  min_kid_count * sizeof(*key_ids));
+if (!key_ids) {
+ret = AVERROR(ENOMEM);
+goto finish;
+}
+info->key_ids = key_ids;
+
+info->key_ids[i] = av_mallocz(16);
+if (!info->key_ids[i]) {
+ret = AVERROR(ENOMEM);
+goto finish;
+}
+info->num_key_ids = i + 1;
+
+if (avio_read(pb, info->key_ids[i], 16) != 16) {
+av_log(c->fc, AV_LOG_ERROR, "Failed to read the key id\n");
+ret = AVERROR_INVALIDDATA;
+goto finish;
+}
+}
+
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_ERROR, "Hit EOF while reading pssh\n");
+ret = AVERROR_INVALIDDATA;
+goto finish;
+}
+}
+
+extra_data_size = avio_rb32(pb);
+ret = mov_try_read_block(pb, extra_data_size, &extra_data);
+if (ret < 0)
+goto finish;
+
+av_freep(&info->data);  // malloc(0) may still allocate something.
+info->data = extra_data;
+info->data_size = extra_data_size;
+
+side_data = av_encryption_init_info_add_side_data(info, &side_data_size);
+if (!side_data) {
+ret = AVERROR(ENOMEM);
+goto finish;
+}
+ret = av_stream_add_side_data(st, AV_PKT_DATA_ENCRYPTION_INIT_DATA,
+  side_data, side_data_size);
+if (ret < 0)
+av_free(side_data);
+
+finish:
+av_encryption_init_info_free(info);
+return ret;
+}
+
 static int mov_read_schm(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 AVStream *st;
@@ -6319,6 +6404,12 @@ static int cenc_filter(MOVContext *mov, MOVStreamContext *sc, AVPacket *pkt, int
 
 if (mov->decryption_key) {
 return cenc_decrypt(mov, sc, encrypted_sample, pkt->data, pkt->size);
+} else {
+size_t size;
+uint8_t *side_data = av_encryption_info_add_side_data(encrypted_sample, &size);
+if (!side_data)
+return AVERROR(ENOMEM);
+return av_packet_add_side_data(pkt, AV_PKT_DATA_ENCRYPTION_INFO, side_data, size);
 }
 }
 
@@ -6452,6 +6543,7 @@ static const MOVParseTableEntry mov_default

[FFmpeg-devel] [PATCH 1/3] libavcodec/v4l2_buffers: return int64_t in v4l2_get_pts

[Lukas Rusak]

v4l2_pts is type int64_t we should return that instead of uint64_t

---
 libavcodec/v4l2_buffers.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ba70c5d14b..fdafe7edca 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -62,7 +62,7 @@ static inline void v4l2_set_pts(V4L2Buffer *out, int64_t pts)
 out->buf.timestamp.tv_sec = v4l2_pts / USEC_PER_SEC;
 }
 
-static inline uint64_t v4l2_get_pts(V4L2Buffer *avbuf)
+static inline int64_t v4l2_get_pts(V4L2Buffer *avbuf)
 {
 V4L2m2mContext *s = buf_to_m2mctx(avbuf);
 AVRational v4l2_timebase = { 1, USEC_PER_SEC };
-- 
2.14.3

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

[FFmpeg-devel] [PATCH 2/3] libavcodec/v4l2_buffers: check for valid pts value

[Lukas Rusak]

we check for a valid pts in v4l2_set_pts so we should do the same here

---
 libavcodec/v4l2_buffers.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index fdafe7edca..5337f6f287 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -71,7 +71,10 @@ static inline int64_t v4l2_get_pts(V4L2Buffer *avbuf)
 /* convert pts back to encoder timebase */
 v4l2_pts = avbuf->buf.timestamp.tv_sec * USEC_PER_SEC + 
avbuf->buf.timestamp.tv_usec;
 
-return av_rescale_q(v4l2_pts, v4l2_timebase, s->avctx->time_base);
+if (v4l2_pts == 0)
+return AV_NOPTS_VALUE;
+else
+return av_rescale_q(v4l2_pts, v4l2_timebase, s->avctx->time_base);
 }
 
 static enum AVColorPrimaries v4l2_get_color_primaries(V4L2Buffer *buf)
-- 
2.14.3

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

[FFmpeg-devel] [PATCH 3/3] libavcodec/v4l2_m2m_dec: set default time base

[Lukas Rusak]

This default time base should be set in order for ffmpeg to rescale the 
timebase in v4l2_get_pts and v4l2_set_pts

---
 libavcodec/v4l2_m2m_dec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index 8308613978..4de091a011 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -177,6 +177,8 @@ static av_cold int v4l2_decode_init(AVCodecContext *avctx)
 capture->av_codec_id = AV_CODEC_ID_RAWVIDEO;
 capture->av_pix_fmt = avctx->pix_fmt;
 
+avctx->time_base = AV_TIME_BASE_Q;
+
 ret = ff_v4l2_m2m_codec_init(avctx);
 if (ret) {
 av_log(avctx, AV_LOG_ERROR, "can't configure decoder\n");
-- 
2.14.3

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

[FFmpeg-devel] [PATCH 0/3] v4l2: some small fixes

[Lukas Rusak]

Some small fixes that I have done while working with v4l2

Lukas Rusak (3):
  libavcodec/v4l2_buffers: return int64_t in v4l2_get_pts
  libavcodec/v4l2_buffers: check for valid pts value
  libavcodec/v4l2_m2m_dec: set default time base

 libavcodec/v4l2_buffers.c | 7 +--
 libavcodec/v4l2_m2m_dec.c | 2 ++
 2 files changed, 7 insertions(+), 2 deletions(-)

-- 
2.14.3

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

Re: [FFmpeg-devel] [PATCHv2 2/2] avfilter/vf_framerate: simplify filter

[Marton Balint]

On Thu, 4 Jan 2018, Marton Balint wrote:


The framerate filter was quite convoluted with some filter_frame /
request_frame logic bugs. It seemed easier to rewrite the whole filter_frame /
request_frame part and also the frame interpolation ratio calculation part in
one step.

Notable changes:
- The filter now only stores 2 frames instead of 3
- filter_frame outputs all the frames it can to be able to handle consecutive
 filter_frame calls which previously caused early drops of buffered frames.
- because of this, request_frame is largely simplified and it only outputs
 frames on flush. Previously consecuitve request_frame calls could cause the
 filter to think it is in flush mode filling its buffer with the same frames
 causing a "ghost" effect on the output.
- PTS discontinuities are handled better
- frames with unknown PTS values are now dropped

Fixes ticket #4870.
Probably fixes ticket #5493.



Will push this soon.

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

Re: [FFmpeg-devel] [PATCH 3/3] libavcodec/v4l2_m2m_dec: set default time base

[wm4]

On Mon,  8 Jan 2018 15:27:39 -0800
Lukas Rusak  wrote:

> This default time base should be set in order for ffmpeg to rescale the 
> timebase in v4l2_get_pts and v4l2_set_pts
> 
> ---
>  libavcodec/v4l2_m2m_dec.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> index 8308613978..4de091a011 100644
> --- a/libavcodec/v4l2_m2m_dec.c
> +++ b/libavcodec/v4l2_m2m_dec.c
> @@ -177,6 +177,8 @@ static av_cold int v4l2_decode_init(AVCodecContext *avctx)
>  capture->av_codec_id = AV_CODEC_ID_RAWVIDEO;
>  capture->av_pix_fmt = avctx->pix_fmt;
>  
> +avctx->time_base = AV_TIME_BASE_Q;
> +
>  ret = ff_v4l2_m2m_codec_init(avctx);
>  if (ret) {
>  av_log(avctx, AV_LOG_ERROR, "can't configure decoder\n");

Decoders in FFmpeg don't really have a concept of a timebase. If they
do, they should not use avctx->time_base, but avctx->pkt_timebase.

(I don't think avctx->pkt_timebase even needs to be set - API users
normally expect that the decoder simply passes through timestamps,
regardless of timebase. But if pkt_timebase is set, it should be the
same timebase that AVPacket uses, and the output AVFrames must use the
same timebase.

avctx->time_base doesn't really mean anything for decoding. There is an
obscure "other" use of it that has been deprecated, and the replacement
has the same obscure use (see doxygen).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH][RFC] libavcodec/v4l2_m2m_dec: output AVDRMFrameDescriptor

[Lukas Rusak]

This is a patch I have been testing for a while in combination with kodi's 
drmprime renderer

I have been testing this with i.MX6 and Dragonboard 410c. So it covers single 
and multiplanar formats.

I'm looking to get some comments on how to integrate this properly so that if 
we request
AV_PIX_FMT_DRM_PRIME we can use that otherwise just use the default buffers.

I basically followed how it was done in the rockchip decoder.

---
 libavcodec/v4l2_buffers.c | 97 +++
 libavcodec/v4l2_buffers.h |  1 +
 libavcodec/v4l2_m2m_dec.c | 45 --
 3 files changed, 97 insertions(+), 46 deletions(-)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ba70c5d14b..065074c944 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -21,6 +21,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,8 @@
 #include 
 #include "libavcodec/avcodec.h"
 #include "libavcodec/internal.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_drm.h"
 #include "v4l2_context.h"
 #include "v4l2_buffers.h"
 #include "v4l2_m2m.h"
@@ -202,11 +205,14 @@ static enum AVColorTransferCharacteristic 
v4l2_get_color_trc(V4L2Buffer *buf)
 return AVCOL_TRC_UNSPECIFIED;
 }
 
-static void v4l2_free_buffer(void *opaque, uint8_t *unused)
+static void v4l2_free_buffer(void *opaque, uint8_t *data)
 {
+AVDRMFrameDescriptor *desc = (AVDRMFrameDescriptor *)data;
 V4L2Buffer* avbuf = opaque;
 V4L2m2mContext *s = buf_to_m2mctx(avbuf);
 
+av_free(desc);
+
 atomic_fetch_sub_explicit(&s->refcount, 1, memory_order_acq_rel);
 if (s->reinit) {
 if (!atomic_load(&s->refcount))
@@ -289,35 +295,15 @@ int ff_v4l2_buffer_avframe_to_buf(const AVFrame *frame, 
V4L2Buffer* out)
 int ff_v4l2_buffer_buf_to_avframe(AVFrame *frame, V4L2Buffer *avbuf)
 {
 V4L2m2mContext *s = buf_to_m2mctx(avbuf);
-int i, ret;
+AVDRMFrameDescriptor *desc = NULL;
+AVDRMLayerDescriptor *layer = NULL;
+int ret;
 
 av_frame_unref(frame);
 
-/* 1. get references to the actual data */
-for (i = 0; i < avbuf->num_planes; i++) {
-ret = v4l2_buf_to_bufref(avbuf, i, &frame->buf[i]);
-if (ret)
-return ret;
-
-frame->linesize[i] = avbuf->plane_info[i].bytesperline;
-frame->data[i] = frame->buf[i]->data;
-}
-
-/* 1.1 fixup special cases */
-switch (avbuf->context->av_pix_fmt) {
-case AV_PIX_FMT_NV12:
-if (avbuf->num_planes > 1)
-break;
-frame->linesize[1] = avbuf->plane_info[0].bytesperline;
-frame->data[1] = frame->buf[0]->data + 
avbuf->plane_info[0].bytesperline * avbuf->context->format.fmt.pix_mp.height;
-break;
-default:
-break;
-}
-
 /* 2. get frame information */
 frame->key_frame = !!(avbuf->buf.flags & V4L2_BUF_FLAG_KEYFRAME);
-frame->format = avbuf->context->av_pix_fmt;
+frame->format = AV_PIX_FMT_DRM_PRIME;
 frame->color_primaries = v4l2_get_color_primaries(avbuf);
 frame->colorspace = v4l2_get_color_space(avbuf);
 frame->color_range = v4l2_get_color_range(avbuf);
@@ -328,6 +314,42 @@ int ff_v4l2_buffer_buf_to_avframe(AVFrame *frame, 
V4L2Buffer *avbuf)
 frame->height = s->output.height;
 frame->width = s->output.width;
 
+ret = ff_v4l2_buffer_export(avbuf);
+if (ret < 0) {
+return AVERROR(errno);
+}
+
+desc = av_mallocz(sizeof(AVDRMFrameDescriptor));
+if (!desc) {
+return AVERROR(ENOMEM);
+}
+
+desc->nb_objects = 1;
+
+if (V4L2_TYPE_IS_MULTIPLANAR(avbuf->buf.type)) {
+desc->objects[0].fd = avbuf->buf.m.planes[0].m.fd;
+desc->objects[0].size = avbuf->buf.m.planes[0].length;
+} else {
+desc->objects[0].fd = avbuf->buf.m.fd;
+desc->objects[0].size = avbuf->buf.length;
+}
+
+desc->nb_layers = 1;
+layer = &desc->layers[0];
+layer->format = DRM_FORMAT_NV12;
+layer->nb_planes = 2;
+
+layer->planes[0].object_index = 0;
+layer->planes[0].offset = 0;
+layer->planes[0].pitch = avbuf->plane_info[0].bytesperline;
+
+layer->planes[1].object_index = 0;
+layer->planes[1].offset = layer->planes[0].pitch * 
avbuf->context->format.fmt.pix_mp.height;
+layer->planes[1].pitch = avbuf->plane_info[0].bytesperline;
+
+frame->data[0] = (uint8_t *)desc;
+frame->buf[0] = av_buffer_create((uint8_t *)desc, sizeof(*desc), 
v4l2_free_buffer, avbuf, AV_BUFFER_FLAG_READONLY);
+
 /* 3. report errors upstream */
 if (avbuf->buf.flags & V4L2_BUF_FLAG_ERROR) {
 av_log(logger(avbuf), AV_LOG_ERROR, "%s: driver decode error\n", 
avbuf->context->name);
@@ -461,3 +483,28 @@ int ff_v4l2_buffer_enqueue(V4L2Buffer* avbuf)
 
 return 0;
 }
+
+int ff_v4l2_buffer_export(V4L2Buffer* avbuf)
+{
+int i, ret;
+
+for (i = 0; i < avbuf->num_planes; i++) {
+
+str

Re: [FFmpeg-devel] [PATCH 0/3] v4l2: some small fixes

[Jorge Ramirez]

On 01/09/2018 12:27 AM, Lukas Rusak wrote:

Some small fixes that I have done while working with v4l2


hi Lukas, what sort of error where you observing? I'd like to reproduce 
on my end
I was about to post Mark Thompson's fix plus another one to get rid of 
the unnecessary timeouts. will do tomorrow.


cheers
jorge



Lukas Rusak (3):
   libavcodec/v4l2_buffers: return int64_t in v4l2_get_pts
   libavcodec/v4l2_buffers: check for valid pts value
   libavcodec/v4l2_m2m_dec: set default time base

  libavcodec/v4l2_buffers.c | 7 +--
  libavcodec/v4l2_m2m_dec.c | 2 ++
  2 files changed, 7 insertions(+), 2 deletions(-)



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

Re: [FFmpeg-devel] [PATCH 2/3] libavcodec/v4l2_buffers: check for valid pts value

[wm4]

On Mon,  8 Jan 2018 15:27:38 -0800
Lukas Rusak  wrote:

> we check for a valid pts in v4l2_set_pts so we should do the same here
> 
> ---
>  libavcodec/v4l2_buffers.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> index fdafe7edca..5337f6f287 100644
> --- a/libavcodec/v4l2_buffers.c
> +++ b/libavcodec/v4l2_buffers.c
> @@ -71,7 +71,10 @@ static inline int64_t v4l2_get_pts(V4L2Buffer *avbuf)
>  /* convert pts back to encoder timebase */
>  v4l2_pts = avbuf->buf.timestamp.tv_sec * USEC_PER_SEC + 
> avbuf->buf.timestamp.tv_usec;
>  
> -return av_rescale_q(v4l2_pts, v4l2_timebase, s->avctx->time_base);
> +if (v4l2_pts == 0)
> +return AV_NOPTS_VALUE;
> +else
> +return av_rescale_q(v4l2_pts, v4l2_timebase, s->avctx->time_base);
>  }
>  
>  static enum AVColorPrimaries v4l2_get_color_primaries(V4L2Buffer *buf)

So, what about pts=0, which is valid? You shouldn't just turn 0 into
AV_NOPTS_VALUE.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] libavcodec/v4l2_buffers: check for valid pts value

[Lukas Rusak]

Hmm ok, disregard then.
On Mon, Jan 8, 2018 at 3:53 PM wm4  wrote:

> On Mon,  8 Jan 2018 15:27:38 -0800
> Lukas Rusak  wrote:
>
> > we check for a valid pts in v4l2_set_pts so we should do the same here
> >
> > ---
> >  libavcodec/v4l2_buffers.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> > index fdafe7edca..5337f6f287 100644
> > --- a/libavcodec/v4l2_buffers.c
> > +++ b/libavcodec/v4l2_buffers.c
> > @@ -71,7 +71,10 @@ static inline int64_t v4l2_get_pts(V4L2Buffer *avbuf)
> >  /* convert pts back to encoder timebase */
> >  v4l2_pts = avbuf->buf.timestamp.tv_sec * USEC_PER_SEC +
> avbuf->buf.timestamp.tv_usec;
> >
> > -return av_rescale_q(v4l2_pts, v4l2_timebase, s->avctx->time_base);
> > +if (v4l2_pts == 0)
> > +return AV_NOPTS_VALUE;
> > +else
> > +return av_rescale_q(v4l2_pts, v4l2_timebase,
> s->avctx->time_base);
> >  }
> >
> >  static enum AVColorPrimaries v4l2_get_color_primaries(V4L2Buffer *buf)
>
> So, what about pts=0, which is valid? You shouldn't just turn 0 into
> AV_NOPTS_VALUE.
> ___
> 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 3/3] libavcodec/v4l2_m2m_dec: set default time base

[Lukas Rusak]

I'm not really sure what to do then.

Should I just replace time_base with pkt_timebase instead?

Or

Should I just remove the time base rescaling completely in v4l2_set_pts and
v4l2_get_pts as it seems to be 1:1 anyways.
On Mon, Jan 8, 2018 at 3:45 PM wm4  wrote:

> On Mon,  8 Jan 2018 15:27:39 -0800
> Lukas Rusak  wrote:
>
> > This default time base should be set in order for ffmpeg to rescale the
> timebase in v4l2_get_pts and v4l2_set_pts
> >
> > ---
> >  libavcodec/v4l2_m2m_dec.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> > index 8308613978..4de091a011 100644
> > --- a/libavcodec/v4l2_m2m_dec.c
> > +++ b/libavcodec/v4l2_m2m_dec.c
> > @@ -177,6 +177,8 @@ static av_cold int v4l2_decode_init(AVCodecContext
> *avctx)
> >  capture->av_codec_id = AV_CODEC_ID_RAWVIDEO;
> >  capture->av_pix_fmt = avctx->pix_fmt;
> >
> > +avctx->time_base = AV_TIME_BASE_Q;
> > +
> >  ret = ff_v4l2_m2m_codec_init(avctx);
> >  if (ret) {
> >  av_log(avctx, AV_LOG_ERROR, "can't configure decoder\n");
>
> Decoders in FFmpeg don't really have a concept of a timebase. If they
> do, they should not use avctx->time_base, but avctx->pkt_timebase.
>
> (I don't think avctx->pkt_timebase even needs to be set - API users
> normally expect that the decoder simply passes through timestamps,
> regardless of timebase. But if pkt_timebase is set, it should be the
> same timebase that AVPacket uses, and the output AVFrames must use the
> same timebase.
>
> avctx->time_base doesn't really mean anything for decoding. There is an
> obscure "other" use of it that has been deprecated, and the replacement
> has the same obscure use (see doxygen).
> ___
> 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 3/3] libavcodec/v4l2_m2m_dec: set default time base

[wm4]

On Tue, 09 Jan 2018 00:03:15 +
Lukas Rusak  wrote:

> I'm not really sure what to do then.
> 
> Should I just replace time_base with pkt_timebase instead?
> 
> Or
> 
> Should I just remove the time base rescaling completely in v4l2_set_pts and
> v4l2_get_pts as it seems to be 1:1 anyways.

The encoder needs to use time_base, the decoder pkt_timebase.

If the decoder can simply pass through timestamps, you don't need to do
any rescaling in the decoder. But I doubt v4l can do that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Aurelien Jacobs]

On Mon, Jan 08, 2018 at 01:27:16PM +0100, Carl Eugen Hoyos wrote:
> 2018-01-08 11:32 GMT+01:00 Hendrik Leppkes :
> > On Mon, Jan 8, 2018 at 1:38 AM, Rostislav Pehlivanov
> >  wrote:
> >>
> >> That's okay - for encoding switch the profile depending on both the
> >> avctx->profile setting and the samplerate and list all supported
> >> samplerates for all profiles in the AVCodec structure. We do something
> >> similar in the AAC encoder where we pick different settings depending on
> >> the profile and change the profile depending on the settings listed.
> >> If there's an overlap, pick a sane default unless the user forces a profile
> >> using profile:a. If forced and the samplerate isn't supported - error out
> >> and let the user know.
> >> For decoding set the profile via the demuxer. There doesn't have to be just
> >> one demuxer for a codec. If there are major changes in how you parse
> >> profiles go ahead and make a new one which sets the codec ID and the
> >> profile.
> >>
> >
> > I don't think there is any precedent for "profile" being mandatory for
> > a decoder to work, so that might be iffy. Decoders usually set
> > profile, don't require it.
> > ie. from the docs:
> > * - decoding: Set by libavcodec.

Oh, very true. I guess that settles it for "profile". Public API do not
allows using profile to select the appropriate decoder.

> > There is plenty precedent for using "codec_tag" however, so that may
> > be a better choice - and can hold the tag from the "container" as-is
> > as well.
> 
> While I don't understand why even having more than one codec_id for
> the same codec (which afaiu isn't the case here) would be an issue,

Same for me, I don't understand why adding a codec_id would be an issue.

> I don't think we should invent codec_tags unless necessary.

I agree. And I don't think there is a container used for aptX or aptX HD
in the wild with some kind of codec_tag. So this is probably not an
option either.

I maintain that using 2 codec IDs is the most appropriate in this
specific case.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data

[Jacob Trimble]

On Mon, Jan 8, 2018 at 11:40 AM, Jacob Trimble  wrote:
>> I'd assume we'd wait with applying this until the mp4 patch that uses
>> it is reviewed. I'm fine with this patch and I think it can be pushed
>> as it is, although I just noticed an APIchanges entry and minor version
>> bump is actually missing. You could add them when sending the final
>> patch set.
>
> Added APIchanges entry and version bump.
>
>> The format of teh side data should be choosen so that demuxers and encoders
>> producing it can interoperate with muxers and decoders consuming it.
>
>> Please correct me if iam wrong but if some containers can store more than
>> others, then the "other" containers would not use that extra information nor
>> set it but it could still be using a compatible representation for 
>> interoperability
>
> Well I guess I can do the same thing for this as for the
> frame-specific encryption info.  There will be a user-friendly struct
> for accessing it and a binary format that will be stored in the side
> data.  This will allow different (de)muxers to use the data in a
> generic way.
>
>> These should be checked against size, making sure the data is consistent
>
> Done.  Also added addition overflow checking.
>
> On Fri, Jan 5, 2018 at 2:42 PM, James Almer  wrote:
>> This being in libavutil, the two functions using AVPacket should be
>> changed to take and return a byte array instead, that the caller
>> manually either got from side data, or will afterwards adds as side data.
>
> Done.

Noticed some bugs when integrating with my other changes.
From 54f996fd8b8b8e44506739b58784e6038309 Mon Sep 17 00:00:00 2001
From: Jacob Trimble 
Date: Tue, 5 Dec 2017 14:52:22 -0800
Subject: [PATCH] avcodec/avcodec.h: Add encryption info side data.

This new side-data will contain info on how a packet is encrypted.
This allows the app to handle packet decryption.

Signed-off-by: Jacob Trimble 
---
 doc/APIchanges  |   4 +
 libavcodec/avcodec.h|  13 ++
 libavutil/Makefile  |   2 +
 libavutil/encryption_info.c | 295 
 libavutil/encryption_info.h | 200 ++
 libavutil/version.h |   2 +-
 6 files changed, 515 insertions(+), 1 deletion(-)
 create mode 100644 libavutil/encryption_info.c
 create mode 100644 libavutil/encryption_info.h

diff --git a/doc/APIchanges b/doc/APIchanges
index d66c842521..b771031740 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-xx-xx - xxx - lavu 56.8.100 - encryption_info.h
+  Add AVEncryptionInitInfo and AVEncryptionInfo structures to hold new side-data
+  for encryption info.
+
 2018-01-xx - xxx - lavfi 7.11.101 - avfilter.h
   Deprecate avfilter_link_get_channels(). Use av_buffersink_get_channels().
 
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c13deb599f..2e5d39eae3 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1341,6 +1341,19 @@ enum AVPacketSideDataType {
  */
 AV_PKT_DATA_A53_CC,
 
+/**
+ * This side data is encryption initialization data.
+ * The format is not part of ABI, use av_encryption_init_info_* methods to
+ * access.
+ */
+AV_PKT_DATA_ENCRYPTION_INIT_INFO,
+
+/**
+ * This side data contains encryption info for how to decrypt the packet.
+ * The format is not part of ABI, use av_encryption_info_* methods to access.
+ */
+AV_PKT_DATA_ENCRYPTION_INFO,
+
 /**
  * The number of side data types.
  * This is not part of the public API/ABI in the sense that it may
diff --git a/libavutil/Makefile b/libavutil/Makefile
index d7474f59e4..760fce3b30 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -24,6 +24,7 @@ HEADERS = adler32.h \
   dict.h\
   display.h \
   downmix_info.h\
+  encryption_info.h \
   error.h   \
   eval.h\
   fifo.h\
@@ -107,6 +108,7 @@ OBJS = adler32.o\
dict.o   \
display.o\
downmix_info.o   \
+   encryption_info.o\
error.o  \
eval.o   \
fifo.o

[FFmpeg-devel] [PATCH 02/11] decklink: Add support for output of Active Format Description (AFD)

[Devin Heitmueller]

Implement support for including AFD in decklink output.  This
includes making sure the AFD data is preserved when going from
an AVFrame to a V210 packet (needed for 10-bit support).

Updated to reflect feedback from Marton Balint ,
Carl Eugen Hoyos  and Aaron Levinson
.

Signed-off-by: Devin Heitmueller 
---
 libavcodec/avcodec.h |  6 ++
 libavcodec/v210enc.c |  8 
 libavdevice/decklink_enc.cpp | 44 ++--
 3 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c13deb5..5fa028e 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1342,6 +1342,12 @@ enum AVPacketSideDataType {
 AV_PKT_DATA_A53_CC,
 
 /**
+ * Active Format Description data consisting of a single byte as specified
+ * in ETSI TS 101 154 using AVActiveFormatDescription enum.
+ */
+AV_PKT_DATA_AFD,
+
+/**
  * The number of side data types.
  * This is not part of the public API/ABI in the sense that it may
  * change when new side data types are added.
diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index b9dcf9a..b024806 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -242,6 +242,14 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 memcpy(buf, side_data->data, side_data->size);
 }
 
+side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_AFD);
+if (side_data && side_data->size) {
+uint8_t *buf = av_packet_new_side_data(pkt, AV_PKT_DATA_AFD, 
side_data->size);
+if (!buf)
+return AVERROR(ENOMEM);
+memcpy(buf, side_data->data, side_data->size);
+}
+
 pkt->flags |= AV_PKT_FLAG_KEY;
 *got_packet = 1;
 return 0;
diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index faa382a..ff60050 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -301,7 +301,8 @@ av_cold int ff_decklink_write_trailer(AVFormatContext 
*avctx)
 
 #if CONFIG_LIBKLVANC
 static int decklink_construct_vanc(AVFormatContext *avctx, struct decklink_ctx 
*ctx,
-   AVPacket *pkt, decklink_frame *frame)
+   AVPacket *pkt, decklink_frame *frame,
+   AVStream *st)
 {
 struct klvanc_line_set_s vanc_lines = { 0 };
 int ret, size;
@@ -359,6 +360,45 @@ static int decklink_construct_vanc(AVFormatContext *avctx, 
struct decklink_ctx *
 }
 }
 
+data = av_packet_get_side_data(pkt, AV_PKT_DATA_AFD, &size);
+if (data) {
+struct klvanc_packet_afd_s *pkt;
+uint16_t *afd;
+uint16_t len;
+
+ret = klvanc_create_AFD(&pkt);
+if (ret != 0)
+return AVERROR(ENOMEM);
+
+ret = klvanc_set_AFD_val(pkt, data[0]);
+if (ret != 0) {
+av_log(avctx, AV_LOG_ERROR, "Invalid AFD value specified: %d\n",
+   data[0]);
+klvanc_destroy_AFD(pkt);
+return AVERROR(EINVAL);
+}
+
+/* FIXME: Should really rely on the coded_width but seems like that
+   is not accessible to libavdevice outputs */
+if (av_cmp_q((AVRational) {st->codecpar->width, st->codecpar->height}, 
(AVRational) {4, 3}) == 1)
+pkt->aspectRatio = ASPECT_16x9;
+else
+pkt->aspectRatio = ASPECT_4x3;
+
+ret = klvanc_convert_AFD_to_words(pkt, &afd, &len);
+if (ret != 0) {
+av_log(avctx, AV_LOG_ERROR, "Failed converting 708 packet to 
words\n");
+return AVERROR(ENOMEM);
+}
+klvanc_destroy_AFD(pkt);
+
+ret = klvanc_line_insert(ctx->vanc_ctx, &vanc_lines, afd, len, 12, 0);
+if (ret != 0) {
+av_log(avctx, AV_LOG_ERROR, "VANC line insertion failed\n");
+return AVERROR(ENOMEM);
+}
+}
+
 IDeckLinkVideoFrameAncillary *vanc;
 int result = ctx->dlo->CreateAncillaryData(bmdFormat10BitYUV, &vanc);
 if (result != S_OK) {
@@ -455,7 +495,7 @@ static int decklink_write_video_packet(AVFormatContext 
*avctx, AVPacket *pkt)
 frame = new decklink_frame(ctx, avpacket, st->codecpar->codec_id, 
ctx->bmd_height, ctx->bmd_width);
 
 #if CONFIG_LIBKLVANC
-ret = decklink_construct_vanc(avctx, ctx, pkt, frame);
+ret = decklink_construct_vanc(avctx, ctx, pkt, frame, st);
 if (ret != 0) {
 av_log(avctx, AV_LOG_ERROR, "Failed to construct VANC\n");
 }
-- 
1.8.3.1

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

[FFmpeg-devel] [PATCH 03/11] decklink: Introduce support for capture of multiple audio streams

[Devin Heitmueller]

Add support for the ability to capture all audio pairs available
to the capture hardware.  Each pair is exposed as a different audio
stream, which matches up with the most common use cases for the
broadcast space (i.e. where there is one stereo pair per audio
language).

To support the existing use case where multi-channel audio can be
captured (i.e. 7.1), we introduced a new configuration option, which
defaults to the existing behavior.

Updated to reflect comments from Carl Eugen Hoyos ,
Aaron Levinson , and Matthias Hunstock
.

Signed-off-by: Devin Heitmueller 
---
 doc/indevs.texi |   8 ++-
 libavdevice/decklink_common.cpp |  12 
 libavdevice/decklink_common.h   |   8 ++-
 libavdevice/decklink_common_c.h |   6 ++
 libavdevice/decklink_dec.cpp| 136 +++-
 libavdevice/decklink_dec_c.c|   3 +
 6 files changed, 142 insertions(+), 31 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index 56066bf..4760d70 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -278,9 +278,15 @@ For SD sources, ffmpeg needs to be compiled with 
@code{--enable-libzvbi}. For
 HD sources, on older (pre-4K) DeckLink card models you have to capture in 10
 bit mode.
 
+@item audio_mode
+Defines whether to capture a bundle of audio channels (the number of which is 
determined
+by the channels argument), or whether to capture a number of audio pairs (the 
number of
+which is determined by the maximum number of pairs supported by the card).  
Must be
+@samp{bundled} or @samp{pairs}.  Defaults to @samp{bundled}.
+
 @item channels
 Defines number of audio channels to capture. Must be @samp{2}, @samp{8} or 
@samp{16}.
-Defaults to @samp{2}.
+Defaults to @samp{2}.  This parameter is ignored if audio_mode is set to pairs.
 
 @item duplex_mode
 Sets the decklink device duplex mode. Must be @samp{unset}, @samp{half} or 
@samp{full}.
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index c432189..e7daa63 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -446,6 +446,7 @@ int ff_decklink_init_device(AVFormatContext *avctx, const 
char* name)
 struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
 struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
 IDeckLink *dl = NULL;
+int64_t maxAudioChannels;
 IDeckLinkIterator *iter = CreateDeckLinkIteratorInstance();
 if (!iter) {
 av_log(avctx, AV_LOG_ERROR, "Could not create DeckLink iterator\n");
@@ -479,5 +480,16 @@ int ff_decklink_init_device(AVFormatContext *avctx, const 
char* name)
 return AVERROR_EXTERNAL;
 }
 
+if (ctx->attr->GetInt(BMDDeckLinkMaximumAudioChannels, &maxAudioChannels) 
!= S_OK) {
+av_log(avctx, AV_LOG_WARNING, "Could not determine number of audio 
channels\n");
+ctx->max_audio_channels = 0;
+} else {
+ctx->max_audio_channels = maxAudioChannels;
+}
+if (ctx->max_audio_channels > DECKLINK_MAX_AUDIO_CHANNELS) {
+av_log(avctx, AV_LOG_WARNING, "Decklink card reported support for more 
channels than ffmpeg supports\n");
+ctx->max_audio_channels = DECKLINK_MAX_AUDIO_CHANNELS;
+}
+
 return 0;
 }
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 143bbb9..b262780 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -37,6 +37,10 @@
 #define DECKLINK_BOOL bool
 #endif
 
+/* Maximum number of channels possible across variants of Blackmagic cards.
+   Actual number for any particular model of card may be lower */
+#define DECKLINK_MAX_AUDIO_CHANNELS 32
+
 class decklink_output_callback;
 class decklink_input_callback;
 
@@ -71,6 +75,7 @@ struct decklink_ctx {
 int bmd_height;
 int bmd_field_dominance;
 int supports_vanc;
+int max_audio_channels;
 
 /* Capture buffer queue */
 AVPacketQueue queue;
@@ -85,7 +90,8 @@ struct decklink_ctx {
 int64_t last_pts;
 unsigned long frameCount;
 unsigned int dropped;
-AVStream *audio_st;
+AVStream *audio_st[DECKLINK_MAX_AUDIO_CHANNELS];
+int num_audio_streams;
 AVStream *video_st;
 AVStream *teletext_st;
 uint16_t cdp_sequence_num;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 368ac25..3a21bae 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -30,6 +30,11 @@ typedef enum DecklinkPtsSource {
 PTS_SRC_WALLCLOCK = 4,
 } DecklinkPtsSource;
 
+typedef enum DecklinkAudioMode {
+AUDIO_MODE_BUNDLED = 0,
+AUDIO_MODE_PAIRS = 1,
+} DecklinkAudioMode;
+
 struct decklink_cctx {
 const AVClass *cclass;
 
@@ -42,6 +47,7 @@ struct decklink_cctx {
 double preroll;
 int v210;
 int audio_channels;
+int audio_mode;
 int audio_depth;
 int duplex_mode;
 DecklinkPtsSource audio_pts_source;
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 94dae26..6

[FFmpeg-devel] [PATCH 05/11] Support encoding of Active Format Description (AFD) in libx264

[Devin Heitmueller]

If AFD side data is present, include it in an H.264 SEI payload when
encoding with libx264.

This is done in the same manner that we currently handle A53 closed
captions (where the business logic for constructing the SEI is in
libavcodec/utils.c), so it should be portable to the other encoder
types (i.e. videotoolbox, etc).

Updated to reflect feedback from Derek Buitenhuis 
and Aaron Levinson .

Signed-off-by: Devin Heitmueller 
---
 libavcodec/internal.h |  3 +++
 libavcodec/libx264.c  | 47 +++
 libavcodec/utils.c| 36 
 3 files changed, 82 insertions(+), 4 deletions(-)

diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 16bd101..821dfb6 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -404,6 +404,9 @@ int ff_side_data_set_encoder_stats(AVPacket *pkt, int 
quality, int64_t *error, i
 int ff_alloc_a53_sei(const AVFrame *frame, size_t prefix_len,
  void **data, size_t *sei_size);
 
+int ff_alloc_afd_sei(const AVFrame *frame, size_t prefix_len,
+ void **data, size_t *sei_size);
+
 /**
  * Get an estimated video bitrate based on frame size, frame rate and coded
  * bits per pixel.
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 12379ff..3bd787d 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -86,6 +86,7 @@ typedef struct X264Context {
 int forced_idr;
 int coder;
 int a53_cc;
+int afd;
 int b_frame_strategy;
 int chroma_offset;
 int scenechange_threshold;
@@ -275,6 +276,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
 x264_nal_t *nal;
 int nnal, i, ret;
 x264_picture_t pic_out = {0};
+int num_payloads = 0;
 int pict_type;
 
 x264_picture_init( &x4->pic );
@@ -327,10 +329,46 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
 } else {
 x4->pic.extra_sei.sei_free = av_free;
 
-x4->pic.extra_sei.payloads[0].payload_size = sei_size;
-x4->pic.extra_sei.payloads[0].payload = sei_data;
-x4->pic.extra_sei.num_payloads = 1;
-x4->pic.extra_sei.payloads[0].payload_type = 4;
+x4->pic.extra_sei.payloads[num_payloads].payload_size = 
sei_size;
+x4->pic.extra_sei.payloads[num_payloads].payload = 
sei_data;
+x4->pic.extra_sei.payloads[num_payloads].payload_type = 4;
+x4->pic.extra_sei.num_payloads++;
+num_payloads++;
+}
+}
+}
+
+/* Active Format Description */
+if (x4->afd) {
+void *sei_data;
+size_t sei_size;
+
+ret = ff_alloc_afd_sei(frame, 0, &sei_data, &sei_size);
+if (ret < 0) {
+for (i = 0; i < num_payloads; i++)
+av_freep(&x4->pic.extra_sei.payloads[i].payload);
+av_freep(&x4->pic.extra_sei.payloads);
+return AVERROR(ENOMEM);
+} else if (sei_data) {
+x264_sei_payload_t *payloads;
+payloads = av_realloc(x4->pic.extra_sei.payloads,
+  sizeof(x4->pic.extra_sei.payloads[0]) * 
(num_payloads + 1));
+if (payloads == NULL) {
+av_log(ctx, AV_LOG_ERROR, "Not enough memory for AFD, 
skipping\n");
+for (i = 0; i < num_payloads; i++)
+av_freep(&x4->pic.extra_sei.payloads[i].payload);
+av_freep(&x4->pic.extra_sei.payloads);
+av_freep(&sei_data);
+return AVERROR(ENOMEM);
+} else {
+x4->pic.extra_sei.payloads = payloads;
+x4->pic.extra_sei.sei_free = av_free;
+
+x4->pic.extra_sei.payloads[num_payloads].payload_size = 
sei_size;
+x4->pic.extra_sei.payloads[num_payloads].payload = 
sei_data;
+x4->pic.extra_sei.payloads[num_payloads].payload_type = 4;
+x4->pic.extra_sei.num_payloads++;
+num_payloads++;
 }
 }
 }
@@ -921,6 +959,7 @@ static const AVOption options[] = {
 {"passlogfile", "Filename for 2 pass stats", OFFSET(stats), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
 {"wpredp", "Weighted prediction for P-frames", OFFSET(wpredp), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
 {"a53cc",  "Use A53 Closed Captions (if available)",  
OFFSET(a53_cc),AV_OPT_TYPE_BOOL,   {.i64 = 1}, 0, 1, VE},
+{"afd","Use Active Format Description (AFD) (if 
available)",OFFSET(afd),AV_OPT_TYPE_BOOL,   {.i64 = 1}, 0, 1, VE},
 {"x264opts", "x264 options", OFFSET(x264opts), AV_OPT_TYPE_STRING, 
{.str=NULL}, 0, 0,

[FFmpeg-devel] [PATCH 01/11] libavdevice/decklink: Add support for EIA-708 output over SDI

[Devin Heitmueller]

Hook in libklvanc and use it for output of EIA-708 captions over
SDI.  The bulk of this patch is just general support for ancillary
data for the Decklink SDI module - the real work for construction
of the EIA-708 CDP and VANC line construction is done by libklvanc.

Libklvanc can be found at: https://github.com/stoth68000/libklvanc

Updated to reflect feedback from Marton Balint ,
Carl Eugen Hoyos , and Aaron Levinson
.

Signed-off-by: Devin Heitmueller 
---
 configure   |   4 +
 libavcodec/v210enc.c|   9 ++
 libavdevice/decklink_common.cpp |  16 +++-
 libavdevice/decklink_common.h   |  10 +++
 libavdevice/decklink_enc.cpp| 178 ++--
 5 files changed, 206 insertions(+), 11 deletions(-)

diff --git a/configure b/configure
index 86d81e3..7d59595 100755
--- a/configure
+++ b/configure
@@ -237,6 +237,7 @@ External library support:
   --enable-libiec61883 enable iec61883 via libiec61883 [no]
   --enable-libilbc enable iLBC de/encoding via libilbc [no]
   --enable-libjack enable JACK audio sound server [no]
+  --enable-libklvanc   enable Kernel Labs VANC processing [no]
   --enable-libkvazaar  enable HEVC encoding via libkvazaar [no]
   --enable-libmodplug  enable ModPlug via libmodplug [no]
   --enable-libmp3lame  enable MP3 encoding via libmp3lame [no]
@@ -1608,6 +1609,7 @@ EXTERNAL_LIBRARY_LIST="
 libiec61883
 libilbc
 libjack
+libklvanc
 libkvazaar
 libmodplug
 libmp3lame
@@ -3086,6 +3088,7 @@ decklink_deps_any="libdl LoadLibrary"
 decklink_indev_deps="decklink threads"
 decklink_indev_extralibs="-lstdc++"
 decklink_outdev_deps="decklink threads"
+decklink_outdev_suggest="libklvanc"
 decklink_outdev_extralibs="-lstdc++"
 libndi_newtek_indev_deps="libndi_newtek"
 libndi_newtek_indev_extralibs="-lndi"
@@ -5857,6 +5860,7 @@ enabled libgsm&& { for gsm_hdr in "gsm.h" 
"gsm/gsm.h"; do
check_lib libgsm "${gsm_hdr}" gsm_create 
-lgsm && break;
done || die "ERROR: libgsm not found"; }
 enabled libilbc   && require libilbc ilbc.h WebRtcIlbcfix_InitDecode 
-lilbc $pthreads_extralibs
+enabled libklvanc && require libklvanc libklvanc/vanc.h 
klvanc_context_create -lklvanc
 enabled libkvazaar&& require_pkg_config libkvazaar "kvazaar >= 0.8.1" 
kvazaar.h kvz_api_get
 # While it may appear that require is being used as a pkg-config
 # fallback for libmfx, it is actually being used to detect a different
diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index a6afbbf..b9dcf9a 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -123,6 +123,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 int aligned_width = ((avctx->width + 47) / 48) * 48;
 int stride = aligned_width * 8 / 3;
 int line_padding = stride - ((avctx->width * 8 + 11) / 12) * 4;
+AVFrameSideData *side_data;
 int h, w, ret;
 uint8_t *dst;
 
@@ -233,6 +234,14 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 }
 }
 
+side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_A53_CC);
+if (side_data && side_data->size) {
+uint8_t *buf = av_packet_new_side_data(pkt, AV_PKT_DATA_A53_CC, 
side_data->size);
+if (!buf)
+return AVERROR(ENOMEM);
+memcpy(buf, side_data->data, side_data->size);
+}
+
 pkt->flags |= AV_PKT_FLAG_KEY;
 *got_packet = 1;
 return 0;
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 6ef2c52..c432189 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -254,10 +254,18 @@ int ff_decklink_set_format(AVFormatContext *avctx,
&support, NULL) != S_OK)
 return -1;
 } else {
-if (ctx->dlo->DoesSupportVideoMode(ctx->bmd_mode, bmdFormat8BitYUV,
-   bmdVideoOutputFlagDefault,
-   &support, NULL) != S_OK)
-return -1;
+if (ctx->supports_vanc == 0 || 
ctx->dlo->DoesSupportVideoMode(ctx->bmd_mode, ctx->raw_format,
+  
bmdVideoOutputVANC,
+  
&support, NULL) != S_OK) {
+/* Try without VANC enabled */
+if (ctx->dlo->DoesSupportVideoMode(ctx->bmd_mode, ctx->raw_format,
+   bmdVideoOutputFlagDefault,
+   &support, NULL) != S_OK) {
+return -1;
+}
+ctx->supports_vanc = 0;
+}
+
 }
 if (support == bmdDisplayModeSupported)
 return 0;
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 57ee7d1..143bbb9 100644
--- a/libavdevice/decklink_co

[FFmpeg-devel] [PATCHv4 00/11] Decklink updates

[Devin Heitmueller]

This patch series provides a number of enhancements for both capture
and output using the decklink module, including addressing comments from
Marton Balint, Derek Buitenhuis, James Almer, Carl Eugen Hoyos, and
Aaron Levinson.

Devin Heitmueller (11):
  libavdevice/decklink: Add support for EIA-708 output over SDI
  decklink: Add support for output of Active Format Description (AFD)
  decklink: Introduce support for capture of multiple audio streams
  Preserve AFD side data when going from AVPacket to AVFrame
  Support encoding of Active Format Description (AFD) in libx264
  decklink: Add support for using libklvanc from within capture module
  decklink: Add support for SCTE-104 to decklink capture
  decklink: Add support for compressed AC-3 output over SDI
  decklink: Suppress warning about misuse of struct instead of class
  decklink: log Blackmagic SDK version compiled against
  decklink: Fix compilation of module on OSX

 configure   |   4 +
 doc/indevs.texi |  12 +-
 libavcodec/avcodec.h|   7 +
 libavcodec/codec_desc.c |   6 +
 libavcodec/decode.c |   1 +
 libavcodec/internal.h   |   3 +
 libavcodec/libx264.c|  47 +-
 libavcodec/utils.c  |  36 +
 libavcodec/v210enc.c|  17 +++
 libavdevice/decklink_common.cpp |  43 +-
 libavdevice/decklink_common.h   |  24 ++-
 libavdevice/decklink_common_c.h |   7 +
 libavdevice/decklink_dec.cpp| 331 
 libavdevice/decklink_dec_c.c|   4 +
 libavdevice/decklink_enc.cpp| 320 +++---
 libavdevice/version.h   |   2 +-
 16 files changed, 801 insertions(+), 63 deletions(-)

-- 
1.8.3.1

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

[FFmpeg-devel] [PATCH 06/11] decklink: Add support for using libklvanc from within capture module

[Devin Heitmueller]

Make use of libklvanc from within the DeckLink capture module,
initially for EIA-708 and AFD.  Support for other VANC types will
come in subsequent patches.

Incorporates feedback from Derek Buitenhuis ,
James Almer , and Aaron Levinson 

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

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 6c1ff82..bab3588 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -3,6 +3,7 @@
  * Copyright (c) 2013-2014 Luca Barbato, Deti Fliegl
  * Copyright (c) 2014 Rafaël Carré
  * Copyright (c) 2017 Akamai Technologies, Inc.
+ * Copyright (c) 2017 LTN Global Communications, Inc.
  *
  * This file is part of FFmpeg.
  *
@@ -673,10 +674,123 @@ error:
 return ret;
 }
 
+#if CONFIG_LIBKLVANC
+/* VANC Callbacks */
+struct vanc_cb_ctx {
+AVFormatContext *avctx;
+AVPacket *pkt;
+};
+static int cb_AFD(void *callback_context, struct klvanc_context_s *ctx,
+  struct klvanc_packet_afd_s *pkt)
+{
+struct vanc_cb_ctx *cb_ctx = (struct vanc_cb_ctx *)callback_context;
+uint8_t *afd;
+
+afd = av_packet_new_side_data(cb_ctx->pkt, AV_PKT_DATA_AFD, 1);
+if (afd == NULL) {
+return AVERROR(ENOMEM);
+}
+afd[0] = pkt->hdr.payload[0] >> 3;
+
+return 0;
+}
+
+static int cb_EIA_708B(void *callback_context, struct klvanc_context_s *ctx,
+   struct klvanc_packet_eia_708b_s *pkt)
+{
+struct vanc_cb_ctx *cb_ctx = (struct vanc_cb_ctx *)callback_context;
+decklink_cctx *cctx = (struct decklink_cctx *)cb_ctx->avctx->priv_data;
+struct decklink_ctx *decklink_ctx = (struct decklink_ctx *)cctx->ctx;
+uint16_t expected_cdp;
+uint8_t *cc;
+
+if (!pkt->checksum_valid)
+return 0;
+
+if (!pkt->header.ccdata_present)
+return 0;
+
+expected_cdp = decklink_ctx->cdp_sequence_num + 1;
+decklink_ctx->cdp_sequence_num = pkt->header.cdp_hdr_sequence_cntr;
+if (pkt->header.cdp_hdr_sequence_cntr != expected_cdp) {
+av_log(cb_ctx->avctx, AV_LOG_DEBUG,
+   "CDP counter inconsistent.  Received=0x%04x Expected=%04x\n",
+   pkt->header.cdp_hdr_sequence_cntr, expected_cdp);
+return 0;
+}
+
+cc = av_packet_new_side_data(cb_ctx->pkt, AV_PKT_DATA_A53_CC, 
pkt->ccdata.cc_count * 3);
+if (cc == NULL)
+return AVERROR(ENOMEM);
+
+for (int i = 0; i < pkt->ccdata.cc_count; i++) {
+cc[3*i] = 0xf8 | (pkt->ccdata.cc[i].cc_valid ? 0x04 : 0x00) |
+  (pkt->ccdata.cc[i].cc_type & 0x03);
+cc[3*i+1] = pkt->ccdata.cc[i].cc_data[0];
+cc[3*i+2] = pkt->ccdata.cc[i].cc_data[1];
+}
+
+return 0;
+}
+
+static struct klvanc_callbacks_s callbacks =
+{
+cb_AFD,
+cb_EIA_708B,
+NULL,
+NULL,
+NULL,
+NULL,
+};
+/* End: VANC Callbacks */
+
+/* Take one line of V210 from VANC, colorspace convert and feed it to the
+ * VANC parser. We'll expect our VANC message callbacks to happen on this
+ * same calling thread.
+ */
+static int klvanc_handle_line(AVFormatContext *avctx, struct klvanc_context_s 
*vanc_ctx,
+  unsigned char *buf, unsigned int uiWidth, 
unsigned int lineNr,
+  AVPacket *pkt)
+{
+/* Convert the vanc line from V210 to CrCB422, then vanc parse it */
+
+/* We need two kinds of type pointers into the source vbi buffer */
+/* TODO: What the hell is this, two ptrs? */
+const uint32_t *src = (const uint32_t *)buf;
+
+/* Convert Blackmagic pixel format to nv20.
+ * src pointer gets mangled during conversion, hence we need its own
+ * ptr instead of passing vbiBufferPtr.
+ * decoded_words should be atleast 2 * uiWidth.
+ */
+uint16_t decoded_words[16384];
+
+/* On output each pixel will be decomposed into three 16-bit words (one 
for Y, U, V) */
+memset(&decoded_words[0], 0, sizeof(decoded_words));
+uint16_t *p_anc = decoded_words;
+if (klvanc_v210_line_to_nv20_c(src, p_anc, sizeof(decoded_words), (uiWidth 
/ 6) * 6) < 0)
+return AVERROR(EINVAL);
+
+if (vanc_ctx) {
+struct vanc_cb_ctx cb_ctx = {
+.avctx = avctx,
+.pkt = pkt
+};
+vanc_ctx->callback_context = &cb_ctx;
+int ret = klvanc_packet_parse(vanc_ctx, lineNr, decoded_words, 
sizeof(decoded_words) / (sizeof(uint16_t)));
+if (ret < 0) {
+return AVERROR(EINVAL);
+}
+}
+return 0;
+}
+#endif
+
 HRESULT decklink_input_callback::VideoInputFrameArrived(
 IDeckLinkVideoInputFrame *videoFrame, IDeckLinkAudioInputPacket 
*audioFrame)
 {
 decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
 void *frameBytes;
 void *audioFrameBytes;
 BMDTimeValue frameTime;
@@ -787,10 +901,17 @@ HRESU

[FFmpeg-devel] [PATCH 04/11] Preserve AFD side data when going from AVPacket to AVFrame

[Devin Heitmueller]

This is needed to ensure that AFD data continues to work when
capturing V210 video with the Decklink libavdevice input.

Signed-off-by: Devin Heitmueller 
---
 libavcodec/decode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index f67b214..14660ac 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1667,6 +1667,7 @@ int ff_init_buffer_info(AVCodecContext *avctx, AVFrame 
*frame)
 { AV_PKT_DATA_MASTERING_DISPLAY_METADATA, 
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA },
 { AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
 { AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
+{ AV_PKT_DATA_AFD,AV_FRAME_DATA_AFD },
 };
 
 if (pkt) {
-- 
1.8.3.1

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

[FFmpeg-devel] [PATCH 07/11] decklink: Add support for SCTE-104 to decklink capture

[Devin Heitmueller]

Make use of libklvanc to parse SCTE-104 packets and announce them
as a new stream.  Right now we just pass the payload straight
through, but once this is hooked into libklscte35 we'll be able
to generate SCTE-35 messages in the MPEG TS stream.

Note that this feature needs to be explicitly enabled by the user
through the "-enable_scte_104" option, since we cannot autodetect
the presence of SCTE-104 (because unlike with 708/AFD messages are
not set except when trigger occurs, thus the stream wouldn't get
created during the read_header phase).

Updated to reflect feedback from Derek Buitenhuis 
and Aaron Levinson 

Signed-off-by: Devin Heitmueller 
---
 doc/indevs.texi |  4 +++
 libavcodec/avcodec.h|  1 +
 libavcodec/codec_desc.c |  6 
 libavdevice/decklink_common.h   |  6 
 libavdevice/decklink_common_c.h |  1 +
 libavdevice/decklink_dec.cpp| 61 -
 libavdevice/decklink_dec_c.c|  1 +
 libavdevice/version.h   |  2 +-
 8 files changed, 80 insertions(+), 2 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index 4760d70..63dfbd4 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -323,6 +323,10 @@ Defaults to @samp{1073741824}.
 Sets the audio sample bit depth. Must be @samp{16} or @samp{32}.
 Defaults to @samp{16}.
 
+@item enable_scte_104
+If set to @samp{true}, enables capture of SCTE-104 packets over SDI and
+creation of the corresponding stream at startup.  Defaults to @samp{false}.
+
 @end table
 
 @subsection Examples
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5fa028e..c61b8a1 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -668,6 +668,7 @@ enum AVCodecID {
 AV_CODEC_ID_TTF = 0x18000,
 
 AV_CODEC_ID_SCTE_35, ///< Contain timestamp estimated through PCR of 
program stream.
+AV_CODEC_ID_SCTE_104,
 AV_CODEC_ID_BINTEXT= 0x18800,
 AV_CODEC_ID_XBIN,
 AV_CODEC_ID_IDF,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index c3688de..e198985 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -3103,6 +3103,12 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .name  = "scte_35",
 .long_name = NULL_IF_CONFIG_SMALL("SCTE 35 Message Queue"),
 },
+{
+.id= AV_CODEC_ID_SCTE_104,
+.type  = AVMEDIA_TYPE_DATA,
+.name  = "scte_104",
+.long_name = NULL_IF_CONFIG_SMALL("SCTE 104 Digital Program 
Insertion"),
+},
 
 /* deprecated codec ids */
 };
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index b262780..ffc0d17 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -41,6 +41,10 @@
Actual number for any particular model of card may be lower */
 #define DECKLINK_MAX_AUDIO_CHANNELS 32
 
+/* This isn't actually tied to the Blackmagic hardware - it's an arbitrary
+   number used to size the array of streams */
+#define DECKLINK_MAX_DATA_STREAMS 16
+
 class decklink_output_callback;
 class decklink_input_callback;
 
@@ -92,6 +96,8 @@ struct decklink_ctx {
 unsigned int dropped;
 AVStream *audio_st[DECKLINK_MAX_AUDIO_CHANNELS];
 int num_audio_streams;
+AVStream *data_st[DECKLINK_MAX_DATA_STREAMS];
+int num_data_streams;
 AVStream *video_st;
 AVStream *teletext_st;
 uint16_t cdp_sequence_num;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 3a21bae..3f22094 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -58,6 +58,7 @@ struct decklink_cctx {
 char *format_code;
 int raw_format;
 int64_t queue_size;
+int enable_scte_104;
 };
 
 #endif /* AVDEVICE_DECKLINK_COMMON_C_H */
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index bab3588..1074dc7 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -674,6 +674,30 @@ error:
 return ret;
 }
 
+static int setup_data(AVFormatContext *avctx)
+{
+struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
+AVStream *st;
+
+if (cctx->enable_scte_104) {
+st = avformat_new_stream(avctx, NULL);
+if (!st) {
+av_log(avctx, AV_LOG_ERROR, "Cannot add data stream\n");
+return AVERROR(ENOMEM);
+}
+st->codecpar->codec_type  = AVMEDIA_TYPE_DATA;
+st->time_base.den = ctx->bmd_tb_den;
+st->time_base.num = ctx->bmd_tb_num;
+st->codecpar->codec_id= AV_CODEC_ID_SCTE_104;
+avpriv_set_pts_info(st, 64, 1, 100);  /* 64 bits pts in us */
+ctx->data_st[ctx->num_data_streams] = st;
+ctx->num_data_streams++;
+}
+
+return 0;
+}
+
 #if CONFIG_LIBKLVANC
 /* VANC Callbacks */
 struct vanc_cb_ctx {
@@ -733,12 +757,44 @@ static int cb_EIA_708B(void *callback_context, struct 
klv

[FFmpeg-devel] [PATCH 08/11] decklink: Add support for compressed AC-3 output over SDI

[Devin Heitmueller]

Extend the decklink output to include support for compressed AC-3,
encapsulated using the SMPTE ST 377:2015 standard.

This functionality can be exercised by using the "copy" codec when
the input audio stream is AC-3.  For example:

./ffmpeg -i ~/foo.ts -codec:a copy -f decklink 'UltraStudio Mini Monitor'

Note that the default behavior continues to be to do PCM output,
which means without specifying the copy codec a stream containing
AC-3 will be decoded and downmixed to stereo audio before output.

Updated to reflect feedback from Aaron Levinson 

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

diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index ff60050..c39fc0e 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -237,19 +237,32 @@ static int decklink_setup_audio(AVFormatContext *avctx, 
AVStream *st)
 av_log(avctx, AV_LOG_ERROR, "Only one audio stream is supported!\n");
 return -1;
 }
-if (c->sample_rate != 48000) {
-av_log(avctx, AV_LOG_ERROR, "Unsupported sample rate!"
-   " Only 48kHz is supported.\n");
-return -1;
-}
-if (c->channels != 2 && c->channels != 8 && c->channels != 16) {
-av_log(avctx, AV_LOG_ERROR, "Unsupported number of channels!"
-   " Only 2, 8 or 16 channels are supported.\n");
+
+if (st->codecpar->codec_id == AV_CODEC_ID_AC3) {
+/* Regardless of the number of channels in the codec, we're only
+   using 2 SDI audio channels at 48000Hz */
+ctx->channels = 2;
+} else if (st->codecpar->codec_id == AV_CODEC_ID_PCM_S16LE) {
+if (c->channels != 2 && c->channels != 8 && c->channels != 16) {
+av_log(avctx, AV_LOG_ERROR, "Unsupported number of channels!"
+   " Only 2, 8 or 16 channels are supported.\n");
+return -1;
+}
+if (c->sample_rate != bmdAudioSampleRate48kHz) {
+av_log(avctx, AV_LOG_ERROR, "Unsupported sample rate!"
+   " Only 48kHz is supported.\n");
+return -1;
+}
+ctx->channels = c->channels;
+} else {
+av_log(avctx, AV_LOG_ERROR, "Unsupported codec specified!"
+   " Only PCM_S16LE and AC-3 are supported.\n");
 return -1;
 }
+
 if (ctx->dlo->EnableAudioOutput(bmdAudioSampleRate48kHz,
 bmdAudioSampleType16bitInteger,
-c->channels,
+ctx->channels,
 bmdAudioOutputStreamTimestamped) != S_OK) {
 av_log(avctx, AV_LOG_ERROR, "Could not enable audio output!\n");
 return -1;
@@ -260,8 +273,7 @@ static int decklink_setup_audio(AVFormatContext *avctx, 
AVStream *st)
 }
 
 /* The device expects the sample rate to be fixed. */
-avpriv_set_pts_info(st, 64, 1, c->sample_rate);
-ctx->channels = c->channels;
+avpriv_set_pts_info(st, 64, 1, bmdAudioSampleRate48kHz);
 
 ctx->audio = 1;
 
@@ -553,25 +565,83 @@ static int decklink_write_video_packet(AVFormatContext 
*avctx, AVPacket *pkt)
 return 0;
 }
 
+static int create_s337_payload(AVPacket *pkt, enum AVCodecID codec_id, uint8_t 
**outbuf, int *outsize)
+{
+uint8_t *s337_payload;
+uint8_t *s337_payload_start;
+int payload_size = (pkt->size + 4) * sizeof(uint16_t);
+int i;
+
+/* Encapsulate AC3 syncframe into SMPTE 337 packet */
+s337_payload = (uint8_t *) av_mallocz(payload_size);
+if (s337_payload == NULL)
+return AVERROR(ENOMEM);
+
+/* Construct SMPTE S337 Burst preamble */
+s337_payload[0] = 0x72; /* Sync Word 1 */
+s337_payload[1] = 0xf8; /* Sync Word 1 */
+s337_payload[2] = 0x1f; /* Sync Word 1 */
+s337_payload[3] = 0x4e; /* Sync Word 1 */
+
+if (codec_id == AV_CODEC_ID_AC3) {
+s337_payload[4] = 0x01;
+} else {
+av_free(s337_payload);
+return AVERROR(EINVAL);
+}
+
+s337_payload[5] = 0x00;
+uint16_t bitcount = pkt->size * 8;
+s337_payload[6] = bitcount & 0xff; /* Length code */
+s337_payload[7] = bitcount >> 8; /* Length code */
+s337_payload_start = &s337_payload[8];
+for (i = 0; i < pkt->size; i += 2) {
+s337_payload_start[0] = pkt->data[i+1];
+s337_payload_start[1] = pkt->data[i];
+s337_payload_start += 2;
+}
+
+*outbuf = s337_payload;
+*outsize = payload_size;
+return 0;
+}
+
 static int decklink_write_audio_packet(AVFormatContext *avctx, AVPacket *pkt)
 {
 struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
 struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
-int sample_count = pkt->size / (ctx->channels << 1);
+AVStream *st = avctx->streams[pkt->stream_index];
+int sample_count;
 buffercount_type buffered;
+  

[FFmpeg-devel] [PATCH 09/11] decklink: Suppress warning about misuse of struct instead of class

[Devin Heitmueller]

When building with Clang, the following warning is shown:

warning: struct 'IDeckLinkVideoFrame' was previously declared as a
class [-Wmismatched-tags]

The function incorrectly casts IDeckLinkVideoFrame as a struct
instead of a class pointer.

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

diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index c39fc0e..5e4cf8a 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -530,7 +530,7 @@ static int decklink_write_video_packet(AVFormatContext 
*avctx, AVPacket *pkt)
 pthread_mutex_unlock(&ctx->mutex);
 
 /* Schedule frame for playback. */
-hr = ctx->dlo->ScheduleVideoFrame((struct IDeckLinkVideoFrame *) frame,
+hr = ctx->dlo->ScheduleVideoFrame((class IDeckLinkVideoFrame *) frame,
   pkt->pts * ctx->bmd_tb_num,
   ctx->bmd_tb_num, ctx->bmd_tb_den);
 /* Pass ownership to DeckLink, or release on failure */
-- 
1.8.3.1

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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Increase support for common encryption.

[Carl Eugen Hoyos]

2018-01-08 23:16 GMT+01:00 Jacob Trimble :
>> You can't remove API just like that without a deprecation period.
>> Add a new av_aes_ctr_set_full_iv() function, and either leave
>> av_aes_ctr_set_iv() alone or deprecate it if it effectively becomes
>> superfluous after adding the new function.
>>
>> Also, this patch needs to be split in three. One for the aes_crt
>> changes, one for the encryption_info changes, and one for mov changes,
>> with a minor libavutil version bump for the former two, and the
>> corresponding APIChanges entry.
>> Alternatively, you could also squash the new encryption_info API from
>> this patch into the one that actually introduces the entire feature.
>
> Whoops, I thought that was internal-only.  Done and split into its own change.
>
> On Sat, Jan 6, 2018 at 7:30 AM, Carl Eugen Hoyos  wrote:
>> 2018-01-05 20:49 GMT+01:00 Jacob Trimble :
>>
>>> +if (!frag_stream_info->encryption_index) {
>>> +frag_stream_info->encryption_index = 
>>> av_mallocz(sizeof(MOVEncryptionIndex));
>>
>> sizeof(variable), please.

Do you disagree?
I have no strong opinion, but I thought it makes the code more robust...

>> [...]
>>
>>> +sample_count = avio_rb32(pb);
>>> +
>>> +encryption_index->encrypted_samples =
>>> av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);
>>
>> This should be avoided if possible, see below.
>>
>>> +if (!encryption_index->encrypted_samples) {
>>>  return AVERROR(ENOMEM);
>>>  }
>>> +encryption_index->nb_encrypted_samples = sample_count;
>>>
>>> -return av_aes_ctr_init(sc->cenc.aes_ctr, c->decryption_key);
>>> +for (i = 0; i < sample_count; i++) {
>>
>> Please check here for eof...
>>
>>> +ret = mov_read_sample_encryption_info(c, pb, sc,
>>> &encryption_index->encrypted_samples[i], use_subsamples);
>>
>> ... and insert a realloc here to avoid the large allocation above, see 
>> 1112ba01.
>
> Done.

> +if (use_subsamples) {
> +subsample_count = avio_rb16(pb);
> +for (i = 0; i < subsample_count && !pb->eof_reached; i++) {
> +unsigned int min_subsamples = FFMIN(FFMAX(i, 1024 * 1024), 
> subsample_count);
> +subsamples = av_fast_realloc((*sample)->subsamples, &alloc_size,
> + min_subsamples * 
> sizeof(*subsamples));

The reason I did not comment on this block in the last mail is that
iiuc, the maximum allocation here is INT16_MAX * 8 which seems
acceptable (and there cannot be a realloc with the chosen initial
limit).

> +sample_count = avio_rb32(pb);

You have to check here...

+for (i = 0; i < sample_count && !pb->eof_reached; i++) {
+unsigned int min_samples = FFMIN(FFMAX(i, 1024 * 1024), sample_count);
+encrypted_samples =
av_fast_realloc(encryption_index->encrypted_samples, &alloc_size,

+min_samples *
sizeof(*encrypted_samples));

... if this product could overflow for the final reallocation, see 1112ba01.

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

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Aurelien Jacobs]

On Mon, Jan 08, 2018 at 12:38:19AM +, Rostislav Pehlivanov wrote:
> On 7 January 2018 at 22:54, Aurelien Jacobs  wrote:
> 
> > On Sun, Jan 07, 2018 at 05:23:24PM +, Rostislav Pehlivanov wrote:
> > > On 6 January 2018 at 16:48, Aurelien Jacobs  wrote:
> > >
> > > > ---
> > > >  Changelog   |   2 +-
> > > >  configure   |   2 +
> > > >  libavcodec/Makefile |   2 +
> > > >  libavcodec/allcodecs.c  |   1 +
> > > >  libavcodec/aptx.c   | 352 ++
> > > > ++
> > > >  libavcodec/avcodec.h|   1 +
> > > >  libavcodec/codec_desc.c |   7 +
> > > >  7 files changed, 339 insertions(+), 28 deletions(-)
> > >
> > >
> > > No, don't add a new codec ID for what is very obviously a profile.
> > >
> [...]
> > Anyway, I do understand how I could use a profile instead of a new codec
> > ID, but I really don't understand what advantage it would bring ?
> >
> > For a codec known with one name, but supporting a lot of different
> > profiles with flags in the bitstream so that the decoder can adapt
> > itself to any profile, that makes a lot of sense. But for aptX and
> > aptX HD it doesn't make any sense to me.
> >
> 
> It makes sense - HD is just a flavor of aptx. You can't call this a brand
> new codec - it just changes some tables and the way codewords are written
> (1 function).

Of course it does make sense to us, the few people who are touching
codecs source code, that they are both flavors of the same code.

> The only people who would call that brand new are in
> marketing and they're wrong.

Of course calling aptX and aptX HD different codecs is pretty much
marketting bullshit.

But that's not the point here.
We are not talking about some internal implementation details.
We are talking about ffmpeg's end user interface. So what we do
has to make sense to end user. And end users "knows very well" that
aptX and aptX HD are 2 different codecs (they are used for exemple
to install 2 differents libs on android to support both).

> > I don't think it would make the code simpler.
> > The decoder itself has no flag in the bitstream to adapt to the correct
> > "profile".
> >
> And I think it would be confusing for end user. aptX HD is publicly know
> > as a different codec than aptX. A user looking at the list of supported
> > codec would probably conclude that aptX is supported but not aptX HD.
> >
> > Also, the closest thing I can think as a standard container for aptX
> > is the bluetooth A2DP protocol. And in this protocol, aptX and aptX HD
> > are differentiated with a different codec ID, just the same way they
> > are differentiated from SBC or LDAC.
> >
> > So in the end, using different codec ID seems pretty natural, while
> > using different profiles seems akward and doesn't seem to bring any
> > advantage.
> >
> > Can you give any technical reason why think using profile would be
> > better ?
> >
> 
> Yes, a big one - we don't bloat the already humongous API. You might say:
> "Well, we have hundreds of codec IDs, what's one more?". If we had a new
> codec ID for every flavor of every codec, we'd have thousands.

So what ? It won't increase binary bloat unless we ever reach more
than 2^32 codecs.
And regarding public API bloat, the 2 options are:
 1) define 2 codec ID consts
 2) define 1 codec ID const and 2 profile consts
Which one is bloating the public API more ?

> The profile systems allows us to discern between actually marketed variants
> of one codec with the same name, for example AAC-LC with AAC-LTP.

Do you really think that AAC-LTP is marketed as a unique codec to end
users ? I've never stumbled on this.

Anyway, all this discussion is moot as Hendrik pointed out that profile
can't be set outside of lavc to determine a decoder behavior.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avformat/mov: Expose encryption info to the app.

[Carl Eugen Hoyos]

2018-01-09 0:22 GMT+01:00 Jacob Trimble :

> Updated with the new design for the side data and applied the realloc
> fix to avoid large allocations.

> +kid_count = avio_rb32(pb);

Missing check here ...

> +for (; i < kid_count && !pb->eof_reached; i++) {
> +unsigned int min_kid_count = FFMIN(FFMAX(i, 1024), kid_count);
> +key_ids = av_fast_realloc(info->key_ids, &alloc_size,

> +  min_kid_count * sizeof(*key_ids));

... for an overflow here.

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

Re: [FFmpeg-devel] [PATCH 4/4] avformat/libopenmpt: Probe file format from file data if possible

[Carl Eugen Hoyos]

2018-01-08 20:25 GMT+01:00 Jörn Heusipp :
>
> On 01/08/2018 12:57 AM, Carl Eugen Hoyos wrote:
>>
>> 2018-01-07 15:40 GMT+01:00 Jörn Heusipp
>> :
>>>
>>> On 01/06/2018 04:10 PM, Carl Eugen Hoyos wrote:

 2018-01-06 11:07 GMT+01:00 Jörn Heusipp
 :
>
>
>
> 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.


 You could also test tools/probetest
>>>
>>>
>>> I was not aware of that tool. Thanks for the suggestion.
>>>
>>> It currently lists a failure related to libopenmpt:
>>> Failure of libopenmpt probing code with score=76 type=0 p=FDC size=1024
>>
>>
>> I did not look at this closely but I suspect libopenmpt should return a
>> smaller score in this case.
>
>
> We (libopenmpt developers) are currently considering making the heuristic
> for M15 files even stricter. The changes will land in libopenmpt 0.3.5.
> libopenmpt 0.3.5 versus 0.3.4 or earlier can be distinguished at runtime via
> openmpt_get_library_version(). I would be fine with only doing probing via
> libopenmpt in FFmpeg starting with libopenmt 0.3.5 and relying on file
> extensions for earlier versions.
>
> However, the data that tools/probetest.c generates here fundamentally does
> have a somewhat high probability of looking like a completely legit M15
> file. False positives are not really avoidable completely no matter what
> libopenmpt does here. The failing data is synthetic, and I am not seeing any
> M15 false positives at all on real-world file collections (media and
> non-media files (tested on 1.2 million data and system files)).
>
>> A solution could be to never return a high value for the FFmpeg
>> probe function.
>
>
> Maybe, but given what tools/probetest generates here, I somewhat doubt these
> examples have any real-world implication at all.
> Anyway, in case a lower score is deemed to be useful, do you have any
> suggestions which score I should pick? AVPROBE_SCORE_EXTENSION or less would
> probably not be very useful, so what comes to mind for me is
> AVPROBE_SCORE_EXTENSION+1 (51).

No real suggestion here, above was just an idea.

>>> Looking at tools/probetest.c, that would be a file with very few bits
>>> set.
>>> libopenmpt detects the random data in question as M15 .MOD files
>>> (original
>>> Amiga 15 samples .mod files), and there is sadly not much that can be
>>> done
>>> about that. There are perfectly valid real-world M15 .MOD files with only
>>> 73
>>> bits set in the first 600 bytes (untouchables-station.mod,
>>>
>>> ).
>>> The following up to 64*4*4*63 bytes could even be completely 0 (empty
>>> pattern data) for valid files (even without the file being totally
>>> silent).
>>> The generated random data that tools/probetest complains about here
>>> contains
>>> 46 bits set to 1 in the first 600 bytes. What follows are various other
>>> examples with up to 96 bits set to 1. Completely loading a file like that
>>> would very likely reject it (in particular, libopenmpt can deduce the
>>> expected file size from the sample headers and, with some slack to
>>> account
>>> for corrupted real-world examples, reject files with non-matching size),
>>> however, that is not possible when only probing the file header.
>>> The libopenmpt API allows for the file header probing functions to return
>>> false-positives, however false-negatives are not allowed.
>>>
>>> Performance numbers shown by tools/probetest are what I had expected
>>> (measured on an AMD A4-5000, during normal Xorg session (i.e. not 100%
>>> idle)):
>>>
>
> [...]
>
>>> 109589637233 cycles,   libopenmpt
>>
>>
>> This sadly may not be acceptable, others may want to comment.
>>
>>>2672917981   libopenmpt (per module format)
>>>
>>> At first glance, libopenmpt looks huge here in comparison. However one
>>> should consider that libopenmpt internally has to probe for (currently)
>>> 41
>>> different module file formats, going through 41 separate probing
>>> functions
>>> internally.
>>>
>>> Dividing 109589637233 by 41 gives 2672917981, which is in the ballpark of
>>> all other probing functions in ffmpeg.
>
>
> What are your expectations for probing speed of 41 completely distinct file
> formats?

My only expectation is that other FFmpeg developers comment, a
(imo strong) argument in your favour is that this will only apply if
an optional external library is activated at compile-time.

> Even only h261,h263,h264,hevc,aac,ac3 (raw streams) combined take more time
> than libopenmpt takes for its 41 formats together.

It is otoh imo not a useful argument to compare four of the most
common formats (we have to auto-detect them for mpeg-ts
recordings) to libopenmpt;-)

> All other FFmpeg probing functions combined (234 formats) take 1201426924609
> cycles. libopenmpt adds 109589637233 cycles for 41 different file formats to
> that, which i

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.

[Carl Eugen Hoyos]

2018-01-08 23:34 GMT+01:00 Jacob Trimble :
> On Fri, Jan 5, 2018 at 3:41 PM, Carl Eugen Hoyos  wrote:
>> 2018-01-05 23:58 GMT+01:00 Jacob Trimble :
>>> On Fri, Jan 5, 2018 at 2:01 PM, Carl Eugen Hoyos  wrote:
 2018-01-05 22:29 GMT+01:00 Jacob Trimble 
 :
> On Fri, Jan 5, 2018 at 12:41 PM, Carl Eugen Hoyos  
> wrote:
>> 2018-01-05 20:49 GMT+01:00 Jacob Trimble 
>> :
>>
>>> +entry_count = avio_rb32(pb);
>>> +encryption_index->auxiliary_offsets = 
>>> av_malloc_array(sizeof(size_t), entry_count);
>>
>> (sizeof(variable) instead of sizeof(type), please.)
>>
>> But since this could be used for a dos attack, please change this
>> to something similar to 1112ba01.
>> If it is easy to avoid it, very short files should not allocate
>> gigabytes.
>
> Switched to calculating the size based on the number of remaining
> bytes and returning an error if it doesn't match what is read.

 Sorry if I miss something:

> +entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version 
> == 0 ? 4 : 8);
> +if (avio_rb32(pb) != entry_count) {
> +av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
> +return AVERROR_INVALIDDATA;
> +}
> +encryption_index->auxiliary_offsets =
> +av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), 
> entry_count);

 Does this avoid a 1G allocation for a file of a few bytes?

 Didn't you simply increase the number of needed bytes to change in a valid
 mov file to behave maliciously from one to two?
>>>
>>> From what I can tell, the mov_read_default method (which is what reads
>>> child atoms) will verify "atom.size" to fit inside the parent atom.
>>> This means that for "atom.size" to be excessively large for the file
>>> size, the input would need to be non-seekable (since I think the
>>> top-level atom uses the file size) and all the atoms would need to
>>> have invalid sizes.
>>
>> (I did not check this but I am not convinced the sample I fixed last
>> week is so sophisticated.)
>>
>>> But technically I guess it is possible.
>>
>> Thank you.
>>
>>> But this is basically malloc some number of bytes then read that many
>>> bytes.  The only alternative I can think of (in the face of
>>> non-seekable inputs) is to try-read in chunks until we hit EOF or the
>>> end of the expected size.  This seems like a lot of extra work that is
>>
>>> not mirrored elsewhere.
>>
>> On the contrary.
>>
>> But you are right, I forgot to write that you have to add an "if (!eof)"
>> to the reading loops, see the function that above commit changed.
>>
>>> There are several cases where this isn't explicitly checked.
>>
>> Yes, and they will be fixed, please don't add another one.
>>
>>> Also, how does this attack work?  If the number is way too big, well
>>> get EOM and error out.
>>
>> Which not only causes dos but also makes checking for other (if you
>> like: more dangerous) issues more difficult which is bad. We already
>> know that there are cases where the issue is hard to avoid, I believe
>> this is not such a case.
>>
>> It is possible to create (valid) samples that allocate a huge amount
>> of memory but very small files should not immediately allocate an
>> amount of several G.
>
> Done.

+entry_count = avio_rb32(pb);

This has to be checked for later overflow, same in other spots.

+encryption_index->auxiliary_offsets =
+av_malloc_array(sizeof(*encryption_index->auxiliary_offsets),
entry_count);

I believe you forgot to remove these two lines.

Note that I chose "1024*1024" arbitrarily to avoid a speed-loss for
(most likely) all valid files when fixing the dos in 1112ba01.
I don't know what a good lower limit for your use-case can be, or
if only using av_fast_realloc() - without the high starting value -
makes sense.

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

[FFmpeg-devel] [PATCH 10/11] decklink: log Blackmagic SDK version compiled against

[Devin Heitmueller]

Add a line to show the SDK version used in the build, if loglevel
is set to verbose.  This is simply to aid in debugging when
building against different SDKs.

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

diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index e7daa63..b033e63 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -448,6 +448,10 @@ int ff_decklink_init_device(AVFormatContext *avctx, const 
char* name)
 IDeckLink *dl = NULL;
 int64_t maxAudioChannels;
 IDeckLinkIterator *iter = CreateDeckLinkIteratorInstance();
+
+av_log(avctx, AV_LOG_VERBOSE, "Using BlackMagic SDK version %s\n",
+   BLACKMAGIC_DECKLINK_API_VERSION_STRING);
+
 if (!iter) {
 av_log(avctx, AV_LOG_ERROR, "Could not create DeckLink iterator\n");
 return AVERROR_EXTERNAL;
-- 
1.8.3.1

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

[FFmpeg-devel] [PATCH 11/11] decklink: Fix compilation of module on OSX

[Devin Heitmueller]

Clang applies the missing-prototypes warning on C++ files, whereas
gcc only applies it to C.  As a result, the decklink_common.cpp file
fails to build because of missing prototypes in DecklinkDispatch.cpp
(which is #included by decklink_common.cpp).

We don't want to change the actual Blackmagic SDK sources, so
suppress the warning just for that one #include.

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

diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index b033e63..c0b3c93 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -29,7 +29,18 @@ extern "C" {
 #ifdef _WIN32
 #include 
 #else
+/* The file provided by the SDK is known to be missing prototypes, which 
doesn't
+   cause issues with GCC since the warning doesn't apply to C++ files.  However
+   Clang does complain (and warnings are treated as errors), so suppress the
+   warning just for this one file */
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wmissing-prototypes"
+#endif
 #include 
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 #endif
 
 extern "C" {
-- 
1.8.3.1

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

[FFmpeg-devel] [PATCH] avfilter/vf_overlay: add comment into eval_expr

[Steven Liu]

comment about the looks like a duplicate line.
but that is used to reason x is expressed from y

Signed-off-by: Steven Liu 
---
 libavfilter/vf_overlay.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index aa5835ae3a..c6a6ac82f3 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -149,6 +149,7 @@ static void eval_expr(AVFilterContext *ctx)
 
 s->var_values[VAR_X] = av_expr_eval(s->x_pexpr, s->var_values, NULL);
 s->var_values[VAR_Y] = av_expr_eval(s->y_pexpr, s->var_values, NULL);
+/* It is necessary if x is expressed from y  */
 s->var_values[VAR_X] = av_expr_eval(s->x_pexpr, s->var_values, NULL);
 s->x = normalize_xy(s->var_values[VAR_X], s->hsub);
 s->y = normalize_xy(s->var_values[VAR_Y], s->vsub);
-- 
2.14.3 (Apple Git-98)



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

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Rostislav Pehlivanov]

On 9 January 2018 at 01:21, Aurelien Jacobs  wrote:

> On Mon, Jan 08, 2018 at 12:38:19AM +, Rostislav Pehlivanov wrote:
> > On 7 January 2018 at 22:54, Aurelien Jacobs  wrote:
> >
> > > On Sun, Jan 07, 2018 at 05:23:24PM +, Rostislav Pehlivanov wrote:
> > > > On 6 January 2018 at 16:48, Aurelien Jacobs 
> wrote:
> > > >
> > > > > ---
> > > > >  Changelog   |   2 +-
> > > > >  configure   |   2 +
> > > > >  libavcodec/Makefile |   2 +
> > > > >  libavcodec/allcodecs.c  |   1 +
> > > > >  libavcodec/aptx.c   | 352 ++
> > > > > ++
> > > > >  libavcodec/avcodec.h|   1 +
> > > > >  libavcodec/codec_desc.c |   7 +
> > > > >  7 files changed, 339 insertions(+), 28 deletions(-)
> > > >
> > > >
> > > > No, don't add a new codec ID for what is very obviously a profile.
> > > >
> > [...]
> > > Anyway, I do understand how I could use a profile instead of a new
> codec
> > > ID, but I really don't understand what advantage it would bring ?
> > >
> > > For a codec known with one name, but supporting a lot of different
> > > profiles with flags in the bitstream so that the decoder can adapt
> > > itself to any profile, that makes a lot of sense. But for aptX and
> > > aptX HD it doesn't make any sense to me.
> > >
> >
> > It makes sense - HD is just a flavor of aptx. You can't call this a brand
> > new codec - it just changes some tables and the way codewords are written
> > (1 function).
>
> Of course it does make sense to us, the few people who are touching
> codecs source code, that they are both flavors of the same code.
>

> > The only people who would call that brand new are in
> > marketing and they're wrong.
>
> Of course calling aptX and aptX HD different codecs is pretty much
> marketting bullshit.
>

> But that's not the point here.
> We are not talking about some internal implementation details.
> We are talking about ffmpeg's end user interface. So what we do
> has to make sense to end user. And end users "knows very well" that
> aptX and aptX HD are 2 different codecs (they are used for exemple
> to install 2 differents libs on android to support both).
>
>
They're not 2 different codecs, regardless of what is being said. The
similarities are unquestionable. You even said it yourself. Now you're just
bikeshedding because you've already done the patches one way and you don't
want to change them to something new and unfamiliar.



> > > I don't think it would make the code simpler.
> > > The decoder itself has no flag in the bitstream to adapt to the correct
> > > "profile".
> > >
> > And I think it would be confusing for end user. aptX HD is publicly know
> > > as a different codec than aptX. A user looking at the list of supported
> > > codec would probably conclude that aptX is supported but not aptX HD.
> > >
> > > Also, the closest thing I can think as a standard container for aptX
> > > is the bluetooth A2DP protocol. And in this protocol, aptX and aptX HD
> > > are differentiated with a different codec ID, just the same way they
> > > are differentiated from SBC or LDAC.
> > >
> > > So in the end, using different codec ID seems pretty natural, while
> > > using different profiles seems akward and doesn't seem to bring any
> > > advantage.
> > >
> > > Can you give any technical reason why think using profile would be
> > > better ?
> > >
> >
> > Yes, a big one - we don't bloat the already humongous API. You might say:
> > "Well, we have hundreds of codec IDs, what's one more?". If we had a new
> > codec ID for every flavor of every codec, we'd have thousands.
>
> So what ? It won't increase binary bloat unless we ever reach more
> than 2^32 codecs.
> And regarding public API bloat, the 2 options are:
>  1) define 2 codec ID consts
>  2) define 1 codec ID const and 2 profile consts
> Which one is bloating the public API more ?
>

The first one.



>
> > The profile systems allows us to discern between actually marketed
> variants
> > of one codec with the same name, for example AAC-LC with AAC-LTP.
>
> Do you really think that AAC-LTP is marketed as a unique codec to end
> users ? I've never stumbled on this.
>

I absolutely do not. Hence I don't see aptx HD being marketed as a unique
codec.



> Anyway, all this discussion is moot as Hendrik pointed out that profile
> can't be set outside of lavc to determine a decoder behavior.
>

What, based on a comment in lavc? Comments there describe the api but they
rarely define it. We're free to adjust them if need be and in this case,
since the codec profile may not be set, the API user is forced to deal with
the lack of such set. Hence, we can clarify that it may be set by lavf as
well as lavc as well as not being set at all. And the decoder may use it.
I maintain that adding a new codec ID for this is unacceptable.


You can keep refusing to change the patches and maintain that they're
separate codecs. However other people who see things the other way are also
free to tak

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Carl Eugen Hoyos]

2018-01-09 5:07 GMT+01:00 Rostislav Pehlivanov :
> On 9 January 2018 at 01:21, Aurelien Jacobs  wrote:

>> So what ? It won't increase binary bloat unless we ever reach more
>> than 2^32 codecs.
>> And regarding public API bloat, the 2 options are:
>>  1) define 2 codec ID consts
>>  2) define 1 codec ID const and 2 profile consts
>> Which one is bloating the public API more ?
>
> The first one.

No?

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

[FFmpeg-devel] [PATCH 1/2] avformat/http: add referer option into http

[Steven Liu]

add Referer message if referer have been set.

Signed-off-by: Steven Liu 
---
 doc/protocols.texi | 3 +++
 libavformat/http.c | 8 
 2 files changed, 11 insertions(+)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index 98deb73005..c24dc74505 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -296,6 +296,9 @@ Use persistent connections if set to 1, default is 0.
 @item post_data
 Set custom HTTP post data.
 
+@item referer
+Set the Referer header. Include 'Referer: URL' header in HTTP request.
+
 @item user_agent
 Override the User-Agent header. If not specified the protocol will use a
 string describing the libavformat build. ("Lavf/")
diff --git a/libavformat/http.c b/libavformat/http.c
index 4806b1e59b..86ee23de6d 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -76,6 +76,7 @@ typedef struct HTTPContext {
 char *mime_type;
 char *http_version;
 char *user_agent;
+char *referer;
 #if FF_API_HTTP_USER_AGENT
 char *user_agent_deprecated;
 #endif
@@ -138,6 +139,7 @@ static const AVOption options[] = {
 { "headers", "set custom HTTP headers, can override built in default 
headers", OFFSET(headers), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D | E },
 { "content_type", "set a specific content type for the POST messages", 
OFFSET(content_type), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D | E },
 { "user_agent", "override User-Agent header", OFFSET(user_agent), 
AV_OPT_TYPE_STRING, { .str = DEFAULT_USER_AGENT }, 0, 0, D },
+{ "referer", "override referer header", OFFSET(referer), 
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D },
 #if FF_API_HTTP_USER_AGENT
 { "user-agent", "override User-Agent header", 
OFFSET(user_agent_deprecated), AV_OPT_TYPE_STRING, { .str = DEFAULT_USER_AGENT 
}, 0, 0, D },
 #endif
@@ -1197,6 +1199,12 @@ static int http_connect(URLContext *h, const char *path, 
const char *local_path,
 if (!has_header(s->headers, "\r\nUser-Agent: "))
 len += av_strlcatf(headers + len, sizeof(headers) - len,
"User-Agent: %s\r\n", s->user_agent);
+if (s->referer) {
+/* set default headers if needed */
+if (!has_header(s->headers, "\r\nReferer: "))
+len += av_strlcatf(headers + len, sizeof(headers) - len,
+   "Referer: %s\r\n", s->referer);
+}
 if (!has_header(s->headers, "\r\nAccept: "))
 len += av_strlcpy(headers + len, "Accept: */*\r\n",
   sizeof(headers) - len);
-- 
2.14.3 (Apple Git-98)



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

[FFmpeg-devel] [PATCH 2/2] avformat/hls: store referer message in HLS http request

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/hls.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 950cc4c3bd..9657b83fd9 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -202,6 +202,7 @@ typedef struct HLSContext {
 int64_t first_timestamp;
 int64_t cur_timestamp;
 AVIOInterruptCB *interrupt_callback;
+char *referer;   ///< holds HTTP referer set as an 
AVOption to the HTTP protocol context
 char *user_agent;///< holds HTTP user agent set as an 
AVOption to the HTTP protocol context
 char *cookies;   ///< holds HTTP cookie values set in 
either the initial response or as an AVOption to the HTTP protocol context
 char *headers;   ///< holds HTTP headers set as an 
AVOption to the HTTP protocol context
@@ -1179,6 +1180,7 @@ static int open_input(HLSContext *c, struct playlist 
*pls, struct segment *seg,
 
 // broker prior HTTP options that should be consistent across requests
 av_dict_set(&opts, "user_agent", c->user_agent, 0);
+av_dict_set(&opts, "referer", c->referer, 0);
 av_dict_set(&opts, "cookies", c->cookies, 0);
 av_dict_set(&opts, "headers", c->headers, 0);
 av_dict_set(&opts, "http_proxy", c->http_proxy, 0);
@@ -1652,7 +1654,7 @@ static int save_avio_options(AVFormatContext *s)
 {
 HLSContext *c = s->priv_data;
 static const char * const opts[] = {
-"headers", "http_proxy", "user_agent", "user-agent", "cookies", NULL };
+"headers", "http_proxy", "user_agent", "user-agent", "cookies", 
"referer", NULL };
 const char * const * opt = opts;
 uint8_t *buf;
 int ret = 0;
-- 
2.14.3 (Apple Git-98)



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