Re: [FFmpeg-devel] [PATCH v2 3/3] avcodec/cuvid: introduce a ringbuffer to reattach additional data

2024-12-03 Thread Clément Péron
On Mon, 2 Dec 2024 at 13:01, Timo Rothenpieler  wrote:
>
> On 02/12/2024 12:03, Clément Péron wrote:
> > Hi Timo,
> >
> > I try to look deeper into this and compare it with others codec.
> > And I'm not 100% sure why only cuviddec, dav1d and xevd set this flag
> > "FF_CODEC_CAP_SETS_FRAME_PROPS"
> > I would expect also nvdec to set this, as by design the hardware could
> > buffer multiple packets and when the decoded frame is retrieve the
> > "avctx->internal->last_pkt_props" sync is not guarantee.
> >
> > I think we could simplify this patch a bit, reusing the FFmpeg ObjPool.
> > But I don't see how we could avoid this packet<->frame sync?
> >
> > Maybe we could try to move it out of the cuviddec,
> > So all this stuff should go in the decode.c and we should use this
> > pool buffer instead of only using the avctx->internal->last_pkt_props.
> >
> > As it could also impact other codec, is there some FFMpeg Maintainers
> > architect / maintainers feedback on this?
> >
> > Thanks,
>
> I don't quite understand why you are so insistent on adding it to
> cuviddec at all.
> This decoder is just barely not deprecated.
>
> If the native decoders and in turn the various hwaccels, including
> nvdec, don't support it, adding it there would be a much easier solution
> that adds support for a lot more hardware all at once.
> Most likely you won't even need to touch any hardware specific code.

I'm open to other suggestions and would be glad to find a solution
that works for all hardware decoders.

After browsing there is some custom implem for decklink and the
side_data timecode.
Which do exactly the same thing,
https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/decklink_dec.cpp#L1351-L1359

I will respin this series without this patch and start a dedicated
thread about this issue.

Thanks,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v2 3/3] avcodec/cuvid: introduce a ringbuffer to reattach additional data

2024-12-03 Thread Hendrik Leppkes
On Tue, Dec 3, 2024 at 12:54 PM Clément Péron  wrote:
>
> On Mon, 2 Dec 2024 at 13:01, Timo Rothenpieler  wrote:
> >
> > On 02/12/2024 12:03, Clément Péron wrote:
> > > Hi Timo,
> > >
> > > I try to look deeper into this and compare it with others codec.
> > > And I'm not 100% sure why only cuviddec, dav1d and xevd set this flag
> > > "FF_CODEC_CAP_SETS_FRAME_PROPS"
> > > I would expect also nvdec to set this, as by design the hardware could
> > > buffer multiple packets and when the decoded frame is retrieve the
> > > "avctx->internal->last_pkt_props" sync is not guarantee.
> > >
> > > I think we could simplify this patch a bit, reusing the FFmpeg ObjPool.
> > > But I don't see how we could avoid this packet<->frame sync?
> > >
> > > Maybe we could try to move it out of the cuviddec,
> > > So all this stuff should go in the decode.c and we should use this
> > > pool buffer instead of only using the avctx->internal->last_pkt_props.
> > >
> > > As it could also impact other codec, is there some FFMpeg Maintainers
> > > architect / maintainers feedback on this?
> > >
> > > Thanks,
> >
> > I don't quite understand why you are so insistent on adding it to
> > cuviddec at all.
> > This decoder is just barely not deprecated.
> >
> > If the native decoders and in turn the various hwaccels, including
> > nvdec, don't support it, adding it there would be a much easier solution
> > that adds support for a lot more hardware all at once.
> > Most likely you won't even need to touch any hardware specific code.
>
> I'm open to other suggestions and would be glad to find a solution
> that works for all hardware decoders.
>

The real question is, why are you using cuviddec instead of nvdec?
side data would already pass through natively with nvdec, and other
hwaccel-based decoders.

- 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] [PATCH v2 00/11] fix broken CC detection and ffprobe fields (cover letter)

2024-12-03 Thread Anton Khirnov
Quoting James Almer (2024-12-01 20:59:10)
> I don't agree it should be in codecpar. It's rarely (if ever) filled 
> during header parsing (codec or container), and instead set when parsing 
> a frame that contains the relevant characteristic that's exported here 
> as a "property", like captions or film grain parameters. Therefore it's 
> not a field used for initialization.

That semantics would be useless, since you can just as well extract the
same information from the frame itself.

-- 
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 3/6] lavc/vvc: Store MIP information over entire CU area

2024-12-03 Thread Nuo Mi
Hi Frank,
Thank you for the patch

On Sat, Nov 30, 2024 at 8:13 PM Frank Plowman  wrote:

> On 30/11/2024 06:46, Nuo Mi wrote:
> > On Fri, Nov 29, 2024 at 6:19 AM Frank Plowman 
> wrote:
> >
> >> Previously, the code only stored the MIP mode and transpose flag in the
> >> relevant tables at the top-left corner of the CU.  This information ends
> >> up being retrieved in ff_vvc_intra_pred_* not based on the CU position
> >> but instead the transform unit position (specifically, using the x0 and
> >> y0 from get_luma_predict_unit).  There might be multiple transform units
> >> in a CU, hence the top-left corner of the transform unit might not
> >> coincide with the top-left corner of the CU.  Consequently, we need to
> >> store the MIP information at all positions in the CU, not only its
> >> top-left corner, as we already do for the MIP flag.
> >>
> >> Signed-off-by: Frank Plowman 
> >> ---
> >>  libavcodec/vvc/ctu.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
> >> index 1e06119cfd..0030938cf5 100644
> >> --- a/libavcodec/vvc/ctu.c
> >> +++ b/libavcodec/vvc/ctu.c
> >> @@ -975,8 +975,8 @@ static void intra_luma_pred_modes(VVCLocalContext
> *lc)
> >>  for (int y = 0; y < (cb_height>>log2_min_cb_size); y++) {
> >>  int width = cb_width>>log2_min_cb_size;
> >>  memset(&fc->tab.imf[x],  cu->intra_mip_flag, width);
> >> -fc->tab.imtf[x] = intra_mip_transposed_flag;
> >> -fc->tab.imm[x]  = intra_mip_mode;
> >> +memset(&fc->tab.imtf[x], intra_mip_transposed_flag,
> >> width);
> >> +memset(&fc->tab.imm[x], intra_mip_mode, width);
> >
> >  intra_mip_mode is 4 bits, 2 flags are 2 bits. maybe we can use a uint8_t
> > for 3 fields,
> > We only need 1 memset and save 2/3 memory.
>
> I've implemented this (patch attached, to be applied atop the set), but
> it's not as straightforward as it may seem.  In particular, because the
> tables are read directly from when determining which CABAC context to
> use for these flags, we have to add quite a lot of extra code in cabac.c
> to support this special case where the MIP information is a bit field.
> In my implementation, this was done by adding this coerce_to_bool
> parameter to get_inc and get_top.  This does actually save a moderate
> amount of memory though, ~1MB for 4K and ~256kB for 1080p.
>
A coding block can be as small as 4x4, so for a 1080p frame, the memory
required is approximately  2*1920*1080/(4*4) ~= 256 kB.
However, with a maximum delay of 16 frames, the total memory usage will be
256kB * 16=4 MB.

In your patch, coerce_to_bool is set to 1 only when we are in
ff_vvc_intra_mip_flag.
How about defining get_mip_inc like this? This way, we can avoid changing
get_inc

static av_always_inline
uint8_t get_mip_inc (VVCLocalContext *lc, const uint8_t *ctx)
{
uint8_t left = 0, top = 0;
get_left_top(lc, &left, &top, lc->cu->x0, lc->cu->y0, ctx, ctx);
return !!left + !!top;
}

BTW: Using pack_mip_info/unpack_mip_info might be shorter and more concise
than structure_mip_info/destructure_mip_info.

>
> >
> >>
> >
> >  x += pps->min_cb_width;
> >>  }
> >>  cu->intra_pred_mode_y = intra_mip_mode;
> >> --
> >> 2.47.0
> >>
>
>
> --
> Frank
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] avcodec/cbs_h266: Fix typo

2024-12-03 Thread Nuo Mi
Thank you Alexander and Franek,
Applied

On Mon, Dec 2, 2024 at 5:44 AM Frank Plowman  wrote:

> On 01/12/2024 19:44, Alexander Strasser via ffmpeg-devel wrote:
> > Introduced in commit 98698ed3c24bfd0b1e6e6db943b5f25f6046cee7
> >
> > Fixes: CID1635788 CID1635789
> > Signed-off-by: Alexander Strasser 
> > ---
> >
> > Just picked this up because of Coverity.
> > Not sure how to verify/test this change, but it seems plausible.
> >
> >   Alexander
> >
> >  libavcodec/cbs_h266_syntax_template.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/cbs_h266_syntax_template.c
> b/libavcodec/cbs_h266_syntax_template.c
> > index 43def9220f..029fbd5e4f 100644
> > --- a/libavcodec/cbs_h266_syntax_template.c
> > +++ b/libavcodec/cbs_h266_syntax_template.c
> > @@ -1151,7 +1151,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx,
> RWContext *rw,
> >  else
> >  infer(sps_subpic_width_minus1[0], max_width_minus1);
> >  if (current->sps_pic_height_max_in_luma_samples >
> ctb_size_y)
> > -us(hlen, sps_subpic_height_minus1[0], 0,
> max_width_minus1, 1, 0);
> > +us(hlen, sps_subpic_height_minus1[0], 0,
> max_height_minus1, 1, 0);
> >  else
> >  infer(sps_subpic_height_minus1[0], max_height_minus1);
> >  if (!current->sps_independent_subpics_flag) {
> > --
> > ___
> > 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".
>
> Looks good to me.
>
> Thanks,
> Frank
>
> ___
> 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 4/8] swscale/range_convert: fix mpeg ranges in yuv range conversion for non-8-bit pixel formats

2024-12-03 Thread Ramiro Polla
On Tue, Dec 3, 2024 at 3:35 AM Michael Niedermayer
 wrote:
> On Sun, Dec 01, 2024 at 07:20:06PM +0100, Ramiro Polla wrote:
> > There is an issue with the constants used in YUV to YUV range conversion,
> > where the upper bound is not respected when converting to mpeg range.
> >
> > With this commit, the constants are calculated at runtime, depending on
> > the bit depth. This approach also allows us to more easily understand how
> > the constants are derived.
> >
> > For bit depths <= 14, the number of fixed point bits has been set to 14
> > for all conversions, to simplify the code.
> > For bit depths > 14, the number of fixed points bits has been raised and
> > set to 18, to allow for the conversion to be accurate enough for the mpeg
> > range to be respected.
> >
> > The convert functions now take the conversion constants (coeff and offset)
> > as function arguments.
> > For bit depths <= 14, coeff is unsigned 16-bit and offset is 32-bit.
> > For bit depths > 14, coeff is unsigned 32-bit and offset is 64-bit.
> >
> > x86_64:
> > chrRangeFromJpeg8_1920_c:2127.4   2125.0  (1.00x)
> > chrRangeFromJpeg16_1920_c:   2325.2   2127.2  (1.09x)
> > chrRangeToJpeg8_1920_c:  3166.9   3168.7  (1.00x)
> > chrRangeToJpeg16_1920_c: 2152.4   3164.8  (0.68x)
> > lumRangeFromJpeg8_1920_c:1263.0   1302.5  (0.97x)
> > lumRangeFromJpeg16_1920_c:   1080.5   1299.2  (0.83x)
> > lumRangeToJpeg8_1920_c:  1886.8   2112.2  (0.89x)
> > lumRangeToJpeg16_1920_c: 1077.0   1906.5  (0.56x)
> >
> > aarch64 A55:
> > chrRangeFromJpeg8_1920_c:   28835.2  28835.6  (1.00x)
> > chrRangeFromJpeg16_1920_c:  28839.8  32680.8  (0.88x)
> > chrRangeToJpeg8_1920_c: 23074.7  23075.4  (1.00x)
> > chrRangeToJpeg16_1920_c:17318.9  24996.0  (0.69x)
> > lumRangeFromJpeg8_1920_c:   15389.7  15384.5  (1.00x)
> > lumRangeFromJpeg16_1920_c:  15388.2  17306.7  (0.89x)
> > lumRangeToJpeg8_1920_c: 19227.8  19226.6  (1.00x)
> > lumRangeToJpeg16_1920_c:15387.0  21146.3  (0.73x)
> >
> > aarch64 A76:
> > chrRangeFromJpeg8_1920_c:6324.4   6268.1  (1.01x)
> > chrRangeFromJpeg16_1920_c:   6339.9  11521.5  (0.55x)
> > chrRangeToJpeg8_1920_c:  9656.0   9612.8  (1.00x)
> > chrRangeToJpeg16_1920_c: 6340.4  11651.8  (0.54x)
> > lumRangeFromJpeg8_1920_c:4422.0   4420.8  (1.00x)
> > lumRangeFromJpeg16_1920_c:   4420.9   5762.0  (0.77x)
> > lumRangeToJpeg8_1920_c:  5949.1   5977.5  (1.00x)
> > lumRangeToJpeg16_1920_c: 4446.8   5946.2  (0.75x)
> >
> > NOTE: all simd optimizations for range_convert have been disabled.
> >   they will be re-enabled when they are fixed for each architecture.
> >
> > NOTE2: the same issue still exists in rgb2yuv conversions, which is not
> >addressed in this commit.
> > ---
> >  libswscale/aarch64/swscale.c  |   5 +
> >  libswscale/hscale.c   |   6 +-
> >  libswscale/swscale.c  | 113 +--
> >  libswscale/swscale_internal.h |  26 ++-
> >  libswscale/x86/swscale.c  |   5 +
> >  tests/checkasm/sw_range_convert.c |  68 ++-
> >  .../fate/filter-alphaextract_alphamerge_rgb   | 100 +-
> >  tests/ref/fate/filter-pixdesc-gray10be|   2 +-
> >  tests/ref/fate/filter-pixdesc-gray10le|   2 +-
> >  tests/ref/fate/filter-pixdesc-gray12be|   2 +-
> >  tests/ref/fate/filter-pixdesc-gray12le|   2 +-
> >  tests/ref/fate/filter-pixdesc-gray14be|   2 +-
> >  tests/ref/fate/filter-pixdesc-gray14le|   2 +-
> >  tests/ref/fate/filter-pixdesc-gray16be|   2 +-
> >  tests/ref/fate/filter-pixdesc-gray16le|   2 +-
> >  tests/ref/fate/filter-pixdesc-gray9be |   2 +-
> >  tests/ref/fate/filter-pixdesc-gray9le |   2 +-
> >  tests/ref/fate/filter-pixdesc-ya16be  |   2 +-
> >  tests/ref/fate/filter-pixdesc-ya16le  |   2 +-
> >  tests/ref/fate/filter-pixdesc-yuvj411p|   2 +-
> >  tests/ref/fate/filter-pixdesc-yuvj420p|   2 +-
> >  tests/ref/fate/filter-pixdesc-yuvj422p|   2 +-
> >  tests/ref/fate/filter-pixdesc-yuvj440p|   2 +-
> >  tests/ref/fate/filter-pixdesc-yuvj444p|   2 +-
> >  tests/ref/fate/filter-pixfmts-copy|  34 ++--
> >  tests/ref/fate/filter-pixfmts-crop|  34 ++--
> >  tests/ref/fate/filter-pixfmts-field   |  34 ++--
> >  tests/ref/fate/filter-pixfmts-fieldorder  |  30 +--
> >  tests/ref/fate/filter-pixfmts-hflip   |  34 ++--
> >  tests/ref/fate/filter-pixfmts-il  |  34 ++--
> >  tests/ref/fate/filter-pixfmts-lut |  18 +-
> >  tests/ref/fate/filter-pixfmts-null|  34 ++--
> >  tests/ref/fate/filter-pixfmts-pad |  22 +--
> >  tests/ref/fate/filter-pixfmts-pullup  |  10 +-
> >  tests/ref/fate/filter-pixfmts-rotate  |   4 +-
> >  tests/ref/fate/filter-pixfmts-scale   |  34 ++--
> >  tests/ref/fate/filter-pixfmts-swapuv  

[FFmpeg-devel] [PATCH 2/2] aarch64/vvc: Add apply_bdof

2024-12-03 Thread Zhao Zhili
From: Zhao Zhili 

Test on rpi 5 with gcc 12:

apply_bdof_8_8x16_c:  7315.2 ( 1.00x)
apply_bdof_8_8x16_neon:   1876.8 ( 3.90x)
apply_bdof_8_16x8_c:  7170.5 ( 1.00x)
apply_bdof_8_16x8_neon:   1752.8 ( 4.09x)
apply_bdof_8_16x16_c:14695.2 ( 1.00x)
apply_bdof_8_16x16_neon:  3490.5 ( 4.21x)
apply_bdof_10_8x16_c: 7371.5 ( 1.00x)
apply_bdof_10_8x16_neon:  1863.8 ( 3.96x)
apply_bdof_10_16x8_c: 7172.0 ( 1.00x)
apply_bdof_10_16x8_neon:  1766.0 ( 4.06x)
apply_bdof_10_16x16_c:   14551.5 ( 1.00x)
apply_bdof_10_16x16_neon: 3576.0 ( 4.07x)
apply_bdof_12_8x16_c: 7236.5 ( 1.00x)
apply_bdof_12_8x16_neon:  1863.8 ( 3.88x)
apply_bdof_12_16x8_c: 7316.5 ( 1.00x)
apply_bdof_12_16x8_neon:  1758.8 ( 4.16x)
apply_bdof_12_16x16_c:   14691.2 ( 1.00x)
apply_bdof_12_16x16_neon: 3480.5 ( 4.22x)
---
 libavcodec/aarch64/vvc/dsp_init.c|  21 ++
 libavcodec/aarch64/vvc/inter.S   | 399 +++
 libavcodec/aarch64/vvc/of_template.c |  64 +
 3 files changed, 484 insertions(+)
 create mode 100644 libavcodec/aarch64/vvc/of_template.c

diff --git a/libavcodec/aarch64/vvc/dsp_init.c 
b/libavcodec/aarch64/vvc/dsp_init.c
index 4a7daf57a8..2c99ba206b 100644
--- a/libavcodec/aarch64/vvc/dsp_init.c
+++ b/libavcodec/aarch64/vvc/dsp_init.c
@@ -27,16 +27,34 @@
 #include "libavcodec/vvc/dec.h"
 #include "libavcodec/vvc/ctu.h"
 
+#define BDOF_BLOCK_SIZE 16
+#define BDOF_MIN_BLOCK_SIZE 4
+
+void ff_vvc_prof_grad_filter_8x_neon(int16_t *gradient_h,
+ int16_t *gradient_v,
+ ptrdiff_t gradient_stride,
+ const int16_t *_src,
+ ptrdiff_t src_stride,
+ int width, int height);
+
+void ff_vvc_derive_bdof_vx_vy_neon(const int16_t *_src0, const int16_t *_src1,
+   int pad_mask,
+   const int16_t **gradient_h,
+   const int16_t **gradient_v,
+   int16_t *vx, int16_t *vy);
 #define BIT_DEPTH 8
 #include "alf_template.c"
+#include "of_template.c"
 #undef BIT_DEPTH
 
 #define BIT_DEPTH 10
 #include "alf_template.c"
+#include "of_template.c"
 #undef BIT_DEPTH
 
 #define BIT_DEPTH 12
 #include "alf_template.c"
+#include "of_template.c"
 #undef BIT_DEPTH
 
 int ff_vvc_sad_neon(const int16_t *src0, const int16_t *src1, int dx, int dy,
@@ -177,6 +195,7 @@ void ff_vvc_dsp_init_aarch64(VVCDSPContext *const c, const 
int bd)
 c->inter.w_avg = vvc_w_avg_8;
 c->inter.dmvr[0][0] = ff_vvc_dmvr_8_neon;
 c->inter.dmvr[1][1] = ff_vvc_dmvr_hv_8_neon;
+c->inter.apply_bdof = apply_bdof_8;
 
 for (int i = 0; i < FF_ARRAY_ELEMS(c->sao.band_filter); i++)
 c->sao.band_filter[i] = ff_h26x_sao_band_filter_8x8_8_neon;
@@ -219,6 +238,7 @@ void ff_vvc_dsp_init_aarch64(VVCDSPContext *const c, const 
int bd)
 c->inter.avg = ff_vvc_avg_10_neon;
 c->inter.w_avg = vvc_w_avg_10;
 c->inter.dmvr[1][1] = ff_vvc_dmvr_hv_10_neon;
+c->inter.apply_bdof = apply_bdof_10;
 
 c->alf.filter[LUMA] = alf_filter_luma_10_neon;
 c->alf.filter[CHROMA] = alf_filter_chroma_10_neon;
@@ -227,6 +247,7 @@ void ff_vvc_dsp_init_aarch64(VVCDSPContext *const c, const 
int bd)
 c->inter.w_avg = vvc_w_avg_12;
 c->inter.dmvr[0][0] = ff_vvc_dmvr_12_neon;
 c->inter.dmvr[1][1] = ff_vvc_dmvr_hv_12_neon;
+c->inter.apply_bdof = apply_bdof_12;
 
 c->alf.filter[LUMA] = alf_filter_luma_12_neon;
 c->alf.filter[CHROMA] = alf_filter_chroma_12_neon;
diff --git a/libavcodec/aarch64/vvc/inter.S b/libavcodec/aarch64/vvc/inter.S
index b6b079b569..87c673c007 100644
--- a/libavcodec/aarch64/vvc/inter.S
+++ b/libavcodec/aarch64/vvc/inter.S
@@ -21,6 +21,8 @@
 #include "libavutil/aarch64/asm.S"
 
 #define VVC_MAX_PB_SIZE 128
+#define BDOF_BLOCK_SIZE 16
+#define BDOF_MIN_BLOCK_SIZE 4
 
 .macro vvc_avg type, bit_depth
 
@@ -618,3 +620,400 @@ function ff_vvc_dmvr_hv_10_neon, export=1
 .unreq tmp0
 .unreq tmp1
 endfunc
+
+function ff_vvc_prof_grad_filter_8x_neon, export=1
+gh  .req x0
+gv  .req x1
+gstride .req x2
+src .req x3
+src_stride  .req x4
+width   .req w5
+height  .req w6
+
+lsl src_stride, src_stride, 

[FFmpeg-devel] [PATCH 1/2] aarch64/vvc: Reuse ff_vvc_put_pel_pixels for chroma

2024-12-03 Thread Zhao Zhili
From: Zhao Zhili 

---
 libavcodec/aarch64/vvc/dsp_init.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavcodec/aarch64/vvc/dsp_init.c 
b/libavcodec/aarch64/vvc/dsp_init.c
index e47f1ab4cc..4a7daf57a8 100644
--- a/libavcodec/aarch64/vvc/dsp_init.c
+++ b/libavcodec/aarch64/vvc/dsp_init.c
@@ -131,6 +131,13 @@ void ff_vvc_dsp_init_aarch64(VVCDSPContext *const c, const 
int bd)
 c->inter.put[0][5][1][1] = ff_vvc_put_qpel_hv64_8_neon;
 c->inter.put[0][6][1][1] = ff_vvc_put_qpel_hv128_8_neon;
 
+c->inter.put[1][1][0][0] = ff_vvc_put_pel_pixels4_8_neon;
+c->inter.put[1][2][0][0] = ff_vvc_put_pel_pixels8_8_neon;
+c->inter.put[1][3][0][0] = ff_vvc_put_pel_pixels16_8_neon;
+c->inter.put[1][4][0][0] = ff_vvc_put_pel_pixels32_8_neon;
+c->inter.put[1][5][0][0] = ff_vvc_put_pel_pixels64_8_neon;
+c->inter.put[1][6][0][0] = ff_vvc_put_pel_pixels128_8_neon;
+
 c->inter.put[1][1][0][1] = ff_vvc_put_epel_h4_8_neon;
 c->inter.put[1][2][0][1] = ff_vvc_put_epel_h8_8_neon;
 c->inter.put[1][3][0][1] = ff_vvc_put_epel_h16_8_neon;
-- 
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 v2 00/11] fix broken CC detection and ffprobe fields (cover letter)

2024-12-03 Thread Marth64
Hi Marton,

> I see two possibilites:
>
> 1) Make ffprobe read the first packet or decode a first frame from every
> stream and print information based on that.
>
> 2) Extend avstream_find_stream_info() so
>   - the API user can force it to read a packet or decode a frame from every
> stream (this is not always the case right now)
>   - it has a way to return the first frame or first packet from every
> stream when probing

My only concern with this is that the presence of Closed Captions
is not necessarily known with the first frame. It could be any N'th frame.
___
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 0/3] Add WASM simd support

2024-12-03 Thread Rémi Denis-Courmont
Le keskiviikkona 27. marraskuuta 2024, 14.35.08 EET Zhao Zhili a écrit :
> Ping.

I don't like that we use intrinsics, especially in this case, but I don't 
volunteer to rewrite the code as assembler.

-- 
レミ・デニ-クールモン
http://www.remlab.net/



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 2/2] lavc/rv40dsp: fix RISC-V chroma_mc

2024-12-03 Thread Rémi Denis-Courmont
Le sunnuntaina 1. joulukuuta 2024, 7.11.02 EET flow gg a écrit :
> Hi, why is there an issue with the ABI?

The ABI requires that the stack pointer is properly aligned AT ALL TIMES. 
Otherwise asynchronous signal handlers would break.

> I previously just thought that s0 shouldn't be used here.

Clobbering the frame pointer is best avoided to ease debugging.

-- 
Rémi Denis-Courmont
http://www.remlab.net/



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v2 3/3] avcodec/cuvid: introduce a ringbuffer to reattach additional data

2024-12-03 Thread Devin Heitmueller
On Tue, Dec 3, 2024 at 9:57 AM Hendrik Leppkes  wrote:
> The real question is, why are you using cuviddec instead of nvdec?
> side data would already pass through natively with nvdec, and other
> hwaccel-based decoders.

I suspect there could be benefits if your workload involves alot of
decoding and the GPU only has a single nvdec unit on it.  Even if it's
less efficient to do it with CUDA, getting a graphics card with lots
of CUDA units could very well be cheaper than a card with multiple
nvdec fixed units on it (each of which might only be able to do 10-15
decodes depending on codec/resolution/framerate).

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v2] avformat/mov: use dvdclut for YUV to RGB conversion of DVD subtitle palettes

2024-12-03 Thread Marth64
Hi Michael,
> v3 did build fine when i tested a few days ago IIRC

Thank you very much. I also checked with some sources
and it looked good to me. Will wait 4-5 days then push
unless there is any objection.
___
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] lavc/libx265: flag as experimental

2024-12-03 Thread Vittorio Giovara
On Tue, Dec 3, 2024 at 1:07 AM Kirithika Kalirathnam <
kirith...@multicorewareinc.com> wrote:

> Hi Vittorio,
>
> The commits in this PR
>  were
> picked
> and pushed to the master branch of x265.(b647da9
> <
> https://bitbucket.org/multicoreware/x265_git/commits/b647da90fb6aeac20cd1228cd02af932b913db23
> >
> ,b153007
> <
> https://bitbucket.org/multicoreware/x265_git/commits/b153007d1e10091a0ef38d16f1d8f35bc0437343
> >
> ,114af15
> <
> https://bitbucket.org/multicoreware/x265_git/commits/114af1598c43c603a6d9473e5f1102efbebf9e27
> >
> ).
>
> *Thanks,*
> *Kirithika*


Thanks that's perfect, I suppose the PR can be closed then!
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v2 00/11] fix broken CC detection and ffprobe fields (cover letter)

2024-12-03 Thread Marton Balint




On Tue, 3 Dec 2024, Marth64 wrote:


Hi Marton,


I see two possibilites:

1) Make ffprobe read the first packet or decode a first frame from every
stream and print information based on that.

2) Extend avstream_find_stream_info() so
  - the API user can force it to read a packet or decode a frame from every
stream (this is not always the case right now)
  - it has a way to return the first frame or first packet from every
stream when probing


My only concern with this is that the presence of Closed Captions
is not necessarily known with the first frame. It could be any N'th frame.


But how many frames do you intend to decode to make sure that you detect 
closed captions reliably? Because as far as I understand we basically rely 
on avformat_find_stream_info() to encounter a frame with closed captions. 
So detection is based on the completeness of AVCodecParameters and 
the order of packets from other streams, more precisely, sheer luck.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v2] libavformat/mpegts: demux DVB VBI data

2024-12-03 Thread Marton Balint




On Tue, 3 Dec 2024, Marton Balint wrote:




On Sat, 30 Nov 2024, Scott Theisen wrote:


 DVB VBI data is defined in ETSI EN 301 775 and can include EBU teletext
 data
 as defined in ETSI EN 300 472.

 ETSI EN 300 468 defines teletext_descriptor, VBI_data_descriptor, and
 VBI_teletext_descriptor, which has the same definition as, but different
 use
 from, teletext_descriptor.
 ---
 libavcodec/codec_desc.c | 6 ++
 libavcodec/codec_id.h   | 1 +
 libavformat/mpegts.c| 3 +++
 libavformat/mpegts.h| 2 ++
 4 files changed, 12 insertions(+)


You should split this to two patches.

Patch 1 should add the codec ID the codec_description and please also update 
the assertion check in libavcodec/version.c.


Patch 2 should add the support for demuxing in mpegts. I'd rather put the VBI 
descriptors after the teletext descriptor in the list, so in case multiple 
descriptors are present the detected codec should be teletext.


On second thought the order does not help, because the codec will be 
determined by the first descriptor...


Maybe when parsing the teletext descriptor it should override VBI codec to 
teletext, e.g.:


case TELETEXT_DESCRIPTOR:
 if (codec_id == DVB_VBI)
codec_id = DVB_TELETEXT
 // fall-through
case VBI_TELETEXT_DESCRIPTOR:
 

Regards,
Marton



Otherwise looks good.

Thanks,
Marton



 diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
 index bc9163bf98..ed500bf798 100644
 --- a/libavcodec/codec_desc.c
 +++ b/libavcodec/codec_desc.c
@@  -3634,6 +3634,12 @@ static const AVCodecDescriptor codec_descriptors[] 
@@  = {

 .long_name = NULL_IF_CONFIG_SMALL("ARIB STD-B24 caption"),
 .profiles  = NULL_IF_CONFIG_SMALL(ff_arib_caption_profiles),
 },
 +{
 +.id= AV_CODEC_ID_DVB_VBI,
 +.type  = AVMEDIA_TYPE_SUBTITLE,
 +.name  = "dvb_vbi",
 +.long_name = NULL_IF_CONFIG_SMALL("DVB VBI data"),
 +},

 /* other kind of codecs and pseudo-codecs */
 {
 diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
 index 6bfaa02601..0e9e83fddb 100644
 --- a/libavcodec/codec_id.h
 +++ b/libavcodec/codec_id.h
@@  -579,6 +579,7 @@ enum AVCodecID {
 AV_CODEC_ID_HDMV_TEXT_SUBTITLE,
 AV_CODEC_ID_TTML,
 AV_CODEC_ID_ARIB_CAPTION,
 +AV_CODEC_ID_DVB_VBI,

 /* other specific kind of codecs (generally used for attachments) */
 AV_CODEC_ID_FIRST_UNKNOWN = 0x18000,   ///< A dummy ID
 pointing at the start of various fake codecs.
 diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
 index 177e610e53..693c8c849d 100644
 --- a/libavformat/mpegts.c
 +++ b/libavformat/mpegts.c
@@  -891,6 +891,8 @@ static const StreamType DESC_types[] = {
 { 0x6a, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_AC3  }, /* AC-3
 descriptor */
 { 0x7a, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_EAC3 }, /* E-AC-3
 descriptor */
 { 0x7b, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_DTS  },
 +{ VBI_DATA_DESCRIPTOR, AVMEDIA_TYPE_SUBTITLE, AV_CODEC_ID_DVB_VBI
 },
 +{ VBI_TELETEXT_DESCRIPTOR, AVMEDIA_TYPE_SUBTITLE, AV_CODEC_ID_DVB_VBI
 },
 { 0x56, AVMEDIA_TYPE_SUBTITLE, AV_CODEC_ID_DVB_TELETEXT },
 { 0x59, AVMEDIA_TYPE_SUBTITLE, AV_CODEC_ID_DVB_SUBTITLE }, /*
 subtitling descriptor */
 { 0 },
@@  -1888,6 +1890,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
@@  AVStream *st, int stream_type

 }
 }
 break;
 +case VBI_TELETEXT_DESCRIPTOR:
 case 0x56: /* DVB teletext descriptor */
 {
 uint8_t *extradata = NULL;
 diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
 index d6dcf20947..bd9d402529 100644
 --- a/libavformat/mpegts.h
 +++ b/libavformat/mpegts.h
@@  -167,6 +167,8 @@

 /* DVB descriptor tag values [0x40, 0x7F] from
ETSI EN 300 468 Table 12: Possible locations of descriptors */
 +#define VBI_DATA_DESCRIPTOR  0x45
 +#define VBI_TELETEXT_DESCRIPTOR  0x46
 #define SERVICE_DESCRIPTOR   0x48
 #define STREAM_IDENTIFIER_DESCRIPTOR 0x52
 #define TELETEXT_DESCRIPTOR  0x56
 --
 2.43.0

 ___
 ffmpeg-devel mailing list
 ffmpeg-devel@ffmpeg.org
 https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

 To unsubscribe, visit link above, or email
 ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH] lavc/h264dsp: R-V V intra loop filter

2024-12-03 Thread Rémi Denis-Courmont
As with the inter loop filter, performance metrics seem to be biased in
favour of the C implementation because checkasm inputs almost always
fall in the no-op case.

h264_h_loop_filter_chroma_intra_8bpp_c: 82.8 ( 1.00x)
h264_h_loop_filter_chroma_intra_8bpp_rvv_i32:   72.6 ( 1.14x)
h264_h_loop_filter_chroma_mbaff_intra_8bpp_c:   41.1 ( 1.00x)
h264_h_loop_filter_chroma_mbaff_intra_8bpp_rvv_i32: 72.6 ( 0.57x)
h264_h_loop_filter_luma_intra_8bpp_c:  166.1 ( 1.00x)
h264_h_loop_filter_luma_intra_8bpp_rvv_i32:395.4 ( 0.42x)
h264_h_loop_filter_luma_mbaff_intra_8bpp_c: 93.3 ( 1.00x)
h264_h_loop_filter_luma_mbaff_intra_8bpp_rvv_i32:  395.4 ( 0.24x)
h264_v_loop_filter_chroma_intra_8bpp_c:134.8 ( 1.00x)
h264_v_loop_filter_chroma_intra_8bpp_rvv_i32:   51.6 ( 2.61x)
h264_v_loop_filter_luma_intra_8bpp_c:  468.1 ( 1.00x)
h264_v_loop_filter_luma_intra_8bpp_rvv_i32:134.8 ( 3.47x)
---
 libavcodec/riscv/h264dsp_init.c |  26 +
 libavcodec/riscv/h264dsp_rvv.S  | 163 
 2 files changed, 189 insertions(+)

diff --git a/libavcodec/riscv/h264dsp_init.c b/libavcodec/riscv/h264dsp_init.c
index 30dd272d6e..f214486bbe 100644
--- a/libavcodec/riscv/h264dsp_init.c
+++ b/libavcodec/riscv/h264dsp_init.c
@@ -40,6 +40,12 @@ void ff_h264_h_loop_filter_luma_8_rvv(uint8_t *pix, 
ptrdiff_t stride,
   int alpha, int beta, int8_t *tc0);
 void ff_h264_h_loop_filter_luma_mbaff_8_rvv(uint8_t *pix, ptrdiff_t stride,
 int alpha, int beta, int8_t *tc0);
+void ff_h264_v_loop_filter_luma_intra_8_rvv(uint8_t *pix, ptrdiff_t stride,
+int alpha, int beta);
+void ff_h264_h_loop_filter_luma_intra_8_rvv(uint8_t *pix, ptrdiff_t stride,
+int alpha, int beta);
+void ff_h264_h_loop_filter_luma_mbaff_intra_8_rvv(uint8_t *pix, ptrdiff_t s,
+  int a, int b);
 void ff_h264_v_loop_filter_chroma_8_rvv(uint8_t *pix, ptrdiff_t stride,
 int alpha, int beta, int8_t *tc0);
 void ff_h264_h_loop_filter_chroma_8_rvv(uint8_t *pix, ptrdiff_t stride,
@@ -47,6 +53,13 @@ void ff_h264_h_loop_filter_chroma_8_rvv(uint8_t *pix, 
ptrdiff_t stride,
 void ff_h264_h_loop_filter_chroma_mbaff_8_rvv(uint8_t *pix, ptrdiff_t stride,
   int alpha, int beta,
   int8_t *tc0);
+void ff_h264_v_loop_filter_chroma_intra_8_rvv(uint8_t *pix, ptrdiff_t stride,
+  int alpha, int beta);
+void ff_h264_h_loop_filter_chroma_intra_8_rvv(uint8_t *pix, ptrdiff_t stride,
+  int alpha, int beta);
+void ff_h264_h_loop_filter_chroma_mbaff_intra_8_rvv(uint8_t *pix,
+ptrdiff_t stride,
+int alpha, int beta);
 
 #define IDCT_DEPTH(depth) \
 void ff_h264_idct_add_##depth##_rvv(uint8_t *d, int16_t *s, int stride); \
@@ -125,13 +138,26 @@ av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp, 
const int bit_depth,
 dsp->h264_h_loop_filter_luma = ff_h264_h_loop_filter_luma_8_rvv;
 dsp->h264_h_loop_filter_luma_mbaff =
 ff_h264_h_loop_filter_luma_mbaff_8_rvv;
+dsp->h264_v_loop_filter_luma_intra =
+ff_h264_v_loop_filter_luma_intra_8_rvv;
+dsp->h264_h_loop_filter_luma_intra =
+ff_h264_h_loop_filter_luma_intra_8_rvv;
+dsp->h264_h_loop_filter_luma_mbaff_intra =
+ff_h264_h_loop_filter_luma_mbaff_intra_8_rvv;
 dsp->h264_v_loop_filter_chroma =
 ff_h264_v_loop_filter_chroma_8_rvv;
+dsp->h264_v_loop_filter_chroma_intra =
+ff_h264_v_loop_filter_chroma_intra_8_rvv;
+
 if (chroma_format_idc <= 1) {
 dsp->h264_h_loop_filter_chroma =
 ff_h264_h_loop_filter_chroma_8_rvv;
 dsp->h264_h_loop_filter_chroma_mbaff =
 ff_h264_h_loop_filter_chroma_mbaff_8_rvv;
+dsp->h264_h_loop_filter_chroma_intra =
+ff_h264_h_loop_filter_chroma_intra_8_rvv;
+dsp->h264_h_loop_filter_chroma_mbaff_intra =
+ff_h264_h_loop_filter_chroma_mbaff_intra_8_rvv;
 }
 
 dsp->h264_idct_add  = ff_h264_idct_add_8_rvv;
diff --git a/libavcodec/riscv/h264dsp_rvv.S b/libavcodec/riscv/h264dsp_rvv.S
index 5423b716ca..60015a7020 100644
--- a/libavcodec/riscv/h264dsp_rvv.S
+++ b/libavcodec/riscv/h264dsp_rvv.S
@@ -308,6 +308,125 @@ func ff_h264_v_loop_filter_\type\()_8_rvv, zve32x
 vse8.vv11, (a0)
 ret
 endfunc
+
+.varian

Re: [FFmpeg-devel] [PATCH 1/2] libavformat/mpegts*: reduce use of magic numbers

2024-12-03 Thread Marton Balint




On Sun, 1 Dec 2024, Scott Theisen wrote:


Note ISO/IEC 13818-1 defines an Extension_descriptor with descriptor_tag value
0x3f (63), so I kept the DVB comment.

I don't know what defines stream_type value 0x8a as DTS.

I don't have any Blu-ray standards so I don't know where those stream_type
values are defined.


Thanks, will apply.

Regards,
Marton


---
libavformat/mpegts.c| 150 
libavformat/mpegts.h|  59 ++--
libavformat/mpegtsenc.c |  78 +++--
3 files changed, 170 insertions(+), 117 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 177e610e53..b4bf70bcbf 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -444,7 +444,7 @@ static void write_section_data(MpegTSContext *ts, 
MpegTSFilter *tss1,

offset = 0;
cur_section_buf = tss->section_buf;
-while (cur_section_buf - tss->section_buf < MAX_SECTION_SIZE && 
cur_section_buf[0] != 0xff) {
+while (cur_section_buf - tss->section_buf < MAX_SECTION_SIZE && 
cur_section_buf[0] != STUFFING_BYTE) {
/* compute section length if possible */
if (tss->section_h_size == -1 && tss->section_index - offset >= 3) {
len = (AV_RB16(cur_section_buf + 1) & 0xfff) + 3;
@@ -590,7 +590,7 @@ static int analyze(const uint8_t *buf, int size, int 
packet_size,
memset(stat, 0, packet_size * sizeof(*stat));

for (i = 0; i < size - 3; i++) {
-if (buf[i] == 0x47) {
+if (buf[i] == SYNC_BYTE) {
int pid = AV_RB16(buf+1) & 0x1FFF;
int asc = buf[i + 3] & 0x30;
if (!probe || pid == 0x1FFF || asc) {
@@ -798,66 +798,66 @@ typedef struct StreamType {
} StreamType;

static const StreamType ISO_types[] = {
-{ 0x01, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MPEG2VIDEO },
-{ 0x02, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MPEG2VIDEO },
-{ 0x03, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_MP3},
-{ 0x04, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_MP3},
-{ 0x0f, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AAC},
-{ 0x10, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MPEG4  },
+{ STREAM_TYPE_VIDEO_MPEG1,AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MPEG2VIDEO },
+{ STREAM_TYPE_VIDEO_MPEG2,AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MPEG2VIDEO },
+{ STREAM_TYPE_AUDIO_MPEG1,AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_MP3},
+{ STREAM_TYPE_AUDIO_MPEG2,AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_MP3},
+{ STREAM_TYPE_AUDIO_AAC,  AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AAC},
+{ STREAM_TYPE_VIDEO_MPEG4,AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MPEG4  },
/* Makito encoder sets stream type 0x11 for AAC,
 * so auto-detect LOAS/LATM instead of hardcoding it. */
#if !CONFIG_LOAS_DEMUXER
-{ 0x11, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AAC_LATM   }, /* LATM syntax */
+{ STREAM_TYPE_AUDIO_AAC_LATM, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AAC_LATM   
}, /* LATM syntax */
#endif
-{ 0x1b, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_H264   },
-{ 0x1c, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AAC},
-{ 0x20, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_H264   },
-{ 0x21, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_JPEG2000   },
-{ 0x24, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_HEVC   },
-{ 0x33, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_VVC},
-{ 0x42, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_CAVS   },
-{ 0xd1, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_DIRAC  },
-{ 0xd2, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_AVS2   },
-{ 0xd4, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_AVS3   },
-{ 0xea, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_VC1},
+{ STREAM_TYPE_VIDEO_H264, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_H264   },
+{ STREAM_TYPE_AUDIO_MPEG4,AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AAC},
+{ STREAM_TYPE_VIDEO_MVC,  AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_H264   },
+{ STREAM_TYPE_VIDEO_JPEG2000, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_JPEG2000   },
+{ STREAM_TYPE_VIDEO_HEVC, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_HEVC   },
+{ STREAM_TYPE_VIDEO_VVC,  AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_VVC},
+{ STREAM_TYPE_VIDEO_CAVS, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_CAVS   },
+{ STREAM_TYPE_VIDEO_DIRAC,AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_DIRAC  },
+{ STREAM_TYPE_VIDEO_AVS2, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_AVS2   },
+{ STREAM_TYPE_VIDEO_AVS3, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_AVS3   },
+{ STREAM_TYPE_VIDEO_VC1,  AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_VC1},
{ 0 },
};

static const StreamType HDMV_types[] = {
-{ 0x80, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_PCM_BLURAY},
-{ 0x81, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_AC3   },
-{ 0x82, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_DTS   },
-{ 0x83, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_TRUEHD},
-{ 0x84, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_EAC3  },
-{ 0x85, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_DTS   }, /* DTS HD 
*/
-{ 0x86, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_

Re: [FFmpeg-devel] [PATCH 2/2] libavformat/mpegts.c: is_pes_stream() use switch case

2024-12-03 Thread Marton Balint




On Sun, 1 Dec 2024, Scott Theisen wrote:


also add STREAM_TYPE_PRIVATE_SECTION since a private_section() is not a
PES_packet().
---
libavformat/mpegts.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)


Will apply.

Thanks,
Marton



diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b4bf70bcbf..e470f12d22 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2316,8 +2316,18 @@ static int parse_stream_identifier_desc(const uint8_t 
*p, const uint8_t *p_end)

static int is_pes_stream(int stream_type, uint32_t prog_reg_desc)
{
-return !(stream_type == STREAM_TYPE_ISO_IEC_14496_SECTION ||
- (stream_type == STREAM_TYPE_SCTE_DATA_SCTE_35 && prog_reg_desc == 
AV_RL32("CUEI")) );
+switch (stream_type) {
+case STREAM_TYPE_PRIVATE_SECTION:
+case STREAM_TYPE_ISO_IEC_14496_SECTION:
+return 0;
+case STREAM_TYPE_SCTE_DATA_SCTE_35:
+/* This User Private stream_type value is used by multiple 
organizations
+   for different things.  ANSI/SCTE 35 splice_info_section() is a
+   private_section() not a PES_packet(). */
+return !(prog_reg_desc == AV_RL32("CUEI"));
+default:
+return 1;
+}
}

static void pmt_cb(MpegTSFilter *filter, const uint8_t *section, int 
section_len)
--
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 2/2] avformat/rpl: Fix check for negative values

2024-12-03 Thread Michael Niedermayer
On Mon, Nov 18, 2024 at 10:26:37AM -0300, James Almer wrote:
> On 11/18/2024 4:37 AM, Rémi Denis-Courmont wrote:
> > Hi,
> > 
> > Le 18 novembre 2024 05:09:11 GMT+02:00, Michael Niedermayer 
> >  a écrit :
> > > Fixes: signed integer overflow: 10 * -192326792533340 cannot be 
> > > represented in type 'int64_t' (aka 'long')
> > > Fixes: 
> > > 378891963/clusterfuzz-testcase-minimized-fuzzer_loadfile_direct-5714338935013376
> > > Found-by: ossfuzz
> > > Reported-by: Kacper Michajlow 
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > > libavformat/rpl.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/libavformat/rpl.c b/libavformat/rpl.c
> > > index e971d0588f3..b30d769efb2 100644
> > > --- a/libavformat/rpl.c
> > > +++ b/libavformat/rpl.c
> > > @@ -102,7 +102,7 @@ static AVRational read_fps(const char* line, int* 
> > > error)
> > >  line++;
> > >  for (; *line>='0' && *line<='9'; line++) {
> > >  // Truncate any numerator too large to fit into an int64_t
> > > -if (num > (INT64_MAX - 9) / 10 || den > INT64_MAX / 10)
> > > +if (num > (INT64_MAX - 9) / 10ULL || den > INT64_MAX / 10ULL)
> > >  break;
> > >  num  = 10 * num + (*line - '0');
> > >  den *= 10;
> > 
> > We have ckd_mul() for this, AFAIK. Easier to read, easier to write and also 
> > easier for the compiler to optimise correctly.
> 
> Not yet, i haven't pushed my compat header patch.

if noone is against it, then i intend to apply the patch soon
it can easily be backported too.

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/7] avcodec/ilbcdec: Initialize tempbuff2

2024-12-03 Thread Michael Niedermayer
On Mon, Sep 23, 2024 at 11:32:43PM +0200, Michael Niedermayer wrote:
> Fixes: Use of uninitialized value
> Fixes: 
> 71350/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-6322020827070464
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/ilbcdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


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 3/9] avcodec/webp: Check ref_x/y

2024-12-03 Thread Michael Niedermayer
Hi Thilo

On Fri, Nov 15, 2024 at 07:52:10PM +0100, Thilo Borgmann via ffmpeg-devel wrote:
> Am 17.08.24 um 01:11 schrieb Michael Niedermayer:
> > Fixes: 
> > 70991/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WEBP_fuzzer-5544067620995072
> > Fixes: use of uninintailized value
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >   libavcodec/webp.c | 3 +++
> >   1 file changed, 3 insertions(+)
> 
> Should be ok if tested.

our fate tests cover this
(they fail if you simply do something random at the changed location instead
 of the correct change)

will apply

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] avcodec/vvc decode: ALF filtering without CC-ALF

2024-12-03 Thread Chris Warrington via ffmpeg-devel
Nuo Mi wrote:
> This will introduce two writes for all blocks, even if there is no CC ALF.
How about checking the sps_ccalf_enabled_flag in ff_vvc_alf_filter?

That makes sense too, but I'd think you'd need to check both 
sps_ccalf_enabled_flag and the slice header 
sh_alf_cc_cb_enabled_flag/sh_alf_cc_cr_enabled_flag or the similar picture 
header values.
___
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] libavformat/mpegts: demux DVB VBI data

2024-12-03 Thread Marton Balint




On Sat, 30 Nov 2024, Scott Theisen wrote:


DVB VBI data is defined in ETSI EN 301 775 and can include EBU teletext data
as defined in ETSI EN 300 472.

ETSI EN 300 468 defines teletext_descriptor, VBI_data_descriptor, and
VBI_teletext_descriptor, which has the same definition as, but different use
from, teletext_descriptor.
---
libavcodec/codec_desc.c | 6 ++
libavcodec/codec_id.h   | 1 +
libavformat/mpegts.c| 3 +++
libavformat/mpegts.h| 2 ++
4 files changed, 12 insertions(+)


You should split this to two patches.

Patch 1 should add the codec ID the codec_description and please also 
update the assertion check in libavcodec/version.c.


Patch 2 should add the support for demuxing in mpegts. I'd rather put the 
VBI descriptors after the teletext descriptor in the list, so in case 
multiple descriptors are present the detected codec should be teletext.


Otherwise looks good.

Thanks,
Marton



diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index bc9163bf98..ed500bf798 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -3634,6 +3634,12 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("ARIB STD-B24 caption"),
.profiles  = NULL_IF_CONFIG_SMALL(ff_arib_caption_profiles),
},
+{
+.id= AV_CODEC_ID_DVB_VBI,
+.type  = AVMEDIA_TYPE_SUBTITLE,
+.name  = "dvb_vbi",
+.long_name = NULL_IF_CONFIG_SMALL("DVB VBI data"),
+},

/* other kind of codecs and pseudo-codecs */
{
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 6bfaa02601..0e9e83fddb 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -579,6 +579,7 @@ enum AVCodecID {
AV_CODEC_ID_HDMV_TEXT_SUBTITLE,
AV_CODEC_ID_TTML,
AV_CODEC_ID_ARIB_CAPTION,
+AV_CODEC_ID_DVB_VBI,

/* other specific kind of codecs (generally used for attachments) */
AV_CODEC_ID_FIRST_UNKNOWN = 0x18000,   ///< A dummy ID pointing at 
the start of various fake codecs.
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 177e610e53..693c8c849d 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -891,6 +891,8 @@ static const StreamType DESC_types[] = {
{ 0x6a, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_AC3  }, /* AC-3 
descriptor */
{ 0x7a, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_EAC3 }, /* E-AC-3 
descriptor */
{ 0x7b, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_DTS  },
+{ VBI_DATA_DESCRIPTOR, AVMEDIA_TYPE_SUBTITLE, AV_CODEC_ID_DVB_VBI  
},
+{ VBI_TELETEXT_DESCRIPTOR, AVMEDIA_TYPE_SUBTITLE, AV_CODEC_ID_DVB_VBI  
},
{ 0x56, AVMEDIA_TYPE_SUBTITLE, AV_CODEC_ID_DVB_TELETEXT },
{ 0x59, AVMEDIA_TYPE_SUBTITLE, AV_CODEC_ID_DVB_SUBTITLE }, /* subtitling 
descriptor */
{ 0 },
@@ -1888,6 +1890,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
}
}
break;
+case VBI_TELETEXT_DESCRIPTOR:
case 0x56: /* DVB teletext descriptor */
{
uint8_t *extradata = NULL;
diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
index d6dcf20947..bd9d402529 100644
--- a/libavformat/mpegts.h
+++ b/libavformat/mpegts.h
@@ -167,6 +167,8 @@

/* DVB descriptor tag values [0x40, 0x7F] from
   ETSI EN 300 468 Table 12: Possible locations of descriptors */
+#define VBI_DATA_DESCRIPTOR  0x45
+#define VBI_TELETEXT_DESCRIPTOR  0x46
#define SERVICE_DESCRIPTOR   0x48
#define STREAM_IDENTIFIER_DESCRIPTOR 0x52
#define TELETEXT_DESCRIPTOR  0x56
--
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 1/2] avcodec/libjxlenc: add animated JPEG XL encoder

2024-12-03 Thread Leo Izen
libjxl supports animated encoding, so we add a wrapper to the
library using the receive_packet callback method.

This code was based largely on a patch sent by Zsolt Vadász,
although it was updated to use more recent coding practices
and many of the leaks and issues were fixed.

Co-authored-by: Zsolt Vadász 
Signed-off-by: Leo Izen 
---
 configure  |   2 +
 libavcodec/allcodecs.c |   2 +
 libavcodec/codec_desc.c|   8 +
 libavcodec/codec_id.h  |   1 +
 libavcodec/jpegxl_parser.c |   2 +-
 libavcodec/libjxldec.c |  16 ++
 libavcodec/libjxlenc.c | 365 +++--
 libavcodec/version.h   |   2 +-
 8 files changed, 303 insertions(+), 95 deletions(-)

diff --git a/configure b/configure
index d7b7b49f92..bda89c460f 100755
--- a/configure
+++ b/configure
@@ -3549,6 +3549,8 @@ libgsm_ms_decoder_deps="libgsm"
 libgsm_ms_encoder_deps="libgsm"
 libilbc_decoder_deps="libilbc"
 libilbc_encoder_deps="libilbc"
+libjxl_anim_decoder_deps="libjxl libjxl_threads"
+libjxl_anim_encoder_deps="libjxl libjxl_threads"
 libjxl_decoder_deps="libjxl libjxl_threads"
 libjxl_encoder_deps="libjxl libjxl_threads"
 libkvazaar_encoder_deps="libkvazaar"
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 0b559dfc58..4bc41239c7 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -777,6 +777,8 @@ extern const FFCodec ff_libgsm_ms_encoder;
 extern const FFCodec ff_libgsm_ms_decoder;
 extern const FFCodec ff_libilbc_encoder;
 extern const FFCodec ff_libilbc_decoder;
+extern const FFCodec ff_libjxl_anim_decoder;
+extern const FFCodec ff_libjxl_anim_encoder;
 extern const FFCodec ff_libjxl_decoder;
 extern const FFCodec ff_libjxl_encoder;
 extern const FFCodec ff_liblc3_encoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index bc9163bf98..fc075ffd7f 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1977,6 +1977,14 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("RealVideo 6.0"),
 .props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_REORDER,
 },
+{
+.id= AV_CODEC_ID_JPEGXL_ANIM,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "jpegxl_anim",
+.long_name = NULL_IF_CONFIG_SMALL("JPEG XL animated"),
+.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_LOSSLESS,
+.mime_types= MT("image/jxl"),
+},
 
 /* various PCM "codecs" */
 {
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 6bfaa02601..ba0480aa09 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -328,6 +328,7 @@ enum AVCodecID {
 AV_CODEC_ID_LEAD,
 AV_CODEC_ID_DNXUC,
 AV_CODEC_ID_RV60,
+AV_CODEC_ID_JPEGXL_ANIM,
 
 /* various PCM "codecs" */
 AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the 
start of audio codecs
diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
index 76122af54a..a888e9ae6e 100644
--- a/libavcodec/jpegxl_parser.c
+++ b/libavcodec/jpegxl_parser.c
@@ -1534,7 +1534,7 @@ flush:
 }
 
 const AVCodecParser ff_jpegxl_parser = {
-.codec_ids  = { AV_CODEC_ID_JPEGXL },
+.codec_ids  = { AV_CODEC_ID_JPEGXL, AV_CODEC_ID_JPEGXL_ANIM },
 .priv_data_size = sizeof(JXLParseContext),
 .parser_parse   = jpegxl_parse,
 .parser_close   = ff_parse_close,
diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c
index 9dfc261e3d..96c338d1b4 100644
--- a/libavcodec/libjxldec.c
+++ b/libavcodec/libjxldec.c
@@ -549,3 +549,19 @@ const FFCodec ff_libjxl_decoder = {
 FF_CODEC_CAP_ICC_PROFILES,
 .p.wrapper_name   = "libjxl",
 };
+
+const FFCodec ff_libjxl_anim_decoder = {
+.p.name   = "libjxl_anim",
+CODEC_LONG_NAME("libjxl JPEG XL animated"),
+.p.type   = AVMEDIA_TYPE_VIDEO,
+.p.id = AV_CODEC_ID_JPEGXL_ANIM,
+.priv_data_size   = sizeof(LibJxlDecodeContext),
+.init = libjxl_decode_init,
+FF_CODEC_RECEIVE_FRAME_CB(libjxl_receive_frame),
+.close= libjxl_decode_close,
+.p.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_OTHER_THREADS,
+.caps_internal= FF_CODEC_CAP_NOT_INIT_THREADSAFE |
+FF_CODEC_CAP_AUTO_THREADS | FF_CODEC_CAP_INIT_CLEANUP |
+FF_CODEC_CAP_ICC_PROFILES,
+.p.wrapper_name   = "libjxl",
+};
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index 8b0e60df6f..5da4d2baad 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -35,6 +35,7 @@
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/pixfmt.h"
+#include "libavutil/rational.h"
 #include "libavutil/version.h"
 
 #include "avcodec.h"
@@ -56,6 +57,13 @@ typedef struct LibJxlEncodeContext {
 int xyb;
 uint8_t *buffer;
 size_t buffer_size;
+JxlPixelFormat jxl_fmt;
+const uint8_t *data;
+
+/* animation stuff */
+AVFram

[FFmpeg-devel] [PATCH 2/2] avformat/jpegxl_anim_dec: use new animated JPEG XL codec ID

2024-12-03 Thread Leo Izen
A new codec ID has been added to avcodec for animated JPEG XL, so
we should use that in the animated JPEG XL demuxer.

Signed-off-by: Leo Izen 
---
 libavformat/jpegxl_anim_dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/jpegxl_anim_dec.c b/libavformat/jpegxl_anim_dec.c
index 2338a2e8c0..612f8a9fb2 100644
--- a/libavformat/jpegxl_anim_dec.c
+++ b/libavformat/jpegxl_anim_dec.c
@@ -136,7 +136,7 @@ static int jpegxl_anim_read_header(AVFormatContext *s)
 return AVERROR(ENOMEM);
 
 st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
-st->codecpar->codec_id   = AV_CODEC_ID_JPEGXL;
+st->codecpar->codec_id   = AV_CODEC_ID_JPEGXL_ANIM;
 avpriv_set_pts_info(st, 1, meta.timebase.num, meta.timebase.den);
 ffstream(st)->need_parsing = AVSTREAM_PARSE_FULL;
 
-- 
2.47.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 3/3] scale_qsv frame crop support

2024-12-03 Thread Koushik Dutta
I am embedding ffmpeg and running a dynamic number of filters passes
per frame. The standard crop filter supports commands that allow
updating the crop region on an existing filter. The vpp filter must be
recreated for any change.
My other changes (cuda and vt) implement the correct crop
functionality in other hardware contexts, and they do not have
dedicated crop filters like vpp. So for consistency I implemented it
for qsv as well, and it would simplify my use case.

Is there anything else necessary to get this merged?

Koush

On Thu, Sep 12, 2024 at 12:17 AM Wang, Fei W  wrote:
>
> On Tue, 2024-09-10 at 11:10 -0700, Koushik Dutta wrote:
> > The crop filter has no effect on scale_qsv:
> >
> > -vf crop=100:100,scale_qsv=300x300
> >
>
> How about to use vpp_qsv filter directly? It support both scale and
> crop via its options which is much more easy to use.
>
> Thanks
> Fei
>
> > Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the
> > crop_* properties,
> > as seen in the implementation vf_crop.c.
> >
> > This patch is slightly different from the previously submitted
> > patches
> > since qsv supports frame crop via the vpp_qsv filter. If no explicit
> > crop
> > is detected via that filter, AVFrame.crop_* will be used instead.
> > Removal of vpp_qsv's crop argument may be warranted.
> > ---
> >  libavfilter/qsvvpp.c | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> > index 0818ada117..05ce387bc3 100644
> > --- a/libavfilter/qsvvpp.c
> > +++ b/libavfilter/qsvvpp.c
> > @@ -467,6 +467,16 @@ static QSVFrame *submit_frame(QSVVPPContext *s,
> > AVFilterLink *inlink, AVFrame *p
> >  else if (qsv_frame->frame->repeat_pict == 4)
> >  qsv_frame->surface.Info.PicStruct |=
> > MFX_PICSTRUCT_FRAME_TRIPLING;
> >
> > +// if crop arguments are not present from the vpp_qsv filter,
> > use the provided AVFrame
> > +// crop_* members instead.
> > +if (!qsv_frame->surface.Info.CropX && !qsv_frame-
> > >surface.Info.CropY
> > +&& qsv_frame->surface.Info.CropW == picref->width &&
> > qsv_frame->surface.Info.CropH == picref->height) {
> > +qsv_frame->surface.Info.CropW = (mfxU16)((picref->width -
> > picref->crop_right) - picref->crop_left);
> > +qsv_frame->surface.Info.CropH = (mfxU16)((picref->height -
> > picref->crop_bottom) - picref->crop_top);
> > +qsv_frame->surface.Info.CropX = (mfxU16)picref->crop_left;
> > +qsv_frame->surface.Info.CropY = (mfxU16)picref->crop_top;
> > +}
> > +
> >  return qsv_frame;
> >  }
> >
>
___
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/5] avutil: add hwcontext_amf.

2024-12-03 Thread Dmitrii Ovchinnikov


Adds  hwcontext_amf, enabling a shared AMF context for encoders, 
decoders, and AMF-based filters, without copy to the host memory.
Code also was tested in HandBrake.

Benefits:
 - Optimizations for direct video memory access from CPU
 - Significant performance boost in full AMF pipelines with filters
 - Integration of GPU filters like VPP, Super Resolution, and 
Compression Artefact Removal(in future plans)
 - VCN power management control for decoders.
 - Ability to specify which VCN instance to use for decoding 
   (like for encoder)
 - AMD will soon introduce full AMF API for multimedia accelerator MA35D
   - With AMF API, integration will be much easier: 
  GPU and the accelerator will have the same API
   - including encoder, decoder, scaler, color converter, 
  Windows and Linux.
   Learn more: 
  https://www.amd.com/en/products/accelerators/alveo/ma35d.htm

Changes by versions:
v2: Header file cleanup.
v3: Removed an unnecessary class.
v4: code cleanup and improved error handling
v5: Fixes related to HandBrake integration.
v6: Fixed AMF filters deps

---
 libavutil/Makefile |   4 +
 libavutil/hwcontext.c  |   4 +
 libavutil/hwcontext.h  |   1 +
 libavutil/hwcontext_amf.c  | 588 +
 libavutil/hwcontext_amf.h  |  45 +++
 libavutil/hwcontext_amf_internal.h |  44 +++
 libavutil/hwcontext_internal.h |   1 +
 libavutil/pixdesc.c|   4 +
 libavutil/pixfmt.h |   5 +
 9 files changed, 696 insertions(+)
 create mode 100644 libavutil/hwcontext_amf.c
 create mode 100644 libavutil/hwcontext_amf.h
 create mode 100644 libavutil/hwcontext_amf_internal.h

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 847878d7a4..2992b53277 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -46,6 +46,7 @@ HEADERS = adler32.h   
  \
   hwcontext_d3d12va.h   \
   hwcontext_drm.h   \
   hwcontext_dxva2.h \
+  hwcontext_amf.h   \
   hwcontext_qsv.h   \
   hwcontext_mediacodec.h\
   hwcontext_opencl.h\
@@ -196,6 +197,7 @@ OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o
 OBJS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.o
 OBJS-$(CONFIG_D3D12VA)  += hwcontext_d3d12va.o
 OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
+OBJS-$(CONFIG_AMF)  += hwcontext_amf.o
 OBJS-$(CONFIG_LIBDRM)   += hwcontext_drm.o
 OBJS-$(CONFIG_MACOS_KPERF)  += macos_kperf.o
 OBJS-$(CONFIG_MEDIACODEC)   += hwcontext_mediacodec.o
@@ -220,6 +222,8 @@ SKIPHEADERS-$(CONFIG_CUDA) += 
hwcontext_cuda_internal.h \
 SKIPHEADERS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.h
 SKIPHEADERS-$(CONFIG_D3D12VA)  += hwcontext_d3d12va.h
 SKIPHEADERS-$(CONFIG_DXVA2)+= hwcontext_dxva2.h
+SKIPHEADERS-$(CONFIG_AMF)  += hwcontext_amf.h   \
+  hwcontext_amf_internal
 SKIPHEADERS-$(CONFIG_QSV)  += hwcontext_qsv.h
 SKIPHEADERS-$(CONFIG_OPENCL)   += hwcontext_opencl.h
 SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index fa99a0d8a4..f06d49c45c 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -65,6 +65,9 @@ static const HWContextType * const hw_table[] = {
 #endif
 #if CONFIG_VULKAN
 &ff_hwcontext_type_vulkan,
+#endif
+#if CONFIG_AMF
+&ff_hwcontext_type_amf,
 #endif
 NULL,
 };
@@ -82,6 +85,7 @@ static const char *const hw_type_names[] = {
 [AV_HWDEVICE_TYPE_VIDEOTOOLBOX] = "videotoolbox",
 [AV_HWDEVICE_TYPE_MEDIACODEC] = "mediacodec",
 [AV_HWDEVICE_TYPE_VULKAN] = "vulkan",
+[AV_HWDEVICE_TYPE_AMF] = "amf",
 };
 
 typedef struct FFHWDeviceContext {
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index bac30debae..96042ba197 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -38,6 +38,7 @@ enum AVHWDeviceType {
 AV_HWDEVICE_TYPE_MEDIACODEC,
 AV_HWDEVICE_TYPE_VULKAN,
 AV_HWDEVICE_TYPE_D3D12VA,
+AV_HWDEVICE_TYPE_AMF,
 };
 
 /**
diff --git a/libavutil/hwcontext_amf.c b/libavutil/hwcontext_amf.c
new file mode 100644
index 00..26050b1e07
--- /dev/null
+++ b/libavutil/hwcontext_amf.c
@@ -0,0 +1,588 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or 

[FFmpeg-devel] [PATCH 3/5] avfilter/scale_amf: Add AMF VPP & super resolution filters

2024-12-03 Thread Dmitrii Ovchinnikov
From: Evgeny Pavlov 

This commit adds two AMF filters: vpp_amf & sr_amf.
Both filters are using AMF hardware acceleration.
vpp_amf supports simple scaling algorithms & color conversion.
sr_amf supports advanced scaling algorithms such as FSR & can
be used for upscaling only.
---
 configure   |   2 +
 libavfilter/Makefile|   2 +
 libavfilter/allfilters.c|   2 +
 libavfilter/vf_amf_common.c | 534 
 libavfilter/vf_amf_common.h |  73 +
 libavfilter/vf_sr_amf.c | 189 +
 libavfilter/vf_vpp_amf.c| 264 ++
 7 files changed, 1066 insertions(+)
 create mode 100644 libavfilter/vf_amf_common.c
 create mode 100644 libavfilter/vf_amf_common.h
 create mode 100644 libavfilter/vf_sr_amf.c
 create mode 100644 libavfilter/vf_vpp_amf.c

diff --git a/configure b/configure
index 0976dc7f63..4f033ebc70 100755
--- a/configure
+++ b/configure
@@ -3953,6 +3953,8 @@ rubberband_filter_deps="librubberband"
 sab_filter_deps="gpl swscale"
 scale2ref_filter_deps="swscale"
 scale_filter_deps="swscale"
+sr_amf_filter_deps="amf"
+vpp_amf_filter_deps="amf"
 scale_qsv_filter_deps="libmfx"
 scale_qsv_filter_select="qsvvpp"
 scdet_filter_select="scene_sad"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 4d9681768b..979a8876a8 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -504,6 +504,7 @@ OBJS-$(CONFIG_SITI_FILTER)   += vf_siti.o
 OBJS-$(CONFIG_SPLIT_FILTER)  += split.o
 OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o qp_table.o
 OBJS-$(CONFIG_SR_FILTER) += vf_sr.o
+OBJS-$(CONFIG_SR_AMF_FILTER) += vf_sr_amf.o scale_eval.o 
vf_amf_common.o
 OBJS-$(CONFIG_SSIM_FILTER)   += vf_ssim.o framesync.o
 OBJS-$(CONFIG_SSIM360_FILTER)+= vf_ssim360.o framesync.o
 OBJS-$(CONFIG_STEREO3D_FILTER)   += vf_stereo3d.o
@@ -557,6 +558,7 @@ OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER)   += 
vidstabutils.o vf_vidstabtransfo
 OBJS-$(CONFIG_VIF_FILTER)+= vf_vif.o framesync.o
 OBJS-$(CONFIG_VIGNETTE_FILTER)   += vf_vignette.o
 OBJS-$(CONFIG_VMAFMOTION_FILTER) += vf_vmafmotion.o framesync.o
+OBJS-$(CONFIG_VPP_AMF_FILTER)+= vf_vpp_amf.o scale_eval.o 
vf_amf_common.o
 OBJS-$(CONFIG_VPP_QSV_FILTER)+= vf_vpp_qsv.o
 OBJS-$(CONFIG_VSTACK_FILTER) += vf_stack.o framesync.o
 OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9819f0f95b..7929444371 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -431,6 +431,8 @@ extern const AVFilter ff_vf_roberts_opencl;
 extern const AVFilter ff_vf_rotate;
 extern const AVFilter ff_vf_sab;
 extern const AVFilter ff_vf_scale;
+extern const AVFilter ff_vf_vpp_amf;
+extern const AVFilter ff_vf_sr_amf;
 extern const AVFilter ff_vf_scale_cuda;
 extern const AVFilter ff_vf_scale_npp;
 extern const AVFilter ff_vf_scale_qsv;
diff --git a/libavfilter/vf_amf_common.c b/libavfilter/vf_amf_common.c
new file mode 100644
index 00..ab8be52f9e
--- /dev/null
+++ b/libavfilter/vf_amf_common.c
@@ -0,0 +1,534 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "vf_amf_common.h"
+
+#include "libavutil/avassert.h"
+#include "avfilter.h"
+#include "avfilter_internal.h"
+#include "formats.h"
+#include "libavutil/mem.h"
+#include "libavutil/imgutils.h"
+
+#include "libavutil/hwcontext_amf.h"
+#include "libavutil/hwcontext_amf_internal.h"
+#include "AMF/components/ColorSpace.h"
+#include "scale_eval.h"
+
+#if CONFIG_DXVA2
+#include 
+#endif
+
+#if CONFIG_D3D11VA
+#include 
+#endif
+
+int amf_filter_init(AVFilterContext *avctx)
+{
+AMFFilterContext *ctx = avctx->priv;
+
+if (!strcmp(ctx->format_str, "same")) {
+ctx->format = AV_PIX_FMT_NONE;
+} else {
+ctx->format = av_get_pix_fmt(ctx->format_str);
+if (ctx->format == AV_PIX_FMT_NONE) {
+av_log(avctx, AV_LOG_ERROR, "Unrecognized pixel format: %s\n", 
ctx->format_str);
+return AVERROR(EINVAL);
+}
+}
+
+return 0;
+}
+
+void amf_filter_uninit(AVFilterContext *avctx)
+

[FFmpeg-devel] [PATCH 4/5] doc/filters: Add documentation for AMF filters

2024-12-03 Thread Dmitrii Ovchinnikov
From: Evgeny Pavlov 

Signed-off-by: Evgeny Pavlov 
---
 doc/filters.texi | 238 +++
 1 file changed, 238 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 428986a1e9..7d75ebfa3e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -22827,6 +22827,76 @@ input upscaled using bicubic upscaling with proper 
scale factor.
 
 To get full functionality (such as async execution), please use the 
@ref{dnn_processing} filter.
 
+@anchor{sr_amf}
+@section sr_amf
+
+Upscale (size increasing) for the input video using AMD Advanced Media 
Framework library for hardware acceleration.
+Use advanced algorithms for upscaling with higher output quality.
+Setting the output width and height works in the same way as for the 
@ref{scale} filter.
+
+The filter accepts the following options:
+@table @option
+@item w
+@item h
+Set the output video dimension expression. Default value is the input 
dimension.
+
+Allows for the same expressions as the @ref{scale} filter.
+
+@item algorithm
+Sets the algorithm used for scaling:
+
+@table @var
+@item bilinear
+Bilinear
+
+@item bicubic
+Bicubic
+
+@item sr1-0
+Video SR1.0
+This is a default value
+
+@item point
+Point
+
+@item sr1-1
+Video SR1.1
+
+@end table
+
+@item sharpness
+Control hq scaler sharpening. The value is a float in the range of [0.0, 2.0]
+
+@item format
+Controls the output pixel format. By default, or if none is specified, the 
input
+pixel format is used.
+
+@item keep-ratio
+Force the scaler to keep the aspect ratio of the input image when the output 
size has a different aspect ratio.
+Default value is false.
+
+@item fill
+Specifies whether the output image outside the region of interest,
+which does not fill the entire output surface should be filled with a solid 
color.
+
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Scale input to 720p, keeping aspect ratio and ensuring the output is yuv420p.
+@example
+sr_amf=-2:720:format=yuv420p
+@end example
+
+@item
+Upscale to 4K with algorithm video SR1.1.
+@example
+sr_amf=4096:2160:algorithm=sr1-1
+@end example
+@end itemize
+
 @section ssim
 
 Obtain the SSIM (Structural SImilarity Metric) between two input videos.
@@ -25565,6 +25635,174 @@ Example:
 ffmpeg -i ref.mpg -vf vmafmotion -f null -
 @end example
 
+@anchor{vpp_amf}
+@section vpp_amf
+
+Scale (resize) and convert colorspace, transfer characteristics or color 
primaries for the input video, using AMD Advanced Media Framework library for 
hardware acceleration.
+Setting the output width and height works in the same way as for the 
@ref{scale} filter.
+
+The filter accepts the following options:
+@table @option
+@item w
+@item h
+Set the output video dimension expression. Default value is the input 
dimension.
+
+Allows for the same expressions as the @ref{scale} filter.
+
+@item scale_type
+Sets the algorithm used for scaling:
+
+@table @var
+@item bilinear
+Bilinear
+
+This is the default.
+
+@item bicubic
+Bicubic
+
+@end table
+
+@item format
+Controls the output pixel format. By default, or if none is specified, the 
input
+pixel format is used.
+
+
+@item force_original_aspect_ratio
+@item force_divisible_by
+Work the same as the identical @ref{scale} filter options.
+
+@anchor{color_profile}
+@item color_profile
+Specify all color properties at once.
+
+The accepted values are:
+@table @samp
+@item bt601
+BT.601
+
+@item bt709
+BT.709
+
+@item bt2020
+BT.2020
+
+@end table
+
+@anchor{trc}
+@item trc
+Specify output transfer characteristics.
+
+The accepted values are:
+@table @samp
+@item bt709
+BT.709
+
+@item gamma22
+Constant gamma of 2.2
+
+@item gamma28
+Constant gamma of 2.8
+
+@item smpte170m
+SMPTE-170M
+
+@item smpte240m
+SMPTE-240M
+
+@item linear
+Linear
+
+@item log
+LOG
+
+@item log-sqrt
+LOG_SQRT
+
+@item iec61966-2-4
+iec61966-2-4
+
+@item bt1361-ecg
+BT1361_ECG
+
+@item iec61966-2-1
+iec61966-2-1
+
+@item bt2020-10
+BT.2020 for 10-bits content
+
+@item bt2020-12
+BT.2020 for 12-bits content
+
+@item smpte2084
+SMPTE2084
+
+@item smpte428
+SMPTE428
+
+@item arib-std-b67
+ARIB_STD_B67
+
+@end table
+
+@anchor{primaries}
+@item primaries
+Specify output color primaries.
+
+The accepted values are:
+@table @samp
+@item bt709
+BT.709
+
+@item bt470m
+BT.470M
+
+@item bt470bg
+BT.470BG or BT.601-6 625
+
+@item smpte170m
+SMPTE-170M or BT.601-6 525
+
+@item smpte240m
+SMPTE-240M
+
+@item film
+film
+
+@item bt2020
+BT.2020
+
+@item smpte428
+SMPTE-428
+
+@item smpte431
+SMPTE-431
+
+@item smpte432
+SMPTE-432
+
+@item jedec-p22
+JEDEC P22 phosphors
+
+@end table
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Scale input to 720p, keeping aspect ratio and ensuring the output is yuv420p.
+@example
+vpp_amf=-2:720:format=yuv420p
+@end example
+
+@item
+Upscale to 4K and change color profile to bt2020.
+@example
+vpp_amf=4096:2160:color_profile=bt2020
+@end example
+@end itemize
+
 @anchor{vstack}
 @section vstack
 Stack input videos vertically.
-- 
2.47.1.windows.1

[FFmpeg-devel] [PATCH 5/5] avcodec/amfenc: redesign to use hwcontext_amf.

2024-12-03 Thread Dmitrii Ovchinnikov
Co-authored-by: Evgeny Pavlov 
v3: cleanup code
---
 libavcodec/amfenc.c  | 875 +--
 libavcodec/amfenc.h  |  34 +-
 libavcodec/amfenc_av1.c  |   8 +-
 libavcodec/amfenc_h264.c |   6 +-
 libavcodec/amfenc_hevc.c |   6 +-
 5 files changed, 306 insertions(+), 623 deletions(-)

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 03d75031f5..b4f5d9c91e 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -22,6 +22,8 @@
 #include "libavutil/avassert.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_amf.h"
+#include "libavutil/hwcontext_amf_internal.h"
 #if CONFIG_D3D11VA
 #include "libavutil/hwcontext_d3d11va.h"
 #endif
@@ -38,6 +40,8 @@
 #include "internal.h"
 #include "libavutil/mastering_display_metadata.h"
 
+#define AMF_AV_FRAME_REF L"av_frame_ref"
+
 static int amf_save_hdr_metadata(AVCodecContext *avctx, const AVFrame *frame, 
AMFHDRMetadata *hdrmeta)
 {
 AVFrameSideData*sd_display;
@@ -112,288 +116,18 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
 AV_PIX_FMT_DXVA2_VLD,
 #endif
 AV_PIX_FMT_P010,
+AV_PIX_FMT_AMF_SURFACE,
 AV_PIX_FMT_NONE
 };
 
-typedef struct FormatMap {
-enum AVPixelFormat   av_format;
-enum AMF_SURFACE_FORMAT  amf_format;
-} FormatMap;
-
-static const FormatMap format_map[] =
-{
-{ AV_PIX_FMT_NONE,   AMF_SURFACE_UNKNOWN },
-{ AV_PIX_FMT_NV12,   AMF_SURFACE_NV12 },
-{ AV_PIX_FMT_P010,   AMF_SURFACE_P010 },
-{ AV_PIX_FMT_BGR0,   AMF_SURFACE_BGRA },
-{ AV_PIX_FMT_RGB0,   AMF_SURFACE_RGBA },
-{ AV_PIX_FMT_GRAY8,  AMF_SURFACE_GRAY8 },
-{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
-{ AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
-};
-
-static enum AMF_SURFACE_FORMAT amf_av_to_amf_format(enum AVPixelFormat fmt)
-{
-int i;
-for (i = 0; i < amf_countof(format_map); i++) {
-if (format_map[i].av_format == fmt) {
-return format_map[i].amf_format;
-}
-}
-return AMF_SURFACE_UNKNOWN;
-}
-
-static void AMF_CDECL_CALL AMFTraceWriter_Write(AMFTraceWriter *pThis,
-const wchar_t *scope, const wchar_t *message)
-{
-AmfTraceWriter *tracer = (AmfTraceWriter*)pThis;
-av_log(tracer->avctx, AV_LOG_DEBUG, "%ls: %ls", scope, message); // \n is 
provided from AMF
-}
-
-static void AMF_CDECL_CALL AMFTraceWriter_Flush(AMFTraceWriter *pThis)
-{
-}
-
-static AMFTraceWriterVtbl tracer_vtbl =
-{
-.Write = AMFTraceWriter_Write,
-.Flush = AMFTraceWriter_Flush,
-};
-
-static int amf_load_library(AVCodecContext *avctx)
-{
-AmfContext*ctx = avctx->priv_data;
-AMFInit_Fn init_fun;
-AMFQueryVersion_Fn version_fun;
-AMF_RESULT res;
-
-ctx->delayed_frame = av_frame_alloc();
-if (!ctx->delayed_frame) {
-return AVERROR(ENOMEM);
-}
-// hardcoded to current HW queue size - will auto-realloc if too small
-ctx->timestamp_list = av_fifo_alloc2(avctx->max_b_frames + 16, 
sizeof(int64_t),
- AV_FIFO_FLAG_AUTO_GROW);
-if (!ctx->timestamp_list) {
-return AVERROR(ENOMEM);
-}
-ctx->dts_delay = 0;
-
-
-ctx->library = dlopen(AMF_DLL_NAMEA, RTLD_NOW | RTLD_LOCAL);
-AMF_RETURN_IF_FALSE(ctx, ctx->library != NULL,
-AVERROR_UNKNOWN, "DLL %s failed to open\n", AMF_DLL_NAMEA);
-
-init_fun = (AMFInit_Fn)dlsym(ctx->library, AMF_INIT_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, init_fun != NULL, AVERROR_UNKNOWN, "DLL %s failed 
to find function %s\n", AMF_DLL_NAMEA, AMF_INIT_FUNCTION_NAME);
-
-version_fun = (AMFQueryVersion_Fn)dlsym(ctx->library, 
AMF_QUERY_VERSION_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, version_fun != NULL, AVERROR_UNKNOWN, "DLL %s 
failed to find function %s\n", AMF_DLL_NAMEA, AMF_QUERY_VERSION_FUNCTION_NAME);
-
-res = version_fun(&ctx->version);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with 
error %d\n", AMF_QUERY_VERSION_FUNCTION_NAME, res);
-res = init_fun(AMF_FULL_VERSION, &ctx->factory);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with 
error %d\n", AMF_INIT_FUNCTION_NAME, res);
-res = ctx->factory->pVtbl->GetTrace(ctx->factory, &ctx->trace);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetTrace() 
failed with error %d\n", res);
-res = ctx->factory->pVtbl->GetDebug(ctx->factory, &ctx->debug);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetDebug() 
failed with error %d\n", res);
-return 0;
-}
-
-#if CONFIG_D3D11VA
-static int amf_init_from_d3d11_device(AVCodecContext *avctx, 
AVD3D11VADeviceContext *hwctx)
-{
-AmfContext *ctx = avctx->priv_data;
-AMF_RESULT res;
-
-res = ctx->context->pVtbl->InitDX11(ctx->context, hwctx->device, 
AMF_DX11_1);
-if (res != AMF_OK) {
-if (res == AMF_NOT_SUPPORTED)
-av_log(avctx, AV_LOG_ERROR, "AMF via D3D11 is not suppor

[FFmpeg-devel] [PATCH 2/5] avcodec: add amfdec.

2024-12-03 Thread Dmitrii Ovchinnikov
From: Evgeny Pavlov 

Added AMF based h264, hevc, av1 decoders.
Co-authored-by: Dmitrii Ovchinnikov 
v2: added encoder reinitialisation
v3: use AMF_SURFACE_UNKNOWN to int decoder(ctx->output_format before)
---
 configure  |   3 +
 libavcodec/Makefile|   7 +-
 libavcodec/allcodecs.c |   3 +
 libavcodec/amfdec.c| 683 +
 libavcodec/amfdec.h|  62 
 5 files changed, 756 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/amfdec.c
 create mode 100644 libavcodec/amfdec.h

diff --git a/configure b/configure
index 591aa53753..0976dc7f63 100755
--- a/configure
+++ b/configure
@@ -3347,6 +3347,7 @@ amrnb_mediacodec_decoder_select="amr_parser"
 amrwb_mediacodec_decoder_deps="mediacodec"
 amrwb_mediacodec_decoder_select="amr_parser"
 av1_amf_encoder_deps="amf"
+av1_amf_decoder_deps="amf"
 av1_cuvid_decoder_deps="cuvid CUVIDAV1PICPARAMS"
 av1_mediacodec_decoder_deps="mediacodec"
 av1_mediacodec_encoder_deps="mediacodec"
@@ -3362,6 +3363,7 @@ av1_vaapi_encoder_select="cbs_av1 vaapi_encode"
 h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m"
 h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m"
 h264_amf_encoder_deps="amf"
+h264_amf_decoder_deps="amf"
 h264_cuvid_decoder_deps="cuvid"
 h264_cuvid_decoder_select="h264_mp4toannexb_bsf"
 h264_mediacodec_decoder_deps="mediacodec"
@@ -3383,6 +3385,7 @@ h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m"
 h264_v4l2m2m_decoder_select="h264_mp4toannexb_bsf"
 h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m"
 hevc_amf_encoder_deps="amf"
+hevc_amf_decoder_deps="amf"
 hevc_cuvid_decoder_deps="cuvid"
 hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf"
 hevc_d3d12va_encoder_select="cbs_h265 d3d12va_encode"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a6e0e0b55e..c976d7ffe7 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -75,7 +75,7 @@ include $(SRC_PATH)/libavcodec/vulkan/Makefile
 OBJS-$(CONFIG_AANDCTTABLES)+= aandcttab.o
 OBJS-$(CONFIG_AC3DSP)  += ac3dsp.o ac3.o ac3tab.o
 OBJS-$(CONFIG_ADTS_HEADER) += adts_header.o 
mpeg4audio_sample_rates.o
-OBJS-$(CONFIG_AMF) += amfenc.o
+OBJS-$(CONFIG_AMF) += amfenc.o amfdec.o
 OBJS-$(CONFIG_AUDIO_FRAME_QUEUE)   += audio_frame_queue.o
 OBJS-$(CONFIG_ATSC_A53)+= atsc_a53.o
 OBJS-$(CONFIG_AUDIODSP)+= audiodsp.o
@@ -172,6 +172,7 @@ OBJS-$(CONFIG_TEXTUREDSPENC)   += texturedspenc.o
 OBJS-$(CONFIG_TPELDSP) += tpeldsp.o
 OBJS-$(CONFIG_VAAPI_ENCODE)+= vaapi_encode.o hw_base_encode.o
 OBJS-$(CONFIG_AV1_AMF_ENCODER) += amfenc_av1.o
+OBJS-$(CONFIG_AV1_AMF_DECODER) += amfdec.o
 OBJS-$(CONFIG_VC1DSP)  += vc1dsp.o
 OBJS-$(CONFIG_VIDEODSP)+= videodsp.o
 OBJS-$(CONFIG_VP3DSP)  += vp3dsp.o
@@ -418,6 +419,7 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o 
h264_cabac.o h264_cavlc.o \
   h264_refs.o \
   h264_slice.o h264data.o h274.o
 OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o
+OBJS-$(CONFIG_H264_AMF_DECODER)+= amfdec.o
 OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuviddec.o
 OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o
 OBJS-$(CONFIG_H264_MEDIACODEC_ENCODER) += mediacodecenc.o
@@ -444,6 +446,7 @@ OBJS-$(CONFIG_HDR_DECODER) += hdrdec.o
 OBJS-$(CONFIG_HDR_ENCODER) += hdrenc.o
 OBJS-$(CONFIG_HEVC_DECODER)+= aom_film_grain.o h274.o 
container_fifo.o
 OBJS-$(CONFIG_HEVC_AMF_ENCODER)+= amfenc_hevc.o
+OBJS-$(CONFIG_HEVC_AMF_DECODER)+= amfdec.o
 OBJS-$(CONFIG_HEVC_CUVID_DECODER)  += cuviddec.o
 OBJS-$(CONFIG_HEVC_D3D12VA_ENCODER)+= d3d12va_encode_hevc.o 
h265_profile_level.o \
   h2645data.o
@@ -1281,7 +1284,7 @@ SKIPHEADERS+= %_tablegen.h
  \
   bitstream_template.h  \
   $(ARCH)/vpx_arith.h   \
 
-SKIPHEADERS-$(CONFIG_AMF)  += amfenc.h
+SKIPHEADERS-$(CONFIG_AMF)  += amfenc.h amfdec.h
 SKIPHEADERS-$(CONFIG_D3D11VA)  += d3d11va.h dxva2_internal.h
 SKIPHEADERS-$(CONFIG_D3D12VA)  += d3d12va_decode.h d3d12va_encode.h
 SKIPHEADERS-$(CONFIG_DXVA2)+= dxva2.h dxva2_internal.h
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 0b559dfc58..62ef77fa3e 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -842,11 +842,13 @@ extern const FFCodec ff_av1_nvenc_encoder;
 extern const FFCodec ff_av1_qsv_decoder;
 extern const FFCodec ff_av1_qsv_encoder;
 extern const FFCodec ff_av1_amf_encoder;
+extern const FFCodec ff_av1_amf_decoder;
 extern const FFCodec ff_av1_mf_encoder;
 extern const FFCodec ff_av1_vaapi_encoder;
 extern const FFCodec f

Re: [FFmpeg-devel] [PATCH v2 3/3] avcodec/cuvid: introduce a ringbuffer to reattach additional data

2024-12-03 Thread Clément Péron
Hi Hendrik,

On Tue, 3 Dec 2024 at 17:47, Devin Heitmueller
 wrote:
>
> On Tue, Dec 3, 2024 at 9:57 AM Hendrik Leppkes  wrote:
> > The real question is, why are you using cuviddec instead of nvdec?
> > side data would already pass through natively with nvdec, and other
> > hwaccel-based decoders.

I think it's a good question and I will try to benchmark performance
and latency of the nvdec against cuvid for my use case.

Are you sure that side data would be natively supported with nvdec?

Reading the source code, the only function I saw is
ff_decode_frame_props(), which will make the side data not properly
sync for my use case.
>
> I suspect there could be benefits if your workload involves alot of
> decoding and the GPU only has a single nvdec unit on it.  Even if it's
> less efficient to do it with CUDA, getting a graphics card with lots
> of CUDA units could very well be cheaper than a card with multiple
> nvdec fixed units on it (each of which might only be able to do 10-15
> decodes depending on codec/resolution/framerate).
>
> Devin
>
> --
> Devin Heitmueller, Senior Software Engineer
> LTN Global Communications
> o: +1 (301) 363-1001
> w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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 3/6] lavc/vvc: Store MIP information over entire CU area

2024-12-03 Thread Frank Plowman
Hi,

Thanks for your review.

On 03/12/2024 10:04, Nuo Mi wrote:
> Hi Frank,
> Thank you for the patch
> 
> On Sat, Nov 30, 2024 at 8:13 PM Frank Plowman  wrote:
> 
>> On 30/11/2024 06:46, Nuo Mi wrote:
>>> On Fri, Nov 29, 2024 at 6:19 AM Frank Plowman 
>> wrote:
>>>
 Previously, the code only stored the MIP mode and transpose flag in the
 relevant tables at the top-left corner of the CU.  This information ends
 up being retrieved in ff_vvc_intra_pred_* not based on the CU position
 but instead the transform unit position (specifically, using the x0 and
 y0 from get_luma_predict_unit).  There might be multiple transform units
 in a CU, hence the top-left corner of the transform unit might not
 coincide with the top-left corner of the CU.  Consequently, we need to
 store the MIP information at all positions in the CU, not only its
 top-left corner, as we already do for the MIP flag.

 Signed-off-by: Frank Plowman 
 ---
  libavcodec/vvc/ctu.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
 index 1e06119cfd..0030938cf5 100644
 --- a/libavcodec/vvc/ctu.c
 +++ b/libavcodec/vvc/ctu.c
 @@ -975,8 +975,8 @@ static void intra_luma_pred_modes(VVCLocalContext
>> *lc)
  for (int y = 0; y < (cb_height>>log2_min_cb_size); y++) {
  int width = cb_width>>log2_min_cb_size;
  memset(&fc->tab.imf[x],  cu->intra_mip_flag, width);
 -fc->tab.imtf[x] = intra_mip_transposed_flag;
 -fc->tab.imm[x]  = intra_mip_mode;
 +memset(&fc->tab.imtf[x], intra_mip_transposed_flag,
 width);
 +memset(&fc->tab.imm[x], intra_mip_mode, width);
>>>
>>>  intra_mip_mode is 4 bits, 2 flags are 2 bits. maybe we can use a uint8_t
>>> for 3 fields,
>>> We only need 1 memset and save 2/3 memory.
>>
>> I've implemented this (patch attached, to be applied atop the set), but
>> it's not as straightforward as it may seem.  In particular, because the
>> tables are read directly from when determining which CABAC context to
>> use for these flags, we have to add quite a lot of extra code in cabac.c
>> to support this special case where the MIP information is a bit field.
>> In my implementation, this was done by adding this coerce_to_bool
>> parameter to get_inc and get_top.  This does actually save a moderate
>> amount of memory though, ~1MB for 4K and ~256kB for 1080p.
>>
> A coding block can be as small as 4x4, so for a 1080p frame, the memory
> required is approximately  2*1920*1080/(4*4) ~= 256 kB.
> However, with a maximum delay of 16 frames, the total memory usage will be
> 256kB * 16=4 MB.
> 
> In your patch, coerce_to_bool is set to 1 only when we are in
> ff_vvc_intra_mip_flag.
> How about defining get_mip_inc like this? This way, we can avoid changing
> get_inc
> 
> static av_always_inline
> uint8_t get_mip_inc (VVCLocalContext *lc, const uint8_t *ctx)
> {
> uint8_t left = 0, top = 0;
> get_left_top(lc, &left, &top, lc->cu->x0, lc->cu->y0, ctx, ctx);
> return !!left + !!top;
> }

What about instead taking a function pointer as an argument to
get_inc/get_left_top which can be used to modify the value read from the
table before using it, or NULL to apply no such modification?  At the
moment, this would only be used for the MIP flag, but if we wanted to
pack other tables in order to save more memory, we could then reuse that
argument in other ways and avoid duplicating the functions for every
case where the in-memory representation differs.  It's not that bad for
get_inc, but if we ever wanted to change the representation of something
which uses get_left_top directly, we would have to duplicate a fair
amount of code.

> 
> BTW: Using pack_mip_info/unpack_mip_info might be shorter and more concise
> than structure_mip_info/destructure_mip_info.

Agreed, will do.

> 
>>
>>>

>>>
>>>  x += pps->min_cb_width;
  }
  cu->intra_pred_mode_y = intra_mip_mode;
 --
 2.47.0

>>
>>
>> --
>> Frank
>>


-- 
Frank

___
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/ffv1enc: Add enum for qtable

2024-12-03 Thread Michael Niedermayer
On Mon, Dec 02, 2024 at 01:08:24PM +0900, Lynne via ffmpeg-devel wrote:
> On 02/12/2024 11:15, Michael Niedermayer wrote:
> 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >   libavcodec/ffv1enc.c| 8 +++-
> >   libavcodec/ffv1enc.h| 6 ++
> >   libavcodec/ffv1enc_vulkan.c | 8 +++-
> >   3 files changed, 20 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
> > index c96c71b1096..696823b7967 100644
> > --- a/libavcodec/ffv1enc.c
> > +++ b/libavcodec/ffv1enc.c
> > @@ -1346,7 +1346,13 @@ static const AVOption options[] = {
> >   { "context", "Context model", OFFSET(context_model), AV_OPT_TYPE_INT,
> >   { .i64 = 0 }, 0, 1, VE },
> >   { "qtable", "Quantization table", OFFSET(qtable), AV_OPT_TYPE_INT,
> > -{ .i64 = -1 }, -1, 2, VE },
> > +{ .i64 = -1 }, -1, 2, VE , .unit = "qtable"},
> > +{ "default", NULL, 0, AV_OPT_TYPE_CONST,
> > +{ .i64 = QTABLE_DEFAULT }, INT_MIN, INT_MAX, VE, .unit = 
> > "qtable" },
> > +{ "8bit", NULL, 0, AV_OPT_TYPE_CONST,
> > +{ .i64 = QTABLE_8BIT }, INT_MIN, INT_MAX, VE, .unit = "qtable" 
> > },
> > +{ "greater8bit", NULL, 0, AV_OPT_TYPE_CONST,
> > +{ .i64 = QTABLE_GT8BIT }, INT_MIN, INT_MAX, VE, .unit = 
> > "qtable" },
> >   { NULL }
> >   };
> > diff --git a/libavcodec/ffv1enc.h b/libavcodec/ffv1enc.h
> > index e22693f2a89..2ecc2d16ec9 100644
> > --- a/libavcodec/ffv1enc.h
> > +++ b/libavcodec/ffv1enc.h
> > @@ -25,6 +25,12 @@
> >   #include "avcodec.h"
> > +enum {
> > +QTABLE_DEFAULT = -1,
> > +QTABLE_8BIT,
> > +QTABLE_GT8BIT,
> > +};
> > +
> >   av_cold int ff_ffv1_encode_init(AVCodecContext *avctx);
> >   av_cold int ff_ffv1_write_extradata(AVCodecContext *avctx);
> >   av_cold int ff_ffv1_encode_setup_plane_info(AVCodecContext *avctx,
> > diff --git a/libavcodec/ffv1enc_vulkan.c b/libavcodec/ffv1enc_vulkan.c
> > index cdb0096969e..41d396fb32c 100644
> > --- a/libavcodec/ffv1enc_vulkan.c
> > +++ b/libavcodec/ffv1enc_vulkan.c
> > @@ -1795,7 +1795,13 @@ static const AVOption vulkan_encode_ffv1_options[] = 
> > {
> >   { "range_tab", "Range with custom table", 0, AV_OPT_TYPE_CONST,
> >   { .i64 = AC_RANGE_CUSTOM_TAB }, INT_MIN, INT_MAX, VE, .unit = 
> > "coder" },
> >   { "qtable", "Quantization table", OFFSET(ctx.qtable), AV_OPT_TYPE_INT,
> > -{ .i64 = -1 }, -1, 2, VE },
> > +{ .i64 = -1 }, -1, 2, VE , .unit = "qtable"},
> > +{ "default", NULL, 0, AV_OPT_TYPE_CONST,
> > +{ .i64 = QTABLE_DEFAULT }, INT_MIN, INT_MAX, VE, .unit = 
> > "qtable" },
> > +{ "8bit", NULL, 0, AV_OPT_TYPE_CONST,
> > +{ .i64 = QTABLE_8BIT }, INT_MIN, INT_MAX, VE, .unit = "qtable" 
> > },
> > +{ "greater8bit", NULL, 0, AV_OPT_TYPE_CONST,
> > +{ .i64 = QTABLE_GT8BIT }, INT_MIN, INT_MAX, VE, .unit = 
> > "qtable" },
> >   { "slices_h", "Number of horizontal slices", OFFSET(num_h_slices), 
> > AV_OPT_TYPE_INT,
> >   { .i64 = -1 }, -1, 1024, VE },
> 
> 
> Thanks, tested and it works fine.

will apply

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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 v2] lavc/vvc: Use a bitfield to store MIP information

2024-12-03 Thread Frank Plowman
Reduces memory consumption by ~4MB for 1080p video with a maximum delay
of 16 frames by packing various information related to MIP:
* intra_mip_flag, 1 bit
* intra_mip_transposed_flag, 1 bit
* intra_mip_mode, 4 bits
Into a single byte.

Co-authored-by: Nuo Mi 
Signed-off-by: Frank Plowman 
---
Changes since v1 (posted as attachment in other thread).
* Renamed (de)?structure_mip_info to (un)?pack_mip_info
* Remove coerce_to_bool argument added to get_inc.  Instead, define a
  variant of get_inc, get_mip_inc, particular to the MIP flag which
  performs the necessary transformations.

I did also try implementing this patch as I mentioned I might on the
other thread: by adding a function pointer argument to get_inc and
get_left_top which can be used to transform values read from tables
before they are used.  I realised while doing so, however, that there is
really no need for such complexity for get_left_top as it returns left
and top separately, hence the caller can simply transform them itself.
Then, get_inc is very simple and only called in two places, and so it is
not fitting to employ such heavy-duty abstractions only for that
function.

---
 libavcodec/vvc/cabac.c  | 10 +-
 libavcodec/vvc/ctu.c| 12 +---
 libavcodec/vvc/dec.c|  2 --
 libavcodec/vvc/dec.h|  4 +---
 libavcodec/vvc/dsp.c|  9 +
 libavcodec/vvc/intra_template.c |  5 +++--
 6 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/libavcodec/vvc/cabac.c b/libavcodec/vvc/cabac.c
index 0d45eec751..5510144893 100644
--- a/libavcodec/vvc/cabac.c
+++ b/libavcodec/vvc/cabac.c
@@ -1257,11 +1257,19 @@ int ff_vvc_pred_mode_ibc_flag(VVCLocalContext *lc, 
const int is_chroma)
 return GET_CABAC(PRED_MODE_IBC_FLAG + inc);
 }
 
+static av_always_inline
+uint8_t get_mip_inc(VVCLocalContext *lc, const uint8_t *ctx)
+{
+uint8_t left = 0, top = 0;
+get_left_top(lc, &left, &top, lc->cu->x0, lc->cu->y0, ctx, ctx);
+return (left & 1) + (top & 1);
+}
+
 int ff_vvc_intra_mip_flag(VVCLocalContext *lc, const uint8_t *intra_mip_flag)
 {
 const int w   = lc->cu->cb_width;
 const int h   = lc->cu->cb_height;
-const int inc =  (w > h * 2 || h > w * 2) ? 3 : get_inc(lc, 
intra_mip_flag);
+const int inc =  (w > h * 2 || h > w * 2) ? 3 : get_mip_inc(lc, 
intra_mip_flag);
 return GET_CABAC(INTRA_MIP_FLAG + inc);
 }
 
diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
index 505099bc76..382fa582f4 100644
--- a/libavcodec/vvc/ctu.c
+++ b/libavcodec/vvc/ctu.c
@@ -946,6 +946,12 @@ static void derive_chroma_intra_pred_mode(VVCLocalContext 
*lc,
 }
 }
 
+static av_always_inline uint8_t pack_mip_info(int intra_mip_flag,
+int intra_mip_transposed_flag, int intra_mip_mode)
+{
+return (intra_mip_mode << 2) | (intra_mip_transposed_flag << 1) | 
intra_mip_flag;
+}
+
 static void intra_luma_pred_modes(VVCLocalContext *lc)
 {
 VVCFrameContext *fc = lc->fc;
@@ -974,9 +980,9 @@ static void intra_luma_pred_modes(VVCLocalContext *lc)
 int x = y_cb * pps->min_cb_width + x_cb;
 for (int y = 0; y < (cb_height>>log2_min_cb_size); y++) {
 int width = cb_width>>log2_min_cb_size;
-memset(&fc->tab.imf[x],  cu->intra_mip_flag, width);
-memset(&fc->tab.imtf[x], intra_mip_transposed_flag, width);
-memset(&fc->tab.imm[x], intra_mip_mode, width);
+const uint8_t mip_info = pack_mip_info(cu->intra_mip_flag,
+intra_mip_transposed_flag, intra_mip_mode);
+memset(&fc->tab.imf[x], mip_info, width);
 x += pps->min_cb_width;
 }
 cu->intra_pred_mode_y = intra_mip_mode;
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index 50be9f9922..fef7339294 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -128,7 +128,6 @@ static void min_cb_tl_init(TabList *l, VVCFrameContext *fc)
 tl_init(l, 1, changed);
 
 TL_ADD(imf,  pic_size_in_min_cb);
-TL_ADD(imm,  pic_size_in_min_cb);
 
 for (int i = LUMA; i <= CHROMA; i++)
 TL_ADD(cb_width[i],  pic_size_in_min_cb);   //is_a0_available requires 
this
@@ -143,7 +142,6 @@ static void min_cb_nz_tl_init(TabList *l, VVCFrameContext 
*fc)
 tl_init(l, 0, changed);
 
 TL_ADD(skip, pic_size_in_min_cb);
-TL_ADD(imtf, pic_size_in_min_cb);
 TL_ADD(ipm,  pic_size_in_min_cb);
 
 for (int i = LUMA; i <= CHROMA; i++) {
diff --git a/libavcodec/vvc/dec.h b/libavcodec/vvc/dec.h
index f7cd5b678c..0f8f1f721d 100644
--- a/libavcodec/vvc/dec.h
+++ b/libavcodec/vvc/dec.h
@@ -161,9 +161,7 @@ typedef struct VVCFrameContext {
 uint8_t *skip;  ///< CuSkipFlag[][]
 uint8_t *ispmf; ///< 
intra_sub_partitions_mode_flag
 uint8_t *msm[2];///< 
MttSplitMode[][][] in 32 pixels
-uint8_t *imf;  

Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: CC election

2024-12-03 Thread Vittorio Giovara
On Thu, Nov 28, 2024 at 9:33 AM Anton Khirnov  wrote:

> Hi all,
> the current Community Committee (CC) was elected on 2023-12-05 and its
> mandate lasts for one year, so we should hold a new election soon. If
> there are no unforeseen circumstances, I would like to start the vote on
> Monday 2024-12-09.
>
> As a reminder, the CC is in charge of resolving code of conduct
> violationd and other personal conflicts in the project. If you would
> like to be a CC member, please say so in a reply to this email.
>

Hi Anton,
I am happy to volunteer as CC.

My campaign will consist of:
* swift action upon those who violate the CoC within a reasonable timeframe
* repercussions for those who abuse the CC, for example clogging the system
by reporting 100s of messages just because they contain a dissenting
opinion or because you don't like their tone
* advice and moderation, not just even when the CC is involved, but
providing suggestions on the language to use when necessary (ie. using more
inclusive words)

Cheers
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".