Re: [FFmpeg-devel] [PATCH v6] avcodec/cbs_vp8: Add support for VP8 codec bitstream
> -Original Message- > From: ffmpeg-devel On Behalf Of > James Almer > Sent: Thursday, November 16, 2023 9:30 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v6] avcodec/cbs_vp8: Add support for > VP8 codec bitstream > > On 11/15/2023 3:47 PM, Ronald S. Bultje wrote: > > Hi, > > > > On Sun, Nov 12, 2023 at 8:53 PM Dai, Jianhui J < > > jianhui.j.dai-at-intel@ffmpeg.org> wrote: > > > >> TESTS: ffmpeg -i fate-suite/vp8/frame_size_change.webm -vcodec copy > >> -bsf:v trace_headers -f null - > >> > > > > (I've merged this already.) > > > > I don't think a fate test was added to prevent regressions. Would that > > be useful? (I didn't see one for the other trace_headers like vp9 or > > av1, so it's possible the answer is "no".) > > > > Ronald > > trace_headers bsf doesn't have tests. What's used to test CBS > implementations in general is a *_metadata bsf. Thanks. I will add the WRITE methods into cbs_vp8, and implement the vp8_metadata_bsf for FATE as the next step. > ___ > 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 v3 3/5] avcodec/h264_mp4toannexb_bsf: fix missing PS before IDR frames
> On Nov 18, 2023, at 01:24, Zhao Zhili wrote: > > From: Zhao Zhili > > If there is a single group of SPS/PPS before an IDR frame, but no > SPS/PPS after that, we will miss the chance to reset > idr_sps_seen/idr_pps_seen. No SPS/PPS are inserted afterwards. > > This patch saves in-band SPS/PPS and insert them before IDR frames > when necessary. > — Please help upload the sample to fate h264/ directory. I have sent request to samples-request too. md5sum 09e56f41c2c804c3e1110bc2170aaa06 ps_prefix_first_idr.mp4  https://drive.google.com/file/d/1_jf8WmhEjiK2LKY8ZAtnCEubrHR0kJ1w/view?usp=sharing ___ 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 4/6] avcodec/h264: keep track of which frames used gray references
On Sun, Nov 19, 2023 at 7:11 PM Michael Niedermayer
wrote:
> On Tue, Nov 14, 2023 at 07:46:16PM +0100, Michael Niedermayer wrote:
> > On Tue, Nov 14, 2023 at 06:32:19PM +0100, Hendrik Leppkes wrote:
> > > On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
> > > wrote:
> > > >
> > > > Signed-off-by: Michael Niedermayer
> > > > ---
> > > > libavcodec/h264_picture.c | 1 +
> > > > libavcodec/h264_slice.c | 19 ++-
> > > > libavcodec/h264dec.c | 1 +
> > > > libavcodec/h264dec.h | 4
> > > > 4 files changed, 24 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> > > > index 691c61eea23..3234141dbd6 100644
> > > > --- a/libavcodec/h264_picture.c
> > > > +++ b/libavcodec/h264_picture.c
> > > > @@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture
> *dst, const H264Picture *src)
> > > > dst->field_picture = src->field_picture;
> > > > dst->reference = src->reference;
> > > > dst->recovered = src->recovered;
> > > > +dst->gray = src->gray;
> > > > dst->invalid_gap = src->invalid_gap;
> > > > dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
> > > > dst->mb_width = src->mb_width;
> > > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > > > index 4861a2cabba..2c4ab89dae1 100644
> > > > --- a/libavcodec/h264_slice.c
> > > > +++ b/libavcodec/h264_slice.c
> > > > @@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext
> *dst,
> > > > h->poc.prev_frame_num= h->poc.frame_num;
> > > >
> > > > h->recovery_frame= h1->recovery_frame;
> > > > +h->non_gray = h1->non_gray;
> > > >
> > > > return err;
> > > > }
> > > > @@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h,
> const H264SliceContext *sl,
> > > > if (ret < 0)
> > > > return ret;
> > > > h->short_ref[0]->poc = prev->poc + 2U;
> > > > +h->short_ref[0]->gray = prev->gray;
> > > > ff_thread_report_progress(>short_ref[0]->tf,
> INT_MAX, 0);
> > > > if (h->short_ref[0]->field_picture)
> > > > ff_thread_report_progress(>short_ref[0]->tf,
> INT_MAX, 1);
> > > > -} else if (!h->frame_recovered && !h->avctx->hwaccel)
> > > > +} else if (!h->frame_recovered && !h->avctx->hwaccel) {
> > > > color_frame(h->short_ref[0]->f, c);
> > > > +h->short_ref[0]->gray = 1;
> > > > +}
> > >
> > > While we can't color invalid frames for hwaccels easily, the flag
> > > should perhaps still be applied, as they are equally invalid.
> >
> > ok
>
> will apply with this changed
>
> >
> >
> > > Thinking about this, maybe the name should be less the color we
> > > happened to use for it, and more like "placeholder" or "invalid" or
> > > anything like that?
> >
> > "invalid" is a quite generic term that covers more than this case.
> > and iam not sure if "placeholder" is really good description of them.
> > I picked "gray" because i had no better idea and they are gray
>
> if someone comes up with a better name, we can rename it
> but gray is kind of fitting
>
Sorry, what exactly are h264 gray frames?
Could you add some documentation to the new field in H264Picture too?
--
Vittorio
___
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 4/6] avcodec/h264: keep track of which frames used gray references
On Tue, Nov 14, 2023 at 07:46:16PM +0100, Michael Niedermayer wrote:
> On Tue, Nov 14, 2023 at 06:32:19PM +0100, Hendrik Leppkes wrote:
> > On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
> > wrote:
> > >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavcodec/h264_picture.c | 1 +
> > > libavcodec/h264_slice.c | 19 ++-
> > > libavcodec/h264dec.c | 1 +
> > > libavcodec/h264dec.h | 4
> > > 4 files changed, 24 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> > > index 691c61eea23..3234141dbd6 100644
> > > --- a/libavcodec/h264_picture.c
> > > +++ b/libavcodec/h264_picture.c
> > > @@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture *dst,
> > > const H264Picture *src)
> > > dst->field_picture = src->field_picture;
> > > dst->reference = src->reference;
> > > dst->recovered = src->recovered;
> > > +dst->gray = src->gray;
> > > dst->invalid_gap = src->invalid_gap;
> > > dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
> > > dst->mb_width = src->mb_width;
> > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > > index 4861a2cabba..2c4ab89dae1 100644
> > > --- a/libavcodec/h264_slice.c
> > > +++ b/libavcodec/h264_slice.c
> > > @@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
> > > h->poc.prev_frame_num= h->poc.frame_num;
> > >
> > > h->recovery_frame= h1->recovery_frame;
> > > +h->non_gray = h1->non_gray;
> > >
> > > return err;
> > > }
> > > @@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h, const
> > > H264SliceContext *sl,
> > > if (ret < 0)
> > > return ret;
> > > h->short_ref[0]->poc = prev->poc + 2U;
> > > +h->short_ref[0]->gray = prev->gray;
> > > ff_thread_report_progress(>short_ref[0]->tf, INT_MAX,
> > > 0);
> > > if (h->short_ref[0]->field_picture)
> > > ff_thread_report_progress(>short_ref[0]->tf,
> > > INT_MAX, 1);
> > > -} else if (!h->frame_recovered && !h->avctx->hwaccel)
> > > +} else if (!h->frame_recovered && !h->avctx->hwaccel) {
> > > color_frame(h->short_ref[0]->f, c);
> > > +h->short_ref[0]->gray = 1;
> > > +}
> >
> > While we can't color invalid frames for hwaccels easily, the flag
> > should perhaps still be applied, as they are equally invalid.
>
> ok
will apply with this changed
>
>
> > Thinking about this, maybe the name should be less the color we
> > happened to use for it, and more like "placeholder" or "invalid" or
> > anything like that?
>
> "invalid" is a quite generic term that covers more than this case.
> and iam not sure if "placeholder" is really good description of them.
> I picked "gray" because i had no better idea and they are gray
if someone comes up with a better name, we can rename it
but gray is kind of fitting
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
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] FFmpeg at NAB 2024
On Sun, Nov 19, 2023 at 9:46 PM Michael Niedermayer wrote: > > On Sun, Nov 19, 2023 at 02:26:22PM +, Kieran Kunhya via ffmpeg-devel > wrote: > [...] > > I would not find it acceptable for SPI to pay these costs. I do not feel > > donors would want their money spent on a corporate show in Las Vegas. > > all SPI refunds must be posted to the mailing list and approved by the > FFmpeg community. > I have 0 clue if anything like this will be posted by anyone. But if its > not, there is no way SPI can pay it and if it is then everyone has an > oppertunity to object. > If theres no consensus to fund something then stefano and me will not > approve it. And SPI will not pay it. > > So if a few people are against it and they state that publically in > the corresponding REFUND thread then there is NO way SPI can pay it > > I cannot comment on anything else To be clear I have no issue with reimbursements for small booths at SCALE, LinuxTAG, FOSDEM etc. But NAB is a big corporate show with very large costs for graphics, furniture, union builders etc (put a number in your head and add two zeroes to the end) and I don't feel donors would want their money spent on this. Regards, Kieran Kunhya ___ 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: merge loudnorm filter functionality into f_ebur128.c
On Sun, Nov 19, 2023 at 10:55 PM Marton Balint wrote: > > > On Sun, 19 Nov 2023, Paul B Mahol wrote: > > > On Fri, Nov 17, 2023 at 7:38 AM Kyle Swanson wrote: > > > >> Hi, > >> > >> On Wed, Nov 15, 2023 at 12:39 PM Paul B Mahol wrote: > >> > > >> > Attached. > >> > >> Only had a few minutes to look at this. Seems like more than just > >> merging two filters, I see a bunch of new filter options for example. > >> Can you explain? > >> > > > > The linear mode and scanning, both input to filter and filter output > itself > > should give similar results. > > The dynamic mode now actually can be configured how aggressively it will > > expand / compress audio. > > Because current state of filter have numerous issues: > > > > - using unmaintained old libebur128 module, when same functionality is > > already available in existing filter. > > - code duplication and functionality duplication due the above > > - buggy limiter - causing clipped samples randomly > > - buggy first and final frame filtering > > - over-complicated flow path for dynamic code in filter > > - excessive compressing of audio dynamic range, causing extreme smaller > > LRU from output audio > > - and probably more that I forgot > > > > Some options from this patch can be probably removed, like attack/release > > options, and just use defaults as currently in patch. > > Previously ebur128 functionality was decoupled from specific filters, so > there was a chance that multiple filters can use it. Unfortunately > f_ebur128.c was never migrated to use internal ebur128 lib, as far as I > remember the maintaner rejected the idea for some reason back then. > Because its pointless, both use histograms, and this is just duplicated code. Also f_ebur128.c code/filter come first, even though its scanner only and have visuals. > IMHO having some generic ebur128 functionality would be preferable. I > have an old patch for example which adds EBUR128 mode to af_dynaudnorm, > see attached for reference. Looks much cleaner than af_loudnorm, which was > always a bit overcomplicated and slightly buggy, as you mentioned. > > So please consider two things: > > - Can you keep some generic ebur128 functionality which can easily reused >by multiple filters? I don't mind if it is the old code from ebur128 lib >or current code from f_ebur128, but it should be reusable internal ff_ >functions. > That can be done, I already done something similar in this patch, but it can be extended and improved. > > - Does it make sense to maintain a separate loudnorm filter for EBUR128 >loudness, or it can be integrated into af_dynaudnorm? Because I kind of >think that having this as a option of af_dynaudnorm would be >cleaner, at least for the dynamic normalization functionality. For the >linear mode, well, we already have compressor filters, so I am not sure >if that mode is worth keeping. But maybe it is easier for the end user, >I don't know. > dynaudnorm filter is using different approach completely. It can have delay less than second and more that 30 seconds depending on parameters. ebur128 is using 3 second window and also history of previous measurements, and minimal delay is 1/10 of second. Also ebur128 applies special biquad before calculating gains... So the approach of loudnorm vs dynaudnorm is completely different and does not make sense to put it into dynaudnorm. (one could add optional side-chain stream to dynaudnorm but that is max where i would go) Linear mode of loudnorm filter is just volume filter. It just set single gain factor by interpreting parameters from input. (The only drawback is that you rescan audio again, twice, input of filter and output of filter, so there are 4 scans in 2-pass mode, when there is only 1 scan pass needed for linear mode) Also linear mode is used heavily by other users/project as can be found on net. Dynamic mode (for real-time streams) is also used, even in its current state, thats why I wanted to cleanup it. > > 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 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 AV_OPT_TYPE_CHLAYOUT
Fixed issue.
From 3abdd4d0b085a6c5aa3e6114448a2967d584d7c4 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 19 Nov 2023 19:35:43 +0100
Subject: [PATCH] avfilter: use AV_OPT_TYPE_CHLAYOUT
Signed-off-by: Paul B Mahol
---
libavfilter/af_channelmap.c | 59 ++-
libavfilter/af_channelsplit.c | 14 +++--
libavfilter/af_join.c | 23 +-
libavfilter/af_surround.c | 28 +
libavfilter/asrc_afdelaysrc.c | 26 ++-
libavfilter/asrc_anullsrc.c | 34 +++-
6 files changed, 35 insertions(+), 149 deletions(-)
diff --git a/libavfilter/af_channelmap.c b/libavfilter/af_channelmap.c
index 09bc4cfbe1..4b71dc1065 100644
--- a/libavfilter/af_channelmap.c
+++ b/libavfilter/af_channelmap.c
@@ -58,7 +58,6 @@ enum MappingMode {
typedef struct ChannelMapContext {
const AVClass *class;
char *mapping_str;
-char *channel_layout_str;
AVChannelLayout output_layout;
struct ChannelMap map[MAX_CH];
int nch;
@@ -72,7 +71,7 @@ static const AVOption channelmap_options[] = {
{ "map", "A comma-separated list of input channel numbers in output order.",
OFFSET(mapping_str),AV_OPT_TYPE_STRING, .flags = A|F },
{ "channel_layout", "Output channel layout.",
- OFFSET(channel_layout_str), AV_OPT_TYPE_STRING, .flags = A|F },
+ OFFSET(output_layout), AV_OPT_TYPE_CHLAYOUT, .flags = A|F },
{ NULL }
};
@@ -122,7 +121,6 @@ static av_cold int channelmap_init(AVFilterContext *ctx)
ChannelMapContext *s = ctx->priv;
char *mapping, separator = '|';
int map_entries = 0;
-char buf[256];
enum MappingMode mode;
uint64_t out_ch_mask = 0;
int i;
@@ -232,50 +230,25 @@ static av_cold int channelmap_init(AVFilterContext *ctx)
s->nch = map_entries;
if (out_ch_mask)
av_channel_layout_from_mask(>output_layout, out_ch_mask);
-else
+else if (map_entries)
av_channel_layout_default(>output_layout, map_entries);
-if (s->channel_layout_str) {
-AVChannelLayout fmt = { 0 };
-int ret;
-if ((ret = av_channel_layout_from_string(, s->channel_layout_str)) < 0) {
-#if FF_API_OLD_CHANNEL_LAYOUT
-uint64_t mask;
-FF_DISABLE_DEPRECATION_WARNINGS
-if ((mask = av_get_channel_layout(s->channel_layout_str)) == 0) {
-#endif
-av_log(ctx, AV_LOG_ERROR, "Error parsing channel layout: '%s'.\n",
- s->channel_layout_str);
-return AVERROR(EINVAL);
-#if FF_API_OLD_CHANNEL_LAYOUT
-}
-FF_ENABLE_DEPRECATION_WARNINGS
-av_log(ctx, AV_LOG_WARNING, "Channel layout '%s' uses a deprecated syntax.\n",
- s->channel_layout_str);
-av_channel_layout_from_mask(, mask);
-#endif
-}
-if (mode == MAP_NONE) {
-int i;
-s->nch = fmt.nb_channels;
-for (i = 0; i < s->nch; i++) {
-s->map[i].in_channel_idx = i;
-s->map[i].out_channel_idx = i;
-}
-} else if (out_ch_mask && av_channel_layout_compare(>output_layout, )) {
-av_channel_layout_describe(>output_layout, buf, sizeof(buf));
-av_log(ctx, AV_LOG_ERROR,
- "Output channel layout '%s' does not match the list of channel mapped: '%s'.\n",
- s->channel_layout_str, buf);
-return AVERROR(EINVAL);
-} else if (s->nch != fmt.nb_channels) {
-av_log(ctx, AV_LOG_ERROR,
- "Output channel layout %s does not match the number of channels mapped %d.\n",
- s->channel_layout_str, s->nch);
-return AVERROR(EINVAL);
+if (mode == MAP_NONE) {
+int i;
+s->nch = s->output_layout.nb_channels;
+for (i = 0; i < s->nch; i++) {
+s->map[i].in_channel_idx = i;
+s->map[i].out_channel_idx = i;
}
-s->output_layout = fmt;
+} else if (s->nch != s->output_layout.nb_channels) {
+char buf[256];
+av_channel_layout_describe(>output_layout, buf, sizeof(buf));
+av_log(ctx, AV_LOG_ERROR,
+ "Output channel layout %s does not match the number of channels mapped %d.\n",
+ buf, s->nch);
+return AVERROR(EINVAL);
}
+
if (!s->output_layout.nb_channels) {
av_log(ctx, AV_LOG_ERROR, "Output channel layout is not set and "
"cannot be guessed from the maps.\n");
diff --git a/libavfilter/af_channelsplit.c b/libavfilter/af_channelsplit.c
index bd4afff122..932b51d701 100644
--- a/libavfilter/af_channelsplit.c
+++ b/libavfilter/af_channelsplit.c
@@ -40,7 +40,6 @@ typedef struct ChannelSplitContext {
const AVClass *class;
AVChannelLayout channel_layout;
-char*channel_layout_str;
char*channels_str;
int map[64];
@@ -50,7 +49,7 @@ typedef struct
Re: [FFmpeg-devel] [PATCH] avfilter: use AV_OPT_TYPE_CHLAYOUT
On Sun, Nov 19, 2023 at 08:33:08PM +0100, Paul B Mahol wrote: > Attached. > af_channelmap.c | 57 > ++ > af_channelsplit.c | 14 +++-- > af_join.c | 23 - > af_surround.c | 28 +++--- > asrc_afdelaysrc.c | 26 +--- > asrc_anullsrc.c | 34 +++- > 6 files changed, 34 insertions(+), 148 deletions(-) > 1b0d8c7266942e9193f52744a8009d3473137792 > 0001-avfilter-use-AV_OPT_TYPE_CHLAYOUT.patch > From 79d3fceece0ead163ffcaca753b9479669776d2f Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Sun, 19 Nov 2023 19:35:43 +0100 > Subject: [PATCH] avfilter: use AV_OPT_TYPE_CHLAYOUT breaks fate-id3v2-utf16-bom Duration: 00:03:09.05, start: 0.00, bitrate: 1 kb/s Stream #1:0: Audio: flac, 44100 Hz, stereo, s16 Stream #1:1: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 350x350 [SAR 1:1 DAR 1:1], 90k tbr, 90k tbn (attached pic) Metadata: comment : Other [Parsed_channelmap_1 @ 0x55992f004b80] Output channel layout is not set and cannot be guessed from the maps. [AVFilterGraph @ 0x55992efcbf00] Error initializing filters [aost#0:0/pcm_s24be @ 0x55992f0030c0] Error initializing a simple filtergraph Error opening output file ffmpeg/tests/data/fate/id3v2-utf16-bom.aiff. Error opening output files: Invalid argument threads=1 tests/Makefile:307: recipe for target 'fate-id3v2-utf16-bom' failed make: *** [fate-id3v2-utf16-bom] Error 234 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. 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: merge loudnorm filter functionality into f_ebur128.c
On Sun, 19 Nov 2023, Paul B Mahol wrote: On Fri, Nov 17, 2023 at 7:38 AM Kyle Swanson wrote: Hi, On Wed, Nov 15, 2023 at 12:39 PM Paul B Mahol wrote: > > Attached. Only had a few minutes to look at this. Seems like more than just merging two filters, I see a bunch of new filter options for example. Can you explain? The linear mode and scanning, both input to filter and filter output itself should give similar results. The dynamic mode now actually can be configured how aggressively it will expand / compress audio. Because current state of filter have numerous issues: - using unmaintained old libebur128 module, when same functionality is already available in existing filter. - code duplication and functionality duplication due the above - buggy limiter - causing clipped samples randomly - buggy first and final frame filtering - over-complicated flow path for dynamic code in filter - excessive compressing of audio dynamic range, causing extreme smaller LRU from output audio - and probably more that I forgot Some options from this patch can be probably removed, like attack/release options, and just use defaults as currently in patch. Previously ebur128 functionality was decoupled from specific filters, so there was a chance that multiple filters can use it. Unfortunately f_ebur128.c was never migrated to use internal ebur128 lib, as far as I remember the maintaner rejected the idea for some reason back then. IMHO having some generic ebur128 functionality would be preferable. I have an old patch for example which adds EBUR128 mode to af_dynaudnorm, see attached for reference. Looks much cleaner than af_loudnorm, which was always a bit overcomplicated and slightly buggy, as you mentioned. So please consider two things: - Can you keep some generic ebur128 functionality which can easily reused by multiple filters? I don't mind if it is the old code from ebur128 lib or current code from f_ebur128, but it should be reusable internal ff_ functions. - Does it make sense to maintain a separate loudnorm filter for EBUR128 loudness, or it can be integrated into af_dynaudnorm? Because I kind of think that having this as a option of af_dynaudnorm would be cleaner, at least for the dynamic normalization functionality. For the linear mode, well, we already have compressor filters, so I am not sure if that mode is worth keeping. But maybe it is easier for the end user, I don't know. Thanks, Martoncommit df4e283d7b2aa4b4de6e405e5dcbbae38d053b9f Author: Marton Balint Date: Sun Oct 16 20:45:51 2016 +0200 lavfi/af_dynaudnorm: add support for momentary loudness based normalization Signed-off-by: Marton Balint diff --git a/doc/filters.texi b/doc/filters.texi index 604e44d569..9d05d7db94 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -3212,6 +3212,22 @@ factor is defined as the factor that would result in exactly that RMS value. Note, however, that the maximum local gain factor is still restricted by the frame's highest magnitude sample, in order to prevent clipping. +@item l +Set the target loudness in LUFS. In range from -70.0 to 0. Default is 0.0 - +disabled. By default, the Dynamic Audio Normalizer performs "peak" +normalization. This means that the maximum local gain factor for each frame is +defined (only) by the frame's highest magnitude sample. This way, the samples +can be amplified as much as possible without exceeding the maximum signal +level, i.e. without clipping. Optionally, however, the Dynamic Audio Normalizer +can also take into account the frame's perceived momentary loudness which is +measured based on the EBU R128 recommendation. Consequently, by adjusting all +frames to a constant loudness value, a uniform "perceived loudness" can be +established. Note, however, that loudness is measured without any kind of +gating, therefore the integrated loudness as defined by EBU R128 will be +usually less than the target level, depending on your content. Also note, that +the maximum local gain factor is still restricted by the frame's highest +magnitude sample, in order to prevent clipping. + @item n Enable channels coupling. By default is enabled. By default, the Dynamic Audio Normalizer will amplify all channels by the same diff --git a/libavfilter/Makefile b/libavfilter/Makefile index 455c809b15..7c3238edd3 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -103,7 +103,7 @@ OBJS-$(CONFIG_CRYSTALIZER_FILTER)+= af_crystalizer.o OBJS-$(CONFIG_DCSHIFT_FILTER)+= af_dcshift.o OBJS-$(CONFIG_DEESSER_FILTER)+= af_deesser.o OBJS-$(CONFIG_DRMETER_FILTER)+= af_drmeter.o -OBJS-$(CONFIG_DYNAUDNORM_FILTER) += af_dynaudnorm.o +OBJS-$(CONFIG_DYNAUDNORM_FILTER) += af_dynaudnorm.o ebur128.o OBJS-$(CONFIG_EARWAX_FILTER) += af_earwax.o OBJS-$(CONFIG_EBUR128_FILTER)+= f_ebur128.o OBJS-$(CONFIG_EQUALIZER_FILTER)
Re: [FFmpeg-devel] FFmpeg at NAB 2024
On Sun, Nov 19, 2023 at 02:26:22PM +, Kieran Kunhya via ffmpeg-devel wrote: [...] > I would not find it acceptable for SPI to pay these costs. I do not feel > donors would want their money spent on a corporate show in Las Vegas. all SPI refunds must be posted to the mailing list and approved by the FFmpeg community. I have 0 clue if anything like this will be posted by anyone. But if its not, there is no way SPI can pay it and if it is then everyone has an oppertunity to object. If theres no consensus to fund something then stefano and me will not approve it. And SPI will not pay it. So if a few people are against it and they state that publically in the corresponding REFUND thread then there is NO way SPI can pay it I cannot comment on anything else thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. 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] [ANNOUNCE] upcoming vote: extra members for GA v2
On Sun, Nov 19, 2023 at 12:58:17PM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-11-19 11:35:20) > > On Sun, Nov 19, 2023 at 08:48:19AM +0100, Anton Khirnov wrote: > > > Reminder that the vote starts tomorrow. > > > > > > Quoting Anton Khirnov (2023-11-17 10:40:06) > > > > The list of candidates I have so far is: > > > > * Ronald Bultje > > > > * Alexander Strasser > > > > * Hendrik Leppkes > > > > * Reimar Döffinger > > > > * Baptiste Coudurier > > > > (hope I haven't missed anyone, please tell me if I did) > > > > > > > > If we get an agreement from any further people Michael has contacted > > > > before the vote starts, I will also add them the list. > > > > > > So far Shiyou Yin has agreed to be added to the list. > > > > I can confirm that, i have not received any additional yes replies either > > at the moment > > > > so from the 12 sent out emails > > (this only included people active or in GA 2020 or paying infra) > > we got 2 people saying yes ATM > > from most we got no reply yet > > maybe we should give people a little more time > > to avoid having to do a 2nd vote round, if we get a late yes reply? > > I'd rather not postpone the vote much longer. I suppose we could start > it on Tuesday, What i said was just a suggestion. Tuesday is perfectly fine with me, as is any other day you would pick. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives. -- Abba Eban 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/6] lavc/aarch64: new optimization for 8-bit hevc_pel_bi_pixels
On Sat, Nov 18, 2023 at 10:06:37AM +0800, Logan.Lyu wrote: > put_hevc_pel_bi_pixels4_8_c: 54.7 > put_hevc_pel_bi_pixels4_8_neon: 43.0 > put_hevc_pel_bi_pixels6_8_c: 94.7 > put_hevc_pel_bi_pixels6_8_neon: 37.0 > put_hevc_pel_bi_pixels8_8_c: 171.0 > put_hevc_pel_bi_pixels8_8_neon: 24.0 > put_hevc_pel_bi_pixels12_8_c: 354.0 > put_hevc_pel_bi_pixels12_8_neon: 68.7 > put_hevc_pel_bi_pixels16_8_c: 588.2 > put_hevc_pel_bi_pixels16_8_neon: 77.5 > put_hevc_pel_bi_pixels24_8_c: 1670.7 > put_hevc_pel_bi_pixels24_8_neon: 173.0 > put_hevc_pel_bi_pixels32_8_c: 2267.7 > put_hevc_pel_bi_pixels32_8_neon: 281.2 > put_hevc_pel_bi_pixels48_8_c: 5787.5 > put_hevc_pel_bi_pixels48_8_neon: 673.5 > put_hevc_pel_bi_pixels64_8_c: 9897.0 > put_hevc_pel_bi_pixels64_8_neon: 1159.5 > > Co-Authored-By: J. Dekker > Signed-off-by: Logan Lyu > --- > libavcodec/aarch64/hevcdsp_epel_neon.S| 179 ++ > libavcodec/aarch64/hevcdsp_init_aarch64.c | 10 +- > 2 files changed, 187 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/aarch64/hevcdsp_epel_neon.S > b/libavcodec/aarch64/hevcdsp_epel_neon.S > index 708b903b00..74165273d7 100644 > --- a/libavcodec/aarch64/hevcdsp_epel_neon.S > +++ b/libavcodec/aarch64/hevcdsp_epel_neon.S > @@ -244,6 +244,185 @@ function ff_hevc_put_hevc_pel_pixels64_8_neon, > export=1 error: corrupt patch at line 194 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- 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".
[FFmpeg-devel] [PATCH] lavc/llvidencdsp: add R-V V diff_bytes
diff_bytes_c: 163.0
diff_bytes_rvv_i32: 52.7
---
libavcodec/lossless_videoencdsp.c | 4 ++-
libavcodec/lossless_videoencdsp.h | 1 +
libavcodec/riscv/Makefile | 2 ++
libavcodec/riscv/llvidencdsp_init.c | 39 +
libavcodec/riscv/llvidencdsp_rvv.S | 37 +++
5 files changed, 82 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/riscv/llvidencdsp_init.c
create mode 100644 libavcodec/riscv/llvidencdsp_rvv.S
diff --git a/libavcodec/lossless_videoencdsp.c
b/libavcodec/lossless_videoencdsp.c
index b4130ebc7b..e2dc99e201 100644
--- a/libavcodec/lossless_videoencdsp.c
+++ b/libavcodec/lossless_videoencdsp.c
@@ -94,7 +94,9 @@ av_cold void ff_llvidencdsp_init(LLVidEncDSPContext *c)
c->sub_median_pred = sub_median_pred_c;
c->sub_left_predict = sub_left_predict_c;
-#if ARCH_X86
+#if ARCH_RISCV
+ff_llvidencdsp_init_riscv(c);
+#elif ARCH_X86
ff_llvidencdsp_init_x86(c);
#endif
}
diff --git a/libavcodec/lossless_videoencdsp.h
b/libavcodec/lossless_videoencdsp.h
index f2c2878485..07fff584af 100644
--- a/libavcodec/lossless_videoencdsp.h
+++ b/libavcodec/lossless_videoencdsp.h
@@ -40,6 +40,7 @@ typedef struct LLVidEncDSPContext {
} LLVidEncDSPContext;
void ff_llvidencdsp_init(LLVidEncDSPContext *c);
+void ff_llvidencdsp_init_riscv(LLVidEncDSPContext *c);
void ff_llvidencdsp_init_x86(LLVidEncDSPContext *c);
#endif /* AVCODEC_LOSSLESS_VIDEOENCDSP_H */
diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index 8f2a519827..2d0e6c19c8 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -30,6 +30,8 @@ OBJS-$(CONFIG_LLAUDDSP) += riscv/llauddsp_init.o
RVV-OBJS-$(CONFIG_LLAUDDSP) += riscv/llauddsp_rvv.o
OBJS-$(CONFIG_LLVIDDSP) += riscv/llviddsp_init.o
RVV-OBJS-$(CONFIG_LLVIDDSP) += riscv/llviddsp_rvv.o
+OBJS-$(CONFIG_LLVIDENCDSP) += riscv/llvidencdsp_init.o
+RVV-OBJS-$(CONFIG_LLVIDENCDSP) += riscv/llvidencdsp_rvv.o
OBJS-$(CONFIG_OPUS_DECODER) += riscv/opusdsp_init.o
RVV-OBJS-$(CONFIG_OPUS_DECODER) += riscv/opusdsp_rvv.o
OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_init.o \
diff --git a/libavcodec/riscv/llvidencdsp_init.c
b/libavcodec/riscv/llvidencdsp_init.c
new file mode 100644
index 00..e35406dc41
--- /dev/null
+++ b/libavcodec/riscv/llvidencdsp_init.c
@@ -0,0 +1,39 @@
+/*
+ * Copyright © 2023 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config.h"
+
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavcodec/lossless_videoencdsp.h"
+
+void ff_llvidenc_diff_bytes_rvv(uint8_t *dst, const uint8_t *src1,
+const uint8_t *src2, intptr_t w);
+
+av_cold void ff_llvidencdsp_init_riscv(LLVidEncDSPContext *c)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if (flags & AV_CPU_FLAG_RVV_I32) {
+c->diff_bytes = ff_llvidenc_diff_bytes_rvv;
+}
+#endif
+}
diff --git a/libavcodec/riscv/llvidencdsp_rvv.S
b/libavcodec/riscv/llvidencdsp_rvv.S
new file mode 100644
index 00..0342165127
--- /dev/null
+++ b/libavcodec/riscv/llvidencdsp_rvv.S
@@ -0,0 +1,37 @@
+/*
+ * Copyright © 2023 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/riscv/asm.S"
+
+func ff_llvidenc_diff_bytes_rvv, zve32x
+1:
+vsetvli t0, a3, e8, m8, ta, ma
+vle8.v v0, (a1)
+sub a3, a3, t0
+vle8.v v8, (a2)
+add a1, t0, a1
+vsub.vv v8, v0, v8
+add a2,
[FFmpeg-devel] [PATCH] avfilter: use AV_OPT_TYPE_CHLAYOUT
Attached.
From 79d3fceece0ead163ffcaca753b9479669776d2f Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 19 Nov 2023 19:35:43 +0100
Subject: [PATCH] avfilter: use AV_OPT_TYPE_CHLAYOUT
Signed-off-by: Paul B Mahol
---
libavfilter/af_channelmap.c | 57 +--
libavfilter/af_channelsplit.c | 14 +++--
libavfilter/af_join.c | 23 +-
libavfilter/af_surround.c | 28 +
libavfilter/asrc_afdelaysrc.c | 26 ++--
libavfilter/asrc_anullsrc.c | 34 +++--
6 files changed, 34 insertions(+), 148 deletions(-)
diff --git a/libavfilter/af_channelmap.c b/libavfilter/af_channelmap.c
index 09bc4cfbe1..3a16f3e4b5 100644
--- a/libavfilter/af_channelmap.c
+++ b/libavfilter/af_channelmap.c
@@ -58,7 +58,6 @@ enum MappingMode {
typedef struct ChannelMapContext {
const AVClass *class;
char *mapping_str;
-char *channel_layout_str;
AVChannelLayout output_layout;
struct ChannelMap map[MAX_CH];
int nch;
@@ -72,7 +71,7 @@ static const AVOption channelmap_options[] = {
{ "map", "A comma-separated list of input channel numbers in output order.",
OFFSET(mapping_str),AV_OPT_TYPE_STRING, .flags = A|F },
{ "channel_layout", "Output channel layout.",
- OFFSET(channel_layout_str), AV_OPT_TYPE_STRING, .flags = A|F },
+ OFFSET(output_layout), AV_OPT_TYPE_CHLAYOUT, .flags = A|F },
{ NULL }
};
@@ -122,7 +121,6 @@ static av_cold int channelmap_init(AVFilterContext *ctx)
ChannelMapContext *s = ctx->priv;
char *mapping, separator = '|';
int map_entries = 0;
-char buf[256];
enum MappingMode mode;
uint64_t out_ch_mask = 0;
int i;
@@ -235,47 +233,22 @@ static av_cold int channelmap_init(AVFilterContext *ctx)
else
av_channel_layout_default(>output_layout, map_entries);
-if (s->channel_layout_str) {
-AVChannelLayout fmt = { 0 };
-int ret;
-if ((ret = av_channel_layout_from_string(, s->channel_layout_str)) < 0) {
-#if FF_API_OLD_CHANNEL_LAYOUT
-uint64_t mask;
-FF_DISABLE_DEPRECATION_WARNINGS
-if ((mask = av_get_channel_layout(s->channel_layout_str)) == 0) {
-#endif
-av_log(ctx, AV_LOG_ERROR, "Error parsing channel layout: '%s'.\n",
- s->channel_layout_str);
-return AVERROR(EINVAL);
-#if FF_API_OLD_CHANNEL_LAYOUT
-}
-FF_ENABLE_DEPRECATION_WARNINGS
-av_log(ctx, AV_LOG_WARNING, "Channel layout '%s' uses a deprecated syntax.\n",
- s->channel_layout_str);
-av_channel_layout_from_mask(, mask);
-#endif
-}
-if (mode == MAP_NONE) {
-int i;
-s->nch = fmt.nb_channels;
-for (i = 0; i < s->nch; i++) {
-s->map[i].in_channel_idx = i;
-s->map[i].out_channel_idx = i;
-}
-} else if (out_ch_mask && av_channel_layout_compare(>output_layout, )) {
-av_channel_layout_describe(>output_layout, buf, sizeof(buf));
-av_log(ctx, AV_LOG_ERROR,
- "Output channel layout '%s' does not match the list of channel mapped: '%s'.\n",
- s->channel_layout_str, buf);
-return AVERROR(EINVAL);
-} else if (s->nch != fmt.nb_channels) {
-av_log(ctx, AV_LOG_ERROR,
- "Output channel layout %s does not match the number of channels mapped %d.\n",
- s->channel_layout_str, s->nch);
-return AVERROR(EINVAL);
+if (mode == MAP_NONE) {
+int i;
+s->nch = s->output_layout.nb_channels;
+for (i = 0; i < s->nch; i++) {
+s->map[i].in_channel_idx = i;
+s->map[i].out_channel_idx = i;
}
-s->output_layout = fmt;
+} else if (s->nch != s->output_layout.nb_channels) {
+char buf[256];
+av_channel_layout_describe(>output_layout, buf, sizeof(buf));
+av_log(ctx, AV_LOG_ERROR,
+ "Output channel layout %s does not match the number of channels mapped %d.\n",
+ buf, s->nch);
+return AVERROR(EINVAL);
}
+
if (!s->output_layout.nb_channels) {
av_log(ctx, AV_LOG_ERROR, "Output channel layout is not set and "
"cannot be guessed from the maps.\n");
diff --git a/libavfilter/af_channelsplit.c b/libavfilter/af_channelsplit.c
index bd4afff122..932b51d701 100644
--- a/libavfilter/af_channelsplit.c
+++ b/libavfilter/af_channelsplit.c
@@ -40,7 +40,6 @@ typedef struct ChannelSplitContext {
const AVClass *class;
AVChannelLayout channel_layout;
-char*channel_layout_str;
char*channels_str;
int map[64];
@@ -50,7 +49,7 @@ typedef struct ChannelSplitContext {
#define A AV_OPT_FLAG_AUDIO_PARAM
#define F AV_OPT_FLAG_FILTERING_PARAM
static const AVOption channelsplit_options[] = {
-{
[FFmpeg-devel] [PATCH v6 2/2] avformat/oggenc: Add support for embedding cover art
Attached.From 38716e20b2e8b3a711cc22f7e7abc45731aa79b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Zsolt=20Vad=C3=A1sz?=
Date: Fri, 10 Mar 2023 11:26:27 +
Subject: [PATCH v6 2/2] avformat/oggenc: Add support for embedding cover art
Fixes #4448.
Signed-off-by: Zsolt Vadasz
---
libavformat/oggenc.c | 214 +++
1 file changed, 176 insertions(+), 38 deletions(-)
diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index 69a66f586d..893f4cac14 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -23,19 +23,28 @@
#include
+#include "libavcodec/codec_id.h"
+#include "libavutil/avutil.h"
#include "libavutil/crc.h"
+#include "libavutil/log.h"
#include "libavutil/mathematics.h"
#include "libavutil/opt.h"
#include "libavutil/random_seed.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/avstring.h"
+#include "libavutil/base64.h"
+#include "libavutil/bswap.h"
#include "libavcodec/xiph.h"
#include "libavcodec/bytestream.h"
#include "libavcodec/flac.h"
#include "avformat.h"
+#include "id3v2.h"
#include "avio_internal.h"
#include "internal.h"
#include "mux.h"
#include "version.h"
#include "vorbiscomment.h"
+#include "flac_picture.h"
#define MAX_PAGE_SIZE 65025
@@ -78,6 +87,11 @@ typedef struct OGGContext {
int pref_size; ///< preferred page size (0 => fill all segments)
int64_t pref_duration; ///< preferred page duration (0 => fill all segments)
int serial_offset;
+
+PacketList queue;
+int audio_stream_idx;
+int waiting_pics;
+unsigned attached_types;
} OGGContext;
#define OFFSET(x) offsetof(OGGContext, x)
@@ -469,12 +483,14 @@ static void ogg_write_pages(AVFormatContext *s, int flush)
ogg->page_list = p;
}
-static int ogg_init(AVFormatContext *s)
+static int ogg_finish_init(AVFormatContext *s)
{
OGGContext *ogg = s->priv_data;
OGGStreamContext *oggstream = NULL;
int i, j;
+ogg->waiting_pics = 0;
+
if (ogg->pref_size)
av_log(s, AV_LOG_WARNING, "The pagesize option is deprecated\n");
@@ -482,29 +498,10 @@ static int ogg_init(AVFormatContext *s)
AVStream *st = s->streams[i];
unsigned serial_num = i + ogg->serial_offset;
-if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
-if (st->codecpar->codec_id == AV_CODEC_ID_OPUS)
-/* Opus requires a fixed 48kHz clock */
-avpriv_set_pts_info(st, 64, 1, 48000);
-else
-avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
-}
-
-if (st->codecpar->codec_id != AV_CODEC_ID_VORBIS &&
-st->codecpar->codec_id != AV_CODEC_ID_THEORA &&
-st->codecpar->codec_id != AV_CODEC_ID_SPEEX &&
-st->codecpar->codec_id != AV_CODEC_ID_FLAC &&
-st->codecpar->codec_id != AV_CODEC_ID_OPUS &&
-st->codecpar->codec_id != AV_CODEC_ID_VP8) {
-av_log(s, AV_LOG_ERROR, "Unsupported codec id in stream %d\n", i);
-return AVERROR(EINVAL);
-}
+if(st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
+ (st->disposition & AV_DISPOSITION_ATTACHED_PIC))
+continue;
-if ((!st->codecpar->extradata || !st->codecpar->extradata_size) &&
-st->codecpar->codec_id != AV_CODEC_ID_VP8) {
-av_log(s, AV_LOG_ERROR, "No extradata present\n");
-return AVERROR_INVALIDDATA;
-}
oggstream = av_mallocz(sizeof(*oggstream));
if (!oggstream)
return AVERROR(ENOMEM);
@@ -515,8 +512,11 @@ static int ogg_init(AVFormatContext *s)
do {
serial_num = av_get_random_seed();
for (j = 0; j < i; j++) {
+// NULL for attached_pic
OGGStreamContext *sc = s->streams[j]->priv_data;
-if (serial_num == sc->serial_num)
+if(!sc)
+continue;
+else if (serial_num == sc->serial_num)
break;
}
} while (j < i);
@@ -563,9 +563,9 @@ static int ogg_init(AVFormatContext *s)
int framing_bit = st->codecpar->codec_id == AV_CODEC_ID_VORBIS ? 1 : 0;
if (avpriv_split_xiph_headers(st->codecpar->extradata, st->codecpar->extradata_size,
- st->codecpar->codec_id == AV_CODEC_ID_VORBIS ? 30 : 42,
- (const uint8_t**)oggstream->header, oggstream->header_len) < 0) {
-av_log(s, AV_LOG_ERROR, "Extradata corrupted\n");
+ st->codecpar->codec_id == AV_CODEC_ID_VORBIS ? 30 : 42,
+ (const uint8_t**)oggstream->header, oggstream->header_len) < 0) {
+av_log(s, AV_LOG_ERROR, "Extradata corrupted for stream #%d\n", i);
oggstream->header[1] = NULL;
[FFmpeg-devel] [PATCH v6 1/2] avformat/flac_picture: Add ff_flac_write_picture
Attached.From 1b7a510ff5720d21868f0284c7a50489034bee7d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Zsolt=20Vad=C3=A1sz?=
Date: Fri, 10 Mar 2023 11:23:13 +
Subject: [PATCH v6 1/2] avformat/flac_picture: Add ff_flac_write_picture
This function is able to write cover art into both FLAC and Ogg files
Signed-off-by: Zsolt Vadasz
---
libavformat/flac_picture.c | 132 +
libavformat/flac_picture.h | 5 ++
libavformat/flacenc.c | 90 +
3 files changed, 140 insertions(+), 87 deletions(-)
diff --git a/libavformat/flac_picture.c b/libavformat/flac_picture.c
index b33fee75b4..30152a2ba9 100644
--- a/libavformat/flac_picture.c
+++ b/libavformat/flac_picture.c
@@ -20,6 +20,9 @@
*/
#include "libavutil/intreadwrite.h"
+#include "libavutil/avstring.h"
+#include "libavutil/base64.h"
+#include "libavutil/pixdesc.h"
#include "libavcodec/bytestream.h"
#include "libavcodec/png.h"
#include "avformat.h"
@@ -188,3 +191,132 @@ fail:
return ret;
}
+
+int ff_flac_write_picture(struct AVFormatContext *s,
+ int isogg,
+ unsigned *attached_types,
+ int audio_stream_idx, // unused if !isogg
+ AVPacket *pkt)
+{
+AVIOContext *pb = s->pb;
+const AVPixFmtDescriptor *pixdesc;
+const CodecMime *mime = ff_id3v2_mime_tags;
+AVDictionaryEntry *e;
+const char *mimetype = NULL, *desc = "";
+const AVStream *st = s->streams[pkt->stream_index];
+int i, mimelen, desclen, type = 0, blocklen;
+
+if (!pkt->data)
+return 0;
+
+while (mime->id != AV_CODEC_ID_NONE) {
+if (mime->id == st->codecpar->codec_id) {
+mimetype = mime->str;
+break;
+}
+mime++;
+}
+if (!mimetype) {
+av_log(s, AV_LOG_ERROR, "No mimetype is known for stream %d, cannot "
+ "write an attached picture.\n", st->index);
+return AVERROR(EINVAL);
+}
+mimelen = strlen(mimetype);
+
+/* get the picture type */
+e = av_dict_get(st->metadata, "comment", NULL, 0);
+for (i = 0; e && i < FF_ARRAY_ELEMS(ff_id3v2_picture_types); i++) {
+if (!av_strcasecmp(e->value, ff_id3v2_picture_types[i])) {
+type = i;
+break;
+}
+}
+
+if (((*attached_types) & (1 << type)) & 0x6) {
+av_log(s, AV_LOG_ERROR, "Duplicate attachment for type '%s'\n", ff_id3v2_picture_types[type]);
+return AVERROR(EINVAL);
+}
+
+if (type == 1 && (st->codecpar->codec_id != AV_CODEC_ID_PNG ||
+ st->codecpar->width != 32 ||
+ st->codecpar->height != 32)) {
+av_log(s, AV_LOG_ERROR, "File icon attachment must be a 32x32 PNG");
+return AVERROR(EINVAL);
+}
+
+*attached_types |= (1 << type);
+
+/* get the description */
+if ((e = av_dict_get(st->metadata, "title", NULL, 0)))
+desc = e->value;
+desclen = strlen(desc);
+
+blocklen = 4 + 4 + mimelen + 4 + desclen + 4 + 4 + 4 + 4 + 4 + pkt->size;
+if (blocklen >= 1<<24) {
+av_log(s, AV_LOG_ERROR, "Picture block too big %d >= %d\n", blocklen, 1<<24);
+return AVERROR(EINVAL);
+}
+
+if(!isogg) {
+avio_w8(pb, 0x06);
+avio_wb24(pb, blocklen);
+
+avio_wb32(pb, type);
+
+avio_wb32(pb, mimelen);
+avio_write(pb, mimetype, mimelen);
+
+avio_wb32(pb, desclen);
+avio_write(pb, desc, desclen);
+
+avio_wb32(pb, st->codecpar->width);
+avio_wb32(pb, st->codecpar->height);
+if ((pixdesc = av_pix_fmt_desc_get(st->codecpar->format)))
+avio_wb32(pb, av_get_bits_per_pixel(pixdesc));
+else
+avio_wb32(pb, 0);
+avio_wb32(pb, 0);
+
+avio_wb32(pb, pkt->size);
+avio_write(pb, pkt->data, pkt->size);
+} else {
+uint8_t *metadata_block_picture, *ptr;
+int encoded_len, ret;
+char *encoded;
+AVStream *audio_stream = s->streams[audio_stream_idx];
+
+metadata_block_picture = av_mallocz(blocklen);
+ptr = metadata_block_picture;
+bytestream_put_be32(, type);
+
+bytestream_put_be32(, mimelen);
+bytestream_put_buffer(, mimetype, mimelen);
+
+bytestream_put_be32(, desclen);
+bytestream_put_buffer(, desc, desclen);
+
+bytestream_put_be32(, st->codecpar->width);
+bytestream_put_be32(, st->codecpar->height);
+if ((pixdesc = av_pix_fmt_desc_get(st->codecpar->format)))
+bytestream_put_be32(, av_get_bits_per_pixel(pixdesc));
+else
+bytestream_put_be32(, 0);
+bytestream_put_be32(, 0);
+
+bytestream_put_be32(, pkt->size);
+bytestream_put_buffer(, pkt->data, pkt->size);
+
+encoded_len = AV_BASE64_SIZE(blocklen);
+encoded = av_mallocz(encoded_len);
+av_base64_encode(encoded, encoded_len,
[FFmpeg-devel] [PATCH] lavc/aacpsdsp: use LMUL=2 and amortise strides
The input is laid out in 16 segments, of which 13 actually need to be loaded. There are no really efficient ways to deal with this: 1) If we load 8 segments wit unit stride, then narrow to 16 segments with right shifts, we can only one half-size vector per segment, or just 2 elements per vector (EMUL=1/2). This ends up unsurprisingly about as fas as the C code. 2) The current approach is to load with strides. We keep that approach, but improve it using three 4-segmented loads instead of 12 single-segment loads. This divides the number of distinct loaded addresses by 4. 3) A potential third approach would be to avoid segmentation altogether and splat the scalar coefficient into vectors. Then we can use a unit-stride and maximum EMUL. But the downside then is that we have to multiply the 3 (of 16) unused segments with zero as part of the multiply-accumulate operations. In addition, we also reuse vectors mid-loop so as to increase the EMUL from 1 to 2, which also improves performance a little bit. Oeverall the gains are quite small with the device under test, as it does not deal with segmented loads very well. But at least the code is tidier, and should enjoy bigger speed-ups on better hardware implementation. Before: ps_hybrid_analysis_c: 1819.2 ps_hybrid_analysis_rvv_f32: 1037.0 (before) ps_hybrid_analysis_rvv_f32: 990.0 (after) --- libavcodec/riscv/aacpsdsp_rvv.S | 61 +++-- 1 file changed, 20 insertions(+), 41 deletions(-) diff --git a/libavcodec/riscv/aacpsdsp_rvv.S b/libavcodec/riscv/aacpsdsp_rvv.S index 1dc426e01c..f46b35fe91 100644 --- a/libavcodec/riscv/aacpsdsp_rvv.S +++ b/libavcodec/riscv/aacpsdsp_rvv.S @@ -85,63 +85,42 @@ NOHWD fsw fs\n, (4 * \n)(sp) flw fs4, (4 * ((6 * 2) + 0))(a1) flw fs5, (4 * ((6 * 2) + 1))(a1) -adda2, a2, 6 * 2 * 4 // point to filter[i][6][0] +add t2, a2, 6 * 2 * 4 // point to filter[i][6][0] li t4, 8 * 2 * 4 // filter byte stride slli a3, a3, 3 // output byte stride 1: .macro filter, vs0, vs1, fo0, fo1, fo2, fo3 vfmacc.vf v8, \fo0, \vs0 -vfmacc.vf v9, \fo2, \vs0 +vfmacc.vf v10, \fo2, \vs0 vfnmsac.vf v8, \fo1, \vs1 -vfmacc.vf v9, \fo3, \vs1 +vfmacc.vf v10, \fo3, \vs1 .endm -vsetvlit0, a4, e32, m1, ta, ma +vsetvlit0, a4, e32, m2, ta, ma /* * The filter (a2) has 16 segments, of which 13 need to be extracted. * R-V V supports only up to 8 segments, so unrolling is unavoidable. */ -addi t1, a2, -48 -vlse32.v v22, (a2), t4 -addi t2, a2, -44 -vlse32.v v16, (t1), t4 -addi t1, a2, -40 -vfmul.vf v8, v22, fs4 -vlse32.v v24, (t2), t4 -addi t2, a2, -36 -vfmul.vf v9, v22, fs5 -vlse32.v v17, (t1), t4 -addi t1, a2, -32 -vlse32.v v25, (t2), t4 -addi t2, a2, -28 -filter v16, v24, ft0, ft1, ft2, ft3 -vlse32.v v18, (t1), t4 -addi t1, a2, -24 -vlse32.v v26, (t2), t4 -addi t2, a2, -20 -filter v17, v25, ft4, ft5, ft6, ft7 -vlse32.v v19, (t1), t4 -addi t1, a2, -16 -vlse32.v v27, (t2), t4 -addi t2, a2, -12 -filter v18, v26, ft8, ft9, ft10, ft11 -vlse32.v v20, (t1), t4 -addi t1, a2, -8 vlse32.v v28, (t2), t4 -addi t2, a2, -4 -filter v19, v27, fa0, fa1, fa2, fa3 -vlse32.v v21, (t1), t4 +addi t1, a2, 16 +vfmul.vf v8, v28, fs4 +vlsseg4e32.v v16, (a2), t4 +vfmul.vf v10, v28, fs5 +filter v16, v18, ft0, ft1, ft2, ft3 +vlsseg4e32.v v24, (t1), t4 +filter v20, v22, ft4, ft5, ft6, ft7 +addi t1, a2, 32 +filter v24, v26, ft8, ft9, ft10, ft11 +vlsseg4e32.v v16, (t1), t4 suba4, a4, t0 -vlse32.v v29, (t2), t4 +filter v28, v30, fa0, fa1, fa2, fa3 slli t1, t0, 3 + 1 + 2 // ctz(8 * 2 * 4) -adda2, a2, t1 -filter v20, v28, fa4, fa5, fa6, fa7 -filter v21, v29, fs0, fs1, fs2, fs3 - -addt2, a0, 4 -vsse32.v v8, (a0), a3 +filter v16, v18, fa4, fa5, fa6, fa7 mult0, t0, a3 -vsse32.v v9, (t2), a3 +filter v20, v22, fs0, fs1, fs2, fs3 +adda2, a2, t1 +addt2, t2, t1 +vssseg2e32.v v8, (a0), a3 adda0, a0, t0 bnez a4, 1b -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email
[FFmpeg-devel] [PATCH] avfilter: ambisonic decoder
Attached.
From 0ff5ad526363bed85022381134a152682cdba487 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Thu, 11 Jan 2018 21:32:22 +0100
Subject: [PATCH] avfilter: add ambisonic decoder
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile |1 +
libavfilter/af_ambisonic.c | 2003 ++
libavfilter/allfilters.c |1 +
libavfilter/ambisonic_template.c | 226
4 files changed, 2231 insertions(+)
create mode 100644 libavfilter/af_ambisonic.c
create mode 100644 libavfilter/ambisonic_template.c
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 04d4717b98..c780029d1f 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -71,6 +71,7 @@ OBJS-$(CONFIG_ALATENCY_FILTER) += f_latency.o
OBJS-$(CONFIG_ALIMITER_FILTER) += af_alimiter.o
OBJS-$(CONFIG_ALLPASS_FILTER)+= af_biquads.o
OBJS-$(CONFIG_ALOOP_FILTER) += f_loop.o
+OBJS-$(CONFIG_AMBISONIC_FILTER) += af_ambisonic.o
OBJS-$(CONFIG_AMERGE_FILTER) += af_amerge.o
OBJS-$(CONFIG_AMETADATA_FILTER) += f_metadata.o
OBJS-$(CONFIG_AMIX_FILTER) += af_amix.o
diff --git a/libavfilter/af_ambisonic.c b/libavfilter/af_ambisonic.c
new file mode 100644
index 00..d4df3bd3f1
--- /dev/null
+++ b/libavfilter/af_ambisonic.c
@@ -0,0 +1,2003 @@
+/*
+ * Copyright (c) 2022 Paul B Mahol
+ * Copyright (c) 2017 Sanchit Sinha
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+
+#include "libavutil/avstring.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/float_dsp.h"
+#include "libavutil/opt.h"
+#include "libavutil/avassert.h"
+#include "audio.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+
+#define EVEN 0
+#define ODD 1
+#define MAX_ORDER 3
+#define SQR(x) ((x) * (x))
+#define MAX_CHANNELS SQR(MAX_ORDER + 1)
+
+enum A_NAME {
+A_W, A_Y, A_Z, A_X, A_V, A_T, A_R, A_S, A_U, A_Q, A_O, A_M, A_K, A_L, A_N, A_P,
+};
+
+enum NearFieldType {
+NF_AUTO = -1,
+NF_NONE,
+NF_IN,
+NF_OUT,
+NB_NFTYPES,
+};
+
+enum PrecisionType {
+P_AUTO = -1,
+P_SINGLE,
+P_DOUBLE,
+NB_PTYPES,
+};
+
+enum PTypes {
+PT_AMP,
+PT_RMS,
+PT_ENERGY,
+PT_NBTYPES,
+};
+
+enum NormType {
+N3D,
+SN3D,
+FUMA,
+NB_NTYPES,
+};
+
+enum DirectionType {
+D_X,
+D_Y,
+D_Z,
+D_C,
+NB_DTYPES,
+};
+
+enum SequenceType {
+M_ACN,
+M_FUMA,
+M_SID,
+NB_MTYPES,
+};
+
+enum Layouts {
+MONO,
+STEREO,
+STEREO_DOWNMIX,
+SURROUND,
+L2_1,
+TRIANGLE,
+QUAD,
+SQUARE,
+L4_0,
+L5_0,
+L5_0_SIDE,
+L6_0,
+L7_0,
+TETRA,
+CUBE,
+NB_LAYOUTS,
+};
+
+typedef struct NearField {
+double d[MAX_ORDER];
+double z[MAX_ORDER];
+} NearField;
+
+typedef struct Xover {
+double b[3];
+double a[3];
+double w[2];
+} Xover;
+
+static const double gains_2d[][4] =
+{
+{ 1 },
+{ 1, 0.707107 },
+{ 1, 0.866025, 0.5 },
+{ 1, 0.92388, 0.707107, 0.382683 },
+};
+
+static const double gains_3d[][4] =
+{
+{ 1 },
+{ 1, 0.57735027 },
+{ 1, 0.774597, 0.4 },
+{ 1, 0.861136, 0.612334, 0.304747 },
+};
+
+static const double same_distance[] =
+{
+1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
+};
+
+static const double cube_azimuth[] =
+{
+315, 45, 135, 225, 315, 45, 135, 225,
+};
+
+static const double cube_elevation[] =
+{
+ 35.26439, 35.26439, 35.26439, 35.26439,
+-35.26439, -35.26439, -35.26439, -35.26439
+};
+
+static const struct {
+const int order;
+const int inputs;
+const int speakers;
+const int near_field;
+const int type;
+const double xover;
+const AVChannelLayout outlayout;
+const double *speakers_azimuth;
+const double *speakers_elevation;
+const double *speakers_distance;
+} ambisonic_tab[] = {
+[MONO] = {
+.order = 0,
+.inputs = 1,
+.speakers = 1,
+.near_field = NF_NONE,
+.xover = 0.,
+.outlayout = (AVChannelLayout)AV_CHANNEL_LAYOUT_MONO,
+
Re: [FFmpeg-devel] [PATCH v3] avcodec/decode: guard against NULL hw_frames_ctx
On Fri, Nov 17, 2023 at 6:04 PM Dmitry Rogozhkin
wrote:
>
> Guard against segfault running VLC decoding under msys2 [1]:
>
> Thread 33 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 37728.0xadd0]
> ff_hwaccel_frame_priv_alloc (avctx=0x6447b00,
> hwaccel_picture_private=0x65dfd00)
> at libavcodec/decode.c:1848
> 1848frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
> (gdb) bt
> at libavcodec/decode.c:1848
> at libavcodec/h264_slice.c:208
> first_slice=1) at libavcodec/h264_slice.c:1599
> at libavcodec/h264_slice.c:2130
> at libavcodec/h264dec.c:652
> got_frame=0x646e4b0, avpkt=0x64522c0) at libavcodec/h264dec.c:1048
>
> (gdb) p avctx
> $1 = (AVCodecContext *) 0x6447b00
> (gdb) p avctx->hw_frames_ctx
> $2 = (AVBufferRef *) 0x0
>
> v2: check for free_frame_priv (Hendrik)
> v3: return EINVAL (Christoph Reiter)
>
> See[1]: https://github.com/msys2/MINGW-packages/pull/19050
> Fixes: be07145109 ("avcodec: add AVHWAccel.free_frame_priv callback")
> CC: Lynne
> CC: Christoph Reiter
> Signed-off-by: Dmitry Rogozhkin
> ---
The latest change itself looks fine to me, I would however prefer if
the commit message would contain a bit more text and a bit less gdb
dump.
Maybe something like this (quick suggestion, for title and body):
avcodec: validate hw_frames_ctx is available when
AVHWAccel.free_frame_priv is used
Validate that a hw_frames_ctx is available before using it for the
AVHWAccel.free_frame_priv callback, and don't require it to be present when
the callback is not in use by the HWAccel.
---
Feel free to augment and reword, but I don't think the gdb dump offers
much info that couldn't be conveyed more clearly in a few words that
mention the absence of hw_frame_ctx.
- 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] FFmpeg at NAB 2024
On Sun, 19 Nov 2023, 14:05 Derek Buitenhuis, wrote: > Hi, > > Followup question... > > On 11/1/2023 9:25 PM, Derek Buitenhuis wrote: > > This is certainly interesting considering we just had a giant thread > about not using > > or using SPI, with multiple people accused of having corporate interests. > > I noticed FFmpeg is on the NAB floor plan. > > This implies FFmpeg has signed a contract with NAB, as to my knowledge, > you are > not on the floor plan without doing that. > > There is one slight problem here... FFmpeg does not have a legal entity in > which > such a contract could have been signed. > > So who signed? The "anonymous" corproate entity, on behalf of FFmpeg, with > out > our consent? > > Pardon my French, but this is sketchy as all fuck. > In addition, the remaining costs of the booth, which in my experience total around twice as much as the floor space itself need to be paid by this corporate contributor. I would not find it acceptable for SPI to pay these costs. I do not feel donors would want their money spent on a corporate show in Las Vegas. Also no plan has been provided about who will actually be present on the booth. Ragards, Kieran Kunhya > ___ 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] FFmpeg at NAB 2024
On 11/19/2023 2:19 PM, Derek Buitenhuis wrote: > http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/317196.html FFS. Here is the right link: http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316603.html - Deek ___ 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] FFmpeg at NAB 2024
On 11/19/2023 2:05 PM, Derek Buitenhuis wrote: > So who signed? The "anonymous" corproate entity, on behalf of FFmpeg, with out > our consent? http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/317196.html Prob unrelated I am sure. - 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] FFmpeg at NAB 2024
Hi, Followup question... On 11/1/2023 9:25 PM, Derek Buitenhuis wrote: > This is certainly interesting considering we just had a giant thread about > not using > or using SPI, with multiple people accused of having corporate interests. I noticed FFmpeg is on the NAB floor plan. This implies FFmpeg has signed a contract with NAB, as to my knowledge, you are not on the floor plan without doing that. There is one slight problem here... FFmpeg does not have a legal entity in which such a contract could have been signed. So who signed? The "anonymous" corproate entity, on behalf of FFmpeg, with out our consent? Pardon my French, but this is sketchy as all fuck. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/g722dsp: optimise R-V V apply_qmf
This stores the constant coefficients deinterleaved, so that they can be loaded directly with NF=0. Unfortunately, we cannot optimise loading the input, due to insufficient memory alignment (not 32-bit). Before: g722_apply_qmf_c: 82.5 g722_apply_qmf_rvv_i32: 78.2 After: g722_apply_qmf_c: 82.5 g722_apply_qmf_rvv_i32: 65.2 --- libavcodec/riscv/g722dsp_rvv.S | 24 +--- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/libavcodec/riscv/g722dsp_rvv.S b/libavcodec/riscv/g722dsp_rvv.S index 350be8dc1f..981d5cecd8 100644 --- a/libavcodec/riscv/g722dsp_rvv.S +++ b/libavcodec/riscv/g722dsp_rvv.S @@ -24,7 +24,9 @@ func ff_g722_apply_qmf_rvv, zve32x lla t0, qmf_coeffs vsetivlizero, 12, e16, m2, ta, ma vlseg2e16.v v28, (a0) -vlseg2e16.v v24, (t0) +addit1, t0, 12 * 2 +vle16.v v24, (t0) +vle16.v v26, (t1) vwmul.vvv16, v28, v24 vwmul.vvv20, v30, v26 vsetivlizero, 12, e32, m4, ta, ma @@ -41,26 +43,26 @@ endfunc const qmf_coeffs, align=2 .short 3 .short -11 -.short -11 -.short53 .short12 -.short -156 .short32 -.short 362 .short -210 -.short -805 .short 951 .short 3876 -.short 3876 -.short 951 .short -805 -.short -210 .short 362 -.short32 .short -156 -.short12 .short53 .short -11 .short -11 +.short53 +.short -156 +.short 362 +.short -805 +.short 3876 +.short 951 +.short -210 +.short32 +.short12 +.short -11 .short 3 endconst -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavu/fixed_dsp: R-V V fmul_window_scaled
vector_fmul_window_scaled_fixed_c: 4393.7
vector_fmul_window_scaled_fixed_rvv_i64: 1642.7
---
libavutil/riscv/fixed_dsp_init.c | 7 -
libavutil/riscv/fixed_dsp_rvv.S | 48
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/libavutil/riscv/fixed_dsp_init.c b/libavutil/riscv/fixed_dsp_init.c
index 6469b45374..cd318af486 100644
--- a/libavutil/riscv/fixed_dsp_init.c
+++ b/libavutil/riscv/fixed_dsp_init.c
@@ -25,6 +25,9 @@
#include "libavutil/cpu.h"
#include "libavutil/fixed_dsp.h"
+void ff_vector_fmul_window_scaled_rvv(int16_t *dst, const int32_t *src0,
+ const int32_t *src1, const int32_t *win,
+ int len, uint8_t bits);
void ff_vector_fmul_window_fixed_rvv(int32_t *dst, const int32_t *src0,
const int32_t *src1, const int32_t *win,
int len);
@@ -43,8 +46,10 @@ av_cold void ff_fixed_dsp_init_riscv(AVFixedDSPContext *fdsp)
int flags = av_get_cpu_flags();
if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
-if (flags & AV_CPU_FLAG_RVV_I64)
+if (flags & AV_CPU_FLAG_RVV_I64) {
+fdsp->vector_fmul_window_scaled = ff_vector_fmul_window_scaled_rvv;
fdsp->vector_fmul_window = ff_vector_fmul_window_fixed_rvv;
+}
fdsp->vector_fmul = ff_vector_fmul_fixed_rvv;
fdsp->vector_fmul_reverse = ff_vector_fmul_reverse_fixed_rvv;
diff --git a/libavutil/riscv/fixed_dsp_rvv.S b/libavutil/riscv/fixed_dsp_rvv.S
index 68de6d7e1b..6bac5813b8 100644
--- a/libavutil/riscv/fixed_dsp_rvv.S
+++ b/libavutil/riscv/fixed_dsp_rvv.S
@@ -20,6 +20,54 @@
#include "asm.S"
+func ff_vector_fmul_window_scaled_rvv, zve64x
+csrwi vxrm, 0
+vsetvli t0, zero, e16, m1, ta, ma
+sh2add a2, a4, a2
+vid.v v0
+sh3add t3, a4, a3
+vadd.vi v0, v0, 1
+sh2add t0, a4, a0
+1:
+vsetvli t2, a4, e16, m1, ta, ma
+sllit4, t2, 2
+sllit1, t2, 1
+vrsub.vx v2, v0, t2
+sub t3, t3, t4
+vsetvli zero, zero, e32, m2, ta, ma
+sub a2, a2, t4
+vle32.v v8, (t3)
+sub t0, t0, t1
+vle32.v v4, (a2)
+sub a4, a4, t2
+vrgatherei16.vv v28, v8, v2
+vle32.v v16, (a1)
+add a1, a1, t4
+vrgatherei16.vv v20, v4, v2
+vle32.v v24, (a3)
+add a3, a3, t4
+vwmul.vv v12, v16, v28
+vwmul.vv v8, v16, v24
+// vwnmsac.vv does _not_ exist so multiply & subtract separately
+vwmul.vv v4, v20, v24
+vwmacc.vv v8, v20, v28
+vsetvli zero, zero, e64, m4, ta, ma
+vsub.vv v12, v12, v4
+vsetvli zero, zero, e32, m2, ta, ma
+vnclip.wi v16, v8, 31
+vnclip.wi v20, v12, 31
+vsetvli zero, zero, e16, m1, ta, ma
+vnclip.wx v8, v16, a5
+vnclip.wx v12, v20, a5
+vrgatherei16.vv v16, v8, v2
+vse16.v v12, (a0)
+add a0, a0, t1
+vse16.v v16, (t0)
+bneza4, 1b
+
+ret
+endfunc
+
func ff_vector_fmul_window_fixed_rvv, zve64x
csrwi vxrm, 0
vsetvli t0, zero, e16, m1, ta, ma
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA v2
Quoting Michael Niedermayer (2023-11-19 11:35:20) > On Sun, Nov 19, 2023 at 08:48:19AM +0100, Anton Khirnov wrote: > > Reminder that the vote starts tomorrow. > > > > Quoting Anton Khirnov (2023-11-17 10:40:06) > > > The list of candidates I have so far is: > > > * Ronald Bultje > > > * Alexander Strasser > > > * Hendrik Leppkes > > > * Reimar Döffinger > > > * Baptiste Coudurier > > > (hope I haven't missed anyone, please tell me if I did) > > > > > > If we get an agreement from any further people Michael has contacted > > > before the vote starts, I will also add them the list. > > > > So far Shiyou Yin has agreed to be added to the list. > > I can confirm that, i have not received any additional yes replies either > at the moment > > so from the 12 sent out emails > (this only included people active or in GA 2020 or paying infra) > we got 2 people saying yes ATM > from most we got no reply yet > maybe we should give people a little more time > to avoid having to do a 2nd vote round, if we get a late yes reply? I'd rather not postpone the vote much longer. I suppose we could start it on Tuesday, but I see little point in waiting beyond that - how much time does it take to write a simple '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".
[FFmpeg-devel] [PATCH 2/2] lavfi/vsrc_ddagrab: add an option to avoid duplicating frames
---
doc/filters.texi | 15 +++
libavfilter/vsrc_ddagrab.c | 7 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index bd4e4ca8f7..30b7c73826 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -28165,10 +28165,10 @@ it'll always be captured.
@item framerate
Maximum framerate at which the desktop will be captured - the interval between
successive frames will not be smaller than the inverse of the framerate. When
-the desktop is not being updated often enough, the filter will duplicate
-a previous frame. Note that there is no background buffering going on, so when
-the filter is not polled often enough then the actual inter-frame interval may
-be significantly larger.
+@var{dup_frames} is true (the default) and the desktop is not being updated
+often enough, the filter will duplicate a previous frame. Note that there is no
+background buffering going on, so when the filter is not polled often enough
+then the actual inter-frame interval may be significantly larger.
Defaults to 30 FPS.
@@ -28201,6 +28201,13 @@ Passes all supported output formats to DDA and returns
what DDA decides to use.
Filter initialization will fail if 10 bit format is requested but unavailable.
@end table
+@item dup_frames
+When this option is set to true (the default), the filter will duplicate frames
+when the desktop has not been updated in order to maintain approximately
+constant target framerate. When this option is set to false, the filter will
+wait for the desktop to be updated (inter-frame intervals may vary
significantly
+in this case).
+
@end table
@subsection Examples
diff --git a/libavfilter/vsrc_ddagrab.c b/libavfilter/vsrc_ddagrab.c
index 9c59faf53e..76dd11af51 100644
--- a/libavfilter/vsrc_ddagrab.c
+++ b/libavfilter/vsrc_ddagrab.c
@@ -101,6 +101,7 @@ typedef struct DdagrabContext {
intout_fmt;
intallow_fallback;
intforce_fmt;
+intdup_frames;
} DdagrabContext;
#define OFFSET(x) offsetof(DdagrabContext, x)
@@ -124,6 +125,8 @@ static const AVOption ddagrab_options[] = {
OFFSET(allow_fallback),
AV_OPT_TYPE_BOOL, { .i64 = 0}, 0, 1, FLAGS },
{ "force_fmt", "exclude BGRA from format list (experimental, discouraged
by Microsoft)",
OFFSET(force_fmt),
AV_OPT_TYPE_BOOL, { .i64 = 0}, 0, 1, FLAGS },
+{ "dup_frames", "duplicate frames to maintain framerate",
+ OFFSET(dup_frames),
AV_OPT_TYPE_BOOL, { .i64 = 1}, 0, 1, FLAGS },
{ NULL }
};
@@ -1067,7 +1070,9 @@ static int ddagrab_request_frame(AVFilterLink *outlink)
now -= dda->first_pts;
if (!dda->probed_texture) {
-ret = next_frame_internal(avctx, _texture, 0);
+do {
+ret = next_frame_internal(avctx, _texture, 0);
+} while (ret == AVERROR(EAGAIN) && !dda->dup_frames);
} else {
cur_texture = dda->probed_texture;
dda->probed_texture = NULL;
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] doc/filters:ddagrab: elaborate on the semantics of framerate
--- doc/filters.texi | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/doc/filters.texi b/doc/filters.texi index 38615e4f18..bd4e4ca8f7 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -28163,7 +28163,12 @@ Only affects hardware cursors. If a game or application renders its own cursor, it'll always be captured. @item framerate -Framerate at which the desktop will be captured. +Maximum framerate at which the desktop will be captured - the interval between +successive frames will not be smaller than the inverse of the framerate. When +the desktop is not being updated often enough, the filter will duplicate +a previous frame. Note that there is no background buffering going on, so when +the filter is not polled often enough then the actual inter-frame interval may +be significantly larger. Defaults to 30 FPS. -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: merge loudnorm filter functionality into f_ebur128.c
On Fri, Nov 17, 2023 at 7:38 AM Kyle Swanson wrote: > Hi, > > On Wed, Nov 15, 2023 at 12:39 PM Paul B Mahol wrote: > > > > Attached. > > Only had a few minutes to look at this. Seems like more than just > merging two filters, I see a bunch of new filter options for example. > Can you explain? > The linear mode and scanning, both input to filter and filter output itself should give similar results. The dynamic mode now actually can be configured how aggressively it will expand / compress audio. Because current state of filter have numerous issues: - using unmaintained old libebur128 module, when same functionality is already available in existing filter. - code duplication and functionality duplication due the above - buggy limiter - causing clipped samples randomly - buggy first and final frame filtering - over-complicated flow path for dynamic code in filter - excessive compressing of audio dynamic range, causing extreme smaller LRU from output audio - and probably more that I forgot Some options from this patch can be probably removed, like attack/release options, and just use defaults as currently in patch. > Thanks, > Kyle > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] lavu/float_dsp: optimise R-V V fmul_reverse & fmul_window
Roll the loop to avoid slow gathers. Before: vector_fmul_reverse_c: 1561.7 vector_fmul_reverse_rvv_f32: 2410.2 vector_fmul_window_c:2068.2 vector_fmul_window_rvv_f32: 1879.5 After: vector_fmul_reverse_c: 1561.7 vector_fmul_reverse_rvv_f32: 916.2 vector_fmul_window_c:2068.2 vector_fmul_window_rvv_f32: 1202.5 --- libavutil/riscv/float_dsp_rvv.S | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/libavutil/riscv/float_dsp_rvv.S b/libavutil/riscv/float_dsp_rvv.S index a2f9488249..ce5b6823d4 100644 --- a/libavutil/riscv/float_dsp_rvv.S +++ b/libavutil/riscv/float_dsp_rvv.S @@ -75,18 +75,19 @@ endfunc func ff_vector_fmul_window_rvv, zve32f // a0: dst, a1: src0, a2: src1, a3: window, a4: length -vsetvlit0, zero, e16, m2, ta, ma +// e16/m2 and e32/m4 are possible but slower due to gather. +vsetvlit0, zero, e16, m1, ta, ma sh2add a2, a4, a2 vid.v v0 sh3add t3, a4, a3 vadd.viv0, v0, 1 sh3add t0, a4, a0 1: -vsetvlit2, a4, e16, m2, ta, ma +vsetvlit2, a4, e16, m1, ta, ma slli t4, t2, 2 vrsub.vx v2, v0, t2 subt3, t3, t4 -vsetvlizero, zero, e32, m4, ta, ma +vsetvlizero, zero, e32, m2, ta, ma suba2, a2, t4 vle32.vv8, (t3) subt0, t0, t4 @@ -133,6 +134,7 @@ endfunc // TODO factor vrsub, separate last iteration? // (a0) = (a1) * reverse(a2) [0..a3-1] func ff_vector_fmul_reverse_rvv, zve32f +// e16/m4 and e32/m8 are possible but slower due to gather. vsetvli t0, zero, e16, m4, ta, ma sh2add a2, a3, a2 vid.vv0 -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] lavu/fixed_dsp: optimise R-V V fmul_reverse
Gathers are (unsurprisingly) a notable exception to the rule that R-V V gets faster with larger group multipliers. So roll the function to speed it up. Before: vector_fmul_reverse_fixed_c: 2840.7 vector_fmul_reverse_fixed_rvv_i32: 2430.2 After: vector_fmul_reverse_fixed_c: 2841.0 vector_fmul_reverse_fixed_rvv_i32: 962.2 It might be possible to further optimise the function by moving the reverse-subtract out of the loop and adding ad-hoc tail handling. --- libavutil/riscv/fixed_dsp_rvv.S | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/libavutil/riscv/fixed_dsp_rvv.S b/libavutil/riscv/fixed_dsp_rvv.S index 2bece88685..46bb591352 100644 --- a/libavutil/riscv/fixed_dsp_rvv.S +++ b/libavutil/riscv/fixed_dsp_rvv.S @@ -127,16 +127,17 @@ endfunc func ff_vector_fmul_reverse_fixed_rvv, zve32x csrwi vxrm, 0 -vsetvli t0, zero, e16, m4, ta, ma +// e16/m4 and e32/m8 are possible but slow the gathers down. +vsetvli t0, zero, e16, m1, ta, ma sh2add a2, a3, a2 vid.v v0 vadd.vi v0, v0, 1 1: -vsetvli t0, a3, e16, m4, ta, ma +vsetvli t0, a3, e16, m1, ta, ma sllit1, t0, 2 vrsub.vx v4, v0, t0 // v4[i] = [VL-1, VL-2... 1, 0] sub a2, a2, t1 -vsetvli zero, zero, e32, m8, ta, ma +vsetvli zero, zero, e32, m2, ta, ma vle32.v v8, (a2) sub a3, a3, t0 vle32.v v16, (a1) -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] doc/encoders/libx264: review and extend option description
On date Saturday 2023-11-04 22:26:27 +0100, Stefano Sabatini wrote:
> On date Wednesday 2023-09-06 11:04:49 +0530, Gyan Doshi wrote:
> [...]
>
> Sorry for the slow reply.
>
> > > -Argument is a list of @var{key}=@var{value} couples separated by
> > > -":". In @var{filter} and @var{psy-rd} options that use ":" as a separator
> > > -themselves, use "," instead. They accept it as well since long ago but
> > > this
> > > -is kept undocumented for some reason.
> > > +@option{x264-param} is functionally the same as the @option{x264opts},
> > > +but is duplicated for compatibility with the Libav fork.
> >
> > There is a difference, in that x264opts accepts boolean args without a
> > value.
>
> Right.
>
> > > +
> > > +The argument for both options is a list of @var{key}=@var{value}
> > > +couples separated by ":". In @var{filter} and @var{psy-rd} options
> > > +that use ":" as a separator themselves, use "," instead. They accept
> > > +it as well since long ago but this is kept undocumented for some
> > > +reason.
> > > +
> > > +For example, the options might be provided as:
> > > +@example
> > > +level=30:bframes=0:weightp=0:cabac=0:ref=1:vbv-maxrate=768:vbv-bufsize=2000:analyse=all:me=umh:no-fast-pskip=1:subq=6:8x8dct=0:trellis=0
> > > +@end example
> > > For example to specify libx264 encoding options with @command{ffmpeg}:
> > > @example
> > > ffmpeg -i foo.mpg -c:v libx264 -x264opts keyint=123:min-keyint=20 -an
> > > out.mkv
> > > @end example
> > > +To get the complete list of the libx264 options, invoke the command
> > > +@command{x264 --fullhelp} or consult the libx264 documentation.
> >
>
> > May want to make it clear that x264 refers to the standalone CLI tool.
>
> Isn't that clear enough? (we use the same formula in other places,
> e.g. in x265 docs).
>
> From a11eafe5a61a572f4e9ab9e4ab9907bba98300e4 Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini
> Date: Sat, 26 Aug 2023 01:10:09 +0200
> Subject: [PATCH] doc/encoders/libx264: review and extend option description
>
> Also, merge x264opts and x264-opts option docs to avoid duplication
> and make it clearer that they provide mostly the same functionality.
> ---
> doc/encoders.texi | 65 ++-
> 1 file changed, 36 insertions(+), 29 deletions(-)
Will apply in a few days if I see no comments.
___
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] lavfilter/af_loudnorm: fix loudnorm limiter invalid at final frame
There are much more serious issues with this filter. That why my approach and fix is to completely rewrite it. ___ 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] [ANNOUNCE] upcoming vote: extra members for GA v2
On Sun, Nov 19, 2023 at 08:48:19AM +0100, Anton Khirnov wrote: > Reminder that the vote starts tomorrow. > > Quoting Anton Khirnov (2023-11-17 10:40:06) > > The list of candidates I have so far is: > > * Ronald Bultje > > * Alexander Strasser > > * Hendrik Leppkes > > * Reimar Döffinger > > * Baptiste Coudurier > > (hope I haven't missed anyone, please tell me if I did) > > > > If we get an agreement from any further people Michael has contacted > > before the vote starts, I will also add them the list. > > So far Shiyou Yin has agreed to be added to the list. I can confirm that, i have not received any additional yes replies either at the moment so from the 12 sent out emails (this only included people active or in GA 2020 or paying infra) we got 2 people saying yes ATM from most we got no reply yet maybe we should give people a little more time to avoid having to do a 2nd vote round, if we get a late yes reply? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avcodec/decode: guard against NULL hw_frames_ctx
On 2023-11-17 09:03:03 -0800, Dmitry Rogozhkin wrote:
> Guard against segfault running VLC decoding under msys2 [1]:
>
> Thread 33 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 37728.0xadd0]
> ff_hwaccel_frame_priv_alloc (avctx=0x6447b00,
> hwaccel_picture_private=0x65dfd00)
> at libavcodec/decode.c:1848
> 1848frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
> (gdb) bt
> at libavcodec/decode.c:1848
> at libavcodec/h264_slice.c:208
> first_slice=1) at libavcodec/h264_slice.c:1599
> at libavcodec/h264_slice.c:2130
> at libavcodec/h264dec.c:652
> got_frame=0x646e4b0, avpkt=0x64522c0) at libavcodec/h264dec.c:1048
>
> (gdb) p avctx
> $1 = (AVCodecContext *) 0x6447b00
> (gdb) p avctx->hw_frames_ctx
> $2 = (AVBufferRef *) 0x0
>
> v2: check for free_frame_priv (Hendrik)
> v3: return EINVAL (Christoph Reiter)
>
> See[1]: https://github.com/msys2/MINGW-packages/pull/19050
> Fixes: be07145109 ("avcodec: add AVHWAccel.free_frame_priv callback")
> CC: Lynne
> CC: Christoph Reiter
> Signed-off-by: Dmitry Rogozhkin
We have also seen the same issue on Debian unstable with VDPAU playback
in vlc. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055952. I
can confirm that this patch fixes the issue. Please apply the patch and
backport it to 6.1.
Cheers
> ---
> libavcodec/decode.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index ad39021..50c3995 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1838,17 +1838,25 @@ int ff_copy_palette(void *dst, const AVPacket *src,
> void *logctx)
> int ff_hwaccel_frame_priv_alloc(AVCodecContext *avctx, void
> **hwaccel_picture_private)
> {
> const FFHWAccel *hwaccel = ffhwaccel(avctx->hwaccel);
> -AVHWFramesContext *frames_ctx;
>
> if (!hwaccel || !hwaccel->frame_priv_data_size)
> return 0;
>
> av_assert0(!*hwaccel_picture_private);
>
> -frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
> -*hwaccel_picture_private =
> ff_refstruct_alloc_ext(hwaccel->frame_priv_data_size, 0,
> - frames_ctx->device_ctx,
> -
> hwaccel->free_frame_priv);
> +if (hwaccel->free_frame_priv) {
> +AVHWFramesContext *frames_ctx;
> +
> +if (!avctx->hw_frames_ctx)
> +return AVERROR(EINVAL);
> +
> +*hwaccel_picture_private =
> ff_refstruct_alloc_ext(hwaccel->frame_priv_data_size, 0,
> +
> frames_ctx->device_ctx,
> +
> hwaccel->free_frame_priv);
> +} else {
> +*hwaccel_picture_private =
> ff_refstruct_allocz(hwaccel->frame_priv_data_size);
> +}
> +
> if (!*hwaccel_picture_private)
> return AVERROR(ENOMEM);
>
> --
> 1.8.3.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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".
