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

2024-09-12 Thread Wang, Fei W
On Tue, 2024-09-10 at 11:10 -0700, Koushik Dutta wrote:
> The crop filter has no effect on scale_qsv:
> 
> -vf crop=100:100,scale_qsv=300x300
> 

How about to use vpp_qsv filter directly? It support both scale and
crop via its options which is much more easy to use.

Thanks
Fei

> Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the
> crop_* properties,
> as seen in the implementation vf_crop.c.
> 
> This patch is slightly different from the previously submitted
> patches
> since qsv supports frame crop via the vpp_qsv filter. If no explicit
> crop
> is detected via that filter, AVFrame.crop_* will be used instead.
> Removal of vpp_qsv's crop argument may be warranted.
> ---
>  libavfilter/qsvvpp.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index 0818ada117..05ce387bc3 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -467,6 +467,16 @@ static QSVFrame *submit_frame(QSVVPPContext *s,
> AVFilterLink *inlink, AVFrame *p
>  else if (qsv_frame->frame->repeat_pict == 4)
>  qsv_frame->surface.Info.PicStruct |=
> MFX_PICSTRUCT_FRAME_TRIPLING;
>  
> +    // if crop arguments are not present from the vpp_qsv filter,
> use the provided AVFrame
> +    // crop_* members instead.
> +    if (!qsv_frame->surface.Info.CropX && !qsv_frame-
> >surface.Info.CropY
> +    && qsv_frame->surface.Info.CropW == picref->width &&
> qsv_frame->surface.Info.CropH == picref->height) {
> +    qsv_frame->surface.Info.CropW = (mfxU16)((picref->width -
> picref->crop_right) - picref->crop_left);
> +    qsv_frame->surface.Info.CropH = (mfxU16)((picref->height -
> picref->crop_bottom) - picref->crop_top);
> +    qsv_frame->surface.Info.CropX = (mfxU16)picref->crop_left;
> +    qsv_frame->surface.Info.CropY = (mfxU16)picref->crop_top;
> +    }
> +
>  return qsv_frame;
>  }
>  

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

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


[FFmpeg-devel] Procedure to enable the Windows on ARM64 FFMPEG Libraries

2024-09-12 Thread Niranjan Kshatriya (QUIC)
Hi team,

I am working on Windows on ARM application development and wants to execute 
FFMPEG on my device.
On FFMPEG download page (Releases * BtbN/FFmpeg-Builds 
(github.com)) "windows on Arm" 
binary is not available (Other binaries(x64 and linux Arm64) are generated and 
validated ).

X64 version of FFMPEG binary is running successfully on my ARM device but 
looking for ARM Native FFMPEG support for better experience as x64 is running 
slow on my device compared to x64 device.

I have downloaded the source from :  https://git.ffmpeg.org/ffmpeg.gitand 
compiled locally ( on ARM using WSL ) for Arm with tool chain : GitHub - 
Windows-on-ARM-Experiments/mingw-woarm64-build: Workflows and build scripts for 
Windows on Arm64 GNU cross-compiler for `aarch64-w64-mingw32` 
target.
  with below configuration :

./configure --arch=arm64 --target-os=mingw32 
--cross-prefix=aarch64-w64-mingw32- --prefix=/ffbuild/prefix 
--pkg-config-flags=--static --pkg-config=pkg-config --enable-gpl 
--enable-version3 --disable-debug --disable-w32threads --enable-pthreads 
--disable-libpulse --disable-libxcb


It will be good to have Windows on ARM prebuilt libraries for FFMPEG as part of 
Download repository (Releases * BtbN/FFmpeg-Builds 
(github.com)).

What it takes to generate Windows on ARM libraries?

Regards,
Niranjan
___
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: Fix epirats suggestions

2024-09-12 Thread Petro Mozil
Thanks for the review!
Sorry about the mistakes, fixed them

Signed-off-by: Petro Mozil 
---
 libavcodec/diracdec.c | 1275 +++--
 libavcodec/vulkan_dirac.c |   52 +-
 2 files changed, 687 insertions(+), 640 deletions(-)

diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index 542824f6e1..44614cc1a8 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -23,23 +23,22 @@
 /**
  * @file
  * Dirac Decoder
- * @author Marco Gerards , David Conrad, Jordi Ortiz 

+ * @author Marco Gerards , David Conrad, Jordi Ortiz
+ * 
  */
 
 #include "diracdec.h"
+#include "config_components.h"
 #include "hwaccels.h"
 #include "hwconfig.h"
 #include "libavutil/imgutils.c"
-#include "config_components.h"
 
 /* magic number division by 3 from schroedinger */
-static inline int divide3(int x)
-{
-return (int)((x+1U)*21845 + 10922) >> 16;
+static inline int divide3(int x) {
+return (int)((x + 1U) * 21845 + 10922) >> 16;
 }
 
-static DiracFrame *remove_frame(DiracFrame *framelist[], unsigned picnum)
-{
+static DiracFrame *remove_frame(DiracFrame *framelist[], unsigned picnum) {
 DiracFrame *remove_pic = NULL;
 int i, remove_idx = -1;
 
@@ -51,13 +50,13 @@ static DiracFrame *remove_frame(DiracFrame *framelist[], 
unsigned picnum)
 
 if (remove_pic)
 for (i = remove_idx; framelist[i]; i++)
-framelist[i] = framelist[i+1];
+framelist[i] = framelist[i + 1];
 
 return remove_pic;
 }
 
-static int add_frame(DiracFrame *framelist[], int maxframes, DiracFrame *frame)
-{
+static int add_frame(DiracFrame *framelist[], int maxframes,
+ DiracFrame *frame) {
 int i;
 for (i = 0; i < maxframes; i++)
 if (!framelist[i]) {
@@ -67,9 +66,8 @@ static int add_frame(DiracFrame *framelist[], int maxframes, 
DiracFrame *frame)
 return -1;
 }
 
-static int alloc_sequence_buffers(DiracContext *s)
-{
-int sbwidth  = DIVRNDUP(s->seq.width,  4);
+static int alloc_sequence_buffers(DiracContext *s) {
+int sbwidth = DIVRNDUP(s->seq.width, 4);
 int sbheight = DIVRNDUP(s->seq.height, 4);
 int i, w, h, top_padding;
 
@@ -77,7 +75,7 @@ static int alloc_sequence_buffers(DiracContext *s)
 for (i = 0; i < 3; i++) {
 int max_xblen = MAX_BLOCKSIZE >> (i ? s->chroma_x_shift : 0);
 int max_yblen = MAX_BLOCKSIZE >> (i ? s->chroma_y_shift : 0);
-w = s->seq.width  >> (i ? s->chroma_x_shift : 0);
+w = s->seq.width >> (i ? s->chroma_x_shift : 0);
 h = s->seq.height >> (i ? s->chroma_y_shift : 0);
 
 /* we allocate the max we support here since num decompositions can
@@ -85,28 +83,31 @@ static int alloc_sequence_buffers(DiracContext *s)
  * 1<0) in arith decoding
  * MAX_BLOCKSIZE padding for MC: blocks can spill up to half of that
  * on each side */
-top_padding = FFMAX(1pshift));
-s->plane[i].idwt.tmp  = av_malloc_array((w+16), 2 << s->pshift);
-s->plane[i].idwt.buf  = s->plane[i].idwt.buf_base + 
(top_padding*w)*(2 << s->pshift);
+top_padding = FFMAX(1 << MAX_DWT_LEVELS, max_yblen / 2);
+w = FFALIGN(CALC_PADDING(w, MAX_DWT_LEVELS),
+8); /* FIXME: Should this be 16 for SSE??? */
+h = top_padding + CALC_PADDING(h, MAX_DWT_LEVELS) + max_yblen / 2;
+
+s->plane[i].idwt.buf_base =
+av_calloc(w + max_xblen, h * (2 << s->pshift));
+s->plane[i].idwt.tmp = av_malloc_array((w + 16), 2 << s->pshift);
+s->plane[i].idwt.buf =
+s->plane[i].idwt.buf_base + (top_padding * w) * (2 << s->pshift);
 if (!s->plane[i].idwt.buf_base || !s->plane[i].idwt.tmp)
 return AVERROR(ENOMEM);
 }
 
 /* fixme: allocate using real stride here */
-s->sbsplit  = av_malloc_array(sbwidth, sbheight);
-s->blmotion = av_malloc_array(sbwidth, sbheight * 16 * 
sizeof(*s->blmotion));
+s->sbsplit = av_malloc_array(sbwidth, sbheight);
+s->blmotion =
+av_malloc_array(sbwidth, sbheight * 16 * sizeof(*s->blmotion));
 
 if (!s->sbsplit || !s->blmotion)
 return AVERROR(ENOMEM);
 return 0;
 }
 
-static int alloc_buffers(DiracContext *s, int stride)
-{
+static int alloc_buffers(DiracContext *s, int stride) {
 int w = s->seq.width;
 int h = s->seq.height;
 
@@ -124,7 +125,8 @@ static int alloc_buffers(DiracContext *s, int stride)
 
 s->edge_emu_buffer_base = av_malloc_array(stride, MAX_BLOCKSIZE);
 
-s->mctmp = av_malloc_array((stride+MAX_BLOCKSIZE), (h+MAX_BLOCKSIZE) * 
sizeof(*s->mctmp));
+s->mctmp = av_malloc_array((stride + MAX_BLOCKSIZE),
+   (h + MAX_BLOCKSIZE) * sizeof(*s->mctmp));
 s->mcscratch = av_malloc_array(stride, MAX_BLOCKSIZE);
 
 if (!s->edge_emu_buffer_base || !s->mctmp || !s->mcscratch)
@@ -134,14 +136,14 @@ static int alloc_buffers(DiracContext *s, int stride)

Re: [FFmpeg-devel] [PATCH 2/2] lavc: Add dirac vulkan hwaccel

2024-09-12 Thread Petro Mozil
Thanks for the review!
Sorry about those mistakes, fixed them here

---
 libavcodec/diracdec.c | 1275 +++--
 libavcodec/vulkan_dirac.c |   52 +-
 2 files changed, 687 insertions(+), 640 deletions(-)

diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index 542824f6e1..44614cc1a8 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -23,23 +23,22 @@
 /**
  * @file
  * Dirac Decoder
- * @author Marco Gerards , David Conrad, Jordi Ortiz <
nenjo...@gmail.com>
+ * @author Marco Gerards , David Conrad, Jordi Ortiz
+ * 
  */

 #include "diracdec.h"
+#include "config_components.h"
 #include "hwaccels.h"
 #include "hwconfig.h"
 #include "libavutil/imgutils.c"
-#include "config_components.h"

 /* magic number division by 3 from schroedinger */
-static inline int divide3(int x)
-{
-return (int)((x+1U)*21845 + 10922) >> 16;
+static inline int divide3(int x) {
+return (int)((x + 1U) * 21845 + 10922) >> 16;
 }

-static DiracFrame *remove_frame(DiracFrame *framelist[], unsigned picnum)
-{
+static DiracFrame *remove_frame(DiracFrame *framelist[], unsigned picnum) {
 DiracFrame *remove_pic = NULL;
 int i, remove_idx = -1;

@@ -51,13 +50,13 @@ static DiracFrame *remove_frame(DiracFrame
*framelist[], unsigned picnum)

 if (remove_pic)
 for (i = remove_idx; framelist[i]; i++)
-framelist[i] = framelist[i+1];
+framelist[i] = framelist[i + 1];

 return remove_pic;
 }

-static int add_frame(DiracFrame *framelist[], int maxframes, DiracFrame
*frame)
-{
+static int add_frame(DiracFrame *framelist[], int maxframes,
+ DiracFrame *frame) {
 int i;
 for (i = 0; i < maxframes; i++)
 if (!framelist[i]) {
@@ -67,9 +66,8 @@ static int add_frame(DiracFrame *framelist[], int
maxframes, DiracFrame *frame)
 return -1;
 }

-static int alloc_sequence_buffers(DiracContext *s)
-{
-int sbwidth  = DIVRNDUP(s->seq.width,  4);
+static int alloc_sequence_buffers(DiracContext *s) {
+int sbwidth = DIVRNDUP(s->seq.width, 4);
 int sbheight = DIVRNDUP(s->seq.height, 4);
 int i, w, h, top_padding;

@@ -77,7 +75,7 @@ static int alloc_sequence_buffers(DiracContext *s)
 for (i = 0; i < 3; i++) {
 int max_xblen = MAX_BLOCKSIZE >> (i ? s->chroma_x_shift : 0);
 int max_yblen = MAX_BLOCKSIZE >> (i ? s->chroma_y_shift : 0);
-w = s->seq.width  >> (i ? s->chroma_x_shift : 0);
+w = s->seq.width >> (i ? s->chroma_x_shift : 0);
 h = s->seq.height >> (i ? s->chroma_y_shift : 0);

 /* we allocate the max we support here since num decompositions can
@@ -85,28 +83,31 @@ static int alloc_sequence_buffers(DiracContext *s)
  * 1<0) in arith decoding
  * MAX_BLOCKSIZE padding for MC: blocks can spill up to half of
that
  * on each side */
-top_padding = FFMAX(1pshift));
-s->plane[i].idwt.tmp  = av_malloc_array((w+16), 2 <<
s->pshift);
-s->plane[i].idwt.buf  = s->plane[i].idwt.buf_base +
(top_padding*w)*(2 << s->pshift);
+top_padding = FFMAX(1 << MAX_DWT_LEVELS, max_yblen / 2);
+w = FFALIGN(CALC_PADDING(w, MAX_DWT_LEVELS),
+8); /* FIXME: Should this be 16 for SSE??? */
+h = top_padding + CALC_PADDING(h, MAX_DWT_LEVELS) + max_yblen / 2;
+
+s->plane[i].idwt.buf_base =
+av_calloc(w + max_xblen, h * (2 << s->pshift));
+s->plane[i].idwt.tmp = av_malloc_array((w + 16), 2 << s->pshift);
+s->plane[i].idwt.buf =
+s->plane[i].idwt.buf_base + (top_padding * w) * (2 <<
s->pshift);
 if (!s->plane[i].idwt.buf_base || !s->plane[i].idwt.tmp)
 return AVERROR(ENOMEM);
 }

 /* fixme: allocate using real stride here */
-s->sbsplit  = av_malloc_array(sbwidth, sbheight);
-s->blmotion = av_malloc_array(sbwidth, sbheight * 16 *
sizeof(*s->blmotion));
+s->sbsplit = av_malloc_array(sbwidth, sbheight);
+s->blmotion =
+av_malloc_array(sbwidth, sbheight * 16 * sizeof(*s->blmotion));

 if (!s->sbsplit || !s->blmotion)
 return AVERROR(ENOMEM);
 return 0;
 }

-static int alloc_buffers(DiracContext *s, int stride)
-{
+static int alloc_buffers(DiracContext *s, int stride) {
 int w = s->seq.width;
 int h = s->seq.height;

@@ -124,7 +125,8 @@ static int alloc_buffers(DiracContext *s, int stride)

 s->edge_emu_buffer_base = av_malloc_array(stride, MAX_BLOCKSIZE);

-s->mctmp = av_malloc_array((stride+MAX_BLOCKSIZE),
(h+MAX_BLOCKSIZE) * sizeof(*s->mctmp));
+s->mctmp = av_malloc_array((stride + MAX_BLOCKSIZE),
+   (h + MAX_BLOCKSIZE) * sizeof(*s->mctmp));
 s->mcscratch = av_malloc_array(stride, MAX_BLOCKSIZE);

 if (!s->edge_emu_buffer_base || !s->mctmp || !s->mcscratch)
@@ -134,14 +136,14 @@ static int alloc_buffers(DiracContext *s, int stride)
 return 0;
 }

-stat

Re: [FFmpeg-devel] [PATCH] tests/checkasm/sw_rgb: don't write random data past the end of the buffer

2024-09-12 Thread Ramiro Polla
On Thu, Sep 12, 2024 at 8:44 AM James Almer  wrote:
>
> Should fix fate-checkasm-sw_rgb under gcc-ubsan.
>
> Signed-off-by: James Almer 
> ---
>  tests/checkasm/sw_rgb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
> index af9434073a..cdd43df8ba 100644
> --- a/tests/checkasm/sw_rgb.c
> +++ b/tests/checkasm/sw_rgb.c
> @@ -287,7 +287,7 @@ static void check_deinterleave_bytes(void)
> int width, int height, int srcStride,
> int dst1Stride, int dst2Stride);
>
> -randomize_buffers(src, 2*MAX_STRIDE*MAX_HEIGHT+2);
> +randomize_buffers(src, 2*MAX_STRIDE*MAX_HEIGHT);

Thank you for spotting it.

The issue is that randomize_buffers() writes 4 bytes at a time. I
think the proper fix is to change randomize_buffers() to not write
past the end of the buffer. It would be even better to move
randomize_buffers() to checkasm.h or checkasm.c so it doesn't have to
be copied around so many times.
___
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] lavc: add hevc_vulkan hardware encoder

2024-09-12 Thread Lynne via ffmpeg-devel
This commit adds a Vulkan hardware HEVC encoder, with full support
of the spec - I, P, and B-frames.
---
 configure   |1 +
 libavcodec/Makefile |3 +
 libavcodec/allcodecs.c  |1 +
 libavcodec/vulkan_encode_h264.c |   14 +-
 libavcodec/vulkan_encode_h265.c | 1870 +++
 libavcodec/vulkan_hevc.c|   25 +-
 libavcodec/vulkan_video.c   |   29 +
 libavcodec/vulkan_video.h   |2 +
 8 files changed, 1916 insertions(+), 29 deletions(-)
 create mode 100644 libavcodec/vulkan_encode_h265.c

diff --git a/configure b/configure
index da36419f2d..8fbf3772a8 100755
--- a/configure
+++ b/configure
@@ -3388,6 +3388,7 @@ 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_vulkan_encoder_select="atsc_a53 cbs_h265 vulkan_encode"
 hevc_v4l2m2m_decoder_deps="v4l2_m2m hevc_v4l2_m2m"
 hevc_v4l2m2m_decoder_select="hevc_mp4toannexb_bsf"
 hevc_v4l2m2m_encoder_deps="v4l2_m2m hevc_v4l2_m2m"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 502be8b09b..82df93fff4 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -452,6 +452,9 @@ OBJS-$(CONFIG_HEVC_QSV_ENCODER)+= qsvenc_hevc.o 
hevc/ps_enc.o
 OBJS-$(CONFIG_HEVC_RKMPP_DECODER)  += rkmppdec.o
 OBJS-$(CONFIG_HEVC_VAAPI_ENCODER)  += vaapi_encode_h265.o 
h265_profile_level.o \
   h2645data.o
+OBJS-$(CONFIG_HEVC_VULKAN_ENCODER) += vulkan_encode.o vulkan_encode_h265.o 
\
+  hw_base_encode.o 
hw_base_encode_h265.o \
+  h265_profile_level.o h2645data.o
 OBJS-$(CONFIG_HEVC_V4L2M2M_DECODER)+= v4l2_m2m_dec.o
 OBJS-$(CONFIG_HEVC_V4L2M2M_ENCODER)+= v4l2_m2m_enc.o
 OBJS-$(CONFIG_HEVC_VIDEOTOOLBOX_ENCODER) += videotoolboxenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index cfd929b81f..aa0fc47647 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -862,6 +862,7 @@ extern const FFCodec ff_hevc_qsv_encoder;
 extern const FFCodec ff_hevc_v4l2m2m_encoder;
 extern const FFCodec ff_hevc_vaapi_encoder;
 extern const FFCodec ff_hevc_videotoolbox_encoder;
+extern const FFCodec ff_hevc_vulkan_encoder;
 extern const FFCodec ff_libkvazaar_encoder;
 extern const FFCodec ff_mjpeg_cuvid_decoder;
 extern const FFCodec ff_mjpeg_qsv_encoder;
diff --git a/libavcodec/vulkan_encode_h264.c b/libavcodec/vulkan_encode_h264.c
index aa72fd74fb..bbdc5a66a3 100644
--- a/libavcodec/vulkan_encode_h264.c
+++ b/libavcodec/vulkan_encode_h264.c
@@ -1460,20 +1460,20 @@ static av_cold int 
vulkan_encode_h264_init(AVCodecContext *avctx)
enc->caps.maxLevelIdc);
 av_log(avctx, AV_LOG_VERBOSE, "maxSliceCount: %i\n",
enc->caps.maxSliceCount);
-av_log(avctx, AV_LOG_VERBOSE, "max(P/B)PictureL0ReferenceCount: %i 
P's; %i B's\n",
+av_log(avctx, AV_LOG_VERBOSE, "max(P/B)PictureL0ReferenceCount: %i 
P's; %i B's\n",
enc->caps.maxPPictureL0ReferenceCount,
enc->caps.maxBPictureL0ReferenceCount);
-av_log(avctx, AV_LOG_VERBOSE, "maxL1ReferenceCount: %i\n",
+av_log(avctx, AV_LOG_VERBOSE, "maxL1ReferenceCount: %i\n",
enc->caps.maxL1ReferenceCount);
-av_log(avctx, AV_LOG_VERBOSE, "maxTemporalLayerCount: %i\n",
+av_log(avctx, AV_LOG_VERBOSE, "maxTemporalLayerCount: %i\n",
enc->caps.maxTemporalLayerCount);
-av_log(avctx, AV_LOG_VERBOSE, "expectDyadicTemporalLayerPattern: %i\n",
+av_log(avctx, AV_LOG_VERBOSE, "expectDyadicTemporalLayerPattern: 
%i\n",
enc->caps.expectDyadicTemporalLayerPattern);
-av_log(avctx, AV_LOG_VERBOSE, "min/max Qp: [%i, %i]\n",
+av_log(avctx, AV_LOG_VERBOSE, "min/max Qp: [%i, %i]\n",
enc->caps.maxQp, enc->caps.minQp);
-av_log(avctx, AV_LOG_VERBOSE, "prefersGopRemainingFrames: %i\n",
+av_log(avctx, AV_LOG_VERBOSE, "prefersGopRemainingFrames: %i\n",
enc->caps.prefersGopRemainingFrames);
-av_log(avctx, AV_LOG_VERBOSE, "requiresGopRemainingFrames: %i\n",
+av_log(avctx, AV_LOG_VERBOSE, "requiresGopRemainingFrames: %i\n",
enc->caps.requiresGopRemainingFrames);
 
 err = init_enc_options(avctx);
diff --git a/libavcodec/vulkan_encode_h265.c b/libavcodec/vulkan_encode_h265.c
new file mode 100644
index 00..c639053c22
--- /dev/null
+++ b/libavcodec/vulkan_encode_h265.c
@@ -0,0 +1,1870 @@
+/*
+ * 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

[FFmpeg-devel] [PATCH 1/3] cbs_h265: add raw filler encoding

2024-09-12 Thread Lynne via ffmpeg-devel
From: Dave Airlie 

---
 libavcodec/cbs_h2645.c| 17 
 libavcodec/cbs_h265.h |  6 ++
 libavcodec/cbs_h265_syntax_template.c | 29 +++
 3 files changed, 52 insertions(+)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 4abd9e0c2e..1969ad8116 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1055,6 +1055,14 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
*ctx,
 }
 break;
 
+case HEVC_NAL_FD_NUT:
+{
+err = cbs_h265_read_filler(ctx, &gbc, unit->content);
+if (err < 0)
+return err;
+}
+break;
+
 case HEVC_NAL_SEI_PREFIX:
 case HEVC_NAL_SEI_SUFFIX:
 {
@@ -1497,6 +1505,14 @@ static int cbs_h265_write_nal_unit(CodedBitstreamContext 
*ctx,
 }
 break;
 
+case HEVC_NAL_FD_NUT:
+{
+err = cbs_h265_write_filler(ctx, pbc, unit->content);
+if (err < 0)
+return err;
+}
+break;
+
 case HEVC_NAL_SEI_PREFIX:
 case HEVC_NAL_SEI_SUFFIX:
 {
@@ -2006,6 +2022,7 @@ static const CodedBitstreamUnitTypeDescriptor 
cbs_h265_unit_types[] = {
 CBS_UNIT_TYPE_INTERNAL_REF(HEVC_NAL_PPS, H265RawPPS, extension_data.data),
 
 CBS_UNIT_TYPE_POD(HEVC_NAL_AUD, H265RawAUD),
+CBS_UNIT_TYPE_POD(HEVC_NAL_FD_NUT,  H265RawFiller),
 
 // Slices of non-IRAP pictures.
 CBS_UNIT_RANGE_INTERNAL_REF(HEVC_NAL_TRAIL_N, HEVC_NAL_RASL_R,
diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
index 892a35bd22..26a5a34fe9 100644
--- a/libavcodec/cbs_h265.h
+++ b/libavcodec/cbs_h265.h
@@ -741,6 +741,12 @@ typedef struct H265RawSEI {
 SEIRawMessageListmessage_list;
 } H265RawSEI;
 
+typedef struct H265RawFiller {
+H265RawNALUnitHeader nal_unit_header;
+
+uint32_t filler_size;
+} H265RawFiller;
+
 typedef struct CodedBitstreamH265Context {
 // Reader/writer context in common with the H.264 implementation.
 CodedBitstreamH2645Context common;
diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 9f0281b8e8..1c11514435 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -2364,3 +2364,32 @@ static int FUNC(sei)(CodedBitstreamContext *ctx, 
RWContext *rw,
 
 return 0;
 }
+
+
+static int FUNC(filler)(CodedBitstreamContext *ctx, RWContext *rw,
+H265RawFiller *current)
+{
+int err;
+
+HEADER("Filler Data");
+
+CHECK(FUNC(nal_unit_header)(ctx, rw, ¤t->nal_unit_header,
+HEVC_NAL_FD_NUT));
+
+#ifdef READ
+while (show_bits(rw, 8) == 0xff) {
+fixed(8, ff_byte, 0xff);
+++current->filler_size;
+}
+#else
+{
+uint32_t i;
+for (i = 0; i < current->filler_size; i++)
+fixed(8, ff_byte, 0xff);
+}
+#endif
+
+CHECK(FUNC(rbsp_trailing_bits)(ctx, rw));
+
+return 0;
+}
-- 
2.45.2.753.g447d99e1c3b
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH 2/3] hw_base_encode_h265: split off SPS/PPS/VPS generation from VAAPI

2024-09-12 Thread Lynne via ffmpeg-devel
---
 libavcodec/hw_base_encode_h265.c | 351 +++
 libavcodec/hw_base_encode_h265.h |  56 +
 2 files changed, 407 insertions(+)
 create mode 100644 libavcodec/hw_base_encode_h265.c
 create mode 100644 libavcodec/hw_base_encode_h265.h

diff --git a/libavcodec/hw_base_encode_h265.c b/libavcodec/hw_base_encode_h265.c
new file mode 100644
index 00..dceec8aba9
--- /dev/null
+++ b/libavcodec/hw_base_encode_h265.c
@@ -0,0 +1,351 @@
+/*
+ * 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 "hw_base_encode_h265.h"
+
+#include "h2645data.h"
+#include "h265_profile_level.h"
+
+#include "libavutil/pixdesc.h"
+
+int ff_hw_base_encode_init_params_h265(FFHWBaseEncodeContext *base_ctx,
+   AVCodecContext *avctx,
+   FFHWBaseEncodeH265 *common,
+   FFHWBaseEncodeH265Opts *opts)
+{
+H265RawVPS*vps = &common->raw_vps;
+H265RawSPS*sps = &common->raw_sps;
+H265RawPPS*pps = &common->raw_pps;
+H265RawProfileTierLevel   *ptl = &vps->profile_tier_level;
+H265RawVUI*vui = &sps->vui;
+
+const AVPixFmtDescriptor *desc;
+int chroma_format, bit_depth;
+int i;
+
+memset(vps, 0, sizeof(*vps));
+memset(sps, 0, sizeof(*sps));
+memset(pps, 0, sizeof(*pps));
+
+desc = av_pix_fmt_desc_get(base_ctx->input_frames->sw_format);
+av_assert0(desc);
+if (desc->nb_components == 1) {
+chroma_format = 0;
+} else {
+if (desc->log2_chroma_w == 1 && desc->log2_chroma_h == 1) {
+chroma_format = 1;
+} else if (desc->log2_chroma_w == 1 && desc->log2_chroma_h == 0) {
+chroma_format = 2;
+} else if (desc->log2_chroma_w == 0 && desc->log2_chroma_h == 0) {
+chroma_format = 3;
+} else {
+av_log(avctx, AV_LOG_ERROR, "Chroma format of input pixel format "
+   "%s is not supported.\n", desc->name);
+return AVERROR(EINVAL);
+}
+}
+bit_depth = desc->comp[0].depth;
+
+
+// VPS
+
+vps->nal_unit_header = (H265RawNALUnitHeader) {
+.nal_unit_type = HEVC_NAL_VPS,
+.nuh_layer_id  = 0,
+.nuh_temporal_id_plus1 = 1,
+};
+
+vps->vps_video_parameter_set_id = 0;
+
+vps->vps_base_layer_internal_flag  = 1;
+vps->vps_base_layer_available_flag = 1;
+vps->vps_max_layers_minus1 = 0;
+vps->vps_max_sub_layers_minus1 = 0;
+vps->vps_temporal_id_nesting_flag  = 1;
+
+ptl->general_profile_space = 0;
+ptl->general_profile_idc   = avctx->profile;
+ptl->general_tier_flag = opts->tier;
+
+ptl->general_profile_compatibility_flag[ptl->general_profile_idc] = 1;
+
+if (ptl->general_profile_compatibility_flag[1])
+ptl->general_profile_compatibility_flag[2] = 1;
+if (ptl->general_profile_compatibility_flag[3]) {
+ptl->general_profile_compatibility_flag[1] = 1;
+ptl->general_profile_compatibility_flag[2] = 1;
+}
+
+ptl->general_progressive_source_flag= 1;
+ptl->general_interlaced_source_flag = 0;
+ptl->general_non_packed_constraint_flag = 1;
+ptl->general_frame_only_constraint_flag = 1;
+
+ptl->general_max_14bit_constraint_flag = bit_depth <= 14;
+ptl->general_max_12bit_constraint_flag = bit_depth <= 12;
+ptl->general_max_10bit_constraint_flag = bit_depth <= 10;
+ptl->general_max_8bit_constraint_flag  = bit_depth ==  8;
+
+ptl->general_max_422chroma_constraint_flag  = chroma_format <= 2;
+ptl->general_max_420chroma_constraint_flag  = chroma_format <= 1;
+ptl->general_max_monochrome_constraint_flag = chroma_format == 0;
+
+ptl->general_intra_constraint_flag = base_ctx->gop_size == 1;
+ptl->general_one_picture_only_constraint_flag = 0;
+
+ptl->general_lower_bit_rate_constraint_flag = 1;
+
+if (avctx->level != AV_LEVEL_UNKNOWN) {
+ptl->general_level_idc = avctx->level;
+} else {
+const H265LevelDescriptor *level;
+
+level = ff_h265_guess_level(ptl, avctx->bit_rate,
+base_ctx->surfac

Re: [FFmpeg-devel] [PATCH] tests/checkasm/sw_rgb: don't write random data past the end of the buffer

2024-09-12 Thread Martin Storsjö

On Thu, 12 Sep 2024, Ramiro Polla wrote:


On Thu, Sep 12, 2024 at 8:44 AM James Almer  wrote:


Should fix fate-checkasm-sw_rgb under gcc-ubsan.

Signed-off-by: James Almer 
---
 tests/checkasm/sw_rgb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index af9434073a..cdd43df8ba 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -287,7 +287,7 @@ static void check_deinterleave_bytes(void)
int width, int height, int srcStride,
int dst1Stride, int dst2Stride);

-randomize_buffers(src, 2*MAX_STRIDE*MAX_HEIGHT+2);
+randomize_buffers(src, 2*MAX_STRIDE*MAX_HEIGHT);


Thank you for spotting it.

The issue is that randomize_buffers() writes 4 bytes at a time. I
think the proper fix is to change randomize_buffers() to not write
past the end of the buffer. It would be even better to move
randomize_buffers() to checkasm.h or checkasm.c so it doesn't have to
be copied around so many times.


Maybe, but part of the point of having randomize_buffers() and similar be 
local to each test, is because the exact procedure for writing and the 
right kind of random differs for each test/function category.


// Martin
___
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] Procedure to enable the Windows on ARM64 FFMPEG Libraries

2024-09-12 Thread Martin Storsjö

On Thu, 12 Sep 2024, Niranjan Kshatriya (QUIC) wrote:

and compiled locally ( on ARM using WSL ) for Arm with tool chain : 
GitHub - Windows-on-ARM-Experiments/mingw-woarm64-build: Workflows and 
build scripts for Windows on Arm64 GNU cross-compiler for 
`aarch64-w64-mingw32` 
target. 
with below configuration :


./configure --arch=arm64 --target-os=mingw32 
--cross-prefix=aarch64-w64-mingw32- --prefix=/ffbuild/prefix 
--pkg-config-flags=--static --pkg-config=pkg-config --enable-gpl 
--enable-version3 --disable-debug --disable-w32threads --enable-pthreads 
--disable-libpulse --disable-libxcb


Just as a general headsup/warning - that toolchain is heavily in progress 
and not very mature yet (plus that it has known ABI discrepancies compared 
to established aarch64 mingw environments). If you're evaluating the 
toolchain or planning on working on it, that's of course fine.


If you want an actually mature mingw toolchain for aarch64, grab one from 
https://github.com/mstorsjo/llvm-mingw/releases.


(This is of course unrelated to what it takes to enable building 
windows/arm64 binaries in that third party repo.)


// Martin

___
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] avcodec/jpeg2000: Fix FF_DWT97_INT to pass the conformance testing defined in ISO/IEC 15444-4

2024-09-12 Thread Osamu Watanabe
Fix for the integer version of the inverse 9-7 DWT processing
(FF_DWT97_INT, https://trac.ffmpeg.org/ticket/10123), which is activated with
`-flags +bitexact`.

I went through the code path for the DWT 9-7 transform (integer) and improved
precision to match conformance codestream.

As a result, the encoded codestream size is slightly larger for a given Q value.
For example, `-flags +bitexact -i lena.pnm -q: 20 -format j2k -y tmp.j2c`
gives 13K (HEAD) and 19K (with this patch).

This commit also updates the source and reference files for affected FATE tests.

Signed-off-by: Osamu Watanabe 
---
 libavcodec/jpeg2000.c|  6 ++--
 libavcodec/jpeg2000dec.c |  2 +-
 libavcodec/jpeg2000dwt.c | 43 ++--
 libavcodec/tests/jpeg2000dwt.c   |  5 +++
 tests/ref/fate/j2k-dwt   | 40 +++---
 tests/ref/fate/jpeg2000-dcinema  |  4 +--
 tests/ref/fate/jpeg2000dec-p0_04 |  2 +-
 tests/ref/fate/jpeg2000dec-p0_05 |  2 +-
 tests/ref/fate/jpeg2000dec-p0_09 |  2 +-
 tests/ref/vsynth/vsynth1-jpeg2000-97 |  8 ++---
 tests/ref/vsynth/vsynth2-jpeg2000-97 |  8 ++---
 tests/ref/vsynth/vsynth3-jpeg2000-97 |  8 ++---
 tests/ref/vsynth/vsynth_lena-jpeg2000-97 |  8 ++---
 13 files changed, 74 insertions(+), 64 deletions(-)

diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
index d6ffb02319..f1a7d55ae1 100644
--- a/libavcodec/jpeg2000.c
+++ b/libavcodec/jpeg2000.c
@@ -260,9 +260,7 @@ static void init_band_stepsize(AVCodecContext *avctx,
 band->f_stepsize *= F_LFTG_X * F_LFTG_X * 4;
 break;
 }
-if (codsty->transform == FF_DWT97) {
-band->f_stepsize *= pow(F_LFTG_K, 2*(codsty->nreslevels2decode - 
reslevelno) + lband - 2);
-}
+band->f_stepsize *= pow(F_LFTG_K, 2*(codsty->nreslevels2decode - 
reslevelno) + lband - 2);
 }
 
 if (band->f_stepsize > (INT_MAX >> 15)) {
@@ -270,7 +268,7 @@ static void init_band_stepsize(AVCodecContext *avctx,
 av_log(avctx, AV_LOG_ERROR, "stepsize out of range\n");
 }
 
-band->i_stepsize = band->f_stepsize * (1 << 15);
+band->i_stepsize = lrint(band->f_stepsize * (1 << 15) + 0.5f);
 
 /* FIXME: In OpenJPEG code stepsize = stepsize * 0.5. Why?
  * If not set output of entropic decoder is not correct. */
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 2e09b279dc..f68e41ed6a 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -2136,7 +2136,7 @@ static void dequantization_int_97(int x, int y, 
Jpeg2000Cblk *cblk,
 int32_t *datap = &comp->i_data[(comp->coord[0][1] - comp->coord[0][0]) 
* (y + j) + x];
 int *src = t1->data + j*t1->stride;
 for (i = 0; i < w; ++i)
-datap[i] = (src[i] * (int64_t)band->i_stepsize + (1<<15)) >> 16;
+datap[i] = (int32_t)(src[i] * (int64_t)band->i_stepsize + (1 << 
14)) >> 15;
 }
 }
 
diff --git a/libavcodec/jpeg2000dwt.c b/libavcodec/jpeg2000dwt.c
index 34e33553f7..d24f15d39b 100644
--- a/libavcodec/jpeg2000dwt.c
+++ b/libavcodec/jpeg2000dwt.c
@@ -39,12 +39,12 @@
 
 /* Lifting parameters in integer format.
  * Computed as param = (float param) * (1 << 16) */
-#define I_LFTG_ALPHA  103949ll
-#define I_LFTG_BETA 3472ll
-#define I_LFTG_GAMMA   57862ll
-#define I_LFTG_DELTA   29066ll
-#define I_LFTG_K   80621ll
-#define I_LFTG_X   53274ll
+#define I_LFTG_ALPHA_PRIME   38413ll // = 103949 - 65536, (= alpha - 1.0)
+#define I_LFTG_BETA   3472ll
+#define I_LFTG_GAMMA 57862ll
+#define I_LFTG_DELTA 29066ll
+#define I_LFTG_K 80621ll
+#define I_LFTG_X 53274ll
 #define I_PRESHIFT 8
 
 static inline void extend53(int *p, int i0, int i1)
@@ -234,8 +234,11 @@ static void sd_1d97_int(int *p, int i0, int i1)
 extend97_int(p, i0, i1);
 i0++; i1++;
 
-for (i = (i0>>1) - 2; i < (i1>>1) + 1; i++)
-p[2 * i + 1] -= (I_LFTG_ALPHA * (p[2 * i] + p[2 * i + 2]) + (1 << 
15)) >> 16;
+for (i = (i0>>1) - 2; i < (i1>>1) + 1; i++) {
+const int64_t sum = p[2 * i] + p[2 * i + 2];
+p[2 * i + 1] -= sum;
+p[2 * i + 1] -= (I_LFTG_ALPHA_PRIME * sum + (1 << 15)) >> 16;
+}
 for (i = (i0>>1) - 1; i < (i1>>1) + 1; i++)
 p[2 * i] -= (I_LFTG_BETA  * (p[2 * i - 1] + p[2 * i + 1]) + (1 << 
15)) >> 16;
 for (i = (i0>>1) - 1; i < (i1>>1); i++)
@@ -276,7 +279,7 @@ static void dwt_encode97_int(DWTContext *s, int *t)
 
 // copy back and deinterleave
 for (i =   mv; i < lv; i+=2, j++)
-t[w*j + lp] = ((l[i] * I_LFTG_X) + (1 << 15)) >> 16;
+t[w*j + lp] = l[i];
 for (i = 1-mv; i < lv; i+=2, j++)
 t[w*j + lp] = l[i];
 }
@@ -293,7 +296,7 @@ static void dwt_encode97_int(DWTContext *s, int *t)
 
 // copy back and deinterleave
 for (i =   mh; i <

Re: [FFmpeg-devel] [PATCH v2 00/14] aarch64/vvc: Add SIMD

2024-09-12 Thread Martin Storsjö

On Thu, 12 Sep 2024, Zhao Zhili wrote:


From: Zhao Zhili 

Patches 1~9 has been updated according to Martin's review.

Patches 10~14 are new.

I have created a PR on github:
https://github.com/quink-black/FFmpeg/pull/2


Thanks for testing it through that set of tests!

No further comments from me on this set, it seems reasonable.

// Martin

___
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] libavformat/mxfdec.c: Recognize and Ignore MXF fill boxes

2024-09-12 Thread Nicolas Gaullier
>De : ffmpeg-devel  De la part de martin 
>schitter
>Envoyé : jeudi 12 septembre 2024 02:36
>
>But an elementary feature like 'fill' should be simply supported by any MXF 
>demuxer in a suitable manner, otherwise it's IMHO a grave defect.

>If you don't see any further objections, please just merge the patch and 
>finally solve this issue by this trivial solution till someone actually 
>contributes a better alternative.

The message "Recognize and Ignore" does not make it clear what issue or grave 
defect is solved here.
I see in the code that fill items are currently recognized as dark metadata and 
ignored likewise, but I don't see any issue here.
Maybe could you comment a little bit about your intent ?

Thanks
Nicolas
___
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] libavformat/mxfdec.c: Recognize and Ignore MXF fill boxes

2024-09-12 Thread martin schitter




On 12.09.24 13:14, Nicolas Gaullier wrote:

The message "Recognize and Ignore" does not make it clear what issue or grave 
defect is solved here.
I see in the code that fill items are currently recognized as dark metadata and 
ignored likewise, but I don't see any issue here.
Maybe could you comment a little bit about your intent ?


While developing this DNxUncompressed code I always got lots of this 
"Dark key ..." log messages in the debug output. This kind of output 
wouldn't be a surprise, if the key belongs to some rare and utterly 
irrelevant data box. but in this particular case the key stands for 
empty "fill" blocks, which are frequently used in various places in MXF 
files. They are an elementary building block of this container format.


On the muxer side of ffmpegs MXF code 'fill' is known and used in many 
places, but the demuxer doesn't recognize this element and just always 
prints these warnings about something "unknown". That's highly 
irritating and also inefficient, because 'fill' is used quite frequently 
e.g. as place holder to align frame data on 256byte boundaries etc.


It's really trivial to fix and I don't see, why we should debate any 
longer about this obvious flaw instead of just quickly solving the issue.


But if you want, you can rewrite the wording to "Recognize 'fill' in MXF 
data and suppress output" or whatever you like...


martin
___
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: don't write random data past the end of the buffer

2024-09-12 Thread James Almer

On 9/12/2024 5:16 AM, Ramiro Polla wrote:

On Thu, Sep 12, 2024 at 8:44 AM James Almer  wrote:


Should fix fate-checkasm-sw_rgb under gcc-ubsan.

Signed-off-by: James Almer 
---
  tests/checkasm/sw_rgb.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index af9434073a..cdd43df8ba 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -287,7 +287,7 @@ static void check_deinterleave_bytes(void)
 int width, int height, int srcStride,
 int dst1Stride, int dst2Stride);

-randomize_buffers(src, 2*MAX_STRIDE*MAX_HEIGHT+2);
+randomize_buffers(src, 2*MAX_STRIDE*MAX_HEIGHT);


Thank you for spotting it.

The issue is that randomize_buffers() writes 4 bytes at a time. I
think the proper fix is to change randomize_buffers() to not write
past the end of the buffer. It would be even better to move


2*MAX_STRIDE*MAX_HEIGHT is a multiple of 4 and the exact size of the 
available buffer, whereas 2*MAX_STRIDE*MAX_HEIGHT+2 isn't.



randomize_buffers() to checkasm.h or checkasm.c so it doesn't have to
be copied around so many times.
___
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".




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

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


Re: [FFmpeg-devel] [PATCH 1/2] lavc: add Vulkan video encoding base code

2024-09-12 Thread Benjamin Cheng via ffmpeg-devel
On Wed Sep 11, 2024 at 12:03 AM EDT, Lynne wrote:
> On 10/09/2024 15:29, Benjamin Cheng wrote:
> > On Mon Sep 9, 2024 at 6:37 AM EDT, Lynne via ffmpeg-devel wrote:
> >> This commit adds the common Vulkan video encoding framework.
> >> It makes full use of the asynchronous features of our new common
> >> hardware encoding code, and of Vulkan.
> >> The code is able to handle anything from H264 to AV1 and MJPEG.
> >> ---
> >>   configure  |   2 +
> >>   libavcodec/Makefile|   2 +-
> >>   libavcodec/vulkan_encode.c | 979 +
> >>   libavcodec/vulkan_encode.h | 243 +
> >>   4 files changed, 1225 insertions(+), 1 deletion(-)
> >>   create mode 100644 libavcodec/vulkan_encode.c
> >>   create mode 100644 libavcodec/vulkan_encode.h
> >>
> >> diff --git a/configure b/configure
> >> index a8e67d230c..6cfb736a86 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -2638,6 +2638,7 @@ CONFIG_EXTRA="
> >>   vp3dsp
> >>   vp56dsp
> >>   vp8dsp
> >> +vulkan_encode
> >>   wma_freqs
> >>   wmv2dsp
> >>   "
> >> @@ -3299,6 +3300,7 @@ qsvdec_select="qsv"
> >>   qsvenc_select="qsv"
> >>   qsvvpp_select="qsv"
> >>   vaapi_encode_deps="vaapi"
> >> +vulkan_encode_deps="vulkan"
> >>   v4l2_m2m_deps="linux_videodev2_h sem_timedwait"
> >>   
> >>   bilateral_cuda_filter_deps="ffnvcodec"
> >> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> >> index 27ef4638ce..ff6a3c4efc 100644
> >> --- a/libavcodec/Makefile
> >> +++ b/libavcodec/Makefile
> >> @@ -1282,7 +1282,7 @@ SKIPHEADERS-$(CONFIG_QSVENC)   += qsvenc.h
> >>   SKIPHEADERS-$(CONFIG_VAAPI)+= vaapi_decode.h vaapi_hevc.h 
> >> vaapi_encode.h
> >>   SKIPHEADERS-$(CONFIG_VDPAU)+= vdpau.h vdpau_internal.h
> >>   SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += videotoolbox.h vt_internal.h
> >> -SKIPHEADERS-$(CONFIG_VULKAN)   += vulkan.h vulkan_video.h 
> >> vulkan_decode.h
> >> +SKIPHEADERS-$(CONFIG_VULKAN)   += vulkan.h vulkan_video.h 
> >> vulkan_encode.h vulkan_decode.h
> >>   SKIPHEADERS-$(CONFIG_V4L2_M2M) += v4l2_buffers.h v4l2_context.h 
> >> v4l2_m2m.h
> >>   SKIPHEADERS-$(CONFIG_ZLIB) += zlib_wrapper.h
> >>   
> >> diff --git a/libavcodec/vulkan_encode.c b/libavcodec/vulkan_encode.c
> >> new file mode 100644
> >> index 00..5e87d4c073
> >> --- /dev/null
> >> +++ b/libavcodec/vulkan_encode.c
> >> @@ -0,0 +1,979 @@
> >> +/*
> >> + * 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/mem.h"
> >> +#include "libavutil/avassert.h"
> >> +#include "vulkan_encode.h"
> >> +#include "config.h"
> >> +
> >> +#include "libavutil/vulkan_loader.h"
> >> +
> >> +const AVCodecHWConfigInternal *const ff_vulkan_encode_hw_configs[] = {
> >> +HW_CONFIG_ENCODER_FRAMES(VULKAN, VULKAN),
> >> +NULL,
> >> +};
> >> +
> >> +av_cold void ff_vulkan_encode_uninit(FFVulkanEncodeContext *ctx)
> >> +{
> >> +FFVulkanContext *s = &ctx->s;
> >> +FFVulkanFunctions *vk = &s->vkfn;
> >> +
> >> +/* Wait on and free execution pool */
> >> +ff_vk_exec_pool_free(s, &ctx->enc_pool);
> >> +
> >> +/* Destroy the session params */
> >> +if (ctx->session_params)
> >> +vk->DestroyVideoSessionParametersKHR(s->hwctx->act_dev,
> >> + ctx->session_params,
> >> + s->hwctx->alloc);
> >> +
> >> +ff_hw_base_encode_close(&ctx->base);
> >> +
> >> +av_buffer_pool_uninit(&ctx->buf_pool);
> >> +
> >> +ff_vk_video_common_uninit(s, &ctx->common);
> >> +
> >> +ff_vk_uninit(s);
> >> +}
> >> +
> >> +static int vulkan_encode_init(AVCodecContext *avctx, 
> >> FFHWBaseEncodePicture *pic)
> >> +{
> >> +int err;
> >> +FFVulkanEncodeContext *ctx = avctx->priv_data;
> >> +FFVulkanEncodePicture *vp = pic->priv;
> >> +
> >> +AVFrame *f = pic->input_image;
> >> +AVHWFramesContext *hwfc = (AVHWFramesContext *)f->hw_frames_ctx->data;
> >> +AVVulkanFramesContext *vkfc = hwfc->hwctx;
> >> +AVVkFrame *vkf = (AVVkFrame *)f->data[0];
> >> +
> >> +if (ctx->codec->picture_priv_data_size > 0) {
> >> +

Re: [FFmpeg-devel] is libswscale maintained?

2024-09-12 Thread Ramiro Polla
Hi,

On Wed, Sep 11, 2024 at 2:21 AM Michael Niedermayer
 wrote:
> On Wed, Sep 11, 2024 at 02:45:59AM +0300, Andrew Randrianasulu wrote:
> > https://trac.ffmpeg.org/ticket/3345
> > https://trac.ffmpeg.org/ticket/7978
>
> I was not aware of these and ATM i dont have time but
> these smell like some constant somewhere is a little off

Coincidentally it's the exact same issue I had asked about on IRC one
day before.

I'm working on a fix which involves calculating the coefficient,
offset, and max value in ff_sws_init_range_convert() based on the bit
depth. The constants could be fixed and hardcoded again, but I prefer
having a clear explanation of where they come from in code.

It requires updating simd code (to take 3 extra parameters: int coeff,
int offset, int amax), and I don't have access to loongson or riscv.

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

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


Re: [FFmpeg-devel] is libswscale maintained?

2024-09-12 Thread Rémi Denis-Courmont


Le 12 septembre 2024 16:43:29 GMT+03:00, Ramiro Polla  
a écrit :
>Hi,
>
>On Wed, Sep 11, 2024 at 2:21 AM Michael Niedermayer
> wrote:
>> On Wed, Sep 11, 2024 at 02:45:59AM +0300, Andrew Randrianasulu wrote:
>> > https://trac.ffmpeg.org/ticket/3345
>> > https://trac.ffmpeg.org/ticket/7978
>>
>> I was not aware of these and ATM i dont have time but
>> these smell like some constant somewhere is a little off
>
>Coincidentally it's the exact same issue I had asked about on IRC one
>day before.
>
>I'm working on a fix which involves calculating the coefficient,
>offset, and max value in ff_sws_init_range_convert() based on the bit
>depth. The constants could be fixed and hardcoded again, but I prefer
>having a clear explanation of where they come from in code.
>
>It requires updating simd code (to take 3 extra parameters: int coeff,
>int offset, int amax), and I don't have access to loongson or riscv.

Just comment the would-be broken code out?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH] lavc/vvc_mc: R-V V avg w_avg

2024-09-12 Thread flow gg
ping

flow gg  于2024年8月28日周三 14:38写道:

> Updated: zve32x -> zve32x, zbb, zba
>
>  于2024年8月28日周三 14:37写道:
>
>> From: sunyuechi 
>>
>>  C908   X60
>> avg_8_2x2_c:1.21.0
>> avg_8_2x2_rvv_i32  :0.70.7
>> avg_8_2x4_c:2.02.2
>> avg_8_2x4_rvv_i32  :1.21.2
>> avg_8_2x8_c:3.74.0
>> avg_8_2x8_rvv_i32  :1.71.5
>> avg_8_2x16_c   :7.27.7
>> avg_8_2x16_rvv_i32 :3.02.7
>> avg_8_2x32_c   :   14.2   15.2
>> avg_8_2x32_rvv_i32 :5.55.0
>> avg_8_2x64_c   :   51.0   43.7
>> avg_8_2x64_rvv_i32 :   39.2   29.7
>> avg_8_2x128_c  :  100.5   79.2
>> avg_8_2x128_rvv_i32:   79.7   68.2
>> avg_8_4x2_c:1.72.0
>> avg_8_4x2_rvv_i32  :1.00.7
>> avg_8_4x4_c:3.53.7
>> avg_8_4x4_rvv_i32  :1.21.2
>> avg_8_4x8_c:6.77.0
>> avg_8_4x8_rvv_i32  :1.71.5
>> avg_8_4x16_c   :   13.5   14.0
>> avg_8_4x16_rvv_i32 :3.02.7
>> avg_8_4x32_c   :   26.2   27.7
>> avg_8_4x32_rvv_i32 :5.54.7
>> avg_8_4x64_c   :   73.0   73.7
>> avg_8_4x64_rvv_i32 :   39.0   32.5
>> avg_8_4x128_c  :  143.0  137.2
>> avg_8_4x128_rvv_i32:   72.7   68.0
>> avg_8_8x2_c:3.53.5
>> avg_8_8x2_rvv_i32  :1.00.7
>> avg_8_8x4_c:6.26.5
>> avg_8_8x4_rvv_i32  :1.51.0
>> avg_8_8x8_c:   12.7   13.2
>> avg_8_8x8_rvv_i32  :2.01.5
>> avg_8_8x16_c   :   25.0   26.5
>> avg_8_8x16_rvv_i32 :3.22.7
>> avg_8_8x32_c   :   50.0   52.7
>> avg_8_8x32_rvv_i32 :6.25.0
>> avg_8_8x64_c   :  118.7  122.5
>> avg_8_8x64_rvv_i32 :   40.2   31.5
>> avg_8_8x128_c  :  236.7  220.2
>> avg_8_8x128_rvv_i32:   85.2   67.7
>> avg_8_16x2_c   :6.26.7
>> avg_8_16x2_rvv_i32 :1.20.7
>> avg_8_16x4_c   :   12.5   13.0
>> avg_8_16x4_rvv_i32 :1.71.0
>> avg_8_16x8_c   :   24.5   26.0
>> avg_8_16x8_rvv_i32 :3.01.7
>> avg_8_16x16_c  :   49.0   51.5
>> avg_8_16x16_rvv_i32:5.53.0
>> avg_8_16x32_c  :   97.5  102.5
>> avg_8_16x32_rvv_i32:   10.55.5
>> avg_8_16x64_c  :  213.7  222.0
>> avg_8_16x64_rvv_i32:   48.5   34.2
>> avg_8_16x128_c :  434.7  420.0
>> avg_8_16x128_rvv_i32   :   97.7   74.0
>> avg_8_32x2_c   :   12.2   12.7
>> avg_8_32x2_rvv_i32 :1.51.0
>> avg_8_32x4_c   :   24.5   25.5
>> avg_8_32x4_rvv_i32 :3.01.7
>> avg_8_32x8_c   :   48.5   50.7
>> avg_8_32x8_rvv_i32 :5.22.7
>> avg_8_32x16_c  :   96.7  101.2
>> avg_8_32x16_rvv_i32:   10.25.0
>> avg_8_32x32_c  :  192.7  202.2
>> avg_8_32x32_rvv_i32:   19.79.5
>> avg_8_32x64_c  :  427.5  426.5
>> avg_8_32x64_rvv_i32:   64.2   18.2
>> avg_8_32x128_c 

[FFmpeg-devel] [PATCH 11/11] avfilter: add an LCEVC decoding filter via LCEVCdec

2024-09-12 Thread James Almer
Signed-off-by: James Almer 
---
 configure|   1 +
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/version.h|   4 +-
 libavfilter/vf_lcevc.c   | 434 +++
 5 files changed, 439 insertions(+), 2 deletions(-)
 create mode 100644 libavfilter/vf_lcevc.c

diff --git a/configure b/configure
index e528714735..e88f4490b4 100755
--- a/configure
+++ b/configure
@@ -3891,6 +3891,7 @@ identity_filter_select="scene_sad"
 interlace_filter_deps="gpl"
 kerndeint_filter_deps="gpl"
 ladspa_filter_deps="ladspa libdl"
+lcevc_filter_deps="liblcevc_dec"
 lensfun_filter_deps="liblensfun version3"
 libplacebo_filter_deps="libplacebo vulkan"
 lv2_filter_deps="lv2"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index ac6a8d5783..91487afb21 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -360,6 +360,7 @@ OBJS-$(CONFIG_INTERLEAVE_FILTER) += 
f_interleave.o
 OBJS-$(CONFIG_KERNDEINT_FILTER)  += vf_kerndeint.o
 OBJS-$(CONFIG_KIRSCH_FILTER) += vf_convolution.o
 OBJS-$(CONFIG_LAGFUN_FILTER) += vf_lagfun.o
+OBJS-$(CONFIG_LCEVC_FILTER)  += vf_lcevc.o
 OBJS-$(CONFIG_LATENCY_FILTER)+= f_latency.o
 OBJS-$(CONFIG_LENSCORRECTION_FILTER) += vf_lenscorrection.o
 OBJS-$(CONFIG_LENSFUN_FILTER)+= vf_lensfun.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 8e7d912c9f..9819f0f95b 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -337,6 +337,7 @@ extern const AVFilter ff_vf_kerndeint;
 extern const AVFilter ff_vf_kirsch;
 extern const AVFilter ff_vf_lagfun;
 extern const AVFilter ff_vf_latency;
+extern const AVFilter ff_vf_lcevc;
 extern const AVFilter ff_vf_lenscorrection;
 extern const AVFilter ff_vf_lensfun;
 extern const AVFilter ff_vf_libplacebo;
diff --git a/libavfilter/version.h b/libavfilter/version.h
index d8cd8a2cfb..7e0eb9af97 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -31,8 +31,8 @@
 
 #include "version_major.h"
 
-#define LIBAVFILTER_VERSION_MINOR   2
-#define LIBAVFILTER_VERSION_MICRO 102
+#define LIBAVFILTER_VERSION_MINOR   3
+#define LIBAVFILTER_VERSION_MICRO 100
 
 
 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
diff --git a/libavfilter/vf_lcevc.c b/libavfilter/vf_lcevc.c
new file mode 100644
index 00..843692cf40
--- /dev/null
+++ b/libavfilter/vf_lcevc.c
@@ -0,0 +1,434 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * Copyright (c) 2024 James Almer 
+ *
+ * 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 "libavutil/internal.h"
+#include "libavutil/opt.h"
+#include "filters.h"
+#include "video.h"
+
+typedef struct LCEVCContext {
+LCEVC_DecoderHandle decoder;
+LCEVC_PictureHandle base;
+int w, h;
+} LCEVCContext;
+
+static LCEVC_ColorFormat map_format(int format)
+{
+switch (format) {
+case AV_PIX_FMT_YUV420P:
+return LCEVC_I420_8;
+case AV_PIX_FMT_YUV420P10:
+return LCEVC_I420_10_LE;
+case AV_PIX_FMT_NV12:
+return LCEVC_NV12_8;
+case AV_PIX_FMT_NV21:
+return LCEVC_NV21_8;
+case AV_PIX_FMT_GRAY8:
+return LCEVC_GRAY_8;
+case AV_PIX_FMT_GRAY10LE:
+return LCEVC_GRAY_10_LE;
+}
+
+return LCEVC_ColorFormat_Unknown;
+}
+
+static inline LCEVC_ColorRange map_range(int range)
+{
+switch (range) {
+case AVCOL_RANGE_MPEG:
+return LCEVC_ColorRange_Limited;
+case AVCOL_RANGE_JPEG:
+return LCEVC_ColorRange_Full;
+}
+
+return LCEVC_ColorRange_Unknown;
+}
+
+static inline enum AVColorRange map_av_range(int range)
+{
+switch (range) {
+case LCEVC_ColorRange_Limited:
+return AVCOL_RANGE_MPEG;
+case LCEVC_ColorRange_Full:
+return AVCOL_RANGE_JPEG;
+}
+
+return AVCOL_RANGE_UNSPECIFIED;
+}
+
+static int alloc_base_frame(AVFilterLink *inlink, const AVFrame *in,
+LCEVC_PictureHandle *picture)
+{
+AVFilterContext *ctx = inlink->dst;
+LCEVCContext *lcevc = ctx->priv;
+LCEVC_PictureDesc desc;
+LCEVC_PicturePlaneDesc planes[AV_VIDEO_MAX_PLANES] = { 0 };
+LCEVC_ColorFormat fmt = map_format(in->format);
+int width = i

Re: [FFmpeg-devel] [PATCH 3/5] avcodec/decode: Check progress before dereferencing

2024-09-12 Thread Michael Niedermayer
On Tue, Jun 25, 2024 at 09:51:32PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Sat, Apr 27, 2024 at 01:13:54PM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> Fixes: NULL pointer dereference
> >>> Fixes: 
> >>> 68192/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP8_fuzzer-6180311026171904
> >>>
> >>> Found-by: continuous fuzzing process 
> >>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >>> Signed-off-by: Michael Niedermayer 
> >>> ---
> >>>  libavcodec/decode.c | 2 ++
> >>>  1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> >>> index d031b1ca176..a6131941f43 100644
> >>> --- a/libavcodec/decode.c
> >>> +++ b/libavcodec/decode.c
> >>> @@ -1744,6 +1744,8 @@ void ff_progress_frame_report(ProgressFrame *f, int 
> >>> n)
> >>>  
> >>>  void ff_progress_frame_await(const ProgressFrame *f, int n)
> >>>  {
> >>> +if (!f->progress)
> >>> +return;
> >>>  ff_thread_progress_await(&f->progress->progress, n);
> >>>  }
> >>>  
> >>
> >> Can I get the sample? I see two places in VP8 where the VP8Frame
> >> pointers are set before the actual frame inside it is properly allocated.
> >>
> >> (Actually, it was intended for this API to not support waiting on
> >> non-existent frames (i.e. let the caller check for this; in most
> >> instances, it is already guaranteed that the frame one waits one exists,
> >> so this is unnecessary for them).)
> > 
> > did you receive the sample i sent you in april ?
> > 
> > any update on this ?
> > its still crashing without this patch
> > 
> > Running: 
> > 68192/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP8_fuzzer-6180311026171904
> > libavcodec/decode.c:1766:44: runtime error: member access within null 
> > pointer of type 'struct ProgressInternal'
> > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> > libavcodec/decode.c:1766:44 in
> > libavcodec/threadprogress.c:72:36: runtime error: member access within null 
> > pointer of type 'ThreadProgress' (aka 'struct ThreadProgress')
> > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> > libavcodec/threadprogress.c:72:36 in
> > 
> 
> Totally forgot about this. Will look into it. Thanks for the reminder.

Hello ?
this issue is still open

thx

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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 v3 1/2] configure: fix symbol prefix detection

2024-09-12 Thread Marvin Scholz
The symbol prefix check would incorrectly detect a bogus prefix in
circumstances where sanitizers instrument the build, like when
configuring with the clang-asan toolchain where it would detect the
prefix as __odr_asan_gen_, which is obviously wrong.

To fix this, adjust the prefix detection to only detect a
one-character prefix, which is the only case that matters
anywhere right now.
---
 configure | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index d3bd46f382a..ad5bf6d6844 100755
--- a/configure
+++ b/configure
@@ -6131,13 +6131,15 @@ enable_weak_pic() {
 enabled pic && enable_weak_pic
 
 test_cc 

[FFmpeg-devel] [PATCH v3 2/2] configure: correctly set sanitizer toolchain compilers

2024-09-12 Thread Marvin Scholz
Previously only the C compiler was set, which would lead to
confusing situations where even though clang-asan was selected,
it would still use g++ for C++ code, failing because configure
does not support mixing compilers in this way (which is a separate
issue not addressed by this commit).
---
 configure | 70 ---
 1 file changed, 41 insertions(+), 29 deletions(-)

diff --git a/configure b/configure
index ad5bf6d6844..29bac713df0 100755
--- a/configure
+++ b/configure
@@ -4547,41 +4547,53 @@ test -n "$valgrind" && toolchain="valgrind-memcheck"
 enabled ossfuzz && ! echo $CFLAGS | grep -q -- "-fsanitize="  && ! echo 
$CFLAGS | grep -q -- "-fcoverage-mapping" &&{
 add_cflags  -fsanitize=address,undefined 
-fsanitize-coverage=trace-pc-guard,trace-cmp -fno-omit-frame-pointer
 add_ldflags -fsanitize=address,undefined 
-fsanitize-coverage=trace-pc-guard,trace-cmp
 }
 
+add_sanitizer_flags(){
+case "$1" in
+asan)
+add_cflags  -fsanitize=address
+add_ldflags -fsanitize=address
+;;
+lsan)
+add_cflags  -fsanitize=leak
+add_ldflags -fsanitize=leak
+;;
+msan)
+add_cflags  -fsanitize=memory -fsanitize-memory-track-origins
+add_ldflags -fsanitize=memory
+;;
+tsan)
+add_cflags  -fsanitize=thread
+add_ldflags -fsanitize=thread
+;;
+usan)
+add_cflags  -fsanitize=undefined
+add_ldflags -fsanitize=undefined
+;;
+?*)
+die "Unknown sanitizer $1"
+;;
+esac
+}
+
 case "$toolchain" in
-*-asan)
-cc_default="${toolchain%-asan}"
-add_cflags  -fsanitize=address
-add_ldflags -fsanitize=address
-;;
-*-lsan)
-cc_default="${toolchain%-lsan}"
-add_cflags  -fsanitize=leak
-add_ldflags -fsanitize=leak
-;;
-*-msan)
-cc_default="${toolchain%-msan}"
-add_cflags  -fsanitize=memory -fsanitize-memory-track-origins
-add_ldflags -fsanitize=memory
-;;
-*-tsan)
-cc_default="${toolchain%-tsan}"
-add_cflags  -fsanitize=thread
-add_ldflags -fsanitize=thread
-case "$toolchain" in
-gcc-tsan)
-add_cflags  -fPIC
-add_ldflags -fPIC
-;;
-esac
+clang-*)
+add_sanitizer_flags "${toolchain#clang-}"
+cc_default="clang"
+cxx_default="clang++"
 ;;
-*-usan)
-cc_default="${toolchain%-usan}"
-add_cflags  -fsanitize=undefined
-add_ldflags -fsanitize=undefined
+gcc-*)
+add_sanitizer_flags "${toolchain#gcc-}"
+cc_default="gcc"
+cxx_default="g++"
+# In case of tsan with gcc, PIC has to be enabled
+if [ "${toolchain#gcc-}" = "tsan" ]; then
+add_cflags  -fPIC
+add_ldflags -fPIC
+fi
 ;;
 valgrind-*)
 target_exec_default="valgrind"
 case "$toolchain" in
 valgrind-massif)
-- 
2.46.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH v2] configure: fix symbol prefix detection

2024-09-12 Thread epirat07


On 12 Sep 2024, at 8:03, Martin Storsjö wrote:

> On Wed, 11 Sep 2024, Marvin Scholz wrote:
>
>> The symbol prefix check would incorrectly detect a bogus prefix in 
>> circumstances where sanitizers
>> instrument the build, like when configuring with the clang-asan toolchain 
>> where it would detect the
>> prefix as __odr_asan_gen_, which is obviously wrong.
>>
>> To fix this, adjust the prefix detection to only detect a one-character 
>> prefix, which is the only case
>> that matters anywhere right now.
>> ---
>> configure | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index d3bd46f382a..7e84272b74b 100755
>> --- a/configure
>> +++ b/configure
>> @@ -6131,13 +6131,15 @@ enable_weak_pic() {
>> enabled pic && enable_weak_pic
>>
>> test_cc <> int ff_extern;
>> EOF
>> -sym=$($nm $TMPO | awk '/ff_extern/{ print substr($0, match($0, /[^ 
>> \t]*ff_extern/)) }')
>> +sym=$($nm $TMPO | awk '/[ \t]+[^ \t]{0,1}ff_extern/{ print substr($0, 
>> match($0, /[^ \t]{0,1}ff_extern$/)) }')
>> extern_prefix=${sym%%ff_extern*}
>
> Since we're checking for ff_extern$ in the substr match, would it be safest 
> to include the $ in the initial ff_extern match as well? So if there's a 
> _ff_extern$foo symbol listed first, that won't be matched?
>

Indeed, sent a v3 where this is fixed.

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

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


[FFmpeg-devel] [PATCH 1/7] avformat/mov_chan: Check for FF_SANE_NB_CHANNELS

2024-09-12 Thread Michael Niedermayer
We do not support more channels. For example avcodec_open2() limits channels 
this way too

The example file contains multiple chunks with over 16 million channels

Fixes: Timeout / DOS
Fixes: 
67143/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-4858720481771520

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/mov_chan.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
index cc5b3331290..2cc6b2a7797 100644
--- a/libavformat/mov_chan.c
+++ b/libavformat/mov_chan.c
@@ -30,6 +30,7 @@
 #include "libavutil/channel_layout.h"
 #include "libavutil/mem.h"
 #include "libavcodec/codec_id.h"
+#include "libavcodec/internal.h"
 #include "mov_chan.h"
 
 enum {
@@ -549,6 +550,10 @@ int ff_mov_read_chan(AVFormatContext *s, AVIOContext *pb, 
AVStream *st,
num_descr, nb_channels);
 num_descr = nb_channels;
 }
+if (nb_channels > FF_SANE_NB_CHANNELS) {
+ret = AVERROR(ENOTSUP);
+goto out;
+}
 
 av_channel_layout_uninit(ch_layout);
 ret = av_channel_layout_custom_init(ch_layout, nb_channels);
-- 
2.46.0

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

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


[FFmpeg-devel] [PATCH 2/7] avcodec/vc2enc: basic sanity check on slice_max_bytes

2024-09-12 Thread Michael Niedermayer
Fixes: left shift of 896021632 by 3 places cannot be represented in type 'int'
Fixes: 
70544/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC2_fuzzer-6685593652756480

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/vc2enc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 508defc0b9f..b82370a7532 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -988,7 +988,7 @@ static av_cold int vc2_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 }
 
 s->slice_min_bytes = s->slice_max_bytes - 
s->slice_max_bytes*(s->tolerance/100.0f);
-if (s->slice_min_bytes < 0)
+if (s->slice_min_bytes < 0 || s->slice_max_bytes > INT_MAX >> 3)
 return AVERROR(EINVAL);
 
 ret = encode_frame(s, avpkt, frame, aux_data, header_size, s->interlaced);
-- 
2.46.0

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

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


[FFmpeg-devel] [PATCH 3/7] swscale/swscale: Use unsigned operation to avoid undefined behavior

2024-09-12 Thread Michael Niedermayer
I have not checked that the constant is correct, this just fixes the undefined 
behavior

Fixes: signed integer overflow: -646656 * 3517 cannot be represented in type 
'int
Fixes: 70559/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-5209368631508992

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libswscale/swscale.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index df0d5708aa8..8b6a3a84b4e 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -224,7 +224,7 @@ static void lumRangeFromJpeg16_c(int16_t *_dst, int width)
 int i;
 int32_t *dst = (int32_t *) _dst;
 for (i = 0; i < width; i++)
-dst[i] = (dst[i]*(14071/4) + (33561947<<4)/4)>>12;
+dst[i] = ((int)(dst[i]*(14071U/4) + (33561947<<4)/4)) >> 12;
 }
 
 
-- 
2.46.0

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

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


[FFmpeg-devel] [PATCH 4/7] avformat/mxfdec: Check timecode for overflow

2024-09-12 Thread Michael Niedermayer
Fixes: signed integer overflow: 9223372036840103968 + 538976288 cannot be 
represented in type 'long'
Fixes: 
70604/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-4844090340999168

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfdec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index ac63c0d5add..8eae9f87afa 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2391,6 +2391,9 @@ static int mxf_parse_physical_source_package(MXFContext 
*mxf, MXFTrack *source_t
   physical_track->edit_rate,
   source_track->edit_rate);
 
+if (av_sat_add64(start_position, mxf_tc->start_frame) != 
start_position + (uint64_t)mxf_tc->start_frame)
+continue;
+
 if (av_timecode_init(&tc, mxf_tc->rate, flags, start_position 
+ mxf_tc->start_frame, mxf->fc) == 0) {
 mxf_add_timecode_metadata(&st->metadata, "timecode", &tc);
 return 0;
-- 
2.46.0

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

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


[FFmpeg-devel] [PATCH 5/7] avformat/mxfdec: More offset_temp checks

2024-09-12 Thread Michael Niedermayer
Fixes: signed integer overflow: 9223372036854775807 - -1927491430256034080 
cannot be represented in type 'long'
Fixes: 
70607/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-5282235077951488

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfdec.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 8eae9f87afa..41281c5196d 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1924,6 +1924,11 @@ static int mxf_edit_unit_absolute_offset(MXFContext 
*mxf, MXFIndexTable *index_t
 return mxf_absolute_bodysid_offset(mxf, index_table->body_sid, 
offset_temp, offset_out, partition_out);
 } else {
 /* EditUnitByteCount == 0 for VBR indexes, which is fine since 
they use explicit StreamOffsets */
+if (s->edit_unit_byte_count &&  s->index_duration > INT64_MAX / 
s->edit_unit_byte_count ||
+s->edit_unit_byte_count * s->index_duration > INT64_MAX - 
offset_temp
+)
+return AVERROR_INVALIDDATA;
+
 offset_temp += s->edit_unit_byte_count * s->index_duration;
 }
 }
-- 
2.46.0

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

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


[FFmpeg-devel] [PATCH 6/7] swscale/output: Fix undefined integer overflow in yuv2rgba64_2_c_template()

2024-09-12 Thread Michael Niedermayer
Fixes: signed integer overflow: -1082982400 + -1083218484 cannot be represented 
in type 'int'
Fixes: 70657/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-6707819712675840

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libswscale/output.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/libswscale/output.c b/libswscale/output.c
index abfb0fd1cee..31921a3ccec 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -1150,8 +1150,8 @@ yuv2rgba64_2_c_template(SwsContext *c, const int32_t 
*buf[2],
 av_assert2(uvalpha <= 4096U);
 
 for (i = 0; i < ((dstW + 1) >> 1); i++) {
-int Y1 = (buf0[i * 2] * yalpha1  + buf1[i * 2] * yalpha) >> 14;
-int Y2 = (buf0[i * 2 + 1] * yalpha1  + buf1[i * 2 + 1] * yalpha) >> 14;
+unsigned Y1 = (buf0[i * 2] * yalpha1  + buf1[i * 2] * yalpha) 
>> 14;
+unsigned Y2 = (buf0[i * 2 + 1] * yalpha1  + buf1[i * 2 + 1] * yalpha) 
>> 14;
 int U  = (ubuf0[i]* uvalpha1 + ubuf1[i]* uvalpha - 
(128 << 23)) >> 14;
 int V  = (vbuf0[i]* uvalpha1 + vbuf1[i]* uvalpha - 
(128 << 23)) >> 14;
 int R, G, B;
@@ -1175,20 +1175,20 @@ yuv2rgba64_2_c_template(SwsContext *c, const int32_t 
*buf[2],
 A2 += 1 << 13;
 }
 
-output_pixel(&dest[0], av_clip_uintp2(((R_B + Y1) >> 14) + (1<<15), 
16));
-output_pixel(&dest[1], av_clip_uintp2(((  G + Y1) >> 14) + (1<<15), 
16));
-output_pixel(&dest[2], av_clip_uintp2(((B_R + Y1) >> 14) + (1<<15), 
16));
+output_pixel(&dest[0], av_clip_uintp2(((int)(R_B + Y1) >> 14) + 
(1<<15), 16));
+output_pixel(&dest[1], av_clip_uintp2(((int)(  G + Y1) >> 14) + 
(1<<15), 16));
+output_pixel(&dest[2], av_clip_uintp2(((int)(B_R + Y1) >> 14) + 
(1<<15), 16));
 if (eightbytes) {
 output_pixel(&dest[3], av_clip_uintp2(A1  , 30) >> 14);
-output_pixel(&dest[4], av_clip_uintp2(((R_B + Y2) >> 14) + 
(1<<15), 16));
-output_pixel(&dest[5], av_clip_uintp2(((  G + Y2) >> 14) + 
(1<<15), 16));
-output_pixel(&dest[6], av_clip_uintp2(((B_R + Y2) >> 14) + 
(1<<15), 16));
+output_pixel(&dest[4], av_clip_uintp2(((int)(R_B + Y2) >> 14) + 
(1<<15), 16));
+output_pixel(&dest[5], av_clip_uintp2(((int)(  G + Y2) >> 14) + 
(1<<15), 16));
+output_pixel(&dest[6], av_clip_uintp2(((int)(B_R + Y2) >> 14) + 
(1<<15), 16));
 output_pixel(&dest[7], av_clip_uintp2(A2  , 30) >> 14);
 dest += 8;
 } else {
-output_pixel(&dest[3], av_clip_uintp2(((R_B + Y2) >> 14) + 
(1<<15), 16));
-output_pixel(&dest[4], av_clip_uintp2(((  G + Y2) >> 14) + 
(1<<15), 16));
-output_pixel(&dest[5], av_clip_uintp2(((B_R + Y2) >> 14) + 
(1<<15), 16));
+output_pixel(&dest[3], av_clip_uintp2(((int)(R_B + Y2) >> 14) + 
(1<<15), 16));
+output_pixel(&dest[4], av_clip_uintp2(((int)(  G + Y2) >> 14) + 
(1<<15), 16));
+output_pixel(&dest[5], av_clip_uintp2(((int)(B_R + Y2) >> 14) + 
(1<<15), 16));
 dest += 6;
 }
 }
-- 
2.46.0

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

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


[FFmpeg-devel] [PATCH 7/7] avformat/flvdec: Free metaVideoColor

2024-09-12 Thread Michael Niedermayer
Fixes: memeleak
Fixes: 
70659/clusterfuzz-testcase-minimized-ffmpeg_dem_KUX_fuzzer-4539872627458048

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/flvdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 22a9b9e4a7c..1fb3e0cd3fa 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -,6 +,7 @@ static int flv_parse_video_color_info(AVFormatContext *s, 
AVStream *st, int64_t
 return TYPE_UNKNOWN;
 }
 
+av_free(flv->metaVideoColor);
 if (!(flv->metaVideoColor = av_mallocz(sizeof(FLVMetaVideoColor {
 return AVERROR(ENOMEM);
 }
-- 
2.46.0

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

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


Re: [FFmpeg-devel] [PATCH] lavc: Fix epirats suggestions

2024-09-12 Thread Marvin Scholz
On 12 Sep 2024, at 9:35, Petro Mozil wrote:

The subject of the email will become the commit message, clearly

   lavc: Fix epirats suggestions

is not a proper one. Also please do not send patches of patches,
instead do the changes, squash/amend it with the previous one and
re-send a new version (with git send-email you can use -v2, -v3, etc.)


Also this patch is unreviewable in this current form as it is filled
with countless code formatting changes completely unrelated to the actual
changes, as far as I can see…

> Thanks for the review!
> Sorry about the mistakes, fixed them
>
> Signed-off-by: Petro Mozil 

[…]

Thanks,
Marvin Scholz
___
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 v5] avcodec/jpeg2000: Fix FF_DWT97_INT to pass the conformance testing defined in ISO/IEC 15444-4

2024-09-12 Thread Pierre-Anthony Lemieux
Looks like a nice improvement. It looks like the size of the
codestreams obtained when running `-q: 20` are larger after the patch
-- maybe related to the change in the step size calculation, which is
now the same for both bitexact and non-bit-exact. Is that expected? I
realize `-q` is arbitrary but this might be surprising to the casual
user.

On Thu, Sep 12, 2024 at 1:52 AM Osamu Watanabe
 wrote:
>
> Fix for the integer version of the inverse 9-7 DWT processing
> (FF_DWT97_INT, https://trac.ffmpeg.org/ticket/10123), which is activated with
> `-flags +bitexact`.
>
> I went through the code path for the DWT 9-7 transform (integer) and improved
> precision to match conformance codestream.
>
> As a result, the encoded codestream size is slightly larger for a given Q 
> value.
> For example, `-flags +bitexact -i lena.pnm -q: 20 -format j2k -y tmp.j2c`
> gives 13K (HEAD) and 19K (with this patch).
>
> This commit also updates the source and reference files for affected FATE 
> tests.
>
> Signed-off-by: Osamu Watanabe 
> ---
>  libavcodec/jpeg2000.c|  6 ++--
>  libavcodec/jpeg2000dec.c |  2 +-
>  libavcodec/jpeg2000dwt.c | 43 ++--
>  libavcodec/tests/jpeg2000dwt.c   |  5 +++
>  tests/ref/fate/j2k-dwt   | 40 +++---
>  tests/ref/fate/jpeg2000-dcinema  |  4 +--
>  tests/ref/fate/jpeg2000dec-p0_04 |  2 +-
>  tests/ref/fate/jpeg2000dec-p0_05 |  2 +-
>  tests/ref/fate/jpeg2000dec-p0_09 |  2 +-
>  tests/ref/vsynth/vsynth1-jpeg2000-97 |  8 ++---
>  tests/ref/vsynth/vsynth2-jpeg2000-97 |  8 ++---
>  tests/ref/vsynth/vsynth3-jpeg2000-97 |  8 ++---
>  tests/ref/vsynth/vsynth_lena-jpeg2000-97 |  8 ++---
>  13 files changed, 74 insertions(+), 64 deletions(-)
>
> diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
> index d6ffb02319..f1a7d55ae1 100644
> --- a/libavcodec/jpeg2000.c
> +++ b/libavcodec/jpeg2000.c
> @@ -260,9 +260,7 @@ static void init_band_stepsize(AVCodecContext *avctx,
>  band->f_stepsize *= F_LFTG_X * F_LFTG_X * 4;
>  break;
>  }
> -if (codsty->transform == FF_DWT97) {
> -band->f_stepsize *= pow(F_LFTG_K, 2*(codsty->nreslevels2decode - 
> reslevelno) + lband - 2);
> -}
> +band->f_stepsize *= pow(F_LFTG_K, 2*(codsty->nreslevels2decode - 
> reslevelno) + lband - 2);
>  }
>
>  if (band->f_stepsize > (INT_MAX >> 15)) {
> @@ -270,7 +268,7 @@ static void init_band_stepsize(AVCodecContext *avctx,
>  av_log(avctx, AV_LOG_ERROR, "stepsize out of range\n");
>  }
>
> -band->i_stepsize = band->f_stepsize * (1 << 15);
> +band->i_stepsize = lrint(band->f_stepsize * (1 << 15) + 0.5f);
>
>  /* FIXME: In OpenJPEG code stepsize = stepsize * 0.5. Why?
>   * If not set output of entropic decoder is not correct. */
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index 2e09b279dc..f68e41ed6a 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -2136,7 +2136,7 @@ static void dequantization_int_97(int x, int y, 
> Jpeg2000Cblk *cblk,
>  int32_t *datap = &comp->i_data[(comp->coord[0][1] - 
> comp->coord[0][0]) * (y + j) + x];
>  int *src = t1->data + j*t1->stride;
>  for (i = 0; i < w; ++i)
> -datap[i] = (src[i] * (int64_t)band->i_stepsize + (1<<15)) >> 16;
> +datap[i] = (int32_t)(src[i] * (int64_t)band->i_stepsize + (1 << 
> 14)) >> 15;
>  }
>  }
>
> diff --git a/libavcodec/jpeg2000dwt.c b/libavcodec/jpeg2000dwt.c
> index 34e33553f7..d24f15d39b 100644
> --- a/libavcodec/jpeg2000dwt.c
> +++ b/libavcodec/jpeg2000dwt.c
> @@ -39,12 +39,12 @@
>
>  /* Lifting parameters in integer format.
>   * Computed as param = (float param) * (1 << 16) */
> -#define I_LFTG_ALPHA  103949ll
> -#define I_LFTG_BETA 3472ll
> -#define I_LFTG_GAMMA   57862ll
> -#define I_LFTG_DELTA   29066ll
> -#define I_LFTG_K   80621ll
> -#define I_LFTG_X   53274ll
> +#define I_LFTG_ALPHA_PRIME   38413ll // = 103949 - 65536, (= alpha - 1.0)
> +#define I_LFTG_BETA   3472ll
> +#define I_LFTG_GAMMA 57862ll
> +#define I_LFTG_DELTA 29066ll
> +#define I_LFTG_K 80621ll
> +#define I_LFTG_X 53274ll
>  #define I_PRESHIFT 8
>
>  static inline void extend53(int *p, int i0, int i1)
> @@ -234,8 +234,11 @@ static void sd_1d97_int(int *p, int i0, int i1)
>  extend97_int(p, i0, i1);
>  i0++; i1++;
>
> -for (i = (i0>>1) - 2; i < (i1>>1) + 1; i++)
> -p[2 * i + 1] -= (I_LFTG_ALPHA * (p[2 * i] + p[2 * i + 2]) + (1 
> << 15)) >> 16;
> +for (i = (i0>>1) - 2; i < (i1>>1) + 1; i++) {
> +const int64_t sum = p[2 * i] + p[2 * i + 2];
> +p[2 * i + 1] -= sum;
> +p[2 * i + 1] -= (I_LFTG_ALPHA_PRIME * sum + (1 << 15)) >> 16;
> +}
>  for (i = (i0>>1) - 1; i < (i1>>1) + 1; i++)
>  p[2 * i] -= (I_LFTG_BETA  * (

Re: [FFmpeg-devel] [PATCH 7/7] avformat/flvdec: Free metaVideoColor

2024-09-12 Thread Steven Liu
Michael Niedermayer  于2024年9月13日周五 07:44写道:
>
> Fixes: memeleak
> Fixes: 
> 70659/clusterfuzz-testcase-minimized-ffmpeg_dem_KUX_fuzzer-4539872627458048
>
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/flvdec.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 22a9b9e4a7c..1fb3e0cd3fa 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -,6 +,7 @@ static int flv_parse_video_color_info(AVFormatContext 
> *s, AVStream *st, int64_t
>  return TYPE_UNKNOWN;
>  }
>
> +av_free(flv->metaVideoColor);
>  if (!(flv->metaVideoColor = av_mallocz(sizeof(FLVMetaVideoColor {
>  return AVERROR(ENOMEM);
>  }
> --
> 2.46.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

lgtm


Thanks
Steven
___
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/vaapi_encode_av1: Fix encode fail since 9db68ed0

2024-09-12 Thread fei . w . wang-at-intel . com
From: Fei Wang 

Signed-off-by: Fei Wang 
---
 libavcodec/vaapi_encode_av1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c
index 6d1be9fc07..1b350cd936 100644
--- a/libavcodec/vaapi_encode_av1.c
+++ b/libavcodec/vaapi_encode_av1.c
@@ -637,7 +637,7 @@ static int 
vaapi_encode_av1_init_picture_params(AVCodecContext *avctx,
 slot = ((VAAPIEncodeAV1Picture*)ref_pic->codec_priv)->slot;
 av_assert0(vpic->reference_frames[slot] == VA_INVALID_SURFACE);
 
-vpic->reference_frames[slot] = ((VAAPIEncodePicture 
*)ref_pic)->recon_surface;
+vpic->reference_frames[slot] = ((VAAPIEncodePicture 
*)ref_pic->priv)->recon_surface;
 }
 }
 
-- 
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] avcodec/vvc: Fix output and unref a frame which isn't decoding yet

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

ff_vvc_output_frame is called before actually decoding. It's possible
for ff_vvc_output_frame to select current frame to output. If current
frame is nonref frame, it will be released by ff_vvc_unref_frame.

Fix this by always marking the current frame with
VVC_FRAME_FLAG_SHORT_REF, as is done by the HEVC decoder.
---
fate sample:
https://drive.google.com/file/d/1U5WGWeSsMFiEkhsl_vL4NiMma-LLh02t/view?usp=drive_link
md5sum:
8054b4b8e62c0171476b40206d044590  Hierarchical.bit

 libavcodec/vvc/refs.c   | 11 +++
 tests/fate/vvc.mak  |  1 +
 tests/ref/fate/vvc-conformance-Hierarchical | 35 +
 3 files changed, 40 insertions(+), 7 deletions(-)
 create mode 100644 tests/ref/fate/vvc-conformance-Hierarchical

diff --git a/libavcodec/vvc/refs.c b/libavcodec/vvc/refs.c
index bebcef7fd6..d3663c7c69 100644
--- a/libavcodec/vvc/refs.c
+++ b/libavcodec/vvc/refs.c
@@ -190,13 +190,10 @@ int ff_vvc_set_new_ref(VVCContext *s, VVCFrameContext 
*fc, AVFrame **frame)
 *frame = ref->frame;
 fc->ref = ref;
 
-if (s->no_output_before_recovery_flag && (IS_RASL(s) || 
!GDR_IS_RECOVERED(s)))
-ref->flags = VVC_FRAME_FLAG_SHORT_REF;
-else if (ph->r->ph_pic_output_flag)
-ref->flags = VVC_FRAME_FLAG_OUTPUT;
-
-if (!ph->r->ph_non_ref_pic_flag)
-ref->flags |= VVC_FRAME_FLAG_SHORT_REF;
+ref->flags = VVC_FRAME_FLAG_SHORT_REF;
+if (ph->r->ph_pic_output_flag && !(s->no_output_before_recovery_flag &&
+   (IS_RASL(s) || !GDR_IS_RECOVERED(s
+ref->flags |= VVC_FRAME_FLAG_OUTPUT;
 
 ref->poc  = poc;
 ref->sequence = s->seq_decode;
diff --git a/tests/fate/vvc.mak b/tests/fate/vvc.mak
index 5335460263..7fd0a47214 100644
--- a/tests/fate/vvc.mak
+++ b/tests/fate/vvc.mak
@@ -1,5 +1,6 @@
 VVC_SAMPLES_8BIT =\
 CodingToolsSets_A_2   \
+Hierarchical  \
 
 VVC_SAMPLES_10BIT =   \
 APSALF_A_2\
diff --git a/tests/ref/fate/vvc-conformance-Hierarchical 
b/tests/ref/fate/vvc-conformance-Hierarchical
new file mode 100644
index 00..0797305b9a
--- /dev/null
+++ b/tests/ref/fate/vvc-conformance-Hierarchical
@@ -0,0 +1,35 @@
+#tb 0: 1/25
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 480x320
+#sar 0: 0/1
+0,  0,  0,1,   230400, 0x3293f7f1
+0,  1,  1,1,   230400, 0xe2570fa4
+0,  2,  2,1,   230400, 0xecd608fb
+0,  3,  3,1,   230400, 0xea46f9f4
+0,  4,  4,1,   230400, 0xb715d24a
+0,  5,  5,1,   230400, 0x69faaf46
+0,  6,  6,1,   230400, 0xf9a362db
+0,  7,  7,1,   230400, 0x2dcd19ca
+0,  8,  8,1,   230400, 0xf8fda185
+0,  9,  9,1,   230400, 0x48a35bfd
+0, 10, 10,1,   230400, 0x27efe832
+0, 11, 11,1,   230400, 0x74279617
+0, 12, 12,1,   230400, 0x91935248
+0, 13, 13,1,   230400, 0x29b621e6
+0, 14, 14,1,   230400, 0x89b1ec0b
+0, 15, 15,1,   230400, 0x898fdba1
+0, 16, 16,1,   230400, 0xc6d18e6f
+0, 17, 17,1,   230400, 0xedff651b
+0, 18, 18,1,   230400, 0x677e2260
+0, 19, 19,1,   230400, 0x930918ef
+0, 20, 20,1,   230400, 0x70da2c30
+0, 21, 21,1,   230400, 0x699a3b9d
+0, 22, 22,1,   230400, 0xff3b1b3a
+0, 23, 23,1,   230400, 0xca11d9a5
+0, 24, 24,1,   230400, 0x904394e0
+0, 25, 25,1,   230400, 0x392e5445
+0, 26, 26,1,   230400, 0x6191f4d8
+0, 27, 27,1,   230400, 0xa7d7be12
+0, 28, 28,1,   230400, 0xbb29752c
+0, 29, 29,1,   230400, 0x14ff297e
-- 
2.42.0

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

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


[FFmpeg-devel] [PATCH] avformat/dvdvideodec: implement seeking

2024-09-12 Thread Marth64
Player applications can now enjoy seeking while playing back
a title. Accuracy is at the mercy of what libdvdnav exposes,
which is currently dvdnav_time_search().

Signed-off-by: Marth64 
---
 libavformat/dvdvideodec.c | 77 ---
 1 file changed, 72 insertions(+), 5 deletions(-)

diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
index 7a859071c3..6bd1dbc17f 100644
--- a/libavformat/dvdvideodec.c
+++ b/libavformat/dvdvideodec.c
@@ -110,6 +110,7 @@ typedef struct DVDVideoPlaybackState {
 int in_pgc; /* if our navigator is in 
the PGC */
 int in_ps;  /* if our navigator is in 
the program stream */
 int in_vts; /* if our navigator is in 
the VTS */
+int is_seeking; /* relax navigation path 
while seeking */
 int64_t nav_pts;/* PTS according to IFO, 
not frame-accurate */
 uint64_tpgc_duration_est;   /* estimated duration as 
reported by IFO */
 uint64_tpgc_elapsed;/* the elapsed time of the 
PGC, cell-relative */
@@ -167,6 +168,7 @@ typedef struct DVDVideoDemuxContext {
 int play_end;   /* signal EOF to the 
parent demuxer */
 DVDVideoPlaybackState   play_state; /* the active playback 
state */
 int play_started;   /* signal that playback 
has started */
+int seek_warned;/* signal that we warned 
about seeking limits */
 int segment_started;/* signal that subdemuxer 
is on a segment */
 } DVDVideoDemuxContext;
 
@@ -715,7 +717,8 @@ static int dvdvideo_play_next_ps_block(AVFormatContext *s, 
DVDVideoPlaybackState
 
 state->in_pgc = 1;
 }
-} else if (state->celln >= e_cell->cellN || state->pgn > 
cur_pgn) {
+} else if (!state->is_seeking &&
+   (state->celln >= e_cell->cellN || state->pgn > 
cur_pgn)) {
 return AVERROR_EOF;
 }
 
@@ -728,7 +731,7 @@ static int dvdvideo_play_next_ps_block(AVFormatContext *s, 
DVDVideoPlaybackState
 if (!state->in_pgc)
 continue;
 
-if ((state->ptt > 0 && state->ptt > cur_ptt) ||
+if ((!state->is_seeking && state->ptt > 0 && state->ptt > 
cur_ptt) ||
 (c->opt_chapter_end > 0 && cur_ptt > c->opt_chapter_end)) {
 return AVERROR_EOF;
 }
@@ -811,6 +814,8 @@ static int dvdvideo_play_next_ps_block(AVFormatContext *s, 
DVDVideoPlaybackState
 
 (*p_nav_event) = nav_event;
 
+state->is_seeking = 0;
+
 return nav_len;
 case DVDNAV_WAIT:
 if (dvdnav_wait_skip(state->dvdnav) != DVDNAV_STATUS_OK) {
@@ -1688,6 +1693,67 @@ static int dvdvideo_close(AVFormatContext *s)
 return 0;
 }
 
+static int dvdvideo_read_seek(AVFormatContext *s, int stream_index, int64_t 
timestamp, int flags)
+{
+DVDVideoDemuxContext *c = s->priv_data;
+int64_t new_nav_pts;
+pci_t*  new_nav_pci;
+dsi_t*  new_nav_dsi;
+
+if (c->opt_menu || c->opt_chapter_start > 1) {
+av_log(s, AV_LOG_ERROR, "Seeking is not compatible with menus or 
chapter extraction\n");
+
+return AVERROR_PATCHWELCOME;
+}
+
+if ((flags & AVSEEK_FLAG_BYTE))
+return AVERROR(ENOSYS);
+
+if (timestamp < 0)
+return AVERROR(EINVAL);
+
+if (!c->seek_warned) {
+av_log(s, AV_LOG_WARNING, "Seeking is inherently unreliable and will 
result "
+  "in imprecise timecodes from this point\n");
+c->seek_warned = 1;
+}
+
+/* XXX(PATCHWELCOME): use 
dvdnav_jump_to_sector_by_time(c->play_state.dvdnav, timestamp, 0)
+ * when it is available in a released version of libdvdnav; it is more 
accurate */
+if (dvdnav_time_search(c->play_state.dvdnav, timestamp) != 
DVDNAV_STATUS_OK) {
+av_log(s, AV_LOG_ERROR, "libdvdnav: seeking to %" PRId64 " failed\n", 
timestamp);
+
+return AVERROR_EXTERNAL;
+}
+
+new_nav_pts = dvdnav_get_current_time   (c->play_state.dvdnav);
+new_nav_pci = dvdnav_get_current_nav_pci(c->play_state.dvdnav);
+new_nav_dsi = dvdnav_get_current_nav_dsi(c->play_state.dvdnav);
+
+if (new_nav_pci == NULL || new_nav_dsi == NULL) {
+av_log(s, AV_LOG_ERROR, "Invalid NAV packet after seeking\n");
+
+return AVERROR_INVALIDDATA;
+}
+
+c->play_state.in_pgc  = 1;
+c->play_state.in_ps   = 0;
+c->play_state.is_seeking  = 1;
+c->play_state.nav_pts = timestamp;
+c->play_state.ts_offset   = timestamp;
+c->play_state.vobu_e_ptm  = new_nav_pci->pci_gi.vobu_s_ptm;
+
+c->first_pts  

[FFmpeg-devel] [PATCH] avcodec/h264: ignore POC when flag is set

2024-09-12 Thread kevmo314
From: Kevin Wang 

When the flag AV_CODEC_FLAG_OUTPUT_CORRUPT or AV_CODEC_FLAG2_SHOW_ALL
is set, ignore any out of order POC's as they may still be valid
frames.

Fixes https://trac.ffmpeg.org/ticket/11190.

Signed-off-by: Kevin Wang 
---
 libavcodec/h264_slice.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index a66b75ca80..fc5a829755 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1341,7 +1341,8 @@ static int h264_select_output_frame(H264Context *h)
 out_idx = i;
 }
 if (h->avctx->has_b_frames == 0 &&
-((h->delayed_pic[0]->f->flags & AV_FRAME_FLAG_KEY) ||
h->delayed_pic[0]->mmco_reset))
+// Check if we should ignore the output order and output the frame
+((h->delayed_pic[0]->f->flags & AV_FRAME_FLAG_KEY) ||
h->delayed_pic[0]->mmco_reset || h->avctx->flags &
(AV_CODEC_FLAG_OUTPUT_CORRUPT | AV_CODEC_FLAG2_SHOW_ALL)))
 h->next_outputed_poc = INT_MIN;
 out_of_order = out->poc < h->next_outputed_poc;

-- 
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 v2] avcodec/vvc: Fix output and unref a frame which isn't decoding yet

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

ff_vvc_output_frame is called before actually decoding. It's possible
for ff_vvc_output_frame to select current frame to output. If current
frame is nonref frame, it will be released by ff_vvc_unref_frame.

Fix this by always marking the current frame with
VVC_FRAME_FLAG_SHORT_REF, as is done by the HEVC decoder.
---
fate sample:
https://drive.google.com/file/d/1U5WGWeSsMFiEkhsl_vL4NiMma-LLh02t/view?usp=drive_link
md5sum:
8054b4b8e62c0171476b40206d044590  Hierarchical.bit

 libavcodec/vvc/refs.c   |  5 +--
 tests/fate/vvc.mak  |  1 +
 tests/ref/fate/vvc-conformance-Hierarchical | 35 +
 3 files changed, 37 insertions(+), 4 deletions(-)
 create mode 100644 tests/ref/fate/vvc-conformance-Hierarchical

diff --git a/libavcodec/vvc/refs.c b/libavcodec/vvc/refs.c
index bebcef7fd6..d5aa2ff28d 100644
--- a/libavcodec/vvc/refs.c
+++ b/libavcodec/vvc/refs.c
@@ -193,10 +193,7 @@ int ff_vvc_set_new_ref(VVCContext *s, VVCFrameContext *fc, 
AVFrame **frame)
 if (s->no_output_before_recovery_flag && (IS_RASL(s) || 
!GDR_IS_RECOVERED(s)))
 ref->flags = VVC_FRAME_FLAG_SHORT_REF;
 else if (ph->r->ph_pic_output_flag)
-ref->flags = VVC_FRAME_FLAG_OUTPUT;
-
-if (!ph->r->ph_non_ref_pic_flag)
-ref->flags |= VVC_FRAME_FLAG_SHORT_REF;
+ref->flags = VVC_FRAME_FLAG_OUTPUT | VVC_FRAME_FLAG_SHORT_REF;
 
 ref->poc  = poc;
 ref->sequence = s->seq_decode;
diff --git a/tests/fate/vvc.mak b/tests/fate/vvc.mak
index 5335460263..7fd0a47214 100644
--- a/tests/fate/vvc.mak
+++ b/tests/fate/vvc.mak
@@ -1,5 +1,6 @@
 VVC_SAMPLES_8BIT =\
 CodingToolsSets_A_2   \
+Hierarchical  \
 
 VVC_SAMPLES_10BIT =   \
 APSALF_A_2\
diff --git a/tests/ref/fate/vvc-conformance-Hierarchical 
b/tests/ref/fate/vvc-conformance-Hierarchical
new file mode 100644
index 00..0797305b9a
--- /dev/null
+++ b/tests/ref/fate/vvc-conformance-Hierarchical
@@ -0,0 +1,35 @@
+#tb 0: 1/25
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 480x320
+#sar 0: 0/1
+0,  0,  0,1,   230400, 0x3293f7f1
+0,  1,  1,1,   230400, 0xe2570fa4
+0,  2,  2,1,   230400, 0xecd608fb
+0,  3,  3,1,   230400, 0xea46f9f4
+0,  4,  4,1,   230400, 0xb715d24a
+0,  5,  5,1,   230400, 0x69faaf46
+0,  6,  6,1,   230400, 0xf9a362db
+0,  7,  7,1,   230400, 0x2dcd19ca
+0,  8,  8,1,   230400, 0xf8fda185
+0,  9,  9,1,   230400, 0x48a35bfd
+0, 10, 10,1,   230400, 0x27efe832
+0, 11, 11,1,   230400, 0x74279617
+0, 12, 12,1,   230400, 0x91935248
+0, 13, 13,1,   230400, 0x29b621e6
+0, 14, 14,1,   230400, 0x89b1ec0b
+0, 15, 15,1,   230400, 0x898fdba1
+0, 16, 16,1,   230400, 0xc6d18e6f
+0, 17, 17,1,   230400, 0xedff651b
+0, 18, 18,1,   230400, 0x677e2260
+0, 19, 19,1,   230400, 0x930918ef
+0, 20, 20,1,   230400, 0x70da2c30
+0, 21, 21,1,   230400, 0x699a3b9d
+0, 22, 22,1,   230400, 0xff3b1b3a
+0, 23, 23,1,   230400, 0xca11d9a5
+0, 24, 24,1,   230400, 0x904394e0
+0, 25, 25,1,   230400, 0x392e5445
+0, 26, 26,1,   230400, 0x6191f4d8
+0, 27, 27,1,   230400, 0xa7d7be12
+0, 28, 28,1,   230400, 0xbb29752c
+0, 29, 29,1,   230400, 0x14ff297e
-- 
2.42.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".