[FFmpeg-devel] [PATCH] avfilter/vf_guided: support single input
From: Xuewei Meng
Support single input for guided filter by adding guidance mode.
If the guidance mode is off, single input is required. And
edge-preserving smoothing is conducted. If the mode is on, two
inputs are needed. The second input serves as the guidance. For
this mode, more tasks are supported, such as detail enhancement,
dehazing and so on.
Signed-off-by: Xuewei Meng
---
doc/filters.texi| 12 ++--
libavfilter/vf_guided.c | 168
2 files changed, 119 insertions(+), 61 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 78faf76..5c362c0 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12975,8 +12975,6 @@ greyedge=difford=1:minknorm=0:sigma=2
@section guided
Apply guided filter for edge-preserving smoothing, dehazing and so on.
-This filter requires two inputs of same resolution and pixel format.
-The second input serves as the reference.
The filter accepts the following options:
@table @option
@@ -12997,6 +12995,12 @@ Set subsampling ratio for @code{fast} mode.
Range is 2 to 64. Default is 4.
No subsampling occurs in @code{basic} mode.
+@item guidance
+Set guidance mode. Can be @code{off} or @code{on}. Default is @code{off}.
+If @code{off}, single input is required.
+If @code{on}, two inputs of the same resolution and pixel format are required.
+The second input serves as the guidance.
+
@item planes
Set planes to filter. Default is first only.
@end table
@@ -13009,7 +13013,7 @@ This filter supports the all above options as
@ref{commands}.
@item
Edge-preserving smoothing with guided filter:
@example
-ffmpeg -i in.png -i in.png -filter_complex guided out.png
+ffmpeg -i in.png -vf guided out.png
@end example
@item
@@ -13017,7 +13021,7 @@ Dehazing, structure-transferring filtering, detail
enhancement with guided filte
For the generation of guidance image, refer to paper "Guided Image Filtering".
See: @url{http://kaiminghe.com/publications/pami12guidedfilter.pdf}.
@example
-ffmpeg -i in.png -i guidance.png -filter_complex guided out.png
+ffmpeg -i in.png -i guidance.png -filter_complex guided=guidance=on out.png
@end example
@end itemize
diff --git a/libavfilter/vf_guided.c b/libavfilter/vf_guided.c
index ea537e4..739d615 100644
--- a/libavfilter/vf_guided.c
+++ b/libavfilter/vf_guided.c
@@ -22,6 +22,7 @@
#include "libavutil/opt.h"
#include "libavutil/pixdesc.h"
#include "avfilter.h"
+#include "filters.h"
#include "formats.h"
#include "framesync.h"
#include "internal.h"
@@ -33,6 +34,12 @@ enum FilterModes {
NB_MODES,
};
+enum GuidanceModes {
+OFF,
+ON,
+NB_GUIDANCE_MODES,
+};
+
typedef struct GuidedContext {
const AVClass *class;
FFFrameSync fs;
@@ -41,7 +48,7 @@ typedef struct GuidedContext {
float eps;
int mode;
int sub;
-
+int guidance;
int planes;
int width;
@@ -59,13 +66,16 @@ typedef struct GuidedContext {
#define FLAGS
AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_RUNTIME_PARAM
static const AVOption guided_options[] = {
-{ "radius", "set the box radius",
OFFSET(radius), AV_OPT_TYPE_INT, {.i64 = 3}, 1, 20, FLAGS },
-{ "eps","set the regularization parameter (with square)",
OFFSET(eps),AV_OPT_TYPE_FLOAT, {.dbl = 0.01 }, 0.0,1, FLAGS },
-{ "mode", "set filtering mode (0: basic mode; 1: fast mode)",
OFFSET(mode), AV_OPT_TYPE_INT, {.i64 = BASIC}, BASIC, NB_MODES - 1, FLAGS,
"mode" },
-{ "basic", "basic guided filter", 0,
AV_OPT_TYPE_CONST, {.i64 = BASIC}, 0,0, FLAGS, "mode" },
-{ "fast", "fast guided filter", 0,
AV_OPT_TYPE_CONST, {.i64 = FAST }, 0,0, FLAGS, "mode" },
-{ "sub","subsampling ratio for fast mode",
OFFSET(sub),AV_OPT_TYPE_INT, {.i64 = 4}, 2, 64, FLAGS },
-{ "planes", "set planes to filter",
OFFSET(planes), AV_OPT_TYPE_INT, {.i64=1 }, 0, 0xF, FLAGS },
+{ "radius", "set the box radius",
OFFSET(radius), AV_OPT_TYPE_INT, {.i64 = 3}, 1,
20, FLAGS },
+{ "eps", "set the regularization parameter (with square)",
OFFSET(eps), AV_OPT_TYPE_FLOAT, {.dbl = 0.01 }, 0.0,
1, FLAGS },
+{ "mode", "set filtering mode (0: basic mode; 1: fast mode)",
OFFSET(mode), AV_OPT_TYPE_INT, {.i64 = BASIC}, BASIC, NB_MODES -
1, FLAGS, "mode" },
+{ "basic","basic guided filter", 0,
AV_OPT_TYPE_CONST, {.i64 = BASIC}, 0, 0,
FLAGS, "mode" },
+{ "fast", "fast guided filter", 0,
AV_OPT_TYPE_CONST, {.i64 = FAST }, 0,
Re: [FFmpeg-devel] [PATCH] libavcodec/libx265: add user data unregistered SEI encoding
On Saturday, 5 June 2021 8:20:28 PM AEST Brad Hards wrote:
> ---
> libavcodec/libx265.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> index 90658d3d9e..35547a5a69 100644
> --- a/libavcodec/libx265.c
> +++ b/libavcodec/libx265.c
> @@ -51,6 +51,9 @@ typedef struct libx265Context {
> char *profile;
> AVDictionary *x265_opts;
>
> +void *sei_data;
> +int sei_data_size;
> +
> /**
> * If the encoder does not support ROI then warn the first time we
> * encounter a frame with ROI side data.
> @@ -489,6 +492,8 @@ static int libx265_encode_frame(AVCodecContext *avctx,
> AVPacket *pkt, ctx->api->picture_init(ctx->params, &x265pic);
>
> if (pic) {
> +x265_sei *sei = &(x265pic.userSEI);
> +sei->numPayloads = 0;
> for (i = 0; i < 3; i++) {
> x265pic.planes[i] = pic->data[i];
> x265pic.stride[i] = pic->linesize[i];
> @@ -516,6 +521,32 @@ static int libx265_encode_frame(AVCodecContext *avctx,
> AVPacket *pkt,
>
> memcpy(x265pic.userData, &pic->reordered_opaque,
> sizeof(pic->reordered_opaque)); }
> +
> +for (i = 0; i < pic->nb_side_data; i++) {
> +AVFrameSideData *side_data = pic->side_data[i];
> +void *tmp;
> +
> +if (side_data->type != AV_FRAME_DATA_SEI_UNREGISTERED)
> +continue;
> +
> +tmp = av_fast_realloc(ctx->sei_data,
> + &ctx->sei_data_size,
> + (sei->numPayloads + 1) *
> sizeof(x265_sei_payload)); +if (!tmp) {
> +av_freep(&x265pic.userData);
> +av_freep(&x265pic.quantOffsets);
> +return AVERROR(ENOMEM);
> +} else {
> +x265_sei_payload *sei_payload;
> +ctx->sei_data = tmp;
> +sei->payloads = ctx->sei_data;
> +sei_payload = &(sei->payloads[sei->numPayloads]);
> +sei_payload->payload = side_data->data;
> +sei_payload->payloadSize = side_data->size;
> +sei_payload->payloadType = USER_DATA_UNREGISTERED;
> +sei->numPayloads++;
> +}
> +}
> }
>
> ret = ctx->api->encoder_encode(ctx->encoder, &nal, &nnal,
Ping on this patch.
Brad
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/ccaption_dec: Make real-time latency configurable
On Sat, Jun 5, 2021 at 11:40 AM Pavel Koshevoy wrote:
> Un-hardcode the 200ms minimum latency between emitting subtitle events
> so that those that wish to receive a subtitle event for every screen
> change could do so.
>
> The problem with delaying realtime output by any amount is that it is
> unknown when the next byte pair that would trigger output will happen.
> It may be within 200ms, or it may be several seconds later -- that's
> not realtime at all.
> ---
> libavcodec/ccaption_dec.c | 4 +++-
> libavcodec/version.h | 2 +-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> index de05d037a8..27c61527f6 100644
> --- a/libavcodec/ccaption_dec.c
> +++ b/libavcodec/ccaption_dec.c
> @@ -238,6 +238,7 @@ struct Screen {
> typedef struct CCaptionSubContext {
> AVClass *class;
> int real_time;
> +int real_time_latency_msec;
> int data_field;
> struct Screen screen[2];
> int active_screen;
> @@ -906,7 +907,7 @@ static int decode(AVCodecContext *avctx, void *data,
> int *got_sub, AVPacket *avp
> }
>
> if (ctx->real_time && ctx->screen_touched &&
> -sub->pts > ctx->last_real_time + av_rescale_q(200, ms_tb,
> AV_TIME_BASE_Q)) {
> +sub->pts >= ctx->last_real_time +
> av_rescale_q(ctx->real_time_latency_msec, ms_tb, AV_TIME_BASE_Q)) {
> ctx->last_real_time = sub->pts;
> ctx->screen_touched = 0;
>
> @@ -927,6 +928,7 @@ static int decode(AVCodecContext *avctx, void *data,
> int *got_sub, AVPacket *avp
> #define SD AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_DECODING_PARAM
> static const AVOption options[] = {
> { "real_time", "emit subtitle events as they are decoded for
> real-time display", OFFSET(real_time), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,
> 1, SD },
> +{ "real_time_latency_msec", "minimum elapsed time between emitting
> real-time subtitle events", OFFSET(real_time_latency_msec),
> AV_OPT_TYPE_INT, { .i64 = 200 }, 0, 500, SD },
> { "data_field", "select data field", OFFSET(data_field),
> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, SD, "data_field" },
> { "auto", "pick first one that appears", 0, AV_OPT_TYPE_CONST, {
> .i64 =-1 }, 0, 0, SD, "data_field" },
> { "first", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0 }, 0, 0, SD,
> "data_field" },
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 48165b9ac4..5b1e9e77f3 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -29,7 +29,7 @@
>
> #define LIBAVCODEC_VERSION_MAJOR 59
> #define LIBAVCODEC_VERSION_MINOR 1
> -#define LIBAVCODEC_VERSION_MICRO 100
> +#define LIBAVCODEC_VERSION_MICRO 101
>
> #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> LIBAVCODEC_VERSION_MINOR, \
> --
> 2.26.2
>
>
Ping. If there are no objections may this be applied?
Thank you,
Pavel.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: fixed jp2k_rsiz and 170M matrix
sön 2021-06-13 klockan 21:48 +0200 skrev Thilo Borgmann:
> Am 13.06.21 um 21:07 schrieb Tomas Härdin:
> > sön 2021-06-06 klockan 05:27 +0300 skrev Valerii Zapodovnikov:
> > > Again. 240M matrix is different from BT.601! And 170M is the same
> > > as BT.601. It is primaries that are the same in 240M and 170M, as
> > > for jp2k_rsiz see page 17 of ST 422:2019. IT WAS THERE since 2006.
> > > This wrong jp2k_rsiz is a copy-paste of header_open_partition_key.
> > > ---
> > > libavformat/mxf.c| 2 +-
> > > libavformat/mxfdec.c | 2 +-
> > > 2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavformat/mxf.c b/libavformat/mxf.c
> > > index 85a65f8718..7c355d789b 100644
> > > --- a/libavformat/mxf.c
> > > +++ b/libavformat/mxf.c
> > > @@ -132,7 +132,7 @@ const MXFCodecUL ff_mxf_color_space_uls[] = {
> > > { {
> > > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x02,0x05,0x00,0x00
> > > }, 14, AVCOL_SPC_RGB }, /* GBR */
> > > { {
> > > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x02,0x06,0x00,0x00
> > > }, 14, AVCOL_SPC_BT2020_NCL }, /* ITU-R BT.2020 Non-Constant Luminance */
> > > /* alternate mappings for encoding */
> > > -{ {
> > > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x02,0x03,0x00,0x00
> > > }, 14, AVCOL_SPC_SMPTE170M }, /* = AVCOL_SPC_SMPTE240M */
> > > +{ {
> > > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x02,0x01,0x00,0x00
> > > }, 14, AVCOL_SPC_SMPTE170M }, /* = AVCOL_SPC_BT470BG */
> > >
> > > { {
> > > 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> > > }, 0, AVCOL_SPC_UNSPECIFIED },
> > > };
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index 3bf480a3a6..9e92ef4175 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -330,7 +330,7 @@ static const uint8_t mxf_encrypted_triplet_key[]
> > > = { 0x06,0x0e,0x2b,0x
> > > static const uint8_t mxf_encrypted_essence_container[] = {
> > > 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0b,0x01,0x00
> > > };
> > > static const uint8_t mxf_sony_mpeg4_extradata[]= {
> > > 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0e,0x06,0x06,0x02,0x02,0x01,0x00,0x00
> > > };
> > > static const uint8_t mxf_avid_project_name[] = {
> > > 0xa5,0xfb,0x7b,0x25,0xf6,0x15,0x94,0xb9,0x62,0xfc,0x37,0x17,0x49,0x2d,0x42,0xbf
> > > };
> > > -static const uint8_t mxf_jp2k_rsiz[] = {
> > > 0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x01,0x00
> > > };
> > > +static const uint8_t mxf_jp2k_rsiz[] = {
> > > 0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x01,0x00,0x00,0x00
> > > };
> > > static const uint8_t mxf_indirect_value_utf16le[] = {
> > > 0x4c,0x00,0x02,0x10,0x01,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
> > > };
> > > static const uint8_t mxf_indirect_value_utf16be[] = {
> > > 0x42,0x01,0x10,0x02,0x00,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
> > > };
> > > static const uint8_t mxf_apple_coll_max_cll[] = {
> > > 0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0e,0x0e,0x20,0x04,0x01,0x05,0x03,0x01,0x01
> > > };
> >
> > These indeed look like copy-paste errors. Patch looks OK to me.
>
> Please apply.
Done
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: fixed jp2k_rsiz and 170M matrix
Am 13.06.21 um 21:07 schrieb Tomas Härdin:
sön 2021-06-06 klockan 05:27 +0300 skrev Valerii Zapodovnikov:
Again. 240M matrix is different from BT.601! And 170M is the same
as BT.601. It is primaries that are the same in 240M and 170M, as
for jp2k_rsiz see page 17 of ST 422:2019. IT WAS THERE since 2006.
This wrong jp2k_rsiz is a copy-paste of header_open_partition_key.
---
libavformat/mxf.c| 2 +-
libavformat/mxfdec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index 85a65f8718..7c355d789b 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -132,7 +132,7 @@ const MXFCodecUL ff_mxf_color_space_uls[] = {
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x02,0x05,0x00,0x00
}, 14, AVCOL_SPC_RGB }, /* GBR */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x02,0x06,0x00,0x00
}, 14, AVCOL_SPC_BT2020_NCL }, /* ITU-R BT.2020 Non-Constant Luminance */
/* alternate mappings for encoding */
-{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x02,0x03,0x00,0x00
}, 14, AVCOL_SPC_SMPTE170M }, /* = AVCOL_SPC_SMPTE240M */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x02,0x01,0x00,0x00
}, 14, AVCOL_SPC_SMPTE170M }, /* = AVCOL_SPC_BT470BG */
{ { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 }, 0, AVCOL_SPC_UNSPECIFIED },
};
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 3bf480a3a6..9e92ef4175 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -330,7 +330,7 @@ static const uint8_t mxf_encrypted_triplet_key[]
= { 0x06,0x0e,0x2b,0x
static const uint8_t mxf_encrypted_essence_container[] = {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0b,0x01,0x00
};
static const uint8_t mxf_sony_mpeg4_extradata[]= {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0e,0x06,0x06,0x02,0x02,0x01,0x00,0x00
};
static const uint8_t mxf_avid_project_name[] = {
0xa5,0xfb,0x7b,0x25,0xf6,0x15,0x94,0xb9,0x62,0xfc,0x37,0x17,0x49,0x2d,0x42,0xbf
};
-static const uint8_t mxf_jp2k_rsiz[] = {
0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x01,0x00
};
+static const uint8_t mxf_jp2k_rsiz[] = {
0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x01,0x00,0x00,0x00
};
static const uint8_t mxf_indirect_value_utf16le[] = {
0x4c,0x00,0x02,0x10,0x01,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
};
static const uint8_t mxf_indirect_value_utf16be[] = {
0x42,0x01,0x10,0x02,0x00,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
};
static const uint8_t mxf_apple_coll_max_cll[] = {
0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0e,0x0e,0x20,0x04,0x01,0x05,0x03,0x01,0x01
};
These indeed look like copy-paste errors. Patch looks OK to me.
Please apply.
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavf/webmdashenc.c: Allow AV1 video in WebM
Hi,
not sure about the spec backing this up, however the following site lists AV1
support in WebM:
https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Video_codecs
-Thilo
From fa6a57486d7fc2cb4d110db05b0b231a2c3046e6 Mon Sep 17 00:00:00 2001
From: Matthieu Patou
Date: Sun, 13 Jun 2021 21:41:06 +0200
Subject: [PATCH] lavf/webmdashenc.c: Allow AV1 video in WebM
Suggested-By: ffm...@fb.com
---
libavformat/webmdashenc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/webmdashenc.c b/libavformat/webmdashenc.c
index 6f9622a..cf69bd3 100644
--- a/libavformat/webmdashenc.c
+++ b/libavformat/webmdashenc.c
@@ -480,7 +480,8 @@ static int webm_dash_manifest_write_header(AVFormatContext
*s)
for (unsigned i = 0; i < s->nb_streams; i++) {
enum AVCodecID codec_id = s->streams[i]->codecpar->codec_id;
if (codec_id != AV_CODEC_ID_VP8&& codec_id != AV_CODEC_ID_VP9 &&
-codec_id != AV_CODEC_ID_VORBIS && codec_id != AV_CODEC_ID_OPUS)
+codec_id != AV_CODEC_ID_AV1&& codec_id != AV_CODEC_ID_VORBIS &&
+codec_id != AV_CODEC_ID_OPUS)
return AVERROR(EINVAL);
}
--
1.8.3.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: fixed jp2k_rsiz and 170M matrix
sön 2021-06-06 klockan 05:27 +0300 skrev Valerii Zapodovnikov:
> Again. 240M matrix is different from BT.601! And 170M is the same
> as BT.601. It is primaries that are the same in 240M and 170M, as
> for jp2k_rsiz see page 17 of ST 422:2019. IT WAS THERE since 2006.
> This wrong jp2k_rsiz is a copy-paste of header_open_partition_key.
> ---
> libavformat/mxf.c| 2 +-
> libavformat/mxfdec.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/mxf.c b/libavformat/mxf.c
> index 85a65f8718..7c355d789b 100644
> --- a/libavformat/mxf.c
> +++ b/libavformat/mxf.c
> @@ -132,7 +132,7 @@ const MXFCodecUL ff_mxf_color_space_uls[] = {
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x02,0x05,0x00,0x00
> }, 14, AVCOL_SPC_RGB }, /* GBR */
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x02,0x06,0x00,0x00
> }, 14, AVCOL_SPC_BT2020_NCL }, /* ITU-R BT.2020 Non-Constant Luminance */
> /* alternate mappings for encoding */
> -{ {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x02,0x03,0x00,0x00
> }, 14, AVCOL_SPC_SMPTE170M }, /* = AVCOL_SPC_SMPTE240M */
> +{ {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x02,0x01,0x00,0x00
> }, 14, AVCOL_SPC_SMPTE170M }, /* = AVCOL_SPC_BT470BG */
>
> { {
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> }, 0, AVCOL_SPC_UNSPECIFIED },
> };
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 3bf480a3a6..9e92ef4175 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -330,7 +330,7 @@ static const uint8_t mxf_encrypted_triplet_key[]
> = { 0x06,0x0e,0x2b,0x
> static const uint8_t mxf_encrypted_essence_container[] = {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0b,0x01,0x00
> };
> static const uint8_t mxf_sony_mpeg4_extradata[]= {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0e,0x06,0x06,0x02,0x02,0x01,0x00,0x00
> };
> static const uint8_t mxf_avid_project_name[] = {
> 0xa5,0xfb,0x7b,0x25,0xf6,0x15,0x94,0xb9,0x62,0xfc,0x37,0x17,0x49,0x2d,0x42,0xbf
> };
> -static const uint8_t mxf_jp2k_rsiz[] = {
> 0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x01,0x00
> };
> +static const uint8_t mxf_jp2k_rsiz[] = {
> 0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x01,0x00,0x00,0x00
> };
> static const uint8_t mxf_indirect_value_utf16le[] = {
> 0x4c,0x00,0x02,0x10,0x01,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
> };
> static const uint8_t mxf_indirect_value_utf16be[] = {
> 0x42,0x01,0x10,0x02,0x00,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
> };
> static const uint8_t mxf_apple_coll_max_cll[] = {
> 0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0e,0x0e,0x20,0x04,0x01,0x05,0x03,0x01,0x01
> };
These indeed look like copy-paste errors. Patch looks OK to me.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_fps: extend support for expressions
On 6/5/2021 12:52 PM, James Almer wrote: AV_OPT_TYPE_VIDEO_RATE AVOption types are parsed as expressions, but in a limited way. For example, name constants can only be parsed alone and not as part of a longer expression. This change allows usage like ffmpeg -i IN -vf fps="if(eq(source_fps\,film)\,ntsc_film\,source_fps)" OUT Suggested-by: ffm...@fb.com Signed-off-by: James Almer --- libavfilter/vf_fps.c | 65 1 file changed, 60 insertions(+), 5 deletions(-) Will apply. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avutil/samplefmt: remove outdated comment
On 6/7/2021 12:42 AM, James Almer wrote: av_samples_fill_arrays() has been returning the minimum required buffer size for a while now. Signed-off-by: James Almer --- libavutil/samplefmt.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/libavutil/samplefmt.h b/libavutil/samplefmt.h index 8cd43ae856..f270199195 100644 --- a/libavutil/samplefmt.h +++ b/libavutil/samplefmt.h @@ -195,9 +195,8 @@ int av_samples_get_buffer_size(int *linesize, int nb_channels, int nb_samples, * @param nb_samples the number of samples in a single channel * @param sample_fmt the sample format * @param alignbuffer size alignment (0 = default, 1 = no alignment) - * @return >=0 on success or a negative error code on failure - * @todo return minimum size in bytes required for the buffer in case - * of success at the next bump + * @return minimum size in bytes required for the buffer on success, + * or a negative error code on failure */ int av_samples_fill_arrays(uint8_t **audio_data, int *linesize, const uint8_t *buf, Will apply set. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avutil/tests/lzo: remove timer macros
On 6/6/2021 11:20 PM, James Almer wrote:
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
libavutil/tests/lzo.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavutil/tests/lzo.c b/libavutil/tests/lzo.c
index 0147ab5c1d..a5655dbfc5 100644
--- a/libavutil/tests/lzo.c
+++ b/libavutil/tests/lzo.c
@@ -55,7 +55,6 @@ int main(int argc, char *argv[]) {
} else
lzo1x_999_compress(orig, s, comp, &clen, tmp);
for (i = 0; i < 300; i++) {
-START_TIMER
inlen = clen; outlen = MAXSZ;
#if BENCHMARK_LIBLZO_SAFE
if (lzo1x_decompress_safe(comp, inlen, decomp, &outlen, NULL))
@@ -65,7 +64,6 @@ START_TIMER
if (av_lzo1x_decode(decomp, &outlen, comp, &inlen))
#endif
av_log(NULL, AV_LOG_ERROR, "decompression error\n");
-STOP_TIMER("lzod")
}
if (memcmp(orig, decomp, s))
av_log(NULL, AV_LOG_ERROR, "decompression incorrect\n");
Will apply.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/hls Implement support for using AVSEEK_FLAG_BACKWARD when seeking
On Sat, 12 Jun 2021 23:14:16 +0200
Gustav Grusell wrote:
> On Sat, Jun 12, 2021 at 6:51 PM Lingjiang Fang
> wrote:
>
> > On Sat, 12 Jun 2021 14:16:22 +0200
> > Gustav Grusell wrote:
> >
> > > On Fri, Jun 11, 2021 at 6:29 PM Lingjiang Fang
> > > wrote:
> > >
> > > > On Sat, 5 Jun 2021 22:42:26 +0200
> > > > Gustav Grusell wrote:
> > > >
> > > > > Before, seeking in hls streams would always seek to the next
> > > > > keyframe after the given timestamp. With this fix, if
> > > > > AVSEEK_FLAG_BACKWARD is set, seeking will be to the first
> > > > > keyframe of the segment containing the given timestamp. This
> > > > > fixes #7485.
> > > > >
> > > > > Signed-off-by: Gustav Grusell
> > > > > ---
> > > > > libavformat/hls.c | 9 +
> > > > > 1 file changed, 9 insertions(+)
> > > > >
> > > > > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > > > > index 8fc6924c90..fb8c9b071a 100644
> > > > > --- a/libavformat/hls.c
> > > > > +++ b/libavformat/hls.c
> > > > > @@ -2197,6 +2197,15 @@ static int
> > > > > hls_read_packet(AVFormatContext *s, AVPacket *pkt) break;
> > > > > }
> > > > >
> > > > > +/* If AVSEEK_FLAG_BACKWARD set and not
> > > > > AVSEEK_FLAG_ANY,
> > > > > + * we return the first keyframe
> > > > > encountered */
> > > > > +if (pls->seek_flags &
> > > > > AVSEEK_FLAG_BACKWARD &&
> > > > > +!(pls->seek_flags & AVSEEK_FLAG_ANY)
> > > > > &&
> > > > > +pls->pkt->flags & AV_PKT_FLAG_KEY) {
> > > > >
> > > > taking account of the case of using flag backward and flag any
> > > > together, a logic like this is better:
> > > >
> > > > if ( pls->seek_flags & AVSEEK_FLAG_BACKWARD &&
> > > > (pls->seek_flags & AVSEEK_FLAG_ANY ||
> > > > pls->pkt->flags & AV_PKT_FLAG_KEY)) {
> > > >
> > > > }
> > > >
> > > >
> > > Thanks for your feedback!
> > > I'm not sure about this, I think it makes more sense if seeking
> > > with AVSEEK_FLAG_BACKWARD and AVSEEK_FLAG_ANY behaves the same as
> > > when using only AVSEEK_FLAG_ANY, that is to seek to as close as
> > > possible as the exact timestamp, regardless if that is a keyframe
> > > or not. If
> > what do you mean "AVSEEK_FLAG_BACKWARD and AVSEEK_FLAGAV_ANY
> > behaves the same as when using only AVSEEK_FLAG_ANY"?
> > I think the default behavior of seek is seek to key frame, where
> > AVSEEK_FLAGAV_ANY means we can accept seeking to non-key frame.
> >
> >
> Sorry I think you can disregard what I wrote. I was thinking of the
> case where the user would set both BACKWARDS and ANY flags, and
> forgot that if the user sets the BACKWARDS flag, the ANY flag will be
> added for other playlists than the one containing the stream
> searched in. I think this made me miss your point.
> So what I meant was that if seeking with both AVSEEK_FLAG_BACKWARD and
> AVSEEK_FLAG_ANY, optimally, I would expect the result to
> be to search to the nearest frame before or exactly at the seek
> timestamp. Note that this is not how i behaves with my patch, it will
> seek to the first frame with a timestamp equal to or greater to the
> seek timestamp. In my opinion this is probably good enough, and is
> in any case the same behaviour as before the patch.
> So if the user has etAVSEEK_FLAG_ANY we would not then want to search
> to the first frame of the segment, even if we have the
> AVSEEK_FLAG_BACKWARD set. But of course this is different if
> AVSEEK_FLAG_ANY has been set because this is not the seek playlist.
>
>
> > > I'm not mistaken, with your proposed change, using both
> > > AVSEEK_FLAG_BACKWARD and AVSEEK_FLAG_ANY would always seek to the
> > > first frame of the segment which is always a keyframe, so
> > > behaviour would be the same as using only AVSEEK_FLAG_BACKWARD.
> > when the first packet of a segment is not key-frame(rarely seen, but
> > is possible), the behavior will be different.
> > - AVSEEK_FLAG_BACKWARD will go on seeking until find a key frame
> > - AVSEEK_FLAG_BACKWARD + AVSEEK_FLAG_BACKWARD should return
> > immediatly
> >
> >
> Ah yes you are correct. I was thinking that the HLS specification
> requires an IDR frame at the start of every (video) segment, but now
> that I looked it up that is not strictly the case.
> Apples HLS authorign specification does require it though.
>
>
> there is a similar logic at the end of this if{} block.
> >
> > >
> > >
> > > > > +pls->seek_timestamp = AV_NOPTS_VALUE;
> > > > > +break;
> > > > > +}
> > > > > +
> > > > > tb = get_timebase(pls);
> > > > > ts_diff = av_rescale_rnd(pls->pkt->dts,
> > > > > AV_TIME_BASE, tb.den, AV_ROUND_DOWN) -
> > > >
> > > > BTW, when I used seek backward before, what I want is to get
> > > > exactly packets of the specified seek time, not only the
> > > > specified stream but also all streams I need. To achieve
[FFmpeg-devel] [PATCH] lavfi/dnn_backend_openvino.c: fix crash when target is not specified
---
libavfilter/dnn/dnn_backend_openvino.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_openvino.c
b/libavfilter/dnn/dnn_backend_openvino.c
index 709a772a4d..dee0a8e047 100644
--- a/libavfilter/dnn/dnn_backend_openvino.c
+++ b/libavfilter/dnn/dnn_backend_openvino.c
@@ -596,8 +596,10 @@ static DNNReturnType
extract_inference_from_task(DNNFunctionType func_type, Task
InferenceItem *inference;
const AVDetectionBBox *bbox = av_get_detection_bbox(header, i);
-if (av_strncasecmp(bbox->detect_label, params->target,
sizeof(bbox->detect_label)) != 0) {
-continue;
+if (params->target) {
+if (av_strncasecmp(bbox->detect_label, params->target,
sizeof(bbox->detect_label)) != 0) {
+continue;
+}
}
inference = av_malloc(sizeof(*inference));
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
