Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/jpeg2000dec: Enhance pix fmt selection
On Thu, Jul 2, 2020 at 3:42 AM Carl Eugen Hoyos wrote:
>
> Am Mi., 1. Juli 2020 um 20:34 Uhr schrieb :
> >
> > From: Gautam Ramakrishnan
> >
> > This patch assigns default pix format values when
> > a match does not take place.
> > ---
> > libavcodec/jpeg2000dec.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> > index 3f4a9ef96c..86f9170723 100644
> > --- a/libavcodec/jpeg2000dec.c
> > +++ b/libavcodec/jpeg2000dec.c
> > @@ -436,6 +436,15 @@ static int get_siz(Jpeg2000DecoderContext *s)
> > s->cdef[3] = 3;
> > i = 0;
> > }
> > +} else if (ncomponents == 3 && s->precision == 8) {
> > +s->avctx->pix_fmt = AV_PIX_FMT_RGB24;
> > +i = 0;
> > +} else if (ncomponents == 2 && s->precision == 8) {
> > +s->avctx->pix_fmt = AV_PIX_FMT_YA8;
> > +i = 0;
>
> Which samples does this fix / why is this a good idea?
Sorry I missed out on this. This is for samples p0_10.j2k,
p1_01.j2k and p1_07.j2k. I finally fully understood what
pix_fmt_match() was doing and realized a previous patch,
which removes a check based on log2_chroma_wh was a bad
idea.I felt that pix_fmt_match was rejecting a few samples just
because the subsampling rate of a few images was not 1, as the
pix_fmt_match() function rejects rgb24, gray8 and ya8 if the sampling
was not 1. This patch adds a default pixel format in these cases.
--
-
Gautam |
___
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] avcodec/libaomenc: fix build w/libaom v1.0.0
broken since:
aa5c6f382b avcodec/libaomenc: Add command-line options to control the use of
partition tools
+ remove control related options when it's unavailable
Signed-off-by: James Zern
---
libavcodec/libaomenc.c | 70 ++
1 file changed, 70 insertions(+)
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index cb6558476c..fc9182003e 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -145,16 +145,36 @@ static const char *const ctlidstr[] = {
#endif
[AV1E_SET_ENABLE_CDEF] = "AV1E_SET_ENABLE_CDEF",
[AOME_SET_TUNING] = "AOME_SET_TUNING",
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_1TO4_PARTITIONS
[AV1E_SET_ENABLE_1TO4_PARTITIONS] = "AV1E_SET_ENABLE_1TO4_PARTITIONS",
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_AB_PARTITIONS
[AV1E_SET_ENABLE_AB_PARTITIONS] = "AV1E_SET_ENABLE_AB_PARTITIONS",
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_RECT_PARTITIONS
[AV1E_SET_ENABLE_RECT_PARTITIONS] = "AV1E_SET_ENABLE_RECT_PARTITIONS",
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_ANGLE_DELTA
[AV1E_SET_ENABLE_ANGLE_DELTA] = "AV1E_SET_ENABLE_ANGLE_DELTA",
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_CFL_INTRA
[AV1E_SET_ENABLE_CFL_INTRA] = "AV1E_SET_ENABLE_CFL_INTRA",
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_FILTER_INTRA
[AV1E_SET_ENABLE_FILTER_INTRA] = "AV1E_SET_ENABLE_FILTER_INTRA",
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_INTRA_EDGE_FILTER
[AV1E_SET_ENABLE_INTRA_EDGE_FILTER] = "AV1E_SET_ENABLE_INTRA_EDGE_FILTER",
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_PAETH_INTRA
[AV1E_SET_ENABLE_PAETH_INTRA] = "AV1E_SET_ENABLE_PAETH_INTRA",
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_SMOOTH_INTRA
[AV1E_SET_ENABLE_SMOOTH_INTRA] = "AV1E_SET_ENABLE_SMOOTH_INTRA",
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_PALETTE
[AV1E_SET_ENABLE_PALETTE] = "AV1E_SET_ENABLE_PALETTE",
+#endif
};
static av_cold void log_encoder_error(AVCodecContext *avctx, const char *desc)
@@ -718,26 +738,46 @@ static av_cold int aom_init(AVCodecContext *avctx,
codecctl_int(avctx, AV1E_SET_ENABLE_CDEF, ctx->enable_cdef);
if (ctx->enable_restoration >= 0)
codecctl_int(avctx, AV1E_SET_ENABLE_RESTORATION,
ctx->enable_restoration);
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_RECT_PARTITIONS
if (ctx->enable_rect_partitions >= 0)
codecctl_int(avctx, AV1E_SET_ENABLE_RECT_PARTITIONS,
ctx->enable_rect_partitions);
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_1TO4_PARTITIONS
if (ctx->enable_1to4_partitions >= 0)
codecctl_int(avctx, AV1E_SET_ENABLE_1TO4_PARTITIONS,
ctx->enable_1to4_partitions);
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_AB_PARTITIONS
if (ctx->enable_ab_partitions >= 0)
codecctl_int(avctx, AV1E_SET_ENABLE_AB_PARTITIONS,
ctx->enable_ab_partitions);
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_ANGLE_DELTA
if (ctx->enable_angle_delta >= 0)
codecctl_int(avctx, AV1E_SET_ENABLE_ANGLE_DELTA,
ctx->enable_angle_delta);
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_CFL_INTRA
if (ctx->enable_cfl_intra >= 0)
codecctl_int(avctx, AV1E_SET_ENABLE_CFL_INTRA, ctx->enable_cfl_intra);
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_FILTER_INTRA
if (ctx->enable_filter_intra >= 0)
codecctl_int(avctx, AV1E_SET_ENABLE_FILTER_INTRA,
ctx->enable_filter_intra);
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_INTRA_EDGE_FILTER
if (ctx->enable_intra_edge_filter >= 0)
codecctl_int(avctx, AV1E_SET_ENABLE_INTRA_EDGE_FILTER,
ctx->enable_intra_edge_filter);
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_PAETH_INTRA
if (ctx->enable_paeth_intra >= 0)
codecctl_int(avctx, AV1E_SET_ENABLE_PAETH_INTRA,
ctx->enable_paeth_intra);
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_SMOOTH_INTRA
if (ctx->enable_smooth_intra >= 0)
codecctl_int(avctx, AV1E_SET_ENABLE_SMOOTH_INTRA,
ctx->enable_smooth_intra);
+#endif
+#ifdef AOM_CTRL_AV1E_SET_ENABLE_PALETTE
if (ctx->enable_palette >= 0)
codecctl_int(avctx, AV1E_SET_ENABLE_PALETTE, ctx->enable_palette);
+#endif
codecctl_int(avctx, AOME_SET_STATIC_THRESHOLD, ctx->static_thresh);
if (ctx->crf >= 0)
@@ -1126,8 +1166,12 @@ static const AVOption options[] = {
{ "crf", "Select the quality for constant quality mode",
offsetof(AOMContext, crf), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 63, VE },
{ "static-thresh","A change threshold on blocks below which they will
be skipped by the encoder", OFFSET(static_thresh), AV_OPT_TYPE_INT, { .i64 = 0
}, 0, INT_MAX, VE },
{ "drop-threshold", "Frame drop threshold", offsetof(AOMContext,
drop_threshold), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN, INT_MAX, VE },
+#ifdef AOM_CTRL_AV1E_SET_DENOISE_NOISE_LEVEL
{ "denoise-noise-level", "Amount of noise to be removed",
OFFSET(denoise_noise_level), AV_OPT_TYPE_INT, {.i64 = -1}, -1, INT_MAX, VE},
+#endif
+#ifdef AOM_CTRL_AV1E_SET_DENOISE_BLOCK_SIZE
{ "denoise-block-size",
Re: [FFmpeg-devel] [PATCH 3/5] libavcodec/libaomenc.c: Add command-line options for intra-coding tools
On Wed, Jul 1, 2020 at 4:39 PM James Almer wrote: > > On 7/1/2020 3:57 PM, James Zern wrote: > > On Mon, Jun 29, 2020 at 11:15 AM James Zern wrote: > >> > >> On Thu, Jun 25, 2020 at 5:55 PM Wang Cao wrote: > >>> > >>> Signed-off-by: Wang Cao > >>> --- > >>> doc/encoders.texi | 21 +++ > >>> libavcodec/libaomenc.c | 47 -- > >>> libavcodec/version.h | 2 +- > >>> 3 files changed, 63 insertions(+), 7 deletions(-) > >>> > >> > >> lgtm. > > > > applied, thanks. > > Are all these options available in 1.0.0? If not, then they need to be > wrapped in a pre-processor check like the other newer options. > You're right, I had thought these made it to the normative branch, my mistake. I'll send a patch. > I did not remove support for 1.0.0 since that's what Debian, Ubuntu and > other distros with LTS releases ship, and nobody (other than you) > commented when i asked what direction we should take. > ___ > 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 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] FATE: fix colorbalance fate test failed on x86_32
From: Limin Wang floating point precision will cause rgb*max generate different value on x86_32 and x86_64. have pass fate test on x86_32 and x86_64 by using lrintf to get the nearest integral value for rgb * max before av_clip. Signed-off-by: Limin Wang --- libavfilter/vf_colorbalance.c | 24 ++--- tests/ref/fate/filter-colorbalance | 6 +++--- tests/ref/fate/filter-colorbalance-gbrap| 6 +++--- tests/ref/fate/filter-colorbalance-gbrap-16 | 6 +++--- tests/ref/fate/filter-colorbalance-rgba64 | 6 +++--- 5 files changed, 24 insertions(+), 24 deletions(-) diff --git a/libavfilter/vf_colorbalance.c b/libavfilter/vf_colorbalance.c index cc90dc08c7..6dc1b28483 100644 --- a/libavfilter/vf_colorbalance.c +++ b/libavfilter/vf_colorbalance.c @@ -188,9 +188,9 @@ static int color_balance8_p(AVFilterContext *ctx, void *arg, int jobnr, int nb_j if (s->preserve_lightness) preservel(, , , l); -dstr[j] = av_clip_uint8(r * max); -dstg[j] = av_clip_uint8(g * max); -dstb[j] = av_clip_uint8(b * max); +dstr[j] = av_clip_uint8(lrintf(r * max)); +dstg[j] = av_clip_uint8(lrintf(g * max)); +dstb[j] = av_clip_uint8(lrintf(b * max)); if (in != out && out->linesize[3]) dsta[j] = srca[j]; } @@ -242,9 +242,9 @@ static int color_balance16_p(AVFilterContext *ctx, void *arg, int jobnr, int nb_ if (s->preserve_lightness) preservel(, , , l); -dstr[j] = av_clip_uintp2_c(r * max, depth); -dstg[j] = av_clip_uintp2_c(g * max, depth); -dstb[j] = av_clip_uintp2_c(b * max, depth); +dstr[j] = av_clip_uintp2_c(lrintf(r * max), depth); +dstg[j] = av_clip_uintp2_c(lrintf(g * max), depth); +dstb[j] = av_clip_uintp2_c(lrintf(b * max), depth); if (in != out && out->linesize[3]) dsta[j] = srca[j]; } @@ -299,9 +299,9 @@ static int color_balance8(AVFilterContext *ctx, void *arg, int jobnr, int nb_job if (s->preserve_lightness) preservel(, , , l); -dst[j + roffset] = av_clip_uint8(r * max); -dst[j + goffset] = av_clip_uint8(g * max); -dst[j + boffset] = av_clip_uint8(b * max); +dst[j + roffset] = av_clip_uint8(lrintf(r * max)); +dst[j + goffset] = av_clip_uint8(lrintf(g * max)); +dst[j + boffset] = av_clip_uint8(lrintf(b * max)); if (in != out && step == 4) dst[j + aoffset] = src[j + aoffset]; } @@ -351,9 +351,9 @@ static int color_balance16(AVFilterContext *ctx, void *arg, int jobnr, int nb_jo if (s->preserve_lightness) preservel(, , , l); -dst[j + roffset] = av_clip_uintp2_c(r * max, depth); -dst[j + goffset] = av_clip_uintp2_c(g * max, depth); -dst[j + boffset] = av_clip_uintp2_c(b * max, depth); +dst[j + roffset] = av_clip_uintp2_c(lrintf(r * max), depth); +dst[j + goffset] = av_clip_uintp2_c(lrintf(g * max), depth); +dst[j + boffset] = av_clip_uintp2_c(lrintf(b * max), depth); if (in != out && step == 4) dst[j + aoffset] = src[j + aoffset]; } diff --git a/tests/ref/fate/filter-colorbalance b/tests/ref/fate/filter-colorbalance index f267da572e..15491fe671 100644 --- a/tests/ref/fate/filter-colorbalance +++ b/tests/ref/fate/filter-colorbalance @@ -3,6 +3,6 @@ #codec_id 0: rawvideo #dimensions 0: 352x288 #sar 0: 0/1 -0, 0, 0,1, 304128, 0xd50c9fea -0, 1, 1,1, 304128, 0xdf9e1f79 -0, 2, 2,1, 304128, 0x9b84087e +0, 0, 0,1, 304128, 0xf68fadfd +0, 1, 1,1, 304128, 0xa6302d9a +0, 2, 2,1, 304128, 0x758d165a diff --git a/tests/ref/fate/filter-colorbalance-gbrap b/tests/ref/fate/filter-colorbalance-gbrap index a85dc388b0..2d76c7d08d 100644 --- a/tests/ref/fate/filter-colorbalance-gbrap +++ b/tests/ref/fate/filter-colorbalance-gbrap @@ -3,6 +3,6 @@ #codec_id 0: rawvideo #dimensions 0: 352x288 #sar 0: 0/1 -0, 0, 0,1, 405504, 0xd33217e5 -0, 1, 1,1, 405504, 0x08f161af -0, 2, 2,1, 405504, 0x27508654 +0, 0, 0,1, 405504, 0xdcc71df0 +0, 1, 1,1, 405504, 0x48d56675 +0, 2, 2,1, 405504, 0x68058bf0 diff --git a/tests/ref/fate/filter-colorbalance-gbrap-16 b/tests/ref/fate/filter-colorbalance-gbrap-16 index d18fe5a466..2ab96ad70f 100644 --- a/tests/ref/fate/filter-colorbalance-gbrap-16 +++ b/tests/ref/fate/filter-colorbalance-gbrap-16 @@ -3,6 +3,6 @@ #codec_id 0: rawvideo #dimensions 0: 352x288 #sar 0: 0/1 -0,
Re: [FFmpeg-devel] [PATCH 2/2] dnn_backend_native: check operand index
> -Original Message-
> From: Michael Niedermayer
> Sent: 2020年7月2日 7:45
> To: FFmpeg development discussions and patches ;
> Guo, Yejun
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] dnn_backend_native: check operand
> index
>
> On Wed, Jun 17, 2020 at 03:23:34AM +, Guo, Yejun wrote:
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Carl Eugen Hoyos
> > > Sent: 2020年6月16日 18:57
> > > To: FFmpeg development discussions and patches
> > >
> > > Subject: Re: [FFmpeg-devel] [PATCH 2/2] dnn_backend_native: check
> > > operand index
> > >
> > >
> > >
> > > > Am 16.06.2020 um 10:18 schrieb Guo, Yejun :
> > > >
> > > > I personally like to always add '{}' to avoid possible mistakes
> > > > when we change
> > > code in the future. Some coding styles also recommend this method.
> > > >
> > > > I checked at http://ffmpeg.org/developer.html#Coding-Rules and do
> > > > not find
> > > an explicit description. But I just remembered that someone also
> > > mentioned this some time ago. I'll change to this style in v2 if no
> > > support from others for my style.
> > >
> > > I support your style but it is only the file maintainer‘s decision.
> >
> > thanks, I'll keep the V1 patch and push soon.
>
> please also apply this to affected release branches
done, pushed to branch 4.3 with dd273d359e45ab69398ac0dc41206d5f1a9371bf and
5530748bfdf1a4d41d4c92e59f662c94e38a5f94,
no need to apply 4.2 and older.
___
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] [ffmpeg-devel][GSoC][PATCH 1/2] libavfilter/vf_colorconstancy.c : Cleanup code for new filter
Signed-off-by: Yatendra Singh
---
libavfilter/vf_colorconstancy.c | 46 ++---
1 file changed, 13 insertions(+), 33 deletions(-)
diff --git a/libavfilter/vf_colorconstancy.c b/libavfilter/vf_colorconstancy.c
index eae62204b5..d974317a48 100644
--- a/libavfilter/vf_colorconstancy.c
+++ b/libavfilter/vf_colorconstancy.c
@@ -552,32 +552,6 @@ static void normalize_light(double *light)
}
}
-/**
- * Redirects to corresponding algorithm estimation function and performs
normalization
- * after estimation.
- *
- * @param ctx the filter context.
- * @param in frame to perfrom estimation on.
- *
- * @return 0 in case of success, a negative value corresponding to an
- * AVERROR code in case of failure.
- */
-static int illumination_estimation(AVFilterContext *ctx, AVFrame *in)
-{
-ColorConstancyContext *s = ctx->priv;
-int ret;
-
-ret = filter_grey_edge(ctx, in);
-
-av_log(ctx, AV_LOG_DEBUG, "Estimated illumination= %f %f %f\n",
- s->white[0], s->white[1], s->white[2]);
-normalize_light(s->white);
-av_log(ctx, AV_LOG_DEBUG, "Estimated illumination after normalization= %f
%f %f\n",
- s->white[0], s->white[1], s->white[2]);
-
-return ret;
-}
-
/**
* Performs simple correction via diagonal transformation model.
*
@@ -682,12 +656,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
int ret;
int direct = 0;
-ret = illumination_estimation(ctx, in);
-if (ret) {
-av_frame_free();
-return ret;
-}
-
if (av_frame_is_writable(in)) {
direct = 1;
out = in;
@@ -699,7 +667,19 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
}
av_frame_copy_props(out, in);
}
-chromatic_adaptation(ctx, in, out);
+
+if (!strcmp(ctx->filter->name, GREY_EDGE)) {
+ColorConstancyContext *s = ctx->priv;
+ret = filter_grey_edge(ctx, in);
+
+normalize_light(s->white);
+
+if (ret) {
+av_frame_free();
+return ret;
+}
+chromatic_adaptation(ctx, in, out);
+}
if (!direct)
av_frame_free();
--
2.20.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".
Re: [FFmpeg-devel] [PATCH v3] avformat/icecast: Add option to use TLS connection
Ping for merge, again :)
On 28 Jun 2020, at 22:43, Marvin Scholz wrote:
Ping
On 18 Jun 2020, at 23:16, Marvin Scholz wrote:
Ping? Anything else needed to get this merged?
On 14 Jun 2020, at 22:23, Marvin Scholz wrote:
On 14 Jun 2020, at 15:42, Michael Niedermayer wrote:
On Sun, Jun 14, 2020 at 12:52:44AM +0200, Marvin Scholz wrote:
---
doc/protocols.texi| 3 +++
libavformat/icecast.c | 6 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 7aa758541c..32c829d2a3 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -520,6 +520,9 @@ audio/mpeg.
This enables support for Icecast versions < 2.4.0, that do not
support the
HTTP PUT method but the SOURCE method.
+@item tls
+Establish a TLS (HTTPS) connection to Icecast.
+
@end table
@example
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
index 38af16b99e..b06c53cabd 100644
--- a/libavformat/icecast.c
+++ b/libavformat/icecast.c
@@ -43,6 +43,7 @@ typedef struct IcecastContext {
int public;
char *url;
char *user_agent;
+int tls;
} IcecastContext;
#define DEFAULT_ICE_USER "source"
@@ -62,6 +63,7 @@ static const AVOption options[] = {
{ "password", "set password", OFFSET(pass),
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
{ "content_type", "set content-type, MUST be set if not
audio/mpeg", OFFSET(content_type), AV_OPT_TYPE_STRING, { .str =
NULL }, 0, 0, E },
{ "legacy_icecast", "use legacy SOURCE method, for Icecast <
v2.4", OFFSET(legacy_icecast), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,
1, E },
+{ "tls", "use a TLS connection", OFFSET(tls),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
{ NULL }
};
@@ -162,7 +164,9 @@ static int icecast_open(URLContext *h, const
char *uri, int flags)
}
// Build new URI for passing to http protocol
-ff_url_join(h_url, sizeof(h_url), "http", auth, host, port,
"%s", path);
+ff_url_join(h_url, sizeof(h_url),
+s->tls ? "https" : "http",
+auth, host, port, "%s", path);
// Finally open http proto handler
ret = ffurl_open_whitelist(>hd, h_url,
AVIO_FLAG_READ_WRITE, NULL,
_dict, h->protocol_whitelist,
h->protocol_blacklist, h);
Is https support common or uncommon for icecast ?
if it is common then changing the default to enabled (in a seperate
patch)
would make sense
the patch should be ok
It's getting more common now but most people are probably still used
to
have http enabled for use with source clients as most of the older
ones do not yet support TLS at all.
Ideally it would default to auto-detect but it seems thats not
easily possible
with how the ffmpeg protocols work.
thx
[...]
--
Michael GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door
even
though the window is wide open and the only thing in the house is a
bunch
of things you dont want and which you would get tomorrow for free
anyway
___
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 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 2/2] dnn_backend_native: check operand index
On Wed, Jun 17, 2020 at 03:23:34AM +, Guo, Yejun wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Carl
> > Eugen Hoyos
> > Sent: 2020年6月16日 18:57
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH 2/2] dnn_backend_native: check operand
> > index
> >
> >
> >
> > > Am 16.06.2020 um 10:18 schrieb Guo, Yejun :
> > >
> > > I personally like to always add '{}' to avoid possible mistakes when we
> > > change
> > code in the future. Some coding styles also recommend this method.
> > >
> > > I checked at http://ffmpeg.org/developer.html#Coding-Rules and do not find
> > an explicit description. But I just remembered that someone also mentioned
> > this
> > some time ago. I'll change to this style in v2 if no support from others
> > for my
> > style.
> >
> > I support your style but it is only the file maintainer‘s decision.
>
> thanks, I'll keep the V1 patch and push soon.
please also apply this to affected release branches
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
signature.asc
Description: PGP signature
___
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] [ffmpeg-devel][GSoC][PATCH 2/2] libavfilter/vf_colorconstancy.c : Adding weighted greyedge
Signed-off-by: Yatendra Singh
---
doc/filters.texi| 36 ++
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_colorconstancy.c | 220
4 files changed, 258 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 85a511b205..2946b5b9e6 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -20250,6 +20250,42 @@
separatefields,select=eq(mod(n,4),0)+eq(mod(n,4),3),weave
@end example
@end itemize
+@section weighted_greyedge
+Apply the color constancy filter which estimates illumination and updates the
+image colors accordingly.
+
+It accepts the following options:
+
+@table @option
+@item minknorm
+The Minkowski parameter to be used for calculating the Minkowski distance. Must
+be chosen in the range [0,20] and default value is 1. Set to 0 for getting
+max value instead of calculating Minkowski distance.
+
+@item sigma
+The standard deviation of Gaussian blur to be applied on the scene. Must be
+chosen in the range [0,1024.0] and default value = 1. floor( @var{sigma} *
break_off_sigma(3) )
+can't be equal to 0 if @var{difford} is greater than 0.
+
+@item min_err
+The error angle between the estimated illumination and white light at which
the algorithm stops even
+if it hasn't reached the required number of iterations @code{max_iters}. Must
be chosen in the range
+[0.02,PI] radians with default of 0.1.
+
+@item max_iters
+The number of iterations at which the algorithm stops even if it hasn't
reached the required
+error angle between the estimated illumination and white light @code{min_err}.
Must be chosen in the
+range [1,100] with a default value of 10.
+
+@item kappa
+The power which is applied to the spectral weights to change the impact of
weights on illuminant
+estimation @code{kappa}. Must be chosen in the range [1,25] with a default
value of 10.
+@end table
+
+@example
+ffmpeg -i mondrian.tif -vf
"weighted_greyedge=minknorm=0:sigma=1:max_iters=50:min_err=0.02:kappa=10"
mondrian_out.tif
+@end example
+
@section xbr
Apply the xBR high-quality magnification filter which is designed for pixel
art. It follows a set of edge-detection rules, see
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 994a4172a3..6973452f8d 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -453,6 +453,7 @@ OBJS-$(CONFIG_VSTACK_FILTER) += vf_stack.o
framesync.o
OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
OBJS-$(CONFIG_WAVEFORM_FILTER) += vf_waveform.o
OBJS-$(CONFIG_WEAVE_FILTER) += vf_weave.o
+OBJS-$(CONFIG_WEIGHTED_GREYEDGE_FILTER) += vf_colorconstancy.o
OBJS-$(CONFIG_XBR_FILTER)+= vf_xbr.o
OBJS-$(CONFIG_XFADE_FILTER) += vf_xfade.o
OBJS-$(CONFIG_XFADE_OPENCL_FILTER) += vf_xfade_opencl.o opencl.o
opencl/xfade.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index f2a44b0090..ad2e07f9c5 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -432,6 +432,7 @@ extern AVFilter ff_vf_vstack;
extern AVFilter ff_vf_w3fdif;
extern AVFilter ff_vf_waveform;
extern AVFilter ff_vf_weave;
+extern AVFilter ff_vf_weighted_greyedge;
extern AVFilter ff_vf_xbr;
extern AVFilter ff_vf_xfade;
extern AVFilter ff_vf_xfade_opencl;
diff --git a/libavfilter/vf_colorconstancy.c b/libavfilter/vf_colorconstancy.c
index d974317a48..cd9d992fdd 100644
--- a/libavfilter/vf_colorconstancy.c
+++ b/libavfilter/vf_colorconstancy.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018 Mina Sami
+ * Copyright (c) 2020 Yatendra Singh
*
* This file is part of FFmpeg.
*
@@ -26,6 +27,14 @@
*
* @cite
* J. van de Weijer, Th. Gevers, A. Gijsenij "Edge-Based Color Constancy".
+ *
+ * @cite
+ * J. van de Weijer, Th. Gevers, and J. Geusebroek,
+ * “Edge and corner detection by photometric quasi-invariants”.
+ *
+ * @cite
+ * A. Gijsenij, Th. Gevers, J. van de Weijer,
+ * "Improving Color Constancy by Photometric Edge Weighting".
*/
#include "libavutil/imgutils.h"
@@ -40,8 +49,10 @@
#include
#define GREY_EDGE "greyedge"
+#define WEIGHTED_GREY_EDGE "weighted_greyedge"
#define SQRT3 1.73205080757
+#define NORMAL_WHITE 1/SQRT3
#define NUM_PLANES3
#define MAX_DIFF_ORD 2
@@ -77,12 +88,16 @@ typedef struct ColorConstancyContext {
int difford;
int minknorm; /**< @minknorm = 0 : getMax instead */
+int kappa;
double sigma;
int nb_threads;
int planeheight[4];
int planewidth[4];
+double min_err;
+int max_iters;
+
int filtersize;
double *gauss[MAX_DIFF_ORD+1];
@@ -608,6 +623,170 @@ static void chromatic_adaptation(AVFilterContext *ctx,
AVFrame *in, AVFrame *out
ctx->internal->execute(ctx, diagonal_transformation, , NULL, nb_jobs);
}
+/**
+ * Slice function for weighted grey edge algorithm that does partial
summing/maximizing
+ * of gaussian derivatives and applies the pixel wise
Re: [FFmpeg-devel] [PATCH 3/5] libavcodec/libaomenc.c: Add command-line options for intra-coding tools
On 7/1/2020 3:57 PM, James Zern wrote: > On Mon, Jun 29, 2020 at 11:15 AM James Zern wrote: >> >> On Thu, Jun 25, 2020 at 5:55 PM Wang Cao wrote: >>> >>> Signed-off-by: Wang Cao >>> --- >>> doc/encoders.texi | 21 +++ >>> libavcodec/libaomenc.c | 47 -- >>> libavcodec/version.h | 2 +- >>> 3 files changed, 63 insertions(+), 7 deletions(-) >>> >> >> lgtm. > > applied, thanks. Are all these options available in 1.0.0? If not, then they need to be wrapped in a pre-processor check like the other newer options. I did not remove support for 1.0.0 since that's what Debian, Ubuntu and other distros with LTS releases ship, and nobody (other than you) commented when i asked what direction we should take. ___ 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] drawtext: Allow textfile path to be expanded per frame
**Help needed**: I am still hopeful the patch will get some attention but hope
is fading now (due to summer) :-). It's an easy patch and probably takes
10-20min to review.
Quick patch's status:- it compiles on the latest ffmpeg 4.3,- it passes the
tests,- the associated documentation has been updated with examples (and
documentation builds successfully),- Manolis Stamatogiannakis gave feedback, to
which I replied. No more action on the feedback needed as far as I can tell.-
The patch's age is ~ 2 months and awaiting someone to make it progress (feedback
or merge).
On pathwork [0], a few weeks ago, I assigned it to Michael Niedermayer as a last
resort but I was told on IRC he is super busy.[0]
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200511143159.19390-1-da...@andreoletti.net/
Any volunteer :-) ?
On Mon, May 25, 2020 4:27 AM, David Andreoletti da...@andreoletti.net wrote:
FFmpeg team,
Is there any other discussion/changes needed to get this contribution merged in
?
Regards,
On Tue, May 19, 2020 12:36 PM, David Andreoletti da...@andreoletti.net wrote:
Manolis: drawtext's text expansion section [0] does not mention the special
variable %{frame_num} has 0 paddable. When I tested locally (on master), it is
not 0 padded.
Running through different scenario, I recommend the expanded file path to not
contain 0 padded frame number:- if automatic padding is specified, then video
with no total frame known (live stream) would be problematic- if manually
padding is specified, it would complicate drawtext's textfile options parsing:
support for 0 padded %{frame_num} and possibly other custom formatting when
other supported %{} variables are expanded.
For a first improvement to an existing functionality, I would prefer to keep it
simple and focused :-)
[0]https://ffmpeg.org/ffmpeg-filters.html#Text-expansion
On Tue, May 19, 2020 9:34 AM, Manolis Stamatogiannakis msta...@gmail.com wrote:
Hi David,
Not a full review, but a minor point that popped in mind.
It is common to pad serially numbered files with 0. E.g. if you have <1000
files, the 9th file will be named file009.txt.
Is this case handled by the expansion? Or is it assumed that the text file
numbers are not zero-padded?
If it the latter is the case, it would be good to make that explicit in the
documentation.
Of course, accounting for padding would be better, but this may not be
straightforward without adding more code.
Regards,
Manolis
On Tue, 19 May 2020 at 06:10, David Andreoletti
wrote:
> Hi ffmpeg maintainers / community,
> New contributor here. The patch [0] for the drawtext filter was submitted
> some
> time ago now but has been reviewed yet. It seems there is no official
> maintainer
> for this filter (as per the MAINTAINERS file)
> What should be done to have it reviewed ?
>
> [0]
>
>
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200511143159.19390-1-da...@andreoletti.net/
>
> Regards,
> David Andreoletti
>
>
>
___
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 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 1/2] avcodec/tiff: Do not overrun the array ends in dng_blit()
Fixes: out of array access
Fixes:
23589/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5110559589793792.fuzz
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/tiff.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index dc24d055ec..d93a02b07e 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -859,8 +859,11 @@ static void dng_blit(TiffContext *s, uint8_t *dst, int
dst_stride,
}
} else {
for (line = 0; line < height; line++) {
+uint8_t *dst_u8 = dst;
+const uint8_t *src_u8 = src;
+
for (col = 0; col < width; col++)
-*dst++ = dng_process_color8(*src++, s->dng_lut,
s->black_level, scale_factor);
+*dst_u8++ = dng_process_color8(*src_u8++, s->dng_lut,
s->black_level, scale_factor);
dst += dst_stride;
src += src_stride;
--
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".
[FFmpeg-devel] [PATCH 2/2] avcodec/scpr3: Fix out of array access with dectab
Fixes:
23721/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCPR_fuzzer-5914074721550336
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/scpr3.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/libavcodec/scpr3.c b/libavcodec/scpr3.c
index b4d2e21a17..1ed764baa1 100644
--- a/libavcodec/scpr3.c
+++ b/libavcodec/scpr3.c
@@ -234,6 +234,8 @@ static int update_model6_to_7(PixelModel3 *m)
}
p = (e + 127) >> 7;
k = ((f + e - 1) >> 7) + 1;
+if (k > FF_ARRAY_ELEMS(n.dectab))
+return AVERROR_INVALIDDATA;
for (i = 0; i < k - p; i++)
n.dectab[p + i] = j;
e += f;
@@ -702,7 +704,11 @@ static int update_model3_to_7(PixelModel3 *m, uint8_t
value)
e = d;
n.cntsum += n.cnts[e];
n.freqs1[e] = c;
-for (g = n.freqs[e], q = c + 128 - 1 >> 7, f = (c + g - 1 >> 7) + 1; q
< f; q++) {
+g = n.freqs[e];
+f = (c + g - 1 >> 7) + 1;
+if (f > FF_ARRAY_ELEMS(n.dectab))
+return AVERROR_INVALIDDATA;
+for (q = c + 128 - 1 >> 7; q < f; q++) {
n.dectab[q] = e;
}
c += g;
@@ -837,6 +843,7 @@ static int decode_unit3(SCPRContext *s, PixelModel3 *m,
uint32_t code, uint32_t
uint16_t a = 0, b = 0;
uint32_t param;
int type;
+int ret;
type = m->type;
switch (type) {
@@ -859,7 +866,9 @@ static int decode_unit3(SCPRContext *s, PixelModel3 *m,
uint32_t code, uint32_t
break;
case 3:
*value = bytestream2_get_byte(>gb);
-decode_static3(m, *value);
+ret = decode_static3(m, *value);
+if (ret < 0)
+return AVERROR_INVALIDDATA;
sync_code3(gb, rc);
break;
case 4:
@@ -877,7 +886,9 @@ static int decode_unit3(SCPRContext *s, PixelModel3 *m,
uint32_t code, uint32_t
break;
case 6:
if (!decode_adaptive6(m, code, value, , )) {
-update_model6_to_7(m);
+ret = update_model6_to_7(m);
+if (ret < 0)
+return AVERROR_INVALIDDATA;
}
decode3(gb, rc, a, b);
sync_code3(gb, rc);
--
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".
Re: [FFmpeg-devel] [PATCH v3] fbdetile cpu based detiling of framebuffers v03
Jul 1, 2020, 17:37 by hanish...@gmail.com: > Hi Lynne, > > On Wed, Jul 1, 2020 at 3:37 PM Lynne wrote: > >> Jun 29, 2020, 18:58 by hanish...@gmail.com: >> >> > v03-20200629IST2208 fbdetile >> > >> > Added a generic detiling logic, which can be easily configured to >> > detile many different tiling schemes. >> > >> > The same is inturn used to detile Intel Tile-Yf layout. >> > >> > NOTE: This is a full patch, it contains the previous versions also >> > in it. >> > >> > v02-20200627IST2331 >> > >> > Unrolled Intel Legacy Tile-Y detiling logic. >> > >> > Also a consolidated patch file, instead of the previous development >> > flow based multiple patch files. >> > >> > v01-20200627IST1308 >> > >> > Implemented Intel Legacy Tile-X and Tile-Y detiling logic >> > >> > NOTES: >> > >> > This video filter allows framebuffers which are tiled to be detiled >> > using logic running on the cpu, into a linear layout. >> > >> > Currently it supports Intel Legacy Tile-X and Tile-Y layout detiling, >> > as well as the newer Intel Tile-Yf layouts. >> > >> > THis should help one to work with frames captured (say using kmsgrab) >> > on laptops having Intel GPU. This can be done live while capturing >> > itself, or it can be applied later as a seperate pass. >> > >> > Tile-X conversion logic has been explicitly cross checked, with Tile-X >> > based frames. However Tile-Y and Tile-Yf conv logics havent been tested >> > with Tile-Y | Tile-Yf based frames, but it should potentially get the >> > job done, based on my current understanding of these layout formats. >> > >> > TODO1: At a later time have to generate Tile-Y|Yf based frames, and then >> > cross check the corresponding logic explicitly. >> > >> > TODO2: May be use OpenGL or Vulcan buffer helper routines to do the >> > layout conversion. But some online discussions from sometime back seem >> > to indicate that this path is not fully bug free currently. >> > >> >> Still not happening, I'd like to see this done properly with hwdownload. >> While what you >> have works as a hack, we're not interested in hacks but something that >> works universally. >> As I said before, it can be easily sped up by a factor of 4 or 8 using >> SIMD, so its >> unjustifiable to have this in the codebase as a filter. >> > Can you tell me how this is not universal. Rather by embedding it within > hwdownload, we > will be making it limited to use from a hwcontext, while keeping it has a > seperate filter, > allows one to use it either with a hw context or from any other source. And > also it gives > the flexibility to do it live or offline. So not sure in what sense you > call my current flow > restricted and a possible embedded within hwdownload one has being > universal? > You have absolutely no idea what tiling is used outside of the hwcontext. No, you can't be clever and just say "write it in the filename". To do this properly, you'll need to add pixel formats for each tiling format. Which we're definitely not doing for very low level device specific layouts. Further still, you'll need to add support for that in libswscale (good luck), because its swscale that will be doing the conversions, not a filter. Filters understand pixel formats only. And options are not pixel formats. And even if you were to add those pixel formats and support for it in libswscale, an implicit conversion will take place before encoding anyway since no encoder will understand those pixel formats. So you'll need to add support for encoding such pixel formats directly without conversion. But as I said before, we're definitely not going to accept such pixel formats, let alone all the rest that would be necessary to do this properly. And its a good thing, because there's a correct solution which doesn't rely on hacks, is so simple and will work for anyone: just do the conversion while downloading. We already kind of do something similar for some hwcontexts, and drm is not special in any way. In fact, I don't think the drm hwcontext is correct in even allowing downloading or mapping of tiled images. Its just that by chance it works for linear images and it doesn't check the mapping (because AMD doesn't support modifiers so you have no idea whether something is linear or not, and the person who wrote the hwcontext was using AMD at the time). So really, please integrate this into hwcontext_drm.c. ___ 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] lavu: add a template for refcounted objects.
Jul 1, 2020, 19:20 by jamr...@gmail.com:
> On 7/1/2020 12:05 PM, Anton Khirnov wrote:
>
>> Quoting Nicolas George (2020-06-27 17:16:44)
>>
>>> Signed-off-by: Nicolas George
>>> ---
>>> libavutil/avrefcount_template.h | 140
>>> tests/ref/fate/source | 1 +
>>> 2 files changed, 141 insertions(+)
>>> create mode 100644 libavutil/avrefcount_template.h
>>>
>>>
>>> I will need to refcount something soon. Recently, the need to stop
>>> abusing AVBuffer for all refcounting was mentioned on the list. So here
>>> is an attempt at isolating the refcounting itself.
>>>
>>> This is not the final verion, I will first work on the "something" to
>>> make sure it suits the needs. But it is a first version.
>>>
>>> Anton, I would appreciate if you had a look at this and told me if there
>>> is something you strongly dislike about before I have piled too much
>>> efforts over it.
>>>
>>
>> Why a template? It seems simpler to add a struct like
>> typedef struct AVRefcount {
>> atomic_uint refcount;
>> void *opaque;
>> void (*free)(void *opaque);
>> } AVRefcount;
>> and then embed it in everything that wants to be refcounted. All just
>> normal structs and functions, no layers of macros.
>>
>
> I very much prefer this approach, being clean looking, public, and free
> of macros from unguarded headers, but it needs to be either easily
> extensible or well defined since day 1.
> For example, it could have more callbacks to be triggered by specific
> actions, like when creating new references, to workaround the current
> constrains of AVBufferRef.
>
Same.
___
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] libavcodec/jpeg2000dec: Enhance pix fmt selection
Am Mi., 1. Juli 2020 um 20:34 Uhr schrieb :
>
> From: Gautam Ramakrishnan
>
> This patch assigns default pix format values when
> a match does not take place.
> ---
> libavcodec/jpeg2000dec.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index 3f4a9ef96c..86f9170723 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -436,6 +436,15 @@ static int get_siz(Jpeg2000DecoderContext *s)
> s->cdef[3] = 3;
> i = 0;
> }
> +} else if (ncomponents == 3 && s->precision == 8) {
> +s->avctx->pix_fmt = AV_PIX_FMT_RGB24;
> +i = 0;
> +} else if (ncomponents == 2 && s->precision == 8) {
> +s->avctx->pix_fmt = AV_PIX_FMT_YA8;
> +i = 0;
Which samples does this fix / why is this a good idea?
Carl Eugen
___
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] avcodec/dstdec: Replace AC overread check by sample rate check
NAK
There is DSD 512 variant
On 7/1/20, Michael Niedermayer wrote:
> Real files do skip coding 0 bits at the end, thus this kind of check
> does not work reliable.
>
> Fixes: Ticket 8770
> Fixes: dst-256fs44-6ch-refdstencoder.dff
>
> The samplerate is specified in ISO/IEC 14496-3:2005(E) as one of 3 fixed
> values, this also can be used to limit the duration and avoid the timeout
>
> This reverts commit f6df99dba1ae64b05d08fba8160d13eb9795042f.
> ---
> libavcodec/dstdec.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/dstdec.c b/libavcodec/dstdec.c
> index 771887faf9..f0926d6c09 100644
> --- a/libavcodec/dstdec.c
> +++ b/libavcodec/dstdec.c
> @@ -56,7 +56,6 @@ static const int8_t probs_code_pred_coeff[3][3] = {
> typedef struct ArithCoder {
> unsigned int a;
> unsigned int c;
> -int overread;
> } ArithCoder;
>
> typedef struct Table {
> @@ -86,6 +85,12 @@ static av_cold int decode_init(AVCodecContext *avctx)
> return AVERROR_PATCHWELCOME;
> }
>
> +// the sample rate is only allowed to be 64,128,256 * 44100 by ISO/IEC
> 14496-3:2005(E)
> +// We are a bit more tolerant here, but this check is needed to bound
> the size and duration
> +if (avctx->sample_rate > 256 * 44100)
> +return AVERROR_INVALIDDATA;
> +
> +
> if (DST_SAMPLES_PER_FRAME(avctx->sample_rate) & 7) {
> return AVERROR_PATCHWELCOME;
> }
> @@ -181,7 +186,6 @@ static void ac_init(ArithCoder *ac, GetBitContext *gb)
> {
> ac->a = 4095;
> ac->c = get_bits(gb, 12);
> -ac->overread = 0;
> }
>
> static av_always_inline void ac_get(ArithCoder *ac, GetBitContext *gb, int
> p, int *e)
> @@ -201,8 +205,6 @@ static av_always_inline void ac_get(ArithCoder *ac,
> GetBitContext *gb, int p, in
> if (ac->a < 2048) {
> int n = 11 - av_log2(ac->a);
> ac->a <<= n;
> -if (get_bits_left(gb) < n)
> -ac->overread ++;
> ac->c = (ac->c << n) | get_bits(gb, n);
> }
> }
> @@ -355,9 +357,6 @@ static int decode_frame(AVCodecContext *avctx, void
> *data,
> prob = 128;
> }
>
> -if (ac->overread > 16)
> -return AVERROR_INVALIDDATA;
> -
> ac_get(ac, gb, prob, );
> v = ((predict >> 15) ^ residual) & 1;
> dsd[((i >> 3) * channels + ch) << 2] |= v << (7 - (i & 0x7 ));
> --
> 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".
___
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] avcodec/dstdec: Replace AC overread check by sample rate check
Real files do skip coding 0 bits at the end, thus this kind of check
does not work reliable.
Fixes: Ticket 8770
Fixes: dst-256fs44-6ch-refdstencoder.dff
The samplerate is specified in ISO/IEC 14496-3:2005(E) as one of 3 fixed
values, this also can be used to limit the duration and avoid the timeout
This reverts commit f6df99dba1ae64b05d08fba8160d13eb9795042f.
---
libavcodec/dstdec.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavcodec/dstdec.c b/libavcodec/dstdec.c
index 771887faf9..f0926d6c09 100644
--- a/libavcodec/dstdec.c
+++ b/libavcodec/dstdec.c
@@ -56,7 +56,6 @@ static const int8_t probs_code_pred_coeff[3][3] = {
typedef struct ArithCoder {
unsigned int a;
unsigned int c;
-int overread;
} ArithCoder;
typedef struct Table {
@@ -86,6 +85,12 @@ static av_cold int decode_init(AVCodecContext *avctx)
return AVERROR_PATCHWELCOME;
}
+// the sample rate is only allowed to be 64,128,256 * 44100 by ISO/IEC
14496-3:2005(E)
+// We are a bit more tolerant here, but this check is needed to bound the
size and duration
+if (avctx->sample_rate > 256 * 44100)
+return AVERROR_INVALIDDATA;
+
+
if (DST_SAMPLES_PER_FRAME(avctx->sample_rate) & 7) {
return AVERROR_PATCHWELCOME;
}
@@ -181,7 +186,6 @@ static void ac_init(ArithCoder *ac, GetBitContext *gb)
{
ac->a = 4095;
ac->c = get_bits(gb, 12);
-ac->overread = 0;
}
static av_always_inline void ac_get(ArithCoder *ac, GetBitContext *gb, int p,
int *e)
@@ -201,8 +205,6 @@ static av_always_inline void ac_get(ArithCoder *ac,
GetBitContext *gb, int p, in
if (ac->a < 2048) {
int n = 11 - av_log2(ac->a);
ac->a <<= n;
-if (get_bits_left(gb) < n)
-ac->overread ++;
ac->c = (ac->c << n) | get_bits(gb, n);
}
}
@@ -355,9 +357,6 @@ static int decode_frame(AVCodecContext *avctx, void *data,
prob = 128;
}
-if (ac->overread > 16)
-return AVERROR_INVALIDDATA;
-
ac_get(ac, gb, prob, );
v = ((predict >> 15) ^ residual) & 1;
dsd[((i >> 3) * channels + ch) << 2] |= v << (7 - (i & 0x7 ));
--
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".
Re: [FFmpeg-devel] [PATCH v6 1/2] libavcodec/pgxdec: Add PGX decoder
On Wed, Jul 1, 2020 at 6:10 PM Nicolas George wrote:
>
> gautamr...@gmail.com (12020-06-30):
> > From: Gautam Ramakrishnan
> >
> > This patch adds a pgx decoder.
> > ---
> > Changelog | 1 +
> > doc/general.texi| 2 +
> > libavcodec/Makefile | 1 +
> > libavcodec/allcodecs.c | 1 +
> > libavcodec/codec_desc.c | 7 ++
> > libavcodec/codec_id.h | 1 +
> > libavcodec/pgxdec.c | 199
> > libavcodec/version.h| 2 +-
> > 8 files changed, 213 insertions(+), 1 deletion(-)
> > create mode 100644 libavcodec/pgxdec.c
> >
> > diff --git a/Changelog b/Changelog
> > index a60e7d2eb8..1bb9931c0d 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest.
> > version :
> > - AudioToolbox output device
> > - MacCaption demuxer
> > +- PGX decoder
> >
> >
> > version 4.3:
> > diff --git a/doc/general.texi b/doc/general.texi
> > index ea34b963b5..53d556c56c 100644
> > --- a/doc/general.texi
> > +++ b/doc/general.texi
> > @@ -751,6 +751,8 @@ following image formats are supported:
> > @tab Portable GrayMap image
> > @item PGMYUV @tab X @tab X
> > @tab PGM with U and V components in YUV 4:2:0
>
> > +@item PGX @tab @tab X
> > +@tab PGX file decoder
> > @item PIC @tab @tab X
> > @tab Pictor/PC Paint
> > @item PNG @tab X @tab X
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 5a6ea59715..12aa43fe51 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -536,6 +536,7 @@ OBJS-$(CONFIG_PGM_ENCODER) += pnmenc.o
> > OBJS-$(CONFIG_PGMYUV_DECODER) += pnmdec.o pnm.o
> > OBJS-$(CONFIG_PGMYUV_ENCODER) += pnmenc.o
> > OBJS-$(CONFIG_PGSSUB_DECODER) += pgssubdec.o
> > +OBJS-$(CONFIG_PGX_DECODER) += pgxdec.o
> > OBJS-$(CONFIG_PICTOR_DECODER) += pictordec.o cga_data.o
> > OBJS-$(CONFIG_PIXLET_DECODER) += pixlet.o
> > OBJS-$(CONFIG_PJS_DECODER) += textdec.o ass.o
> > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > index fa0c08d42e..a5048290f7 100644
> > --- a/libavcodec/allcodecs.c
> > +++ b/libavcodec/allcodecs.c
> > @@ -238,6 +238,7 @@ extern AVCodec ff_pgm_encoder;
> > extern AVCodec ff_pgm_decoder;
> > extern AVCodec ff_pgmyuv_encoder;
> > extern AVCodec ff_pgmyuv_decoder;
> > +extern AVCodec ff_pgx_decoder;
> > extern AVCodec ff_pictor_decoder;
> > extern AVCodec ff_pixlet_decoder;
> > extern AVCodec ff_png_encoder;
> > diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> > index 9f8847544f..67e0a3055c 100644
> > --- a/libavcodec/codec_desc.c
> > +++ b/libavcodec/codec_desc.c
> > @@ -1405,6 +1405,13 @@ static const AVCodecDescriptor codec_descriptors[] =
> > {
> > .long_name = NULL_IF_CONFIG_SMALL("AVS2-P2/IEEE1857.4"),
> > .props = AV_CODEC_PROP_LOSSY,
> > },
> > +{
> > +.id= AV_CODEC_ID_PGX,
> > +.type = AVMEDIA_TYPE_VIDEO,
> > +.name = "pgx",
> > +.long_name = NULL_IF_CONFIG_SMALL("PGX (JPEG2000 Test Format)"),
> > +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
> > +},
> > {
> > .id= AV_CODEC_ID_Y41P,
> > .type = AVMEDIA_TYPE_VIDEO,
> > diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
> > index d885962c9c..896ecb0ce0 100644
> > --- a/libavcodec/codec_id.h
> > +++ b/libavcodec/codec_id.h
> > @@ -241,6 +241,7 @@ enum AVCodecID {
> > AV_CODEC_ID_SCREENPRESSO,
> > AV_CODEC_ID_RSCC,
> > AV_CODEC_ID_AVS2,
> > +AV_CODEC_ID_PGX,
> >
> > AV_CODEC_ID_Y41P = 0x8000,
> > AV_CODEC_ID_AVRP,
> > diff --git a/libavcodec/pgxdec.c b/libavcodec/pgxdec.c
> > new file mode 100644
> > index 00..c9e07c1e55
> > --- /dev/null
> > +++ b/libavcodec/pgxdec.c
> > @@ -0,0 +1,199 @@
> > +/*
> > + * PGX image format
> > + * Copyright (c) 2020 Gautam Ramakrishnan
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA
> > + */
> > +
> > +#include "avcodec.h"
> > +#include "internal.h"
> > +#include "bytestream.h"
> > +#include
Re: [FFmpeg-devel] RfP Candidates
On 2020-06-29 16:04 +0200, Jean-Baptiste Kempf wrote: > Hello, > > The next step in the community voting process is to re-elect the Community > and Technical Committees. > > Therefore, we need candidates. > > Reminders: > The community committee is here to help smooth things down between people in > the community and the conflicts that can arise here. The main task for the > months to come is to create (or not) a CoC and update some of the rules of > interactions. > > The technical committee is here to entangle technical debates, when people > cannot agree, and force a decision. > The TC is not here to define the FFmpeg roadmap or whatever, but to do > arbitration. > > We need 5 people for each. > > > If you are interested in being a candidate, please mail me in private (aka > not on the list). > You can suggest another candidate, but I will validate with them if they > might agree in the end. > > You have until Wednesday 23:59 UTC to suggest candidates. Thursday starts the > votes for 5 days. Do I read correctly that candidates can be suggested from Monday afternoon until today before midnight UTC? If yes it seems a bit short to me? I don't have strong feelings or anything. Just wanted to see if it's only me... Thanks for your efforts JB! [...] Alexander ___ 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] Replace 'FontName' with 'Fontname' in the documentation.
On 02-07-2020 12:33 am, Joe Ratterman wrote:
Ping.
First time contributing to this project, so I'm not sure if I missed
something?
Will apply.
Thanks,
Gyan
On Thu, May 28, 2020 at 10:32 AM Joe Ratterman wrote:
This is the only use of 'FontName' with that capitalization, as both
source-code and tests use 'Fontname'. Having consistent capitalization
makes it easier to find the relevant source from the docs.
See these examples for other uses:
libavcodec/ass_split.c:68
tests/ref/fate/sub-cc:9
---
doc/filters.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 85a511b205..84afa1fff3 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17943,7 +17943,7 @@ subtitles=video.mkv:si=1
To make the subtitles stream from @file{sub.srt} appear in 80%
transparent blue
@code{DejaVu Serif}, use:
@example
-subtitles=sub.srt:force_style='FontName=DejaVu
Serif,PrimaryColour='
+subtitles=sub.srt:force_style='Fontname=DejaVu
Serif,PrimaryColour='
@end example
@section super2xsai
--
2.21.0
___
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 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] Replace 'FontName' with 'Fontname' in the documentation.
Ping.
First time contributing to this project, so I'm not sure if I missed
something?
On Thu, May 28, 2020 at 10:32 AM Joe Ratterman wrote:
> This is the only use of 'FontName' with that capitalization, as both
> source-code and tests use 'Fontname'. Having consistent capitalization
> makes it easier to find the relevant source from the docs.
>
> See these examples for other uses:
> libavcodec/ass_split.c:68
> tests/ref/fate/sub-cc:9
> ---
> doc/filters.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 85a511b205..84afa1fff3 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -17943,7 +17943,7 @@ subtitles=video.mkv:si=1
> To make the subtitles stream from @file{sub.srt} appear in 80%
> transparent blue
> @code{DejaVu Serif}, use:
> @example
> -subtitles=sub.srt:force_style='FontName=DejaVu
> Serif,PrimaryColour='
> +subtitles=sub.srt:force_style='Fontname=DejaVu
> Serif,PrimaryColour='
> @end example
>
> @section super2xsai
> --
> 2.21.0
>
>
___
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] lavc/aac_ac3_parser: fix the potential overflow
Hi Anton,
hi Jun!
On 2020-07-01 16:23 +0200, Anton Khirnov wrote:
> Quoting Jun Zhao (2020-06-29 15:23:10)
> > From: Jun Zhao
> >
> > Fix the potential overflow.
> >
> > Suggested-by: Alexander Strasser
> > Signed-off-by: Jun Zhao
> > ---
> > libavcodec/aac_ac3_parser.c | 9 +
> > libavcodec/aac_ac3_parser.h | 4 ++--
> > tests/ref/fate/adtstoasc_ticket3715 | 2 +-
> > 3 files changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
> > index 0746798..b26790d 100644
> > --- a/libavcodec/aac_ac3_parser.c
> > +++ b/libavcodec/aac_ac3_parser.c
> > @@ -98,11 +98,12 @@ get_next:
> > }
> >
> > /* Calculate the average bit rate */
> > -s->frame_number++;
> > if (avctx->codec_id != AV_CODEC_ID_EAC3) {
> > -avctx->bit_rate =
> > -(s->last_bit_rate * (s->frame_number -1) +
> > s->bit_rate)/s->frame_number;
> > -s->last_bit_rate = avctx->bit_rate;
> > +if (s->frame_number < UINT64_MAX) {
> > +s->frame_number++;
> > +s->last_bit_rate += (s->bit_rate -
> > s->last_bit_rate)/s->frame_number;
> > +avctx->bit_rate = (int64_t)llround(s->last_bit_rate);
> > +}
> > }
> > }
> >
> > diff --git a/libavcodec/aac_ac3_parser.h b/libavcodec/aac_ac3_parser.h
> > index b04041f..c53d16f 100644
> > --- a/libavcodec/aac_ac3_parser.h
> > +++ b/libavcodec/aac_ac3_parser.h
> > @@ -55,8 +55,8 @@ typedef struct AACAC3ParseContext {
> > uint64_t state;
> >
> > int need_next_header;
> > -int frame_number;
> > -int last_bit_rate;
> > +uint64_t frame_number;
> > +double last_bit_rate;
>
> This won't give the same result on all platforms anymore.
It's also a bit different from what I had in mind.
I was thinking more in the line of how it's implemented in
libavcodec/mpegaudio_parser.c .
There is a bit of noise there because of data that doesn't contain audio
and also for the CBR case I think. Wouldn't be needed here AFAICT.
I may well be missing something. If so understanding more would help me
and we could fix both places. Otherwise if it's OK like it was done in
mpegaudio_parser, we could maybe use the same strategy here too.
Thanks for sending the patch and sorry for the delayed response.
Best regards,
Alexander
___
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 2/5] libavcodec/libaomenc: Add command-line options to control the use of partition tools.
On Mon, Jun 29, 2020 at 11:13 AM James Zern wrote: > > On Thu, Jun 25, 2020 at 6:02 PM Wang Cao wrote: > > > > This patch adds the control for enabling rectangular partitions, 1:4/4:1 > > partitions and AB shape partitions. > > > > Signed-off-by: Wang Cao > > --- > > doc/encoders.texi | 10 ++ > > libavcodec/libaomenc.c | 15 +++ > > libavcodec/version.h | 2 +- > > 3 files changed, 26 insertions(+), 1 deletion(-) > > > > lgtm. I'll apply this soon if there aren't any other comments. applied, thanks. ___ 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 v3] avcodec/libaomenc.c: Add super-resolution options to libaom wrapper
On Tue, Jun 30, 2020 at 12:44 PM Wang Cao wrote:
>
> From: Wang Cao
>
> Signed-off-by: Wang Cao
> ---
> doc/encoders.texi | 36 +
> libavcodec/libaomenc.c | 46 ++
> libavcodec/version.h | 2 +-
> 3 files changed, 83 insertions(+), 1 deletion(-)
>
> [...]
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index fe98449fa1..83ccf07fab 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -23,6 +23,7 @@
> * AV1 encoder support via libaom
> */
>
> +#include
This looks unrelated.
> [...]
> +#if AOM_ENCODER_ABI_VERSION >= 22
Judging by when the enum was added, I think 19 might work.
> +{ "superres-mode", "Select super-resolution mode",
> OFFSET(superres_mode), AV_OPT_TYPE_INT, {.i64 = -1},
>-1, AOM_SUPERRES_AUTO, VE, "superres_mode"},
> +{ "none", "No frame superres allowed",
> 0, AV_OPT_TYPE_CONST, {.i64 =
> AOM_SUPERRES_NONE},0, 0, VE, "superres_mode"},
> +{ "fixed", "All frames are coded at the specified scale and
> super-resolved", 0, AV_OPT_TYPE_CONST, {.i64 =
> AOM_SUPERRES_FIXED}, 0, 0, VE, "superres_mode"},
> +{ "random","All frames are coded at a random scale and
> super-resolved.", 0, AV_OPT_TYPE_CONST, {.i64 =
> AOM_SUPERRES_RANDOM}, 0, 0, VE, "superres_mode"},
> +{ "qthresh", "Superres scale for a frame is determined based on
> q_index", 0, AV_OPT_TYPE_CONST, {.i64 =
> AOM_SUPERRES_QTHRESH}, 0, 0, VE, "superres_mode"},
> +{ "auto", "Automatically select superres for appropriate
> frames", 0, AV_OPT_TYPE_CONST, {.i64 =
> AOM_SUPERRES_AUTO},0, 0, VE, "superres_mode"},
___
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 3/5] libavcodec/libaomenc.c: Add command-line options for intra-coding tools
On Mon, Jun 29, 2020 at 11:15 AM James Zern wrote: > > On Thu, Jun 25, 2020 at 5:55 PM Wang Cao wrote: > > > > Signed-off-by: Wang Cao > > --- > > doc/encoders.texi | 21 +++ > > libavcodec/libaomenc.c | 47 -- > > libavcodec/version.h | 2 +- > > 3 files changed, 63 insertions(+), 7 deletions(-) > > > > lgtm. applied, thanks. ___ 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] lavu: add a template for refcounted objects.
Anton Khirnov (12020-07-01): > You do not dereference buf->opaque. You pass it to the free callback > when the refcount reaches zero, that is the only way it should ever be > used. You are talking about the implementation of the refcounted structure. I was talking about when we use the refcounted structure. Your version makes every single use more complex, because of the indirection. This is something to know about code I write with new APIs: I always make efforts to make the API as simple to use as possible, even if it means making the implementation more complex. Because the implementation is done only once, but using the API will happen many times. And this is exactly what happens with your proposal: a refcounted structure defined with it would be more annoying to use because of the indirection, and I will not have it. If you have a proposal that makes using the refcounted structure as simple and clean as: av_foobar_ref(AVFoobar *f); av_foobar_unrefp(AVFoobar **f); then I will listen. But if you have type pruning or indirection, then my proposal is superior. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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 2/2] libavcodec/jpeg2000dec.c: Enable image offsets
From: Gautam Ramakrishnan
This patch enables support for image offsets.
---
libavcodec/jpeg2000dec.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 86f9170723..f91406ab9e 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -288,10 +288,6 @@ static int get_siz(Jpeg2000DecoderContext *s)
s->tile_offset_y = bytestream2_get_be32u(>g); // YT0Siz
ncomponents = bytestream2_get_be16u(>g); // CSiz
-if (s->image_offset_x || s->image_offset_y) {
-avpriv_request_sample(s->avctx, "Support for image offsets");
-return AVERROR_PATCHWELCOME;
-}
if (av_image_check_size2(s->width, s->height, s->avctx->max_pixels,
AV_PIX_FMT_NONE, 0, s->avctx)) {
avpriv_request_sample(s->avctx, "Large Dimensions");
return AVERROR_PATCHWELCOME;
--
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".
[FFmpeg-devel] [PATCH 1/2] libavcodec/jpeg2000dec: Enhance pix fmt selection
From: Gautam Ramakrishnan
This patch assigns default pix format values when
a match does not take place.
---
libavcodec/jpeg2000dec.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 3f4a9ef96c..86f9170723 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -436,6 +436,15 @@ static int get_siz(Jpeg2000DecoderContext *s)
s->cdef[3] = 3;
i = 0;
}
+} else if (ncomponents == 3 && s->precision == 8) {
+s->avctx->pix_fmt = AV_PIX_FMT_RGB24;
+i = 0;
+} else if (ncomponents == 2 && s->precision == 8) {
+s->avctx->pix_fmt = AV_PIX_FMT_YA8;
+i = 0;
+} else if (ncomponents == 1 && s->precision == 8) {
+s->avctx->pix_fmt = AV_PIX_FMT_GRAY8;
+i = 0;
}
}
--
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".
Re: [FFmpeg-devel] [PATCH 1/3] lavu: add a template for refcounted objects.
James Almer (12020-07-01): > I very much prefer this approach, being clean looking, public, and free > of macros from unguarded headers Please do not forget the major drawback: This version makes the creation of the refcounted structure simpler, and every single use more complex. One creation, many uses. Please remember this, it is easy to forget. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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] lavu: add a template for refcounted objects.
Quoting Nicolas George (2020-07-01 18:47:15) > Anton Khirnov (12020-07-01): > > instead of > > #define AVRC_TYPE AVBuffer > > #define AVRC_PREFIX prefix > > #define AVRC_FIELD refcount > > you'd have > > av_refcount_init(>refcount, buf, buffer_free); > > Does not look more annoying to me, to the contrary macro templates > > require more effort to understand or debug. > > The annoying part is to have to dereference buf->opaque each time we > need to use it. It clutters all the code that use a structure. It is > completely unacceptable to me. You do not dereference buf->opaque. You pass it to the free callback when the refcount reaches zero, that is the only way it should ever be used. > > > Why? I do not see how an extra pointer dereference could possibly matter > > here. > > It does not matter much, but in tights loops it can. If you constantly alloc and free objects in tight loops then you have way bigger problems than a single pointer dereference. This is really a red herring. Beyond that, I suppose this is a personal preference difference. Some more opinions from other people would be welcome. -- Anton Khirnov ___ 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] lavu: add a template for refcounted objects.
On 7/1/2020 12:05 PM, Anton Khirnov wrote:
> Quoting Nicolas George (2020-06-27 17:16:44)
>> Signed-off-by: Nicolas George
>> ---
>> libavutil/avrefcount_template.h | 140
>> tests/ref/fate/source | 1 +
>> 2 files changed, 141 insertions(+)
>> create mode 100644 libavutil/avrefcount_template.h
>>
>>
>> I will need to refcount something soon. Recently, the need to stop
>> abusing AVBuffer for all refcounting was mentioned on the list. So here
>> is an attempt at isolating the refcounting itself.
>>
>> This is not the final verion, I will first work on the "something" to
>> make sure it suits the needs. But it is a first version.
>>
>> Anton, I would appreciate if you had a look at this and told me if there
>> is something you strongly dislike about before I have piled too much
>> efforts over it.
>
> Why a template? It seems simpler to add a struct like
> typedef struct AVRefcount {
> atomic_uint refcount;
> void *opaque;
> void (*free)(void *opaque);
> } AVRefcount;
> and then embed it in everything that wants to be refcounted. All just
> normal structs and functions, no layers of macros.
I very much prefer this approach, being clean looking, public, and free
of macros from unguarded headers, but it needs to be either easily
extensible or well defined since day 1.
For example, it could have more callbacks to be triggered by specific
actions, like when creating new references, to workaround the current
constrains of AVBufferRef.
___
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] libavutil/imgutils: UBSan nullptr-with-offset in av_image_fill_pointer
While running under Clang's UndefinedBehaviorSanitizer, I found a few
places where av_image_fill_pointers is called before buffers for the image
are allocated, so ptr is passed in as NULL.
This leads to (currently harmless) UB when the plane sizes are added to the
null pointer, so I was wondering if there was interest in avoiding it?
I've attached a patch to expose some extra utilities and avoid passing in
the null pointer, but is this an appropriate way to work around it?
Thank you,
Brian
From 9db97425b2b3ca0913b7ce8f6f7c096a8aa5c964 Mon Sep 17 00:00:00 2001
From: Brian Kim
Date: Tue, 30 Jun 2020 17:59:53 -0700
Subject: [PATCH] libavutil/imgutils: add utility to get plane sizes
This utility helps avoid undefined behavior when doing things like
checking how much memory we need to allocate for an image before we have
allocated a buffer.
---
libavcodec/decode.c | 11 +++---
libavutil/frame.c| 9
libavutil/imgutils.c | 49
libavutil/imgutils.h | 22
4 files changed, 65 insertions(+), 26 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index de9c079f9d..cd0424b467 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1471,9 +1471,8 @@ static int update_frame_pool(AVCodecContext *avctx, AVFrame *frame)
switch (avctx->codec_type) {
case AVMEDIA_TYPE_VIDEO: {
-uint8_t *data[4];
int linesize[4];
-int size[4] = { 0 };
+int size[4];
int w = frame->width;
int h = frame->height;
int tmpsize, unaligned;
@@ -1494,17 +1493,13 @@ static int update_frame_pool(AVCodecContext *avctx, AVFrame *frame)
unaligned |= linesize[i] % pool->stride_align[i];
} while (unaligned);
-tmpsize = av_image_fill_pointers(data, avctx->pix_fmt, h,
- NULL, linesize);
+tmpsize = av_image_fill_plane_sizes(size, avctx->pix_fmt, h,
+ linesize);
if (tmpsize < 0) {
ret = tmpsize;
goto fail;
}
-for (i = 0; i < 3 && data[i + 1]; i++)
-size[i] = data[i + 1] - data[i];
-size[i] = tmpsize - (data[i] - data[0]);
-
for (i = 0; i < 4; i++) {
pool->linesize[i] = linesize[i];
if (size[i]) {
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 9884eae054..3abb1f12d5 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -212,6 +212,7 @@ void av_frame_free(AVFrame **frame)
static int get_video_buffer(AVFrame *frame, int align)
{
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
+int size[4];
int ret, i, padded_height;
int plane_padding = FFMAX(16 + 16/*STRIDE_ALIGN*/, align);
@@ -239,8 +240,8 @@ static int get_video_buffer(AVFrame *frame, int align)
}
padded_height = FFALIGN(frame->height, 32);
-if ((ret = av_image_fill_pointers(frame->data, frame->format, padded_height,
- NULL, frame->linesize)) < 0)
+if ((ret = av_image_fill_plane_sizes(size, frame->format, padded_height,
+ frame->linesize)) < 0)
return ret;
frame->buf[0] = av_buffer_alloc(ret + 4*plane_padding);
@@ -249,9 +250,7 @@ static int get_video_buffer(AVFrame *frame, int align)
goto fail;
}
-if ((ret = av_image_fill_pointers(frame->data, frame->format, padded_height,
- frame->buf[0]->data, frame->linesize)) < 0)
-goto fail;
+av_image_fill_pointers_from_sizes(frame->data, size, frame->buf[0]->data);
for (i = 1; i < 4; i++) {
if (frame->data[i])
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index 7f9c1b632c..7045a9df65 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -108,26 +108,25 @@ int av_image_fill_linesizes(int linesizes[4], enum AVPixelFormat pix_fmt, int wi
return 0;
}
-int av_image_fill_pointers(uint8_t *data[4], enum AVPixelFormat pix_fmt, int height,
- uint8_t *ptr, const int linesizes[4])
+int av_image_fill_plane_sizes(int size[4], enum AVPixelFormat pix_fmt, int height,
+ const int linesizes[4])
{
-int i, total_size, size[4] = { 0 }, has_plane[4] = { 0 };
+int i, total_size, has_plane[4] = { 0 };
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
-memset(data , 0, sizeof(data[0])*4);
+memset(size , 0, sizeof(size[0])*4);
if (!desc || desc->flags & AV_PIX_FMT_FLAG_HWACCEL)
return AVERROR(EINVAL);
-data[0] = ptr;
if (linesizes[0] > (INT_MAX - 1024) / height)
return AVERROR(EINVAL);
size[0] = linesizes[0] * height;
if (desc->flags & AV_PIX_FMT_FLAG_PAL ||
desc->flags & FF_PSEUDOPAL) {
-data[1] = ptr + size[0]; /* palette is stored here as 256 32
[FFmpeg-devel] [PATCH] libavfilter/vf_codecview: add block structure visualization
example command line to visualize block decomposition:
./ffmpeg -export_side_data +venc_params -i input.webm -vf
codecview=bs=true output.webm
---
doc/filters.texi | 3 +++
libavcodec/vp9.c | 8 +++-
libavfilter/vf_codecview.c | 41 ++
3 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 84567dec16..db2c80b1e9 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7285,6 +7285,9 @@ backward predicted MVs of B-frames
@item qp
Display quantization parameters using the chroma planes.
+@item bs
+Display block structure using the luma plane.
+
@item mv_type, mvt
Set motion vectors type to visualize. Includes MVs from all frames unless
specified by @var{frame_type} option.
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index fd0bab14a2..e700def70e 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1501,10 +1501,8 @@ static int vp9_export_enc_params(VP9Context *s, VP9Frame
*frame)
AVVideoEncParams *par;
unsigned int tile, nb_blocks = 0;
-if (s->s.h.segmentation.enabled) {
-for (tile = 0; tile < s->active_tile_cols; tile++)
-nb_blocks += s->td[tile].nb_block_structure;
-}
+for (tile = 0; tile < s->active_tile_cols; tile++)
+nb_blocks += s->td[tile].nb_block_structure;
par = av_video_enc_params_create_side_data(frame->tf.f,
AV_VIDEO_ENC_PARAMS_VP9, nb_blocks);
@@ -1536,7 +1534,7 @@ static int vp9_export_enc_params(VP9Context *s, VP9Frame
*frame)
b->w = 1 << (3 +
td->block_structure[block_tile].block_size_idx_x);
b->h = 1 << (3 +
td->block_structure[block_tile].block_size_idx_y);
-if (s->s.h.segmentation.feat[seg_id].q_enabled) {
+if (s->s.h.segmentation.enabled &&
s->s.h.segmentation.feat[seg_id].q_enabled) {
b->delta_qp = s->s.h.segmentation.feat[seg_id].q_val;
if (s->s.h.segmentation.absolute_vals)
b->delta_qp -= par->qp;
diff --git a/libavfilter/vf_codecview.c b/libavfilter/vf_codecview.c
index 331bfba777..db06625d70 100644
--- a/libavfilter/vf_codecview.c
+++ b/libavfilter/vf_codecview.c
@@ -34,6 +34,7 @@
#include "libavutil/opt.h"
#include "avfilter.h"
#include "internal.h"
+#include "libavutil/video_enc_params.h"
#define MV_P_FOR (1<<0)
#define MV_B_FOR (1<<1)
@@ -51,6 +52,7 @@ typedef struct CodecViewContext {
unsigned mv_type;
int hsub, vsub;
int qp;
+int bs;
} CodecViewContext;
#define OFFSET(x) offsetof(CodecViewContext, x)
@@ -63,6 +65,7 @@ static const AVOption codecview_options[] = {
CONST("bf", "forward predicted MVs of B-frames", MV_B_FOR, "mv"),
CONST("bb", "backward predicted MVs of B-frames", MV_B_BACK, "mv"),
{ "qp", NULL, OFFSET(qp), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, .flags = FLAGS
},
+{ "bs", "set block structure to visualize", OFFSET(bs), AV_OPT_TYPE_BOOL,
{.i64=0}, 0, 1, .flags = FLAGS },
{ "mv_type", "set motion vectors type", OFFSET(mv_type),
AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv_type" },
{ "mvt", "set motion vectors type", OFFSET(mv_type),
AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv_type" },
CONST("fp", "forward predicted MVs", MV_TYPE_FOR, "mv_type"),
@@ -212,6 +215,30 @@ static void draw_arrow(uint8_t *buf, int sx, int sy, int
ex,
draw_line(buf, sx, sy, ex, ey, w, h, stride, color);
}
+static void draw_block_border(AVFrame *frame, AVVideoBlockParams *b)
+{
+const int lzy = frame->linesize[0];
+uint8_t *py = frame->data[0] + b->src_y * lzy;
+
+for (int x = b->src_x; x < b->src_x + b->w; x++) {
+if (x >= frame->width)
+break;
+py[x] = py[x] * 3 / 4;
+}
+for (int y = b->src_y; y < b->src_y + b->h; y++) {
+if (y >= frame->height)
+break;
+py[b->src_x] = py[b->src_x] * 3 / 4;
+py[b->src_x + b->w - 1] = py[b->src_x + b->w - 1] * 3 / 4;
+py += lzy;
+}
+for (int x = b->src_x; x < b->src_x + b->w; x++) {
+if (x >= frame->width)
+break;
+py[x] = py[x] * 3 / 4;
+}
+}
+
static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
{
AVFilterContext *ctx = inlink->dst;
@@ -242,6 +269,20 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
}
}
+if (s->bs) {
+AVFrameSideData *sd = av_frame_get_side_data(frame,
AV_FRAME_DATA_VIDEO_ENC_PARAMS);
+if (sd) {
+AVVideoEncParams *par = (AVVideoEncParams*)sd->data;
+
+if (par->nb_blocks) {
+for (int i = 0; i < par->nb_blocks; i++) {
+AVVideoBlockParams *b = av_video_enc_params_block(par, i);
+draw_block_border(frame, b);
+}
+}
+}
+}
+
if (s->mv || s->mv_type) {
AVFrameSideData *sd
Re: [FFmpeg-devel] [PATCH v3] ffprobe: Allow unknown format private AVOptions
On Wed, 1 Jul 2020, Derek Buitenhuis wrote:
This useful, because by ffprobe's very nature, you use it to probe
a file and find out what it is. Requiring every format private option
to be known to the demuxer forces one to run ffprobe twice, if one
wants to use ffprobe in a generic way.
For example, say one wants to probe all user-uploaded files, while
also ignoring edit lists for any MP4s that are uploaded. Currently,
you'd have to run ffprobe twice: once to identify the format, and
once again to actually probe the metadata you want. After this
patch, you could set -ignore_editlist 1 on every call and only
probe once.
Signed-off-by: Derek Buitenhuis
---
It now iterates over the missing keys as Marton requested.
LGTM.
Maybe unknown codec options should also be allowed?
Regards,
Marton
---
fftools/ffprobe.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 5515e1b31b..d4e494f11f 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2854,7 +2854,7 @@ static int open_input_file(InputFile *ifile, const char
*filename,
{
int err, i;
AVFormatContext *fmt_ctx = NULL;
-AVDictionaryEntry *t;
+AVDictionaryEntry *t = NULL;
int scan_all_pmts_set = 0;
fmt_ctx = avformat_alloc_context();
@@ -2879,10 +2879,8 @@ static int open_input_file(InputFile *ifile, const char
*filename,
ifile->fmt_ctx = fmt_ctx;
if (scan_all_pmts_set)
av_dict_set(_opts, "scan_all_pmts", NULL, AV_DICT_MATCH_CASE);
-if ((t = av_dict_get(format_opts, "", NULL, AV_DICT_IGNORE_SUFFIX))) {
-av_log(NULL, AV_LOG_ERROR, "Option %s not found.\n", t->key);
-return AVERROR_OPTION_NOT_FOUND;
-}
+while ((t = av_dict_get(format_opts, "", t, AV_DICT_IGNORE_SUFFIX)))
+av_log(NULL, AV_LOG_WARNING, "Option %s skipped - not known to
demuxer.\n", t->key);
if (find_stream_info) {
AVDictionary **opts = setup_find_stream_info_opts(fmt_ctx, codec_opts);
--
2.27.0.rc2
___
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 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 v3] ffprobe: Allow unknown format private AVOptions
This useful, because by ffprobe's very nature, you use it to probe
a file and find out what it is. Requiring every format private option
to be known to the demuxer forces one to run ffprobe twice, if one
wants to use ffprobe in a generic way.
For example, say one wants to probe all user-uploaded files, while
also ignoring edit lists for any MP4s that are uploaded. Currently,
you'd have to run ffprobe twice: once to identify the format, and
once again to actually probe the metadata you want. After this
patch, you could set -ignore_editlist 1 on every call and only
probe once.
Signed-off-by: Derek Buitenhuis
---
It now iterates over the missing keys as Marton requested.
---
fftools/ffprobe.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 5515e1b31b..d4e494f11f 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2854,7 +2854,7 @@ static int open_input_file(InputFile *ifile, const char
*filename,
{
int err, i;
AVFormatContext *fmt_ctx = NULL;
-AVDictionaryEntry *t;
+AVDictionaryEntry *t = NULL;
int scan_all_pmts_set = 0;
fmt_ctx = avformat_alloc_context();
@@ -2879,10 +2879,8 @@ static int open_input_file(InputFile *ifile, const char
*filename,
ifile->fmt_ctx = fmt_ctx;
if (scan_all_pmts_set)
av_dict_set(_opts, "scan_all_pmts", NULL, AV_DICT_MATCH_CASE);
-if ((t = av_dict_get(format_opts, "", NULL, AV_DICT_IGNORE_SUFFIX))) {
-av_log(NULL, AV_LOG_ERROR, "Option %s not found.\n", t->key);
-return AVERROR_OPTION_NOT_FOUND;
-}
+while ((t = av_dict_get(format_opts, "", t, AV_DICT_IGNORE_SUFFIX)))
+av_log(NULL, AV_LOG_WARNING, "Option %s skipped - not known to
demuxer.\n", t->key);
if (find_stream_info) {
AVDictionary **opts = setup_find_stream_info_opts(fmt_ctx, codec_opts);
--
2.27.0.rc2
___
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] lavu: add a template for refcounted objects.
Anton Khirnov (12020-07-01): > instead of > #define AVRC_TYPE AVBuffer > #define AVRC_PREFIX prefix > #define AVRC_FIELD refcount > you'd have > av_refcount_init(>refcount, buf, buffer_free); > Does not look more annoying to me, to the contrary macro templates > require more effort to understand or debug. The annoying part is to have to dereference buf->opaque each time we need to use it. It clutters all the code that use a structure. It is completely unacceptable to me. > Why? I do not see how an extra pointer dereference could possibly matter here. It does not matter much, but in tights loops it can. > In my experience, providing the wrong opaque pointer has never been a > common source of bugs (and is typically easily noticeable if it does > happen), so I see that as an acceptable tradeoff. Acceptable, certainly. But I prefer static type safety whenever possible, especially when it comes with the other benefits. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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 v3] fbdetile cpu based detiling of framebuffers v03
Hi Lynne, On Wed, Jul 1, 2020 at 3:37 PM Lynne wrote: > Jun 29, 2020, 18:58 by hanish...@gmail.com: > > > v03-20200629IST2208 fbdetile > > > > Added a generic detiling logic, which can be easily configured to > > detile many different tiling schemes. > > > > The same is inturn used to detile Intel Tile-Yf layout. > > > > NOTE: This is a full patch, it contains the previous versions also > > in it. > > > > v02-20200627IST2331 > > > > Unrolled Intel Legacy Tile-Y detiling logic. > > > > Also a consolidated patch file, instead of the previous development > > flow based multiple patch files. > > > > v01-20200627IST1308 > > > > Implemented Intel Legacy Tile-X and Tile-Y detiling logic > > > > NOTES: > > > > This video filter allows framebuffers which are tiled to be detiled > > using logic running on the cpu, into a linear layout. > > > > Currently it supports Intel Legacy Tile-X and Tile-Y layout detiling, > > as well as the newer Intel Tile-Yf layouts. > > > > THis should help one to work with frames captured (say using kmsgrab) > > on laptops having Intel GPU. This can be done live while capturing > > itself, or it can be applied later as a seperate pass. > > > > Tile-X conversion logic has been explicitly cross checked, with Tile-X > > based frames. However Tile-Y and Tile-Yf conv logics havent been tested > > with Tile-Y | Tile-Yf based frames, but it should potentially get the > > job done, based on my current understanding of these layout formats. > > > > TODO1: At a later time have to generate Tile-Y|Yf based frames, and then > > cross check the corresponding logic explicitly. > > > > TODO2: May be use OpenGL or Vulcan buffer helper routines to do the > > layout conversion. But some online discussions from sometime back seem > > to indicate that this path is not fully bug free currently. > > > > Still not happening, I'd like to see this done properly with hwdownload. > While what you > have works as a hack, we're not interested in hacks but something that > works universally. > As I said before, it can be easily sped up by a factor of 4 or 8 using > SIMD, so its > unjustifiable to have this in the codebase as a filter. > > Can you tell me how this is not universal. Rather by embedding it within hwdownload, we will be making it limited to use from a hwcontext, while keeping it has a seperate filter, allows one to use it either with a hw context or from any other source. And also it gives the flexibility to do it live or offline. So not sure in what sense you call my current flow restricted and a possible embedded within hwdownload one has being universal? Also I am assuming that gcc + libc is sensible enough to use a appropriate fast memcpy with say rep movs or simd load-stores as the case may be based on which cpu architecture to which the code is being built. The overhead with FullHD content is negligible. Beyond that if required I have structured the generic detile logic which I have implemented to do parallel detiling of multiple tiles in step, which could be easily translated into true parallel detiling in a hw or multicore setup. -- Keep ;-) HanishKVC ___ 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 v04] fbdetile cpu based detiling of framebuffers v04
v04-20200701IST2132, fbdetile
Optimised Generic Detile logic to detile multiple tiles in parallel,
logically speaking. This reduces cross check overheads to some extent
and thus improves speed a bit. While in a hardware or multicore setup,
it can be used to parallelise the detiling operations in a true sense.
Add a additional level of subtiling wrt Tile-Yf, which I had missed out
in the dirChangesList based tiling configuration, which is used by my
generic detiling logic. THe overhead due to this additional subtiling
is compensated by the speed gains due to parallel detiling.
NOTE: This is a consolidated patch, it contains previous versions also
v03-20200629IST2208 fbdetile
Added a generic detiling logic, which can be easily configured to
detile many different tiling schemes.
The same is inturn used to detile Intel Tile-Yf layout.
v02-20200627IST2331
Unrolled Intel Legacy Tile-Y detiling logic.
Also a consolidated patch file, instead of the previous development
flow based multiple patch files.
v01-20200627IST1308
Implemented Intel Legacy Tile-X and Tile-Y detiling logic
NOTES:
This video filter allows framebuffers which are tiled to be detiled
using logic running on the cpu, into a linear layout.
Currently it supports Intel Legacy Tile-X and Tile-Y layout detiling,
as well as the newer Intel Tile-Yf layouts.
THis should help one to work with frames captured (say using kmsgrab)
on laptops having Intel GPU. This can be done live while capturing
itself, or it can be applied later as a seperate pass.
Tile-X conversion logic has been explicitly cross checked, with Tile-X
based frames. However Tile-Y and Tile-Yf conv logics havent been tested
with Tile-Y | Tile-Yf based frames, but it should potentially get the
job done, based on my current understanding of these layout formats. A
minimal test has been done by seeing how a multicolor linear framebuffer
gets converted into a patterned layout, depending on the detile walk.
---
Changelog | 1 +
doc/filters.texi | 74 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_fbdetile.c | 568 ++
5 files changed, 645 insertions(+)
create mode 100644 libavfilter/vf_fbdetile.c
diff --git a/Changelog b/Changelog
index a60e7d2eb8..0e03491f6a 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest
within each release,
releases are sorted from youngest to oldest.
version :
+- fbdetile cpu based framebuffer layout detiling video filter
- AudioToolbox output device
- MacCaption demuxer
diff --git a/doc/filters.texi b/doc/filters.texi
index 67892e0afb..f7bcae1685 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12210,6 +12210,80 @@ It accepts the following optional parameters:
The number of the CUDA device to use
@end table
+@anchor{fbdetile}
+@section fbdetile
+
+Detiles the Framebuffer tile layout into a linear layout using CPU.
+
+It currently supports conversion from Intel legacy tile-x and tile-y as well
+as the newer Intel tile-yf layouts into a linear layout. This is useful if
+one is using kmsgrab and hwdownload to capture a screen which is using one
+of these non-linear layouts.
+
+NOTE: It also provides a generic detiling logic, which can be easily configured
+to detile many different tiling schemes if required, in future. The same is
+used for detiling the intel tile-yf layout. Also sample configuration to handle
+intel tile-x and tile-y using generic detile logic is also shown for reference,
+in the code.
+
+Currently it expects the data to be a 32bit RGB based pixel format. However
+the logic doesnt do any pixel format conversion or so. Later will be enabling
+16bit RGB data also, as the logic is transparent to it at one level.
+
+One could either insert this into the filter chain while capturing itself,
+or else, if it is slowing things down or so, then one could instead insert
+it into the filter chain during playback or transcoding or so.
+
+It supports the following optional parameters
+
+@table @option
+@item type
+Specify which detiling conversion to apply. The supported values are
+@table @var
+@item 0
+intel tile-x to linear conversion (the default)
+@item 1
+intel tile-y to linear conversion.
+@item 2
+intel tile-yf to linear conversion.
+@end table
+@end table
+
+If one wants to convert during capture itself, one could do
+@example
+ffmpeg -f kmsgrab -i - -vf "hwdownload,format=bgr0,fbdetile" OUTPUT
+@end example
+
+However if one wants to convert after the tiled data has been already captured
+@example
+ffmpeg -i INPUT -vf "fbdetile" OUTPUT
+@end example
+@example
+ffplay -i INPUT -vf "fbdetile"
+@end example
+
+NOTE: While transcoding a test 1080p h264 stream, with 276 frames, below was
+the average times taken by the different detile logics.
+@example
+rm out.mp4; time ./ffmpeg -i input.mp4 out.mp4
+rm out.mp4; time ./ffmpeg -i input.mp4 -vf fbdetile=0
Re: [FFmpeg-devel] [PATCH 1/3] lavu: add a template for refcounted objects.
Quoting Nicolas George (2020-07-01 17:13:22)
> Anton Khirnov (12020-07-01):
> > Why a template? It seems simpler to add a struct like
> > typedef struct AVRefcount {
> > atomic_uint refcount;
> > void *opaque;
> > void (*free)(void *opaque);
> > } AVRefcount;
> > and then embed it in everything that wants to be refcounted. All just
> > normal structs and functions, no layers of macros.
>
> Because what you propose requires an extra layer of pointers, which is
> both annoying when reading and writing the code
instead of
#define AVRC_TYPE AVBuffer
#define AVRC_PREFIX prefix
#define AVRC_FIELD refcount
you'd have
av_refcount_init(>refcount, buf, buffer_free);
Does not look more annoying to me, to the contrary macro templates
require more effort to understand or debug.
> and inefficient when running it.
Why? I do not see how an extra pointer dereference could possibly matter here.
>
> Also because what you propose has void pointers, and therefore will not
> benefit from the compiler checking the types at compilation time.
In my experience, providing the wrong opaque pointer has never been a
common source of bugs (and is typically easily noticeable if it does
happen), so I see that as an acceptable tradeoff.
--
Anton Khirnov
___
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] ffprobe: Allow unknown format private AVOptions
On 30/06/2020 21:48, Marton Balint wrote: > This only logs the first skipped option. I think it is best if you > iterate through all of them. Done. v3 sent. - Derek ___ 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] libavformat/hlsenc: Remove duplicate close of the output stream.
The result of the first close attempt is ignored and may be lost. By removing
it we ensure the close result code is properly analyzed.
---
libavformat/hlsenc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 71fa3db060..88b58a1ba8 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2631,7 +2631,6 @@ static int hls_write_trailer(struct AVFormatContext *s)
goto failed;
vs->size = range_length;
-hlsenc_io_close(s, >out, filename);
ret = hlsenc_io_close(s, >out, filename);
if (ret < 0) {
av_log(s, AV_LOG_WARNING, "upload segment failed, will retry with
a new http session.\n");
--
2.25.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".
Re: [FFmpeg-devel] [PATCH 1/3] lavu: add a template for refcounted objects.
Anton Khirnov (12020-07-01):
> Why a template? It seems simpler to add a struct like
> typedef struct AVRefcount {
> atomic_uint refcount;
> void *opaque;
> void (*free)(void *opaque);
> } AVRefcount;
> and then embed it in everything that wants to be refcounted. All just
> normal structs and functions, no layers of macros.
Because what you propose requires an extra layer of pointers, which is
both annoying when reading and writing the code and inefficient when
running it.
Also because what you propose has void pointers, and therefore will not
benefit from the compiler checking the types at compilation time.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
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] lavu: add a template for refcounted objects.
Quoting Nicolas George (2020-06-27 17:16:44)
> Signed-off-by: Nicolas George
> ---
> libavutil/avrefcount_template.h | 140
> tests/ref/fate/source | 1 +
> 2 files changed, 141 insertions(+)
> create mode 100644 libavutil/avrefcount_template.h
>
>
> I will need to refcount something soon. Recently, the need to stop
> abusing AVBuffer for all refcounting was mentioned on the list. So here
> is an attempt at isolating the refcounting itself.
>
> This is not the final verion, I will first work on the "something" to
> make sure it suits the needs. But it is a first version.
>
> Anton, I would appreciate if you had a look at this and told me if there
> is something you strongly dislike about before I have piled too much
> efforts over it.
Why a template? It seems simpler to add a struct like
typedef struct AVRefcount {
atomic_uint refcount;
void *opaque;
void (*free)(void *opaque);
} AVRefcount;
and then embed it in everything that wants to be refcounted. All just
normal structs and functions, no layers of macros.
--
Anton Khirnov
___
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] lavc/aac_ac3_parser: fix the potential overflow
Quoting Jun Zhao (2020-06-29 15:23:10)
> From: Jun Zhao
>
> Fix the potential overflow.
>
> Suggested-by: Alexander Strasser
> Signed-off-by: Jun Zhao
> ---
> libavcodec/aac_ac3_parser.c | 9 +
> libavcodec/aac_ac3_parser.h | 4 ++--
> tests/ref/fate/adtstoasc_ticket3715 | 2 +-
> 3 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
> index 0746798..b26790d 100644
> --- a/libavcodec/aac_ac3_parser.c
> +++ b/libavcodec/aac_ac3_parser.c
> @@ -98,11 +98,12 @@ get_next:
> }
>
> /* Calculate the average bit rate */
> -s->frame_number++;
> if (avctx->codec_id != AV_CODEC_ID_EAC3) {
> -avctx->bit_rate =
> -(s->last_bit_rate * (s->frame_number -1) +
> s->bit_rate)/s->frame_number;
> -s->last_bit_rate = avctx->bit_rate;
> +if (s->frame_number < UINT64_MAX) {
> +s->frame_number++;
> +s->last_bit_rate += (s->bit_rate -
> s->last_bit_rate)/s->frame_number;
> +avctx->bit_rate = (int64_t)llround(s->last_bit_rate);
> +}
> }
> }
>
> diff --git a/libavcodec/aac_ac3_parser.h b/libavcodec/aac_ac3_parser.h
> index b04041f..c53d16f 100644
> --- a/libavcodec/aac_ac3_parser.h
> +++ b/libavcodec/aac_ac3_parser.h
> @@ -55,8 +55,8 @@ typedef struct AACAC3ParseContext {
> uint64_t state;
>
> int need_next_header;
> -int frame_number;
> -int last_bit_rate;
> +uint64_t frame_number;
> +double last_bit_rate;
This won't give the same result on all platforms anymore.
--
Anton Khirnov
___
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] avcodec/nvenc: Video Codec SDK 10 features support
On 30.06.2020 16:08, Roman Arzumanyan wrote: Hello, This patch adds Video Codec SDK 10 features support: * Presets and tuning info * Multipass encode modes * Low Delay Key Frame Scale Applied with some stylistic amendments and minor fixes. Thanks! We now need to figure something out to deal with the newly deprecated stuff. ___ 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 v3] fbdetile cpu based detiling of framebuffers v03
Jun 29, 2020, 18:58 by hanish...@gmail.com: > v03-20200629IST2208 fbdetile > > Added a generic detiling logic, which can be easily configured to > detile many different tiling schemes. > > The same is inturn used to detile Intel Tile-Yf layout. > > NOTE: This is a full patch, it contains the previous versions also > in it. > > v02-20200627IST2331 > > Unrolled Intel Legacy Tile-Y detiling logic. > > Also a consolidated patch file, instead of the previous development > flow based multiple patch files. > > v01-20200627IST1308 > > Implemented Intel Legacy Tile-X and Tile-Y detiling logic > > NOTES: > > This video filter allows framebuffers which are tiled to be detiled > using logic running on the cpu, into a linear layout. > > Currently it supports Intel Legacy Tile-X and Tile-Y layout detiling, > as well as the newer Intel Tile-Yf layouts. > > THis should help one to work with frames captured (say using kmsgrab) > on laptops having Intel GPU. This can be done live while capturing > itself, or it can be applied later as a seperate pass. > > Tile-X conversion logic has been explicitly cross checked, with Tile-X > based frames. However Tile-Y and Tile-Yf conv logics havent been tested > with Tile-Y | Tile-Yf based frames, but it should potentially get the > job done, based on my current understanding of these layout formats. > > TODO1: At a later time have to generate Tile-Y|Yf based frames, and then > cross check the corresponding logic explicitly. > > TODO2: May be use OpenGL or Vulcan buffer helper routines to do the > layout conversion. But some online discussions from sometime back seem > to indicate that this path is not fully bug free currently. > Still not happening, I'd like to see this done properly with hwdownload. While what you have works as a hack, we're not interested in hacks but something that works universally. As I said before, it can be easily sped up by a factor of 4 or 8 using SIMD, so its unjustifiable to have this in the codebase as a filter. ___ 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 1/3] avformat/isom: add comment to mov_mdhd_language_map
Hi Michael, > On Jul 1, 2020, at 5:27 PM, Michael Niedermayer > wrote: > > On Sat, Jun 27, 2020 at 10:26:43PM +0800, Zhao Zhili wrote: >> --- >> The following code is used to do the reformat: >> https://gist.github.com/quink-black/8643d8fab8b3f49ff6ace6916111d2c4 >> >> libavformat/isom.c | 158 +++-- >> 1 file changed, 139 insertions(+), 19 deletions(-) > > will apply Thanks! Could you help merge patch 2/3 and 3/3 too? > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Dictatorship naturally arises out of democracy, and the most aggravated > form of tyranny and slavery out of the most extreme liberty. -- Plato > ___ > 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 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] avcodec/cbs_h2645: keep separate parameter set lists for reading and writing
On 7/1/2020 6:40 AM, Michael Niedermayer wrote: > On Sun, Jun 07, 2020 at 12:45:15PM -0300, James Almer wrote: >> On 6/7/2020 12:20 PM, James Almer wrote: >>> On 6/7/2020 11:45 AM, Michael Niedermayer wrote: On Sun, Jun 07, 2020 at 10:27:37AM -0300, James Almer wrote: > Similar logic as 4e2bef6a82. In scearios where an Access Unit is written > right > after reading it using the same CBS context (hevc_metadata), the list of > parsed > parameters sets used by the writer must not be the one that's the result > of the > reader having already parsed the current Access Unit in question. > > Fixes: out of array access > Fixes: > 23034/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-5074645169733632.fuzz > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: James Almer > --- > An alternative is forcing the usage of separate CBS contexts for reading > and > writing. > > libavcodec/cbs_h264.h | 18 --- > libavcodec/cbs_h2645.c | 72 -- > libavcodec/cbs_h265.h | 26 +++ > 3 files changed, 89 insertions(+), 27 deletions(-) i think the change is probably ok and it fixes the issue what i feel uneasy about is if this is the sole way the security issue is fixed. let me try to explain what i mean by a simpler example: if you have a sprintf() that overwrites the buffer there are 3 ways to fix that A. You make the buffer big enough for what is written B. You make the amount written only as large as the buffer C. You check by using snprintf() Now like here A/B may represent a bugfix the problem with A/B is that security rests on potentially complex code So even when A/B is done, we also should do C This patch fixes the inconsistency on the write side be keeping more references to the parameter sets. For security one would have to proof that no crafted input to the reader fed into any available useer of the reader could result in an inconsistency to a writer following. Are you sure thats the case now and with future users of the code ? OTOH as dumb as a check in the writer may look, anyone can proof it fixes the specific inconsistency. What i suggest specifically is to also include or apply the simple check on top of this, or a equivalent / more generic check. So that security does not rest on alot of spread out code Thanks >>> >>> Well, one possibility is that after this, the infer() warning could be >>> replaced with an assert() instead. The CBS framework is not public, so >>> crashing with an assert() would be acceptable as infer() failing in >>> writing scenarios should be considered an internal bug (bitstream >>> filters, or any CBS user for that matter, should ensure to not change >>> fields in a way that would result in an invalid bitstream and thus >>> failing infer() checks). >>> >>> The issue shouldn't be treated as "If inter_ref_pic_set_prediction_flag >>> is 1 in this scenario, then we should stop to avoid out of array >>> access", but as "We did something wrong because >>> inter_ref_pic_set_prediction_flag was absolutely not meant to be 1 at >>> this point". So using assert() after this patch sounds like a good >>> solution and will help detect future bugs in the parsing code. >> >> It could also be a generic return AVERROR_INVALIDDATA as you suggested, >> to be fair. All the standard writing helpers abort gracefully that way, >> so infer() could do the same. >> >> Or the other helpers could be changed to assert(). > > whats the status of this ? > has this issue been fixed in some other way i missed ? I pushed the first two patches and backported them, so the issue should be fixed by the first. > will this get applied ? I delayed applying this one waiting for more opinions, especially Mark's, since it's kind of ugly. > should i apply my not so pretty fix for 23034 ? > what will be done about releases ? can this be backported ? Already answered above, but maybe confirm it's fixed just to be sure. > > PS: please just make sure 23034/ is mentioned in the commit message so > whatever fixes it can be kept track of (i know its already mentioned > this is more intended as a remainder for other alternative fixes) Ah, guess i should have mentioned that ossfuzz issue in ef13fafe22 (and e6ab99f324by extension) seeing i didn't push this one alongside it... > > thx > > [...] > > > ___ > 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 v6 3/3] avdevice/decklink_dec: export timecode with s12m side data
From: Limin Wang
Signed-off-by: Limin Wang
---
libavdevice/decklink_dec.cpp | 16
1 file changed, 16 insertions(+)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 82106aa..0fc1489 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -41,6 +41,7 @@ extern "C" {
#include "libavutil/imgutils.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/time.h"
+#include "libavutil/timecode.h"
#include "libavutil/mathematics.h"
#include "libavutil/reverse.h"
#include "avdevice.h"
@@ -778,6 +779,21 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
AVDictionary* metadata_dict = NULL;
int metadata_len;
uint8_t* packed_metadata;
+AVTimecode tcr;
+uint32_t tc_data;
+uint8_t *sd;
+int size = sizeof(uint32_t) * 4;
+
+if (av_timecode_init_from_string(,
ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
+if ((tc_data =
av_timecode_get_smpte_from_framenum(, 0)) > 0) {
+sd = av_packet_new_side_data(,
AV_PKT_DATA_S12M_TIMECODE, size);
+if (sd) {
+AV_WL32(sd, 1); // one TC ;
+AV_WL32(sd + 4, tc_data); // TC;
+}
+}
+}
+
if (av_dict_set(_dict, "timecode", tc,
AV_DICT_DONT_STRDUP_VAL) >= 0) {
packed_metadata =
av_packet_pack_dictionary(metadata_dict, _len);
av_dict_free(_dict);
--
1.8.3.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".
[FFmpeg-devel] [PATCH v6 1/3] avutil/timecode: add description for SMPTE binary format
From: Limin Wang
Signed-off-by: Limin Wang
---
libavutil/frame.h| 4 ++--
libavutil/timecode.h | 12
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 3fb8c56..3bd240f 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -162,8 +162,8 @@ enum AVFrameSideDataType {
/**
* Timecode which conforms to SMPTE ST 12-1. The data is an array of 4
uint32_t
* where the first uint32_t describes how many (1-3) of the other
timecodes are used.
- * The timecode format is described in the
av_timecode_get_smpte_from_framenum()
- * function in libavutil/timecode.c.
+ * The timecode format is described in the documentation of
av_timecode_get_smpte_from_framenum()
+ * function in libavutil/timecode.h.
*/
AV_FRAME_DATA_S12M_TIMECODE,
diff --git a/libavutil/timecode.h b/libavutil/timecode.h
index ab38e66..65c5e91 100644
--- a/libavutil/timecode.h
+++ b/libavutil/timecode.h
@@ -62,6 +62,18 @@ int av_timecode_adjust_ntsc_framenum2(int framenum, int fps);
* @param framenum frame number
* @return the SMPTE binary representation
*
+ * the format description as follows:
+ * bits 0-5: hours, in BCD
+ * bits 6: BGF1
+ * bits 7: BGF2 (NTSC) or PC (PAL)
+ * bits 8-13: minutes, in BCD
+ * bits 15:BGF0 (NTSC) or BGF2 (PAL)
+ * bits 16-21: seconds, in BCD
+ * bits 23:PC (NTSC) or BGF0 (PAL)
+ * bits 24-29: frames, in BCD
+ * bits 30:drop frame flag (0: non drop,1: drop)
+ * bits 31:color frame flag (0: unsync mode, 1: sync mode)
+ * @note BCD numbers (6 bits): 4 lower bits for units, 2 higher bits for tens.
* @note Frame number adjustment is automatically done in case of drop
timecode,
* you do NOT have to call av_timecode_adjust_ntsc_framenum2().
* @note The frame number is relative to tc->start.
--
1.8.3.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".
[FFmpeg-devel] [PATCH v6 2/3] API: add AV_PKT_DATA_S12M_TIMECODE to AVPacketSideDataType
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/APIchanges| 3 +++
libavcodec/avpacket.c | 1 +
libavcodec/decode.c | 1 +
libavcodec/packet.h | 8
libavcodec/version.h | 2 +-
libavformat/dump.c| 21 +
6 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 1d6cc36..7aa8d9e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2020-06-xx - xx - lavc 58.94.101 - packet.h
+ Add AV_PKT_DATA_S12M_TIMECODE.
+
2020-06-12 - b09fb030c1 - lavu 56.55.100 - pixdesc.h
Add AV_PIX_FMT_X2RGB10.
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index dce26cb..4801163 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -400,6 +400,7 @@ const char *av_packet_side_data_name(enum
AVPacketSideDataType type)
case AV_PKT_DATA_PRFT: return "Producer Reference
Time";
case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
case AV_PKT_DATA_DOVI_CONF: return "DOVI configuration
record";
+case AV_PKT_DATA_S12M_TIMECODE: return "SMPTE ST 12-1:2014
timecode";
}
return NULL;
}
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index de9c079..f2244fc 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1699,6 +1699,7 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame
*frame)
{ AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
{ AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
{ AV_PKT_DATA_ICC_PROFILE,AV_FRAME_DATA_ICC_PROFILE },
+{ AV_PKT_DATA_S12M_TIMECODE, AV_FRAME_DATA_S12M_TIMECODE
},
};
if (pkt) {
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index 96f237f..0a19a0e 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -283,6 +283,14 @@ enum AVPacketSideDataType {
AV_PKT_DATA_DOVI_CONF,
/**
+ * Timecode which conforms to SMPTE ST 12-1:2014. The data is an array of
4 uint32_t
+ * where the first uint32_t describes how many (1-3) of the other
timecodes are used.
+ * The timecode format is described in the documentation of
av_timecode_get_smpte_from_framenum()
+ * function in libavutil/timecode.h.
+ */
+AV_PKT_DATA_S12M_TIMECODE,
+
+/**
* The number of side data types.
* This is not part of the public API/ABI in the sense that it may
* change when new side data types are added.
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 05f5990..51fba22 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
#include "libavutil/version.h"
#define LIBAVCODEC_VERSION_MAJOR 58
-#define LIBAVCODEC_VERSION_MINOR 93
+#define LIBAVCODEC_VERSION_MINOR 94
#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 1083d7d..46db039 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -34,6 +34,7 @@
#include "libavutil/replaygain.h"
#include "libavutil/spherical.h"
#include "libavutil/stereo3d.h"
+#include "libavutil/timecode.h"
#include "avformat.h"
@@ -407,6 +408,22 @@ static void dump_dovi_conf(void *ctx, const
AVPacketSideData *sd)
dovi->dv_bl_signal_compatibility_id);
}
+static void dump_s12m_timecode(void *ctx, const AVPacketSideData *sd)
+{
+const uint32_t *tc = (const uint32_t *)sd->data;
+
+if ((sd->size != sizeof(uint32_t) * 4) || (tc[0] > 3)) {
+av_log(ctx, AV_LOG_ERROR, "invalid data\n");
+return;
+}
+
+for (int j = 1; j <= tc[0]; j++) {
+char tcbuf[AV_TIMECODE_STR_SIZE];
+av_timecode_make_smpte_tc_string(tcbuf, tc[j], 0);
+av_log(ctx, AV_LOG_INFO, "timecode - %s%s", tcbuf, j != tc[0] ? ", " :
"");
+}
+}
+
static void dump_sidedata(void *ctx, const AVStream *st, const char *indent)
{
int i;
@@ -473,6 +490,10 @@ static void dump_sidedata(void *ctx, const AVStream *st,
const char *indent)
av_log(ctx, AV_LOG_INFO, "DOVI configuration record: ");
dump_dovi_conf(ctx, sd);
break;
+case AV_PKT_DATA_S12M_TIMECODE:
+av_log(ctx, AV_LOG_INFO, "SMPTE ST 12-1:2014: ");
+dump_s12m_timecode(ctx, sd);
+break;
default:
av_log(ctx, AV_LOG_INFO,
"unknown side data type %d (%d bytes)", sd->type, sd->size);
--
1.8.3.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".
Re: [FFmpeg-devel] [PATCH v6 1/2] libavcodec/pgxdec: Add PGX decoder
gautamr...@gmail.com (12020-06-30):
> From: Gautam Ramakrishnan
>
> This patch adds a pgx decoder.
> ---
> Changelog | 1 +
> doc/general.texi| 2 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/codec_desc.c | 7 ++
> libavcodec/codec_id.h | 1 +
> libavcodec/pgxdec.c | 199
> libavcodec/version.h| 2 +-
> 8 files changed, 213 insertions(+), 1 deletion(-)
> create mode 100644 libavcodec/pgxdec.c
>
> diff --git a/Changelog b/Changelog
> index a60e7d2eb8..1bb9931c0d 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest.
> version :
> - AudioToolbox output device
> - MacCaption demuxer
> +- PGX decoder
>
>
> version 4.3:
> diff --git a/doc/general.texi b/doc/general.texi
> index ea34b963b5..53d556c56c 100644
> --- a/doc/general.texi
> +++ b/doc/general.texi
> @@ -751,6 +751,8 @@ following image formats are supported:
> @tab Portable GrayMap image
> @item PGMYUV @tab X @tab X
> @tab PGM with U and V components in YUV 4:2:0
> +@item PGX @tab @tab X
> +@tab PGX file decoder
> @item PIC @tab @tab X
> @tab Pictor/PC Paint
> @item PNG @tab X @tab X
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 5a6ea59715..12aa43fe51 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -536,6 +536,7 @@ OBJS-$(CONFIG_PGM_ENCODER) += pnmenc.o
> OBJS-$(CONFIG_PGMYUV_DECODER) += pnmdec.o pnm.o
> OBJS-$(CONFIG_PGMYUV_ENCODER) += pnmenc.o
> OBJS-$(CONFIG_PGSSUB_DECODER) += pgssubdec.o
> +OBJS-$(CONFIG_PGX_DECODER) += pgxdec.o
> OBJS-$(CONFIG_PICTOR_DECODER) += pictordec.o cga_data.o
> OBJS-$(CONFIG_PIXLET_DECODER) += pixlet.o
> OBJS-$(CONFIG_PJS_DECODER) += textdec.o ass.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index fa0c08d42e..a5048290f7 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -238,6 +238,7 @@ extern AVCodec ff_pgm_encoder;
> extern AVCodec ff_pgm_decoder;
> extern AVCodec ff_pgmyuv_encoder;
> extern AVCodec ff_pgmyuv_decoder;
> +extern AVCodec ff_pgx_decoder;
> extern AVCodec ff_pictor_decoder;
> extern AVCodec ff_pixlet_decoder;
> extern AVCodec ff_png_encoder;
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 9f8847544f..67e0a3055c 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1405,6 +1405,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
> .long_name = NULL_IF_CONFIG_SMALL("AVS2-P2/IEEE1857.4"),
> .props = AV_CODEC_PROP_LOSSY,
> },
> +{
> +.id= AV_CODEC_ID_PGX,
> +.type = AVMEDIA_TYPE_VIDEO,
> +.name = "pgx",
> +.long_name = NULL_IF_CONFIG_SMALL("PGX (JPEG2000 Test Format)"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
> +},
> {
> .id= AV_CODEC_ID_Y41P,
> .type = AVMEDIA_TYPE_VIDEO,
> diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
> index d885962c9c..896ecb0ce0 100644
> --- a/libavcodec/codec_id.h
> +++ b/libavcodec/codec_id.h
> @@ -241,6 +241,7 @@ enum AVCodecID {
> AV_CODEC_ID_SCREENPRESSO,
> AV_CODEC_ID_RSCC,
> AV_CODEC_ID_AVS2,
> +AV_CODEC_ID_PGX,
>
> AV_CODEC_ID_Y41P = 0x8000,
> AV_CODEC_ID_AVRP,
> diff --git a/libavcodec/pgxdec.c b/libavcodec/pgxdec.c
> new file mode 100644
> index 00..c9e07c1e55
> --- /dev/null
> +++ b/libavcodec/pgxdec.c
> @@ -0,0 +1,199 @@
> +/*
> + * PGX image format
> + * Copyright (c) 2020 Gautam Ramakrishnan
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "avcodec.h"
> +#include "internal.h"
> +#include "bytestream.h"
> +#include "libavutil/imgutils.h"
> +
> +typedef struct PGXContext {
> +GetByteContext g;
Double space.
And this gets inited for each frame: it could be a local variable too.
Or even better: get rid of the GetByteContext entirely: the way you use
it, it brings no benefit at all.
> +} PGXContext;
> +
> +static int
Re: [FFmpeg-devel] [PATCH] Ticket #8750 Add inline function for the vec_xl intrinsic in non-VSX environments
ffmpeg_altivec_yuv2rgb_novsx.patch Description: Binary data ___ 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] avcodec/cbs_h2645: keep separate parameter set lists for reading and writing
James Almer: > Similar logic as 4e2bef6a82. In scearios where an Access Unit is written right > after reading it using the same CBS context (hevc_metadata), the list of > parsed > parameters sets used by the writer must not be the one that's the result of > the > reader having already parsed the current Access Unit in question. > > Fixes: out of array access > Fixes: > 23034/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-5074645169733632.fuzz > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: James Almer > --- > An alternative is forcing the usage of separate CBS contexts for reading and > writing. > Am I the only one who thinks this would be cleaner, as it would directly show to the user that there are two separate states involved? It would also lead to a smaller diff. - Andreas ___ 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 2/2] libavfilter/vf_colorconstancy.c : Adding weighted greyedge
> > If you are setting initial estimation to normal white, does it make any >> difference to do a chromatic adaptation? >> > I was trying to reproduce the same values as the official code in matlab > and hence this was done. > It might provide a very minor improvement in speed but having an estimate > beforehand might help converge faster. > I would update the next patch with chromatic adaptation. > Sorry, I kind of misread this part while replying earlier. I was following the algorithm which was laid out in the paper which does chromatic adaptation as the first step in the loop. So according to the algorithm it first performs correction based on the initial estimate and then calculates the weights and new value of estimated light. > ___ 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 2/4] avutil/avsscanf: Add () to avoid integer overflow in scanexp()
On Thu, Jun 18, 2020 at 02:20:24PM +0200, Michael Niedermayer wrote: > Fixes: signed integer overflow: 2147483610 + 52 cannot be represented in type > 'int' > Fixes: > 23260/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PBM_fuzzer-5187871274434560 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavutil/avsscanf.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: PGP signature ___ 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] avcodec/cbs_h2645: keep separate parameter set lists for reading and writing
On Sun, Jun 07, 2020 at 12:45:15PM -0300, James Almer wrote: > On 6/7/2020 12:20 PM, James Almer wrote: > > On 6/7/2020 11:45 AM, Michael Niedermayer wrote: > >> On Sun, Jun 07, 2020 at 10:27:37AM -0300, James Almer wrote: > >>> Similar logic as 4e2bef6a82. In scearios where an Access Unit is written > >>> right > >>> after reading it using the same CBS context (hevc_metadata), the list of > >>> parsed > >>> parameters sets used by the writer must not be the one that's the result > >>> of the > >>> reader having already parsed the current Access Unit in question. > >>> > >>> Fixes: out of array access > >>> Fixes: > >>> 23034/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-5074645169733632.fuzz > >>> > >>> Found-by: continuous fuzzing process > >>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > >>> Signed-off-by: James Almer > >>> --- > >>> An alternative is forcing the usage of separate CBS contexts for reading > >>> and > >>> writing. > >>> > >>> libavcodec/cbs_h264.h | 18 --- > >>> libavcodec/cbs_h2645.c | 72 -- > >>> libavcodec/cbs_h265.h | 26 +++ > >>> 3 files changed, 89 insertions(+), 27 deletions(-) > >> > >> i think the change is probably ok and it fixes the issue > >> what i feel uneasy about is if this is the sole way the security > >> issue is fixed. > >> > >> let me try to explain what i mean by a simpler example: > >> if you have a sprintf() that overwrites the buffer there are 3 ways > >> to fix that > >> A. You make the buffer big enough for what is written > >> B. You make the amount written only as large as the buffer > >> C. You check by using snprintf() > >> > >> Now like here A/B may represent a bugfix > >> the problem with A/B is that security rests on potentially complex code > >> So even when A/B is done, we also should do C > >> > >> This patch fixes the inconsistency on the write side be keeping more > >> references > >> to the parameter sets. > >> For security one would have to proof that no crafted input to the reader > >> fed into any available useer of the reader could result in an inconsistency > >> to a writer following. > >> Are you sure thats the case now and with future users of the code ? > >> OTOH as dumb as a check in the writer may look, anyone can proof it fixes > >> the > >> specific inconsistency. > >> > >> What i suggest specifically is to also include or apply the simple check > >> on top of this, or a equivalent / more generic check. So that security > >> does not > >> rest on alot of spread out code > >> > >> Thanks > > > > Well, one possibility is that after this, the infer() warning could be > > replaced with an assert() instead. The CBS framework is not public, so > > crashing with an assert() would be acceptable as infer() failing in > > writing scenarios should be considered an internal bug (bitstream > > filters, or any CBS user for that matter, should ensure to not change > > fields in a way that would result in an invalid bitstream and thus > > failing infer() checks). > > > > The issue shouldn't be treated as "If inter_ref_pic_set_prediction_flag > > is 1 in this scenario, then we should stop to avoid out of array > > access", but as "We did something wrong because > > inter_ref_pic_set_prediction_flag was absolutely not meant to be 1 at > > this point". So using assert() after this patch sounds like a good > > solution and will help detect future bugs in the parsing code. > > It could also be a generic return AVERROR_INVALIDDATA as you suggested, > to be fair. All the standard writing helpers abort gracefully that way, > so infer() could do the same. > > Or the other helpers could be changed to assert(). whats the status of this ? has this issue been fixed in some other way i missed ? will this get applied ? should i apply my not so pretty fix for 23034 ? what will be done about releases ? can this be backported ? PS: please just make sure 23034/ is mentioned in the commit message so whatever fixes it can be kept track of (i know its already mentioned this is more intended as a remainder for other alternative fixes) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org 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/utils: reorder duration computation to avoid overflow
On Sun, Jun 21, 2020 at 07:07:53PM +0200, Michael Niedermayer wrote: > Fixes: signed integer overflow: 8 * 9223372036854774783 cannot be represented > in type 'long' > Fixes: > 23381/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4818340509122560 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/utils.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org 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] avcodec/pngdec: Check for fctl after idat
On Thu, Jun 25, 2020 at 08:13:08PM +0200, Michael Niedermayer wrote: > Fixes: out of array access > Fixes: > 23554/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APNG_fuzzer-4796622520451072.fuzz > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/pngdec.c | 5 + > 1 file changed, 5 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: PGP signature ___ 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/hls: Pass a copy of the URL for probing
On Mon, Jun 29, 2020 at 09:18:18PM +0200, Michael Niedermayer wrote:
> On Mon, Jun 29, 2020 at 09:08:07PM +0200, Andreas Rheinhardt wrote:
> > Michael Niedermayer:
> > > The segments / url can be modified by the io read when reloading
> > >
> > > This may be an alternative or additional fix for Ticket8673
> > > as a further alternative the reload stuff could be disabled during
> > > probing
> > >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavformat/hls.c | 6 --
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > > index 3798bdd5d1..ba17c4ed96 100644
> > > --- a/libavformat/hls.c
> > > +++ b/libavformat/hls.c
> > > @@ -1946,6 +1946,7 @@ static int hls_read_header(AVFormatContext *s)
> > > /* Open the demuxer for each playlist */
> > > for (i = 0; i < c->n_playlists; i++) {
> > > struct playlist *pls = c->playlists[i];
> > > +char *url;
> > > ff_const59 AVInputFormat *in_fmt = NULL;
> > >
> > > if (!(pls->ctx = avformat_alloc_context())) {
> > > @@ -1983,8 +1984,9 @@ static int hls_read_header(AVFormatContext *s)
> > >read_data, NULL, NULL);
> > > pls->ctx->probesize = s->probesize > 0 ? s->probesize : 1024 * 4;
> > > pls->ctx->max_analyze_duration = s->max_analyze_duration > 0 ?
> > > s->max_analyze_duration : 4 * AV_TIME_BASE;
> > > -ret = av_probe_input_buffer(>pb, _fmt,
> > > pls->segments[0]->url,
> > > -NULL, 0, 0);
> > > +url = av_strdup(pls->segments[0]->url);
> > > +ret = av_probe_input_buffer(>pb, _fmt, url, NULL, 0, 0);
> > > +av_free(url);
> > > if (ret < 0) {
> > > /* Free the ctx - it isn't initialized properly at this
> > > point,
> > > * so avformat_close_input shouldn't be called. If
> > >
> > Is the missing allocation check intentional?
>
> i thought if it fails filename is NULL and the code could still
> plausibly continue.
> but we can also fail or warn if people prefer
will apply this as i think this makes the fix for a public CVE more
robust
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
signature.asc
Description: PGP signature
___
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 v3] avdevice/xcbgrab: Add select_region option
This patch adds a select_region option to the xcbgrab input device.
If set to 1, the user will be prompted to select the grabbing area
graphically by clicking and dragging. A rectangle will be drawn to
mark the grabbing area. A single click with no dragging will select
the whole screen. The option overwrites the video_size, grab_x, and
grab_y options if set by the user.
For testing, just set the select_region option as follows:
ffmpeg -f x11grab -select_region 1 -i :0.0 output.mp4
The drawing happens directly on the root window using standard rubber
banding techniques, so it is very efficient and doesn't depend on any
X extensions or compositors.
Signed-off-by: Omar Emara
---
doc/indevs.texi | 7 +++
libavdevice/xcbgrab.c | 110 ++
2 files changed, 117 insertions(+)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 6f5afaf344..b5df111801 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -1478,6 +1478,13 @@ ffmpeg -f x11grab -framerate 25 -video_size cif -i
:0.0+10,20 out.mpg
@subsection Options
@table @option
+@item select_region
+Specify whether to select the grabbing area graphically using the pointer.
+A value of @code{1} prompts the user to select the grabbing area graphically
+by clicking and dragging. A single click with no dragging will select the
+whole screen. This option overwrites the @var{video_size}, @var{grab_x},
+and @var{grab_y} options. Default value is @code{0}.
+
@item draw_mouse
Specify whether to draw the mouse pointer. A value of @code{0} specifies
not to draw the pointer. Default value is @code{1}.
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index 6f6b2dbf15..1e7d5ab000 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -22,6 +22,7 @@
#include "config.h"
#include
+#include
#include
#if CONFIG_LIBXCB_XFIXES
@@ -69,6 +70,7 @@ typedef struct XCBGrabContext {
int show_region;
int region_border;
int centered;
+int select_region;
const char *framerate;
@@ -92,6 +94,7 @@ static const AVOption options[] = {
{ "centered", "Keep the mouse pointer at the center of grabbing region
when following.", 0, AV_OPT_TYPE_CONST, { .i64 = -1 }, INT_MIN, INT_MAX, D,
"follow_mouse" },
{ "show_region", "Show the grabbing region.", OFFSET(show_region),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
{ "region_border", "Set the region border thickness.",
OFFSET(region_border), AV_OPT_TYPE_INT, { .i64 = 3 }, 1, 128, D },
+{ "select_region", "Select the grabbing region graphically using the
pointer.", OFFSET(select_region), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
{ NULL },
};
@@ -668,6 +671,100 @@ static void setup_window(AVFormatContext *s)
draw_rectangle(s);
}
+#define CROSSHAIR_CURSOR 34
+
+static xcb_rectangle_t rectangle_from_corners(xcb_point_t *corner_a,
+ xcb_point_t *corner_b) {
+xcb_rectangle_t rectangle;
+rectangle.x = FFMIN(corner_a->x, corner_b->x);
+rectangle.y = FFMIN(corner_a->y, corner_b->y);
+rectangle.width = FFABS(corner_a->x - corner_b->x);
+rectangle.height = FFABS(corner_a->y - corner_b->y);
+return rectangle;
+}
+
+static xcb_rectangle_t select_region(xcb_connection_t *connection,
+ xcb_screen_t *screen) {
+int done = 0;
+int was_pressed = 0;
+xcb_cursor_t cursor;
+xcb_font_t cursor_font;
+xcb_point_t press_position;
+xcb_generic_event_t *event;
+xcb_rectangle_t old_rectangle = {0};
+
+xcb_window_t root_window = screen->root;
+xcb_gcontext_t gc = xcb_generate_id(connection);
+uint32_t mask = XCB_GC_FUNCTION | XCB_GC_SUBWINDOW_MODE;
+uint32_t values[] = {XCB_GX_INVERT,
+ XCB_SUBWINDOW_MODE_INCLUDE_INFERIORS};
+xcb_create_gc(connection, gc, root_window, mask, values);
+
+cursor_font = xcb_generate_id(connection);
+xcb_open_font(connection, cursor_font, strlen("cursor"), "cursor");
+cursor = xcb_generate_id(connection);
+xcb_create_glyph_cursor(connection, cursor, cursor_font, cursor_font,
+CROSSHAIR_CURSOR, CROSSHAIR_CURSOR + 1, 0, 0, 0,
+0x, 0x, 0x);
+xcb_grab_pointer(connection, 0, root_window,
+ XCB_EVENT_MASK_BUTTON_PRESS |
+ XCB_EVENT_MASK_BUTTON_RELEASE |
+ XCB_EVENT_MASK_BUTTON_MOTION,
+ XCB_GRAB_MODE_ASYNC, XCB_GRAB_MODE_ASYNC,
+ root_window, cursor, XCB_CURRENT_TIME);
+xcb_grab_server(connection);
+xcb_flush(connection);
+
+while ((event = xcb_wait_for_event(connection))) {
+switch (event->response_type & ~0x80) {
+case XCB_BUTTON_PRESS: {
+xcb_button_press_event_t *press = (xcb_button_press_event_t
*)event;
+press_position = (xcb_point_t){press->event_x, press->event_y};
+
Re: [FFmpeg-devel] [PATCH v2 1/3] avformat/isom: add comment to mov_mdhd_language_map
On Sat, Jun 27, 2020 at 10:26:43PM +0800, Zhao Zhili wrote: > --- > The following code is used to do the reformat: > https://gist.github.com/quink-black/8643d8fab8b3f49ff6ace6916111d2c4 > > libavformat/isom.c | 158 +++-- > 1 file changed, 139 insertions(+), 19 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ 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 v6 1/2] libavcodec/pgxdec: Add PGX decoder
On Tue, Jun 30, 2020 at 07:23:46PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> This patch adds a pgx decoder.
> ---
> Changelog | 1 +
> doc/general.texi| 2 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/codec_desc.c | 7 ++
> libavcodec/codec_id.h | 1 +
> libavcodec/pgxdec.c | 199
> libavcodec/version.h| 2 +-
> 8 files changed, 213 insertions(+), 1 deletion(-)
> create mode 100644 libavcodec/pgxdec.c
>
> diff --git a/Changelog b/Changelog
> index a60e7d2eb8..1bb9931c0d 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest.
> version :
> - AudioToolbox output device
> - MacCaption demuxer
> +- PGX decoder
>
>
> version 4.3:
> diff --git a/doc/general.texi b/doc/general.texi
> index ea34b963b5..53d556c56c 100644
> --- a/doc/general.texi
> +++ b/doc/general.texi
> @@ -751,6 +751,8 @@ following image formats are supported:
> @tab Portable GrayMap image
> @item PGMYUV @tab X @tab X
> @tab PGM with U and V components in YUV 4:2:0
> +@item PGX @tab @tab X
> +@tab PGX file decoder
> @item PIC @tab @tab X
> @tab Pictor/PC Paint
> @item PNG @tab X @tab X
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 5a6ea59715..12aa43fe51 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -536,6 +536,7 @@ OBJS-$(CONFIG_PGM_ENCODER) += pnmenc.o
> OBJS-$(CONFIG_PGMYUV_DECODER) += pnmdec.o pnm.o
> OBJS-$(CONFIG_PGMYUV_ENCODER) += pnmenc.o
> OBJS-$(CONFIG_PGSSUB_DECODER) += pgssubdec.o
> +OBJS-$(CONFIG_PGX_DECODER) += pgxdec.o
> OBJS-$(CONFIG_PICTOR_DECODER) += pictordec.o cga_data.o
> OBJS-$(CONFIG_PIXLET_DECODER) += pixlet.o
> OBJS-$(CONFIG_PJS_DECODER) += textdec.o ass.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index fa0c08d42e..a5048290f7 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -238,6 +238,7 @@ extern AVCodec ff_pgm_encoder;
> extern AVCodec ff_pgm_decoder;
> extern AVCodec ff_pgmyuv_encoder;
> extern AVCodec ff_pgmyuv_decoder;
> +extern AVCodec ff_pgx_decoder;
> extern AVCodec ff_pictor_decoder;
> extern AVCodec ff_pixlet_decoder;
> extern AVCodec ff_png_encoder;
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 9f8847544f..67e0a3055c 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1405,6 +1405,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
> .long_name = NULL_IF_CONFIG_SMALL("AVS2-P2/IEEE1857.4"),
> .props = AV_CODEC_PROP_LOSSY,
> },
> +{
> +.id= AV_CODEC_ID_PGX,
> +.type = AVMEDIA_TYPE_VIDEO,
> +.name = "pgx",
> +.long_name = NULL_IF_CONFIG_SMALL("PGX (JPEG2000 Test Format)"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
> +},
> {
> .id= AV_CODEC_ID_Y41P,
> .type = AVMEDIA_TYPE_VIDEO,
> diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
> index d885962c9c..896ecb0ce0 100644
> --- a/libavcodec/codec_id.h
> +++ b/libavcodec/codec_id.h
> @@ -241,6 +241,7 @@ enum AVCodecID {
> AV_CODEC_ID_SCREENPRESSO,
> AV_CODEC_ID_RSCC,
> AV_CODEC_ID_AVS2,
> +AV_CODEC_ID_PGX,
>
> AV_CODEC_ID_Y41P = 0x8000,
> AV_CODEC_ID_AVRP,
> diff --git a/libavcodec/pgxdec.c b/libavcodec/pgxdec.c
> new file mode 100644
> index 00..c9e07c1e55
> --- /dev/null
> +++ b/libavcodec/pgxdec.c
> @@ -0,0 +1,199 @@
> +/*
> + * PGX image format
> + * Copyright (c) 2020 Gautam Ramakrishnan
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "avcodec.h"
> +#include "internal.h"
> +#include "bytestream.h"
> +#include "libavutil/imgutils.h"
> +
> +typedef struct PGXContext {
> +GetByteContext g;
> +} PGXContext;
> +
> +static int pgx_get_number(AVCodecContext *avctx, PGXContext * const s) {
> +int ret = -1;
> +char digit;
> +
> +while (1) {
> +uint64_t temp;
> +if
Re: [FFmpeg-devel] [PATCH v2] avdevice/xcbgrab: Add select_region option.
Hi Andriy, > > > +#include > > this include is not used > The string.h include is needed by the strlen function. Is it not? ___ 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".
