Re: [FFmpeg-devel] [PATCH 3/3] checkasm: add tests for vvc dmvr
On Fri, Jul 26, 2024 at 9:36 AM James Almer wrote:
> On 7/25/2024 10:35 AM, Nuo Mi wrote:
> > dmvr_8_12x20_c: 186.2
> > dmvr_8_12x20_avx2: 25.7
> > dmvr_8_20x12_c: 181.7
> > dmvr_8_20x12_avx2: 25.2
> > dmvr_8_20x20_c: 283.2
> > dmvr_8_20x20_avx2: 32.0
> > dmvr_10_12x20_c: 90.0
> > dmvr_10_12x20_avx2: 15.7
> > dmvr_10_20x12_c: 41.0
> > dmvr_10_20x12_avx2: 14.7
> > dmvr_10_20x20_c: 81.5
> > dmvr_10_20x20_avx2: 26.7
> > dmvr_12_12x20_c: 190.7
> > dmvr_12_12x20_avx2: 20.2
> > dmvr_12_20x12_c: 187.2
> > dmvr_12_20x12_avx2: 20.2
> > dmvr_12_20x20_c: 292.7
> > dmvr_12_20x20_avx2: 27.2
> > dmvr_h_8_12x20_c: 317.0
> > dmvr_h_8_12x20_avx2: 37.0
> > dmvr_h_8_20x12_c: 340.0
> > dmvr_h_8_20x12_avx2: 41.0
> > dmvr_h_8_20x20_c: 540.7
> > dmvr_h_8_20x20_avx2: 64.0
> > dmvr_h_10_12x20_c: 322.7
> > dmvr_h_10_12x20_avx2: 30.7
> > dmvr_h_10_20x12_c: 344.2
> > dmvr_h_10_20x12_avx2: 34.0
> > dmvr_h_10_20x20_c: 529.0
> > dmvr_h_10_20x20_avx2: 51.5
> > dmvr_h_12_12x20_c: 326.7
> > dmvr_h_12_12x20_avx2: 33.5
> > dmvr_h_12_20x12_c: 331.7
> > dmvr_h_12_20x12_avx2: 51.2
> > dmvr_h_12_20x20_c: 534.0
> > dmvr_h_12_20x20_avx2: 62.7
> > dmvr_hv_8_12x20_c: 650.0
> > dmvr_hv_8_12x20_avx2: 57.2
> > dmvr_hv_8_20x12_c: 676.2
> > dmvr_hv_8_20x12_avx2: 70.0
> > dmvr_hv_8_20x20_c: 1068.5
> > dmvr_hv_8_20x20_avx2: 103.2
> > dmvr_hv_10_12x20_c: 649.0
> > dmvr_hv_10_12x20_avx2: 48.2
> > dmvr_hv_10_20x12_c: 677.7
> > dmvr_hv_10_20x12_avx2: 59.7
> > dmvr_hv_10_20x20_c: 1093.5
> > dmvr_hv_10_20x20_avx2: 91.7
> > dmvr_hv_12_12x20_c: 660.0
> > dmvr_hv_12_12x20_avx2: 58.7
> > dmvr_hv_12_20x12_c: 682.7
> > dmvr_hv_12_20x12_avx2: 72.0
> > dmvr_hv_12_20x20_c: 1094.0
> > dmvr_hv_12_20x20_avx2: 113.2
> > dmvr_v_8_12x20_c: 325.7
> > dmvr_v_8_12x20_avx2: 31.2
> > dmvr_v_8_20x12_c: 326.2
> > dmvr_v_8_20x12_avx2: 38.5
> > dmvr_v_8_20x20_c: 538.5
> > dmvr_v_8_20x20_avx2: 54.2
> > dmvr_v_10_12x20_c: 318.5
> > dmvr_v_10_12x20_avx2: 23.7
> > dmvr_v_10_20x12_c: 330.7
> > dmvr_v_10_20x12_avx2: 40.5
> > dmvr_v_10_20x20_c: 567.5
> > dmvr_v_10_20x20_avx2: 48.0
> > dmvr_v_12_12x20_c: 335.2
> > dmvr_v_12_12x20_avx2: 30.0
> > dmvr_v_12_20x12_c: 330.2
> > dmvr_v_12_20x12_avx2: 39.5
> > dmvr_v_12_20x20_c: 535.2
> > dmvr_v_12_20x20_avx2: 60.0
> > ---
> > tests/checkasm/vvc_mc.c | 59 +
> > 1 file changed, 59 insertions(+)
> >
> > diff --git a/tests/checkasm/vvc_mc.c b/tests/checkasm/vvc_mc.c
> > index bc6b580f42..62fa6aa7d0 100644
> > --- a/tests/checkasm/vvc_mc.c
> > +++ b/tests/checkasm/vvc_mc.c
> > @@ -324,6 +324,64 @@ static void check_avg(void)
> > report("avg");
> > }
> >
> > +#define SR_RANGE 2
> > +static void check_dmvr(void)
> > +{
> > +LOCAL_ALIGNED_32(uint16_t, dst0, [DST_BUF_SIZE]);
> > +LOCAL_ALIGNED_32(uint16_t, dst1, [DST_BUF_SIZE]);
> > +LOCAL_ALIGNED_32(uint8_t, src0, [SRC_BUF_SIZE]);
> > +LOCAL_ALIGNED_32(uint8_t, src1, [SRC_BUF_SIZE]);
> > +const int dst_stride = MAX_PB_SIZE * sizeof(int16_t);
> > +
> > +VVCDSPContext c;
> > +declare_func(void, int16_t *dst, const uint8_t *src, ptrdiff_t
> src_stride, int height,
> > +intptr_t mx, intptr_t my, int width);
> > +
> > +for (int bit_depth = 8; bit_depth <= 12; bit_depth += 2) {
> > +ff_vvc_dsp_init(&c, bit_depth);
> > +randomize_pixels(src0, src1, SRC_BUF_SIZE);
> > +for (int i = 0; i < 2; i++) {
> > +for (int j = 0; j < 2; j++) {
> > +for (int h = 8; h <= 16; h *= 2) {
> > +for (int w = 8; w <= 16; w *= 2) {
> > +const int pred_w = w + 2 * SR_RANGE;
> > +const int pred_h = h + 2 * SR_RANGE;
> > +const int mx = rnd() %
> VVC_INTER_LUMA_DMVR_FACTS;
> > +const int my = rnd() %
> VVC_INTER_LUMA_DMVR_FACTS;
> > +const char *type;
> > +
> > +if (w * h < 128)
> > +continue;
>
> So h == 8 && w == 8 is not tested?
>
Hi James,
thank you for the review.
Yes, DMVR operates on subblocks with a maximum size of 16x16, and it also
requires that the width multiplied by the height be at least 128.
Therefore, only block sizes of 8x16, 16x8, and 16x16 are valid.
see:
8.5.1 General decoding process for coding units coded in inter prediction
mode
and
https://vicuesoft.com/blog/titles/DMVR_in_VVC/
>
> > +
> > +switch ((j << 1) | i) {
> > +case 0: type = "dmvr";break; // 0 0
> > +case 1: type = "dmvr_h"; break; // 0 1
> > +case 2: type = "dmvr_v"; break; // 1 0
> > +case 3: type = "dmvr_hv"; break; // 1 1
> > +}
> > +
> > +if (check_func(c.inter.dmvr[j][i],
> "%s_%d_%dx%d", type, bit_depth, pred_w, pred_h)) {
> > +memset(dst0, 0, DST_BUF_SIZE);
> > +
Re: [FFmpeg-devel] [PATCH] lavu/tx: stop using av_log(NULL, )
Quoting Lynne via ffmpeg-devel (2024-07-26 08:42:11) > Its not feasible to add an AVClass in the main context, as > it would waste space, as the main context is recursive, and > every bit of assembly would need to be changed. > > While its true that on paper av_log has access to the main > context, that functionality is not used as no options are > available for setting. No options will be exposed either, > and it makes no sense. > > mpv has recently started warning if a NULL AVClass is used > as an FFmpeg bug. While I don't fully agree nor disagree with > this, this is a simple patch which fixes the issue. No, it just hides the issue for the time being. I am against this patch, just add a proper AVClass. AVTXContext is entirely opaque, so it should definitely be feasible. -- 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 4/4 v2] avcodec/h264dec: add support for LCEVC enhancement
Quoting James Almer (2024-07-22 00:53:50) > Signed-off-by: James Almer > --- > configure | 2 +- > libavcodec/avcodec.h | 5 + > libavcodec/h264_picture.c | 1 + > libavcodec/h264_slice.c | 15 ++ > libavcodec/h264dec.c | 41 --- > libavcodec/h264dec.h | 3 +++ > 6 files changed, 63 insertions(+), 4 deletions(-) Does this need to be integrated into individual decoders? Can't the generic path apply it based on the presence of AV_FRAME_DATA_LCEVC sdide data and AV_CODEC_EXPORT_DATA_ENHANCEMENTS being set? -- 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 v4 1/3] avcodec/jpeg2000dec: Add support for CAP and CPF markers
tor 2024-07-25 klockan 17:06 -0700 skrev Pierre-Anthony Lemieux: > On Thu, Jul 25, 2024 at 2:17 AM Tomas Härdin wrote: > > > > sön 2024-07-21 klockan 14:07 +0900 skrev Pierre-Anthony Lemieux: > > > On Sat, Jul 20, 2024 at 5:12 PM Tomas Härdin > > > wrote: > > > > > > > > tor 2024-07-18 klockan 23:10 +0900 skrev Pierre-Anthony > > > > Lemieux: > > > > > On Mon, Jul 15, 2024 at 10:33 PM Tomas Härdin > > > > > > > > > > wrote: > > > > > > > > > > > > fre 2024-07-12 klockan 12:51 -0700 skrev Pierre-Anthony > > > > > > Lemieux: > > > > > > > On Thu, Jul 11, 2024 at 10:28 PM Tomas Härdin > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > + if (s->in_tile_headers == 1 && s->isHT > > > > > > > > > && > > > > > > > > > (!s- > > > > > > > > > > Ccap15_b11)) > > > > > > > > > + av_log(s->avctx, AV_LOG_WARNING, > > > > > > > > > "COD > > > > > > > > > marker > > > > > > > > > is > > > > > > > > > found in HOMOGENEOUS HT set\n"); > > > > > > > > > > > > > > > > How bad is this and the other markers being present in > > > > > > > > this > > > > > > > > case? > > > > > > > > > > > > > > At the very least, it means that signaling is > > > > > > > inconsistent > > > > > > > within > > > > > > > the > > > > > > > codestream since the standard states that: > > > > > > > """ > > > > > > > The HOMOGENEOUS set is the set of HTJ2K codestreams > > > > > > > where: > > > > > > > • none of the functional marker segments, e.g., COD, COC, > > > > > > > RGN, > > > > > > > QCD, > > > > > > > QCC, and POC, are present in any > > > > > > > tile-part header; and > > > > > > > • no PPT marker segment is present. > > > > > > > """ > > > > > > > > > > > > > > The point of signalling that a codestream is > > > > > > > "HOMOGENEOUS" is > > > > > > > to > > > > > > > allow > > > > > > > decoders to configure themselves solely based on > > > > > > > information > > > > > > > retrieved > > > > > > > entirely from the main header. > > > > > > > > > > > > > > Since, AFAIK, FFMPEG does not rely on the HOMOGENEOUS to > > > > > > > short- > > > > > > > circuit > > > > > > > configuration, incorrect HOMOGENEOUS signalling will > > > > > > > likely > > > > > > > not > > > > > > > impact > > > > > > > FFMPEG. > > > > > > > > > > > > It could happen that information in tile headers contradict > > > > > > information > > > > > > in the main header, right? In such a case it sounds like we > > > > > > can't > > > > > > be > > > > > > sure which decode is the correct one. > > > > > > > > > > Per the spec, the decoder uses the COD information in tile- > > > > > parts > > > > > over > > > > > the COD information in the header. > > > > > > > > > > The issue here is that a decoder, upon seeing HOMOGENEOUS, > > > > > simply > > > > > does > > > > > not bother with looking for COD information in tile-parts, > > > > > thereby > > > > > missing critical information. > > > > > > > > So it is actually perfectly legal? Then it seems this patch is > > > > wrong > > > > > > What is not "illegal": the HOMOGENEOUS flag being equal to true > > > *and* > > > having COD marker segments in tile-parts. > > > > > > This is what the patch detects. > > > > > > FFMPEG can decode such illegal codestream. Other decoders might > > > not. > > > > > > The question is: what should FFMPEG do? Should FFMPEG exit or > > > warn > > > and continue. > > > > If the spec allows it but it's perhaps unadviced then warning about > > it > > seems reasonable > > (I totally messed up my double negative. Repeat below. Sorry for the > confusion.) > > What is "illegal": the HOMOGENEOUS flag being equal to true *and* > having COD marker segments in tile-parts. > > This is what the patch detects. > > FFMPEG can decode such illegal codestream. Other decoders might not. > > The question is: what should FFMPEG do? Should FFMPEG exit or warn > and continue. Since it's illegal then we should complain and bail out. Users that *really* want it to keep going can change the code. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavu/tx: stop using av_log(NULL, )
Lynne via ffmpeg-devel:
> Its not feasible to add an AVClass in the main context, as
> it would waste space, as the main context is recursive, and
> every bit of assembly would need to be changed.
>
> While its true that on paper av_log has access to the main
> context, that functionality is not used as no options are
> available for setting. No options will be exposed either,
> and it makes no sense.
>
> mpv has recently started warning if a NULL AVClass is used
> as an FFmpeg bug. While I don't fully agree nor disagree with
> this, this is a simple patch which fixes the issue.
Really?
https://github.com/mpv-player/mpv/commit/54d0763b92f3d8239aa2258f2193eebdc74a91ef
is 13 years old and the check would only warn if a logcontext with NULL
AVClass* is used.
> ---
> libavutil/tx.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/libavutil/tx.c b/libavutil/tx.c
> index 0aae4c7cf7..136d10c374 100644
> --- a/libavutil/tx.c
> +++ b/libavutil/tx.c
> @@ -30,6 +30,12 @@
> ((x) == AV_TX_DOUBLE_ ## type) || \
> ((x) == AV_TX_INT32_ ## type))
>
> +static const AVClass tx_class = {
> +.class_name= "tx",
> +.item_name = av_default_item_name,
> +.version = LIBAVUTIL_VERSION_INT,
> +};
> +
> /* Calculates the modular multiplicative inverse */
> static av_always_inline int mulinv(int n, int m)
> {
> @@ -645,7 +651,7 @@ static void print_cd_info(const FFTXCodelet *cd, int
> prio, int len, int print_pr
> if (print_prio)
> av_bprintf(&bp, ", prio: %i", prio);
>
> -av_log(NULL, log_level, "%s\n", bp.str);
> +av_log((void *)&tx_class, log_level, "%s\n", bp.str);
> }
>
> static void print_tx_structure(AVTXContext *s, int depth)
> @@ -653,7 +659,7 @@ static void print_tx_structure(AVTXContext *s, int depth)
> const FFTXCodelet *cd = s->cd_self;
>
> for (int i = 0; i <= depth; i++)
> -av_log(NULL, AV_LOG_DEBUG, "");
> +av_log((void *)&tx_class, AV_LOG_DEBUG, "");
>
> print_cd_info(cd, cd->prio, s->len, 0, AV_LOG_DEBUG);
>
> @@ -818,10 +824,10 @@ av_cold int ff_tx_init_subtx(AVTXContext *s, enum
> AVTXType type,
> AV_QSORT(cd_matches, nb_cd_matches, TXCodeletMatch, cmp_matches);
>
> #if !CONFIG_SMALL
> -av_log(NULL, AV_LOG_TRACE, "%s\n", bp.str);
> +av_log((void *)&tx_class, AV_LOG_TRACE, "%s\n", bp.str);
>
> for (int i = 0; i < nb_cd_matches; i++) {
> -av_log(NULL, AV_LOG_TRACE, "%i: ", i + 1);
> +av_log((void *)&tx_class, AV_LOG_TRACE, "%i: ", i + 1);
> print_cd_info(cd_matches[i].cd, cd_matches[i].prio, 0, 1,
> AV_LOG_TRACE);
> }
> #endif
> @@ -931,7 +937,7 @@ av_cold int av_tx_init(AVTXContext **ctx, av_tx_fn *tx,
> enum AVTXType type,
> *tx = tmp.fn[0];
>
> #if !CONFIG_SMALL
> -av_log(NULL, AV_LOG_DEBUG, "Transform tree:\n");
> +av_log((void *)&tx_class, AV_LOG_DEBUG, "Transform tree:\n");
> print_tx_structure(*ctx, 0);
> #endif
>
Did you ever test this? av_log() expects a pointer to an AVClass-enabled
struct, not a pointer to an AVClass. This will crash (it will interpret
AVClass.class_name as pointer to an AVClass) when the log is active
(when loglevel is high enough).
- Andreas
___
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] lavu/tx: stop using av_log(NULL, )
On 26/07/2024 10:22, Andreas Rheinhardt wrote:
Lynne via ffmpeg-devel:
Its not feasible to add an AVClass in the main context, as
it would waste space, as the main context is recursive, and
every bit of assembly would need to be changed.
While its true that on paper av_log has access to the main
context, that functionality is not used as no options are
available for setting. No options will be exposed either,
and it makes no sense.
mpv has recently started warning if a NULL AVClass is used
as an FFmpeg bug. While I don't fully agree nor disagree with
this, this is a simple patch which fixes the issue.
Really?
https://github.com/mpv-player/mpv/commit/54d0763b92f3d8239aa2258f2193eebdc74a91ef
is 13 years old and the check would only warn if a logcontext with NULL
AVClass* is used.
Odd, something started triggering the check on my system.
libavutil/tx.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/libavutil/tx.c b/libavutil/tx.c
index 0aae4c7cf7..136d10c374 100644
--- a/libavutil/tx.c
+++ b/libavutil/tx.c
@@ -30,6 +30,12 @@
((x) == AV_TX_DOUBLE_ ## type) || \
((x) == AV_TX_INT32_ ## type))
+static const AVClass tx_class = {
+.class_name= "tx",
+.item_name = av_default_item_name,
+.version = LIBAVUTIL_VERSION_INT,
+};
+
/* Calculates the modular multiplicative inverse */
static av_always_inline int mulinv(int n, int m)
{
@@ -645,7 +651,7 @@ static void print_cd_info(const FFTXCodelet *cd, int prio,
int len, int print_pr
if (print_prio)
av_bprintf(&bp, ", prio: %i", prio);
-av_log(NULL, log_level, "%s\n", bp.str);
+av_log((void *)&tx_class, log_level, "%s\n", bp.str);
}
static void print_tx_structure(AVTXContext *s, int depth)
@@ -653,7 +659,7 @@ static void print_tx_structure(AVTXContext *s, int depth)
const FFTXCodelet *cd = s->cd_self;
for (int i = 0; i <= depth; i++)
-av_log(NULL, AV_LOG_DEBUG, "");
+av_log((void *)&tx_class, AV_LOG_DEBUG, "");
print_cd_info(cd, cd->prio, s->len, 0, AV_LOG_DEBUG);
@@ -818,10 +824,10 @@ av_cold int ff_tx_init_subtx(AVTXContext *s, enum AVTXType type,
AV_QSORT(cd_matches, nb_cd_matches, TXCodeletMatch, cmp_matches);
#if !CONFIG_SMALL
-av_log(NULL, AV_LOG_TRACE, "%s\n", bp.str);
+av_log((void *)&tx_class, AV_LOG_TRACE, "%s\n", bp.str);
for (int i = 0; i < nb_cd_matches; i++) {
-av_log(NULL, AV_LOG_TRACE, "%i: ", i + 1);
+av_log((void *)&tx_class, AV_LOG_TRACE, "%i: ", i + 1);
print_cd_info(cd_matches[i].cd, cd_matches[i].prio, 0, 1,
AV_LOG_TRACE);
}
#endif
@@ -931,7 +937,7 @@ av_cold int av_tx_init(AVTXContext **ctx, av_tx_fn *tx,
enum AVTXType type,
*tx = tmp.fn[0];
#if !CONFIG_SMALL
-av_log(NULL, AV_LOG_DEBUG, "Transform tree:\n");
+av_log((void *)&tx_class, AV_LOG_DEBUG, "Transform tree:\n");
print_tx_structure(*ctx, 0);
#endif
Did you ever test this? av_log() expects a pointer to an AVClass-enabled
struct, not a pointer to an AVClass. This will crash (it will interpret
AVClass.class_name as pointer to an AVClass) when the log is active
(when loglevel is high enough).
No, I trusted that I did test it when I submitted it a year ago.
OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key
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] lavu/tx: stop using av_log(NULL, )
On 26/07/2024 09:47, Anton Khirnov wrote: Quoting Lynne via ffmpeg-devel (2024-07-26 08:42:11) Its not feasible to add an AVClass in the main context, as it would waste space, as the main context is recursive, and every bit of assembly would need to be changed. While its true that on paper av_log has access to the main context, that functionality is not used as no options are available for setting. No options will be exposed either, and it makes no sense. mpv has recently started warning if a NULL AVClass is used as an FFmpeg bug. While I don't fully agree nor disagree with this, this is a simple patch which fixes the issue. No, it just hides the issue for the time being. If this means "it may get broken eventually, its not forbidden anywhere", then IMO we should just codify the current behavior such that it won't, unless there's some use-case you can think of. I am against this patch, just add a proper AVClass. AVTXContext is entirely opaque, so it should definitely be feasible. I'd like to avoid adding a pointer and allocating it if it can't be helped. And properly integrating each context into the AVClass system as a child of the parent context. If you think a NULL av_log is valid (you implied that a year ago), then I'm more than happy to drop this patch. OpenPGP_0xA2FEA5F03F034464.asc Description: OpenPGP public key 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] lavu/tx: stop using av_log(NULL, )
> On Jul 26, 2024, at 14:42, Lynne via ffmpeg-devel
> wrote:
>
> Its not feasible to add an AVClass in the main context, as
> it would waste space, as the main context is recursive, and
> every bit of assembly would need to be changed.
>
> While its true that on paper av_log has access to the main
> context, that functionality is not used as no options are
> available for setting. No options will be exposed either,
> and it makes no sense.
>
> mpv has recently started warning if a NULL AVClass is used
> as an FFmpeg bug. While I don't fully agree nor disagree with
> this, this is a simple patch which fixes the issue.
> ---
> libavutil/tx.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/libavutil/tx.c b/libavutil/tx.c
> index 0aae4c7cf7..136d10c374 100644
> --- a/libavutil/tx.c
> +++ b/libavutil/tx.c
> @@ -30,6 +30,12 @@
> ((x) == AV_TX_DOUBLE_ ## type) || \
> ((x) == AV_TX_INT32_ ## type))
>
> +static const AVClass tx_class = {
> +.class_name= "tx",
> +.item_name = av_default_item_name,
> +.version = LIBAVUTIL_VERSION_INT,
> +};
> +
> /* Calculates the modular multiplicative inverse */
> static av_always_inline int mulinv(int n, int m)
> {
> @@ -645,7 +651,7 @@ static void print_cd_info(const FFTXCodelet *cd, int
> prio, int len, int print_pr
> if (print_prio)
> av_bprintf(&bp, ", prio: %i", prio);
>
> -av_log(NULL, log_level, "%s\n", bp.str);
> +av_log((void *)&tx_class, log_level, "%s\n", bp.str);
Isn’t the first argument of av_log is a pointer to pointer to AVClass, not
pointer to AVClass?
> }
>
> static void print_tx_structure(AVTXContext *s, int depth)
> @@ -653,7 +659,7 @@ static void print_tx_structure(AVTXContext *s, int depth)
> const FFTXCodelet *cd = s->cd_self;
>
> for (int i = 0; i <= depth; i++)
> -av_log(NULL, AV_LOG_DEBUG, "");
> +av_log((void *)&tx_class, AV_LOG_DEBUG, "");
>
> print_cd_info(cd, cd->prio, s->len, 0, AV_LOG_DEBUG);
>
> @@ -818,10 +824,10 @@ av_cold int ff_tx_init_subtx(AVTXContext *s, enum
> AVTXType type,
> AV_QSORT(cd_matches, nb_cd_matches, TXCodeletMatch, cmp_matches);
>
> #if !CONFIG_SMALL
> -av_log(NULL, AV_LOG_TRACE, "%s\n", bp.str);
> +av_log((void *)&tx_class, AV_LOG_TRACE, "%s\n", bp.str);
>
> for (int i = 0; i < nb_cd_matches; i++) {
> -av_log(NULL, AV_LOG_TRACE, "%i: ", i + 1);
> +av_log((void *)&tx_class, AV_LOG_TRACE, "%i: ", i + 1);
> print_cd_info(cd_matches[i].cd, cd_matches[i].prio, 0, 1,
> AV_LOG_TRACE);
> }
> #endif
> @@ -931,7 +937,7 @@ av_cold int av_tx_init(AVTXContext **ctx, av_tx_fn *tx,
> enum AVTXType type,
> *tx = tmp.fn[0];
>
> #if !CONFIG_SMALL
> -av_log(NULL, AV_LOG_DEBUG, "Transform tree:\n");
> +av_log((void *)&tx_class, AV_LOG_DEBUG, "Transform tree:\n");
> print_tx_structure(*ctx, 0);
> #endif
>
> --
> 2.45.2.753.g447d99e1c3b
> ___
> 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] lavu/tx: stop using av_log(NULL, )
Quoting Lynne via ffmpeg-devel (2024-07-26 10:33:24) > On 26/07/2024 09:47, Anton Khirnov wrote: > > Quoting Lynne via ffmpeg-devel (2024-07-26 08:42:11) > >> Its not feasible to add an AVClass in the main context, as > >> it would waste space, as the main context is recursive, and > >> every bit of assembly would need to be changed. > >> > >> While its true that on paper av_log has access to the main > >> context, that functionality is not used as no options are > >> available for setting. No options will be exposed either, > >> and it makes no sense. > >> > >> mpv has recently started warning if a NULL AVClass is used > >> as an FFmpeg bug. While I don't fully agree nor disagree with > >> this, this is a simple patch which fixes the issue. > > > > No, it just hides the issue for the time being. > > If this means "it may get broken eventually, its not forbidden > anywhere", then IMO we should just codify the current behavior such that > it won't, unless there's some use-case you can think of. It means "you're offloading fixing this issue properly on someone else", which is a bad thing in my book. In my understanding of the API, it _is_ forbidden and UB. > > I am against this patch, just add a proper AVClass. AVTXContext is > > entirely opaque, so it should definitely be feasible. > I'd like to avoid adding a pointer and allocating it if it can't be > helped. And properly integrating each context into the AVClass system as > a child of the parent context. Consider the possibility that if your code depends on fixed layout of a big and complex struct, then your code is...suboptimal. If it's about offsets for SIMD, you could either * generate them at build time * move the things used by SIMD into a smaller struct embedded in the main context > If you think a NULL av_log is valid (you implied that a year ago), then > I'm more than happy to drop this patch. I didn't and I don't. To the contrary, I consider av_log(NULL) a mispattern that we should be rid of. -- 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 0/1] Sending my broken patch via git
From: Sean Devonport My last patch wasn't able to be merged as I sent it from within the Mail client from MacOS. Attempting to send via git send-email now. Sean Devonport (1): lavc/exr: decode_block() fails when input resolution not exactly divisable by 8 libavcodec/exr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.39.3 (Apple Git-146) ___ 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/1] lavc/exr: decode_block() fails when input resolution not exactly divisable by 8
From: Sean Devonport This stops decode_block() from failing when the .exr resolution is not divisable by 8 (e.g 108x192). The dc_w and dc_h needs to be round up and not down. --- libavcodec/exr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/exr.c b/libavcodec/exr.c index 4bac0be89b..5df2c55609 100644 --- a/libavcodec/exr.c +++ b/libavcodec/exr.c @@ -987,8 +987,8 @@ static int dwa_uncompress(const EXRContext *s, const uint8_t *src, int compresse int64_t version, lo_usize, lo_size; int64_t ac_size, dc_size, rle_usize, rle_csize, rle_raw_size; int64_t ac_count, dc_count, ac_compression; -const int dc_w = td->xsize >> 3; -const int dc_h = td->ysize >> 3; +const int dc_w = (td->xsize + 7) >> 3; +const int dc_h = (td->ysize + 7) >> 3; GetByteContext gb, agb; int skip, ret; -- 2.39.3 (Apple Git-146) ___ 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] lavu/tx: stop using av_log(NULL, )
Lynne via ffmpeg-devel:
> On 26/07/2024 10:22, Andreas Rheinhardt wrote:
>> Lynne via ffmpeg-devel:
>>> Its not feasible to add an AVClass in the main context, as
>>> it would waste space, as the main context is recursive, and
>>> every bit of assembly would need to be changed.
>>>
>>> While its true that on paper av_log has access to the main
>>> context, that functionality is not used as no options are
>>> available for setting. No options will be exposed either,
>>> and it makes no sense.
>>>
>>> mpv has recently started warning if a NULL AVClass is used
>>> as an FFmpeg bug. While I don't fully agree nor disagree with
>>> this, this is a simple patch which fixes the issue.
>>
>> Really?
>> https://github.com/mpv-player/mpv/commit/54d0763b92f3d8239aa2258f2193eebdc74a91ef
>> is 13 years old and the check would only warn if a logcontext with NULL
>> AVClass* is used.
>
> Odd, something started triggering the check on my system.
>
>>> libavutil/tx.c | 16 +++-
>>> 1 file changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/libavutil/tx.c b/libavutil/tx.c
>>> index 0aae4c7cf7..136d10c374 100644
>>> --- a/libavutil/tx.c
>>> +++ b/libavutil/tx.c
>>> @@ -30,6 +30,12 @@
>>> ((x) == AV_TX_DOUBLE_ ## type) || \
>>> ((x) == AV_TX_INT32_ ## type))
>>> +static const AVClass tx_class = {
>>> + .class_name = "tx",
>>> + .item_name = av_default_item_name,
>>> + .version = LIBAVUTIL_VERSION_INT,
>>> +};
>>> +
>>> /* Calculates the modular multiplicative inverse */
>>> static av_always_inline int mulinv(int n, int m)
>>> {
>>> @@ -645,7 +651,7 @@ static void print_cd_info(const FFTXCodelet *cd,
>>> int prio, int len, int print_pr
>>> if (print_prio)
>>> av_bprintf(&bp, ", prio: %i", prio);
>>> - av_log(NULL, log_level, "%s\n", bp.str);
>>> + av_log((void *)&tx_class, log_level, "%s\n", bp.str);
>>> }
>>> static void print_tx_structure(AVTXContext *s, int depth)
>>> @@ -653,7 +659,7 @@ static void print_tx_structure(AVTXContext *s,
>>> int depth)
>>> const FFTXCodelet *cd = s->cd_self;
>>> for (int i = 0; i <= depth; i++)
>>> - av_log(NULL, AV_LOG_DEBUG, " ");
>>> + av_log((void *)&tx_class, AV_LOG_DEBUG, " ");
>>> print_cd_info(cd, cd->prio, s->len, 0, AV_LOG_DEBUG);
>>> @@ -818,10 +824,10 @@ av_cold int ff_tx_init_subtx(AVTXContext *s,
>>> enum AVTXType type,
>>> AV_QSORT(cd_matches, nb_cd_matches, TXCodeletMatch, cmp_matches);
>>> #if !CONFIG_SMALL
>>> - av_log(NULL, AV_LOG_TRACE, "%s\n", bp.str);
>>> + av_log((void *)&tx_class, AV_LOG_TRACE, "%s\n", bp.str);
>>> for (int i = 0; i < nb_cd_matches; i++) {
>>> - av_log(NULL, AV_LOG_TRACE, " %i: ", i + 1);
>>> + av_log((void *)&tx_class, AV_LOG_TRACE, " %i: ", i + 1);
>>> print_cd_info(cd_matches[i].cd, cd_matches[i].prio, 0, 1,
>>> AV_LOG_TRACE);
>>> }
>>> #endif
>>> @@ -931,7 +937,7 @@ av_cold int av_tx_init(AVTXContext **ctx,
>>> av_tx_fn *tx, enum AVTXType type,
>>> *tx = tmp.fn[0];
>>> #if !CONFIG_SMALL
>>> - av_log(NULL, AV_LOG_DEBUG, "Transform tree:\n");
>>> + av_log((void *)&tx_class, AV_LOG_DEBUG, "Transform tree:\n");
>>> print_tx_structure(*ctx, 0);
>>> #endif
>>>
>>
>> Did you ever test this? av_log() expects a pointer to an AVClass-enabled
>> struct, not a pointer to an AVClass. This will crash (it will interpret
>> AVClass.class_name as pointer to an AVClass) when the log is active
>> (when loglevel is high enough).
>
> No, I trusted that I did test it when I submitted it a year ago.
>
You have been informed of this last year:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/nwetfs_--...@lynne.ee/
Then as now there are lots of FATE failures with this patch (as
patchwork shows).
- Andreas
___
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] lavu/cpu: deprecate AV_CPU_FLAG_RV{F, D}
Rémi Denis-Courmont: > --- > doc/APIchanges | 3 +++ > libavutil/cpu.h | 3 +++ > libavutil/version.h | 1 + > 3 files changed, 7 insertions(+) > > diff --git a/doc/APIchanges b/doc/APIchanges > index fb54c3fbc9..16993d310e 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07 > > API changes, most recent first: > > +2024-07-28 - x - lavu 59.30.101 - cpu.h > + Deprecate AV_CPU_FLAG_RVF and AV_CPU_FLAG_RVD without replacement. > + > 2024-07-25 - x - lavu 59.29.100 - cpu.h >Add AV_CPU_FLAG_RVB. > > diff --git a/libavutil/cpu.h b/libavutil/cpu.h > index 9f419aae02..8af1233e6f 100644 > --- a/libavutil/cpu.h > +++ b/libavutil/cpu.h > @@ -22,6 +22,7 @@ > #define AVUTIL_CPU_H > > #include > +#include "version.h" > > #define AV_CPU_FLAG_FORCE0x8000 /* force usage of selected flags > (OR) */ > > @@ -82,8 +83,10 @@ > > // RISC-V extensions > #define AV_CPU_FLAG_RVI (1 << 0) ///< I (full GPR bank) > +#if FF_API_RISCV_FD > #define AV_CPU_FLAG_RVF (1 << 1) ///< F (single precision FP) > #define AV_CPU_FLAG_RVD (1 << 2) ///< D (double precision FP) > +#endif > #define AV_CPU_FLAG_RVV_I32 (1 << 3) ///< Vectors of 8/16/32-bit int's > */ > #define AV_CPU_FLAG_RVV_F32 (1 << 4) ///< Vectors of float's */ > #define AV_CPU_FLAG_RVV_I64 (1 << 5) ///< Vectors of 64-bit int's */ > diff --git a/libavutil/version.h b/libavutil/version.h > index 852eeef1d6..df43dcc321 100644 > --- a/libavutil/version.h > +++ b/libavutil/version.h > @@ -113,6 +113,7 @@ > #define FF_API_VULKAN_CONTIGUOUS_MEMORY (LIBAVUTIL_VERSION_MAJOR < 60) > #define FF_API_H274_FILM_GRAIN_VCS (LIBAVUTIL_VERSION_MAJOR < 60) > #define FF_API_MOD_UINTP2 (LIBAVUTIL_VERSION_MAJOR < 60) > +#define FF_API_RISCV_FD (LIBAVUTIL_VERSION_MAJOR < 60) > > /** > * @} ___ 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] aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support
elf_aux_info(3).
Signed-off-by: Brad Smith
---
configure | 2 ++
libavutil/aarch64/cpu.c | 23 ++-
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index f6f5c29fea..e80b549582 100755
--- a/configure
+++ b/configure
@@ -2366,6 +2366,7 @@ SYSTEM_FUNCS="
clock_gettime
closesocket
CommandLineToArgvW
+elf_aux_info
fcntl
getaddrinfo
getauxval
@@ -6565,6 +6566,7 @@ check_func_headers mach/mach_time.h mach_absolute_time
check_func_headers stdlib.h getenv
check_func_headers sys/stat.h lstat
check_func_headers sys/auxv.h getauxval
+check_func_headers sys/auxv.h elf_aux_info
check_func_headers sys/sysctl.h sysctlbyname
check_func_headers windows.h GetModuleHandle
diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c
index cfa9306663..05272b4db4 100644
--- a/libavutil/aarch64/cpu.c
+++ b/libavutil/aarch64/cpu.c
@@ -42,6 +42,27 @@ static int detect_flags(void)
return flags;
}
+#elif (defined(__FreeBSD__) || defined(__OpenBSD__)) && HAVE_ELF_AUX_INFO
+#include
+#include
+
+static int detect_flags(void)
+{
+int flags = 0;
+
+unsigned long hwcap = 0;
+elf_aux_info(AT_HWCAP, &hwcap, sizeof hwcap);
+unsigned long hwcap2 = 0;
+elf_aux_info(AT_HWCAP2, &hwcap2, sizeof hwcap2);
+
+if (hwcap & HWCAP_ASIMDDP)
+flags |= AV_CPU_FLAG_DOTPROD;
+if (hwcap2 & HWCAP2_I8MM)
+flags |= AV_CPU_FLAG_I8MM;
+
+return flags;
+}
+
#elif defined(__APPLE__) && HAVE_SYSCTLBYNAME
#include
@@ -65,7 +86,7 @@ static int detect_flags(void)
return flags;
}
-#elif defined(__OpenBSD__)
+#elif defined(__OpenBSD__) && !HAVE_ELF_AUX_INFO
#include
#include
#include
--
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".
Re: [FFmpeg-devel] [PATCH] lavu/tx: stop using av_log(NULL, )
On 26/07/2024 11:03, Andreas Rheinhardt wrote:
Lynne via ffmpeg-devel:
On 26/07/2024 10:22, Andreas Rheinhardt wrote:
Lynne via ffmpeg-devel:
Its not feasible to add an AVClass in the main context, as
it would waste space, as the main context is recursive, and
every bit of assembly would need to be changed.
While its true that on paper av_log has access to the main
context, that functionality is not used as no options are
available for setting. No options will be exposed either,
and it makes no sense.
mpv has recently started warning if a NULL AVClass is used
as an FFmpeg bug. While I don't fully agree nor disagree with
this, this is a simple patch which fixes the issue.
Really?
https://github.com/mpv-player/mpv/commit/54d0763b92f3d8239aa2258f2193eebdc74a91ef
is 13 years old and the check would only warn if a logcontext with NULL
AVClass* is used.
Odd, something started triggering the check on my system.
libavutil/tx.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/libavutil/tx.c b/libavutil/tx.c
index 0aae4c7cf7..136d10c374 100644
--- a/libavutil/tx.c
+++ b/libavutil/tx.c
@@ -30,6 +30,12 @@
((x) == AV_TX_DOUBLE_ ## type) || \
((x) == AV_TX_INT32_ ## type))
+static const AVClass tx_class = {
+ .class_name = "tx",
+ .item_name = av_default_item_name,
+ .version = LIBAVUTIL_VERSION_INT,
+};
+
/* Calculates the modular multiplicative inverse */
static av_always_inline int mulinv(int n, int m)
{
@@ -645,7 +651,7 @@ static void print_cd_info(const FFTXCodelet *cd,
int prio, int len, int print_pr
if (print_prio)
av_bprintf(&bp, ", prio: %i", prio);
- av_log(NULL, log_level, "%s\n", bp.str);
+ av_log((void *)&tx_class, log_level, "%s\n", bp.str);
}
static void print_tx_structure(AVTXContext *s, int depth)
@@ -653,7 +659,7 @@ static void print_tx_structure(AVTXContext *s,
int depth)
const FFTXCodelet *cd = s->cd_self;
for (int i = 0; i <= depth; i++)
- av_log(NULL, AV_LOG_DEBUG, " ");
+ av_log((void *)&tx_class, AV_LOG_DEBUG, " ");
print_cd_info(cd, cd->prio, s->len, 0, AV_LOG_DEBUG);
@@ -818,10 +824,10 @@ av_cold int ff_tx_init_subtx(AVTXContext *s,
enum AVTXType type,
AV_QSORT(cd_matches, nb_cd_matches, TXCodeletMatch, cmp_matches);
#if !CONFIG_SMALL
- av_log(NULL, AV_LOG_TRACE, "%s\n", bp.str);
+ av_log((void *)&tx_class, AV_LOG_TRACE, "%s\n", bp.str);
for (int i = 0; i < nb_cd_matches; i++) {
- av_log(NULL, AV_LOG_TRACE, " %i: ", i + 1);
+ av_log((void *)&tx_class, AV_LOG_TRACE, " %i: ", i + 1);
print_cd_info(cd_matches[i].cd, cd_matches[i].prio, 0, 1,
AV_LOG_TRACE);
}
#endif
@@ -931,7 +937,7 @@ av_cold int av_tx_init(AVTXContext **ctx,
av_tx_fn *tx, enum AVTXType type,
*tx = tmp.fn[0];
#if !CONFIG_SMALL
- av_log(NULL, AV_LOG_DEBUG, "Transform tree:\n");
+ av_log((void *)&tx_class, AV_LOG_DEBUG, "Transform tree:\n");
print_tx_structure(*ctx, 0);
#endif
Did you ever test this? av_log() expects a pointer to an AVClass-enabled
struct, not a pointer to an AVClass. This will crash (it will interpret
AVClass.class_name as pointer to an AVClass) when the log is active
(when loglevel is high enough).
No, I trusted that I did test it when I submitted it a year ago.
You have been informed of this last year:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/nwetfs_--...@lynne.ee/
Then as now there are lots of FATE failures with this patch (as
patchwork shows).
There was humor in my response, maybe you didn't see it.
OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key
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] aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
Le 26 juillet 2024 13:58:34 GMT+03:00, Brad Smith
a écrit :
>aarch64: Implement support for elf_aux_info(3) on FreeBSD and OpenBSD
>
>FreeBSD 12.0+, OpenBSD -current and what will be OpenBSD 7.6 support
>elf_aux_info(3).
>
>Signed-off-by: Brad Smith
>---
> configure | 2 ++
> libavutil/aarch64/cpu.c | 23 ++-
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
>diff --git a/configure b/configure
>index f6f5c29fea..e80b549582 100755
>--- a/configure
>+++ b/configure
>@@ -2366,6 +2366,7 @@ SYSTEM_FUNCS="
> clock_gettime
> closesocket
> CommandLineToArgvW
>+elf_aux_info
> fcntl
> getaddrinfo
> getauxval
>@@ -6565,6 +6566,7 @@ check_func_headers mach/mach_time.h mach_absolute_time
> check_func_headers stdlib.h getenv
> check_func_headers sys/stat.h lstat
> check_func_headers sys/auxv.h getauxval
>+check_func_headers sys/auxv.h elf_aux_info
> check_func_headers sys/sysctl.h sysctlbyname
>
> check_func_headers windows.h GetModuleHandle
>diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c
>index cfa9306663..05272b4db4 100644
>--- a/libavutil/aarch64/cpu.c
>+++ b/libavutil/aarch64/cpu.c
>@@ -42,6 +42,27 @@ static int detect_flags(void)
> return flags;
> }
>
>+#elif (defined(__FreeBSD__) || defined(__OpenBSD__)) && HAVE_ELF_AUX_INFO
>+#include
>+#include
>+
>+static int detect_flags(void)
>+{
>+int flags = 0;
>+
>+unsigned long hwcap = 0;
>+elf_aux_info(AT_HWCAP, &hwcap, sizeof hwcap);
>+unsigned long hwcap2 = 0;
>+elf_aux_info(AT_HWCAP2, &hwcap2, sizeof hwcap2);
>+
>+if (hwcap & HWCAP_ASIMDDP)
>+flags |= AV_CPU_FLAG_DOTPROD;
>+if (hwcap2 & HWCAP2_I8MM)
>+flags |= AV_CPU_FLAG_I8MM;
>+
>+return flags;
>+}
>+
Can't getauxval() be implemented with elf_aux_info(), or vice versa? It seems
that otherwise the code should be identical to that from Linux.
> #elif defined(__APPLE__) && HAVE_SYSCTLBYNAME
> #include
>
>@@ -65,7 +86,7 @@ static int detect_flags(void)
> return flags;
> }
>
>-#elif defined(__OpenBSD__)
>+#elif defined(__OpenBSD__) && !HAVE_ELF_AUX_INFO
> #include
> #include
> #include
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4 v2] avcodec/h264dec: add support for LCEVC enhancement
On 7/26/2024 4:55 AM, Anton Khirnov wrote: Quoting James Almer (2024-07-22 00:53:50) Signed-off-by: James Almer --- configure | 2 +- libavcodec/avcodec.h | 5 + libavcodec/h264_picture.c | 1 + libavcodec/h264_slice.c | 15 ++ libavcodec/h264dec.c | 41 --- libavcodec/h264dec.h | 3 +++ 6 files changed, 63 insertions(+), 4 deletions(-) Does this need to be integrated into individual decoders? Can't the generic path apply it based on the presence of AV_FRAME_DATA_LCEVC sdide data and AV_CODEC_EXPORT_DATA_ENHANCEMENTS being set? Individual decoders still need to be aware of lcevc metadata being present to do things like allocating the output frame, because afaik i can't call get_buffer2() from the main/user thread. So is it worth moving things to the generic code when DR1 decoders will still need extra considerations? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4 v2] avcodec/h264dec: add support for LCEVC enhancement
Quoting James Almer (2024-07-26 14:10:46) > On 7/26/2024 4:55 AM, Anton Khirnov wrote: > > Quoting James Almer (2024-07-22 00:53:50) > >> Signed-off-by: James Almer > >> --- > >> configure | 2 +- > >> libavcodec/avcodec.h | 5 + > >> libavcodec/h264_picture.c | 1 + > >> libavcodec/h264_slice.c | 15 ++ > >> libavcodec/h264dec.c | 41 --- > >> libavcodec/h264dec.h | 3 +++ > >> 6 files changed, 63 insertions(+), 4 deletions(-) > > > > Does this need to be integrated into individual decoders? Can't the > > generic path apply it based on the presence of AV_FRAME_DATA_LCEVC sdide > > data and AV_CODEC_EXPORT_DATA_ENHANCEMENTS being set? > > Individual decoders still need to be aware of lcevc metadata being > present to do things like allocating the output frame, because afaik i > can't call get_buffer2() from the main/user thread. So is it worth > moving things to the generic code when DR1 decoders will still need > extra considerations? Can it not be handled in ff_get_buffer()? And even if not - there'd still be a lot less code that needs to be duplicated across every decoder supporting this. -- 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 4/4 v2] avcodec/h264dec: add support for LCEVC enhancement
On 7/26/2024 9:19 AM, Anton Khirnov wrote: Quoting James Almer (2024-07-26 14:10:46) On 7/26/2024 4:55 AM, Anton Khirnov wrote: Quoting James Almer (2024-07-22 00:53:50) Signed-off-by: James Almer --- configure | 2 +- libavcodec/avcodec.h | 5 + libavcodec/h264_picture.c | 1 + libavcodec/h264_slice.c | 15 ++ libavcodec/h264dec.c | 41 --- libavcodec/h264dec.h | 3 +++ 6 files changed, 63 insertions(+), 4 deletions(-) Does this need to be integrated into individual decoders? Can't the generic path apply it based on the presence of AV_FRAME_DATA_LCEVC sdide data and AV_CODEC_EXPORT_DATA_ENHANCEMENTS being set? Individual decoders still need to be aware of lcevc metadata being present to do things like allocating the output frame, because afaik i can't call get_buffer2() from the main/user thread. So is it worth moving things to the generic code when DR1 decoders will still need extra considerations? Can it not be handled in ff_get_buffer()? And even if not - there'd still be a lot less code that needs to be duplicated across every decoder supporting this. I'll try 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".
[FFmpeg-devel] [PATCH 0/1] lavc/exr: decode_block() fails when input resolution not
From: Sean Devonport This fixes the commit message body wrapping between lines 60 and 72 Sean Devonport (1): lavc/exr: decode_block() fails when input resolution not exactly divisable by 8 libavcodec/exr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.39.3 (Apple Git-146) ___ 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/1] lavc/exr: decode_block() fails when input resolution not exactly divisable by 8
From: Sean Devonport This stops decode_block() from failing when the .exr resolution is not divisable by 8 (e.g 108x192). The dc_w and dc_h needs to be round up and not down. --- libavcodec/exr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/exr.c b/libavcodec/exr.c index 4bac0be89b..5df2c55609 100644 --- a/libavcodec/exr.c +++ b/libavcodec/exr.c @@ -987,8 +987,8 @@ static int dwa_uncompress(const EXRContext *s, const uint8_t *src, int compresse int64_t version, lo_usize, lo_size; int64_t ac_size, dc_size, rle_usize, rle_csize, rle_raw_size; int64_t ac_count, dc_count, ac_compression; -const int dc_w = td->xsize >> 3; -const int dc_h = td->ysize >> 3; +const int dc_w = (td->xsize + 7) >> 3; +const int dc_h = (td->ysize + 7) >> 3; GetByteContext gb, agb; int skip, ret; -- 2.39.3 (Apple Git-146) ___ 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 0/1] lavc/exr: decode_block() fails when input resolution not
From: Sean Devonport Fixes word wrap in commit message Sean Devonport (1): lavc/exr: decode_block() fails when input resolution not exactly divisable by 8 libavcodec/exr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.39.3 (Apple Git-146) ___ 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/1] lavc/exr: decode_block() fails when input resolution not exactly divisable by 8
From: Sean Devonport This stops decode_block() from failing when the .exr resolution is not divisable by 8 (e.g 108x192). The dc_w and dc_h needs to be round up and not down. --- libavcodec/exr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/exr.c b/libavcodec/exr.c index 4bac0be89b..5df2c55609 100644 --- a/libavcodec/exr.c +++ b/libavcodec/exr.c @@ -987,8 +987,8 @@ static int dwa_uncompress(const EXRContext *s, const uint8_t *src, int compresse int64_t version, lo_usize, lo_size; int64_t ac_size, dc_size, rle_usize, rle_csize, rle_raw_size; int64_t ac_count, dc_count, ac_compression; -const int dc_w = td->xsize >> 3; -const int dc_h = td->ysize >> 3; +const int dc_w = (td->xsize + 7) >> 3; +const int dc_h = (td->ysize + 7) >> 3; GetByteContext gb, agb; int skip, ret; -- 2.39.3 (Apple Git-146) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavu/common: use fabs(f) for FFABS/FFNABS
The absolute value of a floating point value is easier to calculate than that of an integer: it is obtained by either clearing the sign or xoring it with itself. Accordingly, Arm, LoongArch, RISC-V have dedicated instructions to manipulate float sign bits. x86-64 has ANDPS. As per C11 appendix F, FFABS() is not quite the same as fabs() however, due to differing NaN handling. GCC is able to optimise the current FFABS definition to match fabs() anyway with just -fno-signed-zeros. But Clang is evidently not doing so and inserts a comparison with 0 and a conditional select or branch. Now that we have C11, this is easy to fix properly. (Another option is to manually audit which of the ~880 FFABS/FFNABS use sites involve floating point values.) Note that this still preserves the old definitions for C++ and pre-C11 compilers since the 2 macros are public (even though they start with FF). --- libavutil/common.h | 14 ++ 1 file changed, 14 insertions(+) diff --git a/libavutil/common.h b/libavutil/common.h index 3b830daf30..48761885fb 100644 --- a/libavutil/common.h +++ b/libavutil/common.h @@ -71,7 +71,14 @@ * as with *abs() * @see FFNABS() */ +#if !defined (__cplusplus) && __STDC_VERSION__ >= 201112L +#define FFABS(a) _Generic(a, \ + float: fabsf(a), \ + double: fabs(a), \ + default: ((a) >= 0) ? (a) : (-(a))) +#else #define FFABS(a) ((a) >= 0 ? (a) : (-(a))) +#endif #define FFSIGN(a) ((a) > 0 ? 1 : -1) /** @@ -80,7 +87,14 @@ * As with many macros, this evaluates its argument twice, it thus must not have * a sideeffect, that is FFNABS(x++) has undefined behavior. */ +#if !defined (__cplusplus) && __STDC_VERSION__ >= 201112L +#define FFNABS(a) _Generic(a, \ + float: -fabsf(a), \ + double: -fabs(a), \ + default: ((a) <= 0) ? (a) : (-(a))) +#else #define FFNABS(a) ((a) <= 0 ? (a) : (-(a))) +#endif /** * Unsigned Absolute value. -- 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/vp8: Maintain consistency of frame pointers
Right now it is possible for the pointer for the current frame to
be set in the context even when it could not be properly set up;
this does not influence various the ordinary ref frames, but only
VP8Context.prev_frame. And since this code has been ported to the
ProgressFrame API in d48d7bc434f30dfbdf346f16715e4f2044b3e000,
this leads to segfaults, because the ProgressFrame API is less
forgiving than the ThreadFrame API (waiting on an uninitialized
ProgressFrame segfaults, waiting on an uninitialized ThreadFrame
is a no-op (the code behaves as if frame-threading is not in use)).
Fix this by maintaining the consistency of the frame pointers
in the context (by setting them later).
Fixes: NULL pointer dereference
Fixes:
68192/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP8_fuzzer-6180311026171904
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp8.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index d6df018655..8945447eb6 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -541,9 +541,12 @@ static int vp7_fade_frame(VP8Context *s, int alpha, int
beta)
/* preserve the golden frame, write a new previous frame */
if (s->framep[VP8_FRAME_GOLDEN] == s->framep[VP8_FRAME_PREVIOUS]) {
-s->framep[VP8_FRAME_PREVIOUS] = vp8_find_free_buffer(s);
-if ((ret = vp8_alloc_frame(s, s->framep[VP8_FRAME_PREVIOUS], 1)) <
0)
+VP8Frame *prev_frame = vp8_find_free_buffer(s);
+
+ret = vp8_alloc_frame(s, prev_frame, 1);
+if (ret < 0)
return ret;
+s->framep[VP8_FRAME_PREVIOUS] = prev_frame;
dst = s->framep[VP8_FRAME_PREVIOUS]->tf.f;
@@ -2699,7 +2702,7 @@ int vp78_decode_frame(AVCodecContext *avctx, AVFrame
*rframe, int *got_frame,
&s->frames[i] != s->framep[VP8_FRAME_ALTREF])
vp8_release_frame(&s->frames[i]);
-curframe = s->framep[VP8_FRAME_CURRENT] = vp8_find_free_buffer(s);
+curframe = vp8_find_free_buffer(s);
if (!s->colorspace)
avctx->colorspace = AVCOL_SPC_BT470BG;
@@ -2723,6 +2726,7 @@ int vp78_decode_frame(AVCodecContext *avctx, AVFrame
*rframe, int *got_frame,
if ((ret = vp8_alloc_frame(s, curframe, referenced)) < 0)
goto err;
+s->framep[VP8_FRAME_CURRENT] = curframe;
if (s->keyframe)
curframe->tf.f->flags |= AV_FRAME_FLAG_KEY;
else
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avformat/mov: Check sample_sizes before using it
Fixes: NULL pointer dereference Fixes: 70569/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5247918563459072 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/mov.c | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/mov.c b/libavformat/mov.c index b74e43e2140..63db7d59a58 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -10060,6 +10060,10 @@ static int mov_read_header(AVFormatContext *s) st = item->st; sc = st->priv_data; + +if (!sc->sample_sizes || !sc->sample_count) +return AVERROR_INVALIDDATA; + st->codecpar->width = item->width; st->codecpar->height = item->height; -- 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 2/3] avcodec/adpcm: Make sample count computation match code accesing samplesfor AV_CODEC_ID_ADPCM_DTK
Fixes: out of array access Fixes: 70618/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_DTK_fuzzer-4814907107770368 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/adpcm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c index afdbeaa15ee..8f9a8a8c8e2 100644 --- a/libavcodec/adpcm.c +++ b/libavcodec/adpcm.c @@ -1050,6 +1050,8 @@ static int get_nb_samples(AVCodecContext *avctx, GetByteContext *gb, nb_samples = buf_size / (21 * ch) * 32; break; case AV_CODEC_ID_ADPCM_DTK: +nb_samples = buf_size / 32 * 28; +break; case AV_CODEC_ID_ADPCM_PSX: nb_samples = buf_size / (16 * ch) * 28; break; -- 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 3/3] avcodec/adpcm: Remove setting min_channel to value it is already set to
Signed-off-by: Michael Niedermayer --- libavcodec/adpcm.c | 4 1 file changed, 4 deletions(-) diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c index 8f9a8a8c8e2..6c53d0bcf39 100644 --- a/libavcodec/adpcm.c +++ b/libavcodec/adpcm.c @@ -260,10 +260,6 @@ static av_cold int adpcm_decode_init(AVCodecContext * avctx) case AV_CODEC_ID_ADPCM_IMA_AMV: max_channels = 1; break; -case AV_CODEC_ID_ADPCM_DTK: -case AV_CODEC_ID_ADPCM_EA: -min_channels = 1; -break; case AV_CODEC_ID_ADPCM_AFC: case AV_CODEC_ID_ADPCM_EA_R1: case AV_CODEC_ID_ADPCM_EA_R2: -- 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".
Re: [FFmpeg-devel] [PATCH v4 1/3] avcodec/jpeg2000dec: Add support for CAP and CPF markers
On Fri, Jul 26, 2024 at 1:04 AM Tomas Härdin wrote: > > tor 2024-07-25 klockan 17:06 -0700 skrev Pierre-Anthony Lemieux: > > On Thu, Jul 25, 2024 at 2:17 AM Tomas Härdin wrote: > > > > > > sön 2024-07-21 klockan 14:07 +0900 skrev Pierre-Anthony Lemieux: > > > > On Sat, Jul 20, 2024 at 5:12 PM Tomas Härdin > > > > wrote: > > > > > > > > > > tor 2024-07-18 klockan 23:10 +0900 skrev Pierre-Anthony > > > > > Lemieux: > > > > > > On Mon, Jul 15, 2024 at 10:33 PM Tomas Härdin > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > fre 2024-07-12 klockan 12:51 -0700 skrev Pierre-Anthony > > > > > > > Lemieux: > > > > > > > > On Thu, Jul 11, 2024 at 10:28 PM Tomas Härdin > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > +if (s->in_tile_headers == 1 && s->isHT > > > > > > > > > > && > > > > > > > > > > (!s- > > > > > > > > > > > Ccap15_b11)) > > > > > > > > > > +av_log(s->avctx, AV_LOG_WARNING, > > > > > > > > > > "COD > > > > > > > > > > marker > > > > > > > > > > is > > > > > > > > > > found in HOMOGENEOUS HT set\n"); > > > > > > > > > > > > > > > > > > How bad is this and the other markers being present in > > > > > > > > > this > > > > > > > > > case? > > > > > > > > > > > > > > > > At the very least, it means that signaling is > > > > > > > > inconsistent > > > > > > > > within > > > > > > > > the > > > > > > > > codestream since the standard states that: > > > > > > > > """ > > > > > > > > The HOMOGENEOUS set is the set of HTJ2K codestreams > > > > > > > > where: > > > > > > > > • none of the functional marker segments, e.g., COD, COC, > > > > > > > > RGN, > > > > > > > > QCD, > > > > > > > > QCC, and POC, are present in any > > > > > > > > tile-part header; and > > > > > > > > • no PPT marker segment is present. > > > > > > > > """ > > > > > > > > > > > > > > > > The point of signalling that a codestream is > > > > > > > > "HOMOGENEOUS" is > > > > > > > > to > > > > > > > > allow > > > > > > > > decoders to configure themselves solely based on > > > > > > > > information > > > > > > > > retrieved > > > > > > > > entirely from the main header. > > > > > > > > > > > > > > > > Since, AFAIK, FFMPEG does not rely on the HOMOGENEOUS to > > > > > > > > short- > > > > > > > > circuit > > > > > > > > configuration, incorrect HOMOGENEOUS signalling will > > > > > > > > likely > > > > > > > > not > > > > > > > > impact > > > > > > > > FFMPEG. > > > > > > > > > > > > > > It could happen that information in tile headers contradict > > > > > > > information > > > > > > > in the main header, right? In such a case it sounds like we > > > > > > > can't > > > > > > > be > > > > > > > sure which decode is the correct one. > > > > > > > > > > > > Per the spec, the decoder uses the COD information in tile- > > > > > > parts > > > > > > over > > > > > > the COD information in the header. > > > > > > > > > > > > The issue here is that a decoder, upon seeing HOMOGENEOUS, > > > > > > simply > > > > > > does > > > > > > not bother with looking for COD information in tile-parts, > > > > > > thereby > > > > > > missing critical information. > > > > > > > > > > So it is actually perfectly legal? Then it seems this patch is > > > > > wrong > > > > > > > > What is not "illegal": the HOMOGENEOUS flag being equal to true > > > > *and* > > > > having COD marker segments in tile-parts. > > > > > > > > This is what the patch detects. > > > > > > > > FFMPEG can decode such illegal codestream. Other decoders might > > > > not. > > > > > > > > The question is: what should FFMPEG do? Should FFMPEG exit or > > > > warn > > > > and continue. > > > > > > If the spec allows it but it's perhaps unadviced then warning about > > > it > > > seems reasonable > > > > (I totally messed up my double negative. Repeat below. Sorry for the > > confusion.) > > > > What is "illegal": the HOMOGENEOUS flag being equal to true *and* > > having COD marker segments in tile-parts. > > > > This is what the patch detects. > > > > FFMPEG can decode such illegal codestream. Other decoders might not. > > > > The question is: what should FFMPEG do? Should FFMPEG exit or warn > > and continue. > > Since it's illegal then we should complain and bail out. Users that > *really* want it to keep going can change the code. @Osamu Watanabe Can you update the patch to make FFMPEG exit when encountering an illegal codestream, even if FFMPEG can theoretically decode it? > > /Tomas > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 1/3] avcodec/jpeg2000dec: Add support for CAP and CPF markers
On Thu, Jul 25, 2024 at 05:06:04PM -0700, Pierre-Anthony Lemieux wrote: > On Thu, Jul 25, 2024 at 2:17 AM Tomas Härdin wrote: > > > > sön 2024-07-21 klockan 14:07 +0900 skrev Pierre-Anthony Lemieux: > > > On Sat, Jul 20, 2024 at 5:12 PM Tomas Härdin wrote: > > > > > > > > tor 2024-07-18 klockan 23:10 +0900 skrev Pierre-Anthony Lemieux: > > > > > On Mon, Jul 15, 2024 at 10:33 PM Tomas Härdin > > > > > wrote: > > > > > > > > > > > > fre 2024-07-12 klockan 12:51 -0700 skrev Pierre-Anthony > > > > > > Lemieux: > > > > > > > On Thu, Jul 11, 2024 at 10:28 PM Tomas Härdin > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > +if (s->in_tile_headers == 1 && s->isHT && > > > > > > > > > (!s- > > > > > > > > > > Ccap15_b11)) > > > > > > > > > +av_log(s->avctx, AV_LOG_WARNING, "COD > > > > > > > > > marker > > > > > > > > > is > > > > > > > > > found in HOMOGENEOUS HT set\n"); > > > > > > > > > > > > > > > > How bad is this and the other markers being present in this > > > > > > > > case? > > > > > > > > > > > > > > At the very least, it means that signaling is inconsistent > > > > > > > within > > > > > > > the > > > > > > > codestream since the standard states that: > > > > > > > """ > > > > > > > The HOMOGENEOUS set is the set of HTJ2K codestreams where: > > > > > > > • none of the functional marker segments, e.g., COD, COC, > > > > > > > RGN, > > > > > > > QCD, > > > > > > > QCC, and POC, are present in any > > > > > > > tile-part header; and > > > > > > > • no PPT marker segment is present. > > > > > > > """ > > > > > > > > > > > > > > The point of signalling that a codestream is "HOMOGENEOUS" is > > > > > > > to > > > > > > > allow > > > > > > > decoders to configure themselves solely based on information > > > > > > > retrieved > > > > > > > entirely from the main header. > > > > > > > > > > > > > > Since, AFAIK, FFMPEG does not rely on the HOMOGENEOUS to > > > > > > > short- > > > > > > > circuit > > > > > > > configuration, incorrect HOMOGENEOUS signalling will likely > > > > > > > not > > > > > > > impact > > > > > > > FFMPEG. > > > > > > > > > > > > It could happen that information in tile headers contradict > > > > > > information > > > > > > in the main header, right? In such a case it sounds like we > > > > > > can't > > > > > > be > > > > > > sure which decode is the correct one. > > > > > > > > > > Per the spec, the decoder uses the COD information in tile-parts > > > > > over > > > > > the COD information in the header. > > > > > > > > > > The issue here is that a decoder, upon seeing HOMOGENEOUS, simply > > > > > does > > > > > not bother with looking for COD information in tile-parts, > > > > > thereby > > > > > missing critical information. > > > > > > > > So it is actually perfectly legal? Then it seems this patch is > > > > wrong > > > > > > What is not "illegal": the HOMOGENEOUS flag being equal to true *and* > > > having COD marker segments in tile-parts. > > > > > > This is what the patch detects. > > > > > > FFMPEG can decode such illegal codestream. Other decoders might not. > > > > > > The question is: what should FFMPEG do? Should FFMPEG exit or warn > > > and continue. > > > > If the spec allows it but it's perhaps unadviced then warning about it > > seems reasonable > > (I totally messed up my double negative. Repeat below. Sorry for the > confusion.) > > What is "illegal": the HOMOGENEOUS flag being equal to true *and* > having COD marker segments in tile-parts. > > This is what the patch detects. > > FFMPEG can decode such illegal codestream. Other decoders might not. > > The question is: what should FFMPEG do? Should FFMPEG exit or warn and > continue. Does such a codestream actually exist ? I mean is this just a hypothetical case or something existing ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart than the original author, trying to rewrite it will not make it better. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 1/3] avcodec/jpeg2000dec: Add support for CAP and CPF markers
On Fri, Jul 26, 2024 at 2:29 PM Michael Niedermayer wrote: > > On Thu, Jul 25, 2024 at 05:06:04PM -0700, Pierre-Anthony Lemieux wrote: > > On Thu, Jul 25, 2024 at 2:17 AM Tomas Härdin wrote: > > > > > > sön 2024-07-21 klockan 14:07 +0900 skrev Pierre-Anthony Lemieux: > > > > On Sat, Jul 20, 2024 at 5:12 PM Tomas Härdin wrote: > > > > > > > > > > tor 2024-07-18 klockan 23:10 +0900 skrev Pierre-Anthony Lemieux: > > > > > > On Mon, Jul 15, 2024 at 10:33 PM Tomas Härdin > > > > > > wrote: > > > > > > > > > > > > > > fre 2024-07-12 klockan 12:51 -0700 skrev Pierre-Anthony > > > > > > > Lemieux: > > > > > > > > On Thu, Jul 11, 2024 at 10:28 PM Tomas Härdin > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > +if (s->in_tile_headers == 1 && s->isHT && > > > > > > > > > > (!s- > > > > > > > > > > > Ccap15_b11)) > > > > > > > > > > +av_log(s->avctx, AV_LOG_WARNING, "COD > > > > > > > > > > marker > > > > > > > > > > is > > > > > > > > > > found in HOMOGENEOUS HT set\n"); > > > > > > > > > > > > > > > > > > How bad is this and the other markers being present in this > > > > > > > > > case? > > > > > > > > > > > > > > > > At the very least, it means that signaling is inconsistent > > > > > > > > within > > > > > > > > the > > > > > > > > codestream since the standard states that: > > > > > > > > """ > > > > > > > > The HOMOGENEOUS set is the set of HTJ2K codestreams where: > > > > > > > > • none of the functional marker segments, e.g., COD, COC, > > > > > > > > RGN, > > > > > > > > QCD, > > > > > > > > QCC, and POC, are present in any > > > > > > > > tile-part header; and > > > > > > > > • no PPT marker segment is present. > > > > > > > > """ > > > > > > > > > > > > > > > > The point of signalling that a codestream is "HOMOGENEOUS" is > > > > > > > > to > > > > > > > > allow > > > > > > > > decoders to configure themselves solely based on information > > > > > > > > retrieved > > > > > > > > entirely from the main header. > > > > > > > > > > > > > > > > Since, AFAIK, FFMPEG does not rely on the HOMOGENEOUS to > > > > > > > > short- > > > > > > > > circuit > > > > > > > > configuration, incorrect HOMOGENEOUS signalling will likely > > > > > > > > not > > > > > > > > impact > > > > > > > > FFMPEG. > > > > > > > > > > > > > > It could happen that information in tile headers contradict > > > > > > > information > > > > > > > in the main header, right? In such a case it sounds like we > > > > > > > can't > > > > > > > be > > > > > > > sure which decode is the correct one. > > > > > > > > > > > > Per the spec, the decoder uses the COD information in tile-parts > > > > > > over > > > > > > the COD information in the header. > > > > > > > > > > > > The issue here is that a decoder, upon seeing HOMOGENEOUS, simply > > > > > > does > > > > > > not bother with looking for COD information in tile-parts, > > > > > > thereby > > > > > > missing critical information. > > > > > > > > > > So it is actually perfectly legal? Then it seems this patch is > > > > > wrong > > > > > > > > What is not "illegal": the HOMOGENEOUS flag being equal to true *and* > > > > having COD marker segments in tile-parts. > > > > > > > > This is what the patch detects. > > > > > > > > FFMPEG can decode such illegal codestream. Other decoders might not. > > > > > > > > The question is: what should FFMPEG do? Should FFMPEG exit or warn > > > > and continue. > > > > > > If the spec allows it but it's perhaps unadviced then warning about it > > > seems reasonable > > > > (I totally messed up my double negative. Repeat below. Sorry for the > > confusion.) > > > > What is "illegal": the HOMOGENEOUS flag being equal to true *and* > > having COD marker segments in tile-parts. > > > > This is what the patch detects. > > > > FFMPEG can decode such illegal codestream. Other decoders might not. > > > > The question is: what should FFMPEG do? Should FFMPEG exit or warn and > > continue. > > Does such a codestream actually exist ? I mean is this just a hypothetical > case > or something existing ? Such a codestream exists: a codestream with the HOMOGENEOUS flag equal to true *and* COD marker segments in tile-parts is "illegal" per the specification. Such a codestream may cause certain decoders (esp. hardware decoders) to fail because, based on the value of the HOMOGENEOUS flag, they will not expect COD marker segments in tile-parts. FFMPEG will not fail, because it does not use the value of the HOMOGENEOUS flag to configure itself. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Rewriting code that is poorly written but fully understood is good. > Rewriting code that one doesnt understand is a sign that one is less smart > than the original author, trying to rewrite it will not make it better. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsu
Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Check sample_sizes before using it
On 7/26/2024 6:08 PM, Michael Niedermayer wrote: Fixes: NULL pointer dereference Fixes: 70569/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5247918563459072 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/mov.c | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/mov.c b/libavformat/mov.c index b74e43e2140..63db7d59a58 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -10060,6 +10060,10 @@ static int mov_read_header(AVFormatContext *s) st = item->st; sc = st->priv_data; + +if (!sc->sample_sizes || !sc->sample_count) +return AVERROR_INVALIDDATA; Deja vu. Didn't you send something like this before? Also, can i get the sample? As with other issues, we shouldn't reach this point if these were not allocated. + st->codecpar->width = item->width; st->codecpar->height = item->height; ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Check sample_sizes before using it
On 7/26/2024 7:11 PM, James Almer wrote: On 7/26/2024 6:08 PM, Michael Niedermayer wrote: Fixes: NULL pointer dereference Fixes: 70569/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5247918563459072 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/mov.c | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/mov.c b/libavformat/mov.c index b74e43e2140..63db7d59a58 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -10060,6 +10060,10 @@ static int mov_read_header(AVFormatContext *s) st = item->st; sc = st->priv_data; + + if (!sc->sample_sizes || !sc->sample_count) + return AVERROR_INVALIDDATA; Deja vu. Didn't you send something like this before? Also, can i get the sample? As with other issues, we shouldn't reach No, it was me: https://ffmpeg.org//pipermail/ffmpeg-devel/2024-June/330391.html Still, i want to check the sample because i'm not sure how this code is reached like this. this point if these were not allocated. + st->codecpar->width = item->width; st->codecpar->height = item->height; ___ 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 0/1] lavfi/vf_gopromax_opencl: add GoPor Max 360 video filter
This is updated patch of: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=3943 I contacted to Ronan LE MEILLAT and agreed with him to submit new patch. Abstruct of GoPro Max .360 video file format is described in: https://gopro.com/news/max-tech-specs-stitching-resolution The specification is little bit buggy. The format is based on EAC (Equi-Angular Cubemap), and there are overlapped pixels at boundaries of front and rear cams. Probably, the desinger intended to add 2 x 32 (= total 64) ovelapped pixels. But actual format has 2 x 64 pixels overlapped area. Thus the width will be 2 x 32 pixels shorter than standard EAC format after blending overlapped area. This filter brends overlapped area, stretches the width of the cube, and combine two streams into single stream with standard format. TADANO Tokumei (1): lavfi/vf_gopromax_opencl: add GoPor Max 360 video filter doc/filters.texi | 78 +++ libavfilter/Makefile | 2 + libavfilter/allfilters.c | 1 + libavfilter/opencl/gopromax.cl | 280 libavfilter/opencl_source.h | 1 + libavfilter/vf_gopromax_opencl.c | 351 +++ 6 files changed, 713 insertions(+) create mode 100644 libavfilter/opencl/gopromax.cl create mode 100644 libavfilter/vf_gopromax_opencl.c -- 2.39.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 v2 1/1] lavfi/vf_gopromax_opencl: add GoPor Max 360 video filter
Add an OpenCL filter for filtering GoPro Max native .360 files
into standard equirectangular or youtube equiangular cubemap (eac)
projection.
The .360 file contains separated two video streams.
This filter combine two streams into single stream with standard
format.
---
doc/filters.texi | 78 +++
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 1 +
libavfilter/opencl/gopromax.cl | 280
libavfilter/opencl_source.h | 1 +
libavfilter/vf_gopromax_opencl.c | 351 +++
6 files changed, 713 insertions(+)
create mode 100644 libavfilter/opencl/gopromax.cl
create mode 100644 libavfilter/vf_gopromax_opencl.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 2585d818ff..dd9ab47686 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -27101,6 +27101,84 @@ Apply dilation filter with threshold0 set to 30,
threshold1 set 40, threshold2 s
@end example
@end itemize
+@anchor{gopromax_opencl}
+@section gopromax_opencl
+
+Apply transformation of the two GoPro Max video streams to equirectangular or
equiangular-cubemap projection.
+
+This filter is designed to use directly GoPro .360 files.
+Native .360 files are sort of EAC files, in fact the front and rear lenses
streams are the top and the bottom of the EAC projection.
+
+The .360 file contains two video streams.
+Most of cases, one is stream #0:0, and the other is stream #0:5.
+Please check actual stream number with @code{ffprobe} command.
+This filter combine two streams to single stream.
+
+The .360 contains also 2x64 bits of overlapped area.
+The filter blends overlapped images in these two areas.
+
+The filter accepts the following options:
+
+@table @option
+
+@item output
+Set format of the output video.
+
+Available formats:
+
+@table @samp
+
+@item e
+@item equirect
+Equirectangular projection.
+
+@item eac
+Equi-Angular Cubemap.
+
+@end table
+
+Default is @code{equirect}.
+
+@item w
+@item h
+Set the output video resolution.
+
+Default resolution depends on formats.
+
+@item overlap
+Set number of overlapped pixels on input .360 video.
+
+No need to specify this option for native .360 video file.
+This option is for rescaled video or future video format change.
+
+Default is @code{64}.
+
+@end table
+
+@subsection Example
+
+@itemize
+@item
+Convert .360 to Equirectangular projection.
+@example
+-i INPUT -filter_complex '[0:0]hwupload[a], [0:5]hwupload[b],
[a][b]gopromax_opencl=w=4096:h=2048, hwdownload, format=yuvj420p' -map 0:a:0
-c:a copy OUTPUT
+@end example
+
+Two video streams (#0:0 and #0:5) are combined and converted to default
equirectangular projection with specified resolution.
+First audio stream (GoPro AAC) is copied with the video stream.
+
+@item
+Convert .360 to Equi-Angular Cubemap projection.
+@example
+-i INPUT -filter_complex '[0:0]hwupload[a], [0:5]hwupload[b],
[a][b]gopromax_opencl=eac, hwdownload, format=yuvj420p,
v360=eac:c3x2:w=1344:h=896' -map 0:1 -map 0:3 -c:a copy -c:u copy OUTPUT
+@end example
+
+Two video streams (#0:0 and #0:5) are combined and converted to equi-angular
cubemap projection,
+then it is converted to c3x2 cubemap projection and shrunk by v360 filter.
+Stream #0:1 (GoPro AAC) and stream #0:3 (GoPro MET) are copied with the video
stream.
+
+@end itemize
+
@anchor{nlmeans_opencl}
@section nlmeans_opencl
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 63088e9286..9b5fa78920 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -327,6 +327,8 @@ OBJS-$(CONFIG_FSYNC_FILTER) += vf_fsync.o
OBJS-$(CONFIG_GBLUR_FILTER) += vf_gblur.o
OBJS-$(CONFIG_GBLUR_VULKAN_FILTER) += vf_gblur_vulkan.o vulkan.o
vulkan_filter.o
OBJS-$(CONFIG_GEQ_FILTER)+= vf_geq.o
+OBJS-$(CONFIG_GOPROMAX_OPENCL_FILTER)+= vf_gopromax_opencl.o opencl.o \
+opencl/gopromax.o framesync.o
OBJS-$(CONFIG_GRADFUN_FILTER)+= vf_gradfun.o
OBJS-$(CONFIG_GRAPHMONITOR_FILTER) += f_graphmonitor.o
OBJS-$(CONFIG_GRAYWORLD_FILTER) += vf_grayworld.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 63600e9b58..5a517d8586 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -303,6 +303,7 @@ extern const AVFilter ff_vf_fsync;
extern const AVFilter ff_vf_gblur;
extern const AVFilter ff_vf_gblur_vulkan;
extern const AVFilter ff_vf_geq;
+extern const AVFilter ff_vf_gopromax_opencl;
extern const AVFilter ff_vf_gradfun;
extern const AVFilter ff_vf_graphmonitor;
extern const AVFilter ff_vf_grayworld;
diff --git a/libavfilter/opencl/gopromax.cl b/libavfilter/opencl/gopromax.cl
new file mode 100644
index 00..64d2afe31c
--- /dev/null
+++ b/libavfilter/opencl/gopromax.cl
@@ -0,0 +1,280 @@
+/*
+ * Copyright (c) 2021 Ronan LE MEILLAT
+ * Copyright (c) 2024 TADANO Tokumei
+ *
+ * This file is part of FFmpeg.
+ *
+
