Re: [FFmpeg-devel] [PATCH 02/11] avutil/side_data: allow the addition of internal fields to AVSideDataDescriptor
James Almer:
> Will be useful in the following commits to add fields that don't need to be
> exposed.
>
> Signed-off-by: James Almer
> ---
> libavutil/side_data.c | 70 +++
> 1 file changed, 37 insertions(+), 33 deletions(-)
>
> diff --git a/libavutil/side_data.c b/libavutil/side_data.c
> index 17965f2d3c..8c57fd838a 100644
> --- a/libavutil/side_data.c
> +++ b/libavutil/side_data.c
> @@ -24,44 +24,48 @@
> #include "mem.h"
> #include "side_data.h"
>
> -static const AVSideDataDescriptor sd_props[] = {
> -[AV_FRAME_DATA_PANSCAN] = { "AVPanScan",
>AV_SIDE_DATA_PROP_SIZE_DEPENDENT },
> -[AV_FRAME_DATA_A53_CC] = { "ATSC A53 Part 4 Closed
> Captions" },
> -[AV_FRAME_DATA_MATRIXENCODING] = { "AVMatrixEncoding",
>AV_SIDE_DATA_PROP_CHANNEL_DEPENDENT },
> -[AV_FRAME_DATA_DOWNMIX_INFO]= { "Metadata relevant to a
> downmix procedure", AV_SIDE_DATA_PROP_CHANNEL_DEPENDENT },
> -[AV_FRAME_DATA_AFD] = { "Active format
> description" },
> -[AV_FRAME_DATA_MOTION_VECTORS] = { "Motion vectors",
>AV_SIDE_DATA_PROP_SIZE_DEPENDENT },
> -[AV_FRAME_DATA_SKIP_SAMPLES]= { "Skip samples" },
> -[AV_FRAME_DATA_GOP_TIMECODE]= { "GOP timecode" },
> -[AV_FRAME_DATA_S12M_TIMECODE] = { "SMPTE 12-1 timecode" },
> -[AV_FRAME_DATA_DYNAMIC_HDR_PLUS]= { "HDR Dynamic Metadata
> SMPTE2094-40 (HDR10+)", AV_SIDE_DATA_PROP_COLOR_DEPENDENT },
> -[AV_FRAME_DATA_DYNAMIC_HDR_VIVID] = { "HDR Dynamic Metadata
> CUVA 005.1 2021 (Vivid)", AV_SIDE_DATA_PROP_COLOR_DEPENDENT },
> -[AV_FRAME_DATA_REGIONS_OF_INTEREST] = { "Regions Of Interest",
>AV_SIDE_DATA_PROP_SIZE_DEPENDENT },
> -[AV_FRAME_DATA_VIDEO_ENC_PARAMS]= { "Video encoding
> parameters" },
> -[AV_FRAME_DATA_FILM_GRAIN_PARAMS] = { "Film grain parameters"
> },
> -[AV_FRAME_DATA_DETECTION_BBOXES]= { "Bounding boxes for
> object detection and classification", AV_SIDE_DATA_PROP_SIZE_DEPENDENT },
> -[AV_FRAME_DATA_DOVI_RPU_BUFFER] = { "Dolby Vision RPU Data",
>AV_SIDE_DATA_PROP_COLOR_DEPENDENT },
> -[AV_FRAME_DATA_DOVI_METADATA] = { "Dolby Vision Metadata",
>AV_SIDE_DATA_PROP_COLOR_DEPENDENT },
> -[AV_FRAME_DATA_LCEVC] = { "LCEVC NAL data",
>AV_SIDE_DATA_PROP_SIZE_DEPENDENT },
> -[AV_FRAME_DATA_VIEW_ID] = { "View ID" },
> -[AV_FRAME_DATA_STEREO3D]= { "Stereo 3D",
>AV_SIDE_DATA_PROP_GLOBAL },
> -[AV_FRAME_DATA_REPLAYGAIN] = { "AVReplayGain",
>AV_SIDE_DATA_PROP_GLOBAL },
> -[AV_FRAME_DATA_DISPLAYMATRIX] = { "3x3 displaymatrix",
>AV_SIDE_DATA_PROP_GLOBAL },
> -[AV_FRAME_DATA_AUDIO_SERVICE_TYPE] = { "Audio service type",
>AV_SIDE_DATA_PROP_GLOBAL },
> -[AV_FRAME_DATA_MASTERING_DISPLAY_METADATA] = { "Mastering display
> metadata", AV_SIDE_DATA_PROP_GLOBAL |
> AV_SIDE_DATA_PROP_COLOR_DEPENDENT },
> -[AV_FRAME_DATA_CONTENT_LIGHT_LEVEL] = { "Content light level
> metadata", AV_SIDE_DATA_PROP_GLOBAL |
> AV_SIDE_DATA_PROP_COLOR_DEPENDENT },
> -[AV_FRAME_DATA_AMBIENT_VIEWING_ENVIRONMENT] = { "Ambient viewing
> environment", AV_SIDE_DATA_PROP_GLOBAL },
> -[AV_FRAME_DATA_SPHERICAL] = { "Spherical Mapping",
>AV_SIDE_DATA_PROP_GLOBAL |
> AV_SIDE_DATA_PROP_SIZE_DEPENDENT },
> -[AV_FRAME_DATA_ICC_PROFILE] = { "ICC profile",
>AV_SIDE_DATA_PROP_GLOBAL |
> AV_SIDE_DATA_PROP_COLOR_DEPENDENT },
> -[AV_FRAME_DATA_SEI_UNREGISTERED]= { "H.26[45] User Data
> Unregistered SEI message", AV_SIDE_DATA_PROP_MULTI },
> -[AV_FRAME_DATA_VIDEO_HINT] = { "Encoding video hint",
>AV_SIDE_DATA_PROP_SIZE_DEPENDENT },
> +typedef struct FFSideDataDescriptor {
> +AVSideDataDescriptor p;
> +} FFSideDataDescriptor;
> +
> +static const FFSideDataDescriptor sd_props[] = {
> +[AV_FRAME_DATA_PANSCAN] = { .p = { "AVPanScan",
> AV_SIDE_DATA_PROP_SIZE_DEPENDENT } },
> +[AV_FRAME_DATA_A53_CC] = { .p = { "ATSC A53 Part 4
> Closed Captions" } },
> +[AV_FRAME_DATA_MATRIXENCODING] = { .p = {
> "AVMatrixEncoding",
> AV_SIDE_DATA_PROP_CHANNEL_DEPENDENT } },
> +[
Re: [FFmpeg-devel] [PATCH] avfilter/vsrc_testsrc: add support for semi planar formats to yuvtestsrc
On Tue, Mar 04, 2025 at 06:47:28PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavfilter/drawutils.c| 4 > libavfilter/vsrc_testsrc.c | 19 +++ > 2 files changed, 23 insertions(+) This appears to fail here: TESTfilter-yuvtestsrc-xv36 --- ./tests/ref/fate/filter-yuvtestsrc-xv36 2025-03-03 02:22:06.094332746 +0100 +++ tests/data/fate/filter-yuvtestsrc-xv36 2025-03-08 02:23:10.325029560 +0100 @@ -3,8 +3,8 @@ #codec_id 0: rawvideo #dimensions 0: 320x240 #sar 0: 1/1 -0, 0, 0,1, 614400, 0xdadee6db -0, 1, 1,1, 614400, 0xdadee6db -0, 2, 2,1, 614400, 0xdadee6db -0, 3, 3,1, 614400, 0xdadee6db -0, 4, 4,1, 614400, 0xdadee6db +0, 0, 0,1, 614400, 0x071e35fc +0, 1, 1,1, 614400, 0x071e35fc +0, 2, 2,1, 614400, 0x071e35fc +0, 3, 3,1, 614400, 0x071e35fc +0, 4, 4,1, 614400, 0x071e35fc Test filter-yuvtestsrc-xv36 failed. Look at tests/data/fate/filter-yuvtestsrc-xv36.err for details. make: *** [tests/Makefile:311: fate-filter-yuvtestsrc-xv36] Error 1 (thats just ubuntu x86-64) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein 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 v2] lsws/ppc/yuv2rgb_altivec: Fix build in non-VSX environments with Clang
On Wed, Mar 5, 2025 at 4:17 AM Ramiro Polla wrote: > On Wed, Mar 5, 2025 at 2:24 AM Brad Smith > wrote: > > On 2023-08-23 4:52 p.m., Michael Niedermayer wrote: > > > On Fri, Aug 18, 2023 at 10:14:04PM -0400, Brad Smith wrote: > > >> lsws/ppc/yuv2rgb_altivec: Fix build in non-VSX environments with Clang > > >> > > >> Add a check for the existence of the vec_xl() function. Clang provides > > >> the function even with VSX not enabled. > > >> > > >> v2: test for function if AltiVec is enabled instead of with AltiVec and > > >> without VSX > > >> --- > > >> configure| 8 > > >> libswscale/ppc/yuv2rgb_altivec.c | 4 ++-- > > >> 2 files changed, 10 insertions(+), 2 deletions(-) > > > Has this been tested on an affected platform ? > > > I mean the function is provided but does it also work ? > > > > This has been in the FreeBSD / OpenBSD ports for years. So to a certain > > extent yes. Anyway, I didn't have access to my test VM for quite some > > time but I do now and ran the various tests with FATE and did not see > > any issues. > > Build doesn't seem to fail anymore, but that's probably because of the > #if 0 from b9eaf6e05c2ca16d94869e0263236dbdac752400. > > Could you please send a rebased patch? I tested on Sean's G5 and this patch fixed the build issue with clang, so I pushed it. The code that uses vec_xl() is still under #if 0 though. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/4] avutil/log: Add callback for context prefix formatting
On Fri, Mar 7, 2025 at 6:23 PM Soft Works wrote: > > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Nicolas George > > Sent: Freitag, 7. März 2025 10:44 > > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH v3 1/4] avutil/log: Add callback for > > context prefix formatting > > > > softworkz (HE12025-03-06): > > > From: softworkz > > > > > > also adds a log flag AV_LOG_PRINT_MEMADDRESSES, which is meant to > > > control prefix formatting. The actual formatting has to be performed > > > by the consuming application which needs to provide a formatting > > > callback via av_log_set_formatprefix_callback. > > > > Still more global state in the libraries. > > You mean the callback? > Yes. You are also adding a new callback thats used from within a callback, if someone uses av_log_set_callback then it might just not get used. So instead, why not provide a different implementation of the log callback and use the existing av_log_set_callback function? Then no library changes are needed at all. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] The Concept for the CC Installment is broken by Design
You can criticize the CC structure all you want, but I will absolutely not accept thinly veiled personal attacks, including being called a child. Your email is condescending and dismissive, completely disregarding the time and effort that volunteers like myself have put into this work. I did not volunteer to this role because I was "keen and crazy enough to" but because I wanted to actually try and make a difference. Whether or not I have, that is for the people to decide. But I will not have it being publicly ridiculed and called a "child". I have been nothing but polite to you and others even if we have disagreements. Frankly, beyond this example, you have shown to be generally rude, gatekeeping to others, and are unpleasant to engage with. You also seem unaware that not all CC matters are handled publicly. I have no further comment for you. Sincerely, Marth64, without the CC hat. ___ 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] avutil/log: Replace addresses in log output with simple ids
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Donnerstag, 6. März 2025 11:09 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] avutil/log: Replace addresses in log > output with simple ids > > Soft Works (HE12025-03-05): > > Sorry. So - seriously: what would be your recipe then? > > I see not just a little of non-trivial code for a very minor feature, Whether trivial or non-trivial, it's definitely just very little code. > that might be a hint that it would be best to let it go. This is not a helpful comment. I'm trying hard to be friendly and productive and I think it's not asked too much to at least try doing as well. > Also, if somebody is debugging a program using the libraries, the > pointers are relevant for that program. For that reason, I think the > change is a bad idea in the library. It's a valid point, I have acknowledged that already and added a log flag in V2 which allows to control it. As a further compromise, we could also enable it by default in case when DEBUG is defined, how about that? Generally, debugging is important without doubt, but it doesn't mean that Millions of users need to see something in the output which is only ever relevant to developers - that's the premise of this patchset. And even as a developer, those addresses are interesting only in a very narrow range of cases. These addresses have been a major pain point for myself and many others over years when comparing logfiles. Even the best diffing algorithms are getting confused by these addresses and I think this patchset provides a huge benefit for both, users and developers in the future, making their work a lot easier. > On the other hand, you could do that change in the fftools. The point > about pointers being relevant does not apply for them, and they can have > as much global state as they want. You know that it's not easily possible to do it from within fftools because all libs are logging directly to avutil, so it's not quite clear to me what you are up to. Do you mean something like a int(* av_log_format_prefix)(...) callback that fftools could register to? Thanks sw ___ 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] The Concept for the CC Installment is broken by Design
> -Original Message- > From: ffmpeg-devel On Behalf Of > Marth64 > Sent: Samstag, 8. März 2025 01:22 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] The Concept for the CC Installment is broken > by Design > > > I don't have any reason to think or say anything bad about you or > other members of the CC. > > Then I apologize if I misunderstood. I have no issue hearing criticism > of our structures but the comparison to kindergartners came off the > wrong way. > ___ Hi Marth64, thanks and nevermind. I truly don't want to accuse anybody of anything and at the very least the members of the CC. I know about your intentions to improve the community and totally appreciate that. I also have no doubts that you have done some good things which haven't become public. It's important to have community members like you who are trying to keep people together. My criticism is solely on the structure of the CC operations, which is based on many observations I had made during the past months. You - and the members of the CC - are taking your perceived integrity at stakes, solely for taking that role, not even due to any action that was taken. And when you take any (public) actions, some will always think it was wrong or will be dissatisfied. It's really a tough position to fulfil. My overall impression is that the sole existence of the CC in the current form is more dividing than unifying, no matter what the CC does - and even when it would to nothing at all, the distrust that has emerged wasn't based on anything the CC has done, just about what it might be doing. Similar, the disregarding or CC members like being from this or that "group" or "party", like it had been alluded from various sides recently. I wanted to illustrate the mechanism of and effects of the CC concept and how it can hardly fulfill the intended purposes in a beneficial way (in total sum) - no matter how good and faithful and passionate the people are who are taking those roles. Or let me put it this way: The CC structure is too much overshadowing the good things you are really intending to do. The elementary school comparison is intended to illustrate which kind of system we have: making complaints privately and expecting the target being sanctioned publicly - that's not a healthy pattern. Btw. if you would really want to take it literally, you would be a teacher, not a child, but again, it was really not meant to call anybody a child or anything else, it was meant to make people think about the current system and how much sense it makes for this community. Best wishes sw ___ 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] libavfilter: guard against ff_draw_init/ff_draw_init2 failures
On Tue, Mar 04, 2025 at 10:17:25AM -0800, Nil Fons Miret via ffmpeg-devel wrote: > I'm not sure I understand what documentation you'd like to add. The > behavior of ff_draw_init* is documented in drawutils.h, would you like > me to add a comment where these functions are called with no risk of > failing (as far as I can see, only qrencode.c)? My worry is that such > a comment can easily become outdated. In any case, once I understand > your request I'm happy to add any more documentation. yes, if you add a check that is unreachable and that is intentional it should receive a comment. Otherwise it can confuse the reader, also it can be removed when someone realizes it is unreachable thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives. -- Abba Eban signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/4] avcodec/vp8: Fix wrong #endif comment
Patches attached
- Andreas
From 54e27b588e18fdfe277a77b0f385cb02731022b9 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Thu, 6 Mar 2025 17:56:08 +0100
Subject: [PATCH 1/4] avcodec/vp8: Fix wrong #endif comment
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp8.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 3651688c10..6337fa173b 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -2984,4 +2984,4 @@ const FFCodec ff_vp8_decoder = {
NULL
},
};
-#endif /* CONFIG_VP7_DECODER */
+#endif /* CONFIG_VP8_DECODER */
--
2.45.2
From 2360e180fabb2dc8577018283c8b3f5f46425a51 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Thu, 6 Mar 2025 18:00:28 +0100
Subject: [PATCH 2/4] avcodec/vp8: Move codec-specific init code out of common
init
While just at it, also move the init functions inside
the #if CONFIG_VP?_DECODER (to avoid linking failures).
While just at it, also declare these init functions
as av_cold and uninline the remaining common init function.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp8.c | 48
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 6337fa173b..be8dbde91e 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -2858,8 +2858,7 @@ av_cold int ff_vp8_decode_free(AVCodecContext *avctx)
return 0;
}
-static av_always_inline
-int vp78_decode_init(AVCodecContext *avctx, int is_vp7)
+static av_cold void vp78_decode_init(AVCodecContext *avctx)
{
VP8Context *s = avctx->priv_data;
@@ -2870,37 +2869,25 @@ int vp78_decode_init(AVCodecContext *avctx, int is_vp7)
ff_videodsp_init(&s->vdsp, 8);
ff_vp78dsp_init(&s->vp8dsp);
-if (CONFIG_VP7_DECODER && is_vp7) {
-ff_h264_pred_init(&s->hpc, AV_CODEC_ID_VP7, 8, 1);
-ff_vp7dsp_init(&s->vp8dsp);
-s->decode_mb_row_no_filter = vp7_decode_mb_row_no_filter;
-s->filter_mb_row = vp7_filter_mb_row;
-} else if (CONFIG_VP8_DECODER && !is_vp7) {
-ff_h264_pred_init(&s->hpc, AV_CODEC_ID_VP8, 8, 1);
-ff_vp8dsp_init(&s->vp8dsp);
-s->decode_mb_row_no_filter = vp8_decode_mb_row_no_filter;
-s->filter_mb_row = vp8_filter_mb_row;
-}
/* does not change for VP8 */
memcpy(s->prob[0].scan, ff_zigzag_scan, sizeof(s->prob[0].scan));
-
-return 0;
}
-#if CONFIG_VP7_DECODER
-static int vp7_decode_init(AVCodecContext *avctx)
-{
-return vp78_decode_init(avctx, IS_VP7);
-}
-#endif /* CONFIG_VP7_DECODER */
-
+#if CONFIG_VP8_DECODER
av_cold int ff_vp8_decode_init(AVCodecContext *avctx)
{
-return vp78_decode_init(avctx, IS_VP8);
+VP8Context *s = avctx->priv_data;
+
+vp78_decode_init(avctx);
+ff_h264_pred_init(&s->hpc, AV_CODEC_ID_VP8, 8, 1);
+ff_vp8dsp_init(&s->vp8dsp);
+s->decode_mb_row_no_filter = vp8_decode_mb_row_no_filter;
+s->filter_mb_row = vp8_filter_mb_row;
+
+return 0;
}
-#if CONFIG_VP8_DECODER
#if HAVE_THREADS
static void vp8_replace_frame(VP8Frame *dst, const VP8Frame *src)
{
@@ -2944,6 +2931,19 @@ static int vp8_decode_update_thread_context(AVCodecContext *dst,
#endif /* CONFIG_VP8_DECODER */
#if CONFIG_VP7_DECODER
+av_cold static int vp7_decode_init(AVCodecContext *avctx)
+{
+VP8Context *s = avctx->priv_data;
+
+vp78_decode_init(avctx);
+ff_h264_pred_init(&s->hpc, AV_CODEC_ID_VP7, 8, 1);
+ff_vp7dsp_init(&s->vp8dsp);
+s->decode_mb_row_no_filter = vp7_decode_mb_row_no_filter;
+s->filter_mb_row = vp7_filter_mb_row;
+
+return 0;
+}
+
const FFCodec ff_vp7_decoder = {
.p.name= "vp7",
CODEC_LONG_NAME("On2 VP7"),
--
2.45.2
From 538cb0a9226066d4fe13ef07aad70e6f14273939 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Thu, 6 Mar 2025 18:16:50 +0100
Subject: [PATCH 3/4] avcodec/vp8: Move VPx specific functions inside #if
CONFIG_VPx block
where appropriate. Avoids including ff_vp8_decode_frame()
when the VP8 decoder is disabled.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp8.c | 74 +++-
1 file changed, 36 insertions(+), 38 deletions(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index be8dbde91e..77f7b4d4df 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -2512,18 +2512,6 @@ static av_always_inline int decode_mb_row_no_filter(AVCodecContext *avctx, void
return 0;
}
-static int vp7_decode_mb_row_no_filter(AVCodecContext *avctx, void *tdata,
-int jobnr, int threadnr)
-{
-return decode_mb_row_no_filter(avctx, tdata, jobnr, threadnr, 1);
-}
-
-static int vp8_decode_mb_row_no_filter(AVCodecContext *avctx, void *tdata,
-int jobnr, int threadnr)
-{
-return decode_mb_row_no_filter(avctx, tdata, jobnr, threadnr,
Re: [FFmpeg-devel] [PATCH v3 1/4] avutil/log: Add callback for context prefix formatting
softworkz (HE12025-03-06): > From: softworkz > > also adds a log flag AV_LOG_PRINT_MEMADDRESSES, which is meant to > control prefix formatting. The actual formatting has to be performed > by the consuming application which needs to provide a formatting > callback via av_log_set_formatprefix_callback. Still more global state in the libraries. Also, inconsistent style. -- Nicolas George ___ 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] avcodec/aarch64/vvc: Optimize vvc_avg{8, 10, 12}
On Mon, 3 Mar 2025, Krzysztof Pyrkosz via ffmpeg-devel wrote: This patch replaces integer widening with halving addition, and multi-step "emulated" rounding shift with a single asm instruction doing exactly that. Benchmarks before and after: A78 avg_8_64x64_neon: 2686.2 ( 6.12x) avg_8_128x128_neon: 10734.2 ( 5.88x) avg_10_64x64_neon:2536.8 ( 5.40x) avg_10_128x128_neon: 10079.0 ( 5.22x) avg_12_64x64_neon:2548.2 ( 5.38x) avg_12_128x128_neon: 10133.8 ( 5.19x) avg_8_64x64_neon: 897.8 (18.26x) avg_8_128x128_neon: 3608.5 (17.37x) avg_10_32x32_neon: 444.2 ( 8.51x) avg_10_64x64_neon:1711.8 ( 8.00x) avg_12_64x64_neon:1706.2 ( 8.02x) avg_12_128x128_neon: 7010.0 ( 7.46x) A72 avg_8_64x64_neon: 5823.4 ( 3.88x) avg_8_128x128_neon: 17430.5 ( 4.73x) avg_10_64x64_neon:5228.1 ( 3.71x) avg_10_128x128_neon: 16722.2 ( 4.17x) avg_12_64x64_neon:5379.1 ( 3.51x) avg_12_128x128_neon: 16715.7 ( 4.17x) avg_8_64x64_neon: 2006.5 (10.61x) avg_8_128x128_neon: 9158.7 ( 8.96x) avg_10_64x64_neon:3357.7 ( 5.60x) avg_10_128x128_neon: 12411.7 ( 5.56x) avg_12_64x64_neon:3317.5 ( 5.67x) avg_12_128x128_neon: 12358.5 ( 5.58x) A53 avg_8_64x64_neon: 8327.8 ( 5.18x) avg_8_128x128_neon: 31631.3 ( 5.34x) avg_10_64x64_neon:8783.5 ( 4.98x) avg_10_128x128_neon: 32617.0 ( 5.25x) avg_12_64x64_neon:8686.0 ( 5.06x) avg_12_128x128_neon: 32487.5 ( 5.25x) avg_8_64x64_neon: 6032.3 ( 7.17x) avg_8_128x128_neon: 22008.5 ( 7.69x) avg_10_64x64_neon:7738.0 ( 5.68x) avg_10_128x128_neon: 27813.8 ( 6.14x) avg_12_64x64_neon:7844.5 ( 5.60x) avg_12_128x128_neon: 26999.5 ( 6.34x) --- libavcodec/aarch64/vvc/inter.S | 177 - 1 file changed, 130 insertions(+), 47 deletions(-) diff --git a/libavcodec/aarch64/vvc/inter.S b/libavcodec/aarch64/vvc/inter.S index 0edc861f97..b2f44697d3 100644 --- a/libavcodec/aarch64/vvc/inter.S +++ b/libavcodec/aarch64/vvc/inter.S @@ -24,9 +24,9 @@ #define BDOF_BLOCK_SIZE 16 #define BDOF_MIN_BLOCK_SIZE 4 -.macro vvc_avg type, bit_depth +.macro vvc_avg bit_depth -.macro vvc_\type\()_\bit_depth\()_2_4 tap +.macro vvc_w_avg_\bit_depth\()_2_4 tap .if \tap == 2 ldr s0, [src0] ldr s2, [src1] @@ -34,18 +34,11 @@ ldr d0, [src0] ldr d2, [src1] .endif - -.ifc \type, avg -saddl v4.4s, v0.4h, v2.4h -add v4.4s, v4.4s, v16.4s -sqshrun v4.4h, v4.4s, #(15 - \bit_depth) -.else mov v4.16b, v16.16b smlal v4.4s, v0.4h, v19.4h smlal v4.4s, v2.4h, v20.4h sqshl v4.4s, v4.4s, v22.4s sqxtun v4.4h, v4.4s -.endif .if \bit_depth == 8 sqxtun v4.8b, v4.8h @@ -68,7 +61,7 @@ add dst, dst, dst_stride .endm -function ff_vvc_\type\()_\bit_depth\()_neon, export=1 +function ff_vvc_w_avg_\bit_depth\()_neon, export=1 dst .req x0 dst_stride .req x1 src0.req x2 @@ -78,9 +71,6 @@ function ff_vvc_\type\()_\bit_depth\()_neon, export=1 mov x10, #(VVC_MAX_PB_SIZE * 2) cmp width, #8 -.ifc \type, avg -moviv16.4s, #(1 << (14 - \bit_depth)) -.else lsr x11, x6, #32// weight0 mov w12, w6 // weight1 lsr x13, x7, #32// offset @@ -91,9 +81,8 @@ function ff_vvc_\type\()_\bit_depth\()_neon, export=1 dup v20.8h, w12 dup v16.4s, w13 dup v22.4s, w14 -.endif // avg - .if \bit_depth >= 10 +.if \bit_depth >= 10 // clip pixel mov w6, #((1 << \bit_depth) - 1) dup v17.8h, w6 @@ -105,25 +94,17 @@
Re: [FFmpeg-devel] [RFC] FFV1 float support
Le 07/03/2025 à 02:13, Michael Niedermayer a écrit : [...] We have a generic remap table with the float code. 1. This is not really float specific, it could be used with integers IMO it is important to have a clear split of "tools" available in the bitstream, so it can be used whatever is the pixel kind. the spec should not have many "if". As I have a practical example with 16-bit integer having 4 bits of 0 padding, I'll give it a try. 2. Its per slice, so each slice can have a different table or none Any bits that are always 0 or 1 will be perfectly optimized out using that table. No mattter if LSB, MSB or in the middle even if every color is a multiple of 13 the remap table will still perfectly remove that and produce a continous range that is one thirteenth If you disagree, please explain how thats not already solving every variant and more ? I'll do more tests on that. ___ 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] The Concept for the CC Installment is broken by Design
> I don't have any reason to think or say anything bad about you or other > members of the CC. Then I apologize if I misunderstood. I have no issue hearing criticism of our structures but the comparison to kindergartners came off the wrong way. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/dvdsubenc: Remove pointless wrapper
Patch attached
- Andreas
From e4fe5cbab0cdbb6c47ebe2f9d44ed8c0c4c71afc Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Thu, 6 Mar 2025 17:32:20 +0100
Subject: [PATCH] avcodec/dvdsubenc: Remove pointless wrapper
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dvdsubenc.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/libavcodec/dvdsubenc.c b/libavcodec/dvdsubenc.c
index c6110c29ff..cc6535fda3 100644
--- a/libavcodec/dvdsubenc.c
+++ b/libavcodec/dvdsubenc.c
@@ -250,9 +250,9 @@ static void copy_rectangle(AVSubtitleRect *dst, AVSubtitleRect *src, int cmap[])
}
}
-static int encode_dvd_subtitles(AVCodecContext *avctx,
-uint8_t *outbuf, int outbuf_size,
-const AVSubtitle *h)
+static int dvdsub_encode(AVCodecContext *avctx,
+ uint8_t *outbuf, int outbuf_size,
+ const AVSubtitle *h)
{
DVDSubtitleContext *dvdc = avctx->priv_data;
uint8_t *q, *qq;
@@ -476,17 +476,6 @@ static int dvdsub_init(AVCodecContext *avctx)
return 0;
}
-static int dvdsub_encode(AVCodecContext *avctx,
- unsigned char *buf, int buf_size,
- const AVSubtitle *sub)
-{
-//DVDSubtitleContext *s = avctx->priv_data;
-int ret;
-
-ret = encode_dvd_subtitles(avctx, buf, buf_size, sub);
-return ret;
-}
-
#define OFFSET(x) offsetof(DVDSubtitleContext, x)
#define SE AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/decode: Fix avcodec parameters when bsfs are enable by decoder
From: Zhao Zhili BSF can update extradata, e.g., vvc_mp4toannexb. If we don't copy bsf->par_out back to avcodec context, decoder can get extradata in mp4 format, while packets are in annexb format. --- libavcodec/decode.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/decode.c b/libavcodec/decode.c index c5a577f4f1..95b8c32502 100644 --- a/libavcodec/decode.c +++ b/libavcodec/decode.c @@ -206,6 +206,9 @@ static int decode_bsfs_init(AVCodecContext *avctx) goto fail; ret = av_bsf_init(avci->bsf); +if (ret < 0) +goto fail; +ret = avcodec_parameters_to_context(avctx, avci->bsf->par_out); if (ret < 0) goto fail; -- 2.46.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 v3 1/4] avutil/log: Add callback for context prefix formatting
> -Original Message- > From: ffmpeg-devel On Behalf Of > Hendrik Leppkes > Sent: Freitag, 7. März 2025 18:31 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH v3 1/4] avutil/log: Add callback for > context prefix formatting > > On Fri, Mar 7, 2025 at 6:23 PM Soft Works > wrote: > > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Nicolas George > > > Sent: Freitag, 7. März 2025 10:44 > > > To: FFmpeg development discussions and patches de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH v3 1/4] avutil/log: Add callback > for > > > context prefix formatting > > > > > > softworkz (HE12025-03-06): > > > > From: softworkz > > > > > > > > also adds a log flag AV_LOG_PRINT_MEMADDRESSES, which is meant to > > > > control prefix formatting. The actual formatting has to be > performed > > > > by the consuming application which needs to provide a formatting > > > > callback via av_log_set_formatprefix_callback. > > > > > > Still more global state in the libraries. Hi Hendrik, > > You mean the callback? > > > > Yes. You are also adding a new callback thats used from within a > callback, if someone uses av_log_set_callback then it might just not > get used. Yes, that's true. fftools are sometimes setting it to some "simple" implementation like in cases when printing help information, yet there's no prefix formatting needed - that's why I didn't see it as a problem, but indeed it's kind of going around 2 corners here. > So instead, why not provide a different implementation of the log > callback and use the existing av_log_set_callback function? Then no > library changes are needed at all. I like the idea. I had thought about it for a moment but disregarded it (maybe too) early, being afraid of people criticizing the code duplication involved in doing so. But I'm open to go that way. The option for printing date and time on log lines has just recently been added and not included in any release yet. Maybe that's something that should only be done in the fftools version of the logging callback as well? Thanks for your suggestion, sw ___ 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] lsws/ppc/yuv2rgb_altivec: Fix build in non-VSX environments with Clang
On 2025-03-06 8:28 a.m., Ramiro Polla wrote: On Wed, Mar 5, 2025 at 4:17 AM Ramiro Polla wrote: On Wed, Mar 5, 2025 at 2:24 AM Brad Smith wrote: On 2023-08-23 4:52 p.m., Michael Niedermayer wrote: On Fri, Aug 18, 2023 at 10:14:04PM -0400, Brad Smith wrote: lsws/ppc/yuv2rgb_altivec: Fix build in non-VSX environments with Clang Add a check for the existence of the vec_xl() function. Clang provides the function even with VSX not enabled. v2: test for function if AltiVec is enabled instead of with AltiVec and without VSX --- configure| 8 libswscale/ppc/yuv2rgb_altivec.c | 4 ++-- 2 files changed, 10 insertions(+), 2 deletions(-) Has this been tested on an affected platform ? I mean the function is provided but does it also work ? This has been in the FreeBSD / OpenBSD ports for years. So to a certain extent yes. Anyway, I didn't have access to my test VM for quite some time but I do now and ran the various tests with FATE and did not see any issues. Build doesn't seem to fail anymore, but that's probably because of the #if 0 from b9eaf6e05c2ca16d94869e0263236dbdac752400. Could you please send a rebased patch? I tested on Sean's G5 and this patch fixed the build issue with clang, so I pushed it. The code that uses vec_xl() is still under #if 0 though. I have commit access. Also what you had commited was my v1 diff not v2. I will fix it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7 0/8] Properly decode ogg metadata in ogg/{vorbis, flac, opus} chained bitstreams
Hi again! Le ven. 28 févr. 2025 à 13:54, Romain Beauxis a écrit : > > Le mar. 25 févr. 2025 à 16:01, Romain Beauxis > a écrit : > > > > This is a series of patches to allow proper decoding of ogg metadata in > > chained > > `ogg/vorbis, `ogg/flac` and `ogg/opus` streams. > > Lynne, Michael, any interest in reviewing this series? > > It's definitely the cleaner it's ever been and I believe it addresses > all the previous concerns. Is there any update on this? I'm very thankful for all the help with it, the code is really good now. I went through all these changes carefully and I think the process was positive. Is there any interest in actually giving it a (final?) review? Thanks, -- Romain > Thanks! > -- Romain > > > ## Changes since last version: > > * Cleaned up patch series > > * Reverted changes in how multiple fields are parsed in vorbis comments. > > > > Full discussion: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/6 > > > > Romain Beauxis (8): > > libavcodec/decode.c: intercept `AV_PKT_DATA_METADATA_UPDATE` packet > > extra data, attach them to the next decoded frame. > > tests: Add stream dump test API util. > > tests: Add chained ogg/vorbis stream dump test. > > libavformat/oggdec.h, libavformat/oggparsevorbis.c: Factor out vorbis > > metadata update mechanism. > > libavformat/oggparseflac.c: Parse ogg/flac comments in new ogg > > packets, add them to ogg stream new_metadata. > > tests: Add chained ogg/flac stream dump test. > > libavformat/oggparseopus.c: Parse comments from secondary chained > > streams header packet. > > tests: Add chained ogg/opus stream dump test. > > > > libavcodec/decode.c | 20 +++ > > libavformat/oggdec.h | 14 +++ > > libavformat/oggparseflac.c| 21 > > libavformat/oggparseopus.c| 13 +- > > libavformat/oggparsevorbis.c | 25 ++-- > > tests/Makefile| 4 + > > tests/api/Makefile| 2 +- > > tests/api/api-dump-stream-meta-test.c | 175 ++ > > tests/fate/ogg-flac.mak | 11 ++ > > tests/fate/ogg-opus.mak | 11 ++ > > tests/fate/ogg-vorbis.mak | 11 ++ > > 11 files changed, 297 insertions(+), 10 deletions(-) > > create mode 100644 tests/api/api-dump-stream-meta-test.c > > create mode 100644 tests/fate/ogg-flac.mak > > create mode 100644 tests/fate/ogg-opus.mak > > create mode 100644 tests/fate/ogg-vorbis.mak > > > > -- > > 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] FFV1 float support
Hi On Thu, Mar 06, 2025 at 03:14:49AM +0100, Lynne wrote: > On 06/03/2025 01:15, Michael Niedermayer wrote: > > Hi everyone > > > > Current FFv1 code with my patchset supports 16bit floats. The implementation > > is quite simple. Which is good > > > > I have tried improving compression, the gains are incremental, but its not > > large overall. For example 44% space gain on the remapping table is just > > 0.1% overall. > > > > I have few float samples. Its mainly one high quality slideshow of unrelated > > 16bit float images. These excercise a wide range fo things including > > negative > > color values. > > I think I have only one single (non slideshow) video of float 16 samples, > > > > It turns out the most efficient way to store floats that i found, is to > > remap > > them to integers. Not to store tham as sign, exponent, mantisse, i tried > > that > > for many hours. > > > > Storing them using a remapping, has a very nice side effect though, and > > that is > > it will be easy to add 32bit and 64bit float support (once there is some > > sample data) > > Because a image of 64bit floats, after its split into slices of up to > > 256x256 > > can always be mapped into 16bit integers within each slice. > > *how*? Unlike ints, you cannot simply shift and extract bits from floats and > treat them as floats. well, if the input is IEEE 754 32bit or 64bit floats or some 16bit floats. they can be read with AV_RL16/32/64 and are then 16/32/64bit ints. So we have slices of 256x256 or smaller of such integers. A 256x256 slice has at maximum 64k distinct values, these values can always be stored in 16bit, once they are remapped to a compact list. There are no floats after the remapping and before its inverted in the decoder directly doing anything with floats is not bit exactly defined in C so we have to work with integers anyway in a lossless codec. > > > What about the mapping itself, it uses a rather simple rle coder. ive spend > > most of the day today tuning that and failing to really beat that. > > Using context from the previous image didnt work with the slideshow material > > i have nor that one video i have. I tried using sign and exponent as > > context, > > tried previous run, relations of runs, low bits and many more, but no or > > insignificant improvments of yesterdays implementation was achieved. > > I did mention this once before, but you should look into the Daala/Opus way > of storing rawbits into a separate chunk at the end of the bitstream. It > avoids polluting the range context with equiprobable bits. This may fit into my LSB work but that is not float specific and its not needed for float support. I originally thought we would do floats through RAW storing LSB, and special handling the "always" 0 and 1 bits. It makes sense but just remapping only the used values to a compact list eliminates all the constant bits for free and we never have more than 16bits per sample We still can implement storing LSB raw, i have written 2 implementations the first without range coder was this: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-October/334718.html I didnt like it, but it seems more popular Also given the raw bits are a known and constant length. It could make sense to put them first if they are stored non interleaved. but IIRC, the implementation for LSB refered in the link decorrelates after LSB is split, it should give more compression doing it the other way around. That said the LSB patch still isnt needed for float support, it could improve speed at the expense of compression for 16 and 32bit samples (float or other) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/4] avutil/log: Add callback for context prefix formatting
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Freitag, 7. März 2025 10:44 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH v3 1/4] avutil/log: Add callback for > context prefix formatting > > softworkz (HE12025-03-06): > > From: softworkz > > > > also adds a log flag AV_LOG_PRINT_MEMADDRESSES, which is meant to > > control prefix formatting. The actual formatting has to be performed > > by the consuming application which needs to provide a formatting > > callback via av_log_set_formatprefix_callback. > > Still more global state in the libraries. You mean the callback? > Also, inconsistent style. Could you please be more specific? Thank you sw ___ 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] The Concept for the CC Installment is broken by Design
> -Original Message- > From: ffmpeg-devel On Behalf Of > Marth64 > Sent: Freitag, 7. März 2025 23:42 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] The Concept for the CC Installment is broken > by Design > > You can criticize the CC structure all you want, but I will absolutely > not accept thinly veiled personal attacks, including being called a > child. Your email is condescending and dismissive, completely > disregarding the time and effort that volunteers like myself have put > into this work. I did not volunteer to this role because I was "keen > and crazy enough to" but because I wanted to actually try and make a > difference. Whether or not I have, that is for the people to decide. > But I will not have it being publicly ridiculed and called a "child". > I have been nothing but polite to you and others even if we have > disagreements. > > Frankly, beyond this example, you have shown to be generally rude, > gatekeeping to others, and are unpleasant to engage with. You also > seem unaware that not all CC matters are handled publicly. This was not meant to attack anybody. Neither did I call anybody a child. By saying "keen and crazy" enough I wanted to express my respect for volunteering for such a role, given the fact that this is all the members of the CC to criticism and accusations. Everything I had written was about the concept of the CC - ONLY. Not about any human being. I don't have any reason to think or say anything bad about you or other members of the CC. sw ___ 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".
