Re: [FFmpeg-devel] [PATCH] Fixing rare dshow input crash
Good catch. Or maybe this? diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c index d7f5bd7..96e4374 100644 --- a/libavdevice/dshow.c +++ b/libavdevice/dshow.c @@ -453,6 +453,7 @@ next: if (type->pbFormat) CoTaskMemFree(type->pbFormat); CoTaskMemFree(type); +type = NULL; } end: IAMStreamConfig_Release(config); On Thu, Sep 5, 2019 at 2:56 PM Alexey Potakhov wrote: > > re-sending without tabs. > > On Wed, Sep 4, 2019 at 6:22 PM Carl Eugen Hoyos wrote: > > > > Am Do., 5. Sept. 2019 um 00:08 Uhr schrieb Alexey Potakhov > > : > > > > > In some rare cases when IAMStreamConfig_GetStreamCaps returns > > > an error avformat_open_input() crashes with access violation. > > > > Tabs are rejected by our repository, please remove them and resend. > > > > 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". > ___ > 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] Fixing rare dshow input crash
Please incorporate this change in previous bigger patch. It is ready for merge. On 1/29/20, Roger Pack wrote: > Good catch. > Or maybe this? > > diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c > index d7f5bd7..96e4374 100644 > --- a/libavdevice/dshow.c > +++ b/libavdevice/dshow.c > @@ -453,6 +453,7 @@ next: > if (type->pbFormat) > CoTaskMemFree(type->pbFormat); > CoTaskMemFree(type); > +type = NULL; > } > end: > IAMStreamConfig_Release(config); > > On Thu, Sep 5, 2019 at 2:56 PM Alexey Potakhov wrote: >> >> re-sending without tabs. >> >> On Wed, Sep 4, 2019 at 6:22 PM Carl Eugen Hoyos >> wrote: >> > >> > Am Do., 5. Sept. 2019 um 00:08 Uhr schrieb Alexey Potakhov >> > : >> > >> > > In some rare cases when IAMStreamConfig_GetStreamCaps returns >> > > an error avformat_open_input() crashes with access violation. >> > >> > Tabs are rejected by our repository, please remove them and resend. >> > >> > 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". >> ___ >> 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 mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add xfade filter
Will apply with some small improvements. ___ 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 02/13] lavc/ass: add support for configuring default style via AVOptions
On Tue, Jan 28, 2020 at 22:42:33 -0600, rcombs wrote:
> > You're inverting the "leftmost" 8 bits of c? Can't you just make this
> > return (c ^ 0xff00);
> > ? Even inline, or just a macro? (Or perhaps I'm missing something, and
> > (255 - a) is not always the same as (a ^ 0xff).
>
> These are indeed equivalent, but I thought this more clearly conveyed
> the intent here ("convert between 0=transparent and 0=opaque by
> inverting the 0-255 alpha field").
Whatever is more clear to you. ;) I though it overcomplicated the whole
process, but perhaps it doesn't matter (I don't decide whether it
does).
> > To make this more readable, you should also MACROify the "offsetof(cls,
> > obj.X)", as many other options sections do it, and perhaps align the
> > entries' columns.
>
> I shied away from this to avoid polluting the global macro space
> (since this is in a header); I can do it anyway if you prefer (it's
> not like it's a public header, at least).
As you write, it's not global space. Anyway, I recall seeing such
macros (for multiple use of options structs) in the actual
implementation (*.c), not the declaration. If that reduces your clutter
concern.
Cheers,
looking forward to other proper reviews of your contributions ;-)
Moritz
___
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] avformat/tty: add probe function
Signed-off-by: Paul B Mahol
---
libavformat/tty.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/libavformat/tty.c b/libavformat/tty.c
index 8d48f2c45c..60f7e9f87e 100644
--- a/libavformat/tty.c
+++ b/libavformat/tty.c
@@ -34,6 +34,13 @@
#include "internal.h"
#include "sauce.h"
+static int isansicode(int x)
+{
+return x == 0x1B || x == 0x0A || x == 0x0D || (x >= 0x20 && x < 0x7f);
+}
+
+static const char tty_extensions[31] = "ans,art,asc,diz,ice,nfo,txt,vt";
+
typedef struct TtyDemuxContext {
AVClass *class;
int chars_per_frame;
@@ -42,6 +49,17 @@ typedef struct TtyDemuxContext {
AVRational framerate; /**< Set by a private option. */
} TtyDemuxContext;
+static int read_probe(const AVProbeData *p)
+{
+int cnt = 0;
+
+for (int i = 0; i < p->buf_size; i++)
+cnt += !!isansicode(p->buf[i]);
+
+return (cnt * 100LL / p->buf_size) * (cnt > 400) *
+!!av_match_ext(p->filename, tty_extensions);
+}
+
/**
* Parse EFI header
*/
@@ -153,8 +171,9 @@ AVInputFormat ff_tty_demuxer = {
.name = "tty",
.long_name = NULL_IF_CONFIG_SMALL("Tele-typewriter"),
.priv_data_size = sizeof(TtyDemuxContext),
+.read_probe = read_probe,
.read_header= read_header,
.read_packet= read_packet,
-.extensions = "ans,art,asc,diz,ice,nfo,txt,vt",
+.extensions = tty_extensions,
.priv_class = &tty_demuxer_class,
};
--
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/5] avformat/format: add av_find_input_format2
Quoting Gyan Doshi (2020-01-28 08:44:42) > Identifies demuxer by extension if search by short name fails. > --- > libavformat/avformat.h | 7 +++ > libavformat/format.c | 14 +- > libavformat/version.h | 2 +- > 3 files changed, 21 insertions(+), 2 deletions(-) > > diff --git a/libavformat/avformat.h b/libavformat/avformat.h > index 9b9b634ec3..c81c4f18fd 100644 > --- a/libavformat/avformat.h > +++ b/libavformat/avformat.h > @@ -2246,6 +2246,13 @@ ff_const59 AVInputFormat *av_find_input_format(const > char *short_name); > */ > ff_const59 AVInputFormat *av_probe_input_format(ff_const59 AVProbeData *pd, > int is_opened); > > +/** > + * Find AVInputFormat based on the short name of the input format. > + * If that fails and as_extension is set, find demuxer which has registered > the > + * name as an extension. > + */ > +ff_const59 AVInputFormat *av_find_input_format2(const char *short_name, int > as_extension); This seems rather ad-hoc to me. I think it'd be cleaner to have a dedicated function just for matching by extension. It could be called av_demuxer_find_by_ext() for consistency with av_demuxer_iterate(). -- 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".
[FFmpeg-devel] [PATCH v4] avfilter/vf_zoompan: fix shaking when zooming
Fix shaking of image when zoom is applied by the zoompan filter.
Resolves ticket https://trac.ffmpeg.org/ticket/4298
---
Fixed a typo/bug where dy was dx. Removed request for oversized frame from
filter, instead allocate
internal frame and copy contents to out frame once dimensions are correct.
libavfilter/vf_zoompan.c | 109 +--
1 file changed, 82 insertions(+), 27 deletions(-)
diff --git a/libavfilter/vf_zoompan.c b/libavfilter/vf_zoompan.c
index 59c9b19ec8..e18f9c8d1b 100644
--- a/libavfilter/vf_zoompan.c
+++ b/libavfilter/vf_zoompan.c
@@ -150,16 +150,30 @@ static int config_output(AVFilterLink *outlink)
return 0;
}
+/**
+ * Scales n to the next number divisible by 2 * 2^log_grid_size but minimally
n + 2 * 2^log_grid_size.
+ *
+ * Used to scale the width and height of a frame to fit with the subsampling
grid.
+ * @param n The number to be scaled.
+ * @param log_grid_size log 2 of the gridsize.
+ * @return The next number divisible by 2 * 2^log_grid_size but minimally n +
2 * 2^log_grid_size
+ */
+static int scale_to_grid(int n, uint8_t log2_grid_size)
+{
+return (((n + (1 << log2_grid_size) * 2) & ~((1 << log2_grid_size) - 1)) +
1) & ~1;;
+}
+
static int output_single_frame(AVFilterContext *ctx, AVFrame *in, double
*var_values, int i,
double *zoom, double *dx, double *dy)
{
ZPContext *s = ctx->priv;
AVFilterLink *outlink = ctx->outputs[0];
int64_t pts = s->frame_count;
-int k, x, y, w, h, ret = 0;
+int k, x, y, crop_x, crop_y, w, h, crop_w, crop_h, overscaled_w,
overscaled_h, ret = 0;
uint8_t *input[4];
int px[4], py[4];
-AVFrame *out;
+AVFrame *out, *overscaled_frame;
+double dw, dh, dx_scaled, dy_scaled;
var_values[VAR_PX]= s->x;
var_values[VAR_PY]= s->y;
@@ -173,32 +187,44 @@ static int output_single_frame(AVFilterContext *ctx,
AVFrame *in, double *var_va
*zoom = av_clipd(*zoom, 1, 10);
var_values[VAR_ZOOM] = *zoom;
-w = in->width * (1.0 / *zoom);
-h = in->height * (1.0 / *zoom);
-*dx = av_expr_eval(s->x_expr, var_values, NULL);
+w = dw = (double) in->width / *zoom;
+h = dh = (double) in->height / *zoom;
+crop_w = scale_to_grid(w, s->desc->log2_chroma_w);
+crop_h = scale_to_grid(h, s->desc->log2_chroma_h);
+overscaled_w = outlink->w + (crop_w - dw) * *zoom;
+overscaled_h = outlink->h + (crop_h - dh) * *zoom;
-x = *dx = av_clipd(*dx, 0, FFMAX(in->width - w, 0));
-var_values[VAR_X] = *dx;
-x &= ~((1 << s->desc->log2_chroma_w) - 1);
+*dx = av_expr_eval(s->x_expr, var_values, NULL);
+crop_x = ceil(av_clipd(*dx - (((double) crop_w - w) / 2.0), 0,
FFMAX(in->width - crop_w, 0)));
+var_values[VAR_X] = *dx = av_clipd(*dx, 0, FFMAX(in->width - w, 0));
+crop_x &= ~((1 << s->desc->log2_chroma_w) - 1);
*dy = av_expr_eval(s->y_expr, var_values, NULL);
+crop_y = ceil(av_clipd(*dy - (((double) crop_h - h)/ 2.0), 0,
FFMAX(in->height - crop_h, 0)));
+var_values[VAR_Y] = *dy = av_clipd(*dy, 0, FFMAX(in->height - h, 0));
+crop_y &= ~((1 << s->desc->log2_chroma_h) - 1);
-y = *dy = av_clipd(*dy, 0, FFMAX(in->height - h, 0));
-var_values[VAR_Y] = *dy;
-y &= ~((1 << s->desc->log2_chroma_h) - 1);
-
-out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
-if (!out) {
+overscaled_frame = av_frame_alloc();
+if (!overscaled_frame) {
ret = AVERROR(ENOMEM);
return ret;
}
-px[1] = px[2] = AV_CEIL_RSHIFT(x, s->desc->log2_chroma_w);
-px[0] = px[3] = x;
+overscaled_frame->height = overscaled_h;
+overscaled_frame->width = overscaled_w;
+overscaled_frame->format = outlink->format;
+if ((ret = av_frame_get_buffer(overscaled_frame, 0)) < 0)
+goto error;
-py[1] = py[2] = AV_CEIL_RSHIFT(y, s->desc->log2_chroma_h);
-py[0] = py[3] = y;
+px[1] = px[2] = AV_CEIL_RSHIFT(crop_x, s->desc->log2_chroma_w);
+px[0] = px[3] = crop_x;
+
+py[1] = py[2] = AV_CEIL_RSHIFT(crop_y, s->desc->log2_chroma_h);
+py[0] = py[3] = crop_y;
+
+for (k = 0; k < 4; k++)
+input[k] = in->data[k] + py[k] * in->linesize[k] + px[k];
s->sws = sws_alloc_context();
if (!s->sws) {
@@ -206,21 +232,48 @@ static int output_single_frame(AVFilterContext *ctx,
AVFrame *in, double *var_va
goto error;
}
-for (k = 0; in->data[k]; k++)
-input[k] = in->data[k] + py[k] * in->linesize[k] + px[k];
-
-av_opt_set_int(s->sws, "srcw", w, 0);
-av_opt_set_int(s->sws, "srch", h, 0);
+av_opt_set_int(s->sws, "srcw", crop_w, 0);
+av_opt_set_int(s->sws, "srch", crop_h, 0);
av_opt_set_int(s->sws, "src_format", in->format, 0);
-av_opt_set_int(s->sws, "dstw", outlink->w, 0);
-av_opt_set_int(s->sws, "dsth", outlink->h, 0);
+av_opt_set_int(s->sws, "dstw", overscaled_w, 0);
+av_opt_set_int(s->sws, "dsth", overscaled_h, 0);
av_opt_set_int(s->sws, "
Re: [FFmpeg-devel] [PATCH v4] avfilter/vf_zoompan: fix shaking when zooming
On 1/29/20, Robert Deibel wrote:
> Fix shaking of image when zoom is applied by the zoompan filter.
> Resolves ticket https://trac.ffmpeg.org/ticket/4298
> ---
> Fixed a typo/bug where dy was dx. Removed request for oversized frame from
> filter, instead allocate
> internal frame and copy contents to out frame once dimensions are correct.
>
> libavfilter/vf_zoompan.c | 109 +--
> 1 file changed, 82 insertions(+), 27 deletions(-)
>
> diff --git a/libavfilter/vf_zoompan.c b/libavfilter/vf_zoompan.c
> index 59c9b19ec8..e18f9c8d1b 100644
> --- a/libavfilter/vf_zoompan.c
> +++ b/libavfilter/vf_zoompan.c
> @@ -150,16 +150,30 @@ static int config_output(AVFilterLink *outlink)
> return 0;
> }
>
> +/**
> + * Scales n to the next number divisible by 2 * 2^log_grid_size but
> minimally n + 2 * 2^log_grid_size.
> + *
> + * Used to scale the width and height of a frame to fit with the
> subsampling grid.
> + * @param n The number to be scaled.
> + * @param log_grid_size log 2 of the gridsize.
> + * @return The next number divisible by 2 * 2^log_grid_size but minimally n
> + 2 * 2^log_grid_size
> + */
> +static int scale_to_grid(int n, uint8_t log2_grid_size)
> +{
> +return (((n + (1 << log2_grid_size) * 2) & ~((1 << log2_grid_size) -
> 1)) + 1) & ~1;;
> +}
> +
> static int output_single_frame(AVFilterContext *ctx, AVFrame *in, double
> *var_values, int i,
> double *zoom, double *dx, double *dy)
> {
> ZPContext *s = ctx->priv;
> AVFilterLink *outlink = ctx->outputs[0];
> int64_t pts = s->frame_count;
> -int k, x, y, w, h, ret = 0;
> +int k, x, y, crop_x, crop_y, w, h, crop_w, crop_h, overscaled_w,
> overscaled_h, ret = 0;
> uint8_t *input[4];
> int px[4], py[4];
> -AVFrame *out;
> +AVFrame *out, *overscaled_frame;
> +double dw, dh, dx_scaled, dy_scaled;
>
> var_values[VAR_PX]= s->x;
> var_values[VAR_PY]= s->y;
> @@ -173,32 +187,44 @@ static int output_single_frame(AVFilterContext *ctx,
> AVFrame *in, double *var_va
>
> *zoom = av_clipd(*zoom, 1, 10);
> var_values[VAR_ZOOM] = *zoom;
> -w = in->width * (1.0 / *zoom);
> -h = in->height * (1.0 / *zoom);
>
> -*dx = av_expr_eval(s->x_expr, var_values, NULL);
> +w = dw = (double) in->width / *zoom;
> +h = dh = (double) in->height / *zoom;
> +crop_w = scale_to_grid(w, s->desc->log2_chroma_w);
> +crop_h = scale_to_grid(h, s->desc->log2_chroma_h);
> +overscaled_w = outlink->w + (crop_w - dw) * *zoom;
> +overscaled_h = outlink->h + (crop_h - dh) * *zoom;
>
> -x = *dx = av_clipd(*dx, 0, FFMAX(in->width - w, 0));
> -var_values[VAR_X] = *dx;
> -x &= ~((1 << s->desc->log2_chroma_w) - 1);
> +*dx = av_expr_eval(s->x_expr, var_values, NULL);
> +crop_x = ceil(av_clipd(*dx - (((double) crop_w - w) / 2.0), 0,
> FFMAX(in->width - crop_w, 0)));
> +var_values[VAR_X] = *dx = av_clipd(*dx, 0, FFMAX(in->width - w, 0));
> +crop_x &= ~((1 << s->desc->log2_chroma_w) - 1);
>
> *dy = av_expr_eval(s->y_expr, var_values, NULL);
> +crop_y = ceil(av_clipd(*dy - (((double) crop_h - h)/ 2.0), 0,
> FFMAX(in->height - crop_h, 0)));
> +var_values[VAR_Y] = *dy = av_clipd(*dy, 0, FFMAX(in->height - h, 0));
> +crop_y &= ~((1 << s->desc->log2_chroma_h) - 1);
>
> -y = *dy = av_clipd(*dy, 0, FFMAX(in->height - h, 0));
> -var_values[VAR_Y] = *dy;
> -y &= ~((1 << s->desc->log2_chroma_h) - 1);
> -
> -out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
> -if (!out) {
> +overscaled_frame = av_frame_alloc();
> +if (!overscaled_frame) {
> ret = AVERROR(ENOMEM);
> return ret;
> }
>
> -px[1] = px[2] = AV_CEIL_RSHIFT(x, s->desc->log2_chroma_w);
> -px[0] = px[3] = x;
> +overscaled_frame->height = overscaled_h;
> +overscaled_frame->width = overscaled_w;
> +overscaled_frame->format = outlink->format;
> +if ((ret = av_frame_get_buffer(overscaled_frame, 0)) < 0)
> +goto error;
>
> -py[1] = py[2] = AV_CEIL_RSHIFT(y, s->desc->log2_chroma_h);
> -py[0] = py[3] = y;
> +px[1] = px[2] = AV_CEIL_RSHIFT(crop_x, s->desc->log2_chroma_w);
> +px[0] = px[3] = crop_x;
> +
> +py[1] = py[2] = AV_CEIL_RSHIFT(crop_y, s->desc->log2_chroma_h);
> +py[0] = py[3] = crop_y;
> +
> +for (k = 0; k < 4; k++)
> +input[k] = in->data[k] + py[k] * in->linesize[k] + px[k];
>
> s->sws = sws_alloc_context();
> if (!s->sws) {
> @@ -206,21 +232,48 @@ static int output_single_frame(AVFilterContext *ctx,
> AVFrame *in, double *var_va
> goto error;
> }
>
> -for (k = 0; in->data[k]; k++)
> -input[k] = in->data[k] + py[k] * in->linesize[k] + px[k];
> -
> -av_opt_set_int(s->sws, "srcw", w, 0);
> -av_opt_set_int(s->sws, "srch", h, 0);
> +av_opt_set_int(s->sws, "srcw", crop_w, 0);
> +av_opt_set_int(s->sws, "srch", crop_h, 0);
Is this really needed?
> av_opt_set_
Re: [FFmpeg-devel] [PATCH 1/2] avutil/log: Add av_log_once() for printing a message just once per instance
On Tue, Jan 28, 2020 at 07:38:45PM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2020-01-24 13:04:08) > > On Tue, Jan 21, 2020 at 07:44:46PM +0100, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2020-01-21 15:43:48) > > > > On Tue, Jan 21, 2020 at 12:24:50PM +0100, Anton Khirnov wrote: > > > > > Quoting Michael Niedermayer (2020-01-16 17:51:28) > > > > > > Compared to ad-hoc if(printed) ... code this allows the user to > > > > > > disable > > > > > > it with a flag and see all repeated messages, it is also simpler > > > > > > > > > > That flag is global state - it should be deprecated and removed, not > > > > > embedded further into the API. > > > > > > > > When the flag is replaced by a non global solution every of its uses > > > > would be replaced too. > > > > > > > > Until such a non global API exists, this is the only way the user can > > > > indicate her choice of which log messages to print. > > > > Code should honor the existing API and user preferrance. > > > > > > The problem is that right now, flags is only used by the default log > > > callback. The behaviour of the default log callback is not specified by > > > the API, so it can be changed later without much trouble. With this > > > patch, the function of flags is hardcoded into the API, making its > > > future removal significantly harder. > > > > I dont really see this concern. Because if you disable the flag "today" > > you break the API as it is documented, the flag is documented to > > affect the message repeation. > > With this patch, disabling it still breaks a bunch of message repeating > > behavior, so to me this looks like its basically the same. > > The flag is documented, but the situations where it applies are not. > Currently, it only applies to the default log callback. It has no effect > whatsoever on users who use their own callback. With your patch, its > influence spreads into the core API. Since I see the flag as something > to be removed, I would prefer it were not done. > > > > > But what do you suggest ? > > > > We could send all the repeated _once() messages to the callback and leave it > > to the callback to drop them. Just needs a way to tag them as repeats > > > > We could move the (no)repeat flag to each context but this feels unwieldy > > and feels like it solves a problem noone had. Because noone ever asked > > AFAIR that they wanted to change repeating behavior on a per context base. > > This is probably mostly used by developers wanting to check for "all" > > messages. Or users produding bug reports which also would ideally have > > no dropped messages. > > > > I can also just drop the use of the flag entirely from the patch and just > > leave this as a unconditional _once() log. It feels a bit like a missing > > feature though because as a devleoper for debuging a simple switch to > > see all repeats seems usefull. > > I would say that log_once() should be used only for messages that are > meaningful just once (per context). It then makes no sense to log them > multiple times. Otherwise normal logging should be used. I cannot think of a single case for which this would be true. All cases i can think of for which i intended to use log_once() for, and for some of these users have asked for this. In one case theres a offer to pay for it by a user. So this is a real case with real intrerrest behind is where the messages do carry information in each instance (for a developer). but are annoying to the user. So, we sure can use log_once() with no flag to turn the "once" off. And let the developer who needs it off edit the source and rebuild but its not correct to say that the messages are not meaningful after their first occurance. A developer looking into some issue with a file would want to know if a header error occurs once or on every frame or maybe every time a vissual issue appears. Maybe we could have log_once() not suppress the messages after their first occurance but reduce them to DEBUG or TRACE level. What do you think ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- 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 v4] avfilter/vf_zoompan: fix shaking when zooming
On 29.01.20 11:49, Paul B Mahol wrote: On 1/29/20, Robert Deibel wrote: - -av_opt_set_int(s->sws, "srcw", w, 0); -av_opt_set_int(s->sws, "srch", h, 0); +av_opt_set_int(s->sws, "srcw", crop_w, 0); +av_opt_set_int(s->sws, "srch", crop_h, 0); Is this really needed? av_opt_set_int(s->sws, "src_format", in->format, 0); -av_opt_set_int(s->sws, "dstw", outlink->w, 0); -av_opt_set_int(s->sws, "dsth", outlink->h, 0); +av_opt_set_int(s->sws, "dstw", overscaled_w, 0); +av_opt_set_int(s->sws, "dsth", overscaled_h, 0); ditto Yes, I'm afraid so. Omitting these lines will result in faulty output, so is any combination of the original and the modified parameters. In fact the only combination to produce any image (apart from the one in the patch) is crop_w/crop_/h and outlink->w/outlink->h but even that's faulty. ___ 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] tools/target_dec_fuzzer: Add threshold for IFF_ILBM
On Wed, Jan 29, 2020 at 07:48:54AM +1100, Peter Ross wrote:
> On Thu, Jan 23, 2020 at 12:36:39AM +0100, Michael Niedermayer wrote:
> > Fixes: Timeout (32 -> 1sec)
> > Fixes:
> > 20138/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5634665251864576
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > tools/target_dec_fuzzer.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
> > index a3d784a019..e554558b69 100644
> > --- a/tools/target_dec_fuzzer.c
> > +++ b/tools/target_dec_fuzzer.c
> > @@ -143,6 +143,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
> > size) {
> > case AV_CODEC_ID_DST: maxsamples /= 8192; break;
> > case AV_CODEC_ID_DXV: maxpixels /= 32; break;
> > case AV_CODEC_ID_FFWAVESYNTH: maxsamples /= 16384; break;
> > +case AV_CODEC_ID_IFF_ILBM: maxpixels /= 128; break;
> > case AV_CODEC_ID_MSRLE: maxpixels /= 16; break;
> > case AV_CODEC_ID_QTRLE: maxpixels /= 16; break;
> > case AV_CODEC_ID_RASC: maxpixels /= 16; break;
>
> approve.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Any man who breaks a law that conscience tells him is unjust and willingly
accepts the penalty by staying in jail in order to arouse the conscience of
the community on the injustice of the law is at that moment expressing the
very highest respect for law. - Martin Luther King Jr
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] Why this is happening? CUDA ERROR OUT OF MEMORY
Hi guys, I am using ffmpeg to transcode some live channels, but I'm having a recurring problem. All the time I get a CUDA out of memory error( attached print ), even though the video card has nothing to process. I build my ffmpeg following the NVIDIA FFmpeg Transcoding Guide ( https://devblogs.nvidia.com/nvidia-ffmpeg-transcoding-guide/ ). I already used the following setups, but in all the error keeps happening . First Setup: OS: Ubuntu 18.04.3 LTS 64 bits kernel: 5.0.0-37-generic GPU: Quadro P4000 driver: 440.33.01 Second Setup: OS: CentOS 8.1.1911 kernel: 4.18.0-147.3.1.el8_1.x86_64 GPU: Quadro P4000 driver: 440.33.01 Third Setup: OS: CentOS 8.1.1911 kernel: 4.18.0-147.3.1.el8_1.x86_64 GPU: Quadro P4000 driver: 435.21 Short Lived F ourth Setup: OS: Ubuntu 14.04.6 LTS kernel: 4.4.0-148-generic GPU: Quadro P4000 driver: 435.21 Short Lived Fifth Setup: OS: CentOS 8.1.1911 kernel: 4.18.0-147.3.1.el8_1.x86_64 GPU: Quadro P4000 driver: 440.33.01 According to what I researched this error can be caused by a possible combination between OS, kernel, gpu and driver. ( https://emby.media/community/index.php?/topic/74738-42018-nvenc-sometimes-randomly-fails-with-cuda-error-out-of-memory-out-of-memory/ ) Can someone help me? 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] Fix undefined behavior in ff_configure_buffers_for_index()
On Tue, Jan 28, 2020 at 04:52:16PM -0800, Dale Curtis wrote:
> When e2_pts == INT64_MIN and e1_pts >= 0 the calculation of
> e2_pts - e1_pts will overflow an int64_t. So instead check
> for overflow and default to |time_tolerance| if the value
> is too large for an int64_t.
>
> Signed-off-by: Dale Curtis
> utils.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
> 9c3670236229794d325158a25f26fd0cdf459310 ubfix.patch
> From 412751f4747faf34e3dba088dc55290783eb6bd5 Mon Sep 17 00:00:00 2001
> From: Dale Curtis
> Date: Tue, 28 Jan 2020 16:49:14 -0800
> Subject: [PATCH] Fix undefined behavior in ff_configure_buffers_for_index()
>
> When e2_pts == INT64_MIN and e1_pts >= 0 the calculation of
> e2_pts - e1_pts will overflow an int64_t. So instead check
> for overflow and default to |time_tolerance| if the value
> is too large for an int64_t.
>
> Signed-off-by: Dale Curtis
> ---
> libavformat/utils.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index e22ca7cab8..d6197358c9 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -2135,7 +2135,13 @@ void ff_configure_buffers_for_index(AVFormatContext
> *s, int64_t time_tolerance)
> for (; i2 < st2->nb_index_entries; i2++) {
> AVIndexEntry *e2 = &st2->index_entries[i2];
> int64_t e2_pts = av_rescale_q(e2->timestamp,
> st2->time_base, AV_TIME_BASE_Q);
> -if (e2_pts - e1_pts < time_tolerance)
> +int64_t delta = e1_pts < 1 ? INT64_MAX + e1_pts >= e2_pts
> + ? e2_pts - e1_pts
> + : time_tolerance
> + : INT64_MIN + e1_pts <= e2_pts
> + ? e2_pts - e1_pts
> + : time_tolerance;
> +if (delta < time_tolerance)
> continue;
simpler solution, and also behaves arithmetically more correct when the
overflow happens in the othert direction:
av_assert0(time_tolerance >= 0);
if (e2_pts < e1_pts || e2_pts - (uint64_t)e1_pts < time_tolerance)
continue;
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
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] Why this is happening? CUDA ERROR OUT OF MEMORY
On Wed, 29 Jan 2020, 15:13 Rodrigo Dal Ri, wrote: > Hi guys, > > I am using ffmpeg to transcode some live channels, but I'm having a > recurring problem. > All the time I get a CUDA out of memory error( attached print ), even > though the video card has nothing to process. > I build my ffmpeg following the NVIDIA FFmpeg Transcoding Guide ( > https://devblogs.nvidia.com/nvidia-ffmpeg-transcoding-guide/ ). > I already used the following setups, but in all the error keeps happening > . > > > > First Setup: > OS: Ubuntu 18.04.3 LTS 64 bits > kernel: 5.0.0-37-generic > GPU: Quadro P4000 > driver: 440.33.01 > > > > > Second Setup: > OS: CentOS 8.1.1911 > kernel: 4.18.0-147.3.1.el8_1.x86_64 > GPU: Quadro P4000 > driver: 440.33.01 > > > > > Third Setup: > OS: CentOS 8.1.1911 > kernel: 4.18.0-147.3.1.el8_1.x86_64 > GPU: Quadro P4000 > driver: 435.21 Short Lived > > > > > F ourth Setup: > OS: Ubuntu 14.04.6 LTS > kernel: 4.4.0-148-generic > GPU: Quadro P4000 > driver: 435.21 Short Lived > > > > > Fifth Setup: > OS: CentOS 8.1.1911 > kernel: 4.18.0-147.3.1.el8_1.x86_64 > GPU: Quadro P4000 > driver: 440.33.01 > > > According to what I researched this error can be caused by a possible > combination between OS, kernel, gpu and driver. ( > https://emby.media/community/index.php?/topic/74738-42018-nvenc-sometimes-randomly-fails-with-cuda-error-out-of-memory-out-of-memory/ > ) > > > Can someone help me? > Thanks. > > > First and foremost, move your question to the ffmpeg-user mailing list. > This list is used for patchwork and queries on using libav programmatically. Secondly, post the full command used and the respective output. Pasting images in place of console output isn't encouraged. ___ 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] Support for Frame Duplication(Doubling/Tripling) by FFmpeg's HEVC Decoder by parsing the picture_struct SEI
Hi, Re-submitting the patch. This patch has the implementation for supporting frame-duplication (doubling/ tripling) by FFmpeg's HEVC decoder based on the picture_structure SEI value present in the encoded video. picture_structure value of 7 implies doubling and 8 implies tripling. The value of picture_structure is set while encoding. More details here: http://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245521.html Thanks & Regards, Praveen HEVC_Frame_Doubling_Tripling.patch Description: HEVC_Frame_Doubling_Tripling.patch ___ 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]lavf/nut: Explicitely add tags for NV12 and NV21
On Wed, Jan 29, 2020 at 01:44:52AM +0100, Carl Eugen Hoyos wrote: > Hi! > > Mentioned tags are already used in nut by fate. > > Please comment, Carl Eugen > nut.c |3 +++ > 1 file changed, 3 insertions(+) > ae60da7cb36c94b7cab3bd17f02bd9403c8d2ff8 > 0001-lavf-nut-Explicitely-add-NV12-NV21-tags.patch > From dd52b20ce2eea008a0c58c09f768e5ef92133578 Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Wed, 29 Jan 2020 01:43:24 +0100 > Subject: [PATCH] lavf/nut: Explicitely add NV12/NV21 tags. > > These are already used by fate. > --- > libavformat/nut.c | 3 +++ > 1 file changed, 3 insertions(+) they should be added to nut4cc.txt first https://lists.mplayerhq.hu/mailman/listinfo/nut-devel after that, LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. 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/2] tools/target_dec_fuzzer: Sort threshold list alphabetically
On Sun, Jan 26, 2020 at 12:56:25AM +0100, Michael Niedermayer wrote: > This also removes the comments as they are hard to maintain > together with sorted lists > > Signed-off-by: Michael Niedermayer > --- > tools/target_dec_fuzzer.c | 54 ++- > 1 file changed, 25 insertions(+), 29 deletions(-) will apply so as to reduce rebasing work of related patches [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org 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]lavf/nut: Explicitely add tags for NV12 and NV21
On 1/29/20, Michael Niedermayer wrote: > On Wed, Jan 29, 2020 at 01:44:52AM +0100, Carl Eugen Hoyos wrote: >> Hi! >> >> Mentioned tags are already used in nut by fate. >> >> Please comment, Carl Eugen > >> nut.c |3 +++ >> 1 file changed, 3 insertions(+) >> ae60da7cb36c94b7cab3bd17f02bd9403c8d2ff8 >> 0001-lavf-nut-Explicitely-add-NV12-NV21-tags.patch >> From dd52b20ce2eea008a0c58c09f768e5ef92133578 Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos >> Date: Wed, 29 Jan 2020 01:43:24 +0100 >> Subject: [PATCH] lavf/nut: Explicitely add NV12/NV21 tags. >> >> These are already used by fate. >> --- >> libavformat/nut.c | 3 +++ >> 1 file changed, 3 insertions(+) > > they should be added to nut4cc.txt first > > https://lists.mplayerhq.hu/mailman/listinfo/nut-devel > > after that, LGTM No, patch is LGTM, push at will. Mentioned list should be removed. > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Many things microsoft did are stupid, but not doing something just because > microsoft did it is even more stupid. If everything ms did were stupid they > would be bankrupt already. > ___ 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] lavc/ac3dec: disable DRC by default
This issue has been argued before, with the status quo being preserved under
the logic that the spec says this parameter is supposed to default to 1,
and that we should follow the spec. The spec was misguided, and thus so was
blindly following it.
The (E-)AC3 DRC architecture is a clever optimization: the (relatively) heavy
lifting of analyzing the audio data and calculating the per-block gain needed
is offloaded to the encoder, so that the player only needs to apply the gain
coefficients (at the desired scale) to get the DRC effect. In theory, this
seems like an efficient way to reduce the computational complexity of playback.
In practice, this isn't actually the case.
Actual (E-)AC3 is not guaranteed to have useful DRC metadata at all. For
instance, ffmpeg's encoder has never supported generating it. This means that
a user who wants DRC can't merely use the internal filter for (E-)AC3 and an
external one for other codecs; they have to use an external filter at al
times! They could also apply the internal filter, but it's hard to see what
benefit this would give.
I've also seen it argued that (E-)AC3 DRC does a better job of reproducing the
intent of the audio mastering engineer than playback-time DRC can. I don't
believe this argument is credible either. The official encoder does support
passing in custom gain values, but it doesn't appear that this capability is
frequently used. I'm not aware of any tooling that actually passes custom data
into the encoder's loudness parameters, and Dolby's first-party GUI tools don't
appear to support doing so. Dolby's own tools expose the parameters available in
the encoder itself, which comprise a set of 5 presets with no customizability:
"Film Standard", "Film Light", "Music Standard", "Music Light", and "Speech",
along with the null profile. These profiles are documented (minus their time
constants) in this PDF on the Dolby website:
https://www.dolby.com/us/en/technologies/a-guide-to-dolby-metadata.pdf
These are not advanced filters; they don't provide any complex control to the
content producer, who can't even tune the details or _know_ the time constants.
Even if the mastering engineer did want to customize the DRC with some custom
tool, in most cases I don't think they'd have the ability to do so because they
don't have access to the point in the pipeline where audio encoding occurs.
In TV, audio is often encoded live rather than streaming a pre-compressed
bitstream. In web streaming, masters are usually delivered with uncompressed
PCM audio and no loudness metadata, and encoded using stock configurations.
Film for DVD or Blu-Ray is the only plausible case, but again, I'm not aware
of any widely-used tooling for this with any more configurability than Dolby's.
Additional context: the AudioToolbox (E-)AC3 decoder (which is Dolby's) seems
not to apply DRC; you can see this by comparing the output of ffmpeg's decoder
with drc_scale set to 0 and 1 with the output of the (e)ac3_at decoder.
So to summarize:
- (E-)AC3 DRC is designed as an optimization for the decoder
- There's no inherent reason (E-)AC3 _requires_ DRC for playback more than any
other codec
- Due to inconsistent encoding, it can't be relied upon
- There's no reason to believe it's better than decode-side DRC when it works
- It's not universally applied by other software
I think this makes a compelling case to stop applying (E-)AC3 DRC by default.
The user can enable it on their own if they prefer, but I believe having it off
by default will improve the apparent quality of (E-)AC3 playback for the vast
majority of ffmpeg users, and improve the consistency between (E-)AC3 playback
and playback of any other codec. Thus, this patch.
---
libavcodec/ac3dec_fixed.c | 2 +-
libavcodec/ac3dec_float.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/ac3dec_fixed.c b/libavcodec/ac3dec_fixed.c
index bd66175d50..312616edfd 100644
--- a/libavcodec/ac3dec_fixed.c
+++ b/libavcodec/ac3dec_fixed.c
@@ -169,7 +169,7 @@ static void ac3_downmix_c_fixed16(int16_t **samples,
int16_t **matrix,
static const AVOption options[] = {
{ "cons_noisegen", "enable consistent noise generation",
OFFSET(consistent_noise_generation), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, PAR },
-{ "drc_scale", "percentage of dynamic range compression to apply",
OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 1.0}, 0.0, 6.0, PAR },
+{ "drc_scale", "percentage of dynamic range compression to apply",
OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 0.0}, 0.0, 6.0, PAR },
{ "heavy_compr", "enable heavy dynamic range compression",
OFFSET(heavy_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, PAR },
{ NULL},
};
diff --git a/libavcodec/ac3dec_float.c b/libavcodec/ac3dec_float.c
index b85a4ce336..69bd47aa6a 100644
--- a/libavcodec/ac3dec_float.c
+++ b/libavcodec/ac3dec_float.c
@@ -33,7 +33,7 @@
static const AVOption options[] = {
{ "cons_noisegen", "enable consistent noise generation",
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add an AVCodecContext flag to export PRFT side data on demand
On 1/23/2020 5:25 PM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> doc/APIchanges | 3 +++
> doc/codecs.texi| 2 ++
> libavcodec/avcodec.h | 8 +++-
> libavcodec/options_table.h | 1 +
> libavcodec/version.h | 2 +-
> 5 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 2977b00b60..2433083d55 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
> API changes, most recent first:
>
> +2020-01-xx - xx - lavc 58.66.101 - avcodec.h
> + Add AV_CODEC_FLAG2_EXPORT_PRFT.
> +
> 2020-01-15 - xx - lavc 58.66.100 - avcodec.h
>Add AV_PKT_DATA_PRFT and AVProducerReferenceTime.
>
> diff --git a/doc/codecs.texi b/doc/codecs.texi
> index 15e55cca39..ebf7bab0fb 100644
> --- a/doc/codecs.texi
> +++ b/doc/codecs.texi
> @@ -779,6 +779,8 @@ Place global headers at every keyframe instead of in
> extradata.
> Frame data might be split into multiple chunks.
> @item showall
> Show all frames before the first keyframe.
> +@item export_prft
> +Export Producer Reference Time into packet side-data (see
> @code{AV_PKT_DATA_PRFT})
> @item export_mvs
> Export motion vectors into frame side-data (see
> @code{AV_FRAME_DATA_MOTION_VECTORS})
> for codecs that support it. See also @file{doc/examples/export_mvs.c}.
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 774ed1e641..aae6e83568 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -955,6 +955,10 @@ typedef struct RcOverride{
> * Show all frames before the first keyframe
> */
> #define AV_CODEC_FLAG2_SHOW_ALL (1 << 22)
> +/**
> + * Export Producer Reference Time through packet side data
> + */
> +#define AV_CODEC_FLAG2_EXPORT_PRFT(1 << 27)
> /**
> * Export motion vectors through frame side data
> */
> @@ -1416,7 +1420,9 @@ enum AVPacketSideDataType {
> AV_PKT_DATA_AFD,
>
> /**
> - * Producer Reference Time data corresponding to the
> AVProducerReferenceTime struct.
> + * Producer Reference Time data corresponding to the
> AVProducerReferenceTime struct
> + * exported by some encoders (on demand through the export_prft flag set
> in the
> + * AVCodecContext flags2 field).
> */
> AV_PKT_DATA_PRFT,
>
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index d4c0cdeb48..479a85071b 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -75,6 +75,7 @@ static const AVOption avcodec_options[] = {
> {"local_header", "place global headers at every keyframe instead of in
> extradata", 0, AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_LOCAL_HEADER },
> INT_MIN, INT_MAX, V|E, "flags2"},
> {"chunks", "Frame data might be split into multiple chunks", 0,
> AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_CHUNKS }, INT_MIN, INT_MAX, V|D,
> "flags2"},
> {"showall", "Show all frames before the first keyframe", 0,
> AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_SHOW_ALL }, INT_MIN, INT_MAX, V|D,
> "flags2"},
> +{"export_prft", "export Producer Reference Time through packet side data",
> 0, AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_EXPORT_PRFT}, INT_MIN, INT_MAX,
> A|V|E, "flags2"},
> {"export_mvs", "export motion vectors through frame side data", 0,
> AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_EXPORT_MVS}, INT_MIN, INT_MAX, V|D,
> "flags2"},
> {"skip_manual", "do not skip samples and export skip information as frame
> side data", 0, AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_SKIP_MANUAL},
> INT_MIN, INT_MAX, A|D, "flags2"},
> {"ass_ro_flush_noop", "do not reset ASS ReadOrder field on flush", 0,
> AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_RO_FLUSH_NOOP}, INT_MIN, INT_MAX,
> S|D, "flags2"},
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 6cf333eeb6..b438a09d6d 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -29,7 +29,7 @@
>
> #define LIBAVCODEC_VERSION_MAJOR 58
> #define LIBAVCODEC_VERSION_MINOR 66
> -#define LIBAVCODEC_VERSION_MICRO 100
> +#define LIBAVCODEC_VERSION_MICRO 101
>
> #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> LIBAVCODEC_VERSION_MINOR, \
Will push this set soon if no one objects.
___
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] avcodec: add an AVCodecContext flag to export PRFT side data on demand
Quoting James Almer (2020-01-23 21:25:34)
> Signed-off-by: James Almer
> ---
> doc/APIchanges | 3 +++
> doc/codecs.texi| 2 ++
> libavcodec/avcodec.h | 8 +++-
> libavcodec/options_table.h | 1 +
> libavcodec/version.h | 2 +-
> 5 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 2977b00b60..2433083d55 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
> API changes, most recent first:
>
> +2020-01-xx - xx - lavc 58.66.101 - avcodec.h
> + Add AV_CODEC_FLAG2_EXPORT_PRFT.
> +
> 2020-01-15 - xx - lavc 58.66.100 - avcodec.h
>Add AV_PKT_DATA_PRFT and AVProducerReferenceTime.
>
> diff --git a/doc/codecs.texi b/doc/codecs.texi
> index 15e55cca39..ebf7bab0fb 100644
> --- a/doc/codecs.texi
> +++ b/doc/codecs.texi
> @@ -779,6 +779,8 @@ Place global headers at every keyframe instead of in
> extradata.
> Frame data might be split into multiple chunks.
> @item showall
> Show all frames before the first keyframe.
> +@item export_prft
> +Export Producer Reference Time into packet side-data (see
> @code{AV_PKT_DATA_PRFT})
> @item export_mvs
> Export motion vectors into frame side-data (see
> @code{AV_FRAME_DATA_MOTION_VECTORS})
> for codecs that support it. See also @file{doc/examples/export_mvs.c}.
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 774ed1e641..aae6e83568 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -955,6 +955,10 @@ typedef struct RcOverride{
> * Show all frames before the first keyframe
> */
> #define AV_CODEC_FLAG2_SHOW_ALL (1 << 22)
> +/**
> + * Export Producer Reference Time through packet side data
> + */
> +#define AV_CODEC_FLAG2_EXPORT_PRFT(1 << 27)
I wonder if we couldn't figure out a better place for this toggle.
flags/flags2 are currently a hot mess of everything and the kitchensink
squashed together. Perhaps we could add a new field for "flags to
indicate to the codec that it should export this optional kind of
metadata". It might make things clearer and better organized. Just a
random thought though - feel free to ignore me.
--
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".
[FFmpeg-devel] [PATCH] ac3enc: drop a global variable
Log the warning message once per encoder instance instead.
---
libavcodec/ac3enc.c | 5 ++---
libavcodec/ac3enc.h | 2 ++
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
index 25318f8631..7ce17db067 100644
--- a/libavcodec/ac3enc.c
+++ b/libavcodec/ac3enc.c
@@ -1993,12 +1993,11 @@ int ff_ac3_validate_metadata(AC3EncodeContext *s)
/* set bitstream id for alternate bitstream syntax */
if (!s->eac3 && (opt->extended_bsi_1 || opt->extended_bsi_2)) {
if (s->bitstream_id > 8 && s->bitstream_id < 11) {
-static int warn_once = 1;
-if (warn_once) {
+if (!s->warned_alternate_bitstream) {
av_log(avctx, AV_LOG_WARNING, "alternate bitstream syntax is "
"not compatible with reduced samplerates. writing of "
"extended bitstream information will be disabled.\n");
-warn_once = 0;
+s->warned_alternate_bitstream = 1;
}
} else {
s->bitstream_id = 6;
diff --git a/libavcodec/ac3enc.h b/libavcodec/ac3enc.h
index a2442d0e55..1e4a7405bf 100644
--- a/libavcodec/ac3enc.h
+++ b/libavcodec/ac3enc.h
@@ -255,6 +255,8 @@ typedef struct AC3EncodeContext {
uint8_t *ref_bap [AC3_MAX_CHANNELS][AC3_MAX_BLOCKS]; ///< bit
allocation pointers (bap)
int ref_bap_set; ///< indicates if
ref_bap pointers have been set
+int warned_alternate_bitstream;
+
/* fixed vs. float function pointers */
void (*mdct_end)(struct AC3EncodeContext *s);
int (*mdct_init)(struct AC3EncodeContext *s);
--
2.24.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/5] avformat/format: add av_find_input_format2
On 29-01-2020 03:10 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2020-01-28 08:44:42) Identifies demuxer by extension if search by short name fails. --- libavformat/avformat.h | 7 +++ libavformat/format.c | 14 +- libavformat/version.h | 2 +- 3 files changed, 21 insertions(+), 2 deletions(-) diff --git a/libavformat/avformat.h b/libavformat/avformat.h index 9b9b634ec3..c81c4f18fd 100644 --- a/libavformat/avformat.h +++ b/libavformat/avformat.h @@ -2246,6 +2246,13 @@ ff_const59 AVInputFormat *av_find_input_format(const char *short_name); */ ff_const59 AVInputFormat *av_probe_input_format(ff_const59 AVProbeData *pd, int is_opened); +/** + * Find AVInputFormat based on the short name of the input format. + * If that fails and as_extension is set, find demuxer which has registered the + * name as an extension. + */ +ff_const59 AVInputFormat *av_find_input_format2(const char *short_name, int as_extension); This seems rather ad-hoc to me. I think it'd be cleaner to have a dedicated function just for matching by extension. It could be called av_demuxer_find_by_ext() for consistency with av_demuxer_iterate(). Sure. But it could be both. av_find_input_format2 could call av_find_format_by_ext() if name fails. Gyan ___ 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] avcodec: add an AVCodecContext flag to export PRFT side data on demand
On 1/29/2020 12:12 PM, Anton Khirnov wrote:
> Quoting James Almer (2020-01-23 21:25:34)
>> Signed-off-by: James Almer
>> ---
>> doc/APIchanges | 3 +++
>> doc/codecs.texi| 2 ++
>> libavcodec/avcodec.h | 8 +++-
>> libavcodec/options_table.h | 1 +
>> libavcodec/version.h | 2 +-
>> 5 files changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index 2977b00b60..2433083d55 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>>
>> API changes, most recent first:
>>
>> +2020-01-xx - xx - lavc 58.66.101 - avcodec.h
>> + Add AV_CODEC_FLAG2_EXPORT_PRFT.
>> +
>> 2020-01-15 - xx - lavc 58.66.100 - avcodec.h
>>Add AV_PKT_DATA_PRFT and AVProducerReferenceTime.
>>
>> diff --git a/doc/codecs.texi b/doc/codecs.texi
>> index 15e55cca39..ebf7bab0fb 100644
>> --- a/doc/codecs.texi
>> +++ b/doc/codecs.texi
>> @@ -779,6 +779,8 @@ Place global headers at every keyframe instead of in
>> extradata.
>> Frame data might be split into multiple chunks.
>> @item showall
>> Show all frames before the first keyframe.
>> +@item export_prft
>> +Export Producer Reference Time into packet side-data (see
>> @code{AV_PKT_DATA_PRFT})
>> @item export_mvs
>> Export motion vectors into frame side-data (see
>> @code{AV_FRAME_DATA_MOTION_VECTORS})
>> for codecs that support it. See also @file{doc/examples/export_mvs.c}.
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 774ed1e641..aae6e83568 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -955,6 +955,10 @@ typedef struct RcOverride{
>> * Show all frames before the first keyframe
>> */
>> #define AV_CODEC_FLAG2_SHOW_ALL (1 << 22)
>> +/**
>> + * Export Producer Reference Time through packet side data
>> + */
>> +#define AV_CODEC_FLAG2_EXPORT_PRFT(1 << 27)
>
> I wonder if we couldn't figure out a better place for this toggle.
> flags/flags2 are currently a hot mess of everything and the kitchensink
> squashed together. Perhaps we could add a new field for "flags to
> indicate to the codec that it should export this optional kind of
> metadata". It might make things clearer and better organized. Just a
> random thought though - feel free to ignore me.
I added it to flags2 since that one also has the export_mvs option to
export one specific kind of frame side data, but yeah, both flags and
flags2 are a dumping ground of options and it's hardly intuitive.
What field name, define prefix and options.h names do you suggest?
Should it cover both packets (encoders) and frames (decoders)? And
should we move existing flags like export_mvs to it, deprecating the
existing ones?
___
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] sbcdec: do not unnecessarily set frame properties
Decoders are supposed to export stream properties in AVCodecContext, the AVFrame properties are set from those in ff_get_buffer(). --- libavcodec/sbcdec.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/libavcodec/sbcdec.c b/libavcodec/sbcdec.c index d8ea6855fe..2ebde46627 100644 --- a/libavcodec/sbcdec.c +++ b/libavcodec/sbcdec.c @@ -324,6 +324,8 @@ static int sbc_decode_init(AVCodecContext *avctx) SBCDecContext *sbc = avctx->priv_data; int i, ch; +avctx->sample_fmt = AV_SAMPLE_FMT_S16P; + sbc->frame.crc_ctx = av_crc_get_table(AV_CRC_8_EBU); memset(sbc->dsp.V, 0, sizeof(sbc->dsp.V)); @@ -348,9 +350,8 @@ static int sbc_decode_frame(AVCodecContext *avctx, if (frame_length <= 0) return frame_length; -avctx->channels = -frame->channels = sbc->frame.channels; -frame->format = AV_SAMPLE_FMT_S16P; +avctx->channels = sbc->frame.channels; + frame->nb_samples = sbc->frame.blocks * sbc->frame.subbands; if ((ret = ff_get_buffer(avctx, frame, 0)) < 0) return ret; -- 2.24.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/2] avcodec: add an AVCodecContext flag to export PRFT side data on demand
Quoting James Almer (2020-01-29 17:05:52)
> On 1/29/2020 12:12 PM, Anton Khirnov wrote:
> >
> > I wonder if we couldn't figure out a better place for this toggle.
> > flags/flags2 are currently a hot mess of everything and the kitchensink
> > squashed together. Perhaps we could add a new field for "flags to
> > indicate to the codec that it should export this optional kind of
> > metadata". It might make things clearer and better organized. Just a
> > random thought though - feel free to ignore me.
>
> I added it to flags2 since that one also has the export_mvs option to
> export one specific kind of frame side data, but yeah, both flags and
> flags2 are a dumping ground of options and it's hardly intuitive.
>
> What field name,
export_metadata? (the word 'metadata' is now a bit overloaded though)
export_opt_data? ('opt' could be somewhat misleading)
> define prefix
AVCODEC_EXPORT_FOO
possibly AVCODEC_EXPORT_METADATA_FOO (or whatever we choose from above,
but that's getting too long)
> and options.h names do you suggest?
matching the field name in AVCodecContext?
For the flags, the same you used in original patch.
> Should it cover both packets (encoders) and frames (decoders)?
Yes.
> And should we move existing flags like export_mvs to it, deprecating
> the existing ones?
What others are there? I'd say probably yes.
--
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 3/3] avfilter/vf_geq: fix multiple assignments of ptr in slice_geq_filter
On Sun, 29 Dec 2019, Michael Niedermayer wrote: On Sat, Dec 28, 2019 at 03:46:25PM +0100, Marton Balint wrote: Fixes Coverity CID 1427183. Signed-off-by: Marton Balint --- libavfilter/vf_geq.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) LGTM I forgot about this, now pushed. Thanks, Marton ___ 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] avfilter/vf_geq: use per-thread AVExpr for expression evaluation
There was no consensus about separating AVExprState from AVExpr so here is a
minimal patch using the existing AVExpr to fix ticket #7528.
Signed-off-by: Marton Balint
---
doc/filters.texi | 5 +
libavfilter/vf_geq.c | 26 +++---
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 3f40af8439..8a59de27ee 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11464,6 +11464,11 @@ Default is bilinear.
For functions, if @var{x} and @var{y} are outside the area, the value will be
automatically clipped to the closer edge.
+Please note that this filter can use multiple threads in which case each slice
+will have its own expression state. If you want to use only a single expression
+state because your expressions depend on previous state then you should limit
+the number of filter threads to 1.
+
@subsection Examples
@itemize
diff --git a/libavfilter/vf_geq.c b/libavfilter/vf_geq.c
index 23c989b248..c6f76a6963 100644
--- a/libavfilter/vf_geq.c
+++ b/libavfilter/vf_geq.c
@@ -33,6 +33,7 @@
#include "libavutil/pixdesc.h"
#include "internal.h"
+#define MAX_NB_THREADS 32
#define NB_PLANES 4
enum InterpolationMethods {
@@ -46,7 +47,7 @@ enum { VAR_X, VAR_Y, VAR_W,
VAR_H, VAR_N, VAR_
typedef struct GEQContext {
const AVClass *class;
-AVExpr *e[NB_PLANES]; ///< expressions for each plane
+AVExpr *e[NB_PLANES][MAX_NB_THREADS]; ///< expressions for each plane and
thread
char *expr_str[4+3];///< expression strings for each plane
AVFrame *picref;///< current input buffer
uint8_t *dst; ///< reference pointer to the 8bits output
@@ -288,12 +289,14 @@ static av_cold int geq_init(AVFilterContext *ctx)
NULL };
int counter[10] = {0};
-ret = av_expr_parse(&geq->e[plane], geq->expr_str[plane < 3 &&
geq->is_rgb ? plane+4 : plane], var_names,
-NULL, NULL, func2_names, func2, 0, ctx);
-if (ret < 0)
-break;
+for (int i = 0; i < MAX_NB_THREADS; i++) {
+ret = av_expr_parse(&geq->e[plane][i], geq->expr_str[plane < 3 &&
geq->is_rgb ? plane+4 : plane], var_names,
+NULL, NULL, func2_names, func2, 0, ctx);
+if (ret < 0)
+goto end;
+}
-av_expr_count_func(geq->e[plane], counter, FF_ARRAY_ELEMS(counter), 2);
+av_expr_count_func(geq->e[plane][0], counter, FF_ARRAY_ELEMS(counter),
2);
geq->needs_sum[plane] = counter[5] + counter[6] + counter[7] +
counter[8] + counter[9];
}
@@ -391,7 +394,7 @@ static int slice_geq_filter(AVFilterContext *ctx, void
*arg, int jobnr, int nb_j
for (x = 0; x < width; x++) {
values[VAR_X] = x;
-ptr[x] = av_expr_eval(geq->e[plane], values, geq);
+ptr[x] = av_expr_eval(geq->e[plane][jobnr], values, geq);
}
ptr += linesize;
}
@@ -401,7 +404,7 @@ static int slice_geq_filter(AVFilterContext *ctx, void
*arg, int jobnr, int nb_j
values[VAR_Y] = y;
for (x = 0; x < width; x++) {
values[VAR_X] = x;
-ptr16[x] = av_expr_eval(geq->e[plane], values, geq);
+ptr16[x] = av_expr_eval(geq->e[plane][jobnr], values, geq);
}
ptr16 += linesize/2;
}
@@ -414,7 +417,7 @@ static int geq_filter_frame(AVFilterLink *inlink, AVFrame
*in)
{
int plane;
AVFilterContext *ctx = inlink->dst;
-const int nb_threads = ff_filter_get_nb_threads(ctx);
+const int nb_threads = FFMIN(MAX_NB_THREADS,
ff_filter_get_nb_threads(ctx));
GEQContext *geq = ctx->priv;
AVFilterLink *outlink = inlink->dst->outputs[0];
AVFrame *out;
@@ -464,8 +467,9 @@ static av_cold void geq_uninit(AVFilterContext *ctx)
int i;
GEQContext *geq = ctx->priv;
-for (i = 0; i < FF_ARRAY_ELEMS(geq->e); i++)
-av_expr_free(geq->e[i]);
+for (i = 0; i < NB_PLANES; i++)
+for (int j = 0; j < MAX_NB_THREADS; j++)
+av_expr_free(geq->e[i][j]);
for (i = 0; i < NB_PLANES; i++)
av_freep(&geq->pixel_sums);
}
--
2.16.4
___
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 5/5] avformat/mov: correct to representative names for mov.c
On 28/01/2020 08:07, Hendrik Leppkes wrote: > These names are strictly speaking part of the ABI, and I'm sure that > some applications will use them to identify a format - I know that I > do, for example. To chime in: I do too. I thought it was considered ABI. Further, as far as I know, these are the only way to identify the format when using ffprobe in scripts (e.g. `ffprobe -of json -show_format input.ext`), and it'll break plenty of those scripts. Alternatives to checking this welcome. - 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".
Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/amfenc_hevc.c: Fix constant QP settings for I, P
> 28 янв. 2020 г., в 19:53, OvchinnikovDmitrii
> написал(а):
>
> ---
> libavcodec/amfenc_hevc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
> index 7c9a33ab33..8b4d289fac 100644
> --- a/libavcodec/amfenc_hevc.c
> +++ b/libavcodec/amfenc_hevc.c
> @@ -254,10 +254,10 @@ static av_cold int amf_encode_init_hevc(AVCodecContext
> *avctx)
> }
>
> if (ctx->qp_p != -1) {
> -AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
> AMF_VIDEO_ENCODER_HEVC_QP_I, ctx->qp_p);
> +AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
> AMF_VIDEO_ENCODER_HEVC_QP_P, ctx->qp_p);
> }
> if (ctx->qp_i != -1) {
> -AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
> AMF_VIDEO_ENCODER_HEVC_QP_P, ctx->qp_i);
> +AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
> AMF_VIDEO_ENCODER_HEVC_QP_I, ctx->qp_i);
> }
> AMF_ASSIGN_PROPERTY_BOOL(res, ctx->encoder,
> AMF_VIDEO_ENCODER_HEVC_RATE_CONTROL_SKIP_FRAME_ENABLE, ctx->skip_frame);
>
> --
> 2.19.1.windows.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".
Guys, could you please review and apply the patches. For sure this improve
FFmpeg quality in hw amd support.
Thanks
Alexander
This e-mail and any attachment(s) are intended only for the recipient(s) named
above and others who have been specifically authorized to receive them. They
may contain confidential information. If you are not the intended recipient,
please do not read this email or its attachment(s). Furthermore, you are hereby
notified that any dissemination, distribution or copying of this e-mail and any
attachment(s) is strictly prohibited. If you have received this e-mail in
error, please immediately notify the sender by replying to this e-mail and then
delete this e-mail and any attachment(s) or copies thereof from your system.
Thank you.
___
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/3] avcodec/screenpresso: Optimize sum_delta_flipped()
553 -> 332 sec
Testcase:
20280/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCREENPRESSO_fuzzer-6238663432470528
Signed-off-by: Michael Niedermayer
---
libavcodec/screenpresso.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/screenpresso.c b/libavcodec/screenpresso.c
index 5fac100897..d73c24df83 100644
--- a/libavcodec/screenpresso.c
+++ b/libavcodec/screenpresso.c
@@ -94,8 +94,9 @@ static void sum_delta_flipped(uint8_t *dst, int
dst_linesize,
{
int i;
for (; height > 0; height--) {
+const uint8_t *src1 = &src[(height - 1) * src_linesize];
for (i = 0; i < bytewidth; i++)
-dst[i] += src[(height - 1) * src_linesize + i];
+dst[i] += src1[i];
dst += dst_linesize;
}
}
--
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 3/3] avcodec/x86/diracdsp: Fix incorrect src addressing in dequant_subband_32()
Fixes: Segfault (not reproducable with asm, which made this hard to debug) Fixes: decoding errors Fixes: 19854/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5729372837511168 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/x86/diracdsp.asm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavcodec/x86/diracdsp.asm b/libavcodec/x86/diracdsp.asm index cc8a26fca5..a18bda113e 100644 --- a/libavcodec/x86/diracdsp.asm +++ b/libavcodec/x86/diracdsp.asm @@ -294,8 +294,9 @@ cglobal dequant_subband_32, 7, 7, 4, src, dst, stride, qf, qs, tot_v, tot_h addsrcq, mmsize adddstq, mmsize -subtot_hd, 4 +subtot_hq, 4 jg .loop_h +leasrcq, [srcq + 4*tot_hq] addr3, strideq dectot_vd -- 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/3] tools/target_dec_fuzzer: Adjust threshold for screenpresso
Fixes: Timeout (332 -> 21 sec)
Fixes:
20280/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCREENPRESSO_fuzzer-6238663432470528
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index edfc33e18c..145abcb1dc 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -157,6 +157,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_RASC:maxpixels /= 16;break;
case AV_CODEC_ID_SANM:maxpixels /= 16;break;
case AV_CODEC_ID_SCPR:maxpixels /= 32;break;
+case AV_CODEC_ID_SCREENPRESSO:maxpixels /= 64;break;
case AV_CODEC_ID_SMACKVIDEO: maxpixels /= 64;break;
case AV_CODEC_ID_SNOW:maxpixels /= 128; break;
case AV_CODEC_ID_TGV: maxpixels /= 32;break;
--
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] Fix undefined behavior in ff_configure_buffers_for_index()
On Wed, Jan 29, 2020 at 4:55 AM Michael Niedermayer wrote: > simpler solution, and also behaves arithmetically more correct when the > overflow happens in the othert direction: > > av_assert0(time_tolerance >= 0); > > if (e2_pts < e1_pts || e2_pts - (uint64_t)e1_pts < time_tolerance) > Does that work? e1_pts is INT64_MIN in this case. So the (uint64_t)e1_pts > e2_pts. ___ 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/6] avutil/common: use unsigned int in GET_UTF8
Right shift of signed value is impelentation defined.
Signed-off-by: Marton Balint
---
libavutil/common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/common.h b/libavutil/common.h
index f09f0b486b..5568754bb9 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -389,7 +389,7 @@ static av_always_inline av_const int av_parity_c(uint32_t v)
if ((val & 0xc0) == 0x80 || val >= 0xFE)\
ERROR\
while (val & top) {\
-int tmp= (GET_BYTE) - 128;\
+unsigned int tmp = (GET_BYTE) - 128;\
if(tmp>>6)\
ERROR\
val= (val<<6) + tmp;\
--
2.16.4
___
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/6] avutil/common: add parenthesis around GET_16BIT in GET_UTF16
Signed-off-by: Marton Balint
---
libavutil/common.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/common.h b/libavutil/common.h
index 5568754bb9..02671190a6 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -408,11 +408,11 @@ static av_always_inline av_const int av_parity_c(uint32_t
v)
* typically a goto statement.
*/
#define GET_UTF16(val, GET_16BIT, ERROR)\
-val = GET_16BIT;\
+val = (GET_16BIT);\
{\
unsigned int hi = val - 0xD800;\
if (hi < 0x800) {\
-val = GET_16BIT - 0xDC00;\
+val = (GET_16BIT) - 0xDC00;\
if (val > 0x3FFU || hi > 0x3FFU)\
ERROR\
val += (hi<<10) + 0x1;\
--
2.16.4
___
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 5/6] avfilter/vf_drawtext: use replacement chars for invalid UTF8 sequences
continue is explicitly disallowed for GET_UTF8, so let's fix that as well.
Fixes crash with invalid UTF8 sequences.
Signed-off-by: Marton Balint
---
libavfilter/vf_drawtext.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index aea17b6793..ed10175af0 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -1225,7 +1225,8 @@ static int draw_glyphs(DrawTextContext *s, AVFrame *frame,
for (i = 0, p = text; *p; i++) {
FT_Bitmap bitmap;
Glyph dummy = { 0 };
-GET_UTF8(code, *p++, continue;);
+GET_UTF8(code, *p++, code = 0xfffd; goto continue_on_invalid;);
+continue_on_invalid:
/* skip new line chars, just go to new line */
if (code == '\n' || code == '\r' || code == '\t')
@@ -1363,7 +1364,8 @@ static int draw_text(AVFilterContext *ctx, AVFrame *frame,
/* load and cache glyphs */
for (i = 0, p = text; *p; i++) {
-GET_UTF8(code, *p++, continue;);
+GET_UTF8(code, *p++, code = 0xfffd; goto continue_on_invalid;);
+continue_on_invalid:
/* get glyph */
dummy.code = code;
@@ -1386,7 +1388,8 @@ static int draw_text(AVFilterContext *ctx, AVFrame *frame,
/* compute and save position for each glyph */
glyph = NULL;
for (i = 0, p = text; *p; i++) {
-GET_UTF8(code, *p++, continue;);
+GET_UTF8(code, *p++, code = 0xfffd; goto continue_on_invalid2;);
+continue_on_invalid2:
/* skip the \n in the sequence \r\n */
if (prev_code == '\r' && code == '\n')
--
2.16.4
___
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 6/6] avfilter/vf_drawtext: do not overread text if the last UTF8 sequence is invalid
Signed-off-by: Marton Balint
---
libavfilter/vf_drawtext.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index ed10175af0..b58556e0f1 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -1225,7 +1225,7 @@ static int draw_glyphs(DrawTextContext *s, AVFrame *frame,
for (i = 0, p = text; *p; i++) {
FT_Bitmap bitmap;
Glyph dummy = { 0 };
-GET_UTF8(code, *p++, code = 0xfffd; goto continue_on_invalid;);
+GET_UTF8(code, *p ? *p++ : 0, code = 0xfffd; goto
continue_on_invalid;);
continue_on_invalid:
/* skip new line chars, just go to new line */
@@ -1364,7 +1364,7 @@ static int draw_text(AVFilterContext *ctx, AVFrame *frame,
/* load and cache glyphs */
for (i = 0, p = text; *p; i++) {
-GET_UTF8(code, *p++, code = 0xfffd; goto continue_on_invalid;);
+GET_UTF8(code, *p ? *p++ : 0, code = 0xfffd; goto
continue_on_invalid;);
continue_on_invalid:
/* get glyph */
@@ -1388,7 +1388,7 @@ continue_on_invalid:
/* compute and save position for each glyph */
glyph = NULL;
for (i = 0, p = text; *p; i++) {
-GET_UTF8(code, *p++, code = 0xfffd; goto continue_on_invalid2;);
+GET_UTF8(code, *p ? *p++ : 0, code = 0xfffd; goto
continue_on_invalid2;);
continue_on_invalid2:
/* skip the \n in the sequence \r\n */
--
2.16.4
___
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 3/6] avutil/common: put ERROR statements into separate code blocks in GET_UTF8/16
Signed-off-by: Marton Balint
---
libavutil/common.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavutil/common.h b/libavutil/common.h
index 02671190a6..e6f076a13c 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -387,11 +387,11 @@ static av_always_inline av_const int av_parity_c(uint32_t
v)
{\
uint32_t top = (val & 128) >> 1;\
if ((val & 0xc0) == 0x80 || val >= 0xFE)\
-ERROR\
+{ERROR}\
while (val & top) {\
unsigned int tmp = (GET_BYTE) - 128;\
if(tmp>>6)\
-ERROR\
+{ERROR}\
val= (val<<6) + tmp;\
top <<= 5;\
}\
@@ -414,7 +414,7 @@ static av_always_inline av_const int av_parity_c(uint32_t v)
if (hi < 0x800) {\
val = (GET_16BIT) - 0xDC00;\
if (val > 0x3FFU || hi > 0x3FFU)\
-ERROR\
+{ERROR}\
val += (hi<<10) + 0x1;\
}\
}\
--
2.16.4
___
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 4/6] avutil/common: warn about possible move of the data pointer after the last 0 byte in GET_UTF8
Signed-off-by: Marton Balint --- libavutil/common.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libavutil/common.h b/libavutil/common.h index e6f076a13c..142ff9abe7 100644 --- a/libavutil/common.h +++ b/libavutil/common.h @@ -373,7 +373,9 @@ static av_always_inline av_const int av_parity_c(uint32_t v) * @param GET_BYTE Expression reading one byte from the input. * Evaluated up to 7 times (4 for the currently * assigned Unicode range). With a memory buffer - * input, this could be *ptr++. + * input, this could be *ptr++, or if you want to make sure + * that *ptr stops at the end of a NULL terminated string then + * *ptr ? *ptr++ : 0 * @param ERRORExpression to be evaluated on invalid input, * typically a goto statement. * -- 2.16.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add xfade filter
On Sun, Jan 26, 2020, at 4:46 AM, Paul B Mahol wrote: > +@item wipeleft > +@item wiperight > +@item wipeup > +@item wipedown Nice filter, but you're missing the best wipe of them all: starwipe. > +@item slideleft > +@item slideright > +@item slideup > +@item slidedown > +@end table > +Default transition effect is fade. > + > +@item duration > +Set cross fade duration in seconds. Add "Default is 1 second". > +@item offset > +Set cross fade start relative to first input stream. Add "Default is 0". Compilation is spammy with warnings on gcc 9.2.0: libavfilter/vf_xfade.c: In function ‘uninit’: libavfilter/vf_xfade.c:107:19: warning: unused variable ‘s’ [-Wunused-variable] 107 | XFadeContext *s = ctx->priv; | ^ libavfilter/vf_xfade.c: In function ‘slideleft8_transition’: libavfilter/vf_xfade.c:300:35: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context] 300 | dst[x] = (zx > 0) * (zx < width) ? xf1[zz] : xf0[zz]; \ | ~^~ libavfilter/vf_xfade.c:310:1: note: in expansion of macro ‘SLIDELEFT_TRANSITION’ 310 | SLIDELEFT_TRANSITION(8, uint8_t, 1) | ^~~~ libavfilter/vf_xfade.c: In function ‘slideleft16_transition’: libavfilter/vf_xfade.c:300:35: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context] 300 | dst[x] = (zx > 0) * (zx < width) ? xf1[zz] : xf0[zz]; \ | ~^~ libavfilter/vf_xfade.c:311:1: note: in expansion of macro ‘SLIDELEFT_TRANSITION’ 311 | SLIDELEFT_TRANSITION(16, uint16_t, 2) | ^~~~ libavfilter/vf_xfade.c: In function ‘slideright8_transition’: libavfilter/vf_xfade.c:333:35: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context] 333 | dst[x] = (zx > 0) * (zx < width) ? xf1[zz] : xf0[zz]; \ | ~^~ libavfilter/vf_xfade.c:343:1: note: in expansion of macro ‘SLIDERIGHT_TRANSITION’ 343 | SLIDERIGHT_TRANSITION(8, uint8_t, 1) | ^ libavfilter/vf_xfade.c: In function ‘slideright16_transition’: libavfilter/vf_xfade.c:333:35: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context] 333 | dst[x] = (zx > 0) * (zx < width) ? xf1[zz] : xf0[zz]; \ | ~^~ libavfilter/vf_xfade.c:344:1: note: in expansion of macro ‘SLIDERIGHT_TRANSITION’ 344 | SLIDERIGHT_TRANSITION(16, uint16_t, 2) | ^ libavfilter/vf_xfade.c: In function ‘slideup8_transition’: libavfilter/vf_xfade.c:366:35: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context] 366 | dst[x] = (zy > 0) * (zy < height) ? xf1[x] : xf0[x]; \ | ~^~~ libavfilter/vf_xfade.c:374:1: note: in expansion of macro ‘SLIDEUP_TRANSITION’ 374 | SLIDEUP_TRANSITION(8, uint8_t, 1) | ^~ libavfilter/vf_xfade.c: In function ‘slideup16_transition’: libavfilter/vf_xfade.c:366:35: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context] 366 | dst[x] = (zy > 0) * (zy < height) ? xf1[x] : xf0[x]; \ | ~^~~ libavfilter/vf_xfade.c:375:1: note: in expansion of macro ‘SLIDEUP_TRANSITION’ 375 | SLIDEUP_TRANSITION(16, uint16_t, 2) | ^~ libavfilter/vf_xfade.c: In function ‘slidedown8_transition’: libavfilter/vf_xfade.c:397:35: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context] 397 | dst[x] = (zy > 0) * (zy < height) ? xf1[x] : xf0[x]; \ | ~^~~ libavfilter/vf_xfade.c:405:1: note: in expansion of macro ‘SLIDEDOWN_TRANSITION’ 405 | SLIDEDOWN_TRANSITION(8, uint8_t, 1) | ^~~~ libavfilter/vf_xfade.c: In function ‘slidedown16_transition’: libavfilter/vf_xfade.c:397:35: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context] 397 | dst[x] = (zy > 0) * (zy < height) ? xf1[x] : xf0[x]; \ | ~^~~ libavfilter/vf_xfade.c:406:1: note: in expansion of macro ‘SLIDEDOWN_TRANSITION’ 406 | SLIDEDOWN_TRANSITION(16, uint16_t, 2) | ^~~~ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate/filter-video.mak: do not use bit-exact check for dnn_processing
Am Mi., 29. Jan. 2020 um 04:41 Uhr schrieb Pedro Arthur : > > Em ter., 28 de jan. de 2020 às 21:20, Carl Eugen Hoyos > escreveu: > > > > Am Mi., 22. Jan. 2020 um 13:09 Uhr schrieb Martin Storsjö > > : > > > > > If it takes time to get the test to that point, I would suggest reverting > > > the existing two tests for now. > > > > Did this when I realized that the existing test breaks fate without > > SAMPLES on all platforms. > I'm not against reverting it but isn't SAMPLES required to run fate? Definitely not? 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] avformat/mov: update extensions
Am Mi., 29. Jan. 2020 um 05:56 Uhr schrieb Gyan : > > > > On 29-01-2020 05:52 am, Carl Eugen Hoyos wrote: > > Am Mo., 27. Jan. 2020 um 18:07 Uhr schrieb Gyan : > > > >> As I mentioned, the benefit is for cli users able to specify `-f ext` > >> as well as `-h demuxer=ext` > > I cannot reproduce this... > > That will depend on my patch that adds av_find_input_format2. > I sent it yesterday. In this case it was not ok to commit the patch. 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] ac3enc: drop a global variable
Sent from my mobile device
On Wed, 29 Jan 2020, 15:35 Anton Khirnov, wrote:
> Log the warning message once per encoder instance instead.
> ---
> libavcodec/ac3enc.c | 5 ++---
> libavcodec/ac3enc.h | 2 ++
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
> index 25318f8631..7ce17db067 100644
> --- a/libavcodec/ac3enc.c
> +++ b/libavcodec/ac3enc.c
> @@ -1993,12 +1993,11 @@ int ff_ac3_validate_metadata(AC3EncodeContext *s)
> /* set bitstream id for alternate bitstream syntax */
> if (!s->eac3 && (opt->extended_bsi_1 || opt->extended_bsi_2)) {
> if (s->bitstream_id > 8 && s->bitstream_id < 11) {
> -static int warn_once = 1;
> -if (warn_once) {
> +if (!s->warned_alternate_bitstream) {
> av_log(avctx, AV_LOG_WARNING, "alternate bitstream syntax
> is "
> "not compatible with reduced samplerates. writing
> of "
> "extended bitstream information will be
> disabled.\n");
> -warn_once = 0;
> +s->warned_alternate_bitstream = 1;
> }
> } else {
> s->bitstream_id = 6;
> diff --git a/libavcodec/ac3enc.h b/libavcodec/ac3enc.h
> index a2442d0e55..1e4a7405bf 100644
> --- a/libavcodec/ac3enc.h
> +++ b/libavcodec/ac3enc.h
> @@ -255,6 +255,8 @@ typedef struct AC3EncodeContext {
> uint8_t *ref_bap [AC3_MAX_CHANNELS][AC3_MAX_BLOCKS]; ///< bit
> allocation pointers (bap)
> int ref_bap_set; ///<
> indicates if ref_bap pointers have been set
>
> +int warned_alternate_bitstream;
> +
> /* fixed vs. float function pointers */
> void (*mdct_end)(struct AC3EncodeContext *s);
> int (*mdct_init)(struct AC3EncodeContext *s);
> --
> 2.24.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".
Yes ofc
___
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/mov: update extensions
On 30-01-2020 07:37 am, Carl Eugen Hoyos wrote: Am Mi., 29. Jan. 2020 um 05:56 Uhr schrieb Gyan : On 29-01-2020 05:52 am, Carl Eugen Hoyos wrote: Am Mo., 27. Jan. 2020 um 18:07 Uhr schrieb Gyan : As I mentioned, the benefit is for cli users able to specify `-f ext` as well as `-h demuxer=ext` I cannot reproduce this... That will depend on my patch that adds av_find_input_format2. I sent it yesterday. In this case it was not ok to commit the patch. Why? What does it break? Gyan ___ 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] Fix undefined behavior in ff_configure_buffers_for_index()
On Wed, Jan 29, 2020 at 03:25:32PM -0800, Dale Curtis wrote: > On Wed, Jan 29, 2020 at 4:55 AM Michael Niedermayer > wrote: > > > simpler solution, and also behaves arithmetically more correct when the > > overflow happens in the othert direction: > > > > av_assert0(time_tolerance >= 0); > > > > if (e2_pts < e1_pts || e2_pts - (uint64_t)e1_pts < time_tolerance) > > > > Does that work? e1_pts is INT64_MIN in this case. So the (uint64_t)e1_pts > > e2_pts. the original code was this: if (e2_pts - e1_pts < time_tolerance) time_tolerance is always positive e2_pts - e1_pts can be either positive or negative if its negative (e2_pts < e1_pts) then the original would be true and thats the first term of the new condition otherwise e2_pts - e1_pts is positive and can be represented as a uint64_t which is the 2nd term of the new condition so i think it works but maybe ive missed something, for which values of e2_pts do you see a problem with e1_pts = INT64_MIN? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org 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] avformat/aviobuf: Remove AVIOInternal and one level of indirection
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> On Mon, Jan 6, 2020 at 3:51 PM Andreas Rheinhardt <
>> andreas.rheinha...@gmail.com> wrote:
>>
>>> In the Libav commit cae448cf, the opaque of every AVIOContext opened
>>> by ffio_fdopen() (which is used internally by avio_open() and avio_open2())
>>> changed: It was a simple pointer to an URLContext before, but now it was
>>> a structure (namely AVIOInternal) containing a pointer to an URLContext
>>> as its only member. The next commits (namely 8c0ceafb and ec4c4839) added
>>> members to AVIOInternal to allow white-/blacklisting of protocols.
>>>
>>> But these two commits were never merged into FFmpeg (they were only
>>> merged as no-ops in 510046c2 and 063b26d3), because FFmpeg chose
>>> a different way to implement this (in 93629735); and so our AVIOInternal
>>> still has exactly one member.
>>>
>>> This of course means that it is unnecessary to use AVIOInternal as
>>> opaque as it is just adding a level of indirection (not only pointer
>>> dereference, but also wrapper functions). Therefore this commit
>>> removes AVIOInternal entirely and essentially reverts cae448cf.
>>>
>>> Signed-off-by: Andreas Rheinhardt
>>> ---
>>> libavformat/aviobuf.c | 86 ---
>>> 1 file changed, 15 insertions(+), 71 deletions(-)
>>>
>>> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
>>> index 70e1d2ca10..0e2f038988 100644
>>> --- a/libavformat/aviobuf.c
>>> +++ b/libavformat/aviobuf.c
>>> @@ -42,15 +42,10 @@
>>> */
>>> #define SHORT_SEEK_THRESHOLD 4096
>>>
>>> -typedef struct AVIOInternal {
>>> -URLContext *h;
>>> -} AVIOInternal;
>>> -
>>> static void *ff_avio_child_next(void *obj, void *prev)
>>> {
>>> AVIOContext *s = obj;
>>> -AVIOInternal *internal = s->opaque;
>>> -return prev ? NULL : internal->h;
>>> +return prev ? NULL : s->opaque;
>>> }
>>>
>>> static const AVClass *ff_avio_child_class_next(const AVClass *prev)
>>> @@ -940,49 +935,8 @@ uint64_t ffio_read_varlen(AVIOContext *bc){
>>> return val;
>>> }
>>>
>>> -static int io_read_packet(void *opaque, uint8_t *buf, int buf_size)
>>> -{
>>> -AVIOInternal *internal = opaque;
>>> -return ffurl_read(internal->h, buf, buf_size);
>>> -}
>>> -
>>> -static int io_write_packet(void *opaque, uint8_t *buf, int buf_size)
>>> -{
>>> -AVIOInternal *internal = opaque;
>>> -return ffurl_write(internal->h, buf, buf_size);
>>> -}
>>> -
>>> -static int64_t io_seek(void *opaque, int64_t offset, int whence)
>>> -{
>>> -AVIOInternal *internal = opaque;
>>> -return ffurl_seek(internal->h, offset, whence);
>>> -}
>>> -
>>> -static int io_short_seek(void *opaque)
>>> -{
>>> -AVIOInternal *internal = opaque;
>>> -return ffurl_get_short_seek(internal->h);
>>> -}
>>> -
>>> -static int io_read_pause(void *opaque, int pause)
>>> -{
>>> -AVIOInternal *internal = opaque;
>>> -if (!internal->h->prot->url_read_pause)
>>> -return AVERROR(ENOSYS);
>>> -return internal->h->prot->url_read_pause(internal->h, pause);
>>> -}
>>> -
>>> -static int64_t io_read_seek(void *opaque, int stream_index, int64_t
>>> timestamp, int flags)
>>> -{
>>> -AVIOInternal *internal = opaque;
>>> -if (!internal->h->prot->url_read_seek)
>>> -return AVERROR(ENOSYS);
>>> -return internal->h->prot->url_read_seek(internal->h, stream_index,
>>> timestamp, flags);
>>> -}
>>> -
>>> int ffio_fdopen(AVIOContext **s, URLContext *h)
>>> {
>>> -AVIOInternal *internal = NULL;
>>> uint8_t *buffer = NULL;
>>> int buffer_size, max_packet_size;
>>>
>>> @@ -996,14 +950,10 @@ int ffio_fdopen(AVIOContext **s, URLContext *h)
>>> if (!buffer)
>>> return AVERROR(ENOMEM);
>>>
>>> -internal = av_mallocz(sizeof(*internal));
>>> -if (!internal)
>>> -goto fail;
>>> -
>>> -internal->h = h;
>>> -
>>> -*s = avio_alloc_context(buffer, buffer_size, h->flags &
>>> AVIO_FLAG_WRITE,
>>> -internal, io_read_packet, io_write_packet,
>>> io_seek);
>>> +*s = avio_alloc_context(buffer, buffer_size, h->flags &
>>> AVIO_FLAG_WRITE, h,
>>> +(int (*)(void *, uint8_t *, int)) ffurl_read,
>>> +(int (*)(void *, uint8_t *, int))
>>> ffurl_write,
>>> +(int64_t (*)(void *, int64_t,
>>> int))ffurl_seek);
>>> if (!*s)
>>> goto fail;
>>>
>>> @@ -1023,30 +973,28 @@ int ffio_fdopen(AVIOContext **s, URLContext *h)
>>> (*s)->max_packet_size = max_packet_size;
>>> (*s)->min_packet_size = h->min_packet_size;
>>> if(h->prot) {
>>> -(*s)->read_pause = io_read_pause;
>>> -(*s)->read_seek = io_read_seek;
>>> +(*s)->read_pause = (int (*)(void *, int))h->prot->url_read_pause;
>>> +(*s)->read_seek =
>>> +(int64_t (*)(void *, int, int64_t,
>>> int))h->prot->url_read_seek;
>>>
>>> if (h->prot->url_read_seek)
>>> (*s)->seekable |= AVIO
