[FFmpeg-devel] [PATCH V3 10/11] lavc/remove_extradata_bsf: support dump options.

2018-03-13 Thread Jun Zhao

From d307ac53eaa1fa4b05d4701150fbdf62d74d16e7 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Thu, 8 Mar 2018 15:00:27 +0800
Subject: [PATCH V3 10/11] lavc/remove_extradata_bsf: support dump options.

support dump bit stream filter options

Signed-off-by: Jun Zhao 
---
 libavcodec/remove_extradata_bsf.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/libavcodec/remove_extradata_bsf.c 
b/libavcodec/remove_extradata_bsf.c
index d74391e547..b762079e05 100644
--- a/libavcodec/remove_extradata_bsf.c
+++ b/libavcodec/remove_extradata_bsf.c
@@ -90,12 +90,13 @@ static void remove_extradata_close(AVBSFContext *ctx)
 }
 
 #define OFFSET(x) offsetof(RemoveExtradataContext, x)
+#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_BSF_PARAM)
 static const AVOption options[] = {
-{ "freq", NULL, OFFSET(freq), AV_OPT_TYPE_INT, { .i64 = 
REMOVE_FREQ_KEYFRAME }, REMOVE_FREQ_KEYFRAME, REMOVE_FREQ_NONKEYFRAME, 0, 
"freq" },
-{ "k",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
REMOVE_FREQ_NONKEYFRAME }, .unit = "freq" },
-{ "keyframe", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
REMOVE_FREQ_KEYFRAME }, .unit = "freq" },
-{ "e",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = REMOVE_FREQ_ALL 
 }, .unit = "freq" },
-{ "all",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = REMOVE_FREQ_ALL 
 }, .unit = "freq" },
+{ "freq", NULL, OFFSET(freq), AV_OPT_TYPE_INT, { .i64 = 
REMOVE_FREQ_KEYFRAME }, REMOVE_FREQ_KEYFRAME, REMOVE_FREQ_NONKEYFRAME, FLAGS, 
"freq" },
+{ "k",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
REMOVE_FREQ_NONKEYFRAME }, .flags = FLAGS, .unit = "freq" },
+{ "keyframe", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
REMOVE_FREQ_KEYFRAME }, .flags = FLAGS, .unit = "freq" },
+{ "e",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = REMOVE_FREQ_ALL 
 }, .flags = FLAGS, .unit = "freq" },
+{ "all",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = REMOVE_FREQ_ALL 
 }, .flags = FLAGS, .unit = "freq" },
 { NULL },
 };
 
-- 
2.14.1

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


[FFmpeg-devel] [PATCH V3 11/11] doc/fftools-common-opts: allow printing bsf details.

2018-03-13 Thread Jun Zhao

From a268c566b90cf7fde52ec49b0aad13dae697d443 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Thu, 8 Mar 2018 15:18:11 +0800
Subject: [PATCH V3 11/11] doc/fftools-common-opts: allow printing bsf details.

Signed-off-by: Jun Zhao 
---
 doc/fftools-common-opts.texi | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/fftools-common-opts.texi b/doc/fftools-common-opts.texi
index 185ec218d5..a0b0781050 100644
--- a/doc/fftools-common-opts.texi
+++ b/doc/fftools-common-opts.texi
@@ -102,6 +102,10 @@ Print detailed information about the muxer named 
@var{muxer_name}. Use the
 @item filter=@var{filter_name}
 Print detailed information about the filter name @var{filter_name}. Use the
 @option{-filters} option to get a list of all filters.
+
+@item bsf=@var{bit_stream_filter_name}
+Print detailed information about the bit stream filter name 
@var{bit_stream_filter_name}.
+Use the @option{-bsfs} option to get a list of all bit stream filters.
 @end table
 
 @item -version
-- 
2.14.1

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


[FFmpeg-devel] [PATCH V3 09/11] lavc/noise_bsf: support dump options.

2018-03-13 Thread Jun Zhao

From b7f927496b32256db266564c413ed99675bac097 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Thu, 8 Mar 2018 14:57:47 +0800
Subject: [PATCH V3 09/11] lavc/noise_bsf: support dump options.

support dump bit stream filter options.

Signed-off-by: Jun Zhao 
---
 libavcodec/noise_bsf.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/noise_bsf.c b/libavcodec/noise_bsf.c
index 84b94032ad..6bb89507fc 100644
--- a/libavcodec/noise_bsf.c
+++ b/libavcodec/noise_bsf.c
@@ -78,9 +78,10 @@ fail:
 }
 
 #define OFFSET(x) offsetof(NoiseContext, x)
+#define FLAGS 
(AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_BSF_PARAM)
 static const AVOption options[] = {
-{ "amount", NULL, OFFSET(amount), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 
INT_MAX },
-{ "dropamount", NULL, OFFSET(dropamount), AV_OPT_TYPE_INT, { .i64 = 0 }, 
0, INT_MAX },
+{ "amount", NULL, OFFSET(amount), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 
INT_MAX, FLAGS },
+{ "dropamount", NULL, OFFSET(dropamount), AV_OPT_TYPE_INT, { .i64 = 0 }, 
0, INT_MAX, FLAGS },
 { NULL },
 };
 
-- 
2.14.1

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


[FFmpeg-devel] [PATCH V3 05/11] lavc/extract_extradata_bsf: support dump options.

2018-03-13 Thread Jun Zhao

From 3d49b455b8bea2ee311b011fd9078e180c7bdf9a Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Thu, 8 Mar 2018 14:05:53 +0800
Subject: [PATCH V3 05/11] lavc/extract_extradata_bsf: support dump options.

support dump bit stream filter options

Signed-off-by: Jun Zhao 
---
 libavcodec/extract_extradata_bsf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/extract_extradata_bsf.c 
b/libavcodec/extract_extradata_bsf.c
index 1c386becd7..007a6a71f5 100644
--- a/libavcodec/extract_extradata_bsf.c
+++ b/libavcodec/extract_extradata_bsf.c
@@ -322,9 +322,10 @@ static const enum AVCodecID codec_ids[] = {
 };
 
 #define OFFSET(x) offsetof(ExtractExtradataContext, x)
+#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_BSF_PARAM)
 static const AVOption options[] = {
 { "remove", "remove the extradata from the bitstream", OFFSET(remove), 
AV_OPT_TYPE_INT,
-{ .i64 = 0 }, 0, 1 },
+{ .i64 = 0 }, 0, 1 , FLAGS},
 { NULL },
 };
 
-- 
2.14.1

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


[FFmpeg-devel] [PATCH V3 06/11] lavc/h264_metadata_bsf: support dump options.

2018-03-13 Thread Jun Zhao

From 4db1a0f7cccabe1f74991ba160b8f8506bb5f865 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Thu, 8 Mar 2018 14:22:25 +0800
Subject: [PATCH V3 06/11] lavc/h264_metadata_bsf: support dump options.

support dump bit stream filter options

Signed-off-by: Jun Zhao 
---
 libavcodec/h264_metadata_bsf.c | 39 ---
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 466823cda6..12e739a354 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -451,63 +451,64 @@ static void h264_metadata_close(AVBSFContext *bsf)
 }
 
 #define OFFSET(x) offsetof(H264MetadataContext, x)
+#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_BSF_PARAM)
 static const AVOption h264_metadata_options[] = {
 { "aud", "Access Unit Delimiter NAL units",
 OFFSET(aud), AV_OPT_TYPE_INT,
-{ .i64 = PASS }, PASS, REMOVE, 0, "aud" },
-{ "pass",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = PASS   }, .unit = "aud" },
-{ "insert", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = INSERT }, .unit = "aud" },
-{ "remove", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = REMOVE }, .unit = "aud" },
+{ .i64 = PASS }, PASS, REMOVE, FLAGS, "aud" },
+{ "pass",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = PASS   }, .flags = FLAGS, 
.unit = "aud" },
+{ "insert", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = INSERT }, .flags = FLAGS, 
.unit = "aud" },
+{ "remove", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = REMOVE }, .flags = FLAGS, 
.unit = "aud" },
 
 { "sample_aspect_ratio", "Set sample aspect ratio (table E-1)",
 OFFSET(sample_aspect_ratio), AV_OPT_TYPE_RATIONAL,
-{ .dbl = 0.0 }, 0, 65535 },
+{ .dbl = 0.0 }, 0, 65535, FLAGS },
 
 { "video_format", "Set video format (table E-2)",
 OFFSET(video_format), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 7 },
+{ .i64 = -1 }, -1, 7, FLAGS},
 { "video_full_range_flag", "Set video full range flag",
 OFFSET(video_full_range_flag), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 1 },
+{ .i64 = -1 }, -1, 1, FLAGS },
 { "colour_primaries", "Set colour primaries (table E-3)",
 OFFSET(colour_primaries), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 255 },
+{ .i64 = -1 }, -1, 255, FLAGS },
 { "transfer_characteristics", "Set transfer characteristics (table E-4)",
 OFFSET(transfer_characteristics), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 255 },
+{ .i64 = -1 }, -1, 255, FLAGS },
 { "matrix_coefficients", "Set matrix coefficients (table E-5)",
 OFFSET(matrix_coefficients), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 255 },
+{ .i64 = -1 }, -1, 255, FLAGS },
 
 { "chroma_sample_loc_type", "Set chroma sample location type (figure E-1)",
 OFFSET(chroma_sample_loc_type), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 6 },
+{ .i64 = -1 }, -1, 6, FLAGS },
 
 { "tick_rate", "Set VUI tick rate (num_units_in_tick / time_scale)",
 OFFSET(tick_rate), AV_OPT_TYPE_RATIONAL,
-{ .dbl = 0.0 }, 0, UINT_MAX },
+{ .dbl = 0.0 }, 0, UINT_MAX, FLAGS },
 { "fixed_frame_rate_flag", "Set VUI fixed frame rate flag",
 OFFSET(fixed_frame_rate_flag), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 1 },
+{ .i64 = -1 }, -1, 1, FLAGS },
 
 { "crop_left", "Set left border crop offset",
 OFFSET(crop_left), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, H264_MAX_WIDTH },
+{ .i64 = -1 }, -1, H264_MAX_WIDTH, FLAGS },
 { "crop_right", "Set right border crop offset",
 OFFSET(crop_right), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, H264_MAX_WIDTH },
+{ .i64 = -1 }, -1, H264_MAX_WIDTH, FLAGS },
 { "crop_top", "Set top border crop offset",
 OFFSET(crop_top), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, H264_MAX_HEIGHT },
+{ .i64 = -1 }, -1, H264_MAX_HEIGHT, FLAGS },
 { "crop_bottom", "Set bottom border crop offset",
 OFFSET(crop_bottom), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, H264_MAX_HEIGHT },
+{ .i64 = -1 }, -1, H264_MAX_HEIGHT, FLAGS },
 
 { "sei_user_data", "Insert SEI user data (UUID+string)",
-OFFSET(sei_user_data), AV_OPT_TYPE_STRING, { .str = NULL } },
+OFFSET(sei_user_data), AV_OPT_TYPE_STRING, { .str = NULL }, .flags = 
FLAGS },
 
 { "delete_filler", "Delete all filler (both NAL and SEI)",
-OFFSET(delete_filler), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1 },
+OFFSET(delete_filler), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1 , FLAGS},
 
 { NULL }
 };
-- 
2.14.1

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


[FFmpeg-devel] [PATCH V3 08/11] lavc/mpeg2_metadata_bsf: support dump options.

2018-03-13 Thread Jun Zhao

From b406ee9499bd2f8557c350538a810bf92a828099 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Thu, 8 Mar 2018 14:31:30 +0800
Subject: [PATCH V3 08/11] lavc/mpeg2_metadata_bsf: support dump options.

support dump bit stream filter options

Signed-off-by: Jun Zhao 
---
 libavcodec/mpeg2_metadata_bsf.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/libavcodec/mpeg2_metadata_bsf.c b/libavcodec/mpeg2_metadata_bsf.c
index 3bb6c1d549..6d5f581ab1 100644
--- a/libavcodec/mpeg2_metadata_bsf.c
+++ b/libavcodec/mpeg2_metadata_bsf.c
@@ -266,27 +266,28 @@ static void mpeg2_metadata_close(AVBSFContext *bsf)
 }
 
 #define OFFSET(x) offsetof(MPEG2MetadataContext, x)
+#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_BSF_PARAM)
 static const AVOption mpeg2_metadata_options[] = {
 { "display_aspect_ratio", "Set display aspect ratio (table 6-3)",
 OFFSET(display_aspect_ratio), AV_OPT_TYPE_RATIONAL,
-{ .dbl = 0.0 }, 0, 65535 },
+{ .dbl = 0.0 }, 0, 65535, FLAGS },
 
 { "frame_rate", "Set frame rate",
 OFFSET(frame_rate), AV_OPT_TYPE_RATIONAL,
-{ .dbl = 0.0 }, 0, UINT_MAX },
+{ .dbl = 0.0 }, 0, UINT_MAX, FLAGS },
 
 { "video_format", "Set video format (table 6-6)",
 OFFSET(video_format), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 7 },
+{ .i64 = -1 }, -1, 7, FLAGS },
 { "colour_primaries", "Set colour primaries (table 6-7)",
 OFFSET(colour_primaries), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 255 },
+{ .i64 = -1 }, -1, 255, FLAGS },
 { "transfer_characteristics", "Set transfer characteristics (table 6-8)",
 OFFSET(transfer_characteristics), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 255 },
+{ .i64 = -1 }, -1, 255, FLAGS },
 { "matrix_coefficients", "Set matrix coefficients (table 6-9)",
 OFFSET(matrix_coefficients), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 255 },
+{ .i64 = -1 }, -1, 255, FLAGS },
 
 { NULL }
 };
-- 
2.14.1

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


[FFmpeg-devel] [PATCH V3 07/11] lavc/h265_metadata_bsf: support dump options.

2018-03-13 Thread Jun Zhao

From c558ab3512d8fcbc50f4c0a8e93f6a103fbea7e6 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Thu, 8 Mar 2018 14:28:13 +0800
Subject: [PATCH V3 07/11] lavc/h265_metadata_bsf: support dump options.

support dump bit stream filter options

Signed-off-by: Jun Zhao 
---
 libavcodec/h265_metadata_bsf.c | 35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/libavcodec/h265_metadata_bsf.c b/libavcodec/h265_metadata_bsf.c
index 2398ee95c5..2b5dd9debd 100644
--- a/libavcodec/h265_metadata_bsf.c
+++ b/libavcodec/h265_metadata_bsf.c
@@ -379,59 +379,60 @@ static void h265_metadata_close(AVBSFContext *bsf)
 }
 
 #define OFFSET(x) offsetof(H265MetadataContext, x)
+#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_BSF_PARAM)
 static const AVOption h265_metadata_options[] = {
 { "aud", "Access Unit Delimiter NAL units",
 OFFSET(aud), AV_OPT_TYPE_INT,
-{ .i64 = PASS }, PASS, REMOVE, 0, "aud" },
-{ "pass",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = PASS   }, .unit = "aud" },
-{ "insert", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = INSERT }, .unit = "aud" },
-{ "remove", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = REMOVE }, .unit = "aud" },
+{ .i64 = PASS }, PASS, REMOVE, FLAGS, "aud" },
+{ "pass",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = PASS   }, .flags = FLAGS, 
.unit = "aud" },
+{ "insert", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = INSERT }, .flags = FLAGS, 
.unit = "aud" },
+{ "remove", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = REMOVE }, .flags = FLAGS, 
.unit = "aud" },
 
 { "sample_aspect_ratio", "Set sample aspect ratio (table E-1)",
 OFFSET(sample_aspect_ratio), AV_OPT_TYPE_RATIONAL,
-{ .dbl = 0.0 }, 0, 65535 },
+{ .dbl = 0.0 }, 0, 65535, FLAGS },
 
 { "video_format", "Set video format (table E-2)",
 OFFSET(video_format), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 7 },
+{ .i64 = -1 }, -1, 7, FLAGS },
 { "video_full_range_flag", "Set video full range flag",
 OFFSET(video_full_range_flag), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 1 },
+{ .i64 = -1 }, -1, 1, FLAGS },
 { "colour_primaries", "Set colour primaries (table E-3)",
 OFFSET(colour_primaries), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 255 },
+{ .i64 = -1 }, -1, 255, FLAGS },
 { "transfer_characteristics", "Set transfer characteristics (table E-4)",
 OFFSET(transfer_characteristics), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 255 },
+{ .i64 = -1 }, -1, 255, FLAGS },
 { "matrix_coefficients", "Set matrix coefficients (table E-5)",
 OFFSET(matrix_coefficients), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 255 },
+{ .i64 = -1 }, -1, 255, FLAGS },
 
 { "chroma_sample_loc_type", "Set chroma sample location type (figure E-1)",
 OFFSET(chroma_sample_loc_type), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, 6 },
+{ .i64 = -1 }, -1, 6, FLAGS },
 
 { "tick_rate",
 "Set VPS and VUI tick rate (num_units_in_tick / time_scale)",
 OFFSET(tick_rate), AV_OPT_TYPE_RATIONAL,
-{ .dbl = 0.0 }, 0, UINT_MAX },
+{ .dbl = 0.0 }, 0, UINT_MAX, FLAGS },
 { "num_ticks_poc_diff_one",
 "Set VPS and VUI number of ticks per POC increment",
 OFFSET(num_ticks_poc_diff_one), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, INT_MAX },
+{ .i64 = -1 }, -1, INT_MAX, FLAGS },
 
 { "crop_left", "Set left border crop offset",
 OFFSET(crop_left), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, HEVC_MAX_WIDTH },
+{ .i64 = -1 }, -1, HEVC_MAX_WIDTH, FLAGS },
 { "crop_right", "Set right border crop offset",
 OFFSET(crop_right), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, HEVC_MAX_WIDTH },
+{ .i64 = -1 }, -1, HEVC_MAX_WIDTH, FLAGS },
 { "crop_top", "Set top border crop offset",
 OFFSET(crop_top), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, HEVC_MAX_HEIGHT },
+{ .i64 = -1 }, -1, HEVC_MAX_HEIGHT, FLAGS },
 { "crop_bottom", "Set bottom border crop offset",
 OFFSET(crop_bottom), AV_OPT_TYPE_INT,
-{ .i64 = -1 }, -1, HEVC_MAX_HEIGHT },
+{ .i64 = -1 }, -1, HEVC_MAX_HEIGHT, FLAGS },
 
 { NULL }
 };
-- 
2.14.1

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


[FFmpeg-devel] [PATCH V3 04/11] lavc/dump_extradata_bsf: support dump options.

2018-03-13 Thread Jun Zhao

From fed84536f3c3c0fc11c63104fb6d8d93faf2000f Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Thu, 8 Mar 2018 14:01:48 +0800
Subject: [PATCH V3 04/11] lavc/dump_extradata_bsf: support dump options.

support dump bit stream filter options

Signed-off-by: Jun Zhao 
---
 libavcodec/dump_extradata_bsf.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/libavcodec/dump_extradata_bsf.c b/libavcodec/dump_extradata_bsf.c
index fa7bc86e19..081ae5aa08 100644
--- a/libavcodec/dump_extradata_bsf.c
+++ b/libavcodec/dump_extradata_bsf.c
@@ -78,13 +78,14 @@ fail:
 }
 
 #define OFFSET(x) offsetof(DumpExtradataContext, x)
+#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_BSF_PARAM)
 static const AVOption options[] = {
 { "freq", "When do dump extradata", OFFSET(freq), AV_OPT_TYPE_INT,
-{ .i64 = DUMP_FREQ_KEYFRAME }, DUMP_FREQ_KEYFRAME, DUMP_FREQ_ALL, 0, 
"freq" },
-{ "k",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = DUMP_FREQ_KEYFRAME 
}, .unit = "freq" },
-{ "keyframe", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = DUMP_FREQ_KEYFRAME 
}, .unit = "freq" },
-{ "e",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = DUMP_FREQ_ALL  
}, .unit = "freq" },
-{ "all",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = DUMP_FREQ_ALL  
}, .unit = "freq" },
+{ .i64 = DUMP_FREQ_KEYFRAME }, DUMP_FREQ_KEYFRAME, DUMP_FREQ_ALL, 
FLAGS, "freq" },
+{ "k",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = DUMP_FREQ_KEYFRAME 
}, .flags = FLAGS, .unit = "freq" },
+{ "keyframe", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = DUMP_FREQ_KEYFRAME 
}, .flags = FLAGS, .unit = "freq" },
+{ "e",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = DUMP_FREQ_ALL  
}, .flags = FLAGS, .unit = "freq" },
+{ "all",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = DUMP_FREQ_ALL  
}, .flags = FLAGS, .unit = "freq" },
 { NULL },
 };
 
-- 
2.14.1

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


[FFmpeg-devel] [PATCH V3 03/11] ffmpeg: support dump bit stream filter options

2018-03-13 Thread Jun Zhao

From 6b8f199d0028afb3f0a6a10275e4055ddce91a6a Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Thu, 8 Mar 2018 13:50:31 +0800
Subject: [PATCH V3 03/11] ffmpeg: support dump bit stream filter options.

Support dump bit stream filter option in ffmpeg -h full and
ffmpeg -h bsf=FooBar.

Signed-off-by: Jun Zhao 
---
 fftools/cmdutils.c   | 17 +
 fftools/ffmpeg_opt.c |  3 ++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 0c7d13c27a..f9d87f6724 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1897,6 +1897,21 @@ static void show_help_filter(const char *name)
 }
 #endif
 
+static void show_help_bsf(const char *name)
+{
+const AVBitStreamFilter *bsf = av_bsf_get_by_name(name);
+
+if (!bsf) {
+av_log(NULL, AV_LOG_ERROR, "Unknown bit stream filter '%s'.\n", name);
+return;
+}
+
+printf("Bit stream filter %s\n", bsf->name);
+if (bsf->priv_class)
+show_help_children(bsf->priv_class, AV_OPT_FLAG_BSF_PARAM);
+printf("\n");
+}
+
 int show_help(void *optctx, const char *opt, const char *arg)
 {
 char *topic, *par;
@@ -1923,6 +1938,8 @@ int show_help(void *optctx, const char *opt, const char 
*arg)
 } else if (!strcmp(topic, "filter")) {
 show_help_filter(par);
 #endif
+} else if (!strcmp(topic, "bsf")) {
+show_help_bsf(par);
 } else {
 show_help_default(topic, par);
 }
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 1b591d9695..d7a7eb0662 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -3114,7 +3114,7 @@ void show_help_default(const char *opt, const char *arg)
"-h  -- print basic options\n"
"-h long -- print more options\n"
"-h full -- print all options (including all format and codec 
specific options, very long)\n"
-   "-h type=name -- print all options for the named 
decoder/encoder/demuxer/muxer/filter\n"
+   "-h type=name -- print all options for the named 
decoder/encoder/demuxer/muxer/filter/bsf\n"
"See man %s for detailed description of the options.\n"
"\n", program_name);
 
@@ -3159,6 +3159,7 @@ void show_help_default(const char *opt, const char *arg)
 #endif
 show_help_children(swr_get_class(), AV_OPT_FLAG_AUDIO_PARAM);
 show_help_children(avfilter_get_class(), AV_OPT_FLAG_VIDEO_PARAM | 
AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_FILTERING_PARAM);
+show_help_children(av_bsf_get_class(), AV_OPT_FLAG_VIDEO_PARAM | 
AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_BSF_PARAM);
 }
 }
 
-- 
2.14.1

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


[FFmpeg-devel] [PATCH V3 02/11] lavu/opt: add bit stream filter option dump support

2018-03-13 Thread Jun Zhao

From e479afdf27ab250ad545ea9518644e56be38d185 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Wed, 14 Mar 2018 10:05:05 +0800
Subject: [PATCH V3 02/11] lavu/opt: add bit stream filter option dump support.

enable dump bit stream filter and update opt fate test ref.

Signed-off-by: Jun Zhao 
---
 libavutil/opt.c|  1 +
 tests/ref/fate/opt | 50 +-
 2 files changed, 26 insertions(+), 25 deletions(-)

diff --git a/libavutil/opt.c b/libavutil/opt.c
index df88663e3f..3b0aab4ee8 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -1181,6 +1181,7 @@ static void opt_list(void *obj, void *av_log_obj, const 
char *unit,
 av_log(av_log_obj, AV_LOG_INFO, "%c", (opt->flags & 
AV_OPT_FLAG_SUBTITLE_PARAM) ? 'S' : '.');
 av_log(av_log_obj, AV_LOG_INFO, "%c", (opt->flags & 
AV_OPT_FLAG_EXPORT) ? 'X' : '.');
 av_log(av_log_obj, AV_LOG_INFO, "%c", (opt->flags & 
AV_OPT_FLAG_READONLY)   ? 'R' : '.');
+av_log(av_log_obj, AV_LOG_INFO, "%c", (opt->flags & 
AV_OPT_FLAG_BSF_PARAM)  ? 'B' : '.');
 
 if (opt->help)
 av_log(av_log_obj, AV_LOG_INFO, " %s", opt->help);
diff --git a/tests/ref/fate/opt b/tests/ref/fate/opt
index 7b47d429c5..6a7dbfa797 100644
--- a/tests/ref/fate/opt
+++ b/tests/ref/fate/opt
@@ -18,31 +18,31 @@ num64=1
 flt=0.33
 dbl=0.33
 TestContext AVOptions:
-  -num   E... set num (from 0 to 100) (default 0)
-  -toggleE... set toggle (from 0 to 1) (default 1)
-  -rational E... set rational (from 0 to 10) 
(default 1/1)
-  -string E... set string (default "default")
-  -escape E... set escape str (default "\=,")
-  -flags   E... set flags (default cool)
- cool E... set cool flag
- lame E... set lame flag
- mu   E... set mu flag
-  -size   E... set size (default "200x300")
-  -pix_fmt   E... set pixfmt (default 0bgr)
-  -sample_fmt E... set samplefmt (default s16)
-  -video_rate E... set videorate (default "25")
-  -duration E... set duration (default 0.001)
-  -color   E... set color (default "pink")
-  -cl E... set channel layout (default 
0x137)
-  -binE... set binary value
-  -bin1   E... set binary value
-  -bin2   E... set binary value
-  -num64   E... set num 64bit (from 0 to 100) 
(default 1)
-  -flt E... set float (from 0 to 100) (default 
0.33)
-  -dblE... set double (from 0 to 100) (default 
0.33)
-  -bool1 E... set boolean value (default auto)
-  -bool2 E... set boolean value (default true)
-  -bool3 E... set boolean value (default false)
+  -num   E set num (from 0 to 100) (default 0)
+  -toggleE set toggle (from 0 to 1) (default 
1)
+  -rational E set rational (from 0 to 10) 
(default 1/1)
+  -string E set string (default "default")
+  -escape E set escape str (default "\=,")
+  -flags   E set flags (default cool)
+ cool E set cool flag
+ lame E set lame flag
+ mu   E set mu flag
+  -size   E set size (default "200x300")
+  -pix_fmt   E set pixfmt (default 0bgr)
+  -sample_fmt E set samplefmt (default s16)
+  -video_rate E set videorate (default "25")
+  -duration E set duration (default 0.001)
+  -color   E set color (default "pink")
+  -cl E set channel layout (default 
0x137)
+  -binE set binary value
+  -bin1   E set binary value
+  -bin2   E set binary value
+  -num64   E set num 64bit (from 0 to 100) 
(default 1)
+  -flt E set float (from 0 to 100) (default 
0.33)
+  -dblE set double (from 0 to 100) 
(default 0.33)
+  -bool1 E set boolean value (default auto)
+  -bool2 E set boolean value (default true)
+  -bool3 E set boolean value (default false)
 
 Testing av_opt_is_set_to_default()
 name:   num default:1 error:
-- 
2.14.1

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


[FFmpeg-devel] [PATCH V3 01/11] lavu/opt: add AV_OPT_FLAG_BSF_PARAM

2018-03-13 Thread Jun Zhao
V3: rearrange the patch-sets as Michael's comments
V2: update opt fate test ref file
From c1b532a76153033efa5585915660a8d29a5f8649 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Thu, 8 Mar 2018 13:47:23 +0800
Subject: [PATCH V3 01/11] lavu/opt: add AV_OPT_FLAG_BSF_PARAM

add AV_OPT_FLAG_BSF_PARAM for bit stream filter options.

Signed-off-by: Jun Zhao 
---
 libavutil/opt.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavutil/opt.h b/libavutil/opt.h
index 391720f2e2..07da68ea23 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -287,6 +287,7 @@ typedef struct AVOption {
  * This flag only makes sense when AV_OPT_FLAG_EXPORT is also set.
  */
 #define AV_OPT_FLAG_READONLY128
+#define AV_OPT_FLAG_BSF_PARAM   (1<<8) ///< a generic parameter which can 
be set by the user for bit stream filtering
 #define AV_OPT_FLAG_FILTERING_PARAM (1<<16) ///< a generic parameter which can 
be set by the user for filtering
 //FIXME think about enc-audio, ... style flags
 
-- 
2.14.1

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


[FFmpeg-devel] [PATCH] avformat/movenc: move the concatenated eac3 packet reference

2018-03-13 Thread James Almer
Simplifies code.

Signed-off-by: James Almer 
---
 libavformat/movenc.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index a17bb85900..df6163bae5 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -491,10 +491,7 @@ concatenate:
 if (info->num_blocks != 6)
 goto end;
 av_packet_unref(pkt);
-ret = av_packet_ref(pkt, >pkt);
-if (ret < 0)
-goto end;
-av_packet_unref(>pkt);
+av_packet_move_ref(pkt, >pkt);
 info->num_blocks = 0;
 }
 ret = pkt->size;
-- 
2.16.2

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


Re: [FFmpeg-devel] [PATCH 1/4] lavf/movenc: fix leak of eac3_priv

2018-03-13 Thread Michael Niedermayer
On Mon, Mar 12, 2018 at 11:46:45PM -0500, Rodger Combs wrote:
> This could previously happen in error or early-exit cases. The next commit
> would make it happen in all cases.
> ---
>  libavformat/movenc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 5b1e66c897..353a42ae2c 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -5772,6 +5772,7 @@ static void mov_free(AVFormatContext *s)
>  av_freep(>tracks[i].par);
>  av_freep(>tracks[i].cluster);
>  av_freep(>tracks[i].frag_info);
> +av_freep(>tracks[i].eac3_priv);
>  
>  if (mov->tracks[i].vos_len)
>  av_freep(>tracks[i].vos_data);

eac3_priv.pkt may need freeing too


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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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


[FFmpeg-devel] [PATCH] avcodec/hapqa_extract: remove the AVOption flags

2018-03-13 Thread James Almer
These two are not used for bitstream filters.

Signed-off-by: James Almer 
---
 libavcodec/hapqa_extract_bsf.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavcodec/hapqa_extract_bsf.c b/libavcodec/hapqa_extract_bsf.c
index ee5dc191f7..652f79a7fe 100644
--- a/libavcodec/hapqa_extract_bsf.c
+++ b/libavcodec/hapqa_extract_bsf.c
@@ -110,11 +110,10 @@ static const enum AVCodecID codec_ids[] = {
 };
 
 #define OFFSET(x) offsetof(HapqaExtractContext, x)
-#define FLAGS AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
-{ "texture", "texture to keep", OFFSET(texture), AV_OPT_TYPE_INT, { .i64 = 
0 }, 0, 1, FLAGS,  "texture" },
-{ "color", "keep HapQ texture", 0, AV_OPT_TYPE_CONST, { .i64 = 0 }, 0, 
0, FLAGS, "texture" },
-{ "alpha", "keep HapAlphaOnly texture", 0, AV_OPT_TYPE_CONST, { .i64 = 
1 }, 0, 0, FLAGS, "texture" },
+{ "texture", "texture to keep", OFFSET(texture), AV_OPT_TYPE_INT, { .i64 = 
0 }, 0, 1, 0, "texture" },
+{ "color", "keep HapQ texture", 0, AV_OPT_TYPE_CONST, { .i64 = 
0 }, .unit = "texture" },
+{ "alpha", "keep HapAlphaOnly texture", 0, AV_OPT_TYPE_CONST, { .i64 = 
1 }, .unit = "texture" },
 { NULL },
 };
 
-- 
2.16.2

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


Re: [FFmpeg-devel] [PATCH] avcodec/extract_extradata: don't uninitialize the H2645Packet on every processed packet

2018-03-13 Thread Jun Zhao


On 2018/3/11 7:00, James Almer wrote:
> Based on hevc_parser code. This prevents repeated unnecessary allocations
> and frees on every packet processed by the bsf.
>
> Signed-off-by: James Almer 
> ---
>  libavcodec/extract_extradata_bsf.c | 33 +++--
>  1 file changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/libavcodec/extract_extradata_bsf.c 
> b/libavcodec/extract_extradata_bsf.c
> index 4e2d601742..64017b6fb7 100644
> --- a/libavcodec/extract_extradata_bsf.c
> +++ b/libavcodec/extract_extradata_bsf.c
> @@ -36,6 +36,9 @@ typedef struct ExtractExtradataContext {
>  int (*extract)(AVBSFContext *ctx, AVPacket *pkt,
> uint8_t **data, int *size);
>  
> +/* H264/HEVC specifc fields */
> +H2645Packet h2645_pkt;
> +
>  /* AVOptions */
>  int remove;
>  } ExtractExtradataContext;
> @@ -61,7 +64,6 @@ static int extract_extradata_h2645(AVBSFContext *ctx, 
> AVPacket *pkt,
>  
>  ExtractExtradataContext *s = ctx->priv_data;
>  
> -H2645Packet h2645_pkt = { 0 };
>  int extradata_size = 0, filtered_size = 0;
>  const int *extradata_nal_types;
>  int nb_extradata_nal_types;
> @@ -75,13 +77,13 @@ static int extract_extradata_h2645(AVBSFContext *ctx, 
> AVPacket *pkt,
>  nb_extradata_nal_types = FF_ARRAY_ELEMS(extradata_nal_types_h264);
>  }
>  
> -ret = ff_h2645_packet_split(_pkt, pkt->data, pkt->size,
> +ret = ff_h2645_packet_split(>h2645_pkt, pkt->data, pkt->size,
>  ctx, 0, 0, ctx->par_in->codec_id, 1);
>  if (ret < 0)
> -goto fail;
> +return ret;
>  
> -for (i = 0; i < h2645_pkt.nb_nals; i++) {
> -H2645NAL *nal = _pkt.nals[i];
> +for (i = 0; i < s->h2645_pkt.nb_nals; i++) {
> +H2645NAL *nal = >h2645_pkt.nals[i];
>  if (val_in_array(extradata_nal_types, nb_extradata_nal_types, 
> nal->type)) {
>  extradata_size += nal->raw_size + 3;
>  if (ctx->par_in->codec_id == AV_CODEC_ID_HEVC) {
> @@ -104,8 +106,7 @@ static int extract_extradata_h2645(AVBSFContext *ctx, 
> AVPacket *pkt,
>  if (s->remove) {
>  filtered_buf = av_buffer_alloc(filtered_size + 
> AV_INPUT_BUFFER_PADDING_SIZE);
>  if (!filtered_buf) {
> -ret = AVERROR(ENOMEM);
> -goto fail;
> +return AVERROR(ENOMEM);
>  }
>  memset(filtered_buf->data + filtered_size, 0, 
> AV_INPUT_BUFFER_PADDING_SIZE);
>  
> @@ -115,16 +116,15 @@ static int extract_extradata_h2645(AVBSFContext *ctx, 
> AVPacket *pkt,
>  extradata = av_malloc(extradata_size + AV_INPUT_BUFFER_PADDING_SIZE);
>  if (!extradata) {
>  av_buffer_unref(_buf);
> -ret = AVERROR(ENOMEM);
> -goto fail;
> +return AVERROR(ENOMEM);
>  }
>  memset(extradata + extradata_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
>  
>  *data = extradata;
>  *size = extradata_size;
>  
> -for (i = 0; i < h2645_pkt.nb_nals; i++) {
> -H2645NAL *nal = _pkt.nals[i];
> +for (i = 0; i < s->h2645_pkt.nb_nals; i++) {
> +H2645NAL *nal = >h2645_pkt.nals[i];
>  if (val_in_array(extradata_nal_types, nb_extradata_nal_types,
>   nal->type)) {
>  AV_WB24(extradata, 1); // startcode
> @@ -145,9 +145,7 @@ static int extract_extradata_h2645(AVBSFContext *ctx, 
> AVPacket *pkt,
>  }
>  }
>  
> -fail:
> -ff_h2645_packet_uninit(_pkt);
> -return ret;
> +return 0;
>  }
>  
>  static int extract_extradata_vc1(AVBSFContext *ctx, AVPacket *pkt,
> @@ -311,6 +309,12 @@ fail:
>  return ret;
>  }
>  
> +static void extract_extradata_close(AVBSFContext *ctx)
> +{
> +ExtractExtradataContext *s = ctx->priv_data;
> +ff_h2645_packet_uninit(>h2645_pkt);
> +}
> +
>  static const enum AVCodecID codec_ids[] = {
>  AV_CODEC_ID_CAVS,
>  AV_CODEC_ID_H264,
> @@ -343,4 +347,5 @@ const AVBitStreamFilter ff_extract_extradata_bsf = {
>  .priv_class = _extradata_class,
>  .init   = extract_extradata_init,
>  .filter = extract_extradata_filter,
> +.close  = extract_extradata_close,
>  };
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] fate/hap : add test for hap encoding

2018-03-13 Thread James Almer
On 3/13/2018 4:31 PM, Martin Vignali wrote:
> 2018-03-11 19:37 GMT+01:00 Martin Vignali :
> 
>>
>>
>> 2017-11-26 18:25 GMT+01:00 Martin Vignali :
>>
>>> Hello,
>>>
>>> Patch in attach, add test for hap encoding (currently not cover) (patch
>>> 002)
>>> and move decoding tests to a separate file (patch 001)
>>>
>>> decoding can be test with
>>> make fate-hap SAMPLES=fate-suite/
>>>
>>> and encoding can be test with
>>> make fate-hapenc SAMPLES=fate-suite/
>>>
>>> Hap encoding need ffmpeg compile with libsnappy (--enable-libsnappy)
>>>
>>>
>> If noone is against,
>> i plan to apply this in few days.
>>
>> In attach, updated patch (in order to apply it on master).
>>
>> Martin
>>
>>
> Pushed.
> 
> Martin

These tests are failing
http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-enableshared=20180313201913

I'm with Carl, there's a reason we don't tests wrappers using external
libraries. The output for such tests is unpredictable and depends on a
lot of external factors we can't control, so please remove these tests.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH V2 11/11] lavu/opt: update fate to support dump bit stream filter option.

2018-03-13 Thread Jun Zhao


On 2018/3/14 6:00, Michael Niedermayer wrote:
> On Mon, Mar 12, 2018 at 09:25:36AM +0800, Jun Zhao wrote:
>>  opt |   50 +-
>>  1 file changed, 25 insertions(+), 25 deletions(-)
>> 2038c71aba538e2cf97de3c43e645359ad6e96b0  
>> 0011-lavu-opt-update-fate-to-support-dump-bit-stream-filt.patch
>> From ec00625932e794c52c816d35cca5fade8cdfa4a9 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Sat, 10 Mar 2018 13:35:03 +0800
>> Subject: [PATCH V2 11/11] lavu/opt: update fate to support dump bit stream
>>  filter option.
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  tests/ref/fate/opt | 50 +-
>>  1 file changed, 25 insertions(+), 25 deletions(-)
> This belongs in the patch that causes the change

Will follow the comments, thanks.
>
> [...]
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH V2 01/11] lavu/opt: add AV_OPT_FLAG_BSF_PARAM

2018-03-13 Thread Jun Zhao


On 2018/3/14 6:02, Michael Niedermayer wrote:
> On Mon, Mar 12, 2018 at 09:23:02AM +0800, Jun Zhao wrote:
>> V2: update opt fate test ref file
>>  opt.c |1 +
>>  opt.h |1 +
>>  2 files changed, 2 insertions(+)
>> 5e930c1851c198bd35369b87965c6eeadfd39a95  
>> 0001-lavu-opt-add-AV_OPT_FLAG_BSF_PARAM.patch
>> From 5cd2a18ebe1494e11b08e33ca5587f7d17f41964 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Thu, 8 Mar 2018 13:47:23 +0800
>> Subject: [PATCH V2 01/11] lavu/opt: add AV_OPT_FLAG_BSF_PARAM
>>
>> add AV_OPT_FLAG_BSF_PARAM for bit stream filter options.
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavutil/opt.c | 1 +
>>  libavutil/opt.h | 1 +
>>  2 files changed, 2 insertions(+)
>>
>> diff --git a/libavutil/opt.c b/libavutil/opt.c
>> index df88663e3f..3b0aab4ee8 100644
>> --- a/libavutil/opt.c
>> +++ b/libavutil/opt.c
>> @@ -1181,6 +1181,7 @@ static void opt_list(void *obj, void *av_log_obj, 
>> const char *unit,
>>  av_log(av_log_obj, AV_LOG_INFO, "%c", (opt->flags & 
>> AV_OPT_FLAG_SUBTITLE_PARAM) ? 'S' : '.');
>>  av_log(av_log_obj, AV_LOG_INFO, "%c", (opt->flags & 
>> AV_OPT_FLAG_EXPORT) ? 'X' : '.');
>>  av_log(av_log_obj, AV_LOG_INFO, "%c", (opt->flags & 
>> AV_OPT_FLAG_READONLY)   ? 'R' : '.');
>> +av_log(av_log_obj, AV_LOG_INFO, "%c", (opt->flags & 
>> AV_OPT_FLAG_BSF_PARAM)  ? 'B' : '.');
>>  
>>  if (opt->help)
>>  av_log(av_log_obj, AV_LOG_INFO, " %s", opt->help);
>> diff --git a/libavutil/opt.h b/libavutil/opt.h
>> index 391720f2e2..07da68ea23 100644
>> --- a/libavutil/opt.h
>> +++ b/libavutil/opt.h
>> @@ -287,6 +287,7 @@ typedef struct AVOption {
>>   * This flag only makes sense when AV_OPT_FLAG_EXPORT is also set.
>>   */
>>  #define AV_OPT_FLAG_READONLY128
>> +#define AV_OPT_FLAG_BSF_PARAM   (1<<8) ///< a generic parameter which 
>> can be set by the user for bit stream filtering
>>  #define AV_OPT_FLAG_FILTERING_PARAM (1<<16) ///< a generic parameter which 
>> can be set by the user for filtering
>>  //FIXME think about enc-audio, ... style flags
> these 2 hunks should be split into 2 seperate patches
> this is needed to keep the patchset a series of patches where none breaks
> fate
Will split into 2 separate patches and combine option update patch
(https://patchwork.ffmpeg.org/patch/7936/)  with one of them.
Tks.
>
> [...]
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH]lavfi/deshake: Check alignment before calling asm init function

2018-03-13 Thread Carl Eugen Hoyos
2018-03-10 20:50 GMT+01:00, Carl Eugen Hoyos :
> Hi!
>
> Attached patch fixes ticket #7078 for me.

Ping.

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


Re: [FFmpeg-devel] [PATCH] avcodec/extract_extradata: don't uninitialize the H2645Packet on every processed packet

2018-03-13 Thread James Almer
On 3/10/2018 8:00 PM, James Almer wrote:
> Based on hevc_parser code. This prevents repeated unnecessary allocations
> and frees on every packet processed by the bsf.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/extract_extradata_bsf.c | 33 +++--
>  1 file changed, 19 insertions(+), 14 deletions(-)

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


Re: [FFmpeg-devel] fate/hap : add test for hap encoding

2018-03-13 Thread Carl Eugen Hoyos
2018-03-14 0:26 GMT+01:00, Martin Vignali :
>> >>
>> >> Patch in attach, add test for hap encoding
>>
>> Why is this a good idea?
>
> The question, is maybe why is this a wrong idea ?

We usually don't test external libraries, the main reason is probably
that if they change behaviour, fate breaks (and we cannot fix it
in a reliable way).

>> Does the specification explain how encoding has to be done?
>
> Not sure i understand, the spec explain that hap use DXT
> encoding and snappy, and explain the frame organization.

If the specification defines encoding, the hap encoding fate test
is not necessarily a good idea but it may be acceptable. Afaiu,
modern specifications never define encoding, they (always)
define decoding. If the (snappy) specification defines decoding
(decompression), then the fate test is not only not a good idea,
it is plain wrong and should be reverted.

>> This is very unusual, no?

>> Even if so: Why are we testing an external library?
>>
> Hap encoding inside ffmpeg use an external lib (libsnappy),
> only for one step of the encoding process (the lossless part)
> DXT encoding, and frame organization is done "inside" ffmpeg.

If snappy is so reliable that it can be used for fate, and if
our wrapper is so fragile that is has to be tested, the test
should at least be a round-trip to avoid issues with new
library versions.

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


Re: [FFmpeg-devel] [PATCH] avcodec/hapqa_extract: fix two error return values

2018-03-13 Thread James Almer
On 3/13/2018 8:17 PM, Martin Vignali wrote:
> 2018-03-13 23:08 GMT+01:00 James Almer :
> 
>> ret is 0 by default.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/hapqa_extract_bsf.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/libavcodec/hapqa_extract_bsf.c b/libavcodec/hapqa_extract_
>> bsf.c
>> index 333efb2e3a..ee5dc191f7 100644
>> --- a/libavcodec/hapqa_extract_bsf.c
>> +++ b/libavcodec/hapqa_extract_bsf.c
>> @@ -66,6 +66,7 @@ static int hapqa_extract(AVBSFContext *bsf, AVPacket
>> *pkt)
>>
>>  if ((section_type & 0x0F) != 0x0D) {
>>  av_log(bsf, AV_LOG_ERROR, "Invalid section type for HAPQA
>> %#04x.\n", section_type & 0x0F);
>> +ret = AVERROR_INVALIDDATA;
>>  goto fail;
>>  }
>>
>> @@ -90,6 +91,7 @@ static int hapqa_extract(AVBSFContext *bsf, AVPacket
>> *pkt)
>>
>>  if (check_texture(ctx, section_type) == 0){ /* the second texture
>> is not the one to keep */
>>  av_log(bsf, AV_LOG_ERROR, "No valid texture found.\n");
>> +ret = AVERROR_INVALIDDATA;
>>  goto fail;
>>  }
>>  }
>> --
> 
> 
> lgtm, thanks.
> 
> Martin

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


[FFmpeg-devel] [PATCH] avutil/buffer: add av_buffer_fast_alloc()

2018-03-13 Thread James Almer
Same concept as av_fast_malloc(). If the buffer passed to it is writable
and big enough it will be reused, otherwise a new one will be allocated
instead.

Signed-off-by: James Almer 
---
TODO: Changelog and APIChanges entries, version bump.

 libavutil/buffer.c | 63 ++
 libavutil/buffer.h | 42 
 2 files changed, 105 insertions(+)

diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 8d1aa5fa84..16ce1b82e2 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -215,6 +215,69 @@ int av_buffer_realloc(AVBufferRef **pbuf, int size)
 return 0;
 }
 
+static av_always_inline int buffer_fast_alloc(AVBufferRef **pbuf, int size, 
int zero_alloc)
+{
+AVBufferRef *buf = *pbuf;
+AVBuffer *b;
+uint8_t *data;
+
+if (!buf || !av_buffer_is_writable(buf) || buf->data != buf->buffer->data) 
{
+/* Buffer can't be reused, and neither can the entire AVBufferRef.
+ * Unref the latter and alloc a new one. */
+av_buffer_unref(pbuf);
+
+buf = av_buffer_alloc(size);
+if (!buf)
+return AVERROR(ENOMEM);
+
+if (zero_alloc)
+memset(buf->data, 0, size);
+
+*pbuf = buf;
+return 0;
+}
+b = buf->buffer;
+
+if (size <= b->size) {
+/* Buffer can be reused. Update the size of AVBufferRef but leave the
+ * AVBuffer untouched. */
+buf->size = FFMAX(0, size);
+return 0;
+}
+
+/* Buffer can't be reused, but there's no need to alloc new AVBuffer and
+ * AVBufferRef structs. Free the existing buffer, allocate a new one, and
+ * reset AVBuffer and AVBufferRef to default values. */
+b->free(b->opaque, b->data);
+b->free   = av_buffer_default_free;
+b->opaque = NULL;
+b->flags  = 0;
+
+data = av_malloc(size);
+if (!data) {
+av_buffer_unref(pbuf);
+return AVERROR(ENOMEM);
+}
+
+if (zero_alloc)
+memset(data, 0, size);
+
+b->data = buf->data = data;
+b->size = buf->size = size;
+
+return 0;
+}
+
+int av_buffer_fast_alloc(AVBufferRef **pbuf, int size)
+{
+return buffer_fast_alloc(pbuf, size, 0);
+}
+
+int av_buffer_fast_allocz(AVBufferRef **pbuf, int size)
+{
+return buffer_fast_alloc(pbuf, size, 1);
+}
+
 AVBufferPool *av_buffer_pool_init2(int size, void *opaque,
AVBufferRef* (*alloc)(void *opaque, int 
size),
void (*pool_free)(void *opaque))
diff --git a/libavutil/buffer.h b/libavutil/buffer.h
index 73b6bd0b14..1166017d22 100644
--- a/libavutil/buffer.h
+++ b/libavutil/buffer.h
@@ -197,6 +197,48 @@ int av_buffer_make_writable(AVBufferRef **buf);
  */
 int av_buffer_realloc(AVBufferRef **buf, int size);
 
+/**
+ * Allocate a buffer, reusing the given one if writable and large enough.
+ *
+ * @code{.c}
+ * AVBufferRef *buf = ...;
+ * int ret = av_buffer_fast_alloc(, size);
+ * if (ret < 0) {
+ * // Allocation failed; buf already freed
+ * return ret;
+ * }
+ * @endcode
+ *
+ * @param buf  A buffer reference. *buf may be NULL. On success, a new buffer
+ * reference will be written in its place. On failure, it will be
+ * unreferenced and set to NULL.
+ * @param size Required buffer size.
+ *
+ * @return 0 on success, a negative AVERROR on failure.
+ *
+ * @see av_buffer_realloc()
+ * @see av_buffer_fast_allocz()
+ */
+int av_buffer_fast_alloc(AVBufferRef **buf, int size);
+
+/**
+ * Allocate and clear a buffer, reusing the given one if writable and large
+ * enough.
+ *
+ * Like av_buffer_fast_alloc(), but all newly allocated space is initially
+ * cleared. Reused buffer is not cleared.
+ *
+ * @param buf  A buffer reference. *buf may be NULL. On success, a new buffer
+ * reference will be written in its place. On failure, it will be
+ * unreferenced and set to NULL.
+ * @param size Required buffer size.
+ *
+ * @return 0 on success, a negative AVERROR on failure.
+ *
+ * @see av_buffer_fast_alloc()
+ */
+int av_buffer_fast_allocz(AVBufferRef **buf, int size);
+
 /**
  * @}
  */
-- 
2.16.2

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


[FFmpeg-devel] [PATCH] libavfilter: Add OpenCL convolution filter.

2018-03-13 Thread Danil Iashchenko
Behaves like the existing convolution filter, except working on OpenCL
hardware frames.
Takes exactly the same options: 4 convolution matrices, 4 rdiv values, 4 bias 
values.
If not specified, default parameters are applied.
Matrices can be different sizes.

filter applies:
matrix0, rdiv0, bias0 to image plane0.
matrix1, rdiv1, bias1 to image plane1.
matrix2, rdiv2, bias2 to image plane2.
matrix3, rdiv3, bias3 to image plane3.

About Kernel parameters:
dst - destination image
src - source image
coef_matrices_sizes - stores sizes of matrix{0..3} consecutively one after the 
other
coef_matrices - stores matrices{0..3} consecutively one after the other
rdivs - stores rdiv{0..3} parameters consecutively one after the other
biases - stores bias{0..3} parameters consecutively one after the other

About sscanf. I had (!err_code) condition, because I would never get empty line
as option(if not specified, I always have default matrix), but changed to 
(err_code != 1) due to read-ability.
Also, before sscanf I split matrix with spaces, so I process each single value
of matrix seperately from others and check if they are ok.

about rdiv_buffer, bias_buffer, size_buffer objects: they should be buffer
objects, because they store sequence of values, not a single value
---
 configure   |   1 +
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/opencl/convolution.cl   |  43 
 libavfilter/opencl_source.h |   1 +
 libavfilter/vf_convolution_opencl.c | 449 
 6 files changed, 496 insertions(+)
 create mode 100644 libavfilter/opencl/convolution.cl
 create mode 100644 libavfilter/vf_convolution_opencl.c

diff --git a/configure b/configure
index 6916b45..bf5c312 100755
--- a/configure
+++ b/configure
@@ -3210,6 +3210,7 @@ blackframe_filter_deps="gpl"
 boxblur_filter_deps="gpl"
 bs2b_filter_deps="libbs2b"
 colormatrix_filter_deps="gpl"
+convolution_opencl_filter_deps="opencl"
 convolve_filter_deps="avcodec"
 convolve_filter_select="fft"
 coreimage_filter_deps="coreimage appkit"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6a60836..d005934 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -156,6 +156,7 @@ OBJS-$(CONFIG_COLORLEVELS_FILTER)+= 
vf_colorlevels.o
 OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o
 OBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o colorspacedsp.o
 OBJS-$(CONFIG_CONVOLUTION_FILTER)+= vf_convolution.o
+OBJS-$(CONFIG_CONVOLUTION_OPENCL_FILTER) += vf_convolution_opencl.o 
opencl.o opencl/convolution.o
 OBJS-$(CONFIG_CONVOLVE_FILTER)   += vf_convolve.o framesync.o
 OBJS-$(CONFIG_COPY_FILTER)   += vf_copy.o
 OBJS-$(CONFIG_COREIMAGE_FILTER)  += vf_coreimage.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9adb109..f2dc55e 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -166,6 +166,7 @@ static void register_all(void)
 REGISTER_FILTER(COLORMATRIX,colormatrix,vf);
 REGISTER_FILTER(COLORSPACE, colorspace, vf);
 REGISTER_FILTER(CONVOLUTION,convolution,vf);
+REGISTER_FILTER(CONVOLUTION_OPENCL, convolution_opencl, vf);
 REGISTER_FILTER(CONVOLVE,   convolve,   vf);
 REGISTER_FILTER(COPY,   copy,   vf);
 REGISTER_FILTER(COREIMAGE,  coreimage,  vf);
diff --git a/libavfilter/opencl/convolution.cl 
b/libavfilter/opencl/convolution.cl
new file mode 100644
index 000..b142aa8
--- /dev/null
+++ b/libavfilter/opencl/convolution.cl
@@ -0,0 +1,43 @@
+/*
+ * 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
+ */
+
+__kernel void convolution_global(__write_only image2d_t dst,
+ __read_only  image2d_t src,
+ __constant int *coef_matrices_sizes,
+ __constant float *coef_matrices,
+ __constant float *rdivs,
+ __constant float *biases)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE | 
CLK_FILTER_NEAREST);
+
+int2 loc = (int2)(get_global_id(0), get_global_id(1));
+
+

Re: [FFmpeg-devel] fate/hap : add test for hap encoding

2018-03-13 Thread Martin Vignali
> >>
> >> Patch in attach, add test for hap encoding
>
> Why is this a good idea?
>

The question, is maybe why is this a wrong idea ?


>
> Does the specification explain how encoding has to be done?
>

Not sure i understand, the spec explain that hap use DXT encoding and
snappy, and explain the frame organization.


> This is very unusual, no?
>


> Even if so: Why are we testing an external library?
>
>
>
Hap encoding inside ffmpeg use an external lib (libsnappy), only for one
step of the encoding process (the lossless part)
DXT encoding, and frame organization is done "inside" ffmpeg.

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


Re: [FFmpeg-devel] [PATCH] avcodec/hapqa_extract: fix two error return values

2018-03-13 Thread Martin Vignali
2018-03-13 23:08 GMT+01:00 James Almer :

> ret is 0 by default.
>
> Signed-off-by: James Almer 
> ---
>  libavcodec/hapqa_extract_bsf.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/hapqa_extract_bsf.c b/libavcodec/hapqa_extract_
> bsf.c
> index 333efb2e3a..ee5dc191f7 100644
> --- a/libavcodec/hapqa_extract_bsf.c
> +++ b/libavcodec/hapqa_extract_bsf.c
> @@ -66,6 +66,7 @@ static int hapqa_extract(AVBSFContext *bsf, AVPacket
> *pkt)
>
>  if ((section_type & 0x0F) != 0x0D) {
>  av_log(bsf, AV_LOG_ERROR, "Invalid section type for HAPQA
> %#04x.\n", section_type & 0x0F);
> +ret = AVERROR_INVALIDDATA;
>  goto fail;
>  }
>
> @@ -90,6 +91,7 @@ static int hapqa_extract(AVBSFContext *bsf, AVPacket
> *pkt)
>
>  if (check_texture(ctx, section_type) == 0){ /* the second texture
> is not the one to keep */
>  av_log(bsf, AV_LOG_ERROR, "No valid texture found.\n");
> +ret = AVERROR_INVALIDDATA;
>  goto fail;
>  }
>  }
> --


lgtm, thanks.

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


Re: [FFmpeg-devel] fate/hap : add test for hap encoding

2018-03-13 Thread Carl Eugen Hoyos
2018-03-11 19:37 GMT+01:00, Martin Vignali :
> 2017-11-26 18:25 GMT+01:00 Martin Vignali :
>
>> Hello,
>>
>> Patch in attach, add test for hap encoding

Why is this a good idea?

Does the specification explain how encoding has to be done?
This is very unusual, no?
Even if so: Why are we testing an external library?

Sorry for missing your original mail, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avcodec/hapqa_extract: fix two error return values

2018-03-13 Thread James Almer
ret is 0 by default.

Signed-off-by: James Almer 
---
 libavcodec/hapqa_extract_bsf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/hapqa_extract_bsf.c b/libavcodec/hapqa_extract_bsf.c
index 333efb2e3a..ee5dc191f7 100644
--- a/libavcodec/hapqa_extract_bsf.c
+++ b/libavcodec/hapqa_extract_bsf.c
@@ -66,6 +66,7 @@ static int hapqa_extract(AVBSFContext *bsf, AVPacket *pkt)
 
 if ((section_type & 0x0F) != 0x0D) {
 av_log(bsf, AV_LOG_ERROR, "Invalid section type for HAPQA %#04x.\n", 
section_type & 0x0F);
+ret = AVERROR_INVALIDDATA;
 goto fail;
 }
 
@@ -90,6 +91,7 @@ static int hapqa_extract(AVBSFContext *bsf, AVPacket *pkt)
 
 if (check_texture(ctx, section_type) == 0){ /* the second texture is 
not the one to keep */
 av_log(bsf, AV_LOG_ERROR, "No valid texture found.\n");
+ret = AVERROR_INVALIDDATA;
 goto fail;
 }
 }
-- 
2.16.2

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


Re: [FFmpeg-devel] [PATCH V2 01/11] lavu/opt: add AV_OPT_FLAG_BSF_PARAM

2018-03-13 Thread Michael Niedermayer
On Mon, Mar 12, 2018 at 09:23:02AM +0800, Jun Zhao wrote:
> V2: update opt fate test ref file

>  opt.c |1 +
>  opt.h |1 +
>  2 files changed, 2 insertions(+)
> 5e930c1851c198bd35369b87965c6eeadfd39a95  
> 0001-lavu-opt-add-AV_OPT_FLAG_BSF_PARAM.patch
> From 5cd2a18ebe1494e11b08e33ca5587f7d17f41964 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Thu, 8 Mar 2018 13:47:23 +0800
> Subject: [PATCH V2 01/11] lavu/opt: add AV_OPT_FLAG_BSF_PARAM
> 
> add AV_OPT_FLAG_BSF_PARAM for bit stream filter options.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavutil/opt.c | 1 +
>  libavutil/opt.h | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/libavutil/opt.c b/libavutil/opt.c
> index df88663e3f..3b0aab4ee8 100644
> --- a/libavutil/opt.c
> +++ b/libavutil/opt.c
> @@ -1181,6 +1181,7 @@ static void opt_list(void *obj, void *av_log_obj, const 
> char *unit,
>  av_log(av_log_obj, AV_LOG_INFO, "%c", (opt->flags & 
> AV_OPT_FLAG_SUBTITLE_PARAM) ? 'S' : '.');
>  av_log(av_log_obj, AV_LOG_INFO, "%c", (opt->flags & 
> AV_OPT_FLAG_EXPORT) ? 'X' : '.');
>  av_log(av_log_obj, AV_LOG_INFO, "%c", (opt->flags & 
> AV_OPT_FLAG_READONLY)   ? 'R' : '.');
> +av_log(av_log_obj, AV_LOG_INFO, "%c", (opt->flags & 
> AV_OPT_FLAG_BSF_PARAM)  ? 'B' : '.');
>  
>  if (opt->help)
>  av_log(av_log_obj, AV_LOG_INFO, " %s", opt->help);
> diff --git a/libavutil/opt.h b/libavutil/opt.h
> index 391720f2e2..07da68ea23 100644
> --- a/libavutil/opt.h
> +++ b/libavutil/opt.h
> @@ -287,6 +287,7 @@ typedef struct AVOption {
>   * This flag only makes sense when AV_OPT_FLAG_EXPORT is also set.
>   */
>  #define AV_OPT_FLAG_READONLY128
> +#define AV_OPT_FLAG_BSF_PARAM   (1<<8) ///< a generic parameter which 
> can be set by the user for bit stream filtering
>  #define AV_OPT_FLAG_FILTERING_PARAM (1<<16) ///< a generic parameter which 
> can be set by the user for filtering
>  //FIXME think about enc-audio, ... style flags

these 2 hunks should be split into 2 seperate patches
this is needed to keep the patchset a series of patches where none breaks
fate


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


Re: [FFmpeg-devel] [PATCH V2 11/11] lavu/opt: update fate to support dump bit stream filter option.

2018-03-13 Thread Michael Niedermayer
On Mon, Mar 12, 2018 at 09:25:36AM +0800, Jun Zhao wrote:
> 

>  opt |   50 +-
>  1 file changed, 25 insertions(+), 25 deletions(-)
> 2038c71aba538e2cf97de3c43e645359ad6e96b0  
> 0011-lavu-opt-update-fate-to-support-dump-bit-stream-filt.patch
> From ec00625932e794c52c816d35cca5fade8cdfa4a9 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Sat, 10 Mar 2018 13:35:03 +0800
> Subject: [PATCH V2 11/11] lavu/opt: update fate to support dump bit stream
>  filter option.
> 
> Signed-off-by: Jun Zhao 
> ---
>  tests/ref/fate/opt | 50 +-
>  1 file changed, 25 insertions(+), 25 deletions(-)

This belongs in the patch that causes the change

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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


Re: [FFmpeg-devel] [PATCH v3] avcodec: fix atomics usage for h264/mpeg error_count

2018-03-13 Thread Aman Gupta
On Tue, Mar 13, 2018 at 11:43 AM, Aman Gupta  wrote:

>
> On Tue, Mar 13, 2018 at 11:34 AM Michael Niedermayer
>  wrote:
>
>> On Tue, Mar 13, 2018 at 04:02:57PM +, Aman Gupta wrote:
>> > On Tue, Mar 13, 2018 at 4:39 AM Michael Niedermayer
>> 
>> > wrote:
>> >
>> > > On Mon, Mar 12, 2018 at 06:49:19PM -0700, Aman Gupta wrote:
>> > > > From: Aman Gupta 
>> > > >
>> > > > ---
>> > > >  libavcodec/h264_slice.c|  5 +++--
>> > > >  libavcodec/mpeg12dec.c | 12 +++-
>> > > >  libavcodec/mpegvideo_enc.c |  3 ++-
>> > > >  3 files changed, 12 insertions(+), 8 deletions(-)
>> > >
>> > > Iam a little bit confused, you write about "fixing" but not what this
>> is
>> > > fixing and it appears there are several distinct types of changes
>> >
>> >
>> > The type of error_count is already atomic_int. I don't know when that
>> was
>> > changed.
>> >
>> > The fix here is that these files do not compile on FreeBSD because of
>> > errors such as:
>> >
>> > [2018-03-11 18:26:55.078686] [freebsd-x86_64]
>> libavcodec/mpegvideo_enc.c:
>> > In function 'merge_context_after_encode':
>> >
>> > [2018-03-11 18:26:55.081607] [freebsd-x86_64]
>> > libavcodec/mpegvideo_enc.c:3578:33: error: invalid operands to binary +
>> > (have 'atomic_int' and 'atomic_int')
>> >
>> >
>> > [2018-03-11 16:43:23.543072] [freebsd-x86_64] CC
>> libavcodec/mpeg12dec.o
>> >
>> > [2018-03-11 16:43:23.768864] [freebsd-x86_64] libavcodec/mpeg12dec.c: In
>> > function 'slice_decode_thread':
>> >
>>
>> > [2018-03-11 16:43:23.769713] [freebsd-x86_64]
>> > libavcodec/mpeg12dec.c:1996:23: error: incompatible types when
>> assigning to
>> > type 'atomic_int' from type 'int'
>>
>> what compiler is this ?
>
>
> Target: x86_64-portbld-freebsd10.1
> gcc version 4.8.5 (FreeBSD Ports Collection)
>

I ran `pkg update` and `pkg install gcc` and it upgraded me to:

gcc version 6.4.0 (FreeBSD Ports Collection)

Now I don't see these errors anymore. So you can consider this patchset
abandoned.

Aman


>
>
>
>> 6.5.16.1 Simple assignment
>> Constraints
>> One of the following shall hold: 114)
>> — the left operand has atomic, qualified, or unqualified arithmetic
>> type, and the right has
>> arithmetic type;
>>
>> Please someone correct me here if iam wrong but
>> To me this sounds like doing normal arithmetic operations between atomic
>> and
>> non atomic arithmetic types is allowed.
>>
>>
>>
>> [...]
>>
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Those who are best at talking, realize last or never when they are wrong.
>> ___
>> 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] avcodec/hapqa_extract_bsf : add bsf filter for haqqa (to hapq or hapalpha only) conversion

2018-03-13 Thread Martin Vignali
>
> Should be ok now.
> ___
>
>
Pushed, thanks.

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


Re: [FFmpeg-devel] fate/hap : add test for hap encoding

2018-03-13 Thread Martin Vignali
2018-03-11 19:37 GMT+01:00 Martin Vignali :

>
>
> 2017-11-26 18:25 GMT+01:00 Martin Vignali :
>
>> Hello,
>>
>> Patch in attach, add test for hap encoding (currently not cover) (patch
>> 002)
>> and move decoding tests to a separate file (patch 001)
>>
>> decoding can be test with
>> make fate-hap SAMPLES=fate-suite/
>>
>> and encoding can be test with
>> make fate-hapenc SAMPLES=fate-suite/
>>
>> Hap encoding need ffmpeg compile with libsnappy (--enable-libsnappy)
>>
>>
> If noone is against,
> i plan to apply this in few days.
>
> In attach, updated patch (in order to apply it on master).
>
> Martin
>
>
Pushed.

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


Re: [FFmpeg-devel] [CLT2018] FFmpeg at Chemnitzer Linux-Tage

2018-03-13 Thread Thilo Borgmann
Am 13.03.18 um 19:52 schrieb Paul B Mahol:
> On 3/13/18, Thilo Borgmann  wrote:
>> Hi,
>>
>>> once again, FFmpeg has been accepted for CLT 2018 in Chemnitz, Germany!
>>> This "Chemnitzer Linux Tage" will take place on 10th and 11th of March.
>>> You can find more details on their homepage:
>>>
>>> https://chemnitzer.linux-tage.de/2018/en/
>>>
>>> Thus once again, we will man a booth with our staff and are happily
>>> waiting for
>>> our users to get in touch with us! If you're a developer and want to help
>>> us or
>>> just want to visit and check in at our booth, please let us know.
>>
>> we've returned from the CLT. This year has been the 20th anniversary of the
>> CLT - so they'd put some additional effort into it to make it even a better
>> pleasure for all the exhibitors. Most notably in terms of an updated
>> Saturday dinner :)
>>
>> We presented our usual demo using motion vector overlay to attract people
>> and Thomas and Alexander created a very nice new demo for visualization
>> filters, command-line expressions and video output, randomly altered. We
>> again had a lot of users coming by and Gerion also gave a workshop on
>> command-line based filtering.
> 
> Which filter where used?

Alexander knows about the complete list, maybe he can answer to that in 
particular.


> From older cases, they were not enough covered, causing users asking for 
> filters
> which are already available.

Hmm.. I had not heard such comments or not to a high enough extend so that this 
problem has made it into my memory. Just don't forget about two aspects here, 
first, the complete list of filters is not what we aim to show, but to give 
some examples to get people talking to us and asking questions (so a question 
if we also have filter XY would be a good result of the demo), and second, not 
all filters are presentable - most people seeing the demo have untrained eyes 
looking at it and therefore a hardly recognizable filter might result in their 
thought of what the hell we are doing at all there... and that thought is to be 
avoided by a demo :)

However, if you (or anyone) wants a particular thing to be included in our 
demos, just give that remark early enough and we will happily include it. We 
would like to have even more ideas next time!


>> The hotel we're used to stay in at Chemnitz also improved their interiors so
>> it felt like a completely upgraded version of the CLT this year.
>> Reimbursement request for the four of us will follow as well as the usual
>> photo upload to our social medias.

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


Re: [FFmpeg-devel] [CLT2018] FFmpeg at Chemnitzer Linux-Tage

2018-03-13 Thread Paul B Mahol
On 3/13/18, Thilo Borgmann  wrote:
> Hi,
>
>> once again, FFmpeg has been accepted for CLT 2018 in Chemnitz, Germany!
>> This "Chemnitzer Linux Tage" will take place on 10th and 11th of March.
>> You can find more details on their homepage:
>>
>> https://chemnitzer.linux-tage.de/2018/en/
>>
>> Thus once again, we will man a booth with our staff and are happily
>> waiting for
>> our users to get in touch with us! If you're a developer and want to help
>> us or
>> just want to visit and check in at our booth, please let us know.
>
> we've returned from the CLT. This year has been the 20th anniversary of the
> CLT - so they'd put some additional effort into it to make it even a better
> pleasure for all the exhibitors. Most notably in terms of an updated
> Saturday dinner :)
>
> We presented our usual demo using motion vector overlay to attract people
> and Thomas and Alexander created a very nice new demo for visualization
> filters, command-line expressions and video output, randomly altered. We
> again had a lot of users coming by and Gerion also gave a workshop on
> command-line based filtering.

Which filter where used?
From older cases, they were not enough covered, causing users asking for filters
which are already available.


>
> The hotel we're used to stay in at Chemnitz also improved their interiors so
> it felt like a completely upgraded version of the CLT this year.
> Reimbursement request for the four of us will follow as well as the usual
> photo upload to our social medias.
>
> Thanks,
> Thilo
> ___
> 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] [CLT2018] FFmpeg at Chemnitzer Linux-Tage

2018-03-13 Thread Thilo Borgmann
Hi,

> once again, FFmpeg has been accepted for CLT 2018 in Chemnitz, Germany!
> This "Chemnitzer Linux Tage" will take place on 10th and 11th of March.
> You can find more details on their homepage:
> 
> https://chemnitzer.linux-tage.de/2018/en/
> 
> Thus once again, we will man a booth with our staff and are happily waiting 
> for
> our users to get in touch with us! If you're a developer and want to help us 
> or
> just want to visit and check in at our booth, please let us know.

we've returned from the CLT. This year has been the 20th anniversary of the CLT 
- so they'd put some additional effort into it to make it even a better 
pleasure for all the exhibitors. Most notably in terms of an updated Saturday 
dinner :)

We presented our usual demo using motion vector overlay to attract people and 
Thomas and Alexander created a very nice new demo for visualization filters, 
command-line expressions and video output, randomly altered. We again had a lot 
of users coming by and Gerion also gave a workshop on command-line based 
filtering.

The hotel we're used to stay in at Chemnitz also improved their interiors so it 
felt like a completely upgraded version of the CLT this year. Reimbursement 
request for the four of us will follow as well as the usual photo upload to our 
social medias.

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


Re: [FFmpeg-devel] [PATCH v3] avcodec: fix atomics usage for h264/mpeg error_count

2018-03-13 Thread Aman Gupta
On Tue, Mar 13, 2018 at 11:34 AM Michael Niedermayer 
wrote:

> On Tue, Mar 13, 2018 at 04:02:57PM +, Aman Gupta wrote:
> > On Tue, Mar 13, 2018 at 4:39 AM Michael Niedermayer
> 
> > wrote:
> >
> > > On Mon, Mar 12, 2018 at 06:49:19PM -0700, Aman Gupta wrote:
> > > > From: Aman Gupta 
> > > >
> > > > ---
> > > >  libavcodec/h264_slice.c|  5 +++--
> > > >  libavcodec/mpeg12dec.c | 12 +++-
> > > >  libavcodec/mpegvideo_enc.c |  3 ++-
> > > >  3 files changed, 12 insertions(+), 8 deletions(-)
> > >
> > > Iam a little bit confused, you write about "fixing" but not what this
> is
> > > fixing and it appears there are several distinct types of changes
> >
> >
> > The type of error_count is already atomic_int. I don't know when that was
> > changed.
> >
> > The fix here is that these files do not compile on FreeBSD because of
> > errors such as:
> >
> > [2018-03-11 18:26:55.078686] [freebsd-x86_64] libavcodec/mpegvideo_enc.c:
> > In function 'merge_context_after_encode':
> >
> > [2018-03-11 18:26:55.081607] [freebsd-x86_64]
> > libavcodec/mpegvideo_enc.c:3578:33: error: invalid operands to binary +
> > (have 'atomic_int' and 'atomic_int')
> >
> >
> > [2018-03-11 16:43:23.543072] [freebsd-x86_64] CC
> libavcodec/mpeg12dec.o
> >
> > [2018-03-11 16:43:23.768864] [freebsd-x86_64] libavcodec/mpeg12dec.c: In
> > function 'slice_decode_thread':
> >
>
> > [2018-03-11 16:43:23.769713] [freebsd-x86_64]
> > libavcodec/mpeg12dec.c:1996:23: error: incompatible types when assigning
> to
> > type 'atomic_int' from type 'int'
>
> what compiler is this ?


Target: x86_64-portbld-freebsd10.1
gcc version 4.8.5 (FreeBSD Ports Collection)



> 6.5.16.1 Simple assignment
> Constraints
> One of the following shall hold: 114)
> — the left operand has atomic, qualified, or unqualified arithmetic
> type, and the right has
> arithmetic type;
>
> Please someone correct me here if iam wrong but
> To me this sounds like doing normal arithmetic operations between atomic
> and
> non atomic arithmetic types is allowed.
>
>
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are best at talking, realize last or never when they are wrong.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v3] avcodec: fix atomics usage for h264/mpeg error_count

2018-03-13 Thread Michael Niedermayer
On Tue, Mar 13, 2018 at 04:02:57PM +, Aman Gupta wrote:
> On Tue, Mar 13, 2018 at 4:39 AM Michael Niedermayer 
> wrote:
> 
> > On Mon, Mar 12, 2018 at 06:49:19PM -0700, Aman Gupta wrote:
> > > From: Aman Gupta 
> > >
> > > ---
> > >  libavcodec/h264_slice.c|  5 +++--
> > >  libavcodec/mpeg12dec.c | 12 +++-
> > >  libavcodec/mpegvideo_enc.c |  3 ++-
> > >  3 files changed, 12 insertions(+), 8 deletions(-)
> >
> > Iam a little bit confused, you write about "fixing" but not what this is
> > fixing and it appears there are several distinct types of changes
> 
> 
> The type of error_count is already atomic_int. I don't know when that was
> changed.
> 
> The fix here is that these files do not compile on FreeBSD because of
> errors such as:
> 
> [2018-03-11 18:26:55.078686] [freebsd-x86_64] libavcodec/mpegvideo_enc.c:
> In function 'merge_context_after_encode':
> 
> [2018-03-11 18:26:55.081607] [freebsd-x86_64]
> libavcodec/mpegvideo_enc.c:3578:33: error: invalid operands to binary +
> (have 'atomic_int' and 'atomic_int')
> 
> 
> [2018-03-11 16:43:23.543072] [freebsd-x86_64] CClibavcodec/mpeg12dec.o
> 
> [2018-03-11 16:43:23.768864] [freebsd-x86_64] libavcodec/mpeg12dec.c: In
> function 'slice_decode_thread':
> 

> [2018-03-11 16:43:23.769713] [freebsd-x86_64]
> libavcodec/mpeg12dec.c:1996:23: error: incompatible types when assigning to
> type 'atomic_int' from type 'int'

what compiler is this ?
6.5.16.1 Simple assignment
Constraints
One of the following shall hold: 114)
— the left operand has atomic, qualified, or unqualified arithmetic type, 
and the right has
arithmetic type;

Please someone correct me here if iam wrong but
To me this sounds like doing normal arithmetic operations between atomic and
non atomic arithmetic types is allowed.



[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


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


Re: [FFmpeg-devel] [PATCH v3] avcodec: fix atomics usage for h264/mpeg error_count

2018-03-13 Thread Aman Gupta
On Tue, Mar 13, 2018 at 4:39 AM Michael Niedermayer 
wrote:

> On Mon, Mar 12, 2018 at 06:49:19PM -0700, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > ---
> >  libavcodec/h264_slice.c|  5 +++--
> >  libavcodec/mpeg12dec.c | 12 +++-
> >  libavcodec/mpegvideo_enc.c |  3 ++-
> >  3 files changed, 12 insertions(+), 8 deletions(-)
>
> Iam a little bit confused, you write about "fixing" but not what this is
> fixing and it appears there are several distinct types of changes


The type of error_count is already atomic_int. I don't know when that was
changed.

The fix here is that these files do not compile on FreeBSD because of
errors such as:

[2018-03-11 18:26:55.078686] [freebsd-x86_64] libavcodec/mpegvideo_enc.c:
In function 'merge_context_after_encode':

[2018-03-11 18:26:55.081607] [freebsd-x86_64]
libavcodec/mpegvideo_enc.c:3578:33: error: invalid operands to binary +
(have 'atomic_int' and 'atomic_int')


[2018-03-11 16:43:23.543072] [freebsd-x86_64] CClibavcodec/mpeg12dec.o

[2018-03-11 16:43:23.768864] [freebsd-x86_64] libavcodec/mpeg12dec.c: In
function 'slice_decode_thread':

[2018-03-11 16:43:23.769713] [freebsd-x86_64]
libavcodec/mpeg12dec.c:1996:23: error: incompatible types when assigning to
type 'atomic_int' from type 'int'

[2018-03-11 16:43:23.769808] [freebsd-x86_64]  s->er.error_count = (3 *
(s->end_mb_y - s->start_mb_y) * s->mb_width) >> field_pic;


[2018-03-11 15:40:00.186073] [freebsd-x86_64] CClibavcodec/h264_slice.o

[2018-03-11 15:40:00.335377] [freebsd-x86_64] libavcodec/h264_slice.c: In
function 'ff_h264_execute_decode_slices':

[2018-03-11 15:40:00.336554] [freebsd-x86_64]
libavcodec/h264_slice.c:2765:36: error: incompatible types when assigning
to type 'atomic_int' from type 'int'

[2018-03-11 15:40:00.336639] [freebsd-x86_64]
sl->er.error_count
= 0;

Aman


>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Asymptotically faster algorithms should always be preferred if you have
> asymptotical amounts of data
> ___
> 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] [RFC][PATCH] avformat/mxfdec: provide some mxf DigitalVideoAndImageCompressionParameters as metadata

2018-03-13 Thread Tomas Härdin
fre 2018-03-09 klockan 22:34 +0100 skrev Marton Balint:
> Would this be useful for anybody?

I've never even run into this before, so I can't really say. Maybe?

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


Re: [FFmpeg-devel] [PATCH] avcodec/mediacodecdec: fix immediate EAGAIN with buffered packet

2018-03-13 Thread Matthieu Bouron
On Tue, Mar 13, 2018 at 02:46:57AM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> In cases where the mediacodec decoder consumed a partial packet,
> receive_frame() would start returning EAGAIN if the rest of the
> packet couldn't be flushed and no frames were immediately available.
> 
> This fixes receive_frame() to perform its normal blocking wait for
> new frames before returning EAGAIN. Fixes an issue I could reproduce
> fairly often on a FireOS 6 device, and reported to be happening
> intermittently by two mpv users.
> ---
>  libavcodec/mediacodecdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 89d2421ae9..0d4a853f07 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -452,7 +452,7 @@ static int mediacodec_receive_frame(AVCodecContext 
> *avctx, AVFrame *frame)
>  
>  /* skip fetching new packet if we still have one buffered */
>  if (s->buffered_pkt.size > 0)
> -return AVERROR(EAGAIN);
> +return mediacodec_send_receive(avctx, s, frame, true);
>  
>  /* fetch new packet or eof */
>  ret = ff_decode_get_packet(avctx, >buffered_pkt);
> -- 
> 2.14.2
> 

LGTM.

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


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

2018-03-13 Thread Vasile Toncu



On 06.03.2018 20:38, Thomas Mundt wrote:

Hi,

2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos :


2018-03-05 12:37 GMT+01:00, Paul B Mahol :

On 3/5/18, Vasile Toncu  wrote:

Hello,

Thanks for the review. I've made changes according to your guidance.

It would be great to know if the community will go on with our intention
of adding reinterlace as a alternative for tinterlace.

That being said, here is the new patch.

As already said, this is not acceptable.

There is no point in having 2 filters with near same funcionality.

If you consider the new filter ok, the existing filter will be removed
in the same push. I believe sending only the new filter makes
reviewing easier.


For me reviewing would be easier when Vasile sends a patchset that includes
the replacement of tinterlace filter.
That way existing fate tests could be used which are fortunately pretty
extensive in this case.
Also it would be helpful when you and/or other experienced ffmpeg
developers would clarify first which parts of tinterlace have to be
rewritten for proper relicensing.
Being left in the dark makes working on patches frustrating.

Another question is how to deal with vf_interlace? IMHO for the user there
should be no difference in output, speed and license.
Two options:
1. Relicensing and slice threading will also be ported to vf_interlace
2. The commands from vf_interlace will be included in the new tinterlace
filter. vf_interlace will be deleted together with old tinterlace filter

I would prefer the second option, but maybe there are even better options
that don´t come to my mind.

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


Hello everyone,

sorry for a delayed response.

From what has been discussed in here, I think the reinterlace will 
exist with tinterlace for a period of time, just after that the 
tinterlace can be removed.


To have the reinterlace added, what is needed to be done from my side?

Thanks,
Vasile Toncu

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


Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: provide detail error message if parameters invalid

2018-03-13 Thread Li, Zhong
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Moritz Barsnick
> Sent: Tuesday, March 13, 2018 6:13 PM
> To: FFmpeg development discussions and patches
> 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: provide detail error
> message if parameters invalid
> 
> On Fri, Mar 02, 2018 at 11:24:10 +0800, Zhong Li wrote:
> >  ret = MFXVideoENCODE_Query(q->session, >param,
> _out);
> > -if (ret < 0 ||
> > -param_out.mfx.RateControlMethod !=
> q->param.mfx.RateControlMethod)
> 
> This original code gave the impression that a mismatch of
> RateControlMethod was not reported by MFXVideoENCODE_Query(), and
> therefore checked separately. You are not doing that anymore.
That is an intentional behavior. If current bit rate control mode is not 
supported. MFXVideoENCODE_Query() should return an invalid value as MSDK 
documentation. 
> 
> > +if (UNMATCH(FrameInfo.FrameRateExtN) ||
> > + UNMATCH(FrameInfo.FrameRateExtN))
> 
> Typo? (Both macro arguments are identical.)
Yes, it is should be "FrameInfo.FrameRateExtD", I have a patch to fix it and 
will send soon.
> 
> Moritz

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


Re: [FFmpeg-devel] [PATCH v3] avcodec: fix atomics usage for h264/mpeg error_count

2018-03-13 Thread Michael Niedermayer
On Mon, Mar 12, 2018 at 06:49:19PM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  libavcodec/h264_slice.c|  5 +++--
>  libavcodec/mpeg12dec.c | 12 +++-
>  libavcodec/mpegvideo_enc.c |  3 ++-
>  3 files changed, 12 insertions(+), 8 deletions(-)

Iam a little bit confused, you write about "fixing" but not what this is
fixing and it appears there are several distinct types of changes


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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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


Re: [FFmpeg-devel] [PATCH 1/8] cbs_h264: Fix overflow in shifts

2018-03-13 Thread Michael Niedermayer
On Sun, Mar 11, 2018 at 06:30:14PM +, Mark Thompson wrote:
> The type of the result of a shift operation is unaffected by the type of
> the right operand, so some existing code overflows with undefined behaviour
> when the element length is 32.  Add a helper macro to calculate the maximum
> value correctly and then use it everywhere this pattern appears.
> 
> Found-by: Andreas Rheinhardt 
> ---
>  libavcodec/cbs_h264_syntax_template.c | 22 +++---
>  libavcodec/cbs_internal.h |  4 
>  2 files changed, 15 insertions(+), 11 deletions(-)

should be ok

thx

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

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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


Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: provide detail error message if parameters invalid

2018-03-13 Thread Moritz Barsnick
On Fri, Mar 02, 2018 at 11:24:10 +0800, Zhong Li wrote:
>  ret = MFXVideoENCODE_Query(q->session, >param, _out);
> -if (ret < 0 ||
> -param_out.mfx.RateControlMethod != q->param.mfx.RateControlMethod)

This original code gave the impression that a mismatch of
RateControlMethod was not reported by MFXVideoENCODE_Query(), and
therefore checked separately. You are not doing that anymore.

> +if (UNMATCH(FrameInfo.FrameRateExtN) || 
> UNMATCH(FrameInfo.FrameRateExtN))

Typo? (Both macro arguments are identical.)

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


[FFmpeg-devel] [PATCH 2/2] avformat/hlsenc: use frag_every_frame flag to make fmp4

2018-03-13 Thread Steven Liu
fix ticket: #7023

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 185e3442f6..28e0047cf0 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -782,7 +782,7 @@ static int hls_mux_init(AVFormatContext *s, VariantStream 
*vs)
 
 av_dict_copy(, hls->format_options, 0);
 av_dict_set(, "fflags", "-autobsf", 0);
-av_dict_set(, "movflags", "frag_custom+dash+delay_moov", 0);
+av_dict_set(, "movflags", "frag_every_frame+dash+delay_moov", 
0);
 ret = avformat_init_output(oc, );
 if (ret < 0)
 return ret;
-- 
2.15.1



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


[FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: remove unnecessary variate and logic

2018-03-13 Thread Steven Liu
write init file and first segment at the same time,
so remove the unnecessary variate and logic.

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index d319cba764..185e3442f6 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -111,7 +111,6 @@ typedef struct VariantStream {
 AVOutputFormat *oformat;
 AVOutputFormat *vtt_oformat;
 AVIOContext *out;
-int packets_written;
 int init_range_length;
 
 AVFormatContext *avf;
@@ -745,7 +744,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream 
*vs)
 av_dict_copy(>metadata, vs->streams[i]->metadata, 0);
 }
 
-vs->packets_written = 1;
 vs->start_pos = 0;
 vs->new_start = 1;
 vs->fmp4_init_mode = 0;
@@ -756,7 +754,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream 
*vs)
 return AVERROR_PATCHWELCOME;
 }
 
-vs->packets_written = 0;
 vs->init_range_length = 0;
 vs->fmp4_init_mode = !byterange_mode;
 set_http_options(s, , hls);
@@ -2170,7 +2167,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 
 }
 
-if (vs->packets_written && can_split && av_compare_ts(pkt->pts - 
vs->start_pts, st->time_base,
+if (can_split && av_compare_ts(pkt->pts - vs->start_pts, st->time_base,
   end_pts, 
AV_TIME_BASE_Q) >= 0) {
 int64_t new_start_pos;
 char *old_filename = NULL;
@@ -2192,7 +2189,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 avio_write(vs->out, buffer, range_length);
 vs->init_range_length = range_length;
 avio_open_dyn_buf(>pb);
-vs->packets_written = 0;
 vs->start_pos = range_length;
 if (!byterange_mode) {
 ff_format_io_close(s, >out);
@@ -2216,10 +2212,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 hls_rename_temp_file(s, oc);
 }
 
-if (vs->fmp4_init_mode) {
-vs->number--;
-}
-
 if (hls->segment_type == SEGMENT_TYPE_FMP4) {
 if (hls->flags & HLS_SINGLE_FILE) {
 ret = flush_dynbuf(vs, _length);
@@ -2295,7 +2287,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 }
 }
 
-vs->packets_written++;
 ret = ff_write_chained(oc, stream_index, pkt, s, 0);
 
 return ret;
-- 
2.15.1



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


Re: [FFmpeg-devel] [PATCH v3] avcodec: fix atomics usage for h264/mpeg error_count

2018-03-13 Thread Aman Gupta
On Mon, Mar 12, 2018 at 6:49 PM, Aman Gupta  wrote:

> From: Aman Gupta 
>
> ---
>  libavcodec/h264_slice.c|  5 +++--
>  libavcodec/mpeg12dec.c | 12 +++-
>  libavcodec/mpegvideo_enc.c |  3 ++-
>  3 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 90e05ed8f1..b381397b4d 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -2762,7 +2762,7 @@ int ff_h264_execute_decode_slices(H264Context *h)
>
>  sl = >slice_ctx[i];
>  if (CONFIG_ERROR_RESILIENCE) {
> -sl->er.error_count = 0;
> +sl->er.error_count = ATOMIC_VAR_INIT(0);
>  }
>
>  /* make sure none of those slices overlap */
> @@ -2786,7 +2786,8 @@ int ff_h264_execute_decode_slices(H264Context *h)
>  h->mb_y  = sl->mb_y;
>  if (CONFIG_ERROR_RESILIENCE) {
>  for (i = 1; i < context_count; i++)
> -h->slice_ctx[0].er.error_count +=
> h->slice_ctx[i].er.error_count;
> +atomic_fetch_add(>slice_ctx[0].er.error_count,
> + atomic_load(>slice_ctx[i].
> er.error_count));
>  }
>
>  if (h->postpone_filter) {
> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> index 9e076e89da..5a8570672c 100644
> --- a/libavcodec/mpeg12dec.c
> +++ b/libavcodec/mpeg12dec.c
> @@ -1992,7 +1992,7 @@ static int slice_decode_thread(AVCodecContext *c,
> void *arg)
>  int mb_y= s->start_mb_y;
>  const int field_pic = s->picture_structure != PICT_FRAME;
>
> -s->er.error_count = (3 * (s->end_mb_y - s->start_mb_y) * s->mb_width)
> >> field_pic;
> +s->er.error_count = ATOMIC_VAR_INIT((3 * (s->end_mb_y -
> s->start_mb_y) * s->mb_width) >> field_pic);
>
>  for (;;) {
>  uint32_t start_code;
> @@ -2002,7 +2002,7 @@ static int slice_decode_thread(AVCodecContext *c,
> void *arg)
>  emms_c();
>  ff_dlog(c, "ret:%d resync:%d/%d mb:%d/%d ts:%d/%d ec:%d\n",
>  ret, s->resync_mb_x, s->resync_mb_y, s->mb_x, s->mb_y,
> -s->start_mb_y, s->end_mb_y, s->er.error_count);
> +s->start_mb_y, s->end_mb_y, atomic_load(>er.error_
> count));
>  if (ret < 0) {
>  if (c->err_recognition & AV_EF_EXPLODE)
>  return ret;
> @@ -2485,7 +2485,8 @@ static int decode_chunks(AVCodecContext *avctx,
> AVFrame *picture,
> >thread_context[0], NULL,
> s->slice_count, sizeof(void *));
>  for (i = 0; i < s->slice_count; i++)
> -s2->er.error_count += s2->thread_context[i]->er.
> error_count;
> +atomic_fetch_add(>er.error_count,
> + atomic_load(>thread_
> context[i]->er.error_count));
>  }
>
>  ret = slice_end(avctx, picture);
> @@ -2499,7 +2500,7 @@ static int decode_chunks(AVCodecContext *avctx,
> AVFrame *picture,
>  }
>  s2->pict_type = 0;
>
> -if (avctx->err_recognition & AV_EF_EXPLODE &&
> s2->er.error_count)
> +if (avctx->err_recognition & AV_EF_EXPLODE &&
> atomic_load(>er.error_count))
>  return AVERROR_INVALIDDATA;
>
>  return FFMAX(0, buf_ptr - buf - s2->parse_context.last_index);
> @@ -2553,7 +2554,8 @@ static int decode_chunks(AVCodecContext *avctx,
> AVFrame *picture,
> s2->thread_context, NULL,
> s->slice_count, sizeof(void *));
>  for (i = 0; i < s->slice_count; i++)
> -s2->er.error_count += s2->thread_context[i]->er.
> error_count;
> +atomic_fetch_add(>er.error_count,
> + atomic_load(>thread_
> context[i]->er.error_count));
>  s->slice_count = 0;
>  }
>  if (last_code == 0 || last_code == SLICE_MIN_START_CODE) {
> diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
> index 979e138b88..3447c5e87a 100644
> --- a/libavcodec/mpegvideo_enc.c
> +++ b/libavcodec/mpegvideo_enc.c
> @@ -3595,7 +3595,8 @@ static void merge_context_after_encode(MpegEncContext
> *dst, MpegEncContext *src)
>  MERGE(b_count);
>  MERGE(skip_count);
>  MERGE(misc_bits);
> -MERGE(er.error_count);
> +atomic_fetch_add(>er.error_count, atomic_load(>er.error_
> count));
> +atomic_store(>er.error_count, 0);
>  MERGE(padding_bug_score);
>  MERGE(current_picture.encoding_error[0]);
>  MERGE(current_picture.encoding_error[1]);
>

There was some uncertainty on IRC about whether the usages of
atomic_store() and ATOMIC_VAR_INIT() in this patch were correct, or needed
to be swapped.

Would appreciate if someone familiar with the error 

[FFmpeg-devel] [PATCH] avcodec/mediacodecdec: fix immediate EAGAIN with buffered packet

2018-03-13 Thread Aman Gupta
From: Aman Gupta 

In cases where the mediacodec decoder consumed a partial packet,
receive_frame() would start returning EAGAIN if the rest of the
packet couldn't be flushed and no frames were immediately available.

This fixes receive_frame() to perform its normal blocking wait for
new frames before returning EAGAIN. Fixes an issue I could reproduce
fairly often on a FireOS 6 device, and reported to be happening
intermittently by two mpv users.
---
 libavcodec/mediacodecdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 89d2421ae9..0d4a853f07 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -452,7 +452,7 @@ static int mediacodec_receive_frame(AVCodecContext *avctx, 
AVFrame *frame)
 
 /* skip fetching new packet if we still have one buffered */
 if (s->buffered_pkt.size > 0)
-return AVERROR(EAGAIN);
+return mediacodec_send_receive(avctx, s, frame, true);
 
 /* fetch new packet or eof */
 ret = ff_decode_get_packet(avctx, >buffered_pkt);
-- 
2.14.2

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