[FFmpeg-devel] [PATCH v2] Use AVBufferPool in MOV

[Arnaud MASSERANN]

Most demuxers allocate a new buffer for each packet.
For MOV, this can be problematic, because of some high-bitrate
codecs like ProRes/HAPQ/NotchLC.

Use pools of buffer instead.

For some test media, demuxing goes from 20ms/frame to 11ms/frame,
close to the perf of ReadFile (10ms/frame), making it possible
to read the media at 60Hz.

Signed-off-by: Arnaud Masserann 
---
 libavformat/demux.h | 11 +++
 libavformat/isom.h  |  2 ++
 libavformat/mov.c   | 20 ++--
 libavformat/utils.c | 30 ++
 4 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/libavformat/demux.h b/libavformat/demux.h
index e83d84a201..bd76a90349 100644
--- a/libavformat/demux.h
+++ b/libavformat/demux.h
@@ -338,4 +338,15 @@ int ff_find_stream_index(const AVFormatContext *s, int id);
 
 int ff_buffer_packet(AVFormatContext *s, AVPacket *pkt);
 
+/**
+ * Like av_get_packet, but allocates the AVPacket's buffer from a pool.
+ *
+ * @param sassociated IO context
+ * @param pool the pool of buffer; must be initialized with a sufficient size
+ * @param pkt packet
+ * @param size desired payload size
+ * @return >0 (read size) if OK, AVERROR_xxx otherwise
+ */
+int ff_get_pooled_packet(AVIOContext *s, AVBufferPool* pool, AVPacket *pkt, 
int size);
+
 #endif /* AVFORMAT_DEMUX_H */
diff --git a/libavformat/isom.h b/libavformat/isom.h
index f18b15bbff..9ecfdc9354 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -276,6 +276,8 @@ typedef struct MOVStreamContext {
 } cenc;
 
 struct IAMFDemuxContext *iamf;
+
+AVBufferPool* pools[32];
 } MOVStreamContext;
 
 typedef struct HEIFItem {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 24feadb95b..84fad85f3d 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -9859,6 +9859,7 @@ static void mov_free_encryption_index(MOVEncryptionIndex 
**index) {
 static void mov_free_stream_context(AVFormatContext *s, AVStream *st)
 {
 MOVStreamContext *sc = st->priv_data;
+int i;
 
 if (!sc || --sc->refcount) {
 st->priv_data = NULL;
@@ -9915,6 +9916,9 @@ static void mov_free_stream_context(AVFormatContext *s, 
AVStream *st)
 ff_iamf_read_deinit(sc->iamf);
 #endif
 av_freep(&sc->iamf);
+
+for (i = 0; i < FF_ARRAY_ELEMS(sc->pools); i++)
+av_buffer_pool_uninit(&sc->pools[i]);
 }
 
 static int mov_read_close(AVFormatContext *s)
@@ -10937,6 +10941,16 @@ static int mov_finalize_packet(AVFormatContext *s, 
AVStream *st, AVIndexEntry *s
 return 0;
 }
 
+static AVBufferPool *mov_pool_get(AVBufferPool* pools[32], int size)
+{
+int index = av_log2(size + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!pools[index]) {
+int pool_size = 2 << index;
+pools[index] = av_buffer_pool_init(pool_size, NULL);
+}
+return pools[index];
+}
+
 static int mov_read_packet(AVFormatContext *s, AVPacket *pkt)
 {
 MOVContext *mov = s->priv_data;
@@ -11043,8 +11057,10 @@ static int mov_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 return FFERROR_REDO;
 }
 #endif
-else
-ret = av_get_packet(sc->pb, pkt, sample->size);
+else{
+AVBufferPool* pool = mov_pool_get(sc->pools, sample->size);
+ret = ff_get_pooled_packet(sc->pb, pool, pkt, sample->size);
+}
 if (ret < 0) {
 if (should_retry(sc->pb, ret)) {
 mov_current_sample_dec(sc);
diff --git a/libavformat/utils.c b/libavformat/utils.c
index e892e8bde7..3b92a10159 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -34,6 +34,7 @@
 #include "avformat.h"
 #include "avio_internal.h"
 #include "internal.h"
+#include "demux.h"
 #if CONFIG_NETWORK
 #include "network.h"
 #endif
@@ -104,6 +105,35 @@ FF_ENABLE_DEPRECATION_WARNINGS
 return append_packet_chunked(s, pkt, size);
 }
 
+int ff_get_pooled_packet(AVIOContext *s, AVBufferPool* pool, AVPacket *pkt, 
int size)
+{
+#if FF_API_INIT_PACKET
+FF_DISABLE_DEPRECATION_WARNINGS
+av_init_packet(pkt);
+pkt->data = NULL;
+pkt->size = 0;
+FF_ENABLE_DEPRECATION_WARNINGS
+#else
+av_packet_unref(pkt);
+#endif
+pkt->pos  = avio_tell(s);
+
+if(!pool)
+return AVERROR(ENOMEM);
+
+pkt->buf = av_buffer_pool_get(pool);
+if(!pkt->buf)
+return AVERROR(ENOMEM);
+
+if(pkt->buf->size < size){
+av_packet_unref(pkt);
+return AVERROR(ENOMEM);
+}
+
+return append_packet_chunked(s, pkt, size);
+}
+
+
 int av_append_packet(AVIOContext *s, AVPacket *pkt, int size)
 {
 if (!pkt->size)
-- 
2.34.1

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

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

Re: [FFmpeg-devel] [PATCH v2 0/3] Add WASM simd support

[Zhao Zhili]

> On Nov 27, 2024, at 20:35, Zhao Zhili  wrote:
> 
> Ping.

Ping again.

> 
>> On Nov 20, 2024, at 20:44, Zhao Zhili  wrote:
>> 
>> From: Zhao Zhili 
>> 
>> v2:
>> 1. Remove unused include
>> 2. Remove words on intrinsics vs handwritten assembly in wasm context.
>> 
>> Zhao Zhili (3):
>> configure: Add wasm as a fake arch
>> tests/checkasm: Add partial support for wasm
>> avcodec/hevc: Add wasm simd128 idct
>> 
>> Makefile|   3 +-
>> configure   |  16 +
>> ffbuild/arch.mak|   2 +
>> libavcodec/Makefile |   1 +
>> libavcodec/hevc/dsp.c   |   2 +
>> libavcodec/hevc/dsp.h   |   1 +
>> libavcodec/wasm/hevc/Makefile   |   3 +
>> libavcodec/wasm/hevc/dsp_init.c |  45 ++
>> libavcodec/wasm/hevc/idct.c | 869 
>> libavcodec/wasm/hevc/idct.h |  36 ++
>> libavutil/cpu.c |   6 +
>> libavutil/cpu.h |   3 +
>> libavutil/cpu_internal.h|   2 +
>> libavutil/tests/cpu.c   |   2 +
>> libavutil/wasm/Makefile |   1 +
>> libavutil/wasm/cpu.c|  42 ++
>> tests/checkasm/checkasm.c   |   8 +
>> tests/checkasm/checkasm.h   |  15 +-
>> 18 files changed, 1054 insertions(+), 3 deletions(-)
>> create mode 100644 libavcodec/wasm/hevc/Makefile
>> create mode 100644 libavcodec/wasm/hevc/dsp_init.c
>> create mode 100644 libavcodec/wasm/hevc/idct.c
>> create mode 100644 libavcodec/wasm/hevc/idct.h
>> create mode 100644 libavutil/wasm/Makefile
>> create mode 100644 libavutil/wasm/cpu.c
>> 
>> -- 
>> 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 08/10] swscale/swscale_unscaled: Fix odd height with nv24_to_yuv420p_chroma()

[Ramiro Polla]

Hi Michael,

On Mon, Dec 2, 2024 at 1:33 AM Michael Niedermayer
 wrote:
> On Sat, Sep 28, 2024 at 02:01:33AM +0200, Michael Niedermayer wrote:
> > On Wed, Sep 25, 2024 at 03:16:30PM +0200, Ramiro Polla wrote:
> > > On Tue, Sep 24, 2024 at 3:35 PM Michael Niedermayer
> > >  wrote:
> > > > On Mon, Sep 23, 2024 at 12:42:22AM +0200, Ramiro Polla wrote:
> > > > > Hi,
> > > > >
> > > > > On Mon, Sep 23, 2024 at 12:04 AM Michael Niedermayer
> > > > >  wrote:
> > > > > >
> > > > > > Fixes: out of array read
> > > > > > Fixes: 71726/clusterfuzz-testcase-ffmpeg_SWS_fuzzer-5876893532880896
> > > > > >
> > > > > > Found-by: continuous fuzzing process 
> > > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > > > Signed-off-by: Michael Niedermayer 
> > > > > > ---
> > > > > >  libswscale/swscale_unscaled.c | 2 ++
> > > > > >  1 file changed, 2 insertions(+)
> > > > > >
> > > > > > diff --git a/libswscale/swscale_unscaled.c 
> > > > > > b/libswscale/swscale_unscaled.c
> > > > > > index dc1d5f35932..d403c953cc7 100644
> > > > > > --- a/libswscale/swscale_unscaled.c
> > > > > > +++ b/libswscale/swscale_unscaled.c
> > > > > > @@ -230,6 +230,8 @@ static void nv24_to_yuv420p_chroma(uint8_t 
> > > > > > *dst1, int dstStride1,
> > > > > >  const uint8_t *src2 = src + srcStride;
> > > > > >  // average 4 pixels into 1 (interleaved U and V)
> > > > > >  for (int y = 0; y < h; y += 2) {
> > > > > > +if (y + 1 == h)
> > > > > > +src2 = src1;
> > > > > >  for (int x = 0; x < w; x++) {
> > > > > >  dst1[x] = (src1[4 * x + 0] + src1[4 * x + 2] +
> > > > > > src2[4 * x + 0] + src2[4 * x + 2]) >> 2;
> > > > >
> > > > > I would prefer to keep nv24_to_yuv420p_chroma() expecting height to be
> > > > > a multiple of 2. We could add && !(c->srcH & 1) before selecting
> > > > > nv24ToYuv420Wrapper.
> > > >
> > > > what advantage does this have ?
> > >
> > > This would also have the benefit of keeping the function clearer, and
> > > we wouldn't have to add special cases that might or might not be ok.
> >
> > > It would also make it easier to write simd code, since we wouldn't
> > > have to worry about these special cases.
> >
> > The SIMD code could support a subset of the c code
> >
> >
> > >
> > > It is also easy to forget these corner cases, which leads to some
> > > converters behaving differently in corner cases. For example, the
> > > current yuyv422 to yuv420p scaler just doesn't output the last line if
> > > it has an odd height. What is the correct fix? Should we convert the
> > > last line differently like in this case? Should we duplicate the
> > > second-to-last line? Should we just add a couple lines of code to
> > > tweak the converter? Should we instead call this function with an even
> > > height, and call another function for the last line?
> >
> > >
> > > IMO a converter to yuv420p with odd width or height shouldn't be an
> > > unscaled converter, since we're effectively scaling the chroma planes
> > > (and not just by a factor of two). In this case, the regular scaler
> > > would be used.
> >
> > Iam not sure i understand correctly, but
> > assuming a 99 lines 4:4:4 scaled to 99 lines 4:2:0
> > the chroma here is not a simple "99 to 50 lines rescaling"
> > the chroma samples must stay co-located in relation to the luma samples
> > that can only happen with s 2:1 not a 99:50 rescaling
> > but maybe i misunderstood what you meant
>
> The fuzzer found another sample for this issue:
> 377735917/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-6686071112400896
>
> I still think my patch is fine, if someone else wants to disable the code
> from being used for odd sizes thats not breaking the code, it just would
> then not be used in some cases it could be used for.
>
> If you prefer to only disable this for odd cases, please disable it.
> I just want the bug fixed and not left open

I planned on going over the unscaled subsampled conversion functions
and making sure they all work with odd widths and heights in a
consistent way, but I haven't gotten around to it, and I don't think
I'll have time in the near future.

So I guess for now this patch is ok.

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

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

Re: [FFmpeg-devel] [PATCH] avutil/mem_internal: Don't use alignas for MSVC

[Zhao Zhili]

> On Dec 2, 2024, at 20:11, Hendrik Leppkes  wrote:
> 
> On Mon, Dec 2, 2024 at 11:28 AM Zhao Zhili
>  wrote:
>> 
>> 
>>> On Dec 2, 2024, at 00:53, James Almer  wrote:
>>> 
>>> On 11/30/2024 6:13 AM, Zhao Zhili wrote:
 From: Zhao Zhili 
 MSVC messed up standard C features, again.
 ---
 libavutil/mem_internal.h | 4 
 1 file changed, 4 insertions(+)
 diff --git a/libavutil/mem_internal.h b/libavutil/mem_internal.h
 index 249ec3a642..2eb4aef5b0 100644
 --- a/libavutil/mem_internal.h
 +++ b/libavutil/mem_internal.h
 @@ -78,6 +78,10 @@
 #define DECLARE_ALIGNED_T(n,t,v)alignas(FFMIN(n, 16)) t v
 #define DECLARE_ASM_ALIGNED(n,t,v)  alignas(FFMIN(n, 16)) t av_used v
 #define DECLARE_ASM_CONST(n,t,v)alignas(FFMIN(n, 16)) static const 
 t av_used v
 +#elif defined(_MSC_VER)
 +#define DECLARE_ALIGNED_T(n,t,v)__declspec(align(n)) t v
 +#define DECLARE_ASM_ALIGNED(n,t,v)  __declspec(align(n)) t v
 +#define DECLARE_ASM_CONST(n,t,v)__declspec(align(n)) static const 
 t v
 #else
 #define DECLARE_ALIGNED_T(n,t,v)alignas(n) t v
 #define DECLARE_ASM_ALIGNED(n,t,v)  alignas(n) t av_used v
>>> 
>>> Ok.
>> 
>> I have tested with different msvc version on godbolt.org 
>> .
>> 
>> MSVC v19.25 VS16.5 and below doesn’t support alignas.
>> 
>> Since v19.25 VS16.7 the build seems fine. And fate-test on my machine with 
>> VS2022 have no problem.
>> 
>> Does anyone get other problems with MSVC alignas support?
>> 
> 
> Current master doesn't pass fate on the latest VS2022 for me right here.
> I've been trying to look into whats going on, but haven't had the
> time, so please push this in the meantime.

Pushed, sorry for the break.

> 
> - 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".

___
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] Check MSE bound in FATE

[Michael Niedermayer]

Hi

On Sun, Dec 01, 2024 at 10:17:15PM -0800, Pierre-Anthony Lemieux wrote:
> Hi all,
> 
> Osamu and I are looking at adding FATE tests that checks that the MSE
> of a decode image compared to a reference image does not exceed a
> conformance threshold (see [1]).
> 
> Is there a precedent for adding small shell scripts along the lines of
> the following to FATE?
> 
> https://gist.github.com/palemieux/99b36faa9108089440f2a68df0f2c0a7
> 
> Multiple tests might reuse the same approach.
> 

> Any alternatives?

not sure this is what you are asking for but there is
tests/tiny_psnr.c

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier


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

[Frank Plowman]

On 02/12/2024 14:27, Chris Warrington via ffmpeg-devel wrote:
> When a stream has ALF filtering enabled but not CC-ALF, the CC-ALF set 
> indexes alf->ctb_cc_idc are being read uninitialized during ALF filtering.
> 
> This change initializes alf->ctb_cc_idc whenever ALF is enabled.
> 
> Ref. https://trac.ffmpeg.org/ticket/11325
> 
> ---
>  libavcodec/vvc/ctu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
> index a32abdeb62..c972dcc33e 100644
> --- a/libavcodec/vvc/ctu.c
> +++ b/libavcodec/vvc/ctu.c
> @@ -2288,6 +2288,7 @@ static void alf_params(VVCLocalContext *lc, const int 
> rx, const int ry)
>  ALFParams *alf= &CTB(fc->tab.alf, rx, ry);
> 
>  alf->ctb_flag[LUMA] = alf->ctb_flag[CB] = alf->ctb_flag[CR] = 0;
> +alf->ctb_cc_idc[0] = alf->ctb_cc_idc[1] = 0;
>  if (sh->sh_alf_enabled_flag) {
>  alf->ctb_flag[LUMA] = ff_vvc_alf_ctb_flag(lc, rx, ry, LUMA);
>  if (alf->ctb_flag[LUMA]) {
> @@ -2318,7 +2319,6 @@ static void alf_params(VVCLocalContext *lc, const int 
> rx, const int ry)
>  const uint8_t cc_enabled[] = { sh->sh_alf_cc_cb_enabled_flag, 
> sh->sh_alf_cc_cr_enabled_flag };
>  const uint8_t cc_aps_id[]  = { sh->sh_alf_cc_cb_aps_id, 
> sh->sh_alf_cc_cr_aps_id };
>  for (int i = 0; i < 2; i++) {
> -alf->ctb_cc_idc[i] = 0;
>  if (cc_enabled[i]) {
>  const VVCALF *aps = fc->ps.alf_list[cc_aps_id[i]];
>  alf->ctb_cc_idc[i] = ff_vvc_alf_ctb_cc_idc(lc, rx, ry, i, 
> aps->num_cc_filters[i]);
> --
> 2.43.0
> 
> 
> This message and any attachment are confidential and may be privileged or 
> otherwise protected from disclosure. If you are not the intended recipient, 
> please notify the sender immediately and delete this message and any 
> attachment from your system. Do not copy them or disclose the contents to any 
> other person.

LGTM.

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".

Re: [FFmpeg-devel] [RFC] infrastructure documentation

[Michael Niedermayer]

Hi

On Mon, Dec 02, 2024 at 09:12:55AM -1000, compn wrote:
> On Mon, 2 Dec 2024 19:44:43 +0100, Michael Niedermayer wrote:
> 
> > Hi
> > 
> > On Sat, Nov 30, 2024 at 11:08:29PM +0100, Michael Niedermayer wrote:
> > > On Sat, Nov 30, 2024 at 10:58:03PM +0100, martin schitter wrote:  
> > > > ffmpeg-internals may sound nicer  
> > > 
> > > ok, sounds good to me.
> > > ill wait a day or 2 before creating it, in case someone wants to
> > > suggest another one  
> > 
> > repository created:
> > g...@git.ffmpeg.org:ffmpeg-internals
> 
> can you move doc/infra.txt there.

if the community wants that, i could

do people want that ?

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

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

Re: [FFmpeg-devel] [PATCH] avformat: add AV1 RTP depacketizer and packetizer

[Chris Hodges]

Hi,

On 11/25/24 18:47, Tristan Matthews via ffmpeg-devel wrote:


One nit I'd add is that since the RTP AV1 spec is still in draft (according to 
https://aomediacodec.github.io/av1-rtp-spec/) this feature should probably be 
marked experimental as is done for VP9 in RTP, see:
https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/f8e91ab05ff3d111626ab8a3b5d570865a934f07:/libavformat/rtpenc.c#l221

in which case CLI users will have to add `-strict experimental` to their 
options.


I've added this as suggested.


For the keyframe detection issue I'm not sure if this is something missing in 
FFMPEG's RTP stack (e.g. I've noticed that both GStreamer and libwebrtc signal 
that a buffer contains a keyframe at a higher level), but if not could you set 
it if you're dealing with a FRAME OBU of type 0 (keyframe) or 2 (intra-only)? 
You'd need to parse the OBU to extract that however.


It turns out this was a lapsus on my side, when I used the flags field 
in the RTPMuxContext structure instead of the flags in AVPacket. After 
transferring the key frame information to the encoder function, I could 
remove the workaround.


I also added the key frame info to the AVPacket during demuxing that was 
missing before.


New patch attached.

--
Best regards, Chris--- Begin Message ---
Add RTP packetizer and depacketizer according to (most)
of the official AV1 RTP specification. This enables
streaming via RTSP between ffmpeg and ffmpeg and has
also been tested to work with AV1 RTSP streams via
GStreamer.

It also adds the required SDP attributes for AV1.

AV1 RTP encoding is marked as experimental due to
draft specification status (courtesy of Tristan).

Change-Id: Ie7f984b97be54d86d06bc73fa97c6faa8ffabf89
Signed-off-by: Chris Hodges 
---
 libavformat/Makefile |   2 +
 libavformat/demux.c  |   1 +
 libavformat/rtp_av1.h| 128 +++
 libavformat/rtpdec.c |   1 +
 libavformat/rtpdec_av1.c | 421 +++
 libavformat/rtpdec_formats.h |   1 +
 libavformat/rtpenc.c |  14 ++
 libavformat/rtpenc.h |   1 +
 libavformat/rtpenc_av1.c | 294 
 libavformat/sdp.c|  30 +++
 10 files changed, 893 insertions(+)
 create mode 100644 libavformat/rtp_av1.h
 create mode 100644 libavformat/rtpdec_av1.c
 create mode 100644 libavformat/rtpenc_av1.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 7ca68a7036..1200668a2f 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -47,6 +47,7 @@ OBJS-$(CONFIG_RTPDEC)+= rdt.o 
  \
 rtpdec_ac3.o\
 rtpdec_amr.o\
 rtpdec_asf.o\
+rtpdec_av1.o\
 rtpdec_dv.o \
 rtpdec_g726.o   \
 rtpdec_h261.o   \
@@ -515,6 +516,7 @@ OBJS-$(CONFIG_RTP_MUXER) += rtp.o \
 rtpenc_aac.o \
 rtpenc_latm.o\
 rtpenc_amr.o \
+rtpenc_av1.o \
 rtpenc_h261.o\
 rtpenc_h263.o\
 rtpenc_h263_rfc2190.o \
diff --git a/libavformat/demux.c b/libavformat/demux.c
index cba1f2e4df..8357a3bff1 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -111,6 +111,7 @@ static int set_codec_from_probe_data(AVFormatContext *s, 
AVStream *st,
 { "aac",AV_CODEC_ID_AAC,  AVMEDIA_TYPE_AUDIO},
 { "ac3",AV_CODEC_ID_AC3,  AVMEDIA_TYPE_AUDIO},
 { "aptx",   AV_CODEC_ID_APTX, AVMEDIA_TYPE_AUDIO},
+{ "av1",AV_CODEC_ID_AV1,  AVMEDIA_TYPE_VIDEO},
 { "dts",AV_CODEC_ID_DTS,  AVMEDIA_TYPE_AUDIO},
 { "dvbsub", AV_CODEC_ID_DVB_SUBTITLE, AVMEDIA_TYPE_SUBTITLE },
 { "dvbtxt", AV_CODEC_ID_DVB_TELETEXT, AVMEDIA_TYPE_SUBTITLE },
diff --git a/libavformat/rtp_av1.h b/libavformat/rtp_av1.h
new file mode 100644
index 00..a353fc0e4e
--- /dev/null
+++ b/libavformat/rtp_av1.h
@@ -0,0 +1,128 @@
+/*
+ * Shared definitions and helper functions for
+ * AV1 (de)packetization.
+ * Copyright (c) 2024 Axis Communications
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your optio

Re: [FFmpeg-devel] [PATCH 08/10] swscale/swscale_unscaled: Fix odd height with nv24_to_yuv420p_chroma()

[Michael Niedermayer]

Hi Ramiro

On Mon, Dec 02, 2024 at 02:45:34PM +0100, Ramiro Polla wrote:
> Hi Michael,
> 
> On Mon, Dec 2, 2024 at 1:33 AM Michael Niedermayer
>  wrote:
> > On Sat, Sep 28, 2024 at 02:01:33AM +0200, Michael Niedermayer wrote:
> > > On Wed, Sep 25, 2024 at 03:16:30PM +0200, Ramiro Polla wrote:
> > > > On Tue, Sep 24, 2024 at 3:35 PM Michael Niedermayer
> > > >  wrote:
> > > > > On Mon, Sep 23, 2024 at 12:42:22AM +0200, Ramiro Polla wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Mon, Sep 23, 2024 at 12:04 AM Michael Niedermayer
> > > > > >  wrote:
> > > > > > >
> > > > > > > Fixes: out of array read
> > > > > > > Fixes: 
> > > > > > > 71726/clusterfuzz-testcase-ffmpeg_SWS_fuzzer-5876893532880896
> > > > > > >
> > > > > > > Found-by: continuous fuzzing process 
> > > > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > > > > Signed-off-by: Michael Niedermayer 
> > > > > > > ---
> > > > > > >  libswscale/swscale_unscaled.c | 2 ++
> > > > > > >  1 file changed, 2 insertions(+)
> > > > > > >
> > > > > > > diff --git a/libswscale/swscale_unscaled.c 
> > > > > > > b/libswscale/swscale_unscaled.c
> > > > > > > index dc1d5f35932..d403c953cc7 100644
> > > > > > > --- a/libswscale/swscale_unscaled.c
> > > > > > > +++ b/libswscale/swscale_unscaled.c
> > > > > > > @@ -230,6 +230,8 @@ static void nv24_to_yuv420p_chroma(uint8_t 
> > > > > > > *dst1, int dstStride1,
> > > > > > >  const uint8_t *src2 = src + srcStride;
> > > > > > >  // average 4 pixels into 1 (interleaved U and V)
> > > > > > >  for (int y = 0; y < h; y += 2) {
> > > > > > > +if (y + 1 == h)
> > > > > > > +src2 = src1;
> > > > > > >  for (int x = 0; x < w; x++) {
> > > > > > >  dst1[x] = (src1[4 * x + 0] + src1[4 * x + 2] +
> > > > > > > src2[4 * x + 0] + src2[4 * x + 2]) >> 2;
> > > > > >
> > > > > > I would prefer to keep nv24_to_yuv420p_chroma() expecting height to 
> > > > > > be
> > > > > > a multiple of 2. We could add && !(c->srcH & 1) before selecting
> > > > > > nv24ToYuv420Wrapper.
> > > > >
> > > > > what advantage does this have ?
> > > >
> > > > This would also have the benefit of keeping the function clearer, and
> > > > we wouldn't have to add special cases that might or might not be ok.
> > >
> > > > It would also make it easier to write simd code, since we wouldn't
> > > > have to worry about these special cases.
> > >
> > > The SIMD code could support a subset of the c code
> > >
> > >
> > > >
> > > > It is also easy to forget these corner cases, which leads to some
> > > > converters behaving differently in corner cases. For example, the
> > > > current yuyv422 to yuv420p scaler just doesn't output the last line if
> > > > it has an odd height. What is the correct fix? Should we convert the
> > > > last line differently like in this case? Should we duplicate the
> > > > second-to-last line? Should we just add a couple lines of code to
> > > > tweak the converter? Should we instead call this function with an even
> > > > height, and call another function for the last line?
> > >
> > > >
> > > > IMO a converter to yuv420p with odd width or height shouldn't be an
> > > > unscaled converter, since we're effectively scaling the chroma planes
> > > > (and not just by a factor of two). In this case, the regular scaler
> > > > would be used.
> > >
> > > Iam not sure i understand correctly, but
> > > assuming a 99 lines 4:4:4 scaled to 99 lines 4:2:0
> > > the chroma here is not a simple "99 to 50 lines rescaling"
> > > the chroma samples must stay co-located in relation to the luma samples
> > > that can only happen with s 2:1 not a 99:50 rescaling
> > > but maybe i misunderstood what you meant
> >
> > The fuzzer found another sample for this issue:
> > 377735917/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-6686071112400896
> >
> > I still think my patch is fine, if someone else wants to disable the code
> > from being used for odd sizes thats not breaking the code, it just would
> > then not be used in some cases it could be used for.
> >
> > If you prefer to only disable this for odd cases, please disable it.
> > I just want the bug fixed and not left open
> 
> I planned on going over the unscaled subsampled conversion functions
> and making sure they all work with odd widths and heights in a
> consistent way, but I haven't gotten around to it, and I don't think
> I'll have time in the near future.
> 
> So I guess for now this patch is ok.

will apply

thanks!

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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] avutil/mem_internal: Don't use alignas for MSVC

[Zhao Zhili]

> On Dec 2, 2024, at 00:53, James Almer  wrote:
> 
> On 11/30/2024 6:13 AM, Zhao Zhili wrote:
>> From: Zhao Zhili 
>> MSVC messed up standard C features, again.
>> ---
>>  libavutil/mem_internal.h | 4 
>>  1 file changed, 4 insertions(+)
>> diff --git a/libavutil/mem_internal.h b/libavutil/mem_internal.h
>> index 249ec3a642..2eb4aef5b0 100644
>> --- a/libavutil/mem_internal.h
>> +++ b/libavutil/mem_internal.h
>> @@ -78,6 +78,10 @@
>>  #define DECLARE_ALIGNED_T(n,t,v)alignas(FFMIN(n, 16)) t v
>>  #define DECLARE_ASM_ALIGNED(n,t,v)  alignas(FFMIN(n, 16)) t av_used v
>>  #define DECLARE_ASM_CONST(n,t,v)alignas(FFMIN(n, 16)) static const 
>> t av_used v
>> +#elif defined(_MSC_VER)
>> +#define DECLARE_ALIGNED_T(n,t,v)__declspec(align(n)) t v
>> +#define DECLARE_ASM_ALIGNED(n,t,v)  __declspec(align(n)) t v
>> +#define DECLARE_ASM_CONST(n,t,v)__declspec(align(n)) static const t 
>> v
>>  #else
>>  #define DECLARE_ALIGNED_T(n,t,v)alignas(n) t v
>>  #define DECLARE_ASM_ALIGNED(n,t,v)  alignas(n) t av_used v
> 
> Ok.

I have tested with different msvc version on godbolt.org .

MSVC v19.25 VS16.5 and below doesn’t support alignas.

Since v19.25 VS16.7 the build seems fine. And fate-test on my machine with 
VS2022 have no problem.

Does anyone get other problems with MSVC alignas support?

> 
> ___
> 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] swscale/graph: fix memleak of cascaded graphs

[Niklas Haas]

From: Niklas Haas 

Just free them directly and discard the parent context.
---
 libswscale/graph.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/libswscale/graph.c b/libswscale/graph.c
index ee9d9847a9..fbad1fe8c3 100644
--- a/libswscale/graph.c
+++ b/libswscale/graph.c
@@ -292,7 +292,7 @@ static void legacy_chr_pos(SwsGraph *graph, int *chr_pos, 
int override, int *war
 *chr_pos = override;
 }
 
-static int init_legacy_subpass(SwsGraph *graph, SwsContext *sws, int cascaded,
+static int init_legacy_subpass(SwsGraph *graph, SwsContext *sws,
SwsPass *input, SwsPass **output)
 {
 SwsInternal *c = sws_internal(sws);
@@ -308,11 +308,14 @@ static int init_legacy_subpass(SwsGraph *graph, 
SwsContext *sws, int cascaded,
 for (int i = 0; i < num_cascaded; i++) {
 SwsContext *sub = c->cascaded_context[i];
 const int is_last = i + 1 == num_cascaded;
-ret = init_legacy_subpass(graph, sub, 1, input, is_last ? output : 
&input);
+ret = init_legacy_subpass(graph, sub, input, is_last ? output : 
&input);
 if (ret < 0)
 return ret;
+/* Steal cascaded context, so we can free the parent */
+c->cascaded_context[i] = NULL;
 }
 
+sws_free_context(&sws);
 return 0;
 }
 
@@ -336,8 +339,7 @@ static int init_legacy_subpass(SwsGraph *graph, SwsContext 
*sws, int cascaded,
 if (!pass)
 return AVERROR(ENOMEM);
 pass->setup = setup_legacy_swscale;
-if (!cascaded) /* parent context frees this automatically */
-pass->free = free_legacy_swscale;
+pass->free = free_legacy_swscale;
 
 /**
  * For slice threading, we need to create sub contexts, similar to how
@@ -452,7 +454,7 @@ static int add_legacy_sws_pass(SwsGraph *graph, SwsFormat 
src, SwsFormat dst,
 brightness, contrast, saturation);
 }
 
-ret = init_legacy_subpass(graph, sws, 0, input, output);
+ret = init_legacy_subpass(graph, sws, input, output);
 if (ret < 0) {
 sws_free_context(&sws);
 return ret;
-- 
2.47.0

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

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

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

[Clément Péron]

On Sat, 30 Nov 2024 at 12:28, Clément Péron  wrote:
>
> On Fri, 29 Nov 2024 at 23:44, Timo Rothenpieler  wrote:
> >
> > On 29.11.2024 21:46, Clément Péron wrote:
> > > On Fri, 29 Nov 2024 at 20:06, Timo Rothenpieler  
> > > wrote:
> > >>
> > >> On 01.11.2024 18:21, Clément Péron wrote:
> > >>> From: Troy Benson 
> > >>>
> > >>> Cuvid data packet have specific format that don't contain any side data.
> > >>> In order to keep additional information and metadata, we need to 
> > >>> implement
> > >>> a ring buffer and reattach side data to decoded frame.
> > >>>
> > >>> Signed-off-by: Troy Benson 
> > >>> Signed-off-by: Clément Péron 
> > >>> ---
> > >>>libavcodec/cuviddec.c | 175 
> > >>> ++
> > >>>1 file changed, 175 insertions(+)
> > >>>
> > >>> diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
> > >>> index 3fae9c12eb..464da4d2f4 100644
> > >>> --- a/libavcodec/cuviddec.c
> > >>> +++ b/libavcodec/cuviddec.c
> > >>> @@ -51,6 +51,162 @@
> > >>>#define CUVID_HAS_AV1_SUPPORT
> > >>>#endif
> > >>>
> > >>> +/// @brief Structure to store source packets.
> > >>> +/// This struct implements a circular buffer to store source packets.
> > >>> +/// The packets are packets that have already been sent to the decoder.
> > >>> +/// The reason we need the packets is because they may contain 
> > >>> additional information and metadata,
> > >>> +/// that we need to attach to the decoded frame so that the muxers and 
> > >>> filters can use it.
> > >>> +typedef struct sourcePkts
> > >>> +{
> > >>> +/// @brief Array of AVPackets.
> > >>> +AVPacket **pkts;
> > >>> +/// @brief Number of packets to store.
> > >>> +int capacity;
> > >>> +/// @brief Index of the first packet.
> > >>> +int start_idx;
> > >>> +/// @brief Number of packets stored. (typically we found while 
> > >>> testing that this hovers around 8)
> > >>> +int count;
> > >>> +} sourcePkts;
> > >>> +
> > >>> +/// @brief Allocates a sourcePkts structure.
> > >>> +/// @param avctx - AVCodecContext (for logging)
> > >>> +/// @param source_pkts (output)
> > >>> +/// @param capacity - number of pkts to store
> > >>> +/// @return int = 0 on success, < 0 on error
> > >>> +int sourcePkts_alloc(AVCodecContext *avctx, sourcePkts *source_pkts, 
> > >>> int capacity);
> > >>> +
> > >>> +/// @brief Clears the sourcePkts structure of pkts with pts less than 
> > >>> the given pts.
> > >>> +/// @param avctx - AVCodecContext (for logging)
> > >>> +/// @param source_pkts - sourcePkts structure
> > >>> +/// @param pts - pts to clear pkts before
> > >>> +/// @return int = 0 on success, < 0 on error
> > >>> +int sourcePkts_clear(AVCodecContext *avctx, sourcePkts *source_pkts, 
> > >>> int64_t pts);
> > >>> +
> > >>> +/// @brief Converts a logical index to a physical index.
> > >>> +/// @param source_pkts - sourcePkts structure
> > >>> +/// @param idx - logical index
> > >>> +/// @return int - physical index
> > >>> +int sourcePkts_idx(sourcePkts *source_pkts, int idx);
> > >>> +
> > >>> +/// @brief Adds a pkt to the sourcePkts structure.
> > >>> +/// @param avctx - AVCodecContext (for logging)
> > >>> +/// @param source_pkts - sourcePkts structure
> > >>> +/// @param pkt - AVPacket to add
> > >>> +/// @return int = 0 on success, < 0 on error
> > >>> +int sourcePkts_add(AVCodecContext *avctx, sourcePkts *source_pkts, 
> > >>> AVPacket *pkt);
> > >>> +
> > >>> +/// @brief Clears the sourcePkts structure.
> > >>> +/// @param avctx - AVCodecContext (for logging)
> > >>> +/// @param source_pkts - sourcePkts structure
> > >>> +/// @return int = 0 on success, < 0 on error
> > >>> +int sourcePkts_free(AVCodecContext *avctx, sourcePkts *source_pkts);
> > >>> +
> > >>> +/// @brief Finds a pkt with the given pts.
> > >>> +/// @param avctx - AVCodecContext (for logging)
> > >>> +/// @param source_pkts - sourcePkts structure
> > >>> +/// @param pts - pts to find
> > >>> +/// @return int - physical index of pkt, -1 if not found
> > >>> +int sourcePkts_find(AVCodecContext *avctx, sourcePkts *source_pkts, 
> > >>> int64_t pts);
> > >>> +
> > >>> +int sourcePkts_alloc(AVCodecContext *avctx, sourcePkts *source_pkts, 
> > >>> int capacity)
> > >>> +{
> > >>> +assert(source_pkts->pkts == NULL);
> > >>> +source_pkts->pkts = av_malloc_array(capacity, sizeof(AVPacket *));
> > >>> +if (!source_pkts->pkts)
> > >>> +return AVERROR(ENOMEM);
> > >>> +
> > >>> +source_pkts->capacity = capacity;
> > >>> +source_pkts->start_idx = 0;
> > >>> +source_pkts->count = 0;
> > >>> +
> > >>> +av_log(avctx, AV_LOG_TRACE, "sourcePkts_alloc: capacity: %d\n", 
> > >>> capacity);
> > >>> +
> > >>> +return 0;
> > >>> +}
> > >>> +
> > >>> +// Converts a logical index to a physical index.
> > >>> +int sourcePkts_idx(sourcePkts *source_pkts, int idx)
> > >>> +{
> > >>> +return (source_pkts->start_idx + idx) % source_pkts->capacity;
> > >>> +}
> > >>> +
> > >>> +int sourcePkts_find(AVCodecContex

[FFmpeg-devel] [PATCH 1/5] avutil: add hwcontext_amf.

[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.

---
 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 (at your option) any later ve

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

[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   |   1 +
 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, 1065 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..ea3e09fd2d 100755
--- a/configure
+++ b/configure
@@ -3953,6 +3953,7 @@ rubberband_filter_deps="librubberband"
 sab_filter_deps="gpl swscale"
 scale2ref_filter_deps="swscale"
 scale_filter_deps="swscale"
+scale_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)
+{
+AMFFilterContext 

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

[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.

[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

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

[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.38.1.windows.1

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

[Michael Niedermayer]

Hi Marth64

On Sun, Dec 01, 2024 at 01:56:35PM -0600, Marth64 wrote:
> Any opinions on v3?

v3 did build fine when i tested a few days ago IIRC

thx

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

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

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

[Timo Rothenpieler]

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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avutil/mem_internal: Don't use alignas for MSVC

[Hendrik Leppkes]

On Mon, Dec 2, 2024 at 11:28 AM Zhao Zhili
 wrote:
>
>
> > On Dec 2, 2024, at 00:53, James Almer  wrote:
> >
> > On 11/30/2024 6:13 AM, Zhao Zhili wrote:
> >> From: Zhao Zhili 
> >> MSVC messed up standard C features, again.
> >> ---
> >>  libavutil/mem_internal.h | 4 
> >>  1 file changed, 4 insertions(+)
> >> diff --git a/libavutil/mem_internal.h b/libavutil/mem_internal.h
> >> index 249ec3a642..2eb4aef5b0 100644
> >> --- a/libavutil/mem_internal.h
> >> +++ b/libavutil/mem_internal.h
> >> @@ -78,6 +78,10 @@
> >>  #define DECLARE_ALIGNED_T(n,t,v)alignas(FFMIN(n, 16)) t v
> >>  #define DECLARE_ASM_ALIGNED(n,t,v)  alignas(FFMIN(n, 16)) t av_used v
> >>  #define DECLARE_ASM_CONST(n,t,v)alignas(FFMIN(n, 16)) static 
> >> const t av_used v
> >> +#elif defined(_MSC_VER)
> >> +#define DECLARE_ALIGNED_T(n,t,v)__declspec(align(n)) t v
> >> +#define DECLARE_ASM_ALIGNED(n,t,v)  __declspec(align(n)) t v
> >> +#define DECLARE_ASM_CONST(n,t,v)__declspec(align(n)) static const 
> >> t v
> >>  #else
> >>  #define DECLARE_ALIGNED_T(n,t,v)alignas(n) t v
> >>  #define DECLARE_ASM_ALIGNED(n,t,v)  alignas(n) t av_used v
> >
> > Ok.
>
> I have tested with different msvc version on godbolt.org 
> .
>
> MSVC v19.25 VS16.5 and below doesn’t support alignas.
>
> Since v19.25 VS16.7 the build seems fine. And fate-test on my machine with 
> VS2022 have no problem.
>
> Does anyone get other problems with MSVC alignas support?
>

Current master doesn't pass fate on the latest VS2022 for me right here.
I've been trying to look into whats going on, but haven't had the
time, so please push this in the meantime.

- 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".

[FFmpeg-devel] [PATCH] swscale/utils: disable full_chr_h_input optimization for odd width

[Niklas Haas]

From: Niklas Haas 

The basic problem here is that the rgb*ToUV_half_* functions hard-code a
bilinear downsample from src[i] + src[i+1], with no bounds check on the i+1
access.

Due to the signature of the function, we cannot easily plumb the "true" width
into the function body to perform a bounds check. Similarly, we cannot easily
pre-pad the input because it is typically reading from the original input
frame, which would require a full memcpy to pad. Either of these solutions are
more trouble than the feature is worth, so just disable it on odd input sizes.

Fixes: use of uninitialized value
Fixes: ticket #11265
Signed-off-by: Niklas Haas 
Sponsored-by: Sovereign Tech Fund
---
 libswscale/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libswscale/utils.c b/libswscale/utils.c
index 26ea6062a0..32f90e366e 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1535,7 +1535,7 @@ av_cold int ff_sws_init_single_context(SwsContext *sws, 
SwsFilter *srcFilter,
 
 /* drop every other pixel for chroma calculation unless user
  * wants full chroma */
-if (isAnyRGB(srcFormat) && !(flags & SWS_FULL_CHR_H_INP)   &&
+if (isAnyRGB(srcFormat) && !(srcW & 1) && !(flags & SWS_FULL_CHR_H_INP) &&
 srcFormat != AV_PIX_FMT_RGB8 && srcFormat != AV_PIX_FMT_BGR8 &&
 srcFormat != AV_PIX_FMT_RGB4 && srcFormat != AV_PIX_FMT_BGR4 &&
 srcFormat != AV_PIX_FMT_RGB4_BYTE && srcFormat != AV_PIX_FMT_BGR4_BYTE 
&&
-- 
2.47.0

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

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

Re: [FFmpeg-devel] [PATCH] Use AVBufferPool in MOV

[Arnaud Masserann]

After some more testing suggested by compn:

- Checking the timestamps of the packets (both dts and pts) -> the
patch doesn't change them
- Checking mp4->mkv conversion: before/after produces the same binary
file, except for some padding bytes in the header
- Checking a MOV with many streams: tested with 48 streams. Behaviour
is ok, memory usage is almost the same (see previous mails), perf is
same or better (including images).

Tested for both per-stream and per-media.

I'll submit a v2 with James' suggestions.

On Mon, Nov 25, 2024 at 12:53 AM compn  wrote:
>
> On Sun, 24 Nov 2024 18:14:03 +0100
> Arnaud Masserann  wrote:
>
> > Good question. I just benchmarked all the .mov files in the samples repo.
> > On average, there is a 1.3x speedup. A few files are slower, but 75%
> > of the files have at least a 1.11x speedup, and 25% of the files have
> > at least 1.49x.
> >
> > Outliers include openquicktime/aletrek-tga-8bit.mov (0.8x, so slower),
> > and wmv3/Bluem.mov (10.4x).
> > Full data: 
> > https://etconlyview-my.sharepoint.com/:x:/g/personal/a_masserann_etc-onlyview_com/EXomK72G3LdJgoBHCgnYcBUBnxd0FAe90nrIkL4EFZKEuw?e=vj3TRl
> >
> > And FATE passes with valgrind, btw.
>
> thanks for testing. if the change doesnt break any old files, i have no
> issue with it slowing the speeds of demuxing on old weird files.
>
> more ancient mov samples if you feel like doing more testing.
> https://samples.ffmpeg.org/A-codecs/MACE/MAC6-mov/
> https://samples.ffmpeg.org/A-codecs/QDM2/
> https://samples.ffmpeg.org/A-codecs/QDMC/
> https://samples.ffmpeg.org/A-codecs/qclp/
> https://samples.ffmpeg.org/A-codecs/qtNONE/
> https://samples.ffmpeg.org/A-codecs/qtfl32/
> https://samples.ffmpeg.org/A-codecs/qtraw/
> https://samples.ffmpeg.org/A-codecs/suite/3G2/
> https://samples.ffmpeg.org/A-codecs/suite/3GP/
> https://samples.ffmpeg.org/A-codecs/uLaw/
> https://samples.ffmpeg.org/mobileVideo_3gp/
> https://samples.ffmpeg.org/archive/container/mov/
> https://samples.ffmpeg.org/V-codecs/SVQ1/
> https://samples.ffmpeg.org/V-codecs/SVQ3/
> https://samples.ffmpeg.org/V-codecs/QT-qdrw/Airplane.mov
> https://samples.ffmpeg.org/V-codecs/QTRLE/
> https://samples.ffmpeg.org/V-codecs/ZyGo/
> https://samples.ffmpeg.org/V-codecs/icod/
> https://samples.ffmpeg.org/V-codecs/pxlt-ApplePixlet/
> https://samples.ffmpeg.org/MPEG-4/
> https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4471/spot-day.mj2
>
> probably a good idea to test the rest of the mov formats like
> psp,m4b,ism,ismv,isma,f4v,avif,heic,heif which i didnt link.
>
> especially popular camera photo format heic/heif could do with some
> tests.
>
> full list of samples https://samples.ffmpeg.org/allsamples.txt
>
> note that mp4 files are the 2nd most popular format that i see on a
> daily basis , just behind mkv. with support by default in
> windows, mac/ios, android and web browsers, mov/mp4 is probably the #1
> popular format in the world currently. testing and speeding up our
> mov/mp4 demuxer is a good idea.
>
> 392092  mov.c
> ugh.
>
> thanks,
> -compn
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] infrastructure documentation

[Michael Niedermayer]

Hi

On Sat, Nov 30, 2024 at 11:08:29PM +0100, Michael Niedermayer wrote:
> On Sat, Nov 30, 2024 at 10:58:03PM +0100, martin schitter wrote:
> > 
> > 
> > On 30.11.24 21:41, Michael Niedermayer wrote:
> > > What name should the repository have ?
> > > ffmpeg-infra
> > > ffmpeg-private
> > > 
> > > (i dont like the sound of "private" for a open source project)
> > 
> 
> > ffmpeg-internals may sound nicer
> 
> ok, sounds good to me.
> ill wait a day or 2 before creating it, in case someone wants to
> suggest another one

repository created:
g...@git.ffmpeg.org:ffmpeg-internals

TC + root + people providing the infrastructure should have access.
(everyone listed needs to have access so they can update their entries or 
delete themselves)
(root needs to have access as root may need to contact someone)

other people should have no access, and yes its welcome if people test that
if you manage to access it without being supposed to,
the file contains instructions to report how you did that.

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

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

Re: [FFmpeg-devel] [RFC] infrastructure documentation

[Leo Izen]

On 12/2/24 1:44 PM, Michael Niedermayer wrote:

Hi

repository created:
g...@git.ffmpeg.org:ffmpeg-internals

TC + root + people providing the infrastructure should have access.
(everyone listed needs to have access so they can update their entries or 
delete themselves)
(root needs to have access as root may need to contact someone)

other people should have no access, and yes its welcome if people test that
if you manage to access it without being supposed to,
the file contains instructions to report how you did that.

thx



Just tested it, and I do not have access. I'm not on TC, so I shouldn't 
have access, so that's a good thing.


- Leo Izen (Traneptora)

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

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

Re: [FFmpeg-devel] [RFC] infrastructure documentation

[compn]

On Mon, 2 Dec 2024 19:44:43 +0100, Michael Niedermayer wrote:

> Hi
> 
> On Sat, Nov 30, 2024 at 11:08:29PM +0100, Michael Niedermayer wrote:
> > On Sat, Nov 30, 2024 at 10:58:03PM +0100, martin schitter wrote:  
> > > ffmpeg-internals may sound nicer  
> > 
> > ok, sounds good to me.
> > ill wait a day or 2 before creating it, in case someone wants to
> > suggest another one  
> 
> repository created:
> g...@git.ffmpeg.org:ffmpeg-internals

can you move doc/infra.txt there.
no reason to have it in trunk.
ffmpeg users dont care about our dns records.

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

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

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

[Chris Warrington via ffmpeg-devel]

When a stream has ALF filtering enabled but not CC-ALF, the CC-ALF set indexes 
alf->ctb_cc_idc are being read uninitialized during ALF filtering.

This change initializes alf->ctb_cc_idc whenever ALF is enabled.

Ref. https://trac.ffmpeg.org/ticket/11325

---
 libavcodec/vvc/ctu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
index a32abdeb62..c972dcc33e 100644
--- a/libavcodec/vvc/ctu.c
+++ b/libavcodec/vvc/ctu.c
@@ -2288,6 +2288,7 @@ static void alf_params(VVCLocalContext *lc, const int rx, 
const int ry)
 ALFParams *alf= &CTB(fc->tab.alf, rx, ry);

 alf->ctb_flag[LUMA] = alf->ctb_flag[CB] = alf->ctb_flag[CR] = 0;
+alf->ctb_cc_idc[0] = alf->ctb_cc_idc[1] = 0;
 if (sh->sh_alf_enabled_flag) {
 alf->ctb_flag[LUMA] = ff_vvc_alf_ctb_flag(lc, rx, ry, LUMA);
 if (alf->ctb_flag[LUMA]) {
@@ -2318,7 +2319,6 @@ static void alf_params(VVCLocalContext *lc, const int rx, 
const int ry)
 const uint8_t cc_enabled[] = { sh->sh_alf_cc_cb_enabled_flag, 
sh->sh_alf_cc_cr_enabled_flag };
 const uint8_t cc_aps_id[]  = { sh->sh_alf_cc_cb_aps_id, 
sh->sh_alf_cc_cr_aps_id };
 for (int i = 0; i < 2; i++) {
-alf->ctb_cc_idc[i] = 0;
 if (cc_enabled[i]) {
 const VVCALF *aps = fc->ps.alf_list[cc_aps_id[i]];
 alf->ctb_cc_idc[i] = ff_vvc_alf_ctb_cc_idc(lc, rx, ry, i, 
aps->num_cc_filters[i]);
--
2.43.0


This message and any attachment are confidential and may be privileged or 
otherwise protected from disclosure. If you are not the intended recipient, 
please notify the sender immediately and delete this message and any attachment 
from your system. Do not copy them or disclose the contents to any other person.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] swscale/graph: fix memleak of cascaded graphs

[James Almer]

On 12/2/2024 7:29 AM, Niklas Haas wrote:

From: Niklas Haas 

Just free them directly and discard the parent context.
---
  libswscale/graph.c | 12 +++-
  1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/libswscale/graph.c b/libswscale/graph.c
index ee9d9847a9..fbad1fe8c3 100644
--- a/libswscale/graph.c
+++ b/libswscale/graph.c
@@ -292,7 +292,7 @@ static void legacy_chr_pos(SwsGraph *graph, int *chr_pos, 
int override, int *war
  *chr_pos = override;
  }
  
-static int init_legacy_subpass(SwsGraph *graph, SwsContext *sws, int cascaded,

+static int init_legacy_subpass(SwsGraph *graph, SwsContext *sws,
 SwsPass *input, SwsPass **output)
  {
  SwsInternal *c = sws_internal(sws);
@@ -308,11 +308,14 @@ static int init_legacy_subpass(SwsGraph *graph, 
SwsContext *sws, int cascaded,
  for (int i = 0; i < num_cascaded; i++) {
  SwsContext *sub = c->cascaded_context[i];
  const int is_last = i + 1 == num_cascaded;
-ret = init_legacy_subpass(graph, sub, 1, input, is_last ? output : 
&input);
+ret = init_legacy_subpass(graph, sub, input, is_last ? output : 
&input);
  if (ret < 0)
  return ret;
+/* Steal cascaded context, so we can free the parent */
+c->cascaded_context[i] = NULL;
  }
  
+sws_free_context(&sws);

  return 0;
  }
  
@@ -336,8 +339,7 @@ static int init_legacy_subpass(SwsGraph *graph, SwsContext *sws, int cascaded,

  if (!pass)
  return AVERROR(ENOMEM);
  pass->setup = setup_legacy_swscale;
-if (!cascaded) /* parent context frees this automatically */
-pass->free = free_legacy_swscale;
+pass->free = free_legacy_swscale;
  
  /**

   * For slice threading, we need to create sub contexts, similar to how
@@ -452,7 +454,7 @@ static int add_legacy_sws_pass(SwsGraph *graph, SwsFormat 
src, SwsFormat dst,
  brightness, contrast, saturation);
  }
  
-ret = init_legacy_subpass(graph, sws, 0, input, output);

+ret = init_legacy_subpass(graph, sws, input, output);
  if (ret < 0) {
  sws_free_context(&sws);
  return ret;


Should be ok.



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

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

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

[Marton Balint]

On Sun, 1 Dec 2024, James Almer wrote:


On 11/28/2024 5:02 PM, Marton Balint wrote:



 On Wed, 27 Nov 2024, Marth64 wrote:


 As it stands today, ffprobe has two stream-level fields (closed_captions
 and film_grain)
 that do not work. Their value is always 0 because ffprobe cannot access
 the internal
 codec properties in the stream context when it is setting up its internal
 streams.

 Additionally, avformat/dump used to successfully print about the presence
 of
 Closed Captions (EIA-608/CEA-708) and the presence of film grain. This
 does
 not work either anymore, because avformat_find_stream_info() does not
 copy
 them in the skeleton context it uses after calling codec_close().

 To clarify: the aforementioned features/code are broken.

 So, to the user, Closed Caption detection as a feature is broken, and
 ffprobe
 and the dump is essentially having two fields that do not work.

 This patchset aims to fix the issue by:
 (1) Adding a video stream disposition, AV_DISPOSITION_CAPTIONS_EIA608
 that
    can be set in avformat_find_stream_info(), and using it to express
    the presence of Closed Captions (EIA-608/CEA-708)


 Manually mapping between different codec properties and stream
 dispositions seems ugly, and I am not sure if we should even use the
 disposition field for something like this.

 I suggest you try adding the "properties" attribute to AVCodecParameters,
 because as far as I see it is very similar to profile or level. Can you
 see if that works? If it does, we might even promote the FF_CODEC_PROPERTY
 flags to AV_CODEC_PROPERTY so they will become properly public.


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.




Okay, but if this is a frame property, we should not clobber neither 
AVStream nor AVCodecParameters with it.


Probably we need a more generic solution for the problem that some 
information is only available in the first read packet or in the first 
decoded frame.


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

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 0/3] Add WASM simd support

[Michael Niedermayer]

Hi

On Mon, Dec 02, 2024 at 09:12:06PM +0800, Zhao Zhili wrote:
> 
> > On Nov 27, 2024, at 20:35, Zhao Zhili  wrote:
> > 
> > Ping.
> 
> Ping again.

This is cool

thx

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

It is what and why we do it that matters, not just one of them.


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

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

Re: [FFmpeg-devel] [PATCH] swscale/utils: disable full_chr_h_input optimization for odd width

[Michael Niedermayer]

Hi Niklas

On Mon, Dec 02, 2024 at 01:14:09PM +0100, Niklas Haas wrote:
> From: Niklas Haas 
> 
> The basic problem here is that the rgb*ToUV_half_* functions hard-code a
> bilinear downsample from src[i] + src[i+1], with no bounds check on the i+1
> access.
> 
> Due to the signature of the function, we cannot easily plumb the "true" width
> into the function body to perform a bounds check. Similarly, we cannot easily
> pre-pad the input because it is typically reading from the original input
> frame, which would require a full memcpy to pad. Either of these solutions are
> more trouble than the feature is worth, so just disable it on odd input sizes.
> 
> Fixes: use of uninitialized value
> Fixes: ticket #11265
> Signed-off-by: Niklas Haas 
> Sponsored-by: Sovereign Tech Fund
> ---
>  libswscale/utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

The input generally should be padded, but teh padding may not have been
initialized or may contain things next to the frame being scaled.

The patch is probably ok

thx

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

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

Re: [FFmpeg-devel] [PATCH v4 1/8] checkasm/sw_range_convert: test negative input values

[Michael Niedermayer]

Hi Ramiro

On Sun, Dec 01, 2024 at 07:20:03PM +0100, Ramiro Polla wrote:
> ---
>  tests/checkasm/sw_range_convert.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/tests/checkasm/sw_range_convert.c 
> b/tests/checkasm/sw_range_convert.c
> index bf14209987..ba576ff08c 100644
> --- a/tests/checkasm/sw_range_convert.c
> +++ b/tests/checkasm/sw_range_convert.c
> @@ -65,6 +65,8 @@ static void check_lumConvertRange(int from)
>  
>  LOCAL_ALIGNED_32(int16_t, dst0, [LARGEST_INPUT_SIZE * 2]);
>  LOCAL_ALIGNED_32(int16_t, dst1, [LARGEST_INPUT_SIZE * 2]);
> +int32_t *dst0_32 = (int32_t *) dst0;
> +int32_t *dst1_32 = (int32_t *) dst1;
>  
>  declare_func(void, int16_t *dst, int width);
>  
> @@ -89,6 +91,11 @@ static void check_lumConvertRange(int from)
>  int width = input_sizes[dstWi];
>  if (check_func(c->lumConvertRange, "%s%d_%d", func_str, 
> bit_depth, width)) {
>  randomize_buffers(dst0, dst1, bit_depth, width);
> +if (bit_depth == 16) {
> +dst1_32[2] = dst0_32[2] = -1;
> +} else {
> +dst1[2] = dst0[2] = -1;
> +}
>  call_ref(dst0, width);
>  call_new(dst1, width);
>  if (memcmp(dst0, dst1, width * sample_size))
> @@ -115,6 +122,8 @@ static void check_chrConvertRange(int from)
>  LOCAL_ALIGNED_32(int16_t, dstV0, [LARGEST_INPUT_SIZE * 2]);
>  LOCAL_ALIGNED_32(int16_t, dstU1, [LARGEST_INPUT_SIZE * 2]);
>  LOCAL_ALIGNED_32(int16_t, dstV1, [LARGEST_INPUT_SIZE * 2]);
> +int32_t *dstU0_32 = (int32_t *) dstU0;
> +int32_t *dstU1_32 = (int32_t *) dstU1;
>  
>  declare_func(void, int16_t *dstU, int16_t *dstV, int width);
>  
> @@ -140,6 +149,11 @@ static void check_chrConvertRange(int from)
>  if (check_func(c->chrConvertRange, "%s%d_%d", func_str, 
> bit_depth, width)) {
>  randomize_buffers(dstU0, dstU1, bit_depth, width);
>  randomize_buffers(dstV0, dstV1, bit_depth, width);
> +if (bit_depth == 16) {
> +dstU1_32[2] = dstU0_32[2] = -1;
> +} else {
> +dstU1[2] = dstU0[2] = -1;
> +}
>  call_ref(dstU0, dstV0, width);
>  call_new(dstU1, dstV1, width);
>  if (memcmp(dstU0, dstU1, width * sample_size) ||

should be ok

thx

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

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

Re: [FFmpeg-devel] [PATCH v4 2/8] swscale/range_convert: saturate output instead of limiting input

[Michael Niedermayer]

On Sun, Dec 01, 2024 at 07:20:04PM +0100, Ramiro Polla wrote:
> For bit depths <= 14, the result is saturated to 15 bits.
> For bit depths > 14, the result is saturated to 19 bits.
> 
> x86_64:
> chrRangeFromJpeg8_1920_c:2126.5   2127.4  (1.00x)
> chrRangeFromJpeg16_1920_c:   2331.4   2325.2  (1.00x)
> chrRangeToJpeg8_1920_c:  3163.0   3166.9  (1.00x)
> chrRangeToJpeg16_1920_c: 3163.7   2152.4  (1.47x)
> lumRangeFromJpeg8_1920_c:1262.2   1263.0  (1.00x)
> lumRangeFromJpeg16_1920_c:   1079.5   1080.5  (1.00x)
> lumRangeToJpeg8_1920_c:  1860.5   1886.8  (0.99x)
> lumRangeToJpeg16_1920_c: 1910.2   1077.0  (1.77x)
> 
> aarch64 A55:
> chrRangeFromJpeg8_1920_c:   28836.2  28835.2  (1.00x)
> chrRangeFromJpeg16_1920_c:  28840.1  28839.8  (1.00x)
> chrRangeToJpeg8_1920_c: 44196.2  23074.7  (1.92x)
> chrRangeToJpeg16_1920_c:36527.3  17318.9  (2.11x)
> lumRangeFromJpeg8_1920_c:   15388.5  15389.7  (1.00x)
> lumRangeFromJpeg16_1920_c:  15389.3  15388.2  (1.00x)
> lumRangeToJpeg8_1920_c: 23069.7  19227.8  (1.20x)
> lumRangeToJpeg16_1920_c:19227.8  15387.0  (1.25x)
> 
> aarch64 A76:
> chrRangeFromJpeg8_1920_c:6334.7   6324.4  (1.00x)
> chrRangeFromJpeg16_1920_c:   6336.0   6339.9  (1.00x)
> chrRangeToJpeg8_1920_c: 11474.5   9656.0  (1.19x)
> chrRangeToJpeg16_1920_c: 9640.5   6340.4  (1.52x)
> lumRangeFromJpeg8_1920_c:4453.2   4422.0  (1.01x)
> lumRangeFromJpeg16_1920_c:   4414.2   4420.9  (1.00x)
> lumRangeToJpeg8_1920_c:  6645.0   5949.1  (1.12x)
> lumRangeToJpeg16_1920_c: 6005.2   4446.8  (1.35x)
> 
> NOTE: all simd optimizations for range_convert have been disabled
>   except for x86, which already had the same behaviour.
>   they will be re-enabled when they are fixed for each architecture.
> ---
>  libswscale/aarch64/swscale.c  |  5 +
>  libswscale/loongarch/swscale_init_loongarch.c |  5 +
>  libswscale/riscv/swscale.c|  5 +
>  libswscale/swscale.c  | 21 ---
>  libswscale/x86/range_convert.asm  |  3 ---
>  5 files changed, 29 insertions(+), 10 deletions(-)

should be ok

thx

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

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

Re: [FFmpeg-devel] [PATCH] lavc/libx265: flag as experimental

[Kirithika Kalirathnam]

Hi Vittorio,

The commits in this PR
 were picked
and pushed to the master branch of x265.(b647da9

,b153007

,114af15

).

*Thanks,*
*Kirithika*


On Thu, Nov 28, 2024 at 10:36 PM Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

> On Thu, Nov 28, 2024 at 3:22 AM Kirithika Kalirathnam <
> kirith...@multicorewareinc.com> wrote:
>
> > Hi All,
> >
> > x265 v4.1 
> is
> > released with the fixes addressing memory leak and other reported
> > issues.Please check it out.
> >
> > *Thanks,*
> > *Kirithika*
> >
>
> Hi Kirithika,
> would you be able to also merge this one
> https://bitbucket.org/multicoreware/x265_git/pull-requests/25 ?
> It's triggering security alarms in the company internal checks - I've
> already updated the PR once as requested, but there are new conflicts now.
> Any chance you could help?
> Thank you
> --
> 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".
>
___
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

[Nuo Mi]

Hi Chris and Frank,
Thank you for the patch and review.

On Mon, Dec 2, 2024 at 10:27 PM Chris Warrington via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> When a stream has ALF filtering enabled but not CC-ALF, the CC-ALF set
> indexes alf->ctb_cc_idc are being read uninitialized during ALF filtering.
>
> This change initializes alf->ctb_cc_idc whenever ALF is enabled.
>
> Ref. https://trac.ffmpeg.org/ticket/11325
>
> ---
>  libavcodec/vvc/ctu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
> index a32abdeb62..c972dcc33e 100644
> --- a/libavcodec/vvc/ctu.c
> +++ b/libavcodec/vvc/ctu.c
> @@ -2288,6 +2288,7 @@ static void alf_params(VVCLocalContext *lc, const
> int rx, const int ry)
>  ALFParams *alf= &CTB(fc->tab.alf, rx, ry);
>
>  alf->ctb_flag[LUMA] = alf->ctb_flag[CB] = alf->ctb_flag[CR] = 0;
> +alf->ctb_cc_idc[0] = alf->ctb_cc_idc[1] = 0;
>
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?

>  if (sh->sh_alf_enabled_flag) {
>  alf->ctb_flag[LUMA] = ff_vvc_alf_ctb_flag(lc, rx, ry, LUMA);
>  if (alf->ctb_flag[LUMA]) {
> @@ -2318,7 +2319,6 @@ static void alf_params(VVCLocalContext *lc, const
> int rx, const int ry)
>  const uint8_t cc_enabled[] = { sh->sh_alf_cc_cb_enabled_flag,
> sh->sh_alf_cc_cr_enabled_flag };
>  const uint8_t cc_aps_id[]  = { sh->sh_alf_cc_cb_aps_id,
> sh->sh_alf_cc_cr_aps_id };
>  for (int i = 0; i < 2; i++) {
> -alf->ctb_cc_idc[i] = 0;
>  if (cc_enabled[i]) {
>  const VVCALF *aps = fc->ps.alf_list[cc_aps_id[i]];
>  alf->ctb_cc_idc[i] = ff_vvc_alf_ctb_cc_idc(lc, rx, ry, i,
> aps->num_cc_filters[i]);
> --
> 2.43.0
>
>
> This message and any attachment are confidential and may be privileged or
> otherwise protected from disclosure. If you are not the intended recipient,
> please notify the sender immediately and delete this message and any
> attachment from your system. Do not copy them or disclose the contents to
> any other person.
> ___
> 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

[Michael Niedermayer]

Hi

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  |  10 +-
>  .../ref/fate/filter-pixfmts-tinterlace_cvlpf  |   8 +-
>  .../ref/fate/filter-pixfmts-tinterlace_merge  |   8 +-
>  tests/ref/fate/filter-pixfmts-tinterlace_pad  |   8 +-
>  tests/ref/fate/filter-pixfmts-tinterlace_