Re: [FFmpeg-devel] [RFC] STF 2025

[Marton Balint]

On Tue, 4 Jun 2024, Vittorio Giovara wrote:


If you stop responding with mails on all FFmpeg mailing lists from now to
indefinite time in future nothing of value would be lost.



Please reread what you wrote and appreciate the irony of the situation.

Needless to say, this is also going straight to CC :)
Please just do better, I believe in you!


I find this last sentence quite condescending, something you would tell 
your kid.


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 2/5] swscale/aarch64: Add rgb24 to yuv implementation

[Rémi Denis-Courmont]

Le 5 juin 2024 09:53:45 GMT+03:00, Zhao Zhili  a écrit :
>
>
>> On Jun 5, 2024, at 14:29, Rémi Denis-Courmont  wrote:
>> 
>> 
>> 
>> Le 4 juin 2024 16:55:01 GMT+03:00, Zhao Zhili > > a écrit :
>>> From: Zhao Zhili 
>>> 
>>> Test on Apple M1:
>>> 
>>> rgb24_to_uv_1080_c: 7.2
>>> rgb24_to_uv_1080_neon: 5.5
>>> rgb24_to_uv_1280_c: 8.2
>>> rgb24_to_uv_1280_neon: 6.2
>>> rgb24_to_uv_1920_c: 12.5
>>> rgb24_to_uv_1920_neon: 9.5
>>> 
>>> rgb24_to_uv_half_540_c: 6.5
>>> rgb24_to_uv_half_540_neon: 3.0
>>> rgb24_to_uv_half_640_c: 7.5
>>> rgb24_to_uv_half_640_neon: 3.2
>>> rgb24_to_uv_half_960_c: 12.5
>>> rgb24_to_uv_half_960_neon: 6.0
>>> 
>>> rgb24_to_y_1080_c: 4.5
>>> rgb24_to_y_1080_neon: 3.5
>>> rgb24_to_y_1280_c: 5.2
>>> rgb24_to_y_1280_neon: 4.2
>>> rgb24_to_y_1920_c: 8.0
>>> rgb24_to_y_1920_neon: 6.0
>>> 
>>> Signed-off-by: Zhao Zhili 
>>> ---
>>> libswscale/aarch64/Makefile  |   1 +
>>> libswscale/aarch64/input.S   | 229 +++
>>> libswscale/aarch64/swscale.c |  25 
>>> 3 files changed, 255 insertions(+)
>>> create mode 100644 libswscale/aarch64/input.S
>>> 
>>> diff --git a/libswscale/aarch64/Makefile b/libswscale/aarch64/Makefile
>>> index da1d909561..adfd90a1b6 100644
>>> --- a/libswscale/aarch64/Makefile
>>> +++ b/libswscale/aarch64/Makefile
>>> @@ -3,6 +3,7 @@ OBJS+= aarch64/rgb2rgb.o\
>>>   aarch64/swscale_unscaled.o   \
>>> 
>>> NEON-OBJS   += aarch64/hscale.o \
>>> +   aarch64/input.o  \
>>>   aarch64/output.o \
>>>   aarch64/rgb2rgb_neon.o   \
>>>   aarch64/yuv2rgb_neon.o   \
>>> diff --git a/libswscale/aarch64/input.S b/libswscale/aarch64/input.S
>>> new file mode 100644
>>> index 00..ee0d223c6e
>>> --- /dev/null
>>> +++ b/libswscale/aarch64/input.S
>>> @@ -0,0 +1,229 @@
>>> +/*
>>> + * Copyright (c) 2024 Zhao Zhili 
>>> + *
>>> + * 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 "libavutil/aarch64/asm.S"
>>> +
>>> +.macro rgb24_to_yuv_load_rgb, src
>>> +ld3 { v16.16b, v17.16b, v18.16b }, [\src]
>>> +ushll   v19.8h, v16.8b, #0 // v19: r
>>> +ushll   v20.8h, v17.8b, #0 // v20: g
>>> +ushll   v21.8h, v18.8b, #0 // v21: b
>>> +ushll2  v22.8h, v16.16b, #0// v22: r
>>> +ushll2  v23.8h, v17.16b, #0// v23: g
>>> +ushll2  v24.8h, v18.16b, #0// v24: b
>>> +.endm
>>> +
>>> +.macro rgb24_to_yuv_product, r, g, b, dst1, dst2, dst, coef0, coef1, 
>>> coef2, right_shift
>>> +mov \dst1\().16b, v6.16b// dst1 = 
>>> const_offset
>>> +mov \dst2\().16b, v6.16b// dst2 = 
>>> const_offset
>>> +smlal   \dst1\().4s, \coef0\().4h, \r\().4h // dst1 += 
>>> rx * r
>>> +smlal2  \dst2\().4s, \coef0\().8h, \r\().8h // dst2 += 
>>> rx * r
>>> +smlal   \dst1\().4s, \coef1\().4h, \g\().4h // dst1 += 
>>> gx * g
>>> +smlal2  \dst2\().4s, \coef1\().8h, \g\().8h // dst2 += 
>>> gx * g
>>> +smlal   \dst1\().4s, \coef2\().4h, \b\().4h // dst1 += 
>>> bx * b
>>> +smlal2  \dst2\().4s, \coef2\().8h, \b\().8h // dst2 += 
>>> bx * b
>>> +sqshrn  \dst\().4h, \dst1\().4s, \right_shift   // 
>>> dst_lower_half = dst1 >> right_shift
>>> +sqshrn2 \dst\().8h, \dst2\().4s, \right_shift   // 
>>> dst_higher_half = dst2 >> right_shift
>>> +.endm
>>> +
>>> +function ff_rgb24ToY_neon, export=1
>>> +cmp w4, #0  // check width > 0
>>> +b.le4f
>>> +
>>> +ldp w10, w11, [x5], #8   // w10: ry, w11: gy
>> 
>> I don't think it affects anything on your OoO execution hardware, but you're 
>> using the result of this load right off the bat in the next instruction. 
>> Ditto below. This may hurt perfs on not-so-fancy CPUs.
>
>Will do.
>
>> 
>>> +dup v0.8h, w10
>

Re: [FFmpeg-devel] [PATCH 2/5] swscale/aarch64: Add rgb24 to yuv implementation

[Martin Storsjö]

On Wed, 5 Jun 2024, Zhao Zhili wrote:


On Jun 5, 2024, at 14:29, Rémi Denis-Courmont  wrote:

Le 4 juin 2024 16:55:01 GMT+03:00, Zhao Zhili mailto:quinkbl...@foxmail.com>> a écrit :

From: Zhao Zhili 

Test on Apple M1:

rgb24_to_uv_1080_c: 7.2
rgb24_to_uv_1080_neon: 5.5
rgb24_to_uv_1280_c: 8.2
rgb24_to_uv_1280_neon: 6.2
rgb24_to_uv_1920_c: 12.5
rgb24_to_uv_1920_neon: 9.5

rgb24_to_uv_half_540_c: 6.5
rgb24_to_uv_half_540_neon: 3.0
rgb24_to_uv_half_640_c: 7.5
rgb24_to_uv_half_640_neon: 3.2
rgb24_to_uv_half_960_c: 12.5
rgb24_to_uv_half_960_neon: 6.0

rgb24_to_y_1080_c: 4.5
rgb24_to_y_1080_neon: 3.5
rgb24_to_y_1280_c: 5.2
rgb24_to_y_1280_neon: 4.2
rgb24_to_y_1920_c: 8.0
rgb24_to_y_1920_neon: 6.0

Signed-off-by: Zhao Zhili 
---
libswscale/aarch64/Makefile  |   1 +
libswscale/aarch64/input.S   | 229 +++
libswscale/aarch64/swscale.c |  25 
3 files changed, 255 insertions(+)
create mode 100644 libswscale/aarch64/input.S

diff --git a/libswscale/aarch64/Makefile b/libswscale/aarch64/Makefile
index da1d909561..adfd90a1b6 100644
--- a/libswscale/aarch64/Makefile
+++ b/libswscale/aarch64/Makefile
@@ -3,6 +3,7 @@ OBJS+= aarch64/rgb2rgb.o\
  aarch64/swscale_unscaled.o   \

NEON-OBJS   += aarch64/hscale.o \
+   aarch64/input.o  \
  aarch64/output.o \
  aarch64/rgb2rgb_neon.o   \
  aarch64/yuv2rgb_neon.o   \
diff --git a/libswscale/aarch64/input.S b/libswscale/aarch64/input.S
new file mode 100644
index 00..ee0d223c6e
--- /dev/null
+++ b/libswscale/aarch64/input.S
@@ -0,0 +1,229 @@
+/*
+ * Copyright (c) 2024 Zhao Zhili 
+ *
+ * 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 "libavutil/aarch64/asm.S"
+
+.macro rgb24_to_yuv_load_rgb, src
+ld3 { v16.16b, v17.16b, v18.16b }, [\src]
+ushll   v19.8h, v16.8b, #0 // v19: r
+ushll   v20.8h, v17.8b, #0 // v20: g
+ushll   v21.8h, v18.8b, #0 // v21: b
+ushll2  v22.8h, v16.16b, #0// v22: r
+ushll2  v23.8h, v17.16b, #0// v23: g
+ushll2  v24.8h, v18.16b, #0// v24: b
+.endm
+
+.macro rgb24_to_yuv_product, r, g, b, dst1, dst2, dst, coef0, coef1, coef2, 
right_shift
+mov \dst1\().16b, v6.16b// dst1 = 
const_offset
+mov \dst2\().16b, v6.16b// dst2 = 
const_offset
+smlal   \dst1\().4s, \coef0\().4h, \r\().4h // dst1 += rx 
* r
+smlal2  \dst2\().4s, \coef0\().8h, \r\().8h // dst2 += rx 
* r
+smlal   \dst1\().4s, \coef1\().4h, \g\().4h // dst1 += gx 
* g
+smlal2  \dst2\().4s, \coef1\().8h, \g\().8h // dst2 += gx 
* g
+smlal   \dst1\().4s, \coef2\().4h, \b\().4h // dst1 += bx 
* b
+smlal2  \dst2\().4s, \coef2\().8h, \b\().8h // dst2 += bx 
* b
+sqshrn  \dst\().4h, \dst1\().4s, \right_shift   // dst_lower_half = 
dst1 >> right_shift
+sqshrn2 \dst\().8h, \dst2\().4s, \right_shift   // dst_higher_half = 
dst2 >> right_shift
+.endm
+
+function ff_rgb24ToY_neon, export=1
+cmp w4, #0  // check width > 0
+b.le4f
+
+ldp w10, w11, [x5], #8   // w10: ry, w11: gy


I don't think it affects anything on your OoO execution hardware, but you're 
using the result of this load right off the bat in the next instruction. Ditto 
below. This may hurt perfs on not-so-fancy CPUs.


Will do.




+dup v0.8h, w10
+dup v1.8h, w11
+ldr w12, [x5]   // w12: by
+dup v2.8h, w12
+
+mov w9, #256// w9 = 1 << (RGB2YUV_SHIFT - 
7)
+movkw9, #8, lsl #16 // w9 += 32 << (RGB2YUV_SHIFT 
- 1)
+dup v6.4s, w9   // w9: const_offset
+
+mov x2, #0  // w2: i
+and w3, w4, #0xFFF0 // w3 = width / 16 * 16
+

Re: [FFmpeg-devel] New CC member: Steven Liu

[Marton Balint]

On Tue, 4 Jun 2024, Ronald S. Bultje wrote:


Hi all,

Anton resigned from the CC [1], leaving an empty spot. The remaining
members of the CC agreed it would be best to fill the spot with the next
runner-up from the last CC Elections.
The last CC election results [2] had
Steven Liu as next runner-up, so we've asked him to fill Anton's spot for
the remainder of our term, and he accepted. Thanks & welcome, Steven!


I don't have a problem with this in practice, but the legitimacy of such 
an appointment is not rock solid. The CC itself probably should not decide 
on CC membership, as that comes from the GA.


Maybe we should always choose a spare member (as in the 6th winner), who 
can automatically jump in. And if more than 1 person resign, a new 
election can be held.


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] New CC member: Steven Liu

[Anton Khirnov]

Quoting Ronald S. Bultje (2024-06-05 01:32:12)
> Steven Liu as next runner-up

We are using a proportional system, which does not work this way.

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

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

Re: [FFmpeg-devel] [RFC] STF 2025

[Vittorio Giovara]

On Wed, Jun 5, 2024 at 9:21 AM Marton Balint  wrote:

>
>
> On Tue, 4 Jun 2024, Vittorio Giovara wrote:
>
> >> If you stop responding with mails on all FFmpeg mailing lists from now
> to
> >> indefinite time in future nothing of value would be lost.
> >>
> >
> > Please reread what you wrote and appreciate the irony of the situation.
> >
> > Needless to say, this is also going straight to CC :)
> > Please just do better, I believe in you!
>
> I find this last sentence quite condescending, something you would tell
> your kid.
>

This happens when people are behaving like children, and that happens when
there are no rules or repercussions to bad behavior.

I am kind of stumped how throughout all this exchange, in which I'm subject
to abuse from Paul over multiple emails, my condescending tone is what
struck you, instead of the insults and trolling I received from Paul. Maybe
if more people spoke up against this unhealthy environment and stood up
with the victim instead of the aggressor there would be a better community
all around.

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

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

Re: [FFmpeg-devel] [PATCH v6 3/4] all: Link to "context" from all public contexts with documentation

[Anton Khirnov]

Quoting Andrew Sayers (2024-06-04 16:47:23)
> The goal of putting these links in "@see" blocks is to provide hooks
> for future developers to add links to other useful parts of the codebase.
> ---
>  libavcodec/avcodec.h | 3 +++
>  libavcodec/bsf.h | 3 +++
>  libavcodec/d3d11va.h | 3 +++
>  libavcodec/mediacodec.h  | 2 ++
>  libavcodec/qsv.h | 3 +++
>  libavcodec/vdpau.h   | 3 +++
>  libavcodec/videotoolbox.h| 3 +++
>  libavfilter/avfilter.h   | 7 ++-
>  libavformat/avformat.h   | 3 +++
>  libavformat/avio.h   | 3 +++
>  libavutil/audio_fifo.h   | 3 +++
>  libavutil/hwcontext.h| 6 ++
>  libavutil/hwcontext_cuda.h   | 3 +++
>  libavutil/hwcontext_d3d11va.h| 6 ++
>  libavutil/hwcontext_d3d12va.h| 6 ++
>  libavutil/hwcontext_drm.h| 3 +++
>  libavutil/hwcontext_dxva2.h  | 6 ++
>  libavutil/hwcontext_mediacodec.h | 3 +++
>  libavutil/hwcontext_opencl.h | 6 ++
>  libavutil/hwcontext_qsv.h| 6 ++
>  libavutil/hwcontext_vaapi.h  | 6 ++
>  libavutil/hwcontext_vdpau.h  | 3 +++
>  libavutil/hwcontext_vulkan.h | 6 ++
>  libavutil/lfg.h  | 3 +++
>  24 files changed, 98 insertions(+), 1 deletion(-)

IMO this is pointless churn.

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

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

Re: [FFmpeg-devel] [PATCH v6 1/4] doc: Explain what "context" means

[Anton Khirnov]

Quoting Andrew Sayers (2024-06-04 16:47:21)
> Derived from explanations kindly provided by Stefano Sabatini and others:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325903.html
> ---
>  doc/context.md | 430 +
>  1 file changed, 430 insertions(+)
>  create mode 100644 doc/context.md

430 lines to say "context is a struct storing an object's state"?

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

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

Re: [FFmpeg-devel] [PATCH 2/5] swscale/aarch64: Add rgb24 to yuv implementation

[Martin Storsjö]

On Tue, 4 Jun 2024, Zhao Zhili wrote:


From: Zhao Zhili 

Test on Apple M1:

rgb24_to_uv_1080_c: 7.2
rgb24_to_uv_1080_neon: 5.5
rgb24_to_uv_1280_c: 8.2
rgb24_to_uv_1280_neon: 6.2
rgb24_to_uv_1920_c: 12.5
rgb24_to_uv_1920_neon: 9.5

rgb24_to_uv_half_540_c: 6.5
rgb24_to_uv_half_540_neon: 3.0
rgb24_to_uv_half_640_c: 7.5
rgb24_to_uv_half_640_neon: 3.2
rgb24_to_uv_half_960_c: 12.5
rgb24_to_uv_half_960_neon: 6.0

rgb24_to_y_1080_c: 4.5
rgb24_to_y_1080_neon: 3.5
rgb24_to_y_1280_c: 5.2
rgb24_to_y_1280_neon: 4.2
rgb24_to_y_1920_c: 8.0
rgb24_to_y_1920_neon: 6.0

Signed-off-by: Zhao Zhili 
---
libswscale/aarch64/Makefile  |   1 +
libswscale/aarch64/input.S   | 229 +++
libswscale/aarch64/swscale.c |  25 
3 files changed, 255 insertions(+)
create mode 100644 libswscale/aarch64/input.S

diff --git a/libswscale/aarch64/Makefile b/libswscale/aarch64/Makefile
index da1d909561..adfd90a1b6 100644
--- a/libswscale/aarch64/Makefile
+++ b/libswscale/aarch64/Makefile
@@ -3,6 +3,7 @@ OBJS+= aarch64/rgb2rgb.o\
   aarch64/swscale_unscaled.o   \

NEON-OBJS   += aarch64/hscale.o \
+   aarch64/input.o  \
   aarch64/output.o \
   aarch64/rgb2rgb_neon.o   \
   aarch64/yuv2rgb_neon.o   \
diff --git a/libswscale/aarch64/input.S b/libswscale/aarch64/input.S
new file mode 100644
index 00..ee0d223c6e
--- /dev/null
+++ b/libswscale/aarch64/input.S
@@ -0,0 +1,229 @@
+/*
+ * Copyright (c) 2024 Zhao Zhili 
+ *
+ * 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 "libavutil/aarch64/asm.S"
+
+.macro rgb24_to_yuv_load_rgb, src
+ld3 { v16.16b, v17.16b, v18.16b }, [\src]
+ushll   v19.8h, v16.8b, #0 // v19: r
+ushll   v20.8h, v17.8b, #0 // v20: g
+ushll   v21.8h, v18.8b, #0 // v21: b
+ushll2  v22.8h, v16.16b, #0// v22: r
+ushll2  v23.8h, v17.16b, #0// v23: g
+ushll2  v24.8h, v18.16b, #0// v24: b


Doing "ushll #0" is perhaps a bit unusual, the common thing would be 
"uxtl" instead. It doesn't matter in practice though, it assembles to the 
same instruction anyway.



+.endm
+
+.macro rgb24_to_yuv_product, r, g, b, dst1, dst2, dst, coef0, coef1, coef2, 
right_shift
+mov \dst1\().16b, v6.16b// dst1 = 
const_offset
+mov \dst2\().16b, v6.16b// dst2 = 
const_offset
+smlal   \dst1\().4s, \coef0\().4h, \r\().4h // dst1 += rx 
* r
+smlal2  \dst2\().4s, \coef0\().8h, \r\().8h // dst2 += rx 
* r
+smlal   \dst1\().4s, \coef1\().4h, \g\().4h // dst1 += gx 
* g
+smlal2  \dst2\().4s, \coef1\().8h, \g\().8h // dst2 += gx 
* g
+smlal   \dst1\().4s, \coef2\().4h, \b\().4h // dst1 += bx 
* b
+smlal2  \dst2\().4s, \coef2\().8h, \b\().8h // dst2 += bx 
* b


For sequences like this, the Cortex A53 (and iirc at least the A55 too) 
has got a fastpath; if you do multiple consequent smlal/smlsl (or regular 
mla/mls) into the same register, you actually save a lot of time. E.g. 
instead of this:


smlal dst1
smlal dst2
smlal dst1
smlal dst2
smlal dst1
smlal dst2

Do this:

smlal dst1
smlal dst1
smlal dst1
smlal dst2
smlal dst2
smlal dst2

For in-order cores (with this special fastpath - it is indeed a bit 
non-obvious) this makes a huge difference, and for out of order cores, 
they can reorder it as they prefer anyway (as this is not a very long 
instruction sequence).


This makes a massive difference for the in-order cores.

Before:  Cortex A53  A72  A73
rgb24_to_y_1920_neon:6032.7   3385.7   2514.0
After:
rgb24_to_y_1920_neon:5072.7   3388.2   2522.0

A 19% speedup on A53 with just with this one change, and it makes almost 
no difference for the other cores (mostly within measurement noise).



+function ff_rgb24ToY_neon, export=1
+cmp w4, #0  // check width > 0
+b.le

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_demux: gracefully ignore mismatching channel layouts for -channel_layout option

[Anton Khirnov]

Quoting Marton Balint (2024-06-03 23:48:47)
> The very old behaviour of -channel_layout was to simply warn the user about
> channel layouts which does not have a matching channel count, and ignore them,
> instead of reporting an error.
> 
> The recent fix re-added support for overriding -channel_layout, but it 
> rejected
> mismatching layouts. There is no easy way for the user to specify a channel
> layout only for streams with matching number of channels, so this patch
> restores the very old behaviour of ignoring mismatching layouts. See the
> discussion in ticket #11016.

I'm ambivalent about this. On one hand it probably doesn't hurt, for now
at least, on the other it seems quite ad-hoc. Previously it worked this
way mostly by accident, whereas if we now restore this behaviour
deliberately we'll be committing to supporting it for the foreseeable
future.

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

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

[FFmpeg-devel] [PATCH] lavc/vvc: Prevent overflow in chroma QP derivation

[Frank Plowman]

On the top of p. 112 in VVC (09/2023):

It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/ps.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 1b23675c98..b024caf460 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -101,9 +101,14 @@ static int sps_chroma_qp_table(VVCSPS *sps)
 
 qp_out[0] = qp_in[0] = r->sps_qp_table_start_minus26[i] + 26;
 for (int j = 0; j < num_points_in_qp_table; j++ ) {
+const uint8_t delta_qp_out = (r->sps_delta_qp_in_val_minus1[i][j] 
^ r->sps_delta_qp_diff_val[i][j]);
 delta_qp_in[j] = r->sps_delta_qp_in_val_minus1[i][j] + 1;
+if (qp_in[j] + delta_qp_in[j] > 63)
+return AVERROR_INVALIDDATA;
 qp_in[j+1] = qp_in[j] + delta_qp_in[j];
-qp_out[j+1] = qp_out[j] + (r->sps_delta_qp_in_val_minus1[i][j] ^ 
r->sps_delta_qp_diff_val[i][j]);
+if (qp_out[j] + delta_qp_out > 63)
+return AVERROR_INVALIDDATA;
+qp_out[j+1] = qp_out[j] + delta_qp_out;
 }
 sps->chroma_qp_table[i][qp_in[0] + off] = qp_out[0];
 for (int k = qp_in[0] - 1 + off; k >= 0; k--)
-- 
2.45.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] [RFC] STF 2025

[Rémi Denis-Courmont]

Le 5 juin 2024 10:20:47 GMT+03:00, Marton Balint  a écrit :
>
>
>On Tue, 4 Jun 2024, Vittorio Giovara wrote:
>
>>> If you stop responding with mails on all FFmpeg mailing lists from now to
>>> indefinite time in future nothing of value would be lost.
>>> 
>> 
>> Please reread what you wrote and appreciate the irony of the situation.
>> 
>> Needless to say, this is also going straight to CC :)
>> Please just do better, I believe in you!
>
>I find this last sentence quite condescending, something you would tell your 
>kid.

I understand your viewpoint though I don't necessarily agree with it.

But by reacting *only* to Vittorio trying to defend himself and explicitly (and 
ineffectively) asking for help from the CC, you look like you are attacking the 
victim and defending the troll.

Paul does *not* get a free pass to do whatever he wants even if he has been one 
of the most prolific contributors to this project.
___
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] New CC member: Steven Liu

[Thilo Borgmann via ffmpeg-devel]

Hi,

On 05.06.24 09:34, Marton Balint wrote:



On Tue, 4 Jun 2024, Ronald S. Bultje wrote:


Hi all,

Anton resigned from the CC [1], leaving an empty spot. The remaining
members of the CC agreed it would be best to fill the spot with the next
runner-up from the last CC Elections.
The last CC election results [2] had
Steven Liu as next runner-up, so we've asked him to fill Anton's spot for
the remainder of our term, and he accepted. Thanks & welcome, Steven!


I don't have a problem with this in practice, but the legitimacy of such 
an appointment is not rock solid. The CC itself probably should not 
decide on CC membership, as that comes from the GA.


Agreed. Though we see this the first time and the discussion some time 
ago did not raise much participation / interest.



Maybe we should always choose a spare member (as in the 6th winner), who 
can automatically jump in. And if more than 1 person resign, a new 
election can be held.


Sounds as a good possibility to me. We should determine our procedure of 
choice and put it into the docs.


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

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

[FFmpeg-devel] [PATCH v2 1/2] lavc/vvc: Use sps_chroma_qp_table return code

[Frank Plowman]

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

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 1b23675c98..bfc3c121fd 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -186,8 +186,11 @@ static int sps_derive(VVCSPS *sps, void *log_ctx)
 sps_inter(sps);
 sps_partition_constraints(sps);
 sps_ladf(sps);
-if (r->sps_chroma_format_idc != 0)
-sps_chroma_qp_table(sps);
+if (r->sps_chroma_format_idc != 0) {
+ret = sps_chroma_qp_table(sps);
+if (ret < 0)
+return ret;
+}
 
 return 0;
 }
-- 
2.45.1

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

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

[FFmpeg-devel] [PATCH v2 2/2] lavc/vvc: Prevent overflow in chroma QP derivation

[Frank Plowman]

On the top of p. 112 in VVC (09/2023):

It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/ps.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index bfc3c121fd..c4f64d5da7 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -101,9 +101,14 @@ static int sps_chroma_qp_table(VVCSPS *sps)
 
 qp_out[0] = qp_in[0] = r->sps_qp_table_start_minus26[i] + 26;
 for (int j = 0; j < num_points_in_qp_table; j++ ) {
+const uint8_t delta_qp_out = (r->sps_delta_qp_in_val_minus1[i][j] 
^ r->sps_delta_qp_diff_val[i][j]);
 delta_qp_in[j] = r->sps_delta_qp_in_val_minus1[i][j] + 1;
+if (qp_in[j] + delta_qp_in[j] > 63)
+return AVERROR(EINVAL);
 qp_in[j+1] = qp_in[j] + delta_qp_in[j];
-qp_out[j+1] = qp_out[j] + (r->sps_delta_qp_in_val_minus1[i][j] ^ 
r->sps_delta_qp_diff_val[i][j]);
+if (qp_out[j] + delta_qp_out > 63)
+return AVERROR(EINVAL);
+qp_out[j+1] = qp_out[j] + delta_qp_out;
 }
 sps->chroma_qp_table[i][qp_in[0] + off] = qp_out[0];
 for (int k = qp_in[0] - 1 + off; k >= 0; k--)
-- 
2.45.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] [RFC] STF 2025

[Rémi Denis-Courmont]

Le 5 juin 2024 12:18:57 GMT+03:00, "Rémi Denis-Courmont"  a 
écrit :
>But by reacting *only* to Vittorio trying to defend himself and explicitly 
>(and ineffectively) asking for help from the CC, you look like you are 
>attacking the victim and defending the troll.

I should have said "the one doing the trolling". But whatever, the CC is free 
to ban me for calling someone a troll.
___
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/dovi_rpudec: replace brittle struct copying code

[Niklas Haas]

From: Niklas Haas 

This code was unnecessarily trying to be robust against downgrades of
libavutil (relative to the version libavcodec was compiled against), but
in the process, ended up with very brittle code that is easy to
accidentally forget to update when adding new fields.

Instead, do the obvious thing and just directly copy the parts of the
struct known at compile time. Since it is not generally supported to
link against a version of libavutil older than the version libavcodec
was compiled against, the struct shrinking externally is not a case we
need to be worrying about.
---
 libavcodec/dovi_rpudec.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index 7c7eda9d09..adf2c00cf5 100644
--- a/libavcodec/dovi_rpudec.c
+++ b/libavcodec/dovi_rpudec.c
@@ -56,14 +56,12 @@ int ff_dovi_attach_side_data(DOVIContext *s, AVFrame *frame)
 return AVERROR(ENOMEM);
 }
 
-/* Copy only the parts of these structs known to us at compiler-time. */
-#define COPY(t, a, b, last) memcpy(a, b, offsetof(t, last) + sizeof((b)->last))
-COPY(AVDOVIRpuDataHeader, av_dovi_get_header(dovi), &s->header, 
disable_residual_flag);
-COPY(AVDOVIDataMapping, av_dovi_get_mapping(dovi), s->mapping, nlq_pivots);
-COPY(AVDOVIColorMetadata, av_dovi_get_color(dovi), s->color, 
source_diagonal);
-ext_sz = FFMIN(sizeof(AVDOVIDmData), dovi->ext_block_size);
+*av_dovi_get_header(dovi)  = s->header;
+*av_dovi_get_mapping(dovi) = *s->mapping;
+*av_dovi_get_color(dovi)   = *s->color;
+av_assert0(dovi->ext_block_size >= sizeof(AVDOVIDmData));
 for (int i = 0; i < s->num_ext_blocks; i++)
-memcpy(av_dovi_get_ext(dovi, i), &s->ext_blocks[i], ext_sz);
+*av_dovi_get_ext(dovi, i) = s->ext_blocks[i];
 dovi->num_ext_blocks = s->num_ext_blocks;
 return 0;
 }
-- 
2.45.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] avcodec/dovi_rpudec: replace brittle struct copying code

[Andreas Rheinhardt]

Niklas Haas:
> From: Niklas Haas 
> 
> This code was unnecessarily trying to be robust against downgrades of
> libavutil (relative to the version libavcodec was compiled against), but
> in the process, ended up with very brittle code that is easy to
> accidentally forget to update when adding new fields.
> 
> Instead, do the obvious thing and just directly copy the parts of the
> struct known at compile time. Since it is not generally supported to
> link against a version of libavutil older than the version libavcodec
> was compiled against, the struct shrinking externally is not a case we
> need to be worrying about.

The exact opposite is true: The code is trying to be robust against
upgrades of libavutil. The reason for this is potential trailing padding
in the structures that are copied here. It may be used for actual stuff
in a future libavutil and the approach you use here allows the compiler
to clobber it.

(How would this code be robust against downgrades of libavutil at all?
There is no check here that sizeof of the side data is big enough to
contain everything we expect it to contain.)

> ---
>  libavcodec/dovi_rpudec.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
> index 7c7eda9d09..adf2c00cf5 100644
> --- a/libavcodec/dovi_rpudec.c
> +++ b/libavcodec/dovi_rpudec.c
> @@ -56,14 +56,12 @@ int ff_dovi_attach_side_data(DOVIContext *s, AVFrame 
> *frame)
>  return AVERROR(ENOMEM);
>  }
>  
> -/* Copy only the parts of these structs known to us at compiler-time. */
> -#define COPY(t, a, b, last) memcpy(a, b, offsetof(t, last) + 
> sizeof((b)->last))
> -COPY(AVDOVIRpuDataHeader, av_dovi_get_header(dovi), &s->header, 
> disable_residual_flag);
> -COPY(AVDOVIDataMapping, av_dovi_get_mapping(dovi), s->mapping, 
> nlq_pivots);
> -COPY(AVDOVIColorMetadata, av_dovi_get_color(dovi), s->color, 
> source_diagonal);
> -ext_sz = FFMIN(sizeof(AVDOVIDmData), dovi->ext_block_size);
> +*av_dovi_get_header(dovi)  = s->header;
> +*av_dovi_get_mapping(dovi) = *s->mapping;
> +*av_dovi_get_color(dovi)   = *s->color;
> +av_assert0(dovi->ext_block_size >= sizeof(AVDOVIDmData));
>  for (int i = 0; i < s->num_ext_blocks; i++)
> -memcpy(av_dovi_get_ext(dovi, i), &s->ext_blocks[i], ext_sz);
> +*av_dovi_get_ext(dovi, i) = s->ext_blocks[i];
>  dovi->num_ext_blocks = s->num_ext_blocks;
>  return 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 v6 2/4] lavu: Clarify relationship between AVClass, AVOption and context

[Stefano Sabatini]

On date Tuesday 2024-06-04 15:47:22 +0100, Andrew Sayers wrote:
> ---
>  libavutil/log.h | 16 +---
>  libavutil/opt.h | 26 +-
>  2 files changed, 34 insertions(+), 8 deletions(-)
> 
> diff --git a/libavutil/log.h b/libavutil/log.h
> index ab7ceabe22..88b35897c6 100644
> --- a/libavutil/log.h
> +++ b/libavutil/log.h
> @@ -59,9 +59,19 @@ typedef enum {
>  struct AVOptionRanges;
>  
>  /**
> - * Describe the class of an AVClass context structure. That is an
> - * arbitrary struct of which the first field is a pointer to an
> - * AVClass struct (e.g. AVCodecContext, AVFormatContext etc.).

> + * Generic Logging facilities and configuration options

Generic logging and options handling facilities.

> + *
> + * Logging and AVOptions functions expect to be passed structs

Logging and options handling functions ...

> + * whose first member is a pointer-to-@ref AVClass.
> + *

> + * Structs that only use logging facilities are often referred to as
> + * "AVClass context structures", while those that provide configuration
> + * options are called "AVOptions-enabled structs".

A struct with an AVClass as its first member can be used for both
logging and options management, there is no difference between the
two. My take:
|Structs that use AVClass might be referred to as AVClass
|contexts/structures, those that in addition define options might be
|called AVOptions contexts/structures.

> + *
> + * @see
> + * * @ref lavu_log
> + * * @ref avoptions
> + * * @ref Context
>   */
>  typedef struct AVClass {
>  /**
> diff --git a/libavutil/opt.h b/libavutil/opt.h
> index 07e27a9208..cdee8f7d28 100644
> --- a/libavutil/opt.h
> +++ b/libavutil/opt.h
> @@ -39,9 +39,16 @@
>   * @defgroup avoptions AVOptions
>   * @ingroup lavu_data
>   * @{
> - * AVOptions provide a generic system to declare options on arbitrary structs
> - * ("objects"). An option can have a help text, a type and a range of 
> possible
> - * values. Options may then be enumerated, read and written to.
> + *
> + * Inspection and configuration for AVClass context structures
> + *
> + * Provides a generic API to declare and manage options on any struct
> + * whose first member is a pointer-to-@ref AVClass.  Structs with private
> + * contexts can use that AVClass to return further @ref AVClass "AVClass"es
> + * that allow access to options in the private structs.
> + *
> + * Each option can have a help text, a type and a range of possible values.
> + * Options may be enumerated, read and written to.
>   *
>   * There are two modes of access to members of AVOption and its child 
> structs.
>   * One is called 'native access', and refers to access from the code that
> @@ -53,11 +60,20 @@
>   * question is allowed to access the field. This allows us to extend the
>   * semantics of those fields without breaking API compatibility.
>   *

> + * Note that AVOptions is not reentrant, and that many FFmpeg functions 
> access

... AVOptions access is not reeentrant ...

> + * options from separate threads.  Unless otherwise indicated, it is best to
> + * avoid modifying options once a struct has been initialized.

But this note is not relevant to the change, and should probably be
discussed separately

[...]
___
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] FFmpeg 7.0 blocking issues

[Kacper Michajlow]

On Mon, 3 Jun 2024 at 23:41, James Almer  wrote:
>
> On 6/3/2024 6:32 PM, Michael Niedermayer wrote:
> > On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote:
> >> On 2024-03-03 09:55:15 +0100, Sebastian Ramacher wrote:
> >>> On 2024-03-02 20:39:08 -0500, Sean McGovern wrote:
>  On Sat, Mar 2, 2024, 18:19 Michael Niedermayer 
>  wrote:
> 
> > On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote:
> >> On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
> >>> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
>  Hi all
> 
>  As it was a little difficult for me to not loose track of what is
>  blocking a release. I suggest that for all release blocking issues
>  open a ticket and set Blocking to 7.0
>  that way this:
>  https://trac.ffmpeg.org/query?blocking=~7.0
> 
>  or for the ones not closed:
> 
> > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> 
>  will list all blocking issues
> 
>  Ive added one, for testing that, i intend to add more if i see
> > something
> 
>  What is blocking? (IMHO)
>  * regressions (unless its non possible to fix before release)
>  * crashes
>  * security issues
>  * data loss
>  * privacy issues
>  * anything the commuity agrees should be in the release
> >>>
> >>> We still have 3 blocking issues on trac
> >>>
> >>> do people want me to wait or ignore them and branch ?
> >>> Iam not sure when the exact deadline is but if we keep waiting
> >>> we will not get into ubuntu 24.04 LTS
> >>
> >> 24.04 is past feature freeze, so it's too late for that.
> >
> > we should aim earlier in the future then.
> >
> >
> 
>  LTS is only every 2 years, yes?
> >>>
> >>> Yes
> >>>
>  How do we make sure this doesn't happen in 2026? How much of a gap is 
>  there
>  between feature freeze and release?
> >>>
> >>> Not involved in Ubuntu, so that's from past experience: feature
> >>> freeze is usually about two months before the release.
> >>>
> >>> So here's the catch: Debian's timeline also needs to be taken into
> >>> account. If the ffmpeg release does not involve the removal of deprecated 
> >>> API and
> >>> a SONAME bump, then the time from ffmpeg to release to upload to Debian
> >>> unstable and then import in Ubuntu is short. In this case, I am sure
> >>> that I could convince Ubuntu maintainers to import it even during
> >>> feature freeze.
> >>>
> >>> But with SONAME bumps and changes in the API, it takes a lot more time
> >>> to work through the high number of ffmpeg reverse dependencies. In that
> >>> case, plan a release at least 6 months before an Ubuntu LTS release.
> >>
> >>
> >>
> >>>
> >>> We usually have to rely on upstream maintainers to adopt to the
> >>> changes and that take times. Many moons ago Anton helped with providing
> >>> patches, but for the last couple of API changes it took some months from
> >>> "dear maintainer, here is ffmpeg X for testing, please fix the build of
> >>> your package" to actually doing all uploads and rebuilds. For example,
> >>> the transition to ffmpeg 6.0 was started in July 2023 and was done in
> >>> December 2023.
> >>
> >> Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in
> >> Debian. The list is available at [1]. So if you want ffmpeg X to be in
> >> Debian Y or Ubuntu Z, X needs to be released at least half a year before
> >> Y or Z freeze.
> >
> > Is there something that ffmpeg can do to reduce this breakage ?
> > (i know its a bit of a lame question as its API brekages but i mean
> > can the policy we have about deprecating API/ABI be amended in some way
> > to make this easier ?
>
> Well, no. Breakages are expected when you remove API. The real question
> is why so many projects wait until the old API is gone to migrate. What
> we removed in 7.0 has had its replacement in place for a couple years,
> since 5.1.

Is it the real question, though? I think it is unrealistic to expect
every single developer to track FFmpeg changes and immediately adjust
their projects to the latest API. Not only can this time be allocated
in different areas, but any change also introduces an additional risk
of breakage. Until the old API stops working, it is really up to
individual project maintainers to decide when they want to upgrade. If
they choose to upgrade in bulk after the new stable version is
released, it is perfectly understandable.

Even if a project is updated to a new API, as in the case of mpv, we
still experienced breakage after the removal of the old API. One build
[1] and one runtime [2] issue occurred simply because the deprecation
itself was not sufficiently visible, or not visible at all, and those
two small pieces were missing. Sure, you can blame developers for

Re: [FFmpeg-devel] [PATCH v6] avcodec: add farbfeld encoder

[Stefano Sabatini]

On date Wednesday 2024-06-05 12:02:08 +0200, Andreas Rheinhardt wrote:
> Stefano Sabatini:
> > On date Tuesday 2024-06-04 17:28:35 -0500, Marcus B Spencer wrote:
[...]
> >> +#define HEADER_SIZE 16
> >> +
> >> +static int farbfeld_encode_frame(AVCodecContext *ctx, AVPacket *pkt,
> >> + const AVFrame *p, int *got_packet)
> >> +{
> > 
> >> +int raw_img_size = av_image_get_buffer_size(
> >> +p->format,
> >> +p->width,
> >> +p->height,
> >> +1
> >> +);
> > 
> >> +int64_t buf_size = (int64_t)raw_img_size + HEADER_SIZE;
> > 
> > not yet, this might change the sign for a negative raw_img_size, you
> > need two separate checks (one is not enough), as in the following:
> > 
> > int raw_img_size = av_image_get_buffer_size(p->format, p->width,p->height, 
> > 1);
> > 
> > if (raw_image_size < 0)
> > return raw_image_size;
> >  
> > int buf_size = raw_img_size + HEADER_SIZE;
> > if (buf_size < 0)
> > return AVERROR(EINVAL);
> 

> This is absolutely wrong: raw_img_size is nonnegative here as is
> HEADER_SIZE and the addition will be performed as an int, so that
> overflow would be UB which implies that the compiler can optimize this
> check away.

Correct, the following should avoid the UB if I'm not mistaken again:

if (HEADER_SIZE > (INT_MAX - raw_img_size))
 return AVERROR(EINVAL);
int buf_size = raw_img_size + HEADER_SIZE;
...

> One does not need two checks as long as int is 32 bits (because then one
> can just perform the addition in 64bits).

sizeof(int) is not defined by the C standard, so you cannot assume it
is 32 bits (even if on most platforms/compilers it will be)

> Just use the following (#if
> has been used because compilers have a tendency to emit warnings if a
> particular check is tautologically false):
> 
> #if INT_MAX > INT64_MAX - HEADER_SIZE
> if (raw_img_size > INT64_MAX - HEADER_SIZE)
> return AVERROR(ERANGE);
> #endif
___
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 v6] avcodec: add farbfeld encoder

[Andreas Rheinhardt]

Stefano Sabatini:
> On date Wednesday 2024-06-05 12:02:08 +0200, Andreas Rheinhardt wrote:
>> Stefano Sabatini:
>>> On date Tuesday 2024-06-04 17:28:35 -0500, Marcus B Spencer wrote:
> [...]
 +#define HEADER_SIZE 16
 +
 +static int farbfeld_encode_frame(AVCodecContext *ctx, AVPacket *pkt,
 + const AVFrame *p, int *got_packet)
 +{
>>>
 +int raw_img_size = av_image_get_buffer_size(
 +p->format,
 +p->width,
 +p->height,
 +1
 +);
>>>
 +int64_t buf_size = (int64_t)raw_img_size + HEADER_SIZE;
>>>
>>> not yet, this might change the sign for a negative raw_img_size, you
>>> need two separate checks (one is not enough), as in the following:
>>>
>>> int raw_img_size = av_image_get_buffer_size(p->format, p->width,p->height, 
>>> 1);
>>>
>>> if (raw_image_size < 0)
>>> return raw_image_size;
>>>  
>>> int buf_size = raw_img_size + HEADER_SIZE;
>>> if (buf_size < 0)
>>> return AVERROR(EINVAL);
>>
> 
>> This is absolutely wrong: raw_img_size is nonnegative here as is
>> HEADER_SIZE and the addition will be performed as an int, so that
>> overflow would be UB which implies that the compiler can optimize this
>> check away.
> 
> Correct, the following should avoid the UB if I'm not mistaken again:
> 
> if (HEADER_SIZE > (INT_MAX - raw_img_size))
>  return AVERROR(EINVAL);
> int buf_size = raw_img_size + HEADER_SIZE;
> ...
> 
>> One does not need two checks as long as int is 32 bits (because then one
>> can just perform the addition in 64bits).
> 
> sizeof(int) is not defined by the C standard, so you cannot assume it
> is 32 bits (even if on most platforms/compilers it will be)
> 

Did you even read the following? It handles the case where simply using
64bits is not enough.

>> Just use the following (#if
>> has been used because compilers have a tendency to emit warnings if a
>> particular check is tautologically false):
>>
>> #if INT_MAX > INT64_MAX - HEADER_SIZE
>> if (raw_img_size > INT64_MAX - HEADER_SIZE)
>> return AVERROR(ERANGE);
>> #endif

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

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

[FFmpeg-devel] [PATCH 1/7] avcodec/hevc/Makefile: Move rules for lavc/* files to lavc/Makefile

[Andreas Rheinhardt]

If any of these files (say A) would be changed in such a way
that A acquires a new dependency on another file B, building B
would need to be added to all the rules that lead to A being built.
Yet currently the rules for several files are spread over
the lavc Makefile and the Makefile of the lavc/hevc subdir, making
it more likely to be forgotten. So move the rules for these files
to the lavc/Makefile.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/Makefile  | 4 
 libavcodec/hevc/Makefile | 8 
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 8ab4398b6c..1a44352906 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -106,6 +106,9 @@ OBJS-$(CONFIG_H264PARSE)   += h264_parse.o 
h264_ps.o h264data.o \
 OBJS-$(CONFIG_H264PRED)+= h264pred.o
 OBJS-$(CONFIG_H264QPEL)+= h264qpel.o
 OBJS-$(CONFIG_H264_SEI)+= h264_sei.o h2645_sei.o
+OBJS-$(CONFIG_HEVCPARSE)   += h2645data.o h2645_parse.o h2645_vui.o
+OBJS-$(CONFIG_HEVC_SEI)+= h2645_sei.o aom_film_grain.o \
+  dynamic_hdr_vivid.o
 OBJS-$(CONFIG_HPELDSP) += hpeldsp.o
 OBJS-$(CONFIG_HUFFMAN) += huffman.o
 OBJS-$(CONFIG_HUFFYUVDSP)  += huffyuvdsp.o
@@ -427,6 +430,7 @@ OBJS-$(CONFIG_HCA_DECODER) += hcadec.o
 OBJS-$(CONFIG_HCOM_DECODER)+= hcom.o
 OBJS-$(CONFIG_HDR_DECODER) += hdrdec.o
 OBJS-$(CONFIG_HDR_ENCODER) += hdrenc.o
+OBJS-$(CONFIG_HEVC_DECODER)+= aom_film_grain.o h274.o
 OBJS-$(CONFIG_HEVC_AMF_ENCODER)+= amfenc_hevc.o
 OBJS-$(CONFIG_HEVC_CUVID_DECODER)  += cuviddec.o
 OBJS-$(CONFIG_HEVC_MEDIACODEC_DECODER) += mediacodecdec.o
diff --git a/libavcodec/hevc/Makefile b/libavcodec/hevc/Makefile
index 9c385ef3da..93ed4213f6 100644
--- a/libavcodec/hevc/Makefile
+++ b/libavcodec/hevc/Makefile
@@ -2,8 +2,6 @@ clean::
$(RM) $(CLEANSUFFIXES:%=libavcodec/hevc/%)
 
 OBJS-$(CONFIG_HEVC_DECODER) += \
-aom_film_grain.o   \
-h274.o \
 hevc/cabac.o   \
 hevc/data.o\
 hevc/dsp.o \
@@ -18,9 +16,6 @@ OBJS-$(CONFIG_HEVC_PARSER) += \
 
 
 OBJS-$(CONFIG_HEVCPARSE) += \
-h2645data.o \
-h2645_parse.o   \
-h2645_vui.o \
 hevc/data.o \
 hevc/parse.o\
 hevc/ps.o   \
@@ -28,9 +23,6 @@ OBJS-$(CONFIG_HEVCPARSE) += \
 
 OBJS-$(CONFIG_HEVC_SEI) +=  \
 hevc/sei.o  \
-h2645_sei.o \
-dynamic_hdr_vivid.o \
-aom_film_grain.o\
 
 
 libavcodec/hevc/%.o: CPPFLAGS += -I$(SRC_PATH)/libavcodec/
-- 
2.40.1

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

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

[FFmpeg-devel] [PATCH 2/7] avformat/vvc: Use put_bytes_output()

[Andreas Rheinhardt]

The PutBitContext has just been flushed.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/vvc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/vvc.c b/libavformat/vvc.c
index ac3209a01b..d8195f0fd2 100644
--- a/libavformat/vvc.c
+++ b/libavformat/vvc.c
@@ -761,7 +761,7 @@ static int vvcc_write(AVIOContext *pb, 
VVCDecoderConfigurationRecord *vvcc)
 ff_copy_bits(&pbc, vvcc->ptl.general_constraint_info, 
(vvcc->ptl.num_bytes_constraint_info - 1) * 8);
 put_bits(&pbc, 6, 
vvcc->ptl.general_constraint_info[vvcc->ptl.num_bytes_constraint_info - 1] & 
0x3f);
 flush_put_bits(&pbc);
-avio_write(pb, buf, put_bytes_count(&pbc, 1));
+avio_write(pb, buf, put_bytes_output(&pbc));
 
 if (vvcc->num_sublayers > 1) {
 uint8_t ptl_sublayer_level_present_flags = 0;
-- 
2.40.1

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

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

[FFmpeg-devel] [PATCH 3/7] avformat/vvc: Don't use ff_copy_bits()

[Andreas Rheinhardt]

There is no benefit in using it: The fast path of copying
is not taken because of misalignment; furthermore we are
only dealing with a few byte here anyway, so simply copy
the bytes manually, avoiding the dependency on bitstream.c
in lavf (which also contains a function that is completely
unused in lavf).

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/Makefile| 1 -
 libavformat/bitstream.c | 1 -
 libavformat/vvc.c   | 4 ++--
 tests/ref/fate/source   | 1 -
 4 files changed, 2 insertions(+), 5 deletions(-)
 delete mode 100644 libavformat/bitstream.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 1c4d9deccd..af31d6f795 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -728,7 +728,6 @@ OBJS-$(CONFIG_LIBZMQ_PROTOCOL)   += libzmq.o
 # Objects duplicated from other libraries for shared builds
 SHLIBOBJS+= log2_tab.o to_upper4.o
 SHLIBOBJS-$(CONFIG_ISO_MEDIA)+= mpegaudiotabs.o
-SHLIBOBJS-$(CONFIG_ISO_WRITER)   += bitstream.o
 SHLIBOBJS-$(CONFIG_FLV_MUXER)+= mpeg4audio_sample_rates.o
 SHLIBOBJS-$(CONFIG_HLS_DEMUXER)  += ac3_channel_layout_tab.o
 SHLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER)+= jpegxl_parse.o
diff --git a/libavformat/bitstream.c b/libavformat/bitstream.c
deleted file mode 100644
index 2afda37c30..00
--- a/libavformat/bitstream.c
+++ /dev/null
@@ -1 +0,0 @@
-#include "libavcodec/bitstream.c"
diff --git a/libavformat/vvc.c b/libavformat/vvc.c
index d8195f0fd2..679bb07a4d 100644
--- a/libavformat/vvc.c
+++ b/libavformat/vvc.c
@@ -757,8 +757,8 @@ static int vvcc_write(AVIOContext *pb, 
VVCDecoderConfigurationRecord *vvcc)
 put_bits(&pbc, 1, vvcc->ptl.ptl_frame_only_constraint_flag);
 put_bits(&pbc, 1, vvcc->ptl.ptl_multilayer_enabled_flag);
 av_assert0(vvcc->ptl.num_bytes_constraint_info);
-if (vvcc->ptl.num_bytes_constraint_info > 1)
-ff_copy_bits(&pbc, vvcc->ptl.general_constraint_info, 
(vvcc->ptl.num_bytes_constraint_info - 1) * 8);
+for (int i = 0; i < vvcc->ptl.num_bytes_constraint_info - 1; i++)
+put_bits(&pbc, 8, vvcc->ptl.general_constraint_info[i]);
 put_bits(&pbc, 6, 
vvcc->ptl.general_constraint_info[vvcc->ptl.num_bytes_constraint_info - 1] & 
0x3f);
 flush_put_bits(&pbc);
 avio_write(pb, buf, put_bytes_output(&pbc));
diff --git a/tests/ref/fate/source b/tests/ref/fate/source
index a3beb35093..d7b48a8b85 100644
--- a/tests/ref/fate/source
+++ b/tests/ref/fate/source
@@ -7,7 +7,6 @@ libavdevice/file_open.c
 libavdevice/reverse.c
 libavfilter/file_open.c
 libavfilter/log2_tab.c
-libavformat/bitstream.c
 libavformat/file_open.c
 libavformat/golomb_tab.c
 libavformat/log2_tab.c
-- 
2.40.1

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

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

[FFmpeg-devel] [PATCH 4/7] avformat/vvc: Fix crash on allocation failure, avoid allocations

[Andreas Rheinhardt]

This is the VVC version of 8b5d15530127fea54e934043a64653859de07353.

(Hint: This ensures that the order of NALU arrays is OPI-VPS-SPS-PPS-
Prefix-SEI-Suffix-SEI, regardless of the order in the original
extradata. I hope this is right.)

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/vvc.c | 169 --
 1 file changed, 73 insertions(+), 96 deletions(-)

diff --git a/libavformat/vvc.c b/libavformat/vvc.c
index 679bb07a4d..819ee02e2c 100644
--- a/libavformat/vvc.c
+++ b/libavformat/vvc.c
@@ -32,6 +32,16 @@
 #include "avio_internal.h"
 #include "vvc.h"
 
+enum {
+OPI_INDEX,
+VPS_INDEX,
+SPS_INDEX,
+PPS_INDEX,
+SEI_PREFIX_INDEX,
+SEI_SUFFIX_INDEX,
+NB_ARRAYS
+};
+
 typedef struct VVCCNALUnitArray {
 uint8_t array_completeness;
 uint8_t NAL_unit_type;
@@ -67,7 +77,7 @@ typedef struct VVCDecoderConfigurationRecord {
 uint16_t max_picture_height;
 uint16_t avg_frame_rate;
 uint8_t num_of_arrays;
-VVCCNALUnitArray *array;
+VVCCNALUnitArray arrays[NB_ARRAYS];
 } VVCDecoderConfigurationRecord;
 
 static void vvcc_update_ptl(VVCDecoderConfigurationRecord *vvcc,
@@ -432,32 +442,11 @@ static void nal_unit_parse_header(GetBitContext *gb, 
uint8_t *nal_type)
 
 static int vvcc_array_add_nal_unit(uint8_t *nal_buf, uint32_t nal_size,
uint8_t nal_type, int ps_array_completeness,
-   VVCDecoderConfigurationRecord *vvcc)
+   VVCCNALUnitArray *array)
 {
 int ret;
-uint8_t index;
 uint16_t num_nalus;
-VVCCNALUnitArray *array;
-
-for (index = 0; index < vvcc->num_of_arrays; index++)
-if (vvcc->array[index].NAL_unit_type == nal_type)
-break;
-
-if (index >= vvcc->num_of_arrays) {
-uint8_t i;
-
-ret =
-av_reallocp_array(&vvcc->array, index + 1,
-  sizeof(VVCCNALUnitArray));
-if (ret < 0)
-return ret;
-
-for (i = vvcc->num_of_arrays; i <= index; i++)
-memset(&vvcc->array[i], 0, sizeof(VVCCNALUnitArray));
-vvcc->num_of_arrays = index + 1;
-}
 
-array = &vvcc->array[index];
 num_nalus = array->num_nalus;
 
 ret = av_reallocp_array(&array->nal_unit, num_nalus + 1, sizeof(uint8_t 
*));
@@ -504,7 +493,8 @@ static int vvcc_array_add_nal_unit(uint8_t *nal_buf, 
uint32_t nal_size,
 
 static int vvcc_add_nal_unit(uint8_t *nal_buf, uint32_t nal_size,
  int ps_array_completeness,
- VVCDecoderConfigurationRecord *vvcc)
+ VVCDecoderConfigurationRecord *vvcc,
+ unsigned array_idx)
 {
 int ret = 0;
 GetBitContext gbc;
@@ -529,18 +519,15 @@ static int vvcc_add_nal_unit(uint8_t *nal_buf, uint32_t 
nal_size,
  * vvcc. Perhaps the SEI playload type should be checked
  * and non-declarative SEI messages discarded?
  */
-switch (nal_type) {
-case VVC_OPI_NUT:
-case VVC_VPS_NUT:
-case VVC_SPS_NUT:
-case VVC_PPS_NUT:
-case VVC_PREFIX_SEI_NUT:
-case VVC_SUFFIX_SEI_NUT:
-ret = vvcc_array_add_nal_unit(nal_buf, nal_size, nal_type,
-  ps_array_completeness, vvcc);
-if (ret < 0)
-goto end;
-else if (nal_type == VVC_VPS_NUT)
+ret = vvcc_array_add_nal_unit(nal_buf, nal_size, nal_type,
+  ps_array_completeness,
+  &vvcc->arrays[array_idx]);
+if (ret < 0)
+goto end;
+if (vvcc->arrays[array_idx].num_nalus == 1)
+vvcc->num_of_arrays++;
+
+if (nal_type == VVC_VPS_NUT)
 ret = vvcc_parse_vps(&gbc, vvcc);
 else if (nal_type == VVC_SPS_NUT)
 ret = vvcc_parse_sps(&gbc, vvcc);
@@ -551,11 +538,6 @@ static int vvcc_add_nal_unit(uint8_t *nal_buf, uint32_t 
nal_size,
 }
 if (ret < 0)
 goto end;
-break;
-default:
-ret = AVERROR_INVALIDDATA;
-goto end;
-}
 
   end:
 av_free(rbsp_buf);
@@ -572,22 +554,21 @@ static void vvcc_init(VVCDecoderConfigurationRecord *vvcc)
 
 static void vvcc_close(VVCDecoderConfigurationRecord *vvcc)
 {
-uint8_t i;
+for (unsigned i = 0; i < FF_ARRAY_ELEMS(vvcc->arrays); i++) {
+VVCCNALUnitArray *const array = &vvcc->arrays[i];
 
-for (i = 0; i < vvcc->num_of_arrays; i++) {
-vvcc->array[i].num_nalus = 0;
-av_freep(&vvcc->array[i].nal_unit);
-av_freep(&vvcc->array[i].nal_unit_length);
+array->num_nalus = 0;
+av_freep(&array->nal_unit);
+av_freep(&array->nal_unit_length);
 }
 
 vvcc->num_of_arrays = 0;
-av_freep(&vvcc->array);
 }
 
 static int vvcc_write(AVIOContext *pb, VVCDecoderConfigurationRecord *vvcc)
 {
 uint8_t i;
-uint16_t j, vps_count = 0, sps_count = 0, pps_count = 0;
+uint16_t

[FFmpeg-devel] [PATCH 5/7] avformat/vvc: Reindent after the previous commit

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/vvc.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavformat/vvc.c b/libavformat/vvc.c
index 819ee02e2c..3821de7812 100644
--- a/libavformat/vvc.c
+++ b/libavformat/vvc.c
@@ -527,17 +527,17 @@ static int vvcc_add_nal_unit(uint8_t *nal_buf, uint32_t 
nal_size,
 if (vvcc->arrays[array_idx].num_nalus == 1)
 vvcc->num_of_arrays++;
 
-if (nal_type == VVC_VPS_NUT)
-ret = vvcc_parse_vps(&gbc, vvcc);
-else if (nal_type == VVC_SPS_NUT)
-ret = vvcc_parse_sps(&gbc, vvcc);
-else if (nal_type == VVC_PPS_NUT)
-ret = vvcc_parse_pps(&gbc, vvcc);
-else if (nal_type == VVC_OPI_NUT) {
-// not yet supported
-}
-if (ret < 0)
-goto end;
+if (nal_type == VVC_VPS_NUT)
+ret = vvcc_parse_vps(&gbc, vvcc);
+else if (nal_type == VVC_SPS_NUT)
+ret = vvcc_parse_sps(&gbc, vvcc);
+else if (nal_type == VVC_PPS_NUT)
+ret = vvcc_parse_pps(&gbc, vvcc);
+else if (nal_type == VVC_OPI_NUT) {
+// not yet supported
+}
+if (ret < 0)
+goto end;
 
   end:
 av_free(rbsp_buf);
-- 
2.40.1

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

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

[FFmpeg-devel] [PATCH 6/7] avformat/evc: Fix format specifiers

[Andreas Rheinhardt]

Fixes -Wformat warnings; see e.g.
https://fate.ffmpeg.org/log.cgi?slot=aarch64-osx-clang-1200.0.32.29&time=20240604151047&log=compile

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/evc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/evc.c b/libavformat/evc.c
index 2f4c74fe51..0b72a6441e 100644
--- a/libavformat/evc.c
+++ b/libavformat/evc.c
@@ -208,15 +208,15 @@ static int evcc_write(AVIOContext *pb, 
EVCDecoderConfigurationRecord *evcc)
 if(array->numNalus == 0)
 continue;
 
-av_log(NULL, AV_LOG_TRACE, "array_completeness[%"PRIu8"]:  
 %"PRIu8"\n",
+av_log(NULL, AV_LOG_TRACE, "array_completeness[%u]:   
%"PRIu8"\n",
i, array->array_completeness);
-av_log(NULL, AV_LOG_TRACE, "NAL_unit_type[%"PRIu8"]:   
 %"PRIu8"\n",
+av_log(NULL, AV_LOG_TRACE, "NAL_unit_type[%u]:
%"PRIu8"\n",
i, array->NAL_unit_type);
-av_log(NULL, AV_LOG_TRACE, "numNalus[%"PRIu8"]:
 %"PRIu16"\n",
+av_log(NULL, AV_LOG_TRACE, "numNalus[%u]: 
%"PRIu16"\n",
i, array->numNalus);
 for ( unsigned j = 0; j < array->numNalus; j++)
 av_log(NULL, AV_LOG_TRACE,
-   "nalUnitLength[%"PRIu8"][%"PRIu16"]: 
%"PRIu16"\n",
+   "nalUnitLength[%u][%u]: %"PRIu16"\n",
i, j, array->nalUnitLength[j]);
 }
 
-- 
2.40.1

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

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

[FFmpeg-devel] [PATCH 7/7] avcodec/cbs_h266_syntax_template: Use correct format specifier

[Andreas Rheinhardt]

H266RawSliceHeader.num_entry_points is an uint32_t.
Fixes -Wformat warnings:
https://fate.ffmpeg.org/log.cgi?slot=aarch64-osx-clang-1200.0.32.29&time=20240604151047&log=compile

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_h266_syntax_template.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/cbs_h266_syntax_template.c 
b/libavcodec/cbs_h266_syntax_template.c
index 38685704c5..53c4b60b0d 100644
--- a/libavcodec/cbs_h266_syntax_template.c
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -3426,7 +3426,7 @@ static int FUNC(slice_header) (CodedBitstreamContext 
*ctx, RWContext *rw,
 current->num_entry_points--;
 if (current->num_entry_points > VVC_MAX_ENTRY_POINTS) {
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Too many entry points: "
-   "%" PRIu16 ".\n", current->num_entry_points);
+   "%" PRIu32 ".\n", current->num_entry_points);
 return AVERROR_PATCHWELCOME;
 }
 if (current->num_entry_points > 0) {
-- 
2.40.1

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

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

[FFmpeg-devel] [PATCH v2] movenc: Add an option for hiding fragments at the end

[Martin Storsjö]

This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)

This results in a file where the mdat atom contains (and hides)
all the moof atoms that were part of the fragmented file structure
initially.
---
v2: Made the flag implicitly set FF_MOV_FLAG_FRAGMENT (as it makes
no sense without it).

Updated the description of the flag to "Write a fragmented file that
is converted to non-fragmented at the end".

Kept the flag named "hide_fragments", but I'm also pondering if we
maybe should go for a name like "hybrid_fragmented" or so, as a
better description of _what_ it produces, as opposed to _how_ it
does things. (One could also consider "hybrid_mp4", but even if mp4
is the main thing, the same also goes for mov and a bunch of other
related formats.)
---
 doc/muxers.texi   |  7 
 libavformat/movenc.c  | 62 ---
 libavformat/movenc.h  |  4 ++-
 libavformat/version.h |  4 +--
 tests/fate/lavf-container.mak |  3 +-
 tests/ref/lavf/mov_hide_frag  |  3 ++
 6 files changed, 74 insertions(+), 9 deletions(-)
 create mode 100644 tests/ref/lavf/mov_hide_frag

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 6340c8e54d..e313b5e631 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -569,6 +569,13 @@ experimental, may be renamed or changed, do not use from 
scripts.
 
 @item write_gama
 write deprecated gama atom
+
+@item hide_fragments
+After writing a fragmented file, convert it to a regular, non-fragmented
+file at the end. This keeps the file readable while it is being
+written, and makes it recoverable if the process of writing the file
+gets aborted uncleanly, while still producing an easily seekable
+and widely compatible non-fragmented file in the end.
 @end table
 
 @item movie_timescale @var{scale}
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index d1517870fc..da16a9dae5 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -110,6 +110,7 @@ static const AVOption options[] = {
   { "use_metadata_tags", "Use mdta atom for metadata.", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_USE_MDTA}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, .unit = "movflags" },
   { "write_colr", "Write colr atom even if the color info is unspecified 
(Experimental, may be renamed or changed, do not use from scripts)", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_WRITE_COLR}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, .unit = "movflags" },
   { "write_gama", "Write deprecated gama atom", 0, AV_OPT_TYPE_CONST, 
{.i64 = FF_MOV_FLAG_WRITE_GAMA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
.unit = "movflags" },
+  { "hide_fragments", "Write a fragmented file that is converted to 
non-fragmented at the end", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_HIDE_FRAGMENTS}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
.unit = "movflags" },
 { "min_frag_duration", "Minimum fragment duration", 
offsetof(MOVMuxContext, min_fragment_duration), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM},
 { "mov_gamma", "gamma value for gama atom", offsetof(MOVMuxContext, 
gamma), AV_OPT_TYPE_FLOAT, {.dbl = 0.0 }, 0.0, 10, AV_OPT_FLAG_ENCODING_PARAM},
 { "movie_timescale", "set movie timescale", offsetof(MOVMuxContext, 
movie_timescale), AV_OPT_TYPE_INT, {.i64 = MOV_TIMESCALE}, 1, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM},
@@ -5993,10 +5994,30 @@ static int mov_write_squashed_packets(AVFormatContext 
*s)
 return 0;
 }
 
-static int mov_finish_fragment(MOVTrack *track)
+static int mov_finish_fragment(MOVMuxContext *mov, MOVTrack *track,
+   int64_t ref_pos)
 {
+int i;
 if (!track->entry)
 return 0;
+if (mov->flags & FF_MOV_FLAG_HIDE_FRAGMENTS) {
+for (i = 0; i < track->entry; i++)
+track->cluster[i].pos += ref_pos + track->data_offset;
+if (track->cluster_written == 0 && !(mov->flags & 
FF_MOV_FLAG_EMPTY_MOOV)) {
+// First flush. If this was a case of not using empty moov, reset 
chunking.
+for (i = 0; i < track->entry; i++) {
+track->cluster[i].chunkNum = 0;
+track->cluster[i].samples_in_chunk = track->cluster[i].entries;
+}
+}
+if (av_reallocp_array(&track->cluster_written,
+  track->entry_written + track->entry,
+  sizeof(*track->cluster)))
+return AVERROR(ENOMEM);
+memcpy(&track->cluster_written[track->entry_written],
+   track->cluster, track->entry * sizeof(*track->cluster));
+track->entry_written += track->entry;
+}
 track->entry = 0;
 track->entries_flushed = 0;
 track->end_reliable = 0;
@@ -6007,7 +6028,7 @@ static int mov_f

Re: [FFmpeg-devel] [PATCH 4/7] avformat/vvc: Fix crash on allocation failure, avoid allocations

[Andreas Rheinhardt]

Andreas Rheinhardt:
> This is the VVC version of 8b5d15530127fea54e934043a64653859de07353.
> 
> (Hint: This ensures that the order of NALU arrays is OPI-VPS-SPS-PPS-
> Prefix-SEI-Suffix-SEI, regardless of the order in the original
> extradata. I hope this is right.)
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/vvc.c | 169 --
>  1 file changed, 73 insertions(+), 96 deletions(-)
> 

Even after these patches, there are some strange things going in vvc.c:
1. There are at least 71 bits in general_constraint_info (if present),
yet only 70 of these are written (the
gci_no_chroma_qp_offset_constraint_flag is not).
2. The code contains checks for VVC_DCI_NUT, yet these are dead, because
these NALU type is filtered out before.
3. A comment claims to need at least one VPS and SPS, but it actually
checks for SPS and PPS. Does someone know what was intended?

- Andreas

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/dovi_rpudec: replace brittle struct copying code

[Niklas Haas]

On Wed, 05 Jun 2024 12:07:08 +0200 Andreas Rheinhardt 
 wrote:
> Niklas Haas:
> > From: Niklas Haas 
> > 
> > This code was unnecessarily trying to be robust against downgrades of
> > libavutil (relative to the version libavcodec was compiled against), but
> > in the process, ended up with very brittle code that is easy to
> > accidentally forget to update when adding new fields.
> > 
> > Instead, do the obvious thing and just directly copy the parts of the
> > struct known at compile time. Since it is not generally supported to
> > link against a version of libavutil older than the version libavcodec
> > was compiled against, the struct shrinking externally is not a case we
> > need to be worrying about.
> 
> The exact opposite is true: The code is trying to be robust against
> upgrades of libavutil. The reason for this is potential trailing padding
> in the structures that are copied here. It may be used for actual stuff
> in a future libavutil and the approach you use here allows the compiler
> to clobber it.
> 
> (How would this code be robust against downgrades of libavutil at all?
> There is no check here that sizeof of the side data is big enough to
> contain everything we expect it to contain.)

I should clearly not write code immediately after waking up.

Yes, true, the only thing this logic is trying to accomplish is being
robust against the struct gaining extra padding in the future.

That said, I still think the code as written is brittle and I'm not sure
it's providing anything useful. What is the likelihood of this struct
being extended in a way that does not affect the encoder, vs. the
likelihood of this struct being extended but somebody forgetting to bump
the equivalent "last field" entry in this file?

Anecdotally, the latter has already happened once.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 1/2] avcodec/dnxhdenc: Move PutBitContext from ctx to stack

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/dnxhdenc.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 0cb25d7714..4760a2932c 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -559,7 +559,7 @@ static int dnxhd_write_header(AVCodecContext *avctx, 
uint8_t *buf)
 return 0;
 }
 
-static av_always_inline void dnxhd_encode_dc(DNXHDEncContext *ctx, int diff)
+static av_always_inline void dnxhd_encode_dc(PutBitContext *pb, 
DNXHDEncContext *ctx, int diff)
 {
 int nbits;
 if (diff < 0) {
@@ -568,19 +568,19 @@ static av_always_inline void 
dnxhd_encode_dc(DNXHDEncContext *ctx, int diff)
 } else {
 nbits = av_log2_16bit(2 * diff);
 }
-put_bits(&ctx->m.pb, ctx->cid_table->dc_bits[nbits] + nbits,
+put_bits(pb, ctx->cid_table->dc_bits[nbits] + nbits,
  (ctx->cid_table->dc_codes[nbits] << nbits) +
  av_mod_uintp2(diff, nbits));
 }
 
 static av_always_inline
-void dnxhd_encode_block(DNXHDEncContext *ctx, int16_t *block,
-int last_index, int n)
+void dnxhd_encode_block(PutBitContext *pb, DNXHDEncContext *ctx,
+int16_t *block, int last_index, int n)
 {
 int last_non_zero = 0;
 int slevel, i, j;
 
-dnxhd_encode_dc(ctx, block[0] - ctx->m.last_dc[n]);
+dnxhd_encode_dc(pb, ctx, block[0] - ctx->m.last_dc[n]);
 ctx->m.last_dc[n] = block[0];
 
 for (i = 1; i <= last_index; i++) {
@@ -589,14 +589,14 @@ void dnxhd_encode_block(DNXHDEncContext *ctx, int16_t 
*block,
 if (slevel) {
 int run_level = i - last_non_zero - 1;
 int rlevel = slevel * (1 << 1) | !!run_level;
-put_bits(&ctx->m.pb, ctx->vlc_bits[rlevel], 
ctx->vlc_codes[rlevel]);
+put_bits(pb, ctx->vlc_bits[rlevel], ctx->vlc_codes[rlevel]);
 if (run_level)
-put_bits(&ctx->m.pb, ctx->run_bits[run_level],
+put_bits(pb, ctx->run_bits[run_level],
  ctx->run_codes[run_level]);
 last_non_zero = i;
 }
 }
-put_bits(&ctx->m.pb, ctx->vlc_bits[0], ctx->vlc_codes[0]); // EOB
+put_bits(pb, ctx->vlc_bits[0], ctx->vlc_codes[0]); // EOB
 }
 
 static av_always_inline
@@ -879,9 +879,10 @@ static int dnxhd_encode_thread(AVCodecContext *avctx, void 
*arg,
int jobnr, int threadnr)
 {
 DNXHDEncContext *ctx = avctx->priv_data;
+PutBitContext pb0, *const pb = &pb0;
 int mb_y = jobnr, mb_x;
 ctx = ctx->thread[threadnr];
-init_put_bits(&ctx->m.pb, (uint8_t *)arg + ctx->data_offset + 
ctx->slice_offs[jobnr],
+init_put_bits(pb, (uint8_t *)arg + ctx->data_offset + 
ctx->slice_offs[jobnr],
   ctx->slice_size[jobnr]);
 
 ctx->m.last_dc[0] =
@@ -892,8 +893,8 @@ static int dnxhd_encode_thread(AVCodecContext *avctx, void 
*arg,
 int qscale = ctx->mb_qscale[mb];
 int i;
 
-put_bits(&ctx->m.pb, 11, qscale);
-put_bits(&ctx->m.pb, 1, avctx->pix_fmt == AV_PIX_FMT_YUV444P10);
+put_bits(pb, 11, qscale);
+put_bits(pb, 1, avctx->pix_fmt == AV_PIX_FMT_YUV444P10);
 
 dnxhd_get_blocks(ctx, mb_x, mb_y);
 
@@ -904,13 +905,13 @@ static int dnxhd_encode_thread(AVCodecContext *avctx, 
void *arg,
  ctx->is_444 ? (((i >> 1) % 3) 
< 1 ? 0 : 4): 4 & (2*i),
  qscale, &overflow);
 
-dnxhd_encode_block(ctx, block, last_index, n);
+dnxhd_encode_block(pb, ctx, block, last_index, n);
 }
 }
-if (put_bits_count(&ctx->m.pb) & 31)
-put_bits(&ctx->m.pb, 32 - (put_bits_count(&ctx->m.pb) & 31), 0);
-flush_put_bits(&ctx->m.pb);
-memset(put_bits_ptr(&ctx->m.pb), 0, put_bytes_left(&ctx->m.pb, 0));
+if (put_bits_count(pb) & 31)
+put_bits(pb, 32 - (put_bits_count(pb) & 31), 0);
+flush_put_bits(pb);
+memset(put_bits_ptr(pb), 0, put_bytes_left(pb, 0));
 return 0;
 }
 
-- 
2.40.1

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

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

[FFmpeg-devel] [PATCH 2/2] avcodec/dnxhdenc: Simplify padding

[Andreas Rheinhardt]

It is unnecessary to first pad to 32bits; the memset later
will pad everything will with zeroes anyway.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/dnxhdenc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 4760a2932c..028604a6e5 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -908,8 +908,6 @@ static int dnxhd_encode_thread(AVCodecContext *avctx, void 
*arg,
 dnxhd_encode_block(pb, ctx, block, last_index, n);
 }
 }
-if (put_bits_count(pb) & 31)
-put_bits(pb, 32 - (put_bits_count(pb) & 31), 0);
 flush_put_bits(pb);
 memset(put_bits_ptr(pb), 0, put_bytes_left(pb, 0));
 return 0;
-- 
2.40.1

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

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

Re: [FFmpeg-devel] [PATCH v6 2/4] lavu: Clarify relationship between AVClass, AVOption and context

[Andrew Sayers]

On Wed, Jun 05, 2024 at 12:34:48PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2024-06-04 15:47:22 +0100, Andrew Sayers wrote:

> > + * Structs that only use logging facilities are often referred to as
> > + * "AVClass context structures", while those that provide configuration
> > + * options are called "AVOptions-enabled structs".
> 
> A struct with an AVClass as its first member can be used for both
> logging and options management, there is no difference between the
> two. My take:
> |Structs that use AVClass might be referred to as AVClass
> |contexts/structures, those that in addition define options might be
> |called AVOptions contexts/structures.

I think you were away when this came up, and anyway this thread is getting
quite unwieldy.  See [1] and [2] for the full version, but in short, defining
AVClass by layout leads to conclusions that are at best unintuitive.


> > + * Note that AVOptions is not reentrant, and that many FFmpeg functions 
> > access
> 
> ... AVOptions access is not reeentrant ...
> 
> > + * options from separate threads.  Unless otherwise indicated, it is best 
> > to
> > + * avoid modifying options once a struct has been initialized.
> 
> But this note is not relevant to the change, and should probably be
> discussed separately

Short version: I'll make a separate patch now, let's come back to this after

Long version...

If you assume options can be set at any time, they broadly resemble a reflection
mechanism.  If you assume they can only be set during the configuration stage,
they broadly resemble an OOP constructor.  The document needs to address the one
they resemble (even if just to say "this is why they're different"), and needs
to steer clear of any possible comparison with the one they don't resemble.
So it would be too risky to bump this to the upcoming omnibus patchset,
but it's fine to apply this *before* the context document.

[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2024-May/328058.html
[2] https://ffmpeg.org/pipermail/ffmpeg-devel/2024-May/328087.html
___
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 v6 3/4] all: Link to "context" from all public contexts with documentation

[Andrew Sayers]

Note: I somehow managed to send this message directly to Anton before - sorry
Anton for the message spam, please reply to this one if you want the list to
see it!

On Wed, Jun 05, 2024 at 10:12:47AM +0200, Anton Khirnov wrote:
> Quoting Andrew Sayers (2024-06-04 16:47:23)
> > The goal of putting these links in "@see" blocks is to provide hooks
> > for future developers to add links to other useful parts of the codebase.
> > ---
> >  libavcodec/avcodec.h | 3 +++
> >  libavcodec/bsf.h | 3 +++
> >  libavcodec/d3d11va.h | 3 +++
> >  libavcodec/mediacodec.h  | 2 ++
> >  libavcodec/qsv.h | 3 +++
> >  libavcodec/vdpau.h   | 3 +++
> >  libavcodec/videotoolbox.h| 3 +++
> >  libavfilter/avfilter.h   | 7 ++-
> >  libavformat/avformat.h   | 3 +++
> >  libavformat/avio.h   | 3 +++
> >  libavutil/audio_fifo.h   | 3 +++
> >  libavutil/hwcontext.h| 6 ++
> >  libavutil/hwcontext_cuda.h   | 3 +++
> >  libavutil/hwcontext_d3d11va.h| 6 ++
> >  libavutil/hwcontext_d3d12va.h| 6 ++
> >  libavutil/hwcontext_drm.h| 3 +++
> >  libavutil/hwcontext_dxva2.h  | 6 ++
> >  libavutil/hwcontext_mediacodec.h | 3 +++
> >  libavutil/hwcontext_opencl.h | 6 ++
> >  libavutil/hwcontext_qsv.h| 6 ++
> >  libavutil/hwcontext_vaapi.h  | 6 ++
> >  libavutil/hwcontext_vdpau.h  | 3 +++
> >  libavutil/hwcontext_vulkan.h | 6 ++
> >  libavutil/lfg.h  | 3 +++
> >  24 files changed, 98 insertions(+), 1 deletion(-)
> 
> IMO this is pointless churn.

That's like saying caches are pointless bloat - it's not about correctness,
it's about performance.  Actually, I've been talking about "performance" a lot
round here, but not really explained what I mean...

Imagine a smart young developer who learned C at university and is now dipping
their toe in the world of actual C development.  They've come up with an idea
for a little app that's different enough from the examples to force themselves
not to just copy/paste example code.  It's simple enough that an experienced
developer like you would only need half a day for the whole project, so they
allow themselves a weekend to get it done.   "Performance" in this case means
"can they finish the project in their ~16 hour time budget?"

Assuming they're half as productive as you would be, 8 of their 16 hours go on
programming, leaving 8 hours to learn FFmpeg.

They've never written real-world C before, so they don't know what a context is.
And they only have a narrow understanding of OOP, so as soon as they see words
like "object" and "class", they assume you're referring to the precise version
of OOP their Java lecturer taught them about.  So the longer they spend poking
round looking for information, the more misconceptions they're going to develop.
Even if we assume they find the context document after one hour of searching,
they fully understand the document with no reading time, and only need one
extra hour to unlearn the misconceptions they developed, that's still cost
a quarter of their remaining time budget.

To an expert, these links are unnecessary verbiage pointing to a document
that explains things that are blindingly obvious.  But to a newbie, they're
an important optimisation that can make the difference between finishing
a project or having to give up on FFmpeg altogether.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 3/4] aac: define a new profile for USAC

[Lynne via ffmpeg-devel]

On 05/06/2024 07:33, Andreas Rheinhardt wrote:

Lynne via ffmpeg-devel:

This allows users to determine whether a stream is USAC or not.
---
  libavcodec/aac/aacdec_usac.c | 4 
  libavcodec/avcodec.h | 1 +
  libavcodec/defs.h| 1 +
  libavcodec/profiles.c| 1 +
  libavcodec/profiles.h| 1 +
  5 files changed, 8 insertions(+)

diff --git a/libavcodec/aac/aacdec_usac.c b/libavcodec/aac/aacdec_usac.c
index 7b36b49d63..5c3bb8d4ac 100644
--- a/libavcodec/aac/aacdec_usac.c
+++ b/libavcodec/aac/aacdec_usac.c
@@ -494,6 +494,8 @@ int ff_aac_usac_config_decode(AACDecContext *ac, 
AVCodecContext *avctx,
  }
  }
  
+ac->avctx->profile = AV_PROFILE_AAC_USAC;

+
  ret = ff_aac_usac_reset_state(ac, oc);
  if (ret < 0)
  return ret;
@@ -1533,6 +1535,8 @@ int ff_aac_usac_decode_frame(AVCodecContext *avctx, 
AACDecContext *ac,
  ff_aac_output_configure(ac, ac->oc[1].layout_map, 
ac->oc[1].layout_map_tags,
  ac->oc[1].status, 0);
  
+ac->avctx->profile = AV_PROFILE_AAC_USAC;

+
  indep_flag = get_bits1(gb);
  
  nb_ch_el = 0;

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 2da63c87ea..257e04fe2d 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1652,6 +1652,7 @@ typedef struct AVCodecContext {
  #define FF_PROFILE_AAC_HE_V2 28
  #define FF_PROFILE_AAC_LD   22
  #define FF_PROFILE_AAC_ELD  38
+#define FF_PROFILE_AAC_USAC 41


Don't add new deprecated defines.


Didn't notice. Removed locally.



OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


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

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

[FFmpeg-devel] [PATCH] aacdec: increase MAX_ELEM_ID to 64

[Lynne via ffmpeg-devel]

In USAC, we set the max to 64.
---
 libavcodec/aac.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/aac.h b/libavcodec/aac.h
index 9508760fa6..fc6d1361b2 100644
--- a/libavcodec/aac.h
+++ b/libavcodec/aac.h
@@ -31,7 +31,7 @@
 #define AVCODEC_AAC_H
 
 #define MAX_CHANNELS 64
-#define MAX_ELEM_ID 16
+#define MAX_ELEM_ID 64
 
 #define TNS_MAX_ORDER 20
 #define MAX_LTP_LONG_SFB 40
-- 
2.43.0.381.gb435a96ce8
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] lavu/opt: Mention that AVOptions is not reentrant

[Andrew Sayers]

An external API developer might think they can use AVOptions to modify values
during playback (e.g. putting a playback quality slider next to the volume
slider).  Make it clear that behaviour is not recommended.

Include the warning in the group description and the text for every function
that sets options, but leave it implicit in functions that get options.
This reflects the fact that *modifying* options is likely to cause weird bugs,
while *reading* options isn't guaranteed but is likely to be safe.
---
 libavutil/opt.h | 30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/libavutil/opt.h b/libavutil/opt.h
index 07e27a9208..13292c6473 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -53,11 +53,16 @@
  * question is allowed to access the field. This allows us to extend the
  * semantics of those fields without breaking API compatibility.
  *
+ * Note that AVOptions functions are not reentrant, and options may be accessed
+ * from internal FFmpeg threads.  Unless otherwise noted, it is best to avoid
+ * modifying options once a struct has been initialized.
+ *
  * @section avoptions_scope Scope of AVOptions
  *
  * AVOptions is designed to support any set of multimedia configuration options
- * that can be defined at compile-time.  Although it is mainly used to expose
- * FFmpeg options, you are welcome to adapt it to your own use case.
+ * that can be defined at compile-time and set at object creation time.  
Although
+ * it is mainly used to expose FFmpeg options, you are welcome to adapt it
+ * to your own use case.
  *
  * No single approach can ever fully solve the problem of configuration,
  * but please submit a patch if you believe you have found a problem
@@ -483,6 +488,9 @@ typedef struct AVOptionRanges {
 /**
  * Set the values of all AVOption fields to their default values.
  *
+ * Note: like all AVOptions functions, this is not reentrant.  Unless
+ * otherwise noted, it should only be used before initializing the struct.
+ *
  * @param s an AVOption-enabled struct (its first member must be a pointer to 
AVClass)
  */
 void av_opt_set_defaults(void *s);
@@ -492,6 +500,9 @@ void av_opt_set_defaults(void *s);
  * AVOption fields for which (opt->flags & mask) == flags will have their
  * default applied to s.
  *
+ * Note: like all AVOptions functions, this is not reentrant.  Unless
+ * otherwise noted, it should only be used before initializing the struct.
+ *
  * @param s an AVOption-enabled struct (its first member must be a pointer to 
AVClass)
  * @param mask combination of AV_OPT_FLAG_*
  * @param flags combination of AV_OPT_FLAG_*
@@ -661,6 +672,9 @@ enum {
  * key. ctx must be an AVClass context, storing is done using
  * AVOptions.
  *
+ * Note: like all AVOptions functions, this is not reentrant.  Unless
+ * otherwise noted, it should only be used before initializing the struct.
+ *
  * @param opts options string to parse, may be NULL
  * @param key_val_sep a 0-terminated list of characters used to
  * separate key from value
@@ -679,6 +693,9 @@ int av_set_options_string(void *ctx, const char *opts,
  * Parse the key-value pairs list in opts. For each key=value pair found,
  * set the value of the corresponding option in ctx.
  *
+ * Note: like all AVOptions functions, this is not reentrant.  Unless
+ * otherwise noted, it should only be used before initializing the struct.
+ *
  * @param ctx  the AVClass object to set options on
  * @param opts the options string, key-value pairs separated by a
  * delimiter
@@ -709,6 +726,9 @@ int av_opt_set_from_string(void *ctx, const char *opts,
 /**
  * Set all the options from a given dictionary on an object.
  *
+ * Note: like all AVOptions functions, this is not reentrant.  Unless
+ * otherwise noted, it should only be used before initializing the struct.
+ *
  * @param obj a struct whose first element is a pointer to AVClass
  * @param options options to process. This dictionary will be freed and 
replaced
  *by a new one containing all options not found in obj.
@@ -726,6 +746,9 @@ int av_opt_set_dict(void *obj, struct AVDictionary 
**options);
 /**
  * Set all the options from a given dictionary on an object.
  *
+ * Note: like all AVOptions functions, this is not reentrant.  Unless
+ * otherwise noted, it should only be used before initializing the struct.
+ *
  * @param obj a struct whose first element is a pointer to AVClass
  * @param options options to process. This dictionary will be freed and 
replaced
  *by a new one containing all options not found in obj.
@@ -764,6 +787,9 @@ int av_opt_copy(void *dest, const void *src);
  * @{
  * Those functions set the field of obj with the given name to value.
  *
+ * Note: like all AVOptions functions, these are not reentrant.  Unless
+ * otherwise noted, they should only be used before initializing the struct.
+ *
  * @param[in] obj A struct whose first element is a pointer to 

Re: [FFmpeg-devel] [PATCH v6] avcodec: add farbfeld encoder

[Stefano Sabatini]

On date Wednesday 2024-06-05 13:14:01 +0200, Andreas Rheinhardt wrote:
> Stefano Sabatini:
[...]
> >> One does not need two checks as long as int is 32 bits (because then one
> >> can just perform the addition in 64bits).
> > 
> > sizeof(int) is not defined by the C standard, so you cannot assume it
> > is 32 bits (even if on most platforms/compilers it will be)
> > 
> 

> Did you even read the following? It handles the case where simply using
> 64bits is not enough.

Yes, but there is no need to mix types, introduce ifdeffery and make
more assumptions when there is a simpler solution, please let's stick
at that.
 
> >> Just use the following (#if
> >> has been used because compilers have a tendency to emit warnings if a
> >> particular check is tautologically false):
> >>
> >> #if INT_MAX > INT64_MAX - HEADER_SIZE
> >> if (raw_img_size > INT64_MAX - HEADER_SIZE)
> >> return AVERROR(ERANGE);
> >> #endif
___
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 v6] avcodec: add farbfeld encoder

[Andreas Rheinhardt]

Stefano Sabatini:
> On date Wednesday 2024-06-05 13:14:01 +0200, Andreas Rheinhardt wrote:
>> Stefano Sabatini:
> [...]
 One does not need two checks as long as int is 32 bits (because then one
 can just perform the addition in 64bits).
>>>
>>> sizeof(int) is not defined by the C standard, so you cannot assume it
>>> is 32 bits (even if on most platforms/compilers it will be)
>>>
>>
> 
>> Did you even read the following? It handles the case where simply using
>> 64bits is not enough.
> 
> Yes, but there is no need to mix types, introduce ifdeffery and make
> more assumptions when there is a simpler solution, please let's stick
> at that.
>  

Your "simpler solution" adds a (mostly) avoidable branch.

 Just use the following (#if
 has been used because compilers have a tendency to emit warnings if a
 particular check is tautologically false):

 #if INT_MAX > INT64_MAX - HEADER_SIZE
 if (raw_img_size > INT64_MAX - HEADER_SIZE)
 return AVERROR(ERANGE);
 #endif

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

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

Re: [FFmpeg-devel] [PATCH] lavu/opt: Mention that AVOptions is not reentrant

[Paul B Mahol]

On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers 
wrote:

> An external API developer might think they can use AVOptions to modify
> values
> during playback (e.g. putting a playback quality slider next to the volume
> slider).  Make it clear that behaviour is not recommended.
>

There are options that can be changed at runtime,
And it works just fine.


>
> Include the warning in the group description and the text for every
> function
> that sets options, but leave it implicit in functions that get options.
> This reflects the fact that *modifying* options is likely to cause weird
> bugs,
> while *reading* options isn't guaranteed but is likely to be safe.
> ---
>  libavutil/opt.h | 30 --
>  1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/opt.h b/libavutil/opt.h
> index 07e27a9208..13292c6473 100644
> --- a/libavutil/opt.h
> +++ b/libavutil/opt.h
> @@ -53,11 +53,16 @@
>   * question is allowed to access the field. This allows us to extend the
>   * semantics of those fields without breaking API compatibility.
>   *
> + * Note that AVOptions functions are not reentrant, and options may be
> accessed
> + * from internal FFmpeg threads.  Unless otherwise noted, it is best to
> avoid
> + * modifying options once a struct has been initialized.
> + *
>   * @section avoptions_scope Scope of AVOptions
>   *
>   * AVOptions is designed to support any set of multimedia configuration
> options
> - * that can be defined at compile-time.  Although it is mainly used to
> expose
> - * FFmpeg options, you are welcome to adapt it to your own use case.
> + * that can be defined at compile-time and set at object creation time.
> Although
> + * it is mainly used to expose FFmpeg options, you are welcome to adapt it
> + * to your own use case.
>   *
>   * No single approach can ever fully solve the problem of configuration,
>   * but please submit a patch if you believe you have found a problem
> @@ -483,6 +488,9 @@ typedef struct AVOptionRanges {
>  /**
>   * Set the values of all AVOption fields to their default values.
>   *
> + * Note: like all AVOptions functions, this is not reentrant.  Unless
> + * otherwise noted, it should only be used before initializing the struct.
> + *
>   * @param s an AVOption-enabled struct (its first member must be a
> pointer to AVClass)
>   */
>  void av_opt_set_defaults(void *s);
> @@ -492,6 +500,9 @@ void av_opt_set_defaults(void *s);
>   * AVOption fields for which (opt->flags & mask) == flags will have their
>   * default applied to s.
>   *
> + * Note: like all AVOptions functions, this is not reentrant.  Unless
> + * otherwise noted, it should only be used before initializing the struct.
> + *
>   * @param s an AVOption-enabled struct (its first member must be a
> pointer to AVClass)
>   * @param mask combination of AV_OPT_FLAG_*
>   * @param flags combination of AV_OPT_FLAG_*
> @@ -661,6 +672,9 @@ enum {
>   * key. ctx must be an AVClass context, storing is done using
>   * AVOptions.
>   *
> + * Note: like all AVOptions functions, this is not reentrant.  Unless
> + * otherwise noted, it should only be used before initializing the struct.
> + *
>   * @param opts options string to parse, may be NULL
>   * @param key_val_sep a 0-terminated list of characters used to
>   * separate key from value
> @@ -679,6 +693,9 @@ int av_set_options_string(void *ctx, const char *opts,
>   * Parse the key-value pairs list in opts. For each key=value pair found,
>   * set the value of the corresponding option in ctx.
>   *
> + * Note: like all AVOptions functions, this is not reentrant.  Unless
> + * otherwise noted, it should only be used before initializing the struct.
> + *
>   * @param ctx  the AVClass object to set options on
>   * @param opts the options string, key-value pairs separated by a
>   * delimiter
> @@ -709,6 +726,9 @@ int av_opt_set_from_string(void *ctx, const char *opts,
>  /**
>   * Set all the options from a given dictionary on an object.
>   *
> + * Note: like all AVOptions functions, this is not reentrant.  Unless
> + * otherwise noted, it should only be used before initializing the struct.
> + *
>   * @param obj a struct whose first element is a pointer to AVClass
>   * @param options options to process. This dictionary will be freed and
> replaced
>   *by a new one containing all options not found in obj.
> @@ -726,6 +746,9 @@ int av_opt_set_dict(void *obj, struct AVDictionary
> **options);
>  /**
>   * Set all the options from a given dictionary on an object.
>   *
> + * Note: like all AVOptions functions, this is not reentrant.  Unless
> + * otherwise noted, it should only be used before initializing the struct.
> + *
>   * @param obj a struct whose first element is a pointer to AVClass
>   * @param options options to process. This dictionary will be freed and
> replaced
>   *by a new one containing all options not found in obj.
> @@ -764,6 +787,9 @@ int a

Re: [FFmpeg-devel] [RFC] STF 2025

[Paul B Mahol]

On Wed, Jun 5, 2024 at 11:31 AM Rémi Denis-Courmont  wrote:

>
>
> Le 5 juin 2024 12:18:57 GMT+03:00, "Rémi Denis-Courmont" 
> a écrit :
> >But by reacting *only* to Vittorio trying to defend himself and
> explicitly (and ineffectively) asking for help from the CC, you look like
> you are attacking the victim and defending the troll.
>
> I should have said "the one doing the trolling". But whatever, the CC is
> free to ban me for calling someone a troll.
>

I'm so devastated by you and others calling me a troll. I will remove
myself from this place of abyss immediately.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavu/opt: Mention that AVOptions is not reentrant

[Andrew Sayers]

On Wed, Jun 05, 2024 at 03:34:50PM +0200, Paul B Mahol wrote:
> On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers 
> wrote:
> 
> > An external API developer might think they can use AVOptions to modify
> > values
> > during playback (e.g. putting a playback quality slider next to the volume
> > slider).  Make it clear that behaviour is not recommended.
> >
> 
> There are options that can be changed at runtime,
> And it works just fine.

How would an external developer know which options can be safely changed
(preferably including in future versions of FFmpeg) vs. ones where their tests
got lucky and happened not to trigger a read during a non-atomic write?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavu/opt: Mention that AVOptions is not reentrant

[Ronald S. Bultje]

Hi,

On Wed, Jun 5, 2024 at 9:44 AM Andrew Sayers 
wrote:

> On Wed, Jun 05, 2024 at 03:34:50PM +0200, Paul B Mahol wrote:
> > On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers <
> ffmpeg-de...@pileofstuff.org>
> > wrote:
> >
> > > An external API developer might think they can use AVOptions to modify
> > > values
> > > during playback (e.g. putting a playback quality slider next to the
> volume
> > > slider).  Make it clear that behaviour is not recommended.
> > >
> >
> > There are options that can be changed at runtime,
> > And it works just fine.
>
> How would an external developer know which options can be safely changed
> (preferably including in future versions of FFmpeg) vs. ones where their
> tests
> got lucky and happened not to trigger a read during a non-atomic write?
>

If you see that happening, it would be good to submit a bug report. Right
now it's very abstract.

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

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

Re: [FFmpeg-devel] [PATCH v2 2/2] lavc/vvc: Prevent overflow in chroma QP derivation

[Nuo Mi]

Hi Frank,
Thank you for the patch

On Wed, Jun 5, 2024 at 5:24 PM Frank Plowman  wrote:

> On the top of p. 112 in VVC (09/2023):
>
> It is a requirement of bitstream conformance that the values of
> qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
> of −QpBdOffset to 63, inclusive for i in the range of 0 to
>
Then, why do we not check −QpBdOffset?

> numQpTables − 1, inclusive, and j in the range of 0 to
> sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.
>
> Signed-off-by: Frank Plowman 
> ---
>  libavcodec/vvc/ps.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
> index bfc3c121fd..c4f64d5da7 100644
> --- a/libavcodec/vvc/ps.c
> +++ b/libavcodec/vvc/ps.c
> @@ -101,9 +101,14 @@ static int sps_chroma_qp_table(VVCSPS *sps)
>
>  qp_out[0] = qp_in[0] = r->sps_qp_table_start_minus26[i] + 26;
>  for (int j = 0; j < num_points_in_qp_table; j++ ) {
> +const uint8_t delta_qp_out =
> (r->sps_delta_qp_in_val_minus1[i][j] ^ r->sps_delta_qp_diff_val[i][j]);
>  delta_qp_in[j] = r->sps_delta_qp_in_val_minus1[i][j] + 1;
> +if (qp_in[j] + delta_qp_in[j] > 63)
> +return AVERROR(EINVAL);
>  qp_in[j+1] = qp_in[j] + delta_qp_in[j];
> -qp_out[j+1] = qp_out[j] +
> (r->sps_delta_qp_in_val_minus1[i][j] ^ r->sps_delta_qp_diff_val[i][j]);
> +if (qp_out[j] + delta_qp_out > 63)
> +return AVERROR(EINVAL);
> +qp_out[j+1] = qp_out[j] + delta_qp_out;
>
Instead of changing so many lines, we can  add 2 lines here
if (qp_in[j+1] < 63 ||  qp_out[j+1] < 63)
return AVERROR(EINVAL);

>  }
>  sps->chroma_qp_table[i][qp_in[0] + off] = qp_out[0];
>  for (int k = qp_in[0] - 1 + off; k >= 0; k--)
> --
> 2.45.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavu/opt: Mention that AVOptions is not reentrant

[Paul B Mahol]

On Wed, Jun 5, 2024 at 3:44 PM Andrew Sayers 
wrote:

> On Wed, Jun 05, 2024 at 03:34:50PM +0200, Paul B Mahol wrote:
> > On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers <
> ffmpeg-de...@pileofstuff.org>
> > wrote:
> >
> > > An external API developer might think they can use AVOptions to modify
> > > values
> > > during playback (e.g. putting a playback quality slider next to the
> volume
> > > slider).  Make it clear that behaviour is not recommended.
> > >
> >
> > There are options that can be changed at runtime,
> > And it works just fine.
>
> How would an external developer know which options can be safely changed
> (preferably including in future versions of FFmpeg) vs. ones where their
> tests
> got lucky and happened not to trigger a read during a non-atomic write?
>

See this flag:

#define AV_OPT_FLAG_RUNTIME_PARAM   (1 << 15)

What is the point/gain in changing options from multiple threads
concurrently?



> ___
> 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 v2 1/2] lavc/vvc: Use sps_chroma_qp_table return code

[Nuo Mi]

this code is simple, you can combine it with the next one

On Wed, Jun 5, 2024 at 5:24 PM Frank Plowman  wrote:

> Signed-off-by: Frank Plowman 
> ---
>  libavcodec/vvc/ps.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
> index 1b23675c98..bfc3c121fd 100644
> --- a/libavcodec/vvc/ps.c
> +++ b/libavcodec/vvc/ps.c
> @@ -186,8 +186,11 @@ static int sps_derive(VVCSPS *sps, void *log_ctx)
>  sps_inter(sps);
>  sps_partition_constraints(sps);
>  sps_ladf(sps);
> -if (r->sps_chroma_format_idc != 0)
> -sps_chroma_qp_table(sps);
> +if (r->sps_chroma_format_idc != 0) {
> +ret = sps_chroma_qp_table(sps);
> +if (ret < 0)
> +return ret;
> +}
>
>  return 0;
>  }
> --
> 2.45.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavu/opt: Mention that AVOptions is not reentrant

[Andrew Sayers]

On Wed, Jun 05, 2024 at 09:46:16AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Jun 5, 2024 at 9:44 AM Andrew Sayers 
> wrote:
> 
> > On Wed, Jun 05, 2024 at 03:34:50PM +0200, Paul B Mahol wrote:
> > > On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers <
> > ffmpeg-de...@pileofstuff.org>
> > > wrote:
> > >
> > > > An external API developer might think they can use AVOptions to modify
> > > > values
> > > > during playback (e.g. putting a playback quality slider next to the
> > volume
> > > > slider).  Make it clear that behaviour is not recommended.
> > > >
> > >
> > > There are options that can be changed at runtime,
> > > And it works just fine.
> >
> > How would an external developer know which options can be safely changed
> > (preferably including in future versions of FFmpeg) vs. ones where their
> > tests
> > got lucky and happened not to trigger a read during a non-atomic write?
> >
> 
> If you see that happening, it would be good to submit a bug report. Right
> now it's very abstract.

I think we might be talking past each other - here's a concrete example:

The private struct "SetTSContext" includes an AVOptions-accessible member
"time_base", currently implemented as an AVRational (i.e. a pair of ints).
write_number() in libavutil/opt.c sets options of type AV_OPT_TYPE_RATIONAL
in such a way that a poorly-timed read could see the new numerator
and old denominator (or the other way around).

If I wrote a program that let users dynamically change the time base,
and someone switched their timebase from 1/30 to 100/3000, one unlucky user
might have a few frames encoded with a timebase of 100/30.  Is that something
the AVOptions API is supposed to support?  If yes, the bug is that
AVOptions access isn't guarded by a mutex.  If no, there's no bug, just an
edge case worth mentioning in the docs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/5] checkasm/sw_rgb: test rgb24 to yuv

[James Almer]

On 6/4/2024 11:06 AM, Zhao Zhili wrote:




On Jun 4, 2024, at 21:58, James Almer  wrote:

On 6/4/2024 10:55 AM, Zhao Zhili wrote:

From: Zhao Zhili 
---
  tests/checkasm/sw_rgb.c | 103 
  1 file changed, 103 insertions(+)
diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index 7cd815e5be..cc9b957461 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -24,6 +24,8 @@
  #include "libavutil/mem_internal.h"
#include "libswscale/rgb2rgb.h"
+#include "libswscale/swscale.h"
+#include "libswscale/swscale_internal.h"
#include "checkasm.h"
  @@ -179,8 +181,89 @@ static void check_interleave_bytes(void)
  }
  }
  +#define MAX_LINE_SIZE 1920
+
+static void check_rgb_to_y(struct SwsContext *ctx)
+{
+static const int input_sizes[] = {8, 128, 1280, 1080, MAX_LINE_SIZE};
+
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, dst0_y, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst1_y, [MAX_LINE_SIZE * 2]);
+
+declare_func(void, uint8_t *dst, const uint8_t *src,
+ const uint8_t *unused1, const uint8_t *unused2, int width,
+ uint32_t *rgb2yuv, void *opq);
+
+randomize_buffers(src, MAX_LINE_SIZE * 3);
+
+for (int i = 0; i < FF_ARRAY_ELEMS(input_sizes); i++) {
+int w = input_sizes[i];
+
+if (check_func(ctx->lumToYV12, "rgb24_to_y_%d", w)) {
+memset(dst0_y, 0xFA, MAX_LINE_SIZE * 2);
+memset(dst1_y, 0xFA, MAX_LINE_SIZE * 2);
+
+call_ref(dst0_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table, 
NULL);
+call_new(dst1_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table, 
NULL);
+
+if (memcmp(dst0_y, dst1_y, w * 2))
+fail();
+
+bench_new(dst1_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table, 
NULL);
+}
+}
+}
+
+static void check_rgb_to_uv(struct SwsContext *ctx)
+{
+static const int input_sizes[] = {8, 128, 1280, 1080, MAX_LINE_SIZE};
+
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, dst0_u, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst0_v, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst1_u, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst1_v, [MAX_LINE_SIZE * 2]);
+
+declare_func(void, uint8_t *dstU, uint8_t *dstV,
+ const uint8_t *src1, const uint8_t *src2, const uint8_t *src3,
+ int width, uint32_t *pal, void *opq);
+
+randomize_buffers(src, MAX_LINE_SIZE * 3);
+
+for (int i = 0; i < 2; i++) {
+ctx->chrSrcHSubSample = i ? 1 : 0;
+ctx->srcFormat = AV_PIX_FMT_RGB24;
+ctx->dstFormat = i ? AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUV444P;
+ff_sws_init_scale(ctx);
+
+for (int j = 0; j < FF_ARRAY_ELEMS(input_sizes); j++) {
+int w = input_sizes[j] >> i;
+
+if (check_func(ctx->chrToYV12, "rgb24_to_uv%s_%d", i ? "_half" : 
"", w)) {
+memset(dst0_u, 0xFF, MAX_LINE_SIZE * 2);
+memset(dst0_v, 0xFF, MAX_LINE_SIZE * 2);
+memset(dst1_u, 0xFF, MAX_LINE_SIZE * 2);
+memset(dst1_v, 0xFF, MAX_LINE_SIZE * 2);
+
+call_ref(dst0_u, dst0_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+call_new(dst1_u, dst1_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+
+if (memcmp(dst0_u, dst1_u, w * 2) || memcmp(dst0_v, dst1_v, w 
* 2))
+fail();
+
+bench_new(dst1_u, dst1_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+}
+}
+}
+}
+
  void checkasm_check_sw_rgb(void)
  {
+struct SwsContext *ctx;
+int *inv_table, *table;
+int in_full, out_full, brightness, contrast, saturation;
+
  ff_sws_rgb2rgb_init();
check_shuffle_bytes(shuffle_bytes_2103, "shuffle_bytes_2103");
@@ -203,4 +286,24 @@ void checkasm_check_sw_rgb(void)
check_interleave_bytes();
  report("interleave_bytes");
+
+ctx = sws_getContext(MAX_LINE_SIZE, MAX_LINE_SIZE, AV_PIX_FMT_RGB24,
+ MAX_LINE_SIZE, MAX_LINE_SIZE, AV_PIX_FMT_YUV420P,
+ SWS_ACCURATE_RND | SWS_BITEXACT, NULL, NULL, NULL);
+if (!ctx)
+fail();
+
+sws_getColorspaceDetails(ctx, &inv_table, &in_full,
+ &table, &out_full,
+ &brightness, &contrast, &saturation);
+sws_setColorspaceDetails(ctx, inv_table, in_full,
+ table, out_full,
+ brightness, contrast, saturation);


Isn't this pointless? It looks like you're setting the context with values 
taken from the same context.


Yes, will remove in next version.


Will you send a new version with other changes, or just this? If the 
latter, i can amend it and push it now.

___
ffmpeg-devel mailing list
f

Re: [FFmpeg-devel] [PATCH 1/5] checkasm/sw_rgb: test rgb24 to yuv

[Rémi Denis-Courmont]

Le tiistaina 4. kesäkuuta 2024, 16.55.00 EEST Zhao Zhili a écrit :
> From: Zhao Zhili 
> 
> ---
>  tests/checkasm/sw_rgb.c | 103 
>  1 file changed, 103 insertions(+)
> 
> diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
> index 7cd815e5be..cc9b957461 100644
> --- a/tests/checkasm/sw_rgb.c
> +++ b/tests/checkasm/sw_rgb.c
> @@ -24,6 +24,8 @@
>  #include "libavutil/mem_internal.h"
> 
>  #include "libswscale/rgb2rgb.h"
> +#include "libswscale/swscale.h"
> +#include "libswscale/swscale_internal.h"
> 
>  #include "checkasm.h"
> 
> @@ -179,8 +181,89 @@ static void check_interleave_bytes(void)
>  }
>  }
> 
> +#define MAX_LINE_SIZE 1920
> +
> +static void check_rgb_to_y(struct SwsContext *ctx)
> +{
> +static const int input_sizes[] = {8, 128, 1280, 1080, MAX_LINE_SIZE};
> +
> +LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
> +LOCAL_ALIGNED_32(uint8_t, dst0_y, [MAX_LINE_SIZE * 2]);
> +LOCAL_ALIGNED_32(uint8_t, dst1_y, [MAX_LINE_SIZE * 2]);
> +
> +declare_func(void, uint8_t *dst, const uint8_t *src,
> + const uint8_t *unused1, const uint8_t *unused2, int width,
> + uint32_t *rgb2yuv, void *opq);
> +
> +randomize_buffers(src, MAX_LINE_SIZE * 3);
> +
> +for (int i = 0; i < FF_ARRAY_ELEMS(input_sizes); i++) {
> +int w = input_sizes[i];
> +
> +if (check_func(ctx->lumToYV12, "rgb24_to_y_%d", w)) {
> +memset(dst0_y, 0xFA, MAX_LINE_SIZE * 2);
> +memset(dst1_y, 0xFA, MAX_LINE_SIZE * 2);
> +
> +call_ref(dst0_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table,
> NULL); +call_new(dst1_y, src, NULL, NULL, w,
> ctx->input_rgb2yuv_table, NULL); +
> +if (memcmp(dst0_y, dst1_y, w * 2))
> +fail();
> +
> +bench_new(dst1_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table,
> NULL); +}
> +}
> +}
> +
> +static void check_rgb_to_uv(struct SwsContext *ctx)
> +{
> +static const int input_sizes[] = {8, 128, 1280, 1080, MAX_LINE_SIZE};
> +
> +LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
> +LOCAL_ALIGNED_32(uint8_t, dst0_u, [MAX_LINE_SIZE * 2]);
> +LOCAL_ALIGNED_32(uint8_t, dst0_v, [MAX_LINE_SIZE * 2]);
> +LOCAL_ALIGNED_32(uint8_t, dst1_u, [MAX_LINE_SIZE * 2]);
> +LOCAL_ALIGNED_32(uint8_t, dst1_v, [MAX_LINE_SIZE * 2]);
> +
> +declare_func(void, uint8_t *dstU, uint8_t *dstV,
> + const uint8_t *src1, const uint8_t *src2, const uint8_t
> *src3, + int width, uint32_t *pal, void *opq);
> +
> +randomize_buffers(src, MAX_LINE_SIZE * 3);
> +
> +for (int i = 0; i < 2; i++) {
> +ctx->chrSrcHSubSample = i ? 1 : 0;
> +ctx->srcFormat = AV_PIX_FMT_RGB24;
> +ctx->dstFormat = i ? AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUV444P;
> +ff_sws_init_scale(ctx);

Given the loop is there, wouldn't it be trivial to also test BGR24 ? (maybe 
skipping benchmarks)

> +
> +for (int j = 0; j < FF_ARRAY_ELEMS(input_sizes); j++) {
> +int w = input_sizes[j] >> i;
> +
> +if (check_func(ctx->chrToYV12, "rgb24_to_uv%s_%d", i ? "_half"
> : "", w)) { +memset(dst0_u, 0xFF, MAX_LINE_SIZE * 2);
> +memset(dst0_v, 0xFF, MAX_LINE_SIZE * 2);
> +memset(dst1_u, 0xFF, MAX_LINE_SIZE * 2);
> +memset(dst1_v, 0xFF, MAX_LINE_SIZE * 2);
> +
> +call_ref(dst0_u, dst0_v, NULL, src, src, w,
> ctx->input_rgb2yuv_table, NULL); +call_new(dst1_u, dst1_v,
> NULL, src, src, w, ctx->input_rgb2yuv_table, NULL); +
> +if (memcmp(dst0_u, dst1_u, w * 2) || memcmp(dst0_v, dst1_v,
> w * 2)) +fail();
> +
> +bench_new(dst1_u, dst1_v, NULL, src, src, w,
> ctx->input_rgb2yuv_table, NULL); +}
> +}
> +}
> +}
> +
>  void checkasm_check_sw_rgb(void)
>  {
> +struct SwsContext *ctx;
> +int *inv_table, *table;
> +int in_full, out_full, brightness, contrast, saturation;
> +
>  ff_sws_rgb2rgb_init();
> 
>  check_shuffle_bytes(shuffle_bytes_2103, "shuffle_bytes_2103");
> @@ -203,4 +286,24 @@ void checkasm_check_sw_rgb(void)
> 
>  check_interleave_bytes();
>  report("interleave_bytes");
> +
> +ctx = sws_getContext(MAX_LINE_SIZE, MAX_LINE_SIZE, AV_PIX_FMT_RGB24,
> + MAX_LINE_SIZE, MAX_LINE_SIZE, AV_PIX_FMT_YUV420P,
> + SWS_ACCURATE_RND | SWS_BITEXACT, NULL, NULL,
> NULL); +if (!ctx)
> +fail();
> +
> +sws_getColorspaceDetails(ctx, &inv_table, &in_full,
> + &table, &out_full,
> + &brightness, &contrast, &saturation);
> +sws_setColorspaceDetails(ctx, inv_table, in_full,
> + table, out_full,
> + brightness, contrast, saturation);
> +check_rgb_to_y(ctx);
> +report("rgb_to_y");
> +
> +chec

Re: [FFmpeg-devel] [PATCH 1/4] mpeg4audio: rename AOT_USAC_NOSBR to AOT_USAC

[James Almer]

On 6/5/2024 12:08 AM, Lynne via ffmpeg-devel wrote:

The issue is that AOT 45 isn't defined anywhere, and looking at the git
blame, it seems to have sprung up through a reordering of the enum,
and adding a hole.

The spec does not define an explicit AOT for SBR and no SBR, and only
uses AOT 42 (previously AOT_USAC_NOSBR), so just rename AOT_USAC to
it and replace its use everywhere.
---
  libavcodec/aac/aacdec.c | 7 ++-
  libavcodec/mpeg4audio.h | 3 +--
  2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/libavcodec/aac/aacdec.c b/libavcodec/aac/aacdec.c
index 2b8322fc68..24d2bdde4c 100644
--- a/libavcodec/aac/aacdec.c
+++ b/libavcodec/aac/aacdec.c
@@ -1046,7 +1046,6 @@ static int decode_audio_specific_config_gb(AACDecContext 
*ac,
  return ret;
  break;
  #if CONFIG_AAC_DECODER
-case AOT_USAC_NOSBR: /* fallthrough */
  case AOT_USAC:
  if ((ret = ff_aac_usac_config_decode(ac, avctx, gb,
   oc, m4ac->chan_config)) < 0)
@@ -1571,8 +1570,7 @@ int ff_aac_decode_tns(AACDecContext *ac, 
TemporalNoiseShaping *tns,
GetBitContext *gb, const IndividualChannelStream *ics)
  {
  int tns_max_order = INT32_MAX;
-const int is_usac = ac->oc[1].m4ac.object_type == AOT_USAC ||
-ac->oc[1].m4ac.object_type == AOT_USAC_NOSBR;
+const int is_usac = ac->oc[1].m4ac.object_type == AOT_USAC;
  int w, filt, i, coef_len, coef_res, coef_compress;
  const int is8 = ics->window_sequence[0] == EIGHT_SHORT_SEQUENCE;
  
@@ -2421,8 +2419,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx, AVFrame *frame,
  
  ac->tags_mapped = 0;
  
-if ((ac->oc[1].m4ac.object_type == AOT_USAC) ||

-(ac->oc[1].m4ac.object_type == AOT_USAC_NOSBR)) {
+if (ac->oc[1].m4ac.object_type == AOT_USAC) {
  if (ac->is_fixed) {
  avpriv_report_missing_feature(ac->avctx,
"AAC USAC fixed-point decoding");
diff --git a/libavcodec/mpeg4audio.h b/libavcodec/mpeg4audio.h
index 56615ef321..5daba7824b 100644
--- a/libavcodec/mpeg4audio.h
+++ b/libavcodec/mpeg4audio.h
@@ -108,10 +108,9 @@ enum AudioObjectType {
  AOT_ER_AAC_ELD,///< N   Error Resilient 
Enhanced Low Delay
  AOT_SMR_SIMPLE,///< N   Symbolic Music 
Representation Simple
  AOT_SMR_MAIN,  ///< N   Symbolic Music 
Representation Main
-AOT_USAC_NOSBR,///< N   Unified Speech and 
Audio Coding (no SBR)
+AOT_USAC,  ///< Y   Unified Speech and 
Audio Coding
  AOT_SAOC,  ///< N   Spatial Audio 
Object Coding
  AOT_LD_SURROUND,   ///< N   Low Delay MPEG 
Surround
-AOT_USAC,  ///< N   Unified Speech and 
Audio Coding
  };
  
  #define MAX_PCE_SIZE 320 ///

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

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

Re: [FFmpeg-devel] [PATCH 2/4] mpeg4audio: explicitly define each AOT

[James Almer]

On 6/5/2024 12:08 AM, Lynne via ffmpeg-devel wrote:

This makes it far easier to figure out which AOT belongs to which
profile.
Also, explicitly highlight the holes.
---
  libavcodec/mpeg4audio.h | 82 +
  1 file changed, 42 insertions(+), 40 deletions(-)

diff --git a/libavcodec/mpeg4audio.h b/libavcodec/mpeg4audio.h
index 5daba7824b..0819e48a42 100644
--- a/libavcodec/mpeg4audio.h
+++ b/libavcodec/mpeg4audio.h
@@ -68,49 +68,51 @@ int avpriv_mpeg4audio_get_config2(MPEG4AudioConfig *c, 
const uint8_t *buf,
int size, int sync_extension, void *logctx);
  
  enum AudioObjectType {

-AOT_NULL,
+AOT_NULL = 0,
 // Support?Name
-AOT_AAC_MAIN,  ///< Y   Main
-AOT_AAC_LC,///< Y   Low Complexity
-AOT_AAC_SSR,   ///< N (code in SoC repo)Scalable Sample 
Rate
-AOT_AAC_LTP,   ///< Y   Long Term 
Prediction
-AOT_SBR,   ///< Y   Spectral Band 
Replication
-AOT_AAC_SCALABLE,  ///< N   Scalable
-AOT_TWINVQ,///< N   Twin Vector 
Quantizer
-AOT_CELP,  ///< N   Code Excited 
Linear Prediction
-AOT_HVXC,  ///< N   Harmonic Vector 
eXcitation Coding
+AOT_AAC_MAIN =  1, ///< Y   Main
+AOT_AAC_LC   =  2, ///< Y   Low Complexity
+AOT_AAC_SSR  =  3, ///< N (code in SoC repo)Scalable Sample 
Rate
+AOT_AAC_LTP  =  4, ///< Y   Long Term 
Prediction
+AOT_SBR  =  5, ///< Y   Spectral Band 
Replication
+AOT_AAC_SCALABLE =  6, ///< N   Scalable
+AOT_TWINVQ   =  7, ///< N   Twin Vector 
Quantizer
+AOT_CELP =  8, ///< N   Code Excited 
Linear Prediction
+AOT_HVXC =  9, ///< N   Harmonic Vector 
eXcitation Coding
+
  AOT_TTSI = 12, ///< N   Text-To-Speech 
Interface
-AOT_MAINSYNTH, ///< N   Main Synthesis
-AOT_WAVESYNTH, ///< N   Wavetable Synthesis
-AOT_MIDI,  ///< N   General MIDI
-AOT_SAFX,  ///< N   Algorithmic 
Synthesis and Audio Effects
-AOT_ER_AAC_LC, ///< N   Error Resilient 
Low Complexity
+AOT_MAINSYNTH= 13, ///< N   Main Synthesis
+AOT_WAVESYNTH= 14, ///< N   Wavetable Synthesis
+AOT_MIDI = 15, ///< N   General MIDI
+AOT_SAFX = 16, ///< N   Algorithmic 
Synthesis and Audio Effects
+AOT_ER_AAC_LC= 17, ///< N   Error Resilient 
Low Complexity
+
  AOT_ER_AAC_LTP   = 19, ///< N   Error Resilient 
Long Term Prediction
-AOT_ER_AAC_SCALABLE,   ///< N   Error Resilient 
Scalable
-AOT_ER_TWINVQ, ///< N   Error Resilient 
Twin Vector Quantizer
-AOT_ER_BSAC,   ///< N   Error Resilient 
Bit-Sliced Arithmetic Coding
-AOT_ER_AAC_LD, ///< N   Error Resilient 
Low Delay
-AOT_ER_CELP,   ///< N   Error Resilient 
Code Excited Linear Prediction
-AOT_ER_HVXC,   ///< N   Error Resilient 
Harmonic Vector eXcitation Coding
-AOT_ER_HILN,   ///< N   Error Resilient 
Harmonic and Individual Lines plus Noise
-AOT_ER_PARAM,  ///< N   Error Resilient 
Parametric
-AOT_SSC,   ///< N   SinuSoidal Coding
-AOT_PS,///< N   Parametric Stereo
-AOT_SURROUND,  ///< N   MPEG Surround
-AOT_ESCAPE,///< Y   Escape Value
-AOT_L1,///< Y   Layer 1
-AOT_L2,///< Y   Layer 2
-AOT_L3,///< Y   Layer 3
-AOT_DST,   ///< N   Direct Stream 
Transfer
-AOT_ALS,   ///< Y   Audio LosslesS
-AOT_SLS,   ///< N   Scalable LosslesS
-AOT_SLS_NON_CORE,  ///< N   Scalable LosslesS 
(non core)
-AOT_ER_AAC_ELD,///< N  

Re: [FFmpeg-devel] [PATCH 4/4] lavc: bump minor and add APIchanges entry for new USAC profile

[James Almer]

On 6/5/2024 12:08 AM, Lynne via ffmpeg-devel wrote:

---
  doc/APIchanges   | 3 +++
  libavcodec/version.h | 2 +-
  2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index e36a01336c..d9bec790a3 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07
  
  API changes, most recent first:
  
+2024-06-05 - xx - lavc 61.7.100 - avcodec.h, defs.h

+  Add FF_PROFILE_AAC_USAC and AV_PROFILE_AAC_USAC.


Don't forget to remove FF_PROFILE_AAC_USAC here as well (the the 
reference to its header).


LGTM aside from that.


+
  2024-06-02 - xx - lavu 59.21.100 - channel_layout.h
Add AV_CHAN_SIDE_SURROUND_RIGHT and AV_CH_SIDE_SURROUND_LEFT.
Add AV_CHAN_SIDE_SURROUND_RIGHT and AV_CH_SIDE_SURROUND_RIGHT.
diff --git a/libavcodec/version.h b/libavcodec/version.h
index da54f87887..7acb261bb3 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
  
  #include "version_major.h"
  
-#define LIBAVCODEC_VERSION_MINOR   6

+#define LIBAVCODEC_VERSION_MINOR   7
  #define LIBAVCODEC_VERSION_MICRO 100
  
  #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \

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

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

Re: [FFmpeg-devel] [PATCH 3/4] aac: define a new profile for USAC

[James Almer]

On 6/5/2024 12:08 AM, Lynne via ffmpeg-devel wrote:

This allows users to determine whether a stream is USAC or not.
---
  libavcodec/aac/aacdec_usac.c | 4 
  libavcodec/avcodec.h | 1 +
  libavcodec/defs.h| 1 +
  libavcodec/profiles.c| 1 +
  libavcodec/profiles.h| 1 +
  5 files changed, 8 insertions(+)

diff --git a/libavcodec/aac/aacdec_usac.c b/libavcodec/aac/aacdec_usac.c
index 7b36b49d63..5c3bb8d4ac 100644
--- a/libavcodec/aac/aacdec_usac.c
+++ b/libavcodec/aac/aacdec_usac.c
@@ -494,6 +494,8 @@ int ff_aac_usac_config_decode(AACDecContext *ac, 
AVCodecContext *avctx,
  }
  }
  
+ac->avctx->profile = AV_PROFILE_AAC_USAC;

+
  ret = ff_aac_usac_reset_state(ac, oc);
  if (ret < 0)
  return ret;
@@ -1533,6 +1535,8 @@ int ff_aac_usac_decode_frame(AVCodecContext *avctx, 
AACDecContext *ac,
  ff_aac_output_configure(ac, ac->oc[1].layout_map, 
ac->oc[1].layout_map_tags,
  ac->oc[1].status, 0);
  
+ac->avctx->profile = AV_PROFILE_AAC_USAC;

+
  indep_flag = get_bits1(gb);
  
  nb_ch_el = 0;

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 2da63c87ea..257e04fe2d 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1652,6 +1652,7 @@ typedef struct AVCodecContext {
  #define FF_PROFILE_AAC_HE_V2 28
  #define FF_PROFILE_AAC_LD   22
  #define FF_PROFILE_AAC_ELD  38
+#define FF_PROFILE_AAC_USAC 41
  #define FF_PROFILE_MPEG2_AAC_LOW 128
  #define FF_PROFILE_MPEG2_AAC_HE  131
  
diff --git a/libavcodec/defs.h b/libavcodec/defs.h

index 00d840ec19..7ddfdcad0b 100644
--- a/libavcodec/defs.h
+++ b/libavcodec/defs.h
@@ -73,6 +73,7 @@
  #define AV_PROFILE_AAC_HE_V2   28
  #define AV_PROFILE_AAC_LD  22
  #define AV_PROFILE_AAC_ELD 38
+#define AV_PROFILE_AAC_USAC41
  #define AV_PROFILE_MPEG2_AAC_LOW  128
  #define AV_PROFILE_MPEG2_AAC_HE   131
  
diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c

index 052b77926e..44bdf6f85b 100644
--- a/libavcodec/profiles.c
+++ b/libavcodec/profiles.c
@@ -33,6 +33,7 @@ const AVProfile ff_aac_profiles[] = {
  { AV_PROFILE_AAC_MAIN,  "Main" },
  { AV_PROFILE_AAC_SSR,   "SSR"  },
  { AV_PROFILE_AAC_LTP,   "LTP"  },
+{ AV_PROFILE_AAC_USAC,  "xHE-AAC" },
  { AV_PROFILE_UNKNOWN },
  };
  
diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h

index 842201718b..33b7ffc17a 100644
--- a/libavcodec/profiles.h
+++ b/libavcodec/profiles.h
@@ -35,6 +35,7 @@
  FF_AVCTX_PROFILE_OPTION("aac_he_v2", NULL, AUDIO, 
AV_PROFILE_AAC_HE_V2)\
  FF_AVCTX_PROFILE_OPTION("aac_ld",NULL, AUDIO, AV_PROFILE_AAC_LD)\
  FF_AVCTX_PROFILE_OPTION("aac_eld",   NULL, AUDIO, AV_PROFILE_AAC_ELD)\
+FF_AVCTX_PROFILE_OPTION("aac_xhe",   NULL, AUDIO, AV_PROFILE_AAC_USAC)\
  FF_AVCTX_PROFILE_OPTION("mpeg2_aac_low", NULL, AUDIO, 
AV_PROFILE_MPEG2_AAC_LOW)\
  FF_AVCTX_PROFILE_OPTION("mpeg2_aac_he",  NULL, AUDIO, 
AV_PROFILE_MPEG2_AAC_HE)\


Should be ok without FF_PROFILE_AAC_USAC.
___
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] [PATCHv3 1/3] sws/input: R-V V rgb24ToY & bgr24ToY

[Rémi Denis-Courmont]

T-Head C908:
rgb24_to_y_8_c:2.0
rgb24_to_y_8_rvv_i32:  2.7
rgb24_to_y_128_c: 26.2
rgb24_to_y_128_rvv_i32:9.2
rgb24_to_y_1080_c:   219.5
rgb24_to_y_1080_rvv_i32:  76.2
rgb24_to_y_1280_c:   276.2
rgb24_to_y_1280_rvv_i32:  89.7
rgb24_to_y_1920_c:   389.7
rgb24_to_y_1920_rvv_i32: 134.2

SpacemiT X60:
rgb24_to_y_8_c:1.7
rgb24_to_y_8_rvv_i32:  2.2
rgb24_to_y_128_c: 23.2
rgb24_to_y_128_rvv_i32:4.2
rgb24_to_y_1080_c:   195.0
rgb24_to_y_1080_rvv_i32:  33.7
rgb24_to_y_1280_c:   231.0
rgb24_to_y_1280_rvv_i32:  40.0
rgb24_to_y_1920_c:   346.2
rgb24_to_y_1920_rvv_i32:  59.7
---
 libswscale/riscv/Makefile |  6 ++--
 libswscale/riscv/input.S  | 55 +++
 libswscale/riscv/swscale.c| 46 +
 libswscale/swscale.c  |  2 ++
 libswscale/swscale_internal.h |  1 +
 5 files changed, 108 insertions(+), 2 deletions(-)
 create mode 100644 libswscale/riscv/input.S
 create mode 100644 libswscale/riscv/swscale.c

diff --git a/libswscale/riscv/Makefile b/libswscale/riscv/Makefile
index 48afaf62aa..d1b0eae367 100644
--- a/libswscale/riscv/Makefile
+++ b/libswscale/riscv/Makefile
@@ -1,3 +1,5 @@
-OBJS += riscv/rgb2rgb.o
+OBJS += riscv/rgb2rgb.o \
+riscv/swscale.o
 RV-OBJS += riscv/rgb2rgb_rvb.o
-RVV-OBJS += riscv/rgb2rgb_rvv.o
+RVV-OBJS += riscv/input.o \
+riscv/rgb2rgb_rvv.o
diff --git a/libswscale/riscv/input.S b/libswscale/riscv/input.S
new file mode 100644
index 00..323f650bc9
--- /dev/null
+++ b/libswscale/riscv/input.S
@@ -0,0 +1,55 @@
+/*
+ * Copyright © 2024 Rémi Denis-Courmont.
+ *
+ * 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 "libavutil/riscv/asm.S"
+
+func ff_bgr24ToY_rvv, zve32x
+lw  t1, 8(a5) # BY
+lw  t3, 0(a5) # RY
+j   1f
+endfunc
+
+func ff_rgb24ToY_rvv, zve32x
+lw  t1, 0(a5) # RY
+lw  t3, 8(a5) # BY
+1:
+lw  t2, 4(a5) # GY
+li  t4, (32 << (15 - 1)) + (1 << (15 - 7))
+2:
+vsetvlit0, a4, e32, m8, ta, ma
+vlseg3e8.v v0, (a1)
+suba4, a4, t0
+vzext.vf4  v8, v0
+sh1add t5, t0, t0 # t1 = 3 * t0
+vzext.vf4  v16, v2
+vzext.vf4  v24, v4
+adda1, t5, a1
+vmul.vxv8, v8, t1
+vmacc.vx   v8, t2, v16
+vmacc.vx   v8, t3, v24
+vadd.vxv8, v8, t4
+vsetvlizero, zero, e16, m4, ta, ma
+vnsra.wi   v0, v8, 15 - 6
+vse16.vv0, (a0)
+sh1add a0, t0, a0
+bnez   a4, 2b
+
+ret
+endfunc
diff --git a/libswscale/riscv/swscale.c b/libswscale/riscv/swscale.c
new file mode 100644
index 00..187b3fce58
--- /dev/null
+++ b/libswscale/riscv/swscale.c
@@ -0,0 +1,46 @@
+/*
+ * 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 "config.h"
+#include "libavutil/attributes.h"
+#include "libavutil/riscv/cpu.h"
+#include "libswscale/swscale_internal.h"
+
+void ff_bgr24ToY_rvv(uint8_t *dst, const uint8_t *src, const uint8_t *,
+ const uint8_t *, int width, uint32_t *coeffs, void *);
+void ff_rgb24ToY_rvv(uint8_t *dst, const uint8_t *src, const uint8_t *,
+ const uint8_t *, int width, uint32_t *coeffs, void *);
+
+av_cold void ff_sws_init_swscale_riscv(SwsContext *c)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
+switch (c->srcFormat) {

[FFmpeg-devel] [PATCH 2/3] sws/input: R-V V rgb24ToUV and bgr24ToUV

[Rémi Denis-Courmont]

T-Head C908:
rgb24_to_uv_8_c:2.7
rgb24_to_uv_8_rvv_i32:  3.2
rgb24_to_uv_128_c: 41.0
rgb24_to_uv_128_rvv_i32:   12.7
rgb24_to_uv_1080_c:   342.5
rgb24_to_uv_1080_rvv_i32: 105.7
rgb24_to_uv_1280_c:   406.0
rgb24_to_uv_1280_rvv_i32: 124.2
rgb24_to_uv_1920_c:   626.0
rgb24_to_uv_1920_rvv_i32: 186.0

SpacemiT X60:
rgb24_to_uv_8_c:2.5
rgb24_to_uv_8_rvv_i32:  3.0
rgb24_to_uv_128_c: 36.5
rgb24_to_uv_128_rvv_i32:5.7
rgb24_to_uv_1080_c:   304.2
rgb24_to_uv_1080_rvv_i32:  49.0
rgb24_to_uv_1280_c:   360.5
rgb24_to_uv_1280_rvv_i32:  57.5
rgb24_to_uv_1920_c:   540.7
rgb24_to_uv_1920_rvv_i32:  86.2
---
 libswscale/riscv/input.S   | 46 ++
 libswscale/riscv/swscale.c |  8 +++
 2 files changed, 54 insertions(+)

diff --git a/libswscale/riscv/input.S b/libswscale/riscv/input.S
index 323f650bc9..3392f189ca 100644
--- a/libswscale/riscv/input.S
+++ b/libswscale/riscv/input.S
@@ -53,3 +53,49 @@ func ff_rgb24ToY_rvv, zve32x
 
 ret
 endfunc
+
+func ff_bgr24ToUV_rvv, zve32x
+lw  t1, 20(a6) # BU
+lw  t4, 32(a6) # BV
+lw  t3, 12(a6) # RU
+lw  t6, 24(a6) # RV
+j   1f
+endfunc
+
+func ff_rgb24ToUV_rvv, zve32x
+lw  t1, 12(a6) # RU
+lw  t4, 24(a6) # RV
+lw  t3, 20(a6) # BU
+lw  t6, 32(a6) # BV
+1:
+lw  t2, 16(a6) # GU
+lw  t5, 28(a6) # GV
+li  a7, (256 << (15 - 1)) + (1 << (15 - 7))
+2:
+vsetvlit0, a5, e32, m8, ta, ma
+vlseg3e8.v v0, (a3)
+suba5, a5, t0
+vzext.vf4  v16, v0
+sh1add a6, t0, t0
+vzext.vf4  v24, v2
+vmul.vxv8, v16, t1
+adda3, a6, a3
+vmul.vxv16, v16, t4
+vmacc.vx   v8, t2, v24
+vmacc.vx   v16, t5, v24
+vzext.vf4  v24, v4
+vadd.vxv8, v8, a7
+vadd.vxv16, v16, a7
+vmacc.vx   v8, t3, v24
+vmacc.vx   v16, t6, v24
+vsetvlizero, zero, e16, m4, ta, ma
+vnsra.wi   v0, v8, 15 - 6
+vnsra.wi   v4, v16, 15 - 6
+vse16.vv0, (a0)
+sh1add a0, t0, a0
+vse16.vv4, (a1)
+sh1add a1, t0, a1
+bnez   a5, 2b
+
+ret
+endfunc
diff --git a/libswscale/riscv/swscale.c b/libswscale/riscv/swscale.c
index 187b3fce58..b3552976c6 100644
--- a/libswscale/riscv/swscale.c
+++ b/libswscale/riscv/swscale.c
@@ -23,8 +23,12 @@
 
 void ff_bgr24ToY_rvv(uint8_t *dst, const uint8_t *src, const uint8_t *,
  const uint8_t *, int width, uint32_t *coeffs, void *);
+void ff_bgr24ToUV_rvv(uint8_t *, uint8_t *, const uint8_t *, const uint8_t *,
+  const uint8_t *, int width, uint32_t *coeffs, void *);
 void ff_rgb24ToY_rvv(uint8_t *dst, const uint8_t *src, const uint8_t *,
  const uint8_t *, int width, uint32_t *coeffs, void *);
+void ff_rgb24ToUV_rvv(uint8_t *, uint8_t *, const uint8_t *, const uint8_t *,
+  const uint8_t *, int width, uint32_t *coeffs, void *);
 
 av_cold void ff_sws_init_swscale_riscv(SwsContext *c)
 {
@@ -35,10 +39,14 @@ av_cold void ff_sws_init_swscale_riscv(SwsContext *c)
 switch (c->srcFormat) {
 case AV_PIX_FMT_BGR24:
 c->lumToYV12 = ff_bgr24ToY_rvv;
+if (!c->chrSrcHSubSample)
+c->chrToYV12 = ff_bgr24ToUV_rvv;
 break;
 
 case AV_PIX_FMT_RGB24:
 c->lumToYV12 = ff_rgb24ToY_rvv;
+if (!c->chrSrcHSubSample)
+c->chrToYV12 = ff_rgb24ToUV_rvv;
 break;
 }
 }
-- 
2.45.1

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

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

[FFmpeg-devel] [PATCH 3/3] sws/input: R-V V rgb24ToUV_half and bgr24ToUV_half

[Rémi Denis-Courmont]

T-Head C908:
rgb24_to_uv_half_4_c:   2.0
rgb24_to_uv_half_4_rvv_i32: 3.5
rgb24_to_uv_half_64_c: 27.0
rgb24_to_uv_half_64_rvv_i32:   12.5
rgb24_to_uv_half_540_c:   223.7
rgb24_to_uv_half_540_rvv_i32: 105.2
rgb24_to_uv_half_640_c:   265.5
rgb24_to_uv_half_640_rvv_i32: 123.7
rgb24_to_uv_half_960_c:   414.5
rgb24_to_uv_half_960_rvv_i32: 249.5

SpacemiT X60:
rgb24_to_uv_half_4_c:   1.7
rgb24_to_uv_half_4_rvv_i32: 4.2
rgb24_to_uv_half_64_c: 24.0
rgb24_to_uv_half_64_rvv_i32:8.7
rgb24_to_uv_half_540_c:   199.2
rgb24_to_uv_half_540_rvv_i32:  72.5
rgb24_to_uv_half_640_c:   235.7
rgb24_to_uv_half_640_rvv_i32:  85.2
rgb24_to_uv_half_960_c:   353.5
rgb24_to_uv_half_960_rvv_i32: 127.5
---
 libswscale/riscv/input.S   | 50 ++
 libswscale/riscv/swscale.c | 14 +--
 2 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/libswscale/riscv/input.S b/libswscale/riscv/input.S
index 3392f189ca..f84f79899b 100644
--- a/libswscale/riscv/input.S
+++ b/libswscale/riscv/input.S
@@ -99,3 +99,53 @@ func ff_rgb24ToUV_rvv, zve32x
 
 ret
 endfunc
+
+func ff_bgr24ToUV_half_rvv, zve32x
+lw  t1, 20(a6) # BU
+lw  t4, 32(a6) # BV
+lw  t3, 12(a6) # RU
+lw  t6, 24(a6) # RV
+j   1f
+endfunc
+
+func ff_rgb24ToUV_half_rvv, zve32x
+lw  t1, 12(a6) # RU
+lw  t4, 24(a6) # RV
+lw  t3, 20(a6) # BU
+lw  t6, 32(a6) # BV
+1:
+lw  t2, 16(a6) # GU
+lw  t5, 28(a6) # GV
+li  a7, (256 << 15) + (1 << (15 - 6))
+2:
+vsetvlit0, a5, e8, m1, ta, ma
+vlseg6e8.v v0, (a3)
+sh1add a6, t0, t0
+vwaddu.vv  v8, v0, v3
+suba5, a5, t0
+vwaddu.vv  v10, v1, v4
+sh1add a3, a6, a3
+vwaddu.vv  v12, v2, v5
+vsetvlizero, zero, e32, m4, ta, ma
+vzext.vf2  v20, v8
+vzext.vf2  v24, v10
+vzext.vf2  v28, v12
+vmul.vxv0, v20, t1
+vmul.vxv4, v20, t4
+vmacc.vx   v0, t2, v24
+vmacc.vx   v4, t5, v24
+vmacc.vx   v0, t3, v28
+vmacc.vx   v4, t6, v28
+vadd.vxv0, v0, a7
+vadd.vxv4, v4, a7
+vsetvlizero, zero, e16, m2, ta, ma
+vnsra.wi   v0, v0, 15 - 5
+vnsra.wi   v2, v4, 15 - 5
+vse16.vv0, (a0)
+sh1add a0, t0, a0
+vse16.vv2, (a1)
+sh1add a1, t0, a1
+bnez   a5, 2b
+
+ret
+endfunc
diff --git a/libswscale/riscv/swscale.c b/libswscale/riscv/swscale.c
index b3552976c6..bae626f64a 100644
--- a/libswscale/riscv/swscale.c
+++ b/libswscale/riscv/swscale.c
@@ -25,10 +25,16 @@ void ff_bgr24ToY_rvv(uint8_t *dst, const uint8_t *src, 
const uint8_t *,
  const uint8_t *, int width, uint32_t *coeffs, void *);
 void ff_bgr24ToUV_rvv(uint8_t *, uint8_t *, const uint8_t *, const uint8_t *,
   const uint8_t *, int width, uint32_t *coeffs, void *);
+void ff_bgr24ToUV_half_rvv(uint8_t *, uint8_t *, const uint8_t *,
+   const uint8_t *, const uint8_t *, int width,
+   uint32_t *coeffs, void *);
 void ff_rgb24ToY_rvv(uint8_t *dst, const uint8_t *src, const uint8_t *,
  const uint8_t *, int width, uint32_t *coeffs, void *);
 void ff_rgb24ToUV_rvv(uint8_t *, uint8_t *, const uint8_t *, const uint8_t *,
   const uint8_t *, int width, uint32_t *coeffs, void *);
+void ff_rgb24ToUV_half_rvv(uint8_t *, uint8_t *, const uint8_t *,
+   const uint8_t *, const uint8_t *, int width,
+   uint32_t *coeffs, void *);
 
 av_cold void ff_sws_init_swscale_riscv(SwsContext *c)
 {
@@ -39,13 +45,17 @@ av_cold void ff_sws_init_swscale_riscv(SwsContext *c)
 switch (c->srcFormat) {
 case AV_PIX_FMT_BGR24:
 c->lumToYV12 = ff_bgr24ToY_rvv;
-if (!c->chrSrcHSubSample)
+if (c->chrSrcHSubSample)
+c->chrToYV12 = ff_bgr24ToUV_half_rvv;
+else
 c->chrToYV12 = ff_bgr24ToUV_rvv;
 break;
 
 case AV_PIX_FMT_RGB24:
 c->lumToYV12 = ff_rgb24ToY_rvv;
-if (!c->chrSrcHSubSample)
+if (c->chrSrcHSubSample)
+c->chrToYV12 = ff_rgb24ToUV_half_rvv;
+else
 c->chrToYV12 = ff_rgb24ToUV_rvv;
 break;
 }
-- 
2.45.1

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

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

[FFmpeg-devel] [PATCH v2 1/5] checkasm/sw_rgb: test rgb24/bgr24 to yuv

[Zhao Zhili]

From: Zhao Zhili 

The line width 8 is supposed to test corner case, while the
performance doesn't matter. Width 1080 is also a case of
unaligned to 16.

Width 1920 meant for benchmark (together with --runs options).
---
v2: add bgr24 support

Feel free to remove 128 and/or 1280 from input_sizes if you think it's
redundant.

I'm still working on patch 2-5. Send patch 1/5 because James and R??mi'
patches depend on this.

 tests/checkasm/sw_rgb.c | 113 
 1 file changed, 113 insertions(+)

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index 7cd815e5be..06d27f9235 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -22,8 +22,11 @@
 #include "libavutil/common.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/mem_internal.h"
+#include "libavutil/pixdesc.h"
 
 #include "libswscale/rgb2rgb.h"
+#include "libswscale/swscale.h"
+#include "libswscale/swscale_internal.h"
 
 #include "checkasm.h"
 
@@ -179,8 +182,104 @@ static void check_interleave_bytes(void)
 }
 }
 
+#define MAX_LINE_SIZE 1920
+static const int input_sizes[] = {8, 128, 1280, 1080, MAX_LINE_SIZE};
+static const enum AVPixelFormat rgb_formats[] = {
+AV_PIX_FMT_RGB24,
+AV_PIX_FMT_BGR24,
+};
+
+static void check_rgb_to_y(struct SwsContext *ctx)
+{
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, dst0_y, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst1_y, [MAX_LINE_SIZE * 2]);
+
+declare_func(void, uint8_t *dst, const uint8_t *src,
+ const uint8_t *unused1, const uint8_t *unused2, int width,
+ uint32_t *rgb2yuv, void *opq);
+
+randomize_buffers(src, MAX_LINE_SIZE * 3);
+
+for (int i = 0; i < FF_ARRAY_ELEMS(rgb_formats); i++) {
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(rgb_formats[i]);
+
+ctx->srcFormat = rgb_formats[i];
+ctx->dstFormat = AV_PIX_FMT_YUV420P;
+ff_sws_init_scale(ctx);
+
+for (int j = 0; j < FF_ARRAY_ELEMS(input_sizes); j++) {
+int w = input_sizes[j];
+
+if (check_func(ctx->lumToYV12, "%s_to_y_%d", desc->name, w)) {
+memset(dst0_y, 0xFA, MAX_LINE_SIZE * 2);
+memset(dst1_y, 0xFA, MAX_LINE_SIZE * 2);
+
+call_ref(dst0_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table,
+ NULL);
+call_new(dst1_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table,
+ NULL);
+
+if (memcmp(dst0_y, dst1_y, w * 2))
+fail();
+
+bench_new(dst1_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table,
+  NULL);
+}
+}
+}
+}
+
+static void check_rgb_to_uv(struct SwsContext *ctx)
+{
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, dst0_u, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst0_v, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst1_u, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst1_v, [MAX_LINE_SIZE * 2]);
+
+declare_func(void, uint8_t *dstU, uint8_t *dstV,
+ const uint8_t *src1, const uint8_t *src2, const uint8_t *src3,
+ int width, uint32_t *pal, void *opq);
+
+randomize_buffers(src, MAX_LINE_SIZE * 3);
+
+for (int i = 0; i < 2 * FF_ARRAY_ELEMS(rgb_formats); i++) {
+enum AVPixelFormat src_fmt = rgb_formats[i / 2];
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(src_fmt);
+
+ctx->chrSrcHSubSample = (i % 2) ? 0 : 1;
+ctx->srcFormat = src_fmt;
+ctx->dstFormat = ctx->chrSrcHSubSample ? AV_PIX_FMT_YUV420P : 
AV_PIX_FMT_YUV444P;
+ff_sws_init_scale(ctx);
+
+for (int j = 0; j < FF_ARRAY_ELEMS(input_sizes); j++) {
+int w = input_sizes[j] >> ctx->chrSrcHSubSample;
+
+if (check_func(ctx->chrToYV12, "%s_to_uv%s_%d", desc->name,
+   ctx->chrSrcHSubSample ? "_half" : "",
+   input_sizes[j])) {
+memset(dst0_u, 0xFF, MAX_LINE_SIZE * 2);
+memset(dst0_v, 0xFF, MAX_LINE_SIZE * 2);
+memset(dst1_u, 0xFF, MAX_LINE_SIZE * 2);
+memset(dst1_v, 0xFF, MAX_LINE_SIZE * 2);
+
+call_ref(dst0_u, dst0_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+call_new(dst1_u, dst1_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+
+if (memcmp(dst0_u, dst1_u, w * 2) || memcmp(dst0_v, dst1_v, w 
* 2))
+fail();
+
+bench_new(dst1_u, dst1_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+}
+}
+}
+}
+
 void checkasm_check_sw_rgb(void)
 {
+struct SwsContext *ctx;
+
 ff_sws_rgb2rgb_init();
 
 check_shuffle_bytes(shuffle_bytes_2103, "shuffle_bytes_2103");
@@ -203,4 +302,18 @@ void checkasm_check_sw_rgb(void)
 

[FFmpeg-devel] [PATCH] libswscale/x86/yuv2rgb: Add missing EMMS

[Mario Hros]

Previous rewrite from inline assembly into nasm (commit e934194) missed the 
required EMMS instruction to bring the x87 FPU back into usable state.

Signed-off-by: Mario Hros 
---
 libswscale/x86/yuv_2_rgb.asm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libswscale/x86/yuv_2_rgb.asm b/libswscale/x86/yuv_2_rgb.asm
index e3470fd9ad..7a247797e4 100644
--- a/libswscale/x86/yuv_2_rgb.asm
+++ b/libswscale/x86/yuv_2_rgb.asm
@@ -353,6 +353,7 @@ cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters
 add imageq, 8 * depth * time_num
 add indexq, 4 * time_num
 js .loop0
+emms
 
 RET
 
-- 
2.39.3 (Apple Git-146)

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo_enc: give magic number a name

[Ramiro Polla]

On Wed, Jun 5, 2024 at 1:51 AM Michael Niedermayer
 wrote:
> On Tue, Jun 04, 2024 at 03:05:35PM +0200, Ramiro Polla wrote:
> > ---
> >  libavcodec/mpegvideo_enc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> LGTM

Pushed.
___
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] aacdec_usac: correctly set and use the layout map

[Lynne via ffmpeg-devel]

---
 libavcodec/aac/aacdec_usac.c | 105 +--
 1 file changed, 63 insertions(+), 42 deletions(-)

diff --git a/libavcodec/aac/aacdec_usac.c b/libavcodec/aac/aacdec_usac.c
index 04dd5facff..561734f930 100644
--- a/libavcodec/aac/aacdec_usac.c
+++ b/libavcodec/aac/aacdec_usac.c
@@ -268,17 +268,25 @@ int ff_aac_usac_reset_state(AACDecContext *ac, 
OutputConfiguration *oc)
 /* Initialize state */
 for (int i = 0; i < usac->nb_elems; i++) {
 AACUsacElemConfig *e = &usac->elems[i];
-if (e->type != ID_USAC_SCE && e->type != ID_USAC_CPE)
+if (e->type == ID_USAC_EXT)
 continue;
 
-if (e->type == ID_USAC_SCE) {
+switch (e->type) {
+case ID_USAC_SCE:
 ch = 1;
 type = TYPE_SCE;
 id = elem_id[0]++;
-} else {
+break;
+case ID_USAC_CPE:
 ch = 2;
 type = TYPE_CPE;
 id = elem_id[1]++;
+break;
+case ID_USAC_LFE:
+ch = 1;
+type = TYPE_LFE;
+id = elem_id[2]++;
+break;
 }
 
 che = ff_aac_get_che(ac, type, id);
@@ -318,7 +326,8 @@ int ff_aac_usac_config_decode(AACDecContext *ac, 
AVCodecContext *avctx,
 AACUSACConfig *usac = &oc->usac;
 int elem_id[3 /* SCE, CPE, LFE */];
 
-uint8_t layout_map[MAX_ELEM_ID*4][3];
+int map_pos_set = 0;
+uint8_t layout_map[MAX_ELEM_ID*4][3] = { 0 };
 
 memset(usac, 0, sizeof(*usac));
 
@@ -391,6 +400,8 @@ int ff_aac_usac_config_decode(AACDecContext *ac, 
AVCodecContext *avctx,
 /* Fill in the number of expected channels */
 for (int i = 0; i < nb_elements; i++)
 nb_channels += layout_map[i][0] == TYPE_CPE ? 2 : 1;
+
+map_pos_set = 1;
 }
 
 /* UsacDecoderConfig */
@@ -404,12 +415,12 @@ int ff_aac_usac_config_decode(AACDecContext *ac, 
AVCodecContext *avctx,
 }
 
 for (int i = 0; i < usac->nb_elems; i++) {
+int map_count = elem_id[0] + elem_id[1] + elem_id[2];
 AACUsacElemConfig *e = &usac->elems[i];
 memset(e, 0, sizeof(*e));
 
 e->type = get_bits(gb, 2); /* usacElementType */
-if (e->type != ID_USAC_EXT &&
-(elem_id[0] + elem_id[1] + elem_id[2] + 1) > nb_channels) {
+if (e->type != ID_USAC_EXT && (map_count + 1) > nb_channels) {
 av_log(ac->avctx, AV_LOG_ERROR, "Too many channels for the channel 
"
 "configuration\n");
 usac->nb_elems = 0;
@@ -425,30 +436,31 @@ int ff_aac_usac_config_decode(AACDecContext *ac, 
AVCodecContext *avctx,
 decode_usac_element_core(e, gb, sbr_ratio);
 if (e->sbr.ratio > 0)
 decode_usac_sbr_data(e, gb);
-layout_map[i][0] = TYPE_SCE;
-layout_map[i][1] = i;
-layout_map[i][2] = AAC_CHANNEL_FRONT;
-elem_id[0]++;
+layout_map[map_count][0] = TYPE_SCE;
+layout_map[map_count][1] = elem_id[0]++;
+if (!map_pos_set)
+layout_map[map_count][2] = AAC_CHANNEL_FRONT;
 
 break;
 case ID_USAC_CPE: /* UsacChannelPairElementConf */
 /* UsacCoreConfig */
 decode_usac_element_core(e, gb, sbr_ratio);
 decode_usac_element_pair(e, gb);
-layout_map[i][0] = TYPE_CPE;
-layout_map[i][1] = i;
-layout_map[i][2] = AAC_CHANNEL_FRONT;
-elem_id[1]++;
+layout_map[map_count][0] = TYPE_CPE;
+layout_map[map_count][1] = elem_id[1]++;
+if (!map_pos_set)
+layout_map[map_count][2] = AAC_CHANNEL_FRONT;
 
 break;
 case ID_USAC_LFE: /* LFE */
 /* LFE has no need for any configuration */
 e->tw_mdct = 0;
 e->noise_fill = 0;
-layout_map[i][0] = TYPE_LFE;
-layout_map[i][1] = i;
-layout_map[i][2] = AAC_CHANNEL_LFE;
-elem_id[2]++;
+layout_map[map_count][0] = TYPE_LFE;
+layout_map[map_count][1] = elem_id[2]++;
+if (!map_pos_set)
+layout_map[map_count][2] = AAC_CHANNEL_LFE;
+
 break;
 case ID_USAC_EXT: /* EXT */
 ret = decode_usac_extension(ac, e, gb);
@@ -458,7 +470,8 @@ int ff_aac_usac_config_decode(AACDecContext *ac, 
AVCodecContext *avctx,
 };
 }
 
-ret = ff_aac_output_configure(ac, layout_map, elem_id[0] + elem_id[1] + 
elem_id[2], OC_GLOBAL_HDR, 0);
+ret = ff_aac_output_configure(ac, layout_map, elem_id[0] + elem_id[1] + 
elem_id[2],
+  OC_GLOBAL_HDR, 0);
 if (ret < 0) {
 av_log(avctx, AV_LOG_ERROR, "Unable to parse channel config!\n");
 usac->nb_elems = 0;
@@ -1531,9 +1544,11 @@ static int parse_ext_ele(AACDecContext *ac, 
AACUsacElemConfig *e,
 int ff_aac_usac_decode_frame(AVCodecContext *avctx

Re: [FFmpeg-devel] [PATCH] libavcodec/libxvid: code cleanup (replace magic numbers)

[Ramiro Polla]

On Tue, Jun 4, 2024 at 2:54 PM Ramiro Polla  wrote:
> On Thu, May 30, 2024 at 11:24 PM Sean McGovern  wrote:
> > On Thu, May 30, 2024 at 5:20 PM Ramiro Polla  wrote:
> > >
> > > ---
> > >  libavcodec/libxvid.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
> > > index b9ac39429d..a490f16b3f 100644
> > > --- a/libavcodec/libxvid.c
> > > +++ b/libavcodec/libxvid.c
> > > @@ -422,13 +422,13 @@ static av_cold int xvid_encode_init(AVCodecContext 
> > > *avctx)
> > >
> > >  /* Decide how we should decide blocks */
> > >  switch (avctx->mb_decision) {
> > > -case 2:
> > > +case FF_MB_DECISION_RD:
> > >  x->vop_flags |=  XVID_VOP_MODEDECISION_RD;
> > >  x->me_flags  |=  XVID_ME_HALFPELREFINE8_RD|
> > >   XVID_ME_QUARTERPELREFINE8_RD |
> > >   XVID_ME_EXTSEARCH_RD |
> > >   XVID_ME_CHECKPREDICTION_RD;
> > > -case 1:
> > > +case FF_MB_DECISION_BITS:
> > >  if (!(x->vop_flags & XVID_VOP_MODEDECISION_RD))
> > >  x->vop_flags |= XVID_VOP_FAST_MODEDECISION_RD;
> > >  x->me_flags |= XVID_ME_HALFPELREFINE16_RD |
> > > --
> > > 2.30.2
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
> > This gets a +1 from me.
>
> I'll apply tomorrow.

Pushed.
___
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] libswscale/x86/yuv_2_rgb: fix some comments

[Ramiro Polla]

On Tue, Jun 4, 2024 at 3:15 PM Ramiro Polla  wrote:
>
> ---
>  libswscale/x86/yuv_2_rgb.asm | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libswscale/x86/yuv_2_rgb.asm b/libswscale/x86/yuv_2_rgb.asm
> index e3470fd9ad..a1f9134e08 100644
> --- a/libswscale/x86/yuv_2_rgb.asm
> +++ b/libswscale/x86/yuv_2_rgb.asm
> @@ -195,15 +195,15 @@ cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, 
> parameters
>  mova m5, m7
>  paddsw m3, m0 ; B1 B3 B5 B7 ...
>  paddsw m5, m1 ; R1 R3 R5 R7 ...
> -paddsw m7, m2 ; G1 G3 G4 G7 ...
> +paddsw m7, m2 ; G1 G3 G5 G7 ...
>  paddsw m0, m6 ; B0 B2 B4 B6 ...
>  paddsw m1, m6 ; R0 R2 R4 R6 ...
>  paddsw m2, m6 ; G0 G2 G4 G6 ...
>
>  %if %3 == 24 ; PACK RGB24
>  %define depth 3
> -packuswb m0, m3 ; R0 R2 R4 R6 ... R1 R3 R5 R7 ...
> -packuswb m1, m5 ; B0 B2 B4 B6 ... B1 B3 B5 B7 ...
> +packuswb m0, m3 ; B0 B2 B4 B6 ... B1 B3 B5 B7 ...
> +packuswb m1, m5 ; R0 R2 R4 R6 ... R1 R3 R5 R7 ...
>  packuswb m2, m7 ; G0 G2 G4 G6 ... G1 G3 G5 G7 ...
>  mova m3, m_red
>  mova m6, m_blue
> @@ -248,7 +248,7 @@ cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters
>  psrlq m5, 32
>  movd [imageq + 20], m2 ; -- -- G7 B7
>  movd [imageq + 18], m5 ; R6 G6 B6 R7
> -%endif ; mmsize = 8
> +%endif ; cpuflag
>  %else ; mmsize == 16
>  pshufb m3, [rgb24_shuf1] ; r0  g0  r6  g6  r12 g12 r2  g2  r8  g8  r14 
> g14 r4  g4  r10 g10
>  pshufb m6, [rgb24_shuf2] ; b10 r11 b0  r1  b6  r7  b12 r13 b2  r3  b8  
> r9  b14 r15 b4  r5
> --
> 2.30.2
>

I'll apply tomorrow.
___
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] FFMPEG support for x265 vbv-end and vbv-end-fr-adj

[Tom Vaughan]

Michael - Sorry I missed your response on 5/15. I led the x265 project from 
2013 to 2018, and I helped to define this feature, but I can't speak for the 
x265 development team today. I could put you directly in touch with the x265 
developers at Multicoreware to work this out. I will also encourage them to 
respond to this thread directly on the FFMPEG-devel mailing list.

Speaking as an end-user, I don't think we require frame-accurate precision. The 
vbv-end-fr-adj value specifies the point at which the vbv-end logic is 
activated. vbv-end-fr-adj is a value between 0 and 1, but should always be less 
than 1. Multiply vbv-end-fr-adj by 100 to get the % of the transcoding job in 
time where the vbv-end feature needs to be triggered. A flag that is passed 
from FFMPEG to x265 at this point would work. I'm aware of the challenges of 
frame-rate accuracy when transcoding. I would say that a "best effort" from 
FFMPEG to trigger the signal at the right point is good enough. Non-decodable 
frames should count as if they were decodable, to not throw off the time 
calculation.

As an example, if someone is chunking the encoding of a video title into 300 
second chunks, and they want the vbv-end enforcement to start 15 seconds before 
the end of the chunk encode, they would use vbv-end-fr-adj 0.95. When x265 gets 
to the last 5% of the encode (last 15 seconds), vbv-end logic would be 
activated. 1 or 2 frames inaccuracy won't matter.

Thanks,
Tom

On 5/15/24, 5:59 AM, "ffmpeg-devel on behalf of Michael Niedermayer" 
mailto:ffmpeg-devel-boun...@ffmpeg.org> on 
behalf of mich...@niedermayer.cc > wrote:


On Wed, May 01, 2024 at 09:10:51PM +, Tom Vaughan wrote:
> When I attempt to pass vbv-end and vbv-end-fr-adj parameters to x265, FFMPEG 
> fails.
> 
> x265 [error]: vbv-end-fr-adj cannot be enabled when total number of frames is 
> unknown
> 
> x265 needs to know how many frames it is encoding so that it knows when the 
> vbv-end logic needs to kick in. In this case it would be after 96% of the 
> source video is encoded. Despite specifying a duration of 30 seconds ( -t 30 
> ) on both input and output (using a 60 second source video), x265 does not 
> know the total number of frames (but FFMPEG surely does).
> 
> ffmpeg -i test_uhdsdr_1min.mov -t 30 -an -sn -dn -c:v libx265 -b:v 12000k 
> -maxrate 8M -bufsize 18M -x265-params 
> vbv-init=0.9:vbv-end=0.9:vbv-end-fr-adj=.96:rc-lookahead=48:qg-size=32:scenecut=0:no-open-gop=1:frame-threads=0:repeat-headers=1:nr-inter=400:nr-intra=100:psy-rd=0:cbqpoffs=0:crqpoffs=3
>  -t 30 test_uhdsdr_96.mp4


you can specify total_frames along with vbv-end-fr


there is in general not a 1:1 correspondance between duration and the number of 
frames
the frame rate may vary, there may be skiped frames or damaged frames that
where lost and so on.


in case of some 2 pass mode it should be possible to get the exact number of 
frames
in the 2nd pass.
Otherwise my gut feelng is that a time based instead of a frame number based
threshold would have been easier to work with


if you are thinking that the total frame number should be set automatically
and not by hand. I agree, its just not easy to do that in all cases.
It could maybe be done in specific cases but in the general case
it would need 2 passes to be reliable.


thx


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


Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.



___
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] checkasm/sw_rgb: test rgb32/bgr32 to yuv

[James Almer]

Signed-off-by: James Almer 
---
 tests/checkasm/sw_rgb.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index b51d0836c3..57bd6b20cd 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -187,11 +187,13 @@ static const int input_sizes[] = {8, 128, 1080, 
MAX_LINE_SIZE};
 static const enum AVPixelFormat rgb_formats[] = {
 AV_PIX_FMT_RGB24,
 AV_PIX_FMT_BGR24,
+AV_PIX_FMT_RGBA,
+AV_PIX_FMT_BGRA,
 };
 
 static void check_rgb_to_y(struct SwsContext *ctx)
 {
-LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 4]);
 LOCAL_ALIGNED_32(uint8_t, dst0_y, [MAX_LINE_SIZE * 2]);
 LOCAL_ALIGNED_32(uint8_t, dst1_y, [MAX_LINE_SIZE * 2]);
 
@@ -199,7 +201,7 @@ static void check_rgb_to_y(struct SwsContext *ctx)
  const uint8_t *unused1, const uint8_t *unused2, int width,
  uint32_t *rgb2yuv, void *opq);
 
-randomize_buffers(src, MAX_LINE_SIZE * 3);
+randomize_buffers(src, MAX_LINE_SIZE * 4);
 
 for (int i = 0; i < FF_ARRAY_ELEMS(rgb_formats); i++) {
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(rgb_formats[i]);
@@ -228,7 +230,7 @@ static void check_rgb_to_y(struct SwsContext *ctx)
 
 static void check_rgb_to_uv(struct SwsContext *ctx)
 {
-LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 4]);
 LOCAL_ALIGNED_32(uint8_t, dst0_u, [MAX_LINE_SIZE * 2]);
 LOCAL_ALIGNED_32(uint8_t, dst0_v, [MAX_LINE_SIZE * 2]);
 LOCAL_ALIGNED_32(uint8_t, dst1_u, [MAX_LINE_SIZE * 2]);
@@ -238,7 +240,7 @@ static void check_rgb_to_uv(struct SwsContext *ctx)
  const uint8_t *src1, const uint8_t *src2, const uint8_t *src3,
  int width, uint32_t *pal, void *opq);
 
-randomize_buffers(src, MAX_LINE_SIZE * 3);
+randomize_buffers(src, MAX_LINE_SIZE * 4);
 
 for (int i = 0; i < 2 * FF_ARRAY_ELEMS(rgb_formats); i++) {
 enum AVPixelFormat src_fmt = rgb_formats[i / 2];
-- 
2.45.1

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

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

[FFmpeg-devel] [PATCH v7 1/2] lavu/hashtable: create generic robin hood hash table

[Connor Worley]

Signed-off-by: Connor Worley 
---
 libavutil/Makefile  |   2 +
 libavutil/hashtable.c   | 192 
 libavutil/hashtable.h   |  91 +
 libavutil/tests/hashtable.c | 110 +
 4 files changed, 395 insertions(+)
 create mode 100644 libavutil/hashtable.c
 create mode 100644 libavutil/hashtable.h
 create mode 100644 libavutil/tests/hashtable.c

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 6e6fa8d800..8c7b4452b4 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -138,6 +138,7 @@ OBJS = adler32.o
\
fixed_dsp.o  \
frame.o  \
hash.o   \
+   hashtable.o  \
hdr_dynamic_metadata.o   \
hdr_dynamic_vivid_metadata.o \
hmac.o   \
@@ -252,6 +253,7 @@ TESTPROGS = adler32 
\
 file\
 fifo\
 hash\
+hashtable   \
 hmac\
 hwdevice\
 integer \
diff --git a/libavutil/hashtable.c b/libavutil/hashtable.c
new file mode 100644
index 00..155a264665
--- /dev/null
+++ b/libavutil/hashtable.c
@@ -0,0 +1,192 @@
+/*
+ * Generic hashtable
+ * Copyright (C) 2024 Connor Worley 
+ *
+ * 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 
+#include 
+
+#include "crc.h"
+#include "error.h"
+#include "mem.h"
+#include "hashtable.h"
+
+#define ALIGN _Alignof(size_t)
+
+struct AVHashtableContext {
+size_t key_size;
+size_t key_size_aligned;
+size_t val_size;
+size_t val_size_aligned;
+size_t entry_size;
+size_t max_entries;
+size_t utilization;
+const AVCRC *crc;
+uint8_t *table;
+uint8_t *swapbuf;
+};
+
+#define ENTRY_PSL(entry) (entry)
+#define ENTRY_OCC(entry) (ENTRY_PSL(entry) + FFALIGN(sizeof(size_t), ALIGN))
+#define ENTRY_KEY(entry) (ENTRY_OCC(entry) + FFALIGN(sizeof(size_t), ALIGN))
+#define ENTRY_VAL(entry) (ENTRY_KEY(entry) + ctx->key_size_aligned)
+
+#define KEYS_EQUAL(k1, k2) !memcmp(k1, k2, ctx->key_size)
+
+int av_hashtable_alloc(struct AVHashtableContext **ctx, size_t key_size, 
size_t val_size, size_t max_entries)
+{
+struct AVHashtableContext *res = av_malloc(sizeof(struct 
AVHashtableContext));
+if (!res)
+return AVERROR(ENOMEM);
+res->key_size = key_size;
+res->key_size_aligned = FFALIGN(key_size, ALIGN);
+res->val_size = val_size;
+res->val_size_aligned = FFALIGN(val_size, ALIGN);
+res->entry_size = FFALIGN(sizeof(size_t), ALIGN)
++ FFALIGN(sizeof(size_t), ALIGN)
++ res->key_size_aligned
++ res->val_size_aligned;
+res->max_entries = max_entries;
+res->utilization = 0;
+res->crc = av_crc_get_table(AV_CRC_32_IEEE);
+if (!res->crc) {
+av_hashtable_freep(&res);
+return AVERROR_BUG;
+}
+res->table = av_calloc(res->max_entries, res->entry_size);
+if (!res->table) {
+av_hashtable_freep(&res);
+return AVERROR(ENOMEM);
+}
+res->swapbuf = av_calloc(2, res->key_size_aligned + res->val_size_aligned);
+if (!res->swapbuf) {
+av_hashtable_freep(&res);
+return AVERROR(ENOMEM);
+}
+*ctx = res;
+return 0;
+}
+
+static size_t hash_key(const struct AVHashtableContext *ctx, const void *key)
+{
+return av_crc(ctx->crc, 0, key, ctx->key_size) % ctx->max_entries;
+}
+
+int av_hashtable_get(const struct AVHashtableContext *ctx, const void *ke

[FFmpeg-devel] [PATCH v7 2/2] lavc/dxvenc: migrate DXT1 encoder to lavu hashtable

[Connor Worley]

Offers a modest performance gain due to the switch from naive linear
probling to robin hood.

Signed-off-by: Connor Worley 
---
 libavcodec/dxvenc.c | 121 
 1 file changed, 33 insertions(+), 88 deletions(-)

diff --git a/libavcodec/dxvenc.c b/libavcodec/dxvenc.c
index 8229438373..38c7d7a0ab 100644
--- a/libavcodec/dxvenc.c
+++ b/libavcodec/dxvenc.c
@@ -21,7 +21,7 @@
 
 #include 
 
-#include "libavutil/crc.h"
+#include "libavutil/hashtable.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/mem.h"
 #include "libavutil/opt.h"
@@ -39,72 +39,9 @@
  * appeared in the decompressed stream. Using a simple hash table (HT)
  * significantly speeds up the lookback process while encoding.
  */
-#define LOOKBACK_HT_ELEMS 0x4
+#define LOOKBACK_HT_ELEMS 0x20202
 #define LOOKBACK_WORDS0x20202
 
-typedef struct HTEntry {
-uint32_t key;
-uint32_t pos;
-} HTEntry;
-
-static void ht_init(HTEntry *ht)
-{
-for (size_t i = 0; i < LOOKBACK_HT_ELEMS; i++) {
-ht[i].pos = -1;
-}
-}
-
-static uint32_t ht_lookup_and_upsert(HTEntry *ht, const AVCRC *hash_ctx,
-uint32_t key, uint32_t pos)
-{
-uint32_t ret = -1;
-size_t hash = av_crc(hash_ctx, 0, (uint8_t*)&key, 4) % LOOKBACK_HT_ELEMS;
-for (size_t i = hash; i < hash + LOOKBACK_HT_ELEMS; i++) {
-size_t wrapped_index = i % LOOKBACK_HT_ELEMS;
-HTEntry *entry = &ht[wrapped_index];
-if (entry->key == key || entry->pos == -1) {
-ret = entry->pos;
-entry->key = key;
-entry->pos = pos;
-break;
-}
-}
-return ret;
-}
-
-static void ht_delete(HTEntry *ht, const AVCRC *hash_ctx,
-  uint32_t key, uint32_t pos)
-{
-HTEntry *removed_entry = NULL;
-size_t removed_hash;
-size_t hash = av_crc(hash_ctx, 0, (uint8_t*)&key, 4) % LOOKBACK_HT_ELEMS;
-
-for (size_t i = hash; i < hash + LOOKBACK_HT_ELEMS; i++) {
-size_t wrapped_index = i % LOOKBACK_HT_ELEMS;
-HTEntry *entry = &ht[wrapped_index];
-if (entry->pos == -1)
-return;
-if (removed_entry) {
-size_t candidate_hash = av_crc(hash_ctx, 0, (uint8_t*)&entry->key, 
4) % LOOKBACK_HT_ELEMS;
-if ((wrapped_index > removed_hash && (candidate_hash <= 
removed_hash || candidate_hash > wrapped_index)) ||
-(wrapped_index < removed_hash && (candidate_hash <= 
removed_hash && candidate_hash > wrapped_index))) {
-*removed_entry = *entry;
-entry->pos = -1;
-removed_entry = entry;
-removed_hash = wrapped_index;
-}
-} else if (entry->key == key) {
-if (entry->pos <= pos) {
-entry->pos = -1;
-removed_entry = entry;
-removed_hash = wrapped_index;
-} else {
-return;
-}
-}
-}
-}
-
 typedef struct DXVEncContext {
 AVClass *class;
 
@@ -121,10 +58,8 @@ typedef struct DXVEncContext {
 DXVTextureFormat tex_fmt;
 int (*compress_tex)(AVCodecContext *avctx);
 
-const AVCRC *crc_ctx;
-
-HTEntry color_lookback_ht[LOOKBACK_HT_ELEMS];
-HTEntry lut_lookback_ht[LOOKBACK_HT_ELEMS];
+struct AVHashtableContext *color_ht;
+struct AVHashtableContext *lut_ht;
 } DXVEncContext;
 
 /* Converts an index offset value to a 2-bit opcode and pushes it to a stream.
@@ -159,27 +94,32 @@ static int dxv_compress_dxt1(AVCodecContext *avctx)
 DXVEncContext *ctx = avctx->priv_data;
 PutByteContext *pbc = &ctx->pbc;
 void *value;
-uint32_t color, lut, idx, color_idx, lut_idx, prev_pos, state = 16, pos = 
2, op = 0;
+uint32_t color, lut, idx, color_idx, lut_idx, prev_pos, state = 16, pos = 
0, op = 0;
 
-ht_init(ctx->color_lookback_ht);
-ht_init(ctx->lut_lookback_ht);
+av_hashtable_clear(ctx->color_ht);
+av_hashtable_clear(ctx->lut_ht);
 
 bytestream2_put_le32(pbc, AV_RL32(ctx->tex_data));
+av_hashtable_set(ctx->color_ht, ctx->tex_data, &pos);
+pos++;
 bytestream2_put_le32(pbc, AV_RL32(ctx->tex_data + 4));
-
-ht_lookup_and_upsert(ctx->color_lookback_ht, ctx->crc_ctx, 
AV_RL32(ctx->tex_data), 0);
-ht_lookup_and_upsert(ctx->lut_lookback_ht, ctx->crc_ctx, 
AV_RL32(ctx->tex_data + 4), 1);
+av_hashtable_set(ctx->lut_ht, ctx->tex_data + 4, &pos);
+pos++;
 
 while (pos + 2 <= ctx->tex_size / 4) {
 idx = 0;
+color_idx = 0;
+lut_idx = 0;
 
 color = AV_RL32(ctx->tex_data + pos * 4);
-prev_pos = ht_lookup_and_upsert(ctx->color_lookback_ht, ctx->crc_ctx, 
color, pos);
-color_idx = prev_pos != -1 ? pos - prev_pos : 0;
+if (av_hashtable_get(ctx->color_ht, &color, &prev_pos))
+color_idx = pos - prev_pos;
+av_hashtable_set(ctx->color_ht, &color, &pos);
+
 if (pos >= LOOKBACK_WORDS) {
 uint32_t old_pos = pos - 

[FFmpeg-devel] [PATCH] lavc/vp8dsp: R-V V vp8_idct_add

[Rémi Denis-Courmont]

T-Head C908 (cycles):
vp8_idct_add_c:   312.2
vp8_idct_add_rvv_i32: 117.0
---
 libavcodec/riscv/vp8dsp_init.c |  2 ++
 libavcodec/riscv/vp8dsp_rvv.S  | 59 ++
 2 files changed, 61 insertions(+)

diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index 5911d195ba..d9e2beb237 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -27,6 +27,7 @@
 #include "vp8dsp.h"
 
 void ff_vp8_luma_dc_wht_rvv(int16_t block[4][4][16], int16_t dc[16]);
+void ff_vp8_idct_add_rvv(uint8_t *dst, int16_t block[16], ptrdiff_t stride);
 void ff_vp8_idct_dc_add_rvv(uint8_t *dst, int16_t block[16], ptrdiff_t stride);
 void ff_vp8_idct_dc_add4y_rvv(uint8_t *dst, int16_t block[4][16], ptrdiff_t 
stride);
 void ff_vp8_idct_dc_add4uv_rvv(uint8_t *dst, int16_t block[4][16], ptrdiff_t 
stride);
@@ -129,6 +130,7 @@ av_cold void ff_vp8dsp_init_riscv(VP8DSPContext *c)
 if (flags & AV_CPU_FLAG_RVV_I64)
 c->vp8_luma_dc_wht = ff_vp8_luma_dc_wht_rvv;
 #endif
+c->vp8_idct_add = ff_vp8_idct_add_rvv;
 c->vp8_idct_dc_add = ff_vp8_idct_dc_add_rvv;
 c->vp8_idct_dc_add4y = ff_vp8_idct_dc_add4y_rvv;
 if (flags & AV_CPU_FLAG_RVV_I64)
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index 02eeb4cc2c..b4b7b63195 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -100,6 +100,65 @@ func ff_vp8_luma_dc_wht_rvv, zve64x
 endfunc
 #endif
 
+func ff_vp8_idct_add_rvv, zve32x
+csrwi   vxrm, 0
+vsetivlizero, 4, e16, mf2, ta, ma
+addia3, a1, 1 * 4 * 2
+addia4, a1, 2 * 4 * 2
+addia5, a1, 3 * 4 * 2
+li  t1, 20091
+li  t2, 35468
+jal t0, 1f
+vsseg4e16.v v0, (a1)
+jal t0, 1f
+vlsseg4e8.v v4, (a0), a2
+vssra.viv0, v0, 3
+sd  zero,   (a1)
+vssra.viv1, v1, 3
+sd  zero,  8(a1)
+vssra.viv2, v2, 3
+sd  zero, 16(a1)
+vssra.viv3, v3, 3
+sd  zero, 24(a1)
+vsetvli zero, zero, e8, mf4, ta, ma
+vwaddu.wv   v0, v0, v4
+vwaddu.wv   v1, v1, v5
+vwaddu.wv   v2, v2, v6
+vwaddu.wv   v3, v3, v7
+vsetvli zero, zero, e16, mf2, ta, ma
+vmax.vx v0, v0, zero
+vmax.vx v1, v1, zero
+vmax.vx v2, v2, zero
+vmax.vx v3, v3, zero
+vsetvli zero, zero, e8, mf4, ta, ma
+vnclipu.wi  v4, v0, 0
+vnclipu.wi  v5, v1, 0
+vnclipu.wi  v6, v2, 0
+vnclipu.wi  v7, v3, 0
+vssseg4e8.v v4, (a0), a2
+ret
+1:
+vle16.vv0, (a1)
+vle16.vv2, (a4)
+vle16.vv1, (a3)
+vle16.vv3, (a5)
+vadd.vvv4, v0, v2 # t0
+vsub.vvv5, v0, v2 # t1
+vmulhsu.vx v8, v3, t1
+vmulhsu.vx v6, v1, t2
+vadd.vvv8, v8, v3
+vmulhsu.vx v7, v1, t1
+vmulhsu.vx v9, v3, t2
+vadd.vvv7, v7, v1
+vsub.vvv6, v6, v8 # t2
+vadd.vvv7, v7, v9 # t3
+vadd.vvv1, v5, v6
+vsub.vvv2, v5, v6
+vadd.vvv0, v4, v7
+vsub.vvv3, v4, v7
+jr t0
+endfunc
+
 func ff_vp8_idct_dc_add_rvv, zve32x
 lh  a3, (a1)
 addia3, a3, 4
-- 
2.45.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] checkasm: disable unaligned access emulation

[Rémi Denis-Courmont]

Le lauantaina 1. kesäkuuta 2024, 11.03.55 EEST Rémi Denis-Courmont a écrit :
> The OS may silently fix (emulate) unaligned hardware access exceptions.
> This is extremely slow and code should be fixed not to rely on unaligned
> access on affected hardware. Accordingly this requests that the OS
> disable emulation and instead throw Bus error, which will be caught by
> checkasm's signal handler.
> 
> This has no effects if the hardware supports unaligned access in
> hardware, since no exceptions are generated. prctl() will fail safe in
> that case.

Will push soon.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/



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

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

[FFmpeg-devel] [PATCH v5 0/1] Add support for H266/VVC encoding

[Christian Bartnik]

This patch is based on the latest patchset from Thomas Siedel
(thomas...@spin-digital.com).

The libvvenc patch has been changed with following changes:
  avcodec: add external encoder libvvenc for H266/VVC
- sort includes alphabetically
- remove unneeded cast
- do not separate variables declaration and definition
- change if ((ret = func()) != 0) to: ret = func(); if (ret != 0)
- remove check for correct pix_fmt
- remove call of ff_side_data_set_encoder_stats

Christian Bartnik (1):
  avcodec: add external enc libvvenc for H266/VVC

 configure |   4 +
 doc/encoders.texi |  64 +
 fftools/ffmpeg_mux_init.c |   2 +-
 libavcodec/Makefile   |   1 +
 libavcodec/allcodecs.c|   1 +
 libavcodec/libvvenc.c | 492 ++
 6 files changed, 563 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/libvvenc.c

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

[FFmpeg-devel] [PATCH v5 1/1] avcodec: add external enc libvvenc for H266/VVC

[Christian Bartnik]

From: Thomas Siedel 

Add external encoder VVenC for H266/VVC encoding.
Register new encoder libvvenc.
Add libvvenc to wrap the vvenc interface.
libvvenc implements encoder option: preset,qp,qpa,period,
passlogfile,stats,vvenc-params,level,tier.
Enable encoder by adding --enable-libvvenc in configure step.

Co-authored-by: Christian Bartnik chris1031...@gmail.com
Signed-off-by: Thomas Siedel 
---
 configure |   4 +
 doc/encoders.texi |  64 +
 fftools/ffmpeg_mux_init.c |   2 +-
 libavcodec/Makefile   |   1 +
 libavcodec/allcodecs.c|   1 +
 libavcodec/libvvenc.c | 492 ++
 6 files changed, 563 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/libvvenc.c

diff --git a/configure b/configure
index 6c5b8aab9a..37ece23376 100755
--- a/configure
+++ b/configure
@@ -293,6 +293,7 @@ External library support:
   --enable-libvorbis   enable Vorbis en/decoding via libvorbis,
native implementation exists [no]
   --enable-libvpx  enable VP8 and VP9 de/encoding via libvpx [no]
+  --enable-libvvencenable H.266/VVC encoding via vvenc [no]
   --enable-libwebp enable WebP encoding via libwebp [no]
   --enable-libx264 enable H.264 encoding via x264 [no]
   --enable-libx265 enable HEVC encoding via x265 [no]
@@ -1966,6 +1967,7 @@ EXTERNAL_LIBRARY_LIST="
 libvmaf
 libvorbis
 libvpx
+libvvenc
 libwebp
 libxevd
 libxeve
@@ -3560,6 +3562,7 @@ libvpx_vp8_decoder_deps="libvpx"
 libvpx_vp8_encoder_deps="libvpx"
 libvpx_vp9_decoder_deps="libvpx"
 libvpx_vp9_encoder_deps="libvpx"
+libvvenc_encoder_deps="libvvenc"
 libwebp_encoder_deps="libwebp"
 libwebp_anim_encoder_deps="libwebp"
 libx262_encoder_deps="libx262"
@@ -7030,6 +7033,7 @@ enabled libvpx&& {
 fi
 }
 
+enabled libvvenc  && require_pkg_config libvvenc "libvvenc >= 1.6.1" 
"vvenc/vvenc.h" vvenc_get_version
 enabled libwebp   && {
 enabled libwebp_encoder  && require_pkg_config libwebp "libwebp >= 
0.2.0" webp/encode.h WebPGetEncoderVersion
 enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder 
"libwebpmux >= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; }
diff --git a/doc/encoders.texi b/doc/encoders.texi
index c82f316f94..496852faeb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2378,6 +2378,70 @@ Indicates frame duration
 For more information about libvpx see:
 @url{http://www.webmproject.org/}
 
+@section libvvenc
+
+VVenC H.266/VVC encoder wrapper.
+
+This encoder requires the presence of the libvvenc headers and library
+during configuration. You need to explicitly configure the build with
+@option{--enable-libvvenc}.
+
+The VVenC project website is at
+@url{https://github.com/fraunhoferhhi/vvenc}.
+
+@subsection Supported Pixel Formats
+
+VVenC supports only 10-bit color spaces as input. But the internal (encoded)
+bit depth can be set to 8-bit or 10-bit at runtime.
+
+@subsection Options
+
+@table @option
+@item b
+Sets target video bitrate.
+
+@item g
+Set the GOP size. Currently support for g=1 (Intra only) or default.
+
+@item preset
+Set the VVenC preset.
+
+@item levelidc
+Set level idc.
+
+@item tier
+Set vvc tier.
+
+@item qp
+Set constant quantization parameter.
+
+@item subopt @var{boolean}
+Set subjective (perceptually motivated) optimization. Default is 1 (on).
+
+@item bitdepth8 @var{boolean}
+Set 8bit coding mode instead of using 10bit. Default is 0 (off).
+
+@item period
+set (intra) refresh period in seconds.
+
+@item vvenc-params
+Set vvenc options using a list of @var{key}=@var{value} couples separated
+by ":". See @command{vvencapp --fullhelp} or @command{vvencFFapp --fullhelp} 
for a list of options.
+
+For example, the options might be provided as:
+
+@example
+intraperiod=64:decodingrefreshtype=idr:poc0idr=1:internalbitdepth=8
+@end example
+
+For example the encoding options might be provided with @option{-vvenc-params}:
+
+@example
+ffmpeg -i input -c:v libvvenc -b 1M -vvenc-params 
intraperiod=64:decodingrefreshtype=idr:poc0idr=1:internalbitdepth=8 output.mp4
+@end example
+
+@end table
+
 @section libwebp
 
 libwebp WebP Image encoder wrapper
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 8797265145..ef2922854a 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -739,7 +739,7 @@ static int new_stream_video(Muxer *mux, const 
OptionsContext *o,
  ost->logfile_prefix ? ost->logfile_prefix :
DEFAULT_PASS_LOGFILENAME_PREFIX,
  ost_idx);
-if (!strcmp(ost->enc_ctx->codec->name, "libx264")) {
+if (!strcmp(ost->enc_ctx->codec->name, "libx264") || 
!strcmp(ost->enc_ctx->codec->name, "libvvenc")) {
 av_dict_set(&ost->encoder_opts, "stats", logfilename, 
AV_DICT_DONT_OVERWRITE);
 } else {
 if (video_enc->flag

[FFmpeg-devel] [PATCH v3 1/3] lavc/h265_profile_level: Expand profile compatibility checking

[Mark Thompson]

Replace existing get_profile() with find_profile(), which finds the
lowest compatible profile rather than requiring an exact match.
---
Now with an enum tag.


 libavcodec/h265_profile_level.c | 80 +
 libavcodec/h265_profile_level.h | 70 -
 libavcodec/tests/h265_levels.c  |  2 +-
 libavcodec/vaapi_hevc.c |  2 +-
 libavcodec/vdpau_hevc.c |  2 +-
 5 files changed, 124 insertions(+), 32 deletions(-)

diff --git a/libavcodec/h265_profile_level.c b/libavcodec/h265_profile_level.c
index 7ff9681f65..1e96ec1c32 100644
--- a/libavcodec/h265_profile_level.c
+++ b/libavcodec/h265_profile_level.c
@@ -16,6 +16,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include 
+
 #include "h265_profile_level.h"
 
 
@@ -40,6 +42,7 @@ static const H265LevelDescriptor h265_levels[] = {
 };
 
 static const H265ProfileDescriptor h265_profiles[] = {
+{ "Invalid" },
 // profile_idc   8bit   one-picture
 //   HT-profile  | 422chroma| lower-bit-rate
 //   |  14bit|  | 420chroma |  | CpbVclFactor MinCrScaleFactor
@@ -119,41 +122,62 @@ static const H265ProfileDescriptor h265_profiles[] = {
   5, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 2, 4000, 4400, 6.000, 0.5, 6 },
 };
 
+static_assert(H265_PROFILE_COUNT == FF_ARRAY_ELEMS(h265_profiles),
+  "Incorrect H.265 profiles table.");
+
 
-const H265ProfileDescriptor *ff_h265_get_profile(const H265RawProfileTierLevel 
*ptl)
+const int ff_h265_profile_compatible(const H265RawProfileTierLevel *ptl,
+ enum H265Profile profile)
 {
-int i;
+const H265ProfileDescriptor *desc;
+
+av_assert0(profile > H265_PROFILE_INVALID &&
+   profile < H265_PROFILE_COUNT);
 
 if (ptl->general_profile_space)
-return NULL;
+return 0;
 
-for (i = 0; i < FF_ARRAY_ELEMS(h265_profiles); i++) {
-const H265ProfileDescriptor *profile = &h265_profiles[i];
+desc = &h265_profiles[profile];
 
-if (ptl->general_profile_idc &&
-ptl->general_profile_idc != profile->profile_idc)
-continue;
-if (!ptl->general_profile_compatibility_flag[profile->profile_idc])
-continue;
+if (ptl->general_profile_idc &&
+ptl->general_profile_idc != desc->profile_idc)
+return 0;
+if (!ptl->general_profile_compatibility_flag[desc->profile_idc])
+return 0;
 
-#define check_flag(name) \
-if (profile->name < 2) { \
-if (profile->name != ptl->general_ ## name ## _constraint_flag) \
-continue; \
-}
-check_flag(max_14bit);
-check_flag(max_12bit);
-check_flag(max_10bit);
-check_flag(max_8bit);
-check_flag(max_422chroma);
-check_flag(max_420chroma);
-check_flag(max_monochrome);
-check_flag(intra);
-check_flag(one_picture_only);
-check_flag(lower_bit_rate);
+#define check_flag(flag) \
+if (desc->flag < 2 && \
+desc->flag > ptl->general_ ## flag ## _constraint_flag) \
+return 0;
+check_flag(max_14bit);
+check_flag(max_12bit);
+check_flag(max_10bit);
+check_flag(max_8bit);
+check_flag(max_422chroma);
+check_flag(max_420chroma);
+check_flag(max_monochrome);
+check_flag(intra);
+check_flag(one_picture_only);
+check_flag(lower_bit_rate);
 #undef check_flag
 
-return profile;
+return 1;
+}
+
+
+const H265ProfileDescriptor *ff_h265_get_profile(enum H265Profile profile)
+{
+av_assert0(profile > H265_PROFILE_INVALID &&
+   profile < H265_PROFILE_COUNT);
+
+return &h265_profiles[profile];
+}
+
+const H265ProfileDescriptor *ff_h265_find_profile(const 
H265RawProfileTierLevel *ptl)
+{
+for (int p = 1; p < H265_PROFILE_COUNT; p++) {
+if (ff_h265_profile_compatible(ptl, p))
+return &h265_profiles[p];
 }
 
 return NULL;
@@ -171,12 +195,12 @@ const H265LevelDescriptor *ff_h265_guess_level(const 
H265RawProfileTierLevel *pt
 int i;
 
 if (ptl)
-profile = ff_h265_get_profile(ptl);
+profile = ff_h265_find_profile(ptl);
 else
 profile = NULL;
 if (!profile) {
 // Default to using multiplication factors for Main profile.
-profile = &h265_profiles[4];
+profile = &h265_profiles[H265_PROFILE_MAIN];
 }
 
 pic_size = width * height;
diff --git a/libavcodec/h265_profile_level.h b/libavcodec/h265_profile_level.h
index cd30ac5c50..c019c738a7 100644
--- a/libavcodec/h265_profile_level.h
+++ b/libavcodec/h265_profile_level.h
@@ -24,6 +24,50 @@
 #include "cbs_h265.h"
 
 
+// Enumeration of all H.265 profiles.
+// The list is ordered to match table A.10; numeric values are an index
+// into the latest version of this table and have no codec meaning.
+enum H265Profile {
+H265_PROFILE_INVALID,
+H265_PROFILE_MONOCHROME,
+H265_PROFILE_MONOCHRO

[FFmpeg-devel] [PATCH v3 2/3] lavc: Add test for H.265 profile handling

[Mark Thompson]

---
 libavcodec/Makefile  |   2 +-
 libavcodec/tests/.gitignore  |   1 +
 libavcodec/tests/h265_profiles.c | 440 +++
 tests/fate/libavcodec.mak|   5 +
 4 files changed, 447 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/tests/h265_profiles.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 8ab4398b6c..e7973fb2e6 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1297,7 +1297,7 @@ TESTPROGS-$(CONFIG_MJPEG_ENCODER) += 
mjpegenc_huffman
 TESTPROGS-$(HAVE_MMX) += motion
 TESTPROGS-$(CONFIG_MPEGVIDEO) += mpeg12framerate
 TESTPROGS-$(CONFIG_H264_METADATA_BSF) += h264_levels
-TESTPROGS-$(CONFIG_HEVC_METADATA_BSF) += h265_levels
+TESTPROGS-$(CONFIG_HEVC_METADATA_BSF) += h265_levels h265_profiles
 TESTPROGS-$(CONFIG_RANGECODER)+= rangecoder
 TESTPROGS-$(CONFIG_SNOW_ENCODER)  += snowenc
 
diff --git a/libavcodec/tests/.gitignore b/libavcodec/tests/.gitignore
index 0df4ae10a0..bf29f03911 100644
--- a/libavcodec/tests/.gitignore
+++ b/libavcodec/tests/.gitignore
@@ -10,6 +10,7 @@
 /golomb
 /h264_levels
 /h265_levels
+/h265_profiles
 /htmlsubtitles
 /iirfilter
 /jpeg2000dwt
diff --git a/libavcodec/tests/h265_profiles.c b/libavcodec/tests/h265_profiles.c
new file mode 100644
index 00..37fc545558
--- /dev/null
+++ b/libavcodec/tests/h265_profiles.c
@@ -0,0 +1,440 @@
+/*
+ * 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 "libavutil/bprint.h"
+#include "libavutil/common.h"
+#include "libavcodec/h265_profile_level.h"
+
+
+enum {
+TYPE_MAIN,
+TYPE_SP,
+TYPE_REXT_INTER,
+TYPE_REXT_INTRA,
+TYPE_HT,
+TYPE_HT_INTRA,
+TYPE_SCC,
+TYPE_HT_SCC,
+TYPE_COUNT,
+};
+enum {
+DEPTH_8,
+DEPTH_10,
+DEPTH_12,
+DEPTH_14,
+DEPTH_16,
+DEPTH_COUNT,
+};
+enum {
+CHROMA_MONO,
+CHROMA_420,
+CHROMA_422,
+CHROMA_444,
+CHROMA_COUNT,
+};
+
+// Table of all profiles indexed by chroma subsampling, bit depth and
+// profile type.  This is currently only being used to verify that
+// profile properties are correct, but if there is some other need for
+// this lookup in lavc then the table should be moved to the common
+// profile-level code.  All profiles should appear exactly once in this
+// table (also verified by a test below).
+static enum H265Profile profile_table[CHROMA_COUNT][DEPTH_COUNT][TYPE_COUNT] = 
{
+[CHROMA_MONO] = {
+[DEPTH_8] = {
+[TYPE_REXT_INTER] = H265_PROFILE_MONOCHROME,
+},
+[DEPTH_10] = {
+[TYPE_REXT_INTER] = H265_PROFILE_MONOCHROME_10,
+},
+[DEPTH_12] = {
+[TYPE_REXT_INTER] = H265_PROFILE_MONOCHROME_12,
+},
+[DEPTH_16] = {
+[TYPE_REXT_INTER] = H265_PROFILE_MONOCHROME_16,
+},
+},
+[CHROMA_420] = {
+[DEPTH_8] = {
+[TYPE_MAIN]   = H265_PROFILE_MAIN,
+[TYPE_SP] = H265_PROFILE_MAIN_STILL_PICTURE,
+[TYPE_REXT_INTRA] = H265_PROFILE_MAIN_INTRA,
+[TYPE_SCC]= H265_PROFILE_SCREEN_EXTENDED_MAIN,
+},
+[DEPTH_10] = {
+[TYPE_MAIN]   = H265_PROFILE_MAIN_10,
+[TYPE_SP] = H265_PROFILE_MAIN_10_STILL_PICTURE,
+[TYPE_REXT_INTRA] = H265_PROFILE_MAIN_10_INTRA,
+[TYPE_SCC]= H265_PROFILE_SCREEN_EXTENDED_MAIN_10,
+},
+[DEPTH_12] = {
+[TYPE_REXT_INTER] = H265_PROFILE_MAIN_12,
+[TYPE_REXT_INTRA] = H265_PROFILE_MAIN_12_INTRA,
+},
+},
+[CHROMA_422] ={
+[DEPTH_10] = {
+[TYPE_REXT_INTER] = H265_PROFILE_MAIN_422_10,
+[TYPE_REXT_INTRA] = H265_PROFILE_MAIN_422_10_INTRA,
+},
+[DEPTH_12] = {
+[TYPE_REXT_INTER] = H265_PROFILE_MAIN_422_12,
+[TYPE_REXT_INTRA] = H265_PROFILE_MAIN_422_12_INTRA,
+},
+},
+[CHROMA_444] ={
+[DEPTH_8] = {
+[TYPE_SP] = H265_PROFILE_MAIN_444_STILL_PICTURE,
+[TYPE_REXT_INTER] = H265_PROFILE_MAIN_444,
+[TYPE_REXT_INTRA] = H265_PROFILE_MAIN_444_INTRA,
+[TYPE_HT] = H265_PROFILE_HIGH_THROUGHPUT

[FFmpeg-devel] [PATCH v3 3/3] lavc/vaapi_hevc: Don't require exact profiles

[Mark Thompson]

Rather than turning the constraint flags into a single profile and then
searching for that profile (and failing if it doesn't match any profile
exactly), instead search all supported profiles and use the first one
which supports the given set of constraint flags.
---
 libavcodec/vaapi_decode.c | 45 +++---
 libavcodec/vaapi_hevc.c   | 99 ++-
 libavcodec/vaapi_hevc.h   |  4 +-
 3 files changed, 87 insertions(+), 61 deletions(-)

diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 7c91d50f7b..c9d8add69f 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -393,7 +393,9 @@ static const struct {
 enum AVCodecID codec_id;
 int codec_profile;
 VAProfile va_profile;
-VAProfile (*profile_parser)(AVCodecContext *avctx);
+VAProfile (*match_profile)(AVCodecContext *avctx,
+   const VAProfile *profile_list,
+   int profile_count);
 } vaapi_profile_map[] = {
 #define MAP(c, p, v, ...) { AV_CODEC_ID_ ## c, AV_PROFILE_ ## p, VAProfile ## 
v, __VA_ARGS__ }
 MAP(MPEG2VIDEO,  MPEG2_SIMPLE,MPEG2Simple ),
@@ -420,9 +422,9 @@ static const struct {
 #endif
 #if VA_CHECK_VERSION(1, 2, 0) && CONFIG_HEVC_VAAPI_HWACCEL
 MAP(HEVC,HEVC_REXT,   None,
- ff_vaapi_parse_hevc_rext_scc_profile ),
+ ff_vaapi_hevc_match_rext_scc_profile ),
 MAP(HEVC,HEVC_SCC,None,
- ff_vaapi_parse_hevc_rext_scc_profile ),
+ ff_vaapi_hevc_match_rext_scc_profile ),
 #endif
 MAP(MJPEG,   MJPEG_HUFFMAN_BASELINE_DCT,
   JPEGBaseline),
@@ -505,22 +507,33 @@ static int vaapi_decode_make_config(AVCodecContext *avctx,
 vaapi_profile_map[i].codec_profile == AV_PROFILE_UNKNOWN)
 profile_match = 1;
 
-va_profile = vaapi_profile_map[i].profile_parser ?
- vaapi_profile_map[i].profile_parser(avctx) :
- vaapi_profile_map[i].va_profile;
 codec_profile = vaapi_profile_map[i].codec_profile;
-
-for (j = 0; j < profile_count; j++) {
-if (va_profile == profile_list[j]) {
-exact_match = profile_match;
+if (vaapi_profile_map[i].match_profile) {
+va_profile =
+vaapi_profile_map[i].match_profile(avctx, profile_list,
+   profile_count);
+if (va_profile != VAProfileNone) {
+matched_va_profile = va_profile;
+matched_ff_profile = codec_profile;
+exact_match = 1;
 break;
 }
-}
-if (j < profile_count) {
-matched_va_profile = va_profile;
-matched_ff_profile = codec_profile;
-if (exact_match)
-break;
+} else {
+va_profile = vaapi_profile_map[i].va_profile;
+
+for (j = 0; j < profile_count; j++) {
+if (va_profile == profile_list[j]) {
+exact_match = profile_match;
+break;
+}
+}
+
+if (j < profile_count) {
+matched_va_profile = va_profile;
+matched_ff_profile = codec_profile;
+if (exact_match)
+break;
+}
 }
 }
 av_freep(&profile_list);
diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
index 6164a1d223..716a4a4b43 100644
--- a/libavcodec/vaapi_hevc.c
+++ b/libavcodec/vaapi_hevc.c
@@ -589,63 +589,74 @@ static int ptl_convert(const PTLCommon *general_ptl, 
H265RawProfileTierLevel *h2
 }
 
 /*
- * Find exact va_profile for HEVC Range Extension and Screen Content Coding 
Extension
+ * Find compatible va_profile for HEVC Range Extension and Screen
+ * Content Coding Extension profiles.
  */
-VAProfile ff_vaapi_parse_hevc_rext_scc_profile(AVCodecContext *avctx)
+VAProfile ff_vaapi_hevc_match_rext_scc_profile(AVCodecContext *avctx,
+   const VAProfile *profile_list,
+   int profile_count)
 {
 const HEVCContext *h = avctx->priv_data;
 const HEVCSPS *sps = h->ps.sps;
 const PTL *ptl = &sps->ptl;
 const PTLCommon *general_ptl = &ptl->general_ptl;
-const H265ProfileDescriptor *profile;
 H265RawProfileTierLevel h265_raw_ptl = {0};
 
+static const struct {
+enum H265Profile profile;
+VAProfile va_profile;
+} map[] = {
+#if VA_CHECK_VERSION(1, 2, 0)
+{ H265_PROFILE_MAIN_12,
+  VAProfileHEVCMain12 },
+{ H265_PROFILE_MAIN_422_10,
+  VAProfileHEVCMain422_10 },
+{ H265_PROFILE_MAIN_422_12,
+  VAProfileHEVCMain422_12 },
+{ H265_PROFILE_MAIN_444,
+  VAProfileHEVCMain444 },
+{ H265_PROFILE_MAIN_444_10,
+  VAProfile

[FFmpeg-devel] [PATCH] checkasm/sw_rgb: test rgb32/rgb32_1 to yuv

[James Almer]

Test all four pixel formats, but only bench the two native endian ones for a
given target.

Signed-off-by: James Almer 
---
 tests/checkasm/sw_rgb.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index b51d0836c3..cba6b87add 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -187,11 +187,15 @@ static const int input_sizes[] = {8, 128, 1080, 
MAX_LINE_SIZE};
 static const enum AVPixelFormat rgb_formats[] = {
 AV_PIX_FMT_RGB24,
 AV_PIX_FMT_BGR24,
+AV_PIX_FMT_RGBA,
+AV_PIX_FMT_BGRA,
+AV_PIX_FMT_ABGR,
+AV_PIX_FMT_ARGB,
 };
 
 static void check_rgb_to_y(struct SwsContext *ctx)
 {
-LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 4]);
 LOCAL_ALIGNED_32(uint8_t, dst0_y, [MAX_LINE_SIZE * 2]);
 LOCAL_ALIGNED_32(uint8_t, dst1_y, [MAX_LINE_SIZE * 2]);
 
@@ -199,7 +203,7 @@ static void check_rgb_to_y(struct SwsContext *ctx)
  const uint8_t *unused1, const uint8_t *unused2, int width,
  uint32_t *rgb2yuv, void *opq);
 
-randomize_buffers(src, MAX_LINE_SIZE * 3);
+randomize_buffers(src, MAX_LINE_SIZE * 4);
 
 for (int i = 0; i < FF_ARRAY_ELEMS(rgb_formats); i++) {
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(rgb_formats[i]);
@@ -220,7 +224,10 @@ static void check_rgb_to_y(struct SwsContext *ctx)
 if (memcmp(dst0_y, dst1_y, w * 2))
 fail();
 
-bench_new(dst1_y, src, NULL, NULL, w, 
ctx->input_rgb2yuv_table, NULL);
+if (desc->nb_components == 3 ||
+// only bench native endian formats
+(ctx->srcFormat == AV_PIX_FMT_RGB32 || ctx->srcFormat == 
AV_PIX_FMT_RGB32_1))
+bench_new(dst1_y, src, NULL, NULL, w, 
ctx->input_rgb2yuv_table, NULL);
 }
 }
 }
@@ -228,7 +235,7 @@ static void check_rgb_to_y(struct SwsContext *ctx)
 
 static void check_rgb_to_uv(struct SwsContext *ctx)
 {
-LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 4]);
 LOCAL_ALIGNED_32(uint8_t, dst0_u, [MAX_LINE_SIZE * 2]);
 LOCAL_ALIGNED_32(uint8_t, dst0_v, [MAX_LINE_SIZE * 2]);
 LOCAL_ALIGNED_32(uint8_t, dst1_u, [MAX_LINE_SIZE * 2]);
@@ -238,7 +245,7 @@ static void check_rgb_to_uv(struct SwsContext *ctx)
  const uint8_t *src1, const uint8_t *src2, const uint8_t *src3,
  int width, uint32_t *pal, void *opq);
 
-randomize_buffers(src, MAX_LINE_SIZE * 3);
+randomize_buffers(src, MAX_LINE_SIZE * 4);
 
 for (int i = 0; i < 2 * FF_ARRAY_ELEMS(rgb_formats); i++) {
 enum AVPixelFormat src_fmt = rgb_formats[i / 2];
@@ -266,7 +273,10 @@ static void check_rgb_to_uv(struct SwsContext *ctx)
 if (memcmp(dst0_u, dst1_u, w * 2) || memcmp(dst0_v, dst1_v, w 
* 2))
 fail();
 
-bench_new(dst1_u, dst1_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+if (desc->nb_components == 3 ||
+// only bench native endian formats
+(ctx->srcFormat == AV_PIX_FMT_RGB32 || ctx->srcFormat == 
AV_PIX_FMT_RGB32_1))
+bench_new(dst1_u, dst1_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
 }
 }
 }
-- 
2.45.1

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

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

[FFmpeg-devel] [PATCH] tests/checkasm/sw_rgb: Be more strict about clobbering MMX state

[Andreas Rheinhardt]

The MMXEXT versions of the rgb2rgb functions tested here
always emit emms on their own. Therefore one can use
a stricter test to ensure that it stays that way.

Signed-off-by: Andreas Rheinhardt 
---
 tests/checkasm/sw_rgb.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index b51d0836c3..47c3cdfcc8 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -53,7 +53,7 @@ static void check_shuffle_bytes(void * func, const char * 
report)
 LOCAL_ALIGNED_32(uint8_t, dst0, [MAX_STRIDE]);
 LOCAL_ALIGNED_32(uint8_t, dst1, [MAX_STRIDE]);
 
-declare_func_emms(AV_CPU_FLAG_MMX, void, const uint8_t *src, uint8_t *dst, 
int src_size);
+declare_func(void, const uint8_t *src, uint8_t *dst, int src_size);
 
 memset(dst0, 0, MAX_STRIDE);
 memset(dst1, 0, MAX_STRIDE);
@@ -84,9 +84,9 @@ static void check_uyvy_to_422p(void)
 LOCAL_ALIGNED_32(uint8_t, dst_v_0, [(MAX_STRIDE/2) * MAX_HEIGHT]);
 LOCAL_ALIGNED_32(uint8_t, dst_v_1, [(MAX_STRIDE/2) * MAX_HEIGHT]);
 
-declare_func_emms(AV_CPU_FLAG_MMX, void, uint8_t *ydst, uint8_t *udst, 
uint8_t *vdst,
-  const uint8_t *src, int width, int height,
-  int lumStride, int chromStride, int srcStride);
+declare_func(void, uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
+ const uint8_t *src, int width, int height,
+ int lumStride, int chromStride, int srcStride);
 
 randomize_buffers(src0, MAX_STRIDE * MAX_HEIGHT * 2);
 memcpy(src1, src0, MAX_STRIDE * MAX_HEIGHT * 2);
@@ -127,8 +127,8 @@ static void check_interleave_bytes(void)
 uint8_t *dst0 = dst0_buf + 2;
 uint8_t *dst1 = dst1_buf + 2;
 
-declare_func_emms(AV_CPU_FLAG_MMX, void, const uint8_t *, const uint8_t *,
-   uint8_t *, int, int, int, int, int);
+declare_func(void, const uint8_t *, const uint8_t *,
+ uint8_t *, int, int, int, int, int);
 
 randomize_buffers(src0, MAX_STRIDE * MAX_HEIGHT);
 randomize_buffers(src1, MAX_STRIDE * MAX_HEIGHT);
-- 
2.40.1

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

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

Re: [FFmpeg-devel] [PATCH] checkasm/sw_rgb: test rgb32/rgb32_1 to yuv

[Andreas Rheinhardt]

James Almer:
> Test all four pixel formats, but only bench the two native endian ones for a
> given target.
> 
> Signed-off-by: James Almer 
> ---
>  tests/checkasm/sw_rgb.c | 22 --
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
> index b51d0836c3..cba6b87add 100644
> --- a/tests/checkasm/sw_rgb.c
> +++ b/tests/checkasm/sw_rgb.c
> @@ -187,11 +187,15 @@ static const int input_sizes[] = {8, 128, 1080, 
> MAX_LINE_SIZE};
>  static const enum AVPixelFormat rgb_formats[] = {
>  AV_PIX_FMT_RGB24,
>  AV_PIX_FMT_BGR24,
> +AV_PIX_FMT_RGBA,
> +AV_PIX_FMT_BGRA,
> +AV_PIX_FMT_ABGR,
> +AV_PIX_FMT_ARGB,
>  };
>  
>  static void check_rgb_to_y(struct SwsContext *ctx)
>  {
> -LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
> +LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 4]);
>  LOCAL_ALIGNED_32(uint8_t, dst0_y, [MAX_LINE_SIZE * 2]);
>  LOCAL_ALIGNED_32(uint8_t, dst1_y, [MAX_LINE_SIZE * 2]);
>  
> @@ -199,7 +203,7 @@ static void check_rgb_to_y(struct SwsContext *ctx)
>   const uint8_t *unused1, const uint8_t *unused2, int width,
>   uint32_t *rgb2yuv, void *opq);
>  
> -randomize_buffers(src, MAX_LINE_SIZE * 3);
> +randomize_buffers(src, MAX_LINE_SIZE * 4);
>  
>  for (int i = 0; i < FF_ARRAY_ELEMS(rgb_formats); i++) {
>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(rgb_formats[i]);
> @@ -220,7 +224,10 @@ static void check_rgb_to_y(struct SwsContext *ctx)
>  if (memcmp(dst0_y, dst1_y, w * 2))
>  fail();
>  
> -bench_new(dst1_y, src, NULL, NULL, w, 
> ctx->input_rgb2yuv_table, NULL);
> +if (desc->nb_components == 3 ||
> +// only bench native endian formats
> +(ctx->srcFormat == AV_PIX_FMT_RGB32 || ctx->srcFormat == 
> AV_PIX_FMT_RGB32_1))
> +bench_new(dst1_y, src, NULL, NULL, w, 
> ctx->input_rgb2yuv_table, NULL);
>  }
>  }
>  }
> @@ -228,7 +235,7 @@ static void check_rgb_to_y(struct SwsContext *ctx)
>  
>  static void check_rgb_to_uv(struct SwsContext *ctx)
>  {
> -LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
> +LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 4]);

Doesn't this make the test less strict wrt overreading for tests that
are only supposed to use MAX_LINE_SIZE * 3?

>  LOCAL_ALIGNED_32(uint8_t, dst0_u, [MAX_LINE_SIZE * 2]);
>  LOCAL_ALIGNED_32(uint8_t, dst0_v, [MAX_LINE_SIZE * 2]);
>  LOCAL_ALIGNED_32(uint8_t, dst1_u, [MAX_LINE_SIZE * 2]);
> @@ -238,7 +245,7 @@ static void check_rgb_to_uv(struct SwsContext *ctx)
>   const uint8_t *src1, const uint8_t *src2, const uint8_t 
> *src3,
>   int width, uint32_t *pal, void *opq);
>  
> -randomize_buffers(src, MAX_LINE_SIZE * 3);
> +randomize_buffers(src, MAX_LINE_SIZE * 4);
>  
>  for (int i = 0; i < 2 * FF_ARRAY_ELEMS(rgb_formats); i++) {
>  enum AVPixelFormat src_fmt = rgb_formats[i / 2];
> @@ -266,7 +273,10 @@ static void check_rgb_to_uv(struct SwsContext *ctx)
>  if (memcmp(dst0_u, dst1_u, w * 2) || memcmp(dst0_v, dst1_v, 
> w * 2))
>  fail();
>  
> -bench_new(dst1_u, dst1_v, NULL, src, src, w, 
> ctx->input_rgb2yuv_table, NULL);
> +if (desc->nb_components == 3 ||
> +// only bench native endian formats
> +(ctx->srcFormat == AV_PIX_FMT_RGB32 || ctx->srcFormat == 
> AV_PIX_FMT_RGB32_1))
> +bench_new(dst1_u, dst1_v, NULL, src, src, w, 
> ctx->input_rgb2yuv_table, NULL);
>  }
>  }
>  }

___
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] tests/checkasm/sw_rgb: Be more strict about clobbering MMX state

[James Almer]

On 6/5/2024 5:08 PM, Andreas Rheinhardt wrote:

The MMXEXT versions of the rgb2rgb functions tested here
always emit emms on their own. Therefore one can use
a stricter test to ensure that it stays that way.


Or we could nuke it in favor of an SSE2 version :p



Signed-off-by: Andreas Rheinhardt 
---
  tests/checkasm/sw_rgb.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index b51d0836c3..47c3cdfcc8 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -53,7 +53,7 @@ static void check_shuffle_bytes(void * func, const char * 
report)
  LOCAL_ALIGNED_32(uint8_t, dst0, [MAX_STRIDE]);
  LOCAL_ALIGNED_32(uint8_t, dst1, [MAX_STRIDE]);
  
-declare_func_emms(AV_CPU_FLAG_MMX, void, const uint8_t *src, uint8_t *dst, int src_size);

+declare_func(void, const uint8_t *src, uint8_t *dst, int src_size);
  
  memset(dst0, 0, MAX_STRIDE);

  memset(dst1, 0, MAX_STRIDE);
@@ -84,9 +84,9 @@ static void check_uyvy_to_422p(void)
  LOCAL_ALIGNED_32(uint8_t, dst_v_0, [(MAX_STRIDE/2) * MAX_HEIGHT]);
  LOCAL_ALIGNED_32(uint8_t, dst_v_1, [(MAX_STRIDE/2) * MAX_HEIGHT]);
  
-declare_func_emms(AV_CPU_FLAG_MMX, void, uint8_t *ydst, uint8_t *udst, uint8_t *vdst,

-  const uint8_t *src, int width, int height,
-  int lumStride, int chromStride, int srcStride);
+declare_func(void, uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
+ const uint8_t *src, int width, int height,
+ int lumStride, int chromStride, int srcStride);
  
  randomize_buffers(src0, MAX_STRIDE * MAX_HEIGHT * 2);

  memcpy(src1, src0, MAX_STRIDE * MAX_HEIGHT * 2);
@@ -127,8 +127,8 @@ static void check_interleave_bytes(void)
  uint8_t *dst0 = dst0_buf + 2;
  uint8_t *dst1 = dst1_buf + 2;
  
-declare_func_emms(AV_CPU_FLAG_MMX, void, const uint8_t *, const uint8_t *,

-   uint8_t *, int, int, int, int, int);
+declare_func(void, const uint8_t *, const uint8_t *,
+ uint8_t *, int, int, int, int, int);
  
  randomize_buffers(src0, MAX_STRIDE * MAX_HEIGHT);

  randomize_buffers(src1, MAX_STRIDE * MAX_HEIGHT);

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

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

[FFmpeg-devel] [PATCH v5 1/2] configure, lavu, lavc, lavfi: Remove libva 1.x support

[Mark Thompson]

libva 2.0 was released in 2017 and the 2.x versions are included in all
supported distributions nowadays.  Various features no longer need any
configure check after this change, including all codecs except AV1.
Note that the libva version is the API version plus one, so this is
removing support for VAAPI 0.x and requiring VAAPI 1.x.
---
Now squashed.


 configure  | 25 +++
 libavcodec/vaapi_decode.c  | 39 ++---
 libavcodec/vaapi_encode.c  | 78 ++
 libavcodec/vaapi_encode.h  |  9 
 libavcodec/vaapi_encode_h264.c | 18 
 libavcodec/vaapi_encode_h265.c |  2 -
 libavfilter/vaapi_vpp.c| 22 --
 libavutil/hwcontext_vaapi.c| 22 --
 8 files changed, 29 insertions(+), 186 deletions(-)

diff --git a/configure b/configure
index 6c5b8aab9a..06e6fa22f2 100755
--- a/configure
+++ b/configure
@@ -2630,7 +2630,6 @@ CONFIG_EXTRA="
 texturedsp
 texturedspenc
 tpeldsp
-vaapi_1
 vaapi_encode
 vc1dsp
 videodsp
@@ -3200,7 +3199,7 @@ hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
 hevc_dxva2_hwaccel_select="hevc_decoder"
 hevc_nvdec_hwaccel_deps="nvdec"
 hevc_nvdec_hwaccel_select="hevc_decoder"
-hevc_vaapi_hwaccel_deps="vaapi VAPictureParameterBufferHEVC"
+hevc_vaapi_hwaccel_deps="vaapi"
 hevc_vaapi_hwaccel_select="hevc_decoder"
 hevc_vdpau_hwaccel_deps="vdpau VdpPictureInfoHEVC"
 hevc_vdpau_hwaccel_select="hevc_decoder"
@@ -3272,7 +3271,7 @@ vp9_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_VP9"
 vp9_dxva2_hwaccel_select="vp9_decoder"
 vp9_nvdec_hwaccel_deps="nvdec"
 vp9_nvdec_hwaccel_select="vp9_decoder"
-vp9_vaapi_hwaccel_deps="vaapi VADecPictureParameterBufferVP9_bit_depth"
+vp9_vaapi_hwaccel_deps="vaapi"
 vp9_vaapi_hwaccel_select="vp9_decoder"
 vp9_vdpau_hwaccel_deps="vdpau VdpPictureInfoVP9"
 vp9_vdpau_hwaccel_select="vp9_decoder"
@@ -3365,7 +3364,6 @@ hevc_qsv_decoder_select="hevc_mp4toannexb_bsf qsvdec"
 hevc_qsv_encoder_select="hevcparse qsvenc"
 hevc_rkmpp_decoder_deps="rkmpp"
 hevc_rkmpp_decoder_select="hevc_mp4toannexb_bsf"
-hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC"
 hevc_vaapi_encoder_select="atsc_a53 cbs_h265 vaapi_encode"
 hevc_v4l2m2m_decoder_deps="v4l2_m2m hevc_v4l2_m2m"
 hevc_v4l2m2m_decoder_select="hevc_mp4toannexb_bsf"
@@ -3374,7 +3372,6 @@ mjpeg_cuvid_decoder_deps="cuvid"
 mjpeg_qsv_decoder_select="qsvdec"
 mjpeg_qsv_encoder_deps="libmfx"
 mjpeg_qsv_encoder_select="qsvenc"
-mjpeg_vaapi_encoder_deps="VAEncPictureParameterBufferJPEG"
 mjpeg_vaapi_encoder_select="cbs_jpeg jpegtables vaapi_encode"
 mp3_mf_encoder_deps="mediafoundation"
 mpeg1_cuvid_decoder_deps="cuvid"
@@ -3403,7 +3400,6 @@ vp8_mediacodec_decoder_deps="mediacodec"
 vp8_mediacodec_encoder_deps="mediacodec"
 vp8_qsv_decoder_select="qsvdec"
 vp8_rkmpp_decoder_deps="rkmpp"
-vp8_vaapi_encoder_deps="VAEncPictureParameterBufferVP8"
 vp8_vaapi_encoder_select="vaapi_encode"
 vp8_v4l2m2m_decoder_deps="v4l2_m2m vp8_v4l2_m2m"
 vp8_v4l2m2m_encoder_deps="v4l2_m2m vp8_v4l2_m2m"
@@ -3412,7 +3408,6 @@ vp9_mediacodec_decoder_deps="mediacodec"
 vp9_mediacodec_encoder_deps="mediacodec"
 vp9_qsv_decoder_select="qsvdec"
 vp9_rkmpp_decoder_deps="rkmpp"
-vp9_vaapi_encoder_deps="VAEncPictureParameterBufferVP9"
 vp9_vaapi_encoder_select="vaapi_encode"
 vp9_qsv_encoder_deps="libmfx MFX_CODEC_VP9"
 vp9_qsv_encoder_select="qsvenc"
@@ -3966,9 +3961,9 @@ xfade_vulkan_filter_deps="vulkan spirv_compiler"
 yadif_cuda_filter_deps="ffnvcodec"
 yadif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
 yadif_videotoolbox_filter_deps="metal corevideo videotoolbox"
-hstack_vaapi_filter_deps="vaapi_1"
-vstack_vaapi_filter_deps="vaapi_1"
-xstack_vaapi_filter_deps="vaapi_1"
+hstack_vaapi_filter_deps="vaapi"
+vstack_vaapi_filter_deps="vaapi"
+xstack_vaapi_filter_deps="vaapi"
 hstack_qsv_filter_deps="libmfx"
 hstack_qsv_filter_select="qsvvpp"
 vstack_qsv_filter_deps="libmfx"
@@ -7271,7 +7266,7 @@ enabled libdrm &&
 check_pkg_config libdrm_getfb2 libdrm "xf86drmMode.h" drmModeGetFB2
 
 enabled vaapi &&
-check_pkg_config vaapi "libva >= 0.35.0" "va/va.h" vaInitialize
+check_pkg_config vaapi "libva >= 1.0.0" "va/va.h" vaInitialize
 
 if enabled vaapi; then
 case $target_os in
@@ -7287,18 +7282,10 @@ if enabled vaapi; then
 check_pkg_config vaapi_x11 "libva-x11" "va/va_x11.h" vaGetDisplay
 fi
 
-check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0, 0)"
-
-check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
-check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
 check_struct "va/va.h" "VADecPictureParameterBufferAV1" bit_depth_idx
 check_type   "va/va.h va/va_vpp.h" 
"VAProcFilterParameterBufferHDRToneMapping"
 check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
 check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" blend_flags
-check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
-check_type "va/va.h

[FFmpeg-devel] [PATCH v5 2/2] hwcontext_vaapi: Deprecate quirks

[Mark Thompson]

These only apply to obsolete drivers which do not work with the
now-required libva 2.x.
---
Fixed checkheaders.


 libavutil/hwcontext_vaapi.c | 123 ++--
 libavutil/hwcontext_vaapi.h |  17 +
 2 files changed, 52 insertions(+), 88 deletions(-)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index caff43d1ae..8591fb88ac 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -243,8 +243,7 @@ static int vaapi_frames_get_constraints(AVHWDeviceContext 
*hwdev,
 unsigned int fourcc;
 int err, i, j, attr_count, pix_fmt_count;
 
-if (config &&
-!(hwctx->driver_quirks & AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES)) {
+if (config) {
 attr_count = 0;
 vas = vaQuerySurfaceAttributes(hwctx->display, config->config_id,
0, &attr_count);
@@ -367,23 +366,6 @@ fail:
 return err;
 }
 
-static const struct {
-const char *friendly_name;
-const char *match_string;
-unsigned int quirks;
-} vaapi_driver_quirks_table[] = {
-{
-"Intel iHD",
-"ubit",
-AV_VAAPI_DRIVER_QUIRK_ATTRIB_MEMTYPE,
-},
-{
-"VDPAU wrapper",
-"Splitted-Desktop Systems VDPAU backend for VA-API",
-AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES,
-},
-};
-
 static int vaapi_device_init(AVHWDeviceContext *hwdev)
 {
 VAAPIDeviceContext *ctx = hwdev->hwctx;
@@ -436,36 +418,6 @@ static int vaapi_device_init(AVHWDeviceContext *hwdev)
 if (vendor_string)
 av_log(hwdev, AV_LOG_VERBOSE, "VAAPI driver: %s.\n", vendor_string);
 
-if (hwctx->driver_quirks & AV_VAAPI_DRIVER_QUIRK_USER_SET) {
-av_log(hwdev, AV_LOG_VERBOSE, "Using quirks set by user (%#x).\n",
-   hwctx->driver_quirks);
-} else {
-// Detect the driver in use and set quirk flags if necessary.
-hwctx->driver_quirks = 0;
-if (vendor_string) {
-for (i = 0; i < FF_ARRAY_ELEMS(vaapi_driver_quirks_table); i++) {
-if (strstr(vendor_string,
-   vaapi_driver_quirks_table[i].match_string)) {
-av_log(hwdev, AV_LOG_VERBOSE, "Matched driver string "
-   "as known nonstandard driver \"%s\", setting "
-   "quirks (%#x).\n",
-   vaapi_driver_quirks_table[i].friendly_name,
-   vaapi_driver_quirks_table[i].quirks);
-hwctx->driver_quirks |=
-vaapi_driver_quirks_table[i].quirks;
-break;
-}
-}
-if (!(i < FF_ARRAY_ELEMS(vaapi_driver_quirks_table))) {
-av_log(hwdev, AV_LOG_VERBOSE, "Driver not found in known "
-   "nonstandard list, using standard behaviour.\n");
-}
-} else {
-av_log(hwdev, AV_LOG_VERBOSE, "Driver has no vendor string, "
-   "assuming standard behaviour.\n");
-}
-}
-
 av_free(image_list);
 return 0;
 fail:
@@ -562,48 +514,43 @@ static int vaapi_frames_init(AVHWFramesContext *hwfc)
 }
 
 if (!hwfc->pool) {
-if (!(hwctx->driver_quirks & 
AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES)) {
-int need_memory_type = !(hwctx->driver_quirks & 
AV_VAAPI_DRIVER_QUIRK_ATTRIB_MEMTYPE);
-int need_pixel_format = 1;
-for (i = 0; i < avfc->nb_attributes; i++) {
-if (avfc->attributes[i].type == VASurfaceAttribMemoryType)
-need_memory_type  = 0;
-if (avfc->attributes[i].type == VASurfaceAttribPixelFormat)
-need_pixel_format = 0;
-}
-ctx->nb_attributes =
-avfc->nb_attributes + need_memory_type + need_pixel_format;
+int need_memory_type  = 1;
+int need_pixel_format = 1;
+for (i = 0; i < avfc->nb_attributes; i++) {
+if (avfc->attributes[i].type == VASurfaceAttribMemoryType)
+need_memory_type  = 0;
+if (avfc->attributes[i].type == VASurfaceAttribPixelFormat)
+need_pixel_format = 0;
+}
+ctx->nb_attributes =
+avfc->nb_attributes + need_memory_type + need_pixel_format;
 
-ctx->attributes = av_malloc(ctx->nb_attributes *
-sizeof(*ctx->attributes));
-if (!ctx->attributes) {
-err = AVERROR(ENOMEM);
-goto fail;
-}
+ctx->attributes = av_malloc(ctx->nb_attributes *
+sizeof(*ctx->attributes));
+if (!ctx->attributes) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
 
-for (i = 0; i < avfc->nb_attributes; i++)
-ctx->attributes[i] = avfc->attributes[i];
-if (need_memory_type) {
-ctx->attributes

Re: [FFmpeg-devel] [PATCH] checkasm/sw_rgb: test rgb32/rgb32_1 to yuv

[James Almer]

On 6/5/2024 5:10 PM, Andreas Rheinhardt wrote:

James Almer:

Test all four pixel formats, but only bench the two native endian ones for a
given target.

Signed-off-by: James Almer 
---
  tests/checkasm/sw_rgb.c | 22 --
  1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index b51d0836c3..cba6b87add 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -187,11 +187,15 @@ static const int input_sizes[] = {8, 128, 1080, 
MAX_LINE_SIZE};
  static const enum AVPixelFormat rgb_formats[] = {
  AV_PIX_FMT_RGB24,
  AV_PIX_FMT_BGR24,
+AV_PIX_FMT_RGBA,
+AV_PIX_FMT_BGRA,
+AV_PIX_FMT_ABGR,
+AV_PIX_FMT_ARGB,
  };
  
  static void check_rgb_to_y(struct SwsContext *ctx)

  {
-LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 4]);
  LOCAL_ALIGNED_32(uint8_t, dst0_y, [MAX_LINE_SIZE * 2]);
  LOCAL_ALIGNED_32(uint8_t, dst1_y, [MAX_LINE_SIZE * 2]);
  
@@ -199,7 +203,7 @@ static void check_rgb_to_y(struct SwsContext *ctx)

   const uint8_t *unused1, const uint8_t *unused2, int width,
   uint32_t *rgb2yuv, void *opq);
  
-randomize_buffers(src, MAX_LINE_SIZE * 3);

+randomize_buffers(src, MAX_LINE_SIZE * 4);
  
  for (int i = 0; i < FF_ARRAY_ELEMS(rgb_formats); i++) {

  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(rgb_formats[i]);
@@ -220,7 +224,10 @@ static void check_rgb_to_y(struct SwsContext *ctx)
  if (memcmp(dst0_y, dst1_y, w * 2))
  fail();
  
-bench_new(dst1_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table, NULL);

+if (desc->nb_components == 3 ||
+// only bench native endian formats
+(ctx->srcFormat == AV_PIX_FMT_RGB32 || ctx->srcFormat == 
AV_PIX_FMT_RGB32_1))
+bench_new(dst1_y, src, NULL, NULL, w, 
ctx->input_rgb2yuv_table, NULL);
  }
  }
  }
@@ -228,7 +235,7 @@ static void check_rgb_to_y(struct SwsContext *ctx)
  
  static void check_rgb_to_uv(struct SwsContext *ctx)

  {
-LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 4]);


Doesn't this make the test less strict wrt overreading for tests that
are only supposed to use MAX_LINE_SIZE * 3?


Probably. Want me to add a second src buffer for this?




  LOCAL_ALIGNED_32(uint8_t, dst0_u, [MAX_LINE_SIZE * 2]);
  LOCAL_ALIGNED_32(uint8_t, dst0_v, [MAX_LINE_SIZE * 2]);
  LOCAL_ALIGNED_32(uint8_t, dst1_u, [MAX_LINE_SIZE * 2]);
@@ -238,7 +245,7 @@ static void check_rgb_to_uv(struct SwsContext *ctx)
   const uint8_t *src1, const uint8_t *src2, const uint8_t 
*src3,
   int width, uint32_t *pal, void *opq);
  
-randomize_buffers(src, MAX_LINE_SIZE * 3);

+randomize_buffers(src, MAX_LINE_SIZE * 4);
  
  for (int i = 0; i < 2 * FF_ARRAY_ELEMS(rgb_formats); i++) {

  enum AVPixelFormat src_fmt = rgb_formats[i / 2];
@@ -266,7 +273,10 @@ static void check_rgb_to_uv(struct SwsContext *ctx)
  if (memcmp(dst0_u, dst1_u, w * 2) || memcmp(dst0_v, dst1_v, w 
* 2))
  fail();
  
-bench_new(dst1_u, dst1_v, NULL, src, src, w, ctx->input_rgb2yuv_table, NULL);

+if (desc->nb_components == 3 ||
+// only bench native endian formats
+(ctx->srcFormat == AV_PIX_FMT_RGB32 || ctx->srcFormat == 
AV_PIX_FMT_RGB32_1))
+bench_new(dst1_u, dst1_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
  }
  }
  }


___
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 05/16] avutil: add common code for nvtegra

[Mark Thompson]

On 30/05/2024 20:43, averne wrote:
> This includes a new pixel format for nvtegra hardware frames, and several 
> objects for interaction with hardware blocks.
> In particular, this contains code for channels (handles to hardware engines), 
> maps (memory-mapped buffers shared with engines), and command buffers 
> (abstraction for building command lists sent to the engines).
> 
> Signed-off-by: averne 
> ---
>  configure  |2 +
>  libavutil/Makefile |4 +
>  libavutil/nvtegra.c| 1035 
>  libavutil/nvtegra.h|  258 +
>  libavutil/nvtegra_host1x.h |   94 
>  libavutil/pixdesc.c|4 +
>  libavutil/pixfmt.h |8 +
>  7 files changed, 1405 insertions(+)
>  create mode 100644 libavutil/nvtegra.c
>  create mode 100644 libavutil/nvtegra.h
>  create mode 100644 libavutil/nvtegra_host1x.h

I don't think it is reasonable for all of this to be public API surface of 
ffmpeg.

A separate library containing the headers and exposing some set of functions 
like this might make more sense.

If this has to be in ffmpeg then it really needs to all go in one library 
(libavcodec I guess) so that it's not exposing all this internal detail in the 
public API.

Thanks,

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

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

[FFmpeg-devel] [PATCH 1/2] swscale/x86/input: add AVX2 optimized RGB32 to YUV functions

[James Almer]

abgr_to_uv_8_c: 43.3
abgr_to_uv_8_sse2: 14.3
abgr_to_uv_8_avx: 15.3
abgr_to_uv_8_avx2: 18.8
abgr_to_uv_128_c: 650.3
abgr_to_uv_128_sse2: 110.8
abgr_to_uv_128_avx: 112.3
abgr_to_uv_128_avx2: 64.8
abgr_to_uv_1080_c: 5456.3
abgr_to_uv_1080_sse2: 888.8
abgr_to_uv_1080_avx: 900.8
abgr_to_uv_1080_avx2: 518.3
abgr_to_uv_1920_c: 9692.3
abgr_to_uv_1920_sse2: 1593.8
abgr_to_uv_1920_avx: 1613.3
abgr_to_uv_1920_avx2: 864.8
abgr_to_y_8_c: 23.3
abgr_to_y_8_sse2: 12.8
abgr_to_y_8_avx: 13.3
abgr_to_y_8_avx2: 17.3
abgr_to_y_128_c: 308.3
abgr_to_y_128_sse2: 67.3
abgr_to_y_128_avx: 66.8
abgr_to_y_128_avx2: 44.8
abgr_to_y_1080_c: 2371.3
abgr_to_y_1080_sse2: 512.8
abgr_to_y_1080_avx: 505.8
abgr_to_y_1080_avx2: 314.3
abgr_to_y_1920_c: 4177.3
abgr_to_y_1920_sse2: 915.8
abgr_to_y_1920_avx: 926.8
abgr_to_y_1920_avx2: 519.3
bgra_to_uv_8_c: 37.3
bgra_to_uv_8_sse2: 13.3
bgra_to_uv_8_avx: 14.8
bgra_to_uv_8_avx2: 19.8
bgra_to_uv_128_c: 563.8
bgra_to_uv_128_sse2: 111.3
bgra_to_uv_128_avx: 112.3
bgra_to_uv_128_avx2: 64.8
bgra_to_uv_1080_c: 4691.8
bgra_to_uv_1080_sse2: 893.8
bgra_to_uv_1080_avx: 899.8
bgra_to_uv_1080_avx2: 517.8
bgra_to_uv_1920_c: 8332.8
bgra_to_uv_1920_sse2: 1590.8
bgra_to_uv_1920_avx: 1605.8
bgra_to_uv_1920_avx2: 867.3
bgra_to_y_8_c: 22.3
bgra_to_y_8_sse2: 12.8
bgra_to_y_8_avx: 12.8
bgra_to_y_8_avx2: 17.3
bgra_to_y_128_c: 291.3
bgra_to_y_128_sse2: 67.8
bgra_to_y_128_avx: 69.3
bgra_to_y_128_avx2: 45.3
bgra_to_y_1080_c: 2357.3
bgra_to_y_1080_sse2: 508.3
bgra_to_y_1080_avx: 518.3
bgra_to_y_1080_avx2: 399.8
bgra_to_y_1920_c: 4202.8
bgra_to_y_1920_sse2: 906.8
bgra_to_y_1920_avx: 907.3
bgra_to_y_1920_avx2: 526.3

Signed-off-by: James Almer 
---
 libswscale/x86/input.asm | 51 
 libswscale/x86/swscale.c |  8 +++
 2 files changed, 55 insertions(+), 4 deletions(-)

diff --git a/libswscale/x86/input.asm b/libswscale/x86/input.asm
index e79fe11405..f1ad6a53fd 100644
--- a/libswscale/x86/input.asm
+++ b/libswscale/x86/input.asm
@@ -380,8 +380,13 @@ RGB24_FUNCS 11, 13
 ; %2-5 = rgba, bgra, argb or abgr (in individual characters)
 %macro RGB32_TO_Y_FN 5-6
 cglobal %2%3%4%5 %+ ToY, 6, 6, %1, dst, src, u1, u2, w, table
+%if mmsize == 32
+vbroadcasti128 m5, [rgba_Ycoeff_%2%4]
+vbroadcasti128 m6, [rgba_Ycoeff_%3%5]
+%else
 mova   m5, [rgba_Ycoeff_%2%4]
 mova   m6, [rgba_Ycoeff_%3%5]
+%endif
 %if %0 == 6
 jmp mangle(private_prefix %+ _ %+ %6 %+ ToY %+ SUFFIX).body
 %else ; %0 == 6
@@ -394,13 +399,21 @@ cglobal %2%3%4%5 %+ ToY, 6, 6, %1, dst, src, u1, u2, w, 
table
 lea  srcq, [srcq+wq*2]
 add  dstq, wq
 negwq
+%if mmsize == 32
+vbroadcasti128 m4, [rgb_Yrnd]
+%else
 mova   m4, [rgb_Yrnd]
+%endif
 pcmpeqbm7, m7
 psrlw  m7, 8  ; (word) { 0x00ff } x4
 .loop:
 ; FIXME check alignment and use mova
-movu   m0, [srcq+wq*2+0]  ; (byte) { Bx, Gx, Rx, xx }[0-3]
-movu   m2, [srcq+wq*2+mmsize] ; (byte) { Bx, Gx, Rx, xx }[4-7]
+movu  xm0, [srcq+wq*2+0]  ; (byte) { Bx, Gx, Rx, xx }[0-3]
+movu  xm2, [srcq+wq*2+16] ; (byte) { Bx, Gx, Rx, xx }[4-7]
+%if mmsize == 32
+vinserti128m0, m0, [srcq+wq*2+32], 1
+vinserti128m2, m2, [srcq+wq*2+48], 1
+%endif
 DEINTB  1,  0,  3,  2,  7 ; (word) { Gx, xx (m0/m2) or Bx, Rx 
(m1/m3) }[0-3]/[4-7]
 pmaddwdm1, m5 ; (dword) { Bx*BY + Rx*RY }[0-3]
 pmaddwdm0, m6 ; (dword) { Gx*GY }[0-3]
@@ -421,6 +434,7 @@ cglobal %2%3%4%5 %+ ToY, 6, 6, %1, dst, src, u1, u2, w, 
table
 addsrcq, 2*mmsize - 2
 adddstq, mmsize - 1
 .loop2:
+INIT_XMM cpuname
 movd   m0, [srcq+wq*2+0]  ; (byte) { Bx, Gx, Rx, xx }[0-3]
 DEINTB  1,  0,  3,  2,  7 ; (word) { Gx, xx (m0/m2) or Bx, Rx 
(m1/m3) }[0-3]/[4-7]
 pmaddwdm1, m5 ; (dword) { Bx*BY + Rx*RY }[0-3]
@@ -433,6 +447,9 @@ cglobal %2%3%4%5 %+ ToY, 6, 6, %1, dst, src, u1, u2, w, 
table
 addwq, 2
 jl .loop2
 .end:
+%if cpuflag(avx2)
+INIT_YMM cpuname
+%endif
 RET
 %endif ; %0 == 3
 %endmacro
@@ -442,10 +459,17 @@ cglobal %2%3%4%5 %+ ToY, 6, 6, %1, dst, src, u1, u2, w, 
table
 %macro RGB32_TO_UV_FN 5-6
 cglobal %2%3%4%5 %+ ToUV, 7, 7, %1, dstU, dstV, u1, src, u2, w, table
 %if ARCH_X86_64
+%if mmsize == 32
+vbroadcasti128  m8, [rgba_Ucoeff_%2%4]
+vbroadcasti128  m9, [rgba_Ucoeff_%3%5]
+vbroadcasti128 m10, [rgba_Vcoeff_%2%4]
+vbroadcasti128 m11, [rgba_Vcoeff_%3%5]
+%else
 mova   m8, [rgba_Ucoeff_%2%4]
 mova   m9, [rgba_Ucoeff_%3%5]
 mova  m10, [rgba_Vcoeff_%2%4]
 mova  m11, [rgba_Vcoeff_%3%5]
+%endif
 %define coeffU1 m8
 %define coeffU2 m9
 %define coeffV1 m10
@@ -473,11 +497,19 @@ cglobal %2%3%4%5 %+ ToUV, 7, 7, %1, dstU, dstV, u1, src, 
u2, w, table
 negwq
 pcmpeqbm7, m7
 ps

[FFmpeg-devel] [PATCH 2/2] swscale/x86/input: add AVX2 optimized uyvytoyuv422

[James Almer]

uyvytoyuv422_c: 23991.8
uyvytoyuv422_sse2: 2817.8
uyvytoyuv422_avx: 2819.3
uyvytoyuv422_avx2: 1972.3

Signed-off-by: James Almer 
---
 libswscale/x86/rgb2rgb.c |  6 ++
 libswscale/x86/rgb_2_rgb.asm | 32 
 2 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/libswscale/x86/rgb2rgb.c b/libswscale/x86/rgb2rgb.c
index b325e5dbd5..21ccfafe51 100644
--- a/libswscale/x86/rgb2rgb.c
+++ b/libswscale/x86/rgb2rgb.c
@@ -136,6 +136,9 @@ void ff_uyvytoyuv422_sse2(uint8_t *ydst, uint8_t *udst, 
uint8_t *vdst,
 void ff_uyvytoyuv422_avx(uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
  const uint8_t *src, int width, int height,
  int lumStride, int chromStride, int srcStride);
+void ff_uyvytoyuv422_avx2(uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
+  const uint8_t *src, int width, int height,
+  int lumStride, int chromStride, int srcStride);
 #endif
 
 av_cold void rgb2rgb_init_x86(void)
@@ -177,5 +180,8 @@ av_cold void rgb2rgb_init_x86(void)
 if (EXTERNAL_AVX(cpu_flags)) {
 uyvytoyuv422 = ff_uyvytoyuv422_avx;
 }
+if (EXTERNAL_AVX2_FAST(cpu_flags)) {
+uyvytoyuv422 = ff_uyvytoyuv422_avx2;
+}
 #endif
 }
diff --git a/libswscale/x86/rgb_2_rgb.asm b/libswscale/x86/rgb_2_rgb.asm
index 76ca1eec03..0bf1278718 100644
--- a/libswscale/x86/rgb_2_rgb.asm
+++ b/libswscale/x86/rgb_2_rgb.asm
@@ -34,13 +34,16 @@ pb_shuffle3210: db 3, 2, 1, 0, 7, 6, 5, 4, 11, 10, 9, 8, 
15, 14, 13, 12
 
 SECTION .text
 
-%macro RSHIFT_COPY 3
+%macro RSHIFT_COPY 5
 ; %1 dst ; %2 src ; %3 shift
-%if cpuflag(avx)
-psrldq  %1, %2, %3
+%if mmsize == 32
+vperm2i128 %1, %2, %3, %5
+RSHIFT %1, %4
+%elif cpuflag(avx)
+psrldq  %1, %2, %4
 %else
 mova   %1, %2
-RSHIFT %1, %3
+RSHIFT %1, %4
 %endif
 %endmacro
 
@@ -233,26 +236,37 @@ cglobal uyvytoyuv422, 9, 14, 8, ydst, udst, vdst, src, w, 
h, lum_stride, chrom_s
 jge .end_line
 
 .loop_simd:
+%if mmsize == 32
+movu   xm2, [srcq + wtwoq ]
+movu   xm3, [srcq + wtwoq + 16]
+movu   xm4, [srcq + wtwoq + 16 * 2]
+movu   xm5, [srcq + wtwoq + 16 * 3]
+vinserti128 m2, m2, [srcq + wtwoq + 16 * 4], 1
+vinserti128 m3, m3, [srcq + wtwoq + 16 * 5], 1
+vinserti128 m4, m4, [srcq + wtwoq + 16 * 6], 1
+vinserti128 m5, m5, [srcq + wtwoq + 16 * 7], 1
+%else
 movum2, [srcq + wtwoq ]
 movum3, [srcq + wtwoq + mmsize]
 movum4, [srcq + wtwoq + mmsize * 2]
 movum5, [srcq + wtwoq + mmsize * 3]
+%endif
 
 ; extract y part 1
-RSHIFT_COPYm6, m2, 1 ; UYVY UYVY -> YVYU YVY...
+RSHIFT_COPYm6, m2, m4, 1, 0x20 ; UYVY UYVY -> YVYU YVY...
 pand   m6, m1; YxYx YxYx...
 
-RSHIFT_COPYm7, m3, 1 ; UYVY UYVY -> YVYU YVY...
+RSHIFT_COPYm7, m3, m5, 1, 0x20 ; UYVY UYVY -> YVYU YVY...
 pand   m7, m1 ; YxYx YxYx...
 
 packuswb   m6, m7 ;  ...
 movu [ydstq + wq], m6
 
 ; extract y part 2
-RSHIFT_COPYm6, m4, 1 ; UYVY UYVY -> YVYU YVY...
+RSHIFT_COPYm6, m4, m2, 1, 0x13 ; UYVY UYVY -> YVYU YVY...
 pand   m6, m1; YxYx YxYx...
 
-RSHIFT_COPYm7, m5, 1 ; UYVY UYVY -> YVYU YVY...
+RSHIFT_COPYm7, m5, m3, 1, 0x13 ; UYVY UYVY -> YVYU YVY...
 pand   m7, m1 ; YxYx YxYx...
 
 packuswbm6, m7 ;  ...
@@ -309,4 +323,6 @@ UYVY_TO_YUV422
 
 INIT_XMM avx
 UYVY_TO_YUV422
+INIT_YMM avx2
+UYVY_TO_YUV422
 %endif
-- 
2.45.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 06/16] avutil: add nvtegra hwcontext

[Mark Thompson]

On 30/05/2024 20:43, averne wrote:
> This includes hwdevice and hwframes objects.
> As the multimedia engines work with tiled surfaces (block linear in nvidia 
> jargon), two frame transfer methods are implemented.
> The first makes use of the VIC to perform the copy. Since some revisions of 
> the VIC (such as the one found in the tegra X1) did not support 10+ bit 
> formats, these go through two separate copy steps for the luma and chroma 
> planes.
> The second method copies on the CPU, and is used as a fallback if the VIC 
> constraints are not satisfied.
> 
> Signed-off-by: averne 
> ---
>  libavutil/Makefile |   7 +-
>  libavutil/hwcontext.c  |   4 +
>  libavutil/hwcontext.h  |   1 +
>  libavutil/hwcontext_internal.h |   1 +
>  libavutil/hwcontext_nvtegra.c  | 880 +
>  libavutil/hwcontext_nvtegra.h  |  85 
>  6 files changed, 976 insertions(+), 2 deletions(-)
>  create mode 100644 libavutil/hwcontext_nvtegra.c
>  create mode 100644 libavutil/hwcontext_nvtegra.h
> 
> ...> +
> +static int nvtegra_transfer_data(AVHWFramesContext *ctx, AVFrame *dst, const 
> AVFrame *src) {
> +const AVFrame *swframe;
> +bool from;
> +int num_planes, i;
> +
> +from= !dst->hw_frames_ctx;
> +swframe = from ? dst : src;
> +
> +if (swframe->hw_frames_ctx)
> +return AVERROR(ENOSYS);
> +
> +num_planes = av_pix_fmt_count_planes(swframe->format);
> +
> +for (i = 0; i < num_planes; ++i) {
> +if (((uintptr_t)swframe->data[i] & 0xff) || (swframe->linesize[i] & 
> 0xff)) {
> +av_log(ctx, AV_LOG_WARNING, "Frame address/pitch not aligned to 
> 256, "
> +"falling back to cpu transfer\n");
> +return nvtegra_cpu_transfer_data(ctx, dst, src, num_planes, 
> from);

Are you doing something somewhere to avoid this case?  It seems like it should 
be the normal one (given alignment is typically set signficantly lower than 
256), so this warning would be very spammy.

> +}
> +}
> +
> +return nvtegra_vic_transfer_data(ctx, dst, src, num_planes, from);
> +}
> +
> +const HWContextType ff_hwcontext_type_nvtegra = {
> +.type   = AV_HWDEVICE_TYPE_NVTEGRA,
> +.name   = "nvtegra",
> +
> +.device_hwctx_size  = sizeof(NVTegraDevicePriv),
> +.device_hwconfig_size   = 0,
> +.frames_hwctx_size  = 0,
> +
> +.device_create  = &nvtegra_device_create,
> +.device_init= &nvtegra_device_init,
> +.device_uninit  = &nvtegra_device_uninit,
> +
> +.frames_get_constraints = &nvtegra_frames_get_constraints,
> +.frames_init= &nvtegra_frames_init,
> +.frames_uninit  = &nvtegra_frames_uninit,
> +.frames_get_buffer  = &nvtegra_get_buffer,
> +
> +.transfer_get_formats   = &nvtegra_transfer_get_formats,
> +.transfer_data_to   = &nvtegra_transfer_data,
> +.transfer_data_from = &nvtegra_transfer_data,
> +
> +.pix_fmts = (const enum AVPixelFormat[]) {
> +AV_PIX_FMT_NVTEGRA,
> +AV_PIX_FMT_NONE,
> +},
> +};

What controls whether frames are linear or not?

It seems like the linear case could be exposed directly to the user rather than 
having to wrap it like this - the decoder could return read-only NV12 (or 
whatever) frames directly and they would work with other components.

> diff --git a/libavutil/hwcontext_nvtegra.h b/libavutil/hwcontext_nvtegra.h
> new file mode 100644
> index 00..8a2383d304
> --- /dev/null
> +++ b/libavutil/hwcontext_nvtegra.h
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright (c) 2024 averne 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 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 General Public License for more details.
> + *
> + * You should have received a copy of the GNU 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.
> + */
> +
> +#ifndef AVUTIL_HWCONTEXT_NVTEGRA_H
> +#define AVUTIL_HWCONTEXT_NVTEGRA_H
> +
> +#include 
> +
> +#include "hwcontext.h"
> +#include "buffer.h"
> +#include "frame.h"
> +#include "pixfmt.h"
> +
> +#include "nvtegra.h"
> +
> +/*
> + * Encode a hardware revision into a version number
> + */
> +#define AV_NVTEGRA_ENCODE_REV(maj, min) (((maj & 0xff) << 8) | (min & 0xff))
> +
> +/*
> + * Decode a version number
> + */
> +static inline void av_nvtegra_decode_rev(int rev, int *maj, int *min) {
> +*maj = (rev >> 8) & 0x

Re: [FFmpeg-devel] [PATCH 07/16] hwcontext_nvtegra: add dynamic frequency scaling routines

[Mark Thompson]

On 30/05/2024 20:43, averne wrote:
> To save on energy, the clock speed of multimedia engines should be adapted to 
> their workload.
> 
> Signed-off-by: averne 
> ---
>  libavutil/hwcontext_nvtegra.c | 165 ++
>  libavutil/hwcontext_nvtegra.h |   7 ++
>  2 files changed, 172 insertions(+)
> 
> ...
> diff --git a/libavutil/hwcontext_nvtegra.h b/libavutil/hwcontext_nvtegra.h
> index 8a2383d304..7c845951d9 100644
> --- a/libavutil/hwcontext_nvtegra.h
> +++ b/libavutil/hwcontext_nvtegra.h
> @@ -82,4 +82,11 @@ static inline AVNVTegraMap 
> *av_nvtegra_frame_get_fbuf_map(const AVFrame *frame)
>   */
>  int av_nvtegra_pixfmt_to_vic(enum AVPixelFormat fmt);
>  
> +/*
> + * Dynamic frequency scaling routines
> + */
> +int av_nvtegra_dfs_init(AVHWDeviceContext *ctx, AVNVTegraChannel *channel, 
> int width, int height, double framerate_hz);
> +int av_nvtegra_dfs_update(AVHWDeviceContext *ctx, AVNVTegraChannel *channel, 
> int bitstream_len, int decode_cycles);
> +int av_nvtegra_dfs_uninit(AVHWDeviceContext *ctx, AVNVTegraChannel *channel);
> +
>  #endif /* AVUTIL_HWCONTEXT_NVTEGRA_H */

This really isn't a sensible thing to have in the public API of ffmpeg.  Why on 
earth isn't this sort of detail dealt with by the kernel?  (Which can actually 
see all of the different processes using it, as well.)

Thanks,

- Mark
___
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/x86/rgb2rgb: replace shuffle_bytes_2103_mmxext with an SSE2 version

[James Almer]

shuffle_bytes_2103_c: 46.5
shuffle_bytes_2103_mmxext: 29.3
shuffle_bytes_2103_sse2: 12.5

Signed-off-by: James Almer 
---
 libswscale/x86/rgb2rgb.c |  6 ++
 libswscale/x86/rgb_2_rgb.asm | 30 +++---
 2 files changed, 13 insertions(+), 23 deletions(-)

diff --git a/libswscale/x86/rgb2rgb.c b/libswscale/x86/rgb2rgb.c
index 21ccfafe51..912fe431b3 100644
--- a/libswscale/x86/rgb2rgb.c
+++ b/libswscale/x86/rgb2rgb.c
@@ -116,7 +116,7 @@ DECLARE_ALIGNED(8, extern const uint64_t, ff_bgr2UVOffset);
 
 #endif /* HAVE_INLINE_ASM */
 
-void ff_shuffle_bytes_2103_mmxext(const uint8_t *src, uint8_t *dst, int 
src_size);
+void ff_shuffle_bytes_2103_sse2(const uint8_t *src, uint8_t *dst, int 
src_size);
 void ff_shuffle_bytes_2103_ssse3(const uint8_t *src, uint8_t *dst, int 
src_size);
 void ff_shuffle_bytes_0321_ssse3(const uint8_t *src, uint8_t *dst, int 
src_size);
 void ff_shuffle_bytes_1230_ssse3(const uint8_t *src, uint8_t *dst, int 
src_size);
@@ -154,10 +154,8 @@ av_cold void rgb2rgb_init_x86(void)
 rgb2rgb_init_avx();
 #endif /* HAVE_INLINE_ASM */
 
-if (EXTERNAL_MMXEXT(cpu_flags)) {
-shuffle_bytes_2103 = ff_shuffle_bytes_2103_mmxext;
-}
 if (EXTERNAL_SSE2(cpu_flags)) {
+shuffle_bytes_2103 = ff_shuffle_bytes_2103_sse2;
 #if ARCH_X86_64
 uyvytoyuv422 = ff_uyvytoyuv422_sse2;
 #endif
diff --git a/libswscale/x86/rgb_2_rgb.asm b/libswscale/x86/rgb_2_rgb.asm
index 0bf1278718..2d2ac778b7 100644
--- a/libswscale/x86/rgb_2_rgb.asm
+++ b/libswscale/x86/rgb_2_rgb.asm
@@ -25,7 +25,7 @@
 
 SECTION_RODATA
 
-pb_mask_shuffle2103_mmx times 8 dw 255
+pb_mask_shuffle2103 times 8 dw 255
 pb_shuffle2103: db 2, 1, 0, 3, 6, 5, 4, 7, 10, 9, 8, 11, 14, 13, 12, 15
 pb_shuffle0321: db 0, 3, 2, 1, 4, 7, 6, 5, 8, 11, 10, 9, 12, 15, 14, 13
 pb_shuffle1230: db 1, 2, 3, 0, 5, 6, 7, 4, 9, 10, 11, 8, 13, 14, 15, 12
@@ -50,11 +50,10 @@ SECTION .text
 ;--
 ; shuffle_bytes_2103_mmext (const uint8_t *src, uint8_t *dst, int src_size)
 ;--
-INIT_MMX mmxext
-cglobal shuffle_bytes_2103, 3, 5, 8, src, dst, w, tmp, x
-mova   m6, [pb_mask_shuffle2103_mmx]
-mova   m7, m6
-psllq  m7, 8
+INIT_XMM sse2
+cglobal shuffle_bytes_2103, 3, 5, 4, src, dst, w, tmp, x
+mova   m2, [pb_mask_shuffle2103]
+psllq  m3, m2, 8
 
 movsxdifnidn wq, wd
 mov xq, wq
@@ -86,28 +85,21 @@ jge .end
 
 .loop_simd:
 movu m0, [srcq+wq]
-movu m1, [srcq+wq+8]
-
-pshufw   m3, m0, 177
-pshufw   m5, m1, 177
 
-pand m0, m7
-pand m3, m6
+pshuflw   m1, m0, 0xb1
+pshufhw   m1, m1, 0xb1
 
-pand m1, m7
-pand m5, m6
+pand m0, m3
+pand m1, m2
 
-por  m0, m3
-por  m1, m5
+por  m0, m1
 
 movu  [dstq+wq], m0
-movu  [dstq+wq + 8], m1
 
-add  wq, mmsize*2
+add  wq, mmsize
 jl .loop_simd
 
 .end:
-emms
 RET
 
 ;--
-- 
2.45.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] checkasm/sw_rgb: test rgb32/rgb32_1 to yuv

[Andreas Rheinhardt]

James Almer:
> On 6/5/2024 5:10 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Test all four pixel formats, but only bench the two native endian
>>> ones for a
>>> given target.
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>>   tests/checkasm/sw_rgb.c | 22 --
>>>   1 file changed, 16 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
>>> index b51d0836c3..cba6b87add 100644
>>> --- a/tests/checkasm/sw_rgb.c
>>> +++ b/tests/checkasm/sw_rgb.c
>>> @@ -187,11 +187,15 @@ static const int input_sizes[] = {8, 128, 1080,
>>> MAX_LINE_SIZE};
>>>   static const enum AVPixelFormat rgb_formats[] = {
>>>   AV_PIX_FMT_RGB24,
>>>   AV_PIX_FMT_BGR24,
>>> +    AV_PIX_FMT_RGBA,
>>> +    AV_PIX_FMT_BGRA,
>>> +    AV_PIX_FMT_ABGR,
>>> +    AV_PIX_FMT_ARGB,
>>>   };
>>>     static void check_rgb_to_y(struct SwsContext *ctx)
>>>   {
>>> -    LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
>>> +    LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 4]);
>>>   LOCAL_ALIGNED_32(uint8_t, dst0_y, [MAX_LINE_SIZE * 2]);
>>>   LOCAL_ALIGNED_32(uint8_t, dst1_y, [MAX_LINE_SIZE * 2]);
>>>   @@ -199,7 +203,7 @@ static void check_rgb_to_y(struct SwsContext *ctx)
>>>    const uint8_t *unused1, const uint8_t *unused2,
>>> int width,
>>>    uint32_t *rgb2yuv, void *opq);
>>>   -    randomize_buffers(src, MAX_LINE_SIZE * 3);
>>> +    randomize_buffers(src, MAX_LINE_SIZE * 4);
>>>     for (int i = 0; i < FF_ARRAY_ELEMS(rgb_formats); i++) {
>>>   const AVPixFmtDescriptor *desc =
>>> av_pix_fmt_desc_get(rgb_formats[i]);
>>> @@ -220,7 +224,10 @@ static void check_rgb_to_y(struct SwsContext *ctx)
>>>   if (memcmp(dst0_y, dst1_y, w * 2))
>>>   fail();
>>>   -    bench_new(dst1_y, src, NULL, NULL, w,
>>> ctx->input_rgb2yuv_table, NULL);
>>> +    if (desc->nb_components == 3 ||
>>> +    // only bench native endian formats
>>> +    (ctx->srcFormat == AV_PIX_FMT_RGB32 ||
>>> ctx->srcFormat == AV_PIX_FMT_RGB32_1))
>>> +    bench_new(dst1_y, src, NULL, NULL, w,
>>> ctx->input_rgb2yuv_table, NULL);
>>>   }
>>>   }
>>>   }
>>> @@ -228,7 +235,7 @@ static void check_rgb_to_y(struct SwsContext *ctx)
>>>     static void check_rgb_to_uv(struct SwsContext *ctx)
>>>   {
>>> -    LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
>>> +    LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 4]);
>>
>> Doesn't this make the test less strict wrt overreading for tests that
>> are only supposed to use MAX_LINE_SIZE * 3?
> 
> Probably. Want me to add a second src buffer for this?
> 

Proceed as you wish.

>>
>>>   LOCAL_ALIGNED_32(uint8_t, dst0_u, [MAX_LINE_SIZE * 2]);
>>>   LOCAL_ALIGNED_32(uint8_t, dst0_v, [MAX_LINE_SIZE * 2]);
>>>   LOCAL_ALIGNED_32(uint8_t, dst1_u, [MAX_LINE_SIZE * 2]);
>>> @@ -238,7 +245,7 @@ static void check_rgb_to_uv(struct SwsContext *ctx)
>>>    const uint8_t *src1, const uint8_t *src2, const
>>> uint8_t *src3,
>>>    int width, uint32_t *pal, void *opq);
>>>   -    randomize_buffers(src, MAX_LINE_SIZE * 3);
>>> +    randomize_buffers(src, MAX_LINE_SIZE * 4);
>>>     for (int i = 0; i < 2 * FF_ARRAY_ELEMS(rgb_formats); i++) {
>>>   enum AVPixelFormat src_fmt = rgb_formats[i / 2];
>>> @@ -266,7 +273,10 @@ static void check_rgb_to_uv(struct SwsContext *ctx)
>>>   if (memcmp(dst0_u, dst1_u, w * 2) || memcmp(dst0_v,
>>> dst1_v, w * 2))
>>>   fail();
>>>   -    bench_new(dst1_u, dst1_v, NULL, src, src, w,
>>> ctx->input_rgb2yuv_table, NULL);
>>> +    if (desc->nb_components == 3 ||
>>> +    // only bench native endian formats
>>> +    (ctx->srcFormat == AV_PIX_FMT_RGB32 ||
>>> ctx->srcFormat == AV_PIX_FMT_RGB32_1))
>>> +    bench_new(dst1_u, dst1_v, NULL, src, src, w,
>>> ctx->input_rgb2yuv_table, NULL);
>>>   }
>>>   }
>>>   }
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

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

Re: [FFmpeg-devel] [PATCH 2/2] swscale/x86/input: add AVX2 optimized uyvytoyuv422

[Andreas Rheinhardt]

James Almer:
> uyvytoyuv422_c: 23991.8
> uyvytoyuv422_sse2: 2817.8
> uyvytoyuv422_avx: 2819.3

Why don't you nuke the avx version in a follow-up patch?

> uyvytoyuv422_avx2: 1972.3
> 
> Signed-off-by: James Almer 
> ---
>  libswscale/x86/rgb2rgb.c |  6 ++
>  libswscale/x86/rgb_2_rgb.asm | 32 
>  2 files changed, 30 insertions(+), 8 deletions(-)
> 
> diff --git a/libswscale/x86/rgb2rgb.c b/libswscale/x86/rgb2rgb.c
> index b325e5dbd5..21ccfafe51 100644
> --- a/libswscale/x86/rgb2rgb.c
> +++ b/libswscale/x86/rgb2rgb.c
> @@ -136,6 +136,9 @@ void ff_uyvytoyuv422_sse2(uint8_t *ydst, uint8_t *udst, 
> uint8_t *vdst,
>  void ff_uyvytoyuv422_avx(uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
>   const uint8_t *src, int width, int height,
>   int lumStride, int chromStride, int srcStride);
> +void ff_uyvytoyuv422_avx2(uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
> +  const uint8_t *src, int width, int height,
> +  int lumStride, int chromStride, int srcStride);
>  #endif
>  
>  av_cold void rgb2rgb_init_x86(void)
> @@ -177,5 +180,8 @@ av_cold void rgb2rgb_init_x86(void)
>  if (EXTERNAL_AVX(cpu_flags)) {
>  uyvytoyuv422 = ff_uyvytoyuv422_avx;
>  }
> +if (EXTERNAL_AVX2_FAST(cpu_flags)) {
> +uyvytoyuv422 = ff_uyvytoyuv422_avx2;
> +}
>  #endif
>  }
> diff --git a/libswscale/x86/rgb_2_rgb.asm b/libswscale/x86/rgb_2_rgb.asm
> index 76ca1eec03..0bf1278718 100644
> --- a/libswscale/x86/rgb_2_rgb.asm
> +++ b/libswscale/x86/rgb_2_rgb.asm
> @@ -34,13 +34,16 @@ pb_shuffle3210: db 3, 2, 1, 0, 7, 6, 5, 4, 11, 10, 9, 8, 
> 15, 14, 13, 12
>  
>  SECTION .text
>  
> -%macro RSHIFT_COPY 3
> +%macro RSHIFT_COPY 5
>  ; %1 dst ; %2 src ; %3 shift
> -%if cpuflag(avx)
> -psrldq  %1, %2, %3
> +%if mmsize == 32
> +vperm2i128 %1, %2, %3, %5
> +RSHIFT %1, %4
> +%elif cpuflag(avx)
> +psrldq  %1, %2, %4
>  %else
>  mova   %1, %2
> -RSHIFT %1, %3
> +RSHIFT %1, %4
>  %endif
>  %endmacro
>  
> @@ -233,26 +236,37 @@ cglobal uyvytoyuv422, 9, 14, 8, ydst, udst, vdst, src, 
> w, h, lum_stride, chrom_s
>  jge .end_line
>  
>  .loop_simd:
> +%if mmsize == 32
> +movu   xm2, [srcq + wtwoq ]
> +movu   xm3, [srcq + wtwoq + 16]
> +movu   xm4, [srcq + wtwoq + 16 * 2]
> +movu   xm5, [srcq + wtwoq + 16 * 3]
> +vinserti128 m2, m2, [srcq + wtwoq + 16 * 4], 1
> +vinserti128 m3, m3, [srcq + wtwoq + 16 * 5], 1
> +vinserti128 m4, m4, [srcq + wtwoq + 16 * 6], 1
> +vinserti128 m5, m5, [srcq + wtwoq + 16 * 7], 1
> +%else
>  movum2, [srcq + wtwoq ]
>  movum3, [srcq + wtwoq + mmsize]
>  movum4, [srcq + wtwoq + mmsize * 2]
>  movum5, [srcq + wtwoq + mmsize * 3]
> +%endif
>  
>  ; extract y part 1
> -RSHIFT_COPYm6, m2, 1 ; UYVY UYVY -> YVYU YVY...
> +RSHIFT_COPYm6, m2, m4, 1, 0x20 ; UYVY UYVY -> YVYU YVY...
>  pand   m6, m1; YxYx YxYx...
>  
> -RSHIFT_COPYm7, m3, 1 ; UYVY UYVY -> YVYU YVY...
> +RSHIFT_COPYm7, m3, m5, 1, 0x20 ; UYVY UYVY -> YVYU YVY...
>  pand   m7, m1 ; YxYx YxYx...
>  
>  packuswb   m6, m7 ;  ...
>  movu [ydstq + wq], m6
>  
>  ; extract y part 2
> -RSHIFT_COPYm6, m4, 1 ; UYVY UYVY -> YVYU YVY...
> +RSHIFT_COPYm6, m4, m2, 1, 0x13 ; UYVY UYVY -> YVYU YVY...
>  pand   m6, m1; YxYx YxYx...
>  
> -RSHIFT_COPYm7, m5, 1 ; UYVY UYVY -> YVYU YVY...
> +RSHIFT_COPYm7, m5, m3, 1, 0x13 ; UYVY UYVY -> YVYU YVY...
>  pand   m7, m1 ; YxYx YxYx...
>  
>  packuswbm6, m7 ;  ...
> @@ -309,4 +323,6 @@ UYVY_TO_YUV422
>  
>  INIT_XMM avx
>  UYVY_TO_YUV422
> +INIT_YMM avx2
> +UYVY_TO_YUV422
>  %endif

___
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] checkasm/sw_rgb: test rgb32/rgb32_1 to yuv

[James Almer]

Test all four pixel formats, but only bench the two native endian ones for a
given target.

Signed-off-by: James Almer 
---
 tests/checkasm/sw_rgb.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index b51d0836c3..378412e9d2 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -187,11 +187,16 @@ static const int input_sizes[] = {8, 128, 1080, 
MAX_LINE_SIZE};
 static const enum AVPixelFormat rgb_formats[] = {
 AV_PIX_FMT_RGB24,
 AV_PIX_FMT_BGR24,
+AV_PIX_FMT_RGBA,
+AV_PIX_FMT_BGRA,
+AV_PIX_FMT_ABGR,
+AV_PIX_FMT_ARGB,
 };
 
 static void check_rgb_to_y(struct SwsContext *ctx)
 {
-LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, src24,  [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, src32,  [MAX_LINE_SIZE * 4]);
 LOCAL_ALIGNED_32(uint8_t, dst0_y, [MAX_LINE_SIZE * 2]);
 LOCAL_ALIGNED_32(uint8_t, dst1_y, [MAX_LINE_SIZE * 2]);
 
@@ -199,7 +204,8 @@ static void check_rgb_to_y(struct SwsContext *ctx)
  const uint8_t *unused1, const uint8_t *unused2, int width,
  uint32_t *rgb2yuv, void *opq);
 
-randomize_buffers(src, MAX_LINE_SIZE * 3);
+randomize_buffers(src24, MAX_LINE_SIZE * 3);
+randomize_buffers(src32, MAX_LINE_SIZE * 4);
 
 for (int i = 0; i < FF_ARRAY_ELEMS(rgb_formats); i++) {
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(rgb_formats[i]);
@@ -211,6 +217,7 @@ static void check_rgb_to_y(struct SwsContext *ctx)
 int w = input_sizes[j];
 
 if (check_func(ctx->lumToYV12, "%s_to_y_%d", desc->name, w)) {
+const uint8_t *src = desc->nb_components == 3 ? src24 : src32;
 memset(dst0_y, 0xFA, MAX_LINE_SIZE * 2);
 memset(dst1_y, 0xFA, MAX_LINE_SIZE * 2);
 
@@ -220,7 +227,10 @@ static void check_rgb_to_y(struct SwsContext *ctx)
 if (memcmp(dst0_y, dst1_y, w * 2))
 fail();
 
-bench_new(dst1_y, src, NULL, NULL, w, 
ctx->input_rgb2yuv_table, NULL);
+if (desc->nb_components == 3 ||
+// only bench native endian formats
+(ctx->srcFormat == AV_PIX_FMT_RGB32 || ctx->srcFormat == 
AV_PIX_FMT_RGB32_1))
+bench_new(dst1_y, src, NULL, NULL, w, 
ctx->input_rgb2yuv_table, NULL);
 }
 }
 }
@@ -228,7 +238,8 @@ static void check_rgb_to_y(struct SwsContext *ctx)
 
 static void check_rgb_to_uv(struct SwsContext *ctx)
 {
-LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, src24,  [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, src32,  [MAX_LINE_SIZE * 4]);
 LOCAL_ALIGNED_32(uint8_t, dst0_u, [MAX_LINE_SIZE * 2]);
 LOCAL_ALIGNED_32(uint8_t, dst0_v, [MAX_LINE_SIZE * 2]);
 LOCAL_ALIGNED_32(uint8_t, dst1_u, [MAX_LINE_SIZE * 2]);
@@ -238,7 +249,8 @@ static void check_rgb_to_uv(struct SwsContext *ctx)
  const uint8_t *src1, const uint8_t *src2, const uint8_t *src3,
  int width, uint32_t *pal, void *opq);
 
-randomize_buffers(src, MAX_LINE_SIZE * 3);
+randomize_buffers(src24, MAX_LINE_SIZE * 3);
+randomize_buffers(src32, MAX_LINE_SIZE * 4);
 
 for (int i = 0; i < 2 * FF_ARRAY_ELEMS(rgb_formats); i++) {
 enum AVPixelFormat src_fmt = rgb_formats[i / 2];
@@ -255,6 +267,7 @@ static void check_rgb_to_uv(struct SwsContext *ctx)
 if (check_func(ctx->chrToYV12, "%s_to_uv%s_%d", desc->name,
ctx->chrSrcHSubSample ? "_half" : "",
input_sizes[j])) {
+const uint8_t *src = desc->nb_components == 3 ? src24 : src32;
 memset(dst0_u, 0xFF, MAX_LINE_SIZE * 2);
 memset(dst0_v, 0xFF, MAX_LINE_SIZE * 2);
 memset(dst1_u, 0xFF, MAX_LINE_SIZE * 2);
@@ -266,7 +279,10 @@ static void check_rgb_to_uv(struct SwsContext *ctx)
 if (memcmp(dst0_u, dst1_u, w * 2) || memcmp(dst0_v, dst1_v, w 
* 2))
 fail();
 
-bench_new(dst1_u, dst1_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+if (desc->nb_components == 3 ||
+// only bench native endian formats
+(ctx->srcFormat == AV_PIX_FMT_RGB32 || ctx->srcFormat == 
AV_PIX_FMT_RGB32_1))
+bench_new(dst1_u, dst1_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
 }
 }
 }
-- 
2.45.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] avcodec/dovi_rpudec: replace brittle struct copying code

[Cosmin Stejerean via ffmpeg-devel]

> On Jun 5, 2024, at 5:23 AM, Niklas Haas  wrote:
> 
> On Wed, 05 Jun 2024 12:07:08 +0200 Andreas Rheinhardt 
>  wrote:
>> Niklas Haas:
>>> From: Niklas Haas 
>>> 
>>> This code was unnecessarily trying to be robust against downgrades of
>>> libavutil (relative to the version libavcodec was compiled against), but
>>> in the process, ended up with very brittle code that is easy to
>>> accidentally forget to update when adding new fields.
>>> 
>>> Instead, do the obvious thing and just directly copy the parts of the
>>> struct known at compile time. Since it is not generally supported to
>>> link against a version of libavutil older than the version libavcodec
>>> was compiled against, the struct shrinking externally is not a case we
>>> need to be worrying about.
>> 
>> The exact opposite is true: The code is trying to be robust against
>> upgrades of libavutil. The reason for this is potential trailing padding
>> in the structures that are copied here. It may be used for actual stuff
>> in a future libavutil and the approach you use here allows the compiler
>> to clobber it.
>> 
>> (How would this code be robust against downgrades of libavutil at all?
>> There is no check here that sizeof of the side data is big enough to
>> contain everything we expect it to contain.)
> 
> I should clearly not write code immediately after waking up.
> 
> Yes, true, the only thing this logic is trying to accomplish is being
> robust against the struct gaining extra padding in the future.
> 
> That said, I still think the code as written is brittle and I'm not sure
> it's providing anything useful. What is the likelihood of this struct
> being extended in a way that does not affect the encoder, vs. the
> likelihood of this struct being extended but somebody forgetting to bump
> the equivalent "last field" entry in this file?
> 
> Anecdotally, the latter has already happened once.

+1, having already tripped on this on my patch to add ext_mapping_idc* fields I 
can confirm that it's easy to trip on this, easy to miss unless you carefully 
inspect the RPU afterwards,  and then hard to spot where the problem is without 
having to trace through the code and catch this copy. 

The new approach seems much better in practice.

- Cosmin
___
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] Allow enabling SVC in libaomenc

[Chun-Min Chang]

This patch updates libaomenc.c to accept parameters for SVC (Scalable
Video Coding) settings via the FFmpeg API `av_opt_set`. The SVC
configuration is applied based on the provided parameters. As libaom's
SVC functionality only operates with constant bitrate encoding [1],
these parameters will only take effect when the bitrate is set to
constant.

[1] 
https://aomedia.googlesource.com/aom/+/a7ef80c44bfb34b08254194b1ab72d4e93ff4b07/av1/encoder/svc_layercontext.h#115


Signed-off-by: Chun-Min Chang 
---
 libavcodec/libaomenc.c | 75 ++
 1 file changed, 75 insertions(+)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index dec74ebecd..a8602a6b56 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -30,6 +30,7 @@
 #include 
  #include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
 #include "libavutil/base64.h"
 #include "libavutil/common.h"
 #include "libavutil/cpu.h"
@@ -137,6 +138,7 @@ typedef struct AOMEncoderContext {
 int enable_diff_wtd_comp;
 int enable_dist_wtd_comp;
 int enable_dual_filter;
+AVDictionary *svc_parameters;
 AVDictionary *aom_params;
 } AOMContext;
 @@ -201,6 +203,7 @@ static const char *const ctlidstr[] = {
 [AV1E_GET_TARGET_SEQ_LEVEL_IDX] = "AV1E_GET_TARGET_SEQ_LEVEL_IDX",
 #endif
 [AV1_GET_NEW_FRAME_IMAGE]   = "AV1_GET_NEW_FRAME_IMAGE",
+[AV1E_SET_SVC_PARAMS]   = "AV1E_SET_SVC_PARAMS",
 };
  static av_cold void log_encoder_error(AVCodecContext *avctx, const 
char *desc)

@@ -382,6 +385,31 @@ static av_cold int codecctl_imgp(AVCodecContext *avctx,
 return 0;
 }
 +static av_cold int codecctl_svcp(AVCodecContext *avctx,
+#ifdef UENUM1BYTE
+ aome_enc_control_id id,
+#else
+ enum aome_enc_control_id id,
+#endif
+ aom_svc_params_t *svc_params)
+{
+AOMContext *ctx = avctx->priv_data;
+char buf[80];
+int res;
+
+snprintf(buf, sizeof(buf), "%s:", ctlidstr[id]);
+
+res = aom_codec_control(&ctx->encoder, id, svc_params);
+if (res != AOM_CODEC_OK) {
+snprintf(buf, sizeof(buf), "Failed to get %s codec control",
+ ctlidstr[id]);
+log_encoder_error(avctx, buf);
+return AVERROR(EINVAL);
+}
+
+return 0;
+}
+
 static av_cold int aom_free(AVCodecContext *avctx)
 {
 AOMContext *ctx = avctx->priv_data;
@@ -673,6 +701,18 @@ static int choose_tiling(AVCodecContext *avctx,
 return 0;
 }
 +static void aom_svc_parse_int_array(int *dest, char *value, int 
max_entries)

+{
+int dest_idx = 0;
+char *saveptr = NULL;
+char *token = av_strtok(value, ",", &saveptr);
+
+while (token && dest_idx < max_entries) {
+dest[dest_idx++] = strtoul(token, NULL, 10);
+token = av_strtok(NULL, ",", &saveptr);
+}
+}
+
 static av_cold int aom_init(AVCodecContext *avctx,
 const struct aom_codec_iface *iface)
 {
@@ -968,6 +1008,40 @@ static av_cold int aom_init(AVCodecContext *avctx,
 if (ctx->enable_intrabc >= 0)
 codecctl_int(avctx, AV1E_SET_ENABLE_INTRABC, ctx->enable_intrabc);
 +if (enccfg.rc_end_usage == AOM_CBR) {
+aom_svc_params_t svc_params = {};
+svc_params.framerate_factor[0] = 1;
+svc_params.number_spatial_layers = 1;
+svc_params.number_temporal_layers = 1;
+
+const AVDictionaryEntry *en = NULL;
+while ((en = av_dict_iterate(ctx->svc_parameters, en))) {
+if (!strlen(en->value))
+return AVERROR(EINVAL);
+
+if (!strcmp(en->key, "number_spatial_layers"))
+svc_params.number_spatial_layers = strtoul(en->value, 
NULL, 10);

+else if (!strcmp(en->key, "number_temporal_layers"))
+svc_params.number_temporal_layers = strtoul(en->value, 
NULL, 10);

+else if (!strcmp(en->key, "max_quantizers"))
+aom_svc_parse_int_array(svc_params.max_quantizers, 
en->value, AOM_MAX_LAYERS);

+else if (!strcmp(en->key, "min_quantizers"))
+aom_svc_parse_int_array(svc_params.min_quantizers, 
en->value, AOM_MAX_LAYERS);

+else if (!strcmp(en->key, "scaling_factor_num"))
+aom_svc_parse_int_array(svc_params.scaling_factor_num, 
en->value, AOM_MAX_SS_LAYERS);

+else if (!strcmp(en->key, "scaling_factor_den"))
+aom_svc_parse_int_array(svc_params.scaling_factor_den, 
en->value, AOM_MAX_SS_LAYERS);

+else if (!strcmp(en->key, "layer_target_bitrate"))
+ 
aom_svc_parse_int_array(svc_params.layer_target_bitrate, en->value, 
AOM_MAX_LAYERS);

+else if (!strcmp(en->key, "framerate_factor"))
+aom_svc_parse_int_array(svc_params.framerate_factor, 
en->value, AOM_MAX_TS_LAYERS);

+}
+
+res = codecctl_svcp(avctx, AV1E_SET_SVC_PARAMS, &svc_params);
+if (res < 0)
+return 

[FFmpeg-devel] [PATCH 3/4] swscale/x86/rgb2rgb_template: Remove unused uyvytoyv12

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libswscale/x86/rgb2rgb_template.c | 104 --
 1 file changed, 104 deletions(-)

diff --git a/libswscale/x86/rgb2rgb_template.c 
b/libswscale/x86/rgb2rgb_template.c
index 5c73fa4e16..d1403d08e6 100644
--- a/libswscale/x86/rgb2rgb_template.c
+++ b/libswscale/x86/rgb2rgb_template.c
@@ -1432,110 +1432,6 @@ static inline void RENAME(planar2x)(const uint8_t *src, 
uint8_t *dst, int srcWid
  :::"memory");
 }
 
-/**
- * Height should be a multiple of 2 and width should be a multiple of 16.
- * (If this is a problem for anyone then tell me, and I will fix it.)
- * Chrominance data is only taken from every second line, others are ignored.
- * FIXME: Write HQ version.
- */
-static inline void RENAME(uyvytoyv12)(const uint8_t *src, uint8_t *ydst, 
uint8_t *udst, uint8_t *vdst,
-  int width, int height,
-  int lumStride, int chromStride, int 
srcStride)
-{
-int y;
-const x86_reg chromWidth= width>>1;
-for (y=0; yhttps://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 2/4] swscale/x86/rgb2rgb: Don't unnecessarily check for inline ASM

[Andreas Rheinhardt]

The SSE2 and AVX versions of deinterleaveBytes are external ASM.
Move them out of the inline ASM template.

Signed-off-by: Andreas Rheinhardt 
---
 libswscale/x86/rgb2rgb.c  | 48 +++
 libswscale/x86/rgb2rgb_template.c | 30 ---
 2 files changed, 36 insertions(+), 42 deletions(-)

diff --git a/libswscale/x86/rgb2rgb.c b/libswscale/x86/rgb2rgb.c
index b325e5dbd5..be6f5abc95 100644
--- a/libswscale/x86/rgb2rgb.c
+++ b/libswscale/x86/rgb2rgb.c
@@ -100,13 +100,6 @@ DECLARE_ALIGNED(8, extern const uint64_t, ff_bgr2UVOffset);
 #define RENAME(a) a ## _sse2
 #include "rgb2rgb_template.c"
 
-//AVX versions
-#undef RENAME
-#undef COMPILE_TEMPLATE_AVX
-#define COMPILE_TEMPLATE_AVX 1
-#define RENAME(a) a ## _avx
-#include "rgb2rgb_template.c"
-
 /*
  RGB15->RGB16 original by Strepto/Astral
  ported to gcc & bugfixed : A'rpi
@@ -138,6 +131,33 @@ void ff_uyvytoyuv422_avx(uint8_t *ydst, uint8_t *udst, 
uint8_t *vdst,
  int lumStride, int chromStride, int srcStride);
 #endif
 
+#define DEINTERLEAVE_BYTES(cpuext)\
+void ff_nv12ToUV_ ## cpuext(uint8_t *dstU, uint8_t *dstV, \
+   const uint8_t *unused, \
+   const uint8_t *src1,   \
+   const uint8_t *src2,   \
+   int w, \
+   uint32_t *unused2, \
+   void *opq);\
+static void deinterleave_bytes_ ## cpuext(const uint8_t *src, uint8_t *dst1, 
uint8_t *dst2, \
+  int width, int height, int 
srcStride, \
+  int dst1Stride, int dst2Stride) \
+{ \
+for (int h = 0; h < height; h++) {\
+ff_nv12ToUV_ ## cpuext(dst1, dst2, NULL, src, NULL, width, NULL, 
NULL); \
+src  += srcStride;\
+dst1 += dst1Stride;   \
+dst2 += dst2Stride;   \
+} \
+}
+
+#if HAVE_SSE2_EXTERNAL
+DEINTERLEAVE_BYTES(sse2)
+#endif
+#if HAVE_AVX_EXTERNAL
+DEINTERLEAVE_BYTES(avx)
+#endif
+
 av_cold void rgb2rgb_init_x86(void)
 {
 int cpu_flags = av_get_cpu_flags();
@@ -147,18 +167,19 @@ av_cold void rgb2rgb_init_x86(void)
 rgb2rgb_init_mmxext();
 if (INLINE_SSE2(cpu_flags))
 rgb2rgb_init_sse2();
-if (INLINE_AVX(cpu_flags))
-rgb2rgb_init_avx();
 #endif /* HAVE_INLINE_ASM */
 
 if (EXTERNAL_MMXEXT(cpu_flags)) {
 shuffle_bytes_2103 = ff_shuffle_bytes_2103_mmxext;
 }
+#if HAVE_SSE2_EXTERNAL
 if (EXTERNAL_SSE2(cpu_flags)) {
 #if ARCH_X86_64
 uyvytoyuv422 = ff_uyvytoyuv422_sse2;
 #endif
+deinterleaveBytes = deinterleave_bytes_sse2;
 }
+#endif
 if (EXTERNAL_SSSE3(cpu_flags)) {
 shuffle_bytes_0321 = ff_shuffle_bytes_0321_ssse3;
 shuffle_bytes_2103 = ff_shuffle_bytes_2103_ssse3;
@@ -166,16 +187,19 @@ av_cold void rgb2rgb_init_x86(void)
 shuffle_bytes_3012 = ff_shuffle_bytes_3012_ssse3;
 shuffle_bytes_3210 = ff_shuffle_bytes_3210_ssse3;
 }
+#if HAVE_AVX_EXTERNAL
+if (EXTERNAL_AVX(cpu_flags)) {
+deinterleaveBytes = deinterleave_bytes_avx;
 #if ARCH_X86_64
+uyvytoyuv422 = ff_uyvytoyuv422_avx;
+}
 if (EXTERNAL_AVX2_FAST(cpu_flags)) {
 shuffle_bytes_0321 = ff_shuffle_bytes_0321_avx2;
 shuffle_bytes_2103 = ff_shuffle_bytes_2103_avx2;
 shuffle_bytes_1230 = ff_shuffle_bytes_1230_avx2;
 shuffle_bytes_3012 = ff_shuffle_bytes_3012_avx2;
 shuffle_bytes_3210 = ff_shuffle_bytes_3210_avx2;
-}
-if (EXTERNAL_AVX(cpu_flags)) {
-uyvytoyuv422 = ff_uyvytoyuv422_avx;
+#endif
 }
 #endif
 }
diff --git a/libswscale/x86/rgb2rgb_template.c 
b/libswscale/x86/rgb2rgb_template.c
index e4e884827c..5c73fa4e16 100644
--- a/libswscale/x86/rgb2rgb_template.c
+++ b/libswscale/x86/rgb2rgb_template.c
@@ -1816,31 +1816,6 @@ static void RENAME(interleaveBytes)(const uint8_t *src1, 
const uint8_t *src2, ui
 }
 #endif /* !COMPILE_TEMPLATE_AVX && COMPILE_TEMPLATE_SSE2 */
 
-#if !COMPILE_TEMPLATE_AVX || HAVE_AVX_EXTERNAL
-#if COMPILE_TEMPLATE_SSE2 && HAVE_X86ASM
-void RENAME(ff_nv12ToUV)(uint8_t *dstU, uint8_t *dstV,
- const uint8_t *unused,
- const uint8_t *src1,
- const uint8_t *src2,
- int w,
- uint32_t *unused2,
-  

[FFmpeg-devel] [PATCH 1/4] swscale/x86/rgb2rgb_template: Remove unnecessary SFENCE

[Andreas Rheinhardt]

The ff_nv12ToUV_* functions don't use non-temporal stores
at all.

Signed-off-by: Andreas Rheinhardt 
---
 libswscale/x86/rgb2rgb_template.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/libswscale/x86/rgb2rgb_template.c 
b/libswscale/x86/rgb2rgb_template.c
index edbacea784..e4e884827c 100644
--- a/libswscale/x86/rgb2rgb_template.c
+++ b/libswscale/x86/rgb2rgb_template.c
@@ -1837,10 +1837,6 @@ static void RENAME(deinterleaveBytes)(const uint8_t 
*src, uint8_t *dst1, uint8_t
 dst1 += dst1Stride;
 dst2 += dst2Stride;
 }
-__asm__(
-SFENCE" \n\t"
-::: "memory"
-);
 }
 #endif /* COMPILE_TEMPLATE_SSE2 && HAVE_X86ASM */
 #endif /* !COMPILE_TEMPLATE_AVX || HAVE_AVX_EXTERNAL */
-- 
2.40.1

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

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

Re: [FFmpeg-devel] [PATCH] Allow enabling SVC in libaomenc

[Michael Niedermayer]

On Wed, Jun 05, 2024 at 02:34:07PM -0700, Chun-Min Chang wrote:
> This patch updates libaomenc.c to accept parameters for SVC (Scalable
> Video Coding) settings via the FFmpeg API `av_opt_set`. The SVC
> configuration is applied based on the provided parameters. As libaom's
> SVC functionality only operates with constant bitrate encoding [1],
> these parameters will only take effect when the bitrate is set to
> constant.
> 
> [1] 
> https://aomedia.googlesource.com/aom/+/a7ef80c44bfb34b08254194b1ab72d4e93ff4b07/av1/encoder/svc_layercontext.h#115
> 
> Signed-off-by: Chun-Min Chang 
> ---
>  libavcodec/libaomenc.c | 75 ++
>  1 file changed, 75 insertions(+)

Applying: Allow enabling SVC in libaomenc
error: corrupt patch at line 16
error: could not build fake ancestor
Patch failed at 0001 Allow enabling SVC in libaomenc

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] [PATCH] lavu/opt: Mention that AVOptions is not reentrant

[Michael Niedermayer]

On Wed, Jun 05, 2024 at 03:22:55PM +0100, Andrew Sayers wrote:
> On Wed, Jun 05, 2024 at 09:46:16AM -0400, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Wed, Jun 5, 2024 at 9:44 AM Andrew Sayers 
> > wrote:
> > 
> > > On Wed, Jun 05, 2024 at 03:34:50PM +0200, Paul B Mahol wrote:
> > > > On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers <
> > > ffmpeg-de...@pileofstuff.org>
> > > > wrote:
> > > >
> > > > > An external API developer might think they can use AVOptions to modify
> > > > > values
> > > > > during playback (e.g. putting a playback quality slider next to the
> > > volume
> > > > > slider).  Make it clear that behaviour is not recommended.
> > > > >
> > > >
> > > > There are options that can be changed at runtime,
> > > > And it works just fine.
> > >
> > > How would an external developer know which options can be safely changed
> > > (preferably including in future versions of FFmpeg) vs. ones where their
> > > tests
> > > got lucky and happened not to trigger a read during a non-atomic write?
> > >
> > 
> > If you see that happening, it would be good to submit a bug report. Right
> > now it's very abstract.
> 
> I think we might be talking past each other - here's a concrete example:
> 
> The private struct "SetTSContext" includes an AVOptions-accessible member
> "time_base", currently implemented as an AVRational (i.e. a pair of ints).
> write_number() in libavutil/opt.c sets options of type AV_OPT_TYPE_RATIONAL
> in such a way that a poorly-timed read could see the new numerator
> and old denominator (or the other way around).
> 
> If I wrote a program that let users dynamically change the time base,
> and someone switched their timebase from 1/30 to 100/3000, one unlucky user
> might have a few frames encoded with a timebase of 100/30.  Is that something
> the AVOptions API is supposed to support?  If yes, the bug is that
> AVOptions access isn't guarded by a mutex.  If no, there's no bug, just an
> edge case worth mentioning in the docs.

AVOption simply provides light weight access to the struct fields.
Calling AVOption non re-entrant in modifying a field you arent even allowed
to modify from 2 threads is confusing

If you want to modify a field from 2 threads that field could be some sort
of atomic type. This can then easily be added to AVOption

thx

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

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



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] STF 2025

[Michael Niedermayer]

On Wed, Jun 05, 2024 at 12:31:28PM +0300, Rémi Denis-Courmont wrote:
> 
> 
> Le 5 juin 2024 12:18:57 GMT+03:00, "Rémi Denis-Courmont"  a 
> écrit :
> >But by reacting *only* to Vittorio trying to defend himself and explicitly 
> >(and ineffectively) asking for help from the CC, you look like you are 
> >attacking the victim and defending the troll.
> 
> I should have said "the one doing the trolling". But whatever, the CC is free 
> to ban me for calling someone a troll.

You said something, others said something. Some people want to use somethings
to have others banned. I dont think thats what the CC is there for.

The goal of the CC is not to ban people, but to make people work
together AND by happy while doing so!

(Above is my own, and only my oppinion.)

thx

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

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

[FFmpeg-devel] [PATCH 1/4] aacdec_usac: respect tns_on_lr flag

[Lynne via ffmpeg-devel]

This was left out, and due to av_unused, forgotten about.
---
 libavcodec/aac/aacdec.h  |  1 +
 libavcodec/aac/aacdec_usac.c | 16 
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/libavcodec/aac/aacdec.h b/libavcodec/aac/aacdec.h
index ee21a94007..f0a33e7ac3 100644
--- a/libavcodec/aac/aacdec.h
+++ b/libavcodec/aac/aacdec.h
@@ -230,6 +230,7 @@ typedef struct SingleChannelElement {
 typedef struct AACUsacStereo {
 uint8_t common_window;
 uint8_t common_tw;
+uint8_t tns_on_lr; ///< Apply TNS before M/S and stereo prediction
 
 uint8_t ms_mask_mode;
 uint8_t config_idx;
diff --git a/libavcodec/aac/aacdec_usac.c b/libavcodec/aac/aacdec_usac.c
index 561734f930..3b4e980df4 100644
--- a/libavcodec/aac/aacdec_usac.c
+++ b/libavcodec/aac/aacdec_usac.c
@@ -876,14 +876,14 @@ static int decode_usac_stereo_info(AACDecContext *ac, 
AACUSACConfig *usac,
 return AVERROR_PATCHWELCOME;
 }
 
+us->tns_on_lr = 0;
 sce1->tns.present = sce2->tns.present = 0;
 if (tns_active) {
-av_unused int tns_on_lr;
 int common_tns = 0;
 if (us->common_window)
 common_tns = get_bits1(gb);
 
-tns_on_lr = get_bits1(gb);
+us->tns_on_lr = get_bits1(gb);
 if (common_tns) {
 ret = ff_aac_decode_tns(ac, &sce1->tns, gb, ics1);
 if (ret < 0)
@@ -1214,6 +1214,14 @@ static void spectrum_decode(AACDecContext *ac, 
AACUSACConfig *usac,
 }
 
 if (nb_channels > 1 && us->common_window) {
+for (int ch = 0; ch < nb_channels; ch++) {
+SingleChannelElement *sce = &cpe->ch[ch];
+
+/* Apply TNS, if the tns_on_lr bit is not set. */
+if (sce->tns.present && !us->tns_on_lr)
+ac->dsp.apply_tns(sce->coeffs, &sce->tns, &sce->ics, 1);
+}
+
 if (us->ms_mask_mode == 3) {
 const float *filt;
 complex_stereo_downmix_cur(ac, cpe, us->dmix_re);
@@ -1248,8 +1256,8 @@ static void spectrum_decode(AACDecContext *ac, 
AACUSACConfig *usac,
 for (int ch = 0; ch < nb_channels; ch++) {
 SingleChannelElement *sce = &cpe->ch[ch];
 
-/* Apply TNS */
-if (sce->tns.present)
+/* Apply TNS, if it hasn't been applied yet. */
+if (sce->tns.present && ((nb_channels == 1) || (us->tns_on_lr)))
 ac->dsp.apply_tns(sce->coeffs, &sce->tns, &sce->ics, 1);
 
 ac->oc[1].m4ac.frame_length_short ? 
ac->dsp.imdct_and_windowing_768(ac, sce) :
-- 
2.43.0.381.gb435a96ce8
___
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".