Re: [FFmpeg-devel] [PATCH] avfilter: use ff_inlink_make_frame_writable()
New patch attached.
From 86203516a4d38f312ea5319315aa79841a39a45b Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Mon, 6 Feb 2023 14:57:50 +0100
Subject: [PATCH] avfilter: use ff_inlink_make_frame_writable()
Signed-off-by: Paul B Mahol
---
libavfilter/avf_abitscope.c | 11 --
libavfilter/avf_ahistogram.c | 9 ++--
libavfilter/avf_aphasemeter.c | 9 ++--
libavfilter/avf_avectorscope.c| 7 ++-
libavfilter/avf_showspectrum.c| 5 -
libavfilter/avf_showvolume.c | 8 ++--
libavfilter/f_ebur128.c | 12 ---
libavfilter/f_perms.c | 4 +++-
libavfilter/framesync.c | 2 +-
libavfilter/vf_cover_rect.c | 9 ++--
libavfilter/vf_dedot.c| 2 +-
libavfilter/vf_floodfill.c| 5 -
libavfilter/vf_lensfun.c | 8 +++-
libavfilter/vf_overlay_cuda.c | 3 ++-
libavfilter/vf_paletteuse.c | 2 +-
libavfilter/vf_photosensitivity.c | 3 ++-
libavfilter/vf_repeatfields.c | 34 ---
libavfilter/vf_signalstats.c | 27
libavfilter/vf_telecine.c | 13 ++--
libavfilter/vf_vidstabdetect.c| 12 ---
20 files changed, 146 insertions(+), 39 deletions(-)
diff --git a/libavfilter/avf_abitscope.c b/libavfilter/avf_abitscope.c
index 4fc3c06ecb..782d57e03a 100644
--- a/libavfilter/avf_abitscope.c
+++ b/libavfilter/avf_abitscope.c
@@ -213,6 +213,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *insamples)
AVFilterLink *outlink = ctx->outputs[0];
AudioBitScopeContext *s = ctx->priv;
AVFrame *outpicref;
+int ret;
if (s->mode == 0 || !s->outpicref) {
outpicref = ff_get_video_buffer(outlink, outlink->w, outlink->h);
@@ -228,10 +229,16 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *insamples)
}
if (s->mode == 1) {
-av_frame_make_writable(s->outpicref);
+ret = ff_inlink_make_frame_writable(outlink, >outpicref);
+if (ret < 0) {
+av_frame_free();
+return ret;
+}
outpicref = av_frame_clone(s->outpicref);
-if (!outpicref)
+if (!outpicref) {
+av_frame_free();
return AVERROR(ENOMEM);
+}
}
outpicref->pts = av_rescale_q(insamples->pts, inlink->time_base, outlink->time_base);
diff --git a/libavfilter/avf_ahistogram.c b/libavfilter/avf_ahistogram.c
index c45493730d..06490192a5 100644
--- a/libavfilter/avf_ahistogram.c
+++ b/libavfilter/avf_ahistogram.c
@@ -209,7 +209,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
AudioHistogramContext *s = ctx->priv;
const int H = s->histogram_h;
const int w = s->w;
-int c, y, n, p, bin;
+int c, y, n, p, bin, ret;
uint64_t acmax = 1;
AVFrame *clone;
@@ -229,7 +229,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
}
}
-av_frame_make_writable(s->out);
+ret = ff_inlink_make_frame_writable(outlink, >out);
+if (ret < 0) {
+av_frame_free();
+return ret;
+}
+
if (s->dmode == SEPARATE) {
for (y = 0; y < w; y++) {
s->combine_buffer[3 * y] = 0;
diff --git a/libavfilter/avf_aphasemeter.c b/libavfilter/avf_aphasemeter.c
index 0f7692982c..bf9f922639 100644
--- a/libavfilter/avf_aphasemeter.c
+++ b/libavfilter/avf_aphasemeter.c
@@ -29,6 +29,7 @@
#include "libavutil/parseutils.h"
#include "libavutil/timestamp.h"
#include "avfilter.h"
+#include "filters.h"
#include "formats.h"
#include "audio.h"
#include "video.h"
@@ -246,7 +247,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
float fphase = 0;
AVFrame *out;
uint8_t *dst;
-int i;
+int i, ret;
int mono_measurement;
int out_phase_measurement;
float tolerance = 1.0f - s->tolerance;
@@ -265,8 +266,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
for (i = 0; i < outlink->h; i++)
memset(out->data[0] + i * out->linesize[0], 0, outlink->w * 4);
} else if (s->do_video) {
+ret = ff_inlink_make_frame_writable(outlink, >out);
+if (ret < 0) {
+av_frame_free();
+return ret;
+}
out = s->out;
-av_frame_make_writable(s->out);
for (i = outlink->h - 1; i >= 10; i--)
memmove(out->data[0] + (i ) * out->linesize[0],
out->data[0] + (i-1) * out->linesize[0],
diff --git a/libavfilter/avf_avectorscope.c b/libavfilter/avf_avectorscope.c
index 3927d80b42..6e45fd9575 100644
--- a/libavfilter/avf_avectorscope.c
+++ b/libavfilter/avf_avectorscope.c
@@ -297,6 +297,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *insamples)
unsigned x, y;
unsigned prev_x = s->prev_x, prev_y = s->prev_y;
double zoom = s->zoom;
+int ret;
if (!s->outpicref || s->outpicref->width != outlink->w ||
Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: move help text for -ab/-b:a to audio category
Thank you
On Wed, Feb 8, 2023 at 9:13 PM Anton Khirnov wrote:
> Quoting Marth64 (2023-02-06 19:12:15)
> > Since at least 4.4.3, -ab/-b:a help text was in the video section
> > of ffmpeg -h, but these are audio options.
> >
> > Signed-off-by: Marth64
> > ---
> > fftools/ffmpeg_opt.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> > index 204be38c94..799dcf071e 100644
> > --- a/fftools/ffmpeg_opt.c
> > +++ b/fftools/ffmpeg_opt.c
> > @@ -1637,8 +1637,6 @@ const OptionDef options[] = {
> > { "force_key_frames", OPT_VIDEO | OPT_STRING | HAS_ARG | OPT_EXPERT
> |
> >OPT_SPEC | OPT_OUTPUT,
> { .off = OFFSET(forced_key_frames) },
> > "force key frames at specified timestamps", "timestamps" },
> > -{ "ab", OPT_VIDEO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT,
> { .func_arg = opt_bitrate },
> > -"audio bitrate (please use -b:a)", "bitrate" },
> > { "b",OPT_VIDEO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT,
> { .func_arg = opt_bitrate },
> > "video bitrate (please use -b:v)", "bitrate" },
> > { "hwaccel", OPT_VIDEO | OPT_STRING | HAS_ARG | OPT_EXPERT
> |
> > @@ -1680,6 +1678,8 @@ const OptionDef options[] = {
> > { "acodec", OPT_AUDIO | HAS_ARG | OPT_PERFILE |
> > OPT_INPUT | OPT_OUTPUT,
> { .func_arg = opt_audio_codec },
> > "force audio codec ('copy' to copy stream)", "codec" },
> > +{ "ab", OPT_AUDIO | HAS_ARG | OPT_PERFILE |
> OPT_OUTPUT,{ .func_arg = opt_bitrate },
> > +"audio bitrate (please use -b:a)", "bitrate" },
> > { "atag", OPT_AUDIO | HAS_ARG | OPT_EXPERT | OPT_PERFILE
> |
> > OPT_OUTPUT,
> { .func_arg = opt_old2new },
> > "force audio tag/fourcc", "fourcc/tag" },
>
> Looks ok, will push
>
> --
> 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] ffprobe/eac3/mlp/dca: add detection of spatial audio extensions
Signed-off-by: Marth64
---
Adds detection of spatial/object-based audio extensions in E-AC-3,
TrueHD, and DCA XLL (DTS). This includes Atmos, DTS:X, and IMAX formats.
Please let me know what I could improve, I'm learning still.
Thank you.
doc/ffprobe.xsd| 1 +
fftools/ffprobe.c | 3 +++
libavcodec/ac3dec.c| 1 +
libavcodec/ac3dec.h| 1 +
libavcodec/avcodec.h | 6 ++
libavcodec/codec_par.c | 2 ++
libavcodec/codec_par.h | 6 ++
libavcodec/dca_syncwords.h | 3 +++
libavcodec/dca_xll.c | 14 ++
libavcodec/eac3dec.c | 11 ++-
libavcodec/mlpdec.c| 9 +
11 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd
index 0920380108..a01a4359dc 100644
--- a/doc/ffprobe.xsd
+++ b/doc/ffprobe.xsd
@@ -247,6 +247,7 @@
+
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index dfa7ff1b24..7e81088c56 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -3071,6 +3071,9 @@ static int show_stream(WriterContext *w, AVFormatContext
*fmt_ctx, int stream_id
print_int("bits_per_sample", av_get_bits_per_sample(par->codec_id));
print_int("initial_padding", par->initial_padding);
+if (par->spatial_ext > 0) {
+print_int("spatial_ext", par->spatial_ext);
+}
break;
case AVMEDIA_TYPE_SUBTITLE:
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 0b120e6140..009acd9ff6 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -1714,6 +1714,7 @@ skip:
if (!err) {
avctx->sample_rate = s->sample_rate;
avctx->bit_rate= s->bit_rate + s->prev_bit_rate;
+avctx->spatial_ext = s->eac3_extension_type_a == 1;
}
if (!avctx->sample_rate) {
diff --git a/libavcodec/ac3dec.h b/libavcodec/ac3dec.h
index 138b462abb..0829f4b40d 100644
--- a/libavcodec/ac3dec.h
+++ b/libavcodec/ac3dec.h
@@ -102,6 +102,7 @@ typedef struct AC3DecodeContext {
int eac3; ///< indicates if current frame is
E-AC-3
int eac3_frame_dependent_found; ///< bitstream has E-AC-3
dependent frame(s)
int eac3_subsbtreamid_found;///< bitstream has E-AC-3
additional substream(s)
+int eac3_extension_type_a; ///< bitstream has E-AC-3
extension type A enabled frame(s)
int dolby_surround_mode;///< dolby surround mode
(dsurmod)
int dolby_surround_ex_mode; ///< dolby surround ex mode
(dsurexmod)
int dolby_headphone_mode; ///< dolby headphone mode
(dheadphonmod)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 755e543fac..8b54a99313 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2104,6 +2104,12 @@ typedef struct AVCodecContext {
* The decoder can then override during decoding as needed.
*/
AVChannelLayout ch_layout;
+
+/**
+ * Audio only. Whether or not a spatial audio extension is
+ * detected in the stream (object-based surround).
+ */
+int spatial_ext;
} AVCodecContext;
/**
diff --git a/libavcodec/codec_par.c b/libavcodec/codec_par.c
index abda649aa8..02f6da5059 100644
--- a/libavcodec/codec_par.c
+++ b/libavcodec/codec_par.c
@@ -161,6 +161,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
par->initial_padding = codec->initial_padding;
par->trailing_padding = codec->trailing_padding;
par->seek_preroll = codec->seek_preroll;
+par->spatial_ext = codec->spatial_ext;
break;
case AVMEDIA_TYPE_SUBTITLE:
par->width = codec->width;
@@ -243,6 +244,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
codec->initial_padding = par->initial_padding;
codec->trailing_padding = par->trailing_padding;
codec->seek_preroll = par->seek_preroll;
+codec->spatial_ext = par->spatial_ext;
break;
case AVMEDIA_TYPE_SUBTITLE:
codec->width = par->width;
diff --git a/libavcodec/codec_par.h b/libavcodec/codec_par.h
index f51d27c590..287b138b6b 100644
--- a/libavcodec/codec_par.h
+++ b/libavcodec/codec_par.h
@@ -211,6 +211,12 @@ typedef struct AVCodecParameters {
* Audio only. The channel layout and number of channels.
*/
AVChannelLayout ch_layout;
+
+/**
+ * Audio only. Whether or not a spatial audio extension is
+ * detected in the stream (object-based surround).
+ */
+int spatial_ext;
} AVCodecParameters;
/**
diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h
index 4d2cd5f56d..ccbc38bb38 100644
--- a/libavcodec/dca_syncwords.h
+++ b/libavcodec/dca_syncwords.h
@@ -33,4 +33,7 @@
#defineDCA_SYNCWORD_SUBSTREAM_CORE 0x02B09261U
#defineDCA_SYNCWORD_REV1AUX 0x9A1105A0U
+#defineDCA_SYNCWORD_XLL_X0x20008
+#define
Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: move help text for -ab/-b:a to audio category
Quoting Marth64 (2023-02-06 19:12:15)
> Since at least 4.4.3, -ab/-b:a help text was in the video section
> of ffmpeg -h, but these are audio options.
>
> Signed-off-by: Marth64
> ---
> fftools/ffmpeg_opt.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index 204be38c94..799dcf071e 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -1637,8 +1637,6 @@ const OptionDef options[] = {
> { "force_key_frames", OPT_VIDEO | OPT_STRING | HAS_ARG | OPT_EXPERT |
>OPT_SPEC | OPT_OUTPUT,
> { .off = OFFSET(forced_key_frames) },
> "force key frames at specified timestamps", "timestamps" },
> -{ "ab", OPT_VIDEO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT,
> { .func_arg = opt_bitrate },
> -"audio bitrate (please use -b:a)", "bitrate" },
> { "b",OPT_VIDEO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT,
> { .func_arg = opt_bitrate },
> "video bitrate (please use -b:v)", "bitrate" },
> { "hwaccel", OPT_VIDEO | OPT_STRING | HAS_ARG | OPT_EXPERT |
> @@ -1680,6 +1678,8 @@ const OptionDef options[] = {
> { "acodec", OPT_AUDIO | HAS_ARG | OPT_PERFILE |
> OPT_INPUT | OPT_OUTPUT,
> { .func_arg = opt_audio_codec },
> "force audio codec ('copy' to copy stream)", "codec" },
> +{ "ab", OPT_AUDIO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT,
> { .func_arg = opt_bitrate },
> +"audio bitrate (please use -b:a)", "bitrate" },
> { "atag", OPT_AUDIO | HAS_ARG | OPT_EXPERT | OPT_PERFILE |
> OPT_OUTPUT,
> { .func_arg = opt_old2new },
> "force audio tag/fourcc", "fourcc/tag" },
Looks ok, will push
--
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] ffprobe: report the corrupt flag on packets
will push tomorrow -- 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] Request for assistance with adding new pixel format (NV12_8L128) in FFmpeg
On Wed, 08 Feb 2023 19:38:07 +0200 Rémi Denis-Courmont wrote: > Le keskiviikkona 8. helmikuuta 2023, 16.27.52 EET Devin Heitmueller a > écrit : > > On Wed, Feb 8, 2023 at 8:08 AM Jean-Baptiste Kempf > > wrote: > > > Do we really need those PIX_FMT in FFmpeg public API? > > > > Tiled formats are annoying, but not uncommon in popular embedded > > platforms (e.g. NXP iMX, TI Davinci). > > Uh, not to deny that, but tiled formats are in no way an embedded > thing, as you imply. They are also used by desktop GPUs. And that is > not really relevant, I would argue, to the discussion, either way. > > > Of course ffmpeg could choose > > to ignore them, but it would effectively prevent it from being used > > on those platforms (and it's pretty essential to use the hardware > > blocks to do any real video processing). > > Insofar as the format is *only* used by a single module, I don't see > the need to assign it a pixel format in libavutil. You could just as > well define a generic V4L format that would be used for all weird V4L > formats that nothing other than V4L code understands. > > Ditto tiled DRM pixel formats for that matter. And while V4L is maybe > not there yet, DRM has introduced format modifiers that anyway > preclude any simple enumeration. My point being, there needs to be a > way to further specify framework-specific formats outside of the > avutil pixel format list, in any case. > I never thought about it this way until you mentioned DRM but I think that's the key insight. If we want to take a leaf out of the DRM book (and wouldn't it be wonderful if these m2m decoders used DRM formats?), then this format would NV12 at the pix fmt layer with a modifier indicating the tiling pattern. When we interact with these kinds of formats in VAAPI, for example, VAAPI encapsulates the heavy lifting required to transfer to/from system memory successfully, and when we are doing everything on the GPU side, we pass the surface long with the modifier to whatever eventually consumes it (eg: Display with GL or Vulkan, or encoding). In none of these cases does ffmpeg code really need to care about the modifier. Maybe we've been thinking about these m2m formats the wrong way. --phil ___ 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] doc/ffmpeg: extend -dts_delta_threshold option description
On Mon, Feb 06, 2023 at 02:25:23AM +0100, Stefano Sabatini wrote:
> On date Wednesday 2023-01-25 10:47:20 +0530, Gyan Doshi wrote:
> >
> >
> > On 2023-01-25 06:37 am, Stefano Sabatini wrote:
> > > ---
> > > doc/ffmpeg.texi | 17 +++--
> > > 1 file changed, 15 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > > index 67b3294256..122f7e3387 100644
> > > --- a/doc/ffmpeg.texi
> > > +++ b/doc/ffmpeg.texi
> > > @@ -1823,8 +1823,21 @@ results, but increase memory use and latency.
> > > The default value is 10 seconds.
> > > -@item -dts_delta_threshold
> > > -Timestamp discontinuity delta threshold.
> > > +@item -dts_delta_threshold @var{threshold}
> > > +Timestamp discontinuity delta threshold, expressed as a floating point
> > > +number of @var{AV_TIME_BASE} units.
> > This is a CLI option and those users don't deal with AV_TIME_BASE . More
> > useful to say it's in seconds.
> >
> > > +
> > > +If a timestamp discontinuity is detected whose absolute value is
> > > +greater than @var{threshold} * @var{AV_TIME_BASE}, ffmpeg will remove the
> > > +discontinuity by decreasing/increasing the current DTS and PTS by the
> > > +corresponding delta value.
> >
>
> > Might want to mention that this only applies to AV_FMT_DISCONT demuxers, or
> > rather give a few examples, like MPEG-TS, HLS..etc.
> > For all other formats that users normally work with, clarify that only
> > dts_error_threshold is relevant.
>
>
> > > +
> > > +Timestamp discontinuity correction can be inhibited by setting a big
> > > value for
> > > +@var{threshold}, and is automatically disabled when employing the
> > > +@code{-copy_ts} option.
> >
> > For copy_ts, it is still applied for all negative deltas except the
> > smallest.
>
> Which is a bit arbitrary.
>
> >
> > Not blocking, but I'm reworking this code at present. Shouldn't really
> > affect this patch. See
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305539.html
>
> Updated (had to review the code to get some clarity on the current
> behavior).
>
> Thanks.
> doc/ffmpeg.texi | 36 ++
> fftools/ffmpeg.c| 72
> +++-
> fftools/ffmpeg.h|2 +
> fftools/ffmpeg_demux.c |3 +
> tests/fate/filter-audio.mak |2 -
> tests/fate/mpeg4.mak|2 -
> 6 files changed, 77 insertions(+), 40 deletions(-)
> 55e91624524749274a62bdc43cacdf8e47dd3598
> 0002-ffmpeg-review-dts_delta_threshold-and-dts_delta_erro.patch
> From 30ac56a14d66eb25428b71c9211f401f818bd057 Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini
> Date: Fri, 1 Apr 2011 01:13:35 +0200
> Subject: [PATCH 2/2] ffmpeg: review -dts_delta_threshold and -dts_delta_error
> options
>
> Review handling of -dts_delta_threshold and -dts_delta_error options,
> specify them as floating point expressed in seconds.
>
> Also, review and simplify logic. Adjust values for tests, since in
> some cases the new values does not trigger the correction logic.
>
> PR: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8252
> ---
> doc/ffmpeg.texi | 36 ---
> fftools/ffmpeg.c| 72 -
> fftools/ffmpeg.h| 2 ++
> fftools/ffmpeg_demux.c | 3 ++
> tests/fate/filter-audio.mak | 2 +-
> tests/fate/mpeg4.mak| 2 +-
> 6 files changed, 77 insertions(+), 40 deletions(-)
This seems to break a case with concat and vsync
./ffmpeg -y -i
'concat:///home/michael/videos/angels.mpg|/home/michael/videos/angels.mpg'
-vsync 0 -an file.avi
...
cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: N/A
[mpeg4 @ 0x55e051b8d4c0] Invalid pts (0) <= last (11)00.00 bitrate=N/A speed=
0x
[vost#0:0/mpeg4 @ 0x55e051b9d700] Error submitting video frame to the encoder
Conversion failed!
Ill mail you the angels.mpg, i think its online somewhere but i cant
find it
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott
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] avfilter: use ff_inlink_make_frame_writable()
On Tue, Feb 07, 2023 at 06:26:17PM +0100, Paul B Mahol wrote: > On 2/6/23, Paul B Mahol wrote: > > Patch attached. > > > > Better patch attached. > avf_abitscope.c | 11 +-- > avf_ahistogram.c |9 +++-- > avf_aphasemeter.c |9 +++-- > avf_avectorscope.c|7 ++- > avf_showspectrum.c|5 - > avf_showvolume.c |8 ++-- > f_ebur128.c | 10 -- > f_perms.c |3 ++- > framesync.c |2 +- > vf_cover_rect.c |9 +++-- > vf_dedot.c|2 +- > vf_floodfill.c|5 - > vf_lensfun.c |8 +++- > vf_overlay_cuda.c |3 ++- > vf_paletteuse.c |2 +- > vf_photosensitivity.c |3 ++- > vf_repeatfields.c | 34 +++--- > vf_signalstats.c | 17 + > vf_telecine.c | 13 +++-- > vf_vidstabdetect.c| 12 +--- > 20 files changed, 134 insertions(+), 38 deletions(-) > 8aabbe97177a141f13eb044580349e7ae1779b7f > 0001-avfilter-use-ff_inlink_make_frame_writable.patch > From 15f004ccb196e39c6c429e2c93041444c1a1e419 Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Mon, 6 Feb 2023 14:57:50 +0100 > Subject: [PATCH] avfilter: use ff_inlink_make_frame_writable() > > Signed-off-by: Paul B Mahol > --- Seems to segfault here in fate unless i missed some patch ==14233== Command: ./ffmpeg_g -nostdin -nostats -noauto_conversion_filters -cpuflags all -auto_conversion_filters -idct simple -hwaccel none -threads 1 -thread_type frame+slice -i fate-suite//smjpeg/scenwin.mjpg -vf trim=duration=0.5,perms=random,owdenoise=10:20:20:enable=not(between(t\\,0.2\\,1.2)) -an -f rawvideo -y /dev/null ==14233== ffmpeg version N-109788-g09fec9674b Copyright (c) 2000-2023 the FFmpeg developers built with gcc 7 (Ubuntu 7.5.0-3ubuntu1~18.04) configuration: --enable-libspeex --enable-libvpx --enable-gpl --cc='ccache gcc' --enable-libopenjpeg --enable-pthreads --enable-debug=3 --cpu=core2 --enable-libvorbis --samples=fate-suite/ --enable-libx264 --enable-debug=3 --enable-libdc1394 --enable-libxvid --enable-libfreetype --enable-nonfree --enable-libmodplug --enable-libpulse --enable-libmp3lame --enable-version3 --enable-libbluray --enable-libxml2 --assert-level=2 --enable-libtheora --enable-openssl --enable-libcaca --enable-libopus --enable-libcdio --enable-openal --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-libgsm --enable-libass --enable-frei0r --enable-libsoxr --enable-libfdk-aac --disable-optimizations --disable-stripping --extra-cflags='-Dav_always_inline=inline' libavutil 57. 44.100 / 57. 44.100 libavcodec 59. 63.100 / 59. 63.100 libavformat59. 38.100 / 59. 38.100 libavdevice59. 8.101 / 59. 8.101 libavfilter 8. 56.100 / 8. 56.100 libswscale 6. 8.112 / 6. 8.112 libswresample 4. 9.100 / 4. 9.100 libpostproc56. 7.100 / 56. 7.100 [mjpeg @ 0x16a0cf00] EOI missing, emulating Guessed Channel Layout for Input Stream #0.0 : mono Input #0, smjpeg, from 'fate-suite//smjpeg/scenwin.mjpg': Duration: 00:00:08.11, start: 0.00, bitrate: 557 kb/s Stream #0:0: Audio: adpcm_ima_smjpeg (APCM / 0x4D435041), 22050 Hz, 1 channels, s16 Stream #0:1: Video: mjpeg (Baseline) (JFIF / 0x4649464A), yuvj420p(pc, bt470bg/unknown/unknown), 320x240 [SAR 1:1 DAR 4:3], 9 fps, 9 tbr, 1k tbn Stream mapping: Stream #0:1 -> #0:0 (mjpeg (native) -> rawvideo (native)) [Parsed_perms_1 @ 0x16b61380] random seed: 0x4e2ee912 [swscaler @ 0x16b9df40] deprecated pixel format used, make sure you did set range correctly ==14233== Invalid read of size 4 ==14233==at 0x2C1C4E: ff_filter_frame (avfilter.c:1011) ==14233==by 0x2D4842: filter_frame (f_perms.c:108) ==14233==by 0x2C1A24: ff_filter_frame_framed (avfilter.c:969) ==14233==by 0x2C20AD: ff_filter_frame_to_filter (avfilter.c:1113) ==14233==by 0x2C22BD: ff_filter_activate_default (avfilter.c:1162) ==14233==by 0x2C241D: ff_filter_activate (avfilter.c:1320) ==14233==by 0x2C70AF: ff_filter_graph_run_once (avfiltergraph.c:1352) ==14233==by 0x2C861F: push_frame (buffersrc.c:169) ==14233==by 0x2C8C8C: av_buffersrc_add_frame_flags (buffersrc.c:258) ==14233==by 0x26F938: ifilter_send_frame (ffmpeg.c:2038) ==14233==by 0x26FCDC: send_frame_to_filters (ffmpeg.c:2124) ==14233==by 0x2709D1: decode_video (ffmpeg.c:2310) ==14233==by 0x27190B: process_input_packet (ffmpeg.c:2599) ==14233==by 0x276B57: process_input (ffmpeg.c:3859) ==14233==by 0x277012: transcode_step (ffmpeg.c:3994) ==14233==by 0x277156: transcode (ffmpeg.c:4041) ==14233==by 0x27768C: main (ffmpeg.c:4179) ==14233== Address 0x16dc6770 is 112 bytes inside a block of size 480 free'd ==14233==at 0x4C32D3B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==14233==by 0x12B1201: av_free (mem.c:251)
Re: [FFmpeg-devel] [PATCH] swresample: try to fix regression
On Wed, 8 Feb 2023, Paul B Mahol wrote:
This one should pass FATE.
diff --git a/libavfilter/af_pan.c b/libavfilter/af_pan.c
index 80c194b066..067f646805 100644
--- a/libavfilter/af_pan.c
+++ b/libavfilter/af_pan.c
@@ -313,9 +313,7 @@ static int config_props(AVFilterLink *link)
pan->channel_map[i] = ch_id;
}
-av_opt_set_chlayout(pan->swr, "ichl", >ch_layout, 0);
-av_opt_set_chlayout(pan->swr, "ochl", >out_channel_layout, 0);
-av_opt_set_int(pan->swr, "uch", link->ch_layout.nb_channels, 0);
+av_opt_set_int(pan->swr, "uch", pan->nb_output_channels, 0);
swr_set_channel_mapping(pan->swr, pan->channel_map);
} else {
// renormalize
@@ -335,8 +333,6 @@ static int config_props(AVFilterLink *link)
for (j = 0; j < link->ch_layout.nb_channels; j++)
pan->gain[i][j] /= t;
}
-av_opt_set_chlayout(pan->swr, "ichl", >ch_layout, 0);
-av_opt_set_chlayout(pan->swr, "ochl", >out_channel_layout, 0);
swr_set_matrix(pan->swr, pan->gain[0], pan->gain[1] - pan->gain[0]);
}
This bit looks like a straight revert of the commit that broke fate, so
that's probably ok.
diff --git a/libswresample/swresample.c b/libswresample/swresample.c
index 5884f8d533..7c8d9bfc97 100644
--- a/libswresample/swresample.c
+++ b/libswresample/swresample.c
@@ -312,9 +312,9 @@ av_cold int swr_init(struct SwrContext *s){
if (s->out_ch_layout.order == AV_CHANNEL_ORDER_UNSPEC)
av_channel_layout_default(>out_ch_layout, s->out.ch_count);
-s->rematrix = av_channel_layout_compare(>out_ch_layout,
>in_ch_layout) ||
+s->rematrix = !s->channel_map && (av_channel_layout_compare(>out_ch_layout,
>in_ch_layout) ||
s->rematrix_volume!=1.0 ||
- s->rematrix_custom;
+ s->rematrix_custom);
if(s->int_sample_fmt == AV_SAMPLE_FMT_NONE){
if( av_get_bytes_per_sample(s-> in_sample_fmt) <= 2
I really can't say about this part of the patch though...
Can we maybe just do it in two parts - revert the patch that broke fate
and find someone other than me to comment on the swresample bit?
// Martin
___
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] Request for assistance with adding new pixel format (NV12_8L128) in FFmpeg
Hi Remi, On Wed, Feb 8, 2023 at 12:38 PM Rémi Denis-Courmont wrote: > Uh, not to deny that, but tiled formats are in no way an embedded thing, as > you imply. They are also used by desktop GPUs. And that is not really > relevant, I would argue, to the discussion, either way. I don't disagree that tiled formats can be found on desktop GPUs. My only point was that the importance of being able to pass through the native format is much greater with embedded SOCs since in many cases on desktops you have enough CPU power to get away with doing a conversion. Also, you're more likely to find that desktop GPUs which support tiled formats also support formats that are likely to be supported by ffmpeg today. This is less likely to be the case with embedded SOCs. > > Of course ffmpeg could choose > > to ignore them, but it would effectively prevent it from being used on > > those platforms (and it's pretty essential to use the hardware blocks > > to do any real video processing). > > Insofar as the format is *only* used by a single module, I don't see the need > to assign it a pixel format in libavutil. You could just as well define a > generic V4L format that would be used for all weird V4L formats that nothing > other than V4L code understands. In many cases the lack of support for a pixel format may be the reason that more platforms aren't supported. Somebody has got to be the first. Suggesting that it's only used by a single module may be the effect of not supporting the pixel format, not the other way around. This is not to suggest that like most developers I don't hate the fact that there are so many different pixel formats out there, and with each new format proposed for addition to ffmpeg we have the same arguments. > Ditto tiled DRM pixel formats for that matter. And while V4L is maybe not > there yet, DRM has introduced format modifiers that anyway preclude any simple > enumeration. My point being, there needs to be a way to further specify > framework-specific formats outside of the avutil pixel format list, in any > case. I can't really offer an opinion on the implementation detail regarding the avutil pixel format list. I suspect the OP is open to alternative approaches as long as the original requirement is met. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com ___ 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] swresample: try to fix regression
This one should pass FATE.
From ca54f241756e764f70c919acd0c99c811762dcb1 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Wed, 8 Feb 2023 18:35:38 +0100
Subject: [PATCH] swresample: do not attempt to rematrix if channel map is
provided
Signed-off-by: Paul B Mahol
---
libavfilter/af_pan.c | 6 +-
libswresample/swresample.c | 4 ++--
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/libavfilter/af_pan.c b/libavfilter/af_pan.c
index 80c194b066..067f646805 100644
--- a/libavfilter/af_pan.c
+++ b/libavfilter/af_pan.c
@@ -313,9 +313,7 @@ static int config_props(AVFilterLink *link)
pan->channel_map[i] = ch_id;
}
-av_opt_set_chlayout(pan->swr, "ichl", >ch_layout, 0);
-av_opt_set_chlayout(pan->swr, "ochl", >out_channel_layout, 0);
-av_opt_set_int(pan->swr, "uch", link->ch_layout.nb_channels, 0);
+av_opt_set_int(pan->swr, "uch", pan->nb_output_channels, 0);
swr_set_channel_mapping(pan->swr, pan->channel_map);
} else {
// renormalize
@@ -335,8 +333,6 @@ static int config_props(AVFilterLink *link)
for (j = 0; j < link->ch_layout.nb_channels; j++)
pan->gain[i][j] /= t;
}
-av_opt_set_chlayout(pan->swr, "ichl", >ch_layout, 0);
-av_opt_set_chlayout(pan->swr, "ochl", >out_channel_layout, 0);
swr_set_matrix(pan->swr, pan->gain[0], pan->gain[1] - pan->gain[0]);
}
diff --git a/libswresample/swresample.c b/libswresample/swresample.c
index 5884f8d533..7c8d9bfc97 100644
--- a/libswresample/swresample.c
+++ b/libswresample/swresample.c
@@ -312,9 +312,9 @@ av_cold int swr_init(struct SwrContext *s){
if (s->out_ch_layout.order == AV_CHANNEL_ORDER_UNSPEC)
av_channel_layout_default(>out_ch_layout, s->out.ch_count);
-s->rematrix = av_channel_layout_compare(>out_ch_layout, >in_ch_layout) ||
+s->rematrix = !s->channel_map && (av_channel_layout_compare(>out_ch_layout, >in_ch_layout) ||
s->rematrix_volume!=1.0 ||
- s->rematrix_custom;
+ s->rematrix_custom);
if(s->int_sample_fmt == AV_SAMPLE_FMT_NONE){
if( av_get_bytes_per_sample(s-> in_sample_fmt) <= 2
--
2.39.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] Request for assistance with adding new pixel format (NV12_8L128) in FFmpeg
Le keskiviikkona 8. helmikuuta 2023, 16.27.52 EET Devin Heitmueller a écrit : > On Wed, Feb 8, 2023 at 8:08 AM Jean-Baptiste Kempf wrote: > > Do we really need those PIX_FMT in FFmpeg public API? > > Tiled formats are annoying, but not uncommon in popular embedded > platforms (e.g. NXP iMX, TI Davinci). Uh, not to deny that, but tiled formats are in no way an embedded thing, as you imply. They are also used by desktop GPUs. And that is not really relevant, I would argue, to the discussion, either way. > Of course ffmpeg could choose > to ignore them, but it would effectively prevent it from being used on > those platforms (and it's pretty essential to use the hardware blocks > to do any real video processing). Insofar as the format is *only* used by a single module, I don't see the need to assign it a pixel format in libavutil. You could just as well define a generic V4L format that would be used for all weird V4L formats that nothing other than V4L code understands. Ditto tiled DRM pixel formats for that matter. And while V4L is maybe not there yet, DRM has introduced format modifiers that anyway preclude any simple enumeration. My point being, there needs to be a way to further specify framework-specific formats outside of the avutil pixel format list, in any case. -- レミ・デニ-クールモン http://www.remlab.net/ ___ 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] fftools/ffmpeg: add an option for writing pre-muxing stats
Quoting Devin Heitmueller (2023-02-08 16:59:43) > On Wed, Feb 8, 2023 at 8:54 AM Anton Khirnov wrote: > > Muxers are fundamentally consume-only, I don't see what stats could > > possibly be printed after muxing, even conceptually. > > I can offer some examples, in particular because I generate lots of > such statistics after muxing in my private tree. > > - Decklink output statistics - late arrival and drop counts for audio > and video packets, pipeline latency (time between submission to the > hardware and the callback indicating frame was played out), FIFO > levels within the module, video frames actually played out in last > second, audio samples played out in last second. > > - SRT output - various SRT related statistics (lost packets, > retransmits, connection RTT, etc) > > - HLS output - counters for various HTTP recoverable events (HTTP > redirects, resends, etc), packets written Hmm, I have not considered it but you're right that this information could be exported via AVOptions and printed by ffmpeg CLI. I'll send a patch with the renames then. -- 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/4] avformat: add av_program_copy()
On 2023-02-08 08:47 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2023-02-07 15:58:47) Needed to transfer programs in parent muxing contexts to child muxers, like in hls, segment, tee muxers. If it's only intended for use in muxers, why is it public? Could have worded the msg better. The intention wasn't to limit this internally. The fn is motivated by a CLI HLS user's troubleshhoting but it is useful to any API user who uses the public av_new_program and then copies the data manually. That reminds me, I should update this to check for existing programs. Regards, 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 2/2] fftools/ffmpeg: add an option for writing pre-muxing stats
On Wed, Feb 8, 2023 at 8:54 AM Anton Khirnov wrote: > Muxers are fundamentally consume-only, I don't see what stats could > possibly be printed after muxing, even conceptually. I can offer some examples, in particular because I generate lots of such statistics after muxing in my private tree. - Decklink output statistics - late arrival and drop counts for audio and video packets, pipeline latency (time between submission to the hardware and the callback indicating frame was played out), FIFO levels within the module, video frames actually played out in last second, audio samples played out in last second. - SRT output - various SRT related statistics (lost packets, retransmits, connection RTT, etc) - HLS output - counters for various HTTP recoverable events (HTTP redirects, resends, etc), packets written Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com ___ 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] doc: Merge doc/dev_community/* and Code of Conduct into a seperate file
Remove doc/dev_communit markup files completely as they are at the wrong place.
Create a new community page, merging all of doc/dev_community and subsection
Code of Conduct into a common place.
The corresponding patch to ffmpeg-web puts the Organisation & Code of Conduct
into a seperate community chapter on the FFmpeg website.
---
doc/Makefile| 1 +
doc/community.texi | 173
doc/dev_community/community.md | 83
doc/dev_community/resolution_process.md | 91 -
doc/developer.texi | 29
doc/mailing-list-faq.texi | 2 +-
6 files changed, 175 insertions(+), 204 deletions(-)
create mode 100644 doc/community.texi
delete mode 100644 doc/dev_community/community.md
delete mode 100644 doc/dev_community/resolution_process.md
diff --git a/doc/Makefile b/doc/Makefile
index 25774c7bad..67586e4b74 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -19,6 +19,7 @@ MANPAGES3 = $(LIBRARIES-yes:%=doc/%.3)
MANPAGES= $(MANPAGES1) $(MANPAGES3)
PODPAGES= $(AVPROGS-yes:%=doc/%.pod) $(AVPROGS-yes:%=doc/%-all.pod)
$(COMPONENTS-yes:%=doc/%.pod) $(LIBRARIES-yes:%=doc/%.pod)
HTMLPAGES = $(AVPROGS-yes:%=doc/%.html) $(AVPROGS-yes:%=doc/%-all.html)
$(COMPONENTS-yes:%=doc/%.html) $(LIBRARIES-yes:%=doc/%.html) \
+ doc/community.html\
doc/developer.html\
doc/faq.html \
doc/fate.html \
diff --git a/doc/community.texi b/doc/community.texi
new file mode 100644
index 00..21125d34d2
--- /dev/null
+++ b/doc/community.texi
@@ -0,0 +1,173 @@
+\input texinfo @c -*- texinfo -*-
+@documentencoding UTF-8
+
+@settitle Community
+@titlepage
+@center @titlefont{Community}
+@end titlepage
+
+@top
+
+@contents
+
+@anchor{Organisation}
+@chapter Organisation
+
+The FFmpeg project is organized through a community working on global
consensus.
+
+Decisions are taken by the ensemble of active members, through voting and are
aided by two committees.
+
+@anchor{General Assembly}
+@chapter General Assembly
+
+The ensemble of active members is called the General Assembly (GA).
+
+The General Assembly is sovereign and legitimate for all its decisions
regarding the FFmpeg project.
+
+The General Assembly is made up of active contributors.
+
+Contributors are considered "active contributors" if they have pushed more
than 20 patches in the last 36 months in the main FFmpeg repository, or if they
have been voted in by the GA.
+
+Additional members are added to the General Assembly through a vote after
proposal by a member of the General Assembly. They are part of the GA for two
years, after which they need a confirmation by the GA.
+
+@anchor{Voting}
+@chapter Voting
+
+Voting is done using a ranked voting system, currently running on
https://vote.ffmpeg.org/ .
+
+Majority vote means more than 50% of the expressed ballots.
+
+@anchor{Technical Committee}
+@chapter Technical Committee
+
+The Technical Committee (TC) is here to arbitrate and make decisions when
technical conflicts occur in the project. They will consider the merits of all
the positions, judge them and make a decision.
+
+The TC resolves technical conflicts but is not a technical steering committee.
+
+Decisions by the TC are binding for all the contributors.
+
+Decisions made by the TC can be re-opened after 1 year or by a majority vote
of the General Assembly, requested by one of the member of the GA.
+
+The TC is elected by the General Assembly for a duration of 1 year, and is
composed of 5 members. Members can be re-elected if they wish. A majority vote
in the General Assembly can trigger a new election of the TC.
+
+The members of the TC can be elected from outside of the GA. Candidates for
election can either be suggested or self-nominated.
+
+The conflict resolution process is detailed in the resolution process document.
+
+The TC can be contacted at .
+
+@anchor{Resolution Process}
+@section Resolution Process
+
+The Technical Committee (TC) is here to arbitrate and make decisions when
technical conflicts occur in the project.
+
+The TC main role is to resolve technical conflicts. It is therefore not a
technical steering committee, but it is understood that some decisions might
impact the future of the project.
+
+@subsection Seizing
+
+The TC can take possession of any technical matter that it sees fit.
+
+To involve the TC in a matter, email tc@ or CC them on an ongoing discussion.
+
+As members of TC are developers, they also can email tc@ to raise an issue.
+@subsection Announcement
+
+The TC, once seized, must announce itself on the main mailing list, with a
[TC] tag.
+
+The TC has 2 modes of operation: a RFC one and an internal one.
+
+If the TC thinks it needs the input
[FFmpeg-devel] [PATCH 1/2] doc/dev_community: add the addresses of the committees
From: Nicolas George Omitting the .org from the address should be protection enough against spam spiders. Signed-off-by: Nicolas George --- doc/dev_community/community.md | 4 1 file changed, 4 insertions(+) diff --git a/doc/dev_community/community.md b/doc/dev_community/community.md index 21e08e20e3..59519393e2 100644 --- a/doc/dev_community/community.md +++ b/doc/dev_community/community.md @@ -55,6 +55,8 @@ Candidates for election can either be suggested or self-nominated. The conflict resolution process is detailed in the [resolution process](resolution_process.md) document. +The TC can be contacted at . + ## Community committee The Community Committee (CC) is here to arbitrage and make decisions when @@ -77,3 +79,5 @@ The members of the CC can be elected from outside of the GA. Candidates for election can either be suggested or self-nominated. The CC is governed by and responsible for enforcing the Code of Conduct. + +The CC can be contacted at . -- 2.20.1 (Apple Git-117) ___ 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] doc/dev_community: add the addresses of the committees
Pls ignnore this as well... I'll send the actual patch now patching two repos is confusing, sorry for spam. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc: Merge doc/dev_community/* and Code of Conduct into a seperate file
Am 08.02.23 um 16:45 schrieb Thilo Borgmann: Remove doc/dev_communit markup files completely as they are at the wrong place. Create a new community page, merging all of doc/dev_community and subsection Code of Conduct into a common place. The corresponding patch to ffmpeg-web puts the Organisation & Code of Conduct into a seperate community chapter on the FFmpeg website. --- doc/Makefile| 1 + doc/community.texi | 169 doc/dev_community/community.md | 83 doc/dev_community/resolution_process.md | 91 - doc/developer.texi | 29 doc/mailing-list-faq.texi | 2 +- 6 files changed, 171 insertions(+), 204 deletions(-) create mode 100644 doc/community.texi delete mode 100644 doc/dev_community/community.md delete mode 100644 doc/dev_community/resolution_process.md Pls ignore this, a patchset replacing this had been submitted to -devel. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] doc: Merge doc/dev_community/* and Code of Conduct into a seperate file
Remove doc/dev_communit markup files completely as they are at the wrong place.
Create a new community page, merging all of doc/dev_community and subsection
Code of Conduct into a common place.
The corresponding patch to ffmpeg-web puts the Organisation & Code of Conduct
into a seperate community chapter on the FFmpeg website.
---
doc/Makefile| 1 +
doc/community.texi | 169
doc/dev_community/community.md | 83
doc/dev_community/resolution_process.md | 91 -
doc/developer.texi | 29
doc/mailing-list-faq.texi | 2 +-
6 files changed, 171 insertions(+), 204 deletions(-)
create mode 100644 doc/community.texi
delete mode 100644 doc/dev_community/community.md
delete mode 100644 doc/dev_community/resolution_process.md
diff --git a/doc/Makefile b/doc/Makefile
index 25774c7bad..67586e4b74 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -19,6 +19,7 @@ MANPAGES3 = $(LIBRARIES-yes:%=doc/%.3)
MANPAGES= $(MANPAGES1) $(MANPAGES3)
PODPAGES= $(AVPROGS-yes:%=doc/%.pod) $(AVPROGS-yes:%=doc/%-all.pod)
$(COMPONENTS-yes:%=doc/%.pod) $(LIBRARIES-yes:%=doc/%.pod)
HTMLPAGES = $(AVPROGS-yes:%=doc/%.html) $(AVPROGS-yes:%=doc/%-all.html)
$(COMPONENTS-yes:%=doc/%.html) $(LIBRARIES-yes:%=doc/%.html) \
+ doc/community.html\
doc/developer.html\
doc/faq.html \
doc/fate.html \
diff --git a/doc/community.texi b/doc/community.texi
new file mode 100644
index 00..92e62bde5c
--- /dev/null
+++ b/doc/community.texi
@@ -0,0 +1,169 @@
+\input texinfo @c -*- texinfo -*-
+@documentencoding UTF-8
+
+@settitle Community
+@titlepage
+@center @titlefont{Community}
+@end titlepage
+
+@top
+
+@contents
+
+@anchor{Organisation}
+@chapter Organisation
+
+The FFmpeg project is organized through a community working on global
consensus.
+
+Decisions are taken by the ensemble of active members, through voting and are
aided by two committees.
+
+@anchor{General Assembly}
+@chapter General Assembly
+
+The ensemble of active members is called the General Assembly (GA).
+
+The General Assembly is sovereign and legitimate for all its decisions
regarding the FFmpeg project.
+
+The General Assembly is made up of active contributors.
+
+Contributors are considered "active contributors" if they have pushed more
than 20 patches in the last 36 months in the main FFmpeg repository, or if they
have been voted in by the GA.
+
+Additional members are added to the General Assembly through a vote after
proposal by a member of the General Assembly. They are part of the GA for two
years, after which they need a confirmation by the GA.
+
+@anchor{Voting}
+@chapter Voting
+
+Voting is done using a ranked voting system, currently running on
https://vote.ffmpeg.org/ .
+
+Majority vote means more than 50% of the expressed ballots.
+
+@anchor{Technical Committee}
+@chapter Technical Committee
+
+The Technical Committee (TC) is here to arbitrate and make decisions when
technical conflicts occur in the project. They will consider the merits of all
the positions, judge them and make a decision.
+
+The TC resolves technical conflicts but is not a technical steering committee.
+
+Decisions by the TC are binding for all the contributors.
+
+Decisions made by the TC can be re-opened after 1 year or by a majority vote
of the General Assembly, requested by one of the member of the GA.
+
+The TC is elected by the General Assembly for a duration of 1 year, and is
composed of 5 members. Members can be re-elected if they wish. A majority vote
in the General Assembly can trigger a new election of the TC.
+
+The members of the TC can be elected from outside of the GA. Candidates for
election can either be suggested or self-nominated.
+
+The conflict resolution process is detailed in the resolution process document.
+
+@anchor{Resolution Process}
+@section Resolution Process
+
+The Technical Committee (TC) is here to arbitrate and make decisions when
technical conflicts occur in the project.
+
+The TC main role is to resolve technical conflicts. It is therefore not a
technical steering committee, but it is understood that some decisions might
impact the future of the project.
+
+@subsection Seizing
+
+The TC can take possession of any technical matter that it sees fit.
+
+To involve the TC in a matter, email tc@ or CC them on an ongoing discussion.
+
+As members of TC are developers, they also can email tc@ to raise an issue.
+@subsection Announcement
+
+The TC, once seized, must announce itself on the main mailing list, with a
[TC] tag.
+
+The TC has 2 modes of operation: a RFC one and an internal one.
+
+If the TC thinks it needs the input from the larger community, the
[FFmpeg-devel] [PATCH 1/2] doc/dev_community: add the addresses of the committees
From: Nicolas George Omitting the .org from the address should be protection enough against spam spiders. Signed-off-by: Nicolas George --- doc/dev_community/community.md | 4 1 file changed, 4 insertions(+) diff --git a/doc/dev_community/community.md b/doc/dev_community/community.md index 21e08e20e3..59519393e2 100644 --- a/doc/dev_community/community.md +++ b/doc/dev_community/community.md @@ -55,6 +55,8 @@ Candidates for election can either be suggested or self-nominated. The conflict resolution process is detailed in the [resolution process](resolution_process.md) document. +The TC can be contacted at . + ## Community committee The Community Committee (CC) is here to arbitrage and make decisions when @@ -77,3 +79,5 @@ The members of the CC can be elected from outside of the GA. Candidates for election can either be suggested or self-nominated. The CC is governed by and responsible for enforcing the Code of Conduct. + +The CC can be contacted at . -- 2.20.1 (Apple Git-117) ___ 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/2] tools: add general_assembly.pl
Since Nicolas did not follow up, shall we go ahead and push this? Something so simple really should not be stuck in place for a year. -- 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] src/template_head2: Make "community" a seperate page containing Organisation and Code of Conduct.
Forgot to put this in the subject, this patch is for ffmpeg-web, of course. -Thilo Am 08.02.23 um 16:47 schrieb Thilo Borgmann: --- src/template_head2 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/template_head2 b/src/template_head2 index a0b11ab..7ba634b 100644 --- a/src/template_head2 +++ b/src/template_head2 @@ -21,8 +21,9 @@ News Download Documentation - Community + Community + Code of Conduct Mailing Lists IRC Forums ___ 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] src/template_head2: Make "community" a seperate page containing Organisation and Code of Conduct.
--- src/template_head2 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/template_head2 b/src/template_head2 index a0b11ab..7ba634b 100644 --- a/src/template_head2 +++ b/src/template_head2 @@ -21,8 +21,9 @@ News Download Documentation - Community + Community + Code of Conduct Mailing Lists IRC Forums -- 2.20.1 (Apple Git-117) ___ 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] doc: Merge doc/dev_community/* and Code of Conduct into a seperate file
Remove doc/dev_communit markup files completely as they are at the wrong place.
Create a new community page, merging all of doc/dev_community and subsection
Code of Conduct into a common place.
The corresponding patch to ffmpeg-web puts the Organisation & Code of Conduct
into a seperate community chapter on the FFmpeg website.
---
doc/Makefile| 1 +
doc/community.texi | 169
doc/dev_community/community.md | 83
doc/dev_community/resolution_process.md | 91 -
doc/developer.texi | 29
doc/mailing-list-faq.texi | 2 +-
6 files changed, 171 insertions(+), 204 deletions(-)
create mode 100644 doc/community.texi
delete mode 100644 doc/dev_community/community.md
delete mode 100644 doc/dev_community/resolution_process.md
diff --git a/doc/Makefile b/doc/Makefile
index 25774c7bad..67586e4b74 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -19,6 +19,7 @@ MANPAGES3 = $(LIBRARIES-yes:%=doc/%.3)
MANPAGES= $(MANPAGES1) $(MANPAGES3)
PODPAGES= $(AVPROGS-yes:%=doc/%.pod) $(AVPROGS-yes:%=doc/%-all.pod)
$(COMPONENTS-yes:%=doc/%.pod) $(LIBRARIES-yes:%=doc/%.pod)
HTMLPAGES = $(AVPROGS-yes:%=doc/%.html) $(AVPROGS-yes:%=doc/%-all.html)
$(COMPONENTS-yes:%=doc/%.html) $(LIBRARIES-yes:%=doc/%.html) \
+ doc/community.html\
doc/developer.html\
doc/faq.html \
doc/fate.html \
diff --git a/doc/community.texi b/doc/community.texi
new file mode 100644
index 00..92e62bde5c
--- /dev/null
+++ b/doc/community.texi
@@ -0,0 +1,169 @@
+\input texinfo @c -*- texinfo -*-
+@documentencoding UTF-8
+
+@settitle Community
+@titlepage
+@center @titlefont{Community}
+@end titlepage
+
+@top
+
+@contents
+
+@anchor{Organisation}
+@chapter Organisation
+
+The FFmpeg project is organized through a community working on global
consensus.
+
+Decisions are taken by the ensemble of active members, through voting and are
aided by two committees.
+
+@anchor{General Assembly}
+@chapter General Assembly
+
+The ensemble of active members is called the General Assembly (GA).
+
+The General Assembly is sovereign and legitimate for all its decisions
regarding the FFmpeg project.
+
+The General Assembly is made up of active contributors.
+
+Contributors are considered "active contributors" if they have pushed more
than 20 patches in the last 36 months in the main FFmpeg repository, or if they
have been voted in by the GA.
+
+Additional members are added to the General Assembly through a vote after
proposal by a member of the General Assembly. They are part of the GA for two
years, after which they need a confirmation by the GA.
+
+@anchor{Voting}
+@chapter Voting
+
+Voting is done using a ranked voting system, currently running on
https://vote.ffmpeg.org/ .
+
+Majority vote means more than 50% of the expressed ballots.
+
+@anchor{Technical Committee}
+@chapter Technical Committee
+
+The Technical Committee (TC) is here to arbitrate and make decisions when
technical conflicts occur in the project. They will consider the merits of all
the positions, judge them and make a decision.
+
+The TC resolves technical conflicts but is not a technical steering committee.
+
+Decisions by the TC are binding for all the contributors.
+
+Decisions made by the TC can be re-opened after 1 year or by a majority vote
of the General Assembly, requested by one of the member of the GA.
+
+The TC is elected by the General Assembly for a duration of 1 year, and is
composed of 5 members. Members can be re-elected if they wish. A majority vote
in the General Assembly can trigger a new election of the TC.
+
+The members of the TC can be elected from outside of the GA. Candidates for
election can either be suggested or self-nominated.
+
+The conflict resolution process is detailed in the resolution process document.
+
+@anchor{Resolution Process}
+@section Resolution Process
+
+The Technical Committee (TC) is here to arbitrate and make decisions when
technical conflicts occur in the project.
+
+The TC main role is to resolve technical conflicts. It is therefore not a
technical steering committee, but it is understood that some decisions might
impact the future of the project.
+
+@subsection Seizing
+
+The TC can take possession of any technical matter that it sees fit.
+
+To involve the TC in a matter, email tc@ or CC them on an ongoing discussion.
+
+As members of TC are developers, they also can email tc@ to raise an issue.
+@subsection Announcement
+
+The TC, once seized, must announce itself on the main mailing list, with a
[TC] tag.
+
+The TC has 2 modes of operation: a RFC one and an internal one.
+
+If the TC thinks it needs the input from the larger community, the
Re: [FFmpeg-devel] [PATCH 1/4] avformat: add av_program_copy()
Quoting Gyan Doshi (2023-02-07 15:58:47) > Needed to transfer programs in parent muxing contexts to child muxers, > like in hls, segment, tee muxers. If it's only intended for use in muxers, why is it public? -- 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/1] avformat/assenc: avoid incorrect copy of null terminator
On 27/01/2023 17:20, Tim Angus wrote: When writing a subtitle SSA/ASS subtitle file, the AVCodecParameters::extradata buffer is written directly to the output. In the case where the buffer is filled from a matroska source file produced by some older versions of Handbrake, this buffer ends with a null terminating character, which is then erroneously copied into the middle of the output file. The refactoring here avoids this problem by copying the source buffer, manually null terminating it, then treating it as a string rather than a raw buffer. This way it is agnostic as to whether the source buffer was null terminated or not. Could somebody give this a look please? 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] sws/utils.c: Do not uselessly call initFilter() when unscaling
fre 2023-02-03 klockan 10:51 +0100 skrev Tomas Härdin: > ons 2023-02-01 klockan 13:25 +0100 skrev Michael Niedermayer: > > On Tue, Jan 31, 2023 at 04:54:46PM +0100, Tomas Härdin wrote: > > > Passes FATE > > > > > > /Tomas > > > > > utils.c | 62 +++-- > > > -- > > > --- > > > 1 file changed, 31 insertions(+), 31 deletions(-) > > > 4d695be7739560358464400f1c7839b3646ff717 0001-sws-utils.c-Do- > > > not- > > > uselessly-call-initFilter-when-un.patch > > > From 485b779b06085ca0b51eaf33a56f6ddade05b3c1 Mon Sep 17 00:00:00 > > > 2001 > > > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= > > > Date: Tue, 31 Jan 2023 16:33:21 +0100 > > > Subject: [PATCH] sws/utils.c: Do not uselessly call initFilter() > > > when > > > unscaling > > > > LGTM > > > > thx > > I'll push it later today Pushed, somewhat late /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Request for assistance with adding new pixel format (NV12_8L128) in FFmpeg
On Wed, Feb 8, 2023 at 8:08 AM Jean-Baptiste Kempf wrote: > Do we really need those PIX_FMT in FFmpeg public API? Tiled formats are annoying, but not uncommon in popular embedded platforms (e.g. NXP iMX, TI Davinci). Of course ffmpeg could choose to ignore them, but it would effectively prevent it from being used on those platforms (and it's pretty essential to use the hardware blocks to do any real video processing). In the past there was an expectation that adding new pixel formats required the contributor to also add corresponding routines to swscale to convert to more common formats that ffmpeg works with. You could alternatively treat it as a packet format and require a decoder to do the conversion to something more common to ffmpeg, but this would both be expensive (in terms of CPU usage and memory copying) and effectively prevent you from being able to capture or decode in the native format and then hand off those buffers to other hardware blocks like encoders, colorspace conversion, etc. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com ___ 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 1/3] avcodec/pngenc: avoid writing cICP when inappropriate
On 2/7/23 14:17, Leo Izen wrote: On 2/2/23 10:09, Leo Izen wrote: We parse the fallback cHRM on decode and correctly determine that we have BT.709 primaries, but unknown TRC. This causes us to write cICP where we shouldn't. Primaries without transfer can be handled entirely by cHRM, so we should only write cICP if we actually know the transfer function. Additionally, we should avoid writing cICP if there's an ICC profile because the spec says decoders must prioritize cICP over the ICC profile. Andreas has an issue with one of the other patches, but as this first one is just a fix I'll apply it soon if there's no objections. - Leo Izen (thebombzen) Pushed just this one patch. The other two are still open for review. - Leo Izen (thebombzen) ___ 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] fftools/ffmpeg: add an option for writing pre-muxing stats
Quoting Tim Harris (2023-02-07 18:19:48)
> > > Am 07.02.23 um 10:41 schrieb Anton Khirnov:
> > > Also, I'm wondering if we shouldn't rename the options to
> > > -stats_{mux,enc_pre,enc_post}[_fmt] for consistency.
> > > They were added just recently, so it should be fine if done before the
> > > release.
> > >
> > > Opinions?
> >
> > I'd like that. Can't comment on the code itself, though.
> >
>
> -stats_mux_pre (in case we want to report stats post muxing in the future?)
Muxers are fundamentally consume-only, I don't see what stats could
possibly be printed after muxing, even conceptually.
--
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] Request for assistance with adding new pixel format (NV12_8L128) in FFmpeg
On Wed, Feb 8, 2023 at 2:08 PM Jean-Baptiste Kempf wrote: > > On Wed, 8 Feb 2023, at 10:47, Le Bao Tin Ha wrote: > > Hello, you can found the explanation here: > > > > https://docs.kernel.org/userspace-api/media/v4l/pixfmt-yuv-planar.html > > > > "V4L2_PIX_FMT_NV12M_8L128 is similar to V4L2_PIX_FMT_NV12M but stores > > pixels in 2D 8x128 tiles, and stores tiles linearly in memory. The > > image height must be aligned to a multiple of 128. The layouts of the > > luma and chroma planes are identical. > > > > V4L2_PIX_FMT_NV12_8L128 is similar to V4L2_PIX_FMT_NV12M_8L128 but > > stores two planes in one memory." > > Do we really need those PIX_FMT in FFmpeg public API? > Tiled formats also really don't fit into our format definitions, and would not work with any generic pixel format handling code, as far as I can tell. - Hendrik ___ 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] Request for assistance with adding new pixel format (NV12_8L128) in FFmpeg
On Wed, 8 Feb 2023, at 10:47, Le Bao Tin Ha wrote: > Hello, you can found the explanation here: > > https://docs.kernel.org/userspace-api/media/v4l/pixfmt-yuv-planar.html > > "V4L2_PIX_FMT_NV12M_8L128 is similar to V4L2_PIX_FMT_NV12M but stores > pixels in 2D 8x128 tiles, and stores tiles linearly in memory. The > image height must be aligned to a multiple of 128. The layouts of the > luma and chroma planes are identical. > > V4L2_PIX_FMT_NV12_8L128 is similar to V4L2_PIX_FMT_NV12M_8L128 but > stores two planes in one memory." Do we really need those PIX_FMT in FFmpeg public API? -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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/vp9:add skip-loop-filter flag
---
libavcodec/vp9.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 7c0a246446..ebb89a413c 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1371,7 +1371,7 @@ static int decode_tiles(AVCodecContext *avctx,
}
// loopfilter one row
-if (s->s.h.filter.level) {
+if (s->s.h.filter.level && !avctx->skip_loop_filter) {
yoff2 = yoff;
uvoff2 = uvoff;
lflvl_ptr = s->lflvl;
@@ -1486,7 +1486,7 @@ int loopfilter_proc(AVCodecContext *avctx)
for (i = 0; i < s->sb_rows; i++) {
vp9_await_tile_progress(s, i, s->s.h.tiling.tile_cols);
-if (s->s.h.filter.level) {
+if (s->s.h.filter.level && !avctx->skip_loop_filter) {
yoff = (ls_y * 64)*i;
uvoff = (ls_uv * 64 >> s->ss_v)*i;
lflvl_ptr = s->lflvl+s->sb_cols*i;
--
2.32.0 (Apple Git-132)
___
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] Request for assistance with adding new pixel format (NV12_8L128) in FFmpeg
Hello, you can found the explanation here: https://docs.kernel.org/userspace-api/media/v4l/pixfmt-yuv-planar.html "V4L2_PIX_FMT_NV12M_8L128 is similar to V4L2_PIX_FMT_NV12M but stores pixels in 2D 8x128 tiles, and stores tiles linearly in memory. The image height must be aligned to a multiple of 128. The layouts of the luma and chroma planes are identical. V4L2_PIX_FMT_NV12_8L128 is similar to V4L2_PIX_FMT_NV12M_8L128 but stores two planes in one memory." - Original Message - From: "Kieran Kunhya" To: "FFmpeg development discussions and patches" Sent: Monday, February 6, 2023 7:15:22 PM Subject: Re: [FFmpeg-devel] Request for assistance with adding new pixel format (NV12_8L128) in FFmpeg On Mon, 6 Feb 2023 at 15:43, Le Bao Tin Ha wrote: > I hope this email finds you well. I am currently working on the Toradex > Apalis iMX8QM board and I am trying to perform a hardware decode using the > Amphion driver with ffmpeg h264_v4l2m2m codec. The decoder outputs a pixel > format (NV12_8L128, a linear 8x128 NV12 based tiles) that is not supported > yet by FFmpeg. > Hello, Are you able to provide more information about this nonstandard pixel format? Kieran ___ 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: use ff_inlink_make_frame_writable()
Paul B Mahol (12023-02-07):
> On 2/6/23, Paul B Mahol wrote:
> > Patch attached.
> >
>
> Better patch attached.
> From 15f004ccb196e39c6c429e2c93041444c1a1e419 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Mon, 6 Feb 2023 14:57:50 +0100
> Subject: [PATCH] avfilter: use ff_inlink_make_frame_writable()
>
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/avf_abitscope.c | 11 --
> libavfilter/avf_ahistogram.c | 9 ++--
> libavfilter/avf_aphasemeter.c | 9 ++--
> libavfilter/avf_avectorscope.c| 7 ++-
> libavfilter/avf_showspectrum.c| 5 -
> libavfilter/avf_showvolume.c | 8 ++--
> libavfilter/f_ebur128.c | 10 +++--
> libavfilter/f_perms.c | 3 ++-
> libavfilter/framesync.c | 2 +-
> libavfilter/vf_cover_rect.c | 9 ++--
> libavfilter/vf_dedot.c| 2 +-
> libavfilter/vf_floodfill.c| 5 -
> libavfilter/vf_lensfun.c | 8 +++-
> libavfilter/vf_overlay_cuda.c | 3 ++-
> libavfilter/vf_paletteuse.c | 2 +-
> libavfilter/vf_photosensitivity.c | 3 ++-
> libavfilter/vf_repeatfields.c | 34 ---
> libavfilter/vf_signalstats.c | 17
> libavfilter/vf_telecine.c | 13 ++--
> libavfilter/vf_vidstabdetect.c| 12 ---
> 20 files changed, 134 insertions(+), 38 deletions(-)
>
> diff --git a/libavfilter/avf_abitscope.c b/libavfilter/avf_abitscope.c
> index 4fc3c06ecb..782d57e03a 100644
> --- a/libavfilter/avf_abitscope.c
> +++ b/libavfilter/avf_abitscope.c
> @@ -213,6 +213,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *insamples)
> AVFilterLink *outlink = ctx->outputs[0];
> AudioBitScopeContext *s = ctx->priv;
> AVFrame *outpicref;
> +int ret;
>
> if (s->mode == 0 || !s->outpicref) {
> outpicref = ff_get_video_buffer(outlink, outlink->w, outlink->h);
> @@ -228,10 +229,16 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *insamples)
> }
>
> if (s->mode == 1) {
> -av_frame_make_writable(s->outpicref);
> +ret = ff_inlink_make_frame_writable(outlink, >outpicref);
> +if (ret < 0) {
> +av_frame_free();
> +return ret;
> +}
> outpicref = av_frame_clone(s->outpicref);
> -if (!outpicref)
> +if (!outpicref) {
> +av_frame_free();
> return AVERROR(ENOMEM);
> +}
> }
>
> outpicref->pts = av_rescale_q(insamples->pts, inlink->time_base,
> outlink->time_base);
> diff --git a/libavfilter/avf_ahistogram.c b/libavfilter/avf_ahistogram.c
> index c45493730d..06490192a5 100644
> --- a/libavfilter/avf_ahistogram.c
> +++ b/libavfilter/avf_ahistogram.c
> @@ -209,7 +209,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> AudioHistogramContext *s = ctx->priv;
> const int H = s->histogram_h;
> const int w = s->w;
> -int c, y, n, p, bin;
> +int c, y, n, p, bin, ret;
> uint64_t acmax = 1;
> AVFrame *clone;
>
> @@ -229,7 +229,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> }
> }
>
> -av_frame_make_writable(s->out);
> +ret = ff_inlink_make_frame_writable(outlink, >out);
> +if (ret < 0) {
> +av_frame_free();
> +return ret;
> +}
> +
> if (s->dmode == SEPARATE) {
> for (y = 0; y < w; y++) {
> s->combine_buffer[3 * y] = 0;
> diff --git a/libavfilter/avf_aphasemeter.c b/libavfilter/avf_aphasemeter.c
> index 0f7692982c..bf9f922639 100644
> --- a/libavfilter/avf_aphasemeter.c
> +++ b/libavfilter/avf_aphasemeter.c
> @@ -29,6 +29,7 @@
> #include "libavutil/parseutils.h"
> #include "libavutil/timestamp.h"
> #include "avfilter.h"
> +#include "filters.h"
> #include "formats.h"
> #include "audio.h"
> #include "video.h"
> @@ -246,7 +247,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> float fphase = 0;
> AVFrame *out;
> uint8_t *dst;
> -int i;
> +int i, ret;
> int mono_measurement;
> int out_phase_measurement;
> float tolerance = 1.0f - s->tolerance;
> @@ -265,8 +266,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> for (i = 0; i < outlink->h; i++)
> memset(out->data[0] + i * out->linesize[0], 0, outlink->w * 4);
> } else if (s->do_video) {
> +ret = ff_inlink_make_frame_writable(outlink, >out);
> +if (ret < 0) {
> +av_frame_free();
> +return ret;
> +}
> out = s->out;
> -av_frame_make_writable(s->out);
> for (i = outlink->h - 1; i >= 10; i--)
> memmove(out->data[0] + (i ) * out->linesize[0],
> out->data[0] + (i-1) * out->linesize[0],
> diff --git a/libavfilter/avf_avectorscope.c b/libavfilter/avf_avectorscope.c
> index 3927d80b42..6e45fd9575 100644
> ---
[FFmpeg-devel] [PATCH] libavfilter/qsvvpp: check the return value
From: Wenbin Chen
Signed-off-by: Wenbin Chen
---
libavfilter/qsvvpp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index e181e7b584..54e7284234 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.c
@@ -441,7 +441,10 @@ static QSVFrame *submit_frame(QSVVPPContext *s,
AVFilterLink *inlink, AVFrame *p
return NULL;
}
-av_frame_copy_props(qsv_frame->frame, picref);
+if (av_frame_copy_props(qsv_frame->frame, picref) < 0) {
+av_frame_free(_frame->frame);
+return NULL;
+}
} else
qsv_frame->frame = av_frame_clone(picref);
--
2.34.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".
