[FFmpeg-devel] lavf : scale_vaapi : add denoise/sharpless support
From 78421d6b3a4da21dc1e7793777946cf057fc6cfe Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Tue, 30 Aug 2016 14:36:00 +0800
Subject: [PATCH] lavf : scale_vaapi : add denoise/sharpless support.
add denoise/sharpless support, used scope [-1, 100] as the input
scope.
Signed-off-by: Jun Zhao
---
libavfilter/vf_scale_vaapi.c | 115 +++
1 file changed, 115 insertions(+)
diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
index 8dd5acf..06bb128 100644
--- a/libavfilter/vf_scale_vaapi.c
+++ b/libavfilter/vf_scale_vaapi.c
@@ -53,6 +53,16 @@ typedef struct ScaleVAAPIContext {
int output_width;
int output_height;
+VAProcFilterCap denoise_caps;
+int support_denoise;
+int denoise; // enable denoise algo. level is the optional
+ // value from the interval [-1, 100], -1 means
disabled
+
+VAProcFilterCap sharpless_caps;
+int support_sharpless;
+int sharpless; // enable sharpless. level is the optional value
+ // from the interval [-1, 100], -1 means disabled
+
} ScaleVAAPIContext;
@@ -117,6 +127,8 @@ static int scale_vaapi_config_output(AVFilterLink *outlink)
AVVAAPIFramesContext *va_frames;
VAStatus vas;
int err, i;
+unsigned int num_denoise_caps = 1;
+unsigned int num_sharpless_caps = 1;
scale_vaapi_pipeline_uninit(ctx);
@@ -225,6 +237,29 @@ static int scale_vaapi_config_output(AVFilterLink *outlink)
goto fail;
}
+vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterNoiseReduction,
+ &ctx->denoise_caps, &num_denoise_caps);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_WARNING, "Failed to query denoise caps "
+ "context: %d (%s).\n", vas, vaErrorStr(vas));
+ctx->support_denoise = -1;
+} else {
+ctx->support_denoise = 1;
+}
+
+vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterSharpening,
+ &ctx->sharpless_caps,
&num_sharpless_caps);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_WARNING, "Failed to query sharpless caps "
+ "context: %d (%s).\n", vas, vaErrorStr(vas));
+ctx->support_sharpless = -1;
+} else {
+ctx->support_sharpless = 1;
+}
+
+
av_freep(&hwconfig);
av_hwframe_constraints_free(&constraints);
return 0;
@@ -250,6 +285,14 @@ static int vaapi_proc_colour_standard(enum AVColorSpace
av_cs)
}
}
+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 scale_vaapi_filter_frame(AVFilterLink *inlink, AVFrame *input_frame)
{
AVFilterContext *avctx = inlink->dst;
@@ -259,6 +302,10 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink,
AVFrame *input_frame)
VASurfaceID input_surface, output_surface;
VAProcPipelineParameterBuffer params;
VABufferID params_id;
+VABufferID denoise_id;
+VABufferID sharpless_id;
+VABufferID filter_bufs[8];
+int num_filter_bufs = 0;
VAStatus vas;
int err;
@@ -290,6 +337,43 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink,
AVFrame *input_frame)
av_log(ctx, AV_LOG_DEBUG, "Using surface %#x for scale output.\n",
output_surface);
+if (ctx->denoise != -1 && ctx->support_denoise) {
+VAProcFilterParameterBuffer denoise;
+denoise.type = VAProcFilterNoiseReduction;
+denoise.value = map_to_range(ctx->denoise, 0, 100,
+ ctx->denoise_caps.range.min_value,
+ ctx->denoise_caps.range.max_value);
+vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterParameterBufferType, sizeof(denoise), 1,
+ &denoise, &denoise_id);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_ERROR, "Failed to create denoise parameter
buffer: "
+ "%d (%s).\n", vas, vaErrorStr(vas));
+err = AVERROR(EIO);
+goto fail;
+}
+filter_bufs[num_filter_bufs++] = denoise_id;
+}
+
+if (ctx->sharpless != -1 && ctx->support_sharpless) {
+VAProcFilterParameterBuffer sharpless;
+sharpless.type = VAProcFilterSharpening;
+sharpless.value = map_to_range(ctx->sharpless,
+ ctx->sharpless_caps.range.min_value,
+ ctx->sharpless_caps.range.max_value,
+ 0, 100);
+vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterPa
[FFmpeg-devel] [PATCH v2] lavf : scale_vaapi : add denoise/sharpless support
From 1d2d7e0671027948644e08ca79853cc40b0fcf27 Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Tue, 30 Aug 2016 14:36:00 +0800
Subject: [PATCH] lavf : scale_vaapi : add denoise/sharpless support.
add denoise/sharpless support, used scope [-1, 100] as the input
scope.
Signed-off-by: Jun Zhao
---
libavfilter/vf_scale_vaapi.c | 115 +++
1 file changed, 115 insertions(+)
diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
index 8dd5acf..6fb1b39 100644
--- a/libavfilter/vf_scale_vaapi.c
+++ b/libavfilter/vf_scale_vaapi.c
@@ -53,6 +53,16 @@ typedef struct ScaleVAAPIContext {
int output_width;
int output_height;
+VAProcFilterCap denoise_caps;
+int support_denoise;
+int denoise; // enable denoise algo. level is the optional
+ // value from the interval [-1, 100], -1 means
disabled
+
+VAProcFilterCap sharpless_caps;
+int support_sharpless;
+int sharpless; // enable sharpless. level is the optional value
+ // from the interval [-1, 100], -1 means disabled
+
} ScaleVAAPIContext;
@@ -117,6 +127,8 @@ static int scale_vaapi_config_output(AVFilterLink *outlink)
AVVAAPIFramesContext *va_frames;
VAStatus vas;
int err, i;
+unsigned int num_denoise_caps = 1;
+unsigned int num_sharpless_caps = 1;
scale_vaapi_pipeline_uninit(ctx);
@@ -225,6 +237,29 @@ static int scale_vaapi_config_output(AVFilterLink *outlink)
goto fail;
}
+vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterNoiseReduction,
+ &ctx->denoise_caps, &num_denoise_caps);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_WARNING, "Failed to query denoise caps "
+ "context: %d (%s).\n", vas, vaErrorStr(vas));
+ctx->support_denoise = 0;
+} else {
+ctx->support_denoise = 1;
+}
+
+vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterSharpening,
+ &ctx->sharpless_caps,
&num_sharpless_caps);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_WARNING, "Failed to query sharpless caps "
+ "context: %d (%s).\n", vas, vaErrorStr(vas));
+ctx->support_sharpless = 0;
+} else {
+ctx->support_sharpless = 1;
+}
+
+
av_freep(&hwconfig);
av_hwframe_constraints_free(&constraints);
return 0;
@@ -250,6 +285,14 @@ static int vaapi_proc_colour_standard(enum AVColorSpace
av_cs)
}
}
+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 scale_vaapi_filter_frame(AVFilterLink *inlink, AVFrame *input_frame)
{
AVFilterContext *avctx = inlink->dst;
@@ -259,6 +302,10 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink,
AVFrame *input_frame)
VASurfaceID input_surface, output_surface;
VAProcPipelineParameterBuffer params;
VABufferID params_id;
+VABufferID denoise_id;
+VABufferID sharpless_id;
+VABufferID filter_bufs[8];
+int num_filter_bufs = 0;
VAStatus vas;
int err;
@@ -290,6 +337,43 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink,
AVFrame *input_frame)
av_log(ctx, AV_LOG_DEBUG, "Using surface %#x for scale output.\n",
output_surface);
+if (ctx->denoise != -1 && ctx->support_denoise) {
+VAProcFilterParameterBuffer denoise;
+denoise.type = VAProcFilterNoiseReduction;
+denoise.value = map_to_range(ctx->denoise, 0, 100,
+ ctx->denoise_caps.range.min_value,
+ ctx->denoise_caps.range.max_value);
+vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterParameterBufferType, sizeof(denoise), 1,
+ &denoise, &denoise_id);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_ERROR, "Failed to create denoise parameter
buffer: "
+ "%d (%s).\n", vas, vaErrorStr(vas));
+err = AVERROR(EIO);
+goto fail;
+}
+filter_bufs[num_filter_bufs++] = denoise_id;
+}
+
+if (ctx->sharpless != -1 && ctx->support_sharpless) {
+VAProcFilterParameterBuffer sharpless;
+sharpless.type = VAProcFilterSharpening;
+sharpless.value = map_to_range(ctx->sharpless,
+ ctx->sharpless_caps.range.min_value,
+ ctx->sharpless_caps.range.max_value,
+ 0, 100);
+vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterPara
[FFmpeg-devel] [PATCH] libavutil: let clang-FORTIFY build; NFC.
ChromeOS is adopting a new FORTIFY implementation tailored for clang. As
an artifact of how this new FORTIFY is implemented, a handful of
implicit conversion warnings get turned into errors. This patch fixes
the implicit conversions in ffmpeg that clang-FORTIFY has an issue with.
Signed-off-by: George Burgess IV
---
libavutil/opt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index cd16bd1..f7f5225 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -733,7 +733,8 @@ int av_opt_get(void *obj, const char *name, int
search_flags, uint8_t **out_val)
{
void *dst, *target_obj;
const AVOption *o = av_opt_find2(obj, name, NULL, 0, search_flags,
&target_obj);
-uint8_t *bin, buf[128];
+uint8_t *bin;
+char buf[128];
int len, i, ret;
int64_t i64;
@@ -795,7 +796,7 @@ int av_opt_get(void *obj, const char *name, int
search_flags, uint8_t **out_val)
}
bin = *(uint8_t **)dst;
for (i = 0; i < len; i++)
-snprintf(*out_val + i * 2, 3, "%02X", bin[i]);
+snprintf(*(char **)out_val + i * 2, 3, "%02X", bin[i]);
return 0;
case AV_OPT_TYPE_IMAGE_SIZE:
ret = snprintf(buf, sizeof(buf), "%dx%d", ((int *)dst)[0], ((int
*)dst)[1]);
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix implicit declaration of SetDllDirectory function
On 30.08.2016 04:10, James Almer wrote: On 8/29/2016 10:42 AM, Tobias Rapp wrote: Attached patch fixes a build error on my system (Ubuntu 14.04, mingw-w64 3.1.0, gcc-mingw-w64 4.8.2) introduced by commit 3bf142c77337814458ed8e036796934032d9837f. Interesting. windows.h is already included if CommandLineToArgvW() is available. I guess this means old mingw-w64 doesn't define it. HAVE_COMMANDLINETOARGVW is set to "1" in config.h on my system, but the include of windows.h for CommandLineToArgvW() is on line 228 while SetDllDirectory() is used on line 118. Attached patch is a suggestion to refactor the includes by moving the include of shellapi.h to the top of the file. As the original commit has been backported to older releases (2.8, 3.0 and 3.1 as far as I can see) it probably makes sense to backport this fix, too. Applied where it's needed. Thanks. Regards, Tobias >From 5d1cbec583647b5023589afba3f5095583d7ccd6 Mon Sep 17 00:00:00 2001 From: Tobias Rapp Date: Tue, 30 Aug 2016 09:19:04 +0200 Subject: [PATCH] cmdutils: move includes to top of file Signed-off-by: Tobias Rapp --- cmdutils.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/cmdutils.c b/cmdutils.c index 44f44cd..cc27c63 100644 --- a/cmdutils.c +++ b/cmdutils.c @@ -64,6 +64,9 @@ #ifdef _WIN32 #include #endif +#if HAVE_COMMANDLINETOARGVW +#include +#endif static int init_report(const char *env); @@ -225,8 +228,6 @@ static const OptionDef *find_option(const OptionDef *po, const char *name) * by default. HAVE_COMMANDLINETOARGVW is true on cygwin, while * it doesn't provide the actual command line via GetCommandLineW(). */ #if HAVE_COMMANDLINETOARGVW && defined(_WIN32) -#include -#include /* Will be leaked on exit */ static char** win32_argv_utf8 = NULL; static int win32_argc = 0; -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3] lavf : scale_vaapi : add denoise/sharpless support
v3 : fix sharpless mapping issue
v2 : fix filter support flag check logic issue
From 415b00c6157d8311cc18713e6347400895f7333c Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Tue, 30 Aug 2016 14:36:00 +0800
Subject: [PATCH v3] lavf : scale_vaapi : add denoise/sharpless support.
add denoise/sharpless support, used scope [-1, 100] as the input
scope.
Signed-off-by: Jun Zhao
---
libavfilter/vf_scale_vaapi.c | 115 +++
1 file changed, 115 insertions(+)
diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
index 8dd5acf..5658746 100644
--- a/libavfilter/vf_scale_vaapi.c
+++ b/libavfilter/vf_scale_vaapi.c
@@ -53,6 +53,16 @@ typedef struct ScaleVAAPIContext {
int output_width;
int output_height;
+VAProcFilterCap denoise_caps;
+int support_denoise;
+int denoise; // enable denoise algo. level is the optional
+ // value from the interval [-1, 100], -1 means
disabled
+
+VAProcFilterCap sharpless_caps;
+int support_sharpless;
+int sharpless; // enable sharpless. level is the optional value
+ // from the interval [-1, 100], -1 means disabled
+
} ScaleVAAPIContext;
@@ -117,6 +127,8 @@ static int scale_vaapi_config_output(AVFilterLink *outlink)
AVVAAPIFramesContext *va_frames;
VAStatus vas;
int err, i;
+unsigned int num_denoise_caps = 1;
+unsigned int num_sharpless_caps = 1;
scale_vaapi_pipeline_uninit(ctx);
@@ -225,6 +237,29 @@ static int scale_vaapi_config_output(AVFilterLink *outlink)
goto fail;
}
+vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterNoiseReduction,
+ &ctx->denoise_caps, &num_denoise_caps);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_WARNING, "Failed to query denoise caps "
+ "context: %d (%s).\n", vas, vaErrorStr(vas));
+ctx->support_denoise = 0;
+} else {
+ctx->support_denoise = 1;
+}
+
+vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterSharpening,
+ &ctx->sharpless_caps,
&num_sharpless_caps);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_WARNING, "Failed to query sharpless caps "
+ "context: %d (%s).\n", vas, vaErrorStr(vas));
+ctx->support_sharpless = 0;
+} else {
+ctx->support_sharpless = 1;
+}
+
+
av_freep(&hwconfig);
av_hwframe_constraints_free(&constraints);
return 0;
@@ -250,6 +285,14 @@ static int vaapi_proc_colour_standard(enum AVColorSpace
av_cs)
}
}
+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 scale_vaapi_filter_frame(AVFilterLink *inlink, AVFrame *input_frame)
{
AVFilterContext *avctx = inlink->dst;
@@ -259,6 +302,10 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink,
AVFrame *input_frame)
VASurfaceID input_surface, output_surface;
VAProcPipelineParameterBuffer params;
VABufferID params_id;
+VABufferID denoise_id;
+VABufferID sharpless_id;
+VABufferID filter_bufs[8];
+int num_filter_bufs = 0;
VAStatus vas;
int err;
@@ -290,6 +337,43 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink,
AVFrame *input_frame)
av_log(ctx, AV_LOG_DEBUG, "Using surface %#x for scale output.\n",
output_surface);
+if (ctx->denoise != -1 && ctx->support_denoise) {
+VAProcFilterParameterBuffer denoise;
+denoise.type = VAProcFilterNoiseReduction;
+denoise.value = map_to_range(ctx->denoise, 0, 100,
+ ctx->denoise_caps.range.min_value,
+ ctx->denoise_caps.range.max_value);
+vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterParameterBufferType, sizeof(denoise), 1,
+ &denoise, &denoise_id);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_ERROR, "Failed to create denoise parameter
buffer: "
+ "%d (%s).\n", vas, vaErrorStr(vas));
+err = AVERROR(EIO);
+goto fail;
+}
+filter_bufs[num_filter_bufs++] = denoise_id;
+}
+
+if (ctx->sharpless != -1 && ctx->support_sharpless) {
+VAProcFilterParameterBuffer sharpless;
+sharpless.type = VAProcFilterSharpening;
+sharpless.value = map_to_range(ctx->sharpless,
+ 0, 100,
+ ctx->sharpless_caps.range.min_value,
+ ctx->sharpless_caps.range.max_value);
+vas = vaCreateBu
Re: [FFmpeg-devel] [PATCHv2] vf_colorspace: Allow overriding input color properties
On Mon, Aug 29, 2016 at 5:53 PM, Ronald S. Bultje wrote: > Hi, > > On Mon, Aug 29, 2016 at 11:23 AM, Vittorio Giovara < > vittorio.giov...@gmail.com> wrote: > > > The filter needs input frames with color properties filled out by > > the decoder. Since this is not always possible, add input options to > > the filter so that user may override color space, color primaries, > > transfer characteristics, and color range, as well as a generic option > > to set all properties at once. > > > > Signed-off-by: Vittorio Giovara > > --- > > * added iall option > > * updated filter documentation > > > > Please CC. > > Vittorio > > > > doc/filters.texi| 20 > > libavfilter/vf_colorspace.c | 39 ++ > - > > 2 files changed, 54 insertions(+), 5 deletions(-) > > > lgtm. > > (I wonder if the error message - if the input AVFrame has no > trc/rng/csp/prm - should be changed to reflect that you can override them > using the added properties? This isn't a big deal but maybe someone feels > that's important.) > Still breaks backward compatibility. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] patch libavformat/crypto buffer count
patch split and advice taken :) libavformat-crypto-buffer-count.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Patch libavformat/crypto to add seek when reading
libavformat-crypto-add-seek.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] Motion Interpolation
On Tue, Aug 30, 2016 at 3:13 AM, Davinder Singh wrote: > On Sat, Aug 27, 2016 at 6:15 PM Robert Krüger > wrote: > > > [...] > > what is the way to best contribute with test cases? I have two samples > that > > I use for testing, so far the results look very, very promising but there > > are still a few artefact problems, so these could maybe serve as a good > > test case. In some cases the artefacts almost certainly look like there > is > > a bug in motion vector calculation as a very large area suddenly begins > to > > move in which really only a small part is/should be moving. > > > > How do I make this available to you or other devs at this stage? Just > trac > > tickets or is it too early for that and you would like to work on this > > differently? After all it is always a grey area, when this can be > > considered solved, as it is a process of gradual improvements, so maybe > > it's not well-suited for a ticket. > > > > Let me know. Happy to contribute samples and some testing time here and > > there. > > > > I'm currently testing support for unrestricted search area which can be > used with EPZS, which has improved the quality. > Once I send the patch you can test if it actually reduces the artifacts or > doesn't make it worse. > > OK, great. I'll test the patch when it's there. Have you looked at the example with the moving wall? This really looks a bit like a bug in motion vectors and I also had the impression that this wasn't there when I was testing with earlier version from your branch but cannot be 100% sure. > For smaller details newer recursive algorithms should perform better. Like > this one, https://www.osapublishing.org/jdt/abstract.cfm?uri=jdt-11-7-580 > which uses Modified 3D recursive search iteratively. > So, at this point before any new algorithm is implemented, best way to test > is to verify the experiments I do improves the quality for most of the > samples or not. > > Makes sense. > One would like to compare PSNR, as it's hard compare each frame visually. > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193067.html (for > better > results, original sample should be 60fps, subsampled to 30) > for visual testing, I used to transcode interpolate sample to images and > compared them to original ones. > > Thanks for testing. > > Thanks for building this great filter. Robert ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 5/5] avformat/tee: Use BSF list API
On 08/26/2016 12:53 AM, sebechlebsky...@gmail.com wrote: From: Jan Sebechlebsky Signed-off-by: Jan Sebechlebsky --- I believe I have fixed handling input / output timebase and input parameters to bitstream filters list. libavformat/tee.c | 131 ++ 1 file changed, 64 insertions(+), 67 deletions(-) [...] ping :) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] vf_colorspace: Allow overriding input color properties
Hi, On Tue, Aug 30, 2016 at 4:13 AM, Paul B Mahol wrote: > On Mon, Aug 29, 2016 at 5:53 PM, Ronald S. Bultje > wrote: > > > Hi, > > > > On Mon, Aug 29, 2016 at 11:23 AM, Vittorio Giovara < > > vittorio.giov...@gmail.com> wrote: > > > > > The filter needs input frames with color properties filled out by > > > the decoder. Since this is not always possible, add input options to > > > the filter so that user may override color space, color primaries, > > > transfer characteristics, and color range, as well as a generic option > > > to set all properties at once. > > > > > > Signed-off-by: Vittorio Giovara > > > --- > > > * added iall option > > > * updated filter documentation > > > > > > Please CC. > > > Vittorio > > > > > > doc/filters.texi| 20 > > > libavfilter/vf_colorspace.c | 39 ++ > > - > > > 2 files changed, 54 insertions(+), 5 deletions(-) > > > > > > lgtm. > > > > (I wonder if the error message - if the input AVFrame has no > > trc/rng/csp/prm - should be changed to reflect that you can override them > > using the added properties? This isn't a big deal but maybe someone feels > > that's important.) > > > > Still breaks backward compatibility. Hm yes that should probably be fixed. you said it just means moving the new properties to the end of the AVOptions[] right? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/hlsenc: add warning for append_list and hls_init_time option
When use append_list mode, the hls_init_time set nouse,
Because the append_list only support append at the old m3u8 end
cannot set init segments durations at the middle of the list.
That's invalid use append_list and hls_init_time one time.
and show a warning message for user.
Signed-off-by: LiuQi
---
libavformat/hlsenc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index ab4a9bf..b08f7ec 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -812,6 +812,12 @@ static int hls_write_header(AVFormatContext *s)
if (hls->flags & HLS_APPEND_LIST) {
parse_playlist(s, s->filename);
+if (hls->init_time > 0) {
+av_log(s, AV_LOG_WARNING, "append_list mode cannot set
hls_init_time,"
+"this is append to the endlist of the old m3u8\n");
+hls->init_time = 0;
+hls->recording_time = hls->time * AV_TIME_BASE;
+}
}
if ((ret = hls_start(s)) < 0)
--
2.7.4 (Apple Git-66)
0001-avformat-hlsenc-add-warning-for-append_list-and-hls_.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] added expr evaluation to drawtext - fontsize
Le tridi 13 fructidor, an CCXXIV, Brett Harrison a écrit : > Before I fix the patch, can you clarify the intended functionality? > > The docs say that 16 is the default fontsize, however if > CONFIG_LIBFONTCONFIG is configured and ffmpeg if called with: > > -vf drawtext=text=abc:fontcolor=white > > on my system the font used will be /opt/X11/share/fonts/TTF/Vera.ttf (the > default chosen by libfontconfig) and the fontsize will be set to 12. > > However if ffmpeg is called with: > > -vf > drawtext=text=abc:fontcolor=white:fontfile=/opt/X11/share/fonts/TTF/Vera.ttf > > This is the same font that libfontconfig used, however this time fontsize > 16 is used as stated in the docs. > > The difference is this line of code in load_font_fontconfig > if (!s->fontsize) > s->fontsize = size + 0.5; > > I didn't set the fontsize in either command, but the output was different. > Do we want to keep this as is? I think the current behaviour is correct. I start with the following principle: when users want something precise about aesthetic or other arbitrary settings, they have to say it. Default values are for the lazy or the careless ones: quick profiling and testing when the exact result does not matter much. But as soon as the result matters, explicit values must be given. Do not take me wrong, the default values should be, as much as possible, sensible. But for a font size, 12 is as sensible as 16. Most importantly, backward compatibility should not be an hindrance to choosing better default values. We should not change them lightly, but not feel forbidden to do so either. Fontconfig is not just a path search library for finding font files. It is a complete mechanism for choosing the right font according to several conditions set by the user. Including the font size. There are no less than four levels for choosing the font size: (1) lavfi's default, 16; (2) fontconfig's default; (3) fontconfig's explicit value, as in "Times-12:bold"; (4) lavfi's explicit value, as in "fontsize=16". I think the order of precedence should be just that, for the following reasons: - First, of course, (3), (4) > (1), (2), because explicit values are always more important. - Second, conflicting explicit values are the users' problem. We can produce warnings to help diagnose, but in the end it is their choice. (4) > (3) is slightly easier to implement (distinguishing (3) from (2) requires a bit of work), and (4) is more supple, especially when your patch gets applied. - Last, (2) > (1), because fontconfig is more cross-applications than lavfi, and also because it includes a mechanism for explicit configuration. Still, the documentation should be clarified, possibly something like that: "The default value of fontsize is provided by fontconfig if in use or 16 when using a font file directly." Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Evolution of lavfi's design and API
Le duodi 12 fructidor, an CCXXIV, Paul B Mahol a écrit : > Nicolas, what is status of this? > > I'm currently interested in frame multithreading in lavfi. I am currently locked on a patch series to replace the recursive calls to filter_frames() with a FIFO on each link. I think this is an absolute necessity before considering inter-filter multithreading. Unfortunately, this is very tricky business because the filters' implementation are not ready for it. Filters must be activated, by actually calling their filter_frame() methods, when a frame is available, but not repeatedly so when they can not perform any work, but they often provide no visible test for that. Plus, the global API for activating a filtergraph was not designed with that kind of working in mind. I have made significant progress in the last weeks. I think I have got the propagating of frames working, and the propagating of EOF conditions on 1-to-1 filters too, but there is still an issue with filters with multiple inputs. I could post the whole patch as is at any time, but I do not think it would do much good as is. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavutil: let clang-FORTIFY build; NFC.
On Tue, Aug 30, 2016 at 12:11:42AM -0700, George Burgess IV wrote: > ChromeOS is adopting a new FORTIFY implementation tailored for clang. As > an artifact of how this new FORTIFY is implemented, a handful of > implicit conversion warnings get turned into errors. This patch fixes > the implicit conversions in ffmpeg that clang-FORTIFY has an issue with. > > Signed-off-by: George Burgess IV > --- > libavutil/opt.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) does this patch fix the issue entirely or are there other patches needed for other files ? (asking as it seems odd that its just this) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [GSoC][PATCH v2 2/2] mlpenc: Working MLP/TrueHD encoder
* Multichannel support for TrueHD is experimental
There should be downmix substreams present for 2+ channel bitstreams,
but ffmpeg decoder doesn't need it. Will add support for this soon.
* There might be lossless check failures on LFE channels
* 32-bit sample support has been removed for now, will add it later
While testing, some samples gave lossless check failures when enforcing
s32. Probably this will also get solved with the LFE issues.
Signed-off-by: Jai Luthra
---
> a fate test could also be added
sure. i will add it in a separate patch later.
libavcodec/Makefile|2 +
libavcodec/allcodecs.c |4 +-
libavcodec/mlp.c | 21 +
libavcodec/mlp.h | 40 +
libavcodec/mlpenc.c| 2416
5 files changed, 2481 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/mlpenc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 7396468..b8d2a4c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -382,6 +382,7 @@ OBJS-$(CONFIG_MJPEG_ENCODER) += mjpegenc.o
mjpegenc_common.o
OBJS-$(CONFIG_MJPEGB_DECODER) += mjpegbdec.o
OBJS-$(CONFIG_MJPEG_VAAPI_ENCODER) += vaapi_encode_mjpeg.o
OBJS-$(CONFIG_MLP_DECODER) += mlpdec.o mlpdsp.o
+OBJS-$(CONFIG_MLP_ENCODER) += mlpenc.o
OBJS-$(CONFIG_MMVIDEO_DECODER) += mmvideo.o
OBJS-$(CONFIG_MOTIONPIXELS_DECODER)+= motionpixels.o
OBJS-$(CONFIG_MOVTEXT_DECODER) += movtextdec.o ass.o
@@ -545,6 +546,7 @@ OBJS-$(CONFIG_TIFF_DECODER)+= tiff.o lzw.o
faxcompr.o tiff_data.o ti
OBJS-$(CONFIG_TIFF_ENCODER)+= tiffenc.o rle.o lzwenc.o tiff_data.o
OBJS-$(CONFIG_TMV_DECODER) += tmv.o cga_data.o
OBJS-$(CONFIG_TRUEHD_DECODER) += mlpdec.o mlpdsp.o
+OBJS-$(CONFIG_TRUEHD_ENCODER) += mlpenc.o
OBJS-$(CONFIG_TRUEMOTION1_DECODER) += truemotion1.o
OBJS-$(CONFIG_TRUEMOTION2_DECODER) += truemotion2.o
OBJS-$(CONFIG_TRUEMOTION2RT_DECODER) += truemotion2rt.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 4c6b94e..64e0514 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -419,7 +419,7 @@ void avcodec_register_all(void)
REGISTER_DECODER(MACE3, mace3);
REGISTER_DECODER(MACE6, mace6);
REGISTER_DECODER(METASOUND, metasound);
-REGISTER_DECODER(MLP, mlp);
+REGISTER_ENCDEC (MLP, mlp);
REGISTER_DECODER(MP1, mp1);
REGISTER_DECODER(MP1FLOAT, mp1float);
REGISTER_ENCDEC (MP2, mp2);
@@ -448,7 +448,7 @@ void avcodec_register_all(void)
REGISTER_ENCDEC (SONIC, sonic);
REGISTER_ENCODER(SONIC_LS, sonic_ls);
REGISTER_DECODER(TAK, tak);
-REGISTER_DECODER(TRUEHD,truehd);
+REGISTER_ENCDEC (TRUEHD,truehd);
REGISTER_DECODER(TRUESPEECH,truespeech);
REGISTER_ENCDEC (TTA, tta);
REGISTER_DECODER(TWINVQ,twinvq);
diff --git a/libavcodec/mlp.c b/libavcodec/mlp.c
index 87f7c77..ddbab60 100644
--- a/libavcodec/mlp.c
+++ b/libavcodec/mlp.c
@@ -41,6 +41,27 @@ const uint8_t ff_mlp_huffman_tables[3][18][2] = {
}
};
+const ChannelInformation ff_mlp_ch_info[21] = {
+{ 0x01, 0x01, 0x00, 0x1f }, { 0x03, 0x02, 0x00, 0x1b },
+{ 0x07, 0x02, 0x01, 0x1f }, { 0x0F, 0x02, 0x02, 0x19 },
+{ 0x07, 0x02, 0x01, 0x03 }, { 0x0F, 0x02, 0x02, 0x1f },
+{ 0x1F, 0x02, 0x03, 0x01 }, { 0x07, 0x02, 0x01, 0x1a },
+{ 0x0F, 0x02, 0x02, 0x1f }, { 0x1F, 0x02, 0x03, 0x18 },
+{ 0x0F, 0x02, 0x02, 0x02 }, { 0x1F, 0x02, 0x03, 0x1f },
+{ 0x3F, 0x02, 0x04, 0x00 }, { 0x0F, 0x03, 0x01, 0x1f },
+{ 0x1F, 0x03, 0x02, 0x18 }, { 0x0F, 0x03, 0x01, 0x02 },
+{ 0x1F, 0x03, 0x02, 0x1f }, { 0x3F, 0x03, 0x03, 0x00 },
+{ 0x1F, 0x04, 0x01, 0x01 }, { 0x1F, 0x04, 0x01, 0x18 },
+{ 0x3F, 0x04, 0x02, 0x00 },
+};
+
+const uint64_t ff_mlp_channel_layouts[12] = {
+AV_CH_LAYOUT_MONO, AV_CH_LAYOUT_STEREO, AV_CH_LAYOUT_2_1,
+AV_CH_LAYOUT_QUAD, AV_CH_LAYOUT_2POINT1, AV_CH_LAYOUT_SURROUND,
+AV_CH_LAYOUT_4POINT0, AV_CH_LAYOUT_5POINT0_BACK, AV_CH_LAYOUT_3POINT1,
+AV_CH_LAYOUT_4POINT1, AV_CH_LAYOUT_5POINT1_BACK, 0,
+};
+
static int crc_init = 0;
#if CONFIG_SMALL
#define CRC_TABLE_SIZE 257
diff --git a/libavcodec/mlp.h b/libavcodec/mlp.h
index 05d8dba..41a45a3 100644
--- a/libavcodec/mlp.h
+++ b/libavcodec/mlp.h
@@ -76,6 +76,9 @@ typedef struct FilterParams {
uint8_t shift; ///< Right shift to apply to output of filter.
int32_t state[MAX_FIR_ORDER];
+
+int coeff_bits;
+int coeff_shift;
} FilterParams;
/** sample data coding information */
@@ -96,6 +99,43 @@ typedef struct ChannelParams {
*/
extern const uint8_t ff_mlp_huffman_tables[3][18][2];
+typedef struct {
+uint8_t channel_occupancy;
+uint8_t group1_channels;
+uint8_t group2_channels;
Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer
On date Tuesday 2016-08-23 16:53:28 +0200, Nicolas George encoded:
> Le septidi 7 fructidor, an CCXXIV, Stefano Sabatini a écrit :
> > Bump.
> >
> > So, basically, what are the features that you want to add?
> > I can list a few:
> >
> > - have multiple streams (with media type and optionally encoding,
> > assumes base64 by default) in a dedicated header
> >
> > - specify codec parameters: this could be done serializing
> > AVCodecParameters. This is the part which would be less robust.
> >
> > The important point to keep in mind is that this is meant to be an
> > internal format, so it should be used internally (e.g. to mux data)
> > coming from an external source, and we give no guarantee that the
> > format will be robust to changes in libavformat/libavcodec (e.g. in
> > case AVCodecParameter is extended).
> >
> > My main objection to the ffprobe format is that it's not easily
> > parseable, but I can reconsider it in case there is a strong request
> > for that.
>
> Sorry for the delay. Here is the patch; as you can see it is two and a half
> years old. IIRC, it used to work with the output of "ffprobe -show_format
> -show_streams -show_packets -show_data", provided the output was edited to
> put the sections in the required order.
>
> The benefit from using ffprobe instead of a custom format is to not have yet
> another variant of text format.
Sure.
I rebased the patch, and performed two simple changes in ffprobe (see
attachment), and it's almost working.
I think supporting the show_compact_data mode should simplify the
format in case the format is generated programmatically/through
scripting.
>From e0a698f1877c52df13158f3f0744f2e5430c75f3 Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Sat, 11 Jan 2014 19:42:41 +0100
Subject: [PATCH] lavf: add ffprobe demuxer
Signed-off-by: Nicolas George
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 2 +
libavformat/ffprobedec.c | 341 +++
3 files changed, 344 insertions(+)
create mode 100644 libavformat/ffprobedec.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index b68c27c..d222ac2 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -162,6 +162,7 @@ OBJS-$(CONFIG_FFM_DEMUXER) += ffmdec.o
OBJS-$(CONFIG_FFM_MUXER) += ffmenc.o
OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
OBJS-$(CONFIG_FFMETADATA_MUXER) += ffmetaenc.o
+OBJS-$(CONFIG_FFPROBE_DEFAULT_DEMUXER) += ffprobedec.o
OBJS-$(CONFIG_FFTEXTDATA_DEMUXER)+= fftextdatadec.o
OBJS-$(CONFIG_FFTEXTDATA_MUXER) += fftextdataenc.o
OBJS-$(CONFIG_FIFO_MUXER)+= fifo.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index e58e41d..2e10e26 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -123,8 +123,10 @@ void av_register_all(void)
REGISTER_MUXER (F4V, f4v);
REGISTER_MUXDEMUX(FFM, ffm);
REGISTER_MUXDEMUX(FFMETADATA, ffmetadata);
+REGISTER_DEMUXER (FFPROBE_DEFAULT, ffprobe_default);
REGISTER_MUXDEMUX(FFTEXTDATA, fftextdata);
REGISTER_MUXER (FIFO, fifo);
+REGISTER_MUXDEMUX(FFTEXTDATA, fftextdata);
REGISTER_MUXDEMUX(FILMSTRIP,filmstrip);
REGISTER_MUXDEMUX(FLAC, flac);
REGISTER_DEMUXER (FLIC, flic);
diff --git a/libavformat/ffprobedec.c b/libavformat/ffprobedec.c
new file mode 100644
index 000..28e4e66
--- /dev/null
+++ b/libavformat/ffprobedec.c
@@ -0,0 +1,341 @@
+/*
+ * Copyright (c) 2013 Nicolas George
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with FFmpeg; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/bprint.h"
+#include "avformat.h"
+#include "internal.h"
+
+enum SectionType {
+SEC_NONE = 0,
+SEC_FORMAT,
+SEC_STREAM,
+SEC_PACKET,
+};
+
+const char *const section_names[] = {
+[SEC_NONE] = "NONE",
+[SEC_FORMAT] = "FORMAT",
+[SEC_STREAM] = "STREAM",
+[SEC_PACKET] = "PACKET",
+};
+
+typedef struct {
+AVClass *class;
+enum SectionType section;
+AVBPrint data;
+} FFprobeContext;
+
+static int ffprobe_probe(AVProbeData *probe)
+{
+unsigned score;
+
+
[FFmpeg-devel] [PATCH] configure: improve logic and checks for nvenc
---
configure | 37 +
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/configure b/configure
index 52931c3..bcfc9a8 100755
--- a/configure
+++ b/configure
@@ -5992,20 +5992,33 @@ enabled vdpau && enabled xlib &&
check_lib2 "vdpau/vdpau.h vdpau/vdpau_x11.h" vdp_device_create_x11 -lvdpau
&&
enable vdpau_x11
-case $target_os in
-mingw32*|mingw64*|win32|win64|linux|cygwin*)
-disabled nvenc || enable nvenc
-;;
-*)
-disable nvenc
-;;
-esac
-
-if enabled nvenc; then
+if ! enabled x86; then
+enabled nvenc && die "NVENC is only supported on x86"
+disable nvenc
+elif ! disabled nvenc; then
{
echo '#include "compat/nvenc/nvEncodeAPI.h"'
-echo 'int main(void) { return 0; }'
-} | check_cc -I$source_path || disable nvenc
+echo 'NV_ENCODE_API_FUNCTION_LIST flist;'
+echo 'void f(void) { struct { const GUID guid; } s[] = { {
NV_ENC_PRESET_HQ_GUID } }; }'
+echo 'int main(void) { f(); return 0; }'
+} | check_cc -I$source_path
+nvenc_check_res=$?
+
+if [ $nvenc_check_res != 0 ] && enabled nvenc; then
+die "NVENC enabled but test-compile failed"
+fi
+
+case $target_os in
+mingw32*|mingw64*|win32|win64|linux|cygwin*)
+[ $nvenc_check_res = 0 ] && enable nvenc
+;;
+*)
+enabled nvenc && die "NVENC is only supported on Windows and Linux"
+disable nvenc
+;;
+esac
+
+unset nvenc_check_res
fi
# Funny iconv installations are not unusual, so check it after all flags have
been set
--
2.9.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ffmpeg video conversation command is not working
Hi ffmpeg Team,
Good day to you,
We are waiting for your reply, kindly let us know your suggestion to
resolve the issue.
Thanks,
On Fri, Aug 26, 2016 at 8:51 PM, Markin Abras wrote:
> Hello, did you hear back from ffmpeg? Did they say what we should do?
>
> Markin
>
> On Thu, Aug 25, 2016 at 11:58 AM, Markin Abras <
> abras_mar...@macdirectory.com> wrote:
>
>> Thank you for the error log but I'm not clear what you need me to do.
>> Unfortunately, I don't have the experience or knowledge to resolve the
>> issue. Why don't you email someone at ffmpeg directly and ask for their
>> support? They will certainly be able to help. Let me know what they say.
>> Thanks!!
>>
>> Markin
>>
>> On Thu, Aug 25, 2016 at 1:05 AM, Madhav G wrote:
>>
>>> Hi ffmpeg team,
>>>
>>> Kindly find the attachment for the error log that occur when we try to
>>> install ffmpeg 3.1.2, if any other details you need means kindly let us
>>> know.
>>>
>>> Thanks,
>>>
>>> On Thu, Aug 25, 2016 at 11:02 AM, Madhav G wrote:
>>>
Hi ffmpeg Team,
Good day,
We are waiting for your reply, kindly I request you to give some
solution on our issue.
Thanks,
On Wed, Aug 24, 2016 at 3:52 PM, Madhav G wrote:
> *Hi ffmpeg team,*
>
> We are using your software past 2 years with following version and OS,
>
> CentOS - 6.8
> Php - 5.3.29
> ffmpeg - 0.6.5
> ffmpeg-php - 0.6.0
>
> till last month its has been worked well after that video does not
> converted, just new file will be created with 0 MB file, to solve it we
> have check your website and document then we came to know that, old
> version
> is the problem, so we try to install new version ffmpeg 3.1.2 its has been
> installed but dependency file ffmpeg-php does not get upgraded, because of
> that following
>
>
>
> * command line in the php is not working,exec("ffmpeg -i sample_20.mp4
> outfile.avi");*
>
>
>
> *Error message :"Error while opening encoder for output stream #0.1 -
> maybe incorrect parameters such as bit_rate, rate, width or height"*
>
> *same time the command working well in command prompt.*
>
> I have attached the error log file that we got during the installation
> time kindly check it out.
>
> I hope you have understand my situation kindly advise us to install
> full package successfully and run the command in the php.
>
> Thanks for your help,
>
> --
> --
>
> *Best Regards,*
>
> *Madhav,*
>
> Asst Manager - Project
>
> *NDOT Technologies Pvt Ltd,*
>
> Block No 3,
> 1,2 & 3rd Floor,
> Mullai Nagar,
>
> Coimbatore - 641041.
>
> *Phone:* +91 422-434-2518, 519
>
> *Mail:-*
>
> *US :* +1 (323) 744 -6443
> [image: Facebook] [image: Linked_in]
> [image: Twitter]
>
>
> Enterprise Mobility – CRM - ERP – Mobile - Web - Software - Hire Team
> - Ecommerce
>
> *INDIA (HQ)* - Singapore - United States - Dubai - Morocco – Spain -
> Venezuela
>
>
> DISCLAIMER:
> The information contained in this message (including any attachments)
> is confidential and may be privileged. If you have received it by mistake
> please notify the sender by return e-mail and permanently delete this
> message and any attachments from your system. Any dissemination, use,
> review, distribution, printing or copying of this message in whole or in
> part is strictly prohibited. Please note that e-mails are susceptible to
> change. NDOT Technologies Pvt Ltd (including its group companies) shall
> not
> be liable for the improper or incomplete transmission of the information
> contained in this email.
>
--
--
*Best Regards,*
*Madhav,*
Asst Manager - Project
*NDOT Technologies Pvt Ltd,*
Block No 3,
1,2 & 3rd Floor,
Mullai Nagar,
Coimbatore - 641041.
*Phone:* +91 422-434-2518, 519
*Mail:-*
*US :* +1 (323) 744 -6443
[image: Facebook] [image: Linked_in]
[image: Twitter]
Enterprise Mobility – CRM - ERP – Mobile - Web - Software - Hire Team -
Ecommerce
*INDIA (HQ)* - Singapore - United States - Dubai - Morocco – Spain -
Venezuela
DISCLAIMER:
The information contained in this message (including any attachments)
is confidential and may be privileged. If you have received it by mistake
please notify the sender by return e-mail and permanently delete this
message and any attachments from your system. Any disse
Re: [FFmpeg-devel] [PATCH v4 5/5] avformat/tee: Use BSF list API
Le decadi 10 fructidor, an CCXXIV, sebechlebsky...@gmail.com a écrit :
> From: Jan Sebechlebsky
>
> Signed-off-by: Jan Sebechlebsky
> ---
> I believe I have fixed handling input / output timebase and input parameters
> to bitstream filters list.
>
> libavformat/tee.c | 131
> ++
> 1 file changed, 64 insertions(+), 67 deletions(-)
>
> diff --git a/libavformat/tee.c b/libavformat/tee.c
> index 5689ca3..ba852c3 100644
> --- a/libavformat/tee.c
> +++ b/libavformat/tee.c
> @@ -37,7 +37,7 @@ typedef enum {
>
> typedef struct {
> AVFormatContext *avf;
> -AVBitStreamFilterContext **bsfs; ///< bitstream filters per stream
> +AVBSFContext **bsfs; ///< bitstream filters per stream
>
> SlaveFailurePolicy on_fail;
>
> @@ -64,46 +64,6 @@ static const AVClass tee_muxer_class = {
> .version= LIBAVUTIL_VERSION_INT,
> };
>
> -/**
> - * Parse list of bitstream filters and add them to the list of filters
> - * pointed to by bsfs.
> - *
> - * The list must be specified in the form:
> - * BSFS ::= BSF[,BSFS]
> - */
> -static int parse_bsfs(void *log_ctx, const char *bsfs_spec,
> - AVBitStreamFilterContext **bsfs)
> -{
> -char *bsf_name, *buf, *dup, *saveptr;
> -int ret = 0;
> -
> -if (!(dup = buf = av_strdup(bsfs_spec)))
> -return AVERROR(ENOMEM);
> -
> -while (bsf_name = av_strtok(buf, ",", &saveptr)) {
> -AVBitStreamFilterContext *bsf = av_bitstream_filter_init(bsf_name);
> -
> -if (!bsf) {
> -av_log(log_ctx, AV_LOG_ERROR,
> - "Cannot initialize bitstream filter with name '%s', "
> - "unknown filter or internal error happened\n",
> - bsf_name);
> -ret = AVERROR_UNKNOWN;
> -goto end;
> -}
> -
> -/* append bsf context to the list of bsf contexts */
> -*bsfs = bsf;
> -bsfs = &bsf->next;
> -
> -buf = NULL;
> -}
> -
> -end:
> -av_free(dup);
> -return ret;
> -}
> -
> static inline int parse_slave_failure_policy_option(const char *opt,
> TeeSlave *tee_slave)
> {
> if (!opt) {
> @@ -135,14 +95,8 @@ static int close_slave(TeeSlave *tee_slave)
> ret = av_write_trailer(avf);
>
> if (tee_slave->bsfs) {
> -for (i = 0; i < avf->nb_streams; ++i) {
> -AVBitStreamFilterContext *bsf_next, *bsf = tee_slave->bsfs[i];
> -while (bsf) {
> -bsf_next = bsf->next;
> -av_bitstream_filter_close(bsf);
> -bsf = bsf_next;
> -}
> -}
> +for (i = 0; i < avf->nb_streams; ++i)
> +av_bsf_free(&tee_slave->bsfs[i]);
> }
> av_freep(&tee_slave->stream_map);
> av_freep(&tee_slave->bsfs);
> @@ -312,7 +266,7 @@ static int open_slave(AVFormatContext *avf, char *slave,
> TeeSlave *tee_slave)
> "output '%s', filters will be ignored\n", i,
> filename);
> continue;
> }
> -ret = parse_bsfs(avf, entry->value, &tee_slave->bsfs[i]);
> +ret = av_bsf_list_parse_str(entry->value,
> &tee_slave->bsfs[i]);
> if (ret < 0) {
> av_log(avf, AV_LOG_ERROR,
> "Error parsing bitstream filter sequence '%s'
> associated to "
> @@ -325,6 +279,35 @@ static int open_slave(AVFormatContext *avf, char *slave,
> TeeSlave *tee_slave)
> av_dict_set(&options, entry->key, NULL, 0);
> }
>
> +for (i = 0; i < avf->nb_streams; i++){
> +int target_stream = tee_slave->stream_map[i];
> +if (target_stream < 0)
> +continue;
> +
> +if (!tee_slave->bsfs[target_stream]) {
> +/* Add pass-through bitstream filter */
> +ret = av_bsf_get_null_filter(&tee_slave->bsfs[target_stream]);
> +if (ret < 0) {
> +av_log(avf, AV_LOG_ERROR,
> + "Failed to create pass-through bitstream filter:
> %s\n",
> + av_err2str(ret));
> +goto end;
> +}
> +}
> +
> +tee_slave->bsfs[target_stream]->time_base_in =
> avf->streams[i]->time_base;
> +ret = avcodec_parameters_copy(tee_slave->bsfs[target_stream]->par_in,
> + avf->streams[i]->codecpar);
ret ignored here.
(I wonder if all this block could be made a single utility function:
av_bsf_full_init(&bsf, time_base, codecpar);
... including getting a null bsf if there is nothing to init; but that is
not important.)
> +
> +ret = av_bsf_init(tee_slave->bsfs[target_stream]);
> +if (ret < 0) {
> +av_log(avf, AV_LOG_ERROR,
> +"Failed to initialize bitstream filter(s): %s\n",
> +av_err2str(ret));
> +goto end;
> +}
> +}
> +
> if (options) {
> entry = N
Re: [FFmpeg-devel] ffmpeg video conversation command is not working
Le quartidi 14 fructidor, an CCXXIV, Madhav G a écrit : > We are waiting for your reply, kindly let us know your suggestion to > resolve the issue. You did get a reply, on ffmpeg-user, which is the proper place. As this mail is not about the development of ffmpeg proper, it should not have been sent to ffmpeg-devel. > On Fri, Aug 26, 2016 at 8:51 PM, Markin Abras DISCLAIMER: > The information contained in this message (including any attachments) is > confidential and may be privileged. If you have received it by mistake > please notify the sender by return e-mail and permanently delete this > message and any attachments from your system. Any dissemination, use, > review, distribution, printing or copying of this message in whole or in > part is strictly prohibited. Please note that e-mails are susceptible to > change. NDOT Technologies Pvt Ltd (including its group companies) shall not > be liable for the improper or incomplete transmission of the information > contained in this email. This kind of disclaimer is complete nonsense on public mailing-lists and forbidden here. Please fix it. Ignoring mailing-lists netiquette is a good way of never getting answers. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Evolution of lavfi's design and API
On Tuesday, August 30, 2016, Nicolas George wrote: > Le duodi 12 fructidor, an CCXXIV, Paul B Mahol a écrit : > > Nicolas, what is status of this? > > > > I'm currently interested in frame multithreading in lavfi. > > I am currently locked on a patch series to replace the recursive calls to > filter_frames() with a FIFO on each link. > > I think this is an absolute necessity before considering inter-filter > multithreading. > > Unfortunately, this is very tricky business because the filters' > implementation are not ready for it. Filters must be activated, by actually > calling their filter_frame() methods, when a frame is available, but not > repeatedly so when they can not perform any work, but they often provide no > visible test for that. Plus, the global API for activating a filtergraph > was > not designed with that kind of working in mind. > > I have made significant progress in the last weeks. I think I have got the > propagating of frames working, and the propagating of EOF conditions on > 1-to-1 filters too, but there is still an issue with filters with multiple > inputs. > > I could post the whole patch as is at any time, but I do not think it would > do much good as is. > > the filter frame multithreading would just internally, in filter context cache frames, once enough frames are in cache - call workers and be done, repeat. At eof call workers on remaining frames in cache. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] vf_colorspace: Allow overriding input color properties
On Tue, Aug 30, 2016 at 4:13 AM, Paul B Mahol wrote: > > > On Mon, Aug 29, 2016 at 5:53 PM, Ronald S. Bultje > wrote: >> >> Hi, >> >> On Mon, Aug 29, 2016 at 11:23 AM, Vittorio Giovara < >> vittorio.giov...@gmail.com> wrote: >> >> > The filter needs input frames with color properties filled out by >> > the decoder. Since this is not always possible, add input options to >> > the filter so that user may override color space, color primaries, >> > transfer characteristics, and color range, as well as a generic option >> > to set all properties at once. >> > >> > Signed-off-by: Vittorio Giovara >> > --- >> > * added iall option >> > * updated filter documentation >> > >> > Please CC. >> > Vittorio >> > >> > doc/filters.texi| 20 >> > libavfilter/vf_colorspace.c | 39 >> > ++- >> > 2 files changed, 54 insertions(+), 5 deletions(-) >> >> >> lgtm. >> >> (I wonder if the error message - if the input AVFrame has no >> trc/rng/csp/prm - should be changed to reflect that you can override them >> using the added properties? This isn't a big deal but maybe someone feels >> that's important.) > > > Still breaks backward compatibility. I fail to see how, can you provide more details? -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] vf_colorspace: Allow overriding input color properties
On Tuesday, August 30, 2016, Vittorio Giovara wrote: > On Tue, Aug 30, 2016 at 4:13 AM, Paul B Mahol > wrote: > > > > > > On Mon, Aug 29, 2016 at 5:53 PM, Ronald S. Bultje > > > wrote: > >> > >> Hi, > >> > >> On Mon, Aug 29, 2016 at 11:23 AM, Vittorio Giovara < > >> vittorio.giov...@gmail.com > wrote: > >> > >> > The filter needs input frames with color properties filled out by > >> > the decoder. Since this is not always possible, add input options to > >> > the filter so that user may override color space, color primaries, > >> > transfer characteristics, and color range, as well as a generic option > >> > to set all properties at once. > >> > > >> > Signed-off-by: Vittorio Giovara > > >> > --- > >> > * added iall option > >> > * updated filter documentation > >> > > >> > Please CC. > >> > Vittorio > >> > > >> > doc/filters.texi| 20 > >> > libavfilter/vf_colorspace.c | 39 > >> > ++- > >> > 2 files changed, 54 insertions(+), 5 deletions(-) > >> > >> > >> lgtm. > >> > >> (I wonder if the error message - if the input AVFrame has no > >> trc/rng/csp/prm - should be changed to reflect that you can override > them > >> using the added properties? This isn't a big deal but maybe someone > feels > >> that's important.) > > > > > > Still breaks backward compatibility. > > I fail to see how, can you provide more details? when doing options without typing option name, but just values, like: val0:val1:... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] patch libavformat/crypto buffer count
On Tue, Aug 30, 2016 at 09:45:56AM +0100, Simon H wrote: > patch split and advice taken :) > crypto.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > 31c87f6b089c8e51817dda80327bda83d91bb3c4 > libavformat-crypto-buffer-count.patch > From 14176ca9d6a1d62d10c2e670ccf4f1d2cf16648f Mon Sep 17 00:00:00 2001 > From: Simon Hailes > Date: Tue, 30 Aug 2016 08:47:02 +0100 > Subject: [PATCH] libavformat/crypto - encourage reads of 4096 bytes > > the current implementation reads in chunks of 149x16=2384 bytes. > Seems more logical for it to read in chunks of 4096 > --- > libavformat/crypto.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch libavformat/crypto to add seek when reading
On Tue, Aug 30, 2016 at 09:47:12AM +0100, Simon H wrote: > > crypto.c | 116 > +-- > 1 file changed, 114 insertions(+), 2 deletions(-) > a8d9d6638d0be86896de1cb2fa5f9a9f60d7b3c3 libavformat-crypto-add-seek.patch > From a0c4d274b2b1712e6ca26a18083edccb55032b94 Mon Sep 17 00:00:00 2001 > From: Simon Hailes > Date: Tue, 30 Aug 2016 09:40:14 +0100 > Subject: [PATCH] cyrpto allows reading of data which has been aes-128-cbc > encrypted given a key and an iv. But it did not handle filetypes which > require seeking... e.g. it failed on an encrypted .mp4 file. > > example: > take 25.mp4 created with: > ffmpeg -f lavfi -i sine=frequency=1000:beep_factor=2:r=48000:duration=720.0 > -f lavfi -i testsrc=duration=720.0:rate=25 -vcodec libx264 -cmp 22 -timecode > 10:00:00:00 -r 25 -y out\25.mp4 > > encrypt with: > openssl enc -aes-128-cbc -K 12345678901234567890123456789012 -iv > 12345678901234567890123456789012 -in 25.mp4 -out 25.enc > then to transcode in ffmpeg: > ffmpeg -key 12345678901234567890123456789012 -iv > 12345678901234567890123456789012 -i crypto:25.enc -vcodec mpeg4 -r 25 -y > 25dec.mp4 > > prior to this modification, the transcode would fail. > > Note also: crypto previously maked both reads and writes as streamed, which > caused the whole file > to be read before the transcode started. Now, for read only, if the > underlying layer is not marked as streamed, > then crypto is not. This should enable efficient reading of encrypted > containers which require seeking. > --- > libavformat/crypto.c | 116 > ++- > 1 file changed, 114 insertions(+), 2 deletions(-) applied can you add a fate test for this case ? thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] vf_colorspace: Allow overriding input color properties
On Tue, Aug 30, 2016 at 10:54 AM, Paul B Mahol wrote: > > > On Tuesday, August 30, 2016, Vittorio Giovara > wrote: >> >> On Tue, Aug 30, 2016 at 4:13 AM, Paul B Mahol wrote: >> > >> > >> > On Mon, Aug 29, 2016 at 5:53 PM, Ronald S. Bultje >> > wrote: >> >> >> >> Hi, >> >> >> >> On Mon, Aug 29, 2016 at 11:23 AM, Vittorio Giovara < >> >> vittorio.giov...@gmail.com> wrote: >> >> >> >> > The filter needs input frames with color properties filled out by >> >> > the decoder. Since this is not always possible, add input options to >> >> > the filter so that user may override color space, color primaries, >> >> > transfer characteristics, and color range, as well as a generic >> >> > option >> >> > to set all properties at once. >> >> > >> >> > Signed-off-by: Vittorio Giovara >> >> > --- >> >> > * added iall option >> >> > * updated filter documentation >> >> > >> >> > Please CC. >> >> > Vittorio >> >> > >> >> > doc/filters.texi| 20 >> >> > libavfilter/vf_colorspace.c | 39 >> >> > ++- >> >> > 2 files changed, 54 insertions(+), 5 deletions(-) >> >> >> >> >> >> lgtm. >> >> >> >> (I wonder if the error message - if the input AVFrame has no >> >> trc/rng/csp/prm - should be changed to reflect that you can override >> >> them >> >> using the added properties? This isn't a big deal but maybe someone >> >> feels >> >> that's important.) >> > >> > >> > Still breaks backward compatibility. >> >> I fail to see how, can you provide more details? > > > > when doing options without typing option name, but just values, like: > val0:val1:... Oh I see, thanks. Isn't that syntax a little too fragile for this kind of filter? Or, from another perspective, is the filter old enough that backward compatibility should matter? -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer
On date Tuesday 2016-08-30 12:31:27 +0200, Stefano Sabatini encoded: [...] > I rebased the patch, and performed two simple changes in ffprobe (see > attachment), and it's almost working. > > I think supporting the show_compact_data mode should simplify the > format in case the format is generated programmatically/through > scripting. In other words, I see these options: the demuxer should support both compact and non-compact data formats, or only one format - in this case the easiest format, that is the compact one. Anyway no need to reply, will send the related patches soon. -- FFmpeg = Faithless Free Mystic Power Easy Gymnast ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] vf_colorspace: Allow overriding input color properties
Hi, On Tue, Aug 30, 2016 at 10:00 AM, Vittorio Giovara < vittorio.giov...@gmail.com> wrote: > On Tue, Aug 30, 2016 at 4:13 AM, Paul B Mahol wrote: > > > > > > On Mon, Aug 29, 2016 at 5:53 PM, Ronald S. Bultje > > wrote: > >> > >> Hi, > >> > >> On Mon, Aug 29, 2016 at 11:23 AM, Vittorio Giovara < > >> vittorio.giov...@gmail.com> wrote: > >> > >> > The filter needs input frames with color properties filled out by > >> > the decoder. Since this is not always possible, add input options to > >> > the filter so that user may override color space, color primaries, > >> > transfer characteristics, and color range, as well as a generic option > >> > to set all properties at once. > >> > > >> > Signed-off-by: Vittorio Giovara > >> > --- > >> > * added iall option > >> > * updated filter documentation > >> > > >> > Please CC. > >> > Vittorio > >> > > >> > doc/filters.texi| 20 > >> > libavfilter/vf_colorspace.c | 39 > >> > ++- > >> > 2 files changed, 54 insertions(+), 5 deletions(-) > >> > >> > >> lgtm. > >> > >> (I wonder if the error message - if the input AVFrame has no > >> trc/rng/csp/prm - should be changed to reflect that you can override > them > >> using the added properties? This isn't a big deal but maybe someone > feels > >> that's important.) > > > > > > Still breaks backward compatibility. > > I fail to see how, can you provide more details? You can use ordered, unnamed properties to configure filters (-vf colorspace=bt709:bt709:jpeg is identical to -vf colorspace=all=bt709:space=bt709:range=jpeg; this probably shows how range should've been before space to be especially useful, but whatever), and that breaks after this patch because you changed the ordering. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] MAINTAINERS: Add myself for alsdec
On Mon, Aug 29, 2016 at 10:58:46PM +0530, Umair Khan wrote: > Hi, > > Patch attached. > > - Umair > MAINTAINERS |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > 6d3177b33447c480236a1519270e13ec7ed67b7a > 0001-MAINTAINERS-Add-myself-for-alsdec.patch > From b5bb6b16c313dd84857bf41cd61ced31b254f171 Mon Sep 17 00:00:00 2001 > From: Umair Khan > Date: Mon, 29 Aug 2016 22:55:54 +0530 > Subject: [PATCH] MAINTAINERS: Add myself for alsdec applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch libavformat/crypto to add seek when reading
hmm... not sure i understand fate, even after a quick look. Is there an explanation more complete than on the website? I'm guessing that the ideal test for this would be to exercise the url functions directly from code; e.g.: 1. write some known data through crypto:, compare with pre-prepared output of openssl. 2. read the same data linearly through crypto: , and check it's the same as it should be. 3. read the same data non-linearly through crypto: , and check it's the same as it should be. 4. try to write some known data with seek, and expect failure? Seems fate has some dedicated test programs; libavformat/tests/aes.c may be a good example to start with? Seems to just return 0 if OK, and 1 if fail? s On Tue, Aug 30, 2016 at 4:17 PM, Michael Niedermayer wrote: > On Tue, Aug 30, 2016 at 09:47:12AM +0100, Simon H wrote: > > > > > crypto.c | 116 ++ > +++-- > > 1 file changed, 114 insertions(+), 2 deletions(-) > > a8d9d6638d0be86896de1cb2fa5f9a9f60d7b3c3 libavformat-crypto-add-seek. > patch > > From a0c4d274b2b1712e6ca26a18083edccb55032b94 Mon Sep 17 00:00:00 2001 > > From: Simon Hailes > > Date: Tue, 30 Aug 2016 09:40:14 +0100 > > Subject: [PATCH] cyrpto allows reading of data which has been aes-128-cbc > > encrypted given a key and an iv. But it did not handle filetypes which > > require seeking... e.g. it failed on an encrypted .mp4 file. > > > > example: > > take 25.mp4 created with: > > ffmpeg -f lavfi -i sine=frequency=1000:beep_ > factor=2:r=48000:duration=720.0 -f lavfi -i > testsrc=duration=720.0:rate=25 -vcodec libx264 -cmp 22 -timecode > 10:00:00:00 -r 25 -y out\25.mp4 > > > > encrypt with: > > openssl enc -aes-128-cbc -K 12345678901234567890123456789012 -iv > 12345678901234567890123456789012 -in 25.mp4 -out 25.enc > > then to transcode in ffmpeg: > > ffmpeg -key 12345678901234567890123456789012 -iv > 12345678901234567890123456789012 -i crypto:25.enc -vcodec mpeg4 -r 25 -y > 25dec.mp4 > > > > prior to this modification, the transcode would fail. > > > > Note also: crypto previously maked both reads and writes as streamed, > which caused the whole file > > to be read before the transcode started. Now, for read only, if the > underlying layer is not marked as streamed, > > then crypto is not. This should enable efficient reading of encrypted > containers which require seeking. > > --- > > libavformat/crypto.c | 116 ++ > - > > 1 file changed, 114 insertions(+), 2 deletions(-) > > applied > > can you add a fate test for this case ? > > thanks > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > When you are offended at any man's fault, turn to yourself and study your > own failings. Then you will forget your anger. -- Epictetus > > ___ > 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] HLS Segmenter and the "hls_time" option
On Fri, Aug 26, 2016 at 2:06 AM, Steven Liu wrote: > 2016-08-26 16:58 GMT+08:00 Ibrahim Tachijian : > > > Thanks this actually does what I expected it to do. > > For me this option will help a lot, and we would really be interested in > > this eventually reaching git. > > > > Thanks to Steven Liu's patch we will be able to use this to start live > > streams faster. Great job! > > > > Below follows what command I ran and the output m3u8 playlist. > > > > /root/ffmpeg_patched -analyzeduration 100 -i udp://MCAST_ADDR:3301 > -map > > 0:0 -map 0:1 -c:v libx264 -preset superfast -g 25 -b:v 900k -maxrate 900k > > -bufsize 2000k -filter:v yadif -c:a libfdk_aac -b:a 64k -hls_time 5 > > *-hls_init_time > > 1* -hls_list_size 10 -hls_allow_cache 0 -hls_flags delete_segments -f hls > > /tmp/playlist.m3u8 > > > > The output M3U8 of patched ffmpeg: > > > > #EXTM3U > > #EXT-X-VERSION:3 > > #EXT-X-ALLOW-CACHE:NO > > #EXT-X-TARGETDURATION:5 > > #EXT-X-MEDIA-SEQUENCE:3 > > #EXTINF:1.00, > > playlist3.ts > > #EXTINF:1.00, > > playlist4.ts > > #EXTINF:1.00, > > playlist5.ts > > #EXTINF:1.00, > > playlist6.ts > > #EXTINF:1.00, > > playlist7.ts > > #EXTINF:1.00, > > playlist8.ts > > #EXTINF:1.60, > > playlist9.ts > > #EXTINF:1.00, > > playlist10.ts > > #EXTINF:4.00, > > playlist11.ts > > #EXTINF:5.00, > > playlist12.ts > > > > > > On Fri, Aug 26, 2016 at 8:37 AM Steven Liu > > wrote: > > > > > 2016-08-26 14:00 GMT+08:00 Steven Liu : > > > > > > > > > > > > > > > 2016-08-26 10:34 GMT+08:00 Ibrahim Tachijian : > > > > > > > >> In my use case scenario I only need it for the very first couple of > > > >> segments. > > > >> After 5 segments it is not a problem anymore to have 5 second > segments > > > >> only. > > > >> > > > >> > > > >> > > > >> On Fri, Aug 26, 2016 at 4:25 AM Steven Liu > > > > >> wrote: > > > >> > > > >> > 2016-08-26 10:10 GMT+08:00 Ibrahim Tachijian : > > > >> > > > > >> > > yes that is correct Steven. > > > >> > > > > > >> > > On Fri, Aug 26, 2016 at 3:41 AM Steven Liu < > > lingjiujia...@gmail.com > > > > > > > >> > > wrote: > > > >> > > > > > >> > > > 2016-08-26 8:17 GMT+08:00 Ibrahim Tachijian >: > > > >> > > > > > > >> > > > > Steven, I am not sure you understood me correctly or > perhaps I > > > did > > > >> > not > > > >> > > > > explain myself optimally. > > > >> > > > > > > > >> > > > > We still want to split by keyframe in a normal fashion. But, > > for > > > >> > > example, > > > >> > > > > would like the first 5 segments to have an "hls_time" of 1s > > and > > > >> the > > > >> > > rest > > > >> > > > of > > > >> > > > > the segments after the first 5 to have an "hls_time" of 5s. > > > >> > > > > > > > >> > > > > An made up option would be (hls_time_initial Seconds,Number) > > > >> > > > > > > > >> > > > >- "-hls_time_initial 1,5 -hls_time 5" > > > >> > > > > > > > >> > > > > The output playlist would contain segments (split at > > keyframes) > > > 5 > > > >> > > > segments > > > >> > > > > of length 1s and then any segment after the initial 5 > segment > > > >> would > > > >> > be > > > >> > > > 5s. > > > >> > > > > > > > >> > > > > Is it clear what I am trying to explain? > > > >> > > > > > > > >> > > > > What do you think? Do you know how this can be achieved? > > > >> > > > > > > > >> > > > > Thanks, > > > >> > > > > > > > >> > > > > On Fri, Aug 26, 2016 at 2:06 AM Steven Liu < > > > >> lingjiujia...@gmail.com> > > > >> > > > > wrote: > > > >> > > > > > > > >> > > > > > 2016-08-26 7:39 GMT+08:00 Ibrahim Tachijian < > > bar...@netsat.se > > > >: > > > >> > > > > > > > > >> > > > > > > Hello, > > > >> > > > > > > > > > >> > > > > > > I've been thinking about an option for "hls_time" that > is > > > not > > > >> > > > currently > > > >> > > > > > > supported by FFMpeg and I would like feedback to if some > > of > > > >> you > > > >> > may > > > >> > > > > think > > > >> > > > > > > this is useful or utterly unnecessary. > > > >> > > > > > > > > > >> > > > > > > I find scenarios where we sometimes want to create an > HLS > > > >> output > > > >> > > and > > > >> > > > > > would > > > >> > > > > > > like the *first couple of segments* to be shorter than > the > > > >> *rest > > > >> > of > > > >> > > > the > > > >> > > > > > > segments.* > > > >> > > > > > > > > > >> > > > > > > For example starting off with 1s segments up to N > segments > > > >> then > > > >> > > > switch > > > >> > > > > to > > > >> > > > > > > 5s segments. > > > >> > > > > > > > > > >> > > > > > > The reasoning is simply to have the playlist.m3u8 and > > first > > > >> > segment > > > >> > > > > > > available *asap.* > > > >> > > > > > > > > > >> > > > > > > What do you think? Do you know how this can be achieved? > > > >> > > > > > > > > > >> > > > > > > Thanks, > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > ffmpeg split segment use hlsenc by keyframe, if you want > to > > > >> split > > > >> > > > segment > > > >> > > > > > *ASAP*, > > > >> > > > > > you can try set
Re: [FFmpeg-devel] Patch libavformat/crypto to add seek when reading
On Tue, Aug 30, 2016 at 06:04:57PM +0100, Simon H wrote: > hmm... not sure i understand fate, even after a quick look. Is there an > explanation more complete than on the website? the code and git log > > I'm guessing that the ideal test for this would be to exercise the url > functions directly from code; e.g.: > 1. write some known data through crypto:, compare with pre-prepared output > of openssl. md5 is better than storing large reference data > 2. read the same data linearly through crypto: , and check it's the same as > it should be. > 3. read the same data non-linearly through crypto: , and check it's the > same as it should be. yes > 4. try to write some known data with seek, and expect failure? maybe > > Seems fate has some dedicated test programs; libavformat/tests/aes.c may be > a good example to start with? > Seems to just return 0 if OK, and 1 if fail? a dedicated test would be possible, testing with ffmpeg -i crypto:// or similar might be easier though thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Possible long(er?) term support
On Samstag, 27. August 2016 23:37:09 CEST Dominik 'Rathann' Mierzejewski wrote: > On Saturday, 27 August 2016 at 12:48, Michael Niedermayer wrote: > > which other distros use 2.8 ? (that is distro releases which will not/ > > cannot upgrade to 3.*) > > I can see 2.8.6 in Gentoo (marked as stable, with 3.x as testing). Note that the 3.x version are masked (similar to unstable, indicating that they break other things). See here [1] and here [2] for details. If all bugs are fixed, 3.x will be stabilized, I think. Gerion [1] https://packages.gentoo.org/packages/media-video/ffmpeg [2] https://bugs.gentoo.org/show_bug.cgi?id=574788 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Evolution of lavfi's design and API
Le quartidi 14 fructidor, an CCXXIV, Paul B Mahol a écrit : > the filter frame multithreading would just internally, in filter context > cache frames, once enough frames are in cache - call workers and be done, > repeat. At eof call workers on remaining frames in cache. I have no idea how much thought you have already given to it, but I am pretty sure it is not as simple as that with the current architecture. By far. In the meantime, I finally got the non-recursive version passing FATE. Here are the raw patch, so that people can have an idea what this is all about. There is still a lot of cleanup and documentation to do, as you can see. Regards, -- Nicolas George From b73206d61b94f5b3c2cd854d901c2a59c423bcde Mon Sep 17 00:00:00 2001 From: Nicolas George Date: Tue, 30 Aug 2016 20:12:20 +0200 Subject: [PATCH 1/4] fate/colorkey: disable audio stream. The test is not supposed to cover audio. Also, using -vframes along with an audio stream depends on the exact order the frames are processed by filters, it is too much constraint to guarantee. Signed-off-by: Nicolas George --- tests/fate/ffmpeg.mak | 2 +- tests/ref/fate/ffmpeg-filter_colorkey | 9 - 2 files changed, 1 insertion(+), 10 deletions(-) diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak index 3b91c12..60f1303 100644 --- a/tests/fate/ffmpeg.mak +++ b/tests/fate/ffmpeg.mak @@ -20,7 +20,7 @@ fate-ffmpeg-filter_complex: CMD = framecrc -filter_complex color=d=1:r=5 -fflags FATE_SAMPLES_FFMPEG-$(CONFIG_COLORKEY_FILTER) += fate-ffmpeg-filter_colorkey fate-ffmpeg-filter_colorkey: tests/data/filtergraphs/colorkey -fate-ffmpeg-filter_colorkey: CMD = framecrc -idct simple -fflags +bitexact -flags +bitexact -sws_flags +accurate_rnd+bitexact -i $(TARGET_SAMPLES)/cavs/cavs.mpg -fflags +bitexact -flags +bitexact -sws_flags +accurate_rnd+bitexact -i $(TARGET_SAMPLES)/lena.pnm -filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/colorkey -sws_flags +accurate_rnd+bitexact -fflags +bitexact -flags +bitexact -qscale 2 -vframes 10 +fate-ffmpeg-filter_colorkey: CMD = framecrc -idct simple -fflags +bitexact -flags +bitexact -sws_flags +accurate_rnd+bitexact -i $(TARGET_SAMPLES)/cavs/cavs.mpg -fflags +bitexact -flags +bitexact -sws_flags +accurate_rnd+bitexact -i $(TARGET_SAMPLES)/lena.pnm -an -filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/colorkey -sws_flags +accurate_rnd+bitexact -fflags +bitexact -flags +bitexact -qscale 2 -vframes 10 FATE_FFMPEG-$(CONFIG_COLOR_FILTER) += fate-ffmpeg-lavfi fate-ffmpeg-lavfi: CMD = framecrc -lavfi color=d=1:r=5 -fflags +bitexact diff --git a/tests/ref/fate/ffmpeg-filter_colorkey b/tests/ref/fate/ffmpeg-filter_colorkey index 9fbdfeb..effc13b 100644 --- a/tests/ref/fate/ffmpeg-filter_colorkey +++ b/tests/ref/fate/ffmpeg-filter_colorkey @@ -3,17 +3,8 @@ #codec_id 0: rawvideo #dimensions 0: 720x576 #sar 0: 0/1 -#tb 1: 1/48000 -#media_type 1: audio -#codec_id 1: pcm_s16le -#sample_rate 1: 48000 -#channel_layout 1: 3 0, 0, 0,1, 622080, 0x4e30accb -1, 0, 0, 1152, 4608, 0x -1, 1152, 1152, 1152, 4608, 0xbca29063 0, 1, 1,1, 622080, 0x7d941c14 -1, 2304, 2304, 1152, 4608, 0x6e70df10 -1, 3456, 3456, 1152, 4608, 0x95e6a535 0, 2, 2,1, 622080, 0xf7451c5b 0, 3, 3,1, 622080, 0xb2c74319 0, 4, 4,1, 622080, 0xc9b80b79 -- 2.9.3 From b55d3b23665663ef61435c19b4a722740e048284 Mon Sep 17 00:00:00 2001 From: Nicolas George Date: Tue, 30 Aug 2016 15:28:41 +0200 Subject: [PATCH 2/4] lavfi: split frame_count between input and output. AVFilterLink.frame_count is supposed to count the number of frames that were passed on the link, but with min_samples, that number is not always the same for the source and destination filters. With the addition of a FIFO on the link, the difference will become more significant. Split the variable in two: frame_count_in counts the number of frames that entered the link, frame_count_out counts the number of frames that were sent to the destination filter. Signed-off-by: Nicolas George --- libavfilter/af_ashowinfo.c | 2 +- libavfilter/af_volume.c | 2 +- libavfilter/asrc_sine.c | 2 +- libavfilter/avf_showfreqs.c | 4 ++-- libavfilter/avfilter.c | 5 +++-- libavfilter/avfilter.h | 2 +- libavfilter/f_loop.c | 2 +- libavfilter/f_metadata.c | 4 ++-- libavfilter/f_select.c | 2 +- libavfilter/f_streamselect.c | 2 +- libavfilter/vf_bbox.c| 2 +- libavfilter/vf_blackdetect.c | 2 +- libavfilter/vf_blend.c | 2 +- libavfilter/vf_crop.c| 2 +- libavfilter/vf_decimate.c| 2 +- libavfilter/vf_detelecine.c | 2 +- libavfilter/vf_drawtext.c| 4 ++-- libavfilter/vf_eq.c | 2 +- libavfilter/vf_fade.c| 8 libavf
Re: [FFmpeg-devel] [PATCH] swscale: add support for P010LE/BE output
On Mon, Aug 29, 2016 at 11:23:00PM +0200, Timo Rothenpieler wrote: > --- > libswscale/output.c | 98 > +++- > libswscale/utils.c | 4 +- > libswscale/x86/swscale.c | 4 +- > tests/ref/fate/filter-pixdesc-p010be | 1 + > tests/ref/fate/filter-pixdesc-p010le | 1 + > tests/ref/fate/filter-pixfmts-copy | 2 + > tests/ref/fate/filter-pixfmts-crop | 2 + > tests/ref/fate/filter-pixfmts-field | 2 + > tests/ref/fate/filter-pixfmts-hflip | 2 + > tests/ref/fate/filter-pixfmts-il | 2 + > tests/ref/fate/filter-pixfmts-null | 2 + > tests/ref/fate/filter-pixfmts-pad| 1 + > tests/ref/fate/filter-pixfmts-scale | 2 + > tests/ref/fate/filter-pixfmts-vflip | 2 + > 14 files changed, 120 insertions(+), 5 deletions(-) > create mode 100644 tests/ref/fate/filter-pixdesc-p010be > create mode 100644 tests/ref/fate/filter-pixdesc-p010le breaks fate on mips --- tests/ref/fate/filter-pixfmts-lut 2016-08-30 11:54:39.618278382 +0200 +++ tests/data/fate/filter-pixfmts-lut 2016-08-30 21:08:24.970978353 +0200 @@ -4,10 +4,10 @@ bgra4e2e689897ee7a8e42b16234597bab35 gbrap 0d1eb2c39e291c53c57302cdc653c2fc gbrpe572d53183f3f2ed3951aa9940d440a1 -gbrp10lea8fd1ebbc36a477e2b134241fed91687 -gbrp12lec5a4b89571f7095eb737ad9fd6b1ee08 -gbrp14lebdfdfd6f36c60497d1cdae791f3cc117 -gbrp9le a8c4e29f4cb627db81ba053e0853e702 +gbrp10be238c5d6171910f27805da2f3ee405580 +gbrp12be69fd44411fb2a437e61fbcd1a23729bb +gbrp14be3c40e3b99fce7415d045f50193a0189a +gbrp9be 9c3d8e525100359059f13f692833b6f4 rgb24 a356171207723a580e7d277078072005 rgb48le 5c7dd8575836d18c91e09f1915cf9aa9 rgba7bc854c2698b78af3e9159a19c2d9d21 Test filter-pixfmts-lut failed. Look at tests/data/fate/filter-pixfmts-lut.err for details. make: *** [fate-filter-pixfmts-lut] Error 1 make: *** Waiting for unfinished jobs --- tests/ref/fate/filter-pixfmts-pad 2016-08-30 20:50:57.806956293 +0200 +++ tests/data/fate/filter-pixfmts-pad 2016-08-30 21:08:28.058978418 +0200 @@ -15,7 +15,7 @@ gray16le468bda6155bdc7a7a20c34d6e599fd16 nv12381574979cb04be10c9168540310afad nv210fdeb2cdd56cf5a7147dc273456fa217 -p010le bc516038fd968b9e389f9df05851fbcb +p010le e494e9ddd9ee778d5a0014449a45cf51 rgb078d500c8361ab6423a4826a00268c908 rgb24 17f9e2e0c609009acaf2175c42d4a2a5 rgbab157c90191463d34fb3ce77b36c96386 Test filter-pixfmts-pad failed. Look at tests/data/fate/filter-pixfmts-pad.err for details. make: *** [fate-filter-pixfmts-pad] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] CNG (consistent noise generation) idea
I have some spare time again, I'd like to reimplement the "consistent noise generation" patch I made awhile back. To clarify what that is, some codecs use pseudo-random noise generation in the decoding process (noise bands). The idea is to enable seeding that pseudo-random generator with the bytes of the audio frame so that the decoded output is always the same given the same compressed audio data. I'm not concerned with noise generation given silent audio blocks since silent audio blocks have no sound anyway. Software that needs consistent decoding (like NLE editing software) can enable this option. Last time my patch was rejected because it used the flags field of the AVContext. I understand that the FFMPEG project would rather have it an option given through the av options dictionary instead, correct? I'm thinking the avoption should be named "cng" as a boolean set to 0 or 1, off by default. Any suggestions? Jonathan Campbell ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] HLS Segmenter and the "hls_time" option
Aman Gupta 于2016年8月31日 周三上午1:48写道： > On Fri, Aug 26, 2016 at 2:06 AM, Steven Liu > wrote: > > > 2016-08-26 16:58 GMT+08:00 Ibrahim Tachijian : > > > > > Thanks this actually does what I expected it to do. > > > For me this option will help a lot, and we would really be interested > in > > > this eventually reaching git. > > > > > > Thanks to Steven Liu's patch we will be able to use this to start live > > > streams faster. Great job! > > > > > > Below follows what command I ran and the output m3u8 playlist. > > > > > > /root/ffmpeg_patched -analyzeduration 100 -i udp://MCAST_ADDR:3301 > > -map > > > 0:0 -map 0:1 -c:v libx264 -preset superfast -g 25 -b:v 900k -maxrate > 900k > > > -bufsize 2000k -filter:v yadif -c:a libfdk_aac -b:a 64k -hls_time 5 > > > *-hls_init_time > > > 1* -hls_list_size 10 -hls_allow_cache 0 -hls_flags delete_segments -f > hls > > > /tmp/playlist.m3u8 > > > > > > The output M3U8 of patched ffmpeg: > > > > > > #EXTM3U > > > #EXT-X-VERSION:3 > > > #EXT-X-ALLOW-CACHE:NO > > > #EXT-X-TARGETDURATION:5 > > > #EXT-X-MEDIA-SEQUENCE:3 > > > #EXTINF:1.00, > > > playlist3.ts > > > #EXTINF:1.00, > > > playlist4.ts > > > #EXTINF:1.00, > > > playlist5.ts > > > #EXTINF:1.00, > > > playlist6.ts > > > #EXTINF:1.00, > > > playlist7.ts > > > #EXTINF:1.00, > > > playlist8.ts > > > #EXTINF:1.60, > > > playlist9.ts > > > #EXTINF:1.00, > > > playlist10.ts > > > #EXTINF:4.00, > > > playlist11.ts > > > #EXTINF:5.00, > > > playlist12.ts > > > > > > > > > On Fri, Aug 26, 2016 at 8:37 AM Steven Liu > > > wrote: > > > > > > > 2016-08-26 14:00 GMT+08:00 Steven Liu : > > > > > > > > > > > > > > > > > > > 2016-08-26 10:34 GMT+08:00 Ibrahim Tachijian : > > > > > > > > > >> In my use case scenario I only need it for the very first couple > of > > > > >> segments. > > > > >> After 5 segments it is not a problem anymore to have 5 second > > segments > > > > >> only. > > > > >> > > > > >> > > > > >> > > > > >> On Fri, Aug 26, 2016 at 4:25 AM Steven Liu < > lingjiujia...@gmail.com > > > > > > > >> wrote: > > > > >> > > > > >> > 2016-08-26 10:10 GMT+08:00 Ibrahim Tachijian >: > > > > >> > > > > > >> > > yes that is correct Steven. > > > > >> > > > > > > >> > > On Fri, Aug 26, 2016 at 3:41 AM Steven Liu < > > > lingjiujia...@gmail.com > > > > > > > > > >> > > wrote: > > > > >> > > > > > > >> > > > 2016-08-26 8:17 GMT+08:00 Ibrahim Tachijian < > bar...@netsat.se > > >: > > > > >> > > > > > > > >> > > > > Steven, I am not sure you understood me correctly or > > perhaps I > > > > did > > > > >> > not > > > > >> > > > > explain myself optimally. > > > > >> > > > > > > > > >> > > > > We still want to split by keyframe in a normal fashion. > But, > > > for > > > > >> > > example, > > > > >> > > > > would like the first 5 segments to have an "hls_time" of > 1s > > > and > > > > >> the > > > > >> > > rest > > > > >> > > > of > > > > >> > > > > the segments after the first 5 to have an "hls_time" of > 5s. > > > > >> > > > > > > > > >> > > > > An made up option would be (hls_time_initial > Seconds,Number) > > > > >> > > > > > > > > >> > > > >- "-hls_time_initial 1,5 -hls_time 5" > > > > >> > > > > > > > > >> > > > > The output playlist would contain segments (split at > > > keyframes) > > > > 5 > > > > >> > > > segments > > > > >> > > > > of length 1s and then any segment after the initial 5 > > segment > > > > >> would > > > > >> > be > > > > >> > > > 5s. > > > > >> > > > > > > > > >> > > > > Is it clear what I am trying to explain? > > > > >> > > > > > > > > >> > > > > What do you think? Do you know how this can be achieved? > > > > >> > > > > > > > > >> > > > > Thanks, > > > > >> > > > > > > > > >> > > > > On Fri, Aug 26, 2016 at 2:06 AM Steven Liu < > > > > >> lingjiujia...@gmail.com> > > > > >> > > > > wrote: > > > > >> > > > > > > > > >> > > > > > 2016-08-26 7:39 GMT+08:00 Ibrahim Tachijian < > > > bar...@netsat.se > > > > >: > > > > >> > > > > > > > > > >> > > > > > > Hello, > > > > >> > > > > > > > > > > >> > > > > > > I've been thinking about an option for "hls_time" that > > is > > > > not > > > > >> > > > currently > > > > >> > > > > > > supported by FFMpeg and I would like feedback to if > some > > > of > > > > >> you > > > > >> > may > > > > >> > > > > think > > > > >> > > > > > > this is useful or utterly unnecessary. > > > > >> > > > > > > > > > > >> > > > > > > I find scenarios where we sometimes want to create an > > HLS > > > > >> output > > > > >> > > and > > > > >> > > > > > would > > > > >> > > > > > > like the *first couple of segments* to be shorter than > > the > > > > >> *rest > > > > >> > of > > > > >> > > > the > > > > >> > > > > > > segments.* > > > > >> > > > > > > > > > > >> > > > > > > For example starting off with 1s segments up to N > > segments > > > > >> then > > > > >> > > > switch > > > > >> > > > > to > > > > >> > > > > > > 5s segments. > > > > >> > > > > > > > > > > >> > > > > > > The reasoning is simply to have the playlist.m3u8 and > > > firs
Re: [FFmpeg-devel] [PATCH] configure: improve logic and checks for nvenc
On 8/30/2016 8:00 AM, Timo Rothenpieler wrote:
> ---
> configure | 37 +
> 1 file changed, 25 insertions(+), 12 deletions(-)
>
> diff --git a/configure b/configure
> index 52931c3..bcfc9a8 100755
> --- a/configure
> +++ b/configure
> @@ -5992,20 +5992,33 @@ enabled vdpau && enabled xlib &&
> check_lib2 "vdpau/vdpau.h vdpau/vdpau_x11.h" vdp_device_create_x11
> -lvdpau &&
> enable vdpau_x11
>
> -case $target_os in
> -mingw32*|mingw64*|win32|win64|linux|cygwin*)
> -disabled nvenc || enable nvenc
> -;;
> -*)
> -disable nvenc
> -;;
> -esac
> -
> -if enabled nvenc; then
> +if ! enabled x86; then
> +enabled nvenc && die "NVENC is only supported on x86"
> +disable nvenc
> +elif ! disabled nvenc; then
> {
> echo '#include "compat/nvenc/nvEncodeAPI.h"'
> -echo 'int main(void) { return 0; }'
> -} | check_cc -I$source_path || disable nvenc
> +echo 'NV_ENCODE_API_FUNCTION_LIST flist;'
> +echo 'void f(void) { struct { const GUID guid; } s[] = { {
> NV_ENC_PRESET_HQ_GUID } }; }'
This will most likely prevent nvenc from being enabled for msvc 2012, but not
old
mingw32, which is failing with the error:
src/libavcodec/nvenc.c:115:52: error: 'ENOBUFS' undeclared here (not in a
function)
{ NV_ENC_ERR_NOT_ENOUGH_BUFFER,AVERROR(ENOBUFS), "not enough
buffer"},
I think the easiest solution would be using AVERROR_BUFFER_TOO_SMALL if ENOBUFS
is
not defined.
That or just disable nvenc if using mingw32 toolchains by checking "enabled
libc_mingw32", since disabling for target-os == mingw32 would also affect
mingw-w64.
gcc-asan fails with
/usr/bin/ld: libavcodec/libavcodec.a(nvenc.o): undefined reference to symbol
'dlsym@@GLIBC_2.2.5'
/usr/lib/../lib/libdl.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
I have no idea how to deal with this.
> +echo 'int main(void) { f(); return 0; }'
> +} | check_cc -I$source_path
> +nvenc_check_res=$?
> +
> +if [ $nvenc_check_res != 0 ] && enabled nvenc; then
> +die "NVENC enabled but test-compile failed"
> +fi
> +
> +case $target_os in
> +mingw32*|mingw64*|win32|win64|linux|cygwin*)
> +[ $nvenc_check_res = 0 ] && enable nvenc
> +;;
> +*)
> +enabled nvenc && die "NVENC is only supported on Windows and
> Linux"
> +disable nvenc
> +;;
> +esac
> +
> +unset nvenc_check_res
This test is different from other automatically detected features, and also
unnecessarily complex.
You should force enable nvenc earlier in the script like with other similar
features (including hardware codecs and accelerators), then disable it on
unsupported platforms and old/broken compilers with the corresponding checks
and tests.
Something like this:
--
diff --git a/configure b/configure
index 52931c3..a09aa6e 100755
--- a/configure
+++ b/configure
@@ -3205,7 +3205,7 @@ enable audiotoolbox
enable d3d11va dxva2 vaapi vda vdpau videotoolbox_hwaccel xvmc
enable xlib
-enable vda_framework videotoolbox videotoolbox_encoder
+enable nvenc vda_framework videotoolbox videotoolbox_encoder
# build settings
SHFLAGS='-shared -Wl,-soname,$$(@F)'
@@ -5992,22 +5992,25 @@ enabled vdpau && enabled xlib &&
check_lib2 "vdpau/vdpau.h vdpau/vdpau_x11.h" vdp_device_create_x11 -lvdpau
&&
enable vdpau_x11
-case $target_os in
-mingw32*|mingw64*|win32|win64|linux|cygwin*)
-disabled nvenc || enable nvenc
-;;
-*)
-disable nvenc
-;;
-esac
-
-if enabled nvenc; then
-{
-echo '#include "compat/nvenc/nvEncodeAPI.h"'
-echo 'int main(void) { return 0; }'
-} | check_cc -I$source_path || disable nvenc
+if enabled x86; then
+case $target_os in
+mingw32*|mingw64*|win32|win64|linux|cygwin*)
+;;
+*)
+disable nvenc
+;;
+esac
+else
+disable nvenc
fi
+enabled nvenc &&
+check_cc -I$source_path
Re: [FFmpeg-devel] HLS Segmenter and the "hls_time" option
2016-08-31 1:48 GMT+08:00 Aman Gupta : > On Fri, Aug 26, 2016 at 2:06 AM, Steven Liu > wrote: > > > 2016-08-26 16:58 GMT+08:00 Ibrahim Tachijian : > > > > > Thanks this actually does what I expected it to do. > > > For me this option will help a lot, and we would really be interested > in > > > this eventually reaching git. > > > > > > Thanks to Steven Liu's patch we will be able to use this to start live > > > streams faster. Great job! > > > > > > Below follows what command I ran and the output m3u8 playlist. > > > > > > /root/ffmpeg_patched -analyzeduration 100 -i udp://MCAST_ADDR:3301 > > -map > > > 0:0 -map 0:1 -c:v libx264 -preset superfast -g 25 -b:v 900k -maxrate > 900k > > > -bufsize 2000k -filter:v yadif -c:a libfdk_aac -b:a 64k -hls_time 5 > > > *-hls_init_time > > > 1* -hls_list_size 10 -hls_allow_cache 0 -hls_flags delete_segments -f > hls > > > /tmp/playlist.m3u8 > > > > > > The output M3U8 of patched ffmpeg: > > > > > > #EXTM3U > > > #EXT-X-VERSION:3 > > > #EXT-X-ALLOW-CACHE:NO > > > #EXT-X-TARGETDURATION:5 > > > #EXT-X-MEDIA-SEQUENCE:3 > > > #EXTINF:1.00, > > > playlist3.ts > > > #EXTINF:1.00, > > > playlist4.ts > > > #EXTINF:1.00, > > > playlist5.ts > > > #EXTINF:1.00, > > > playlist6.ts > > > #EXTINF:1.00, > > > playlist7.ts > > > #EXTINF:1.00, > > > playlist8.ts > > > #EXTINF:1.60, > > > playlist9.ts > > > #EXTINF:1.00, > > > playlist10.ts > > > #EXTINF:4.00, > > > playlist11.ts > > > #EXTINF:5.00, > > > playlist12.ts > > > > > > > > > On Fri, Aug 26, 2016 at 8:37 AM Steven Liu > > > wrote: > > > > > > > 2016-08-26 14:00 GMT+08:00 Steven Liu : > > > > > > > > > > > > > > > > > > > 2016-08-26 10:34 GMT+08:00 Ibrahim Tachijian : > > > > > > > > > >> In my use case scenario I only need it for the very first couple > of > > > > >> segments. > > > > >> After 5 segments it is not a problem anymore to have 5 second > > segments > > > > >> only. > > > > >> > > > > >> > > > > >> > > > > >> On Fri, Aug 26, 2016 at 4:25 AM Steven Liu < > lingjiujia...@gmail.com > > > > > > > >> wrote: > > > > >> > > > > >> > 2016-08-26 10:10 GMT+08:00 Ibrahim Tachijian >: > > > > >> > > > > > >> > > yes that is correct Steven. > > > > >> > > > > > > >> > > On Fri, Aug 26, 2016 at 3:41 AM Steven Liu < > > > lingjiujia...@gmail.com > > > > > > > > > >> > > wrote: > > > > >> > > > > > > >> > > > 2016-08-26 8:17 GMT+08:00 Ibrahim Tachijian < > bar...@netsat.se > > >: > > > > >> > > > > > > > >> > > > > Steven, I am not sure you understood me correctly or > > perhaps I > > > > did > > > > >> > not > > > > >> > > > > explain myself optimally. > > > > >> > > > > > > > > >> > > > > We still want to split by keyframe in a normal fashion. > But, > > > for > > > > >> > > example, > > > > >> > > > > would like the first 5 segments to have an "hls_time" of > 1s > > > and > > > > >> the > > > > >> > > rest > > > > >> > > > of > > > > >> > > > > the segments after the first 5 to have an "hls_time" of > 5s. > > > > >> > > > > > > > > >> > > > > An made up option would be (hls_time_initial > Seconds,Number) > > > > >> > > > > > > > > >> > > > >- "-hls_time_initial 1,5 -hls_time 5" > > > > >> > > > > > > > > >> > > > > The output playlist would contain segments (split at > > > keyframes) > > > > 5 > > > > >> > > > segments > > > > >> > > > > of length 1s and then any segment after the initial 5 > > segment > > > > >> would > > > > >> > be > > > > >> > > > 5s. > > > > >> > > > > > > > > >> > > > > Is it clear what I am trying to explain? > > > > >> > > > > > > > > >> > > > > What do you think? Do you know how this can be achieved? > > > > >> > > > > > > > > >> > > > > Thanks, > > > > >> > > > > > > > > >> > > > > On Fri, Aug 26, 2016 at 2:06 AM Steven Liu < > > > > >> lingjiujia...@gmail.com> > > > > >> > > > > wrote: > > > > >> > > > > > > > > >> > > > > > 2016-08-26 7:39 GMT+08:00 Ibrahim Tachijian < > > > bar...@netsat.se > > > > >: > > > > >> > > > > > > > > > >> > > > > > > Hello, > > > > >> > > > > > > > > > > >> > > > > > > I've been thinking about an option for "hls_time" that > > is > > > > not > > > > >> > > > currently > > > > >> > > > > > > supported by FFMpeg and I would like feedback to if > some > > > of > > > > >> you > > > > >> > may > > > > >> > > > > think > > > > >> > > > > > > this is useful or utterly unnecessary. > > > > >> > > > > > > > > > > >> > > > > > > I find scenarios where we sometimes want to create an > > HLS > > > > >> output > > > > >> > > and > > > > >> > > > > > would > > > > >> > > > > > > like the *first couple of segments* to be shorter than > > the > > > > >> *rest > > > > >> > of > > > > >> > > > the > > > > >> > > > > > > segments.* > > > > >> > > > > > > > > > > >> > > > > > > For example starting off with 1s segments up to N > > segments > > > > >> then > > > > >> > > > switch > > > > >> > > > > to > > > > >> > > > > > > 5s segments. > > > > >> > > > > > > > > > > >> > > > > > > The reasoning is simply to have the playlist.m3u8 and > > >
Re: [FFmpeg-devel] [PATCH] added expr evaluation to drawtext - fontsize
Since there are differing opinions on how the default fontsize should be established this patch adds my changes while preserving the current behavior when fontsize is not specified. On Tue, Aug 30, 2016 at 2:43 AM, Nicolas George wrote: > Le tridi 13 fructidor, an CCXXIV, Brett Harrison a écrit : > > Before I fix the patch, can you clarify the intended functionality? > > > > The docs say that 16 is the default fontsize, however if > > CONFIG_LIBFONTCONFIG is configured and ffmpeg if called with: > > > > -vf drawtext=text=abc:fontcolor=white > > > > on my system the font used will be /opt/X11/share/fonts/TTF/Vera.ttf > (the > > default chosen by libfontconfig) and the fontsize will be set to 12. > > > > However if ffmpeg is called with: > > > > -vf > > drawtext=text=abc:fontcolor=white:fontfile=/opt/X11/share/ > fonts/TTF/Vera.ttf > > > > This is the same font that libfontconfig used, however this time fontsize > > 16 is used as stated in the docs. > > > > The difference is this line of code in load_font_fontconfig > > if (!s->fontsize) > > s->fontsize = size + 0.5; > > > > I didn't set the fontsize in either command, but the output was > different. > > Do we want to keep this as is? > > I think the current behaviour is correct. > > I start with the following principle: when users want something precise > about aesthetic or other arbitrary settings, they have to say it. > > Default values are for the lazy or the careless ones: quick profiling and > testing when the exact result does not matter much. But as soon as the > result matters, explicit values must be given. > > Do not take me wrong, the default values should be, as much as possible, > sensible. But for a font size, 12 is as sensible as 16. > > Most importantly, backward compatibility should not be an hindrance to > choosing better default values. We should not change them lightly, but not > feel forbidden to do so either. > > Fontconfig is not just a path search library for finding font files. It is > a > complete mechanism for choosing the right font according to several > conditions set by the user. Including the font size. > > There are no less than four levels for choosing the font size: > > (1) lavfi's default, 16; > > (2) fontconfig's default; > > (3) fontconfig's explicit value, as in "Times-12:bold"; > > (4) lavfi's explicit value, as in "fontsize=16". > > I think the order of precedence should be just that, for the following > reasons: > > - First, of course, (3), (4) > (1), (2), because explicit values are always > more important. > > - Second, conflicting explicit values are the users' problem. We can > produce > warnings to help diagnose, but in the end it is their choice. (4) > (3) > is > slightly easier to implement (distinguishing (3) from (2) requires a bit > of work), and (4) is more supple, especially when your patch gets > applied. > > - Last, (2) > (1), because fontconfig is more cross-applications than > lavfi, > and also because it includes a mechanism for explicit configuration. > > Still, the documentation should be clarified, possibly something like that: > "The default value of fontsize is provided by fontconfig if in use or 16 > when using a font file directly." > > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > 0001-added-expr-evaluation-to-drawtext-fontsize.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/opus: Add channel mapping 2 to extradata parser
This allows libavcodec/opus to demux ambisonics in an ogg/opus container.
Channel mapping family 2 is being added in this standards track IETF draft:
tools.ietf.org/html/draft-ietf-codec-ambisonics-00
---
libavcodec/opus.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavcodec/opus.c b/libavcodec/opus.c
index 703d2e8..db758e9 100644
--- a/libavcodec/opus.c
+++ b/libavcodec/opus.c
@@ -328,7 +328,7 @@ av_cold int ff_opus_parse_extradata(AVCodecContext *avctx,
channels = avctx->extradata ? extradata[9] : (avctx->channels == 1) ? 1 :
2;
if (!channels) {
-av_log(avctx, AV_LOG_ERROR, "Zero channel count specified in the
extadata\n");
+av_log(avctx, AV_LOG_ERROR, "Zero channel count specified in the
extradata\n");
return AVERROR_INVALIDDATA;
}
@@ -347,7 +347,7 @@ av_cold int ff_opus_parse_extradata(AVCodecContext *avctx,
streams= 1;
stereo_streams = channels - 1;
channel_map= default_channel_map;
-} else if (map_type == 1 || map_type == 255) {
+} else if (map_type == 1 || map_type == 2 || map_type == 255) {
if (extradata_size < 21 + channels) {
av_log(avctx, AV_LOG_ERROR, "Invalid extradata size: %d\n",
extradata_size);
@@ -371,6 +371,15 @@ av_cold int ff_opus_parse_extradata(AVCodecContext *avctx,
}
layout = ff_vorbis_channel_layouts[channels - 1];
channel_reorder = channel_reorder_vorbis;
+} else if (map_type == 2) {
+int ambisonic_order = ((int)sqrt(channels)) - 1;
+if (channels != (ambisonic_order + 1) * (ambisonic_order + 1)) {
+av_log(avctx, AV_LOG_ERROR,
+ "Channel mapping 2 is only specified for channel counts"
+ " which can be written as (n + 1)^2 for nonnegative
integer n\n");
+return AVERROR_INVALIDDATA;
+}
+layout = 0;
} else
layout = 0;
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] added expr evaluation to drawtext - fontsize
Hi, On Fri, Aug 26, 2016 at 10:37 PM, Brett Harrison wrote: > Allows expr evaluation in the fontsize parameter for drawtext. Thanks for making this. I regularly use drawtext to create watermarked/timecoded access copies in a moving image archive and I have to use workarounds in scripts in order to make relative font sizes. I'm not sure if this kind of 'thanks' email is against ffmpeg-devel rules as I didn't see it listed here: https://ffmpeg.org/contact.html#MailingLists -Kieran. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_dctdnoiz: add YUV444P support
On Mon, Aug 29, 2016 at 10:00:31PM +0200, Paul B Mahol wrote: > On Mon, Aug 29, 2016 at 8:52 PM, Clément Bœsch wrote: > > > On Mon, Aug 29, 2016 at 07:00:54PM +0200, Paul B Mahol wrote: > > > Hi, > > > > > > patch attached. > > > > The color decorrelation is an important part of the denoising algorithm > > described in http://www.ipol.im/pub/art/2011/ys-dct/ (see 2.3) > > > > Can we really consider the YUV planes as properly decorrelated ones? It > > seems to me that allowing YUV444 means that sometimes the denoising will > > be different (randomly if picked). > > > > -- > > Clément B. > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > They also say that gray should not be (de)correlated at all. in the context where there is a single plane, so of course you don't have anything to decorrelate with. > Y is basically gray. > U/V is already correlated with Y. > U and V are correlated with Y, so with the decorrelation you introduce which is a noop for YUV (IIUC), you will loose the benefit of having the "PSNR improvement from about 1 to 3 dB". > Those number to me look random, they should be set via filter options. you mean the 3-point DCT basis? -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavutil: let clang-FORTIFY build; NFC.
[Re-sending from the right email address...] Good intuition. :) This is all I saw when compiling Chrome; looks like I misconfigured ffmpeg, though, so `make fate` was using GCC to compile things. With the correct configuration, I see a few more errors. I'll send out v2 shortly. Thanks! On Tue, Aug 30, 2016 at 3:05 AM, Michael Niedermayer wrote: > On Tue, Aug 30, 2016 at 12:11:42AM -0700, George Burgess IV wrote: > > ChromeOS is adopting a new FORTIFY implementation tailored for clang. As > > an artifact of how this new FORTIFY is implemented, a handful of > > implicit conversion warnings get turned into errors. This patch fixes > > the implicit conversions in ffmpeg that clang-FORTIFY has an issue with. > > > > Signed-off-by: George Burgess IV > > --- > > libavutil/opt.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > does this patch fix the issue entirely or are there other patches > needed for other files ? > (asking as it seems odd that its just this) > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Observe your enemies, for they first find out your faults. -- Antisthenes > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] Let clang-FORTIFY build; NFC.
ChromeOS is adopting a new FORTIFY implementation tailored for clang. As
an artifact of how this new FORTIFY is implemented, a handful of
implicit conversion warnings get turned into errors. This patch fixes
the implicit conversions in ffmpeg that clang-FORTIFY has an issue with.
Signed-off-by: George Burgess IV
---
If anyone feels that more comments would be useful, I'll add them above some of
the char* casts, so it's a bit more obvious why we have said casts.
Testing methodology was "run `make fate` and see what doesn't build." If there
are other targets that would be good to try, I'm happy to check with those, as
well. :)
libavcodec/pamenc.c | 2 +-
libavcodec/pnmenc.c | 4 ++--
libavcodec/xbmenc.c | 8 +---
libavcodec/xsubenc.c | 2 +-
libavfilter/af_astats.c | 4 ++--
libavfilter/avf_aphasemeter.c | 2 +-
libavformat/flacenc.c | 2 +-
libavformat/http.c| 4 ++--
libavformat/matroskaenc.c | 3 ++-
libavformat/md5proto.c| 3 ++-
libavformat/nutenc.c | 4 ++--
libavformat/rtmppkt.c | 4 ++--
libavutil/hash.c | 2 +-
libavutil/opt.c | 5 +++--
14 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/libavcodec/pamenc.c b/libavcodec/pamenc.c
index 50c9fcb..143d38f 100644
--- a/libavcodec/pamenc.c
+++ b/libavcodec/pamenc.c
@@ -98,7 +98,7 @@ static int pam_encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
bytestream = pkt->data;
bytestream_end = pkt->data + pkt->size;
-snprintf(bytestream, bytestream_end - bytestream,
+snprintf((char *)bytestream, bytestream_end - bytestream,
"P7\nWIDTH %d\nHEIGHT %d\nDEPTH %d\nMAXVAL %d\nTUPLTYPE
%s\nENDHDR\n",
w, h, depth, maxval, tuple_type);
bytestream += strlen(bytestream);
diff --git a/libavcodec/pnmenc.c b/libavcodec/pnmenc.c
index ba9478d..f1bcbc6 100644
--- a/libavcodec/pnmenc.c
+++ b/libavcodec/pnmenc.c
@@ -80,12 +80,12 @@ static int pnm_encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
default:
return -1;
}
-snprintf(bytestream, bytestream_end - bytestream,
+snprintf((char *)bytestream, bytestream_end - bytestream,
"P%c\n%d %d\n", c, avctx->width, h1);
bytestream += strlen(bytestream);
if (avctx->pix_fmt != AV_PIX_FMT_MONOWHITE) {
int maxdepth = (1 <<
av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth) - 1;
-snprintf(bytestream, bytestream_end - bytestream,
+snprintf((char *)bytestream, bytestream_end - bytestream,
"%d\n", maxdepth);
bytestream += strlen(bytestream);
}
diff --git a/libavcodec/xbmenc.c b/libavcodec/xbmenc.c
index b25615f..7f7fbc0 100644
--- a/libavcodec/xbmenc.c
+++ b/libavcodec/xbmenc.c
@@ -28,14 +28,16 @@ static int xbm_encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
const AVFrame *p, int *got_packet)
{
int i, j, ret, size, linesize;
-uint8_t *ptr, *buf;
+// buf is a char* instead of a uint8_t* to make FORTIFY on clang happy.
+char *buf;
+uint8_t *ptr;
linesize = (avctx->width + 7) / 8;
size = avctx->height * (linesize * 7 + 2) + 110;
if ((ret = ff_alloc_packet2(avctx, pkt, size, 0)) < 0)
return ret;
-buf = pkt->data;
+buf = (char *)pkt->data;
ptr = p->data[0];
buf += snprintf(buf, 32, "#define image_width %u\n", avctx->width);
@@ -49,7 +51,7 @@ static int xbm_encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
}
buf += snprintf(buf, 5, " };\n");
-pkt->size = buf - pkt->data;
+pkt->size = (uint8_t *)buf - pkt->data;
pkt->flags |= AV_PKT_FLAG_KEY;
*got_packet = 1;
return 0;
diff --git a/libavcodec/xsubenc.c b/libavcodec/xsubenc.c
index b3da909..a4a8221 100644
--- a/libavcodec/xsubenc.c
+++ b/libavcodec/xsubenc.c
@@ -163,7 +163,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
return -1;
}
-snprintf(buf, 28,
+snprintf((char *)buf, 28,
"[%02d:%02d:%02d.%03d-%02d:%02d:%02d.%03d]",
start_tc[3], start_tc[2], start_tc[1], start_tc[0],
end_tc[3], end_tc[2], end_tc[1], end_tc[0]);
diff --git a/libavfilter/af_astats.c b/libavfilter/af_astats.c
index e7f9675..32c6041 100644
--- a/libavfilter/af_astats.c
+++ b/libavfilter/af_astats.c
@@ -211,8 +211,8 @@ static inline void update_stat(AudioStatsContext *s,
ChannelStats *p, double d,
static void set_meta(AVDictionary **metadata, int chan, const char *key,
const char *fmt, double val)
{
-uint8_t value[128];
-uint8_t key2[128];
+char value[128];
+char key2[128];
snprintf(value, sizeof(value), fmt, val);
if (chan)
diff --git a/libavfilter/avf_aphasemeter.c b/libavfilter/avf_aphasemeter.c
index 8e8b292..4afc6bb 100644
--- a/libavfilter/avf_aphasemeter.c
+++ b/libavfilter/avf_aphasemeter.c
@@ -190,7 +190,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
Re: [FFmpeg-devel] [PATCH v3] lavf : scale_vaapi : add denoise/sharpless support
On 30/08/16 09:00, Jun Zhao wrote:
> v3 : fix sharpless mapping issue
> v2 : fix filter support flag check logic issue
Hi,
A general remark to start: vf_scale_vaapi is named to be a scaling filter (i.e.
it replaces vf_scale/swscale for AV_PIX_FMT_VAAPI) - is this therefore really
the right place to be adding other operations unrelated to scaling?
Do use-cases for these operations actually make sense to add here rather than
in a separate filter? (I'm not sure what the answer to this should be - I
would definitely argue that the deinterlacer should be a separate filter, but
these other operations are unclear.)
> From 415b00c6157d8311cc18713e6347400895f7333c Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Tue, 30 Aug 2016 14:36:00 +0800
> Subject: [PATCH v3] lavf : scale_vaapi : add denoise/sharpless support.
>
> add denoise/sharpless support, used scope [-1, 100] as the input
> scope.
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/vf_scale_vaapi.c | 115
> +++
> 1 file changed, 115 insertions(+)
>
> diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
> index 8dd5acf..5658746 100644
> --- a/libavfilter/vf_scale_vaapi.c
> +++ b/libavfilter/vf_scale_vaapi.c
> @@ -53,6 +53,16 @@ typedef struct ScaleVAAPIContext {
> int output_width;
> int output_height;
>
> +VAProcFilterCap denoise_caps;
> +int support_denoise;
> +int denoise; // enable denoise algo. level is the optional
> + // value from the interval [-1, 100], -1 means
> disabled
> +
> +VAProcFilterCap sharpless_caps;
> +int support_sharpless;
> +int sharpless; // enable sharpless. level is the optional value
> + // from the interval [-1, 100], -1 means disabled
"sharpless"? "sharpness" or "sharpen", might be better. (The filter is called
"sharpening", though maybe it can also blur the image?)
> +
> } ScaleVAAPIContext;
>
>
> @@ -117,6 +127,8 @@ static int scale_vaapi_config_output(AVFilterLink
> *outlink)
> AVVAAPIFramesContext *va_frames;
> VAStatus vas;
> int err, i;
> +unsigned int num_denoise_caps = 1;
> +unsigned int num_sharpless_caps = 1;
>
> scale_vaapi_pipeline_uninit(ctx);
>
> @@ -225,6 +237,29 @@ static int scale_vaapi_config_output(AVFilterLink
> *outlink)
> goto fail;
> }
>
> +vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
> + VAProcFilterNoiseReduction,
> + &ctx->denoise_caps, &num_denoise_caps);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(ctx, AV_LOG_WARNING, "Failed to query denoise caps "
> + "context: %d (%s).\n", vas, vaErrorStr(vas));
> +ctx->support_denoise = 0;
> +} else {
> +ctx->support_denoise = 1;
> +}
> +
> +vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
> + VAProcFilterSharpening,
> + &ctx->sharpless_caps,
> &num_sharpless_caps);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(ctx, AV_LOG_WARNING, "Failed to query sharpless caps "
> + "context: %d (%s).\n", vas, vaErrorStr(vas));
> +ctx->support_sharpless = 0;
> +} else {
> +ctx->support_sharpless = 1;
> +}
If the user explicitly requests these filters that can still be ignored if they
not supported? Maybe it would be better to just give up with an error message
at that point.
Similarly, the warning that they are not supported is unhelpful if the user
didn't ask for them.
> +
> +
> av_freep(&hwconfig);
> av_hwframe_constraints_free(&constraints);
> return 0;
> @@ -250,6 +285,14 @@ static int vaapi_proc_colour_standard(enum AVColorSpace
> av_cs)
> }
> }
>
> +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 scale_vaapi_filter_frame(AVFilterLink *inlink, AVFrame
> *input_frame)
> {
> AVFilterContext *avctx = inlink->dst;
> @@ -259,6 +302,10 @@ static int scale_vaapi_filter_frame(AVFilterLink
> *inlink, AVFrame *input_frame)
> VASurfaceID input_surface, output_surface;
> VAProcPipelineParameterBuffer params;
> VABufferID params_id;
> +VABufferID denoise_id;
> +VABufferID sharpless_id;
> +VABufferID filter_bufs[8];
> +int num_filter_bufs = 0;
> VAStatus vas;
> int err;
>
> @@ -290,6 +337,43 @@ static int scale_vaapi_filter_frame(AVFilterLink
> *inlink, AVFrame *input_frame)
> av_log(ctx, AV_LOG_DEBUG, "Using surface %#x for scale output.\n",
> output_surface);
>
> +if (ctx->denoise != -1 && ctx->support_denoise) {
> +VAProcFilterParameterBuffer denoise;
> +denoise.type = VAProcFilter
Re: [FFmpeg-devel] Evolution of lavfi's design and API
On Tue, Aug 30, 2016 at 09:08:18PM +0200, Nicolas George wrote: > Le quartidi 14 fructidor, an CCXXIV, Paul B Mahol a écrit : > > the filter frame multithreading would just internally, in filter context > > cache frames, once enough frames are in cache - call workers and be done, > > repeat. At eof call workers on remaining frames in cache. > > I have no idea how much thought you have already given to it, but I am > pretty sure it is not as simple as that with the current architecture. By > far. > > In the meantime, I finally got the non-recursive version passing FATE. Here > are the raw patch, so that people can have an idea what this is all about. > There is still a lot of cleanup and documentation to do, as you can see. > > Regards, > > -- > Nicolas George ./ffmpeg -i tickets//679/oversized_pgs_subtitles.mkv -filter_complex '[0:s:1]scale=848x480,[0:v]overlay=shortest=1' test.avi fails assertion: Assertion progress failed at libavfilter/avfilter.c:1391 https://trac.ffmpeg.org/attachment/ticket/679/oversized_pgs_subtitles.mkv ffmpeg -v 0 -i tickets/3539/crash.swf -map 0 -t 1 -f framecrc - output changes, not sure this is a bug but reporting it anyway as i noticed http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3539/ doc/examples/filtering_video matrixbench_mpeg2.mpg also breaks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] Let clang-FORTIFY build; NFC.
Hi, On Tue, Aug 30, 2016 at 6:49 PM, George Burgess IV wrote: > ChromeOS is adopting a new FORTIFY implementation tailored for clang. As > an artifact of how this new FORTIFY is implemented, a handful of > implicit conversion warnings get turned into errors. This patch fixes > the implicit conversions in ffmpeg that clang-FORTIFY has an issue with. Isn't it easier to change your fortify-clang and add a compiler option to disable this specific error for specific targets? (I don't find the casts particularly pretty.) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/2] avisynth: fixes for alpha and planar rgb
When bugtesting AviSynth+ against the patches submitted to libavformat, some issues came up that required changes to avisynth_c.h (which is updated here mostly to match what will be included in upstream avsplus) and the demuxer. Stephen Hutchinson (2): compat/avisynth: minor update for alpha offsets avisynth: fix Planar RGB output compat/avisynth/avisynth_c.h | 8 ++-- libavformat/avisynth.c | 4 +++- 2 files changed, 9 insertions(+), 3 deletions(-) -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avisynth: fix Planar RGB output
---
libavformat/avisynth.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 1fe8e08..1acc44f 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -690,8 +690,10 @@ static int avisynth_read_packet_video(AVFormatContext *s,
AVPacket *pkt,
#ifdef USING_AVISYNTH
/* Flip Planar RGB video. */
if (avsplus && (avs_library.avs_is_planar_rgb(avs->vi) ||
-avs_library.avs_is_planar_rgba(avs->vi)))
+avs_library.avs_is_planar_rgba(avs->vi))) {
+src_p = src_p + (planeheight - 1) * pitch;
pitch = -pitch;
+}
#endif
avs_library.avs_bit_blt(avs->env, dst_p, rowsize, src_p, pitch,
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] compat/avisynth: minor update for alpha offsets
---
compat/avisynth/avisynth_c.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/compat/avisynth/avisynth_c.h b/compat/avisynth/avisynth_c.h
index 605b92a..2f84dd1 100644
--- a/compat/avisynth/avisynth_c.h
+++ b/compat/avisynth/avisynth_c.h
@@ -533,7 +533,11 @@ typedef struct AVS_VideoFrame {
volatile long refcount;
AVS_VideoFrameBuffer * vfb;
int offset, pitch, row_size, height, offsetU, offsetV, pitchUV; // U&V
offsets are from top of picture.
- int row_sizeUV, heightUV;
+ int row_sizeUV, heightUV; // for Planar RGB offsetU, offsetV is for the 2nd
and 3rd Plane.
+// for Planar RGB pitchUV and row_sizeUV = 0,
because when no VideoInfo (MakeWriteable)
+// the decision on existance of UV is checked by
zero pitch
+ // AVS+ extension, avisynth.h: class does not break plugins if appended here
+ int offsetA, pitchA, row_sizeA; // 4th alpha plane support, pitch and
row_size is 0 is none
} AVS_VideoFrame;
// Access functions for AVS_VideoFrame
@@ -753,7 +757,7 @@ enum {
AVS_CPUF_SSSE3 = 0x200, // Core 2
AVS_CPUF_SSE4 = 0x400, // Penryn, Wolfdale, Yorkfield
AVS_CPUF_SSE4_1 = 0x400,
-//AVS_CPUF_AVX= 0x800, // Sandy Bridge, Bulldozer
+ AVS_CPUF_AVX= 0x800, // Sandy Bridge, Bulldozer
AVS_CPUF_SSE4_2= 0x1000, // Nehalem
//AVS_CPUF_AVX2 = 0x2000, // Haswell
//AVS_CPUF_AVX512= 0x4000, // Knights Landing
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] Let clang-FORTIFY build; NFC.
Thanks for the feedback! I agree the casts aren't pretty. :)
> Isn't it easier to change your fortify-clang and add a compiler option to
disable this specific error for specific targets?
The short answer is "in some cases, yes. Sadly, this doesn't seem to be one
of those cases."
The longer answer is that FORTIFY is a thing that's implemented partially
in the compiler, and partially in the standard library (for example, the
canonical FORTIFY implementation* has bits in both gcc and glibc). The
errors this patch is trying to fix originate from the bits in the standard
library, so it's not as simple as checking if the compiler got a flag. At
this point, the least-effort fix would be turning FORTIFY off for
${project_with_errors}. If we wanted to be more granular, we could probably
add #ifndef _DISABLE_FORTIFY_FOR_$functionName for each FORTIFY'ed
function, but:
1. grep tells me there are currently 75 FORTIFY functions, so we would need
75 such flags;
2. it lessens the effectiveness of FORTIFY across the entire project; and
3. the idea of hand-curating a list of per-project+per-function defines,
that can arbitrarily change from release to release, seems kind of ugly in
itself. :/
* - Clang is able to compile things with this gcc-based FORTIFY
implementation enabled. It's not able to do *nearly* as well as GCC,
though, because said impl depends heavily on implementation details of GCC
that don't hold true for clang.
Thanks,
George
On Tue, Aug 30, 2016 at 4:10 PM, Ronald S. Bultje
wrote:
> Hi,
>
> On Tue, Aug 30, 2016 at 6:49 PM, George Burgess IV
> wrote:
>
>> ChromeOS is adopting a new FORTIFY implementation tailored for clang. As
>> an artifact of how this new FORTIFY is implemented, a handful of
>> implicit conversion warnings get turned into errors. This patch fixes
>> the implicit conversions in ffmpeg that clang-FORTIFY has an issue with.
>
>
> Isn't it easier to change your fortify-clang and add a compiler option to
> disable this specific error for specific targets? (I don't find the casts
> particularly pretty.)
>
> Ronald
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add warning for append_list and hls_init_time option
On Tue, Aug 30, 2016 at 05:30:18PM +0800, Steven Liu wrote: > When use append_list mode, the hls_init_time set nouse, > Because the append_list only support append at the old m3u8 end > cannot set init segments durations at the middle of the list. > That's invalid use append_list and hls_init_time one time. > and show a warning message for user. > > Signed-off-by: LiuQi > --- > libavformat/hlsenc.c | 6 ++ > 1 file changed, 6 insertions(+) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/matroskaenc: improve tag-skipping checks
- Add "duration" to list of skipped attributes (we handle that elsewhere)
- Move the list to its own function and make its use consistent
This fixes cases where we'd have a string in one list and not another, which
could result in us writing an empty tag.
---
libavformat/matroskaenc.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 2a2877f..3eeb09b 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1308,6 +1308,17 @@ static int mkv_write_tag_targets(AVFormatContext *s,
return 0;
}
+static int mkv_check_tag_name(const char *name, unsigned int elementid)
+{
+return av_strcasecmp(name, "title") &&
+ av_strcasecmp(name, "stereo_mode") &&
+ av_strcasecmp(name, "creation_time") &&
+ av_strcasecmp(name, "encoding_tool") &&
+ av_strcasecmp(name, "duration") &&
+ (elementid != MATROSKA_ID_TAGTARGETS_TRACKUID ||
+av_strcasecmp(name, "language"));
+}
+
static int mkv_write_tag(AVFormatContext *s, AVDictionary *m, unsigned int
elementid,
unsigned int uid, ebml_master *tags)
{
@@ -1320,12 +1331,7 @@ static int mkv_write_tag(AVFormatContext *s,
AVDictionary *m, unsigned int eleme
return ret;
while ((t = av_dict_get(m, "", t, AV_DICT_IGNORE_SUFFIX))) {
-if (av_strcasecmp(t->key, "title") &&
-av_strcasecmp(t->key, "stereo_mode") &&
-av_strcasecmp(t->key, "creation_time") &&
-av_strcasecmp(t->key, "encoding_tool") &&
-(elementid != MATROSKA_ID_TAGTARGETS_TRACKUID ||
- av_strcasecmp(t->key, "language"))) {
+if (mkv_check_tag_name(t->key, elementid)) {
ret = mkv_write_simpletag(s->pb, t);
if (ret < 0)
return ret;
@@ -1336,12 +1342,12 @@ static int mkv_write_tag(AVFormatContext *s,
AVDictionary *m, unsigned int eleme
return 0;
}
-static int mkv_check_tag(AVDictionary *m)
+static int mkv_check_tag(AVDictionary *m, unsigned int elementid)
{
AVDictionaryEntry *t = NULL;
while ((t = av_dict_get(m, "", t, AV_DICT_IGNORE_SUFFIX)))
-if (av_strcasecmp(t->key, "title") && av_strcasecmp(t->key,
"stereo_mode"))
+if (mkv_check_tag_name(t->key, elementid))
return 1;
return 0;
@@ -1355,7 +1361,7 @@ static int mkv_write_tags(AVFormatContext *s)
ff_metadata_conv_ctx(s, ff_mkv_metadata_conv, NULL);
-if (mkv_check_tag(s->metadata)) {
+if (mkv_check_tag(s->metadata, 0)) {
ret = mkv_write_tag(s, s->metadata, 0, 0, &tags);
if (ret < 0) return ret;
}
@@ -1363,7 +1369,7 @@ static int mkv_write_tags(AVFormatContext *s)
for (i = 0; i < s->nb_streams; i++) {
AVStream *st = s->streams[i];
-if (!mkv_check_tag(st->metadata))
+if (!mkv_check_tag(st->metadata, MATROSKA_ID_TAGTARGETS_TRACKUID))
continue;
ret = mkv_write_tag(s, st->metadata, MATROSKA_ID_TAGTARGETS_TRACKUID,
i + 1, &tags);
@@ -1392,7 +1398,7 @@ static int mkv_write_tags(AVFormatContext *s)
for (i = 0; i < s->nb_chapters; i++) {
AVChapter *ch = s->chapters[i];
-if (!mkv_check_tag(ch->metadata))
+if (!mkv_check_tag(ch->metadata, MATROSKA_ID_TAGTARGETS_CHAPTERUID))
continue;
ret = mkv_write_tag(s, ch->metadata,
MATROSKA_ID_TAGTARGETS_CHAPTERUID, ch->id + mkv->chapter_id_offset, &tags);
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
