[FFmpeg-devel] [PATCH] avcodec/ac3dec: fix downmix logic for eac3
Ensure downmixed is only set once during init, as it used to be.
Fixes a regression since acbb2777e28c.
Fixes ticket #11321.
Signed-off-by: James Almer
---
libavcodec/ac3dec.c | 121 ++--
1 file changed, 61 insertions(+), 60 deletions(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 0a4d3375ee..11374bcb7d 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -199,7 +199,6 @@ static void ac3_downmix(AVCodecContext *avctx)
av_channel_layout_uninit(&avctx->ch_layout);
avctx->ch_layout = (AVChannelLayout)AV_CHANNEL_LAYOUT_STEREO;
}
-s->downmixed = 1;
}
/**
@@ -241,6 +240,7 @@ static av_cold int ac3_decode_init(AVCodecContext *avctx)
avctx->sample_fmt = AV_SAMPLE_FMT_FLTP;
ac3_downmix(avctx);
+s->downmixed = 1;
for (i = 0; i < AC3_MAX_CHANNELS; i++) {
s->xcfptr[i] = s->transform_coeffs[i];
@@ -1647,6 +1647,66 @@ dependent_frame:
if (ch < s->out_channels)
s->outptr[channel_map[ch]] = s->output_buffer[ch + offset];
}
+
+for (ch = 0; ch < EAC3_MAX_CHANNELS; ch++)
+extended_channel_map[ch] = ch;
+
+if (s->frame_type == EAC3_FRAME_TYPE_DEPENDENT) {
+uint64_t ich_layout = ff_ac3_channel_layout_tab[s->prev_output_mode &
~AC3_OUTPUT_LFEON];
+int channel_map_size = ff_ac3_channels_tab[s->output_mode &
~AC3_OUTPUT_LFEON] + s->lfe_on;
+uint64_t channel_layout;
+int extend = 0;
+
+if (s->prev_output_mode & AC3_OUTPUT_LFEON)
+ich_layout |= AV_CH_LOW_FREQUENCY;
+
+channel_layout = ich_layout;
+for (ch = 0; ch < 16; ch++) {
+if (s->channel_map & (1 << (EAC3_MAX_CHANNELS - ch - 1))) {
+channel_layout |= ff_eac3_custom_channel_map_locations[ch][1];
+}
+}
+if (av_popcount64(channel_layout) > EAC3_MAX_CHANNELS) {
+av_log(avctx, AV_LOG_ERROR, "Too many channels (%d) coded\n",
+ av_popcount64(channel_layout));
+return AVERROR_INVALIDDATA;
+}
+
+av_channel_layout_uninit(&avctx->ch_layout);
+av_channel_layout_from_mask(&avctx->ch_layout, channel_layout);
+
+for (ch = 0; ch < EAC3_MAX_CHANNELS; ch++) {
+if (s->channel_map & (1 << (EAC3_MAX_CHANNELS - ch - 1))) {
+if (ff_eac3_custom_channel_map_locations[ch][0]) {
+int index =
av_channel_layout_index_from_channel(&avctx->ch_layout,
+
ff_ctzll(ff_eac3_custom_channel_map_locations[ch][1]));
+if (index < 0)
+return AVERROR_INVALIDDATA;
+if (extend >= channel_map_size)
+break;
+
+extended_channel_map[index] = offset +
channel_map[extend++];
+} else {
+int i;
+
+for (i = 0; i < 64; i++) {
+if ((1ULL << i) &
ff_eac3_custom_channel_map_locations[ch][1]) {
+int index =
av_channel_layout_index_from_channel(&avctx->ch_layout, i);
+if (index < 0)
+return AVERROR_INVALIDDATA;
+if (extend >= channel_map_size)
+break;
+
+extended_channel_map[index] = offset +
channel_map[extend++];
+}
+}
+}
+}
+}
+
+ac3_downmix(avctx);
+}
+
for (blk = 0; blk < s->num_blocks; blk++) {
if (!err && decode_audio_block(s, blk, offset)) {
av_log(avctx, AV_LOG_ERROR, "error decoding the audio block\n");
@@ -1713,65 +1773,6 @@ skip:
return AVERROR_INVALIDDATA;
}
-for (ch = 0; ch < EAC3_MAX_CHANNELS; ch++)
-extended_channel_map[ch] = ch;
-
-if (s->frame_type == EAC3_FRAME_TYPE_DEPENDENT) {
-uint64_t ich_layout = ff_ac3_channel_layout_tab[s->prev_output_mode &
~AC3_OUTPUT_LFEON];
-int channel_map_size = ff_ac3_channels_tab[s->output_mode &
~AC3_OUTPUT_LFEON] + s->lfe_on;
-uint64_t channel_layout;
-int extend = 0;
-
-if (s->prev_output_mode & AC3_OUTPUT_LFEON)
-ich_layout |= AV_CH_LOW_FREQUENCY;
-
-channel_layout = ich_layout;
-for (ch = 0; ch < 16; ch++) {
-if (s->channel_map & (1 << (EAC3_MAX_CHANNELS - ch - 1))) {
-channel_layout |= ff_eac3_custom_channel_map_locations[ch][1];
-}
-}
-if (av_popcount64(channel_layout) > EAC3_MAX_CHANNELS) {
-av_log(avctx, AV_LOG_ERROR, "Too many channels (%d) coded\n",
- av_popcount64(channel_layout));
-return AVERROR_INVALIDDATA;
-}
-
-av_channel_layout_uninit(&avctx->ch_layout);
-av_channel_layout_from_mas
Re: [FFmpeg-devel] [PATCH] Use AVBufferPool in MOV
On 11/24/2024 2:31 PM, James Almer wrote:
On 11/22/2024 2:46 PM, Arnaud Masserann wrote:
Most demuxers allocate a new buffer for each packet.
For MOV, this can be problematic, because of some high-bitrate
codecs like ProRes/HAPQ/NotchLC.
Use pools of buffer instead.
For some test media, demuxing goes from 20ms/frame to 11ms/frame,
close to the perf of ReadFile (10ms/frame), making it possible
to read the media at 60Hz.
Signed-off-by: Arnaud Masserann
---
libavformat/avformat.h | 12
libavformat/isom.h | 2 ++
libavformat/mov.c | 20 ++--
libavformat/utils.c | 29 +
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 56c1c80289..25f2e59b22 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -440,6 +440,18 @@ int av_get_packet(AVIOContext *s, AVPacket *pkt,
int size);
*/
int av_append_packet(AVIOContext *s, AVPacket *pkt, int size);
+
+/**
+ * Like av_get_packet, but allocates the AVPacket's buffer from a pool.
+ *
+ * @param s associated IO context
+ * @param pool the pool of buffers; must be initialized with a
sufficient size
+ * @param pkt packet
+ * @param size desired payload size
+ * @return >0 (read size) if OK, AVERROR_xxx otherwise
+ */
+int av_get_pooled_packet(AVIOContext *s, AVBufferPool* pool, AVPacket
*pkt, int size);
This doesn't need to be public. It can be internal to lavf just fine.
+
/*/
/* input/output formats */
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 4723397048..c608f30e04 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -273,6 +273,8 @@ typedef struct MOVStreamContext {
} cenc;
struct IAMFDemuxContext *iamf;
+
+ AVBufferPool* pools[32];
Like you argued, this can be in MovContext instead, since the pools are
fixed size and can be used by any stream.
} MOVStreamContext;
typedef struct HEIFItem {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index a2333ac1fd..2668bdf78f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -9583,6 +9583,7 @@ static void
mov_free_encryption_index(MOVEncryptionIndex **index) {
static void mov_free_stream_context(AVFormatContext *s, AVStream *st)
{
MOVStreamContext *sc = st->priv_data;
+ int i;
if (!sc || --sc->refcount) {
st->priv_data = NULL;
@@ -9639,6 +9640,9 @@ static void
mov_free_stream_context(AVFormatContext *s, AVStream *st)
ff_iamf_read_deinit(sc->iamf);
#endif
av_freep(&sc->iamf);
+
+ for (i = 0; i < FF_ARRAY_ELEMS(sc->pools); i++)
+ av_buffer_pool_uninit(&sc->pools[i]);
}
static int mov_read_close(AVFormatContext *s)
@@ -10544,6 +10548,16 @@ static int
mov_finalize_packet(AVFormatContext *s, AVStream *st, AVIndexEntry *s
return 0;
}
+static AVBufferPool *mov_pool_get(AVBufferPool* pools[32], int size)
+{
+ int index = av_log2(size + AV_INPUT_BUFFER_PADDING_SIZE);
+ if (!pools[index]) {
+ int pool_size = 2 << index;
+ pools[index] = av_buffer_pool_init(pool_size, NULL);
+ }
+ return pools[index];
+}
+
static int mov_read_packet(AVFormatContext *s, AVPacket *pkt)
{
MOVContext *mov = s->priv_data;
@@ -10617,8 +10631,10 @@ static int mov_read_packet(AVFormatContext
*s, AVPacket *pkt)
return FFERROR_REDO;
}
#endif
- else
- ret = av_get_packet(sc->pb, pkt, sample->size);
+ else{
+ AVBufferPool* pool = mov_pool_get(sc->pools, sample->size);
+ ret = av_get_pooled_packet(sc->pb, pool, pkt, sample->size);
+ }
if (ret < 0) {
if (should_retry(sc->pb, ret)) {
mov_current_sample_dec(sc);
diff --git a/libavformat/utils.c b/libavformat/utils.c
index e9ded627ad..869e97c089 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -104,6 +104,35 @@ FF_ENABLE_DEPRECATION_WARNINGS
return append_packet_chunked(s, pkt, size);
}
+int av_get_pooled_packet(AVIOContext *s, AVBufferPool* pool, AVPacket
*pkt, int size)
+{
+#if FF_API_INIT_PACKET
+FF_DISABLE_DEPRECATION_WARNINGS
+ av_init_packet(pkt);
+ pkt->data = NULL;
+ pkt->size = 0;
+FF_ENABLE_DEPRECATION_WARNINGS
+#else
+ av_packet_unref(pkt);
+#endif
+ pkt->pos = avio_tell(s);
+
+ if(!pool)
+ return AVERROR(ENOMEM);
+
+ pkt->buf = av_buffer_pool_get(pool);;
Extra ;
+ if(!pkt->buf)
+ return AVERROR(ENOMEM);
+
+ if(pkt->buf->size < size){
+ av_packet_unref(pkt); // TODO test this
+ return AVERROR(ENOMEM);
Maybe EINVAL instead.
Also, you're not setting pkt->data to pkt->buf->data.
Actually, disregard this part. It's fine as is.
+ }
+
+ return append_packet_chunked(s, pkt, size);
+}
+
+
int av_append_packet(AVIOContext *s, AVPacket *pkt, int size)
{
if (!pkt->size)
OpenPGP_signature.asc
Desc
Re: [FFmpeg-devel] [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
Hi Ronald On Sun, Nov 24, 2024 at 08:26:28AM -0500, Ronald S. Bultje wrote: > Hi Michael, > > On Sat, Nov 23, 2024 at 8:12 AM Michael Niedermayer > wrote: > > > +Stay On-Topic: Ensure your messages relate to software development or the > > specific purpose of the mailing list. Avoid unrelated discussions. > > +Be Respectful: Treat all members with courtesy and respect. Personal > > attacks, insults, or harassment of any kind are not tolerated. > > +Avoid Provocation: Refrain from posting inflammatory, controversial, or > > intentionally provocative messages. Focus on constructive discussions. > > +No Trolling: Messages intended to provoke an emotional response or > > disrupt the discussion are prohibited. > > +Professional Language: Use clear, professional, and inclusive language. > > Avoid offensive or derogatory remarks, even in jest. > > +Constructive Criticism Only: Offer feedback in a constructive and > > solution-oriented manner. Criticize ideas, not people. > > +Handle Disagreements Professionally: Disagreements are normal but should > > be handled respectfully. Assume good intentions and avoid escalating > > conflicts. > > > > Is there a source you used for these rules? Or did you write this yourself? I did not write these myself as i expected anything i would write would be claimed to be targeted against someone or be bad rules or otherwise. But i do think these rules would be a good addition. I did read through them before posting them and I belive these rules would improve the climate on the list. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Use AVBufferPool in MOV
There is no 32-stream limit. Each AVBufferPool needs to be initialized with a fixed allocation size. So, the 32 pools are for 1^1 bit allocations, 1^2 bit allocations, ...2^32 bit allocations. See mov_pool_get in the patch. This is why moving pools[32] to MOVContext could be ok: audio packets would statistically use pools[4...10], and video packets pools[12..20] or something like that. Personally I find it cleaner to separate the buffers per-stream, but maybe there are reasons to do it the other way. As for the perf regarding small packet sizes: is my answer to compn enough ? Would you like some more detailed analysis ? Arnaud On Sat, Nov 23, 2024 at 1:46 PM Ronald S. Bultje wrote: > > Hi Arnaud, > > On Fri, Nov 22, 2024 at 1:08 PM Arnaud Masserann > wrote: > > > - Should the pools be per-stream (in MOVStreamContext) or per file (in > > MOVContext) ? > > > > I'm assuming the per-stream is because their bitrates (and packet sizes) > will typically be substantially different. For example, video will have > much higher packet sizes than audio, especially in situations where the > video is only lightly compressed - like what we're talking about here. If > we mix video and audio pools, the audio will take half the video size, and > effective application size in a 1video+1audio stream will as much as double > in the worst case. So I think what you're doing here is better - per-stream > pools. > > I don't know if the 32-stream (*pool[32]) limit is because of practical > limits or to prevent double allocations, but if latter, it seems iffy and > should maybe be double-allocated so it works for any-streamcount media, > even if > 32. > > Question: does the pooling help with small packet sizes? If not, does it > make sense to only (by default) use pools for large-packet streams (if we > know this in advance)? Or for codecs known to generate large packets? > > Ronald > ___ > 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 v2] swscale/ppc: disable YUV2RGB AltiVec acceleration
The FATE test 'checkasm-sw_yuv2rgb' currently fails on this platform,
in both little- and big-endian configurations.
Disable it by default.
Add '-DSWS_USE_ALTIVEC_YUV2RGB' to CPPFLAGS to re-enable it.
---
v2: rebased over top of the recent swscale changes from Nik Haas
---
libswscale/ppc/yuv2rgb_altivec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libswscale/ppc/yuv2rgb_altivec.c b/libswscale/ppc/yuv2rgb_altivec.c
index 57574c4ab3..f44733a880 100644
--- a/libswscale/ppc/yuv2rgb_altivec.c
+++ b/libswscale/ppc/yuv2rgb_altivec.c
@@ -558,6 +558,7 @@ av_cold SwsFunc ff_yuv2rgb_init_ppc(SwsInternal *c)
if ((c->opts.src_h & 0x1) != 0)
return NULL;
+#ifdef SWS_USE_ALTIVEC_YUV2RGB
switch (c->opts.dst_format) {
case AV_PIX_FMT_RGB24:
av_log(c, AV_LOG_WARNING, "ALTIVEC: Color Space RGB24\n");
@@ -579,6 +580,7 @@ av_cold SwsFunc ff_yuv2rgb_init_ppc(SwsInternal *c)
return altivec_yuv2_bgra;
default: return NULL;
}
+#endif /* SWS_USE_ALTIVEC_YUV2RGB */
break;
case AV_PIX_FMT_UYVY422:
--
2.39.5
___
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] Use AVBufferPool in MOV
On 11/24/2024 8:52 PM, compn wrote: On Sun, 24 Nov 2024 18:14:03 +0100 Arnaud Masserann wrote: Good question. I just benchmarked all the .mov files in the samples repo. On average, there is a 1.3x speedup. A few files are slower, but 75% of the files have at least a 1.11x speedup, and 25% of the files have at least 1.49x. Outliers include openquicktime/aletrek-tga-8bit.mov (0.8x, so slower), and wmv3/Bluem.mov (10.4x). Full data: https://etconlyview-my.sharepoint.com/:x:/g/personal/a_masserann_etc-onlyview_com/EXomK72G3LdJgoBHCgnYcBUBnxd0FAe90nrIkL4EFZKEuw?e=vj3TRl And FATE passes with valgrind, btw. thanks for testing. if the change doesnt break any old files, i have no issue with it slowing the speeds of demuxing on old weird files. more ancient mov samples if you feel like doing more testing. https://samples.ffmpeg.org/A-codecs/MACE/MAC6-mov/ https://samples.ffmpeg.org/A-codecs/QDM2/ https://samples.ffmpeg.org/A-codecs/QDMC/ https://samples.ffmpeg.org/A-codecs/qclp/ https://samples.ffmpeg.org/A-codecs/qtNONE/ https://samples.ffmpeg.org/A-codecs/qtfl32/ https://samples.ffmpeg.org/A-codecs/qtraw/ https://samples.ffmpeg.org/A-codecs/suite/3G2/ https://samples.ffmpeg.org/A-codecs/suite/3GP/ https://samples.ffmpeg.org/A-codecs/uLaw/ https://samples.ffmpeg.org/mobileVideo_3gp/ https://samples.ffmpeg.org/archive/container/mov/ https://samples.ffmpeg.org/V-codecs/SVQ1/ https://samples.ffmpeg.org/V-codecs/SVQ3/ https://samples.ffmpeg.org/V-codecs/QT-qdrw/Airplane.mov https://samples.ffmpeg.org/V-codecs/QTRLE/ https://samples.ffmpeg.org/V-codecs/ZyGo/ https://samples.ffmpeg.org/V-codecs/icod/ https://samples.ffmpeg.org/V-codecs/pxlt-ApplePixlet/ https://samples.ffmpeg.org/MPEG-4/ https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4471/spot-day.mj2 probably a good idea to test the rest of the mov formats like psp,m4b,ism,ismv,isma,f4v,avif,heic,heif which i didnt link. especially popular camera photo format heic/heif could do with some tests. heif/heic/avif can (and most likely will) spawn several streams as a that's how tiled images are handled. So a 4k photo taken from a phone can have about 50 512x512 single frame hevc/av1 streams, which is another argument in favor of having the pools be container level and not stream. For single stream images, a pool will probably be slightly slower. full list of samples https://samples.ffmpeg.org/allsamples.txt note that mp4 files are the 2nd most popular format that i see on a daily basis , just behind mkv. with support by default in windows, mac/ios, android and web browsers, mov/mp4 is probably the #1 popular format in the world currently. testing and speeding up our mov/mp4 demuxer is a good idea. 392092 mov.c ugh. thanks, -compn ___ 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". OpenPGP_signature.asc Description: OpenPGP digital 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] Use AVBufferPool in MOV
On Sun, 24 Nov 2024 18:14:03 +0100 Arnaud Masserann wrote: > Good question. I just benchmarked all the .mov files in the samples repo. > On average, there is a 1.3x speedup. A few files are slower, but 75% > of the files have at least a 1.11x speedup, and 25% of the files have > at least 1.49x. > > Outliers include openquicktime/aletrek-tga-8bit.mov (0.8x, so slower), > and wmv3/Bluem.mov (10.4x). > Full data: > https://etconlyview-my.sharepoint.com/:x:/g/personal/a_masserann_etc-onlyview_com/EXomK72G3LdJgoBHCgnYcBUBnxd0FAe90nrIkL4EFZKEuw?e=vj3TRl > > And FATE passes with valgrind, btw. thanks for testing. if the change doesnt break any old files, i have no issue with it slowing the speeds of demuxing on old weird files. more ancient mov samples if you feel like doing more testing. https://samples.ffmpeg.org/A-codecs/MACE/MAC6-mov/ https://samples.ffmpeg.org/A-codecs/QDM2/ https://samples.ffmpeg.org/A-codecs/QDMC/ https://samples.ffmpeg.org/A-codecs/qclp/ https://samples.ffmpeg.org/A-codecs/qtNONE/ https://samples.ffmpeg.org/A-codecs/qtfl32/ https://samples.ffmpeg.org/A-codecs/qtraw/ https://samples.ffmpeg.org/A-codecs/suite/3G2/ https://samples.ffmpeg.org/A-codecs/suite/3GP/ https://samples.ffmpeg.org/A-codecs/uLaw/ https://samples.ffmpeg.org/mobileVideo_3gp/ https://samples.ffmpeg.org/archive/container/mov/ https://samples.ffmpeg.org/V-codecs/SVQ1/ https://samples.ffmpeg.org/V-codecs/SVQ3/ https://samples.ffmpeg.org/V-codecs/QT-qdrw/Airplane.mov https://samples.ffmpeg.org/V-codecs/QTRLE/ https://samples.ffmpeg.org/V-codecs/ZyGo/ https://samples.ffmpeg.org/V-codecs/icod/ https://samples.ffmpeg.org/V-codecs/pxlt-ApplePixlet/ https://samples.ffmpeg.org/MPEG-4/ https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4471/spot-day.mj2 probably a good idea to test the rest of the mov formats like psp,m4b,ism,ismv,isma,f4v,avif,heic,heif which i didnt link. especially popular camera photo format heic/heif could do with some tests. full list of samples https://samples.ffmpeg.org/allsamples.txt note that mp4 files are the 2nd most popular format that i see on a daily basis , just behind mkv. with support by default in windows, mac/ios, android and web browsers, mov/mp4 is probably the #1 popular format in the world currently. testing and speeding up our mov/mp4 demuxer is a good idea. 392092 mov.c ugh. thanks, -compn ___ 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] [RFC] libpostproc splitout
Quoting Tomas Härdin (2024-11-08 11:44:03) > 15k sounds like money better spent on something else, for example > improving the build system. What actual problems are there with our build systems. It works better than most and is quite easily hackable. > good build systems What is this mythical beast? -- 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] avfilter/scale_vt: implement frame crop
Thanks! I believe I have made the necessary fixes and resubmitted the
patch. I also resubmitted another related patch that adds support for
negative scale values that preserve aspect ratio, similar to what the
scale, scale_cuda, and scale_vaapi filters support.
Koush
On Sun, Nov 24, 2024 at 8:58 AM Zhao Zhili wrote:
>
>
>
> > On Nov 21, 2024, at 00:40, Koushik Dutta wrote:
> >
> > Is anyone reviewing videotoolbox or qsv filters? The scale_cuda
> > version of this patch was merged.
> >
> > On Sat, Oct 19, 2024 at 10:58 PM Koushik Dutta wrote:
> >>
> >> The crop filter has no effect on scale_vt:
> >>
> >> -vf crop=100:100,scale_vt=300x300
> >>
> >> Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_*
> >> properties,
> >> as seen in the implementation vf_crop.c.
> >>
> >> The current workaround is to hwdownload the full frame
> >> and perform the crop on CPU.
> >>
> >> Signed-off-by: Koushik Dutta
> >> ---
> >> libavfilter/vf_scale_vt.c | 50 +++
> >> 1 file changed, 50 insertions(+)
> >>
> >> diff --git a/libavfilter/vf_scale_vt.c b/libavfilter/vf_scale_vt.c
> >> index 05f4e7b797..3da46a6cd5 100644
> >> --- a/libavfilter/vf_scale_vt.c
> >> +++ b/libavfilter/vf_scale_vt.c
> >> @@ -109,6 +109,8 @@ static av_cold int scale_vt_init(AVFilterContext
> >> *avctx)
> >> VTSessionSetProperty(s->transfer,
> >> kVTPixelTransferPropertyKey_DestinationYCbCrMatrix, value);
> >> }
> >>
> >> +VTSessionSetProperty(s->transfer,
> >> kVTPixelTransferPropertyKey_ScalingMode,
> >> kVTScalingMode_CropSourceToCleanAperture);
> >> +
> >> return 0;
> >> }
> >>
> >> @@ -132,6 +134,18 @@ static int scale_vt_filter_frame(AVFilterLink *link,
> >> AVFrame *in)
> >> CVPixelBufferRef src;
> >> CVPixelBufferRef dst;
> >>
> >> +int left;
> >> +int top;
> >> +int width;
> >> +int height;
> >> +CFNumberRef crop_width_num;
> >> +CFNumberRef crop_height_num;
> >> +CFNumberRef crop_offset_left_num;
> >> +CFNumberRef crop_offset_top_num;
> >> +const void *clean_aperture_keys[4];
> >> +const void *source_clean_aperture_values[4];
> >> +CFDictionaryRef source_clean_aperture;
> >> +
> >> AVFrame *out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
> >> if (!out) {
> >> ret = AVERROR(ENOMEM);
> >> @@ -153,8 +167,43 @@ static int scale_vt_filter_frame(AVFilterLink *link,
> >> AVFrame *in)
> >> if (s->colour_matrix != AVCOL_SPC_UNSPECIFIED)
> >> out->colorspace = s->colour_matrix;
> >>
> >> +width = (in->width - in->crop_right) - in->crop_left;
> >> +height = (in->height - in->crop_bottom) - in->crop_top;
> >> +// The crop offsets are relative to the center of the frame.
> >> +// the crop width and crop height are relative to the center of the
> >> crop rect, not top left as normal.
> >> +left = in->crop_left - in->width / 2 + width / 2;
> >> +top = in->crop_top - in->height / 2 + height / 2;
> >> +crop_width_num = CFNumberCreate(kCFAllocatorDefault,
> >> kCFNumberIntType, &width);
> >> +crop_height_num = CFNumberCreate(kCFAllocatorDefault,
> >> kCFNumberIntType, &height);
> >> +crop_offset_left_num = CFNumberCreate(kCFAllocatorDefault,
> >> kCFNumberIntType, &left);
> >> +crop_offset_top_num = CFNumberCreate(kCFAllocatorDefault,
> >> kCFNumberIntType, &top);
> >> +
> >> +clean_aperture_keys[0] = kCVImageBufferCleanApertureWidthKey;
> >> +clean_aperture_keys[1] = kCVImageBufferCleanApertureHeightKey;
> >> +clean_aperture_keys[2] =
> >> kCVImageBufferCleanApertureHorizontalOffsetKey;
> >> +clean_aperture_keys[3] = kCVImageBufferCleanApertureVerticalOffsetKey;
> >> +
> >> +source_clean_aperture_values[0] = crop_width_num;
> >> +source_clean_aperture_values[1] = crop_height_num;
> >> +source_clean_aperture_values[2] = crop_offset_left_num;
> >> +source_clean_aperture_values[3] = crop_offset_top_num;
> >> +
> >> +source_clean_aperture = CFDictionaryCreate(kCFAllocatorDefault,
> >> +clean_aperture_keys,
> >> +
> >> source_clean_aperture_values,
> >> +4,
> >> +
> >> &kCFTypeDictionaryKeyCallBacks,
> >> +
> >> &kCFTypeDictionaryValueCallBacks);
> >> +
> >> +CFRelease(crop_width_num);
> >> +CFRelease(crop_height_num);
> >> +CFRelease(crop_offset_left_num);
> >> +CFRelease(crop_offset_top_num);
> >> +
> >> src = (CVPixelBufferRef)in->data[3];
> >> dst = (CVPixelBufferRef)out->data[3];
> >> +CVBufferSetAttachment(src, kCVImageBufferCleanApertureKey,
> >> + source_clean_aperture,
> >> kCVAttachmentMode_ShouldPropagate);
>
> After applied crop, the output frame still holding crop info which are copied
Re: [FFmpeg-devel] [RFC] libpostproc splitout
Quoting Michael Niedermayer (2024-11-08 17:17:42) > On Fri, Nov 08, 2024 at 11:44:03AM +0100, Tomas Härdin wrote: > > tor 2024-11-07 klockan 00:11 +0100 skrev Michael Niedermayer: > > > Hi all > > > > > > Should libpostproc be split out into a seperate source repository ? > > > > > > Several people did over the years want libpostproc removed, and such > > > a task was part of the submitted and approved STF 2024 projects. > > > But when i recently started posting related work, tomas questioned > > > if spliting libpostproc into a seperate source repository actually is a > > > good idea. > > > > > > No invoice was submitted yet, so we could likely still change > > > this to something else, if thats what people prefer. > > > > > > To clarify this a bit (as its a bit convoluted) > > > Option A. > > > 1. split libpostproc out so it builds and links fine (already done) > > > (send to SPI/STF/Invoice in future) > > > 2. develop test system for libpostproc (2024 future) (send to > > > SPI/STF/Invoice in future) > > > 3. actually remove libpostproc from master repository (2025 future) > > > (send to SPI/STF/Invoice in future) > > > Option B. > > > 0. double check with STF/SPI that such change is ok > > > 1. split libpostproc out so it builds and links fine (already done) > > > (send to SPI/STF/ never send invoice) > > > 2. develop test system for libpostproc (2024 future) (send to > > > SPI/STF, never send invoice) (this will get used with the libpostproc > > > inside FFmpeg) > > > 3. renegotiate actual libpostproc task to something else the > > > community wants > > > 4. whoever does the new task sends invoices and gets the whole money > > > for all 3 parts > > > > > > This looks a bit convoluted as iam trying to minimize the annoyance for > > > STF so > > > we dont have issues in the future. (Iam especially avoiding moving any > > > STF payments > > > accross teh year end which is a issue IIUC for STF) > > > > > > each of the 3 milestones is 5040 Euro > > > > > > Please comment what you prefer, the > > > A. split libpostproc out or > > > B. leave libpostproc in ffmpeg and fund some other maintaince work with > > > the 15k Euro > > > > 15k sounds like money better spent on something else, for example > > improving the build system. Circular dependencies are kind of ugly, but > > they're not showstoppers given good build systems > > my wish would be that the 15k could be spend on a plugin interface > for libavfilter. > > Something that on startup would scan ~/.ffmpeg/plugins/ or something like that > and load all compatible ones. > A restriction to a simple 1 input link, 1 output link with possibility of > future extension would already cover likely 90% of use cases. > > anton, would you be interrested to implement something like that for 15k ? I am working in that direction anyway as a part of my other work, but * doing it properly requires a ton of preparatory work (for which 15k is way too little) * I am not a fan of doing things improperly -- 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] avfilter/scale_vt: implement frame crop
The crop filter has no effect on scale_vt:
-vf crop=100:100,scale_vt=300x300
Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_*
properties,
as seen in the implementation vf_crop.c.
The current workaround is to hwdownload the full frame
and perform the crop on CPU.
Signed-off-by: Koushik Dutta
---
libavfilter/vf_scale_vt.c | 55 +++
1 file changed, 55 insertions(+)
diff --git a/libavfilter/vf_scale_vt.c b/libavfilter/vf_scale_vt.c
index 07d825b1ba..eff23a6f39 100644
--- a/libavfilter/vf_scale_vt.c
+++ b/libavfilter/vf_scale_vt.c
@@ -109,6 +109,8 @@ static av_cold int scale_vt_init(AVFilterContext *avctx)
VTSessionSetProperty(s->transfer,
kVTPixelTransferPropertyKey_DestinationYCbCrMatrix, value);
}
+VTSessionSetProperty(s->transfer, kVTPixelTransferPropertyKey_ScalingMode,
kVTScalingMode_CropSourceToCleanAperture);
+
return 0;
}
@@ -132,6 +134,18 @@ static int scale_vt_filter_frame(AVFilterLink *link,
AVFrame *in)
CVPixelBufferRef src;
CVPixelBufferRef dst;
+int left;
+int top;
+int width;
+int height;
+CFNumberRef crop_width_num;
+CFNumberRef crop_height_num;
+CFNumberRef crop_offset_left_num;
+CFNumberRef crop_offset_top_num;
+const void *clean_aperture_keys[4];
+const void *source_clean_aperture_values[4];
+CFDictionaryRef source_clean_aperture;
+
AVFrame *out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
if (!out) {
ret = AVERROR(ENOMEM);
@@ -142,6 +156,11 @@ static int scale_vt_filter_frame(AVFilterLink *link,
AVFrame *in)
if (ret < 0)
goto fail;
+out->crop_left = 0;
+out->crop_top = 0;
+out->crop_right = 0;
+out->crop_bottom = 0;
+
av_reduce(&out->sample_aspect_ratio.num, &out->sample_aspect_ratio.den,
(int64_t)in->sample_aspect_ratio.num * outlink->h * link->w,
(int64_t)in->sample_aspect_ratio.den * outlink->w * link->h,
@@ -153,9 +172,45 @@ static int scale_vt_filter_frame(AVFilterLink *link,
AVFrame *in)
if (s->colour_matrix != AVCOL_SPC_UNSPECIFIED)
out->colorspace = s->colour_matrix;
+width = (in->width - in->crop_right) - in->crop_left;
+height = (in->height - in->crop_bottom) - in->crop_top;
+// The crop offsets are relative to the center of the frame.
+// the crop width and crop height are relative to the center of the crop
rect, not top left as normal.
+left = in->crop_left - in->width / 2 + width / 2;
+top = in->crop_top - in->height / 2 + height / 2;
+crop_width_num = CFNumberCreate(kCFAllocatorDefault, kCFNumberIntType,
&width);
+crop_height_num = CFNumberCreate(kCFAllocatorDefault, kCFNumberIntType,
&height);
+crop_offset_left_num = CFNumberCreate(kCFAllocatorDefault,
kCFNumberIntType, &left);
+crop_offset_top_num = CFNumberCreate(kCFAllocatorDefault,
kCFNumberIntType, &top);
+
+clean_aperture_keys[0] = kCVImageBufferCleanApertureWidthKey;
+clean_aperture_keys[1] = kCVImageBufferCleanApertureHeightKey;
+clean_aperture_keys[2] = kCVImageBufferCleanApertureHorizontalOffsetKey;
+clean_aperture_keys[3] = kCVImageBufferCleanApertureVerticalOffsetKey;
+
+source_clean_aperture_values[0] = crop_width_num;
+source_clean_aperture_values[1] = crop_height_num;
+source_clean_aperture_values[2] = crop_offset_left_num;
+source_clean_aperture_values[3] = crop_offset_top_num;
+
+source_clean_aperture = CFDictionaryCreate(kCFAllocatorDefault,
+clean_aperture_keys,
+
source_clean_aperture_values,
+4,
+
&kCFTypeDictionaryKeyCallBacks,
+
&kCFTypeDictionaryValueCallBacks);
+
+CFRelease(crop_width_num);
+CFRelease(crop_height_num);
+CFRelease(crop_offset_left_num);
+CFRelease(crop_offset_top_num);
+
src = (CVPixelBufferRef)in->data[3];
dst = (CVPixelBufferRef)out->data[3];
+CVBufferSetAttachment(src, kCVImageBufferCleanApertureKey,
+ source_clean_aperture,
kCVAttachmentMode_ShouldPropagate);
ret = VTPixelTransferSessionTransferImage(s->transfer, src, dst);
+CFRelease(source_clean_aperture);
if (ret != noErr) {
av_log(ctx, AV_LOG_ERROR, "transfer image failed, %d\n", ret);
ret = AVERROR_EXTERNAL;
--
2.39.5 (Apple Git-154)
___
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] avfilter/scale_vt: implement negative width/height aspect ratio sizing
Signed-off-by: Koushik Dutta --- libavfilter/vf_scale_vt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavfilter/vf_scale_vt.c b/libavfilter/vf_scale_vt.c index 05f4e7b797..07d825b1ba 100644 --- a/libavfilter/vf_scale_vt.c +++ b/libavfilter/vf_scale_vt.c @@ -189,6 +189,8 @@ static int scale_vt_config_output(AVFilterLink *outlink) if (err < 0) return err; +ff_scale_adjust_dimensions(inlink, &s->output_width, &s->output_height, 0, 1); + outlink->w = s->output_width; outlink->h = s->output_height; -- 2.39.5 (Apple Git-154) ___ 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] [RFC] libpostproc splitout
Quoting Michael Niedermayer (2024-11-11 00:06:12) > The reason for me to consider to split libpostproc out is to be able to > work on the code without the eternal debates here. So i need it to be > maintainable and i need it to support a wider range of filters. In other words you would like to use the project's resources while avoiding scrutiny and oversight. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/sanm: clear codec47 diff buffers with specific color
Your patch seems to be against something other than git master, and fails to apply. -- 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] avformat: add AV1 RTP depacketizer and packetizer
Your mailer mangled the newlines in the patch. Consider a different mailer or sending it as an attachment. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: deprecate sonic
Quoting Vittorio Giovara (2024-11-20 23:14:03)
> On Thu, Feb 29, 2024 at 7:47 AM J. Dekker wrote:
>
> > This is an experimental and research codec of which ffmpeg is the only
> > encoder and decoder, development has stalled since 2013 and these files
> > don't exist in the wild.
> >
> > Deprecate the encoders to be removed next major bump, decoders to be
> > removed one bump afterwards. We also disable the the encoders by default
> > in configure, the decoders should be disabled by default next bump.
> >
> > Signed-off-by: J. Dekker
> > ---
> >
> > Since this codec was added in 2004, there has only been one major
> > non-maintenance, non-bugfix commit in 2013 (6026a5ad4f). That's 1 out of
> > 107
> > total commits touching this file.
> >
> > This isn't a matter of the codec being unpopular like a niche game codec
> > or
> > some other codec with media found in the wild, it's an experiment which
> > didn't
> > continue and we continue to pay the maintenance cost.
> >
> > Deprecating the codec instead of immediate removal gives a grace period
> > for
> > anyone interested to pick up the format and make it the most advanced
> > audio
> > codec in FFmpeg if they so wish. It encourages an action to be taken
> > whether
> > that be improving the codec, or leaving it to be removed later.
> >
> > configure | 3 +++
> > libavcodec/version_major.h | 4
> > 2 files changed, 7 insertions(+)
> >
> > diff --git a/configure b/configure
> > index bb5e630bad..f11c035796 100755
> > --- a/configure
> > +++ b/configure
> > @@ -4234,6 +4234,9 @@ do_random(){
> > $action $(rand_list "$@" | awk "BEGIN { srand($random_seed) } \$1 ==
> > \"prob\" { prob = \$2; next } rand() < prob { print }")
> > }
> >
> > +# deprecated components (disabled by default)
> > +disable sonic_encoder sonic_ls_encoder
> > +
> > for opt do
> > optval="${opt#*=}"
> > case "$opt" in
> > diff --git a/libavcodec/version_major.h b/libavcodec/version_major.h
> > index 161442df95..97e4c47d45 100644
> > --- a/libavcodec/version_major.h
> > +++ b/libavcodec/version_major.h
> > @@ -57,5 +57,9 @@
> >
> > // reminder to remove CrystalHD decoders on next major bump
> > #define FF_CODEC_CRYSTAL_HD(LIBAVCODEC_VERSION_MAJOR < 61)
> > +// reminder to remove Sonic Lossy/Lossless encoders on next major bump
> > +#define FF_CODEC_SONIC_ENC (LIBAVCODEC_VERSION_MAJOR < 62)
> > +// reminder to remove Sonic decoder on next-next major bump
> > +#define FF_CODEC_SONIC_DEC (LIBAVCODEC_VERSION_MAJOR < 63)
> >
> > #endif /* AVCODEC_VERSION_MAJOR_H */
> > --
> >
>
> unless objections I'd like to push this patch
SGTM
--
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] lavfi/qsvvpp: Copy frame props before modify it
On Mon, 2024-11-25 at 02:31 +, Xiang, Haihao wrote:
> On Vr, 2024-11-22 at 13:18 +0800,
> fei.w.wang-at-intel@ffmpeg.org wrote:
> > From: Fei Wang
> >
> > The changes to output frame props in query_frame overlapped since
> > b14ed6ea58. Move the copy frame props before the changes.
>
> I can't find commit b14ed6ea58, could you double check the bad commit
> ?
Fixed in V2. Thanks.
>
> Thanks
> Haihao
>
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavfilter/qsvvpp.c | 23 ---
> > 1 file changed, 12 insertions(+), 11 deletions(-)
> >
> > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> > index 0818ada117..67ae23b165 100644
> > --- a/libavfilter/qsvvpp.c
> > +++ b/libavfilter/qsvvpp.c
> > @@ -471,7 +471,8 @@ static QSVFrame *submit_frame(QSVVPPContext *s,
> > AVFilterLink *inlink, AVFrame *p
> > }
> >
> > /* get the output surface */
> > -static QSVFrame *query_frame(QSVVPPContext *s, AVFilterLink
> > *outlink, const
> > AVFrame *in)
> > +static QSVFrame *query_frame(QSVVPPContext *s, AVFilterLink
> > *outlink, const
> > AVFrame *in,
> > + const AVFrame *propref)
> > {
> > FilterLink *l = ff_filter_link(outlink);
> > AVFilterContext *ctx = outlink->src;
> > @@ -513,6 +514,15 @@ static QSVFrame *query_frame(QSVVPPContext *s,
> > AVFilterLink *outlink, const AVFr
> > return NULL;
> > }
> >
> > + if (propref) {
> > + ret = av_frame_copy_props(out_frame->frame, propref);
> > + if (ret < 0) {
> > + av_frame_free(&out_frame->frame);
> > + av_log(ctx, AV_LOG_ERROR, "Failed to copy metadata
> > fields from
> > src to dst.\n");
> > + return NULL;
> > + }
> > + }
> > +
> > if (l->frame_rate.num && l->frame_rate.den)
> > out_frame->frame->duration = av_rescale_q(1, av_inv_q(l-
> > >frame_rate),
> > outlink->time_base);
> > else
> > @@ -985,7 +995,7 @@ int ff_qsvvpp_filter_frame(QSVVPPContext *s,
> > AVFilterLink
> > *inlink, AVFrame *picr
> > }
> >
> > do {
> > - out_frame = query_frame(s, outlink, in_frame->frame);
> > + out_frame = query_frame(s, outlink, in_frame->frame,
> > propref);
> > if (!out_frame) {
> > av_log(ctx, AV_LOG_ERROR, "Failed to query an output
> > frame.\n");
> > return AVERROR(ENOMEM);
> > @@ -1009,15 +1019,6 @@ int ff_qsvvpp_filter_frame(QSVVPPContext *s,
> > AVFilterLink *inlink, AVFrame *picr
> > break;
> > }
> >
> > - if (propref) {
> > - ret1 = av_frame_copy_props(out_frame->frame, propref);
> > - if (ret1 < 0) {
> > - av_frame_free(&out_frame->frame);
> > - av_log(ctx, AV_LOG_ERROR, "Failed to copy metadata
> > fields
> > from src to dst.\n");
> > - return ret1;
> > - }
> > - }
> > -
> > out_frame->frame->pts = av_rescale_q(out_frame-
> > > surface.Data.TimeStamp,
> > default_tb, outlink-
> > >time_base);
> >
>
___
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] libavutil/riscv: Make use of elf_aux_info() on FreeBSD / OpenBSD riscv
On 2024-11-18 1:28 p.m., Rémi Denis-Courmont wrote: Le maanantaina 18. marraskuuta 2024, 4.02.39 EET Brad Smith a écrit : libavutil/riscv: Make use of elf_aux_info() on FreeBSD / OpenBSD riscv FreeBSD/OpenBSD riscv have elf_aux_info(). Does OpenBSD use the same HWCAP encoding as Linux and FreeBSD? Yes. All of the relevant bits were copied as is from FreeBSD and the feature flags are the same between all of them. On real contemporary commercial hardware, there are two CPU configurations that affect FFmpeg, on top of the baseline RV64GC/RVA20: - StarFive JH7110: Zba and Zbb, - Canaan K230 and SpacemiT K1: Zba, Zbb, Zbs and V (or RVA22 + V). The first one simply can't be handled with this encoding scheme which leaves no room for extension without single letter designation. The second one won't be detected properly unless the kernel understands that B is equivalent to Zba, Zbb and Zbs (or the device tree is manually patched). It seems that at least FreeBSD fails there:https://reviews.freebsd.org/D46277 I wasn't aware of that. My consideration for this was for the eventual Vector support. Thanks for pointing out the diff. I'll see about bringing that in as a start. ___ 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] ANN: FATE RISC-V Vector enabled
Quoting Rémi Denis-Courmont (2024-11-19 13:35:19) > Hello all, > > This is just a short notice that we finally have a nightly FATE run on real > hardware with RISC-V Vector support and working CPU feature run-time > detection. .''. .''. *''*:_\/_: . :_\/_: ..:.*_\/_* : /\ : .'.:.'. .''.: /\ : _\(/_ ':'* /\ * : '..'. -=:o:=- :_\/_:'.:::. /)\*''* .|.* '.\'/.'_\(/_'.':'.' : /\ : : '*_\/_* | | -= o =- /)\' * '..' ':::' * /\ * |'| .'/.\'. '._ *__*..* | | : |. |' .---"| _* .-' '-. | | .--'| || | _|| .-'| _.| ||| '-__ | | ||| | |' | |.||| | | | ||| | ___| '-' '"" '-' '-.''` | jgs~ -- 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] fate/jpeg2000dec: add missing ISO/IEC 15444-4 conformance tests
Quoting Pierre-Anthony Lemieux (2024-11-18 06:57:52) > On Mon, Nov 11, 2024 at 12:19 AM WATANABE Osamu > wrote: > > > > I have confirmed that these failures in FATE were due to the insufficient > > floating point precision of a 32-bit environment. > > > > The commit 82467b635efced67c1767cb810af1f3c31a2e493 introduces the improved > > dequantization in FF_DWT97_INT path and makes FFmpeg compliant for ISO/IEC > > 15444-4 (Conformance testing.) > > > > Actually, both 64 and 32-bit FFmpeg with the commit pass the conformance > > testing. > > > > Current FATE tests for JPEG 2000 are to check the CRC of reconstructed > > images. > > Checking CRC is unsuitable for lossy codestream because even a patch that > > can improve the quality of a reconstructed image cannot pass the FATE. > > Passing FATE is, of course, important, but passing the official (ISO's) > > conformance tests is essential, too. > > > > I recommend introducing a way to allow some tolerance in FATE tests for > > JPEG 2000 lossy codestreams. > > For example, including the original files and using the PSNR value in FATE > > will be an option. > > The original files are approximately 10 MB. Any objection/concerns to > adding them to FATE, which can then apply the conformance requirements > specified in the standard? IMO it should not be a problem, other codecs have far larger conformance samples. -- 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] libavcodec/mpegaudio_parser.c: differentiate MPEG audio dual mono
Quoting Scott Theisen (2024-11-14 05:37:49)
> @@ -85,7 +85,13 @@ static int mpegaudio_parse(AVCodecParserContext *s1,
> if (s->header_count > header_threshold) {
> avctx->sample_rate= sr;
> av_channel_layout_uninit(&avctx->ch_layout);
> -av_channel_layout_default(&avctx->ch_layout,
> channels);
> +if (dual_mono) {
> +av_channel_layout_custom_init(&avctx->ch_layout,
> 2);
This can fail - the return code should be checked.
--
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] MAINTAINERS: Add myself as Darwin maintainer
Hi On Sun, Nov 24, 2024 at 09:49:00PM +0100, Marvin Scholz wrote: > I do some development and usage of FFmpeg regularly on macOS and sent > some patches to fix issues specific to Darwin in the past so I think it > makes sense to add myself as maintainer so people know they can ping me > if required, for Darwin specific issues/testing. > > I have both Intel and Apple Silicon (aarch64) machines as well as older > Macs for testing on older macOS versions if necessary. > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8a1883c48c..ba92d73c1f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -511,6 +511,7 @@ Operating systems / CPU architectures > Alpha [0] > MIPSManojkumar Bhosale, Shiyou Yin > LoongArch [2] Shiyou Yin > +Darwin (macOS, iOS) [2] Marvin Scholz > Mac OS X / PowerPC Romain Dolbeau, Guillaume Poirier > Amiga / PowerPC Colin Ward > Linux / PowerPC Lauri Kasanen LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes 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 2/2] tools/general_assembly: exclude Derek from GA emails
On Sat, 23 Nov 2024 06:35:57 +0100 Anton Khirnov wrote: > At his own request, he can remove the entry whenever he likes. if its his wish. -compn ___ 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] Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
On 11/24/2024 6:24 PM, Michael Niedermayer wrote: Hi On Sun, Nov 24, 2024 at 06:02:55PM -0300, James Almer wrote: On 11/24/2024 5:43 PM, Michael Niedermayer wrote: Hi On Sun, Nov 24, 2024 at 04:11:42PM -0300, James Almer wrote: On 11/24/2024 4:09 PM, Michael Niedermayer wrote: Now reality is, Paul (the 2nd most active developer of all time) was bullied out of FFmpeg. In private mail he spoke about being treated like a slave. Huh?? By whom? by the community, by us all maybe "bullied" is a badly choosen word here, but the way i understand it, is paul dislike having to deal with "disturbing" reviews I think only Nicolas was against his patches in general, sometimes for a fair reason, others probably not so much. I at least helped him every time i could. There has to be another reason for him to leave like he did. Iam fairly sure, if we would have left him change whatever he wants in his code and gave him final authority there that he would not have left. But he could do that. He did it all the time, and rarely got opposition since it was almost always for filters he wrote and maintained. BUT i do not know that He also pushed patches to his stuff bypassing the mailing list and review process. It introduced a bug or 2 and I think i pointed that out. I dont remember at all how i worded that. And there was teh conflicts where he pointed to bugs but refused to provide samples or details, making fixing them often impossible. While he caused this it lead to further friction. This really feels like a failure of mutual understanding, noone benefitted from this Not adding test was a problem, yes. Such a trivial thing to do for most filters and he'd still refuse. Also teh CC was re-elected at the time of him leaving IIRC. He may have preceived that a ban or harsh actions against him where imminent from the new CC. Thing is that nothing like that was imminent. He got a temp ban (like a week?) after several warnings for being too aggressive in his replies. I don't know why he was aggressive to begin with, and i even asked him to stop before anything was done. I dont know how to undo the decissions from the past. But i want to undo what led to paul leaving OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] tools/general_assembly: add a mechanism for excluding people from GA list
On Sat, 23 Nov 2024 06:35:56 +0100 Anton Khirnov wrote: > To be used at their own request, when they do not wish to receive vote > emails. good idea, i have not tested patch. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/ac3dec: fix downmix logic for eac3
On 11/24/2024 2:07 PM, James Almer wrote:
Ensure downmixed is only set once during init, as it used to be.
Fixes a regression since acbb2777e28c.
Fixes ticket #11321.
Signed-off-by: James Almer
---
libavcodec/ac3dec.c | 121 ++--
1 file changed, 61 insertions(+), 60 deletions(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 0a4d3375ee..11374bcb7d 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -199,7 +199,6 @@ static void ac3_downmix(AVCodecContext *avctx)
av_channel_layout_uninit(&avctx->ch_layout);
avctx->ch_layout = (AVChannelLayout)AV_CHANNEL_LAYOUT_STEREO;
}
-s->downmixed = 1;
}
/**
@@ -241,6 +240,7 @@ static av_cold int ac3_decode_init(AVCodecContext *avctx)
avctx->sample_fmt = AV_SAMPLE_FMT_FLTP;
ac3_downmix(avctx);
+s->downmixed = 1;
for (i = 0; i < AC3_MAX_CHANNELS; i++) {
s->xcfptr[i] = s->transform_coeffs[i];
@@ -1647,6 +1647,66 @@ dependent_frame:
if (ch < s->out_channels)
s->outptr[channel_map[ch]] = s->output_buffer[ch + offset];
}
+
+for (ch = 0; ch < EAC3_MAX_CHANNELS; ch++)
+extended_channel_map[ch] = ch;
+
+if (s->frame_type == EAC3_FRAME_TYPE_DEPENDENT) {
+uint64_t ich_layout = ff_ac3_channel_layout_tab[s->prev_output_mode &
~AC3_OUTPUT_LFEON];
+int channel_map_size = ff_ac3_channels_tab[s->output_mode &
~AC3_OUTPUT_LFEON] + s->lfe_on;
+uint64_t channel_layout;
+int extend = 0;
+
+if (s->prev_output_mode & AC3_OUTPUT_LFEON)
+ich_layout |= AV_CH_LOW_FREQUENCY;
+
+channel_layout = ich_layout;
+for (ch = 0; ch < 16; ch++) {
+if (s->channel_map & (1 << (EAC3_MAX_CHANNELS - ch - 1))) {
+channel_layout |= ff_eac3_custom_channel_map_locations[ch][1];
+}
+}
+if (av_popcount64(channel_layout) > EAC3_MAX_CHANNELS) {
+av_log(avctx, AV_LOG_ERROR, "Too many channels (%d) coded\n",
+ av_popcount64(channel_layout));
+return AVERROR_INVALIDDATA;
+}
+
+av_channel_layout_uninit(&avctx->ch_layout);
+av_channel_layout_from_mask(&avctx->ch_layout, channel_layout);
+
+for (ch = 0; ch < EAC3_MAX_CHANNELS; ch++) {
+if (s->channel_map & (1 << (EAC3_MAX_CHANNELS - ch - 1))) {
+if (ff_eac3_custom_channel_map_locations[ch][0]) {
+int index =
av_channel_layout_index_from_channel(&avctx->ch_layout,
+
ff_ctzll(ff_eac3_custom_channel_map_locations[ch][1]));
+if (index < 0)
+return AVERROR_INVALIDDATA;
+if (extend >= channel_map_size)
+break;
+
+extended_channel_map[index] = offset +
channel_map[extend++];
+} else {
+int i;
+
+for (i = 0; i < 64; i++) {
+if ((1ULL << i) &
ff_eac3_custom_channel_map_locations[ch][1]) {
+int index =
av_channel_layout_index_from_channel(&avctx->ch_layout, i);
+if (index < 0)
+return AVERROR_INVALIDDATA;
+if (extend >= channel_map_size)
+break;
+
+extended_channel_map[index] = offset +
channel_map[extend++];
+}
+}
+}
+}
+}
+
+ac3_downmix(avctx);
+}
+
Actually, i don't even need to move this chunk. Just moving s->downmixed
is enough, so amended locally.
for (blk = 0; blk < s->num_blocks; blk++) {
if (!err && decode_audio_block(s, blk, offset)) {
av_log(avctx, AV_LOG_ERROR, "error decoding the audio block\n");
@@ -1713,65 +1773,6 @@ skip:
return AVERROR_INVALIDDATA;
}
-for (ch = 0; ch < EAC3_MAX_CHANNELS; ch++)
-extended_channel_map[ch] = ch;
-
-if (s->frame_type == EAC3_FRAME_TYPE_DEPENDENT) {
-uint64_t ich_layout = ff_ac3_channel_layout_tab[s->prev_output_mode &
~AC3_OUTPUT_LFEON];
-int channel_map_size = ff_ac3_channels_tab[s->output_mode &
~AC3_OUTPUT_LFEON] + s->lfe_on;
-uint64_t channel_layout;
-int extend = 0;
-
-if (s->prev_output_mode & AC3_OUTPUT_LFEON)
-ich_layout |= AV_CH_LOW_FREQUENCY;
-
-channel_layout = ich_layout;
-for (ch = 0; ch < 16; ch++) {
-if (s->channel_map & (1 << (EAC3_MAX_CHANNELS - ch - 1))) {
-channel_layout |= ff_eac3_custom_channel_map_locations[ch][1];
-}
-}
-if (av_popcount64(channel_layout) > EAC3_MAX_CHANNELS) {
-av_log(avctx, AV_LOG_ERROR, "Too many channels (%d) coded\n",
-
Re: [FFmpeg-devel] [PATCH] Use AVBufferPool in MOV
Good question. I just benchmarked all the .mov files in the samples repo. On average, there is a 1.3x speedup. A few files are slower, but 75% of the files have at least a 1.11x speedup, and 25% of the files have at least 1.49x. Outliers include openquicktime/aletrek-tga-8bit.mov (0.8x, so slower), and wmv3/Bluem.mov (10.4x). Full data: https://etconlyview-my.sharepoint.com/:x:/g/personal/a_masserann_etc-onlyview_com/EXomK72G3LdJgoBHCgnYcBUBnxd0FAe90nrIkL4EFZKEuw?e=vj3TRl And FATE passes with valgrind, btw. On Fri, Nov 22, 2024 at 8:56 PM compn wrote: > > On Fri, 22 Nov 2024 18:46:19 +0100 > Arnaud Masserann wrote: > > > Most demuxers allocate a new buffer for each packet. > > For MOV, this can be problematic, because of some high-bitrate > > codecs like ProRes/HAPQ/NotchLC. > > > > Use pools of buffer instead. > > > > For some test media, demuxing goes from 20ms/frame to 11ms/frame, > > close to the perf of ReadFile (10ms/frame), making it possible > > to read the media at 60Hz. > > was this tested with all mov samples or just those high bitrate ones ? > > i am wondering if it helps/hurts demuxing the ancient mov samples we > also support. see the nightmares here https://samples.ffmpeg.org/mov/ > > if hurts, i wonder if buffer pools could be used only for specific high > bitrate codecs in mov demuxer? > > not important just curious. nice job on the speedup! > > -compn > ___ > 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] Use AVBufferPool in MOV
On 11/22/2024 2:46 PM, Arnaud Masserann wrote:
Most demuxers allocate a new buffer for each packet.
For MOV, this can be problematic, because of some high-bitrate
codecs like ProRes/HAPQ/NotchLC.
Use pools of buffer instead.
For some test media, demuxing goes from 20ms/frame to 11ms/frame,
close to the perf of ReadFile (10ms/frame), making it possible
to read the media at 60Hz.
Signed-off-by: Arnaud Masserann
---
libavformat/avformat.h | 12
libavformat/isom.h | 2 ++
libavformat/mov.c | 20 ++--
libavformat/utils.c| 29 +
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 56c1c80289..25f2e59b22 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -440,6 +440,18 @@ int av_get_packet(AVIOContext *s, AVPacket *pkt, int size);
*/
int av_append_packet(AVIOContext *s, AVPacket *pkt, int size);
+
+/**
+ * Like av_get_packet, but allocates the AVPacket's buffer from a pool.
+ *
+ * @param sassociated IO context
+ * @param pool the pool of buffers; must be initialized with a sufficient size
+ * @param pkt packet
+ * @param size desired payload size
+ * @return >0 (read size) if OK, AVERROR_xxx otherwise
+ */
+int av_get_pooled_packet(AVIOContext *s, AVBufferPool* pool, AVPacket *pkt,
int size);
This doesn't need to be public. It can be internal to lavf just fine.
+
/*/
/* input/output formats */
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 4723397048..c608f30e04 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -273,6 +273,8 @@ typedef struct MOVStreamContext {
} cenc;
struct IAMFDemuxContext *iamf;
+
+AVBufferPool* pools[32];
Like you argued, this can be in MovContext instead, since the pools are
fixed size and can be used by any stream.
} MOVStreamContext;
typedef struct HEIFItem {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index a2333ac1fd..2668bdf78f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -9583,6 +9583,7 @@ static void mov_free_encryption_index(MOVEncryptionIndex
**index) {
static void mov_free_stream_context(AVFormatContext *s, AVStream *st)
{
MOVStreamContext *sc = st->priv_data;
+int i;
if (!sc || --sc->refcount) {
st->priv_data = NULL;
@@ -9639,6 +9640,9 @@ static void mov_free_stream_context(AVFormatContext *s,
AVStream *st)
ff_iamf_read_deinit(sc->iamf);
#endif
av_freep(&sc->iamf);
+
+for (i = 0; i < FF_ARRAY_ELEMS(sc->pools); i++)
+av_buffer_pool_uninit(&sc->pools[i]);
}
static int mov_read_close(AVFormatContext *s)
@@ -10544,6 +10548,16 @@ static int mov_finalize_packet(AVFormatContext *s,
AVStream *st, AVIndexEntry *s
return 0;
}
+static AVBufferPool *mov_pool_get(AVBufferPool* pools[32], int size)
+{
+int index = av_log2(size + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!pools[index]) {
+int pool_size = 2 << index;
+pools[index] = av_buffer_pool_init(pool_size, NULL);
+}
+return pools[index];
+}
+
static int mov_read_packet(AVFormatContext *s, AVPacket *pkt)
{
MOVContext *mov = s->priv_data;
@@ -10617,8 +10631,10 @@ static int mov_read_packet(AVFormatContext *s,
AVPacket *pkt)
return FFERROR_REDO;
}
#endif
-else
-ret = av_get_packet(sc->pb, pkt, sample->size);
+else{
+AVBufferPool* pool = mov_pool_get(sc->pools, sample->size);
+ret = av_get_pooled_packet(sc->pb, pool, pkt, sample->size);
+}
if (ret < 0) {
if (should_retry(sc->pb, ret)) {
mov_current_sample_dec(sc);
diff --git a/libavformat/utils.c b/libavformat/utils.c
index e9ded627ad..869e97c089 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -104,6 +104,35 @@ FF_ENABLE_DEPRECATION_WARNINGS
return append_packet_chunked(s, pkt, size);
}
+int av_get_pooled_packet(AVIOContext *s, AVBufferPool* pool, AVPacket *pkt, int size)
+{
+#if FF_API_INIT_PACKET
+FF_DISABLE_DEPRECATION_WARNINGS
+av_init_packet(pkt);
+pkt->data = NULL;
+pkt->size = 0;
+FF_ENABLE_DEPRECATION_WARNINGS
+#else
+av_packet_unref(pkt);
+#endif
+pkt->pos = avio_tell(s);
+
+if(!pool)
+return AVERROR(ENOMEM);
+
+pkt->buf = av_buffer_pool_get(pool);;
Extra ;
+if(!pkt->buf)
+return AVERROR(ENOMEM);
+
+if(pkt->buf->size < size){
+av_packet_unref(pkt); // TODO test this
+return AVERROR(ENOMEM);
Maybe EINVAL instead.
Also, you're not setting pkt->data to pkt->buf->data.
+}
+
+return append_packet_chunked(s, pkt, size);
+}
+
+
int av_append_packet(AVIOContext *s, AVPacket *pkt, int size)
{
if (!pkt->size)
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [FFmpeg-devel] [PATCH] Use AVBufferPool in MOV
Hi, On Sun, Nov 24, 2024 at 12:25 PM Arnaud Masserann wrote: > There is no 32-stream limit. > Each AVBufferPool needs to be initialized with a fixed allocation > size. So, the 32 pools are for 1^1 bit allocations, 1^2 bit > allocations, ...2^32 bit allocations. See mov_pool_get in the patch. > > This is why moving pools[32] to MOVContext could be ok: audio packets > would statistically use pools[4...10], and video packets pools[12..20] > or something like that. Personally I find it cleaner to separate the > buffers per-stream, but maybe there are reasons to do it the other > way. > Ah, I see, clever. OK, so when you use something like /usr/bin/time to measure peak memory usage before/after, I assume it's roughly the same? Very cool. > As for the perf regarding small packet sizes: is my answer to compn > enough ? Would you like some more detailed analysis ? > I think it's fine. Some statistical variation is probably expected, and if the average gets better, that's probably good enough (at least from my perspective). Ronald ___ 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] Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
Hi all, On 11/24/2024 1:49 PM, James Almer wrote: On 11/24/2024 6:24 PM, Michael Niedermayer wrote: Hi On Sun, Nov 24, 2024 at 06:02:55PM -0300, James Almer wrote: On 11/24/2024 5:43 PM, Michael Niedermayer wrote: Hi On Sun, Nov 24, 2024 at 04:11:42PM -0300, James Almer wrote: On 11/24/2024 4:09 PM, Michael Niedermayer wrote: Now reality is, Paul (the 2nd most active developer of all time) was bullied out of FFmpeg. In private mail he spoke about being treated like a slave. Huh?? By whom? by the community, by us all maybe "bullied" is a badly choosen word here, but the way i understand it, is paul dislike having to deal with "disturbing" reviews I think only Nicolas was against his patches in general, sometimes for a fair reason, others probably not so much. I at least helped him every time i could. There has to be another reason for him to leave like he did. Iam fairly sure, if we would have left him change whatever he wants in his code and gave him final authority there that he would not have left. But he could do that. He did it all the time, and rarely got opposition since it was almost always for filters he wrote and maintained. BUT i do not know that He also pushed patches to his stuff bypassing the mailing list and review process. It introduced a bug or 2 and I think i pointed that out. I dont remember at all how i worded that. And there was teh conflicts where he pointed to bugs but refused to provide samples or details, making fixing them often impossible. While he caused this it lead to further friction. This really feels like a failure of mutual understanding, noone benefitted from this Not adding test was a problem, yes. Such a trivial thing to do for most filters and he'd still refuse. Also teh CC was re-elected at the time of him leaving IIRC. He may have preceived that a ban or harsh actions against him where imminent from the new CC. Thing is that nothing like that was imminent. He got a temp ban (like a week?) after several warnings for being too aggressive in his replies. I don't know why he was aggressive to begin with, and i even asked him to stop before anything was done. I dont know how to undo the decissions from the past. But i want to undo what led to paul leaving Sorry to interfere into your conversation, I just wanted to say important things here. Emotions are human, and to stay human with its own emotions are essentials since it's from our mistakes and the mistakes of other than we can mutually learn from each other. This said, ban someone because he/she 's too agressive or even insulting, at the end a lose lose will occur. Rather, if no ban is done, ok, after the storm, calm will come and compromise will be done, all the time... this is just a share of my life experience... Cheers David Jefferson ___ 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] swscale/ppc: disable YUV2RGB AltiVec acceleration
On Sun, Nov 24, 2024 at 02:01:48PM -0500, Sean McGovern wrote: > The FATE test 'checkasm-sw_yuv2rgb' currently fails on this platform, > in both little- and big-endian configurations. > > Disable it by default. > Add '-DSWS_USE_ALTIVEC_YUV2RGB' to CPPFLAGS to re-enable it. > --- > v2: rebased over top of the recent swscale changes from Nik Haas > --- > libswscale/ppc/yuv2rgb_altivec.c | 2 ++ > 1 file changed, 2 insertions(+) If noone reviews this within the next 7 days then consider this approved i can confirm that the test is disabled under qemu-ppc64abi32 with this and fails prior thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire 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] swscale/internal: fix typo in loongarch specific code
On Sun, Nov 24, 2024 at 10:21:34PM +0100, Marvin Scholz wrote:
> Regression from 2d077f9acda4946b3455ded5778fb3fc7e85bba2
> ---
> libswscale/loongarch/swscale_init_loongarch.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libswscale/loongarch/swscale_init_loongarch.c
> b/libswscale/loongarch/swscale_init_loongarch.c
> index 843fa08196..5204a8b66d 100644
> --- a/libswscale/loongarch/swscale_init_loongarch.c
> +++ b/libswscale/loongarch/swscale_init_loongarch.c
> @@ -42,7 +42,7 @@ av_cold void
> ff_sws_init_range_convert_loongarch(SwsInternal *c)
> #if HAVE_LASX
> if (have_lasx(cpu_flags)) {
> if (c->dstBpc <= 14) {
> -if (c->opts,src_range) {
> +if (c->opts.src_range) {
> c->lumConvertRange = lumRangeFromJpeg_lasx;
> c->chrConvertRange = chrRangeFromJpeg_lasx;
> } else {
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
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 2/3 v2] avformat/mov: Populate packet duration using stts atom instead of guessing
On 11/24/2024 10:46 PM, Michael Niedermayer wrote: Hi On Thu, Nov 21, 2024 at 07:40:22PM -0300, James Almer wrote: From: Darren Mo Fixes tickets #7855 and #11312. Signed-off-by: James Almer --- libavformat/isom.h| 3 + libavformat/mov.c | 181 -- tests/ref/fate/copy-trac236 | 4 +- tests/ref/fate/filter-fps | 1 + tests/ref/fate/filter-fps-cfr | 1 + tests/ref/fate/filter-meta-4560-rotate0 | 4 +- tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 2 +- tests/ref/fate/matroska-dovi-write-config8| 4 +- .../fate/matroska-non-rotation-displaymatrix | 6 +- tests/ref/fate/mov-aac-2048-priming | 2 +- tests/ref/fate/mov-zombie | 4 +- 11 files changed, 182 insertions(+), 30 deletions(-) this does strange things to duration: ./ffmpeg -i mm-short.mpg -y -bitexact -t 1 -acodec aac -frag_duration 200k test2.mov ./ffprobe -v 0 test2.mov -show_packets -print_format compact packet|codec_type=video|stream_index=0|pts=10752|pts_time=0.84|dts=10240|dts_time=0.80|duration=512|duration_time=0.04|size=2130|pos=77815|flags=___ packet|codec_type=video|stream_index=0|pts=13312|pts_time=1.04|dts=10752|dts_time=0.84|duration=512|duration_time=0.04|size=5123|pos=79945|flags=___ packet|codec_type=video|stream_index=0|pts=12288|pts_time=0.96|dts=11264|dts_time=0.88|duration=512|duration_time=0.04|size=3980|pos=85068|flags=___ packet|codec_type=video|stream_index=0|pts=11776|pts_time=0.92|dts=11776|dts_time=0.92|duration=512|duration_time=0.04|size=2266|pos=89048|flags=___ packet|codec_type=video|stream_index=0|pts=12800|pts_time=1.00|dts=12288|dts_time=0.96|duration=512|duration_time=0.04|size=2085|pos=91314|flags=___ -packet|codec_type=audio|stream_index=1|pts=38656|pts_time=0.805333|dts=38656|dts_time=0.805333|duration=1024|duration_time=0.021333|size=343|pos=93399|flags=K__ -packet|codec_type=audio|stream_index=1|pts=39680|pts_time=0.826667|dts=39680|dts_time=0.826667|duration=1024|duration_time=0.021333|size=338|pos=93742|flags=K__ -packet|codec_type=audio|stream_index=1|pts=40704|pts_time=0.848000|dts=40704|dts_time=0.848000|duration=1024|duration_time=0.021333|size=337|pos=94080|flags=K__ -packet|codec_type=audio|stream_index=1|pts=41728|pts_time=0.869333|dts=41728|dts_time=0.869333|duration=1024|duration_time=0.021333|size=326|pos=94417|flags=K__ -packet|codec_type=audio|stream_index=1|pts=42752|pts_time=0.890667|dts=42752|dts_time=0.890667|duration=1024|duration_time=0.021333|size=339|pos=94743|flags=K__ -packet|codec_type=audio|stream_index=1|pts=43776|pts_time=0.912000|dts=43776|dts_time=0.912000|duration=1024|duration_time=0.021333|size=336|pos=95082|flags=K__ -packet|codec_type=audio|stream_index=1|pts=44800|pts_time=0.93|dts=44800|dts_time=0.93|duration=1024|duration_time=0.021333|size=330|pos=95418|flags=K__ -packet|codec_type=audio|stream_index=1|pts=45824|pts_time=0.954667|dts=45824|dts_time=0.954667|duration=1024|duration_time=0.021333|size=333|pos=95748|flags=K__ -packet|codec_type=audio|stream_index=1|pts=46848|pts_time=0.976000|dts=46848|dts_time=0.976000|duration=1024|duration_time=0.021333|size=340|pos=96081|flags=K__ -packet|codec_type=audio|stream_index=1|pts=47872|pts_time=0.997333|dts=47872|dts_time=0.997333|duration=1024|duration_time=0.021333|size=337|pos=96421|flags=K__ -packet|codec_type=audio|stream_index=1|pts=48896|pts_time=1.018667|dts=48896|dts_time=1.018667|duration=1024|duration_time=0.021333|size=398|pos=96898|flags=K__ -packet|codec_type=audio|stream_index=1|pts=49920|pts_time=1.04|dts=49920|dts_time=1.04|duration=1024|duration_time=0.021333|size=367|pos=97296|flags=K__ -packet|codec_type=audio|stream_index=1|pts=50944|pts_time=1.061333|dts=50944|dts_time=1.061333|duration=1024|duration_time=0.021333|size=328|pos=97663|flags=K__ +packet|codec_type=audio|stream_index=1|pts=38656|pts_time=0.805333|dts=38656|dts_time=0.805333|duration=1070071408|duration_time=22293.154333|size=343|pos=93399|flags=K__ +packet|codec_type=audio|stream_index=1|pts=39680|pts_time=0.826667|dts=39680|dts_time=0.826667|duration=1070071408|duration_time=22293.154333|size=338|pos=93742|flags=K__ +packet|codec_type=audio|stream_index=1|pts=40704|pts_time=0.848000|dts=40704|dts_time=0.848000|duration=1070071408|duration_time=22293.154333|size=337|pos=94080|flags=K__ +packet|codec_type=audio|stream_index=1|pts=41728|pts_time=0.869333|dts=41728|dts_time=0.869333|duration=1070071408|duration_time=22293.154333|size=326|pos=94417|flags=K__ +packet|codec_type=audio|stream_index=1|pts=42752|pts_time=0.890667|dts=42752|dts_time=0.890667|duration=1070071408|duration_time=22293.154333|size=339|pos=94743|flags=K__ +packet|codec_type=audio|stream_index=1|pts=43776|pts_time=0.912000|dts=43776|dts_time=0.912000|duration=1070071408|duration_ti
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Remove Guillaume Poirier and Romain Dolbeau
On Sun, Nov 24, 2024 at 09:21:12PM +0100, Michael Niedermayer wrote: > Guillaume no longer has a PPC > Romain has no time > > CC: Guillaume POIRIER > CC: Romain Dolbeau > Signed-off-by: Michael Niedermayer > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/icodec: fix integer overflow with nb_pal
On Sun, Nov 24, 2024 at 09:06:16PM +1100, Peter Ross wrote: > On Thu, Nov 21, 2024 at 03:39:05PM +0100, Kacper Michajlow wrote: > > On Sun, 3 Nov 2024 at 11:24, Michael Niedermayer > > wrote: > > > > > > Fixes: runtime error: signed integer overflow > > > Fixes: > > > 42536949/clusterfuzz-testcase-minimized-fuzzer_loadfile-6199846684393472 > > > Found-by: ossfuzz > > > Reported-by: Kacper Michajlow > > > Tested-by: Kacper Michajlow > > > Signed-off-by: Michael Niedermayer > > > --- > > > libavformat/icodec.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/libavformat/icodec.c b/libavformat/icodec.c > > > index afd0c71b1f9..b09d0060a65 100644 > > > --- a/libavformat/icodec.c > > > +++ b/libavformat/icodec.c > > > @@ -198,7 +198,7 @@ static int read_packet(AVFormatContext *s, AVPacket > > > *pkt) > > > AV_WL32(buf + 32, image->nb_pal); > > > } > > > > > > -if (image->nb_pal > INT_MAX / 4 - 14 - 40) > > > +if (image->nb_pal > INT_MAX / 4 - 14 - 40U) > > > return AVERROR_INVALIDDATA; > > > > > > AV_WL32(buf - 4, 14 + 40 + image->nb_pal * 4); > > > -- > > > 2.47.0 > > as the original author of icodec.c, this lgtm will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mjpegdec: Disallow progressive bayer images
On Tue, Nov 19, 2024 at 03:20:45AM +0100, Michael Niedermayer wrote: > Fixes: Null pointer dereference > Fixes: sample1.dng > Found-by: South East <8billion.peo...@gmail.com> > Signed-off-by: Michael Niedermayer > --- > libavcodec/mjpegdec.c | 4 > 1 file changed, 4 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates 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] lavfi/qsvvpp: Copy frame props before modify it
On Vr, 2024-11-22 at 13:18 +0800, fei.w.wang-at-intel@ffmpeg.org wrote:
> From: Fei Wang
>
> The changes to output frame props in query_frame overlapped since
> b14ed6ea58. Move the copy frame props before the changes.
I can't find commit b14ed6ea58, could you double check the bad commit ?
Thanks
Haihao
>
> Signed-off-by: Fei Wang
> ---
> libavfilter/qsvvpp.c | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index 0818ada117..67ae23b165 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -471,7 +471,8 @@ static QSVFrame *submit_frame(QSVVPPContext *s,
> AVFilterLink *inlink, AVFrame *p
> }
>
> /* get the output surface */
> -static QSVFrame *query_frame(QSVVPPContext *s, AVFilterLink *outlink, const
> AVFrame *in)
> +static QSVFrame *query_frame(QSVVPPContext *s, AVFilterLink *outlink, const
> AVFrame *in,
> + const AVFrame *propref)
> {
> FilterLink *l = ff_filter_link(outlink);
> AVFilterContext *ctx = outlink->src;
> @@ -513,6 +514,15 @@ static QSVFrame *query_frame(QSVVPPContext *s,
> AVFilterLink *outlink, const AVFr
> return NULL;
> }
>
> + if (propref) {
> + ret = av_frame_copy_props(out_frame->frame, propref);
> + if (ret < 0) {
> + av_frame_free(&out_frame->frame);
> + av_log(ctx, AV_LOG_ERROR, "Failed to copy metadata fields from
> src to dst.\n");
> + return NULL;
> + }
> + }
> +
> if (l->frame_rate.num && l->frame_rate.den)
> out_frame->frame->duration = av_rescale_q(1, av_inv_q(l->frame_rate),
> outlink->time_base);
> else
> @@ -985,7 +995,7 @@ int ff_qsvvpp_filter_frame(QSVVPPContext *s, AVFilterLink
> *inlink, AVFrame *picr
> }
>
> do {
> - out_frame = query_frame(s, outlink, in_frame->frame);
> + out_frame = query_frame(s, outlink, in_frame->frame, propref);
> if (!out_frame) {
> av_log(ctx, AV_LOG_ERROR, "Failed to query an output frame.\n");
> return AVERROR(ENOMEM);
> @@ -1009,15 +1019,6 @@ int ff_qsvvpp_filter_frame(QSVVPPContext *s,
> AVFilterLink *inlink, AVFrame *picr
> break;
> }
>
> - if (propref) {
> - ret1 = av_frame_copy_props(out_frame->frame, propref);
> - if (ret1 < 0) {
> - av_frame_free(&out_frame->frame);
> - av_log(ctx, AV_LOG_ERROR, "Failed to copy metadata fields
> from src to dst.\n");
> - return ret1;
> - }
> - }
> -
> out_frame->frame->pts = av_rescale_q(out_frame-
> >surface.Data.TimeStamp,
> default_tb, outlink->time_base);
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/mov: add missing stts array syncing in mov_build_index
Missed in 865c73c86f9d9d167be7e41ad6cef71eba92dadd. Fixes parsing durations in
some cases.
Signed-off-by: James Almer
---
libavformat/mov.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index ce7a2f69c4..10ef002eff 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4690,7 +4690,9 @@ static void mov_build_index(MOVContext *mov, AVStream *st)
unsigned int stps_index = 0;
unsigned int i, j;
uint64_t stream_size = 0;
+MOVStts *stts_data_old = sc->stts_data;
MOVCtts *ctts_data_old = sc->ctts_data;
+unsigned int stts_count_old = sc->stts_count;
unsigned int ctts_count_old = sc->ctts_count;
int ret = build_open_gop_key_points(st);
@@ -4795,6 +4797,30 @@ static void mov_build_index(MOVContext *mov, AVStream
*st)
ctts_data_old[i].offset);
av_free(ctts_data_old);
}
+if (stts_data_old) {
+// Expand stts entries such that we have a 1-1 mapping with samples
+if (sc->sample_count >= UINT_MAX / sizeof(*sc->stts_data))
+return;
+sc->stts_count = 0;
+sc->stts_allocated_size = 0;
+sc->stts_data = av_fast_realloc(NULL, &sc->stts_allocated_size,
+sc->sample_count * sizeof(*sc->stts_data));
+if (!sc->stts_data) {
+av_free(stts_data_old);
+return;
+}
+
+memset((uint8_t*)(sc->stts_data), 0, sc->stts_allocated_size);
+
+for (i = 0; i < stts_count_old &&
+sc->stts_count < sc->sample_count; i++)
+for (j = 0; j < stts_data_old[i].count &&
+sc->stts_count < sc->sample_count; j++)
+add_stts_entry(&sc->stts_data, &sc->stts_count,
+ &sc->stts_allocated_size, 1,
+ stts_data_old[i].duration);
+av_free(stts_data_old);
+}
for (i = 0; i < sc->chunk_count; i++) {
int64_t next_offset = i+1 < sc->chunk_count ?
sc->chunk_offsets[i+1] : INT64_MAX;
--
2.47.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 2/3 v2] avformat/mov: Populate packet duration using stts atom instead of guessing
On 11/24/2024 10:57 PM, James Almer wrote: On 11/24/2024 10:46 PM, Michael Niedermayer wrote: Hi On Thu, Nov 21, 2024 at 07:40:22PM -0300, James Almer wrote: From: Darren Mo Fixes tickets #7855 and #11312. Signed-off-by: James Almer --- libavformat/isom.h | 3 + libavformat/mov.c | 181 -- tests/ref/fate/copy-trac236 | 4 +- tests/ref/fate/filter-fps | 1 + tests/ref/fate/filter-fps-cfr | 1 + tests/ref/fate/filter-meta-4560-rotate0 | 4 +- tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 2 +- tests/ref/fate/matroska-dovi-write-config8 | 4 +- .../fate/matroska-non-rotation-displaymatrix | 6 +- tests/ref/fate/mov-aac-2048-priming | 2 +- tests/ref/fate/mov-zombie | 4 +- 11 files changed, 182 insertions(+), 30 deletions(-) this does strange things to duration: ./ffmpeg -i mm-short.mpg -y -bitexact -t 1 -acodec aac -frag_duration 200k test2.mov ./ffprobe -v 0 test2.mov -show_packets -print_format compact [...] Can't reproduce. With current master I get: Actually, just noticed that the last packet duration is incorrect before and after this patch, and looking at it made me find a mistake in the commit. Will send a patch fixing it, which will make the last packet report the correct duration of 896, as coded in the output file (the commit as is already fixed the reported duration of the first packet from 1024 to 3840). OpenPGP_signature.asc Description: OpenPGP digital 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 v2] lavfi/qsvvpp: Copy frame props before modify it
From: Fei Wang
The changes to output frame props in query_frame overlapped since
578ac59887. Move the copy frame props before the changes.
Signed-off-by: Fei Wang
---
libavfilter/qsvvpp.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index 0818ada117..67ae23b165 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.c
@@ -471,7 +471,8 @@ static QSVFrame *submit_frame(QSVVPPContext *s,
AVFilterLink *inlink, AVFrame *p
}
/* get the output surface */
-static QSVFrame *query_frame(QSVVPPContext *s, AVFilterLink *outlink, const
AVFrame *in)
+static QSVFrame *query_frame(QSVVPPContext *s, AVFilterLink *outlink, const
AVFrame *in,
+ const AVFrame *propref)
{
FilterLink *l = ff_filter_link(outlink);
AVFilterContext *ctx = outlink->src;
@@ -513,6 +514,15 @@ static QSVFrame *query_frame(QSVVPPContext *s,
AVFilterLink *outlink, const AVFr
return NULL;
}
+if (propref) {
+ret = av_frame_copy_props(out_frame->frame, propref);
+if (ret < 0) {
+av_frame_free(&out_frame->frame);
+av_log(ctx, AV_LOG_ERROR, "Failed to copy metadata fields from src
to dst.\n");
+return NULL;
+}
+}
+
if (l->frame_rate.num && l->frame_rate.den)
out_frame->frame->duration = av_rescale_q(1, av_inv_q(l->frame_rate),
outlink->time_base);
else
@@ -985,7 +995,7 @@ int ff_qsvvpp_filter_frame(QSVVPPContext *s, AVFilterLink
*inlink, AVFrame *picr
}
do {
-out_frame = query_frame(s, outlink, in_frame->frame);
+out_frame = query_frame(s, outlink, in_frame->frame, propref);
if (!out_frame) {
av_log(ctx, AV_LOG_ERROR, "Failed to query an output frame.\n");
return AVERROR(ENOMEM);
@@ -1009,15 +1019,6 @@ int ff_qsvvpp_filter_frame(QSVVPPContext *s,
AVFilterLink *inlink, AVFrame *picr
break;
}
-if (propref) {
-ret1 = av_frame_copy_props(out_frame->frame, propref);
-if (ret1 < 0) {
-av_frame_free(&out_frame->frame);
-av_log(ctx, AV_LOG_ERROR, "Failed to copy metadata fields from
src to dst.\n");
-return ret1;
-}
-}
-
out_frame->frame->pts = av_rescale_q(out_frame->surface.Data.TimeStamp,
default_tb, outlink->time_base);
--
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".
Re: [FFmpeg-devel] Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
On Sun, 24 Nov 2024, 19:09 Michael Niedermayer, wrote: > Hi Kieran > > I think this is off topic for this thread, but i will reply with adjusted > Subject and as a new thread > > On Sun, Nov 24, 2024 at 02:58:29PM +, Kieran Kunhya via ffmpeg-devel > wrote: > > On Sun, Nov 24, 2024 at 12:23 PM Michael Niedermayer > [...] > > "In the email at the URL you provided > > (https://ffmpeg.org//pipermail/ffmpeg-devel/2015-July/176489.html), > > Michael Niedermayer states: > > > > Root admin roles: > > I will keep the server root admin role until there is an agreement who > > should have it that is acceptable for the ffmpeg and libav > > communities. > > This confirms that Michael Niedermayer agrees to give root access of > > the FFmpeg project to whomever both the FFmpeg and Libav communities > > agree should have it." > > This is a very long time ago. And at the time i believed everyone would > join and work together and that all hostilities where over. > Yes i guess i was naive. (Or maybe i was thinking something else, its > 9 years ago, who knows) > > Now reality is, Paul (the 2nd most active developer of all time) was > bullied > out of FFmpeg. In private mail he spoke about being treated like a slave. > > And in the last 3 weeks, alot of hostilities have hit me, so i kind of > feel a little like Paul maybe felt. > One of the reasons Paul left was because you tried to ram SDR into this project in spite of huge objections from the community. There are other areas like sonic and libpostproc where he is unhappy with your actions. Yet again you don't have the right to hold this project to ransom based on your whims. If anything you doing this proves that you shouldn't be de facto leader. We have a GA and the GA leads the project, not you. 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".
Re: [FFmpeg-devel] Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
On Sun, 24 Nov 2024, 19:09 Michael Niedermayer, wrote: > And i hear almost everyone at VDD are old man. FFmpeg cannot be run by > just old man. There is a need for young people and need for new ideas. Then stop blocking a move to Gitlab based on false concerns of paranoia. Using a mailing list is like using a fax machine or BBS. It's no surprise we have no young blood. On Twitter/X I see weekly complaints from people about our antiquated patch review process. Has it ever occured to you that if someone disagrees with you they are not "attacks"? There are plenty of new ideas and it's only you and a few others that talk repeatedly about ancient history. It's as if this current setup is highly convenient for you... 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".
Re: [FFmpeg-devel] Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
On Sun, 24 Nov 2024 20:09:43 +0100 Michael Niedermayer wrote: > less than 2 weeks ago the founder was insulted like this: > "Fabrice's control of ffmpeg.org and French trademark, despite not havign > contributed > in 20 years, purely for ego reasons mean we can never move to a truly > community run set or project infra." > > And we can probably go on and on. > On top of this i would not be surprised if other people have similar stories > from yet others they spoke with. a non-ff developer at vdd said i was "inactive for years". it makes me not want to visit vdd again. i reported them to the videolan board, but the videolan board never even bothered to reply to my mail. i dont think the videolan code of conduct has any enforcement, despite them saying how awesome the videolan code of conduct is. i also question how "strong" their board/project is if it cant even ack a code of conduct complaint in 20+ days. thats not strong, its non functional. i have maintained a few things these last 5 years, although i havent been active on the ml. i've done hundreds of hours of work in the past 5 years on ffmpeg. including moderating the mailing lists, which i've done since ~2006. now that i have more time recently i'm back to doing patch reviews on ml, answering questions to new developers in #ffmpeg-devel. there is a huge hole now that carl has left the bug trac. his work was super under appreciated. developers for years would attack and threaten him for insignificant things, example because he marked a bug invalid/wontfix. i come back to the mailing list and see so much infighting. for no reason. 9 year old mail quotes? nonsense! are you trying to chase more developers from the project? calling developers inactive? calling developers paranoid? calling developers to step down? > Not realizing that the domain is held by the founder who belongs to the > community, not realizing most of the root admins are active members of > the community. arpi, alex and reimar are certainly ffmpeg committers and part of the community. it was a shock when someone asked who they were. -compn ___ 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] Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
On 11/24/2024 5:43 PM, Michael Niedermayer wrote: Hi On Sun, Nov 24, 2024 at 04:11:42PM -0300, James Almer wrote: On 11/24/2024 4:09 PM, Michael Niedermayer wrote: Now reality is, Paul (the 2nd most active developer of all time) was bullied out of FFmpeg. In private mail he spoke about being treated like a slave. Huh?? By whom? by the community, by us all maybe "bullied" is a badly choosen word here, but the way i understand it, is paul dislike having to deal with "disturbing" reviews I think only Nicolas was against his patches in general, sometimes for a fair reason, others probably not so much. I at least helped him every time i could. There has to be another reason for him to leave like he did. And i can here only speak of myself not about how paul sees it, so it is my view here: Posting a patch that is technically correct and fine and then having to deal with endless debates is annoying. Thats also why i keep asking for plugin support, as it allows people to work on their code under their own terms. thx [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". OpenPGP_signature.asc Description: OpenPGP digital 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] Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
On 11/24/2024 4:54 PM, Kieran Kunhya via ffmpeg-devel wrote: On Sun, 24 Nov 2024, 19:09 Michael Niedermayer, wrote: And i hear almost everyone at VDD are old man. FFmpeg cannot be run by just old man. There is a need for young people and need for new ideas. Then stop blocking a move to Gitlab based on false concerns of paranoia. Can you point to where he blocked such a move? Being vocally against it isn't blocking as he can easily get outvoted. Afair, the main arguments against that move was the need to use web interfaces for tasks that until now were handled with a command line. But otherwise, it's been mentioned in every meeting and the only thing missing is a vote for it, and probably deciding where it would be hosted. Using a mailing list is like using a fax machine or BBS. It's no surprise we have no young blood. On Twitter/X I see weekly complaints from people about our antiquated patch review process. I agree with this, and I'd like to move to gitlab or a similar MR based solution with integrated CI soon. Has it ever occured to you that if someone disagrees with you they are not "attacks"? There are plenty of new ideas and it's only you and a few others that talk repeatedly about ancient history. It's as if this current setup is highly convenient for you... 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". OpenPGP_signature.asc Description: OpenPGP digital 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] MAINTAINERS: Add myself as Darwin maintainer
I do some development and usage of FFmpeg regularly on macOS and sent some patches to fix issues specific to Darwin in the past so I think it makes sense to add myself as maintainer so people know they can ping me if required, for Darwin specific issues/testing. I have both Intel and Apple Silicon (aarch64) machines as well as older Macs for testing on older macOS versions if necessary. --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8a1883c48c..ba92d73c1f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -511,6 +511,7 @@ Operating systems / CPU architectures Alpha [0] MIPSManojkumar Bhosale, Shiyou Yin LoongArch [2] Shiyou Yin +Darwin (macOS, iOS) [2] Marvin Scholz Mac OS X / PowerPC Romain Dolbeau, Guillaume Poirier Amiga / PowerPC Colin Ward Linux / PowerPC Lauri Kasanen base-commit: ecc7d5db9c8a1aaccc876dc4b549558eadfe140a -- 2.39.5 (Apple Git-154) ___ 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] Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
Hi On Sun, Nov 24, 2024 at 07:33:57PM +, Kieran Kunhya via ffmpeg-devel wrote: > On Sun, 24 Nov 2024, 19:09 Michael Niedermayer, > wrote: > > > Hi Kieran > > > > I think this is off topic for this thread, but i will reply with adjusted > > Subject and as a new thread > > > > On Sun, Nov 24, 2024 at 02:58:29PM +, Kieran Kunhya via ffmpeg-devel > > wrote: > > > On Sun, Nov 24, 2024 at 12:23 PM Michael Niedermayer > > [...] > > > "In the email at the URL you provided > > > (https://ffmpeg.org//pipermail/ffmpeg-devel/2015-July/176489.html), > > > Michael Niedermayer states: > > > > > > Root admin roles: > > > I will keep the server root admin role until there is an agreement who > > > should have it that is acceptable for the ffmpeg and libav > > > communities. > > > This confirms that Michael Niedermayer agrees to give root access of > > > the FFmpeg project to whomever both the FFmpeg and Libav communities > > > agree should have it." > > > > This is a very long time ago. And at the time i believed everyone would > > join and work together and that all hostilities where over. > > Yes i guess i was naive. (Or maybe i was thinking something else, its > > 9 years ago, who knows) > > > > Now reality is, Paul (the 2nd most active developer of all time) was > > bullied > > out of FFmpeg. In private mail he spoke about being treated like a slave. > > > > And in the last 3 weeks, alot of hostilities have hit me, so i kind of > > feel a little like Paul maybe felt. > > > > One of the reasons Paul left was because you tried to ram SDR into this > project in spite of huge objections from the community. Paul was against SDR and SDR was never included into FFmpeg. But the main person who was against SDR was you. And i thus tried to talk with you about this. You refused to talk with me and pointed to the community. The community, that happily talked with me had largely no idea why SDR was bad they just screamed "foul" because you did. Thats how i preceived it > There are other > areas like sonic and libpostproc where he is unhappy with your actions. I intended to work on sonic but did not had the time yet And libpostproc, i intended to split out as a STF project and maintain outside. But people said 5k$ is too much. So 5k will be donated and libpostproc stays in FFmpeg. I dont know. But it seems the people are fighting the problem and the solution at the same time. > > Yet again you don't have the right to hold this project to ransom based on > your whims. If anything you doing this proves that you shouldn't be de > facto leader. You want me to return as leader and talk with a few aggressive people from the ML ? And no i would not ban anyone if they stop. But if i was leader these annoying debates would have stoped 1 day after their start. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
Hi On Sun, Nov 24, 2024 at 06:02:55PM -0300, James Almer wrote: > On 11/24/2024 5:43 PM, Michael Niedermayer wrote: > > Hi > > > > On Sun, Nov 24, 2024 at 04:11:42PM -0300, James Almer wrote: > > > On 11/24/2024 4:09 PM, Michael Niedermayer wrote: > > > > Now reality is, Paul (the 2nd most active developer of all time) was > > > > bullied > > > > out of FFmpeg. In private mail he spoke about being treated like a > > > > slave. > > > > > > Huh?? By whom? > > > > by the community, by us all > > > > maybe "bullied" is a badly choosen word here, but the way i understand it, > > is paul > > dislike having to deal with "disturbing" reviews > > I think only Nicolas was against his patches in general, sometimes for a > fair reason, others probably not so much. I at least helped him every time i > could. > > There has to be another reason for him to leave like he did. Iam fairly sure, if we would have left him change whatever he wants in his code and gave him final authority there that he would not have left. BUT i do not know that He also pushed patches to his stuff bypassing the mailing list and review process. It introduced a bug or 2 and I think i pointed that out. I dont remember at all how i worded that. And there was teh conflicts where he pointed to bugs but refused to provide samples or details, making fixing them often impossible. While he caused this it lead to further friction. This really feels like a failure of mutual understanding, noone benefitted from this Also teh CC was re-elected at the time of him leaving IIRC. He may have preceived that a ban or harsh actions against him where imminent from the new CC. Thing is that nothing like that was imminent. I dont know how to undo the decissions from the past. But i want to undo what led to paul leaving thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes 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] swscale/internal: fix typo in loongarch specific code
Regression from 2d077f9acda4946b3455ded5778fb3fc7e85bba2
---
libswscale/loongarch/swscale_init_loongarch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswscale/loongarch/swscale_init_loongarch.c
b/libswscale/loongarch/swscale_init_loongarch.c
index 843fa08196..5204a8b66d 100644
--- a/libswscale/loongarch/swscale_init_loongarch.c
+++ b/libswscale/loongarch/swscale_init_loongarch.c
@@ -42,7 +42,7 @@ av_cold void ff_sws_init_range_convert_loongarch(SwsInternal
*c)
#if HAVE_LASX
if (have_lasx(cpu_flags)) {
if (c->dstBpc <= 14) {
-if (c->opts,src_range) {
+if (c->opts.src_range) {
c->lumConvertRange = lumRangeFromJpeg_lasx;
c->chrConvertRange = chrRangeFromJpeg_lasx;
} else {
base-commit: ecb7232bac33ebba47e03663e7e5a3517a8e0a5c
--
2.39.5 (Apple Git-154)
___
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] libavformat/mpegts: demux DVB VBI data
On Fri, 22 Nov 2024, Scott Theisen wrote: On 11/22/24 16:12, Marton Balint wrote: On Fri, 15 Nov 2024, Scott Theisen wrote: From: ulmus-scott DVB VBI data is defined in ETSI EN 301 775 and can include EBU teletext data as defined in ETSI EN 300 472. ETSI EN 300 468 defines teletext_descriptor, VBI_data_descriptor, and VBI_teletext_descriptor, which has the same definition as, but different use from, teletext_descriptor. Hmm, adding a new codec for VBI data might be OK, but I am not sure if there is a better way to automagically let the framework know if there are teletext compatible VBI packets, so the teletext decoder can be used. Would another AVCodecID AV_CODEC_ID_DVB_VBI_WITH_TELETEXT that would use the teletext decoder work? Would this be AVMEDIA_TYPE_SUBTITLE even though it also includes data? (Also, what teletext decoder?) I am not that big fan of adding both DVB_VBI and DVB_VBI_WITH_TELETEXT, considering these use the same essence format. And VBI_teletext_descriptor is an additional descriptor to VBI_data_descriptor as far as I understand the standard. (Although ETSI EN 300 468 6.2.47 seems to be referring to teletext_descriptor as an additional descriptor, but that makes little sense to me, they meant VBI_teletext_descriptor here?) Or maybe we should simply set the codec id to DVB_TELETEXT if there is a VBI_TELETEXT_DESCRIPTOR, and make the teletext decoder parse all data units in search for a comptaible data unit id? That would work only if you don't want to use any of the other VBI data, which is what MythTV currently does, ignoring packets where data_identifier is not EBU data and data_field()s where data_unit_id is not EBU teletext data as defined in ETSI EN 300 472. My main concern is if someone wants to decode the other types of VBI data how would they do that, or know to try, if it claims it is just EBU teletext data? FFmpeg does not have data decoders, so the user has to parse the packets anyway if he is interested in VBI. Because if we set the codec to VBI for VBI_TELETEXT cases, won't this break the automatic probing of unknown codecs? (which otherwise might recognize the stream as teletext)? So maybe for VBI_TELETEXT_DESCRIPTOR case we should keep the coded id NONE and rely entirely on probing? I have no idea how this would interact with the automatic probing. Me neither to be honest, and relying entirely on probing is not very nice in the first place, so let's just forget this. Maybe we should stick to your original idea, use a single codec for the VBI streams, but make it AVMEDIA_TYPE_SUBTITLE, considering it can contain teletext (even if there is no VBI teletext descriptor in case of inverted teletext) and even closed captions, which our decoders might be able to decode to something meaninful. Then anybody interested can add a new decoder for this new codec ID (which obviously can share code with libzvbi-teletextdec), so it will be able to decode teletext as well. Regards, 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".
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Remove Guillaume Poirier and Romain Dolbeau
Hi On Sun, Nov 24, 2024 at 09:21:12PM +0100, Michael Niedermayer wrote: > Guillaume no longer has a PPC > Romain has no time > > CC: Guillaume POIRIER > CC: Romain Dolbeau > Signed-off-by: Michael Niedermayer > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8a1883c48c9..ed931d0119f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -511,7 +511,7 @@ Operating systems / CPU architectures > Alpha [0] > MIPSManojkumar Bhosale, Shiyou Yin > LoongArch [2] Shiyou Yin > -Mac OS X / PowerPC Romain Dolbeau, Guillaume Poirier > +Mac OS X / PowerPC [0] > Amiga / PowerPC Colin Ward does anyone know of a way to contact Colin Ward ? 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".
[FFmpeg-devel] [PATCH] MAINTAINERS: Remove Guillaume Poirier and Romain Dolbeau
Guillaume no longer has a PPC Romain has no time CC: Guillaume POIRIER CC: Romain Dolbeau Signed-off-by: Michael Niedermayer --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8a1883c48c9..ed931d0119f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -511,7 +511,7 @@ Operating systems / CPU architectures Alpha [0] MIPSManojkumar Bhosale, Shiyou Yin LoongArch [2] Shiyou Yin -Mac OS X / PowerPC Romain Dolbeau, Guillaume Poirier +Mac OS X / PowerPC [0] Amiga / PowerPC Colin Ward Linux / PowerPC Lauri Kasanen RISC-V [2] Rémi Denis-Courmont -- 2.47.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] Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
Hi On Sun, Nov 24, 2024 at 04:11:42PM -0300, James Almer wrote: > On 11/24/2024 4:09 PM, Michael Niedermayer wrote: > > Now reality is, Paul (the 2nd most active developer of all time) was bullied > > out of FFmpeg. In private mail he spoke about being treated like a slave. > > Huh?? By whom? by the community, by us all maybe "bullied" is a badly choosen word here, but the way i understand it, is paul dislike having to deal with "disturbing" reviews And i can here only speak of myself not about how paul sees it, so it is my view here: Posting a patch that is technically correct and fine and then having to deal with endless debates is annoying. Thats also why i keep asking for plugin support, as it allows people to work on their code under their own terms. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire 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 2/3 v2] avformat/mov: Populate packet duration using stts atom instead of guessing
Hi On Thu, Nov 21, 2024 at 07:40:22PM -0300, James Almer wrote: > From: Darren Mo > > Fixes tickets #7855 and #11312. > > Signed-off-by: James Almer > --- > libavformat/isom.h| 3 + > libavformat/mov.c | 181 -- > tests/ref/fate/copy-trac236 | 4 +- > tests/ref/fate/filter-fps | 1 + > tests/ref/fate/filter-fps-cfr | 1 + > tests/ref/fate/filter-meta-4560-rotate0 | 4 +- > tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 2 +- > tests/ref/fate/matroska-dovi-write-config8| 4 +- > .../fate/matroska-non-rotation-displaymatrix | 6 +- > tests/ref/fate/mov-aac-2048-priming | 2 +- > tests/ref/fate/mov-zombie | 4 +- > 11 files changed, 182 insertions(+), 30 deletions(-) this does strange things to duration: ./ffmpeg -i mm-short.mpg -y -bitexact -t 1 -acodec aac -frag_duration 200k test2.mov ./ffprobe -v 0 test2.mov -show_packets -print_format compact packet|codec_type=video|stream_index=0|pts=10752|pts_time=0.84|dts=10240|dts_time=0.80|duration=512|duration_time=0.04|size=2130|pos=77815|flags=___ packet|codec_type=video|stream_index=0|pts=13312|pts_time=1.04|dts=10752|dts_time=0.84|duration=512|duration_time=0.04|size=5123|pos=79945|flags=___ packet|codec_type=video|stream_index=0|pts=12288|pts_time=0.96|dts=11264|dts_time=0.88|duration=512|duration_time=0.04|size=3980|pos=85068|flags=___ packet|codec_type=video|stream_index=0|pts=11776|pts_time=0.92|dts=11776|dts_time=0.92|duration=512|duration_time=0.04|size=2266|pos=89048|flags=___ packet|codec_type=video|stream_index=0|pts=12800|pts_time=1.00|dts=12288|dts_time=0.96|duration=512|duration_time=0.04|size=2085|pos=91314|flags=___ -packet|codec_type=audio|stream_index=1|pts=38656|pts_time=0.805333|dts=38656|dts_time=0.805333|duration=1024|duration_time=0.021333|size=343|pos=93399|flags=K__ -packet|codec_type=audio|stream_index=1|pts=39680|pts_time=0.826667|dts=39680|dts_time=0.826667|duration=1024|duration_time=0.021333|size=338|pos=93742|flags=K__ -packet|codec_type=audio|stream_index=1|pts=40704|pts_time=0.848000|dts=40704|dts_time=0.848000|duration=1024|duration_time=0.021333|size=337|pos=94080|flags=K__ -packet|codec_type=audio|stream_index=1|pts=41728|pts_time=0.869333|dts=41728|dts_time=0.869333|duration=1024|duration_time=0.021333|size=326|pos=94417|flags=K__ -packet|codec_type=audio|stream_index=1|pts=42752|pts_time=0.890667|dts=42752|dts_time=0.890667|duration=1024|duration_time=0.021333|size=339|pos=94743|flags=K__ -packet|codec_type=audio|stream_index=1|pts=43776|pts_time=0.912000|dts=43776|dts_time=0.912000|duration=1024|duration_time=0.021333|size=336|pos=95082|flags=K__ -packet|codec_type=audio|stream_index=1|pts=44800|pts_time=0.93|dts=44800|dts_time=0.93|duration=1024|duration_time=0.021333|size=330|pos=95418|flags=K__ -packet|codec_type=audio|stream_index=1|pts=45824|pts_time=0.954667|dts=45824|dts_time=0.954667|duration=1024|duration_time=0.021333|size=333|pos=95748|flags=K__ -packet|codec_type=audio|stream_index=1|pts=46848|pts_time=0.976000|dts=46848|dts_time=0.976000|duration=1024|duration_time=0.021333|size=340|pos=96081|flags=K__ -packet|codec_type=audio|stream_index=1|pts=47872|pts_time=0.997333|dts=47872|dts_time=0.997333|duration=1024|duration_time=0.021333|size=337|pos=96421|flags=K__ -packet|codec_type=audio|stream_index=1|pts=48896|pts_time=1.018667|dts=48896|dts_time=1.018667|duration=1024|duration_time=0.021333|size=398|pos=96898|flags=K__ -packet|codec_type=audio|stream_index=1|pts=49920|pts_time=1.04|dts=49920|dts_time=1.04|duration=1024|duration_time=0.021333|size=367|pos=97296|flags=K__ -packet|codec_type=audio|stream_index=1|pts=50944|pts_time=1.061333|dts=50944|dts_time=1.061333|duration=1024|duration_time=0.021333|size=328|pos=97663|flags=K__ +packet|codec_type=audio|stream_index=1|pts=38656|pts_time=0.805333|dts=38656|dts_time=0.805333|duration=1070071408|duration_time=22293.154333|size=343|pos=93399|flags=K__ +packet|codec_type=audio|stream_index=1|pts=39680|pts_time=0.826667|dts=39680|dts_time=0.826667|duration=1070071408|duration_time=22293.154333|size=338|pos=93742|flags=K__ +packet|codec_type=audio|stream_index=1|pts=40704|pts_time=0.848000|dts=40704|dts_time=0.848000|duration=1070071408|duration_time=22293.154333|size=337|pos=94080|flags=K__ +packet|codec_type=audio|stream_index=1|pts=41728|pts_time=0.869333|dts=41728|dts_time=0.869333|duration=1070071408|duration_time=22293.154333|size=326|pos=94417|flags=K__ +packet|codec_type=audio|stream_index=1|pts=42752|pts_time=0.890667|dts=42752|dts_time=0.890667|duration=1070071408|duration_time=22293.154333|size=339|pos=94743|flags=K__ +packet|codec_type=audio|stream_index=1|pts=43776|pts_time=0.912000|dts=43776|dts_time=0.912000|duration=1070071408|duration_time=22293.154333|size=336|pos=95082|f
Re: [FFmpeg-devel] [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
Hi Michael, On Sat, Nov 23, 2024 at 8:12 AM Michael Niedermayer wrote: > +Stay On-Topic: Ensure your messages relate to software development or the > specific purpose of the mailing list. Avoid unrelated discussions. > +Be Respectful: Treat all members with courtesy and respect. Personal > attacks, insults, or harassment of any kind are not tolerated. > +Avoid Provocation: Refrain from posting inflammatory, controversial, or > intentionally provocative messages. Focus on constructive discussions. > +No Trolling: Messages intended to provoke an emotional response or > disrupt the discussion are prohibited. > +Professional Language: Use clear, professional, and inclusive language. > Avoid offensive or derogatory remarks, even in jest. > +Constructive Criticism Only: Offer feedback in a constructive and > solution-oriented manner. Criticize ideas, not people. > +Handle Disagreements Professionally: Disagreements are normal but should > be handled respectfully. Assume good intentions and avoid escalating > conflicts. > Is there a source you used for these rules? Or did you write this yourself? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/icodec: fix integer overflow with nb_pal
On Thu, Nov 21, 2024 at 03:39:05PM +0100, Kacper Michajlow wrote: > On Sun, 3 Nov 2024 at 11:24, Michael Niedermayer > wrote: > > > > Fixes: runtime error: signed integer overflow > > Fixes: > > 42536949/clusterfuzz-testcase-minimized-fuzzer_loadfile-6199846684393472 > > Found-by: ossfuzz > > Reported-by: Kacper Michajlow > > Tested-by: Kacper Michajlow > > Signed-off-by: Michael Niedermayer > > --- > > libavformat/icodec.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavformat/icodec.c b/libavformat/icodec.c > > index afd0c71b1f9..b09d0060a65 100644 > > --- a/libavformat/icodec.c > > +++ b/libavformat/icodec.c > > @@ -198,7 +198,7 @@ static int read_packet(AVFormatContext *s, AVPacket > > *pkt) > > AV_WL32(buf + 32, image->nb_pal); > > } > > > > -if (image->nb_pal > INT_MAX / 4 - 14 - 40) > > +if (image->nb_pal > INT_MAX / 4 - 14 - 40U) > > return AVERROR_INVALIDDATA; > > > > AV_WL32(buf - 4, 14 + 40 + image->nb_pal * 4); > > -- > > 2.47.0 as the original author of icodec.c, this lgtm -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
Hi Remi On Sat, Nov 23, 2024 at 05:16:10PM +0100, Rémi Denis-Courmont wrote: > > > Le 23 novembre 2024 14:12:19 GMT+01:00, Michael Niedermayer > a écrit : > >Signed-off-by: Michael Niedermayer > >--- > > doc/community.texi | 14 ++ > > 1 file changed, 14 insertions(+) > > > >diff --git a/doc/community.texi b/doc/community.texi > >index 97a49f15ede..8c24faef95e 100644 > >--- a/doc/community.texi > >+++ b/doc/community.texi > >@@ -162,6 +162,20 @@ Looking at issues from a different perspective assists > >development. > > Do not assume malice for things that can be attributed to incompetence. > > Even if > > it is malice, it's rarely good to start with that as initial assumption. > > > >+Stay On-Topic: Ensure your messages relate to software development or the > >specific purpose of the mailing list. Avoid unrelated discussions. > > Nobody wants off-topic discussions, but that rule sounds ripe for abuse. This rule is not intended to stifle conversation but to maintain focus. Mailing lists with frequent off-topic discussions often alienate participants who are there for the stated purpose. Abuse of the rule can be mitigated by transparent enforcement and community oversight. Clear guidelines on what constitutes "on-topic" can prevent ambiguity. > > >+ > >+Be Respectful: Treat all members with courtesy and respect. Personal > >attacks, insults, or harassment of any kind are not tolerated. > > This is just dumb. If the CC can't do its job, adding more subjective rules > is going to make things worse, not better. > > And indeed people often take criticism about their work as personal attacks, > so this would make negative reviews impossible. > > Lastly insults are typically illegal anyway, so no point adding a rule for > them. Respect is the foundation of productive communication. Without it, discussions devolve into hostility, driving valuable contributors away. While some people misinterpret criticism of their work as a personal attack, the rule explicitly emphasizes avoiding actual personal attacks, not robust technical critique. A respectful tone ensures conversations remain productive, and this rule complements legal boundaries by addressing subtler, often legal but still damaging, behaviors. The Community commitee or moderators ensure this rule is enforced fairly and objectively. > > >+ > >+Avoid Provocation: Refrain from posting inflammatory, controversial, or > >intentionally provocative messages. Focus on constructive discussions. > > This is very subjective and completely unenforceable. While it’s true that provocation is subjective to some extent, this rule targets intentional disruption, which is often clear. Patterns of behavior, context, and community feedback guide enforcement. This rule doesn’t prohibit controversial opinions; it asks for them to be expressed constructively, not to derail discussions or incite conflict. > > >+ > >+No Trolling: Messages intended to provoke an emotional response or disrupt > >the discussion are prohibited. > > Ditto. Trolling is often identifiable through repeated disruptive behavior, and many online communities successfully enforce anti-trolling rules. Clear examples and consistent enforcement make this rule practical. Ignoring trolling entirely leaves the community vulnerable to disruption, which impacts everyone. This rule empowers moderators/CC to act while fostering a healthier environment. > > >+ > >+Professional Language: Use clear, professional, and inclusive language. > >Avoid offensive or derogatory remarks, even in jest. > > That's fine *guideline*. It can't be a hard rule. This is indeed more of a guideline than a hard rule, and it’s framed as such. However, a guideline doesn’t diminish its importance. Encouraging professional language ensures inclusivity and clarity, reducing misunderstandings and making the mailing list more welcoming. Rules set the tone for the group, and even if enforcement is flexible, they guide expectations. > > >+ > >+Constructive Criticism Only: Offer feedback in a constructive and > >solution-oriented manner. Criticize ideas, not people. > > This is just dumb. Reviewers aren't typically paid. We can't require them to > write constructive feedback every time (if ever). And the TC is already there > to arbitrate technical disagreement. > > Again, this is a fine guideline but it can't be a hard rule. This rule doesn’t require every reviewer to provide detailed solutions; it emphasizes the tone of feedback. Even brief reviews can avoid unnecessarily harsh language or personal criticism. Constructive criticism fosters collaboration and improvement, while unconstructive negativity deters participation. The TC (Technical Committee) shouldn’t have to arbitrate every disagreement—this rule helps prevent conflicts from escalating. > > >+Handle Disagreements Professionally: Disagreements are normal but should be > >handled respectfully. Assume good intentions and avoid
Re: [FFmpeg-devel] [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
On Sun, Nov 24, 2024 at 12:23 PM Michael Niedermayer wrote: > > Hi Remi > > On Sat, Nov 23, 2024 at 05:16:10PM +0100, Rémi Denis-Courmont wrote: > > > > > > Le 23 novembre 2024 14:12:19 GMT+01:00, Michael Niedermayer > > a écrit : > > >Signed-off-by: Michael Niedermayer > > >--- > > > doc/community.texi | 14 ++ > > > 1 file changed, 14 insertions(+) > > > > > >diff --git a/doc/community.texi b/doc/community.texi > > >index 97a49f15ede..8c24faef95e 100644 > > >--- a/doc/community.texi > > >+++ b/doc/community.texi > > >@@ -162,6 +162,20 @@ Looking at issues from a different perspective > > >assists development. > > > Do not assume malice for things that can be attributed to incompetence. > > > Even if > > > it is malice, it's rarely good to start with that as initial assumption. > > > > > >+Stay On-Topic: Ensure your messages relate to software development or the > > >specific purpose of the mailing list. Avoid unrelated discussions. > > > > Nobody wants off-topic discussions, but that rule sounds ripe for abuse. > > This rule is not intended to stifle conversation but to maintain focus. > Mailing lists with frequent off-topic discussions often alienate participants > who are there for the stated purpose. Abuse of the rule can be mitigated by > transparent enforcement and community oversight. Clear guidelines on what > constitutes "on-topic" can prevent ambiguity. > > > > > > >+ > > >+Be Respectful: Treat all members with courtesy and respect. Personal > > >attacks, insults, or harassment of any kind are not tolerated. > > > > This is just dumb. If the CC can't do its job, adding more subjective rules > > is going to make things worse, not better. > > > > And indeed people often take criticism about their work as personal > > attacks, so this would make negative reviews impossible. > > > > Lastly insults are typically illegal anyway, so no point adding a rule for > > them. > > Respect is the foundation of productive communication. Without it, > discussions devolve into hostility, driving valuable contributors away. > > While some people misinterpret criticism of their work as a personal attack, > the rule explicitly emphasizes avoiding actual personal attacks, not robust > technical critique. A respectful tone ensures conversations remain productive, > and this rule complements legal boundaries by addressing subtler, often > legal but still damaging, behaviors. > > The Community commitee or moderators ensure this rule is enforced fairly > and objectively. > > > > > > >+ > > >+Avoid Provocation: Refrain from posting inflammatory, controversial, or > > >intentionally provocative messages. Focus on constructive discussions. > > > > This is very subjective and completely unenforceable. > > While it’s true that provocation is subjective to some extent, this rule > targets intentional disruption, which is often clear. Patterns of behavior, > context, and community feedback guide enforcement. > > This rule doesn’t prohibit controversial opinions; it asks for them to be > expressed constructively, not to derail discussions or incite conflict. > > > > > > >+ > > >+No Trolling: Messages intended to provoke an emotional response or > > >disrupt the discussion are prohibited. > > > > Ditto. > > Trolling is often identifiable through repeated disruptive behavior, and > many online communities successfully enforce anti-trolling rules. Clear > examples and consistent enforcement make this rule practical. > > Ignoring trolling entirely leaves the community vulnerable to disruption, > which impacts everyone. This rule empowers moderators/CC to act while > fostering a healthier environment. > > > > > > >+ > > >+Professional Language: Use clear, professional, and inclusive language. > > >Avoid offensive or derogatory remarks, even in jest. > > > > That's fine *guideline*. It can't be a hard rule. > > This is indeed more of a guideline than a hard rule, and it’s framed as > such. However, a guideline doesn’t diminish its importance. Encouraging > professional language ensures inclusivity and clarity, reducing > misunderstandings and making the mailing list more welcoming. > > Rules set the tone for the group, and even if enforcement is flexible, > they guide expectations. > > > > > > >+ > > >+Constructive Criticism Only: Offer feedback in a constructive and > > >solution-oriented manner. Criticize ideas, not people. > > > > This is just dumb. Reviewers aren't typically paid. We can't require them > > to write constructive feedback every time (if ever). And the TC is already > > there to arbitrate technical disagreement. > > > > Again, this is a fine guideline but it can't be a hard rule. > > This rule doesn’t require every reviewer to provide detailed solutions; > it emphasizes the tone of feedback. Even brief reviews can avoid > unnecessarily harsh language or personal criticism. > > Constructive criticism fosters collaboration and improvement, while > unconstructive negativity deters participatio
Re: [FFmpeg-devel] [PATCH 6/6] ffv1enc_vulkan: switch to receive_packet
Le 24/11/2024 à 04:41, Lynne via ffmpeg-devel a écrit : On 11/23/24 23:10, Jerome Martinez wrote: Le 23/11/2024 à 20:58, Lynne via ffmpeg-devel a écrit : This allows the encoder to fully saturate all queues the GPU has, giving a good 10% in certain cases and resolutions. Using a RTX 4070: +50% (!!!) with 2K 10-bit content. +17% with 4K 16-bit content. Also the speed with 2K content is now 4x the speed of 4K content which is similar to the SW encoder (with similar count of slices) and which is the expected result, it seems that a bottleneck with smaller resolutions is removed. Unfortunatly, it has a drawback, a 6K5K content which was well handled without this patch is now having an immediate error: [vost#0:0/ffv1_vulkan @ 0x10467840] [enc:ffv1_vulkan @ 0x12c011c0] Error submitting video frame to the encoder [vost#0:0/ffv1_vulkan @ 0x10467840] [enc:ffv1_vulkan @ 0x12c011c0] Error encoding a frame: Cannot allocate memory [vost#0:0/ffv1_vulkan @ 0x10467840] Task finished with error code: -12 (Cannot allocate memory) [vost#0:0/ffv1_vulkan @ 0x10467840] Terminating thread with return code -12 (Cannot allocate memory) Which is a problem, the handling of 6K5K being good on the RTX 4070 (3x faster than a CPU at the same price) before this patch. Is it possible to keep the handling of bigger resolutions on such card while keeping the performance boost of this patch? To an extent. At high resolutions, -async_depth 0 (maximum) harms performance for higher resolution. I get the best results with it set to 2 or 3 for 6k content, on my odd setup. Increasing async_depth increases the amount of VRAM used, so that's the tradeoff. Automatically detecting it is difficult, as Vulkan doesn't give you metrics on how much free VRAM there is, so there's nothing we can do I am torn between a default having as much performance as possible and a default working for sure (a default value of 1 is OK for the 6K5K content on the RTX 4070, not 2). Surprisingly, default async_depth works on 4K (51 MiB) but async_depth 2 does not work on 6K5K (183 MiB), but I don't know what is the value of nb_queues. Maybe real use case is a user managing 6K5K with the biggest GPU available so it does not hurt much to have a default crashing with such big content. The encoder catches the allocation error and sends a nice message, wouldn't it possible to reduce automatically async_depth and retry instead of sending immediately the error, in the case async_depth is not provided, and error only if -async_depth 1 does not work? than to document it and hope users follow the instructions in case they run out of memory. If not possible to try automatically smaller values, is it possible to add "use -async_depth with a value smaller than (here the current value)" to the error message? The good news is that -async_depth 1 uses less VRAM than before this patch. Must of the VRAM used is from somewhere within Nvidia's black-box driver, as RADV uses 1/3rd of the VRAM at the same content and async_depth settings. Nothing we can do about this too. This also improves error resilience if an allocation fails, and properly cleans up after itself if it does. Looks like that this part does not work, still a freeze if an allocation fails. This is due to Nvidia's drivers. If you switch to using their GSP firmware, recovery is instant, pretty much. Beyond my knowledge, and it does not make things worse so not blocking. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/framecrc: add AVFMT_NODIMENSIONS flag
On Tue, Nov 19, 2024 at 10:47:30PM +0100, Marton Balint wrote: > Framecrc does not need frame dimensions to work correctly. > > Signed-off-by: Marton Balint > --- > libavformat/framecrcenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides 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 6/6] ffv1enc_vulkan: switch to receive_packet
On 11/24/24 16:51, Jerome Martinez wrote: Le 24/11/2024 à 04:41, Lynne via ffmpeg-devel a écrit : On 11/23/24 23:10, Jerome Martinez wrote: Le 23/11/2024 à 20:58, Lynne via ffmpeg-devel a écrit : This allows the encoder to fully saturate all queues the GPU has, giving a good 10% in certain cases and resolutions. Using a RTX 4070: +50% (!!!) with 2K 10-bit content. +17% with 4K 16-bit content. Also the speed with 2K content is now 4x the speed of 4K content which is similar to the SW encoder (with similar count of slices) and which is the expected result, it seems that a bottleneck with smaller resolutions is removed. Unfortunatly, it has a drawback, a 6K5K content which was well handled without this patch is now having an immediate error: [vost#0:0/ffv1_vulkan @ 0x10467840] [enc:ffv1_vulkan @ 0x12c011c0] Error submitting video frame to the encoder [vost#0:0/ffv1_vulkan @ 0x10467840] [enc:ffv1_vulkan @ 0x12c011c0] Error encoding a frame: Cannot allocate memory [vost#0:0/ffv1_vulkan @ 0x10467840] Task finished with error code: -12 (Cannot allocate memory) [vost#0:0/ffv1_vulkan @ 0x10467840] Terminating thread with return code -12 (Cannot allocate memory) Which is a problem, the handling of 6K5K being good on the RTX 4070 (3x faster than a CPU at the same price) before this patch. Is it possible to keep the handling of bigger resolutions on such card while keeping the performance boost of this patch? To an extent. At high resolutions, -async_depth 0 (maximum) harms performance for higher resolution. I get the best results with it set to 2 or 3 for 6k content, on my odd setup. Increasing async_depth increases the amount of VRAM used, so that's the tradeoff. Automatically detecting it is difficult, as Vulkan doesn't give you metrics on how much free VRAM there is, so there's nothing we can do I am torn between a default having as much performance as possible and a default working for sure (a default value of 1 is OK for the 6K5K content on the RTX 4070, not 2). Surprisingly, default async_depth works on 4K (51 MiB) but async_depth 2 does not work on 6K5K (183 MiB), but I don't know what is the value of nb_queues. Maybe real use case is a user managing 6K5K with the biggest GPU available so it does not hurt much to have a default crashing with such big content. The encoder catches the allocation error and sends a nice message, wouldn't it possible to reduce automatically async_depth and retry instead of sending immediately the error, in the case async_depth is not provided, and error only if -async_depth 1 does not work? than to document it and hope users follow the instructions in case they run out of memory. If not possible to try automatically smaller values, is it possible to add "use -async_depth with a value smaller than (here the current value)" to the error message? The good news is that -async_depth 1 uses less VRAM than before this patch. Must of the VRAM used is from somewhere within Nvidia's black-box driver, as RADV uses 1/3rd of the VRAM at the same content and async_depth settings. Nothing we can do about this too. This also improves error resilience if an allocation fails, and properly cleans up after itself if it does. Looks like that this part does not work, still a freeze if an allocation fails. This is due to Nvidia's drivers. If you switch to using their GSP firmware, recovery is instant, pretty much. Beyond my knowledge, and it does not make things worse so not blocking. I've added VRAM checking to the patch. It should work in most cases. It autodetects the async_depth value based on both the VRAM and the size needed for one frame. Except for when VRAM is already full. We cannot detect currently used VRAM, but its a good thing no one will want to run anything else anyway. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avfilter/scale_vt: implement frame crop
> On Nov 21, 2024, at 00:40, Koushik Dutta wrote:
>
> Is anyone reviewing videotoolbox or qsv filters? The scale_cuda
> version of this patch was merged.
>
> On Sat, Oct 19, 2024 at 10:58 PM Koushik Dutta wrote:
>>
>> The crop filter has no effect on scale_vt:
>>
>> -vf crop=100:100,scale_vt=300x300
>>
>> Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_*
>> properties,
>> as seen in the implementation vf_crop.c.
>>
>> The current workaround is to hwdownload the full frame
>> and perform the crop on CPU.
>>
>> Signed-off-by: Koushik Dutta
>> ---
>> libavfilter/vf_scale_vt.c | 50 +++
>> 1 file changed, 50 insertions(+)
>>
>> diff --git a/libavfilter/vf_scale_vt.c b/libavfilter/vf_scale_vt.c
>> index 05f4e7b797..3da46a6cd5 100644
>> --- a/libavfilter/vf_scale_vt.c
>> +++ b/libavfilter/vf_scale_vt.c
>> @@ -109,6 +109,8 @@ static av_cold int scale_vt_init(AVFilterContext *avctx)
>> VTSessionSetProperty(s->transfer,
>> kVTPixelTransferPropertyKey_DestinationYCbCrMatrix, value);
>> }
>>
>> +VTSessionSetProperty(s->transfer,
>> kVTPixelTransferPropertyKey_ScalingMode,
>> kVTScalingMode_CropSourceToCleanAperture);
>> +
>> return 0;
>> }
>>
>> @@ -132,6 +134,18 @@ static int scale_vt_filter_frame(AVFilterLink *link,
>> AVFrame *in)
>> CVPixelBufferRef src;
>> CVPixelBufferRef dst;
>>
>> +int left;
>> +int top;
>> +int width;
>> +int height;
>> +CFNumberRef crop_width_num;
>> +CFNumberRef crop_height_num;
>> +CFNumberRef crop_offset_left_num;
>> +CFNumberRef crop_offset_top_num;
>> +const void *clean_aperture_keys[4];
>> +const void *source_clean_aperture_values[4];
>> +CFDictionaryRef source_clean_aperture;
>> +
>> AVFrame *out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
>> if (!out) {
>> ret = AVERROR(ENOMEM);
>> @@ -153,8 +167,43 @@ static int scale_vt_filter_frame(AVFilterLink *link,
>> AVFrame *in)
>> if (s->colour_matrix != AVCOL_SPC_UNSPECIFIED)
>> out->colorspace = s->colour_matrix;
>>
>> +width = (in->width - in->crop_right) - in->crop_left;
>> +height = (in->height - in->crop_bottom) - in->crop_top;
>> +// The crop offsets are relative to the center of the frame.
>> +// the crop width and crop height are relative to the center of the
>> crop rect, not top left as normal.
>> +left = in->crop_left - in->width / 2 + width / 2;
>> +top = in->crop_top - in->height / 2 + height / 2;
>> +crop_width_num = CFNumberCreate(kCFAllocatorDefault, kCFNumberIntType,
>> &width);
>> +crop_height_num = CFNumberCreate(kCFAllocatorDefault, kCFNumberIntType,
>> &height);
>> +crop_offset_left_num = CFNumberCreate(kCFAllocatorDefault,
>> kCFNumberIntType, &left);
>> +crop_offset_top_num = CFNumberCreate(kCFAllocatorDefault,
>> kCFNumberIntType, &top);
>> +
>> +clean_aperture_keys[0] = kCVImageBufferCleanApertureWidthKey;
>> +clean_aperture_keys[1] = kCVImageBufferCleanApertureHeightKey;
>> +clean_aperture_keys[2] = kCVImageBufferCleanApertureHorizontalOffsetKey;
>> +clean_aperture_keys[3] = kCVImageBufferCleanApertureVerticalOffsetKey;
>> +
>> +source_clean_aperture_values[0] = crop_width_num;
>> +source_clean_aperture_values[1] = crop_height_num;
>> +source_clean_aperture_values[2] = crop_offset_left_num;
>> +source_clean_aperture_values[3] = crop_offset_top_num;
>> +
>> +source_clean_aperture = CFDictionaryCreate(kCFAllocatorDefault,
>> +clean_aperture_keys,
>> +
>> source_clean_aperture_values,
>> +4,
>> +
>> &kCFTypeDictionaryKeyCallBacks,
>> +
>> &kCFTypeDictionaryValueCallBacks);
>> +
>> +CFRelease(crop_width_num);
>> +CFRelease(crop_height_num);
>> +CFRelease(crop_offset_left_num);
>> +CFRelease(crop_offset_top_num);
>> +
>> src = (CVPixelBufferRef)in->data[3];
>> dst = (CVPixelBufferRef)out->data[3];
>> +CVBufferSetAttachment(src, kCVImageBufferCleanApertureKey,
>> + source_clean_aperture,
>> kCVAttachmentMode_ShouldPropagate);
After applied crop, the output frame still holding crop info which are copied
from input frame
via
ret = av_frame_copy_props(out, in);
The output frame crop info should be reset.
>> ret = VTPixelTransferSessionTransferImage(s->transfer, src, dst);
>> if (ret != noErr) {
>> av_log(ctx, AV_LOG_ERROR, "transfer image failed, %d\n", ret);
>> @@ -162,6 +211,7 @@ static int scale_vt_filter_frame(AVFilterLink *link,
>> AVFrame *in)
>> goto fail;
>> }
>>
>> +CFRelease(source_clean_aperture);
Should be released early in case of error which leading to leak (the goto fail).
>> av_fra
Re: [FFmpeg-devel] Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
On 11/24/2024 4:09 PM, Michael Niedermayer wrote: Now reality is, Paul (the 2nd most active developer of all time) was bullied out of FFmpeg. In private mail he spoke about being treated like a slave. Huh?? By whom? OpenPGP_signature.asc Description: OpenPGP digital 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] Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists
Hi Kieran I think this is off topic for this thread, but i will reply with adjusted Subject and as a new thread On Sun, Nov 24, 2024 at 02:58:29PM +, Kieran Kunhya via ffmpeg-devel wrote: > On Sun, Nov 24, 2024 at 12:23 PM Michael Niedermayer [...] > "In the email at the URL you provided > (https://ffmpeg.org//pipermail/ffmpeg-devel/2015-July/176489.html), > Michael Niedermayer states: > > Root admin roles: > I will keep the server root admin role until there is an agreement who > should have it that is acceptable for the ffmpeg and libav > communities. > This confirms that Michael Niedermayer agrees to give root access of > the FFmpeg project to whomever both the FFmpeg and Libav communities > agree should have it." This is a very long time ago. And at the time i believed everyone would join and work together and that all hostilities where over. Yes i guess i was naive. (Or maybe i was thinking something else, its 9 years ago, who knows) Now reality is, Paul (the 2nd most active developer of all time) was bullied out of FFmpeg. In private mail he spoke about being treated like a slave. And in the last 3 weeks, alot of hostilities have hit me, so i kind of feel a little like Paul maybe felt. Then theres Nicolas who people kept making snide remarks on IRC and who also reduced in activity alot. Theres Thilo who besides spending time in hospital a year or two ago was accused of all kinds of things, in some recent mail the author himself used the phrase "I accept this may be slander" The hostilities even prior to this caused thilo to avoid posting to the mailing list. (for which he then was accused even more) There are multiple people who where once at the VDD and do not want to go there again. And ill be clear here i keep telling everyone, "please go to vdd" There where also serious accusations against some people in private (I cant make these public, i was mostly just on the CC) And there where many more people who left after some collision with other community members over the years. (I cannot name them because they never spoke up in public and in some cases iam only 99% sure of the reasons) Also you might wonder why carl is not employed by FFlabs, as he was very important to FFmpeg, kept track of every bug on the bug tracker and so on. Yes iam also curious, it was requested by multiple people to FFlabs to hire him. less than 2 weeks ago the founder was insulted like this: "Fabrice's control of ffmpeg.org and French trademark, despite not havign contributed in 20 years, purely for ego reasons mean we can never move to a truly community run set or project infra." And we can probably go on and on. On top of this i would not be surprised if other people have similar stories from yet others they spoke with. So, the project community is not healthy. My original intend was to at some point hand power over to someone choosen by a healthy community of people who respect each other and mostly pull on the same string in the same direction. That is i envissioned a community which grew and i become unneeded and would simply pass powers on to someone from that community. Similar to fabrice leaving once ffmpeg had grown enough to self sustain. (and passing power over to me) But what i see is infighting, i see people permanently leaving because of hostilities. I see slander, i see trolling, i see hatred, I see people playing social tricks to screw others over. I see people finger pointing at others who are trying to solve problems instead of supporting them. Also we now have the commercial interrests like FFlabs. Which are important to pay developers. But i also am quite concerned that power over FFmpeg could fall into the hands of some commercial company. FFmpeg should stay a community led project and i will not hand power over to commercial entities. (this may have been misinterpreted in some other thread) And i hear almost everyone at VDD are old man. FFmpeg cannot be run by just old man. There is a need for young people and need for new ideas. On top of that, iam really not an "active root admin", work is done by timo and raz mostly. And they do it well and are professional. Now the community seems to wants to add someone from "them" to root. And i dont know what that even means. And that exactly reflects back to what i was writing above. This sort of split where theres 2 sides. You know Timo and Raz are part of the community Timo is a GA member, he has 27 commits this year and a commit this months. He is listed 8 times in MAINTAINERS. I also have like 29 thousand commits in FFmpeg. It seems each VDD event re-enforces the community feeling amongth the people who meet and at the same time seperation to everyone who does not go there. Then the people come and demand things are handed over to them. Last year the domain name, this year root access. Not realizing that the domain is held by the founder who belongs to the community, not realizing most of the root admins are active members of the
Re: [FFmpeg-devel] [PATCH] avformat: add AV1 RTP depacketizer and packetizer
Hi Anton (sorry for the PM),
Your mailer mangled the newlines in the patch. Consider a different
mailer or sending it as an attachment.
Thanks for the info, had sent it with Thunderbird. Resending it as
attachment.
--
Chris--- Begin Message ---
Add RTP packetizer and depacketizer according to (most)
of the official AV1 RTP specification. This enables
streaming via RTSP between ffmpeg and ffmpeg and has
also been tested to work with AV1 RTSP streams via
GStreamer.
It also adds the required SDP additions.
Signed-off-by: Chris Hodges
---
libavformat/Makefile | 2 +
libavformat/demux.c | 1 +
libavformat/rtp_av1.h| 128 +++
libavformat/rtpdec.c | 1 +
libavformat/rtpdec_av1.c | 417 +++
libavformat/rtpdec_formats.h | 1 +
libavformat/rtpenc.c | 4 +
libavformat/rtpenc.h | 1 +
libavformat/rtpenc_av1.c | 305 +
libavformat/sdp.c| 30 +++
10 files changed, 890 insertions(+)
create mode 100644 libavformat/rtp_av1.h
create mode 100644 libavformat/rtpdec_av1.c
create mode 100644 libavformat/rtpenc_av1.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 7ca68a7036..1200668a2f 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -47,6 +47,7 @@ OBJS-$(CONFIG_RTPDEC)+= rdt.o
\
rtpdec_ac3.o\
rtpdec_amr.o\
rtpdec_asf.o\
+rtpdec_av1.o\
rtpdec_dv.o \
rtpdec_g726.o \
rtpdec_h261.o \
@@ -515,6 +516,7 @@ OBJS-$(CONFIG_RTP_MUXER) += rtp.o \
rtpenc_aac.o \
rtpenc_latm.o\
rtpenc_amr.o \
+rtpenc_av1.o \
rtpenc_h261.o\
rtpenc_h263.o\
rtpenc_h263_rfc2190.o \
diff --git a/libavformat/demux.c b/libavformat/demux.c
index cba1f2e4df..8357a3bff1 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -111,6 +111,7 @@ static int set_codec_from_probe_data(AVFormatContext *s,
AVStream *st,
{ "aac",AV_CODEC_ID_AAC, AVMEDIA_TYPE_AUDIO},
{ "ac3",AV_CODEC_ID_AC3, AVMEDIA_TYPE_AUDIO},
{ "aptx", AV_CODEC_ID_APTX, AVMEDIA_TYPE_AUDIO},
+{ "av1",AV_CODEC_ID_AV1, AVMEDIA_TYPE_VIDEO},
{ "dts",AV_CODEC_ID_DTS, AVMEDIA_TYPE_AUDIO},
{ "dvbsub", AV_CODEC_ID_DVB_SUBTITLE, AVMEDIA_TYPE_SUBTITLE },
{ "dvbtxt", AV_CODEC_ID_DVB_TELETEXT, AVMEDIA_TYPE_SUBTITLE },
diff --git a/libavformat/rtp_av1.h b/libavformat/rtp_av1.h
new file mode 100644
index 00..a353fc0e4e
--- /dev/null
+++ b/libavformat/rtp_av1.h
@@ -0,0 +1,128 @@
+/*
+ * Shared definitions and helper functions for
+ * AV1 (de)packetization.
+ * Copyright (c) 2024 Axis Communications
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * @brief shared defines and functions for AV1 RTP dec/enc
+ * @author Chris Hodges
+ */
+
+#ifndef AVFORMAT_RTP_AV1_H
+#define AVFORMAT_RTP_AV1_H
+
+// define a couple of flags and bit fields
+#define AV1B_OBU_FORBIDDEN 7
+#define AV1F_OBU_FORBIDDEN (1u << AV1B_OBU_FORBIDDEN)
+#define AV1S_OBU_TYPE 3
+#define AV1M_OBU_TYPE 15
+#define AV1B_OBU_EXTENSION_FLAG 2
+#define AV1F_OBU_EXTENSION_FLAG (1u << AV1B_OBU_EXTENSION_FLAG)
+#define AV1B_OBU_HAS_SIZE_FIELD 1
+#define AV1F_OBU_HAS_SIZE_FIELD (1u << AV1B_OBU_HAS_SIZE_FIELD)
+#define AV1B_OBU_RESERVED_1BIT 0
+#define AV1F_OBU_RESERVED_1BIT (1u << AV1B_OBU_RESERVED_1BIT)
+
+#define AV1
